[00:03] cjwatson: dmraid> doesn't the to_cpu() function need updated to also handle conversion of the total_secs_h field? [00:05] slangasek: no, because it's only one byte [00:05] oh [00:05] so it is :) [00:06] parted,dmraid accepted [00:07] Very scary. [00:08] I ust accepted zope.html, which was right next to dmraid on the list and then say dmraid building. [00:08] ust/just [00:08] say/saw [00:08] Urgh. [00:09] timing's fun [00:09] :-) [00:29] urgh, maybe I should have test-built dmraid :-/ [00:30] * cjwatson fixes [00:49] score [00:49] slangasek: sanity-check on http://paste.ubuntu.com/585685/ ? [00:50] slangasek: it does mean that libraries installed to multiarch directories in the initramfs will also be collapsed to /lib or /usr/lib; but I can't think of a neater way to do it [00:50] cjwatson: multiarch directories shouldn't need ld.so.conf to work, actually? [00:50] no, but I have /etc/ld.so.conf/i686-linux-gnu.conf here [00:51] the ld.so.conf snippets are for the benefit of ldconfig (so everything gets into the cache, not just the stuff for the native arch), and for other tools that are naughty and parse ld.so.conf themselves [00:51] I'm hoping to avoid special-casing libGL here [00:51] which lands in /usr/lib/mesa/libGL.so.1, which *does* require ld.so.conf [00:51] ok, if this is for libGL's benefit, sure [00:51] that's the actual problem [00:51] wasn't sure if we were still on the same topic :) [00:51] oh, yeah, should have clarified since this was a few logical steps along [00:51] yeah, LGTM [00:51] great [00:52] I tried to get ldconfig working but I think it's a doomed endeavour [00:54] yeah, and it seems rather unnecessary in the context of an initramfs [00:56] quite (though it might make it a bit faster, possibly) [00:56] fractionally [00:56] jdstrand: to keep you in the loop given this morning's meeting discussion, I currently have a list of 14 library packages in main that need to be fixed up due to broken .la references to .la files moved by multiarch; I expect to have these all fixed over the weekend [00:57] (they could all be "fixed" with a no-change rebuild, but I'm fixing them harder) [00:58] that's the last set of breakages (in main) that I'm aware of from multiarch [00:58] (I haven't pulled a list of affected packages for universe yet, I'll do that afterwards) [00:59] doko_: do you want binutils fixed before doing the archive rebuild? I don't think binutils' view of the linker path should affect main, but ICBW [00:59] slangasek: I would like to [00:59] ok [00:59] trying to get something tomorrow or Sunday [01:26] I've accepted everything in the queue I was comfortable with accepting. [01:26] Either I need more uploads or it's someone else's turn. [01:27] please accept bzr (component mismatch, no functional change, just running the tests sequentially) [01:28] I was going to look at bzr, but my mirror job is hammering my bandwidth and I can't tell whether that's why queuediff is refusing to show me a diff yet or not; in any case I ought to sleep [01:28] if it's still there tomorrow I'll look at it [01:32] ubuntu-release, please have a look at bug #730759, that would be the last component mismatch [01:32] Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) (and 1 other project) "[MIR] b-d for libffado (affects: 1) (heat: 18)" [High,New] https://launchpad.net/bugs/730759 [01:33] I'm still uploading libs, I'll have a look at the queue once I'm done there :) [01:35] If only LP made diffs faster ... [01:41] slangasek: Can you upload libmusicbrainz to Debian? It's QA maintained, so if you upload the change we can just sync later and there's no diff to maintain. [01:42] ScottK: yes, I've uploaded there as well, but given the number of libs I'm having to upload I didn't want to wait for it to publish to Debian before getting it into Ubuntu [01:43] (especially since the Debian publisher is on manual this week for the ftp-master sprint) [01:43] Agreed. Thus the later in my comment. [01:43] ok [01:43] yes, I'm forwarding all of these directly to Debian, either bug report or QA upload === doko__ is now known as doko [10:24] for general reference, I'm not going to accept syncpackage uploads for beta-1 [10:24] if people want to have syncs performed, they can do it the standard way; syncpackage doesn't even let me see who asked for the sync at the Ubuntu end [10:24] (aview, bbrun) [10:24] (papaya) [10:39] rejected the syncpackage uploads [10:39] and I've written an explanatory mail to -devel [11:07] ^ this is the 'figure out what went wrong' upload [11:27] accepted === nigelb_ is now known as nigelb [14:28] cjwatson: +1 on the -1 for syncpackage during freeze. === GrueMaster_ is now known as GrueMaster [15:32] Indeed. I'm quite impressed how many people still use syncpackage. [15:34] Syncs get processed a lot faster these days, so I think people are making present virtue out of past necessity. [15:35] cjwatson: Apparently you've just filled two separate bugs for the same package. squashfs-tools 1:4.2-1. Would you like me to fix that for you? [15:35] ScottK: Yea... [15:43] cjwatson: 1:4.2-1 looks good to me but I wouldn't mind if someone else takes another quick look at it, just to be sure that I haven't missed something important. [15:46] ScottK: I agree with you here but the thing is that they know that syncs get processed faster these days and honestly this bothers me a bit. [15:46] I think some of it's habit, some of it is it's cooler/more fun to upload than to file a bug. [15:46] If we get syncs in LP, then I think that will go away. [15:47] iulian: If there's stuff in the queue you're ready to accept, just ping me and I'll be glad to push the button for you. [15:47] (although speak fast for the moment as I'll be offline for awhile in ~10 muntes. [15:47] ) [15:48] ScottK: Hopefully it will go away, yes. [15:49] I've got nothing now for you. Maybe later on. Thanks, appreciate it. [15:49] OK. [17:07] hi, could someone please take a look at bug #669211? if that issue isn't fixed, you're going to release a completely broken xpdf package with natty. btw i'm the debian xpdf maintainer. [17:07] Launchpad bug 669211 in xpdf (Ubuntu) "Xpdf segfaults on start in libpoppler.so.7 (affects: 13) (dups: 3) (heat: 96)" [Medium,Confirmed] https://launchpad.net/bugs/669211 [17:20] iulian: hmm, requestsync raised an exception and it wasn't visible when I looked in the web interface so I filed it by hand [17:20] iulian: if you could fix that'd be great, thanks [17:42] cjwatson: Fixed. [17:58] zsync ed the images today, Ubuntu natty-alternate-i386.iso shows 679MB on the server, but synced to 705MB on my system [17:58] Do I need to do a full download to get the size down locally? [18:00] charlie-tca: #ubuntu-testing might be a better place for that question. [18:01] Okay, I was just hoping it is not an error at the server [18:02] ^^^ is my upload, so I won't be reviewing it ... [18:06] iulian: ta [18:10] * slangasek looks at kdegames [18:13] ScottK: no changes needed to debian/rules to compensate for the opengl build-dep going away? [18:14] (e.g., have you tested that removing libqt4-opengl-dev and building with -d works on x86?) [18:14] slangasek: No. It's all automagically detected in CMake. I tested on armel. [18:14] ok [18:14] accepted [18:14] Thanks. [18:19] slangasek: Avogadro is going to take some surgery to fix on armel. Not sure if you've got someone who can look into it or not, but the chances of kubuntu-dev fixing it are ~nil. [18:19] (unless I completely misunderstood the situation with it, which is also a possibliity) [18:20] ack, assigning someone to it now [18:20] Thanks. [18:42] armel builders appear to be dieing like flies. [18:47] :/ [18:50] Fortunately the backlog is small, so I think we'll be OK until lamont can wave his magic wand at them. [18:52] Oh, fun from your libisofs upload yesterday: libisofs/make_isohybrid_mbr.c:446:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17274 [19:03] yes, bug #742961 [19:03] Launchpad bug 742961 in libisofs (Ubuntu) (and 2 other projects) "libisofs ftbfs on armel with current gcc-4.5 (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/742961 [19:36] please reject my upload of vlc: it is useless [19:42] OK [19:42] fabrice_sp: Done. [19:48] ScottK, thanks [21:06] ScottK: yeah - I'm about to smack 'em [21:08] adoxaceae|UNK|False|True|False|Non-virtual builder in ABORTED state, requires admin to restart [21:08] * lamont sighs [21:09] * lamont restarts launchpad-buildd on 5 otherwise-idle builders [21:10] ScottK: so the real question that I'm ignoring for the weekend: which build is it that's hitting them hard enough to make buildd-master go ZOMG I GIVE UP and mark them dead? [21:11] interestingly, all 5 have been up for 4 days, 1 hour 22 minutes. [21:11] Like since the last time this happened... [21:11] nah, that's when I rebooted them all for new kernels [21:11] Oh. [21:14] this is what happens when a build has a in-memory footprint of 2+GB and a total of 512MB of RAM in which to work [21:15] My arm box has a SDcard just for swap. [21:15] and yeah, when I glanced at the machines this morning, there was a fairly short queue, so I didn't bother before running off with kids for many hours [21:15] It's slower, but it doesn't die. [21:15] 30GB of the USB drive is swap, the rest of it is / [21:15] Ah. [21:16] that was from the "tired now" school of swap design [21:16] Heh. [21:22] and never mind that a process can't address more than 2GB of userspace memory on those kernels. :) [21:23] slangasek: that 2GB+ footprint is generally somewhere between 50 and (yes) 200 processes [21:23] heh [21:28] because, I mean, what's wrong with make -j, or make -j $undefined_variable ? [21:28] though to be fair, the normal culprit seems to be java stress tests [21:36] Sounds like a reasonable candidate for a mbf in Debian if there's a reasonable way to detect such cases.