=== Riddell [i=jr@kde/jriddell]  has joined #ubuntu-toolchain
=== infinity [n=adconrad@loki.0c3.net]  has joined #ubuntu-toolchain
=== netjoined: irc.freenode.net -> brown.freenode.net
=== Riddell [i=jr@kde/jriddell]  has joined #ubuntu-toolchain
=== infinity [n=adconrad@loki.0c3.net]  has joined #ubuntu-toolchain
[05:32] <jbailey> Random notes before I pass out:
[05:32] <jbailey> Binutils upgrade breaks glibc build in two ways.
[05:32] <jbailey> The first of which I have a patch for (binutils is now sensitive to gcc emitting strange symbols)
[05:32] <elmo> one is known
[05:33] <jbailey> The second of which I don't, (weak symbols can no longer override global symbols)
[05:33] <elmo> a newer CVS (woo, this CVS idea WAS SUCH A GOOD IDEA) should fix the latter
[05:33] <jbailey> Great.
[05:33] <elmo> can you put a source package someone for me to test build with?
[05:33] <elmo> and do we only care about this for ubuntu?
[05:34] <jbailey> Yup, gimme a sec to make sure I have a ChangeLog entry for everything.
[05:41] <jbailey> elmo: rookery:~jbailey/public_html/glibc/*
[05:42] <elmo> jbailey: k, thx, I'll test a new upstream version tomorrow
[05:42] <jbailey> elmo: Thanks.  Do you know what time of day you'll be doing that?
[05:42] <jbailey> I'll try to be around for that.
[05:42] <elmo> oh, no idea sorry
[05:43] <elmo> if it's important, and you don't want to be blocked on me, feel free to just do it yourself
[05:43] <jbailey> Umm, as far as distros we care about for this?  Certainly Ubuntu for now.  Debian will be broken, but I haven't completed the merge yet.
[05:43] <jbailey> 'kay.  Is it just a CVS update?
[05:43] <elmo> I make a point of only maintaining binutils for Debian, and Debian may or may not want to fix this (I've asked Vorlon)
[05:43] <jbailey> It's blocking X from building, or I wouldn't still be up staring at it.
[05:43] <elmo> basically, yes
[05:43] <elmo> none of the patches have been merged upstream, so it should just be a matter of copying the debian tree into a recent CVS checkout
[05:43] <jbailey> I'll look at it in 7 hours then.  If you look at it before then, can you let me know?
[05:48] <elmo> I won't be
[05:48] <elmo> it's 5am, I need to sleep ;-)
[05:52] <jbailey> Right. =)
[05:53] <jbailey> I'm going to grab it first thing, so I'll just tackle it.
[05:53] <jbailey> Any objections to me just updating in Ubuntu and sorting out merging to Debian later?
[05:53] <elmo> err, that'd kind of suck since it involves an orig.tar.gz
[05:54] <elmo> if you do that, pls try and make sure it's a sane one I can reuse
[05:54] <elmo> but basically, I guess not, if you're in a rush
[05:54] <elmo> anyway, night
[05:55] <jbailey> I'll do my best.  Thanks, James.
[05:55] <jbailey> g'night
[05:56] <jbailey> infinity: If you care read the above text.
[05:56] <jbailey> and g'night. =)
[07:13] <lamont-away> doko_: you realize that if you added a build-dep on the new libstdc++ version to the packages affected, they could be uploaded at the same time as gcc, and then the build-dep dropped on the next sync or whatever (that is, they could have -build versions...)
[07:14] <fabbione> is the transition started btw?
[07:15] <lamont-away> waiting for the CD set to get built, iirc
[07:16] <fabbione> ok
=== lamont-away -> bed
[07:45] <fabbione> good night lamont
[10:03] <Riddell> doko: did you look into subversion with libdb4.3?
[10:04] <doko> Riddell: infinity said, he's preparing packages and handling the upgrade
[10:06] <doko> fabbione: do you know which binutils failure daniels had in mind=
[10:06] <doko> ?
[10:06] <fabbione> no sorry
[10:06] <fabbione> just read the scrollback here?
[10:08] <Riddell> infinity: same question :)
[10:34] <infinity> Riddell : I've made the changes already in Debian's SVN repository.  The Debian upload is blocking on someone properly documenting the repo upgrade procedures for end users.
[10:35] <infinity> Riddell : I can, for now, cut an Ubuntu release from Debian SVN, if it's blocking you elsewhere, since we don't care much about being user friendly this early in OUR release cycle.
[10:46] <Riddell> infinity: that would be good, it's blocking kdesdk which blocks a couple other important kde modules
[10:52] <Riddell> doko: http://bugs.debian.org/323133 fixed in ubuntu too?
[10:53] <doko> Riddell: not yet, but with the next upload
[10:58] <Riddell> doko: which will be after today's flight-1 CD?
[11:00] <doko> not sure about today, but after the flight-1 CD, so the gcc-3.4 workaround for hppa can be removed
=== chmj [n=chmj@wbs-146-137-107.telkomadsl.co.za]  has joined #ubuntu-toolchain
[01:43] <elmo> anyone done anything with binutils yet?
[01:49] <doko> not yet, jbailey did want to have a look today. it's the X build failure?
[01:50] <elmo> well, more getting newer glibc built, so X can build
[01:50] <elmo> but there's now also a patch for gcj vs. c++filt and I can fix hppa properly too
[01:51] <doko> hppa is the one metnioned on parisc-linux?
[01:51] <elmo> hum? no, the expect-tcl8.3 thing
[01:51] <elmo> what's the other thing?
[01:53] <doko> http://lists.parisc-linux.org/pipermail/parisc-linux/2005-November/027663.html
[01:53] <doko> infinity, elmo: i386 and powerpc buildd's run 32, or 64bit kernels?
[01:53] <elmo> 64-bit kernel, but they force the personality to 32-bit
[01:53] <elmo> (just like sparc does, in Debian at least)
[01:54] <elmo> doko: oh, that, dunno about that
[01:58] <fabbione> and in Ubuntu too
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[01:59] <fabbione> you talk about the evil...
[02:00] <jbailey> I'm not evil.  I'm cute like Devil Doll
[02:04] <fabbione> tell that to jblack :D
[02:04] <jbailey> Thinking of which, I'd love to know what he thought of the drive to NYC.
[02:04] <jbailey> Jordi's blog posts were fun. 
[02:06] <elmo> jbailey: fyi, I'm spinning a new binutils cvs for debian anyway
[02:06] <elmo> since there's a fix for c++filt
[02:09] <jbailey> elmo: 'kay.
[02:09] <jbailey> elmo: Safe to assume you'll sync it when you're happy?
[02:10] <elmo> heck no
[02:10] <elmo> it needs merging of that evil crap you guys use for the link on boot
[02:10] <elmo> which so isn't going anywhere near Debian
[02:11] <fabbione> elmo: speak with sabdfl about it please :D
[02:11] <elmo> eh, I don't care if you use it, it's just Not My Problem
[02:11] <elmo> "expect-tcl8.3 [hppa]  | expect [hppa] "
=== elmo looks at doko
[02:12] <fabbione> elmo: it's not like we had the option to say "it sucks"
[02:13] <elmo> fabbione: dude, you're missing the point, I'm not criticizing you guys for using it - it's just I don't maintain packages in Ubuntu, so I'm not going to start do merge work for them, even if it's my "own package" (in Debian)
[02:13] <fabbione> ahhh ok
[02:13] <fabbione> sorry
[02:13] <fabbione> i misunderstood
[02:15] <infinity> elmo : I'll merge it in the morning (~8 hours from now), if you do the Debian upload before then.  I'm intimately involved with binutils' debian/rules at this point.
[02:18] <fabbione> infinity: are on you kernel-team@l.u.c ?
[02:19] <infinity> fabbione : I am, I responded to your mail there a few minutes ago.
[02:23] <fabbione> ok
[02:30] <doko> elmo: which one is that?
[02:58] <elmo> doko: gcc-4.0
[03:02] <doko> elmo: yes, already fixed in svn
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[07:56] <elmo> ok, so sorry, I got entirely distracted this afternoon by meetings and stuff, so I'm only just building binutils for ubuntu and test building glibc now
[07:57] <elmo> or has anyone beat me to it?
[07:57] <jbailey> elmo: Adam said that he'd do it, and I haven't heard from him.
[07:57] <jbailey> So I suspect he's still sleeping.
[07:57] <elmo> tho I just realised I'm doing it on amd64 instead of i386, sigh
[07:57] <elmo> will that still work as a test case?
[08:00] <jbailey> I saw it on ppc and ppc64.
[08:00] <jbailey> I hadn't tried i386 and amd64 yet.
[08:05] <jbailey> "2.6.15-rc1 marks the closing of the window for new features, so Linus's git repository contains mostly fixes. It does, however, also include a generic cmpxchg implementation for i386, new Omnikey Cardman 4000 and 4040 drivers, and a new DMA32 zone for the x86-64 architecture."
[08:05] <jbailey> Does this mean we're going to go back to supporting i386, or can we still say fuckit, and consider going to i686 only?
[08:08] <elmo> we're not going to go back to i386, it'd require a recompile of the archive
[08:08] <elmo> I don't think we can do i686 only given our target market
[08:09] <jbailey> Our target market appears to include computers that can run openoffice2.
[08:09] <jbailey> Does that honestly allow pre-i686?
[08:11] <jbailey> (I'm not actually too fussed about this, MS starting to move to 64 bit on servers is a good sign that we're on our way past the mess of upgrades to ia32)
[08:12] <elmo> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S: Assembler messages:
[08:12] <elmo> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
[08:13] <elmo> I got that for amd64; is that related or random?
[08:14] <jbailey> Looks likely to be related, that's the same type of error I saw for the bind symbol.
[08:14] <jbailey> Lemme fire this up on concordia for a sec and get amd64 output for that.
[08:15] <jbailey> jbailey@concordia:~ $ dchroot -c dapper
[08:15] <jbailey> Invalid chroot 'dapper'
[08:16] <jbailey> elmo: Should I send that to RT?
[08:26] <elmo> aww, crap jan hasn't committed the patch to fix it yet
[08:28] <elmo> crap, even worse, it has, but clearly hasn't fixed it
[08:31] <jbailey> elmo: I'd just revert the patch from the 4th or so that loses the ability to override the symbols.
[08:32] <jbailey> (Assuming I have the patch right)
[08:34] <elmo> err, what patch from the 4th?
[08:34] <elmo> http://sourceware.org/ml/binutils/2005-10/msg00412.html references the problematic part of thepatch AFAIK
[08:51] <elmo> ok, this is krazy with a K
[08:51] <elmo> AFAICS it's nothing to do with Jan's patch
[08:51] <elmo> http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/read.c.diff?cvsroot=src&r1=1.108&r2=1.109
[08:51] <elmo> @@ -2784,18 +2793,37 @@
[08:52] <elmo> +	  as_bad (_("symbol `%s' is already defined"), name);
[08:52] <elmo> +	  symbolP = symbol_clone (symbolP, 0);
[08:53] <elmo> which is like, "fatal error, but then do something", AFAICS
[08:55] <elmo> [oh, well, it is Jan's patch, just applied by Nick] 
[09:19] <elmo> meh
[09:19] <elmo> jbailey: drow says 'iz glibc bug'
=== doko_ [n=doko@dslb-084-059-099-041.pools.arcor-ip.net]  has joined #ubuntu-toolchain
[09:27] <elmo> jbailey: http://sourceware.org/ml/glibc-cvs/2005-q4/msg00350.html
[09:28] <jbailey> elmo Eh, okay.  I had assumed it was the same thing as the bind issue (which it might be, but there isn't a patch for yet)
[09:29] <jbailey> elmo: Are you able to put a dapper chroot on concordia for me to look at this?  OtherwiseI can update my wife's machine to dapper, but that'll take an hour or two.
[09:30] <elmo> done
[09:32] <jbailey> tx
[09:40] <elmo> lamont/infinity: floe has gone insane, please uninsane it, kthx
[09:41] <jbailey> elmo: May I have devscripts in the dapper chroot, please? =)
[09:41] <elmo> done
[09:43] <lamont-away> elmo: wow
[09:44] <jbailey> elmo: Building, thanks.
[09:46] <elmo> jbailey: oh, so http://people.ubuntu.com/~james/binutils/ has the new binutils, if it still helps any
[09:47] <elmo> I'm test building i386 (-12 tho) myself now with current dapper binutils
[09:47] <elmo> if it doesn't help powerpc, pls let me know
[09:54] <elmo> holy cow, could we build glibc a few more times on i386?  I'm sure we're not doing it enough
[09:54] <jbailey> *lol*
[09:54] <jbailey> elmo: For dapper + 1 one of those passes gets dropped.
[09:55] <jbailey> If we finally admit that noone in their right mind would run Ubuntu with less than an i686, the other can be dropped. =)
[09:55] <elmo> {standard input}:422: Error: symbol `__moddi3' is already defined
[09:55] <elmo> {standard input}:513: Error: symbol `__udivdi3' is already defined
[09:55] <elmo> {standard input}:547: Error: symbol `__umoddi3' is already defined
[09:55] <elmo> ok, so that one iz glibc bug too
[09:55] <jbailey> elmo: You need the -13 I gave you.
[09:55] <elmo> and I believe there's a patch, do you know about it?
[09:55] <jbailey> It has that fix in it already.
[09:55] <elmo> meh, seriously? gar
[09:55] <elmo> oh, well, I'll restart that in a screen session
[09:58] <fabbione> WOWOOOO
[09:58] <fabbione> GO GCC!
[09:58] <fabbione> gcc: Internal error: Segmentation fault (program as)
[09:58] <jbailey> fabbione: that's binutils, dude.
[09:59] <jbailey> The segfault bubbled up from as.
[09:59] <fabbione> i don't think that chroot has been updated actually
[10:05] <lamont-away> elmo: floe is once again sane
[10:14] <fabbione> elmo: do you know if Karl is around?
[10:14] <fabbione> he did ping me yesterday even..
[10:14] <fabbione> ponged this morning
[10:14] <fabbione> but no answer from him all day
[10:16] <jbailey> I have glibc on amd64 now with my -13 + the patch drow mentioned for amd64
[10:17] <jbailey> binutils still building on i386
[10:17] <jbailey> err
[10:17] <jbailey> ppc
[10:30] <jbailey> elmo: I seem to be getting the same message even with the new binutils on ppc
[10:30] <jbailey> ../sysdeps/unix/sysv/linux/bind.S: Messages de l'assembleur:
[10:30] <jbailey> ../sysdeps/unix/sysv/linux/bind.S:5: ERREUR: symbole  __bind  est dj dfini
[10:30] <jbailey> err
[10:30] <jbailey> symbol is already defined.
[10:53] <jbailey> Eh, weird.  on amd64 if doesn't using sysdeps/unix/sysv/linux/bind.S
[11:10] <elmo> fabbione: we've been in meetings all day; he's clocked off now, I suspect
[11:10] <elmo> lamont-away: thanks
[11:10] <elmo> jbailey: ok, are we sure there isn't a patch for that one too? :)
[11:11] <elmo> hmm, no unfortunately not
[11:12] <fabbione> elmo: thanks, he did ping me back again :)
[11:12] <fabbione> i tought it was under your input :)
[11:14] <lamont-away> elmo: I didn't bother to count higher than 4 buildds running there...
[11:25] <elmo> duh, the glibc build for i386 failed just like amd64
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[11:28] <elmo> jbailey: glibc builds for i386 fails in the same way as amd64 - obviously ;)
[11:29] <elmo> is the bind.S thing maybe because it's not in powerpc's syscall list?<random and uneducated guess>
[11:30] <jbailey> Could easily be.  I'm just testing the ppc64 kernel for ben atm.
[11:31] <elmo> if you have a dpatch for amd64, I'm happy to test that, FWIW
[11:32] <jbailey> concordia:~jbailey/amd64/glibc/glibc-2.3.5/debian/patches/ubuntu-new-binutils.dpatch
[11:33] <jbailey> That replaces the old ubuntu-new-binutils.dpatch
[11:36] <elmo> ok, rebuilding on amd64
[11:36] <jbailey> elmo: You're testing the new binutils?
[11:36] <elmo> oh, good point, err, yes
[11:37] <elmo> I suppose I should downgrade
[11:37] <jbailey> Well, it built fine in the dapper chroot you made for me.
[11:37] <jbailey> So no point in repeating that test.
[11:37] <elmo> oh
[11:37] <jbailey> My brain is spacy, so I'm just trying to make sure I have some clue as to what's happening. =)
[11:39] <elmo> sweet
[11:39] <elmo> I get a different error with dapper binutils on ppc
[11:39] <elmo> ../sysdeps/unix/sysv/linux/getsockname.S: Assembler messages:
[11:39] <elmo> ../sysdeps/unix/sysv/linux/getsockname.S:5: Error: symbol `__getsockname' is already defined
[11:39] <elmo> will that go away if I upgrade binutils?
[11:39] <elmo> I'm getting so confused by all the versions and patches flying around here
[11:41] <jbailey> Err.
[11:42] <jbailey> bind.S passed for you?
[11:42] <jbailey> Or are you on an SMP machine that happened to get a bit further?
[11:42] <jbailey> getsockname.S and bind.S are basically the same code.
[11:42] <elmo> ah, yeah, it's davis
[11:42] <elmo> (which is SMP)
[11:42] <jbailey> Right.  Look at the build log just before that and see if bind.S failed also.
[11:43] <jbailey> If it passed then I'm *very* confused.
[11:43] <jbailey> But it's the exactly same problem.
[11:43] <elmo> oh, eww
[11:43] <jbailey> The nice part is it looks like the weak reference is the correct one (per the current symbol set)
[11:43] <elmo> it died for the 32 bit build
[11:43] <elmo> but didn't kill the build
[11:43] <jbailey> Um, yeah.  THere's a small bug in the packaging.
[11:43] <elmo> symbol `__bind' is already defined
[11:43] <elmo> make[3] : *** [/home/james/scratch/glibc-2.3.5/build-tree/powerpc-libc/socket/bind.o]  Error 1
[11:43] <elmo> touch /home/james/scratch/glibc-2.3.5/stamp-dir/build_libc
[11:43] <elmo> ok
[11:44] <jbailey> The error code gets eaten by tee.
[11:46] <jbailey> elmo: Good guess on the syscall.