[05:20] <fabbione> morning guys
[05:27] <fabbione> buildd@sunfire:~/build$ sbuild -d feisty --comp=main gcc-4.1_4.1.1-18ubuntu1
[05:27] <fabbione> *** glibc detected *** ./pthread5.exe: corrupted double-linked list: 0x71700490 ***
[05:27] <fabbione> doko ^^^otherwise it builds fine
[09:23] <doko> fabbione: you did not run the testsuite in parallel, did you?
[09:24] <fabbione> doko: i just builded the package as you did it.. 
[09:24] <fabbione> dpkg-build...
[09:24] <fabbione> so if it's set to run in parallel then yes
[09:25] <fabbione> ld.so.1 (pid 7864): Privileged operation (code 10) at 401bc127   
[09:25] <fabbione> ld.so.1 (pid 9413): Protection id trap (code 7) at 400016a3                     
[09:25] <fabbione> ld.so.1(9618): unaligned access to 0x00010ae6 at ip=0x4010ce0b                  
[09:25] <fabbione> ld.so.1(10034): unaligned access to 0x00013736 at ip=0x4010b6ff                 
[09:25] <fabbione> ld.so.1(10718): unaligned access to 0x00010b06 at ip=0x4010ce0b                 
[09:26] <fabbione> MEH
[09:26] <fabbione> this can't be good
[09:37] <doko> which package?
[09:38] <fabbione> glibc-2.5 (hppa)
[09:38] <fabbione> anyway.. let's talk about sparc and 128 bits
[09:39] <fabbione> i just finished the second build of glibc-2.5 with newer gcc
[09:39] <fabbione> ls still works :)
[09:39] <fabbione> i am going to open the gates once i have the chroots ready
[09:54] <fabbione> gates are open
[10:33] <fabbione> libc6_2.5-0ubuntu1_hppa.deb
[10:33] <fabbione> whooopa
[10:36] <fabbione> ok we are getting tons of non fatal unalligned access with 2.5
=== ..[topic/#ubuntu-toolchain:fabbione] : STATUS: gcc: sparc (under testing) | hppa: bootstrapping needed (test in progress)
[10:44] <fabbione> we have the fix for ppc kernel
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-toolchain
[11:06] <cjwatson> argh, Ben's udeb changes are crack
[11:08] <fabbione> cjwatson: i told him.. he was going to talk to you at UDS
[11:10] <cjwatson> I've mailed him
[11:10] <cjwatson> I don't care about the storage stuff, but the filesystem changes will break things
[11:11] <cjwatson> newed, anyway
[11:11] <fabbione> nah pointless again :)
[11:11] <fabbione> it's still broken on ppc and sparc
[11:11] <fabbione> it seems that the changes got lost somehow
[11:12] <cjwatson> perhaps pointless, but harmless. :)
[11:12] <cjwatson> and I don't like excess stuff stuck in new
=== jerom2 [n=jeromeb@LSt-Amand-152-32-6-178.w82-127.abo.wanadoo.fr]  has joined #ubuntu-toolchain
=== jerom2 [n=jeromeb@LSt-Amand-152-32-6-178.w82-127.abo.wanadoo.fr]  has left #ubuntu-toolchain [] 
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[02:46] <jbailey> doko: Around?
[02:46] <doko> jbailey, fabbione, cjwatson, lamont: ping
[02:46] <doko> jbailey: yes :)
[02:46] <fabbione> doko: pongish
[02:46] <jbailey> =)
[02:46] <fabbione> i need 2 minutes break.. absolutely.. brb
[02:49] <cjwatson> doko: yes?
[02:49] <doko> about the ABI change on powerpc and sparc: long double changing from 64bit to 128bit
[02:50] <doko> glibc and libstdc++ are the only libs having both support for 64 and 128 long doubles
[02:51] <doko> how should we handle other libraries using long double datatypes in their interfaces?
[02:51] <doko> - rename the library packages
[02:51] <fabbione> re
[02:52] <doko> - do nothing (minor ABI breakagae on some archs), and rebuild the archive
[02:52] <fabbione> doko: do you have a list of packages affected?
[02:53] <doko> http://people.ubuntu.com/~doko/ldbl/  (these are all packages with a long[ _] *double string in their header files
[02:53] <fabbione> eh
[02:54] <cjwatson> I don't see that in http://gcc.gnu.org/gcc-4.2/changes.html
[02:54] <cjwatson> is this an undocumented ABI change or something?
[02:54] <cjwatson> oww, that's a lot of packages in main
[02:55] <fabbione> hold on.. those are headers.. what about stuff that B-D on those headers?
[02:55] <doko> fabbione: right, that's the next step ...
[02:55] <jbailey> doko: I'm confused.  The ldbl change is supposed to be ABI-neutral, no rebuild needed.
[02:56] <jbailey> doko: I thought we'd shown that the old symbols got provided?
[02:56] <doko> cjwatson: 4.2 is not yet released; these are backports from the fc 4.1 branch
[02:57] <cjwatson> if it's supposed to be ABI-neutral, and isn't, then that seems like a bug, and can we unbackport those changes? :P
[02:57] <doko> jbailey: yes for libc and libstdc++; but what about rebuilding a library libfoo and packages depinding on that library?
[02:58] <doko> depending even
[02:58] <jbailey> cjwatson: It's usually better to suck it up and follow upstream to be safe.
[02:58] <fabbione> this is going to be another clusterfuck.. i feel  it
[02:59] <jbailey> doko: Yeah, dunno.  I haven't followed all the header magic in that.  I don't know if there was some sort of compat macros or whatever that twiddled it transparently.
[03:00] <cjwatson> jbailey: if renaming lots of libraries is involved, I'd rather have some time to consider that rather than being forced to do it immediately
[03:00] <cjwatson> jbailey: especially if it might be a bug that gets fixed so we have to unrename everything later!
[03:01] <doko> jbailey: what does header magic solve for libraries which don't support both?
[03:01] <fabbione> cjwatson: it really depends on how soon you want to open feisty
[03:01] <fabbione> if there is really an ABI breakage we better deal with it before
[03:01] <fabbione> rather than later and collecting pieces with tons of uploads
[03:01] <cjwatson> isn't this a specs file thing?
[03:01] <cjwatson> -mlong-double-128
[03:01] <cjwatson> fabbione: I would like to have it open before UDS
[03:02] <fabbione> cjwatson: toolchain is not ready yet.. it's likely we can make it for UDS, but for example ppc is now stalling on elmo to install a new kernel on buildd and he is not around today.
[03:02] <jbailey> doko: Magic headers in the type definition, is what I'm thinking.
[03:02] <doko> see http://gcc.gnu.org/PR25864 for the detauls
[03:03] <doko> can't type anymore
[03:03] <fabbione> doko: could you before ? ;)
[03:05] <cjwatson> how practical is it likely to be to provide _Q_ functions in other affected libraries?
[03:05] <cjwatson> I'm not happy with a flag-day renaming of a bunch of libraries in main and all the upgrade pain that entails for the sake of two architectures, really
[03:06] <cjwatson> _Q_> or whatever the compatibility symbols are called
[03:06] <fabbione> cjwatson: what scares me is that we might trip in runtime errors during upgrades if we change ABI without renaming packages
[03:07] <fabbione> or een using upgrader itself that's written in python and python is one of those affected pkgs
[03:07] <cjwatson> if it's possible to provide compatibility symbols for both ABIs, that would solve that problem
[03:07] <doko> fabbione: there are not many extensions actually using long double
[03:08] <fabbione> cjwatson: right.. assuming we can
[03:08] <cjwatson> if it's doable in libc ...
[03:09] <fabbione> doko: can you write me a test case that will trip in that problem?
[03:09] <doko> cjwatson: what would that solve? having a "long double foo (long double)" function in libfoo, we would need to have these symbols in libfoo
[03:12] <cjwatson> EPARSE
[03:12] <fabbione> and i guess massive patching is not an option for the sake of 2 arches
[03:13] <cjwatson> library renaming that Debian isn't going to do for ages yet (given the etch freeze) counts as "massive patching"
[03:13] <cjwatson> I'd actually be happier with a bunch of library patches ...
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #ubuntu-toolchain
[03:14] <fabbione> cjwatson: hmmm massive code patching is more dangerous IMHO
[03:14] <fabbione> hi mdz
[03:14] <mdz> morning
=== ..[topic/#ubuntu-toolchain:fabbione] : STATUS: gcc: sparc (under testing) | hppa: bootstrapping needed (test in progress) | ppc needs fixed kernel on buildd (elmo informed)
[03:15] <cjwatson> doko: glibc clearly has code that uses the old-style long double type somehow
[03:15] <doko> cjwatson: "some arches" = sparc, sparc64, powerpc, powerpc64, s390, s390x, alpha
[03:16] <jbailey> cjwatson: glibc handles it by not actually using the real function names.
[03:16] <cjwatson> doko: i.e. powerpc and sparc from our point of view
[03:16] <jbailey> cjwatson: When you call open, it gets mapped to _open@GLIBC_2.4
[03:16] <fabbione> doko: for us is still sparc and ppc only
[03:16] <doko> cjwatson: no, it provides functions handling both the old and new data types
[03:16] <cjwatson> doko: yes, that's what I said
[03:16] <jbailey> cjwatson: They change symbol version for the new ABI.
[03:17] <cjwatson> jbailey: right, I know that, but the new glibc still builds the old _open@GLIBC_2.4 code with the current gcc
[03:17] <jbailey> Right.  I'm guessing that they still have a compat type sitting around that they use.  I don't know off hand.
[03:18] <cjwatson> yep, and if that compatibility type can be / is exported, it would not be that hard to make other libraries support both old and new ABIs
[03:18] <fabbione> ok.. is there any way i can have a test case?
[03:18] <fabbione> doko: ^^
[03:18] <fabbione> i have almost done rebuild edgy on top of feisty toolchain on sparc
[03:18] <fabbione> and i can test
[03:18] <fabbione> but i want test cases
[03:18] <fabbione> that should tell us if we need to do something fancy or not
[03:18] <cjwatson> also assuming that it's possible to call the GLIBC_2.4 code directly
[03:19] <cjwatson> (or do exceedingly cunning linker tricks to make that happen automatically for some objects)
[03:19] <fabbione> ROFL
[03:19] <cjwatson> fabbione: one of my concerns is that we have no established mechanism for ABI changes in perl and python
[03:20] <infinity> Speaking of ABI changes...
[03:20] <cjwatson> fabbione: I don't particularly want to establish one in a hurry (or at all, if we can get away with it)
[03:20] <fabbione> cjwatson: that's why i need a test case :)
[03:20] <fabbione> cjwatson:  i can test with old and new stuff
[03:20] <infinity> jbailey: Is glibc/hppa still going to give us a broken ABI, and should I whip up a clever script to find every package that's not changed since dapper, so I can make sure they get rebuilt? :)
[03:20] <fabbione> infinity: hppa will be rebuilt in full.. no matter :)
[03:21] <fabbione> infinity: we lost an entire release
[03:21] <infinity> fabbione: Yes, hence the "find things that haven't changed since dapper".
[03:21] <infinity> fabbione: We still ship packages that haven't changed since warty, you know.
[03:21] <fabbione> i don't think there is something left :)
[03:21] <fabbione> infinity: probably because nobody uses them ...
[03:21] <infinity> Some just don't need updates. :)
[03:21] <fabbione> exactly :)
[03:21] <cjwatson> $ ./suite-diff.py ubuntu/dists/warty/main/binary-i386/Packages.gz ubuntu/dists/edgy/main/binary-i386/Packages.gz eq | wc -l
[03:22] <cjwatson> 28
[03:22] <infinity> I maintain one that hasn't changed since dapper. *shrug*
[03:22] <cjwatson> $ ./suite-diff.py ubuntu/dists/warty/universe/binary-i386/Packages.gz ubuntu/dists/edgy/universe/binary-i386/Packages.gz eq | wc -l
[03:22] <cjwatson> 806
[03:22] <infinity> cjwatson: I see I'm not the first person to want this statistic. :)
[03:22] <infinity> Anyohw, 28/806 is very workable.  Cool.
[03:23] <jbailey> infinity: Totally changed thread ABI.
[03:23] <cjwatson> I use suite-diff more for ge, gt, le, lt comparisons, but eq is occasionally handy and was trivial to implement
[03:23] <infinity> And main's all I care about initially anyway.
[03:23] <cjwatson> infinity: one sec and I'll give you dapper->edgy figures
[03:24] <infinity> jbailey: Right, so after bootstrapping the toolchain, I'll want to rebuild everything in {Build-,}Essential, and then move up the chain.  Fun.
[03:24] <infinity> cjwatson: Oh, that was warty.  I wasn't paying attention.
[03:24] <jbailey> infinity: It's an interesting experiment to see how ugly a bootstrap is these days.
[03:24] <cjwatson> infinity: counting by source package:
[03:24] <cjwatson> main: 478
[03:24] <cjwatson> restricted: 1
[03:24] <cjwatson> universe: 3885
[03:24] <cjwatson> multiverse: 258
[03:24] <infinity> jbailey: Shouldn't be too bad, and for all that I complain about them, the hppa buildds are still pretty quick.
[03:25] <cjwatson> feel free to go "dear god" now
[03:25] <infinity> cjwatson: Those figures sound more correct anyway. :)
[03:25] <infinity> edgy's short cycle didn't help there.
[03:26] <infinity> We might get those numbers down just with the initial round of merge/sync madness.
[03:27] <infinity> But, whatever.  Worst case, I just do a mess of rebuild uploads.  Serves a dual purpose of fixing hppa, and getting the rest of the arches built against a modern toolchain.
[03:27] <infinity> hppa's simple, just time-consuming.
[03:27] <infinity> This long double thing sounds far more icky.
[03:27] <fabbione> infinity: hppa is a pain at the moment.. second round of glibc build will fail but we have our super-Jeff on it
[03:28] <infinity> Oh, it's not self-hosting yet?  Fun.
[03:28] <fabbione> infinity: and you really want to take the debs i did build to get to gcc B-D
[03:28] <fabbione> infinity: yes.. it's a header issue that shows up only at the second rebuild
[03:28] <infinity> fabbione: Yeah, I'll use your bootstrap stuff, thanks.  It'll be several rebuilds before I get to the final archive debs anyway, so I don't mind the taint.
[03:29] <fabbione> infinity: i know, they are just useful.. it's building gcc for feisty now.. that will come handy too
=== infinity hopes no one quotes him out of context as saying "I don't mind the taint".
[03:29] <fabbione> doko: ok.. so what is your suggestion on how to handle this ABI breakage+
[03:29] <fabbione> ?
[03:29] <infinity> I suspect I won't fully open hppa until I get back from UDS and have my 6750 powered on anyway.
[03:30] <infinity> But the primary arches should, ideally, be opened in the next two or three days, if we can at all manage.
[03:30] <fabbione> infinity: or we can play with it together.. i have console on mine
[03:30] <fabbione> and your has also remote power capabilities.. that's even better
[03:30] <fabbione> ok should we do a summary before my wife will kill me?
[03:30] <infinity> fabbione: Well, I'll have a console on mine as soon as I've visited a Frys in SF and bought a USB->Serial dongle. :)
[03:30] <fabbione> (i was supposed to be out of the office 2 hours ago)
[03:31] <fabbione> i think i386/amd64 are fine.. at least so it seems
[03:31] <infinity> fabbione: And yeah, the DC ones have remote power that I can mangle from anywhere, which is rather handy in light of the hppa kernel's... Oddities.
[03:31] <fabbione> infinity: i am not running .19 kernel.. only dapper kernels
[03:31] <fabbione> ppc needs a new kernel. the patch is in pitti/elmo hands
[03:31] <doko> fabbione: last time we had an arch specific ABI change on sparc in unstable, we didn't do anything
[03:32] <fabbione> sparc/ppc have the ABI issue
[03:32] <fabbione> ia64 looks good
[03:32] <fabbione> hppa whatever...
[03:32] <cjwatson> doko: powerpc is first-class and released; IIRC last time sparc wasn't
[03:32] <fabbione> sparc is released now and first-class on enterprise servers
[03:32] <infinity> doko: Is this the sort of ABI breakage that will royally mess up upgrades (ie: postinst scripts dying and the like)?  If so, "just ignoring it" isn't going to cut it.
=== fabbione hides a bit
[03:33] <cjwatson> if it stands a decent chance of not breaking during upgrades (and that sounds plausible; do upgrades really require serious floating-point code?), then ignoring it is an option I'd certainly consider
[03:33] <infinity> Yeah, that's the point I was driving at.
[03:33] <infinity> Unlike Debian, we don't really pretend to support partial upgrades.
[03:33] <fabbione> cjwatson: i can test scenario too
[03:33] <cjwatson> thought I'd emphasise it the other way round. :-)
[03:34] <infinity> So, I'm cool with "once your upgrade has settled, you'll be okay"... If the upgrade can go smoothly.
[03:34] <fabbione> but i need a couple of more days to get there
[03:34] <fabbione> otherwise somebody needs to ship me another T2000 and i could run 64 buildd
[03:34] <cjwatson> infinity: and if we can figure out how to do compatibility code for this, we could do that just for libraries that break during upgrade, if any
[03:34] <infinity> fabbione: You have enough toys.. Share with the class. :P
[03:34] <fabbione> infinity: ehhe
[03:35] <infinity> cjwatson: Fair point.
[03:35] <fabbione> cjwatson: that's even scarier.. 
[03:35] <fabbione> but well whatever
[03:36] <fabbione> infinity: can you get Ben to upload a working kernel today?
[03:36] <doko> right, that was my thinking. there shouldn't be too much code (if any) which needs floating point arithmetics in installation/removal
[03:36] <cjwatson> fabbione: surely it's less scary
[03:36] <infinity> fabbione: I tried that yesterday. :)
[03:36] <cjwatson> given that it involves less work and less code
[03:36] <infinity> (But yes, I'll try again)
[03:36] <fabbione> infinity: try harder? ;)
[03:36] <fabbione> jbailey: is binutils ok for you to upload or does it need more?
[03:36] <fabbione> doko: did you review binutils?
[03:37] <doko> fabbione: yes, looks fine to me
[03:37] <doko> jbailey: ^^^
[03:37] <fabbione> i know we lack a patch for hppa that miscompile the kernel, but we CAN live with an unbootable hppa kerenl for bootstrapping
[03:37] <jbailey> fabbione: I'm happy with it from ppc/ppc64/hppa tests.  I haven't looked at i386/amd64.  Given that it's HJ, I suspect those and ia64 are pretty guaranteed.
[03:37] <jbailey> fabbione: Yes, that's fine.
[03:37] <fabbione> jbailey: ok.
[03:37] <infinity> Unbottable hppa kernels don't matter to me right now.
[03:37] <fabbione> infinity: neither for me
[03:37] <fabbione> jbailey: what about glibc debian/patches?
[03:38] <infinity> If you guys are happy with binutils, toss it in the queue SVP.
[03:38] <fabbione> should we go with what we have and review later?
[03:38] <jbailey> fabbione: I want to commit what I've got in there.  The Debian patches cause one of the tests to segfault.
[03:38] <fabbione> jbailey: ok.
[03:38] <jbailey> (yay debian)
[03:38] <fabbione> jbailey, doko: i am going to upload binutils then.
[03:38] <fabbione> i did check the testsuite with .17 and .19 hreaders
[03:38] <fabbione> there is no difference
[03:38] <fabbione> so it doesn't matter to wait for the new kernel
[03:39] <jbailey> Cool.  I'm happy to see binutils go in.
[03:39] <jbailey> fabbione: You're putting in the same one that I put into bzr?
[03:39] <infinity> And binutils passes its testsuite with no regressions regardless of whether it's built against edgy or feisty?
[03:39] <fabbione> jbailey: yes and the same orig
[03:39] <infinity> (ie: Can I build it now, now, now?)
[03:39] <fabbione> infinity: yes it can build now now
[03:40] <infinity> \o/
[03:40] <jbailey> fabbione: Do you know any timeframe for the kernel patch going in for ppc?
[03:40] <infinity> jbailey: Being applied on the buildds, you mean?
[03:40] <fabbione> jbailey: i guess tomorrow... elmo is not around today
[03:40] <fabbione> infinity: yes
[03:40] <jbailey> fabbione: I have Angie's ultrasound midday today, but I'd like to beat on this when I'm back to get that patches directory in shape.
[03:40] <infinity> I can get Znarl to do it.
[03:40] <jbailey> Lovely, so there's no pressure for today for glibc going in.
[03:40] <infinity> Oh, unless you want the breathing room.
[03:40] <infinity> Then I'll, uhm, not get Znarl to do it.
[03:41] <fabbione> infinity: i have the patch and i can send it to Znarl, but we still need to jump to edgy .17
[03:41] <fabbione> infinity:  i didn't test the patch on dapper yet
[03:41] <infinity> Should apply to .15 without terrible issues, I'd suspect.
[03:42] <infinity> On the other hand, we wanted the PPC buildds upgraded to edgy kernel source for other reasons.
[03:42] <fabbione> yes it might apply but it's not tested and you don't want to DoS the buildd.. do you?
[03:42] <infinity> Some sketchy build failures that were kernel-releated.
[03:42] <infinity> related, too.
[03:44] <fabbione> infinity: well elmo will have to speed that up a lot
[03:44] <infinity> I've got a laundry list of things to talk to elmo about, so I'll make sure this gets done.
[03:44] <infinity> (Still have some sketchiness on jackass to deal with, which takes priority, but only barely)
[03:45] <fabbione> infinity: he has the patch in an email
[03:45] <infinity> I know, you CC'd me, remember? :)
[03:45] <fabbione> infinity: i did? ok
[03:46] <infinity> Oh, looks like the buildds went to edgy kernels when I wasn't looking anyway.
[03:46] <fabbione> no i didn't
[03:46] <infinity> That makes life easier.
[03:46] <fabbione> binutils on the way
[03:46] <fabbione> jbailey: does bzr support tagging?
[03:46] <fabbione> no it doesn't
[03:46] <jbailey> fabbione: I remember there was a spec for it, dunno where that got to.
[03:46] <fabbione> jbailey: ok...
[03:46] <infinity> fabbione: "local DoS fix for ppc", sent to elmo, CCd to pitti and I.
[03:46] <jbailey> j-a-meinal will be on in an hour or so usually, we can ask him.
[03:46] <fabbione> infinity: BenC is around!
[03:46] <infinity> fabbione: Your memory's failing in your old age. :)
[03:47] <jbailey> infinity: Why not the RT queue so that one of the other sysadmins can deal with it?
[03:47] <fabbione> infinity: screw you old boy! :P
[03:47] <fabbione> jbailey: because they don't do kernel stuff.. i did ask on -sysadmin
[03:47] <infinity> Znarl does kernels occasionally.
[03:48] <fabbione> infinity: up to you.. without that kernel ppc boxes will die like KITTIES if we upload glibc :)
[03:48] <fabbione> infinity: binutils uploaded
[03:49] <infinity> Does it cause the build to fail, or just cause the machine to Zombie half to death?
[03:49] <infinity> Cause I *do* have remote power on them. :)
[03:49] <fabbione> machine will die
[03:49] <infinity> Right, not pleasant.  Will wait.
[03:49] <fabbione> and the build won't finish
[03:49] <fabbione> it's pointless
[03:50] <jbailey> infinity: reboot -f works, too. =)
[03:50] <jbailey> fabbione: I never reproduced machine death.
[03:50] <fabbione> jbailey: i did
[03:50] <jbailey> Just the Hallowe'en drama of things running around yelling "GRAAAAIIIIINNNNSSSS...."
[03:51] <fabbione> This upload awaits approval by a distro manager
[03:51] <fabbione> infinity: ^
[03:51] <infinity> fabbione: Yes dear. :)
[03:51] <fabbione> slacker! do you want to accept the upload?
[03:51] <fabbione> i got this email more than 60 secs ago! :P
[03:51] <infinity> I'm on it, I'm on it.
[03:51] <infinity> Punk.
[03:51] <fabbione> you are getting slow.. must be the age
[03:51] <fabbione> MUHHAHAHA
[03:51] <infinity> No, it's the latency.
=== fabbione claims revenge
[03:52] <fabbione> yeah between fingers and eyes
[03:52] <jbailey> fabbione: Bah..  When *I* was young...
[03:52] <infinity> Takes 12 minutes to do an SSH handshake between .au and the DC.
[03:52] <jbailey> infinity: Throw *out* the m68k, dude. =)
[03:52] <fabbione> jbailey: speaking of which.. congratulation.. your bday was yesterday?
[03:52] <jbailey> fabbione: Yeah, thanks.
[03:52] <infinity> jbailey: *grin*
[03:53] <fabbione> there.. i guess we are all set.. more or less
[03:53] <infinity> Getting there.
[03:53] <fabbione> infinity: yeah...
[03:54] <fabbione> jbailey: ok.. i will be back later this evening...
[03:54] <fabbione> jbailey: so we can look again at glibc
[03:54] <fabbione> doko: are you ready to upload gcc?
[03:54] <jbailey> fabbione: 'kay.  I'll try to run the glibc stuff today over the day, but will focus on it tongiht.
[03:54] <jbailey> I'll also get some more hppa love going.
[03:54] <jbailey> I've just sent a final "we're doing this, any questions?" email to the parisc list.
[03:54] <fabbione> jbailey: ok. your tonight is my deep night... should i shift working hours?
[03:55] <jbailey> Nope, there's not much to share except scrolling consoles.
[03:55] <fabbione> i don't mind it at all.. i just need to know so that we can work closer
[03:55] <fabbione> ok
[03:55] <fabbione> we can still share the orgasms on each line text
[03:55] <jbailey> fabbione: More useful to have you work when I'm asleep for a final test with goal of upload tomorrow.
[03:55] <fabbione> jbailey: ok perfect works for me
[03:55] <fabbione> by tomorrow i should have enough sparc debs to do some kind of tests
[03:56] <fabbione> ok dok
[03:56] <fabbione> oky doky
[03:56] <fabbione> i am off
[03:56] <infinity> fabbione: Did you forward that ppc fix to BenC too, for inclusion in edgy-updates?
[03:56] <fabbione> infinity: i think i did?
[03:56] <fabbione> infinity: wasn't he in the email?
[03:56] <infinity> Not in the same email you sent me.
[03:56] <jbailey> fabbione: I'd imagine benh will submit it for the . release, won't he?
[03:57] <fabbione> infinity: ok. i will talk to him once benh gives me the greenlight for stable release
[03:57] <fabbione> jbailey: yes i am sure he will
[03:57] <infinity> Kay.
[03:57] <fabbione> infinity: there are 2 solutions to that problem.. really
[03:57] <fabbione> one is the patch
[03:57] <fabbione> and one is to disable a couple of syscalls in the kernel
[03:57] <doko> fabbione: davis:~doko/gcc/4.1/tst/
[03:58] <fabbione> doko: what's that?
[03:58] <fabbione> doko: ok thanks.
[04:00] <fabbione> later guys
=== fabbione takes off
[04:00] <fabbione> infinity: and yes.. even pigs can fly given enough thrust
[04:01] <infinity> It's not nice to talk about my mother that way.
[04:01] <jbailey> And with the image of FAbio thrusting a pig...  Off to the office I go.
[04:02] <fabbione> infinity: i miss the association with your mother... if it's there for some reasons it was REALLY not meant
=== jbailey [n=jbailey@montreal.canonical.com]  has joined #ubuntu-toolchain
[10:06] <fabbione> doko: i did build that test case on edgy and it segfaults
[10:06] <fabbione> doko: should i try on feisty and it should work.. right?
[10:06] <fabbione> or the other way around?
[10:10] <fabbione> doko: it segfaults also when built with feisty toolchain
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-toolchain
=== anibal_ [n=anibal@debian/developer/anibal]  has joined #ubuntu-toolchain
=== doko_ [n=doko@dslb-088-073-093-229.pools.arcor-ip.net]  has joined #ubuntu-toolchain
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[11:57] <jbailey> doko: There are libgcc-compat patches in here to expose some extra symbols.  I wonder if they actually matter to anyone.
[11:57] <jbailey> They're old versions, so nothing new will build with them.
[12:00] <doko> jbailey: disconnected, maybe I did miss something?
[12:02] <jbailey> doko: No, sorry.  I started mid-thought.
[12:02] <jbailey> I'm reviewing all of the glibc patches again.
[12:02] <jbailey> glibc for awhile leaked some libgcc symbols directly.
[12:03] <jbailey> When Jakub fixed up glibc to not leak stray things, he removed these, but we brought them back.
[12:03] <jbailey> Sadly, there's no explanation *why* we did this, and I was wondering if we should maybe not do so.
[12:03] <jbailey> Not important for right now, but probably something to look at for feisty+1
[12:04] <jbailey> But it might be nice to start stripping out some of these patches.
[12:05] <doko> ok
[12:06] <doko> jbailey: I'm not opposed to a feisty+1 toolchain roadmap, but I think we can do better than the edgy+1 roadmap; we should discuss this next week.
[12:07] <jbailey> I don't think we booked a bof for it. =)