[00:05]  * infinity wishes poor queuebot would come back.
[01:36] <infinity> Thanks, mystery queue accepty person.
[03:43] <slangasek> infinity: tested here, and the libisofs patch doesn't give me any more useful MBR tables than the previous version without -partition_offset 16
[03:44] <infinity> slangasek: Well, that seems a bit special, then. :/
[03:44] <slangasek> infinity: so -partition_offset 16 no longer breaks EFI hybrid booting, but I'm not sure if it's worth including this fix just to include the -partition_offset option
[03:44] <infinity> slangasek: (We don't have a hidden static copy or something, do we?)
[03:45] <slangasek> no
[03:45] <slangasek> it's using the new version, and it does cause partition_offset to not break the GPT itself
[03:45] <infinity> Ahh.
[03:45] <slangasek> but the MBR seems to be totally useless on this image in both cases
[03:47] <slangasek> by which I mean, the MBR /partition table/ is useless; obviously the MBR boot sector is working fine
[03:48] <slangasek> so IMHO it's not worth fiddling with libisofs further right now unless something turns up in testing
[03:48] <slangasek> considering we still have SB pieces to put together, which is going to take a bit of time
[03:48]  * infinity nods.
[03:49] <infinity> I'm too busy wasting my weekend with Pandas to have opinions. :P
[07:37] <ara> good morning!
[07:38] <ara> anybody around from the release team willing to review a FFe request?
[07:38] <ara> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1060211
[07:38] <ubot2> Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed]
 good morning!
[08:29] <ara>  anybody around from the release team willing to review a FFe request?
[08:29] <ara>  https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1060211
[08:29] <ubot2> Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed]
[08:59] <ara> Laney, ^ ?
[09:02] <Laney> hi ara, will look at the queue in a bit
[09:02] <Laney> make sure it's New and has ubuntu-release subscribed
[09:10] <ara> OK, I will, thanks
[09:10] <ara> Laney, it is
[09:10] <Laney> ok
[11:23] <cjwatson> ^- asymptotically approaching working secure boot; Steve and I cross-reviewed each other's changes and at least my grub-install changes are battle-tested on relevant hardware
[11:24] <cjwatson> would greatly appreciate quick review so that we have a chance of getting working images by ~tomorrow
[11:25] <cjwatson> also it'd be nice to get my 20 no-change rebuilds this morning accepted; running out of time
[11:25] <Laney> unapproved: the gift that keeps on giving
[11:35] <cjwatson> thanks
[11:35] <Laney> what's left?
[11:35] <cjwatson> for sb?
[11:35] <Laney> yeah
[11:37]  * Laney eyes lplib
[11:37] <Laney> I do not want to set a password for my keyring every time, thanks
[11:38] <cjwatson> grub-efi-amd64-signed.postinst tweak to run grub-install and update-grub on configure; shim-signed upload with MS signature + possibly calls to things like sbkeysync; grub-installer change to install grub-efi-amd64-signed and shim-signed if SB active; debian-installer work to use gcdx64.efi.signed rather than building its own image; and possibly a cdimage tweak to make use of that
[11:39] <cjwatson> oh, and probably something to arrange for the signed kernel to be installed
[11:39] <cjwatson> so still quite a few elements but I think they are individually mercifully small by this point
[11:40] <cjwatson> (it would all have been done a month or two ago if we hadn't been politically stalled for ages, but anyway :-/)
[11:40] <Laney> fair do
[11:40] <Laney> hopefully I'll be able to run it here
[12:03] <cjwatson> ^- that'll be the amd64 binary for signing; an AA should accept it iff they feel that my most recent changes are not a security compromise
[12:58] <ara> Laney, any news for my FFe? 0:-)
[13:06] <Laney> ara: just replied
[13:06] <Laney> also, punted some removals to the -archive queue
[13:13] <ara> Laney, fantastic, thanks!
[13:41] <apw> cjwatson, the above linux-meta carries the new linux-signed-* meta packages
[13:56] <apw> cjwatson, the above linux-signed carries fixed up binary dependancies to include linux-image-extras so we get all of the modules
[14:00] <cjwatson> apw: both look good, thanks
[14:05] <cjwatson> Hum
[14:05] <apw> hum sounds bad
[14:06] <cjwatson> jdstrand: Can I promote linux-signed without an MIR?  The installer's going to want to install it, and it's just a signed copy of code maintained elsewhere
[14:07] <cjwatson> I left linux-signed-{,image-}generic in universe for the time being
[14:07] <apw> ahh yes, and now the installer will need them, croak
[14:28] <cyphermox> I'm just finding out that the ModemManager orig tarball in the archive is bad and missing stuff; should I just upload the right one now (after re-testing) to make sure things still work, given that I had all the necessary FFEs?
[14:28] <cyphermox> fwiw; the missing stuff appears to be just bugfix that should have made it but somehow didn't
[14:29] <cyphermox> and the cause of the issue looks like it was because I'm working with a few versions of ModemManager at the same time, I handled the wrong tarball
[14:30] <cjwatson> I'd say just upload it to the queue, obviously with a new upstream version number for the changed.orig
[14:30] <cjwatson> *changed .orig
[14:30] <cyphermox> cjwatson: alright
[14:38] <TheLordOfTime> when's the final EOL date for 12.04?
[14:38] <TheLordOfTime> s/12.04/11.04/
[14:38] <TheLordOfTime> (yes, i failed to type 11.04, but the 1 and 2 keys are righ tnext to each other :P)
[14:40] <cyphermox> https://wiki.ubuntu.com/Releases
[14:41] <TheLordOfTime> cyphermox, it states October 2012, i was looking for a more specific date :P
[14:44] <cjwatson> by default, exactly 18 months after original release
[14:44] <cjwatson> whether that's actually when it happens depends on available effort
[15:03] <jbicha> personally, I'd prefer the definition of "18 months" to be once the third release after comes out, I didn't like that maverick was EOL before precise came out
[15:04] <cjwatson> Yeah, I don't really feel strongly about it either way; three releases give or take a few weeks is roughly what it's always meant, I think
[15:05]  * smartboyhw agrees
[15:07] <cjwatson> So, it looks as though the ARM buildd issues are fixed; we're catching up on some urgent security builds, and will then retry the current broken ones from quantal-proposed
[15:09] <seb128> ^ libreoffice is Sweetshark second try at fixing the arm* builds
[15:10] <cjwatson> seb128: the previous builds are still going though?
[15:11] <seb128> cjwatson, well, he said that his test build on scheat finished before the buildds and failed on a packaging error (he didn't correctly update some part after disabling the plugins on arm)
[15:11] <seb128> cjwatson, so the current builds are going to fail at some point
[15:12] <cjwatson> Hm.  OK, but I'd like to not fill up the ARM builders with libreoffice just now
[15:12] <seb128> your call
[15:12] <cjwatson> Trying to spread things out a bit
[15:12] <seb128> feel free to kill the current libreoffice builds there
[15:12] <cjwatson> I can't
[15:13] <cjwatson> Well, only by asking IS
[15:13] <seb128> hum, k ... well anyway, when there is spare arm* builder time you might want to throw that new libreoffice at them ;-)
[15:13] <cjwatson> Which I guess might not be a terrible idea
[15:13] <seb128> seems worth it if you need arm* builds
[15:30] <Laney> cyphermox: wowzers, that's quite the diff (modemmanager)
[15:33] <cjwatson> OK, libreoffice builds killed, security builds at higher score already, accepted new libreoffice
[15:34] <cjwatson> Well, accepting - IIRC last time it took a few attempts
[15:34] <cjwatson> Currently nine geckos and two webkits building, so it'll take a while for much else to get a look-in
[15:35] <cjwatson> Oh, good, libreoffice accepted first try
[15:36]  * Laney checks how long webkit takes
[15:36] <Laney> 1 day, 8 hours, 59 minutes, 10.0 seconds
[15:36] <Laney> oh good
[15:36] <cjwatson> Quite
[15:50] <cyphermox> Laney: yeah, had a "major" issue with the upstream tarball
[15:51] <cyphermox> this is how things should have been since Sep. 7
[15:53] <cyphermox> I re-tested all my modems and those that worked still do, those that didn't work still don't (but I suspect it's a SIM issue more than the modem, I just didn't get a SIM for them yet)
[15:56] <Laney> cyphermox: Righto ...
[16:35] <bdmurray> Would it be possible to waive the 7 days in -proposed for bug 964674?
[16:35] <ubot2> Launchpad bug 964674 in update-manager "update-manager fails to display an error message" [High,Fix committed] https://launchpad.net/bugs/964674
[19:30] <ScottK> If someone can review/accept clamav today, I can start the microversion update process this evening ....
[19:32] <doko> would it be possible to accept gcc-snapshot so that it builds once the arm queues get empty?
[19:39] <ScottK> Looks like that'll be awhile.
[19:39] <ScottK> I'll try and keep an eye on it though.
[20:03] <popey> is there anything else missing from bug 1063133 to get it synced from debian?
[20:03] <ubot2> Launchpad bug 1063133 in openshot "FFe: Sync openshot 1.4.3-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1063133
[20:26] <doko> cjwatson, how many armv5 uploads are left?
[20:27] <iulian> popey: I was looking at it earlier but I didn't realise that Len was in -studio-dev and thus I didn't do anything. It looks fine to me. Daviey ^
[20:39] <Daviey> ogasawara: Hey, are we expecting a kernel upload soon?
[20:40] <Daviey> iulian: Ah, thanks.. Processing now
[20:44] <Daviey> popey: Done.
[20:44] <popey> awesome, thanks chaps!
[20:52] <cjwatson> doko: about 50
[20:52] <doko> cjwatson, maybe just upload now?
[20:52] <cjwatson> Yeah, I expect I'll do that before I go to bed tonight
[20:53] <doko> the queues should be empty tomorrow, most of the mozilla builds will finish in the next hour
[20:54] <cjwatson> I'll do a few now, but I'll need to go and spend time with K.  I'll be back later
[20:54] <tkamppeter> I have posted a fix for critical bug 1059286 (Avahi).
[20:54] <ubot2> Launchpad bug 1059286 in avahi "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,Fix committed] https://launchpad.net/bugs/1059286
[20:54] <tkamppeter> Can someone upload the fixed avahi package?
[20:56] <doko> looking
[21:02] <cjwatson> doko: uploaded another dozen or so - as I say, I'll do the rest later tonight
[21:04] <doko> tkamppeter, I think the patch itself looks ok. however this is an ABI change. I think you need to change the lib* package name(s), where this struct changes.
[21:04] <doko> tkamppeter, is this change accepted upstream?
[21:05] <doko> I think it would be good to coordinate with debian on the package name change
[21:05] <cjwatson> It's too late to change avahi's soname for 12.10
[21:05] <cjwatson> FWIW
[21:06] <doko> cjwatson, please have a look at the patch, if my conclusion is correct
[21:06] <cjwatson> No time now
[21:06] <doko> ok
[21:06] <cjwatson> Just saying that this is a constraint on what's reasonable for 12.10
[21:06] <cjwatson> (And certainly not saying that it would be OK to change the ABI backward-incompatibly without changing the soname - it wouldn't, of course)
[21:08] <cjwatson> Is struct AvahiDnsPacket part of the public API?
[21:09] <cjwatson> I don't see it in the header files
[21:09] <cjwatson> I mean the installed ones
[21:09] <doko> you don't have time ;)
[21:10] <cjwatson> Yeah, I found a bit after all :)
[21:10] <cjwatson> Because I love you all so much
[21:10] <doko> you better love K.
[21:10] <cjwatson> Heh
[21:10] <cjwatson> So, OK, this is in publicly exported symbols
[21:11] <cjwatson> It depends how opaquely it's defined; if existing binaries outside avahi itself are not allowed to know about the layout of that struct, it's OK
[21:12] <cjwatson> But it would still be worth checking with upstream
[21:12] <tkamppeter> doko, I do not know whether it is accepted upstream, as there is no answer from an upstream developer.
[21:13] <tkamppeter> doko, how does the ABI change look like? If it only adds stuff and does not remove anything or change parameter lists of functions is it then not harmless?
[21:13] <cjwatson> tkamppeter: changes struct layout and size
[21:13] <cjwatson> That *would* be an ABI change if (and only if) existing binaries linked against the library are allowed to know about the layout and size of that struct
[21:14] <cjwatson> If all they do is treat it as a pointer to opaque stuff and use entirely accessor functions, it's OK
[21:14] <cjwatson> That's why I was trying to work that out
[21:15] <tkamppeter> cjwatson, doko, can this perhaps be fixed/worked around by marking the extra symbols/variables private?
[21:15] <cjwatson> I think it's actually OK, because that header file isn't installed for public use, so nothing should be able to know about that struct
[21:16] <cjwatson> This isn't C++
[21:16] <cjwatson> But the header not being installed in /usr/include is a good guarantee anyway
[21:16] <cjwatson> This is just an internal interface within avahi, AFAICS safe to change
[21:17] <doko> indeed, http://packages.ubuntu.com/search?searchon=contents&keywords=dns.h&mode=exactfilename&suite=quantal&arch=any doesn't show anything about avahi
[21:35] <doko> tkamppeter, cjwatson: avahi uploaded
[21:35] <tkamppeter> doko, thank you very much.
[21:35] <doko> tkamppeter, please could you ping this patch upstream?
[21:39] <tkamppeter> doko, the patch is from upstream mailing list and was contributed by a SUSE developer, but I have emphasized anyway that it should go upstream.
[21:59] <cjwatson> doko: Could you have a look at whether speex is OK for ARMv5t?  The recent changelog entries make me unsure about whether a simple rebuild is enough
[21:59] <cjwatson> Stuff about FP
[22:07] <doko> looking
[22:13] <infinity> cjwatson: We probably just want to go back in sync with Debian for speex.
[22:15] <infinity> doko: ^
[22:17] <infinity> cjwatson / doko: Any objections to me just syncing speex, it seems to have picked up other things we'd want (hardening, etc)
[22:17] <infinity> cjwatson / doko: And it's been cooking in unstable/testing for 3 months, should be pretty safe.
[22:18] <doko> ugh, maintainer Ron Lee ..
[22:18] <infinity> Well, yes, there's that.
[22:18] <doko> and a rc report
[22:19] <cjwatson> infinity: Not sure the cross-building patch is in Debian
[22:19] <cjwatson> Is the fortify stuff?
[22:20] <infinity> I don't see a cross-building patch.  Unless you mean multiarch?
[22:20] <cjwatson> Uh, duh, sorry, wrong changelog
[22:20] <infinity> The current Debian version is multi-archy.
[22:21] <cjwatson> tcl8.4 != speex, shockingly
[22:21] <infinity> In all respects, it looks like a sane sync to me, and one less useless delta to worry about.
[22:21] <infinity> Yeah, I get them confused all the time too. ;)
[22:21] <infinity> After looking at the diff, I'll just sync.
[22:21] <cjwatson> If the diff's sane, sure
[22:21] <infinity> You can hold me responsible if it breaks.
[22:21] <doko> infinity, please could you review the proposed patch, and include it if appropriate?
[22:21] <cjwatson> I don't see the RC report
[22:22] <infinity> cjwatson: The PTS is confused, I think.
[22:22] <doko> no, just out of date. it was downgraded
[22:22] <cjwatson> Oh, just slightly out of date
[22:22] <cjwatson> Yeah
[22:24] <infinity> doko: Oh, indeed, the bug and patch look somewhat sane, I think.  Though, I might have to look at more context to judge that.
[22:24] <infinity> cjwatson: You can reject my sync, if you like, I might do an ubuntu1 with the patch in the morning.
[22:24] <doko> thanks
[22:25] <infinity> Meh, I'll reject it myself.  The reject mail will be a reminder to do the merge. :)
[22:25] <cjwatson> No harm doing the sync anyway, surely
[22:27] <infinity> cjwatson: No, no harm except buildd time.  But I guess I'm curious to see that it builds correctly.  Fine, no rejecting.
[22:32] <cjwatson> infinity: Looks fine.  Accepted.
[22:32] <cjwatson> Feel free to follow up :)
[22:33] <cjwatson> Now you have an accept mail as a reminder for the merge. :P
[22:37] <cjwatson> doko: Do you think we should sync zope.interface?  Looks like the only Ubuntu delta was reverted, and the bug fixed in Debian looks potentially interesting
[22:40] <cjwatson> So, aside from that, I just want to look into whether tcl8.4 and vte should be merged
[22:40] <doko> cjwatson, zope.interface: ack
[22:40] <cjwatson> I skipped linux-linaro-omap and linux-linaro-vexpress - I expect those are for userspace tools binary packages, but I really don't see the point as any actual ARMv[56] device is going to need a kernel package anyway
[22:41] <cjwatson> doko: thanks, synced
[22:41] <doko> hmm, there is no way to build python-stdlib-extensions for 3.3
[22:41] <cjwatson> And everything else is uploaded now
[22:41] <doko> or we promote it for main, which we'll do anyway for r
[22:41] <cjwatson> Isn't there a python3-stdlib-extensions?
[22:41] <cjwatson> Oh, right
[22:42] <doko> same source
[22:42] <cjwatson> Different source
[22:42] <cjwatson> According to LP
[22:42] <doko> yeah, but not in main
[22:42] <doko> I mean, 3.3
[22:42] <cjwatson> Mm
[22:43] <cjwatson> Well, you're the one on the MIR team :)
[22:44] <doko> proposing it hinders me to ack it
[22:44] <cjwatson> Sigh, uninstallables.  My bad :-/
[22:45]  * cjwatson does a bit of constructive rescoring
[22:47] <doko> I'll ask security on the 3.3 promotion
[22:47] <cjwatson> I expect the uninstallables will mostly clear as ARM builds flush
[22:47] <cjwatson> Daviey: Any progress on freeipmi?
[22:47] <cjwatson> Final freeze nears
[22:49] <doko> we should rename component-mismatches to server-mismatches ;-P
[22:52] <cjwatson> doh, think I retried pygobject-2/powerpc too early, was reading wrong uninstallables report
[22:52] <cjwatson> hate the primary/ports split there
[22:54] <cjwatson> Yep.  My bad
[22:55] <bdmurray> If I want to upload a new version (same number) of update-manager to precise-proposed I should first use remove package to remove update-manager from precise-proposed correct?
[22:55] <ScottK> Well, for once ppc isn't the slowest one.
[22:55] <cjwatson> Ah, super-long publisher run, bah
[22:55] <ScottK> bdmurray: Is it in the queue or has it been accepted already?
[22:55] <cjwatson> ~18 minutes spent processing a libreoffice translations tarball
[22:56] <cjwatson> bdmurray: You may not ever reuse a version number in the primary archive
[22:56] <cjwatson> Removal won't help you (and if you manage to get it to, you're exploiting a bug)
[22:56] <cjwatson> As ScottK implies, if it's only in the queue then you can reject that and reupload, and that's fine, but if it's accepted you must use a new version
[22:57] <ScottK> Right.  That's where I was going.
[22:57] <bdmurray> Got it thanks.
[22:57] <cjwatson> Version numbers are cheap anyway. :-)
[22:57] <ScottK> Right.  I just used clamav - 0.97.6+dfsg-1ubuntu0.11.04.1~10.04.1~ppa1 for a test package.
[22:58] <ScottK> cheap and potentially ugly.
[23:02] <cjwatson> ScottK: I'm finding it hilarious for powerpc to be so comfortably far ahead again
[23:02] <cjwatson> I notice the absence of calls to drop ARM
[23:03] <ScottK> Right, now that it's armv5, it'll run on lots of stuff Ubuntu couldn't run before.  Maybe people like it for that.  Dunno.
[23:03] <cjwatson> Oh, I just meant ARM in general. :-)
[23:03] <cjwatson> (armv5> As long as you didn't need chunks of universe.)
[23:04] <ScottK> Right.
[23:04] <ScottK> Stale chunks.
[23:04] <cjwatson> Mmm.
[23:05] <ScottK> I liked how some of your rebuilds to drop to v5, the previous changelog entry was a rebuild to bump to v7.
[23:07] <cjwatson> ScottK: Me too :-)
[23:09] <doko> the armel buildds cry for more armv5 uploads
[23:10] <doko> finally, the last mozilla security upload is now building on armel
[23:11] <ScottK> doko: I pushed some more through.
[23:15] <ScottK> Actually I got an upload building sooner on powerpc than on armhf too.
[23:17] <ScottK> cjwatson: Would you please rescore calligra.  It's a longish build and I'd like to see it get started on arm/ppc since AFAIK it's not been built on those archs before.
[23:18] <ScottK> Plus, then I won't feel conflicted about accepting more of the rebuild uploads ....
[23:19] <cjwatson> ScottK: sure, bumped up a bit
[23:19] <cjwatson> hm, maybe a touch higher
[23:20] <ScottK> cjwatson: There is a non-rebuild usb-modeswitch in queue.  How about if you review/accept that one and I'll reject your rebuild only upload.
[23:20] <ScottK> Thanks.
[23:20] <cjwatson> ah, sure, didn't notice that
[23:20] <doko> ScottK, cjwatson: calligra rescores done
[23:20] <ScottK> Thanks.
[23:22] <cjwatson> cyphermox: hm, so I'm not totally comfortable with this
[23:22] <cjwatson> cyphermox: strtok mutates its first argument, and getenv typically returns a pointer straight into environ
[23:22] <ScottK> Are lpia ppa builders permanently gone?
[23:23] <cjwatson> cyphermox: you should really strdup the return value of getenv before calling strtok on it
[23:23] <cjwatson> ScottK: we can reassign x86 builders to lpia temporarily
[23:23] <ScottK> Probably not worth the trouble.
[23:23] <cjwatson> I do it in batches occasionally
[23:24] <ScottK> OK.  It'd be nice to know if the clamav upload I just did for hardy to the ubuntu-clamav PPA will build on lpia.  It'll have to eventually ...
[23:24] <ScottK> No rush though.
[23:24] <cjwatson> cyphermox: So not comfortable with this as it stands and rejecting, but it should be OK if you add a strdup/free pair
[23:25] <ScottK> cjwatson: Should I accept your rebuild then or assume he'll be back before release?
[23:26] <cjwatson> ScottK: Happy to assume he'll be back
[23:26] <ScottK> OK.
[23:27] <cjwatson> ScottK: There are a couple of lpia builders there now.  I'll rebalance again later
[23:27] <ScottK> I think my flight's about to board, so I'll likely vanish in a few minutes.
[23:27] <ScottK> Thanks.
[23:27] <cjwatson> Safe travels
[23:27] <ScottK> LP claims a 6 hour wait for the lpia buildd.
[23:27] <ScottK> I wouldn't wait up for it.
[23:28] <ScottK> ;-)
[23:29] <ScottK> All the rebuilds accepted.
[23:33] <cyphermox> cjwatson: ah, sure. I didn't think of that