[12:56] <jbailey> Ah, bugger, I see my thinko
[12:57] <jbailey> Don't you love those moments where you realise that something shouldn't have worked the first time around? =)
[12:58] <jbailey> doko: After this glibc upload, are you uploading the gcc with the fix for 260710?
[01:06] <lamont> jbailey: so you got bits for me yet?
[01:06] <jbailey> lamont: No, I figured out why it won't build when it gets that far...
[01:06] <lamont> jbailey: -mcpu was 3.3, -mtune is 3.4/4.0
[01:06] <lamont> oh.
[01:25] <jbailey> lamont: eh...
[01:25] <jbailey> lamont: hppa64.
[01:26] <jbailey> lamont: Should we eventually be doing a biarch setup for that?
[01:32] <doko> jbailey: biarch on hppa doesn't work yet, it needs a cross - binutils packaged in binutils-hppa64
[01:33] <jbailey> Ah, okay.
[01:33] <jbailey> glibc has this now: # hppa64 needs symlink /usr/hppa64-linux/include to /usr/include
[01:34] <doko> 260710, yes it's better, the patch to fix -g1 was dropped from 3.4.4
[01:36] <jbailey> Eh?  Dropped?
[01:36] <jbailey> Do you plan to put it back in?
[01:36] <doko> currently it is, but it shows some regressions in the testsuite
[01:36] <jbailey> Ugh. =(
[01:37] <doko> so, leave it out.
[01:37] <jbailey> Upstream PR still has it listed as committed.
[01:38] <jbailey> 'kay.  I've forced -g0 right now for our main arch's + sparc.
[02:21] <jbailey> I've fired off another round of this, it'll take a few hours to build, so I'll have to get it tomorrow.
[06:26] <ercxy> hi everybody
[06:27] <ercxy> does anybody know how to increase stack size of a process ?
[09:27] <fabbione> doko: ?
[09:46] <doko> fabbione: ?
[09:46] <fabbione> doko: gcc-3.4 on sparc status:
[09:47] <fabbione> i could reproduce the problem with a perfectly clean chroot
[09:47] <fabbione> this time i kept the tree
[09:47] <fabbione> well it seems like make all is not called in that direcotry before calling make install
[09:47] <fabbione> otherwise it works perfectly
[09:47] <doko> nice :(
[09:47] <fabbione> the reason why it can't find libv3test.a is because it's not there
[09:48] <svenl> doko: i managed to rebuild the biarch glibc yesterdat.
[09:48] <doko> fabbione: you build with sparc32 dpkg-buildpackage ... ?
[09:49] <fabbione> doko: yes
[09:49] <fabbione> that's automatic
[09:50] <svenl> doko: so, now i want to rebuild your biarch gcc packages, and you told me that the standard gcc packages will do.
[09:50] <svenl> doko: but i suppose i need to tweak some config options or something ? 
[09:51] <doko> yes, set biarch in debian/rules.defs. it's currently disabled.
[09:52] <svenl> doko: that's the only thing ? 
[09:52] <fabbione> doko: i am going to binNMU gcc-3.4 for sparc so that i can have the full toolchain but i would really love you to get it fixed properly, since this bug is a regression introduced recently
[09:52] <fabbione> ah ok
[09:52] <fabbione> ops
[09:53] <svenl> doko: i can just apt-get source gcc-3.4 modify it, and build it, and this will trigger the cannot-build-on-ppc32 bug, right ? 
[09:53] <doko> does jbailey still build using -g1?
[09:54] <svenl> doko: that was for me ? 
[09:59] <doko> svenl: yes
[09:59] <svenl> doko: any hint on it ? 
[09:59] <svenl> doko: or will you help me hunt it down or something ?
[10:01] <doko> svenl: sorry, currently not the time, trying to have something for sparc when we start the transition
[10:02] <svenl> doko. Ok.
[10:02] <svenl> doko: not even a summary of what you have found out so far about this ? 
[10:03] <svenl> doko: and i guess i will hit the problem sometime tomorrow only.
[10:04] <doko> svenl: what do you mean? as it looks, you cannot build glibc with -g1 due to PR16676
[10:05] <svenl> huh ? 
[10:05] <svenl> doko: i built glibc, so i guess it is not the issue.
[10:05] <svenl> doko: about gcc.
[10:10] <svenl> doko: BTW, any idea of what will happen if i install these biarch glibc and gcc on a debian system ? 
[10:12] <doko> hmm, haven't tried yet. maybe install l-k-h as well?
[10:12] <svenl> yep.
[10:13] <svenl> but the glibc will be backward binary compatible, even if we enabled NPTL and biarch, right ? 
[10:29] <svenl> doko, what is XXX_powerpc_XXX ? 
[10:29] <svenl> doko: and should i also set with_lib64gcc and with_lib64cxx ? 
[10:31] <doko> svenl, that's the switch which needs to be enabled.
[10:32] <svenl> oh.
[10:32] <svenl> doko: so i should just remove the XXX stuff ? 
[10:32] <doko> yes
[10:33] <svenl> doko: and how will this handle the guys doing true-ppc64 and having a ppc64 or powerpc64 arch ? 
[10:33] <doko> the architecture is called powerpc64, not powerpc
[10:33] <svenl> doko: but the current package doesn't make provision for it, right ? 
[10:34] <svenl> or you should change the XXX by powerpc64 or something ?
[10:34] <svenl> Anyway, this is not my problem ATM.
[10:34] <doko> ask aj ... I think he did it prepare for 4.0 only
[10:36] <svenl> we will see once this happens.
[10:41] <svenl> Damn.
[10:42] <svenl> lot of build depends to load, and apt-get is not happy with the gcc packages i have installed :/
[10:42] <svenl> doko: do i need a biarch gcc to build the biarch gcc, or will just the biarch glibc do ? 
[10:44] <doko> biarch glibc is enough
[10:45] <svenl> ok, so i can install the standard gcc over the one i used to build glibc in the first place.
[10:45] <doko> should work
[10:47] <svenl> i will tell you if it does not.
[10:47] <svenl> doko: so, is it better to start with gcc-3.4 or gcc-4.0 ?
[10:48] <doko> according to jbailey, gcc-4.0 doesn't work to build glibc.
[10:49] <svenl> well.
[10:49] <svenl> let's start with gcc-3.4 for now then.
[10:49] <svenl> doko: am i supposed to rebuild glibc with this new gcc once i have it ? 
[10:50] <svenl> doko: and how did you manage that ? Did you first build a biarch gcc bi hand for jbailey to use, or did he build one from upstream locally to build the first glibc ? 
[10:50] <doko> jbailey meant, that wouldn't be possible
[10:50] <svenl> doko: with 4.0 ? 
[10:50] <svenl> doko: but ok with the biarch 3.4 i am building.
[10:53] <doko> svenl: yes
[10:53] <svenl> doko: you didn't reply to my question about the way you originally built it :)
[10:57] <svenl> ARG.
[10:58] <svenl> it seems it didn't fix the linux-kernel-headers bad dependency :/
[11:10] <svenl> hand fixed that.
[11:11] <svenl> ok, gcc-3.4 build started.
[01:34] <fabbione> doko: at what time do you plan to start the transition on monday?
[01:35] <doko> evening, when lamont and elmo are awake
[01:36] <fabbione> doko: ok thanks
[01:36] <fabbione> i am going to crontab the sparc buildd to stop at 2pm our local time
[01:36] <fabbione> please do not start before that ok?
[01:36] <fabbione> i should be already back at that time
[01:37] <doko> fabbione: ok
[01:37] <fabbione> but i can't be 100% sure
[01:37] <fabbione> 0 14 * * Mon touch $HOME/EXIT-DAEMON-PLEASE
[01:37] <fabbione> there
[01:37] <fabbione> doko: if there are big issues, please tell lamont to stop it. he has access to the buildd
[01:38] <fabbione> i should be already home by that time.. but you may never know :)
[02:23] <\sh> mmm..
[02:31] <\sh> do i need to rename kdelibs4?
[04:25] <svenl> Mmm, it kind of failed. stopped building and lot of gcc tests marked as FAIL.
[04:25] <svenl> doko: is this supposed to happen ? 
[04:26] <svenl> doko: or more to the point, is this a symptom of the ppc64-kernel failure, or something else ? 
[04:29] <doko> svenl: which tests fail?
[04:29] <svenl> doko: i don't see any other obvious error message in the log.
[04:29] <svenl> doko: all of them
[04:29] <svenl> doko: which is why i think that something else went wrong.
[04:31] <doko> look at the build logs to see why they fail
[04:32] <svenl> doko: where can i find it ? 
[04:33] <svenl> i get stuff like :
[04:33] <svenl> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
[04:33] <svenl> Using /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
[04:33] <doko> find -name '*.log'
[04:33] <svenl> Running /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
[04:33] <svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O0  (test for excess errors)
[04:33] <svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O1  (test for excess errors)
[04:33] <svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O2  (test for excess errors)
[04:34] <svenl> output is :
[04:34] <svenl> spawn failed
[04:34] <svenl> Mmm.
[04:34] <doko> better mount /proc
[04:34] <doko> and /dev/pts
[04:35] <svenl> oh well.
[04:35] <svenl> Can i restart the build from where it left ? 
[04:36] <svenl> nope, proc was mounted, but not /dev/pts.
[04:37] <svenl> mmm, how do i mount /dev/pts. ...
[04:37] <svenl> Mmm.
[04:37] <svenl> will installing that glibc in my real system break it horribly ? 
[04:39] <svenl> Oh hell, let's try.
[04:39] <doko> debian/rules check should work
[04:39] <svenl> doko: does running the build as root could have affected it ? 
[04:40] <doko> don't think so, although I work with fakeroot only
[04:40] <svenl> i am inside a chroot as root, /proc is mounted, but not /dev/pts.
[04:41] <doko> so mount it and re-run
[04:42] <svenl> doko: how do i mount /dev/pts ? 
[04:43] <doko> proc    /org/chroots/breezy/proc        proc    defaults,auto           0 0
[04:43] <svenl> no, proc is ok, i know about it, /dev/pts is the one.
[04:43] <doko> devpts          /data/chroot/breezy32/dev/pts   devpts  defaults,auto   0 0
[04:43] <svenl> ok.
[04:44] <svenl> mount: special device ptsdev does not exist
[04:44] <svenl> no fun :/
[04:46] <svenl> err, the message was
[04:46] <svenl> mount: special device devpts does not exist
[04:46] <svenl> strange,
[04:48] <svenl> oh, well, need to go.
[05:49] <svenl> oh, well, no way to build gcc without moving to breezy will try again later on.
[06:24] <jbailey> lamont: hAround?
[07:08] <lamont> jbailey: am now
[07:09] <jbailey> lamont: Cool, got source for you.
[07:09] <jbailey> Just have one last dependancy to sort out.
[07:09] <jbailey> doko: There?
[07:09] <jbailey>  lib64gcc1 depends on amd64-libs (>= 0.1)
[07:09] <jbailey>   amd64-libs is to be removed.
[07:10] <jbailey> What do you want done about that?
[07:10] <jbailey> I'm now conflicting with amd64-libs as we'd talked about.
[07:11] <jbailey> lamont: The chroot basically needs to be:  Current Breezy, add amd64-libs amd64-libs-dev from breezy, add:
[07:11] <jbailey> cpp-3.4_3.4.3-13_i386.deb       lib64gcc1_3.4.3-13_i386.deb
[07:11] <jbailey> gcc-3.4-base_3.4.3-13_i386.deb  libgcc1_3.4.3-13_i386.deb
[07:11] <jbailey> gcc-3.4_3.4.3-13_i386.deb
[07:11] <jbailey> from Debian
[07:12] <doko> no
[07:15] <doko> jbailey: away for the evening
[07:15] <lamont>    features' might be clobbered by `longjmp' or `vfork'
[07:15] <lamont> {standard input}: Assembler messages:
[07:15] <lamont> {standard input}:59358: Error: Unrecognized opcode: `vand'
[07:15] <lamont> make[3] : *** [libkdefx_la.all_cpp.lo]  Error 1
[07:15] <lamont>  /build/buildd/kdelibs-3.4.0/kdefx/kcpuinfo.cpp:75: warning: variable `int
[07:16] <lamont> that last line should be first
[07:16] <lamont> bad gcc
[07:33] <svenl> jbailey: hi.
[07:33] <jbailey> svenl: hi.
[07:33] <svenl> jbailey: it is not possible to build stuff from inside hoary :/
[07:34] <jbailey> svenl: 'stuff'?
[07:34] <svenl> jbailey: gcc-3.4
[07:34] <jbailey> Errr.
[07:34] <jbailey> Usually one of the last steps to a release is that we rebuild the archive to make sure there aren't FTBFSs
[07:34] <svenl> jbailey: at least not the biarch version from doko.
[07:34] <svenl> jbailey: the blocker is doxygen.
[07:35] <svenl> and doxygen depends on libgcc >= 1:4.0-2
[07:35] <svenl> which is a breezy gcc-4.0 package i think.
[07:35] <svenl> and which overwrote my biarch libgcc.
[07:36] <svenl> so i am moving my box to breezy.
[07:36] <jbailey> Breezy won't be a great improvement for you.
[07:37] <svenl> well, i will be able to install the build-depends of gcc-3.4
[07:37] <jbailey> I've started another build of a biarch glibc on ppc, I'll just post it for you.
[07:37] <svenl> but then, i wonder if the libgcc1 4.0.0-7ubuntu1 is compatible with the libgcc1ppc64 or whatever i just built.
[07:38] <jbailey> the lib gcc1's should be completely unrelated to one another.
[07:38] <svenl> and the -dev ppc64 package of glibc depends on libgcc64.
[07:38] <svenl> ah.
[07:38] <jbailey> It's only important when you're looking at optimsed libs for the same architecture.
[07:38] <jbailey> There's pretty much no commonality otherwise, to the point where they use completely separate linkers and search paths.
[07:39] <svenl> jbailey: ok.
[07:39] <svenl> jbailey: BTW, what does this one glibc mean for userland libs ?
[07:39] <jbailey> one glibc?
[07:39] <svenl> the biarch one i built ? 
[07:39] <svenl> this one
[07:39] <jbailey> Right, but it should really be two glibcs.
[07:39] <jbailey> They just happen to coninstall.
[07:40] <svenl> Ok.
[07:40] <svenl> well, this way of doing things :)
[07:40] <jbailey> co-install, rather.
[07:40] <jbailey> It doesn't affect existing libs in any way.  They will link against /lib/ld.so.1 (or whatever PT_INTERP is on ppc, I don't remember).
[07:40] <jbailey> Any libs built for ppc64 will link against /lib64/ld.so.1
[07:41] <jbailey> So there's truly no relationship between them.  That ld.so should be wired to look in different search paths and whatnot.
[07:41] <svenl> ok.
[07:41] <svenl> what does this mean for 64bit libs ? 
[07:41] <svenl> they go in /lib64 and /usr/lib64 ? 
[07:41] <jbailey> Yes.
[07:41] <jbailey> In practice very few of them get built.
[07:42] <jbailey> Usually a few minor things like ncurses, zlib and such.
[07:42] <jbailey> Whatever the bare minimum we need for an LSB system, basically.
[07:44] <svenl> I think we need ncurses, which is a build dependency of the 64bit procutils.
[07:45] <jbailey> See two lines up. =)
[07:49] <svenl> )
[07:49] <svenl> only comenting on why ncurses is needed, which is not really an important lib to 64bit-is.
[07:49] <svenl> alternatively, we can build a static procutils-64.
[07:56] <jbailey> Well, we'd still need the library.
[07:57] <svenl> jbailey: this would be in the case of just ppc64 kernels.
[07:59] <svenl> jbailey: Now, if i want to upgrade my debian/sid system to use the new NPTL and biarch enhanced glibc, will this break my system ? 
[07:59] <svenl> Obviously i will not be able to use it anymore to build debian packages, but that is another issue.
[08:07] <jbailey> svenl: The best I can say is that it shouldn't.
[08:07] <jbailey> I've been running the nptl-based stuff for a while with no issues.
[08:07] <jbailey> But that was all on Hoary, etc.
[09:09] <\sh> anyone awake?
[09:33] <jbailey> \sh: Just got back, sup?
[09:51] <\sh> jbailey: my question is already answered.
[09:51] <\sh> jbailey: kdelibs4 has to be renamed
[10:31] <jbailey> svenl: l?
[10:32] <jbailey> svenl: I have the glibc-ppc64 bits if you want.