#ubuntu-toolchain 2005-11-21
<doko> Riddell: see the mail to ubuntu-devel, after the flight-1 CD
<Riddell> doko: ok, well qt and above are all sitting here waiting on it so I look forward to being able to upload :)
<jbailey> doko: Thinking of which.
<jbailey> doko: kyle pointed out that monticito is dropped ia32 compatability in hardware.
<jbailey> So I'm wondering if we should drop ia32-libs for ia64 for now, or if there's a software emulator we should be using for those cases?
<doko> hmm, why keep it at all?
<jbailey> Only for openoffice and such.
<jbailey> But if we could drop it without consequence, it would save some hassle, I think.
<doko> to drop it we need libc6-i386-dev first, *hint*, *hint* ;-P
<fabbione> doko: hey dude
<fabbione> hi jbailey 
<fabbione> so when is the libstdc++++++ transition++ planned to start?
<jbailey> Heya Fabio
<fabbione> immediatly after flying-1 or will you give us time to stop the buildd?
<doko> fabbione: sure, but I want to be able to build it probably before the weekend
<fabbione> doko: for me it's enough to be able to stop the buildd before you upload the 3 billion pkgs :)
<lamont-away> so what's the word on new gcc?  should I start the hppa buildd back up for now?
<doko> lamont-away: please do, we are waiting for the flight-1 CD
<doko> jbailey: ping
<doko> jbailey: any estimate for 2.3.6?
<jbailey> doko: Upstream or in Ubuntu, and with which features?
<doko> jbailey: Ubuntu, merges and libc6-i386
<jbailey> merges will be post-flight-1, 2.3.6 from upstream will be this afternoon (with the X fix).
<jbailey> libc6-i386 should probably be after, since it means fixing ia32-libs at the same time.
<jbailey> doko: Anything else you need in before flight-1?
<doko> jbailey: no, not at all
<jbailey> Luvly.
<lamont-away> uh, doko....
<lamont-away> expect-tcl8.3 [!hppa !hurd-any !hurd-i386] 
<lamont-away> from debian gcc-4.0...
<lamont-away> which then ftbfs
<doko> hmm, ok, it's already in the archive, fixed for the next one
<elmo> oi, lamont
<lamont-away> hi elmo
<lamont-away> doko: that was gcc-4.0_4.0.2-4
<elmo> lamont-away: did you manually upload binutils for hppa in Debian?
<lamont-away> uh.  I don't remember doing that particularly
<lamont-away> elmo: talking about expect b0rkage type issues or something else?
<elmo> lamont-away: yes, I suspect so
<elmo> both builds on the buildd failed with testsuite death
<elmo> and yet a binary "appeared" in the archive
<elmo> with no corresponding successful build
<lamont-away> quite possible that I helped it along - but I don't think I manually built it, no.
<lamont-away> who's sig on the .changes?
<elmo> that'd be like.. effort.  can't you just admit it? :-P
<lamont-away> (my normal involvement with expect and hppa's buildd comes in the form of 'killall -9 expect' once the build hangs
<lamont-away> but those give you success logs...
<lamont-away> I wish expect would either switch to tcl8.3, or they would fix the threads in 8.4
<lamont-away> elmo: fwiw, it'd be really cool if the .changes files were publicly available somewhere.
<lamont-away> (for both debian and ubuntu)
<elmo> they are, on merkel
<elmo> for debian, for ubuntu - yeah
<lamont-away> oh, even better
<elmo> I don't want to bloat the archive with them tho
<doko> elmo: that was me. I tried with expect first, which failed, then expect-tcl8.3. you should have a mail in your mailbox
<lamont-away> no sense to mirror them, that's for sure
<lamont-away> elmo: see, I'm innocent
<elmo> ok, doko and lamont are not allowed to go to conferences anymore
<elmo> clearly doko has been hanging around lamont too long ;-P
<lamont-away> elmo - I always leave tracks.
<elmo> doko: dude, the correct fix for that is a bug, not a random upload of a package that can't be built on the buildds
<doko> elmo: submitted.
<lamont-away> elmo: fwiw, doko is just one more in the long line of people who "fix" hppa build failures that I've left failed by uploading something they built themselves.  go debian
<jbailey> lamont-away: There is possibly a reasonable argument that the buildd is broken if it fails to build something that can be reasonably built in a clean chroot on a standard Debian setup.
<elmo> jbailey: dude, this is NOT the buildd being broken
<elmo> jbailey: and even if it was, that's not an even remotely sane argument
<elmo> this same buildd has to be used for security builds
<jbailey> Right, but if the buildd is configured in a different way than the standard OS (different kernel, different kernel settings), then that machine is misconfigured in an important way
<elmo> and should be fixed
<elmo> not worked around
<jbailey> I'm not saying the right soluton is to build it yourself and upload it.
<jbailey> I'm arguing that having alignment checking turned on by default on the buildd machines for hppa and not on the standard hppa kernel is probably a bug.
<jbailey> Among other tweaks that might be done to various buildds.
<jbailey> rather alignment checking turned on for standard builds, and not turned on for the buildd.
<elmo> yeah, fine I can agree with that
<jbailey> But you know what I mean.
<elmo> but one day, I really am going to block non-buildd uploads in debian too :-P
<lamont-away> jbailey: yeah...
<lamont-away> but I can't really file a bug against camm for having broken thinking in how he does packaging.
<lamont-away> although i suppose I could file a bug against the b0rked packages - not that it would change much
<jbailey> elmo: And I will phear i386 on Debian so much less when you do. =)
<jbailey> lamont-away: Hmm, bug queues on people.
<jbailey> lamont-away: I wonder if there should be some ritual when people show up at Debconf where the people with the most bugs on them get thrown out on the assumption that they must be mouldy and rotten?
<jbailey> Or perhaps we can be gentler and write "corpse" on their forehead with indelible marker? =)
* lamont-away had a group of friends that had George Takei sign someone's forehead once...
<lamont-away> with a sharpie.  the day before a job interview.  upside down.
<elmo> what's a sharpie?
<lamont-away> permanent marker
<lamont-away> "sharpie" is a brand name
<lamont-away> the person was up for several hours turning his autographed forehead into a red not-quite-bloody forehead.
<elmo> oh
<elmo> I assume it was like those compasses you had at school, the one with the sharp metal ends
<elmo> which would have been, like, harsh
<lamont-away> yeah, well, they would have had a hard time talking George into it, too... as it was, they just bodily carried jack over and said "Mr Takei, would you please sign this?  thx"
<lamont-away> hrm.. /me realizes that signing foreheads has nothing to do with toolchains anywhere, let alone ubuntu
#ubuntu-toolchain 2005-11-22
* netjoined: irc.freenode.net -> brown.freenode.net
<jbailey> Random notes before I pass out:
<jbailey> Binutils upgrade breaks glibc build in two ways.
<jbailey> The first of which I have a patch for (binutils is now sensitive to gcc emitting strange symbols)
<elmo> one is known
<jbailey> The second of which I don't, (weak symbols can no longer override global symbols)
<elmo> a newer CVS (woo, this CVS idea WAS SUCH A GOOD IDEA) should fix the latter
<jbailey> Great.
<elmo> can you put a source package someone for me to test build with?
<elmo> and do we only care about this for ubuntu?
<jbailey> Yup, gimme a sec to make sure I have a ChangeLog entry for everything.
<jbailey> elmo: rookery:~jbailey/public_html/glibc/*
<elmo> jbailey: k, thx, I'll test a new upstream version tomorrow
<jbailey> elmo: Thanks.  Do you know what time of day you'll be doing that?
<jbailey> I'll try to be around for that.
<elmo> oh, no idea sorry
<elmo> if it's important, and you don't want to be blocked on me, feel free to just do it yourself
<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.
<jbailey> 'kay.  Is it just a CVS update?
<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)
<jbailey> It's blocking X from building, or I wouldn't still be up staring at it.
<elmo> basically, yes
<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
<jbailey> I'll look at it in 7 hours then.  If you look at it before then, can you let me know?
<elmo> I won't be
<elmo> it's 5am, I need to sleep ;-)
<jbailey> Right. =)
<jbailey> I'm going to grab it first thing, so I'll just tackle it.
<jbailey> Any objections to me just updating in Ubuntu and sorting out merging to Debian later?
<elmo> err, that'd kind of suck since it involves an orig.tar.gz
<elmo> if you do that, pls try and make sure it's a sane one I can reuse
<elmo> but basically, I guess not, if you're in a rush
<elmo> anyway, night
<jbailey> I'll do my best.  Thanks, James.
<jbailey> g'night
<jbailey> infinity: If you care read the above text.
<jbailey> and g'night. =)
<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...)
<fabbione> is the transition started btw?
<lamont-away> waiting for the CD set to get built, iirc
<fabbione> ok
* lamont-away -> bed
<fabbione> good night lamont
<Riddell> doko: did you look into subversion with libdb4.3?
<doko> Riddell: infinity said, he's preparing packages and handling the upgrade
<doko> fabbione: do you know which binutils failure daniels had in mind=
<doko> ?
<fabbione> no sorry
<fabbione> just read the scrollback here?
<Riddell> infinity: same question :)
<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.
<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.
<Riddell> infinity: that would be good, it's blocking kdesdk which blocks a couple other important kde modules
<Riddell> doko: http://bugs.debian.org/323133 fixed in ubuntu too?
<doko> Riddell: not yet, but with the next upload
<Riddell> doko: which will be after today's flight-1 CD?
<doko> not sure about today, but after the flight-1 CD, so the gcc-3.4 workaround for hppa can be removed
<elmo> anyone done anything with binutils yet?
<doko> not yet, jbailey did want to have a look today. it's the X build failure?
<elmo> well, more getting newer glibc built, so X can build
<elmo> but there's now also a patch for gcj vs. c++filt and I can fix hppa properly too
<doko> hppa is the one metnioned on parisc-linux?
<elmo> hum? no, the expect-tcl8.3 thing
<elmo> what's the other thing?
<doko> http://lists.parisc-linux.org/pipermail/parisc-linux/2005-November/027663.html
<doko> infinity, elmo: i386 and powerpc buildd's run 32, or 64bit kernels?
<elmo> 64-bit kernel, but they force the personality to 32-bit
<elmo> (just like sparc does, in Debian at least)
<elmo> doko: oh, that, dunno about that
<fabbione> and in Ubuntu too
<fabbione> you talk about the evil...
<jbailey> I'm not evil.  I'm cute like Devil Doll
<fabbione> tell that to jblack :D
<jbailey> Thinking of which, I'd love to know what he thought of the drive to NYC.
<jbailey> Jordi's blog posts were fun. 
<elmo> jbailey: fyi, I'm spinning a new binutils cvs for debian anyway
<elmo> since there's a fix for c++filt
<jbailey> elmo: 'kay.
<jbailey> elmo: Safe to assume you'll sync it when you're happy?
<elmo> heck no
<elmo> it needs merging of that evil crap you guys use for the link on boot
<elmo> which so isn't going anywhere near Debian
<fabbione> elmo: speak with sabdfl about it please :D
<elmo> eh, I don't care if you use it, it's just Not My Problem
<elmo> "expect-tcl8.3 [hppa]  | expect [hppa] "
* elmo looks at doko
<fabbione> elmo: it's not like we had the option to say "it sucks"
<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)
<fabbione> ahhh ok
<fabbione> sorry
<fabbione> i misunderstood
<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.
<fabbione> infinity: are on you kernel-team@l.u.c ?
<infinity> fabbione : I am, I responded to your mail there a few minutes ago.
<fabbione> ok
<doko> elmo: which one is that?
<elmo> doko: gcc-4.0
<doko> elmo: yes, already fixed in svn
<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
<elmo> or has anyone beat me to it?
<jbailey> elmo: Adam said that he'd do it, and I haven't heard from him.
<jbailey> So I suspect he's still sleeping.
<elmo> tho I just realised I'm doing it on amd64 instead of i386, sigh
<elmo> will that still work as a test case?
<jbailey> I saw it on ppc and ppc64.
<jbailey> I hadn't tried i386 and amd64 yet.
<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."
<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?
<elmo> we're not going to go back to i386, it'd require a recompile of the archive
<elmo> I don't think we can do i686 only given our target market
<jbailey> Our target market appears to include computers that can run openoffice2.
<jbailey> Does that honestly allow pre-i686?
<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)
<elmo> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S: Assembler messages:
<elmo> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
<elmo> I got that for amd64; is that related or random?
<jbailey> Looks likely to be related, that's the same type of error I saw for the bind symbol.
<jbailey> Lemme fire this up on concordia for a sec and get amd64 output for that.
<jbailey> jbailey@concordia:~ $ dchroot -c dapper
<jbailey> Invalid chroot 'dapper'
<jbailey> elmo: Should I send that to RT?
<elmo> aww, crap jan hasn't committed the patch to fix it yet
<elmo> crap, even worse, it has, but clearly hasn't fixed it
<jbailey> elmo: I'd just revert the patch from the 4th or so that loses the ability to override the symbols.
<jbailey> (Assuming I have the patch right)
<elmo> err, what patch from the 4th?
<elmo> http://sourceware.org/ml/binutils/2005-10/msg00412.html references the problematic part of thepatch AFAIK
<elmo> ok, this is krazy with a K
<elmo> AFAICS it's nothing to do with Jan's patch
<elmo> http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/read.c.diff?cvsroot=src&r1=1.108&r2=1.109
<elmo> @@ -2784,18 +2793,37 @@
<elmo> +	  as_bad (_("symbol `%s' is already defined"), name);
<elmo> +	  symbolP = symbol_clone (symbolP, 0);
<elmo> which is like, "fatal error, but then do something", AFAICS
<elmo> [oh, well, it is Jan's patch, just applied by Nick] 
<elmo> meh
<elmo> jbailey: drow says 'iz glibc bug'
<elmo> jbailey: http://sourceware.org/ml/glibc-cvs/2005-q4/msg00350.html
<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)
<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.
<elmo> done
<jbailey> tx
<elmo> lamont/infinity: floe has gone insane, please uninsane it, kthx
<jbailey> elmo: May I have devscripts in the dapper chroot, please? =)
<elmo> done
<lamont-away> elmo: wow
<jbailey> elmo: Building, thanks.
<elmo> jbailey: oh, so http://people.ubuntu.com/~james/binutils/ has the new binutils, if it still helps any
<elmo> I'm test building i386 (-12 tho) myself now with current dapper binutils
<elmo> if it doesn't help powerpc, pls let me know
<elmo> holy cow, could we build glibc a few more times on i386?  I'm sure we're not doing it enough
<jbailey> *lol*
<jbailey> elmo: For dapper + 1 one of those passes gets dropped.
<jbailey> If we finally admit that noone in their right mind would run Ubuntu with less than an i686, the other can be dropped. =)
<elmo> {standard input}:422: Error: symbol `__moddi3' is already defined
<elmo> {standard input}:513: Error: symbol `__udivdi3' is already defined
<elmo> {standard input}:547: Error: symbol `__umoddi3' is already defined
<elmo> ok, so that one iz glibc bug too
<jbailey> elmo: You need the -13 I gave you.
<elmo> and I believe there's a patch, do you know about it?
<jbailey> It has that fix in it already.
<elmo> meh, seriously? gar
<elmo> oh, well, I'll restart that in a screen session
<fabbione> WOWOOOO
<fabbione> GO GCC!
<fabbione> gcc: Internal error: Segmentation fault (program as)
<jbailey> fabbione: that's binutils, dude.
<jbailey> The segfault bubbled up from as.
<fabbione> i don't think that chroot has been updated actually
<lamont-away> elmo: floe is once again sane
<fabbione> elmo: do you know if Karl is around?
<fabbione> he did ping me yesterday even..
<fabbione> ponged this morning
<fabbione> but no answer from him all day
<jbailey> I have glibc on amd64 now with my -13 + the patch drow mentioned for amd64
<jbailey> binutils still building on i386
<jbailey> err
<jbailey> ppc
<jbailey> elmo: I seem to be getting the same message even with the new binutils on ppc
<jbailey> ../sysdeps/unix/sysv/linux/bind.S: Messages de l'assembleur:
<jbailey> ../sysdeps/unix/sysv/linux/bind.S:5: ERREUR: symbole  __bind  est dj dfini
<jbailey> err
<jbailey> symbol is already defined.
<jbailey> Eh, weird.  on amd64 if doesn't using sysdeps/unix/sysv/linux/bind.S
<elmo> fabbione: we've been in meetings all day; he's clocked off now, I suspect
<elmo> lamont-away: thanks
<elmo> jbailey: ok, are we sure there isn't a patch for that one too? :)
<elmo> hmm, no unfortunately not
<fabbione> elmo: thanks, he did ping me back again :)
<fabbione> i tought it was under your input :)
<lamont-away> elmo: I didn't bother to count higher than 4 buildds running there...
<elmo> duh, the glibc build for i386 failed just like amd64
<elmo> jbailey: glibc builds for i386 fails in the same way as amd64 - obviously ;)
<elmo> is the bind.S thing maybe because it's not in powerpc's syscall list?<random and uneducated guess>
<jbailey> Could easily be.  I'm just testing the ppc64 kernel for ben atm.
<elmo> if you have a dpatch for amd64, I'm happy to test that, FWIW
<jbailey> concordia:~jbailey/amd64/glibc/glibc-2.3.5/debian/patches/ubuntu-new-binutils.dpatch
<jbailey> That replaces the old ubuntu-new-binutils.dpatch
<elmo> ok, rebuilding on amd64
<jbailey> elmo: You're testing the new binutils?
<elmo> oh, good point, err, yes
<elmo> I suppose I should downgrade
<jbailey> Well, it built fine in the dapper chroot you made for me.
<jbailey> So no point in repeating that test.
<elmo> oh
<jbailey> My brain is spacy, so I'm just trying to make sure I have some clue as to what's happening. =)
<elmo> sweet
<elmo> I get a different error with dapper binutils on ppc
<elmo> ../sysdeps/unix/sysv/linux/getsockname.S: Assembler messages:
<elmo> ../sysdeps/unix/sysv/linux/getsockname.S:5: Error: symbol `__getsockname' is already defined
<elmo> will that go away if I upgrade binutils?
<elmo> I'm getting so confused by all the versions and patches flying around here
<jbailey> Err.
<jbailey> bind.S passed for you?
<jbailey> Or are you on an SMP machine that happened to get a bit further?
<jbailey> getsockname.S and bind.S are basically the same code.
<elmo> ah, yeah, it's davis
<elmo> (which is SMP)
<jbailey> Right.  Look at the build log just before that and see if bind.S failed also.
<jbailey> If it passed then I'm *very* confused.
<jbailey> But it's the exactly same problem.
<elmo> oh, eww
<jbailey> The nice part is it looks like the weak reference is the correct one (per the current symbol set)
<elmo> it died for the 32 bit build
<elmo> but didn't kill the build
<jbailey> Um, yeah.  THere's a small bug in the packaging.
<elmo> symbol `__bind' is already defined
<elmo> make[3] : *** [/home/james/scratch/glibc-2.3.5/build-tree/powerpc-libc/socket/bind.o]  Error 1
<elmo> touch /home/james/scratch/glibc-2.3.5/stamp-dir/build_libc
<elmo> ok
<jbailey> The error code gets eaten by tee.
<jbailey> elmo: Good guess on the syscall.
#ubuntu-toolchain 2005-11-23
<elmo> jbailey: ok, confirmed amd64 works with new patch + new binutils for whatever little that's worth ;)
<elmo> well at least it's not regressing any further, I guess
<jbailey> works like builds, or works like you installed it and shit still generally runs?
<elmo> oh, builds
<elmo> I can do install, this is a throw away chroot
<jbailey> That would be lovely.
<jbailey> Even just if bash and ls run, at least we know it won't drive the world to a complete halt. =)
<elmo> done, stuff seems fine
<jbailey> Thanks.
<jbailey> Hmm, seems I have a patch for ppc32, anyway.
<jbailey> I'll let it build and check the symbol table to make sure it's still okay.
<jbailey> Feh.  For the socket family.
* jbailey debugs the s_lround stuff
<jbailey> woohoo, gratuitous strong_alias removed.
<jbailey> Bah, the bind fix is wrong, it leaves it as a strong alias.
<jbailey> the lround fix is right, though.
<jbailey> I'll fix after dinner. whee
<jbailey> Bah.  All of the libc6 symbols match on ppc now in my local build.
<jbailey> In ppc64 .free, .malloc, and .realloc went from weak symbols to global ones.
<jbailey> elmo: If you happen to be awake and want to follow along: http://people.ubuntu.com/~jbailey/ubuntu-new-binutils.dpatch
<jbailey> Is my current dpatch.
<jbailey> elmo: Can I get an i386 dapper chroot on concordia as well for these tests?  I'd like to do symbol comparisons there, too.
<jbailey> And I should get off my ass and generally implement it for our builds.
<jbailey> One more item on the glibc todo list.
* jbailey goes and spends time with his wife
<doko> infinity, elmo, jbailey: would I interfer with you merging the current binutils from unstable?
<doko> infinity, elmo, jbailey: would I interfer with you merging the current binutils from unstable?
<jbailey> EPARSE: Missing conditional clause.
<infinity> Yeah, uhm.  ENGLISH.
<infinity> :P
<infinity> (I assume you're asking if we'd mind if you did the merge, and I'd answer "no, go the fuck ahead")
<infinity> I'm sick, and it's the weekend.
<jbailey> drow said that binutils needs the update from this week.
<infinity> Yeah, elmo uploaded to sid yesterday.
<infinity> Or today.
<jbailey> Ah, okay.
<infinity> 20051117 snap.
<jbailey> In which case, that's a good thing to merge.
<infinity> <nod>
<infinity> I was going to merge it, but ENOBRAIN... Or ETOOMUCHMUCOUS.
<jbailey> The claire disease has gotten to you too?
<infinity> doko : Go ahead and merge it.  Don't forget to remove all occurrances of pkgstriptranslations from debian/rules, that stuff's obsolete now.
<infinity> jbailey : It's Claire's fault?
<jbailey> It was for our room, anyway.
<jbailey> Noone was sick until she showed up.
<infinity> I'll be sure to make an extra large expense claim, then.
<doko> ok, merging
<infinity> Danke.
<infinity> That puts me one step closer to a new LRM.
<infinity> jbailey : Is the glibc upload ready to go and just waiting on binutils?
<jbailey> infinity: No, glibc now builds correctly on ppc32 and I've verified all the symbols.  ppc64 builds but some unrelated bits had their symbol types change.
<jbailey> Since those were *completely* unrealted to anything I touched, I assume it's more binutils fallout, so I feel compelled to actually do symbol matching against every arch.
<jbailey> But if it were to be uploaded now, it would probably actually build everywhere.
<infinity> Mmkay.  Well, it's a weekend now anyway, so I'm fine waiting on you being cautious.
<jbailey> Did flight-1 go out yet?
<fabbione> no afaik
<infinity> Early next week, I'd love to get it in, though (and I'm sure you'd love to get it in so yo ucan get distro off your task list)
<infinity> And no, I don't think flight-1 actually happened, so you'd want to ping Colin before blowing up the world.
<jbailey> Dude, I have a pile of glibc stuff after this to do.
<jbailey> I've been just reducing the scope so that it actually builds with the new binutils so we can get on with life.
<jbailey> It looks like people have generally stopped asking me about initramfs-tools, which is nice.
<doko> http://people.ubuntu.com/~doko/
<doko> somebody wants to double-check? built ok on i386 and amd64
<jbailey> doko: Do you fail the build in the event of testsuite regressions?
<elmo> no
<lamont-away> doko: so we get a new gcc-3.4 and gcc-4.0, yes?
<doko> lamont-away: is flight-1 done?
<lamont-away> dunno - I was more just making sure that we get both when it happens...
<doko> lamont-away: yes, both are prepared
<doko> binutils hppa build failure:
<doko> /bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2   -o strip-new  objcopy.o is-strip.o rename.o rddbg.o debug.o stabs.o ieee.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a  
<doko> gcc -W -Wall "" -Wmissing-prototypes -Werror -g -O2 -o .libs/strip-new objcopy.o is-strip.o rename.o rddbg.o debug.o stabs.o ieee.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o  ../bfd/.libs/libbfd.so -L/build/buildd/binutils-2.16.1cvs20051117/builddir-single/libiberty/pic -liberty ../libiberty/libiberty.a
<doko> gcc: : No such file or directory
<doko> make[5] : *** [strip-new]  Error 1
<doko> hmm, that's the libc built with gcc-4.0
<doko> lamont-away: please update
<lamont-away> The following packages will be upgraded:
<lamont-away>   coreutils grep gzip login
<lamont-away> then what?
<jbailey> doko: libc build with gcc-4.0?
<jbailey> You mean in Debian, right?
<doko> yes, -7 was built with 4.0, -8 with 3.4
<jbailey> Right, just making sure that the broken idea of gcc-4 and glibc playing together hadn't surfaced in Dapper.
<jbailey> That breakage is definetly for dapper+!
<lamont-away>   clisp coreutils cpio debconf debconf-english debianutils fakeroot grep initscripts libc6 libc6-dev login lsb-base passwd perl-modules sysv-rc sysvinit tar
<lamont-away> oh... debian.  right.
<doko> lamont-away: the binutils build log says -7
<lamont-away> which was clear from the channel name and all that. :-)
<jbailey> lamont-away: And when in doubt, the /topic =)
<lamont-away> not that I mind debian discussions here, I just need to know that we're talking about debian, not ubuntu... :-)
<lamont-away> and binutils given back
<doko> lamont-away: just trying to look at our community builds, before uploading to dapper ...
<doko> FAIL: sym@tocbase is a regression on powerpc compared to 2.16.1cvs20051109
<doko> jbailey, elmo: ^^^
<jb-away> doko_: You around?
<doko_> jbailey: yes
<jbailey> I've been thinking a bit more about toolchain-ng and your concerns about targetting i486 by default.
<jbailey> Do you have any good links to gcc mailing list where people are saying "use i686 instead of i386" for your target?
<jbailey> I remember when I did some tests before that I wasn't able to show a big improvement for i686 because most apps that could be improved already provided enhanced libraries.
<doko_> no, just private mails
<jbailey> When I've mentioned it before, the answers I've gotten were basically that our target audience includes folks with older machines.
<jbailey> My counter argument is that our choice of applications argues that it's not actually our focus.
<jbailey> So part of me was wondering whether or not older machines should be actually left to a derivative distro or something, or maybe micro-buntu?
<jbailey> Especially since Dapper is a long lived release, right after it is time to change.
<doko_> maybe I should re-find some bug reports which I submitted for i486, not showing on i686
<jbailey> Yeah, and maybe use them as data for a rationale section in a spec.
<doko_> hmm, but we currently don't have derivatives, which recompile packages
<jbailey> Right, but micro-ubuntu is going to have to, noone wants all the docs on their handheld. =)
<jbailey> And it certainly needs to be generally possible anyway.
<jbailey>  -- And I think is generally possible from how Daniel explained Soyuz
<doko_> yes, it should be possible. but is micro-ubuntu and i386-ubuntu really the same thing?
<jbailey> The question is how are they different?
<jbailey> Any machine running i386 really *doesn't* want gnome and openoffice.
<jbailey> It probably doesn't have USB, so doesn't need all the plug events.
<jbailey> It quite likely doesn't have PCI, so might need a different startup mechanism than we're using.
<doko_> yes, but is all the other stuff the same? i.e. an installer for an embedded device?
<jbailey> I don't think anyone's thought through how the installer should look.
<jbailey> But I don't imagine that writing to a CF card is all that different than writing to a harddrive in an i386.
<jbailey> You'll need some way to boot it, and prep the media and then start loading data.
<jbailey> d-i is flexible enough to generally handle 2 and 3.
<doko_> have other defaults for cron/at/logd?
<jbailey> Again, maybe.
<jbailey> cron,daily is difficult enough on my pentium 3 machine when I'm online.
<jbailey> On an i386 it could be brutal.
<jbailey> The same is true for any embedded device.
<jbailey> I think the burden isn't on us at the moment to solve the how-would-it-work on i386.
<jbailey> I think the burden is on us to show that there's a clear advantage do doing i686 and up only.
<jbailey> Specifically: The toolchain folks aren't really targetting pre-i686
<jbailey> Our applications don't effectively run on pre-i686
<doko> yes, let's search these things until our next dev-sprint
<jbailey> 'k
<doko> good night!
<jbailey> g'n Matthias
#ubuntu-toolchain 2005-11-24
<Riddell> doko: libstdc++ trasition today then? :)
#ubuntu-toolchain 2005-11-25
<elmo> lamont: ?
<linnuxxy> where can i find a prebuilt toolchain for armeb?
<jbailey> I'm pretty certain we don't provide one right now.
<jbailey> That sort of thing will come when we do micro-buntu, probably.
<fabbione> doko: ping?
<doko> infinity, lamont-away: gcc-4.0 doesn't build, because 
<doko> The following information may help to resolve the situation:
<doko> The following packages have unmet dependencies:
<doko>   lsb-release: Depends: python (> 2.3) but it is not going to be installed
<doko>                Depends: python (< 2.5) but it is not going to be installed
<doko> E: Broken packages
<doko> apt-get failed.
<doko> Package installation failed
<doko> fabbione: pong
<fabbione> doko: yo
<fabbione> same for gcc-3.4
<fabbione> when do we start the transition?
<fabbione> at least gcc-3.4 on sparc doesn't build for the same exact reason
<doko> when the packages are built
<doko> this error message doesn't make sense for me
<fabbione> doko: ok, are the buildd's at the DC on idle?
<fabbione> do we actually need to put them in idle?
<doko> fabbione: no, doesn't seem to be necessary, we'll rebuild the packages anyway
<fabbione> hmmm
<fabbione> how are you going to make sure that all of them are built with the latest gcc-4.0 and 3.4?
<doko> not starting with the renaming before the buildd's have the new versions
<fabbione> doko: i assume that includes also SCC :D
<doko> fabbione: any hint, why lsb-release is not installable?
<fabbione> doko: no, i should check in a chroot to see why
<fabbione> but clearly it's trying to install a python that can't be installed
<doko> nice, dapper_probs lists the whole archive as uninstallable
<fabbione> yeah i saw
<doko> infinity, lamont-away, fabbione: after python2.4_2.4.2-1ubuntu1 is built, please requeue gcc-3.4 and gcc-4.0, so we can start the libstdc++ allocator change
<fabbione> doko: gotchat
<fabbione> -t$
#ubuntu-toolchain 2005-11-26
<jbailey> <stdin>: Assembler messages:
<jbailey> <stdin>:4: Warning: Empty argument of .endp
<jbailey> <stdin>:4: Warning: `__syscall_error_4' should be an operand to this .endp
<jbailey> I wonder if that's new (for ia64)
<fabbione> doko:
<fabbione> checking LIBART_LIBS... -lart_lgpl_2  
<fabbione> checking for XTestQueryExtension in -lXtst... no
<fabbione> configure: error: libXtst not found, required by java.awt.Robot
<fabbione> gcc-snapshot on sparc ^^
<fabbione> _20051118-0ubuntu1
<fabbione> doko: sparc is building gcc-4 and gcc-3.. if they are not FTBFS you are good go ;)
<fabbione> later
<infinity> doko : On ia64 and powerpc, gcc-4.0 gets this:
<infinity> checking for X... no
<infinity> *** xlib peers requested but no X library available
<infinity> make[3] : *** [configure-target-libjava]  Error 1
<doko> infinity: nice, do you know why?
<doko> infinity: on i386 and amd64 as well?
<infinity> doko : No, i386 and amd64 built fine, just ppc and ia64 choked.  I'll rety them in a bit to see if it was a transient build-dep issue.
<infinity> Oh, wait.
<infinity> Did I need a specific newer version of something that might be stuck in the chroots?
<infinity> Nevermind, the chroots are up to date anyway.
* infinity respins powerpc and ia64 to see what happens.
<doko> it's strange, that the generice test for X fails. please keep the build, so you have a look at the config.log file
<infinity> Meh.  Too late to keep the build, already started it.
<infinity> (sbuild on our buildds is configured to remove failed trees, so we don't eat disk insanely)
<infinity> But if it fails again, I'll muck with it again and keep the tree.
<Riddell> doko: so libstdc++ transition has happened?
<doko> Riddell: no, no powerpc packages yet
<Riddell> doko: so I shouldn't start uploading?
<doko> no
<jbailey> doko: What's blocking PPC?
<doko> a strange build failure, no X found. infinity is currently rebuilding
<jbailey> Feh, I hope it's not some part of the X transition.
<jbailey> I have ppc and amd64 building.  i386 and ia64 fail for glibc right now.
<jbailey> I'll be back to hacking on that in an hour or so, I think.
<doko> X transition?
<jbailey> To modular X, blocked by glibc.
<infinity> doko : Around?
<infinity> doko : conftest.c:23:27: error: X11/Intrinsic.h: No such file or directory
<doko> that's in libxt-dev? 
<infinity> In theory.
<doko> strange that his breaks on only two architectures
<fabbione> it might as well be that the other 2 chroots are dirty :)
<infinity> They're not.
<infinity> I already checked that.
<doko> fabbione: but then, my own chroots are dirty as well
<infinity> I wonder if another -dev lib used to depend on libxt-dev, and your upload happened at just the right time to catch that changing.
<fabbione> doko: we all know you like "dirty" stuff :P
<fabbione> is that only on gcc-4.?
<fabbione> or also 3.4?
<doko> no, 3.4 doesn't build java
<fabbione> i saw that error yesterday on -snapshot
<fabbione> (pasted the log here)
<fabbione> on sparc
<infinity> I blame GTK.
<infinity> Anyhow.
<infinity> doko : Your configure test explicitely includes that header (it's not pulled in through a transient dep in another header), so you may as well just build-dep on libxt-dev and call it a day.
<jbailey> I like how even GCC can say "Iz gtk bug" and possibly be right.
<doko> :)
<doko> infinity: that configure test comes directly from autoconf ...
<infinity> doko : And autoconf is wrong, because it assume a monolithic X, but whatever.  One battle at a time. :)
<infinity> I believe changes are going into autoconf upstream to make the X tests more correctly modular.
<doko> ok, thanks for figuring that out ...
<infinity> Can you upload ASAP, or should I just pre-seed the chroots with xt-dev and rebuild?
<doko> uploading now ...
<fabbione> doko: you also want to reupload gcc-snapshot
<fabbione> for the same reason
<doko> fabbione: not now ...
<infinity> It's hardly urgent.
<fabbione> fabbione doko:
<fabbione> fabbione checking LIBART_LIBS... -lart_lgpl_2  
<fabbione> fabbione checking for XTestQueryExtension in -lXtst... no
<fabbione> fabbione configure: error: libXtst not found, required by java.awt.Robot
<fabbione> fabbione gcc-snapshot on sparc ^^
<fabbione> fabbione _20051118-0ubuntu1
<fabbione> fabbione doko: sparc is building gcc-4 and gcc-3.. if they are not FTBFS you are good go ;)
<fabbione> no
<fabbione> just FYI
<infinity> xtst-dev != xt-dev
* fabbione smells more borkage
<infinity> If Java really needs xtst-dev too, you just found another build-dep. :)
<doko> no, that's something else. xtst-dev is needed for something called JavaRobot
<doko> but it's interesting, that the build did succeed on i386 and amd64
<infinity> Oh, cock.
<infinity> doko : Do you disable logwatch on ubuntu, or is it just breaking?
<infinity> doko : gcc-3.4 on ia64 timed out in the testsuite.
<doko> no, it was never enabled on ia64
<infinity> Ahh.  I assumed it was enabled on all arches.
<infinity> Silly me.
<infinity> Maybe if it was, the odd bugs with it occasionally hanging would have been found sooner. :)
<infinity> (I still need to look into that some day... I had to kill logwatch on kullervo the other day for gcc-3.4... And lamont had to kill it on hppa, I think)
<lamont-away> infinity: this time I just had to kill of an expect from 3.4
<lamont-away> interesting... said find started after findutils sbuild started.
<infinity> Ahh.
<infinity> ARGH.
<infinity> buildd-watcher on floe is racing AGAIN.
<infinity> Why just floe?  Have you hand-hacked something there?  <stafre>
<infinity> s/starfe/stare/
<lamont-away> not to the best of my knowledge...
<infinity> Same buildd-watcher as on hooker...
<infinity> <sigh>
<infinity> I'm going to shut down the buildd on floe for now, and look into it tomorrow when my plate's not so full.
<infinity> Having several buildds running and competing with each other for chroots is kinda.  Uhm.  Bad.
<infinity> (Yes, that happened earlier today)
<infinity> Though right now, we only seem to have one buildd/sbuild, thankfully.  Many buildd-watchers, though.
<lamont-away> buildd-watcher backs up sometimes, yes.
<lamont-away> there might be a window where it assumes that it's find (build-tree cleaning/reporting, etc) will finish before another buildd-watcher starts.
<lamont-away> this is not always the case...
<fabbione> hey lamont-away 
<infinity> Oddly enough, this never seems to happen on m68k, despite my running buildd-watcher several times per hour and having really, really, really slow I/O.
<infinity> I guess I should check your diffs against Ryan's tree.
<infinity> doko : I see you're getting pressure from vorlon for the system compiler split.
<infinity> (or, at least splitting java out)
<infinity> doko : You really should have put it in big blinking letters in your toolchain roadmap so you could do it on paid time.  It's totally justifiable for Ubuntu as well.
<doko> infinity: it should be in JavaRoadmap
<elmo> infinity: our insane number of distros doesn't help, most m68k buildds only have one chroot to traverse
<elmo> at least, whenever I look at a buildd they tend to sit their in io wait for a rather pointless find over the chroots
<infinity> elmo : Well, 6.
<infinity> But yeah, we have more than 6.
<jbailey> What's happening with a core compiler split?
<elmo> ?
<doko> gcc-4.0 sucks in the whole archive as b-d's while completing libgcj  ...
<doko> jbailey: and even in ubuntu it would be nice to get rid of the x dependencies, as you can see
<fabbione> jbailey: i think it all goes back to modular gcc...
<fabbione> that i did propose not too long ago to $icantrememberwhoinhere
<infinity> Ah-ha.
<infinity> lamont : I'll fix the "buildd-watcher takes too effin' long" bug tomorrow when I have time to test it.
<doko> fabbione: I can't remember, did you?
<infinity> But it's pretty obvious.
<infinity> Original code:
<fabbione> doko: i don't think it was to you actually
<infinity>         next if $file =~ m#^build/chroot-[^/] +$#;
<fabbione> doko: more likely jbailey 
<infinity> Ours kinda.  Uhm.  Doesn't do that.
<elmo> hahaha
* infinity claps.
<elmo> more to the point ours doesn't match 'build/'
<infinity> Stupid build-* split.
<infinity> elmo : Yes, we explicitely name all the build-$DIST targets in ours... Then don't exclude the chroots.
<infinity> I'd blame lamont, but this is a public channel, and I'm a nice person.
<infinity> Oops, gthat was my out loud voice. :)
<infinity> s/gthat/that/
<fabbione> ahaha
<lamont-away> infinity: oops. :)
<lamont-away> infinity: sigh
<infinity> I'll fix it tomorrow.
<lamont-away> was that in our original base, or just merged in from upstream?
<infinity> For bonus points, I'll actually run a full watcher run, with no report-ed-old-files cache and actually clean everything up, so I can stop ignoring cron's whining.
* lamont-away added an  -xdev to the find, which got rid of the ccache search.. :-)
<lamont-away> ok
<infinity> Heh, but if chroot is properly ignored (and ~/ccache as well), that's a non issue.
<infinity> elmo : floe should stop setting off alarms for you.
<infinity> Though I'm curious why floe is the only one that races this badly.  Either it has one mother of a huge chroot somewhere (that should be removed and rebuilt), or something's desperately wrong with that box.
<infinity> I'm going to assume the former, cause it seems well behaved otherwise.
<lamont-away> fwiw, pitti picks really ugly version numbers
<lamont-away> inkscape_0.42-1build1ubuntu0.1 is now in breezy-security
<infinity> foo_1.2.3-1ubuntu05.10?
<infinity> Oh, eww.
<lamont-away> 'zactly
<infinity> Someone should point out to him that 'u' is higher than 'b'.
<elmo> did you guys get my mail about b-backports btw?
<elmo> [nb: I'm not chasing, I don't care when it's done, just checking] 
<lamont-away> elmo: when did you send it?
<infinity> elmo : Yes, and I'll enable it tomorrow, if the world doesn't come to an end first. :)
<lamont-away> there it is
<elmo> infinity: kthx
<infinity> Unless lamont feels the urge.
<fabbione> can't we forget about -backports by ... let say.. mistake?
* infinity coughs.
<fabbione> i mean
<fabbione> that would comply with the specs
<lamont-away> infinity: I'll go ahead and create the chroots - that's the easy part.
<lamont-away> then it should autostart when the nightly chroot update runs
<fabbione> quoting: https://wiki.ubuntu.com/BackportsPromotion
<infinity> Such faith you have in your automated tools.  I like it.
<fabbione> "Make people more aware of backports, and make the backport request process LESS transparent"
<lamont-away> adare is now launchpad, yes?
<fabbione> i can't see anything more hidden than not creating the chroots ;)
<infinity> lamont-away : In theory.  Not sure it's being used as such, but it's definitely not hooked into w-b either.
<infinity> fabbione : Hah.  Nice thinko.
<fabbione> infinity: when i read that at UBZ i was >< this close to approve the specs :D
<infinity> Sadist.
<fabbione> oh yeah
<fabbione> I LOVE TO SEE PEOPLE SUFFER IN ENDLESS PAIN
* infinity goes back to work, after briefly wondering WHY he's working at 2:44am.
<infinity> What I wouldn't give for a nasty case of narcolepsy in my old age.
* lamont-away is building the chroots, then I get to go work on septic systems.  sigh
<infinity> Man, HP really makes you start at the bottom of the ladder when you're a new hire again, don't they? :)
<lamont-away> elmo: chroots are created everywhere
<lamont-away> infinity: nah - this is house work... and the more I procrastinate, the deeper the sludge in the tank.  Hence, todya
<lamont-away> the damage was discovered friday when the nice people pumped the tank for me.
<lamont-away> but I fear I shall be buying hip-waders before the day is out.
<infinity> And throwing them out tomorrow.
<lamont-away> nah - you just put trash bags on them first. :-)
<Riddell> infinity: are you going to upload subversion with new libdb ?
<doko> Riddell: he has to ... it's not buildable otherwise
<Riddell> and neither is large chunks of KDE
<lamont-away> checking for XTestQueryExtension in -lXtst... no
<lamont-away> configure: error: libXtst not found, required by java.awt.Robot
* lamont-away kicks doko
<lamont-away> interestingly, libxt-dev is in build-depends
<doko_> lamont-away: which architecture?
<lamont-away> that was -2 on ppc
<lamont-away> is -3 the end of it?
<fabbione> i told ya that we needed more :)
<fabbione> gcc-snapshot rules!
<fabbione> doko: still around?
<doko> fabbione: yes
<fabbione> doko: ok-- gcc-4.0 is going to build in 10/15 minutes of sparc
<fabbione> 3.4 is up
<fabbione> do we need gcj before we start the transition?
<doko> no
<doko> hmm, but gettext depends on it ...
<fabbione> is gettext a pkg that needs transition?
<fabbione> well i guess it's going to stall the others
<fabbione> we will see tomorrow
<fabbione> doko: thanks for the info
<fabbione> i am off to sleep
<doko> no, it doesn't need a transition, but a working libgcj
<fabbione> ok
<lamont> gcc-4.0 (-3) will start building on hppa momentarily
<doko> note that I did separate the build of the gcj packages into a separate source package, so you need to build that as well. that's currently stuck in NEW
<lamont> can we get that unstuck please?
<lamont> or does that not need to happen before the transition starts?
<lamont> avg-pkg-build-time gcc-4.0
<lamont> gcc-4.0:                06:31:36 (3 entries, sigma 00:46:59)
<doko> the build time will drop, it doesn't build java anymore
#ubuntu-toolchain 2005-11-27
<lamont> gcc-4.0 finally starts building.
<lamont> db4.3 and breezy-security got in the way
<lamont> and the 4 hours of building -4ubuntu2 didn't help much either
* infinity hugs doko for the gcj split.
<infinity> jbailey : glibc is FTBFS on amd64.
<infinity> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S: Assembler messages:
<infinity> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
<infinity> make[3] : *** [/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl/sem_trywait.o]  Error 1
<fabbione> SCORE
<fabbione> hi infinity 
<doko> lamont, infinity, fabbione: what's the status of gcc-4.0 / gcc-3.4 on the buildd's?
<fabbione> 3.4 is done on sparc
<fabbione> 4.0 is building
<fabbione> doko: ASSUMING 4.0 is not FTBFS
<fabbione> you can just start the transition for what is SPARC concern
<fabbione> because i did stop syncing from archive
<fabbione> so i am working a specific archive snapshot
<infinity> doko : I'll make sure all the chroots are up to date in a bit.
<doko> so we don't have a status for hppa?
<infinity> doko : Okay, all the DC buildds are up to date with -4ubuntu3
<fabbione> doko: nope
<doko> ok, lamont will be awake in a few hours
<infinity> jbailey : Actually, you're FTBFS on everything but powerpc.  Lucky you.
<lamont> doko: hppa won't build anything more for dapper until the chroot is updated.
<doko> lamont: cool
<lamont> doko: right now, it's building a breezy-security package, which should be done in another 2-3 hours... :-(
<lamont> and then the buildd will stop and I'll upgrade the chroot
<lamont> actually...
<lamont> if it's building breezy-security, then the dapper chroot is quiescent
<lamont> interesting... gcc-4.0 doesn't show up in the upgrade
<lamont> but then, it hasn't been that very long...
<lamont> I'll upgrade the chroot in a bit when I get to work.
<lamont> doko: hppa chroot updated
<lamont> Build needed 11:09:59, 1173980k disk space
<lamont> just fyi on the gcc-4.0 thing...
<doko> lamont: ok, thanks
<doko> now we just need an updated subversion, and Riddell get's happy for the kde uploads ...
<Riddell> yes please :)
<Riddell> doko: can I upload stuff that doesn't need subversion?
<doko> Riddell, yes, but I need to announce it, however I'm away now until 23:00 UTC
<Riddell> announce it?
<doko> u-d-a ...
<mdz> /usr/bin/ld: section .note.ABI-tag [0000000000002c58 -> 0000000000002c77]  overlaps section .dynsym [0000000000002810 -> 000000000000836f] 
<mdz> /usr/bin/ld: qemu-i386: Not enough room for program headers (allocated 8, need 9)
<mdz> /usr/bin/ld: final link failed: Bad value
<mdz> elmo: does that look like a new-binutils issue?  if so, what can I do about it?
<elmo> could be; try an older one, and if it works, file a bug on binutils in Debian
<mdz> conveniently, the old one is still available from dapper on us.archive.ubuntu.com
<mdz> elmo: works with 2.16.1-2ubuntu7, will file
<elmo> we're looking at the us thing; it really isn't actually trivial
<lamont> doko.  where is doko.
<lamont> must kill
<lamont> doko: gcj-4.0 fails to build:
<lamont> The following packages have unmet dependencies:
<lamont>   gettext: Depends: libgcj6 (>= 4.0.1) but it is not going to be installed
<lamont> doko: thoughts?
<fabbione> lamont: recursive build-dep
<fabbione> lamont: what version are you trying to build?
<fabbione> i think doko already fixed that
<lamont> logs/gcj-4.1_4.1ds1-0ubuntu1_20051122-1114
<lamont> ditto for gcj-4.0_4.0.2-4ubuntu5
<fabbione> i have this wonderful feeling that tells me to keep a local copy of libgjc
<lamont> yep
#ubuntu-toolchain 2007-11-19
<arthur-> doko: do you have a 4.1 or 4.2 upload planed soon ?
<arthur-> doko: I've fixed gdc-4.2 ICEs, I'm preparing next upload, it'll perhaps make sens to have a gdc in gcc-defaults now
<arthur-> doko: but locales/dak must be fixed first to allow source uploads...
<doko> arthur-: not yet planned
<arthur-> doko: ok, thanks
<jbailey> What is 'gdc'?
<arthur-> jbailey: D front end for gcc
<jbailey> Which 'D'?  There've been a dozen or so in the last decade calling themselves that.
<arthur-> jbailey: http://en.wikipedia.org/wiki/D_programming_language
<jbailey> Thanks.
<arthur-> ;-)
<jbailey> I'll have to ask Danny about this.  I was chatting with him about the annoyances of optimising C code versus the annoyances of optimising Java code.
<jbailey> He described a few chance to C that would make escape analysis quite nice, and a few other things.
<jbailey> I'm curious if D does those things.
