[00:00] <Daviey> infinity: Fancy revewing ubuntu-archive ML, i have a held mail.
[00:13] <cjwatson> Daviey: Done, and whitelisted you for the future.
[00:14] <Daviey> cjwatson: thank you sir.
[00:14] <Daviey> (i assumed you'd be smarter than me, and be afk :)
[02:14] <micahg> skaet: would it be ok for me to add Firefox/Thunderbird to the interlock page?
[02:15] <skaet> micahg,  please do.  :)   Thanks!
[02:17] <micahg> skaet: only conflicts seem to be alpha 1 (we can upload final early I think), and final freeze (release is 2 days before RC candidates)
[02:30] <skaet> micahg,  thanks for making that visible.  :)
[03:02] <infinity> cjwatson: Okay, arm* toolchains should be in a sane state again.  I'm going to freshen all the buildd chroots after eglibc is done building, and you should be good to go on the unstable autosync switcheroo any time after that (so, in a few hours).
[07:19] <infinity> cjwatson: Alright, chroots all updated and verified happy.
[08:58] <cjwatson> infinity: great, thanks
[10:29] <xnox> cjwatson: based from email to u-d, did you start syncs from unstable or are you still working on a work-around to enable syncing from unstable?
[10:30] <cjwatson> I meant what I said :-)
[10:31] <cjwatson> I'm still working on the workaround
[10:31] <cjwatson> I just wanted to give slightly more than "hi, I just started syncing from unstable, kthxbye" kind of notice
[10:44] <cjwatson> But certainly this is "speak now or forever hold your peace" kind of time
[10:49] <xnox> ok.
[10:49] <xnox> I have managed to make ubiquity fail one unit test by the way ;-)
[10:50] <xnox> but is comming up.
[10:50] <cjwatson> oh?
[10:50] <cjwatson> (-> #ubuntu-installer maybe)
[10:55] <cjwatson> gosh, my auto-sync workaround seems to be working more or less first time; I genuinely hadn't expected that
[10:57] <xnox> you are just awesome =) didn't you get used to that by now?! ;-)
[11:00] <ogra_> xnox, the prob is that he never belives us :)
[11:08] <wgrant> cjwatson: What'd you do?
[11:10] <cjwatson> wgrant: Fell back to fetching Sources from Debian
[11:10] <cjwatson> You thought auto-sync was elegant?
[11:10] <wgrant> Heh
[11:13] <cjwatson> Hm, slightly different results for new packages though; will need to look into that
[11:48] <ScottK> I'd appreciate it if someone from ubuntu-sru could accept the remaining KDE 4.8.3 packages for precise-proposed so we can get testing.
[13:40] <cjwatson> wgrant: Looking at this, I'm not sure I believe the accuracy of DSD creation in the slightest.
[13:42] <cjwatson> I'll file a bug, but right now I think I'm honestly better off not bothering to look at them.
[13:45] <wgrant> cjwatson: I don't trust them at all, but what's the issue?
[13:45] <wgrant> I had no part in them other than defining the base version calculation.
[13:45] <cjwatson> A fair number of new packages in wheezy that have no DSDs.
[13:46] <wgrant> That's unhelpful.
[13:46] <cjwatson> Including some that were never in Ubuntu and ought to be synced, and some that were removed but have since had new versions in Debian.
[13:50] <cjwatson> wgrant: Do you think it will cause any major obstacle to investigation if I go ahead and sync some of the packages that should be synced?
[13:50] <wgrant> cjwatson: Go ahead
[13:50] <wgrant> It'll be months/years before anyone can investigate, and there are probably other cases
[13:52] <cjwatson> Righto
[14:12] <slangasek> how do I see from launchpad who synced a package?
[14:12] <slangasek> someone synced python-xattr over an Ubuntu delta, dropping the dh_python2 integration
[14:14] <stgraber> slangasek: Signed-By: Andres Rodriguez <andreserl@ubuntu-pe.org>
[14:14] <slangasek> stgraber: how do I see that ;)
[14:14] <stgraber> slangasek: quantal-changes :)
[14:15] <slangasek> stgraber: ah, ok
[14:15] <stgraber> slangasek: there might be some obscure way of getting it from LP too
[14:33] <tumbleweed> slangasek, stgraber: The SPPH record creator in the LP API
[14:34] <slangasek> tumbleweed: so nowhere visible in the UI?
[14:35] <tumbleweed> no, that would be too easy :)
[14:35] <slangasek> ack :)
[14:35] <slangasek> thanks for the info
[14:38] <cjwatson> Right, running a final auto-sync with the new algorithm from Debian testing, and then I'll attempt a switch to unstable
[14:38] <cjwatson> This has taken way too much of the day
[14:41] <tumbleweed> cjwatson: [reading backscroll] it may be useful to output a report on removed packages that have never versions in Debian to the version we removed (assuming they weren't blacklisted). or are such reintroductions rare enough not to bother?
[14:43] <cjwatson> auto-sync outputs those
[14:43] <cjwatson> Whoever's running it gets to decide what to do (or defer)
[14:43] <tumbleweed> great
[14:43] <cjwatson> They're certainly not infrequent
[14:44] <cjwatson> At some point I might add some stuff to open up packages.qa.debian.org and publishinghistory URLs in a browser or something
[14:44] <cjwatson> Since that's usually what I do to try to work it out
[17:51] <cjwatson> Auto-sync from unstable in progress ...
[17:51] <seb128> *fear* ;-)
[17:52]  * micahg wonders how many builds will end up in the queue
[17:53] <cjwatson> You know, I'm just going to go with "lots"
[17:55]  * micahg is just wondering if it'll be anywhere near the 10k at the first autosync
[17:56] <cjwatson> I shouldn't think so
[17:56] <stgraber> cjwatson: are you expecting a lot of things to hit New? (wondering if we should silence queuebot again)
[17:58] <cjwatson> Yes
[17:58] <cjwatson> Probably a plan
[17:59] <cjwatson> [New] nyancat_0.1+git20120401.5a88b86-1
[17:59] <cjwatson> obviously that's vital
[18:00] <knome>  
[18:02] <stgraber> ;)
[18:04] <stgraber> cjwatson: can you run "/msg chanserv quiet #ubuntu-release queuebot"? (chanserv tells me I don't have access)
[18:05] <cjwatson> There you go
[18:05]  * knome is wondering if stgraber ircs from the same host
[18:05] <knome> ;]
[18:05] <cjwatson> He's cloaked, hopefully that makes a difference
[18:06] <knome> we probably see in a moment ;)
[18:06] <stgraber> I'm connected with @shell01.dmz.dcnue.stgraber.net which is also vorash but over IPv6
[18:06] <knome> heh
[18:07] <stgraber> (and the cloak probably also lets me avoid that mask)
[18:07] <cjwatson> http://paste.ubuntu.com/1005184/
[18:07] <cjwatson> pressed enter, let's see how many goes it takes to get it through LP
[18:16] <ScottK> pitti: Thanks for accepting kde-l10n for precise.  If you could also accept blinken and cantor, we'd have all of KDE 4.8.3 in (they're in Universe and the uploader isn't MOTU, so they took longer to get in the queue).
[18:17] <cjwatson> (1256 syncs, FWIW)
[18:21] <micahg> 15 hrs on powerpc, not so exciting
[18:21] <cjwatson> It's not finished processing the PCJs yet, but sure
[18:22] <micahg> ah, ok
[18:44] <tumbleweed> looks like we got to 42 hours on ppc
[18:46] <micahg> nice, hopefully we'll end up with less build failures than we currently have
[20:34] <stgraber> I just uploaded a new lxc (-3ubuntu57) to precise-proposed. The diff is fairly big though I think I did a reasonable job of describing everything in the changelog.
[20:34] <stgraber> as discussed earlier with SpamapS, quite a few improvements are in there that won't change the behavior for the user but will make it significantly easier for us to cherry-pick additional fixes from quantal (if needed)
[20:35] <stgraber> I have testcases in all the linked bugs except one (lxc-start-ephemeral failing to get the IP from dhcp lease file) but I was told by gary_poster that the bug would be updated tomorrow
[20:36] <stgraber> the LXC testsuite was also run without spotting any regression. If whoever reviews it has any question, feel free to poke me :)
[22:09]  * xnox is puzzled
[22:09] <xnox> bitcoin	[build logs] (0.6.2.2-1)	✔	✔	✘	✘	✘
[22:09] <xnox> in the boost1.49 transition tracker, when it required boost1.49 merge, to get gcc4.7 ftbfs fixes
[22:10] <micahg> xnox: old binaries exist
[22:10] <xnox> micahg: but they would not have passed the transition criteria
[22:10] <micahg> hrm?
[22:11] <xnox> it looks like it was synced 3h40m ago, maybe newer bitcoin works around boost brokeness
[22:11] <micahg> no, it just dropped the other archs
[22:11] <xnox> micahg: I am talking about this page: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[22:11] <micahg> err...idk about boost, but it dropped the other archs
[22:11] <xnox> are we on the same page?
[22:11] <micahg> xnox: yes, I nkow
[22:11] <micahg>   bitcoind | 0.3.24~dfsg-1 | quantal/universe | armel, armhf, powerpc
[22:12] <xnox> aha thanks
[22:12] <xnox> I wonder why though
[22:12] <micahg> hrm, LP doesn't recognize any-arm apparently
[22:13] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669200
[22:13] <micahg> infinity: ^^
[22:13] <ubot2> Debian bug 669200 in bitcoind "bitcoin: FTBFS on armel, armhf" [Normal,Fixed]
[22:13] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668864
[22:13] <ubot2> Debian bug 668864 in bitcoind "bitcoind: Doesn't support big-endian systems" [Wishlist,Fixed]
[22:14] <micahg> xnox: yes, powerpc binary should be removed, but arm needs any-arm to be recognized
[22:15] <xnox> micahg saves the day again!
[22:15]  * micahg flies off into the sunset
[22:15]  * xnox files an lp bug?
[22:16] <micahg> bug 917708
[22:16] <ubot2> Launchpad bug 917708 in launchpad "Launchpad does not recognize Arch = any-arm" [Low,Triaged] https://launchpad.net/bugs/917708
[22:16] <xnox> yeap, found it as well now =) you are quicker
[22:22] <xnox> micahg: can we bump the priority of that bug?
[22:22] <micahg> xnox: better off buying infinity cookies
[22:24] <xnox> infinity: I promise british biscuits to you =)
[22:34] <infinity> That's a recognized arch?
[22:41] <micahg> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668868#28
[22:41] <ubot2> Debian bug 668868 in src:bitcoin "bitcoind: Assertion failed at startup on mips (big endian)" [Serious,Fixed]
[22:51] <infinity> xnox: And yeah, for now, you'll just want to replace any-arm with "armel armhf"
[22:53] <infinity> (I can't imagine any-arm is used a lot...)
[22:54] <slangasek> whoa, any-arm is an alias to arm*?  That seems contrary to the other any globs
[22:55] <slangasek> I would've expected any-arm to match arm, hurd-arm :P
[22:55] <infinity> Yeah, I would have too.  But it seems to be a CPU alias.
[22:55] <slangasek> yuck
[22:55] <infinity> Which, actually, would make it incorrect for bitcoin's stated use ANYWAY.
[22:55] <infinity> Since it would match any-armeb.
[22:55] <slangasek> \o/
[22:55] <infinity> xnox: So, file a bug on bitcoin to change it to any-armel and any-armhf. :P
[22:56] <infinity> xnox: (In Debian)
[22:56] <infinity> Not that anyone builds armeb anymore, but it's the principle of the thing.
[22:57] <slangasek> or arwoofeb
[22:58] <infinity> aarc64eb
[22:58] <infinity> With a missing h.
[22:59] <slangasek> aardvarch
[22:59] <infinity> aardvarcheebie.
[23:00] <infinity> I'm actually kinda hoping the ditched the ability to flip endianness in v8, but I haven't looked.
[23:02] <slangasek> dh_clean: No compatibility level specified in debian/compat
[23:02] <slangasek> dh_clean: This package will soon FTBFS; time to fix it!
[23:02] <slangasek> wow
[23:02] <slangasek> what have I gotten myself into
[23:02] <infinity> No compat?  Seriously?
[23:02] <slangasek> well, DH_COMPAT=5 in debian/rules
[23:02] <slangasek> so it's one of Those
[23:16] <slangasek> ScottK: python-pam hasn't had a new upstream version since 1999, nor a Debian maintainer upload since 2007, and the packaging is quite ancient.  I'm happy to modernize the packaging but don't really want to be on the hook for maintaining it going forward; what would you recommend?
[23:17] <slangasek> (would be happy for it to go away under the circumstances, but python-twisted-core wants it)
[23:22] <RAOF> Hm. When I copied utouch-geis out of precise-proposed I should have also copied it to quantal, but didn't. Is there an existing tool to sync from precise-updates to quantal?
[23:22] <slangasek> RAOF: there are tools... but I may be using one that's deprecated since it's on cocoplum ;P  which one are you using?
[23:23] <RAOF> I'm not currently using one; I'm looking for one :)
[23:23] <RAOF> (Or, rather, I *used* sru-release for the copy from precise-proposed to -updates, but forgot to add the --devel switch)
[23:27] <stgraber> RAOF: maybe something like that from lp-shell will do it: http://paste.ubuntu.com/1005675/
[23:33] <RAOF> Or maybe something like that will OOPS on launchpad with a timeout :)
[23:33] <RAOF> Thanks, though.
[23:36] <slangasek> RAOF: I can run a copy-package for you now
[23:36] <RAOF> slangasek: That'd be good, thanks.
[23:36] <slangasek> though, we're well past the point in the cycle at which anyone should be uploading to -proposed and expecting us to copy to quantal
[23:37] <slangasek> next time this happens, we ought to make it the uploader's problem... :)
[23:37] <RAOF> This was uploaded to precise-updates before the precise release; it's only just been verified.
[23:37] <slangasek> ah
[23:37] <RAOF> That said... there doesn't seem to be any particularly good reason to wait for it to be verified before copying it from precise-proposed to quantal.
[23:38] <slangasek> true
[23:38] <stgraber> RAOF: oh, well, that probably means that it was the right call, just got into the usual LP timeout on package copy :)
[23:39] <RAOF> It *does* have about 4 bugs attached; that might bring poor little launchpad to its knees :)
[23:39] <slangasek> RAOF: my point is, though, that we're well into the cycle now and we should be getting stuff rebuilt with the quantal toolchain / lib deps
[23:40] <slangasek> so should make people reupload to quantal anyway
[23:40] <slangasek> (so that the SRU team doesn't have to do a bunch of work to make a determination of whether it's safe to copy, that takes us more time than it would take to just reupload it)
[23:41] <slangasek> anyway - copied now
[23:48] <RAOF> Thanks.