=== RAOF_ is now known as RAOF
[00:42] <cjwatson> perlqt LGTM
[01:21] <slangasek> bdmurray: I think I have the cryptsetup fix.... it's a 'udevadm settle' before 'dmsetup rename' :P
[01:27] <slangasek> bdmurray: I can't be 100% sure I've caught it since it's racy... care to give lp:~vorlon/cryptsetup/lp.874774 a try on your machine?
[02:16] <cjwatson> slangasek: when you get a moment (no rush, I'm off to bed), what do you think of my analysis of bug 979661?  I'm not entirely convinced that the libc6/libnih1 pre-depends resolution bug is in fact the same as bug 850264, although that was the primary symptom that dupondje presented with earlier and you said that that was his bug
[02:16] <ubot2> Launchpad bug 979661 in update-manager "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [High,New] https://launchpad.net/bugs/979661
[02:16] <ubot2> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix released] https://launchpad.net/bugs/850264
[02:17] <slangasek> cjwatson: that's not the bug number of the libc6/libnih1 issue, is it?
[02:18] <slangasek> so my analysis that it was the same issue was based on the logs attached to the bug... whichever one it was now
[02:19] <slangasek> bug 946709
[02:19] <ubot2> Launchpad bug 946709 in update-manager "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle." (dup-of: 850264)" [Undecided,Confirmed] https://launchpad.net/bugs/946709
[02:19] <ubot2> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix released] https://launchpad.net/bugs/850264
[02:19] <slangasek> I quoted the relevant of apt.log in the bug
[02:20] <slangasek> I certainly didn't think the debconf frontend issue was related :)
[02:20] <cjwatson> ah, I think this is a bit different, because in that case apt is refusing to do the operation at all; in this case, it's doing it but getting the ordering wrong
[02:20] <cjwatson> (ignoring the debconf warnings for a moment, you can see it failing to unpack libnih1)
[02:21] <cjwatson> ok, so not dupondje's bug
[02:21] <slangasek> right
[02:21] <cjwatson> but nasty; do you happen to know of a bug for this bit/
[02:21] <cjwatson> ?
[02:21] <cjwatson> I couldn't find one in a quick changelog trawl
[02:22] <slangasek> no, don't think I'd seen this one before
[02:22] <cjwatson> unless it's the giant unpack/configure ordering rearrangemnet
[02:23] <cjwatson> it wouldn't totally surprise me
[02:23] <slangasek> yeah... that would be no fun
[02:24] <cjwatson> things that are hard to SRU, #43
[02:25] <cjwatson> oh, wait, maybe I'm wrong
[02:25] <cjwatson> it says "Configuring libc6:amd64", so maybe the debconf confusion caused that to fail
[02:26] <cjwatson> and that's before it unpacks libnih1
[02:26] <cjwatson> OK, false alarm
[02:27]  * cjwatson -> bed, since I think my analytical abilities are fading
[02:27] <slangasek> :)
[02:28] <slangasek> night
[02:36]  * ScottK ^^^
[02:37] <ScottK> I'll look at muon in a moment too.
[03:07] <wgrant> cjwatson: It's been back for a while now. LVM decided to hang a couple of times, it seems.
[03:55] <slangasek> ^^ that cryptsetup fixes bug #874774, I believe
[03:55] <ubot2> Launchpad bug 874774 in cryptsetup "could not mount /dev/mapper/cryptswap1" [High,Fix committed] https://launchpad.net/bugs/874774
[04:00] <infinity> Ahh, udevadm settle, the new sleep.
[04:01] <infinity> Accepting on "I can't see how it can be worse" grounds.
[04:04]  * infinity tries to decide what to do with doko's gdb upload...
[04:09] <slangasek> infinity: it's much better than sleep, when used correctly :)
[04:10] <infinity> That's true of a lot of things.
[04:10] <slangasek> heh
[04:12] <slangasek> the only way to improve on udevadm settle here would be an interface that lets us wait for a *specific* event to finish processing... and that would be unwieldly
[04:12] <slangasek> infinity: so how goes the compiling?
[04:13] <infinity> slangasek: Nothing's exploded yet?
[04:14] <infinity> GCC seems happy, eglibc's building, at which point, I expect to discover I did something dumb.
[04:14] <infinity> Because I'm a pessimist.
[04:14] <slangasek> assuming it continues not exploding, what's the ETA to an upload?
[04:15] <infinity> It'll be done by the end of the weekend for sure, but if everything goes smoothly, I expect tomorrow.
[04:15] <slangasek> ok
[04:15] <slangasek> I'm out all day tomorrow and won't be able to help pushing it in
[04:16] <infinity> Turns out that you're not the only Release/Archive dude that doesn't understand "core hours".  I'm sure I can find some reviews. ;)
[04:17] <slangasek> ;)
[04:17] <slangasek> just letting you know not to expect me :P
[04:18] <infinity> Oh, crap.
[04:18] <infinity> Hrm.
[04:18] <infinity> dpkg-shlibdeps is about to outsmart me.
[04:20] <infinity> slangasek: It's entirely possible that, short of not shipping .symbols files, I might not be able to represent the ABI break in the PI move.
[04:22] <slangasek> this is sounding familiar
[04:23] <slangasek> how are you doing the override?
[04:24] <infinity> slangasek: Override isn't the issue, the .shlibs file is correct.
[04:24] <infinity> slangasek: It's that dpkg-shlibdeps prefers .symbols, if present.
[04:24] <infinity> slangasek: And some packages (like, uhm, gcc), only use symbols from 2.11 and earlier, apparently. :P
[04:25] <infinity> But, maybe there's a way for me to represent the PI itself in the symbols file.
[04:25] <slangasek> right... but if the package uses dpkg-gensymbols (perhaps via dh_makeshlibs), the symbols file in the binary is a munging of the .shlibs and the sourceful symbols, I think?
[04:26] <slangasek> ld-linux.so.3 #PACKAGE# #MINVER#
[04:26] <slangasek> that #MINVER# token can be replaced directly, IIRC?
[04:27] <infinity> That doesn't seem to be replaced by anything on build...
[04:27] <slangasek> no - but you can manually replace it
[04:27] <slangasek> in the source
[04:27] <infinity> Oh, sure.  Will that be enough to fake out dpkg-shlibdeps?
[04:28] <infinity> I guess I can find out with a minimal hello or something.
[04:28] <slangasek> I believe so
[04:28] <infinity> In that case, I don't even need to muck with shlibs versions, which would be much cleaer.
[04:28] <infinity> cleaner, too.
[04:29]  * infinity sets about doing some manual testing.
[04:29] <infinity> Depends: libc6 (>= 2.4), dpkg (>= 1.15.4) | install-info
[04:29] <infinity> Looks like a good candidate.
[04:29] <slangasek> the alternative would be to artificially bump the dependency for some of the symbols in the PI (probably the symbol-version-symbols)
[04:30] <slangasek> either way, it needs fixed in the .symbols, yes
[04:32] <infinity> Do dee do...
[04:41] <infinity> Oh, I found my oops.  Carrying on.  Nothing to see hre.
[04:41] <infinity> Nor here.
[05:21]  * infinity blinks.
[05:21] <slangasek> don't mind the rejects
[05:21] <slangasek> :)
[05:22] <infinity> Oh, I mind.
[05:22] <infinity> http://www.youtube.com/watch?v=92IkddsjtAA <-- I mind this much.
[05:23] <slangasek> heh
=== robbiew1 is now known as robbiew
[05:25]  * infinity wonders if he might be able to find time in the next week to heroically fix dpkg-divert --rename --package
[05:25] <infinity> Not that it does us any good right now if I do, but at least then it would be fixed pre-release in an LTS, which bodes well for transitiony things.
=== doko_ is now known as doko
[13:47] <cjwatson> excellent, powerpc has cleared
[14:23] <doko> and the rebuild is finally finished on x86 too
[15:05] <stgraber> I just requested an ldm sync (not shown by queuebot as it was down), that's for the ldm bugfix I mentioned in my e-mail to the release mailing list and during the meeting
[15:06] <stgraber> The diff should be fairly easy to review and from my point of view is all bugfixes, including the one for the typo breaking OpenGL on thin clients (that we really want for release)
[15:06] <stgraber> let me know if you have any question
[15:59] <cjwatson> slangasek: I've moved bug 848915 to rls-p-nottracking; rationale in the bug
[15:59] <ubot2> Launchpad bug 848915 in ubuntu-release-notes "$DISPLAY not set in some cases, resulting in cryptic traceback" [Undecided,Fix released] https://launchpad.net/bugs/848915
[17:31] <slangasek> cjwatson: ok
[17:37] <cjwatson> stgraber: ldm LGTM; accepted
[17:49]  * cjwatson copies gnome-shell, which has finished building in -proposed
[17:49] <cjwatson> ps3-kboot fixes the last powerpc-only build failure in main
[17:50] <cjwatson> entertaining race there - I accepted gnome-shell shortly before the bot finished processing it, which I think is what caused it to say "3.4.0-0ubuntu3 => 3.4.0-0ubuntu3"
[17:51] <doko> could somebody review the two outstanding python2.6 issues? plus the zope2.12 removal request?
[17:53] <cjwatson> pygobject-2 is fine
[17:54] <cjwatson> python-stdlib-extensions is fine
[17:55] <cjwatson> out of time for the removal request though
[17:55] <cjwatson> (I mean I need to go and do other things rather than sitting aimlessly in front of the computer :-) )
[17:55] <slangasek> that's an apt SRU we'll want in before release, one of two package manager bugfixes wanted for a clean multiarch upgrade for oneiric->precise
[17:56] <doko> ok, thanks, afk for the evening
[17:56] <slangasek> if there's an SRU team member around to approve it who *isn't* overdue for some afk R&R ;)
[18:52] <gotwig> hey
[18:52] <gotwig> SpamapS: hey there
[18:52] <gotwig> Streamstormer: dont have much; have you read my mail; do you know the problem?
[18:52]  * gotwig does not have much time
[18:53] <Streamstormer> gotwig, sorry what do you mean?
[18:53] <gotwig> Streamstormer: sorry.. wrong guy :X
[18:53] <gotwig> SpamapS: dont have much; have you read my mail; do you know the problem?
[18:53] <Streamstormer> gotwig, ok np
=== bulldog98_ is now known as bulldog98
[19:40] <stgraber> cjwatson: thanks
[20:03]  * ScottK ^^^
[20:19]  * ScottK took care of node too.
[20:28] <Laney> wdyt to opennebula? bug #959087
[20:28] <ubot2> Launchpad bug 959087 in ubiquity "with the newly burned cd-r it crashed in the same way as the last time (dup-of: 892846)" [Undecided,New] https://launchpad.net/bugs/959087
[20:28] <ubot2> Launchpad bug 892846 in ubiquity "ubiquity crash during installation after failed grub install" [Undecided,Confirmed] https://launchpad.net/bugs/892846
[20:28] <Laney> erm
[20:29] <Laney> bug #959097
[20:29] <ubot2> Launchpad bug 959097 in opennebula "FFe: Sync opennebula 3.2.1-2 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/959097
[20:31] <ScottK> I was just reading the bug and hoping you would decide.
[20:32] <Laney> the diff is huge
[20:32] <Laney> but we might be against the wall with the refusal of support thing
[20:34] <ScottK> It's probably better to lean forward than back in such cases.
[20:36] <Laney> done.
[20:37]  * ScottK just said no to distro-info.
[20:37] <ScottK> "nice to have" and "final freeze" don't mix.
[21:28]  * ScottK took care of ^^^
[21:49] <cjwatson> ^- fixes last NBS entry
[21:51] <stgraber> I'll have a look as soon as I get a diff from LP
[21:53] <stgraber> cjwatson: looks good, feel free to accept
[21:54] <cjwatson> done, thanks
[22:12]  * ScottK accepted ps3-kboot too.
[22:51] <ScottK> ^^^ fixes a high impact bug for UbuntuOne.  I'd appreciate it if someone would review/accept.  Then we can get it built/tested and decide if it ends up in -release or -updates.
=== bulldog98_ is now known as bulldog98
[22:59] <infinity> ScottK: Looking.
[23:00] <infinity> Or, will in a bit.
[23:00] <ScottK> infinity: Thanks.  Diff is from upstream.
[23:06] <infinity> ScottK: Patches that remove copyright notices are kinda uncool (unless Phil works for Riverbank, and he just got the attribution wrong the first time?)
[23:06] <ScottK> infinity: He does.
[23:06] <infinity> Kay.
[23:07] <ScottK> He's been gradually changing them from his name to the company's as he touches files.
[23:09] <infinity> This sort of implies this is non-deterministic...
[23:14] <ScottK> It is.  But since he's both the guy doing the work for Riverbank and an employee of Riverbank it doesn't make much difference.
[23:15] <infinity> ScottK: I meant the patch, not the copyright notice. :P
[23:15] <ScottK> Oh.
[23:15] <ScottK> That too.
[23:16] <infinity> ScottK: I'd have to hunt down what dbus_watch_handle() actually does, but I'm concerned that it might "sometimes" kill the socket?
[23:16] <ScottK> It was only failing ~a third of the time.
[23:16] <infinity> Or, more likely, this is trying to close an external threading race with... A slightly smaller race window.
[23:16]  * infinity shrugs.
[23:17] <ScottK> There's a reduced test case in the bug if you want to investigate.
[23:17] <infinity> It's not any more broken than it was before.
[23:17] <infinity> I guess that's all I can hope for from upstreams.
[23:17] <ScottK> ;-)
[23:17] <ScottK> One day turn-around was nice too.
[23:17] <infinity> I have no interest whatsoever in looking into it more, no.  I'm currently fighting with making ld.so rewrite SONAMEs on the fly.
[23:17] <infinity> But yeah, this looks a lot like someone just trying to close a race window.
[23:18] <infinity> Which, like I said, isn't more broken than it was, and given dbus lag, probably makes it look "fixed" most of the time.
[23:18] <infinity> So, whatever. :P
=== yofel_ is now known as yofel
[23:26] <ScottK> Thanks