[04:02] ^^^ is my upload, so I'd appreciate some other archive admin reviewing/accepting. [04:12] Erm. [04:13] Now that we have multiarch, why not make an arch:all package that depends on the arch:ppc one? [04:13] Oh, I guess that's overkill. [04:14] Either way, I guess qemu and the like still can't depend on it. :/ [04:16] ScottK: Did you at least make it Multi-Arch: foreign, so I can install it? [04:17] Oh, I guess I can do that manually wihthout the M-A header, things just can't depend on it. [04:18] infinity: No. I just beat it into a arch dependent package that only builds on powerpc from an arch indep package that only builds on powerpc. [04:19] It's a shame it's GPL. :/ [04:19] If it was BSD, I'd just toss the binary blob in multiverse and call it done. [04:20] Anyhow, this situation is no worse than what we had before. [04:21] Before we had no binary at all. [04:21] ScottK: Have you downloaded the deb from the build and confirmed that qemu appears to like it in some meaningful way? [04:21] Yeah, hence no worse than before. :P [04:21] No. I haven't. I've assumed that it builds something useful since it does in Debian. I figured all I needed to do was trick it into building on LP. [04:23] It builds and there's some binary file in there is all I can tell you. [04:23] Heh. [04:24] I'm not sure how useful it is, unless people are really willing to turn on multiarch for one deb. [04:24] But meh. [04:24] Like I said, better than the previous situation. [04:26] Thanks. [04:28] doko_: Do you have a valid argument for the GDB upload in the queue? [04:30] doko_: Actually, on second though, I'm going to reject it so no one else accepts it, and you can argue the point later. :P [04:30] ScottK: Want to review a diff for me and have a bit of a cry? [04:30] ScottK: http://lucifer.0c3.net/~adconrad/eglibc.debdiff [04:31] As soon as I saw the package name, I knew there would be tears. [04:34] It seems not unreasonable, but I by no means feel comfortable with saying it's OK or not. Way over my head. [04:34] If it doesn't seem unreasonable, I think that's proof it's over your head, yes. ;) [04:35] But thanks for the vote of confidence. [04:35] Not unreasonable in that I suspect is does what you want. [04:35] That saws nothing about the reasonableness of what you want. [04:35] It appears to, yes. No kittens have died thus far. [04:35] Also, if some guy is going to be they guy that approved the upload that broke eglibc during final freeze, I do not want to be that guy. [04:36] ScottK: Wuss. ;) [04:36] I chickened out on approving the last openssl merge too. [04:42] sssss/ws 36 [04:42] gah [04:43] *slow clap* [04:52] infinity: What are computers? How do I use 'em? :) [04:52] Try not to pass out on the "s" key, and you'll be fine. [04:54] heh [04:58] infinity: ^^^ just makes the version numbers line up pretty. It turns out to affect the Kubuntu dvd, but I think we should do it anyway. Otherwise it's 5 years of "Why is python3 at 3.2.3~rc1 and python3.2 is at 3.2.3?" [05:00] Yeah, doko did the same for python-defaults, didn't he? [05:01] I was going to accept it as soon as I saw the diff. [05:01] He did. [05:01] (rather, as soon as I've reviewed it) [05:01] It won't take much longer to review it than to see it. [05:01] ScottK: You dropped the maintainer mangling in debian/control. [05:02] -Maintainer: Ubuntu Developers [05:02] -XSBC-Original-Maintainer: Matthias Klose [05:02] +Maintainer: Matthias Klose [05:04] It's suppose to do that automagically. [05:04] Hang on. [05:07] infinity: Found it. [05:07] I can't spell Ubuntu. Please reject that one. [05:07] Oh, hah. 0ubunu1 [05:08] I didn't even see that. [05:08] The maintainer magic did though. [05:08] I guess that's why we review them all at this stage. [05:08] New one is uploadded. [05:09] Every time I see something like that, I'm reminded that I want to revisit my pam_dwim module. [05:09] ;-) [05:09] Your scripts totally should have noticed and fixed the typo. [05:09] Just like a computer should log me in if my password is "close enough". [05:10] Picky things. [05:10] And not log someone else in on your account even if it's close, because that's not what you want. [05:10] That logic might be harder to write, but yeah. [05:12] pam_dwim would just try a few simple and common typo transpositions and home-row offsets and such before giving up, with a scaleable fuzziness level. [05:12] At sufficiently high fuzz levels, it'll offload to an opencl library and get your video card to log you in. [05:13] At one UDS, apachelogger_ had a facial recognition module for kdm working reasonably well. [05:14] Thanks. [05:15] I'd do facial rec for unlocking phones with front-facing cameras, except that it's so touchy. Not being able to log in because my face is partially in shadow, or I'm wearing a hat, could prove annoying. [05:16] Finished 1 minute ago (took 55.4 seconds) <--- buildds are getting faster, I guess. [05:16] Well, the i386 chroot is fresh, and sbuild no longer purges build-deps. [05:16] So, yeah. [05:16] Also, until it gets reliable enough to disable password access, it's a convenience thing, not a security feature. [05:16] On roseapple, we were seeing langpack builds in 20ish seconds after I landed that change. [05:16] Nice. [05:17] Well, okay, the chroot *was* fresh. [05:17] Silly people and their uploading. [05:18] Speaking of which, I see you cracked into the top ten uploaders this cycle. You've been a busy boy. [05:18] I've been slacking. [05:18] Didn't do a single transition... [05:19] Though, I still have time to do an fpc one. [05:19] But that's a tiny package set. [05:19] Doesn't it need bootstrapping on armhf? [05:20] IIRC, I only did one library transition and it had 3 rdepends. [05:20] Yes, hence the transition. [05:20] Ah. Right. [05:20] Since I'll be updating to 2.6.x at the same time. :P [05:20] Cause, hey, that's the sort of thing one does 1.5 weeks before release. [05:21] Looks like the only thing we'll be missing on armhf is gnat. [05:21] Meh. Universe. [05:21] Which is unfortunate, but we all just ran out of time to make it go. :/ [05:21] Well, ada's not hip and cool anyway. [05:21] If it had been haskell, people would have been upset about their pet language. [05:22] There was one discussion about if a package update had new features (and thus would need an FFe) and part of the conversation was "It's written in haskell, so it's hard to tell." [05:22] I only had 385 uploads in oneiric. [05:22] I *am* slacking. [05:23] Hahaha. Yeah. My friend's doing a haskell course at university right now, and I help him with his homework occasionally. [05:23] It's pretty much gibberish to me. [05:23] I'm not sure how many uploads I have but for Oneiric I was #5 on the uploaders list and this time I'm #26. [05:24] I have you at 641 for oneiric. [05:24] Where is this shiny list? [05:24] I'm just grepping -changes. :P [05:26] http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ [05:27] Oneiric was also the cycle where Riddell was on the bzr team, so I stepped up my game. $WORK was a bit slow too, which also helped. [05:28] Heh. [05:28] Colin totally cheated this cycle with transitions. [05:28] I demand half of his life-saver chunk be equally redistributed. [05:30] Man, you can so see when I moved from distro to IS... [05:30] #7 in breezy, #12 in dapper, then.. Gone. [05:30] Sad. [05:35] Looking back, I'm quite surprised. Feisty was the first release I was involved in development in and I made the top 50 despite not being a MOTU yet and not starting until halfway through the cycle. [05:35] That's not that surprising. [05:36] A) there weren't a lot of us, and B) even as we've expanded the ranks, a few really involved people always do most of the heavy lifting. [05:37] I'm a bit confused by my not showing up in hoary, though. [05:38] Gotta love these helpful debian/changelog entries, "Update packaging bits.". [05:38] ;) [05:38] meh, I was hoping for top 5 this cycle, but not making it for +1 maintenance threw that out the window [05:39] Oh, maybe I didn't start until the tail end of hoary. I suck at history. [05:40] micahg: There's more than enough unseeded Universe FTBFS to fix to resolve that concern. [05:41] micahg: I haven't uploaded much with a +1 maint hat on. [05:41] ScottK: I'm aware, the only thing I'm lacking is time [05:41] micahg: Also, what Scott said. Fix every FTBFS please. [05:41] infinity: that's why I still have more uploads than you :) [05:41] You have time right now! [05:41] infinity: yeah, I'm taking a look at a few things now [05:42] I used to look at my LP karma and go 'wow'. No I check it every now and then to make sure it hasn't gotten too high. [05:42] My LP karma sucks. [05:42] I should probably register and needlessly manipulate a blueprint every morning with my coffee. [05:43] I'm sure I could automate that. [05:43] It's hight than mine (which is good). [05:44] My current goal is to stay under 25K. [05:44] Yeah, but I only compare to doko and cjwatson. [05:44] * micahg would like to break 30k again, but that will require a bit of effort [05:45] * infinity would like to remove karma from LP. [05:45] Maybe I'll do that in my next commit, in the name of "every new line should remove two others". [05:46] No. How else would I know to go do something else for a few days? [05:46] Get a dog. [05:46] They're needy. [05:46] Got a dog. [05:46] Hrm. [05:46] It's very old and very needy. [05:46] Got kids too (3). [05:46] I'm stumped, then. [05:46] Also very needy and distracting. [05:47] The dog gave up and went to bed about two hours ago. [05:47] lobotomy? [05:47] If the amount of alcohol I consumed in my 20's didn't do it, I don't think so. [05:48] Could explain the KDE fetish, though. [05:49] That's purely what I started on. [05:49] Other stuff feels wrong. [05:49] That's how I explain my sexuality. [05:50] Gee. Look at the time. I should probably go get some sleep. [05:51] Hahaha. [05:51] G'night. ;) [05:51] (I win!) [05:51] I'm probably not being useful by staring at parallel glibc builds scrolling by, maybe I'll nap too. [05:55] ScottK: congrats on fixing openbios-ppc :) [05:56] * micahg wonders if we should SRU the fix [05:59] Nah. [05:59] People still need to do some hand-installing anyway. [06:00] So pointing them at the precise deb is just as easy. :P [06:01] I'm wondering if it might not be almost "saner" (for some messed up value of "sane") to just have all the openbios* stuff be downloader packages that grab the Debian version and unpack it. :P [06:01] micahg: If someone cares, they can ask for a backport. [06:01] Then we could still have sparc too. [06:01] And whatever other ones there may be. [09:57] can someone please retry libcomplearn in the rebuild? [10:07] micahg: Done. [10:08] infinity: thanks [10:30] * infinity thinks he's finally tracked down the last place(s) where the linker change will affect us. [10:31] Although, the d-i bit will need some trial and error to get right. [11:25] bug 982232 \o/ [11:25] Launchpad bug 982232 in yada "Please remove yada source and binaries as well as its reverse dependencies" [Wishlist,Confirmed] https://launchpad.net/bugs/982232 [11:31] micahg: Done. [11:32] infinity: awesome :), I at least met one of my release goals [11:32] Hahaha. [11:32] "Kill yada" has been an Ubuntu goal since our inception. [11:32] We got it out of main in a hurry, but... Today's a good day. [13:44] reminder to self: we should sync golang 2:1-5 once LP knows about it, to fix the armel build failure [14:00] cjwatson: Because disabling tests is always a winning notion. ;) [14:02] cjwatson: Say, want to eyeball a diff for me? I'm waiting for my laptop to have some spare CPU time to actually do a test build. :P [14:02] cjwatson: http://paste.ubuntu.com/931060/ [14:03] cjwatson: Err, context is bug #852101 [14:03] Launchpad bug 852101 in ia32-libs "32-bit applications do not start on 64" [High,Fix released] https://launchpad.net/bugs/852101 [14:25] at this point in the cycle, disabling tests may be all we have :-/ [14:25] infinity: LIBC is substituted? [14:26] True. And I'm trying my best to make sure people don't run armel anyway. :P [14:26] cjwatson: Yeah, is gets munged to the current package/pass. [14:26] /lib/ld-linux.so.2 won't ever be a dangling symlink? [14:26] I'd quote $(readlink -f /lib/ld-linux.so.2) because I'm paranoid [14:26] Heh. [14:27] also would be inclined to use rm -f but that's probably superstition [14:27] I tend never to force in maintainer scripts. [14:27] My theory is that if you're screwing with the package manager in ways that make root unable to do things, you've got bigger problems. [14:27] mm [14:28] And yeah, /lib/ld-linux.so.2 can end up dangling, which is why the elif nukes it. [14:28] Because libc6:i386 and libc6-i386:amd64 both ship it, and both replace each other. [14:29] but [ ! -f ] will pass on a dangling symlink so that ln -s could fail. [14:29] So, due to the fun of package takeovers, and then me cowboying the ln -s... [14:30] indeed, you could just [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ] rather than bothering with readlink; -f follows symlinks anyway [14:30] Oh, right. I forgot about that property of -f. [14:30] Is that POSIX? [14:31] yeah [14:31] derives from stat [14:31] Kay. I'll scrap the readlink, then. [14:31] I'm a bit perturbed that the two branches of the if leave the system in wildly different states [14:31] And change the first to a -h [14:31] not sure I quite understand it at this stage of caffeination [14:31] So, basically, it's combating two seperate issues: [14:32] 1) installing both libc6:i386 and libc6-i386 and then removing one will leave you with no ld.so [14:32] 2) One we fix (1) with the first if branch, we end up pooping a symlink on the filesystem that's no longer owned by any packages, once you remove both. [14:33] The proper solution for this would be a diversion, but a bug in dpkg-divert makes that infeasible. :P [14:34] (And I hope to fix said dpkg-divert bug before release, if I can find the time, so this code can go away in LTS+1 when we know we have a trustworthy dpkg on all upgrade paths) [14:35] cjwatson: Actually, in the first, I think making the ln force would be what I want. Testing for fileness seems sane (some weirdo might have put a real file there), but if it's a dangling link, I'll just want to overwrite it with a sane one. [14:36] OK; maybe -nsf for real weirdos [14:37] but OK, I think I understand now [14:37] seems sane, then [14:37] If someone's symlinking their PI to a directory, I kinda want their computer to explode... [14:37] Twice. [14:38] :-) [17:33] We ought to decide if we'll take Bug 982109 or not. Technically it's not RC and we're in final freeze, but I have this suspicion it should go in. [17:33] Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,New] https://launchpad.net/bugs/982109 [17:38] What's the size change? [17:41] Yeah, if they didn't increase size (bonus points if they reduced it), I think it's a no-brainer that we want the slideshow to match the OS. [17:41] Shame it took so long. :/ [17:41] I was planning another upload of the slideshow on Tuesday anyway for a last translation update, so I'm happy to include the new screenshots [17:41] stgraber: Cool, mention that in the bug, then? [17:42] FWIW I'm the one who reverted these out of the previous upload because of lack of UIFe but I'm certainly not against having them in [17:42] stgraber: And we can leave it up to you to make sure they didn't muck up the size. ;) [17:42] IIRC the size was fine but I'll triple check [17:42] * Laney thinks it is naughty that stuff like this and the wallpaper is coming in so late [17:42] as in, the new translations will probably take more space than the size difference in the screenshots :) [17:42] Laney: Not inclined to disagree. [17:43] got to run now but I'll leave a comment in the bug and will make sure the branch looks good for an upload on Tuesday [17:43] Is Monday a holiday in Quebekistan? [17:44] Or do you really plan your uploads more than a day in advance? :) [18:13] could I get someone to address Bug #982487 please? [18:13] Launchpad bug 982487 in djview4 "Please remove the blacklist for djview4" [Wishlist,Confirmed] https://launchpad.net/bugs/982487 [18:13] infinity: ^^^ [18:15] * tumbleweed is glad to see lots of FFe rejections :) [18:26] if whoever accepts the lua binaries can wait for lua5.2 and dh-lua together, that would be great [18:27] OK. [18:27] infinity: Tuesday is the LanguagePackTranslationDeadline so even though this package doesn't contain langpack translations, skaet and I agreed that it'd be the last reasonable upload date for it [18:28] infinity: I'm actually off on Monday and Tuesday (with the Ubuntu definition of "off" ;)) [18:29] stgraber: Yeah, note my definition of "weekend". :P [18:33] # cjwatson, 2011-04-30 [18:33] djview4 # overrides djvulibre-plugin [18:33] micahg: ^^ [18:33] micahg: Is this no longer true? [18:34] micahg: I tried to read your bug report, but I think you had a serious English fail this morning. :P [18:38] micahg: lua5.2/dh-lua all in together. [18:39] ScottK: thanks [18:42] infinity: since https://launchpad.net/ubuntu/+source/djvulibre/3.5.24-7, djvulibre was no longer providing that package, before that it was a transitional package, so not sure why the blacklist was added in the first place [18:42] micahg: Ahh, okay, I think I made sense of your bug report. [18:43] infinity: yes, I didn't mean seeded, didn't quite wake up yet when I filed that [18:43] jbicha: Got FFe? (gnome-applets) [18:44] ScottK: no, would you like one? [18:44] ScottK: It's GNOME. [18:44] infinity: That's not relevant anymore. [18:44] Gnome got a pass when we were doing new version exceptions. [18:44] I missed that memo. [18:44] jbicha: do you have any screenshot of the installer slideshow in the docs? [18:45] jbicha: (I just commented in bug 982109) [18:45] Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,Triaged] https://launchpad.net/bugs/982109 [18:45] Now that we're doing FFe, it doesn't make sense as we've got features in already. [18:45] stgraber: no [18:45] Going from, say 3.3.90 -> 3.4.0 should be bugfix only. [18:45] jbicha: cool, thanks. One less potential problem with that change then. [18:45] jbicha: In theory, I think it should have one, but as long as you've tested it, I think it's fine. [18:46] ScottK: Oh, I didn't notice the 3.2 [18:46] You've tested it, right? [18:46] ScottK: yes [18:46] jbicha: OK. We'll call this FFe over IRC then. [18:46] In case anyone asks. [18:46] thanks [18:48] Someone should email me some cafeine. [18:49] gnome-applets had one change this cycle which was I didn't bother packaging the dev snapshot [18:49] *only one [18:50] Yeah, now that the diff's showed up, I'm going to retroactively declare that not a feature release. :P [18:51] OK. [19:10] I have i386 opportunistically on manual so I can aim gcc-4.6 at roseapple. [19:10] FYI. [19:11] slangasek: gcc-4.6 and eglibc landing in the queue, would appreciate one last review before jamming them in. [19:11] * ScottK steps away from the queue. [19:12] slangasek: There will be more to follow shortly. :P [19:22] cjwatson: Alternately, you? ;) [19:24] stgraber: Or you? Surely, someone wants to review this. ;) [19:24] * infinity curses lazy Sundays. [19:25] lazy for whom? :P [19:26] Not me, that's for sure. :P [19:26] yeah, I've seen you type more than queuebot in this channel today. [19:26] That's just because queuebot's shy. [19:30] infinity: I'm having a look at eglibc [19:30] stgraber: Take an antiemetic first. [19:30] (though I'm really not familiar with it, so it's most typo-checking and making sure changelog seems to match the changes) [19:31] * infinity goes for a smoke and to find a beverage to wake him up. [19:32] infinity: eglibc needs to go to -proposed (multiarch installs, if you recall) [19:32] infinity: gcc-4.6 does for the same reason (libgcc1) [19:33] stgraber, infinity: in fact, I'm rejecting eglibc per the above so it doesn't get accidentally accepted :P [19:33] slangasek: ok. I'll keep reviewing the diff anyway as only the pocket should be different [19:35] infinity: if [ "${ARCH}" = "amd64" ] && [ "LIBC-FLAVOR" = "libc6-i386" ]; then [19:36] infinity: surely LIBC-FLAVOR != libc6-i386 or is there some sedding magic changing LIBC-FLAVOR to the right value at some point? [19:36] infinity: you've confirmed then that this change to libc6.symbols.armhf DTRT? [19:37] stgraber: these are tokens substituted with sed in the package build, yes - note the path is debian/debhelper.in/libc-alt.postinst [19:38] slangasek: I have. [19:38] slangasek: A trusty build of GNU Hello confirmed it. [19:38] As did a rebuild of gcc. [19:38] * slangasek nods [19:39] Oh, I can push them to proposed, sure. [19:39] slangasek: ok, makes sense I guess, that must get you some interesting things in the resulting postinst ;) [19:41] infinity: right, so I didn't spot anything obviously wrong (keeping in mind that it's the first time I look at eglibc ;)). I tend to prefer using -L for symlink checks and always put strings between "" in the checks but that's just personal preference. [19:41] Reuploaded to proposed. [19:41] yeah; it would be a bit nicer to have this block substituted at build time rather than doing a runtime comparison of two static strings, but eh [19:41] no time to be clever [19:42] infinity: btw, have we seen the upstream commit for this yet? :) [19:42] slangasek: That's pretty much how all glibc maintainer scripts work. A lot of no-op code with substitutions. [19:42] And I'm not sure if it's been committed. But I'll hound people during the work week. [19:42] Right now, I just want things building. [19:42] doing clean multi-line substitution/removal with sed is pretty much impossible, so yeah, some no-op code is probably the cleanest :) [19:43] Multi-line sed isn't impossible, just unreadable. [19:44] infinity: right, for me, unreadable != clean ;) [19:46] slangasek: gcc-4.6 and eglibc back in the -proposed queue now. [19:46] slangasek: I'm assuming you don't care as deeply about the old compilers? [19:46] except we're already doing multiline sed substitutions in parts of the eglibc maintainer scripts, so :P [19:46] infinity: gcc-4.6 has to go to proposed because of libgcc1; the others don't AFAIK cause multiarch skew [19:47] Check. [19:47] Does anyone have the hacked up copy of sru-release that pitti's been using to do proposed->release promotions? [19:47] infinity: what are the consequences of debian/patches/arm/unsubmitted-soname-hack.diff not being applied? [19:48] slangasek: Err, what? Am I that asleep? [19:48] infinity: it *is* applied, I'm trying to understand why [19:48] Looks applied to me... [19:48] Oh. [19:48] s/are/would be/ [19:49] The consequence is that all the old binaries in the archive fail to work. [19:49] Nothing major. [19:49] if (strcmp(name, "ld-linux.so.3") || strcmp(soname, "ld-linux-armhf.so.3")) [19:49] strcmp returns true (non-zero) on non-match, so that's always true? [19:49] Basically, we're spoofing the linker's SONAME in the linker. [19:50] Note the continue. [19:50] my point is that the above reduces to "True" [19:50] because it will always *not* match at least one of the two strings [19:50] so that looks wrong to me [19:51] Yeah, that's where you're wrong. ;) [19:51] Because we have a file named ld-linux.so.3 with an SONAME of ld-linux-armhf.so.3 [19:51] oh [19:51] the first checks name, the second checks soname [19:51] right, missed the differing variable, sorry [19:52] Basically, if something is linked to the ld-linux.so.3 linker, we spoof its SONAME as ld-linux.so.3, instead of the ld-linux-armhf.so.3 that's burned into the headers. [19:52] Without that, every old binary just happily segfaults. [19:52] It's unpleasant. [19:53] I might argue that segfaulting isn't the ideal failure mode there, but I'm not sure I care precisely why that is today. [19:53] (And even if it didn't segv, the best you could hope for is a complaint and a failure to load) [19:55] And, generally, I'd say that a binary having two PIs (which is effectively the problem) shouldn't be a common use case for ld.so. [19:55] Anyhow, this is all pretty extensively tested with some serious paranoia on my end. [19:55] the multiple layers of symlinks fill me with a general unease; I don't see any actual bugs though, or think we should do anything differently for now [20:00] + elif [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ]; then [20:00] + rm /lib/ld-linux.so.2 [20:00] + fi [20:00] shouldn't actually happen, should it? [20:00] in libc:i386's postrm [20:01] libc6:i386 has been removed; while installed it was the only possible owner of /lib/ld-linux.so.2, which gets removed on package removal [20:02] Hrm, I suppose if libc6 is installed, the symlink would be owned. [20:02] That block is probably a no-op. [20:02] infinity: It would be nice if you could put one i386 builder back on auto long enough for lua-gl to start building. [20:02] I'm not entirely sure I care to re-test right now. [20:02] infinity: ack [20:03] infinity: please drop it when pushing to Debian, anyway [20:03] +if [ "$1" = deconfigure ]; then [20:03] + :; # blah, do something useful with ldso [20:03] +fi [20:03] ^^ was that cut'n'paste from somewhere else? [20:03] That was copying libc.postrm to libc-alt.postrm, yeah. [20:03] ok [20:03] It seemed like a healthy reminder. [20:03] does accept/build order for eglibc+gcc-4.6 matter? [20:03] Though perhaps obsolete in both cases by now. I'd have to figure out why it was there in the first place. :P [20:04] Both together are fine. [20:04] eglibc accepted [20:06] Erk. You can't be serious, soyuz. [20:06] ? [20:07] My packages that happily upgrade locally... Didn't on the buildd. [20:07] ^*&$! [20:07] * infinity checks quickly WTF. [20:08] Oh, ugh, I wonder if it's the libc-bin/libc6 ordering. [20:16] ^^^ was me. No FFe. [20:16] I emailed the uploader. [20:16] Is broken libc expected on armhf right now? [20:16] https://launchpadlibrarian.net/102038392/buildlog_ubuntu-precise-armhf.lua-lgi_0.4%2B29%2Bg74cbbb1-1_CHROOTWAIT.txt.gz [20:16] ScottK: Expected, no. Noticed, yes. [20:17] OK. [20:17] I'll leave it in your capable hands and go to the store then ... [20:24] Aww, crap. Found it. [20:26] I must have always had a compat symlink sitting around on upgrade. Grr. [20:37] http://paste.ubuntu.com/931655/ [20:37] * infinity goes to test that. [20:39] infinity: so apparently the new screenshots will take us an extra 10kB on the CD, I guess we can live with that [20:41] stgraber: I dunno, pitti might have a sad. ;) [20:42] infinity: I looked on cdimage and we seem to be in pretty good shape at the moment (ignoring powerpc), as these are .jpg we can always recompress a bit if we need to save a few kBs ;) [20:45] Yeah, I have no idea how to fix PPC, short of dropping one of the kernels. [20:45] Or just randomly dropping some big application. [20:46] Okay, hacked-up version tested in a CLEAN chroot. :/ [20:46] There's always one bug, right? [20:49] stgraber: http://paste.ubuntu.com/931680/ <-- uploading that. [20:49] (as well as a fixed libc6 to the bootstrap archive) [20:53] infinity: does what it says it does, assuming all the required sed magic. [20:55] RTLD_SO = /lib/ld-linux.so.3 and SLIBDIR = /lib/arm-linux-gnueabihf [21:00] infinity: k, looks good. Please approve so we get working armhf again :) (sadly I'm in ENOARMHF here as my panda is back home some 7000km away and currently on armel 11.10 ...) [21:01]