[00:51] slangasek: ^- avoid breakage from including signed kernel in image [00:53] slangasek: does the .efi.signed image work when booted using a legacy BIOS, by any chance? [00:54] OK, I'm going to have to defer booting images with signed kernels until tomorrow, just too tired [00:55] cjwatson: Wait, we're shipping a signed and unsigned kernel? [00:55] cjwatson: Wouldn't a signed one Just Work, even in the absence of anything that cares if it's signed? [00:55] Well we have to ship an unsigned one somewhere due to the mechanics [00:56] cjwatson: I meant in images, obviously the archive has one. [00:56] As for images it depends how specific the format is to EFI, I forget [00:56] Hence my question [00:56] Yeah, fair. [00:57] If anyone else wants to work on it, I think the steps are: for desktop, make livecd-rootfs move vmlinuz-*.efi.signed to kernel-$FLAVOUR if it exists - or possibly to kernel-$FLAVOUR.efi.signed depending on the answer to my question above, in which case debian-cd will need some work to handle that; for server, I have a suspicion that the easiest way is going to be to modify linux-signed to spit out a kernel-signed-image ... [00:57] ... udeb so that debian-installer can use it [00:57] again depending on the answer to my question above [00:58] hopefully BIOSes can boot vmlinuz-*.efi.signed and it's all simpler [00:58] Hopefully. [00:58] Otherwise, this is all disgusting. [00:58] Well, more disgusting than I thought it was. [00:58] Which was already a pretty vile. [00:59] cjwatson: In other news, that mlwhatever compiler is just awful. [01:00] The underlying .efi file is just a copy of vmlinuz, extension notwithstanding [01:00] cjwatson: It does some initial bootstrappy bits, and then just sits there with no output for (many) hours, doing... presumably... something to itself. [01:01] cjwatson: Right, I has hoped it was just a vmlinuz, and I'm also hoping that the signing process took care to make sure it didn't mangle it in any awful ways. [01:01] cjwatson: Thus leading to the theory that one can just ship a single signed image. [01:02] cjwatson: (Which would also mean that linux-signed should be the one spitting out the linux-image-$(abi)-generic package, while the linux source just spits out linux-generic-raw to sign from, but it's a bit too late in the cycle to rearchitect that. :P [01:02] The cert table goes at the end, so it's probably OK, but I was hoping somebody more awake had boot-tested it. [01:03] Maybe I can install it here and ask kvm. Yay multiarch. [01:04] "error: premature end of file /boot/vmlinuz-blah" [01:04] Lame. :/ [01:04] actually maybe that's just insufficient syncing [01:04] 'kvm -snapshot -hda /dev/sda' is handy but produces nonintuitive results sometimes [01:06] Right, that boots fine if I actually sync all the data to disk [01:06] \o/ [01:06] So, this may sound awful and vile. [01:06] But instead of moving things in build scripts, and other ickiness. [01:07] Why not just, along with having linux-signed-image depend on linux-image (whatever), we also have it replace that same version, and install the kernel to vmlinuz-$(abi)-flavour and be done with it? [01:07] I've already changed the installer to handle linux-signed-* specially in various ways, and GRUB to handle .efi.signed. Changing package and file names would involve undoing or at least rethinking all of that. [01:07] Replaces will keep it as the file installed, even if you reinstall the underlying kernel. [01:07] IOW tell me this two weeks ago. [01:08] Well, I just looked at it now. :P [01:08] * infinity gets a time machine. [01:08] cjwatson: .efi.signed image> sorry, are you asking whether grub can boot the vmlinuz.efi.signed under BIOS? [01:08] Happy to make it more rational for R. For now I just need to make it work. [01:08] slangasek: I was until I tested it and found that it can. [01:08] ok [01:09] Actually what I care about is syslinux not grub, but I think the odds are good [01:09] So that I can just have one /casper/vmlinuz and have it work on both [01:09] cjwatson: Does Q have a plan for keeping signed images up to date, too? [01:09] infinity: kernel team will just reupload linux-signed as part of each sru stack [01:09] cjwatson: Yes, but... [01:09] cjwatson: I see no meta for it. [01:10] Look harder. [01:10] Or, again, wasn't paying attention. *looks* [01:10] linux-signed-{,image-}generic [01:10] Ahh, there it is. [01:10] Check. [01:10] base-installer will install that as appropriate. [01:10] I missed that bit. [01:10] Assuming I got all the code right. [01:11] So, still feels better to not have two kernels installed, but otherwise, meh. This works. [01:12] right, but that's not a last-minute-before-release kind of change [01:12] Nope. [01:12] See above, re: time machines. [01:13] So actually this means my ubuntu-defaults-image approach is a bit suboptimal. I'll upload a new version tweaking that. [01:15] This is basically all the set of weird build script nonsense that I expected to have to change anyway :-) [01:20] ogra_: You didn't push your most recent livecd-rootfs changes to bzr. Fixing up by hand, but please bind your bzr branch so that this doesn't happen again. [01:26] OK. If somebody could review ubuntu-defaults-builder 0.43 and livecd-rootfs 2.90, that would be very helpful, and then at least the desktop images should be using a signed kernel in the morning. [01:26] I'll figure out how to do the same for server tomorrow. [01:28] I'll review them [01:29] Thanks. [01:29] * cjwatson -> zonk [01:31] good night [01:44] jbicha: Does Bug #713423 need any changes for ubuntu-docs to be complete? If not, please remove the docs task. [01:44] Launchpad bug 713423 in ayatana-design "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [High,Fix committed] https://launchpad.net/bugs/713423 [01:50] doko_: Oh, duh. armhf takes so much longer than armel because the testsuite runs twice, I'm betting. [01:50] doko_: unix + unix/-mthumb [01:51] doko_: Err, wait. That's all backward. armel takes longer. And both run -mthumb. [01:51] doko_: Nevermind me. [01:51] doko_: (Why DOES armel take so much longer? Is v7 optimisation really that awesome?) [01:55] jbicha: Same for Bug #876017. [01:55] Launchpad bug 876017 in ayatana-design "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017 [02:12] I'd like to try to retarget 876017 to R but LP won't let me [02:15] Let me try. [02:17] Weird. No "R" there for me either. [02:19] There's a bug whereby a series disappears if... Some condition. [02:19] Maybe when it's been targetted then rejected? [02:19] Don't recall. [02:19] Thanks. [02:20] I unsubscribed the release team, so my caring factor has declined. [02:20] Shouldn't matter anyway, since the default of "untargetted" is correct as soon as R is the current devel release. :P [02:21] looking at the bug history, that's because it was targeted at r-series then someone removed the bug tasks [02:21] stgraber: Yeah, that's the bug. [02:21] But, again, who cares? [02:21] R = devel soon, = "Ubuntu" tasks are R. [02:21] So, meh. [02:24] Right, then. Mozillafest is done on x86, I'm going to give i386 another buildd and open the langpack floodgates. [02:47] https://bugs.launchpad.net/~ubuntu-release from 95 bugs/tasks to 19. [02:53] thanks! [03:58] yep, targeted then deleted task makes series disappear [03:59] Yay, gcc-snapshot on armhf finished. [03:59] In just about the right amount of time to make that thunderbird ain picks up finish around the same time as the last firefoxen. [03:59] Serendipitous. [04:01] all your arm* buildds are belong to us :) [04:02] *working arm* buildds :) [04:35] https://launchpad.net/builders/primero is looking a bit schizophrenic at the moment. [04:38] hrm, amsn is back, I guess that's fine for non-LTS... [04:39] It's allegedly maintained again. [04:41] right...let's see what happens with that :) [04:42] people seem to like it for some reason, and at this point, it's not any worse that some of the other software in universe [04:42] Spoken like a dedicated MOTU. [04:43] jbicha TIL, so whatever, his problem. [04:43] infinity: ^^^ that's a dedicated MOTU. [06:04] dpm asked me to upload the two packages which are affected by https://bugs.launchpad.net/launchpad/+bug/1048556 [06:04] Ubuntu bug 1048556 in ubuntu-translations "Language pack translations export needs to add universe packages to domain map" [Undecided,New] [06:05] they will drop the X-Ubuntu-Langpack header, so that they will use the upstream translations again and include them in the .debs [06:05] instead of stripping them and relying on the langpacks to carry them [06:05] (both are universe packages) [06:05] gnome-panel and banshee [06:06] I upload them to -proposed for being cautious, but they are intended for the final release [06:06] as the final langpacks are uploaded now === chrisccoulson_ is now known as chrisccoulson [06:16] pitti: Want to let that neko in? Just a rebuild (and moving a debian-changes patch), fixes an FTBFS on armhf for its r-build-deps. [06:16] infinity: I'm not officially in ~ubuntu-release any more, but if you want to pretend for a moment that I was, I'm happy to review it :) [06:17] I'm all for pretending. [06:17] * pitti puts on his -release veteran hat [06:17] * infinity curses the queue diffs, and diffs gnome-panel manually. [06:18] infinity: LGTM, accepted; thanks for cleaning up that as-needed patch [06:20] And the mozillathon is finally coming to a close. [06:20] infinity: well, the mozilla buildathon :) [06:22] micahg: Were the FTBFSes on sparc expected? [06:22] infinity: yes, unfortunately [06:23] Compile-time page size does not divide the runtime one. [06:23] ^-- Is that a fancy way of saying LOLALIGNMENT? [06:23] I'm pretty sure Debian has the fix, just no one has had time to dig it out [06:24] and since you can't install sparc from lucid media, we haven't cared too much [06:24] Not even from d-i images? [06:24] AFAIK, no [06:24] Special. [06:24] or did you fix that? [06:25] Was I going to? [06:25] What was broken? [06:25] ISTR having this conversation with you before [06:25] I made d-i stop FTBFSing on sparc, but that doesn't mean it works. [06:26] I didn't know it didn't work, just that it didn't build. [06:26] Oh, and that was on hardy. [06:26] Which is what we're talking about. [06:26] right [06:26] Even if you said lucid. :P [06:26] Oh, wait. [06:26] No. [06:26] You meant lucid. [06:26] * infinity wonders what's wrong with lucid. [06:27] Oh well, I have no hardware to test on anyway, so without blindingly obvious bug reports, I wouldn't be able to do much. [06:27] yeah, powerpc was the only arch we got complaints about [06:28] and BenC was kind enough to fix that [06:28] Not so much kindness as being paid, I think. [06:29] whatever gets the job done ;) [06:32] PPC in quantal is in better shape than precise [06:32] cjwatson: So, it was neko that was doing the wrong thing. With neko rebuilt, neither haxe nor mercurial-buildpackage FTBFS (no need to rebuild either of those, mind you) [06:32] micahg: Yeah, shame he didn't start on his crusade about 3 months earlier. [06:32] heh, right [06:32] micahg: Though he got precise in pretty decent shape. [06:32] yeah, it's not bad [06:32] micahg: Certainly good enough for most server workloads, which is actually what his employer cared about. [06:33] micahg: I think fixing the rest of the world was just a point of pride, and cause whoever pays him didn't really understand that they didn't care. ;) [06:37] 241 root 20 0 0 0 0 D 15 0.0 131:52.45 usb-storage [06:37] 14520 adconrad 20 0 668m 352m 100 D 4 39.0 20:09.78 mlton-compile [06:37] 14395 adconrad 20 0 678m 288m 80 D 3 31.8 20:02.58 mlton-compile [06:37] ^-- Dear Santa, I'd like an ARM box with RAM, so I can stop spending more time swapping than compiling, kthx. [08:06] ^--- Best version number EVAR. [08:09] what in the [08:09] infinity: it could only be better if it regressed and we had to drop back with, 7.2~alpha5+cvs20101124-1+deb7u0ubuntu2~really7.2~alpha5+cvs20101124-1ubuntu1 [08:10] Daviey: Except that's the same upstream, so it would just be ubuntu2. :P [08:10] is that a convention for tpu? [08:10] (Don't forget the ~precise1 backport suffix) [08:10] Laney: Apparently. === henrix_ is now known as henrix [08:10] infinity: bah! :) [08:11] pitti: ~ubuntu12.04.1 you mean :-) [08:14] 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.246.0ubuntu1 [08:14] still wins [08:16] * xnox I am tempted to make some software and actually call it 10.0.58.4.5, first upstream version will also match the name of the software. [08:16] Aaaanyhow, if someone would like to review that instead of making fun of the version number... ;) [08:17] I think that's the only legitimate FTBFS left in main. [08:18] And I'm sick of staring at mlton bootstrapping, so I might go to bed. [08:18] cjwatson: mlton bootstrappyness will happen in-archive tomorrow, by the looks of this local build. [08:21] Cool. [08:22] Impressed at somebody fixing libatomic-ops. I tried and failed. [08:22] (Like, last release.) [08:22] * cjwatson goes cross-eyed at x86 asm [08:22] Only one coffee ... [08:26] small internationalization fix to generate some javascript strings in pot which can be translated :p ^ === henrix is now known as henrix_ === henrix_ is now known as henrix [08:56] linux-signed upload adding di integration as a step towards netboot support [08:56] (and server) [09:03] * cjwatson reviews [09:04] LGTM === mmrazik is now known as mmrazik|lunch [09:25] cjwatson, i notice source.list contains uncommented deb cdrom:[Ubuntu 12.10 _Quantal Quetzal_ - Beta i386 (20121010)]/ quantal main restricted after an i386 reinstall [09:25] cjwatson, is that intended? [09:28] hmpf, whats wrong with the arm builds [09:28] psivaa: Sounds reasonable to me [09:29] cjwatson: is that for installing network drivers etc. post-installataion? [09:29] cjwatson, ok, on amd64 i see that line commented though [09:30] pitti: for example; also if you have the stuff locally then why not [09:30] apt used to be irritating and ask for the CD, but it doesn't any more [09:30] psivaa: honestly - it might be a micro-bug somewhere, but I'm doubtful that it's worth spending any time on [09:31] cjwatson, ack, software center asks for the CD when this line is uncommented [09:32] ! [09:32] That bug was fixed in apt in, what, 2005? [09:32] ogra_: You mean ARM image builds? [09:33] psivaa: Sigh, file a bug on whichever installer you're using with logs, then [09:33] infinity, yeah [09:33] ogra_: Could be suffering from skew since all the Pandas were busy with firefox/thunderbird all day. [09:33] infinity, livefs builds particulary [09:33] ogra_: And I mean *all* the Pandas. [09:33] ogra_: The queues will catch up in a bit. [09:33] oh, did we now switch to LP buildds ? [09:34] ogra_: Hrm? No, I meant that we could have had package skews due to ARM not building anything useful for 12h. [09:34] (i.e. is it pointless to look at celbalrai ?) [09:34] psivaa: how did you get s-c to ask you for a CDROM? [09:34] I can't get that here [09:34] oh, well, i dont even see build attempts for the last two days [09:34] infinity: thanks for accepting udev; for quantal, did you intend to land this in quantal proper, or SRU? (I'm fine with final, it's quite straightforward and tested by two people) [09:34] Oh, that's disconcerting. [09:34] right [09:34] pitti: I was going to let it in. [09:35] I got some empty error mails about ARM builds [09:35] (livefs) [09:35] infinity: cheers [09:35] ac100 has a build attempt yesterday with some weird chroot cleanup message [09:35] banshee and gnome-panel look good, they now have translations [09:35] and omap/omap4 hanst even been attempted it seems [09:35] *hasnt [09:35] Laney, when you try to install something using software center it asks for the cd, [09:35] * ogra_ suspects a buildd issue [09:35] no, I don't see that [09:35] ogra_: Could be that someone needs to hard rm -rf chroot/build/* [09:35] ogra_: Where's that log? [09:35] yep [09:35] well even if the line is uncommented? [09:35] yes [09:36] ah, perhaps I need apt-cdrom [09:36] no [09:36] ogra_: Oh, found it. [09:36] Laney: merely adding the line won't help; did you actually add it in apt? [09:36] ho hum. [09:36] http://paste.ubuntu.com/1272866/ [09:36] ogra_: Weird. It has no errors. Just doesn't configure. [09:36] psivaa: desktop image, presumably? [09:36] cjwatson, yes [09:37] pitti: I just uncommented it in sources.list [09:37] psivaa: from DVD or USB? [09:37] do I have to do more? [09:37] apt-cdrom add, I think [09:37] cjwatson, usb [09:37] And when you tested amd64, was that also from USB? [09:37] ogra_: 20121009 was okay, though. [09:37] cjwatson, yes [09:37] yep [09:37] ogra_: So, this is very recent. [09:38] Curious. I suppose the difference might relate to multiarch, since we've never really tidied up multiarch on the CD. [09:38] but there was no livecd-rootfs or live-build uploads or anything in that timeframe === doko_ is now known as doko [09:38] i uploaded a change on the 3rd ... we had working builds since and colin uploaded the efi change today [09:39] psivaa: FWIW my snap assessment is that commenting that out has a high risk of regressions both in the installer and in post-install tasks such as installing restricted network drivers [09:39] So I'd much rather see software-center fixed to not ask [09:39] But I'll have a look to see if it's something subtler [09:39] (Which is quite possible) [09:40] ogra_: Try a by-hand lubuntu-ac100 build? [09:40] Or... [09:40] Wait. [09:41] nothing suspicious in debian-cd either [09:41] debian-cd wouldn't relate anyway. [09:42] well, neither in cdimage :) [09:42] yeah, let me try a manual buildlive [09:43] I was just about to do a manual core. [09:43] cjwatson i actually did a reinstall from amd64 ->i386, then i see the line uncommented -> when i use s-c it asks for a cd and after i comment the line the s-c does not ask for the cd [09:43] what sort of reinstall? [09:43] infinity, are you running already ? [09:43] ogra_: I will be, yeah. Hands off for a sec. [09:44] lubuntu-armhf-ac100 on celbalrai.buildd starting at 2012-10-11 09:43:28 [09:44] lockfile: Try praying, giving up on "/home/buildd/buildLiveCD.lock" [09:44] lubuntu-armhf-ac100 on celbalrai.buildd finished at 2012-10-11 09:43:30 (failed) [09:44] Null message body; hope that's ok [09:44] Error: no livefs builds succeede [09:44] Ahh. [09:44] cjwatson, usb-> and the new Re-install option [09:44] Not that new, but OK [09:44] ogra_: Working with webops to fixify it. [09:44] And the amd64 install was a fresh unmodified install of quantal? [09:45] It'd be great if I could have exact directions rather than asking lots of questions :) [09:45] infinity, great, thx [09:46] cjwatson: well it wasn't shown for dev-releases until I fixed it recently ;-) hence "new in quantal recently". I wonder if we should not allow cross-grading... or do some sanity to sources.list. [09:47] cjwatson, ill reproduce that and file a bug, with steps to reproduce [09:48] ogra_: So, celbalrai went read-only. That would explain the weird logs. :P [09:48] haha [09:48] yeah [09:49] * ogra_ wants arm boards with 6G RAM and tmpfses for live builds ! [09:49] How about 4G of RAM and a filesystem that's not tethered to the machine with a USB cable? [09:51] ogra_: Right, it's being escalated with some urgency. For now, you has no livefses. I hope you had other things to work on... [09:52] well, i was about to roll a ubuntu rootfs tarball :) [09:52] but yeah, i can do enough other stuff [09:53] Oh, you can't be serious... libatomic-ops now segfaults on armel? [09:53] FML. [09:54] * infinity gives it back and prays that was cosmic rays screwing with him. [09:54] infinity: welcome to this timezone ;-) [09:54] heh [09:54] You say that as if infinity has a home timezone. [09:54] xnox: I've been up for 22h, I'm not actually sure what TZ I'm in. [09:55] infinity: clearly the odd one ;-) [09:55] infinity works 24x7 during freezes, and release times. Outside of those times, he sleeps. [09:56] The latter bit may not be true. [10:03] *sigh*... And now it's gone into an infinite loop. [10:03] Ooh, I can haz netbeans fix? [10:03] * cjwatson reviews [10:04] Why do I have a sinking feeling this isn't going to end well? [10:05] lol [10:06] Ifinitely-looping testsuites make me sad. [10:22] Would anyone object to syncing in sugar-base-0.88 and sugar-toolkit-0.88 so that sugar-moon-activity can build? [10:23] (I might test-build them first) [10:25] Oh, feh. I see the problem with atomic-ops on armel. I think. I'll need to look at this in the morning. [10:25] If this was on a v5 buildd, it would just happily SIGILL instead of doing Weird Things. [10:26] -march FTW? [10:27] cjwatson: You mean just force it to v7 and be done with it for now? :P [10:28] I meant v5, but perhaps I misunderstand [10:28] cjwatson: I was going to just backport the newer sysdeps/gcc/arm.h, since it actually properly deals with Thumb1/Thumb2. [10:28] Ah [10:28] cjwatson: The problem is the inline ASM in the old version of libatomic-ops we carry assumes thumb == thumb2, and does Very Bad Things. [10:29] Well, that's *a* problem. I can't tell if that's what just exploded aleya until I fix it. [10:29] But yeah. I need a nap. [10:29] Will fix in the "morning", whenever that happens. [10:35] OK, sugar-{base,toolkit}-0.88 build cleanly here, and should be enough to resolve that dep-wait, even if they don't represent a complete Sugar environment. [10:35] So synced. [10:40] Oh, that's where linux-signed got to [10:40] * cjwatson curses -proposed, made me waste an hour [10:52] cjwatson: Say, how did libatomic-ops miss your napalm rebuild-for-armv5 run anyway? [10:53] cjwatson: Then this would have been your problem. ;) [10:53] cjwatson: (Turns out I was wrong about the thumb thing, it is guarded elsewhere, so it never executes.. But this infinite looping testsuite has been seen on several arches in recent rebuilds on Debian too) [10:55] Kinda tempted to just disable the test suite on armel and say screw it for now. [10:56] infinity: Not quite sure. [10:57] Possibly worth debugging if I had any time :-) [11:03] I'm pretty sure I never should have collapsed the waveform on this one. [11:04] * infinity naps for real this time, and hopes he doesn't dream of atomics. [11:18] * cjwatson battles with ruby-fusefs === mmrazik|lunch is now known as mmrazik [11:58] Apparently I mashed the wrong buttton on sugar and it can't be fixed: [11:58] FAILED: sugar-toolkit-0.88 (Can't resurrect rejected syncs) [11:58] FAILED: sugar-base-0.88 (Can't resurrect rejected syncs) [11:58] yeah, re-sync them [11:58] Yeah, you can't ... that. I can resync. [11:58] Thanks. [12:00] * ScottK tries again. [12:14] Hmm, sugar-* still rejected [12:15] Damn, it was deleted from quantal [12:15] I wonder if I can re-copy it from precise [12:15] Or even from quantal come to that [12:20] * cjwatson tries [12:22] Ha! Master. Hopefully that won't break the publisher. [12:48] * infinity gives up on the mystery of libatomic-ops. No, really. Honest. [12:49] You can review d-i instead :) [12:49] Seeing as you're clearly failing to sleep [12:50] I'm also failing to reproduce the failures the buildds are seeing. [12:50] And it's making me a sad panda. [12:50] barry: so, um, why is this python-mode sync appropriate during final freeze? [12:51] While I understand the desire to get all one's own Debian packages in sync :) [12:51] cjwatson: dang, you noticed. :) [12:55] barry: I'm wary of anything but crash/build/other-serious-bug-fixes and maybe some already-known feature freeze exceptions at this point, TBH [12:56] cjwatson: Why not just ifdef; if -e; mv boot/$nameALT boot/$name; fi; endif, instead of duplicating the other mv with an else? [12:57] infinity: I suppose if I did that *after* the other mv [12:57] Oh, or I could read what you wrote [12:57] cjwatson: that's cool. this does fix real problems people have with functionality, it's universe, but i have no problems sru'ing it after release if you prefer. [12:57] Yeah, that would work [12:57] cjwatson: It just seems a bit more readable to me that way. And shorter. [12:58] barry: Yeah, I'd rather that at this point, honestly. More time to spot any new breakage. [12:59] cjwatson: np [12:59] cjwatson: So, basically, just ditching the rm/else/mv, and then ending the ifdef, rather than elsing it. [12:59] (elsing is totally a verb, right?) [12:59] infinity: http://paste.ubuntu.com/1273151/ ? [13:00] Why does diff insist on silly ordering I can't read. [13:00] Yeah, that looks like what I'm driving at. [13:01] mkay, will upload ubuntu183 [13:01] Ends up doing the same thing, but the smaller the unusual ifdef code blocks, the better, IMO. [13:01] Easier to track WTF they're up to. [13:01] I'll just reject 182, and you can re-tag it. [13:01] I prefer a new version anyway [13:02] Alright. :) [13:02] * infinity probably abuses bzr tag --force a bit too often. [13:04] Yay, resurrecting with copy-package totally works, admittedly with a couple of slight hacks only one of which I committed. [13:05] My local copy-package is hacked to bits for that sort of thing. [13:05] But not in any remotely committable way. [13:05] Maybe I should write a dedicated undelete-package. Except the opposite is called remove-package, and unremove-package doesn't sound right. It sucks to be a pedant sometimes. [13:05] Just, like, a ton of stuff commented out. :P [13:05] I fixed lputils in a way that deals with most of what you usually complain about [13:05] But you also have to comment out the target-same-as-source guard [13:06] The opposite of remove would be insert, surely. [13:06] insert-package [13:06] Not really in this sense ... [13:06] Cause that doesn't sound dirty at all. [13:06] restore, but it looks too similar. [13:06] Or resurrect. [13:06] I think just giving copy an option to do it seems sane. [13:06] Since it really *is* a copy. [13:07] Just a weird one. [13:07] It is, it's just that only people who know Soyuz will think of it that way. [13:09] Laney: So I was looking at removing pandoc/armel, since I suspect that mysterious build failure isn't likely to go away [13:09] I like resurrect. [13:09] revive? [13:09] revive isn't bad [13:10] Though even more similar to remove [13:10] Laney: Looks like the rdepends stack that would need to be removed on armel would be: bup carettah imageshack-uploader purity-ng libnss-rainbow2 tempest-for-eliza [13:10] What do you think? [13:10] cjwatson: remove-package --not? :P [13:11] --just-kidding [13:11] remove-package --undo [13:11] Alright, going to try harder to nap. Maybe I'll dream of some way to reproduce this stupid test failure before I give up and disable the testsuite and make Daviey's day by being a hypocrite. [13:13] cjwatson: undo-removal would work. It doesn't HAVE to have 'package' in the name. [13:19] cjwatson: feel free [13:19] Someone who cares more could look into removing the pandoc BDs on those packages (at least some of them are likely to be for documentation only) [13:20] cjwatson: Oh, by the way, if that paste was a pastebinit pipe, "pastebinit -f diff" makes it pretty (aliased to pastediff here, cause that's 99% of my pastes). [13:21] My bin/ubuntu-paste is old-skool. One of these days I might switch to pastebinit. [13:22] Laney: OK, removed [13:23] hi, vlc 2.0.4 will be released on sunday. it contains a bunch of bug-fixes and adds support for opus (= only new feature). now likely is it to get a FFe? [13:23] skaet, cjwatson: is now an ok time to pocket copy firefox and tbird? [13:23] bdrung: I suspect an SRU at this point would be more likely [13:23]