[00:31] ScottK: so there's a python-cinderclient upload in raring-proposed which, according to bug #1191848, seems to have been intended for -backports? [00:31] Launchpad bug 1191848 in raring-backports "please backport cinderclient 1.0.4 to raring" [Wishlist,Confirmed] https://launchpad.net/bugs/1191848 [00:36] hmmph [01:22] would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that? [01:22] Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress] [01:22] slangasek: I'm away from an appropriate computer, would you please reject and reupload to backports? === jbicha is now known as Guest92324 [03:51] ScottK: done [03:51] Thanks. Just now got to my computer to look in on it. [04:04] ScottK: well, it seems my upload didn't take anyway, because it's older than the version in the archive. Is the upload target for backports still the same? [04:04] I mean, the same as the rest of Ubuntu uploads [04:04] Yes, just foo-backports for release. [04:04] hmm, that's what I had [04:05] oh [04:05] ok, that upload was *really* broken [04:05] it was an upload of 1.0.3, in response to a request for backporting 1.0.4. And saucy now has 1.0.5. [04:05] * slangasek washes his hands of this mess [04:06] I'll take a look at it. Thanks. [04:59] That was not fun. [05:00] Ended up uploading both a fix to 1.0.5 in saucy and having to fish 1.0.4 out of LP (and fix it as well). [05:08] One more time, with the epoch ... [10:52] is it possible to upload blender in saucy or am I too late? I have made a bug report: https://bugs.launchpad.net/ubuntu/+source/blender/+bug/1220384 [10:52] Launchpad bug 1220384 in blender (Ubuntu) "FFe: Blender to version 2.86a" [Undecided,New] [10:54] thotz, fix https://launchpad.net/ubuntu/+source/blender/2.68a-3 's build failure:P [11:02] smartboyhw: that's my problem. I can't do such things. [11:02] thotz, why? [11:05] not enough knowledge. maybe wrong channel here, last time I asked to get gimp 2.8.6 in saucy that was in ubuntu-devel. [11:05] but i read about ffes [11:10] thotz, now that it's in -proposed, it doesn't need an FFe. You just need to make it build. [11:13] smartboyhw: ok i understand. I removed ffe from the bug. [11:21] smartboyhw: but the build thing, but I think blender 2.68a should be in Saucy. I'm a simple bug triager and I like to test new things. I simply have no time for more. but thank you! [18:01] would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that? [18:01] Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress] [18:01] ^ Laney, stgraber ? [18:02] darkxst: you'd need a FFe [18:15] stgraber, ok, updated bug [21:26] hey [21:26] there seems to be something wrong with this package build: https://launchpad.net/ubuntu/+source/android/20130905-0ubuntu4/+build/4943178 it's been running for 2 hours and stopped making progress; previous builds on the same buildd took 45mn [21:28] I'm tempted to try this Cancel build button [21:28] lool: I'll wait till :45 see if it's just some horribly slow I/Os on that final dpkg-deb call, if not, I'll cancel, disable that buildd and have it restarted somewhere else [21:29] infinity: ^ (stuck on lamiak) [21:29] it finished [21:30] 2013-09-07 19:41:59+0000 [-] Returning build status: OK [21:30] I've no idea why launchpad's claiming it's still building [21:30] special [21:31] so unless we've got some of the LP guys around (wgrant?) I guess our best bet is to cancel the build and have it rebuilt (and waste 45min of buildd time...) [21:32] (or cjwatson perhaps) [21:33] would be nice to preserve the broken build somehow, to allow investigation [21:33] not sure whether upload an ubuntu5 would be any better than cancelling the build on that respect? [21:34] well, between what elmo said above, the build log (that I believe is now always kept) and the fact that it's clearly currently in state BUILDING in LP, I don't think we'd loose any debugging data by cancel+rebuild [21:34] (and that'd save myself an android re-upload) [21:35] ok, lets do it then [21:37] canceling (well, trying to anyway), not sure what'll happen since there's nothing to cancel on the builder side [21:37] seems to stick in the Cancelling state; can't possibly be long since there's nothing to do? [21:38] yeah... I'll upload another no change rebuild then [21:39] thanks, sorry for your waster time and bandwidth [21:39] *wasted [21:40] uploaded [21:47] elmo: hey, if you're still around, could you check the status of: [21:47] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943255 [21:47] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943251 [21:47] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943247 [21:48] those are chromium builds all pretty much at the end of the build process and using the 3 other i386 buildds [21:48] so I'm wondering if we don't have some kind of bigger issues with all our buildds being somehow stuck [21:49] the chromium builds on the amd64 buildds also appear to be done but still running according to LP... [21:54] Does buildd-manager need a restart perhaps? [21:54] elmo: Can you give buildd-manager a restart on alpaca? [21:56] stgraber: You didn't need a no-change rebuild for that, it's quite clearly (I think) buildd-manager being stuck, not the buildd. [21:56] infinity: yeah, it wasn't clear at the time (I hadn't spotted that all the other builds were in the same state) [21:56] That's the failure mode for buildd-manager being stuck. Build finishes, but never gets reaped. [21:58] Yeah. Sorry I didn't get here in time, could have saved you a reupload. [21:58] lool: FWIW this failure mode cannot ever have anything to do with the archive [21:58] Shame I was eating dinner at the time people were cancelling and reuploading. [21:58] Oh well. [21:58] The cancel will probably not actually happen (even though it claims it's happening) [21:59] Now we wait patiently for someone to restart buildd-mangler, or call the emergency number. [21:59] cjwatson: It should happen when buildd-manager is restarted and picks up its new state, I'd guess? [21:59] well, I should have checked /builders before re-uploading, not after. How well, we'll just waste 45min of one i386 builder, it's not the end of the world. [21:59] Or maybe it'll reap the SUCCESS build instead. [21:59] infinity: No, neither [22:00] infinity: It isn't actually cancelling because it succeeded - the cancel actually gets ignored [22:00] cjwatson: What do you figure will happen? Fail the builder and cry for help? [22:00] infinity: (But it might be superseded by the time it succeeds) [22:01] cjwatson: Want to ring up elmo before it's too late in the UK for that to be a polite thing to do, and we'll get it all unstuck? [22:02] infinity: Could somebody else? The children are asleep after something of a battle to get them that way and I'm trying to avoid making noise. [22:02] I'm just trying to avoid the double-whammy of long distance and roaming charges. :P [22:03] I can call [22:03] Danke. [22:03] is it the emergency number, or literally elmo's number that I should call? [22:03] Well, given that elmo was here ~30m ago, calling him would probably be sane. [22:04] The emergency number, if you'd prefer not to bug elmo. [22:04] (Though he might be the on-call guy anyway) [22:04] I'll try the emergency one, seems more appropriate [22:04] I would use the emergency number. [22:04] Assuming this is actually something that can't wait. [22:05] It can't wait until Monday, we seem to have thoroughly buggered all the x86 buildds. [22:05] (buildd-manager isn't actually totally dead, it's just having its usual problems with certain builds) [22:05] Yeah, but it's "dead enough". [22:05] Yeah [22:05] Did someone remove the 80% rule for PPAs for me? [22:05] cjwatson: Was that you? [22:05] Just in case people were under the impression that it was actually entirely crashed [22:05] infinity: Yes, I did [22:06] cjwatson: Just for non-virt, or for all PPAs? [22:06] Across the board [22:06] Shiny. [22:06] Given decent cancellation it provides no real benefit [22:06] * infinity nods. [22:06] Might as well build things as fast as possible and then occasionally need to cancel when something needs to jump the queue NOW [22:06] Yeahp, that was my argument too. [22:06] The most efficient use of resources is to be always building. [22:07] (Also it was a pain to fit that code into wgrant's refactoring, because it meant that dispatch logic depended on things that happened earlier in the same scan [22:07] ) [22:10] stgraber: finally figured out the sbsigntool bug, so sbsigntool + shim-signed 1.3 are now uploaded [22:10] slangasek: nice! thanks [22:10] which gives us actual secureboot netboot, as soon as we get a pregenerated tftp-capable grub [22:11] slangasek: Say, where's my non-crufty apt? :) [22:11] slangasek: (er, yeah, not ignoring you on that, just didn't have bandwidth to think about it at the weekend) [22:11] cjwatson: no problem :) [22:11] slangasek: Regarding sbsigntool, is this something we want backported/SRUed? [22:12] * cjwatson -> away [22:12] * infinity notes that ftpmaster is still running 0.4-0ubuntu2~0.IS.10.04.1, which could explain some curious things I see in publisher logs. [22:13] infinity: apt> I'll do that later this evening, I really needed to be done with this shim nonsense and now I need to not be at a keyboard for a while :) [22:13] infinity: yeah, I think we want gnu-efi, sbsigntool, shim and shim-signed SRUed to 12.04 for 12.04.4 (as we clearly missed 12.04.3) [22:13] stgraber: Check, and current sbsigntool also tossed in lucid-cat, perhaps? [22:13] infinity: backported/SRUed> yeah [22:13] (since that's what actually signs the bits in the archive) [22:14] infinity: can't we make lucid-cat obsolete instead? ;) [22:14] slangasek: 95% of -cat goes away when we upgrade pepo to precise which is happening Very Soon. [22:14] infinity: right, so I would Not Worry About It™ [22:14] slangasek: I've been trying to make sure Soyuz reqs are getting SRUed to precise, so we don't need to rely on cat. [22:15] Which reminds me, time for a dpkg SRU for ppc64el. [22:15] (And a saucy upload) [22:15] we want sbsigntool updated in precise as a precondition for SRUing shim itself; the distro's demands on sbsigntool are much more onerous than the archive's [22:15] is ppc64el landed in dpkg upstream? [22:16] anyway, afk now [22:16] slangasek: It is, yeah. jbailey filed the bug a month or two ago, and I think guillem landed it in 1.17 [22:16] fun [22:16] Which I was going to merge if it ever got to testing, but it's not done so yet. :P [22:16] Anyhow, adding a new arch is a 1 or 2 line patch, not worth the full merge just for that. [22:18] slangasek: Regarding the "need it SRUed to SRU shim", pretty sure that means you need it updated on pepo too. Since the signed binary in shim-signed is coming from pepo, not from your machine. [22:19] Or is shim special? [22:19] Oh, shim is special because it's signed by MS, not us. Derp. [22:20] I keep trying to foget that fact and, apparently, succeeding. [22:20] yeah, the sbsigntool issue was when taking a signed binary, detaching the signature and re-attaching the signature to another binary as is done during shim-signed's build to validate MS signed our binary and not something else. [22:21] current sbsigntool would give us a resulting binary that'd be slightly different (extra padding) and would fail the check. [22:21] Right, go be AFK better. [22:21] fo0bar: Does this mean you're at the other end of the emergency number? [22:22] infinity: it's whoever's on call for the weekend. so yes, for this weekend [22:22] fo0bar: Shiny. We need buildd-mangler restarted on alpaca. [22:23] fo0bar: That would be buildd-manager on alphecca, if you don't speak fluent infinity. :P [22:24] infinity: ... we have so many naming schemes, I took at face value that "alpaca" was a valid hostname [22:24] and was updating sshebang to try to find it [22:24] fo0bar: Hahaha. Sorry about that. :) [22:28] infinity: buildd-manager was hard hung. killed, starting now [22:29] I haven't handled it in a long time, but it appears to be going through the right motions. it's doing ppa-resets now [22:29] It seems to be doing some Stuff and Things, yes. [22:29] Hard to say how happy it is until it's reaped a bunch of these builds. [22:30] infinity: cool. I'll be around; lool was just unfortunate enough to call while I was in the shower. ping me if it doesn't look good [22:31] fo0bar: thanks for restarting [22:32] fo0bar: hope you still managed to finish the shower :-) [22:32] i386 and amd64 look good now [22:32] Yeah, it's all clearing up. [22:32] I see android build was somehow recancelled and is running from start again, that's fine [22:32] lool: That's a new version. [22:32] my initial android build got marked superseded, the second one is building now [22:33] infinity: oh right, it hadn't even started building