[09:20] <ogra_> yay, properly failed image builds \o//
[09:58] <Laney> stopping ben for a minute
[13:04] <Laney> OK I think I have ben looking at -proposed correctly now
[13:05] <Laney> http://people.canonical.com/~laney/www-test/ghc.html
[13:05] <Laney> I'd appreciate some quick sanity checks before putting it into production
[13:05]  * Laney lunches
[13:07] <cjwatson> Laney: seems to match my by-hand analyses of britney output
[13:09] <cjwatson> Laney: any recommendations for the best way to adapt "libghc-persistent-dev (>> 0.9), libghc-persistent-dev (<< 0.10)" type build-deps to handle the reversion of haskell-persistent?
[13:10]  * cjwatson does boolean algebra
[14:08] <xnox> do we have dcut facility?
[14:09]  * xnox uploaded something into the archive, instead of my sbuild.... so there is a untested merge uploaded now. Well the worst that can happen, it will still FTBFS.
[14:17] <tumbleweed> xnox: no
[14:41] <Laney> ok then, ben is re-enabled and should be proposedified now
[14:42] <xnox> Laney: so it looks at both now? =)
[14:42] <xnox> nice
[14:42] <Laney> hopefully
[14:44] <Laney> a side-effect is that it no longer uses ./ben download … to get Packages/Sources
[14:44] <Laney> so to update for a new release you need to edit SERIES in the 'go' script
[14:44] <xnox> Laney: I smell magic by-hand downloading and concatination...
[14:45] <Laney> it's not so magic, but yeah
[14:55] <apw> Laney, where did that test page wander off too
[14:55] <Laney> the great bit bucket in the sky
[14:56] <Laney> http://people.canonical.com/~ubuntu-archive/transitions/ is now running that code
[15:24] <xnox> Laney: how often are transitions regenerated?
[15:28] <Laney> xnox: every publisher run, so half hourly I think
[15:33] <xnox> Laney: ack.
[17:14] <infinity> xnox: We process our FTP queues every 5 minutes, you'd have to be rather quick/lucky to get a dcut in (if we supported the mechanism, which we don't)
[17:15] <xnox> Laney: Page generated on Tue, 06 Nov 2012 16:12:49 +0000 is more than half an hour.
[17:15] <xnox> infinity: I needed it that quick =)
[17:15]  * xnox wasted a few CPU cycles.
[17:16] <infinity> xnox: Yeah, my point is that the window is so tiny that, while it might sometimes work, it would just as often not, so implementing the feature would be pretty much pointless.
[17:17] <infinity> xnox: This is also why I now have a habit of doing PPA uploads that are << the version that I plan to upload to Ubuntu. ;)
[17:17] <infinity> (Things like testpackage_1.2.3-2ubuntu1~ppa1, where my real merge is that, minus the ~ppa1)
[17:24] <stgraber> infinity: I think I'll actually make it to my estimate of "can be done by Thursday" for the QA tracker work to allow for builds to belong to more than one milestone and to store the product manifest in the tracker.
[17:25] <infinity> stgraber: Shiny!
[17:25] <stgraber> got the first part 90% done, just need to fix an extra 3 functions and for the manifest, the DB is there and the functions use it, just need to make some kind of decent UI for it
[17:26]  * Laney gives xnox a can of Lilt
[17:26] <Laney> take it easy mon, it's done now (was already running)
[17:27] <xnox> Laney: it takes that long =/
[17:27] <xnox> *sigh*
[17:27] <Laney> I doubt it
[17:28] <Laney> it updates whenever the release pocket changes
[17:29] <xnox> Laney: oh.. it should update whenever proposed pocket changes =)
[17:29] <Laney> well, either of them
[17:29]  * xnox is not even sure if it really was a can of Lilt now =)
[18:00] <xnox> doko: please prepare & upload python3-defaults that drops 3.2 from supported versions, the remaining packages that depend on python3.2 will need to be rebuild after 3.2 is dropped.
[18:14] <plars> xnox: have you seen https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1075631 I seem to also get a similar hang during install on amd64
[18:14] <ubot2`> Launchpad bug 1075631 in ubiquity (Ubuntu) "Ubiquity hangs on Raring i386 desktop installation at Step_before = stepLanguage' for vm and at Step_before = stepWebcam for hw" [Undecided,Confirmed]
[18:15] <xnox> plars: I have seen the bug, but I have not been testing or fixing ubiquity yet post-uds.
[18:16] <xnox> plars: good that the images are available though.
[18:16] <plars> xnox: indeed :)
[18:17] <plars> xnox: the i86x and amd64 images just started showing up today I think
[18:25] <infinity> plars: Yeah, we had some hiccups in the livefs buildds.  Should all be sorted now.
[18:41] <tumbleweed> infinity: we *could* kill an upload until the publisher ran (with significantly more pain)
[18:42] <tumbleweed> (re-dcut)
[18:43] <infinity> tumbleweed: un-accepting isn't quite the same as dcut, and is pretty fiddly.
[18:44] <infinity> (Unaccepting in dak is just a matter of moving things around between directories, unaccepting in Soyuz is database surgery... It's a feature someone sufficiently motivated *could* implement in a friendly way, I imagine, but it seems like a waste of time to try)
[18:45] <tumbleweed> it would occasionally be useful, but only very occasionally
[20:19] <doko> xnox, done
[22:11] <xnox> doko: thanks.
[22:12] <doko> xnox, do you take care about the non-change uploads?
[22:16] <xnox> doko: yes.
[22:17] <doko> thanks!
[22:20] <doko> hmm, why is ggcov only built on i386?
[22:30] <infinity> doko: Cause it landed in P-a-s as i386-only.
[22:31] <doko> infinity, debian builds it for amd64 too
[22:31] <infinity> Not anymore, apparently.
[22:32]  * infinity looks for history.
[22:32] <doko> hmm
[22:32] <doko> wondering about the amd64 comment in the last upload ...
[22:36] <infinity> doko: Hrm, it's always been i386-only in Debian (at least, as long as P-a-s has been in git), so I suspect we once removed it from ours, and it got mistakenly merged back in recently.
[22:36] <infinity> doko: https://buildd.debian.org/status/package.php?p=ggcov
[22:36] <doko> yes, seen
[22:36] <infinity> doko: ^- Clearly shows it only being on i386, methinks the maintainer was just blindly merging from us. ;)
[22:37] <infinity> Anyhow, do we know it actually works on amd64 at all?  The disabling of testsuites implies it might not.
[22:37] <infinity> But I'm happy to remove it from our P-a-s and create the missing build.
[22:42] <infinity> doko: Opinions?
[22:47] <doko> infinity, no, not necessary. just stumbled upon it because binutils wouldn't migrate
[22:51] <infinity> doko: Right, well, we can just remove the amd64 binary.  But if it works there, I'd rather fix P-a-s.
[23:44] <infinity> doko: I'm going to go with the "trust ggcov's debian/control" theory here, and remove it from P-a-s, and create the missing build.
[23:44] <doko> mehh, wait until binutils is in raring ...
[23:45] <infinity> doko: Hrm?  won't require a reupload or anything...