=== Guest20955 is now known as Termana === yofel_ is now known as yofel === lool- is now known as lool [08:15] xnox: the relevant cron entry is disabled "for saucy opening" [08:17] which also covers some other things, notably britney, so i'm loathe to uncomment it myself [09:02] Laney: fair enough. [09:05] soz! [09:05] how was the release party? [09:05] Nobody died. [09:06] I suppose that makes it a success. [09:06] * infinity adds saucy schroots to all his porting boxes. [09:06] That's what I look for in a party [09:08] do you know if saucy is meant to appear in testdrive yet? === gema_ is now known as gema [09:12] doko: Did you re-override gcj-4.8 after I did? :/ [09:15] Silly double-override bug. [09:18] wgrant: I'll give you big money and fabulous prizes if you can unwind the double-override bug and make it go away. [09:19] wgrant: It may be the single most confusing thing Soyuz can do to an archive admin who isn't painfully vigilant. [09:27] mk-sbuild saucy is failing for me and doesn't install apt. *sigh* [09:28] debootstrap sad or? [09:28] well I added the usual symlink.... [09:29] * Laney just finished mirroring so is about to try [09:30] I now copied raring chroot / schroot config and just gonna dist-upgrade it by hand. That seems to work. [09:30] infinity: If it was reasonably easy I would have done it 3 years ago :) [09:31] xnox: "Failure while installing base packages."? [09:31] wgrant: .... but were you offered fabulous prizes 3 years ago?! =) [09:31] A good point! [09:31] wgrant: What he said! [09:32] Laney: well i was getting failure in finish.d [09:32] well, that's after this [09:32] xnox: I don't see how debootstrap would fail, given that the release pocket is an identical copy of raring. [09:32] infinity: In related news, can you promote something from proposed so I can check that the saucy dominator isn't still too much for postgres? [09:32] wgrant: how about item #1: Blackpool Rock Candy ?! [09:33] wgrant: Sure, I'll do distro-info-data, that should be vaguely harmless. [09:33] infinity: Thanks [09:33] I eventually realised that britney must be turned off, so I hadn't actually broken anything. [09:33] But I'd like to see saucy-release dominated before I fly away. [09:35] wgrant: Should hit the next publisher run. [09:37] xnox, infinity: Curiously, debootstrap doesn't seem to download apt-get. [09:37] infinity: Thanks. [09:38] debootstrap --variant=buildd is failing for me [09:38] but the log file it points me to doesn't exist [09:38] grr [09:38] * infinity tests. [09:40] Hrm, yes, the lack of apt there is worrisome. [09:40] Hm [09:40] My mirror isn't that out of date, and it works fine [09:40] I'll unwind this in a second. [09:40] http://paste.ubuntu.com/5604007/ [09:45] Are we missing lots of overrides? [09:46] Yeah [09:46] http://paste.ubuntu.com/5604012/ [09:46] Seems likely, from that output. [09:46] No Build-Essential in Packages === mmrazik is now known as mmrazik|afk [09:46] That could self-solve after this next run. [09:46] Due to the germinate->apt-ftparchive ordering oddities, and the fact that the release pocket hasn't been regenerated in a while. [09:47] Yeah [09:47] The last two release publications failed [09:47] But germinate's working fine [09:47] The one in 15 minutes will hopefully wor [09:47] k [09:48] Fingers crossed. [09:48] What was breaking it? [09:48] .... well publishing was stuck last night and there were ooops that vorlon was trying to unwind on #launchpad-ops [09:48] see scrollback there. [09:48] infinity: BPPH is sufficiently large that postgres hadn't yet automatically reanalysed it, so saucy domination queries were taking hours and getting killed [09:49] That *should* be fixed now [09:49] wgrant: Oh, that's vomitously fun. [09:49] Yes [09:49] So I think saucy may still be running on its initial indices [09:50] It's likely that no subsequent release publication succeeded. [09:50] infinity, according to my backlog, nobody did override these before I did: http://paste.ubuntu.com/5604017/ [09:51] doko: I overrode them in the queue, and then you did it again in the same run, which makes Soyuz drop arch:all packages on the floor, cause it's SMART. [09:51] doko: I thought Colin has mentioned that to you in a query. [09:51] laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/raring/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes [09:51] 44 [09:51] doko: No big deal, copying over itself (which I just did) should rescue it. [09:51] laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/saucy/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes [09:51] 0 [09:52] Yeah [09:52] Laney: Yeah, see above. That should self-solve when the release pocket reindexes in this upcoming run. [09:52] infinity: You've checked that the override files look sane now, right? [09:52] Given you have pepo access [09:52] Rockin. [09:52] wgrant: Nah, I'm operating on faith (and multitasking a bit here) [09:52] :) [09:53] wgrant: germinate/apt-ftparchive order is a known misfeature, and a plausible explanation for this. [09:53] Colin and I were discussing how NMAF and germinate-from-db combined could wipe that one out. [09:54] infinity, but you didn't touch mpclib3, isl, and cloog, correct? [09:55] doko: I did mpclib3, but it doesn't have arch:all packages, so the double-override didn't break it. [09:55] doko: I didn't do the others. [09:55] ok [09:55] * infinity retries ecj on powerpc... [09:57] infinity: Yeah, but I was hoping to find out ASAP if it wasn't the actual explanation, 'cause I'm well past EOD already. [09:57] But we'll see shortly. [09:58] adconrad@pepo:/srv/launchpad.net/ubuntu-archive/ubuntu-misc$ grep Build-Essential more-extra.override.saucy.main | wc -l [09:58] 172 [09:58] That's more plausible. [09:58] That seems like a number bigger than 0. [09:58] Thanks. [10:00] * infinity blinks at ecj's continued failure on the buildds, despite it now working in his chroot. [10:00] Grr. [10:01] Oh. [10:01] Get:9 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libisl10 powerpc 0.11.1-2 [445 kB] [10:01] Get:10 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libcloog-isl4 powerpc 0.18.0-2 [65.3 kB] [10:01] That seems a bit suspect. [10:01] doko: Did you just fix the above while we were talking, or can I safely do it now? [10:01] $ ./change-override -c main -s saucy -S isl [10:01] Override component to main [10:01] isl 0.11.1-2 in saucy: universe/libs -> main [10:02] Override [y|N]? y [10:02] 13 publications overridden. [10:02] doko: That was in the last 30m? :) [10:02] infinity, no, do it now [10:04] infinity: Can you kick boost-defaults out of accepted? It's already published, so that dupe is oopsing [10:05] 2013-04-26 10:04:26 DEBUG Domination for saucy/Release finished [10:05] So the publisher should be happy now [10:05] wgrant: Punted. [10:06] Thanks. [10:08] Every time I watch the primary archive publisher, I want to finish NMAF... [10:09] If you're positive you can get a faster/saner implementation, I want to sort out how to make time for you this cycle to get it done. [10:10] My attempt in 2009 was dominated by bzip2 compression time... [10:12] I heard we're going to move all of launchpad to hyperscale ARM servers to encourage better service parallelisation and code profiling habits. [10:12] Heh [10:12] 2013-04-26 10:07:12 DEBUG Calculating binary filelist. [10:12] infinity: So yeah, it's practical, and I might even get bored on the plane. [10:12] That... Shouldn't take 5 minutes. [10:13] We'd need to add extra override support, bu that's basically trivial [10:13] infinity: It can if the cache is cold. [10:13] It just finished [10:13] Well, 40s ago [10:13] Yeah, I know. Just as I pasted that. [10:13] My timing is impeccable. [10:13] Most of LP only works if the cache is hot [10:13] Because the schema design is not hot. [10:13] *smirk* [10:13] Thankyou 2005. [10:14] Thank you, "we can always solve it with more RAM" mentality. [10:14] Turns out that there's a limit to that. [10:21] Well [10:21] There actually isn't [10:21] That'd be the easiest solution to our problems today :) [10:22] The limit is when you can't get enough RAM to stuff your DB in it. :P [10:22] But our DB's still just under 400GB :) [10:22] I think [10:22] ez [10:22] *shudders* [10:23] clearly we need a distributed shared memory scientific riggs to run launchpad. [10:25] New Packages files have Build-Essential! [10:25] Not quite done yet, though === mmrazik|afk is now known as mmrazik [10:36] wgrant: Oh, other curiosity, the publisher is still hanging on to custom uploads for armel in saucy. :/ [10:36] adconrad@pepo:~$ ls /srv/launchpad.net/ubuntu-archive/ubuntu/dists/saucy/main/installer-armel/ [10:36] 20101020ubuntu187 current [10:37] wgrant: No other armel cruft, just custom uploads (so, in effect, just d-i). [10:37] wgrant: Easy enough to RM at the filesystem level, but I suspect this means it'll come back AGAIN for t-series? [10:37] infinity: The latest d-i image is deliberately copied, I'm pretty sure [10:37] Except that's not the latest, is it.. [10:37] wgrant: It's the last that was published for armel, but not the "latest", no. [10:37] .... we don't have armel any more [10:37] Oh, armel, right [10:37] xnox: Yes, we know. :P [10:38] Hmm [10:38] Difficult [10:38] PUs aren't actually bound to the DAS [10:38] So we'd have to exclude based on filename [10:38] Can you file a bug? [10:38] I can. [10:38] But will I? [10:38] This code is completely hideous and I tried to veto it, but it didn't work :( [10:39] You'd think this would have come up in the past for other dropped arches. [10:39] It was written since then [10:39] Unless this code happened after we dropped sparc. [10:39] Check. [10:39] Custom uploads have only been copied since DDs [10:39] And sparc/ia64 were dropped in maverick [10:40] Can someone reasonably close to a.u.c try to debootstrap now? [10:41] wgrant: I will. [10:41] wgrant: Also, https://bugs.launchpad.net/launchpad/+bug/1173128 [10:41] Launchpad bug 1173128 in Launchpad itself "Custom uploads get carried over to the next series, even for dead architectures" [Undecided,New] [10:42] infinity: Done [10:43] This debootstrap package list looks more plausibly correct. We'll see if it completes. [10:43] Should have done it in RAM, I'd be done by now. [10:44] Yeah, that's much happier [10:45] Works fine [10:45] \o/ [10:45] Happy EODing. [10:45] And see you on Sunday... [10:46] Indeed. Good stuff. [10:46] Hopefully there'll be no more breakage... [10:46] Jesus, dude. Don't SAY that. [10:47] You just lit the DC on fire with your mind. [10:47] infinity: wgrant didn't, but you did =) [10:47] LP needs to be threatened every now and then. [10:47] *FOOMP* [10:48] Hrm, the sun came back for yet another lovely day in London. [10:48] I don't know what the locals complain about, it's alwayd gorgeous when I'm here. [10:48] I thought London had banned the sun [10:48] Yeah, that [10:51] infinity, gcj-4.8-jre-lib is still in universe, promoting it ... [10:52] doko: Erm... [10:52] infinity, doko: With these missing binaries due to double overrides, that should only happen if two people are overriding them the same way at the very same time, or if you override them one way then override them back in the same publishing cycle [10:52] Not just if two people override them the same way 5 minutes apart. [10:53] wgrant: It's hard to track down exactly who did what when something like this happens, mind you. [10:54] doko: Oh, it went back to universe when I did the copy-over-itself trick. Lame. Your override looks like it'll be happy in the next run, at least. [10:54] ok, good to know [10:54] https://launchpad.net/ubuntu/saucy/powerpc/gcj-4.8-jre-lib <-- Ugly publishing history and a half. [10:54] infinity: Not really. You can see if the two overrides happened within a few seconds of each other [10:57] infinity: Those two were created 21 seconds apart, which suggests that the exported API method might not actually be checking if the overrides match before changing them [10:57] Except that it does. [11:02] doko: infinity: can you please accept rocs and ogre ? that would be the zero boost transition iteration. [11:04] done [11:28] * infinity fixes partner harder. [11:34] doko: I've re-enabled most of the archive jobs on lillypilly now [11:35] infinity: Any reason I shouldn't re-enable proposed-migration at this point? I intentionally stopped it during opening by creating ~/proposed-migration/STOP [11:35] (which is why the bzr branches weren't automatically updated when slangasek looked - the cron job updates itself) [11:41] wgrant: infinity's override did take quite a while, I recall [11:41] wgrant: Could easily have been >21 seconds, so possibly there was overlap [11:43] * cjwatson starts proposed-migration. Let's see what happens [11:44] cjwatson: I'm all for it, let's see what explodes. :P [11:44] cjwatson: (And good morning) [11:44] I just wanted to be around for its first run, really [11:44] Morning. I'll be off again soon :) [11:44] Hmm. That did nothing [11:44] Oh, blocks [11:45] Heh, yeah. [11:45] But suspicious excuses [11:45] Yay, partner got fixed in the last publisher run. [11:45] Ah, I forgot about symlinks [11:45] Let's move that to code so it's less opaque ... [11:45] cjwatson: That excuses looks like it's still doing raring... [11:46] Or am I looking at a stale copy? [11:46] It is, hence my "forgot about symlinks" comment [11:46] lrwxrwxrwx 1 ubuntu-archive ubuntu_archive 6 Oct 22 2012 testing -> raring [11:46] Check. [11:46] lrwxrwxrwx 1 ubuntu-archive ubuntu_archive 15 Oct 22 2012 unstable -> raring-proposed [11:47] So I'll leave the block in place for another run just for safety [11:48] That's suspicious anyway, I was fairly sure I removed some of those from raring-proposed. [11:48] Is lillypilly's mirror stale? [11:49] Shouldn't be but I'll look later [11:49] Well, if the archive reports cron is disabled, it might not be updating. [11:50] I enabled it [11:50] And it looked like it had got that far at least [11:50] Weird. That handbrake definitely isn't in raring-proposed, and hasn't been since yesterday. [11:51] infinity: Oh, no, it's just that britney updated its notion of saucy-proposed but then tried to run against raring-proposed. [11:51] In fact, none of those 4 packages are. [11:51] Ahhh. [11:51] So it's OK. [11:52] doko: ecj has an actual FTBFS on powerpc now. [11:52] infinity, yes, looking [11:52] doko: leviathan has a saucy chroot if you need it. [11:54] OK, excuses look more correct now [11:54] clearing blocks [11:56] final: base-files,boost-mpi-source1.53,boost1.53,casper,debootstrap,gcc-4.7,gcc-4.8,gcc-4.8-arm64-cross,gcc-4.8-armhf-cross,gcc-4.8-powerpc-cross,gcj-4.8,lightdm,mpclib3,plymouth,ubiquity,xdiagnose [11:57] lgtm =) [11:58] Indeed, looks vaguely sane. [11:58] And the copies went to the right place (at least base-files did) [11:59] Right, time for me to vanish again :) SMS me if that caused the publisher to explode or something [11:59] Assuming doko's happy with his toolchain, we're probably about ready to thaw, then. [11:59] And you can touch ~ubuntu-archive/proposed-migration/STOP if you need to emergency-halt it [11:59] infinity: In terms of the success of the release party, depends on who was there if that's a success or not. [11:59] I'll let the publisher run a few more cycles before I unfreeze. [12:00] doko: You happy to unfreeze whenever? [12:00] cjwatson: ^ [12:00] * xnox has 74 .changes files ready for next boost iteration once ogre-1.8 is published. [12:00] infinity: can't wait to unfreeze =) [12:00] infinity, yes, will build ecj with 4.7 for now, don't have the time to investigate today [12:01] Up to you lot, I'm about 17 hours out of date on most of this [12:01] merges.u.c seems to have updated roughly sanely [12:01] doko: Alright. We don't need to wait on ecj to unfreeze though, right? [12:01] sure [12:01] Kay, I'll give the publisher a cycle or two to settle down with proposed-migration, double-check that the world looks sane, and then unfreeze. [12:02] doko: Do you have your usual "Archive open, here's the toolchain changes" email drafted up? [12:02] infinity, yes, can do this now [12:03] doko: Delay it an hour or two, I guess. But yeah, soon. [12:03] but lets wait with this until the packages migrate from -proposed [12:03] doko: Yeahp, that was the plan. [12:04] cjwatson, infinity: Oh, of course, BPPH.changeOverride will only create a new pub if the new overrides don't match... but it doesn't check that the pub it's being called on is actually the latest. [12:04] So I suspect that only raced because the method was called on the old pub [12:04] It probably wants to scream if it's not the latest. [12:06] wgrant: It's not like we get to choose which one we call it against... [12:07] infinity: Your API script does [12:07] Oh, is it actually picking (incorrectly) from a list? I suspect that's fixable. [12:07] No [12:07] Well, yes, it picks, but it's correct *at the time* [12:08] Ahh. [12:08] But then it probably prompts "I'm going to change *these ones*! Pls confirm" [12:08] Then you wait a few seconds [12:08] Press y [12:08] And then it changes the overrides on them [12:08] In the meantime, a new pub has been created [12:08] So you're overriding old ones [12:09] Yay, races. [12:09] xnox: Don't forget to update bzr for your rocs upload. [12:44] ScottK: i haven't. I'm not generating these hundrets of packages from vcs.... especially if they are not lp:ubuntu/pkg [12:45] might update a couple, but I don't promise to update every single one though. [12:45] xnox: VCS headers are in debian/control for a reason. [12:46] Even if you don't pick up un-upload changes to go with your upload (which is fine, IMO) you need to update the VCS after. [12:46] ... including those that point to stale/out-of-date/wrong VCSs?! [12:48] ScottK: rocs VCS as pointed in debian/control is out of date. I'm not touching it. [12:48] missing last raring upload. [12:49] and we will not be able to fix this until we like reject uploads which have not been tagged & match the contents in the $VCS pointed by lp:ubuntu/* or what's in debian/control..... [12:51] doko: Fun fun on the version fail. You might need to do an artificial 4.8.0 -> 4.8.0.0 or something to fix that. :/ === mmrazik is now known as mmrazik|otp [13:10] xnox: Both bzr and raring have 4:4.10.2-0ubuntu1. I'm not sure what you mean. [13:12] ScottK: bzr tags -d lp:~kubuntu-packagers/kubuntu-packaging/rocs | grep 4.10.2 [13:13] xnox: OK. It's missing the tag, but the VCS data is up to date. [13:14] Fixed, BTW. [13:15] * xnox ponders if I can play "to late now, tags were out of date from the archive when a new upload was done" card [13:16] xnox: I think you need to look at the last changelog entry, not just tags. [13:16] It's easy enough to forget a tag. [13:20] infinity, time to drop spu, and demote newlib [13:24] doko: I suppose that's one way to fix the broken versions. :P === mmrazik|otp is now known as mmrazik [13:26] infinity, somebody else should be happy too ... (the one wanting to fix newlib during the last two cycles ;-P ) [13:27] Yeah. newlib sucks. [13:28] doko: Don't know how Debian PPC people feel about it (or if they care), but we haven't even pretended to support Cell/PS3 in ages. [13:28] and I did annonuce to drop it for jessie already [13:28] Ahh, good. Cool. [13:29] Then yeah, that's an elegant solution to many problems. :) [13:29] people should use the cross-build infrastructure to build it [13:29] hmm, where does do-release-upgrade pull the release notes from that it displays to the user? [13:29] plars: Is it getting it wrong? [13:29] it looks like on this system I'm upgrading, it still says "alpha" for raring [13:30] meta file from somewhere.... [13:30] infinity: "This is stiall a ALPHA release. Do not install it on production machines." [13:30] Possibly unrelated, but it looks like the wiki redirect got buggerd. :/ [13:31] plars: which text of three do you see? http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/ [13:31] I'm guessing Devel, that means meta is pointing to the wrong one. [13:31] xnox: devel, yes [13:33] ahh, hang on [13:33] probably because (by habit) I ran with -d [13:33] hmm... http://changelogs.ubuntu.com/meta-release seems correct [13:33] Yeah, -d would do silly things. [13:33] so even if it's released, I guess -d tells it to display the devel one [13:34] At least, until we point meta-release to spanky for devel. [13:34] heh [13:34] in other news. The release text in those files is wrong as it mentions "supported from 18 months to 5 years" [13:34] =)))) [13:35] * xnox ponders to do a grep for "18" across *.ubuntu.com [13:35] yes [13:35] xnox: that's just in the EOL one though [13:37] yeah, low priority. [13:38] xnox: you may want to get *slightly* more restrictive with the search than "18" :) [13:40] plars: true.... About 569,000 results (0.21 seconds) [13:44] doko: The diff for that spu-dropping gcc-defaults also bumped gccgo to 4.8, was that intentional? === mmrazik is now known as mmrazik|afk [13:46] am i to be supprised that rmadison does not yet show saucy ? [13:46] Possibly. [13:46] apw: i'd say impatient. [13:46] xnox, heh, but you are always the optimist :) [13:47] lack of beer i suspect [13:47] apw: guess what I am on, if I don't drink beer. ;-) [13:48] apw: to be honest that beer / you are weird joke is getting rather old now and not-funny at all. [13:48] * infinity adds it. [13:48] xnox, soz, i am having an offend everyone day it seems [13:49] apw: that's ok, no worries. [13:50] apw: All fixed. [13:50] infinity, taz [13:52] Laney: infinity: transition tracker seems to be activated & running, but it's still raring and not saucy. [13:53] * infinity wonders where that runs from... [13:54] infinity: an interesting lucid schroot on people.canonical.com by ubuntu-archive user, or something of some-such. [13:54] let me look [13:55] Yeah, I just got there. [13:55] infinity, looks ok to me, I can still use this with go build -compiler gccgo [13:55] conflicts: Text conflict in ubuntu/download/archive.ben Text conflict in ubuntu/download/archive_ports.ben [13:55] YOU WHAT [13:56] I take it Laney's on the case. :P [13:56] punching it in the guts right now [13:56] Which is good, cause I've failed to find a config file. [13:56] Oh. [13:56] (lucid-transitions)I have no name!@lillypilly:/srv/transitions/transition-tracker$ grep raring go [13:56] SERIES=raring [13:56] I suspect that would be it. [13:57] ya [13:57] I'll leave it to you. [13:57] let me see what this conflict is about too [13:57] I've dealt with enough variations of voodoo today. [13:59] * Laney briefly ponders getting distro-info in lucid [14:00] Laney: yes, please. [14:20] xnox: is that better? [14:21] Laney: yes, thanks a lot. [14:21] Laney: it's fiddly to setup locally inspection of both release & -proposed pockets. [14:22] rbasak: hi robby [14:22] rbasak: i've just replied to the bug here : https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325 [14:22] Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New] [14:23] sure [14:23] rbasak: if you need any more information, i remain at your disposal [14:30] infinity, what does the kdepim-dev/boost excuse mean? [14:30] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [14:30] xnox, ^^^ [14:32] doko: It means that updating boost-defaults makes kdepim-dev uninstallable. [14:32] but why ... [14:33] dpends only on libboost1.49-dev, libboost-graph1.49-dev [14:33] Yep. [14:33] http://paste.ubuntu.com/5604825/ [14:34] kdepim-dev needs transitioning before boost-defaults can migrate. [14:35] infinity: are you unfreezing saucy, or shall I upload 74 packages and you will accept them? [14:35] xnox, ^^^go on with the tranistion. ogra did migrate [14:35] and / or doko will accept them?! =) [14:35] or ogre ... what's the difference ;p [14:36] xnox, just upload [14:36] ack. [14:36] xnox: I'm unfreezing once gcc-defaults migrates, but it's not hard for us to accept either. [14:36] * xnox ponders if queuebot and launchpad api will get overwhelmed with saucy at :40 ;-) [14:37] doko, the difference is the smell of onions ! [14:37] ogra_: and the other one is 3D as well [14:38] heh [14:39] xnox: Are you implying that ogra only exists in two dimensions? [14:39] * ogra_ feels pretty flat at times [14:39] ... or that ogre actually only ever shows 2D projections [14:40] ogra_, ok, then I'm happy that our room sharing was undone next week ;-P [14:40] doko, heh [14:41] ScottK: the description of bug 831768 had some information regarding letting it wait more than 7 days so it could get more testing... [14:41] Launchpad bug 831768 in aptitude (Ubuntu Oneiric) "aptitude cannot handle conflicts with multiarch enabled" [High,Confirmed] https://launchpad.net/bugs/831768 [14:41] bdmurray: Sigh. I missed that. [14:42] ScottK: bdmurray and now your conversation will be forever flooded with uploads. [14:42] xnox: Erm, are most of these no-change rebuilds? [14:42] xnox: If so, the versions seem a bit suspect. [14:42] infinity: yes, but all of them actually have binary depends.... Hmm..... [14:43] mute queue saucy-proposed [14:43] infinity: good point, I may have used "-i" instead of rebuild one. [14:43] stgraber: thanks. [14:43]