[10:26] <Riddell> who can tell me what's wrong with kwrited-data in proposed
[10:30] <Riddell> I removed it from the kwrited source package and I ran remove-package but it still complains in update_excuses
[10:33] <Laney> Riddell: I still see it in vivid-proposed. Did you wait for the publisher?
[10:35] <cjwatson> https://launchpad.net/ubuntu/vivid/amd64/kwrited-data still shows it as published.  What was your remove-package command line?
[10:36] <cjwatson> Riddell: ^-
[10:36] <cjwatson> That's not just a "wait for publication" issue; the removal didn't happen.
[10:36]  * Laney nods
[10:36] <Riddell> seems to have disappeared from my bash history
[10:37] <cjwatson> Should be: remove-package -m 'some reason' -s vivid-proposed -b kwrited-data
[10:38] <Riddell> ok run that now, let's see if that helps, thanks cjwatson
[10:38] <Riddell> whatever will we do when you're no longer around!
[10:39] <cjwatson> Oddly your removal seems to have worked for some arches but not others.
[10:39] <cjwatson> See https://launchpad.net/ubuntu/vivid/powerpc/kwrited-data
[10:39] <cjwatson> I'll still be around to diagnose Launchpad-related weirdness :-)
[10:40] <cjwatson> Oh, from the publication history above, looks like you removed it from vivid rather than from vivid-proposed, I think
[11:46] <infinity> Riddell: When you can't bug Colin, I'm sure you'll find someone else who knows most of the same answers.
[13:56] <teward> if I want specific built binaries removed from current Ubuntu releases (not the dev release), do I have to bug the tech board about it, or is there a specific list I should email to for discussing it?
[13:57] <infinity> teward: As a general rule, the answer to that is "no".
[13:58] <infinity> teward: A first starting point would to mail the ubuntu-archive list about it, though.
[13:58] <teward> infinity: okay... that kind of explains that, and was assumed, the issue being E:NotFixableAndNeverMaintainedAnymore for specific binaries in a source package, but meh
[14:01] <infinity> teward: We've done SRUs in the past to disable specific bits of software and point users in a more supportable direction, but that should also be considered a last (or second-last, I guess) resort.
[14:03] <teward> infinity: right, the issue here goes back to https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1392319, a case of the naxsi that's included in that being ancient beyond reason, and it being dropped in Debian because nobody on the Debian maintaners for the nginx package use naxsi and can support or diagnose it.  with users still using it and it being filled with holes and those specific binaries not being supportable, I'm not sure
[14:03] <teward> whether it can even be sanely kept...
[14:03] <ubot2> Launchpad bug 1392319 in nginx (Ubuntu) "naxsi-ui-extract does not work" [Undecided,New]
[14:03] <teward> but again, as you said, last or second-last resort...
[14:04] <teward> i think it's more of a case that "This is never going to be fixed and we don't maintain it anywhere anymore", for the bug and package, but that kind of breaks triage guidelines...
[14:04] <teward> (specifically for the nginx-naxsi-* binaries)
[14:07] <teward> infinity: i'll probably end up emailing the list anyways.  but i have a few other things on my radar first
[14:45] <infinity> teward: Does one of the other flavours support everything naxsi does except for the naxsi bit itself?
[14:46] <infinity> teward: An unfriendly-but-workable solution would be to turn nginx-naxsi into an empty package that depends on another flavour, and pops up a preinst note telling the user that they're about to be shafter and sidegraded, and why that is.
[14:46] <teward> infinity: AFAIK naxsi is unique - there's nothing that does what naxsi does.  I"m already beyond the argument of making the package empty
[14:47] <infinity> teward: But it might also pay to discuss with Debian what they plan to do for their stable releases.
[14:47] <teward> infinity: i know it's already dropped in testing - the unstable changes as such migrated
[14:48] <teward> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746199#18 is the most relevant
[14:48] <ubot2> Debian bug 746199 in src:nginx "Outdated naxsi version, incorrect learning tools included in packages" [Important,Fixed]
[14:48] <teward> even states as such that the "naxsi packages are going to be removed before jessie is frozen"
[14:48] <infinity> teward: Right, I can see what they've done for jessie, I meant what they plan to do for wheezy.
[14:48] <teward> infinity: i don't think they can make the changes in wheezy
[14:49] <teward> infinity: i'm not on their maintainers team, but I can poke people and see what they're thinking
[14:50] <infinity> teward: Well, my gut feeling would be "fix the broken tool" (or replace it with the right one, if it's literally the wrong tool).
[14:51] <teward> infinity: and therein lies the crucial issue, and rbasak echoed that
[14:51] <infinity> teward: As for "it's old and upstream has moved on", the answer is generally "too bad".  That's true of all software in a stable distribution.
[14:51] <rbasak> I suggested to just leave a Trusty task open.
[14:51] <teward> infinity: right, again, i'm already well past my initial question
[14:51] <teward> exactly
[14:51] <teward> rbasak: i pinged you after my first comment here :)
[14:51] <rbasak> If someone does come along with something SRU-able that fixes everything, then we wouldn't refuse that.
[14:52] <infinity> Thankfully, those packages are in universe, so no one has actually committed to supporting them.
[14:52] <infinity> Aren't we glad we split that up. :P
[14:52] <rbasak> :)
[14:53] <teward> rbasak: in the mean time per your recommendation i'm writing a comment on the bug that there's nobody to maintain the naxsi section, so it'll just remain open until someone in the community tries and supports it
[14:53] <rbasak> Though in part, I presume nobody reviewed naxsi for supportability because it wasn't a candidate for main
[14:53] <teward> infinity: yeah, definitely glad about that, nginx core plugins behave themselves :P
[14:53] <teward> rbasak: yeah, probably that, bigger issue is that it still has third-party modules in it, so sarnold's initial argument about the third-party plugins in the MIR for nginx remains.
[17:19] <elfy> Laney: hey - apparently you're the owner of the vid for the 15:00 release session - the video at summit isn't viewable
[17:21] <Laney> I know, it's processing
[17:21] <Laney> youtube needs more hamsters
[17:22] <elfy> okey doke - thanks Laney :)
[18:14] <Laney> elfy: there
[18:55] <bdmurray> tracker doesn't fall under the gnome MRE does it?
[18:58] <elfy> Laney: cheers