[04:02] <ScottK> ^^^ is my upload, so I'd appreciate some other archive admin reviewing/accepting.
[04:12] <infinity> Erm.
[04:13] <infinity> Now that we have multiarch, why not make an arch:all package that depends on the arch:ppc one?
[04:13] <infinity> Oh, I guess that's overkill.
[04:14] <infinity> Either way, I guess qemu and the like still can't depend on it. :/
[04:16] <infinity> ScottK: Did you at least make it Multi-Arch: foreign, so I can install it?
[04:17] <infinity> Oh, I guess I can do that manually wihthout the M-A header, things just can't depend on it.
[04:18] <ScottK> 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] <infinity> It's a shame it's GPL. :/
[04:19] <infinity> If it was BSD, I'd just toss the binary blob in multiverse and call it done.
[04:20] <infinity> Anyhow, this situation is no worse than what we had before.
[04:21] <ScottK> Before we had no binary at all.
[04:21] <infinity> ScottK: Have you downloaded the deb from the build and confirmed that qemu appears to like it in some meaningful way?
[04:21] <infinity> Yeah, hence no worse than before. :P
[04:21] <ScottK> 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] <ScottK> It builds and there's some binary file in there is all I can tell you.
[04:23] <infinity> Heh.
[04:24] <infinity> I'm not sure how useful it is, unless people are really willing to turn on multiarch for one deb.
[04:24] <infinity> But meh.
[04:24] <infinity> Like I said, better than the previous situation.
[04:26] <ScottK> Thanks.
[04:28] <infinity> doko_: Do you have a valid argument for the GDB upload in the queue?
[04:30] <infinity> 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] <infinity> ScottK: Want to review a diff for me and have a bit of a cry?
[04:30] <infinity> ScottK: http://lucifer.0c3.net/~adconrad/eglibc.debdiff
[04:31] <ScottK> As soon as I saw the package name, I knew there would be tears.
[04:34] <ScottK> It seems not unreasonable, but I by no means feel comfortable with saying it's OK or not.  Way over my head.
[04:34] <infinity> If it doesn't seem unreasonable, I think that's proof it's over your head, yes. ;)
[04:35] <infinity> But thanks for the vote of confidence.
[04:35] <ScottK> Not unreasonable in that I suspect is does what you want.
[04:35] <ScottK> That saws nothing about the reasonableness of what you want.
[04:35] <infinity> It appears to, yes.  No kittens have died thus far.
[04:35] <ScottK> 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] <infinity> ScottK: Wuss. ;)
[04:36] <ScottK> I chickened out on approving the last openssl merge too.
[04:42] <nigelb> sssss/ws 36
[04:42] <nigelb> gah
[04:43] <infinity> *slow clap*
[04:52] <nigelb> infinity: What are computers? How do I use 'em? :)
[04:52] <infinity> Try not to pass out on the "s" key, and you'll be fine.
[04:54] <nigelb> heh
[04:58] <ScottK> 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] <infinity> Yeah, doko did the same for python-defaults, didn't he?
[05:01] <infinity> I was going to accept it as soon as I saw the diff.
[05:01] <ScottK> He did.
[05:01] <infinity> (rather, as soon as I've reviewed it)
[05:01] <ScottK> It won't take much longer to review it than to see it.
[05:01] <infinity> ScottK: You dropped the maintainer mangling in debian/control.
[05:02] <infinity> -Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[05:02] <infinity> -XSBC-Original-Maintainer: Matthias Klose <doko@debian.org>
[05:02] <infinity> +Maintainer: Matthias Klose <doko@debian.org>
[05:04] <ScottK> It's suppose to do that automagically.
[05:04] <ScottK> Hang on.
[05:07] <ScottK> infinity: Found it.
[05:07] <ScottK> I can't spell Ubuntu.  Please reject that one.
[05:07] <infinity> Oh, hah. 0ubunu1
[05:08] <infinity> I didn't even see that.
[05:08] <ScottK> The maintainer magic did though.
[05:08] <ScottK> I guess that's why we review them all at this stage.
[05:08] <ScottK> New one is uploadded.
[05:09] <infinity> Every time I see something like that, I'm reminded that I want to revisit my pam_dwim module.
[05:09] <ScottK> ;-)
[05:09] <infinity> Your scripts totally should have noticed and fixed the typo.
[05:09] <infinity> Just like a computer should log me in if my password is "close enough".
[05:10] <infinity> Picky things.
[05:10] <ScottK> And not log someone else in on your account even if it's close, because that's not what you want.
[05:10] <infinity> That logic might be harder to write, but yeah.
[05:12] <infinity> 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] <infinity> At sufficiently high fuzz levels, it'll offload to an opencl library and get your video card to log you in.
[05:13] <ScottK> At one UDS, apachelogger_ had a facial recognition module for kdm working reasonably well.
[05:14] <ScottK> Thanks.
[05:15] <infinity> 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] <ScottK> Finished 1 minute ago (took 55.4 seconds)  <--- buildds are getting faster, I guess.
[05:16] <infinity> Well, the i386 chroot is fresh, and sbuild no longer purges build-deps.
[05:16] <infinity> So, yeah.
[05:16] <ScottK> Also, until it gets reliable enough to disable password access, it's a convenience thing, not a security feature.
[05:16] <infinity> On roseapple, we were seeing langpack builds in 20ish seconds after I landed that change.
[05:16] <ScottK> Nice.
[05:17] <infinity> Well, okay, the chroot *was* fresh.
[05:17] <infinity> Silly people and their uploading.
[05:18] <ScottK> Speaking of which, I see you cracked into the top ten uploaders this cycle.  You've been a busy boy.
[05:18] <infinity> I've been slacking.
[05:18] <infinity> Didn't do a single transition...
[05:19] <infinity> Though, I still have time to do an fpc one.
[05:19] <infinity> But that's a tiny package set.
[05:19] <ScottK> Doesn't it need bootstrapping on armhf?
[05:20] <ScottK> IIRC, I only did one library transition and it had 3 rdepends.
[05:20] <infinity> Yes, hence the transition.
[05:20] <ScottK> Ah.  Right.
[05:20] <infinity> Since I'll be updating to 2.6.x at the same time. :P
[05:20] <infinity> Cause, hey, that's the sort of thing one does 1.5 weeks before release.
[05:21] <infinity> Looks like the only thing we'll be missing on armhf is gnat.
[05:21] <ScottK> Meh.  Universe.
[05:21] <infinity> Which is unfortunate, but we all just ran out of time to make it go. :/
[05:21] <infinity> Well, ada's not hip and cool anyway.
[05:21] <infinity> If it had been haskell, people would have been upset about their pet language.
[05:22] <ScottK> 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] <infinity> I only had 385 uploads in oneiric.
[05:22] <infinity> I *am* slacking.
[05:23] <infinity> Hahaha.  Yeah.  My friend's doing a haskell course at university right now, and I help him with his homework occasionally.
[05:23] <infinity> It's pretty much gibberish to me.
[05:23] <ScottK> 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] <infinity> I have you at 641 for oneiric.
[05:24] <infinity> Where is this shiny list?
[05:24] <infinity> I'm just grepping -changes. :P
[05:26] <ScottK> http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
[05:27] <ScottK> 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] <infinity> Heh.
[05:28] <infinity> Colin totally cheated this cycle with transitions.
[05:28] <infinity> I demand half of his life-saver chunk be equally redistributed.
[05:30] <infinity> Man, you can so see when I moved from distro to IS...
[05:30] <infinity> #7 in breezy, #12 in dapper, then.. Gone.
[05:30] <infinity> Sad.
[05:35] <ScottK> 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] <infinity> That's not that surprising.
[05:36] <infinity> 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] <infinity> I'm a bit confused by my not showing up in hoary, though.
[05:38] <ScottK> Gotta love these helpful debian/changelog entries, "Update packaging bits.".
[05:38] <infinity> ;)
[05:38] <micahg> meh, I was hoping for top 5 this cycle, but not making it for +1 maintenance threw that out the window
[05:39] <infinity> Oh, maybe I didn't start until the tail end of hoary.  I suck at history.
[05:40] <ScottK> micahg: There's more than enough unseeded Universe FTBFS to fix to resolve that concern.
[05:41] <infinity> micahg: I haven't uploaded much with a +1 maint hat on.
[05:41] <micahg> ScottK: I'm aware, the only thing I'm lacking is time
[05:41] <infinity> micahg: Also, what Scott said.  Fix every FTBFS please.
[05:41] <micahg> infinity: that's why I still have more uploads than you :)
[05:41] <infinity> You have time right now!
[05:41] <micahg> infinity: yeah, I'm taking a look at a few things now
[05:42] <ScottK> 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] <infinity> My LP karma sucks.
[05:42] <infinity> I should probably register and needlessly manipulate a blueprint every morning with my coffee.
[05:43] <infinity> I'm sure I could automate that.
[05:43] <ScottK> It's hight than mine (which is good).
[05:44] <ScottK> My current goal is to stay under 25K.
[05:44] <infinity> 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] <infinity> Maybe I'll do that in my next commit, in the name of "every new line should remove two others".
[05:46] <ScottK> No.  How else would I know to go do something else for a few days?
[05:46] <infinity> Get a dog.
[05:46] <infinity> They're needy.
[05:46] <ScottK> Got a dog.
[05:46] <infinity> Hrm.
[05:46] <ScottK> It's very old and very needy.
[05:46] <ScottK> Got kids too (3).
[05:46] <infinity> I'm stumped, then.
[05:46] <ScottK> Also very needy and distracting.
[05:47] <ScottK> The dog gave up and went to bed about two hours ago.
[05:47] <infinity> lobotomy?
[05:47] <ScottK> If the amount of alcohol I consumed in my 20's didn't do it, I don't think so.
[05:48] <infinity> Could explain the KDE fetish, though.
[05:49] <ScottK> That's purely what I started on.
[05:49] <ScottK> Other stuff feels wrong.
[05:49] <infinity> That's how I explain my sexuality.
[05:50] <ScottK> Gee.  Look at the time.  I should probably go get some sleep.
[05:51] <infinity> Hahaha.
[05:51] <infinity> G'night. ;)
[05:51] <infinity> (I win!)
[05:51] <infinity> I'm probably not being useful by staring at parallel glibc builds scrolling by, maybe I'll nap too.
[05:55] <micahg> ScottK: congrats on fixing openbios-ppc :)
[05:56]  * micahg wonders if we should SRU the fix
[05:59] <infinity> Nah.
[05:59] <infinity> People still need to do some hand-installing anyway.
[06:00] <infinity> So pointing them at the precise deb is just as easy. :P
[06:01] <infinity> 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] <ScottK> micahg: If someone cares, they can ask for a backport.
[06:01] <infinity> Then we could still have sparc too.
[06:01] <infinity> And whatever other ones there may be.
[09:57] <micahg> can someone please retry libcomplearn in the rebuild?
[10:07] <infinity> micahg: Done.
[10:08] <micahg> infinity: thanks
[10:30]  * infinity thinks he's finally tracked down the last place(s) where the linker change will affect us.
[10:31] <infinity> Although, the d-i bit will need some trial and error to get right.
[11:25] <micahg> bug 982232 \o/
[11:25] <ubot2> 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] <infinity> micahg: Done.
[11:32] <micahg> infinity: awesome :), I at least met one of my release goals
[11:32] <infinity> Hahaha.
[11:32] <infinity> "Kill yada" has been an Ubuntu goal since our inception.
[11:32] <infinity> We got it out of main in a hurry, but... Today's a good day.
[13:44] <cjwatson> reminder to self: we should sync golang 2:1-5 once LP knows about it, to fix the armel build failure
[14:00] <infinity> cjwatson: Because disabling tests is always a winning notion. ;)
[14:02] <infinity> 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] <infinity> cjwatson: http://paste.ubuntu.com/931060/
[14:03] <infinity> cjwatson: Err, context is bug #852101
[14:03] <ubot2> Launchpad bug 852101 in ia32-libs "32-bit applications do not start on 64" [High,Fix released] https://launchpad.net/bugs/852101
[14:25] <cjwatson> at this point in the cycle, disabling tests may be all we have :-/
[14:25] <cjwatson> infinity: LIBC is substituted?
[14:26] <infinity> True.  And I'm trying my best to make sure people don't run armel anyway. :P
[14:26] <infinity> cjwatson: Yeah, is gets munged to the current package/pass.
[14:26] <cjwatson> /lib/ld-linux.so.2 won't ever be a dangling symlink?
[14:26] <cjwatson> I'd quote $(readlink -f /lib/ld-linux.so.2) because I'm paranoid
[14:26] <infinity> Heh.
[14:27] <cjwatson> also would be inclined to use rm -f but that's probably superstition
[14:27] <infinity> I tend never to force in maintainer scripts.
[14:27] <infinity> 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] <cjwatson> mm
[14:28] <infinity> And yeah, /lib/ld-linux.so.2 can end up dangling, which is why the elif nukes it.
[14:28] <infinity> Because libc6:i386 and libc6-i386:amd64 both ship it, and both replace each other.
[14:29] <cjwatson> but [ ! -f ] will pass on a dangling symlink so that ln -s could fail.
[14:29] <infinity> So, due to the fun of package takeovers, and then me cowboying the ln -s...
[14:30] <cjwatson> 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] <infinity> Oh, right.  I forgot about that property of -f.
[14:30] <infinity> Is that POSIX?
[14:31] <cjwatson> yeah
[14:31] <cjwatson> derives from stat
[14:31] <infinity> Kay.  I'll scrap the readlink, then.
[14:31] <cjwatson> I'm a bit perturbed that the two branches of the if leave the system in wildly different states
[14:31] <infinity> And change the first to a -h
[14:31] <cjwatson> not sure I quite understand it at this stage of caffeination
[14:31] <infinity> So, basically, it's combating two seperate issues:
[14:32] <infinity> 1) installing both libc6:i386 and libc6-i386 and then removing one will leave you with no ld.so
[14:32] <infinity> 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] <infinity> The proper solution for this would be a diversion, but a bug in dpkg-divert makes that infeasible. :P
[14:34] <infinity> (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] <infinity> 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] <cjwatson> OK; maybe -nsf for real weirdos
[14:37] <cjwatson> but OK, I think I understand now
[14:37] <cjwatson> seems sane, then
[14:37] <infinity> If someone's symlinking their PI to a directory, I kinda want their computer to explode...
[14:37] <infinity> Twice.
[14:38] <cjwatson> :-)
[17:33] <ScottK> 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] <ubot2> Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,New] https://launchpad.net/bugs/982109
[17:38] <Laney> What's the size change?
[17:41] <infinity> 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] <infinity> Shame it took so long. :/
[17:41] <stgraber> 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] <infinity> stgraber: Cool, mention that in the bug, then?
[17:42] <stgraber> 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] <infinity> stgraber: And we can leave it up to you to make sure they didn't muck up the size. ;)
[17:42] <stgraber> 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] <stgraber> as in, the new translations will probably take more space than the size difference in the screenshots :)
[17:42] <infinity> Laney: Not inclined to disagree.
[17:43] <stgraber> 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] <infinity> Is Monday a holiday in Quebekistan?
[17:44] <infinity> Or do you really plan your uploads more than a day in advance? :)
[18:13] <micahg> could I get someone to address Bug #982487 please?
[18:13] <ubot2> Launchpad bug 982487 in djview4 "Please remove the blacklist for djview4" [Wishlist,Confirmed] https://launchpad.net/bugs/982487
[18:13] <ScottK> infinity: ^^^
[18:15]  * tumbleweed is glad to see lots of FFe rejections :)
[18:26] <micahg> if whoever accepts the lua binaries can wait for lua5.2 and dh-lua together, that would be great
[18:27] <ScottK> OK.
[18:27] <stgraber> 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] <stgraber> infinity: I'm actually off on Monday and Tuesday (with the Ubuntu definition of "off" ;))
[18:29] <infinity> stgraber: Yeah, note my definition of "weekend". :P
[18:33] <infinity> # cjwatson, 2011-04-30
[18:33] <infinity> djview4 # overrides djvulibre-plugin
[18:33] <infinity> micahg: ^^
[18:33] <infinity> micahg: Is this no longer true?
[18:34] <infinity> micahg: I tried to read your bug report, but I think you had a serious English fail this morning. :P
[18:38] <ScottK> micahg: lua5.2/dh-lua all in together.
[18:39] <micahg> ScottK: thanks
[18:42] <micahg> 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] <infinity> micahg: Ahh, okay, I think I made sense of your bug report.
[18:43] <micahg> infinity: yes, I didn't mean seeded, didn't quite wake up yet when I filed that
[18:43] <ScottK> jbicha: Got FFe?  (gnome-applets)
[18:44] <jbicha> ScottK: no, would you like one?
[18:44] <infinity> ScottK: It's GNOME.
[18:44] <ScottK> infinity: That's not relevant anymore.
[18:44] <ScottK> Gnome got a pass when we were doing new version exceptions.
[18:44] <infinity> I missed that memo.
[18:44] <stgraber> jbicha: do you have any screenshot of the installer slideshow in the docs?
[18:45] <stgraber> jbicha: (I just commented in bug 982109)
[18:45] <ubot2> Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,Triaged] https://launchpad.net/bugs/982109
[18:45] <ScottK> Now that we're doing FFe, it doesn't make sense as we've got features in already.
[18:45] <jbicha> stgraber: no
[18:45] <ScottK> Going from, say 3.3.90 -> 3.4.0 should be bugfix only.
[18:45] <stgraber> jbicha: cool, thanks. One less potential problem with that change then.
[18:45] <ScottK> jbicha: In theory, I think it should have one, but as long as you've tested it, I think it's fine.
[18:46] <infinity> ScottK: Oh, I didn't notice the 3.2
[18:46] <ScottK> You've tested it, right?
[18:46] <jbicha> ScottK: yes
[18:46] <ScottK> jbicha: OK.  We'll call this FFe over IRC then.
[18:46] <ScottK> In case anyone asks.
[18:46] <jbicha> thanks
[18:48] <infinity> Someone should email me some cafeine.
[18:49] <jbicha> gnome-applets had one change this cycle which was I didn't bother packaging the dev snapshot
[18:49] <jbicha> *only one
[18:50] <infinity> Yeah, now that the diff's showed up, I'm going to retroactively declare that not a feature release. :P
[18:51] <ScottK> OK.
[19:10] <infinity> I have i386 opportunistically on manual so I can aim gcc-4.6 at roseapple.
[19:10] <infinity> FYI.
[19:11] <infinity> 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] <infinity> slangasek: There will be more to follow shortly. :P
[19:22] <infinity> cjwatson: Alternately, you? ;)
[19:24] <infinity> stgraber: Or you?  Surely, someone wants to review this. ;)
[19:24]  * infinity curses lazy Sundays.
[19:25] <nigelb> lazy for whom? :P
[19:26] <infinity> Not me, that's for sure. :P
[19:26] <nigelb> yeah, I've seen you type more than queuebot in this channel today.
[19:26] <infinity> That's just because queuebot's shy.
[19:30] <stgraber> infinity: I'm having a look at eglibc
[19:30] <infinity> stgraber: Take an antiemetic first.
[19:30] <stgraber> (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] <slangasek> infinity: eglibc needs to go to -proposed (multiarch installs, if you recall)
[19:32] <slangasek> infinity: gcc-4.6 does for the same reason (libgcc1)
[19:33] <slangasek> stgraber, infinity: in fact, I'm rejecting eglibc per the above so it doesn't get accidentally accepted :P
[19:33] <stgraber> slangasek: ok. I'll keep reviewing the diff anyway as only the pocket should be different
[19:35] <stgraber> infinity: if [ "${ARCH}" = "amd64" ] && [ "LIBC-FLAVOR" = "libc6-i386" ]; then
[19:36] <stgraber> infinity: surely LIBC-FLAVOR != libc6-i386 or is there some sedding magic changing LIBC-FLAVOR to the right value at some point?
[19:36] <slangasek> infinity: you've confirmed then that this change to libc6.symbols.armhf DTRT?
[19:37] <slangasek> stgraber: these are tokens substituted with sed in the package build, yes - note the path is debian/debhelper.in/libc-alt.postinst
[19:38] <infinity> slangasek: I have.
[19:38] <infinity> slangasek: A trusty build of GNU Hello confirmed it.
[19:38] <infinity> As did a rebuild of gcc.
[19:38]  * slangasek nods
[19:39] <infinity> Oh, I can push them to proposed, sure.
[19:39] <stgraber> slangasek: ok, makes sense I guess, that must get you some interesting things in the resulting postinst ;)
[19:41] <stgraber> 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] <infinity> Reuploaded to proposed.
[19:41] <slangasek> 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] <slangasek> no time to be clever
[19:42] <slangasek> infinity: btw, have we seen the upstream commit for this yet? :)
[19:42] <infinity> slangasek: That's pretty much how all glibc maintainer scripts work.  A lot of no-op code with substitutions.
[19:42] <infinity> And I'm not sure if it's been committed.  But I'll hound people during the work week.
[19:42] <infinity> Right now, I just want things building.
[19:42] <stgraber> doing clean multi-line substitution/removal with sed is pretty much impossible, so yeah, some no-op code is probably the cleanest :)
[19:43] <infinity> Multi-line sed isn't impossible, just unreadable.
[19:44] <stgraber> infinity: right, for me, unreadable != clean ;)
[19:46] <infinity> slangasek: gcc-4.6 and eglibc back in the -proposed queue now.
[19:46] <infinity> slangasek: I'm assuming you don't care as deeply about the old compilers?
[19:46] <slangasek> except we're already doing multiline sed substitutions in parts of the eglibc maintainer scripts, so :P
[19:46] <slangasek> infinity: gcc-4.6 has to go to proposed because of libgcc1; the others don't AFAIK cause multiarch skew
[19:47] <infinity> Check.
[19:47] <infinity> Does anyone have the hacked up copy of sru-release that pitti's been using to do proposed->release promotions?
[19:47] <slangasek> infinity: what are the consequences of debian/patches/arm/unsubmitted-soname-hack.diff not being applied?
[19:48] <infinity> slangasek: Err, what?  Am I that asleep?
[19:48] <slangasek> infinity: it *is* applied, I'm trying to understand why
[19:48] <infinity> Looks applied to me...
[19:48] <infinity> Oh.
[19:48] <slangasek> s/are/would be/
[19:49] <infinity> The consequence is that all the old binaries in the archive fail to work.
[19:49] <infinity> Nothing major.
[19:49] <slangasek> if (strcmp(name, "ld-linux.so.3") || strcmp(soname, "ld-linux-armhf.so.3"))
[19:49] <slangasek> strcmp returns true (non-zero) on non-match, so that's always true?
[19:49] <infinity> Basically, we're spoofing the linker's SONAME in the linker.
[19:50] <infinity> Note the continue.
[19:50] <slangasek> my point is that the above reduces to "True"
[19:50] <slangasek> because it will always *not* match at least one of the two strings
[19:50] <slangasek> so that looks wrong to me
[19:51] <infinity> Yeah, that's where you're wrong. ;)
[19:51] <infinity> Because we have a file named ld-linux.so.3 with an SONAME of ld-linux-armhf.so.3
[19:51] <slangasek> oh
[19:51] <stgraber> the first checks name, the second checks soname
[19:51] <slangasek> right, missed the differing variable, sorry
[19:52] <infinity> 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] <infinity> Without that, every old binary just happily segfaults.
[19:52] <infinity> It's unpleasant.
[19:53] <infinity> 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] <infinity> (And even if it didn't segv, the best you could hope for is a complaint and a failure to load)
[19:55] <infinity> 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] <infinity> Anyhow, this is all pretty extensively tested with some serious paranoia on my end.
[19:55] <slangasek> 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] <slangasek> +       elif [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ]; then
[20:00] <slangasek> +           rm /lib/ld-linux.so.2
[20:00] <slangasek> +       fi
[20:00] <slangasek> shouldn't actually happen, should it?
[20:00] <slangasek> in libc:i386's postrm
[20:01] <slangasek> 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] <infinity> Hrm, I suppose if libc6 is installed, the symlink would be owned.
[20:02] <infinity> That block is probably a no-op.
[20:02] <ScottK> 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] <infinity> I'm not entirely sure I care to re-test right now.
[20:02] <slangasek> infinity: ack
[20:03] <slangasek> infinity: please drop it when pushing to Debian, anyway
[20:03] <slangasek> +if [ "$1" = deconfigure ]; then
[20:03] <slangasek> +    :; # blah, do something useful with ldso
[20:03] <slangasek> +fi
[20:03] <slangasek> ^^ was that cut'n'paste from somewhere else?
[20:03] <infinity> That was copying libc.postrm to libc-alt.postrm, yeah.
[20:03] <slangasek> ok
[20:03] <infinity> It seemed like a healthy reminder.
[20:03] <slangasek> does accept/build order for eglibc+gcc-4.6 matter?
[20:03] <infinity> 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] <infinity> Both together are fine.
[20:04] <slangasek> eglibc accepted
[20:06] <infinity> Erk.  You can't be serious, soyuz.
[20:06] <slangasek> ?
[20:07] <infinity> My packages that happily upgrade locally... Didn't on the buildd.
[20:07] <infinity> ^*&$!
[20:07]  * infinity checks quickly WTF.
[20:08] <infinity> Oh, ugh, I wonder if it's the libc-bin/libc6 ordering.
[20:16] <ScottK> ^^^ was me.  No FFe.
[20:16] <ScottK> I emailed the uploader.
[20:16] <ScottK> Is broken libc expected on armhf right now?
[20:16] <ScottK> https://launchpadlibrarian.net/102038392/buildlog_ubuntu-precise-armhf.lua-lgi_0.4%2B29%2Bg74cbbb1-1_CHROOTWAIT.txt.gz
[20:16] <infinity> ScottK: Expected, no.  Noticed, yes.
[20:17] <ScottK> OK.
[20:17] <ScottK> I'll leave it in your capable hands and go to the store then ...
[20:24] <infinity> Aww, crap.  Found it.
[20:26] <infinity> I must have always had a compat symlink sitting around on upgrade.  Grr.
[20:37] <infinity> http://paste.ubuntu.com/931655/
[20:37]  * infinity goes to test that.
[20:39] <stgraber> infinity: so apparently the new screenshots will take us an extra 10kB on the CD, I guess we can live with that
[20:41] <infinity> stgraber: I dunno, pitti might have a sad. ;)
[20:42] <stgraber> 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] <infinity> Yeah, I have no idea how to fix PPC, short of dropping one of the kernels.
[20:45] <infinity> Or just randomly dropping some big application.
[20:46] <infinity> Okay, hacked-up version tested in a CLEAN chroot. :/
[20:46] <infinity> There's always one bug, right?
[20:49] <infinity> stgraber: http://paste.ubuntu.com/931680/ <-- uploading that.
[20:49] <infinity> (as well as a fixed libc6 to the bootstrap archive)
[20:53] <stgraber> infinity: does what it says it does, assuming all the required sed magic.
[20:55] <infinity> RTLD_SO = /lib/ld-linux.so.3 and SLIBDIR = /lib/arm-linux-gnueabihf
[21:00] <stgraber> 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] <infinity> Someone remind me to never move a PI again.
[21:02] <infinity> Though, on the flip side, I'm getting really good at it?
[21:03] <infinity> Err, not accepting yet.  *sigh*
[21:03] <infinity> I need to stare at this for a second to figure out why it worked here, and not there.
[21:03] <phillw> stgraber: if powerpc size is a possible problem, do you want me ask the guys testing it what should be dropped? They have said some of the stuff cannot be used..
[21:14] <stgraber> infinity: what was wrong with it?
[21:15] <infinity> stgraber: Okay, small thinko on that one (I had it right in the one I did by hand, of course, but not in the source package...)
[21:15] <infinity> Cause I'm that awake.
[21:15] <infinity> stgraber: http://paste.ubuntu.com/931711/
[21:16] <infinity> stgraber: ld-linux-armhf.so.3 doesn't exist yet in /lib/triplet/ until after unpack.
[21:16] <infinity> stgraber: So, have to symlink to the OLD location.
[21:16] <infinity> Derp.
[21:16] <infinity> I'm going to sleep for a week after this.
[21:17]  * infinity tags that one in bzr, assuming you'll just say "yeah, whatever, I'm done with you crazy man".
[21:18] <stgraber> infinity: ah right, so what you pasted above "RTLD_SO = /lib/ld-linux.so.3" was wrong? (otherwise basename(RTLD_SO) == ld-linux.so.3 so your new debdiff would effectively be identical to the previous one)
[21:18] <infinity> stgraber: That was me being half asleep, RTLD_SO is /lib/ld-linux-armhf.so.3
[21:19] <stgraber> right, all makes sense then ;)
[21:20] <infinity> And now that that mess is taken care of...
[21:20] <infinity> Odds on getting gcc-4.6 approved?
[21:20] <infinity> It's much less scary. :P
[21:20] <infinity> (thankfully)
[21:21] <slangasek> except that I can't prove to myself that this fix for a segfault won't change other code generation
[21:21] <infinity> slangasek: Or did you already approve, but not accept gcc-4.6?
[21:22] <infinity> Oh, you're looking at the PR patches still?
[21:22] <slangasek> yes
[21:22] <infinity> I did a test build on amd64 and didn't see any testsuite regressions.
[21:23] <infinity> Beyond that, I'm a bit hopeless at reviewing compiler bits, unless they're dead simple.
[21:25] <infinity> Reading the bugs, in one case, it looks like we're suffering from carrying half a patch set.
[21:26] <infinity> (And this is the other half, matching mainline 4.7)
[21:32] <ScottK> infinity: Drop libreoffice on powerpc.  That's what I did on the Kubuntu images and I've never had a size problem since.
[21:32] <slangasek> infinity: I understand that these are both worthwhile bugs to fix, but I'm not comfortable taking either of these pr patches because I can't hold the side-effects in my head
[21:33] <slangasek> so I think they're inappropriate for final freeze and need to be backed out
[21:33] <infinity> slangasek: Can do.  It's doko who'll be grumpy, not me. ;)
[21:33] <infinity> I'll just go re-do all the 4.6-based packages really quick-like.
[21:33] <slangasek> doko_: ^^ sorry, I can't approve these gcc-4.6 PR patches for a final freeze exception; I'm asking infinity to upload without them, they can go in as an SRU after gcc-4.6 gets copied to -release
[21:33] <infinity> ScottK: Did you replace it with something else, or just drop it entirely?
[21:34] <ScottK> infinity: Just dropped it.
[21:34] <ScottK> One can still apt-get install it, unlike a kernel if that's the one you reallly need.
[21:34] <infinity> Fair point.
[21:34] <infinity> And yeah, we need both kernels. :P
[21:34] <ScottK> lua-lgi was me.
[21:38] <infinity> slangasek: Re-uploaded.  And re-doing the other 4.6-based packages to remove those patches for when I upload them in a bit.
[21:38] <infinity> (Where "a bit" is "after gcc-4.6-source is published")
[21:39] <kklimonda> what's the process for syncing unseeded almost-no-new-features-in package this close to the release? I'm thinking of bug 981044 for example
[21:39] <ubot2> Launchpad bug 981044 in znc "Sync znc 0.206-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/981044
[21:39] <kklimonda> (I've tried reading through the current docs, but they are a bit messy)
[21:41] <Laney> Which documents do you think are messy?
[21:44] <kklimonda> Laney: how nominal is Final Freeze for unseeded packages? Does that mean that we are not limited to release-critical/security-critical/exceptional cases?
[21:45] <ScottK> kklimonda: For unseeded packages, final freeze didn't happen yet, so no, we aren't so restricted.
[21:45] <ScottK> Feature changes still need FFe though.
[21:45] <kklimonda> one man's feature.. ;)
[21:45] <infinity> slangasek: That one should be less scary.
[21:46] <ScottK> kklimonda: I did look at the bug.  I think it should go in.  Please subscribe ubuntu-release and change the body to indicate it's a FFe and I'll approve it.
[21:47] <kklimonda> ScottK: ah, that was my second question - we still subscribe ubuntu-release, wait for exception, and then upload?
[21:47] <infinity> Not much waiting in this case.
[21:48] <ScottK> Yes.  Since Universe is not technically frozen, stuff may just get pushed through, so ask first.
[21:48] <ScottK> No.
[21:48] <kklimonda> ScottK: ah, that makes sense - thanks
[21:52] <ScottK> micahg: ^^^ is that bugfix or am I just failing to find the FFe?
[21:52] <infinity> He had two bugs for it, if I recall.
[21:52] <infinity> Neither was fiffie.
[21:53] <ScottK> kklimonda: Approved.
[21:53] <kklimonda> ScottK: thanks
[21:53] <ScottK> No problem.
[21:53] <micahg> ScottK: I thought you approved it :) bug 982211
[21:53] <ubot2> Launchpad bug 982211 in djview4 "FFe: Sync djview4 4.9-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/982211
[21:55] <infinity> slangasek: Hrm.  I don't think your diff is coming. :P
[21:55] <infinity> ... he says as it shows up.
[21:55] <infinity> slangasek: If you can accept the three compilers, I'll stop bugging you for the night (and find another sucker for the next round of compilers) ;)
[21:56] <micahg> ScottK: sorry, I closed the bugs too quickly
[21:56] <ScottK> That would explain why I didn't see it on the bug list.
[21:57] <slangasek> infinity: gcc-4.6 accepted.  Just to be sure, which are the others you want accepted right now?
[21:57] <ScottK> micahg: Accepted.  Thanks.
[21:57] <infinity> slangasek: 4.5 and 4.4 as well.  They can all build in parallel.
[21:57] <slangasek> ok
[21:57] <micahg> ScottK: thank you :)
[21:57] <infinity> slangasek: I won't upload gcj/gdc/cross-toolchain/etc until after all the gcc's spit out their respective gcc-*-source.
[22:00] <slangasek> is there a 4.7 to follow?
[22:00] <ScottK> It would be nice, if someone with powerz has a moment, to get a respin for kubuntu daily and daily-live.  I just fiddled the language packs and I want to make sure I didn't go overboard.
[22:00] <infinity> slangasek: 4.7 is only in doko's PPA.
[22:01] <infinity> slangasek: Except for gccgo-4.7, which is queued here, yeah.
[22:01] <infinity> ScottK: Sure.
[22:02] <slangasek> ok
[22:03] <infinity> ScottK: Building.
[22:03] <ScottK> Thanks.
[22:13] <ScottK> Can eglibc 2.15-0ubuntu8 be shot in the head?  powerpc's backlogged again and that would help.
[22:13] <infinity> ScottK: Already asked.
[22:13] <ScottK> Thanks.
[22:14] <infinity> And PPC will be backlogged for a while with all these compilers.
[22:14] <infinity> :/
[22:14] <ScottK> No doubt, that's why I figured every little bit helps.
[22:14]  * infinity nods.
[22:15] <infinity> Though, it's already 2/3 done anyway.
[22:16] <infinity> ^--- PowerPC diet.
[22:17]  * ScottK looks
[22:18]  * ScottK waits for a diff
[22:18] <infinity> It looks remarkably similar to the changelog.
[22:19] <ScottK> Probably, but final freeze and all, I'm obligated to look.
[22:19] <infinity> ;)
[22:21] <infinity> pitti: When you wake up, where does that forked version of sru-release that can do proposed->release live?
[22:22] <infinity> Oh, wait, maybe that's committed.
[22:23] <ScottK> I'm glad I asked for the respin.  My language pack math was way off.
[22:23] <ScottK> fixed.
[22:24] <infinity> I suppose I could actually add some languages to PPC after scrapping LibO.  Novel idea.
[22:24] <infinity> But I'll worry about it another time.
[22:25] <stgraber> infinity: ubuntu-meta matches .changes so looks good :)
[22:26] <stgraber> infinity: might be worth opening a bug against ubuntu-releases-notes or making a note somewhere to mention that powerpc won't have libreoffice by default
[22:29] <ScottK> For both Ubuntu powerpc users?
[22:29] <ScottK> Accepted.
[22:30] <infinity> I'm an Ubuntu powerpc user.  But not on the desktop currently.
[22:30] <ScottK> That makes you an Ubuntu Server powerpc user.
[22:31] <ScottK> Ubuntu Desktop isn't called that anymore, it's just Ubuntu, so the term is a bit overloaded in any case.
[22:31] <infinity> Yeah, yeah.  I know.
[22:32] <infinity> Fine, I'm an Ubuntu Server PowerPC user who sometimes dabbles with Ubuntu (desktop) on his PowerStation, but not often.
[22:32] <infinity> Mostly cause I still need to buy a sound card for it.
[22:33] <infinity> Anyhow.  Someone baked me a ham.  I think I'll go eat it.
[22:33] <ScottK> Sounds nice.
[22:50] <phillw> stgraber: oh, sorry, i was thinking about lubuntu-ppc, the guys struggle to run ubuntu-ppc as it is a little too hungry for resources, but they will go test for you.
[22:51] <cjwatson> micahg: sync-source.py -a used to get really upset about syncs of sources that overwrote binaries from other sources that had Ubuntu modifications and require manual untangling, so blacklisting was generally the first step there; that bug is fixed with the new auto-sync script so those blacklist entries are no longer necessary
[22:51] <micahg> cjwatson: ah, ok, thanks
[22:52] <cjwatson> infinity: sru-release> use the -r option, it's committed
[22:54] <micahg> can someone please give back denemo in the rebuild?
[22:55] <cjwatson> micahg: done
[22:55] <micahg> cjwatson: thanks
[23:01] <micahg> cjwatson: can you do one more please? https://launchpad.net/ubuntu/+archive/test-rebuild-20120328/+build/3329862
[23:02] <cjwatson> micahg: done
[23:29] <micahg> please give back geda-gaf in the rebuild as well
[23:31] <cjwatson> micahg: done
[23:31] <micahg> cjwatson: gfccore also please
[23:33] <cjwatson> micahg: done
[23:44] <micahg> gfcui please as well
[23:46] <cjwatson> micahg: done
[23:47] <micahg> thanks
[23:54] <micahg> glabels also
[23:58] <cjwatson> micahg: done.  you know, I have scripts to search these things, if you just want to give me a build log regex ...
[23:59] <micahg> cjwatson: glib.h include :)
[23:59] <micahg> #error "Only <glib.h> can be included directly."