[00:08] <hallyn> anyone around who would considering pushing https://code.launchpad.net/~psusi/ubuntu/precise/lm-sensors/merge/+merge/85044 ?  I don't  have perms to dput it.
[00:19] <broder> hallyn: i'm hoping to have time to try and improve that upgrade path during my holiday break
[00:45] <hallyn> broder: for schroot?  cool - it's no big deal if documented, just took me awhiel (and looking through a patch you sent to debian :) to figure out where to tweak
[00:46] <hallyn> the subdirs under /etc confounded me :)  i was grepping in /etc/*
[01:54] <elky> anyone heard from lifeless & other christchurch people in the past hour? there's been another big quake there :(
[02:01] <bilal> iHate changing nicks, but this is going to be my nick from now onwards. Plain and simple
[02:04] <bryceh> elky, "only" 5.8 this time, hopefully only modest damage and no casualties
[02:04] <bryceh> bilal, nice
[02:06] <elky> bryceh, yeah, so far no reports of toppled buildings or death, but there has been reports of injury and cracking and liquefaction. Merry christmas, christchurch :(
[02:06] <ajmitch> great way to finish the year
[02:13] <elky> ajmitch, yeah
[02:20] <RAOF> :(
[02:24] <ScottK> And ross is dead again.
[02:24] <ScottK> powerpc may never catch up.
[02:25] <ScottK> infinity: Any idea what's up with it (dunno if you can still look into such things)?
[02:25] <ScottK> At least the third time today it's died.
[02:27] <infinity> ScottK: I can't, no.  Gave up that access.
[02:27] <infinity> ScottK: I know people have been notified, however.
[02:27] <ScottK> Thanks.
[02:40] <infinity> ScottK: ross lives.  Of course, the firefox build that killed it might take out adare soon. ;)
[02:41] <ScottK> It's been that same build it died on at least two of the times.
[02:41] <ScottK> Of course it's a long build, so it may just be coincidence.
[02:41]  * infinity nods.
[02:42] <infinity> I suspect the Xserves will be infinitely happier when we can upgrade them to precise.
[02:42] <infinity> The older kernels we left them on weren't the happiest of pandas, if I recall.
[02:42] <infinity> At least, back when the machines were "mine".
[02:43] <infinity> Oh, no, I'm living in the past.  They're lucid now.
[02:43] <infinity> It was hardy that they skipped.
[02:44] <ScottK> Yep
[02:44] <ScottK> IIRC they ran Karmic for a little while.
[03:05] <psusi> doko_, in xmlrpc-c (1.16.32-0ubuntu2) you wrote: * Don't use the symbols files, renamed the library packages anyway.  I assume this means you renamed the binary package to have -0 in the name.  Why?  I'm trying to install boxee and it depends on the non -0 version.  Is there an abi breakage, or could adding a provides: for the non -0 fix this?
[03:10] <ScottK> Which is preferred (it seems they both work fine): (qreal)foo or qreal(foo)?
[03:10] <psusi> ScottK, you talking about casting in C++?
[03:10] <ScottK> yes.
[03:10] <ScottK> Sorry.
[03:11] <psusi> well, the former works in C as well, in C++, I think the specific {static,dynamic}_cast<> is preferred
[03:11] <psusi> technically the latter form instantiates a new temporary
[03:12] <ScottK> For Qt qreal is a double on all archs except armel/armhf so it's quite common for people to interleave doubles and qreals when they shouldn't.
[03:17] <infinity> psusi: I'm not sure if there was an ABI break, but the package should have the SOVER in the name regardless.  Can boxee not be rebuilt to get the correct dep?
[03:18] <infinity> psusi: Oh, it's proprietary.  Yay.
[03:18] <psusi> infinity, right.. so if there wasn't an actual abi breakage, adding a provides: for the old incorrect soname should fix things right?
[03:18] <infinity> psusi: If.  You might want to check that.
[03:19] <infinity> It's still "wrong" from a "packaging libraries correctly" standpoint, but...
[03:19] <infinity> psusi: On the other hand, if doko had to disable checksymbols, that sort of points to ABI breakage.
[03:20] <hallyn> @pilot out
[04:51] <micahg> infinity: just noticed that libsmbclient doesn't have a SONAME in the package either
[05:38] <jk-> anyone know how the ubuntu core images are built? is it just a debootstrap?
[06:18] <infinity> jk-: It's essentially debootstrap --variant=minbase at the moment.
[06:19] <jk-> infinity: awesome, thanks.
[08:03] <dholbach> good morning
[09:18] <micahg> infinity: can I get you to copy firefox (lucid/maverick) from ubuntu-security-proposed to {lucid,maverick}-proposed?
[11:12] <bdrung> tumbleweed: it seems that we have to live with the broken dh_install. do you have the patch for wrap-and-sort for me?
[11:15] <tumbleweed> bdrung: :/ http://paste.debian.net/150005/
[11:16] <bdrung> tumbleweed: do you have a commit message for that change?
[11:44] <tumbleweed> bdrung: no, I hadn't committed it locally
[12:44] <bdrung> tumbleweed: pushed slightly modified
[14:02] <Laney> doko_: do you know if that kernel fix is going to be deployed to the buildds any time soon?
[14:03] <doko> Laney, I assume first week of Jan, there's nobody around now, but the kernels are in -proposed and can age
[14:03] <Laney> great
[14:04] <Laney> wfm
[14:04] <doko> and they are already tested
[15:11] <mdeslaur> doko: hi! any idea why this could be happening? (unbound FTBFS on oneiric) http://paste.ubuntu.com/779905/
[15:11] <mdeslaur> doko: line 6301+
[15:11] <mdeslaur> doko: same package build fine on precise, and precise's package doesn't build on oneiric
[15:12] <doko> mdeslaur, configure:14781: checking python extra libraries
[15:12] <doko> configure:14788: result: -lssl -lcrypto  -lssl -lcrypto      -L/usr/lib -lz -lpthread -ldl  -lutil
[15:12] <doko> but then not linking with these ...
[15:13] <mdeslaur> yeah, I tried adding -lssl -lcrypto...but I didn't add the other...thanks, I'll give it a try
[15:14] <doko> mdeslaur, hmm, it shouldn't be necessary, the conftest.c doesn't use any of these
[15:15] <doko> mdeslaur, does it work without -flto?
[15:15] <mdeslaur> doko: let me check
[15:16] <doko> mdeslaur, is this oneiric-security?
[15:17] <mdeslaur> doko: yes, but I tried building with -updates too
[15:17] <doko> hmm, it should be fixed in binutils from oneiric-updates
[15:17] <mdeslaur> oh, interesting...ok, I'll try it again with -updates
[15:18] <mdeslaur> thanks doko
[15:29] <mdeslaur> doko: binutils worked, thanks!
[15:47] <doko> mdeslaur, so maybe copy it to the -security pocket?
[15:47] <mdeslaur> doko: yeah, I'm rebuilding it in -security now so we don't hit it again
[15:55] <Riddell> sladen: guy on ubuntu-users asked for monospace fonts, you may want to check if he's tried ubuntu mono
[16:02] <doko> Riddell, according to NBS, a kdevelop upload is missing ;)
[16:21] <Riddell> doko: I'll try a rebuild locally and upload
[18:17] <ScottK> doko: KDE core is now fully built on armhf in the archive.
[19:21] <roadmr> SRU question. I need to re-submit an SRU that needs some code added and some removed. Should I prepare a new branch to be merged against the oneiric branch (replacing the first one), or just request a merge on the oneiric-proposed branch with the modified code?
[19:22]  * roadmr wonders if the question is understandable
[19:22] <micahg> roadmr: #ubuntu-devel or #ubuntu-motu would be better for this, but oneiric-proposed would be the place to propose a merge to
[19:23] <roadmr> micahg: ok.
[19:23] <roadmr> micahg: btw, thanks! you're always answering my dumb SRU questions, you must hate me by now :)
[19:23] <micahg> roadmr: oops, you're in the right channel :)
[19:23] <micahg> roadmr: I'm used to seeing  you in #ubuntu-bugs
[19:24] <roadmr> micahg: hehe well sorry if I've been asking devel stuff in -bugs, too many channels! argh
[19:24] <micahg> roadmr: there are no dumb questions :), we're all learning
[19:26] <roadmr> micahg: ok so I'll branch the current oneiric-proposed, prepare my fixes and request a merge on that
[19:27] <micahg> roadmr: branching for the first SRU from the release branch is only out of necessity since the -proposed branch doesn't exist until the first SRU is uploaded
[19:28] <roadmr> micahg: oh I see, well that makes sense - and subsequent SRUs, if needed, would go to -proposed then?
[19:28] <micahg> roadmr: right
[19:28] <roadmr> awesome :) thanks
[19:29] <micahg> roadmr: just keep in mind, if there's a security update, you'll need to branch from -updates or -security to get the full history (sometimes you might have to rebase -proposed onto security if the security team is forced to drop a fix in their upload)
[19:30] <roadmr> micahg: ok, I'll be careful with that if the need arises
[20:59] <infinity> micahg: Done.
[21:00] <micahg> infinity: ooh, thanks :)
[21:05] <micahg> infinity: can you copy {firefox,mozvoikko,ubufox}/natty from ubuntu-mozilla-security to natty-proposed please?
[21:13] <infinity> micahg: Done, done, and done.
[21:13] <micahg> infinity: thanks :)
[21:26] <micahg> infinity: can we copy for oneiric and permakill the powerpc firefox build before it hangs the buildd
[21:30] <micahg> infinity: I don't want to risk hanging one of the powerpc buildds over the weekend, so if we can't, then we'll wait until monday
[21:31] <Laney> does it hang 100% of the time on ppc?
[21:32] <micahg> Laney: ATM, it seems to, we're disabling the tests which should in theory "resolve" the issue, but I don't want to test that w/out a safety net (i.e. someone to push the power button) either
[21:35] <Laney> ah OK. I was going to suggest p-a-sing it at least for the buildds' sake, and investigating why it builds for Debian but not us.
[21:35] <micahg> oh, i don't know if Debian's running the tests, I got the FTBFS fix from them
[21:39] <Laney> I am trying to see but the build log killed my firefox :-)
[21:40] <micahg> can I use p-a-s on a stable release?
[21:41] <Laney> infinity knows
[22:00] <micahg> infinity: if you get a chance and you can permakill the powerpc build, please copy {firefox,mozvoikko,ubufox}/oneiric from ubuntu-mozilla-security to oneiric-proposed, if not, don't worry about it, I"ll look into it Monday
[22:00]  * micahg has to run