| 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:31 |
| adam_g | hmmph | 00:36 |
| 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? | 01:22 |
| === jbicha is now known as Guest92324 | ||
| slangasek | ScottK: done | 03:51 |
| ScottK | Thanks. Just now got to my computer to look in on it. | 03:51 |
| 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:04 |
| 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:05 | |
| ScottK | I'll take a look at it. Thanks. | 04:06 |
| ScottK | That was not fun. | 04:59 |
| 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:00 |
| ScottK | One more time, with the epoch ... | 05:08 |
| 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:52 |
| smartboyhw | thotz, fix https://launchpad.net/ubuntu/+source/blender/2.68a-3 's build failure:P | 10:54 |
| thotz | smartboyhw: that's my problem. I can't do such things. | 11:02 |
| smartboyhw | thotz, why? | 11:02 |
| 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:05 |
| smartboyhw | thotz, now that it's in -proposed, it doesn't need an FFe. You just need to make it build. | 11:10 |
| thotz | smartboyhw: ok i understand. I removed ffe from the bug. | 11:13 |
| 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! | 11:21 |
| 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:01 |
| stgraber | darkxst: you'd need a FFe | 18:02 |
| darkxst | stgraber, ok, updated bug | 18:15 |
| 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:26 |
| 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:28 |
| stgraber | infinity: ^ (stuck on lamiak) | 21:29 |
| elmo | it finished | 21:29 |
| 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:30 |
| 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:31 |
| lool | (or cjwatson perhaps) | 21:32 |
| 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:33 |
| 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:34 |
| lool | ok, lets do it then | 21:35 |
| 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:37 |
| stgraber | yeah... I'll upload another no change rebuild then | 21:38 |
| lool | thanks, sorry for your waster time and bandwidth | 21:39 |
| lool | *wasted | 21:39 |
| stgraber | uploaded | 21:40 |
| 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:47 |
| 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:48 |
| stgraber | the chromium builds on the amd64 buildds also appear to be done but still running according to LP... | 21:49 |
| infinity | Does buildd-manager need a restart perhaps? | 21:54 |
| infinity | elmo: Can you give buildd-manager a restart on alpaca? | 21:54 |
| 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:56 |
| 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:58 |
| 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 | 21:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:10 |
| 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:11 |
| * 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:12 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:18 |
| infinity | Or is shim special? | 22:19 |
| infinity | Oh, shim is special because it's signed by MS, not us. Derp. | 22:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| infinity | fo0bar: That would be buildd-manager on alphecca, if you don't speak fluent infinity. :P | 22:23 |
| 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:24 |
| fo0bar | infinity: buildd-manager was hard hung. killed, starting now | 22:28 |
| 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:29 |
| 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:30 |
| lool | fo0bar: thanks for restarting | 22:31 |
| 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:32 |
| lool | infinity: oh right, it hadn't even started building | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!