[12:01] <jbailey> Bah.
[12:02] <jbailey> I just retested locally, and it doesn't fail there.
=== jbailey sets up a minimal chroot.
[12:33] <lamont__> jbailey: minimal chroot?  (maybe missing build-deps?)
[12:34] <jbailey> Right, I usually test in a chroot I use for development.
[12:35] <jbailey> I don't see how it built before if it was missing a build-dep, but I've slimmed down the chroot for this build.
[12:36] <jbailey> I think I need to hack glibc (and maybe cdbs) so that if a build fails at configure time that config.log is spit to stdout.
[12:45] <jbailey> Mm, missing build-dep on the bit the provides libcgcc_s_64
[12:46] <jbailey> erm
[12:46] <jbailey> or not.
[12:46] <jbailey> That's provided by gcc-3.4 supposedly.
[01:15] <jbailey> doko: Still around?
[01:28] <doko> yep
[01:29] <jbailey> doko: I figured it out.  collect2 was acting strange, but I hadn't realised that gcc would change its arguments to collect2 based on what was available.
[01:29] <jbailey> lamont__: In Debian (and in Ubuntu if you know...) is libc6-dev-sparc64 usually already in the base chroots / is it part of build essential?
[01:30] <jbailey> lamont__: I'd like to have ppc64 be consistant with current practice for sparc/s390
[01:30] <lamont__> jbailey: nfc
[01:30] <lamont__> for it to be there (properly), it needs to either be essential, or a Depend: of build-essential
[01:33] <doko> only for sparc, not s390
[01:34] <BenM> Hey doko, tseng sent me to you
[01:35] <doko> BenM: i
[01:35] <doko> BenM: hi
[01:35] <BenM> mono is failing its regression test on gcc4
[01:36] <BenM> and tseng thought you might be able to help out
[01:36] <doko> jbailey, lamont__: b-e lists the 64bit dev only for sparc, not s390
[01:36] <doko> BenM: I do? hmm. all of them?
[01:37] <BenM> well, one specific test case gets a segfault
[01:37] <BenM> we are pretty sure something is getting miscompiled
[01:38] <BenM> http://primates.ximian.com/~bmaurer/mono-1.1.8.tar.gz
[01:38] <BenM> its reproducable on that
[01:38] <BenM> you just have to configure; make; make check
[01:38] <doko> what does happen, if you reduce the optimization level? any warnings?
[01:39] <BenM> it happens both on -O2 and -O0
[01:39] <BenM> no warnings for the file other than pointer signedness
[01:39] <doko> ahh, you know the file. does gcc-3.4 work?
[01:41] <BenM> yes
[01:41] <BenM> well, by that i mean "the file where the backtrace says the segfault happens"
[01:42] <BenM> there isn't anything suspcious in the entire build log though
[01:44] <jbailey> lamont__: Any objection to it being added to b-e?
[01:50] <doko> so, if you compile the testcase with 3.4, the testcase works? or a file from the distribution?
[01:51] <lamont__> jbailey: that gets back to the question of whether or not it is build-essential...
[01:51] <BenM> well, the test case is c# :-)
[01:51] <lamont__> jbailey: for which, I'd recommend a discussion with the build-essential maintainer
[01:51] <lamont__> == keybuk
[01:52] <BenM> the issue is, if I compile mono using gcc4, it fails
[01:52] <BenM> if i compile mono with gcc!=4, it works fine
=== BenM is now known as bhome
[02:47] <jbailey> lamont: I couldn't remember your email address, so I didn't cc: you, but I've emailed scott.  If it turns out that it gets added to b-e, we just need to respin the build, otherwise I'll need to add the build-dep
[02:48] <jbailey> lamont: Did you keep your ubuntu.com address?  I remember that sabdfl was talking about them being available to members, so thought you might be  testcase. =)
[03:03] <lamont> jbailey: yes, still have ubuntu.com
[03:03] <jbailey> Luvly
=== BenM [~benm@c-24-128-49-153.hsd1.ma.comcast.net]  has joined #ubuntu-toolchain
[03:08] <BenM> doko, gotten a chance to try that tarball yet
[03:08] <BenM> ?
=== BenM is now known as bcook
=== bcook is now known as BenM
=== lamont__ [~lamont@rover3.mmjgroup.com]  has joined #ubuntu-toolchain
[06:18] <fabbione> morning
[06:26] <fabbione> lamont: ping?
[06:26] <lamont> ack
[06:27] <fabbione> lamont: we will need to revert the gcc-3.4 b-d stuff...
[06:27] <lamont> fabbione: having difficulty verifying that ipsec traffic is passing back through INPUT once unencapsulated.
[06:27] <lamont> iz annoying
[06:27] <lamont> fabbione: why?
[06:27] <fabbione> unfortunatly we need the latest gcc and latesr k-p to build
[06:27] <lamont> on all architectures?
[06:27] <fabbione> 11753
[06:27] <fabbione> no only i386
[06:27] <lamont> because the relaxed check made it so that I could build... :-)
[06:29] <fabbione> yeah i know
[06:29] <lamont> ah, so make the build-dep be powerpc i386
[06:30] <fabbione> yeah that too
[06:32] <fabbione> kernel-package (>= 8.135ubuntu4) [powerpc] , kernel-package (>= 8.132ubuntu2) [!powerpc]  ???
[06:32] <fabbione> kernel-package is arch all
[06:33] <fabbione> but we will need to upgrade that too :/
[06:34] <fabbione> gcc-3.4 (>= 3.4.4-0ubuntu6) [powerpc i386] , gcc-3.4 [!powerpc !i386] 
[06:34] <fabbione> does it look sane?
[06:34] <fabbione> i can never remeber how to add more than arch to [] 
[06:35] <lamont> I believe that's it
[06:35] <lamont> (comma is right out..)
[06:37] <fabbione> yeah i did check with other packages too :)
[06:39] <fabbione> lamont: what did you change in the configs?
[06:41] <lamont> fabbione: I added the missing lines.
[06:41] <lamont> R2[45] 00, SQUASHFS, HOSTAP
[06:41] <fabbione> ah ok
[06:41] <fabbione> it was just an update
[06:42] <lamont> well, it was a 'fix hppa configs since they didn't get updated with the addition of the drivers'... but I shortened that...
[06:42] <fabbione> humm
[06:42] <fabbione> sorry.. i might have done that in a different way recently
=== BenM is now known as bsleep
=== chmj [~d3vic3@dumbledore.hbd.com]  has joined #ubuntu-toolchain
[10:02] <chmj> jbailey, thanks for the patch 
[11:41] <jbailey> chmj: Glad to show it to you. =)  IT's just really nice to have all that information for tracking.
[11:41] <jbailey> chmj: We found that we were starting to lose track of where things things came from and why we did them. =)
[11:43] <chmj> oh ok, that format sure has enough info 
[11:45] <jbailey> doko: I thought sparc killed the wrapper a couple years ago on the grounds that it was unpredictable and that it sucked? 
[11:46] <jbailey> lamont, fabbione: ping re: builds of glibc on your archs. =)
[11:46] <fabbione> jbailey: i am still building gcc-*
[11:46] <fabbione> jbailey: once it's done i will do glibc
[11:47] <jbailey> fabbione: Cool.
[11:47] <fabbione> it's running the test-suite right now
[11:47] <fabbione> it shouldn't take too long
[11:47] <jbailey> Any idea how the hack is going to get the build-logs onto people so I can just see them myself?
[11:47] <doko> jbailey: no, the thread on d-sparc
[11:48] <doko> jbailey: so you upload a glibc with fixed b-d's?
[11:48] <jbailey> doko: Ah, a'ight.
[11:48] <fabbione> jbailey: i didn't manage to talk with elmo in a few days
[11:48] <fabbione> jbailey: i will need to check with him
[11:48] <jbailey> doko: I haven't.  If we're adding it to build-essential, it just needs a give-back.
[11:49] <jbailey> doko: (I've also been awake for about 10 minutes)
[11:52] <doko> jbailey: as you like it, but for packages like zlib1g and others, we should explicitely add it.
[11:52] <jbailey> Why?
[11:52] <doko> push back a package to Debian and it will fail
[11:53] <doko> it's not a big job to add that b-d for these few packages
[11:53] <jbailey> True.  I just hate b-d'ing on b-e packages.
[11:55] <doko> so we should add amd64-libs-dev to b-e as well?
[11:55] <jbailey> That's the question. =)
[11:56] <jbailey> Or should sparc be made like the others and have sparc64 dropped from b-e?
[11:56] <doko> no, then we have to change the gcc wrapper as well ...
[11:57] <jbailey> We should be treating biarch configs consistently.
[11:57] <doko> but what about an update for amd64-libs to match our current glibc before we go multiarch?
[11:57] <doko> Mithrandir: ^^^
[11:58] <jbailey> But I tend to fall on the side of thinking that the sparc-gcc wrapper is teh suck.
[11:58] <jbailey> right!  That's what I was going to ask you yesterday! =)
[11:58] <jbailey> To just clarify the include directories so I could do the glibc work for i386/amd64 and amd64/i386 biarch
[12:01] <doko> jbailey: I don't like it either, but BenC defends it
[12:01] <jbailey> Is benc the only one who defends it?  At this point I'd take joshk's word over ben's for the sparc port.
[12:02] <fabbione> jbailey: did you complete the kernel build with a ppc32 kernel?
[12:02] <doko> I would have to look
[12:02] <jbailey> fabbione: BAh, that's what I was supposed to do last night, sorry.  No, lemme reboot and start it now.
[12:02] <fabbione> eheh ok :) thanks
[12:02] <fabbione> there is no rush really
[12:02] <fabbione> i am not going to upload anytime soon
[12:02] <fabbione> i need to go and prepare food
[12:02] <fabbione> bbl
[12:06] <jbailey> doko: I'm just updating the status of my stuff for the wiki.  Want me to update ToolChainRoadmap?  I was thinking "C++ transition still in progress, ppc64 uploaded"
[12:06] <doko> sure
[12:07] <jbailey> Mm, and java bits in main?
[12:08] <jbailey> and C++ done for main
=== jbailey adds b-d for now to ppc
[12:21] <doko> still waiting for the OOo2 build ...
[12:23] <jbailey> glibc with added build-dep uploaded
=== doko_ [~doko___@dsl-084-059-033-037.arcor-ip.net]  has joined #ubuntu-toolchain
[12:52] <infinity> doko : Which OOo2 build are you waiting on?
[12:52] <infinity> doko : It was successful on i386/ppc, failed on amd64/ia64.
[01:21] <doko_> infinity: oh, nice, I didn't see them succeed, you know, the upload was done some months ago ;)
[02:39] <lamont> ln -sf /usr/include debian/libc6-dev/usr/hppa64-linux-gnu/include
[02:39] <lamont> ln: creating symbolic link `debian/libc6-dev/usr/hppa64-linux-gnu/include' to `/usr/include': No such file or directory
[02:40] <lamont> jbailey: that's the error I get from -5...
[02:40] <lamont> seems kinda familiar.. :-)
[02:41] <lamont> -6 is downloading now, build will happen sometime today, I expect.
[03:20] <Mithrandir> doko: amd64-libs is utterly uninteresting to me and jbailey have some things up his sleeve to get rid of it, afaik.
[03:22] <doko> Mithrandir: ok, would it be possible to keep building gcc-4.0 biarch in unstable ? would be a good thing to point people to it as a test for 64bit compatibility
[03:23] <Mithrandir> doko: yes, I think that would be a good thing.
[03:25] <doko> Mithrandir: asking, because it's NOT possible to build gcc-4.0 biarch in breezy at the moment
[03:25] <doko> I think we face the same problem in unstable once glibc get's updated?
[03:51] <jbailey> lamont: Don't bother with -6 then.
[03:56] <Mithrandir> doko: why isn't that possible?
[03:58] <doko> Mithrandir: build failure, just try to build the package with an installed amd64-libs-dev.
[03:58] <doko> IIRC, even if biarch is disabled
=== lamont__ [~lamont@15.238.5.160]  has joined #ubuntu-toolchain
[04:12] <jbailey> doko: ln: creating symbolic link `debian/libc6-dev/usr/hppa64-linux-gnu/include' to `/usr/include': No such file or directory
[04:12] <jbailey> doko: Who provides /usr/hppa64-linux-gnu ?
[04:12] <jbailey> Do we?
[04:12] <doko> hmm, glibc should provide that
[04:13] <jbailey> 'kay, I'll add the mkdir.
[04:13] <doko> it doesn't hurt. ok, it' currently not yet available, because I didn't build a hppa64 compiler yet.
=== bhome is now known as BenM
[05:49] <doko> infinity, lamont, lamont__: please requeue binutils for powerpc, if this is built and in the archives, then gcc-3.3 and gcc-3.4 for powerpc.
[05:51] <lamont__> doko: binutils kicked
[05:52] <doko> lamont__: thanks
=== lamont__ sighs, updates the chroots on ppc, and prepares to give binutils back again
[06:18] <jbailey> doko: Thanks
[06:18] <jbailey> lamont__: If you can do the same for ppc that would be lovely.
[06:18] <jbailey> err
[06:18] <jbailey> gdb on ppc
[06:25] <lamont__> jbailey: ok.  but grumbling about gdb just doesn't seem kind until after an incomplete statement of work. :-)
=== lamont__ grumbles about gdb.
[06:25] <lamont__> there -you happy>
[06:25] <jbailey> Wha...? =)
[06:26] <lamont__> you just want it given back?  or do I need to actually _do_ something to the chroot first?
[06:26] <lamont__> ah, same 'needs new procfs.h' issue
[06:26] <jbailey> Sorry, I had assumed this was in the queue after the "updates chroots on ppc" =)
[06:26] <lamont__> lol
[06:27] <jbailey> Bad optimiser!  Stop applying yourself to human interactions!
=== lamont__ is fighting with ipsec.  makes for a cranky mood
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
[07:46] <elmo> doko: have you seen this fun "gcc-4 miscompiles glibc" bug?
[08:36] <jbailey> elmo: Doesn't affect us, we use gcc-3.4 to compile glibc.
[08:40] <elmo> score
[08:41] <elmo> can we make it a goal to not be using gcc-3.4 for anything by breezy?
[08:41] <elmo> or is there anything that's unlikely to be compilable by 4.0 by release?
[08:41] <jbailey> I think we'd planned on glibc and the kernel staying with 3.4
[08:41] <jbailey> We still need 3.4 in the archive for g77 anyway, so we're not losing much.
[08:41] <elmo> whine
[08:41] <elmo> ok
[08:42] <jbailey> Neither upstream is advocating gcc 4 anyway.  glibc 2.3.5 doesn't compile with gcc-3.4 without patches.  The bug you're thinking of is for CVS HEAD of glibc.
[08:44] <elmo> yeah, it just makes me cry that we're carrying 4 compilers around
[08:44] <elmo> and using one of them to only compile basically two packages
[08:45] <jbailey> 4?
[08:45] <elmo> 2.95/3.3/3.4/4.0
[08:45] <jbailey> I thought we had dropped 2.95 already
[08:45] <elmo>   gcc-2.95 | 2.95.4.ds15-22 | breezy/universe | source
[08:45] <jbailey> Oh, hmm.
[08:45] <jbailey> NEeded to compile silo for sparc still.
[08:45] <elmo> it's kind of nice for some commerical crap too
[08:46] <jbailey> Feh
[08:46] <elmo> well, if you have a better way to monitor hardware raid array on big 3 servers, lemme know :p
[08:46] <jbailey> But 3.4 will probably need to stick around until the 4.2 timeframe when fortran catches up.
[08:46] <elmo> that long?  ouch
[08:47] <jbailey> Follow 4.1, it doesn't look like fortran is moving fast to get the old g77 specific bits in.
[08:47] <jbailey> s/Follow/I've been following
[08:47] <jbailey> Is it build errors in software that you can change, or linking problems from precompiled modules?
[08:48] <elmo> latter
[08:48] <elmo> not modules tho, just binary progs
[08:48] <elmo> usually linked to old libstdc++
[08:49] <elmo> it's not a huge problem, there are newer versions for FC 4 and so on, but I've had other problems with them
[08:49] <elmo> (glibc symbol errors RUN AWAY)
[08:49] <jbailey> afk a sec
[09:03] <jbailey> Right.  Those should probably all work fine against the breezy glibc.
[09:03] <jbailey> elmo: (And everyone knows that backports of glibc are a good idea.. Right kids?)
[09:07] <lamont__> jbailey: B4CKP0R75 RUL3Z!
[09:08] <lamont__> hey, I know.  lets backport breezy to Bo.
[09:08] <lamont__> All of it.
[09:08] <jbailey> lamont__: package by package or feature by feature?
[09:08] <lamont__> package-by-package in one fell swoop
[09:09] <lamont__> and build it twice, of course. :-)
[09:09] <jbailey> (/me fears how hard allowing bo to seamlessly dist-upgrade to breezy would be)
[09:09] <elmo> jbailey: chicken
[09:10] <lamont__> jbailey: best accomplished via rapid injection of lead into the crainal cavity
[09:10] <lamont__> cranial?
[09:10] <jbailey> I'm a tofudebeast, a far fiercer animal.
[09:10] <lamont__> jbailey: call the result frankenstein - people will expect seams that way.
[09:26] <fabbione> jbailey: right now silo is building with the default gcc... i removed the strict b-d to allow silo in main
[09:28] <jbailey> fabbione: Ah?  I thought benc said it didn't work?
[09:28] <fabbione> it doesn't ALWAYS work
[09:28] <fabbione> it does most of the time
[09:30] <jbailey> But..  it's *silo*
[09:30] <jbailey> That's the way it is even with gcc-2.95 compiling it.
[09:37] <fabbione> jbailey: tough.. i am not going to commit to support gcc-2.95 in main because of silo
[09:37] <fabbione> if it boots.. good.. otherwise bitch upstream to fix silo :)
[09:37] <jbailey> benc doesn't answer *questions* I have, I can't imagine him answeing me asking him to do actual work. =)
[09:38] <fabbione> jbailey: he is busy working to make his own business
[09:38] <fabbione> but i can still ping him on irc when he is around
[09:38] <fabbione> : idle     : 61 hours 24 mins 0 secs (signon: Sun Jun 12 08:14:43 2005)
[09:39] <fabbione> anyway
[09:39] <fabbione> time to be with my wife :)
[09:39] <fabbione> cya tomorrow guys
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain