[00:31] <slangasek> 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] <ubot2`> Launchpad bug 1191848 in raring-backports "please backport cinderclient 1.0.4 to raring" [Wishlist,Confirmed] https://launchpad.net/bugs/1191848
[00:36] <adam_g> hmmph
[01:22] <darkxst> would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that?
[01:22] <ubot2`> Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress]
[01:22] <ScottK> slangasek: I'm away from an appropriate computer, would you please reject and reupload to backports?
[03:51] <slangasek> ScottK: done
[03:51] <ScottK> Thanks.  Just now got to my computer to look in on it.
[04:04] <slangasek> 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] <slangasek> I mean, the same as the rest of Ubuntu uploads
[04:04] <ScottK> Yes, just foo-backports for release.
[04:04] <slangasek> hmm, that's what I had
[04:05] <slangasek> oh
[04:05] <slangasek> ok, that upload was *really* broken
[04:05] <slangasek> 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] <ScottK> I'll take a look at it.  Thanks.
[04:59] <ScottK> That was not fun.
[05:00] <ScottK> 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] <ScottK> One more time, with the epoch ...
[10:52] <thotz> 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] <ubot2`> Launchpad bug 1220384 in blender (Ubuntu) "FFe: Blender to version 2.86a" [Undecided,New]
[10:54] <smartboyhw> thotz, fix https://launchpad.net/ubuntu/+source/blender/2.68a-3 's build failure:P
[11:02] <thotz> smartboyhw: that's my problem. I can't do such things.
[11:02] <smartboyhw> thotz, why?
[11:05] <thotz> 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] <thotz> but i read about ffes
[11:10] <smartboyhw> thotz, now that it's in -proposed, it doesn't need an FFe. You just need to make it build.
[11:13] <thotz> smartboyhw: ok i understand. I removed ffe from the bug.
[11:21] <thotz> 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] <darkxst> would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that?
[18:01] <ubot2`> Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress]
[18:01] <darkxst> ^ Laney, stgraber ?
[18:02] <stgraber> darkxst: you'd need a FFe
[18:15] <darkxst> stgraber, ok, updated bug
[21:26] <lool> hey
[21:26] <lool> 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] <lool> I'm tempted to try this Cancel build button
[21:28] <stgraber> 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] <stgraber> infinity: ^ (stuck on lamiak)
[21:29] <elmo> it finished
[21:30] <elmo> 2013-09-07 19:41:59+0000 [-] Returning build status: OK
[21:30] <elmo> I've no idea why launchpad's claiming it's still building
[21:30] <stgraber> special
[21:31] <stgraber> 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] <lool> (or cjwatson perhaps)
[21:33] <lool> would be nice to preserve the broken build somehow, to allow investigation
[21:33] <lool> not sure whether upload an ubuntu5 would be any better than cancelling the build on that respect?
[21:34] <stgraber> 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] <stgraber> (and that'd save myself an android re-upload)
[21:35] <lool> ok, lets do it then
[21:37] <stgraber> canceling (well, trying to anyway), not sure what'll happen since there's nothing to cancel on the builder side
[21:37] <lool> seems to stick in the Cancelling state; can't possibly be long since there's nothing to do?
[21:38] <stgraber> yeah... I'll upload another no change rebuild then
[21:39] <lool> thanks, sorry for your waster time and bandwidth
[21:39] <lool> *wasted
[21:40] <stgraber> uploaded
[21:47] <stgraber> elmo: hey, if you're still around, could you check the status of:
[21:47] <stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943255
[21:47] <stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943251
[21:47] <stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943247
[21:48] <stgraber> those are chromium builds all pretty much at the end of the build process and using the 3 other i386 buildds
[21:48] <stgraber> so I'm wondering if we don't have some kind of bigger issues with all our buildds being somehow stuck
[21:49] <stgraber> the chromium builds on the amd64 buildds also appear to be done but still running according to LP...
[21:54] <infinity> Does buildd-manager need a restart perhaps?
[21:54] <infinity> elmo: Can you give buildd-manager a restart on alpaca?
[21:56] <infinity> 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] <stgraber> 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] <infinity> That's the failure mode for buildd-manager being stuck.  Build finishes, but never gets reaped.
[21:58] <cjwatson> Yeah.  Sorry I didn't get here in time, could have saved you a reupload.
[21:58] <cjwatson> lool: FWIW this failure mode cannot ever have anything to do with the archive
[21:58] <infinity> Shame I was eating dinner at the time people were cancelling and reuploading.
[21:58] <infinity> Oh well.
[21:58] <cjwatson> The cancel will probably not actually happen (even though it claims it's happening)
[21:59] <infinity> Now we wait patiently for someone to restart buildd-mangler, or call the emergency number.
[21:59] <infinity> cjwatson: It should happen when buildd-manager is restarted and picks up its new state, I'd guess?
[21:59] <stgraber> 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] <infinity> Or maybe it'll reap the SUCCESS build instead.
[21:59] <cjwatson> infinity: No, neither
[22:00] <cjwatson> infinity: It isn't actually cancelling because it succeeded - the cancel actually gets ignored
[22:00] <infinity> cjwatson: What do you figure will happen?  Fail the builder and cry for help?
[22:00] <cjwatson> infinity: (But it might be superseded by the time it succeeds)
[22:01] <infinity> 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] <cjwatson> 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] <infinity> I'm just trying to avoid the double-whammy of long distance and roaming charges. :P
[22:03] <lool> I can call
[22:03] <infinity> Danke.
[22:03] <lool> is it the emergency number, or literally elmo's number that I should call?
[22:03] <infinity> Well, given that elmo was here ~30m ago, calling him would probably be sane.
[22:04] <infinity> The emergency number, if you'd prefer not to bug elmo.
[22:04] <infinity> (Though he might be the on-call guy anyway)
[22:04] <lool> I'll try the emergency one, seems more appropriate
[22:04] <cjwatson> I would use the emergency number.
[22:04] <cjwatson> Assuming this is actually something that can't wait.
[22:05] <infinity> It can't wait until Monday, we seem to have thoroughly buggered all the x86 buildds.
[22:05] <cjwatson> (buildd-manager isn't actually totally dead, it's just having its usual problems with certain builds)
[22:05] <infinity> Yeah, but it's "dead enough".
[22:05] <cjwatson> Yeah
[22:05] <infinity> Did someone remove the 80% rule for PPAs for me?
[22:05] <infinity> cjwatson: Was that you?
[22:05] <cjwatson> Just in case people were under the impression that it was actually entirely crashed
[22:05] <cjwatson> infinity: Yes, I did
[22:06] <infinity> cjwatson: Just for non-virt, or for all PPAs?
[22:06] <cjwatson> Across the board
[22:06] <infinity> Shiny.
[22:06] <cjwatson> Given decent cancellation it provides no real benefit
[22:06]  * infinity nods.
[22:06] <cjwatson> 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] <infinity> Yeahp, that was my argument too.
[22:06] <infinity> The most efficient use of resources is to be always building.
[22:07] <cjwatson> (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] <cjwatson> )
[22:10] <slangasek> stgraber: finally figured out the sbsigntool bug, so sbsigntool + shim-signed 1.3 are now uploaded
[22:10] <stgraber> slangasek: nice! thanks
[22:10] <slangasek> which gives us actual secureboot netboot, as soon as we get a pregenerated tftp-capable grub
[22:11] <infinity> slangasek: Say, where's my non-crufty apt? :)
[22:11] <cjwatson> slangasek: (er, yeah, not ignoring you on that, just didn't have bandwidth to think about it at the weekend)
[22:11] <slangasek> cjwatson: no problem :)
[22:11] <infinity> 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] <slangasek> 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] <stgraber> 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] <infinity> stgraber: Check, and current sbsigntool also tossed in lucid-cat, perhaps?
[22:13] <slangasek> infinity: backported/SRUed> yeah
[22:13] <infinity> (since that's what actually signs the bits in the archive)
[22:14] <slangasek> infinity: can't we make lucid-cat obsolete instead? ;)
[22:14] <infinity> slangasek: 95% of -cat goes away when we upgrade pepo to precise which is happening Very Soon.
[22:14] <slangasek> infinity: right, so I would Not Worry About It™
[22:14] <infinity> 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] <infinity> Which reminds me, time for a dpkg SRU for ppc64el.
[22:15] <infinity> (And a saucy upload)
[22:15] <slangasek> 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] <slangasek> is ppc64el landed in dpkg upstream?
[22:16] <slangasek> anyway, afk now
[22:16] <infinity> slangasek: It is, yeah.  jbailey filed the bug a month or two ago, and I think guillem landed it in 1.17
[22:16] <slangasek> fun
[22:16] <infinity> Which I was going to merge if it ever got to testing, but it's not done so yet. :P
[22:16] <infinity> Anyhow, adding a new arch is a 1 or 2 line patch, not worth the full merge just for that.
[22:18] <infinity> 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] <infinity> Or is shim special?
[22:19] <infinity> Oh, shim is special because it's signed by MS, not us.  Derp.
[22:20] <infinity> I keep trying to foget that fact and, apparently, succeeding.
[22:20] <stgraber> 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] <stgraber> current sbsigntool would give us a resulting binary that'd be slightly different (extra padding) and would fail the check.
[22:21] <infinity> Right, go be AFK better.
[22:21] <infinity> fo0bar: Does this mean you're at the other end of the emergency number?
[22:22] <fo0bar> infinity: it's whoever's on call for the weekend.  so yes, for this weekend
[22:22] <infinity> fo0bar: Shiny.  We need buildd-mangler restarted on alpaca.
[22:23] <infinity> fo0bar: That would be buildd-manager on alphecca, if you don't speak fluent infinity. :P
[22:24] <fo0bar> infinity: ... we have so many naming schemes, I took at face value that "alpaca" was a valid hostname
[22:24] <fo0bar> and was updating sshebang to try to find it
[22:24] <infinity> fo0bar: Hahaha.  Sorry about that. :)
[22:28] <fo0bar> infinity: buildd-manager was hard hung.  killed, starting now
[22:29] <fo0bar> 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] <infinity> It seems to be doing some Stuff and Things, yes.
[22:29] <infinity> Hard to say how happy it is until it's reaped a bunch of these builds.
[22:30] <fo0bar> 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] <lool> fo0bar: thanks for restarting
[22:32] <lool> fo0bar: hope you still managed to finish the shower  :-)
[22:32] <stgraber> i386 and amd64 look good now
[22:32] <infinity> Yeah, it's all clearing up.
[22:32] <lool> I see android build was somehow recancelled and is running from start again, that's fine
[22:32] <infinity> lool: That's a new version.
[22:32] <stgraber> my initial android build got marked superseded, the second one is building now
[22:33] <lool> infinity: oh right, it hadn't even started building