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