[00:49] <stgraber> that's going to clear the SRU report quite a bit ;)
[01:01] <ScottK> Yes.  Yes it is.
[01:16] <stgraber> commented some more on libart-lgpl to try and remind everyone of what's expected for a multi-arch change in -updates (though the same test should happen in the dev release, really...)
[01:33] <ScottK> Thanks.
[05:15] <micahg> ScottK: regressions in the security pocket, need to be fixed in the security pocket (unless the security team doesn't want to fix them)
[05:15] <micahg> err..unless the security team doesn't want them fixed that way
[05:18]  * micahg guesses in this case it doesn't make much difference
[05:48]  * micahg is referring to the cacti lucid SRU for onlookers
[05:49] <infinity> I was curious.
[05:49] <infinity> So, why not just drop the SRU and reupload it as a security update? :)
[05:49] <infinity> (Assuming it's sane)
[05:52] <micahg> infinity: that would work, but I don't know if it's worth it in this case (shouldn't make a difference), will leave it up to mdeslaur and jdstrand
[09:48] <tkamppeter> hi, it is about the CUPS SRU.
[09:50] <seb128> tkamppeter, hey, what about it?
[09:51] <tkamppeter> I got verifications for 5 of 6 bugs. For one bug, bug 973270 it seems that the original reporter went away.
[09:51] <ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
[09:52] <tkamppeter> The bug is fixed by adding the ipp14 backend, the same fix as for the verified bug 945028.
[09:52] <ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
[09:53] <tkamppeter> The OP of bug 973270 has at least given positive feedback when I asked him to try the ipp14 solution via my PPA.
[09:53] <ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
[09:54] <tkamppeter> So can we simply move cups to -updates then? This would improve the 12.04.1 a lot.
[09:59] <tkamppeter> seb128, ^^
[10:30] <tkamppeter> Anyone has read my messages above?
[10:33] <tumbleweed> generally speaking, we don't need the original reporter to verify the SRU. Anyone can
[10:45] <tkamppeter> tumbleweed, problem here is that it is hardware-dependent, so only someone with a Samsung ML-3710ND (or Samsung with same buggy IPP implementation) can veryfy this fix.
[10:47] <tkamppeter> tumbleweed, due to not getting an answer here (I do not have such a Samsung to verify) I suggest to promote the SRU to -updates based on the other 5 bugs which are all verified.
[10:48] <tkamppeter> The fix for this one bug is the same as the fix for the verified bug 945028.
[10:48] <ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
[10:49] <tkamppeter> tumbleweed, therefore the fix cannot be taken out of the SRU, we simply consider it the fix for bug 945028.
[10:49] <ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
[10:51] <infinity> tkamppeter: Based on the fact that it (a) fixes another bug, and that (b) the general fix (thought not this build) was tested previously, it seems reasonable, but are there any scary regression potentials for that particular part of the update on other hardware?
[10:51] <infinity> tkamppeter: If it's pretty isolated to specific hardware that was already broken, I wouldn't have any issues with being somewhat lax on the one unverifiable bug.
[11:08] <tkamppeter> There are no regression potentials at all, as all other hardware (automatic setup) uses the standard ipp backend. The fix is the addition of an extra backend which needs to get selected manually.
[11:08] <tkamppeter> infinity, ^^
[11:08] <infinity> tkamppeter: Check, that's comforting.
[11:08] <infinity> tkamppeter: I'll look into it more when I do my SRU run later today, then.  Thanks for the heads-up.
[11:09] <infinity> tkamppeter: Can you try to summarise this conversation (especially the bit about the backen having no regression potential due to being a manual selection) in the unverified bug?
[11:10] <tkamppeter> infinity, We will add instructions to the Release Notes of 12.04.1 to manually select ipp14 in case of "bad" hardware. How do I propose an item for the Release Notes?
[11:11] <infinity> tkamppeter: Hrm, is there no way the UI can present it as an option somehow? :/
[11:11] <infinity> tkamppeter: I mean, release notes are fine and all, but the average person who has issues with their printer probably doesn't read release notes.
[11:16] <tkamppeter> infinity, bug 973270 updated.
[11:16] <ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
[11:16] <infinity> tkamppeter: Thanks.
[11:17] <tkamppeter> infinity, currently there is no intuitive GUI way to select the backend. There appear entries in system-config-printer, but they do not tell for what 1pp14 is good for.
[11:17] <infinity> tkamppeter: They can't be annotated some pleasant way?
[11:18] <tkamppeter> infinity, it would require patching system-config-printer and the patch would add new UI strings which will not have a translation.
[11:18] <infinity> (Sorry, printing on Linux isn't my forte, I don't own a printer, and the only people I know who have a printer run Windows but, for instance, I poke at possible drivers for my parents' printer and get "HP LJ6 (PS), HP LJ6 (PCL5), HP LJ6 (PCL6)", etc, etc.  They're not pleasantly-named to non-technical users, but the choice is there, at least.
[11:19] <CareBear\> is now a good time to try to get libusb updates into the next release? :)
[12:49] <ScottK> micahg: OK.
[13:56] <stgraber> infinity: for bug 1021293, our only proper way of testing the fix is to upload a new ubiquity with the refreshed source package, if I do that and confirm that the fix indeed works, are you happy to accept both debian-installer-utils and ubiquity when debian-installer-utils reaches the 7 days mark?
[13:56] <ubot2> Launchpad bug 1021293 in ubiquity "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress] https://launchpad.net/bugs/1021293
[13:56] <stgraber> I believe we might have some more ubiquity fixes coming so I don't really want to see ubiquity stuck for 7 days in proposed when the only delta is a source package refresh
[13:57] <infinity> stgraber: If it's just a refresh of d-i-u, I'm happy to see them go in together, absolutely.
[13:57] <infinity> stgraber: Just remind the SRU-on-duty who accepts d-i-u of this conversation, if it's not me. :P
[13:57] <stgraber> ok :)
[13:58] <stgraber> will upload ubiquity shortly then
[13:59] <infinity> stgraber: You know, if ubiquity is pretty much the only way to verify the d-i-u fix anyway, I'd push the whole mess in today, if you can do some test installs and verify solidly.
[14:01] <infinity> stgraber: Oh, but it needs the accountservice thing too, right?
[14:01] <stgraber> nope, accountservice is another fix for the same bug, any of the two fix should work
[14:01] <infinity> Ahh.
[14:01] <infinity> Yeah, reading the bug log.
[14:01] <stgraber> the accountservice SRU is for people who are using the original 12.04 media without updating ubiquity
[14:01] <infinity> So, they're not interdependant.
[14:01] <stgraber> right
[14:02] <infinity> Right, then I stand by my previous statement.  Get me a ubiquity that's smoke-tested to do ubiquity-ish things, and is well-tested to fix the bug, and the waiting period matters less to me.
[14:03] <infinity> It's not like anyone actually tests installers from proposed enough to make the waiting period mean anything.
[14:04] <stgraber> right :)
[14:04] <stgraber> hmm, looks like the source refresh (using -proposed) will also pick up the calxeda enablement
[14:05] <stgraber> (base-installer 1.122ubuntu7.1 and flash-kernel 2.28ubuntu42.2)
[14:09] <infinity> stgraber: That should all be no-ops for ubiquity anyway.
[14:09] <infinity> stgraber: Since we don't use ubiquity on that platform.  If you just double-check the diffs to make sure the platform-specific bits are guarded.
[14:09] <infinity> (Or I can when you upload)
[14:09] <stgraber> yeah and they are marked verification-done anyway
[14:10] <infinity> Well, they're v-done for d-i.  No one's made sure they don't break ubiquity somehow. :P
[14:10] <infinity> But they really shouldn't, unless Michael did something silly.
[14:11] <infinity> And, actually, we're not building *any* ARM desktop images for 12.04.1 are we?
[14:11] <infinity> So, it's not really a big deal anyway. :P
[14:11] <stgraber> indeed
[14:12]  * infinity goes back to watching TV until his day starts officially.
[14:13] <brendand> stgraber, infinity - for the d-i-u fix what are you guys looking for? would installing the 12.04.1 daily be sufficient verification?
[14:14] <stgraber> brendand: not quite, you need a new ubiquity (I'm working on that), then take an old daily, update just ubiquity and go through the install
[14:16] <brendand> stgraber, how to update just ubiquity?
[14:18] <stgraber> brendand: drop to a shell, apt-get update, apt-get install ubiquity ubiquity-frontend-gtk
[14:18] <stgraber> well, after adding -proposed
[14:19] <brendand> stgraber, when and where do you drop to the shell?
[14:20] <stgraber> infinity: ubiquity uploaded. Diff looked sane, delta is arm-specific except for d-i-u (as expected), though not all of the arm delta is highbank-specific, there's also a change for omap3/omap4 kernel handling with the linaro kernels (but nothing that looked wrong)
[14:20] <stgraber> brendand: before starting the install
[14:20] <stgraber> anyway, it's a trivial SRU verification for someone who knows what to look for, so I'll do it as soon as my new ubiquity is accepted and built
[14:24] <cjwatson> brendand: Yeah, if you want to test this properly then you need to start with 12.04(.0) and upgrade ubiquity - otherwise you have a new accountsservice and don't encounter the bug
[14:24] <cjwatson> Although testing with a more current daily might be good for regression analysis
[14:25] <cjwatson> Daviey: How did things go with the new squashfs-based server CD last week?
[14:26] <cjwatson> I'd have looked in on it but I was knocked offline.
[14:35] <stgraber> can someone please reject the ubiquity in precise-proposed? (missing bug reference)
[14:37] <stgraber> pushing a new one now
[14:58] <ScottK> stgraber: Done.
[14:59] <stgraber> thanks
[15:13] <Daviey> cjwatson: it looks swell!
[15:14] <Daviey> cjwatson: I noticed that report.html is skewed.. and there was something else trivial (escaped me atm)
[15:14] <Daviey> but yeah, it looks great!  So thanks mucly
[15:14] <infinity> cjwatson: Your statement about accountservice would be true if it were fixed, but that's still in the queue. ;)
[15:14] <infinity> cjwatson: (Though that will probably change today, I guess)
[15:23] <stgraber> infinity: if you have a sec to look at that ubiquity upload, it'd be appreciated. I'm kind of hoping for it to be published and ready for testing post-lunch here.
[15:24] <cjwatson> Daviey: Yeah, I was meaning to attack the installability report
[15:24] <infinity> stgraber: I'll poke in a sec.
[15:24] <cjwatson> Cool
[16:02] <ScottK> infinity: The amavisd-new SRU in queue fixes a problem that will cause 10.04 -> 12.04 upgrade failures, so it'd be really nice to get that in soon.
[16:25] <Laney> SRU people: Do you mind if multiple SRUs are tracked in the same bug if they are tied together?
[16:30] <infinity> Laney: If it's all addressing the same bug, multiple tasks on the one bug are just fine.
[16:32] <Laney> tidy
[16:35] <ScottK> Thanks infinity .
[16:36] <infinity> NP.
[16:47] <Laney> leave transmageddon for now, still got bug wrangling to do
[16:47] <infinity> Laney: Sure, I'll look at it next week. ;)
[16:48] <Laney> I'm sure other people process SRUs too :P
[16:51] <infinity> I'll be sure to let them know not to!
[16:51] <infinity> RAOF, ScottK, SpamapS, bdmurray, slangasek: Laney doesn't want anyone to process his SRUs, ever.
[16:52] <infinity> Laney: There. ;)
[16:52]  * ScottK makes a note.
[16:56] <Laney> poison supplier copenhagen
[16:56] <Laney> whoops, this isn't google!
[16:57]  * infinity starts building immunities to Danish poisons.
[17:06] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/copy-auto-approve/+merge/117299 so close ...
[17:12] <highvoltage> /win 23
[18:31] <stgraber> infinity: there you go, that's bug 1021293 verified
[18:31] <ubot2> Launchpad bug 1021293 in accountsservice "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress] https://launchpad.net/bugs/1021293
[18:52] <Laney> utouch stuff was removed before the new things built?
[18:54] <micahg> hrm? why does Firefox have new binaries?
[18:54] <highvoltage> Laney: hmm, is utouch stuff coming to the archives?
[18:55] <Laney> highvoltage: It's Canonical's multitouch stuff
[18:55] <Laney> has been around for some time
[18:55] <Laney> just seems to be a slightly abrupt transition
[18:56] <skaet> Laney,  there's some renaming going on.   Its probably a transitory side-effect.
[18:57] <Laney> skaet: I see that :-)
[19:12]  * skaet experimenting with building precise from proposed images before adding to cron job
[19:15] <micahg> ah, the new Firefox binaries from -security were never seen in -proposed, /me files bug
[19:19] <micahg> Bug #1031027
[19:19] <ubot2> Launchpad bug 1031027 in launchpad "new binaries seen in -updates/-security hit binary NEW in -proposed" [Undecided,New] https://launchpad.net/bugs/1031027
[19:51] <infinity> Laney: I removed the sources, not the binaries...
[19:52] <infinity> micahg: Pretty sure that bug already existed.
[19:52] <micahg> infinity: couldn't find it :)
[19:52] <micahg> feel free to dupe
[19:54] <Laney> infinity: I don't see it in Packages
[19:54] <Laney> and I noticed because of the ubuntustudio daily image build failure
[19:55] <Laney> (libgrip0 uninstallable)
[19:55] <infinity> Erk.  Maybe the remove-package --source-only thing doesn't work? :/
[19:57] <infinity> Dangit.
[19:58] <Laney> Oh well. Accept it and we can transition stuff.
[19:58] <infinity> Can't until it's built everywhere.
[19:58] <infinity> Thanks, firefox.
[19:59] <infinity> *sigh*
[19:59] <infinity> Checked command history, I definitely removed only source.  And terminal log claimed it was doing that too.
[19:59] <infinity> Not sure if I blame the API utility, or the API itself.
[20:00] <Laney> staging is a fine playground
[20:01] <stgraber> infinity: and you didn't get a failure e-mail from LP? (with the new async stuff, the "yay it worked" from the client doesn't mean much anymore...)
[20:01] <infinity> stgraber: Removals aren't async, are they?
[20:01] <infinity> stgraber: But it's clearly not a failure.  It worked "too well". :P
[20:03] <Laney> I don't see that you can just remove source.
[20:03] <Laney> requestDeletion
[20:03] <Laney> Delete this source and its binaries.
[20:04] <infinity> Well, the old tool used to be able to, but it didn't use the API.
[20:04] <infinity> So, if the API can't, Colin shouldn't have pretended it could in the help text. :)
[20:05] <Laney> Looking at the source, it certainly tries to.
[20:06] <Laney> hah, comment in LP's source:
[20:06] <Laney>         # Special deletion method for the api that makes sure binaries
[20:06] <Laney>         # get deleted too.
[20:06] <infinity> GAH.
[20:09] <infinity> Well, bug #1031061 at any rate.
[20:09] <ubot2> Launchpad bug 1031061 in ubuntu-archive-tools "remove-package --only-source doesn't do as advertised" [Undecided,New] https://launchpad.net/bugs/1031061
[20:10] <Laney> ITYM source-only
[20:11] <infinity> Laney: That, yes.  I actually used -S, used the long form in the bug title to avoid ambiguity.  Clearly failed. ;)
[20:12] <infinity> Fixed.
[20:14] <slangasek> infinity: do you know offhand what launchpad is using to generate Packages files?  is it apt-ftparchive?
[20:15] <slangasek> apt-ftparchive appears to mangle package descriptions that contain leading whitespace
[20:17] <elmo> slangasek: it is
[20:17]  * slangasek nods
[20:17] <slangasek> thanks
[20:19] <infinity> slangasek: Yes.
[22:33]  * slangasek wonders why copy-package seems to be working only intermittently for him in partner
[22:35] <slangasek> oh, or perhaps it's working but dropping things in unapproved without telling me and without me noticing ;)