=== yofel_ is now known as yofel
[09:20] <ogra_> yay, properly failed image builds \o//
=== doko_ is now known as doko
[09:58] <Laney> stopping ben for a minute
=== mmrazik is now known as mmrazik|lunch
=== mmrazik|lunch is now known as mmrazik|afk
=== Ursinha_ is now known as Ursinha
[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.
=== lynxman_ is now known as lynxman
[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
=== mmrazik|afk is now known as mmrazik
[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.
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
[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
=== popey_ is now known as popey
[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.
=== Ursinha is now known as Ursinha-afk
[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...
=== Ursinha-afk is now known as Ursinha