=== doko_ [n=doko@dslb-088-073-066-174.pools.arcor-ip.net]  has joined #ubuntu-toolchain
=== Keybuk [n=scott@217.205.109.249]  has joined #ubuntu-toolchain
[10:40] <fabbione> doko_: ping?
[10:41] <doko_> fabbione: pong
[10:41] <fabbione> doko_: what gcc do you expect for feisty?
[10:41] <fabbione> i have glibc-2.5 almost done
[10:44] <doko_> currently 4.1; 4.2 is not released, and probably will take longer.
[10:44] <fabbione> doko_: so the same gcc we have now in edgy?
[10:44] <doko_> so we have to backport the relevant binutils changes
[10:44] <fabbione> or are you adding extra patches and stuff like that?
[10:44] <fabbione> we will need a very new binutils to get hppa back in the game
[10:44] <fabbione> AFAIK Jeff is looking at it
[10:44] <doko_> fabbione: no, extra patches, long double 64->128 bit ABI change on powerpc and sparc
[10:44] <fabbione> doko_: ok, can you please let me have a source to build before monday?
[10:44] <doko_> fabbione: unreleased? an alternative might be the HJ Lu binutils for feisty
[10:44] <fabbione> or if you have it done.. now
[10:44] <fabbione> doko_: yes unreleased..
[10:44] <fabbione> dunno.. i hate binutils from the bottom of my heart
[10:44] <fabbione> it freaks me out...
[10:44] <doko_> it's not my toy package either
[10:45] <fabbione> eheh
[10:45] <fabbione> what i am done up till now is to merge all the packaging bits for glibc. i will need help from Jeff to review debian/patches
[10:45] <doko_> I'll prepare gcc either over the weekend or today
[10:45] <fabbione> and that's basically done
[10:46] <fabbione> but i want to simulate a bootstrap over all my machines
[10:46] <fabbione> build gcc with old gcc
[10:46] <fabbione> build gcc
[10:46] <fabbione> build kernel (that i know is going to suck)
[10:46] <fabbione> rebuild glibc and gcc and kernel again for fun and profit
[10:46] <fabbione> that would be lovely.. thanks
[10:47] <fabbione> if we can have at least part of the toolchain ready before we open feisty that will be great
=== mlpug [n=user@a84-231-238-186.elisa-laajakaista.fi]  has joined #ubuntu-toolchain
=== Dvalin [i=hawkeye@195.0.160.130]  has joined #ubuntu-toolchain
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-toolchain
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[03:46] <jbailey> fabbione: Yeah, what you said.
[03:46] <jbailey> =)
[03:46] <fabbione> ehe
[03:47] <fabbione> i was saying that my target now is to 2.5 out for opening
[03:47] <fabbione> then we can cleanup as much as we want
[03:47] <jbailey> Yup.
[03:47] <fabbione> afaict the only thing missing now for an upload is debian/patches/ubuntu from 2.4 to 2.5
[03:47] <jbailey> I need to merge in ports stuff for hppa/
[03:47] <jbailey> And get the TLS patches in for binutils.
[03:47] <fabbione> and decide if we want NPTL or LT for hppa...
[03:47] <jbailey> The nice part is that I now feel comfortable enough with BFD to do that.
[03:48] <jbailey> No LT.
[03:48] <fabbione> ok
[03:48] <fabbione> i can fix that easily
[03:48] <jbailey> Our .orig.tar.gz shouldn't even have the tar.bz2 in there.
[03:48] <fabbione> well it has for now..
[03:48] <jbailey> But just in general.
[03:48] <fabbione> should we kill it?
[03:48] <fabbione> yeah
[03:48] <jbailey> We're not Debian, we don't drag corpses behind us chained to the bumper.
[03:49] <fabbione> ahah
[03:49] <fabbione> there are a few entries in debian/changelog marked as (requires testing) or (requires review)
[03:49] <fabbione> that's because i am not 100% of the reason why that stuff is there
[03:52] <jbailey> The only thing that I see in there off hand is that some of the changes done directly to control.in/{main,opt} might be best done in sysdeps/depflags.pl
[03:52] <jbailey> I *hate* sysdeps/depflags.pl
[03:52] <jbailey> That was about where I ran out of steam redoing the packages for Debian in 2003.
[03:53] <jbailey> What I think it should be is a tab delimited table or something like that which sits in control.in
[03:54] <jbailey> Maybe a few different files, conflicts, depends, etc.
[03:54] <jbailey> ARCH\tPACKAGE\tVERSION
[04:00] <fabbione> imho we could simplify the packaging a lot with a set of shell scripts
[04:01] <fabbione> or start eliminating tons of .mk stuff
[04:01] <jbailey> There's a surprising amount of this that *can't* be simplified once you start to look at what it does.
[04:01] <jbailey> But certainly half of rules.d/debhelper.mk can go.
[04:02] <jbailey> I thought quilt provided a rules snippet to include, so I'm not sure why we have our own.
[04:08] <doko_> the tarball approach can go again; it was for the binutils-source package, elmo did prefer to have patched sources in this patch, so we can revert that again.
[04:08] <doko_> but keeping the binutils-source package
[04:09] <jbailey> doko_: I've wondered a few times if it's better to use the upstream binutils releases or HJ Lu's snapshots, since his snapshots tend to include extra optimisation instructions and such.
[04:10] <jbailey> But are still sort of crack-of-the-moment.
[04:10] <jbailey> With his snapshots, we'dhave the HPPA TLS stuff already.
[04:10] <jbailey> Otherwise we'll have to backport them to get hppa working.
[04:13] <doko_> jbailey: yes, I was thinking about it as well. but then, how switch back to FSF binutils without having any regressions?
[04:14] <jbailey> Dunno.  I've never understood why the binutils release cycle is so slow.
[04:15] <jbailey> The changes that tend to go in there seem to be consistantly just opcode adds, etc.
[04:17] <doko_> if we can track these changes in a separate branch?
[04:18] <jbailey> I don't think we have the bodies on toolchain to do that sort of work.
[04:18] <jbailey> Since that drags the QA responsibility for those things onto us.
[04:18] <jbailey> I think it just wouldn't get done in the end.
[04:21] <fabbione> jbailey: i am getting a feisty amd64 chroot on ronne. the debs look good
[04:22] <fabbione> jbailey: at least debdiff did spot only 2 changes.. one i knew about but we don't care (it's ppc only) and the other one it's just an extra file that needs investigation
[04:34] <jbailey> We don't care about ppc anymore? =/
[04:35] <fabbione> it's already fixed in bzr.. i didn't feel restarting the builds for a ppc thingy
[04:35] <fabbione> but at least i know it is fixed properly
[04:39] <fabbione> dh_install: libc6-dev missing files (debian/tmp-libc/usr/lib/nptl*), aborting
[04:39] <fabbione> GRRRRRRRRRRRRRRR
[05:06] <jbailey> Right, debhelper 5 broke that construct, sadly.
[05:06] <jbailey> I pouted at Joey for it.
[05:06] <jbailey> foo* doesn't resolve to empty set in a glob anymore.
[05:08] <fabbione> i don't think we ship anything with that name anyway
[05:09] <fabbione> i386/ia64 did fail
[05:09] <fabbione> amd64 is rebuilding and waiting sparc/ppc
[05:10] <fabbione> we might as well chop it away if it's not required
[05:17] <fabbione> (feisty-libc)fabbione@ronne:/lib$ 
[05:17] <fabbione> well.. they seem to work on amd64 at least
[05:25] <jbailey> whee =)
[05:26] <fabbione> waiting for all the builds to complete.. then i will respin with that postinst fix and the nptl fix
[05:26] <fabbione> i am sure locales are broken
[05:27] <fabbione> because we need to port the patch for belocs and the other search path from 2.4
[05:27] <fabbione> but at least we know that we can run
=== __keybuk [n=scott@217.205.109.249]  has joined #ubuntu-toolchain
[06:56] <Dvalin> fabbione: what gcc do you guys use to build kernel?
[06:56] <fabbione> gcc-4.1
[06:56] <Dvalin> okay
[06:56] <fabbione> Dvalin: doko is our gcc god here
[06:56] <Dvalin> yes
[06:56] <Dvalin> that's why I ask in here ;)
[06:57] <Dvalin> I have this weird issue
[06:57] <fabbione> yeah but you are building on *mandriva*
[06:57] <fabbione> you have issues.. no matter :
[06:57] <fabbione> :P
[06:57] <Dvalin> with the atyfb driver, I tried recompiling the same old kernel where it was working
[06:57] <Dvalin> with current toolchain, not what I compiled it at that time
[06:58] <fabbione> oh you are suspecting a gcc breakage?
[06:58] <Dvalin> otherwise everything being the same, and problem exist in the same kernel release which previously worked (even with the same config)
[06:58] <Dvalin> yes
[06:58] <fabbione> Dvalin: i suggest you try with -O0 and check the asm output
[06:59] <fabbione> in theory it should be the same
[06:59] <Dvalin> I'm thinking about trying to build with gcc 4.0.3 which I built last working kernel with..
[06:59] <Dvalin> fabbione: okay, good tip, for checking the asm output.. I think you overestimating me ;)
[06:59] <fabbione> Dvalin: nah.. that was a trick doko handed to me
[07:00] <Dvalin> checking the asm output? or -O0?
[07:00] <fabbione> asm output
[07:00] <fabbione> and -O0 ;)
[07:00] <fabbione> both
[07:01] <Dvalin> okay
[07:01] <Dvalin> I'm not competent at asm stuff.. ;p
[07:02] <Dvalin> but I did score 100% at a simple asm asisgnment at an exam last spring ;)
[07:02] <Dvalin> harrharr
[07:02] <Dvalin> I think that landed me the C in stead of E which otherwise would be the final grade :p
[07:03] <infinity> You don't need to write asm fluently to be able to compare it.
[07:03] <Dvalin> ah
[07:03] <infinity> (Thank god, too, because my i386 asm is less than perfect)
[07:03] <Dvalin> I see your point :)
[07:04] <infinity> Useless architectures, like m68k, powerpc, hppa, and sparc.  Sure, they're easy. :P
[07:04] <infinity> i386, not so much.
[07:05] <Dvalin> hehe
[07:05] <Dvalin> "useless"
[07:05] <Dvalin> quite a bombastic statement, no? ;)
[07:05] <infinity> Yes, that belonged in quotes.  I missed adding the irony. :)
[07:28] <jbailey> infinity: hppa can be annoyingly hard to read.  It appears to be able to unable to load 32 bits into a register in a single operation.
[07:29] <fabbione> jbailey: ia64 glibc are good
[07:29] <fabbione> if i could only get sparc to complete the testsuite without a kernel crash
[07:29] <fabbione> jbailey: i am uploading all the debs here: http://people.ubuntu.com/~fabbione/glibc-2.5/
[07:29] <jbailey> Joy.
[07:29] <fabbione> amd64 is good too
[07:29] <jbailey> Does it crash in a consistant place?
[07:29] <fabbione> i386 will test tomorrow
[07:29] <fabbione> it's a kernel problem.. 
[07:30] <fabbione> it lockups on high load
[07:30] <fabbione> i need to downgrade to edgy kernel
=== fabbione was running 2.6.19-rc2
[07:30] <jbailey> Any idea if Ben is going to target 2.6.19 or 2.6.20 for fiesty?
[07:31] <fabbione> .19 afaik
[07:31] <fabbione> 9391 fabbione  21   0  5088  448  304 D  300  0.0   9:22.63 ld-linux.so.2
[07:31] <fabbione> now i have a process on 400 of CPU
[07:32] <jbailey> fabbione: Any idea when we're targetting to open the next one?
[07:32] <jbailey> I remember that edgy had some hitches, openning up.
[07:32] <fabbione> the kernel is already in git
[07:32] <fabbione> we need to get a few important things fixed
[07:32] <fabbione> like that headers issue i was mentioning
[07:32] <fabbione> otherwise we won't even be able to rebuild the kernel
[07:32] <jbailey> Headers issue?
[07:33] <fabbione> yes.. build .19
[07:33] <fabbione> install linux-libc-dev
[07:33] <fabbione> and you are doomed: )
[07:33] <fabbione> you can't even rebuild the kernel with that stuff
=== jbailey knows of ia64 klibc headers and ppc merging ppc and ppc incorrectly.
[07:33] <fabbione> it's totally broken
[07:33] <jbailey> Err.
[07:33] <fabbione> no.. this is worst
[07:33] <jbailey> Kernel builds with -nostdinc.
[07:33] <jbailey> Nothing in /usr/include should matter in the slighjtest.
[07:33] <fabbione> not the scripts/*
[07:33] <fabbione> and you need those
[07:34] <fabbione> like.. hmmmm modpost?
[07:34] <jbailey> I don't think I know about those.
[07:34] <fabbione> you use them all the time.. you just don't know that :)
[07:34] <jbailey> Can you toss a build failure into a pastebin?
[07:34] <fabbione> jbailey: sure.. in a minute 
[07:34] <jbailey> No worries.
[07:35] <fabbione> no actually i can't.. i don't have the deb handy..
[07:35] <fabbione> but i can show it here by memory
[07:35] <fabbione> #include <errno.h>
[07:35] <fabbione> #include <sys/socket.h>
[07:35] <fabbione> int main() {
[07:35] <fabbione> return -EINVAL;
[07:36] <fabbione> return -SOL_SOCKET;
[07:36] <fabbione> }
[07:36] <fabbione> you can't build that one
[07:36] <jbailey> Right, but I'm curious about the actual failure.
[07:37] <fabbione> it's an include order issue
[07:37] <fabbione> either SOL_SOCKET or EINVAL is not defined
[07:37] <fabbione> if you swap the include's at the top, you get the other error
[07:37] <doko_> gcc-4.1_4.1.1-17ubuntu1 is on ronne:~doko/gcc/4.1/
[07:38] <fabbione> doko_: cool.. there is a feisty-libc chroot (amd64) on ronne
[07:38] <fabbione> doko_: 
[07:38] <doko_> enabling long-double-128 on powerpc and sparc, configuring with --enable-secureplt on powerpc
[07:38] <fabbione> you can build there if you like
[07:38] <fabbione> it has glibc-2.5 installed
[07:38] <fabbione> doko_: i will do ia64/ppc/sparc/i386 tomorrow
[07:38] <fabbione> i am just too tired today to do it
[07:38] <fabbione> actually.. i could do ia64 overnight
[07:39] <fabbione> ii  libc6.1        2.5-0ubuntu1   GNU C Library: Shared libraries
[07:41] <jbailey> doko_: Do you happen to know what binutils FC6 is shipping with?  I remember that they have the GNU HASH lookups for the PLT stuff as one of their features.
[07:41] <jbailey> But I think that requires a new binutils snapshot.
[07:42] <doko_> http://cvs.fedora.redhat.com/viewcvs/devel/binutils/
[07:42] <doko_> 2.17.50
[07:43] <doko_> 2.17.50.0.6, the version number smells like beeing the HJ stuff ...
[07:44] <fabbione> doko_: gcc-4.1 building on ia64
[07:44] <fabbione> doko_: do you want to ask B-D on feisty-libc chroot or should I? i can do the others locally
[07:45] <doko_> they were installed
[07:45] <doko_> currently building on feisty
[07:45] <fabbione> hmm ok
[07:45] <fabbione> good
[08:15] <jbailey> Hmm, here's going to be an interesting question.
[08:15] <jbailey> Some of the libc tests probably need corresponding kernel functions to pass.
[08:15] <fabbione> jbailey: ?
[08:15] <jbailey> What do the buildds run for a kernel>
[08:15] <fabbione> oh yes.. i already noticed that
[08:16] <fabbione> 2.6.17 basically everywhere
[08:16] <fabbione> i saw a bunch of test failures
[08:16] <fabbione> but i didn't track them down yet
[08:16] <fabbione> and i don't think for bootstrapping we care too much
[08:16] <jbailey> If you toss those into a pastebin somewhere, I might be able to offer you opinions on them.
[08:17] <fabbione> jbailey: ronne:/home/fabbione/{i386,amd64}/
[08:17] <fabbione> ppc is on davis
[08:17] <fabbione> i can upload sparc and ia64 later
[08:18] <fabbione> davis is still building FYI
[08:19] <fabbione> oh acutally i did build ia64 with .19
[08:20] <jbailey> make[3] : bug-atexit3-lib.cc: Command not found
[08:20] <jbailey> make[3] : *** [/home/fabbione/i386/glibc-2.5/build-tree/i386-i686/dlfcn/bug-atexi
[08:20] <jbailey> t3-lib.os]  Error 127
[08:20] <jbailey> Eh, weird.
[08:20] <jbailey> Oh, no G++ installed.
[08:21] <fabbione> scp glibc-2.5.tar.bz2 chinstrap.ubuntu.com:glibc-2.5-ia64-log.tar.bz2
[08:22] <fabbione> jbailey: uh? i did use dpkg-buildpackage.. do we miss a B-D ?
[08:23] <jbailey> checking for g++... g++
[08:23] <fabbione> hmmm
[08:24] <fabbione> i readded the CXX patch from you...
[08:24] <fabbione> could that be related?
[08:24] <jbailey> 604-421-2460 604-726-2460
[08:24] <jbailey> ls
[08:24] <jbailey> BAH
[08:24] <fabbione> 0wn3d
[08:29] <Dvalin> mm/filemap.c: In function ?__generic_file_aio_write_nolock?:
[08:29] <Dvalin> mm/filemap.c:1830: sorry, unimplemented: inlining failed in call to ?generic_write_checks?: function body not available
[08:30] <Dvalin> mm/filemap.c:2133: sorry, unimplemented: called from here
[08:30] <Dvalin> fabbione: are you sure you actually can compile the kernel with -O0?
[08:30] <fabbione> Dvalin: i am pretty sure you can
[08:31] <Dvalin> hmm
[08:31] <Dvalin> then I don't get why I get that error when compiling with -O0
[08:31] <Dvalin> will try again with -O2 to see if it reproduces
[08:31] <fabbione> i usually compile only the bits i need with -O0
[08:31] <Dvalin> okay
[08:32] <Dvalin> so in other words, you don't know for sure that the *whole* kernel can be compiled with -O0?
[08:32] <fabbione> no but it should be able to
[08:32] <Dvalin> soo
[08:32] <Dvalin> the error I got, a bug in kernel?
[08:34] <fabbione> or gcc
[08:35] <fabbione> it really depends what you are experimenting with
[08:35] <jbailey> fabbione: It's entirely possibly that the kernel relies on optimiser tricks for correct code.
[08:35] <jbailey> You can't compile glibc at -O0 for instance.
[08:35] <fabbione> you are working on both at the same times so that makes it impossible to track easily
[08:35] <Dvalin> fabbione: I got the same error with the "old" compiler
[08:35] <fabbione> jbailey: it's a possibility..
[08:35] <Dvalin> I reverted back to last known good compiler
[08:35] <Dvalin> 4.0.3
[08:36] <Dvalin> which I'm using now
[08:40] <jbailey> fabbione: You didn't use debuild to build this?
[08:40] <fabbione> dpkg-buildpackage -rfakeroot -uc -us -b
[08:40] <fabbione> as i always do
[08:41] <jbailey> debuild actually logs the whole build (as well as cleans some pieces of the environment)
[08:41] <jbailey> So just "debuild -uc -us -b" is the equivalent.
[08:41] <fabbione> hmm ok
=== mlpug [n=user@a84-231-238-186.elisa-laajakaista.fi]  has joined #ubuntu-toolchain
[08:42] <fabbione> we still shouldn't really on debuild.. it should just work...
[08:43] <fabbione> if we need to sanitize the ENV that should happen in debian/rules
[08:43] <jbailey> eh, what do you mean?
[08:43] <fabbione> sbuild doesn't call debuild or dpkg-buildpackage
[08:43] <jbailey> No - sometimes I set external environment varilables to change what's happening intentionally.
[08:43] <fabbione> ok.. those are well defined things to trigger certain behavious
[08:43] <jbailey> Sucks to be sbuild.  If the buildds don't use what all the developpers use then I consider the buildd broken.
[08:43] <fabbione> but i don't set anything in my env other than ccache 
[08:44] <jbailey> Right, I don't know that it's a problem or not.  Just that debuild is handy for that.
[08:44] <jbailey> Mostly what I'm wishing for is the .build file.
[08:44] <jbailey> The logs that the glibc build produces on its own start logging too late.
[08:44] <fabbione> jbailey: actually.. no.. i disagree.. according to policy you should be able to call ./debian/rules $target and it should work. All the other tools are "wrappers" for that
[08:44] <jbailey> So?
[08:44] <jbailey> the buildd should do what the developpers are doing for maximum reliability.
[08:45] <jbailey> whether the devs change or whether the buildds change is irrelevant.
[08:45] <fabbione> if debuild does extra cleaning, then it might fail on the buildd
[08:45] <fabbione> well i don't use debuild and like you i did build 95% of the biggest packages around without issues...
[08:45] <fabbione> if you understand what i mean
[08:45] <jbailey> It's less likely, I think, since the buildds don't tend to have random things in their environment.
[08:45] <jbailey> Whereas a user running gnome and a pile of crap might.
[08:46] <fabbione> right, but in my buildd/chroots i don't set random crap either
[08:46] <fabbione> i know that for a fact of me being sane :)
[08:46] <jbailey> So you agree, nice. =)
=== jbailey hids
[08:46] <jbailey> +e
[08:46] <fabbione> ahah whatever :)
[08:46] <fabbione> what i consider scary is this:
[08:46] <fabbione> i have  a clean environment
[08:46] <jbailey> either way, I want a log file of the build more than I care about the environment.
[08:46] <jbailey> It would've told me how make was called.
[08:47] <fabbione> jbailey: the sources are stilll on ronne
[08:47] <fabbione> it doesn't take long to build there
[08:47] <jbailey> Nope, should be about 20 minutes.
[08:47] <fabbione> more or less yeah
[08:47] <jbailey> Which I can do.  But I was asking that you consider using debuild since it just always produces a log file.
[08:48] <fabbione> i will try.. i need to get used to type it :)
[08:48] <fabbione> oh  my wife made dinner!
[08:48] <fabbione> bbl
[08:48] <jbailey> enjoy! =)
[08:48] <fabbione> thanks
[08:48] <jbailey> bah!  no source package! =)
=== jbailey also talks fabbione into dropping the -b =)
[08:55] <jbailey> echo "CXX = "   >> build-tree/i386-libc/configparms
[08:55] <jbailey> that would be the bug. =)
[08:57] <jbailey> Need s BUILD_CXX line in debian/rules
[08:57] <jbailey> Although more I wonder how much we care about the cross-compilation case.
[08:58] <jbailey> echo "CXX = g++-4.1 -fno-stack-protector"       >> build-tree/i386-libc/configpa
[08:58] <jbailey> Better.
[08:58] <jbailey> doko_: Any idea if upstream gcc is going to integrate cleanly an option to enable the stack-protector by default?
[08:59] <fabbione> jbailey: yes.. in ~fabbione/
[09:00] <jbailey> fabbione: All good.  cp -a was my bitch. =)
[09:00] <fabbione> jbailey: so are you going to commit the fix?
[09:00] <jbailey> After I see a succesful test suite on i386, yes. =)
[09:01] <fabbione> jbailey: also note that the patch pristine from 2.4.. so it have been buggy in edgy too?
[09:02] <jbailey> I don't think these two tests existed in 2.4.
[09:02] <fabbione> ok
[09:02] <jbailey> So the only thing would've been the C++ abi test, we I never paid attention to anyway.
[09:02] <fabbione> see.. as i said.. harmless errors in the logs
[09:02] <fabbione> you should have trust me before :P
[09:03] <jbailey> I didn't say I didn't trust you.  =)  I merely offered my opinion.
[09:03] <jbailey> "wow, this is broken.  Here's the fix."  Easy opinions like that. =)
[09:04] <fabbione> ahah
[09:04] <fabbione> yeah yeah
[09:04] <jbailey> fabbione: There've got to be *some* advantages of staring at this package for 6 years. =)
[09:05] <fabbione> jbailey: like an extra discount for the super-pack offer from your shrink?
[09:05] <jbailey> Doesn't help much after the surcharge.
[09:05] <fabbione> 10 hours at the price of 8
[09:06] <jbailey> Something about my reality check bouncing...
[09:06] <fabbione> and if you are a glibc maintianer 10 hours at the price of 6!
[09:06] <fabbione> ehhe
[09:07] <doko_> jbailey: no idea ...
[09:10] <fabbione> doko_: you want to look at debian bug #391858
[09:10] <fabbione> doko_: it's not a glibc bug, but gcc.. the same we fixed in ubuntu not too long ago
[09:10] <fabbione> their fix is just wrong
[09:10] <fabbione> and they don't take into account other arches like sparc
[09:10] <fabbione> that does the same thing
[09:24] <doko_> Tags: experimental, fixed-in-experimental
[09:25] <fabbione> yes but still in glibc
[09:25] <fabbione> and you are the gcc maintainer so you might want to explain to them that it is wrong
[09:28] <doko_> fabbione: fixed-in-experimental, they did fix it already ;-p
[09:29] <fabbione> doko_: yes i know.. whatever.. our gcc is fine and will cope.. 
[09:30] <fabbione> jbailey: the ppc build seems to hang on a test suite
[09:30] <fabbione> i have a bunch of processes in Z on davis
[09:31] <jbailey> Joy.
[09:32] <fabbione> this is the second timei see this
[09:32] <fabbione> in the same build
[09:33] <fabbione> the first time did "unblock" itself
[09:37] <jbailey> fabbione: Can you tell which test?
[09:37] <fabbione> x/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser.h resolv/arpa/nameser_compat.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/soc
[09:37] <fabbione> ket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/auth.h sunrpc/rpc/auth_des.h sunrpc/rpc/auth_unix.h sunrpc/rpc/clnt.h sunrpc/r
[09:37] <fabbione> pc/des_crypt.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/rpc_des.h sunrpc/rpc/rpc_msg.h sunrpc/rpc/svc.h sunrpc/rpc/svc_auth.h sunrpc/rpc/types.h sunrpc/rpc/xdr.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys
[09:37] <fabbione> /time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h > /home/fabbione/glibc-2.5/build-tree/powerpc-libc/begin-end-check.out
[09:37] <fabbione> this is all i can get
[09:38] <fabbione> or you need to remind me how to scroll back in screen
[09:40] <jbailey> C-a {
[09:40] <jbailey> err
[09:40] <jbailey> C-a [
[09:41] <jbailey> but I don't remember what begin-end-check.out is.
[09:41] <jbailey> I can look in my i386 build logs.
[09:41] <jbailey> Meh, they haven't started the test suite yet.
[09:42] <jbailey> I'm fighting doko for CPU time on ronne. =)
[09:43] <fabbione> jbailey: if we really need a running .17 to build glibc we need to talk to elmo for the buildd
[09:44] <jbailey> Shouldn't need it on ppc.
[09:44] <jbailey> Will certainly need it on parisc.
[09:45] <fabbione> what about i386/amd64/sparc?
[09:45] <fabbione> and ia64?
[09:45] <jbailey> Mainstream arches should all be fine.
[09:46] <fabbione> ok
[09:46] <jbailey> Have to check with Dave on sparc to be certain.
[09:46] <jbailey> But since their nptl port worked fine, I wouldn't expect that to change.
[09:46] <fabbione> no..
[09:46] <jbailey> The rest of the arches all had corporate funding for their ports, so they got done early.
[09:47] <fabbione> ok.. i killed the build on ppc.. waiting Znarl to kill some Zl processes leftover
[09:47] <fabbione> and restart with debuild
[09:50] <fabbione> jbailey: ppc will wait tomorrow
[09:51] <fabbione> i need to get some sleep
[09:52] <jbailey> fabbione: g'n! =)
[09:52] <fabbione> night
[09:53] <Dvalin> seems like I was right
[09:53] <Dvalin> building kernel with old gcc
[09:53] <Dvalin> made it work