[08:15] <Laney> xnox: the relevant cron entry is disabled "for saucy opening"
[08:17] <Laney> which also covers some other things, notably britney, so i'm loathe to uncomment it myself
[09:02] <xnox> Laney: fair enough.
[09:05] <Laney> soz!
[09:05] <Laney> how was the release party?
[09:05] <infinity> Nobody died.
[09:06] <infinity> I suppose that makes it a success.
[09:06]  * infinity adds saucy schroots to all his porting boxes.
[09:06] <Laney> That's what I look for in a party
[09:08] <Noskcaj> do you know if saucy is meant to appear in testdrive yet?
[09:12] <infinity> doko: Did you re-override gcj-4.8 after I did? :/
[09:15] <infinity> Silly double-override bug.
[09:18] <infinity> 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] <infinity> wgrant: It may be the single most confusing thing Soyuz can do to an archive admin who isn't painfully vigilant.
[09:27] <xnox> mk-sbuild saucy is failing for me and doesn't install apt. *sigh*
[09:28] <Laney> debootstrap sad or?
[09:28] <xnox> well I added the usual symlink....
[09:29]  * Laney just finished mirroring so is about to try
[09:30] <xnox> I now copied raring chroot / schroot config and just gonna dist-upgrade it by hand. That seems to work.
[09:30] <wgrant> infinity: If it was reasonably easy I would have done it 3 years ago :)
[09:31] <Laney> xnox: "Failure while installing base packages."?
[09:31] <xnox> wgrant: .... but were you offered fabulous prizes 3 years ago?! =)
[09:31] <wgrant> A good point!
[09:31] <infinity> wgrant: What he said!
[09:32] <xnox> Laney: well i was getting failure in finish.d
[09:32] <Laney> well, that's after this
[09:32] <infinity> xnox: I don't see how debootstrap would fail, given that the release pocket is an identical copy of raring.
[09:32] <wgrant> 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] <xnox> wgrant: how about item #1: Blackpool Rock Candy ?!
[09:33] <infinity> wgrant: Sure, I'll do distro-info-data, that should be vaguely harmless.
[09:33] <wgrant> infinity: Thanks
[09:33] <wgrant> I eventually realised that britney must be turned off, so I hadn't actually broken anything.
[09:33] <wgrant> But I'd like to see saucy-release dominated before I fly away.
[09:35] <infinity> wgrant: Should hit the next publisher run.
[09:37] <RAOF> xnox, infinity: Curiously, debootstrap doesn't seem to download apt-get.
[09:37] <wgrant> infinity: Thanks.
[09:38] <Laney> debootstrap --variant=buildd is failing for me
[09:38] <Laney> but the log file it points me to doesn't exist
[09:38] <Laney> grr
[09:38]  * infinity tests.
[09:40] <infinity> Hrm, yes, the lack of apt there is worrisome.
[09:40] <wgrant> Hm
[09:40] <wgrant> My mirror isn't that out of date, and it works fine
[09:40] <infinity> I'll unwind this in a second.
[09:40] <Laney> http://paste.ubuntu.com/5604007/
[09:45] <wgrant> Are we missing lots of overrides?
[09:46] <wgrant> Yeah
[09:46] <infinity> http://paste.ubuntu.com/5604012/
[09:46] <infinity> Seems likely, from that output.
[09:46] <wgrant> No Build-Essential in Packages
[09:46] <infinity> That could self-solve after this next run.
[09:46] <infinity> Due to the germinate->apt-ftparchive ordering oddities, and the fact that the release pocket hasn't been regenerated in a while.
[09:47] <wgrant> Yeah
[09:47] <wgrant> The last two release publications failed
[09:47] <wgrant> But germinate's working fine
[09:47] <wgrant> The one in 15 minutes will hopefully wor
[09:47] <wgrant> k
[09:48] <infinity> Fingers crossed.
[09:48] <infinity> What was breaking it?
[09:48] <xnox> .... well publishing was stuck last night and there were ooops that vorlon was trying to unwind on #launchpad-ops
[09:48] <xnox> see scrollback there.
[09:48] <wgrant> 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] <wgrant> That *should* be fixed now
[09:49] <infinity> wgrant: Oh, that's vomitously fun.
[09:49] <wgrant> Yes
[09:49] <wgrant> So I think saucy may still be running on its initial indices
[09:50] <wgrant> It's likely that no subsequent release publication succeeded.
[09:50] <doko> infinity, according to my backlog, nobody did override these before I did: http://paste.ubuntu.com/5604017/
[09:51] <infinity> 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] <infinity> doko: I thought Colin has mentioned that to you in a query.
[09:51] <Laney> laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/raring/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes
[09:51] <Laney> 44
[09:51] <infinity> doko: No big deal, copying over itself (which I just did) should rescue it.
[09:51] <Laney> laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/saucy/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes
[09:51] <Laney> 0
[09:52] <wgrant> Yeah
[09:52] <infinity> Laney: Yeah, see above.  That should self-solve when the release pocket reindexes in this upcoming run.
[09:52] <wgrant> infinity: You've checked that the override files look sane now, right?
[09:52] <wgrant> Given you have pepo access
[09:52] <Laney> Rockin.
[09:52] <infinity> wgrant: Nah, I'm operating on faith (and multitasking a bit here)
[09:52] <wgrant> :)
[09:53] <infinity> wgrant: germinate/apt-ftparchive order is a known misfeature, and a plausible explanation for this.
[09:53] <infinity> Colin and I were discussing how NMAF and germinate-from-db combined could wipe that one out.
[09:54] <doko> infinity, but you didn't touch mpclib3, isl, and cloog, correct?
[09:55] <infinity> doko: I did mpclib3, but it doesn't have arch:all packages, so the double-override didn't break it.
[09:55] <infinity> doko: I didn't do the others.
[09:55] <doko> ok
[09:55]  * infinity retries ecj on powerpc...
[09:57] <wgrant> 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] <wgrant> But we'll see shortly.
[09:58] <infinity> adconrad@pepo:/srv/launchpad.net/ubuntu-archive/ubuntu-misc$ grep Build-Essential more-extra.override.saucy.main | wc -l
[09:58] <infinity> 172
[09:58] <wgrant> That's more plausible.
[09:58] <infinity> That seems like a number bigger than 0.
[09:58] <wgrant> Thanks.
[10:00]  * infinity blinks at ecj's continued failure on the buildds, despite it now working in his chroot.
[10:00] <infinity> Grr.
[10:01] <infinity> Oh.
[10:01] <infinity> Get:9 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libisl10 powerpc 0.11.1-2 [445 kB]
[10:01] <infinity> Get:10 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libcloog-isl4 powerpc 0.18.0-2 [65.3 kB]
[10:01] <infinity> That seems a bit suspect.
[10:01] <infinity> doko: Did you just fix the above while we were talking, or can I safely do it now?
[10:01] <doko> $ ./change-override -c main -s saucy -S isl
[10:01] <doko> Override component to main
[10:01] <doko> isl 0.11.1-2 in saucy: universe/libs -> main
[10:02] <doko> Override [y|N]? y
[10:02] <doko> 13 publications overridden.
[10:02] <infinity> doko: That was in the last 30m? :)
[10:02] <doko> infinity, no, do it now
[10:04] <wgrant> infinity: Can you kick boost-defaults out of accepted? It's already published, so that dupe is  oopsing
[10:05] <wgrant> 2013-04-26 10:04:26 DEBUG   Domination for saucy/Release finished
[10:05] <wgrant> So the publisher should be happy now
[10:05] <infinity> wgrant: Punted.
[10:06] <wgrant> Thanks.
[10:08] <wgrant> Every time I watch the primary archive publisher, I want to finish NMAF...
[10:09] <infinity> 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] <wgrant> My attempt in 2009 was dominated by bzip2 compression time...
[10:12] <infinity> 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] <wgrant> Heh
[10:12] <infinity> 2013-04-26 10:07:12 DEBUG   Calculating binary filelist.
[10:12] <wgrant> infinity: So yeah, it's practical, and I might even get bored on the plane.
[10:12] <infinity> That... Shouldn't take 5 minutes.
[10:13] <wgrant> We'd need to add extra override support, bu that's basically trivial
[10:13] <wgrant> infinity: It can if the cache is cold.
[10:13] <wgrant> It just finished
[10:13] <wgrant> Well, 40s ago
[10:13] <infinity> Yeah, I know.  Just as I pasted that.
[10:13] <infinity> My timing is impeccable.
[10:13] <wgrant> Most of LP only works if the cache is hot
[10:13] <wgrant> Because the schema design is not hot.
[10:13] <infinity> *smirk*
[10:13] <wgrant> Thankyou 2005.
[10:14] <infinity> Thank you, "we can always solve it with more RAM" mentality.
[10:14] <infinity> Turns out that there's a limit to that.
[10:21] <wgrant> Well
[10:21] <wgrant> There actually isn't
[10:21] <wgrant> That'd be the easiest solution to our problems today :)
[10:22] <infinity> The limit is when you can't get enough RAM to stuff your DB in it. :P
[10:22] <wgrant> But our DB's still just under 400GB :)
[10:22] <wgrant> I think
[10:22] <wgrant> ez
[10:22] <infinity> *shudders*
[10:23] <xnox> clearly we need a distributed shared memory scientific riggs to run launchpad.
[10:25] <wgrant> New Packages files have Build-Essential!
[10:25] <wgrant> Not quite done yet, though
[10:36] <infinity> wgrant: Oh, other curiosity, the publisher is still hanging on to custom uploads for armel in saucy. :/
[10:36] <infinity> adconrad@pepo:~$ ls /srv/launchpad.net/ubuntu-archive/ubuntu/dists/saucy/main/installer-armel/
[10:36] <infinity> 20101020ubuntu187  current
[10:37] <infinity> wgrant: No other armel cruft, just custom uploads (so, in effect, just d-i).
[10:37] <infinity> wgrant: Easy enough to RM at the filesystem level, but I suspect this means it'll come back AGAIN for t-series?
[10:37] <wgrant> infinity: The latest d-i image is deliberately copied, I'm pretty sure
[10:37] <wgrant> Except that's not the latest, is it..
[10:37] <infinity> wgrant: It's the last that was published for armel, but not the "latest", no.
[10:37] <xnox> .... we don't have armel any more
[10:37] <wgrant> Oh, armel, right
[10:37] <infinity> xnox: Yes, we know. :P
[10:38] <wgrant> Hmm
[10:38] <wgrant> Difficult
[10:38] <wgrant> PUs aren't actually bound to the DAS
[10:38] <wgrant> So we'd have to exclude based on filename
[10:38] <wgrant> Can you file a bug?
[10:38] <infinity> I can.
[10:38] <infinity> But will I?
[10:38] <wgrant> This code is completely hideous and I tried to veto it, but it didn't work :(
[10:39] <infinity> You'd think this would have come up in the past for other dropped arches.
[10:39] <wgrant> It was written since then
[10:39] <infinity> Unless this code happened after we dropped sparc.
[10:39] <infinity> Check.
[10:39] <wgrant> Custom uploads have only been copied since DDs
[10:39] <wgrant> And sparc/ia64 were dropped in maverick
[10:40] <wgrant> Can someone reasonably close to a.u.c try to debootstrap now?
[10:41] <infinity> wgrant: I will.
[10:41] <infinity> wgrant: Also, https://bugs.launchpad.net/launchpad/+bug/1173128
[10:41] <ubot2> Launchpad bug 1173128 in Launchpad itself "Custom uploads get carried over to the next series, even for dead architectures" [Undecided,New]
[10:42] <wgrant> infinity: Done
[10:43] <infinity> This debootstrap package list looks more plausibly correct.  We'll see if it completes.
[10:43] <infinity> Should have done it in RAM, I'd be done by now.
[10:44] <wgrant> Yeah, that's much happier
[10:45] <wgrant> Works fine
[10:45] <infinity> \o/
[10:45] <infinity> Happy EODing.
[10:45] <infinity> And see you on Sunday...
[10:46] <Laney> Indeed. Good stuff.
[10:46] <wgrant> Hopefully there'll be no more breakage...
[10:46] <infinity> Jesus, dude.  Don't SAY that.
[10:47] <infinity> You just lit the DC on fire with your mind.
[10:47] <xnox> infinity: wgrant didn't, but you did =)
[10:47] <wgrant> LP needs to be threatened every now and then.
[10:47] <infinity> *FOOMP*
[10:48] <infinity> Hrm, the sun came back for yet another lovely day in London.
[10:48] <infinity> I don't know what the locals complain about, it's alwayd gorgeous when I'm here.
[10:48] <wgrant> I thought London had banned the sun
[10:48] <wgrant> Yeah, that
[10:51] <doko> infinity, gcj-4.8-jre-lib is still in universe, promoting it ...
[10:52] <infinity> doko: Erm...
[10:52] <wgrant> 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] <wgrant> Not just if two people override them the same way 5 minutes apart.
[10:53] <infinity> wgrant: It's hard to track down exactly who did what when something like this happens, mind you.
[10:54] <infinity> 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] <doko> ok, good to know
[10:54] <infinity> https://launchpad.net/ubuntu/saucy/powerpc/gcj-4.8-jre-lib <-- Ugly publishing history and a half.
[10:54] <wgrant> infinity: Not really. You can see if the two overrides happened within a few seconds of each other
[10:57] <wgrant> 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] <wgrant> Except that it does.
[11:02] <xnox> doko: infinity: can you please accept rocs and ogre ? that would be the zero boost transition iteration.
[11:04] <doko> done
[11:28]  * infinity fixes partner harder.
[11:34] <cjwatson> doko: I've re-enabled most of the archive jobs on lillypilly now
[11:35] <cjwatson> 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] <cjwatson> (which is why the bzr branches weren't automatically updated when slangasek looked - the cron job updates itself)
[11:41] <cjwatson> wgrant: infinity's override did take quite a while, I recall
[11:41] <cjwatson> 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] <infinity> cjwatson: I'm all for it, let's see what explodes. :P
[11:44] <infinity> cjwatson: (And good morning)
[11:44] <cjwatson> I just wanted to be around for its first run, really
[11:44] <cjwatson> Morning.  I'll be off again soon :)
[11:44] <cjwatson> Hmm.  That did nothing
[11:44] <cjwatson> Oh, blocks
[11:45] <infinity> Heh, yeah.
[11:45] <cjwatson> But suspicious excuses
[11:45] <infinity> Yay, partner got fixed in the last publisher run.
[11:45] <cjwatson> Ah, I forgot about symlinks
[11:45] <cjwatson> Let's move that to code so it's less opaque ...
[11:45] <infinity> cjwatson: That excuses looks like it's still doing raring...
[11:46] <infinity> Or am I looking at a stale copy?
[11:46] <cjwatson> It is, hence my "forgot about symlinks" comment
[11:46] <cjwatson> lrwxrwxrwx 1 ubuntu-archive ubuntu_archive     6 Oct 22  2012 testing -> raring
[11:46] <infinity> Check.
[11:46] <cjwatson> lrwxrwxrwx 1 ubuntu-archive ubuntu_archive    15 Oct 22  2012 unstable -> raring-proposed
[11:47] <cjwatson> So I'll leave the block in place for another run just for safety
[11:48] <infinity> That's suspicious anyway, I was fairly sure I removed some of those from raring-proposed.
[11:48] <infinity> Is lillypilly's mirror stale?
[11:49] <cjwatson> Shouldn't be but I'll look later
[11:49] <infinity> Well, if the archive reports cron is disabled, it might not be updating.
[11:50] <cjwatson> I enabled it
[11:50] <cjwatson> And it looked like it had got that far at least
[11:50] <infinity> Weird.  That handbrake definitely isn't in raring-proposed, and hasn't been since yesterday.
[11:51] <cjwatson> infinity: Oh, no, it's just that britney updated its notion of saucy-proposed but then tried to run against raring-proposed.
[11:51] <infinity> In fact, none of those 4 packages are.
[11:51] <infinity> Ahhh.
[11:51] <cjwatson> So it's OK.
[11:52] <infinity> doko: ecj has an actual FTBFS on powerpc now.
[11:52] <doko> infinity, yes, looking
[11:52] <infinity> doko: leviathan has a saucy chroot if you need it.
[11:54] <cjwatson> OK, excuses look more correct now
[11:54] <cjwatson> clearing blocks
[11:56] <cjwatson> 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] <xnox> lgtm =)
[11:58] <infinity> Indeed, looks vaguely sane.
[11:58] <cjwatson> And the copies went to the right place (at least base-files did)
[11:59] <cjwatson> Right, time for me to vanish again :)  SMS me if that caused the publisher to explode or something
[11:59] <infinity> Assuming doko's happy with his toolchain, we're probably about ready to thaw, then.
[11:59] <cjwatson> And you can touch ~ubuntu-archive/proposed-migration/STOP if you need to emergency-halt it
[11:59] <ScottK> infinity: In terms of the success of the release party, depends on who was there if that's a success or not.
[11:59] <infinity> I'll let the publisher run a few more cycles before I unfreeze.
[12:00] <infinity> doko: You happy to unfreeze whenever?
[12:00] <infinity> cjwatson: ^
[12:00]  * xnox has 74 .changes files ready for next boost iteration once ogre-1.8 is published.
[12:00] <xnox> infinity: can't wait to unfreeze =)
[12:00] <doko> infinity, yes, will build ecj with 4.7 for now, don't have the time to investigate today
[12:01] <cjwatson> Up to you lot, I'm about 17 hours out of date on most of this
[12:01] <cjwatson> merges.u.c seems to have updated roughly sanely
[12:01] <infinity> doko: Alright.  We don't need to wait on ecj to unfreeze though, right?
[12:01] <doko> sure
[12:01] <infinity> 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] <infinity> doko: Do you have your usual "Archive open, here's the toolchain changes" email drafted up?
[12:02] <doko> infinity, yes, can do this now
[12:03] <infinity> doko: Delay it an hour or two, I guess.  But yeah, soon.
[12:03] <doko> but lets wait with this until the packages migrate from -proposed
[12:03] <infinity> doko: Yeahp, that was the plan.
[12:04] <wgrant> 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] <wgrant> So I suspect that only raced because the method was called on the old pub
[12:04] <wgrant> It probably wants to scream if it's not the latest.
[12:06] <infinity> wgrant: It's not like we get to choose which one we call it against...
[12:07] <wgrant> infinity: Your API script does
[12:07] <infinity> Oh, is it actually picking (incorrectly) from a list?  I suspect that's fixable.
[12:07] <wgrant> No
[12:07] <wgrant> Well, yes, it picks, but it's correct *at the time*
[12:08] <infinity> Ahh.
[12:08] <wgrant> But then it probably prompts "I'm going to change *these ones*! Pls confirm"
[12:08] <wgrant> Then you wait a few seconds
[12:08] <wgrant> Press y
[12:08] <wgrant> And then it changes the overrides on them
[12:08] <wgrant> In the meantime, a new pub has been created
[12:08] <wgrant> So you're overriding old ones
[12:09] <infinity> Yay, races.
[12:09] <ScottK> xnox: Don't forget to update bzr for your rocs upload.
[12:44] <xnox> ScottK: i haven't. I'm not generating these hundrets of packages from vcs.... especially if they are not lp:ubuntu/pkg
[12:45] <xnox> might update a couple, but I don't promise to update every single one though.
[12:45] <ScottK> xnox: VCS headers are in debian/control for a reason.
[12:46] <ScottK> 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] <xnox> ... including those that point to stale/out-of-date/wrong VCSs?!
[12:48] <xnox> ScottK: rocs VCS as pointed in debian/control is out of date. I'm not touching it.
[12:48] <xnox> missing last raring upload.
[12:49] <xnox> 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] <infinity> 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. :/
[13:10] <ScottK> xnox: Both bzr and raring have 4:4.10.2-0ubuntu1.  I'm not sure what you mean.
[13:12] <xnox> ScottK: bzr tags -d lp:~kubuntu-packagers/kubuntu-packaging/rocs | grep 4.10.2
[13:13] <ScottK> xnox: OK.  It's missing the tag, but the VCS data is up to date.
[13:14] <ScottK> 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] <ScottK> xnox: I think you need to look at the last changelog entry, not just tags.
[13:16] <ScottK> It's easy enough to forget a tag.
[13:20] <doko> infinity, time to drop spu, and demote newlib
[13:24] <infinity> doko: I suppose that's one way to fix the broken versions. :P
[13:26] <doko> infinity, somebody else should be happy too ... (the one wanting to fix newlib during the last two cycles ;-P )
[13:27] <infinity> Yeah.  newlib sucks.
[13:28] <infinity> 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] <doko> and I did annonuce to drop it for jessie already
[13:28] <infinity> Ahh, good.  Cool.
[13:29] <infinity> Then yeah, that's an elegant solution to many problems. :)
[13:29] <doko> people should use the cross-build infrastructure to build it
[13:29] <plars> hmm, where does do-release-upgrade pull the release notes from that it displays to the user?
[13:29] <infinity> plars: Is it getting it wrong?
[13:29] <plars> it looks like on this system I'm upgrading, it still says "alpha" for raring
[13:30] <xnox> meta file from somewhere....
[13:30] <plars> infinity: "This is stiall a ALPHA release. Do not install it on production machines."
[13:30] <infinity> Possibly unrelated, but it looks like the wiki redirect got buggerd. :/
[13:31] <xnox> plars: which text of three do you see? http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/
[13:31] <xnox> I'm guessing Devel, that means meta is pointing to the wrong one.
[13:31] <plars> xnox: devel, yes
[13:33] <plars> ahh, hang on
[13:33] <plars> probably because (by habit) I ran with -d
[13:33] <xnox> hmm... http://changelogs.ubuntu.com/meta-release seems correct
[13:33] <infinity> Yeah, -d would do silly things.
[13:33] <plars> so even if it's released, I guess -d tells it to display the devel one
[13:34] <infinity> At least, until we point meta-release to spanky for devel.
[13:34] <plars> heh
[13:34] <xnox> in other news. The release text in those files is wrong as it mentions "supported from 18 months to 5 years"
[13:34] <xnox> =))))
[13:35]  * xnox ponders to do a grep for "18" across *.ubuntu.com
[13:35] <plars> yes
[13:35] <plars> xnox: that's just in the EOL one though
[13:37] <xnox> yeah, low priority.
[13:38] <plars> xnox: you may want to get *slightly* more restrictive with the search than "18" :)
[13:40] <xnox> plars: true.... About 569,000 results (0.21 seconds)
[13:44] <infinity> doko: The diff for that spu-dropping gcc-defaults also bumped gccgo to 4.8, was that intentional?
[13:46] <apw> am i to be supprised that rmadison does not yet show saucy ?
[13:46] <infinity> Possibly.
[13:46] <xnox> apw: i'd say impatient.
[13:46] <apw> xnox, heh, but you are always the optimist :)
[13:47] <apw> lack of beer i suspect
[13:47] <xnox> apw: guess what I am on, if I don't drink beer. ;-)
[13:48] <xnox> 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] <apw> xnox, soz, i am having an offend everyone day it seems
[13:49] <xnox> apw: that's ok, no worries.
[13:50] <infinity> apw: All fixed.
[13:50] <apw> infinity, taz
[13:52] <xnox> 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] <xnox> infinity: an interesting lucid schroot on people.canonical.com by ubuntu-archive user, or something of some-such.
[13:54] <Laney> let me look
[13:55] <infinity> Yeah, I just got there.
[13:55] <doko> infinity, looks ok to me, I can still use this with go build -compiler gccgo
[13:55] <Laney> conflicts: Text conflict in ubuntu/download/archive.ben Text conflict in ubuntu/download/archive_ports.ben
[13:55] <Laney> YOU WHAT
[13:56] <infinity> I take it Laney's on the case. :P
[13:56] <Laney> punching it in the guts right now
[13:56] <infinity> Which is good, cause I've failed to find a config file.
[13:56] <infinity> Oh.
[13:56] <infinity> (lucid-transitions)I have no name!@lillypilly:/srv/transitions/transition-tracker$ grep raring go
[13:56] <infinity> SERIES=raring
[13:56] <infinity> I suspect that would be it.
[13:57] <Laney> ya
[13:57] <infinity> I'll leave it to you.
[13:57] <Laney> let me see what this conflict is about too
[13:57] <infinity> I've dealt with enough variations of voodoo today.
[13:59]  * Laney briefly ponders getting distro-info in lucid
[14:00] <xnox> Laney: yes, please.
[14:20] <Laney> xnox: is that better?
[14:21] <xnox> Laney: yes, thanks a lot.
[14:21] <xnox> Laney: it's fiddly to setup locally inspection of both release & -proposed pockets.
[14:22] <rustx> rbasak: hi robby
[14:22] <rustx> rbasak: i've just  replied to the bug here : https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325
[14:22] <ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
[14:23] <Laney> sure
[14:23] <rustx> rbasak: if you need any more information, i remain at your disposal
[14:30] <doko> infinity, what does the kdepim-dev/boost excuse mean?
[14:30] <doko> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:30] <doko> xnox, ^^^
[14:32] <infinity> doko: It means that updating boost-defaults makes kdepim-dev uninstallable.
[14:32] <doko> but why ...
[14:33] <doko> dpends only on libboost1.49-dev, libboost-graph1.49-dev
[14:33] <infinity> Yep.
[14:33] <infinity> http://paste.ubuntu.com/5604825/
[14:34] <infinity> kdepim-dev needs transitioning before boost-defaults can migrate.
[14:35] <xnox> infinity: are you unfreezing saucy, or shall I upload 74 packages and you will accept them?
[14:35] <doko> xnox, ^^^go on with the tranistion. ogra did migrate
[14:35] <xnox> and / or doko will accept them?! =)
[14:35] <doko> or ogre ... what's the difference ;p
[14:36] <doko> xnox, just upload
[14:36] <xnox> ack.
[14:36] <infinity> 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] <ogra_> doko, the difference is the smell of onions !
[14:37] <xnox> ogra_: and the other one is 3D as well
[14:38] <ogra_> heh
[14:39] <infinity> xnox: Are you implying that ogra only exists in two dimensions?
[14:39]  * ogra_ feels pretty flat at times
[14:39] <xnox> ... or that ogre actually only ever shows 2D projections
[14:40] <doko> ogra_, ok, then I'm happy that our room sharing was undone next week ;-P
[14:40] <ogra_> doko, heh
[14:41] <bdmurray> 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] <ubot2> Launchpad bug 831768 in aptitude (Ubuntu Oneiric) "aptitude cannot handle conflicts with multiarch enabled" [High,Confirmed] https://launchpad.net/bugs/831768
[14:41] <ScottK> bdmurray: Sigh.  I missed that.
[14:42] <xnox> ScottK: bdmurray and now your conversation will be forever flooded with uploads.
[14:42] <infinity> xnox: Erm, are most of these no-change rebuilds?
[14:42] <infinity> xnox: If so, the versions seem a bit suspect.
[14:42] <xnox> infinity: yes, but all of them actually have binary depends.... Hmm.....
[14:43] <stgraber> mute queue saucy-proposed
[14:43] <xnox> infinity: good point, I may have used "-i" instead of rebuild one.
[14:43] <xnox> stgraber: thanks.
[14:43] <xnox> infinity: reject all and let me try again?
[14:43] <infinity> xnox: Dependencies have nothing to do with it.  If they're rebuilds, all these 1.2.3-1 -> 1.2.3-1ubuntu1 versions should be 1.2.3-1build1
[14:43] <doko> infinity, hmm, wait with accepting ...
[14:43]  * xnox goes to check my scripts.
[14:43] <infinity> xnox: Yeah, I'll just reject the whole queue, since it's all you. :P
[14:44] <infinity> xnox: You want dch -R
[14:44] <ScottK> Some of them probably have version specific boost depends and won't be a rebuild, but I bet most of them are.
[14:44] <xnox> ScottK: I also sed through control ;-)
[14:44] <infinity> Then if you sed through control, those need -i instead of -R.
[14:44] <xnox> true.
[14:45] <infinity> But do be careful on that, we don't want to stop syncs from happening for the ones that aren't changed.
[14:45] <xnox> let me check debdiffs.
[14:45] <infinity> It's a pain to deal with later.
[14:45] <xnox> infinity: reject the whole lot, and let me go through these again.
[14:46] <infinity> Working on it.  Making sure no one uploaded something in the middle of your spw.
[14:46] <infinity> spew*
[14:47] <infinity> xnox: Would be nice if the changelogs were clean on "No-change rebuild for XXX transition" or "Mangled debian/control for XXX transition" too.
[14:48] <xnox> infinity: ack.
[14:48] <doko> infinity, I'm doing another gcc-4.8 upload
[14:48] <infinity> doko: One we want to wait on?
[14:49] <doko> infinity, yes, I think so. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
[14:49] <ubot2> gcc.gnu.org bug 57003 in rtl-optimization "[4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included" [Normal,Resolved: fixed]
[14:52] <infinity> doko: Ick.  Well, I guess that lets you turn off spu in the process.  And give xnox time to do better changelogs. :P
[14:54] <doko> spu already done
[14:54] <infinity> Oh?  I thought you only did it in -defaults, not in GCC itself.
[14:54] <doko> infinity, can we force demoting gcc-4.4 please?
[14:56] <infinity> doko: mysql is still building with it.
[14:56] <infinity> doko: If we can switch that without the testsuite regressing, you win.
[14:57] <doko> infinity, waiting on getting this resolved didn't help  ...
[14:57] <doko> or I'm uploading a gcc-4.4 which just builds gcc-4.4-base ...
[14:58] <infinity> ...
[14:58] <infinity> Dude, we support mysql-5.5, rather a lot.
[14:58] <infinity> I'm not sure how breaking it will force anything.
[15:00] <doko> so apparently it's unsupported. lets talk next week
[15:01]  * xnox shakes fist at "libboost-dev | libboost1.49-dev"
[15:02] <infinity> doko: I'm going to give it a test spin with 4.8 here and see how that goes.
[15:02] <infinity> doko: Maybe the world has improved.
[15:02] <doko> infinity, you misunderstand.
[15:02] <doko> this is buggy asm inline code
[15:06] <infinity> doko: buggy inline ASM that previously worked.
[15:07] <infinity> doko: Anyhow, maybe upstream did something to it, or gcc now mangles it differently.  I don't think it's been checked since SpamapS last changed the build-dep.
[15:07] <doko> infinity, in 4.4 ... yes, so what makes you confident that this will get addressed?
[15:08] <doko> and *nobody* besides debian is using this code
[15:08] <doko> well, us
[15:08] <infinity> doko: Nothing makes me confident that it'll get fixed.  I'm just saying that we can't stop supporting it either, so we need to fix it, not break it.
[15:08] <doko> mariadb ...
[15:08] <infinity> doko: You're welcome to abuse Daviey. :)
[15:09] <infinity> doko: mariadb must have the same code... Maybe there's a patch there?
[15:09] <infinity> (Or it's broken the same way)
[15:09] <infinity> Project renames don't magically fix bugs.
[15:10] <SpamapS> my opinion, btw, is to disable the inline ASM
[15:11] <infinity> SpamapS: There's a way to do that without sadness?  It's been a long time since we talked about this...
[15:11] <SpamapS> rbasak actually reported it as a bug in Debian, which I ack'd
[15:11] <infinity> SpamapS: Was it just a question of ending up with slower C routines?
[15:11] <SpamapS> infinity: there are several ways.
[15:12] <dobey> infinity: hey! did you get a chance to poke at rhythmbox-ubuntuone SRUs btw?
[15:12] <SpamapS> infinity: yes, though I believe in newer yassl's, the inline asm has been fixed
[15:12] <infinity> SpamapS: But, if you have a workaround, please go for it.
[15:12] <infinity> SpamapS: Or, fix the ASM with a cherrypick? :P
[15:12] <dobey> infinity: btw are you in UK/EU this week?
[15:12] <SpamapS> infinity: so one way to handle it is to use newer yassl. Another is to just accept the 10% slow down.
[15:12] <rtg> infinity, are y'all ready for a 3.9 saucy kernel ?
[15:13] <doko> rtg, kernel headers would be nice, yes
[15:13] <SpamapS> infinity: I think the right thing to do is to drop the build-dep, and disable the inline ASM for now. Ihave a TODO to get Debian and Ubuntu mysql in sync once Debian un-freezes.
[15:13] <rtg> doko, ok, gimme a bit
[15:14] <infinity> SpamapS: Alright, cool.  If you're going to be fixing this and dropping the dep, that's good enough for me (and doko).
[15:14] <doko> SpamapS, \o/
[15:14] <infinity> SpamapS: As long as it happens SoonTM.
[15:15] <infinity> SpamapS: (Like, weeks soon, not days soon, I don't think anyone's panicking to drop gcc-4.4 TODAY, just to make sure it's gone this cycle)
[15:15] <SpamapS> infinity: right, lets target a1?
[15:16] <doko> infinity, rtg: and I'd like to demote 4.7 as well. not now, but after the next glibc and linux upstream versions are in the archive
[15:16] <infinity> doko: Should be doable.  I'll do some eglibc PPA tests against 4.8
[15:19] <infinity> SpamapS: Meh, just target "really soon".  Ubuntu doesn't do alphas, but you can target month-1, if you like to have a TODO list.
[15:19] <infinity> SpamapS: I'm sure doko will bug you again if you forget about it. ;)
[15:21] <SpamapS> infinity: ok, a1 was really "target a time where somebody in charge of release management will bug me if I forget"
[15:22] <infinity> SpamapS: Heh.  doko will bug me, and I'll bug you.  It'll be great.
[15:23] <doko> indirect spanking
[15:23] <infinity> SpamapS: (or, you could upload the quick "disable asm" hack to Ubuntu now, and then fix it less crappily in Debian and sync/merge at your leisure)
[15:24] <SpamapS> infinity: indeed I think thats probably the way to go.
[15:28] <infinity> doko, slangasek, cjwatson: Let's avoid touching component-mismatches while toolchain/boost transitions shake out a bit.
[15:28] <xnox> infinity: in the mean time, where shall I upload boost transition? just keep in on my machine or upload into ppa and then do a source copy?
[15:28] <xnox> once gcc4.8 builds & publishes.
[15:29] <doko> sure, looks fine
[15:29] <doko> xnox, upload them now. they can wait in the queue
[15:29] <infinity> Except people might accept them.  Are we concerned about that gcc bug being a problem?
[15:30]  * xnox ponders to artificially tweak .dsc to depend on the pending gcc-4.8, to just let the packages into dep-wait state on gcc-4.8 ;-)
[15:30] <doko> well, misoptimized memcpy ... otoh it didn't show up in gcc itself
[15:31] <doko> xnox, yes, that's what I'm actually doing in such cases ...
[15:31] <infinity> xnox: Not an awful idea, actually.  And simple enough.
[15:31] <infinity> gcc-4.8 >= 4.8.0-4ubuntu2
[15:32]  * xnox goes to add it to my scripts ;-)
[15:32] <xnox> cause i want these built, while I sleep / on the plane.
[15:32] <rtg> infinity, linux_3.9.0-0.1 is in the pipe. Shall I wait on linux-meta until after we're sure headers and everything are good ?
[15:33] <infinity> rtg: Meh, just throw it all at the archive, we'll avoid accepting it for a little while anyway.
[15:33] <rtg> ack
[15:39] <SpamapS> $ bzr branch ubuntu:mysql-5.5
[15:39] <SpamapS> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/mysql-5.5/"
[15:39] <SpamapS> huh?
[15:39] <doko> rtg, heh, you only see something with the headers once you start building with it ...
[15:40] <xnox> SpamapS: we did distro-branch but didn't import saucy yet. Use bzr branch lp:ubuntu/raring/mysql-5.5 for now.
[15:41]  * xnox goes to check if it's safe to start package importer.
[15:42] <SpamapS> xnox: *ah* ok that makes sense
[15:58] <apw> rtg, did you prep linux-signed for saucy as well ?
[16:02] <stgraber> win 77
[16:02] <stgraber> gah
[16:07] <rtg> apw, all 3 packages are uploaded
[16:07] <apw> rtg, great thanks
[16:08] <rtg> let the carnage begin....
[16:13] <rbasak> SpamapS, doko, infinity: note that we *assume* that the C code is slower. I haven't seen any evidence that the assembly actually speeds things up when pitted against a more recent gcc.
[16:13] <SpamapS> rbasak: I tested it
[16:13] <rbasak> So I think it makes complete sense to drop the assembly and use the C until/unless upstream fix it.
[16:13] <SpamapS> rbasak: it was slower.
[16:13] <rbasak> Ah, OK. Fair enough.
[16:14] <SpamapS> rbasak: by about 10%
[16:14] <Daviey> SpamapS: how did you benchmark ?
[16:14] <SpamapS> as I said, I believe they have fixed it in newer yassl
[16:14] <SpamapS> Daviey: 10000 MySQL connections
[16:14] <rbasak> SpamapS: I wonder if updating the entire extra/yassl directory to the latest upstream yassl breaks anything?
[16:15] <SpamapS> I can dig out the results.. its been a while now
[16:15] <SpamapS> rbasak: it does not break anything, I have tested that
[16:15] <rbasak> SpamapS: could that be a cost of connection setup, then, rather than normal use? Who actually uses 10000 MySQL connections in the real world?
[16:15] <SpamapS> the yassl guys are actually really awesome and care a lot about API stability and high performance / low cost
[16:16] <SpamapS> rbasak: *everyone*
[16:16] <Daviey> rbasak: So many crappy php applications have poor connection reuse
[16:16] <rbasak> Oh, OK then.
[16:16] <SpamapS> And specifically, 10000 iterations of connect, do a big giant select, disconnect.
[16:16] <SpamapS> I tested w/o SSL as well for a control
[16:17]  * SpamapS is so bad about keeping these things around :-P
[16:17] <SpamapS> anyway, we're talking about a tiny subset.. i386 mysql servers.
[16:17] <SpamapS> that need SSL..
[16:18] <rbasak> So I guess the question is whether Debian or Ubuntu are willing to carry that patch? I think we want to shrink Ubuntu's MySQL delta if we can rather than grow it, given MySQL's closed development and the existence of MariaDB and Percona etc. I'd rather that we spent the time on them if we're going to introduce deltas.
[16:22] <doko> rbasak, that's not the only thing to consider. we'll drop gcc-4.4 in ubuntu with this patch. this is more than enough
[16:24] <Daviey> My care for 386 is small. :)
[16:25] <rbasak> Daviey: yeah but Debian's is bigger, and I don't want Ubuntu to maintain a delta. I'm concerned that it'll get neglected.
[16:25] <vibhav> When, during the UDS, is the toolchain for the next release discussed? (Assuming such a discussion takes place)
[16:26] <doko> vibhav, there's a blueprint
[16:26] <infinity> rbasak: This wasn't about deltas, SpamapS is going to fix it in Debian.
[16:27] <infinity> vibhav: It's usually more "decided" than "discussed", though we sometimes debate a bit about deadlines for getting things in.
[16:27] <vibhav> doko: Could you link me to the blueprint?
[16:28] <vibhav> ah
[16:28] <vibhav> Yes, the toolchain is rather decided
[16:29] <vibhav> I presume we would be using gcc 4.8.0 for this cycle, wont we?
[16:29] <infinity> Yes.  Already in the archive.
[16:29] <vibhav> \o/
[16:30] <vibhav> thanks infinity
[16:30] <doko> Daviey, did I miss your blueprint to drop i386?
[16:31] <Daviey> doko: no
[16:35] <xnox> doko: Ubuntu Server for quantal and up only released i386 install media.
[16:35] <xnox> s/i386/amd64/
[16:36] <xnox> Daviey: how much do you care about x32 ?
[16:36] <SpamapS> rbasak: I think we'll just live with a bad i386 ssl in MySQL.
[16:36] <Daviey> xnox: Right, but the archive is still reasonable
[16:37] <SpamapS> and by bad I mean 10% slower.. not exactly the end of the world. :-P
[16:37] <Daviey> xnox: My interest in 32 bit is pretty small. But i'm not pushing for it to be discontinued
[16:37] <rbasak> SpamapS: OK, thanks. At least until upstream fix it :)
[16:37] <infinity> SpamapS: Surely, a full upstream pull of yassl is overkill, there must be one upstream commit or something that fixes the bug.
[16:37] <SpamapS> rbasak: don't hold your breath, its been open for 18 months now.
[16:37] <rbasak> infinity: I couldn't find an available upstream VCS when I looked.
[16:38] <SpamapS> infinity: the only reason we have to do that is the ridiculous embedding. Part of my grand plan is to have yassl be its own library.
[16:38] <SpamapS> infinity: gearmand is about to start linking to yassl, so Debian will have two consumers.
[16:38] <infinity> Ahh, ick.  Yeah, linking that dynamically will lead to less sad security teams.
[16:38] <SpamapS> Right.
[16:39] <SpamapS> and we'll get to use the latest yassl, because they're a good library, and don't break backward compatibility.
[16:39] <Daviey> asm makes me cry.  It's impossible to do a reasonable audit without wanting to kll yourself
[16:40] <ScottK> BTW, there are plenty of desktop users of mysql, so it's not just a server thing.
[16:40] <ScottK> (SSL may be though)
[16:41] <infinity> Daviey: That's how I feel about python. :P
[16:42] <Daviey> infinity: pah! :)
[16:43] <ScottK> infinity: Be nice.  You'll make barry cry.
[16:43] <antarus> infinity: bleh
[16:45] <Daviey> infinity: You are confident you could audit malicious asm shellcode embedded in something?
[16:45] <xnox> infinity: are you about for a second review of the batch with corrected version numbers, changelog, and mangled .dsc with gcc-4.8 build-dep ? not two linux packages are in the queue. Turns out none of the packages need s/1.49/1.53/ mangling as all of them use defaults-dev (sometimes defaults-dev | 1.49-dev)
[16:45] <infinity> Daviey: Depends on the machine, not all asm is created equal.
[16:46] <Daviey> infinity: true
[16:47] <xnox> s/not/no/
[16:47] <antarus> Daviey: I don't think his point was that asm was *good*
[16:47] <infinity> xnox: Sure, I'll have a glance when I get back to the hotel.  Don't feel like being in the office all night again.
[16:48] <xnox> infinity: ack. will upload in a sec.
[16:48] <antarus> dynamic languages like python let you do colossally stupid things
[16:48] <antarus> like the C preprocessor ;p
[16:50] <rbasak> All Turing compelte languages let you do colossally stupid things :)
[16:51] <xnox> rbasak: any language let you do colossally stupid things =)
[16:51]  * rbasak invents a language with only one command that takes no parameters: "exit"
[17:37] <xnox> vowpal-wabbit.updated.changes -> inappropriate changesfile name, OMG!
[18:41] <dobey> everything that gets accepted to raring-proposed will end up in saucy right now?
[18:45] <xnox> dobey: NO!
[18:46] <xnox> dobey: anything accepted to raring-proposed will end up in raring-proposed => heading for SRU.
[18:46] <xnox> dobey: saucy already has different compiler and boost1.53 api. and kernel.
[18:47] <xnox> dobey: one should do an upload to saucy _first_ and then to raring-proposed.
[18:47] <dobey> xnox: right, but at least in the past there has been a period of time when updates to the just-released ubuntu will get copied into the new development version as well
[18:47] <xnox> dobey: all 0day sru's and raring-proposed carry over, has already been carried over.
[18:48] <xnox> that was done yesterday.
[18:50] <dobey> i'd rather not have to create separate uploads for this :-/
[18:50] <dobey> but i don't know if the fix is totally correct yet or not, and Laney has presumably already left
[18:50] <dobey> hopefully not missing his flight if he's going to the sprint
[18:51] <xnox> AAs: please reject clamav, cups, casper, maas from raring-proposed unapproved queue. All of them trying to upload a higher than saucy version number into raring without using SRU version number.
[18:51] <xnox> (SRU team?!)
[18:52] <xnox> glib-networking already has matching upload in saucy and correct SRU version in raring-proposed unapproved queue.
[18:52] <xnox> dobey: upload to saucy with normal version number. Bugs should be fixed in saucy first!
[18:52]  * xnox or laney or anyone else can do sru version upload for you later.
[18:53] <xnox> or it will simply wait.
[18:53] <dobey> xnox: well it's a bug that doesn't really affect saucy, as it only happens on upgrade from quantal -> raring
[18:54] <xnox> dobey: bug # ?
[18:54] <ScottK> I self rejected clamav.  I meant that for saucy.
[18:54] <dobey> xnox: bug #1173249
[18:54] <ubot2> Launchpad bug 1173249 in software-center (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Critical,Triaged] https://launchpad.net/bugs/1173249
[18:55] <dobey> i guess i should mark it invalid for saucy though
[18:55] <xnox> dobey: i think it still should be in saucy, as at one point we were considering quantal -> lts upgrades. Also wouldn't it affect precise -> next-LTS upgrades?
[18:56] <xnox> dobey: and regradless it's friday, so there is no difference in uploading today vs on monday.
[18:59] <dobey> well, it doesn't change the fact that in the past, i have uploaded packages to release-proposed to do updates, and was able to just have them copied over to development series, within the first few weeks after a release. i don't recall any new policy to disallow that being declared (but if there was, please refersh my memory with a URL) :)
[19:00] <stgraber> xnox: are you done flooding the saucy?
[19:02] <stgraber> unmute queue saucy-proposed
[19:05] <ScottK> xnox: I fixed clamav.
[19:06] <xnox> stgraber: yes.
[19:06] <xnox> ScottK: thanks.
[19:06] <ScottK> That was just my fingers typing raring while my brain was saying saucy.
[19:07] <xnox> stgraber: want to redirect casper upload to saucy?
[19:08] <stgraber> xnox: didn't I copy it already?
[19:08] <stgraber> ah no, looks like I only copied the one from -updates not the one that was in -proposed
[19:09] <xnox> stgraber: nope, there is 1.332 in raring-proposed unapproved. which is higher than salamaner
[19:09] <xnox> salamander.
[19:09] <stgraber> xnox: right. I'll wait for that one to be at least approved in raring-proposed then will do a binary copy to saucy
[19:09] <xnox> stgraber: but it's not using sru style version number. But I guess you can blag it that it actually is ;-)
[19:10] <ScottK> xnox: It's usual for us to forward copy stuff until the archive is open for uploads.
[19:10] <ScottK> xnox: There's no requirement for a particular style of version numbers for SRU.
[19:10] <xnox> ScottK: which is bad encouragement.
[19:10] <stgraber> xnox: well, to be fair at the time I uploaded it, it wasn't clear whether it'd be an SRU or not ;)
[19:10] <xnox> stgraber: sure.
[19:11] <ScottK> I think it's better to announce a change in the way we do things rather than just rejecting stuff.
[19:11] <stgraber> ScottK: btw, if you've got a sec, it'd be great if you could let casper into raring-proposed. I'd like that one fixed ASAP so that anyone building a derivated distro picks it up and avoids the bug.
[19:12] <xnox> ScottK: if not gcc bug, we would be open now. And I don't want what happened in raring where 2 months later (which is ~6 weeks after archive open) on my raring system I saw uploads in quantal-proposed & quantal-updates >> than raring
[19:12] <ScottK> stgraber: Sure.
[19:12] <ScottK> infinity: I think xnox is volunteering to join the SRU team.
[19:13] <stgraber> xnox: don't worry, I've got a script for that and I monitor + copy-package when I spot one
[19:13] <stgraber> though I usually only care once the package hits -updates
[19:13] <xnox> ScottK: I volunteer to be AA and only remove packages =)
[19:14] <ScottK> No, that's StevenK's job.
[19:14] <ScottK> stgraber: Need a test case.  You can add that while it's building.
[19:14] <stgraber> ScottK: ah yeah, true, didn't do the SRU paperwork back then :) will do in a sec
[19:14] <ScottK> Thanks
[19:16] <ScottK> xnox: I'll forward copy that one after it's built/published.
[19:18] <xnox> I'd even would like to get security team to do saucy first and/or together with -security if the version numbers still match.
[19:21] <stgraber> ScottK: there you go
[19:22] <ScottK> Thanks.
[19:22] <ScottK> xnox: They usually do.
[19:29] <infinity> xnox: You might want to avoid making policy that other people enforce. :)
[19:29] <infinity> xnox: It's pretty routine for 0-day SRUs to get copied over, rather than force two identical uploads.
[19:31] <infinity> xnox: Now, this doesn't go on forever, but you were demanding we reject things that were uploaded before raring released.  Trust me, if I had planned on doing so, I would have done so then.
[19:31] <xnox> infinity: sure. but it's day 1 now =) the stuff that is in unapproved queue already is fair game and the rest of packages there have SRU template complete.
[19:32] <infinity> (We also have scripts to check if release-1-updates is >> release)
[19:32] <xnox> infinity: dobey wanted to upload something today as if it was 0-day SRU (which may still be possible, if in fact we do not need that patch in saucy but it feels like if it's needed for quantal -> raring upgrade we do want it in saucy)
[19:33] <infinity> xnox: If he uploads it to raring, we want it in saucy too, yes.  And we'll copy it.
[19:33] <stgraber> I don't see what annoying people who worked hard during release week preparing SRUs gets us. The backlog of pre-release SRU uploads should just get processed as usual and then be copied to saucy once built, which AFAICT has been done by the SRU team (or me with the mass copy I did yesterday)
[19:33] <infinity> xnox: In short, please don't flip out about nothing, this is business as usual.
[19:33] <infinity> stgraber: Indeed, I did some yesterday too.
[19:34] <xnox> hmm...... it's just in raring cycle release-1-updates was << release, but that patch was not actually part of release. ( one person did -1-updates while the other did release) and it took a few months to get noticed.
[19:34] <xnox> that was with lvm2 package.
[19:35] <stgraber> oh and I really need to poke cjwatson and infinity during the sprint about that whole becoming an AA and SRU team member thing
[19:35] <infinity> xnox: That's unfortunate, but not solved by this.
[19:35] <xnox> not sure how that slipped all the fancy reports you say exist and you are teaching me about.
[19:35] <infinity> xnox: Reports don't look at the contents of packages.
[19:36] <xnox> i think a third party noticed and opened the task against $release and that's how eventually we noticed this.
[19:37] <infinity> xnox: Anyhow.  I'm not here to argue.  Just calm down.
[19:37] <slangasek> infinity: so do you want me to prepare separate uploads for this hdparm SRU I was about to do? :)
[19:37] <infinity> xnox: Yes, SRU patches can get lost in release+1 when someone does a merge or something and skips that revision.  That's not new.
[19:38] <xnox> infinity: also very true =)
[19:38] <xnox> anywho I have now boost1.53 build failures to attend to and/or pack =)
[19:38] <infinity> slangasek: Couldn't care less, tbh.
[19:38] <slangasek> xnox: I wouldn't really advise packing the boost1.53 build failures; they could push your luggage over the weight limit
[19:39] <infinity> (Yes, we should move to the "fix it in both releases independently" thing soon, both to get new toolchain good/badness, and to make sure we're not stomping all over ourselves with merges, but in the first few days after release when all is calm, I really don't much care, and I'm all for a bit of slack)
[19:40] <infinity> I'd rather be having a beer than uploading everything twice today. :P
[19:41] <xnox> i guess something lightweight like opening a saucy task should be enough on those to "copy over once build OR notice that it got stomped over and do a separate upload"
[19:41] <xnox> =))))
[19:41]  * xnox forgets about sloppy SRUs , boost1.53 FTBFS, packing and goes to drink tea!
[19:42] <infinity> Shouldn't need a saucy task, the generic task won't be closed by an SRU (assuming there is a generic task).
[19:55] <phillw> infinity: just as total "by the way", is there any planned date for the first makes of the likes of lubuntu to arrive on the daily images?
[19:55] <ScottK> "next week"
[19:56] <infinity> phillw: We'll turn dailies on again over the weekend or early next week.
[19:56] <infinity> phillw: No schedule day for flipping the switch, but "soon".
[19:56] <infinity> phillw: Right now, they're be nearly identical to raring anyway, so not much excitement there. :P
[19:56] <infinity> s/they're/they'd/
[19:56] <phillw> ScottK: infinity thanks :) You know how keen our l-QA testers are :D
[20:26] <dobey> can someone sponsor the debdiff on bug #1173249 into raring-proposed please? since i don't have upload privs to pygobject
[20:26] <ubot2> Launchpad bug 1173249 in software-center (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Critical,Triaged] https://launchpad.net/bugs/1173249
[20:32] <ScottK> dobey: I'd try -devel.  There's nothing release specific about a sponsoring request and there are more people there.
[20:53] <dobey> i guess it's just not a great time for requesting such a thing, regardless of where the request is made.
[20:57] <ScottK> No
[21:26]  * cjwatson uploads ghc - might as well get that in place along with the rest of the toolchain
[21:27] <Laney> seriously?
[21:27] <cjwatson> why not?
[21:27] <cjwatson> (you have 80MB worth of upload time to persuade me to C-c :-) )
[21:27] <Laney> http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html doesn't change very much
[21:28] <Laney> There will probably be a more featureful upstream release that will be more worth the effort
[21:28] <cjwatson> I guess ...
[21:28] <antarus> cjwatson: you can move to austin, TX, they are getting google fiber ;p
[21:28] <cjwatson> Wish we had binNMUs, then it wouldn't be so annoying
[21:28] <Laney> well, this transition should be entirely no-change
[21:28] <cjwatson> antarus: I will live in the US some time after hell freezes over
[21:29] <cjwatson> Laney: OK, ctrl-c'ed
[21:29] <Laney> merci
[21:30] <dobey> cjwatson: given the rate of ice cap melting, we're not too far from that ;)
[21:30] <Laney> yeah, we can help it along with ghc transitions too :P
[21:30] <Laney> ref. https://buildd.debian.org/~nomeata/graphs.cgi
[21:31] <dobey> heh
[21:31] <dobey> Laney: i don't have upload privs to pygobject btw. attached a debdiff to the bug, if you have a minute to upload it :)
[21:32] <Laney> dobey: I'm a beer or two down - feels like a dubious proposition to me
[21:32] <Laney> tomorrow on my travels though, no probs
[21:32] <dobey> heh
[21:39] <ScottK> antarus: Kansas City has Google Fiber.  It gets pretty cold in the winter there.   Maybe he'd go for that.
[21:40] <cjwatson> It's not the *temperature* I object to :)
[21:42] <ogra_> the fiber ?
[21:43] <ogra_> you're such a copper guy
[21:43] <dobey> i definitely like my fiber
[21:43] <dobey> even if it's not gigabit yet
[21:43]  * ScottK <--- too (FIOS, not Google, but it'll do)
[23:34] <slangasek> Riddell, ScottK: hey, so there are an awful lot of kubuntu-specific plymouth bugs coming in for raring; I don't know of any reason there would be kubuntu-specific plymouth problems though, and I can't reproduce them either in a VM or on real hardware by installing the kubuntu theme on an existing Ubuntu system.  Is there someone who could take a look at these and figure out what's going on?
[23:34] <ScottK> apachelogger would be the appropriate victim.
[23:34] <slangasek> ok
[23:35] <slangasek> apachelogger: ping, re: plymouth+kubuntu
[23:35] <ScottK> he's not online though.
[23:36] <ScottK> There are some issues that only happen on fresh install, not upgrades, so it wouldn't surprise me if a system that already had Ubuntu on it would be different.