[12:08] <elmo> jbailey: ok, confirmed amd64 works with new patch + new binutils for whatever little that's worth ;)
[12:08] <elmo> well at least it's not regressing any further, I guess
[12:09] <jbailey> works like builds, or works like you installed it and shit still generally runs?
[12:09] <elmo> oh, builds
[12:09] <elmo> I can do install, this is a throw away chroot
[12:09] <jbailey> That would be lovely.
[12:10] <jbailey> Even just if bash and ls run, at least we know it won't drive the world to a complete halt. =)
[12:10] <elmo> done, stuff seems fine
[12:10] <jbailey> Thanks.
[12:23] <jbailey> Hmm, seems I have a patch for ppc32, anyway.
[12:24] <jbailey> I'll let it build and check the symbol table to make sure it's still okay.
[12:29] <jbailey> Feh.  For the socket family.
=== jbailey debugs the s_lround stuff
[12:37] <jbailey> woohoo, gratuitous strong_alias removed.
[12:43] <jbailey> Bah, the bind fix is wrong, it leaves it as a strong alias.
[12:44] <jbailey> the lround fix is right, though.
[12:44] <jbailey> I'll fix after dinner. whee
=== infinity [n=adconrad@loki.0c3.net]  has joined #ubuntu-toolchain
=== Riddell [i=jr@kde/jriddell]  has joined #ubuntu-toolchain
[04:31] <jbailey> Bah.  All of the libc6 symbols match on ppc now in my local build.
[04:31] <jbailey> In ppc64 .free, .malloc, and .realloc went from weak symbols to global ones.
[04:32] <jbailey> elmo: If you happen to be awake and want to follow along: http://people.ubuntu.com/~jbailey/ubuntu-new-binutils.dpatch
[04:32] <jbailey> Is my current dpatch.
[04:36] <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.
[04:37] <jbailey> And I should get off my ass and generally implement it for our builds.
[04:37] <jbailey> One more item on the glibc todo list.
=== jbailey goes and spends time with his wife
=== chmj [n=chmj@wbs-146-146-186.telkomadsl.co.za]  has joined #ubuntu-toolchain
[12:44] <doko> infinity, elmo, jbailey: would I interfer with you merging the current binutils from unstable?
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[01:46] <doko> infinity, elmo, jbailey: would I interfer with you merging the current binutils from unstable?
[01:47] <jbailey> EPARSE: Missing conditional clause.
[01:47] <infinity> Yeah, uhm.  ENGLISH.
[01:47] <infinity> :P
[01:48] <infinity> (I assume you're asking if we'd mind if you did the merge, and I'd answer "no, go the fuck ahead")
[01:48] <infinity> I'm sick, and it's the weekend.
[01:48] <jbailey> drow said that binutils needs the update from this week.
[01:48] <infinity> Yeah, elmo uploaded to sid yesterday.
[01:48] <infinity> Or today.
[01:48] <jbailey> Ah, okay.
[01:48] <infinity> 20051117 snap.
[01:48] <jbailey> In which case, that's a good thing to merge.
[01:49] <infinity> <nod>
[01:49] <infinity> I was going to merge it, but ENOBRAIN... Or ETOOMUCHMUCOUS.
[01:49] <jbailey> The claire disease has gotten to you too?
[01:49] <infinity> doko : Go ahead and merge it.  Don't forget to remove all occurrances of pkgstriptranslations from debian/rules, that stuff's obsolete now.
[01:49] <infinity> jbailey : It's Claire's fault?
[01:50] <jbailey> It was for our room, anyway.
[01:50] <jbailey> Noone was sick until she showed up.
[01:50] <infinity> I'll be sure to make an extra large expense claim, then.
[01:52] <doko> ok, merging
[01:54] <infinity> Danke.
[01:54] <infinity> That puts me one step closer to a new LRM.
[01:54] <infinity> jbailey : Is the glibc upload ready to go and just waiting on binutils?
[01:56] <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.
[01:57] <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.
[01:57] <jbailey> But if it were to be uploaded now, it would probably actually build everywhere.
[01:58] <infinity> Mmkay.  Well, it's a weekend now anyway, so I'm fine waiting on you being cautious.
[01:58] <jbailey> Did flight-1 go out yet?
[01:58] <fabbione> no afaik
[01:58] <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)
[01:59] <infinity> And no, I don't think flight-1 actually happened, so you'd want to ping Colin before blowing up the world.
[01:59] <jbailey> Dude, I have a pile of glibc stuff after this to do.
[01:59] <jbailey> I've been just reducing the scope so that it actually builds with the new binutils so we can get on with life.
[02:00] <jbailey> It looks like people have generally stopped asking me about initramfs-tools, which is nice.
[02:48] <doko> http://people.ubuntu.com/~doko/
[02:48] <doko> somebody wants to double-check? built ok on i386 and amd64
[02:52] <jbailey> doko: Do you fail the build in the event of testsuite regressions?
[02:53] <elmo> no
[02:58] <lamont-away> doko: so we get a new gcc-3.4 and gcc-4.0, yes?
[03:01] <doko> lamont-away: is flight-1 done?
[03:02] <lamont-away> dunno - I was more just making sure that we get both when it happens...
[03:03] <doko> lamont-away: yes, both are prepared
[03:07] <doko> binutils hppa build failure:
[03:07] <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  
[03:07] <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
[03:07] <doko> gcc: : No such file or directory
[03:07] <doko> make[5] : *** [strip-new]  Error 1
[03:08] <doko> hmm, that's the libc built with gcc-4.0
[03:08] <doko> lamont-away: please update
[03:17] <lamont-away> The following packages will be upgraded:
[03:17] <lamont-away>   coreutils grep gzip login
[03:17] <lamont-away> then what?
[03:18] <jbailey> doko: libc build with gcc-4.0?
[03:18] <jbailey> You mean in Debian, right?
[03:18] <doko> yes, -7 was built with 4.0, -8 with 3.4
[03:18] <jbailey> Right, just making sure that the broken idea of gcc-4 and glibc playing together hadn't surfaced in Dapper.
[03:18] <jbailey> That breakage is definetly for dapper+!
[03:19] <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
[03:19] <lamont-away> oh... debian.  right.
[03:19] <doko> lamont-away: the binutils build log says -7
[03:19] <lamont-away> which was clear from the channel name and all that. :-)
[03:20] <jbailey> lamont-away: And when in doubt, the /topic =)
[03:21] <lamont-away> not that I mind debian discussions here, I just need to know that we're talking about debian, not ubuntu... :-)
[03:21] <lamont-away> and binutils given back
[03:21] <doko> lamont-away: just trying to look at our community builds, before uploading to dapper ...
[03:26] <doko> FAIL: sym@tocbase is a regression on powerpc compared to 2.16.1cvs20051109
[03:26] <doko> jbailey, elmo: ^^^
=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has left #ubuntu-toolchain ["Leaving"] 
=== doko_ [n=doko@dslb-084-059-084-248.pools.arcor-ip.net]  has joined #ubuntu-toolchain
=== jb-away [n=jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[10:43] <jb-away> doko_: You around?
[10:43] <doko_> jbailey: yes
[10:44] <jbailey> I've been thinking a bit more about toolchain-ng and your concerns about targetting i486 by default.
[10:44] <jbailey> Do you have any good links to gcc mailing list where people are saying "use i686 instead of i386" for your target?
[10:45] <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.
[10:45] <doko_> no, just private mails
[10:46] <jbailey> When I've mentioned it before, the answers I've gotten were basically that our target audience includes folks with older machines.
[10:46] <jbailey> My counter argument is that our choice of applications argues that it's not actually our focus.
[10:46] <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?
[10:47] <jbailey> Especially since Dapper is a long lived release, right after it is time to change.
[10:47] <doko_> maybe I should re-find some bug reports which I submitted for i486, not showing on i686
[10:48] <jbailey> Yeah, and maybe use them as data for a rationale section in a spec.
[10:48] <doko_> hmm, but we currently don't have derivatives, which recompile packages
[10:48] <jbailey> Right, but micro-ubuntu is going to have to, noone wants all the docs on their handheld. =)
[10:48] <jbailey> And it certainly needs to be generally possible anyway.
[10:49] <jbailey>  -- And I think is generally possible from how Daniel explained Soyuz
[10:50] <doko_> yes, it should be possible. but is micro-ubuntu and i386-ubuntu really the same thing?
[10:54] <jbailey> The question is how are they different?
[10:54] <jbailey> Any machine running i386 really *doesn't* want gnome and openoffice.
[10:54] <jbailey> It probably doesn't have USB, so doesn't need all the plug events.
[10:55] <jbailey> It quite likely doesn't have PCI, so might need a different startup mechanism than we're using.
[10:55] <doko_> yes, but is all the other stuff the same? i.e. an installer for an embedded device?
[10:56] <jbailey> I don't think anyone's thought through how the installer should look.
[10:56] <jbailey> But I don't imagine that writing to a CF card is all that different than writing to a harddrive in an i386.
[10:57] <jbailey> You'll need some way to boot it, and prep the media and then start loading data.
[10:57] <jbailey> d-i is flexible enough to generally handle 2 and 3.
[10:57] <doko_> have other defaults for cron/at/logd?
[10:57] <jbailey> Again, maybe.
[10:57] <jbailey> cron,daily is difficult enough on my pentium 3 machine when I'm online.
[10:57] <jbailey> On an i386 it could be brutal.
[10:57] <jbailey> The same is true for any embedded device.
[10:59] <jbailey> I think the burden isn't on us at the moment to solve the how-would-it-work on i386.
[10:59] <jbailey> I think the burden is on us to show that there's a clear advantage do doing i686 and up only.
[10:59] <jbailey> Specifically: The toolchain folks aren't really targetting pre-i686
[10:59] <jbailey> Our applications don't effectively run on pre-i686
[11:00] <doko> yes, let's search these things until our next dev-sprint
[11:02] <jbailey> 'k
[11:24] <doko> good night!
[11:37] <jbailey> g'n Matthias
=== lamont [n=lamont@mib.fc.hp.com]  has joined #ubuntu-toolchain