#ubuntu-toolchain 2005-10-24
<fabbione> doko_: build finished.. do you want to see the logs?
<doko> fabbione: test-summary
<fabbione> doko: i have all the log.. let me upload it
<fabbione> doko: people/~fabbione/gcc-4.1-full.bz2
<doko> looks fine, how fast is that machine? I get some less timeouts in tests
<fabbione> doko: it's a 433 Mhz 512MB of ram
<fabbione> sort of slow
<fabbione> but i can feel you are happy to donate a buildd :P
<doko> $ cat /proc/cpuinfo
<doko> cpu             : TI UltraSparc IIi (Sabre)
<doko> fpu             : UltraSparc IIi integrated FPU
<doko> promlib         : Version 3 Revision 19
<doko> prom            : 3.19.4
<doko> type            : sun4u
<doko> ncpus probed    : 1
<doko> ncpus active    : 1
<doko> Cpu0Bogo        : 716.80
<doko> Cpu0ClkTck      : 0000000015752a00
<doko> MMU Type        : Spitfire
<doko> don't know how fast that one is ...
<fabbione> pretty fast :)
<doko> fabbione: I did ask you about the buildd, but never got an answer
<fabbione> doko: i can't recall that...
<fabbione> doko: i rather prefer you to keep it free for debugging :)
<fabbione> would it be possible to set it up as developer machine access?
<doko> sure, just wanting to make it a combined debian/unstable machine. I got access to it for Debian originally.
<fabbione> doko: are you the admin of that box? or there are more?
<doko> the local admin
<fabbione> ok
#ubuntu-toolchain 2005-10-27
<fabbione> doko_: you need to add a Build-Dep: g++-3.4 to OO2
<fabbione> or something is trying to use it
#ubuntu-toolchain 2005-10-28
<doko> fabbione doko_: you need to add a Build-Dep: g++-3.4 to OO2
<doko> do you have the log, where it tries to use g++-3.4?
#ubuntu-toolchain 2005-10-30
<lamont> doko/et.al...: what was the -m64/-m32 issue?
<doko> ?
<doko> which platform?
<infinity> We've got it sorted.
<jbailey> These are not droids you're looking for?
<lamont> jbailey: nah, it's just that I hate gcc args
<infinity> They hate you too.
<lamont> can't make them say '-march=64 -mtune=64',  no... that'd be too easy to parse.
<infinity> Says so in the manpage.
<lamont> doko: and how come i386 doesn't have an option to generate ia64 code?  and vice versa?
<infinity> "SEE ALSO: GCC hates lamont."
<jbailey> That's fine.  I'm a GNU maintainer.  manpages aren't canonical. =)
<lamont> it _would_ actually be nice to get -m32 working on ia64
<jbailey> lamont: Feh.
<doko> lamont: it does. it's called a cross-compiler :-P
<jbailey> lamont: You're kidding, right? =)
<lamont> jbailey: 99% kidding...
<infinity> -m32 on ia64 may be doable.  The other way ain't ever going to happen.
<lamont> but it would fix mithrandir's latest breakage of ia32-libs-openoffice$mumble
<lamont> infinity: yeah, assumed as much
<jbailey> Oh.  Does ia32-libs cover it?
<jbailey> I'm all about painful elimination of ia32-libs
<infinity> "it"?
<lamont> jbailey: oo.o2 was ftbfs on ia64 for breezy.. .root cause was one package with comple errors becausee it assumed biarch was present, and the other was an 'Architecture: amd64' that should have had ia64 as well.
<lamont> infinity: -m32
<lamont> because then the compile error would go away
<infinity> Yes, yes it would.
<infinity> And ia32-libs going away would be so amazingly wonderful that I may crap myself with glee.
<lamont> jbailey: painful or otherwise, getting rid of ia32-libs* is a noble goal.
<jbailey> I LIKE PAIN
<jbailey> wait
<jbailey> that came out wrong
<lamont> but enough.. I'm leaving for home 22 minutes ago, according to what I told my wife... must flee.
<lamont> jbailey: I'll bring something to hit you with to UBZ then. :-)
<lamont> on later from home
<doko> see you tomorrow
<jbailey> doko: Yes, dear.
<doko> jbailey: ok, I'll leave  ....
<lamont-away> moof
<lamont-away> checking whether strstr is declared...
<lamont-away> malloc: ../bash/jobs.c:708: assertion botched
<lamont-away> free: underflow detected; mh_nbytes out of range
<lamont-away> Aborting.../bin/sh: line 1:  9172 Aborted                 /bin/sh
<lamont-away> go gcc - it's your birthday
<lamont-away> gcc-4.0_4.0.2-3/debian, that is
<fabbione> hey doko
<fabbione> doko: http://people.ubuntu.com/~fabbione/
<fabbione> oo2-no-g++-3.4.bz2
<fabbione> this is the build failure without g++-3.4
<fabbione> i assume that upstream did change default c++ compiler on sparc, because they didn't get David patch
<fabbione> install g++-3.4 builds all the way
<fabbione> so we can either revert the upstream change and go with g++-4.0
<fabbione> or just add that build-deps for sparc
<fabbione> up to you
<fabbione> i am off for a bit
<fabbione> doko: hey did you read what i wrote before?
<doko> yes
<doko> obviously that was the "fix" that _rene" did mention :-(
<fabbione> bah
#ubuntu-toolchain 2006-10-24
<jbailey> doko_: ping?
<doko_> phone ...
<jbailey> doko_: No worries.  I'll type for now, reply when you have brainspace for it.
<jbailey> Fabio and I were just talking about how to share some of the glibc work in a better way.  I'm going to create a team on launchpad so we can host the packaging on the supermirror.
<jbailey> Should I create it as a "glibc" team, or a "toolchain" team?
<doko_> well, lets call it toolchain, glibc is debian =)
<jbailey> I'm curious what drepper would think of that statement.
<jbailey> But alright ;)
<jbailey> Hmm.  doko_, fabbione, infinity, me.  who else should be in here?
<doko_> bluefoxity ;-p
<fabbione> doko_: screw you
<fabbione> ok.. jbailey please create the team and add people there.. together with a nice logo
<fabbione> you want to add lamont too probably?
<jbailey> fabbione: Done, except the nice logo.
<jbailey> fabbione: Still got your old X one handy?
<lamont> jbailey: feel free to add me if you haven't
<fabbione> jbailey: which one? the one from X-men 3 or goatse.cx?
<jbailey> lamont: Done, thanks.  Do you feel the need to be an administrator?
<lamont> almost never.
<jbailey> fabbione: Not the X men ;)
<fabbione> hehe
<fabbione> let me find it
<fabbione> jbailey: http://people.ubuntu.com/~fabbione/.ubuntu-kernel-team.png
<fabbione> you just need to copy/paste the logo
<fabbione> it shold be 16x16
<fabbione> and with that i can start packing my bag and get fired :)
<jbailey> *lol*
<jbailey> "Why did you leave your last job?"  "I was fired for a photo"  "A Photo?"  "Yeah, this one, (pulls it out)"  "My eyes!"
<lamont> fabbione: how come I'm not on the kernel team?
<fabbione> lamont: uh?
<fabbione> jbailey: ahha
<lamont> https://launchpad.net/people/ubuntu-kernel-team
<lamont> Your involvement
<lamont> You are not a member of this team. 
<fabbione> -ENOCLUE
* lamont sniffles
* fabbione readds
<fabbione> done
<jbailey> fabbione: How many colours are available in that bmp?
<fabbione> no idea.. i just took a screenshot
<jbailey> Oh, you didn't make the emblem?
<infinity> lamont: You don't want to be on the kernel team, the bug influx in your inbox would make you sad.
<infinity> jbailey: I'll make a nice toolchain icon when I'm bored.
<lamont> infinity: ah - that gives me a good date to understand when I got dropped then... had been wondering why kernel-bugs was so quiet these last couple months...
<infinity> lamont: Do you want to be on it?  I can re-add you.
<infinity> Wait, you're there..
<lamont> infinity: I'll debate that some more...
<lamont> ??
<infinity> Someone already put you back?
<lamont> ubuntu-kernel-team?
<infinity> Team members
<infinity>     *   Adam Conrad
<infinity>     * Ben Collins (Administrator)
<infinity>     * ChuckShort
<infinity>     * Fabio Massimo Di Nitto (Owner)
<infinity>     * LaMont Jones
<infinity>     * Matthew Garrett
<lamont> yep
* lamont feels loved
<fabbione> infinity: yeah i did
<fabbione> jbailey: no, i took goatse.cx, selected THE area and resized it
<jbailey> Ah. =)
<jbailey> I think I made an emblem and uploaded it.  I can no longer remember where to look for them, though.
<fabbione> yeps
<fabbione> but i can't understand what it is
<fabbione> it looks like a bird?
<jbailey> The end of a wrench that I reduced.
<jbailey> Oh, I wonder if the CSS sheet that I have for launchpad is hiding that section of the page.
<jbailey> I think I tweaked it to remove things that I just *never* care about seeing.
<fabbione> i look at my personal page to see the emblem
<jbailey> Ah, yeah.  The two boxes on the right are killed with the CSS template.
<jbailey> Bugger.  I should ask for a div around those emblems just so I can get them put somewhere else on the page for me. =)
<Keybuk> jbailey: use greasemonkey to rearrange them
<jbailey> Keybuk: Don't they need a div around them or something in order to manipulate them in the first place though?
<jbailey> Or do they already have it?
<Keybuk> jbailey: they have one around each box
<Keybuk> so you can grab the box as an item and stick it elsewhere in the page
<Keybuk> (ie. reorder the boxes)
<jbailey> Right, I'm thinking kill the surrounding blue box, keep the emblems. =)
<infinity> jbailey: Emblem replaced with something with a transparent background and better pixel art. :)
* infinity is so anal...
<fabbione> infinity: much better :)
<jbailey> infinity: *lol*  Thanks. =)
<doko_> infinity: heh, the hammer was already taken ;)
#ubuntu-toolchain 2006-10-25
<fabbione> doko_: ping?
<doko_> fabbione: pong
<fabbione> doko_: what gcc do you expect for feisty?
<fabbione> i have glibc-2.5 almost done
<doko_> currently 4.1; 4.2 is not released, and probably will take longer.
<fabbione> doko_: so the same gcc we have now in edgy?
<doko_> so we have to backport the relevant binutils changes
<fabbione> or are you adding extra patches and stuff like that?
<fabbione> we will need a very new binutils to get hppa back in the game
<fabbione> AFAIK Jeff is looking at it
<doko_> fabbione: no, extra patches, long double 64->128 bit ABI change on powerpc and sparc
<fabbione> doko_: ok, can you please let me have a source to build before monday?
<doko_> fabbione: unreleased? an alternative might be the HJ Lu binutils for feisty
<fabbione> or if you have it done.. now
<fabbione> doko_: yes unreleased..
<fabbione> dunno.. i hate binutils from the bottom of my heart
<fabbione> it freaks me out...
<doko_> it's not my toy package either
<fabbione> eheh
<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
<doko_> I'll prepare gcc either over the weekend or today
<fabbione> and that's basically done
<fabbione> but i want to simulate a bootstrap over all my machines
<fabbione> build gcc with old gcc
<fabbione> build gcc
<fabbione> build kernel (that i know is going to suck)
<fabbione> rebuild glibc and gcc and kernel again for fun and profit
<fabbione> that would be lovely.. thanks
<fabbione> if we can have at least part of the toolchain ready before we open feisty that will be great
<jbailey> fabbione: Yeah, what you said.
<jbailey> =)
<fabbione> ehe
<fabbione> i was saying that my target now is to 2.5 out for opening
<fabbione> then we can cleanup as much as we want
<jbailey> Yup.
<fabbione> afaict the only thing missing now for an upload is debian/patches/ubuntu from 2.4 to 2.5
<jbailey> I need to merge in ports stuff for hppa/
<jbailey> And get the TLS patches in for binutils.
<fabbione> and decide if we want NPTL or LT for hppa...
<jbailey> The nice part is that I now feel comfortable enough with BFD to do that.
<jbailey> No LT.
<fabbione> ok
<fabbione> i can fix that easily
<jbailey> Our .orig.tar.gz shouldn't even have the tar.bz2 in there.
<fabbione> well it has for now..
<jbailey> But just in general.
<fabbione> should we kill it?
<fabbione> yeah
<jbailey> We're not Debian, we don't drag corpses behind us chained to the bumper.
<fabbione> ahah
<fabbione> there are a few entries in debian/changelog marked as (requires testing) or (requires review)
<fabbione> that's because i am not 100% of the reason why that stuff is there
<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
<jbailey> I *hate* sysdeps/depflags.pl
<jbailey> That was about where I ran out of steam redoing the packages for Debian in 2003.
<jbailey> What I think it should be is a tab delimited table or something like that which sits in control.in
<jbailey> Maybe a few different files, conflicts, depends, etc.
<jbailey> ARCH\tPACKAGE\tVERSION
<fabbione> imho we could simplify the packaging a lot with a set of shell scripts
<fabbione> or start eliminating tons of .mk stuff
<jbailey> There's a surprising amount of this that *can't* be simplified once you start to look at what it does.
<jbailey> But certainly half of rules.d/debhelper.mk can go.
<jbailey> I thought quilt provided a rules snippet to include, so I'm not sure why we have our own.
<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.
<doko_> but keeping the binutils-source package
<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.
<jbailey> But are still sort of crack-of-the-moment.
<jbailey> With his snapshots, we'dhave the HPPA TLS stuff already.
<jbailey> Otherwise we'll have to backport them to get hppa working.
<doko_> jbailey: yes, I was thinking about it as well. but then, how switch back to FSF binutils without having any regressions?
<jbailey> Dunno.  I've never understood why the binutils release cycle is so slow.
<jbailey> The changes that tend to go in there seem to be consistantly just opcode adds, etc.
<doko_> if we can track these changes in a separate branch?
<jbailey> I don't think we have the bodies on toolchain to do that sort of work.
<jbailey> Since that drags the QA responsibility for those things onto us.
<jbailey> I think it just wouldn't get done in the end.
<fabbione> jbailey: i am getting a feisty amd64 chroot on ronne. the debs look good
<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
<jbailey> We don't care about ppc anymore? =/
<fabbione> it's already fixed in bzr.. i didn't feel restarting the builds for a ppc thingy
<fabbione> but at least i know it is fixed properly
<fabbione> dh_install: libc6-dev missing files (debian/tmp-libc/usr/lib/nptl*), aborting
<fabbione> GRRRRRRRRRRRRRRR
<jbailey> Right, debhelper 5 broke that construct, sadly.
<jbailey> I pouted at Joey for it.
<jbailey> foo* doesn't resolve to empty set in a glob anymore.
<fabbione> i don't think we ship anything with that name anyway
<fabbione> i386/ia64 did fail
<fabbione> amd64 is rebuilding and waiting sparc/ppc
<fabbione> we might as well chop it away if it's not required
<fabbione> (feisty-libc)fabbione@ronne:/lib$ 
<fabbione> well.. they seem to work on amd64 at least
<jbailey> whee =)
<fabbione> waiting for all the builds to complete.. then i will respin with that postinst fix and the nptl fix
<fabbione> i am sure locales are broken
<fabbione> because we need to port the patch for belocs and the other search path from 2.4
<fabbione> but at least we know that we can run
<Dvalin> fabbione: what gcc do you guys use to build kernel?
<fabbione> gcc-4.1
<Dvalin> okay
<fabbione> Dvalin: doko is our gcc god here
<Dvalin> yes
<Dvalin> that's why I ask in here ;)
<Dvalin> I have this weird issue
<fabbione> yeah but you are building on *mandriva*
<fabbione> you have issues.. no matter :
<fabbione> :P
<Dvalin> with the atyfb driver, I tried recompiling the same old kernel where it was working
<Dvalin> with current toolchain, not what I compiled it at that time
<fabbione> oh you are suspecting a gcc breakage?
<Dvalin> otherwise everything being the same, and problem exist in the same kernel release which previously worked (even with the same config)
<Dvalin> yes
<fabbione> Dvalin: i suggest you try with -O0 and check the asm output
<fabbione> in theory it should be the same
<Dvalin> I'm thinking about trying to build with gcc 4.0.3 which I built last working kernel with..
<Dvalin> fabbione: okay, good tip, for checking the asm output.. I think you overestimating me ;)
<fabbione> Dvalin: nah.. that was a trick doko handed to me
<Dvalin> checking the asm output? or -O0?
<fabbione> asm output
<fabbione> and -O0 ;)
<fabbione> both
<Dvalin> okay
<Dvalin> I'm not competent at asm stuff.. ;p
<Dvalin> but I did score 100% at a simple asm asisgnment at an exam last spring ;)
<Dvalin> harrharr
<Dvalin> I think that landed me the C in stead of E which otherwise would be the final grade :p
<infinity> You don't need to write asm fluently to be able to compare it.
<Dvalin> ah
<infinity> (Thank god, too, because my i386 asm is less than perfect)
<Dvalin> I see your point :)
<infinity> Useless architectures, like m68k, powerpc, hppa, and sparc.  Sure, they're easy. :P
<infinity> i386, not so much.
<Dvalin> hehe
<Dvalin> "useless"
<Dvalin> quite a bombastic statement, no? ;)
<infinity> Yes, that belonged in quotes.  I missed adding the irony. :)
<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.
<fabbione> jbailey: ia64 glibc are good
<fabbione> if i could only get sparc to complete the testsuite without a kernel crash
<fabbione> jbailey: i am uploading all the debs here: http://people.ubuntu.com/~fabbione/glibc-2.5/
<jbailey> Joy.
<fabbione> amd64 is good too
<jbailey> Does it crash in a consistant place?
<fabbione> i386 will test tomorrow
<fabbione> it's a kernel problem.. 
<fabbione> it lockups on high load
<fabbione> i need to downgrade to edgy kernel
* fabbione was running 2.6.19-rc2
<jbailey> Any idea if Ben is going to target 2.6.19 or 2.6.20 for fiesty?
<fabbione> .19 afaik
<fabbione> 9391 fabbione  21   0  5088  448  304 D  300  0.0   9:22.63 ld-linux.so.2
<fabbione> now i have a process on 400 of CPU
<jbailey> fabbione: Any idea when we're targetting to open the next one?
<jbailey> I remember that edgy had some hitches, openning up.
<fabbione> the kernel is already in git
<fabbione> we need to get a few important things fixed
<fabbione> like that headers issue i was mentioning
<fabbione> otherwise we won't even be able to rebuild the kernel
<jbailey> Headers issue?
<fabbione> yes.. build .19
<fabbione> install linux-libc-dev
<fabbione> and you are doomed: )
<fabbione> you can't even rebuild the kernel with that stuff
* jbailey knows of ia64 klibc headers and ppc merging ppc and ppc incorrectly.
<fabbione> it's totally broken
<jbailey> Err.
<fabbione> no.. this is worst
<jbailey> Kernel builds with -nostdinc.
<jbailey> Nothing in /usr/include should matter in the slighjtest.
<fabbione> not the scripts/*
<fabbione> and you need those
<fabbione> like.. hmmmm modpost?
<jbailey> I don't think I know about those.
<fabbione> you use them all the time.. you just don't know that :)
<jbailey> Can you toss a build failure into a pastebin?
<fabbione> jbailey: sure.. in a minute 
<jbailey> No worries.
<fabbione> no actually i can't.. i don't have the deb handy..
<fabbione> but i can show it here by memory
<fabbione> #include <errno.h>
<fabbione> #include <sys/socket.h>
<fabbione> int main() {
<fabbione> return -EINVAL;
<fabbione> return -SOL_SOCKET;
<fabbione> }
<fabbione> you can't build that one
<jbailey> Right, but I'm curious about the actual failure.
<fabbione> it's an include order issue
<fabbione> either SOL_SOCKET or EINVAL is not defined
<fabbione> if you swap the include's at the top, you get the other error
<doko_> gcc-4.1_4.1.1-17ubuntu1 is on ronne:~doko/gcc/4.1/
<fabbione> doko_: cool.. there is a feisty-libc chroot (amd64) on ronne
<fabbione> doko_: 
<doko_> enabling long-double-128 on powerpc and sparc, configuring with --enable-secureplt on powerpc
<fabbione> you can build there if you like
<fabbione> it has glibc-2.5 installed
<fabbione> doko_: i will do ia64/ppc/sparc/i386 tomorrow
<fabbione> i am just too tired today to do it
<fabbione> actually.. i could do ia64 overnight
<fabbione> ii  libc6.1        2.5-0ubuntu1   GNU C Library: Shared libraries
<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.
<jbailey> But I think that requires a new binutils snapshot.
<doko_> http://cvs.fedora.redhat.com/viewcvs/devel/binutils/
<doko_> 2.17.50
<doko_> 2.17.50.0.6, the version number smells like beeing the HJ stuff ...
<fabbione> doko_: gcc-4.1 building on ia64
<fabbione> doko_: do you want to ask B-D on feisty-libc chroot or should I? i can do the others locally
<doko_> they were installed
<doko_> currently building on feisty
<fabbione> hmm ok
<fabbione> good
<jbailey> Hmm, here's going to be an interesting question.
<jbailey> Some of the libc tests probably need corresponding kernel functions to pass.
<fabbione> jbailey: ?
<jbailey> What do the buildds run for a kernel>
<fabbione> oh yes.. i already noticed that
<fabbione> 2.6.17 basically everywhere
<fabbione> i saw a bunch of test failures
<fabbione> but i didn't track them down yet
<fabbione> and i don't think for bootstrapping we care too much
<jbailey> If you toss those into a pastebin somewhere, I might be able to offer you opinions on them.
<fabbione> jbailey: ronne:/home/fabbione/{i386,amd64}/
<fabbione> ppc is on davis
<fabbione> i can upload sparc and ia64 later
<fabbione> davis is still building FYI
<fabbione> oh acutally i did build ia64 with .19
<jbailey> make[3] : bug-atexit3-lib.cc: Command not found
<jbailey> make[3] : *** [/home/fabbione/i386/glibc-2.5/build-tree/i386-i686/dlfcn/bug-atexi
<jbailey> t3-lib.os]  Error 127
<jbailey> Eh, weird.
<jbailey> Oh, no G++ installed.
<fabbione> scp glibc-2.5.tar.bz2 chinstrap.ubuntu.com:glibc-2.5-ia64-log.tar.bz2
<fabbione> jbailey: uh? i did use dpkg-buildpackage.. do we miss a B-D ?
<jbailey> checking for g++... g++
<fabbione> hmmm
<fabbione> i readded the CXX patch from you...
<fabbione> could that be related?
<jbailey> 604-421-2460 604-726-2460
<jbailey> ls
<jbailey> BAH
<fabbione> 0wn3d
<Dvalin> mm/filemap.c: In function ?__generic_file_aio_write_nolock?:
<Dvalin> mm/filemap.c:1830: sorry, unimplemented: inlining failed in call to ?generic_write_checks?: function body not available
<Dvalin> mm/filemap.c:2133: sorry, unimplemented: called from here
<Dvalin> fabbione: are you sure you actually can compile the kernel with -O0?
<fabbione> Dvalin: i am pretty sure you can
<Dvalin> hmm
<Dvalin> then I don't get why I get that error when compiling with -O0
<Dvalin> will try again with -O2 to see if it reproduces
<fabbione> i usually compile only the bits i need with -O0
<Dvalin> okay
<Dvalin> so in other words, you don't know for sure that the *whole* kernel can be compiled with -O0?
<fabbione> no but it should be able to
<Dvalin> soo
<Dvalin> the error I got, a bug in kernel?
<fabbione> or gcc
<fabbione> it really depends what you are experimenting with
<jbailey> fabbione: It's entirely possibly that the kernel relies on optimiser tricks for correct code.
<jbailey> You can't compile glibc at -O0 for instance.
<fabbione> you are working on both at the same times so that makes it impossible to track easily
<Dvalin> fabbione: I got the same error with the "old" compiler
<fabbione> jbailey: it's a possibility..
<Dvalin> I reverted back to last known good compiler
<Dvalin> 4.0.3
<Dvalin> which I'm using now
<jbailey> fabbione: You didn't use debuild to build this?
<fabbione> dpkg-buildpackage -rfakeroot -uc -us -b
<fabbione> as i always do
<jbailey> debuild actually logs the whole build (as well as cleans some pieces of the environment)
<jbailey> So just "debuild -uc -us -b" is the equivalent.
<fabbione> hmm ok
<fabbione> we still shouldn't really on debuild.. it should just work...
<fabbione> if we need to sanitize the ENV that should happen in debian/rules
<jbailey> eh, what do you mean?
<fabbione> sbuild doesn't call debuild or dpkg-buildpackage
<jbailey> No - sometimes I set external environment varilables to change what's happening intentionally.
<fabbione> ok.. those are well defined things to trigger certain behavious
<jbailey> Sucks to be sbuild.  If the buildds don't use what all the developpers use then I consider the buildd broken.
<fabbione> but i don't set anything in my env other than ccache 
<jbailey> Right, I don't know that it's a problem or not.  Just that debuild is handy for that.
<jbailey> Mostly what I'm wishing for is the .build file.
<jbailey> The logs that the glibc build produces on its own start logging too late.
<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
<jbailey> So?
<jbailey> the buildd should do what the developpers are doing for maximum reliability.
<jbailey> whether the devs change or whether the buildds change is irrelevant.
<fabbione> if debuild does extra cleaning, then it might fail on the buildd
<fabbione> well i don't use debuild and like you i did build 95% of the biggest packages around without issues...
<fabbione> if you understand what i mean
<jbailey> It's less likely, I think, since the buildds don't tend to have random things in their environment.
<jbailey> Whereas a user running gnome and a pile of crap might.
<fabbione> right, but in my buildd/chroots i don't set random crap either
<fabbione> i know that for a fact of me being sane :)
<jbailey> So you agree, nice. =)
* jbailey hids
<jbailey> +e
<fabbione> ahah whatever :)
<fabbione> what i consider scary is this:
<fabbione> i have  a clean environment
<jbailey> either way, I want a log file of the build more than I care about the environment.
<jbailey> It would've told me how make was called.
<fabbione> jbailey: the sources are stilll on ronne
<fabbione> it doesn't take long to build there
<jbailey> Nope, should be about 20 minutes.
<fabbione> more or less yeah
<jbailey> Which I can do.  But I was asking that you consider using debuild since it just always produces a log file.
<fabbione> i will try.. i need to get used to type it :)
<fabbione> oh  my wife made dinner!
<fabbione> bbl
<jbailey> enjoy! =)
<fabbione> thanks
<jbailey> bah!  no source package! =)
* jbailey also talks fabbione into dropping the -b =)
<jbailey> echo "CXX = "   >> build-tree/i386-libc/configparms
<jbailey> that would be the bug. =)
<jbailey> Need s BUILD_CXX line in debian/rules
<jbailey> Although more I wonder how much we care about the cross-compilation case.
<jbailey> echo "CXX = g++-4.1 -fno-stack-protector"       >> build-tree/i386-libc/configpa
<jbailey> Better.
<jbailey> doko_: Any idea if upstream gcc is going to integrate cleanly an option to enable the stack-protector by default?
<fabbione> jbailey: yes.. in ~fabbione/
<jbailey> fabbione: All good.  cp -a was my bitch. =)
<fabbione> jbailey: so are you going to commit the fix?
<jbailey> After I see a succesful test suite on i386, yes. =)
<fabbione> jbailey: also note that the patch pristine from 2.4.. so it have been buggy in edgy too?
<jbailey> I don't think these two tests existed in 2.4.
<fabbione> ok
<jbailey> So the only thing would've been the C++ abi test, we I never paid attention to anyway.
<fabbione> see.. as i said.. harmless errors in the logs
<fabbione> you should have trust me before :P
<jbailey> I didn't say I didn't trust you.  =)  I merely offered my opinion.
<jbailey> "wow, this is broken.  Here's the fix."  Easy opinions like that. =)
<fabbione> ahah
<fabbione> yeah yeah
<jbailey> fabbione: There've got to be *some* advantages of staring at this package for 6 years. =)
<fabbione> jbailey: like an extra discount for the super-pack offer from your shrink?
<jbailey> Doesn't help much after the surcharge.
<fabbione> 10 hours at the price of 8
<jbailey> Something about my reality check bouncing...
<fabbione> and if you are a glibc maintianer 10 hours at the price of 6!
<fabbione> ehhe
<doko_> jbailey: no idea ...
<fabbione> doko_: you want to look at debian bug #391858
<fabbione> doko_: it's not a glibc bug, but gcc.. the same we fixed in ubuntu not too long ago
<fabbione> their fix is just wrong
<fabbione> and they don't take into account other arches like sparc
<fabbione> that does the same thing
<doko_> Tags: experimental, fixed-in-experimental
<fabbione> yes but still in glibc
<fabbione> and you are the gcc maintainer so you might want to explain to them that it is wrong
<doko_> fabbione: fixed-in-experimental, they did fix it already ;-p
<fabbione> doko_: yes i know.. whatever.. our gcc is fine and will cope.. 
<fabbione> jbailey: the ppc build seems to hang on a test suite
<fabbione> i have a bunch of processes in Z on davis
<jbailey> Joy.
<fabbione> this is the second timei see this
<fabbione> in the same build
<fabbione> the first time did "unblock" itself
<jbailey> fabbione: Can you tell which test?
<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
<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
<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
<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
<fabbione> this is all i can get
<fabbione> or you need to remind me how to scroll back in screen
<jbailey> C-a {
<jbailey> err
<jbailey> C-a [
<jbailey> but I don't remember what begin-end-check.out is.
<jbailey> I can look in my i386 build logs.
<jbailey> Meh, they haven't started the test suite yet.
<jbailey> I'm fighting doko for CPU time on ronne. =)
<fabbione> jbailey: if we really need a running .17 to build glibc we need to talk to elmo for the buildd
<jbailey> Shouldn't need it on ppc.
<jbailey> Will certainly need it on parisc.
<fabbione> what about i386/amd64/sparc?
<fabbione> and ia64?
<jbailey> Mainstream arches should all be fine.
<fabbione> ok
<jbailey> Have to check with Dave on sparc to be certain.
<jbailey> But since their nptl port worked fine, I wouldn't expect that to change.
<fabbione> no..
<jbailey> The rest of the arches all had corporate funding for their ports, so they got done early.
<fabbione> ok.. i killed the build on ppc.. waiting Znarl to kill some Zl processes leftover
<fabbione> and restart with debuild
<fabbione> jbailey: ppc will wait tomorrow
<fabbione> i need to get some sleep
<jbailey> fabbione: g'n! =)
<fabbione> night
<Dvalin> seems like I was right
<Dvalin> building kernel with old gcc
<Dvalin> made it work
#ubuntu-toolchain 2006-10-26
<doko> fabbione: gcc-4.1 did sucessfully build. please install on feisty
<fabbione> doko: i need to ask Spads to do it. i dont have root there
<fabbione> jbailey: ping?
<jbailey> fabbione: yoyosup?
<fabbione> yo dude
<fabbione> so it's confirmed.. glibc builds hang on Niagara. i am trying to build on a normal sparc now.
<fabbione> ppc is rebuilding now (without the Zombie processes)
<fabbione> ia64 is ahead of everything.. rebuilding glibc for the second time after glibc -> gcc
<jbailey> Is the T1000 also a Niagara?
<fabbione> yes
<fabbione> T1000 and T2000 are Niagara
<jbailey> 'kay.  We have one coming to Montral, apparently.
<fabbione> nice
<fabbione> but i am pretty sure it's something Niagara related
<jbailey> I had actually wanted a regular sparc so that we didn't have the noise problems, but ah well.
<fabbione> did your build with BUILD_CC finished?
<jbailey> BUILD_CXX, lemme check.
<jbailey> Yup, lesse the errors.
<jbailey> Testing ASCIItst-tables.sh: 259: tst-table.sh: not found
<jbailey> Weird, that's different than last time.
<fabbione> hmm ok
<fabbione> i will start soon a test build on a ppc32 kernel
<fabbione> just to isolate
<jbailey> make[3] : *** [/home/jbailey/i386/glibc/glibc-2.5/build-tree/i386-libc/posix/tst-
<jbailey> rxspencer.out]  Error 139
<jbailey> That's a segfault.
<fabbione> interesting
<jbailey> Oh, right.  I hadbeen looking at i686 before.
<jbailey> i486 has problems, but those might exist today.
<jbailey> i686 is now correct for those C++ tests.
<jbailey> amd64 biarch, I didn't specify -m64 in there.
<jbailey> Aside from that looks good.
<jbailey> so mostly just i486 needs some love there.
<jbailey> Lemme commit that fix.
<fabbione> thanks
<jbailey> Done, thanks.
<jbailey> fabbione: Need anything else before I crawl off to bed?
<fabbione> this fix is only for the test suite right?
<jbailey> Yup, reduce some false negatives.
<fabbione> ok thanks
<fabbione> no more sir.. good night sir!
<jbailey> Luvly.   demain!
* Starting logfile irclogs/ubuntu-toolchain.log
<fabbione> lamont, infinity: ia64 toolchain is good.
<fabbione> glibc -> gcc -> glibc and everything still hold up
<fabbione> we only need the kernel headers fixes now
<fabbione> but that's for arch all
<fabbione> doko: i requested gcc install on ronne's amd64 chroot and opening of an i386 chroot+glibc install.
<fabbione> ppc/sparc are a bit doomed at the moment
<fabbione> ppc glibc build can cause a DoS
<fabbione> (WOWOWOW)
<fabbione> sparc just need a bit of extra love
<fabbione> (test suite crappage)
<doko> fabbione: did you request a chroot on davis as well?
<fabbione> yes
<fabbione> libc6_2.5-0ubuntu1_sparc.deb                                                                           100% 4520KB   4.4MB/s   00:00    
<fabbione> there we have sparc
<fabbione> we miss ppc still
<fabbione> there is an issue in the testsuite that hangs but i think i have it now
<fabbione> doko: asked for a chroot on faure too with gcc build-dep
<fabbione> glibc fails to build on my Niagara. I know why but i don't have time to fix it right away
<fabbione> doko: gcc-4.1 FTBFS on sparc with glibc-2.5 
<fabbione> see /msg
<fabbione> doko: anyway chroot on faure has been requested
<doko> ahh, this was the txxx?
<fabbione> yes
<fabbione> but in this case should make no difference
<fabbione> it was bootstrapping
<fabbione> ./xgcc -B./ -B/usr/sparc-linux-gnu/bin/ -isystem /usr/sparc-linux-gnu/include -isystem /usr/sparc-linux-gnu/sys-include -L/usr/src/sparc/gcc-4.1-4.1.1/build/gcc/../ld -O2  -O2 -g -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector  -I. -I. -I../../src/gcc -I../../src/gcc/. -I
<fabbione> ../../src/gcc/../include -I../../src/gcc/../libcpp/include  -DL_muldc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../src/gcc/libgcc2.c -o libgcc/./_muldc3.o
<fabbione> (that was the command)
<fabbione> doko: trying to rebuild with linux32 ...
<fabbione> just for the fun
<fabbione> doko not a diff with linux32
<doko> fabbione: is this failure in the 64bit part? i.e. does building with WITHOUT_LANG=biarch work?
<fabbione> dunno what part is that.. it's just a few lines above..
<fabbione> i can test yes.. but i am heading for food and sleep soon
<fabbione> ok build started
<fabbione> i will let you know
<fabbione> export WITHOUT_LANG=biarch
<fabbione> doko.. same error
<fabbione> that looks like the 32bit part of it
<fabbione> anyway i am off for real now
<fabbione> we will wait faure to be ready
<jbailey> fabbione: g'm
<doko> hi jbailey 
<jbailey> Heya Matthias
<doko> did drepper release 2.6?
<jbailey> Eh?  No.  It's not expected for another 6 months.
<jbailey> They're releases with FC.
<jbailey> s/They're/They/
<jbailey> s/releases/release/
<jbailey> *clearly* awake.
<jbailey> doko: Another advantage to using the HJ Lu snapshots is getting the PT_GNU_HASH stuff.
<jbailey> Is the concern basically that the packages are too bleeding edge?
<doko> AFAIK elmo did not want them, because they are not tested on the minor debian archs and did break lot of things in the past.
* doko invites elmo
<jbailey> I suspect the sysadmins are either keeping the harddrives cool with firehoses or are out drinking at the moment ;)
<doko> bah
<fabbione> morning jb
<fabbione> jbailey: ping?
<jbailey> fabbione: PONGEROO!
<fabbione> jbailey: hey dude.. so sparc glibc are go.. gcc FTBFS
<jbailey> What's the FTBFS?
<fabbione> ppc can't build glibc and the build can DoS the machine
<fabbione> i already passed it on to doko
<jbailey> Interesting.  I wonder if that's a kernel issue.
<fabbione> ../../src/gcc/libgcc2.c:1629: error: size of array 'compile_type_assert' is negative
<fabbione> make[5] : *** [libgcc/./_muldc3.o]  Error 1
<fabbione> make[5] : Leaving directory `/usr/src/sparc/gcc-4.1-4.1.1/build/gcc'
<fabbione> make[4] : *** [stmp-multilib]  Error 2
<fabbione> make[4] : Leaving directory `/usr/src/sparc/gcc-4.1-4.1.1/build/gcc'
<jbailey> I'm running latest edgy on mine, and I didn't have a failure when I last tried it.
<fabbione> ppc is running ppc64 kernels. i need to try on my ppc32
<jbailey> I can try a build of your packages, though.
<fabbione> that's tomorrows job
<jbailey> Right, so is mine.
<fabbione> brb son is crying
<jbailey> I'll try a build at home over lunch.
<fabbione> re
<fabbione> yes please
<fabbione> jbailey: ia64 is gold.. 
<fabbione> i am waiting for am64 gcc to be installed on ronne and feisty-libc i386 chroot created + glibc
<fabbione> so for now it looks decent
<fabbione> could be better tho
<fabbione> i also found out part of the problem with glibc build hanging
<fabbione> (on sparc)
<fabbione> there is a commit that works around it
<fabbione> jbailey: also.. please don't use davis to build for now.. each build requires a davis reboot to cleanup
<fabbione> might be just a kernel thingy.. but well
<jbailey> Unkillable processes are always broken kernel, no?
<jbailey> Do we have the updated kernels?
<jbailey> But in general, I have a decent ppc box at home, so I don't tend to use davis.
<fabbione> well i don't see necessarely how it can be a kernel fault but i am too tired to look into it now
<fabbione> anyway i will test here tomorrow morning with ppc32
<fabbione> (since i can reboot locally)
<jbailey> Sure, or I'll test later too.  Whatever.
<jbailey> Unless you'd rather do it?
<jbailey> I'm surprised at your sudden interest in glibc. =)
<fabbione> we should test both
<fabbione> i am on ppc32.,. you ppc64 kernel
<fabbione> guess why we should do it
<jbailey> I could test on ppc32, but my Pegasos box is quite slow.
<fabbione> jbailey: bah i decided i want to be the only one that got to upload all possible source packages > 10MB or so :)
<fabbione> nah my G4 is fast
<fabbione> don't worry
<fabbione> we can just share the load
<jbailey> Sounds lovely. =)
<fabbione> i will only need to convince doko to let me upload gcc and OOo :)
<fabbione> once those 2 are done, i can go in pension :)
<jbailey> Dude, this is Ubuntu.  No BML. =)
<jbailey> Besides.
<jbailey> doko: Eh, Matthias.
<jbailey> doko: Fabio wants to take over OpenOffice.  Any objections?  =)
* jbailey hides.
<fabbione> jbailey: f**k y*u
<fabbione> with love
<fabbione> Fabio
<jbailey> *lol*
<jbailey> Hmm.  if it's likely to hang my ppc box, I should probably do that when I get home.
<fabbione> ok. i am off for the evening
<jbailey> Otherwise I lose access to a bunch of things.
<fabbione> me needs relax a lot. kthxbye
<jbailey> g'n F!  Happy drinking!
<fabbione> jbailey: it doesn't kill your machine
<fabbione> it leaves Zl processes there
<jbailey> fabbione: Oh, I can still reboot it remotely?
<jbailey> Easy then, I'll do a build in a sec.
<fabbione> and it needs a really hard reboot
<jbailey> I'll also take a look at the i386 failures on davis if I can.
<jbailey>  /sbin/reboot isn't enough?
<fabbione> if you issue reboot from console you are screwed
<fabbione> reboot -n -f probably might do it
<jbailey> Meh
<fabbione> but the machine doesn't die till it's up
<fabbione> that's really funny
<fabbione> i386 failures on davis <- that doesn't work.. on ronne? :P
<jbailey> ronne rather, right.
<jbailey> Do we have new kernel from Ben yet?
<fabbione> eheh eok
<fabbione> the kernel is in git, but don't install linux-libc-dev or you are doomed. that hasn't been fixed yet AFAIK
<fabbione> worth to try tho
<fabbione> i am happy if we can start glibc -> gcc -> glibc
<jbailey> Does he keep that on kernel.org ?
<fabbione> yeps
<jbailey> Cool.
<fabbione> https://wiki.ubuntu.com/KernelGitGuide
<jbailey> Perfect, thanks.
<fabbione> np
* fabbione heads offline
<jbailey> g'n!
<doko> jbailey: are you working on faure or davis?
<jbailey> Neither.
<doko> ok, trying to build the current gcc-4.1 there on edgy first ...
<Dvalin> Linux cm-84.210.59.173.chello.no 2.6.19-rc3.1mdv #1 PREEMPT Thu Oct 26 00:17:35 CEST 2006 sparc64 TI UltraSparc IIe (Hummingbird) unknown GNU/Linux
<Dvalin> reverting to old gcc did actually do the trick :)
<Dvalin> doko: I had same issues with sb100 booting your guys kernel for sparc too.. maybe the same one?
<mdz> feisty exists in launchpad now; presumably infinity has some work to do before anything useful can be done with it
<mdz> but that bit is done
<jbailey> mdz: Sweet, thanks.
<doko> nice
<doko> jbailey: the GCC build failures are bootstrapping problems with long double 128; anything that needs to be enabled in glibc?
<Dvalin> doko: I have some issues that might be similiar..?
<Dvalin> ./xgcc -B./ -B/usr/sparc-mandriva-linux-gnu/bin/ -isystem /usr/sparc-mandriva-linux-gnu/include -isystem /usr/sparc-mandriva-linux-gnu/sys-include -L/home/peroyvind/RPM/BUILD/gcc-4.1.2/obj-sparc-mandriva-linux-gnu/gcc/../ld -O2 -O2 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -mtune=ultrasparc  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I. -I../../gcc -I.
<Dvalin> ooops
<Dvalin> /usr/include/bits/types.h:147: error: size of array ?__val? is too large
<Dvalin> a lot of similar errors..
<Dvalin> managed to bootstrap, but then you see what happened afterwards.. (applied your sparc_biarch patch to gcc)
<jbailey> doko: I think glibc has everything enabled by default.
<jbailey> doko: Is there a build log I can look at to understand better?
<doko> jbailey: overwritten
<lamont> doko: remind me why a binary defining rpath is a bad thing...
<jbailey> lamont: It's not possible to override an rpath with a LD_LIBRARY_PATH, iirc.
<lamont> is that all>
<lamont> ?
<doko> I don't know anything more
<lamont> ok
<lamont> hrm... lintian warning: W: xxx: postrm-has-useless-call-to-ldconfig
<lamont> cat postrm
<lamont> #!/bin/sh
<lamont> set -e
<lamont> # Automatically added by dh_makeshlibs
<lamont> if [ "$1" = "remove" ] ; then
<lamont>         ldconfig
<lamont> fi
<lamont> # End automatically added section
<lamont> and there's a shlib in the package...
<lamont> otoh, it's not in /usr/lib
<lamont> is that a bogus warning, or a valid one, I wonder?
<jbailey> If it's not in /usr/lib, ldconfig won't see it.
<jbailey> Well.
<lamont>  /usr/lib/foo
<jbailey>  /lib, /usr/lib, or a patch specified in /etc/ld.so.conf or /etc/ld.so.conf.d
<lamont>  /usr/lib/foo/libfoo.so.2.5.2
<lamont> so why did dh_makeshlibs add the call, I wonder
<jbailey> Dunno.  Unusual to have a versioned lib in a subdirectory, though.
<lamont> yeah, well...  this is unusual code
<fabbione> mdz: i am pretty sure infinity needs to create the chroots for it. In any case we can't upload glibc just yet. PPC has issues and it will kill buildds
<fabbione> mdz: i386/amd64/sparc/ia64 looks good for glibc. gcc needs some love on sparc apparently (unknown ppc)
<fabbione> doko: Nick did the chroots on ronne and davis. but note that davis doesn't have glibc-2.5 quite yet
<fabbione> checking for sparc too
<fabbione> no it's not done yet
<fabbione> anyway movie time
<doko> fabbione: have fun
<fabbione> doko: thanks dude
#ubuntu-toolchain 2006-10-27
<cjwatson> Listing ubuntu/feisty (DONE) 0/0
<cjwatson> y'all are slackers
<cjwatson> :-)
<doko_> cjwatson: is edgy-updates open?
<doko_> or -proposed ...
<infinity> So, what's the status of toolchain mangling, kids?
<infinity> Anyone have uploads ready for me?
<doko_> yes, for edgy-updates; sparc has problems
<jb-home> doko, fabbione: Whenever you guys wake up.  I'm going to patch glibc such that it build-dep's on linux-libc-dev 2.6.19.  Some defines went away, so I'll patch glibc to have them directly (and submit the patch upstream)
<infinity> jb-home: So, am I going to do a manual bootstrap to get glibc in place, then do the rest of the toolchain (and kernel), then we'll upload glibc again with the correct build-dep?
<jb-home> infinity: Eh, you're awake earlier than expected. =)
<infinity> It's almost noon...
<jb-home> glibc doesn't build without it.
<jb-home> So I'd start with the kernel upload.
<jb-home> I suggested that to Ben, and he doesn't want people usng the kernel, so wouldn't update linux-meta.
<infinity> Oh, yeah, starting with the kernel seems sane, since it should build fine regardless.
<jb-home> Right.
<infinity> Do we have a kernel upload for me?
<jb-home> Best to poke BenC.  He has one that he was using to give us linux-libc-dev .debs from.
* BenC was summoned
<infinity> Woo.
<infinity> BenC: How quickly can I get that linux-source-2.6.19 in edgy?
<infinity> feisty, even.
<infinity> That's going to take some brain mangling.
<infinity> feisty, feisty, feisty.
<infinity> I wonder how many changelogs I'll mess up in the first month...
<BenC> I can upload tonight
<infinity> Where "tonight" = ?
<BenC> withing a few hours
<infinity> Cool.  Should do.
<BenC> want me to get on it?
<infinity> Please. :)
<BenC> there's no lrm, and not touching linux-meta, and don't suggest to anyone to install it :)
<jb-home> infinity: It's only bad because you have the rights to approve uploads to edgy, don't you? =)
<BenC> I don't have all the third-party drivers in place yet
<doko_> jb-home: I can disable double-128 for sparc for now, but we shouldn't open the archive before we can fix that
<jb-home> doko_: Right, it seems like it's just a patch missing from the backport, yes?
<doko_> jb-home: tell me which one ...
<jb-home> =)
<jb-home> Considering I had trouble *reading* the bloody assertion that was tripping...
<doko_> I'm currently trying to work around the C++ regressions, (fixes of accepts-invalid-code :-/ )
<doko_> yeah, and davem doesn't know either
<jb-home> Does it happen with pristine CVS?
<infinity> jb-home: s/edgy/feisty/ in the above?
<doko_> jb-home: 4.1 doesn't support double-128, 4.2 does
<infinity> Anyhow, if all the above babble is telling me we're not ready for the bootstrap, I can hold off.
<infinity> I have other stuff to do right now anyway.
<doko_> interim solution: make 4.2 the default on sparc and let fabbione fix the fallout bugs =)
<jb-home> infinity: No.  As in, it's bad if you type edgy in the changelog, because you have launchpad god rights.  You can accidentally make it go through. =)
<infinity> BenC: But please, do get us the kernel upload soonish, so when jeff and doko are ready, we're good to go with linux-libc-dev.
<jb-home> infinity: re: hppa...
<BenC> infinity: on its way, at 30k/sec, so give it some time
<infinity> jb-home: I'd have to put edgy back in "development" before I could do that, which would be a lot of effort to work around a typo.
<jb-home> infinity: Are there feisty chroots there based off of dapper?
<infinity> jb-home: There are no chroots for any arch, but yes, there will be an hppa/feisty chroot that's essentially a dapper chroot.
<doko_> jb-home: just ronne/i386
<infinity> (No chroots intentionally, so uploads don't trigger builds accidentally)
<jb-home> infinity: Cool.  So with any luck, it'll give us the kernel headers there.
<infinity> Assuming linux-2.6.19 can build on dapper, yeah.
<infinity> If not, this'll be a fun ride.
<jb-home> Oh, which it certainly can't.  Forgot about that.
<jb-home> Although I can tell you which pieces need to be built. =)
<infinity> If the only thing we need to pull in is linux-libc-dev, and one of you has already bootstrapped that on hppa, I'm all for cheating.
<jb-home> I have all the basic stuff to do it, just need Ben's source package.
<infinity> Okay, cool.
<infinity> I'm less concerned about hppa today anyway.
<infinity> But if we can squeeze it in here and there and make it happen, cool.
<BenC> infinity, jb-home: 5 more minutes to upload completion
<infinity> BenC: \o/
<infinity> Thanks, dude.
<infinity> Were Fabio's "The headers are so busted that the kernel's scripts/ directory can't even be compiled against the new linuc-libc-dev" concerns addressed? :)
<BenC> yep, retested today with latest git
<infinity> Awesome.  Thanks.
<BenC> done
<fabbione> morning guys
<BenC> hey fabbione
<fabbione> so what's the situation now?
<fabbione> new kernel is up?
<jb-home> Hola Fabbione!
<fabbione> jb-home: glibc still doesn't build on ppc
<doko> fabbione: see the reply from davem, that's our major sparc problem
<fabbione> doko: is that long-double thing REALLY required ?
<fabbione> doko: i am going trough my emails right now...
<fabbione> jb-home: did you commit that patch?
<doko> fabbione: yes, see PR28701
<jb-home> fabbione: No, I went to eat dinner. =)
<fabbione> doko: url?
<fabbione> jb-home: ok
<fabbione> jb-home: i am going to try to build glibc on ppc32
<jb-home> fabbione: Starting by build now.
<fabbione> but that will take some time
<doko> fabbione: http://gcc.gnu.org/PR...
<jb-home> The patch commits, anyway.
<jb-home> I think this thing usually takes about 20 minutes to build.
<jb-home> doko: oh, is that the shortcut?  I can never remember it. =)
<BenC> infinity: got the NEW for l-s-2.6.19
<fabbione> jb-home: we also still need to port the ubuntu locale patches to 2.5. in theory they could wait for the second upload..
<doko> jb-home: what was Alzheimers first name?
<jb-home> doko: Is "I don't remember" a good answer? =)
<jb-home> fabbione: They didn't apply cleanly?  I thought I had seen them in the patch set.
<fabbione> jb-home: i didn't even look at debian/patches YET
<fabbione> you know.. been doing only a merge for 8 hours or so
<doko> jb-home: yeah, ...
<fabbione> ppc32 fired up
<fabbione> doko: when is gcc-4.2 due to?
<doko> just branched
<doko> no release date
<fabbione> what does that mean in gcc world usually?
<fabbione> 3 months? 20 months?
<doko> maybe 3, maybe 5 months
<fabbione> wow...
<fabbione> jb-home: building glibc on ppc32 basically froze my entire machines except the ssh sessione where it's building
<jb-home> fabbione: Fucked kernel?
<fabbione> jb-home: possibly.. 
<fabbione> Linux daltanius 2.6.19-1-powerpc #1 Mon Oct 23 05:18:52 CEST 2006 ppc
<fabbione> it's rc2
* fabbione reboots in .17
<fabbione> infinity: feisty doesn't exists on the mirrors yet?
<fabbione> doko: i dunno what to do with gcc... i have no idea what to look for and so on..
<infinity> It won't until something is published in it, I susect.
<fabbione> should we go for 4.2 branch for all arches?
<infinity> Woo, the queue tool still defaults to edgy.
<infinity> \o/
<BenC> will new gcc build hppa kernels yet?
<fabbione> BenC: yes. 4.1 should do
<fabbione> we don't know yet if they will boot, but to start with, it's enough it builds :)
<infinity> Although, hrm, I'd expect something to be published by now...
<infinity> Maybe the publisher hasn't been run since the import.
<infinity> Feh.
<infinity> No Team Soyuz around to confirm which step we're at.
<infinity> I may have to wait until malcc wakes up before I start this dance.
<fabbione> infinity: don't sweat it... glibc and gcc are not ready yet
<infinity> Kay.  I'll get the kernel building as soon as I have malcc's okay, at least.
<fabbione> infinity: yeps...
<infinity> hppa will have to wait, of course, cause it'll need manual love, but the other 5 should work, right?
<fabbione> not yet
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: glibc: ppc busted | gcc: sparc busted
<infinity> BenC: On which arches will the kernel actually build? :)
<BenC> should build on all
<fabbione> infinity: all of them.. i did test build on all 6 a couple of days ago
<infinity> Even hppa/dapper?
<fabbione> hppa will need edgy kernel-package and kernel-wedge otherwise it should be good
<infinity> (I suspect that will require love)
<infinity> Ahh, that's it?  Cool.
<fabbione> yes
<infinity> I can manage that.
<fabbione> the resulting kernel will NOT boot
<fabbione> but it will build
<infinity> Booting is not critcal, getting linux-libc-dev is.
<fabbione> BenC: i assume you did pull also my changes to debian/d-i/ for ia64 and hppa, right?
<fabbione> i didn't notice the commit logs after that depatch-repatch
<BenC> fabbione: yep
<fabbione> that should do
<fabbione> if nothing drastic changed in the meantime
<jb-home> Looks like I got the patch to build with the 2.6.19 headers right enough this time.
<infinity> "right enough"
<jb-home> infinity: As in, the build didn't fail.
<jb-home> Not that I've reduced the patch to the set that I would expect to get past drepper.
<fabbione> doko: <fabbione> should we go for 4.2 branch for all arches?
<jb-home> Eh, no.
<jb-home> Having the merge be done with 4.2 in it's current state would almost certainly mean a rebuild after something crazy was discovered.
<jb-home> They only branched what, a week ago?  maybe two?
<fabbione> fun :)
<jb-home> If we were sane and kept the results of the rebuild at the end for publishing, I'd say go for it.
<jb-home> But I'd also track glibc-2.6 actively through the release.
<fabbione> jb-home: that's MV spec (glibc-2.6 tracking).. we could start packaging it immediatly together with gcc-4.2 and use them offbw for some crazy rebuild.. we would have feisty+1 toolchain ready at the same moment it opens
<jb-home> fabbione: By spec for the last two release, we're supposed to have had places to upload toolchains and the ability to do test rebuilds.
<jb-home> Hard to get enthusiastic for that a third go 'round.
<fabbione> jb-home: well let's put this way ... with my addition to the toolchain slackers, at least i have enough CPU power at home to do main once in a while for all arches
<jb-home> fabbione: Ah, are you officially added to the crew now? =)
<fabbione> jb-home: didn't you add me to the team?
<jb-home> Yeah.  You just hadn't acknowledged it before. =) 
<fabbione> yeah yeah... whatever you say.. i am committing to glibc for fun :)
<jb-home> fabbione: Do you remember on which test she zombie'd out?
<fabbione> ppc ?
<jb-home> Yeah.
<fabbione> no, and i just started a build on davis disabling the test suite
<fabbione> you are late by 30 secs or so
<jb-home> Late how?
<jb-home> No build logs?
<fabbione> late with me doing ./debian/rules clean && rm ../*.build
<jb-home> Ah.
<jb-home> I'm just curious if I've passed that point already or not.
<fabbione> don't worry.. i can rebuild running the test suite and claim that i thought i was using my machine
<fabbione> hostnames are very similar :)
<jb-home> davis versus datbloodppcbox?
<fabbione> well get to the debs .. there might be an error in sysdeps/powerpc.mk anyway for the headers install in ppc64
<jb-home> bloody. even.
<fabbione> davis versus daltanius
<fabbione> you know.. tab completion shit
<fabbione> i blame bash and its maintainer ;)
<fabbione> it means that in case i will never get root on ANY of the DC machines, but i don't think that will ever happen anyway
<jb-home> Eh, why don't I have any swap on my box...
<jb-home> Oh I see the problem you were describing.
<jb-home> So it doesn't actually stop the build at all.
<fabbione> are you getting Zombies?
<fabbione> Zl to be exact
<jb-home> 23241 jbailey   21   0     0    0    0 Z   95  0.0   3:17.46 ld.so.1 <defunct>  
<jb-home> 23103 jbailey   16   0     0    0    0 Z   13  0.0   0:40.09 ld.so.1 <defunct>  
<jb-home> 23159 jbailey   16   0     0    0    0 Z   13  0.0   0:32.74 ld.so.1 <defunct>  
<jb-home> 23196 jbailey   16   0     0    0    0 Z   13  0.0   0:28.47 ld.so.1 <defunct>  
<jb-home> 23120 jbailey   16   0     0    0    0 Z   13  0.0   0:36.73 ld.so.1 <defunct>  
<jb-home> 23139 jbailey   16   0     0    0    0 Z   13  0.0   0:33.48 ld.so.1 <defunct>  
<jb-home> 23176 jbailey   16   0     0    0    0 Z   13  0.0   0:29.87 ld.so.1 <defunct>  
<jb-home> 23216 jbailey   21   0     0    0    0 Z   12  0.0   0:29.16 ld.so.1 <defunct> 
<fabbione> yeps
<fabbione> i am still not getting them on ppc32 kernel
<fabbione> well at a certain point the testsuite will hang
<fabbione> it won't take long from there
<jb-home> Swap: 19531232k total,        0k used, 19531232k free,  1398728k cached
<jb-home> Much better.
<fabbione> * tim (n=tim@carl-sgc-sg-1.inter-touch.net) has joined #canonical
<fabbione> who is he?
<fabbione> ops.. ECHAN
<jb-home> fabbione: You're one of thoses detectives that work for HP, aren't you?
<fabbione> ehhehe
<jb-home> So hmm.  Are those zombied because of a bug in glibc, the kernel, or upstart?
<fabbione> those are spawned by glibc build so i can't think of anything upstart related.
<fabbione> i am trying to exclude the kernel, building on ppc32
<jb-home> They're parented to 1
<jb-home> So wouldn't that mean they might be hanging around for not having SIG..CHLD? acknowledged by upstart?
<jb-home> Especially since they appear to be spinning?
<jb-home> Or using up CPU time somehow?
<fabbione> hmm
<fabbione> no i exclude upstart.. davis is running dapper
<fabbione> and i could reproduce it there
<fabbione> and it's running 2.6.15.x
<fabbione> compared to .17 on your box perhaps?
<jb-home> Yeah, I'm current edgy from 2 days ago or so.
<fabbione> right.. so am i
<jb-home> kill -9 won't take it out, so it's not a userspace problem.
<fabbione> as i told you yesterday you need a hard reboot of the box
<fabbione> brb
<jb-home> Bedtime soon for me.
<jb-home> I'll try asking Steve Munroe from IBM tomorrow.
<jb-home> fabbione: It made it through the nptl tests, which is where I would've expected permanent problems if nothing else.
<fabbione> jb-home: since it doesn't take too long to build there, could you please get it to the deb before you head to bed?
<jb-home> fabbione: It's working it's way through now.
<fabbione> ok
<fabbione> i am running 2 builds here: full on ppc32 and without test suite on ppc64
<jb-home> But with a zombie taking up 98% of one CPU, and a collectiong of others fihting for the second one, it's not going quickly.
<fabbione> so what i would suggest is:
<jb-home> In the meantime I'll commit the build fix.
<fabbione> if ppc32 builds fine without zombies and ppc64 goes trough, we look at the tests results from ppc32 and upload temporary disabling the test suite
<fabbione> (assuming the results are good enough)
<jb-home> Errr...
<jb-home> I'd *really* rather talk to Steve first.
<fabbione> well that can be parallelized :)
<fabbione> it's not going to happen before monday anyway
<jb-home> What part of "first" can be parallelized? =)
<fabbione> our test build can parallelize with you talking with Steve :)
<jb-home> Lovely, I've commited that.  Builds will now demand newer linux-libc-devs than edgy has.
<jb-home> And it's 00h36, time for sleep.
<jb-home> See y'all.
<fabbione> night jeff
<fabbione> jb-home: it hangs on ppc32 too
<fabbione> F U C K
<fabbione> davis did build without testsuite but clearly that's NOT good
<fabbione> jb-home, infinity: mailed all the ppc hackers for glibc issue.. let see what happens
<fabbione> BenC: latest git is FTBFS on ppc 
<fabbione> oh nevermind
<fabbione> it's Olaf patch
<fabbione> jb-home: portforwarded the patches from glibc-2.4 
<fabbione> so we should be good with that
<cjwatson> doko: edgy-{proposed,updates} are open as of edgy release; follow StableReleaseUpdates as usual
<infinity> (open and functional, even)
<cjwatson> infinity: publisher should've been run since i-f-p happened ...
<infinity> cjwatson: Should've, as in "you think it has", or as in "why hasn't it"?
<infinity> cjwatson: I've been waiting for malcc to show up to give me a status report.
<cjwatson> $ ls ubuntu/dists/feisty/
<cjwatson> Release  Release.gpg  main  multiverse  restricted  universe
<cjwatson> can't see what else would've put that there. :-)
<infinity> Yeah, fair point. :)
<infinity> (I thought someone said that wasn't there earlier..)
<infinity> Well, then, I guess we can NEW the kernel, and I can work on getting it building.
<cjwatson> at this point I'm happy to turn the cron job back on
<infinity> Also, the queue tool still defaults to edgy.  Fun.
<cjwatson> now done
<cjwatson> yeah, I noticed that
<cjwatson> I wonder if that's because feisty is EXPERIMENTAL not DEVELOPMENT
<infinity> Could be.  Why is it, anyway?
<infinity> I'll happily change it.
<infinity> I thought EXPERIMENTAL was meant to only exist if there was *also* a DEVELOPMENT release.
<infinity> (And, afaik, we've never actually used it for anything)
<cjwatson> right
<fabbione> i suggest you feisty in frozen
<fabbione> till we bootstrap the toolchain
<infinity> I'm down with that idea.
<cjwatson> that will work for queue too
<fabbione> infinity: it wasn't on the mirror a couple of hours ago
<infinity> There, it's frozen now.
<cjwatson> queue (and everything in launchpad that does Distribution.currentrelease) tries FROZEN, DEVELOPMENT, CURRENT in that order
<cjwatson> and if there isn't one of those then it just picks the first one
<infinity> cjwatson: Err, did you already NEW the kernel?
<infinity> Oh, feh.  The changes list is empty.
<cjwatson> infinity: no
* infinity fixes.
<cjwatson> does feisty-changes exist yet?
<cjwatson> it didn't last night
<infinity> Yes.
<cjwatson> wait until I subscribe? :-)
<cjwatson> not that I'm a sad completist or anything
<infinity> Be quick. :)
<infinity> Okay, NOW it's frozen (and has a changes list)
<infinity> cjwatson: Subscribed yet, huh, huh? :)
<cjwatson> BenC: you seem to have gone back to native packaging rather than .diff.gz ...?
<fabbione> cjwatson: yes it's an -rc..
<fabbione> no point to go .diff.gz
<fabbione> i guess he will switch with .19 final
<cjwatson> infinity: yes. :-)
<cjwatson> fabbione: ah
<fabbione> cjwatson: this upload is only to bootstrap
<fabbione> not for use
<cjwatson> I know
<infinity> Well, she's accepted.
<infinity> Now I get to play.
* infinity does a publisher run, real quick-like.
<Keybuk> doesn't that need a toolchain? :p
<infinity> Oh, I remember what I wanted to ask malcc (he says, 2 minutes after the publisher starts)...
<infinity> cjwatson: Are we sure the dsync changes got made, so we don't keep altering edgy?
<infinity> Keybuk: linux-libc-dev is the first bit of the chain that we want.
<Keybuk> ahh
<Keybuk> of course
<Keybuk> I'd forgotten about that
* infinity runs to 7-11 for nutrience while the publisher does... Stuff.
<cjwatson> infinity: yes
<cjwatson> malcc commented out link-dups; we have a better solution in testing
<infinity> cjwatson: Oh, good.  I didn't want to have to test how well the publisher deals with a SIGINT.
<cjwatson> hah
<cjwatson> we made sure of this before creating feisty. :)
<cjwatson> Keybuk: carlos wants to start up feisty translations before we do the first big auto-sync, if possible
<cjwatson> which requires downing launchpad for a few hours
<fabbione> cjwatson: we don't have glibc yet.. so that shouldn't be an issue
<Keybuk> cjwatson: that's ok
<fabbione> jb-home and I think we will need a new kernel on ppc buildd to let glibc build
<Keybuk> we also need to sync edgy -> feisty before I'll do the unstable -> feisty one ;P
<Keybuk> and that needs a toolchain
<fabbione> edgy -> feisty?
<fabbione> isn't that done automatically when they "clone" edgy into feisty?
<Keybuk> apparently not
<Keybuk> it appears to have been done now though
<Keybuk> it wasn't when I looked yesterday
<fabbione> qh ok
<cjwatson> yeah, that was done early on
<infinity> cjwatson: I'm down with the initial translation run being done anytime after this publisher run is done, since my kernel builds will likely be out-of-band anyway.
<infinity> And, the publisher just finished.
<Keybuk> *sigh*
* Keybuk so can't remember how mom works
<infinity> She just sits at home, does laundry, and watches Oprah while dad works, doesn't she?
<infinity> At least, that sounds like my mom.
<Keybuk> this is the first release cycle where she hasn't had a PMT attack, so I literally haven't touched her for sixth months!
<Keybuk> we should let Hobbsee loose on the archive, if only to free up some disk space on casey :)
<fabbione> Keybuk: i knew about PMS attack.. PMT?????
<Keybuk> fabbione: another word for PMS, I guess s/Stress/Tension/
<fabbione> syndrome ... yeah gotcha
<fabbione> dict has a lot of interesting other definitions tho :)
<cjwatson> infinity: are you the one accepting stuff?
<cjwatson> infinity: note that debootstrap has some C programs in it
<infinity> cjwatson: I am.
<infinity> cjwatson: Don't mind so much, I'd just like to see it built and useable.
<infinity> cjwatson: It'll get reuploaded at least once, I'm sure. :)
<cjwatson> fair enough :)
<jb-home> fabbione: The build hang is *tee* hanging.
<jb-home> Whacked.
<infinity> (Not accepting anything else, mind you)
<cjwatson> infinity: just uploaded debhelper; you might want that
<cjwatson> I'm skipping dpkg because (a) it's bloody hard to merge and iwj can do it and (b) it doesn't seem necessary
<cjwatson> mind you, debhelper doesn't look like a huge deal either
<jb-home> fabbione: Oh, I guess that makes sense since the children haven't exitted.
<jbailey> fabbione: Still around?  /proc/##/wchan says that the process is sitting in do_exit
<jbailey> Is there any way to tell where it is in that?
<doko> fabbione: gcc-4.1 built on 2.4 at davis:gcc/4.1/
<lamont> jbailey: twisting like a baby in a slow flame?  you sick puppy
<jbailey> lamont: Eh?
<jbailey> Oh.  It's a quote from a Cult song called "edie"
<lamont> 27-10-2006 06:17:36 -!- jb-home!n=jbailey@modemcable139.249-203-24.mc.videotron.ca has left #ubuntu-toolchain ["Twisting like a flame in a slow dance, baby..."] 
<lamont> maybe I transposed a few words
<jbailey> Perhaps. =)
<jbailey> Although it's an incredibly depressing song.  One of the ones I really enjoyed as a teenager.
<fabbione> jbailey: i am here now. i did mail all of upstream.
<fabbione> doko: it does?!?!??
<fabbione> doko: glibc-2.5? please doublecheck
<doko> fabbione: I'm currently building in feisty-libc
<fabbione> doko: ok...
<fabbione> these Niagara failures are scary. i need to talk to david
* lamont wonders if there's any signficance to neither of his pet architectures being in the topic
<fabbione> lamont: ia64 is ok already as i told you
<lamont> fabbione: right.  must wake up.
<fabbione> lamont: hppa we need to do some extra bootstrapping love but getting ready for it
<lamont> and hppa has the signals, um, patch.  plus bootstrapping
* ..[topic/#ubuntu-toolchain:lamont] : STATUS: glibc: ppc busted | gcc: sparc busted | hppa: bootstrapping needed
<fabbione> doko: looks good glibc.. dunno what to say
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: glibc: ppc busted | hppa: bootstrapping needed
<fabbione> so we only need ppc glibc
<lamont> rock
<fabbione> jbailey: anyway i did build a set of debs for ppc
<fabbione> without running the test suite
<jbailey> fabbione: Any thoughts on my debugging questiosn?
<fabbione> no i have no idea. i did spoke with benh and he also believes it's a kenrel bug
<fabbione> and he said that they were going to look at it very quickly
<jbailey> Cool.
<fabbione> oh doko halt stop.. are we talking about davis??? or faure?
<fabbione> i got confused now
<fabbione> doko: there is also a feisty-libc chroot on davis with 2.5
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: glibc: ppc busted | gcc: sparc | hppa: bootstrapping needed
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: glibc: ppc busted | gcc: sparc busted| hppa: bootstrapping needed
<fabbione> jbailey: btw i did also port the ubuntu patches to 2.5 so that's done. i assume all the other dirs are "ok" and we don't want to delta from them
<jbailey> other dirs?
<jbailey> You're scaring me. patches are in a pile of directories..
<fabbione> jbailey: in 2.4 we had an ubuntu directory for our own patches.
<fabbione> i did port them to 2.5 (one only required)
<fabbione> the other dirs.. with tons of patches...
<fabbione> i am assuming we don't want to create a huge delta with Debian
<fabbione> except for the documentation one
<infinity> Ideally not.
<fabbione> (removed from debian/patches/series only)
<fabbione> infinity: exactly
<doko> fabbione: davis
<fabbione> doko: ok.. there is feisty there.. before i read faure... dunno why
<BenC> no builds for linux-source-2.6.19?
<infinity> BenC: No chroots (officially), so no build records, I'm playing with stuff manually.
<infinity> I'm taking my time with some fiddling here and there, since I'm not opening anything until glibc and gcc happen anyway.
<doko> infinity, fabbione: is a test rebuild of the archive on sparc and powerpc possible, using the new toolchain?
<Dvalin> busted?
<Dvalin> what kind of status is "busted"?
<Dvalin> is it good or bad? :p
<Keybuk> http://www.thefreedictionary.com/busted
<Dvalin> okay
<Dvalin> broken..
<fabbione> doko: sparc yes.. no idea for ppc
<fabbione> doko: i could theoretically ppc here, but it's slow and i need the laptop
<doko> fabbione: ok, do we have a dependency order, how to build?
<fabbione> doko: yes. kernel first -> binutils or glibc (depends how much we care about hppa) -> gcc -> open gates
<jbailey> fabbione: binutils is also for PT_GNU_HASH
<fabbione> ok
<fabbione> so kernel (that's already uploaded) -> binutils -> glibc -> gcc -> opengates
<jbailey> so kernel -> binutils -> glibc -> gcc -> glibc -> binutils -> gcc -> open gates probably.
<fabbione> yeah or something like that
<doko> fabbione: no, long double ... 64 != 128 
<doko> we have to be careful ...
<doko> on sparc and powerpc
<Dvalin> fabbione: btw. why do you build for sparcv8 and not sparcv9 when sparcv8 isn't supported (~broken?) anyways?
<fabbione> Dvalin: that was David request to do it that way
<Dvalin> dunno what additional optimizations one could actually really aquire in real world by building for sparcv9, but seems odd to me..
<Dvalin> fabbione: hmm, okay, but any reasoning behind it?
<fabbione> i don't recall
<fabbione> it was something done a year ago
<Dvalin> for Mandriva I was thinking of trying to keep a pure sparcv9 (sparc32plus v8+ abi) for consistency, maintainability and performancewise
<Dvalin> also wouldn't a more precise target be sparcvX-blabla-linux-gnu than sparc-blabla-linux-gnu?
<Dvalin> if for nothing else, consitency and clarity of actual platform..
<fabbione> Dvalin: you are really talking to the wrong guy :) i am not the gcc expert 
<Dvalin> fabbione: well, you're still the sparc guy, and uh.. we're in tthe chan for gcc experts, soo, doko? :)
<Dvalin> also, was it a decission pre or post 2.6 (sparc32 ~brokenness)?
<fabbione> Dvalin: sparc is a supported arch.. everybody contributes to it.. not just me.. i am the one that goes around trashing people testicles to get stuff fixed
<Dvalin> fabbione: sparcv7?
<fabbione> we did never support sparc32 from the beginning
<Dvalin> yes
<Dvalin> that's why I refer to sparcv9 as more consistent/precise target than sparc (as it's ~known as sparcv7)
<fabbione> Dvalin: i don't have any energy left today.. neither for sparc or for me :)
<Dvalin> (keep in mind, I'm speaking of lack of knowledge, this might be obvious to the rest of you, but educational for me, aka: don't get annoyed;)
<fabbione> let's look at it tomorrow or monday
<Dvalin> fabbione: yeah.. I didn't neither
<Dvalin> my concerta was ending
<Dvalin> but then I had some tequilas
<fabbione> sorry but i am really just way too tired to focus
<Dvalin> and shared a puffpuff with my gf.. then I got excited ;)
<fabbione> between release yesterday and other stuff
<Dvalin> fabbione: I totally understand you :)
<Dvalin> (as pointed out earlier, I might be some sporadic/erradic/hyperactive;)
<fabbione> we noticed :)
<Dvalin> (note to everyone than fabbione, so people will not get *that* easily annoyed for me being annoying.. adhd..)
<Dvalin> fabbione: good :)
<Dvalin> I hate to come by channels, asking questions I've actually done some rtfm and then feeling like a total retard since it's so obvious to everyone else, especially when I'm hubahubaadhdboy
<Dvalin> =)
<Dvalin> btw.
<Dvalin> are ubuntu involved in the EDOS project?
<Dvalin> (I know niemeyer was when being onboard with us)
#ubuntu-toolchain 2006-10-28
<fabbione> doko: got gcc for sparc. will test tomorrow
<fabbione> doko: how big do you want the test case?
<doko> fabbione: main would be nice
#ubuntu-toolchain 2006-10-29
* cjwatson accepts kernel binaries (amd64, i386, ia64)
<fabbione> cjwatson: no point.. we need another kernel upload
<cjwatson> fabbione: fair enough, probably did no harm to NEW it though :)
<fabbione> cjwatson: yeah
<doko> fabbione: how is the test build looking?
<fabbione> doko: i will start it tomorrow morning. waiting Jeff to send me binutils and it's sunday :) i had to take care of my son today
<fabbione> i have katie ready anyway
<fabbione> it's a matter of few commands to start it
<fabbione> doko: do you want to receive the buildlogs via email?
<fabbione> infinity: same question for ya..
<fabbione> doko: i got a  clean glibc build on ppc. building gcc now
<Dvalin> you have kids?
<Dvalin> :o)
<fabbione> Dvalin: yeps.. one
<fabbione> http://people.ubuntu.com/~fabbione/christian.jpg
<Dvalin> cool
<Dvalin> fabbione: current toolchain for sparc broken in ubuntu?
<fabbione> Dvalin: edgy is fine. we are testing for the next release
<fabbione> glibc are ok
<fabbione> gcc did build but it needs testing
<fabbione> that's what i am going to do tomorrow
<fabbione> Dvalin: with the niagara i will rebuild a random set of a 1000 pkgs
<fabbione> and install them
<fabbione> see if nothing obvious break
<Dvalin> okay
<Dvalin> I had some difficulties tracking your packages
<Dvalin> in comparision to our ways
<Dvalin> but I haven't had much time to investigate the issue much further
<fabbione> tuesday i might have some spare time and i can give you the general directions on how we package/patch
<fabbione> that can help you a bit
<Dvalin> :)
<Dvalin> that would be cool
<fabbione> if you still have the installation on the other disk we can use it as chroot to get the tools to unpack and stuff like that
<Dvalin> I have it available, been playing with it via chroot some :)
<Dvalin> but I'm still puzzled by sparcv8 as default target..
<Dvalin> I can see a few reasonings for it maybe, but some of it seems kinda obsoleted..
<fabbione> doko: gcc 18ubuntu1 doesn't build on ppc
<doko> fabbione: thats on feisty?
<fabbione> yes
<fabbione> glibc-2.5
<fabbione> i took the source from ronne/doko/gcc/4.1/
<doko> fabbione: successfully built it on davis:~doko/gcc/4.1, using glibc-2.5 ...
<fabbione> try using linux32 dpkg---
<fabbione> this is on ppc32 kernel
<fabbione> also the glibc on davis didn't pass the test suite
<fabbione> this one did
<doko> fabbione: linux32 ...  does work, but not on a G4, thats known
<fabbione> doko: davis is G5 ppc64
<fabbione> my failure is on G4 
<doko> if you want to build on a 32bit kernel, you cannot build biarch
<fabbione> that's special.. 
<fabbione> but ok
<doko> I still don't understand what does work and what not. I could successfully build the biarch compiler in the feisty-libc chroot on davis
<fabbione> glibc that was built on davis for feisty-libc was without the test suite. That problem has been hunted down to a kernel issue
<fabbione> next i did build glibc locally (ppc32) with the whole test suite and it went ok
<fabbione> and then i did try to build gcc
<fabbione> and it fails
<fabbione> as you say it's known but it sounds strange to me
<doko> fabbione: it's a failure during the configury of the target libraries, isn't it?
<fabbione> Configuring in powerpc-linux-gnu/libiberty
<fabbione> looks likw
<fabbione> like
<doko> yes, so install your new glibc on davis tomorrow and try there again
<doko> (or build gcc-4.1 prefixed with WITHOUT_LANG=biarch ...
<fabbione> i don't have root on davis
<fabbione> i need to ask admins to do it for me
<fabbione> ok
<doko> elmo seems to be awake ...
<doko> fabbione: ^^^
<fabbione> doko: yes, but we don't have the kernel yet
<fabbione> we need Ben to upload
<doko> ahh, ok
<fabbione> elmo is NEVER going to run a kernel from my deb... 
<fabbione> he can't trust them and that's the same i would do with his debs
<fabbione> he needs to get them out of archive
* fabbione -> bed
<fabbione> good night
#ubuntu-toolchain 2007-10-23
<arthur-> hi doko 
<doko> good morning
