=== jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[01:54] <lamont> jbailey: http://buildd.debian.org/fetch.php?&pkg=alsaplayer&ver=0.99.76-5&arch=ia64&stamp=1120845002&file=log&as=raw
[01:58] <jbailey> Is this a huge blocker for you?  Otherwise, I'd prefer to wait to deal with issues like this until glibc 2.3.5 is in sid.
=== karlheg [~karlheg@host-250-237.resnet.pdx.edu]  has joined #ubuntu-toolchain
[04:03] <lamont> gcc  -g -O2  -Wl,-O1 -Wl,--as-needed -o tsclient  main.o support.o connect.o rdpfile.o mrulist.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2
[04:03] <lamont> +-lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
[04:03] <lamont> +-lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0
[04:03] <lamont> /usr/lib/gcc/hppa-linux-gnu/3.4.5/../../../crt1.o:../sysdeps/hppa/elf/start.S:56: multiple definition of `_GLOBAL_OFFSET_TABLE_'
[04:03] <lamont> collect2: ld returned 1 exit status
[04:04] <lamont> ew
[04:04] <lamont> jbailey: it's blocking about 6 packages, and at least 2 maintainers have asked me about it...
[04:04] <lamont> (ucontext)
[04:04] <lamont> and the root of the issue is that the "constant" isn't defined anywhere
[04:05] <lamont> I'll probably pester dannf et al about ucontext tomorrow
[04:05] <lamont> it could just be a kernel bug
[04:07] <lamont>   wcs = new (WorldCoor*)[MULTWCS] ;
[04:07] <lamont> so that's bad C++, eh?
=== daniels stares.
=== karlheg [~karlheg@host-250-237.resnet.pdx.edu]  has joined #ubuntu-toolchain
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-toolchain
[04:41] <jbailey> karlheg: Hey!
[04:42] <jbailey> lamont: Umm, yes.
[04:42] <jbailey> lamont: The thing is that if it compiled fine in Breezy, then the answer is to just wait for the new glibc.  There's no point in uploading a fix for the current glibc in sid.
=== karlheg [~karlheg@host-250-237.resnet.pdx.edu]  has joined #ubuntu-toolchain
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-toolchain
=== karlheg [~karlheg@host-250-237.resnet.pdx.edu]  has joined #ubuntu-toolchain
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-toolchain
[06:50] <fabbione> morning
=== Riddell [jr@muse.19inch.net]  has joined #ubuntu-toolchain
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-toolchain
=== svenl [~luther@AStrasbourg-251-1-20-215.w82-126.abo.wanadoo.fr]  has joined #ubuntu-toolchain
=== daniels [~daniels@amnesiac.heapspace.net]  has joined #ubuntu-toolchain
=== Riddell [jr@muse.19inch.net]  has joined #ubuntu-toolchain
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #ubuntu-toolchain
=== infinity [~adconrad@loki.0c3.net]  has joined #ubuntu-toolchain
=== ajmitch [~ajmitch@port163-96.ubs.maxnet.co.nz]  has joined #ubuntu-toolchain
=== desrt [~desrt@dhcp-0-20-af-d2-7c-3.cpe.mountaincable.net]  has joined #ubuntu-toolchain
=== jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
=== Seveas [~seveas@ksl403-uva-165.wireless.uva.nl]  has joined #ubuntu-toolchain
=== svenl [~luther@AStrasbourg-251-1-20-215.w82-126.abo.wanadoo.fr]  has joined #ubuntu-toolchain
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-toolchain
=== daniels [~daniels@amnesiac.heapspace.net]  has joined #ubuntu-toolchain
=== svenl [~luther@AStrasbourg-251-1-20-215.w82-126.abo.wanadoo.fr]  has joined #ubuntu-toolchain
=== chmj [~chmj@196.36.161.235]  has joined #ubuntu-toolchain
=== doko [~doko@a130-233-5-210.debconf5.hut.fi]  has joined #ubuntu-toolchain
=== jbailey_ [~jbailey@modemcable139.249-203-24.mc.videotron.ca]  has joined #ubuntu-toolchain
[01:42] <fabbione> jbailey_: yo dude
[01:42] <jbailey_> yoyosup?
[01:42] <fabbione> jbailey_: amd64 is borked.. we need to fix it asap
[01:43] <fabbione> did you get that bug about ld.so assertion something?
[01:43] <jbailey_> borkage caused how?
[01:43] <jbailey_> doko mentioned it in two apps that had been recompiled with the new gcc 4.0.1, but I haven't looked for anything.
=== ..[topic/#ubuntu-toolchain:jbailey_] : GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: i386 biarch, C++ ABI change: completed in main, some universe work left
[01:44] <fabbione> see this http://people.ubuntu.com/~lamont/buildLogs/o/ocfs2-tools/0.99.15-0ubuntu2/
[01:44] <fabbione> check the amd64 FTBFS
[01:44] <fabbione> i can reproduce that problem constantly just compiling the kernel on concordia
[01:45] <fabbione> Setting up python2.4 (2.4.1-2ubuntu3) ...
[01:45] <fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._
[01:45] <fabbione> dl_rtld_map.l_libname' failed!
[01:45] <fabbione> on concordia for me it happens at build time
[01:45] <jbailey_> When using python, probably.
[01:46] <fabbione> i don't use python to build the kernel dude :)
[01:46] <jbailey_> But..  But..  This is Ubuntu!
[01:46] <jbailey_> PYTHON MUST OOZE FROM YOUR PORES!
[01:46] <jbailey_> er.
[01:46] <jbailey_> anyhow
[01:47] <fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
[01:47] <fabbione> there.. building the kernel :)
[01:47] <jbailey_> I'll see if I can figure it out on Concordia.  I suspect I'll block very quickly on needing to instll debug packages.
[01:47] <jbailey_> fabbione: I need the line before that from the log, dude. =)  What triggers it?
[01:47] <daniels> didn't esr's freakshow config system (CML2?) use Python?
[01:47] <jbailey_> Running python is a sucky test case.
[01:48] <fabbione> jbailey_: just try to build the source that's in breezy with KBUILD_VERBOSE=1 in the environment
[01:48] <fabbione> breezy chroot on concordia has all you need
[01:48] <fabbione> i need to run away soon....
[01:49] <jbailey_> Which source package exactly are you using to make sure I get this right?
[01:49] <fabbione> linux-source-2.6.12
[01:49] <jbailey_> Tx.
[01:50] <fabbione> you can grab it from my home on concordia
[01:50] <fabbione> so you are 100% sure to use the same source as i am developing
[01:51] <jbailey_> Building..  Does it fail quickly?
[01:51] <jbailey_> debuild -B -eKBUILD_VERBOSE=1
[01:52] <fabbione> jbailey_: yes. pretty quickly
[01:52] <jbailey_> Cool.  i'll grab a bowl of cereal and check on it while I eat, then.
[01:52] <fabbione> jbailey_: concordia will be faster :)
[01:54] <jbailey_> Not so far...
[01:54] <fabbione> because you don't use CONCURRENCY_LEVEL=300 to arrive to the point of failure
[01:54] <fabbione> and switch it back to 1 to check the real error :)
[01:55] <jbailey_> Ahahah.
[01:55] <jbailey_> The glibc build just uses -J$(NCPUS)
[01:56] <fabbione> i do it only on the buildd...
[01:56] <fabbione> you know.. it's not nice to kill people's pc
[01:56] <fabbione> normal pc i mean ;)
[01:56] <jbailey_> If they have a normal PC, that's -j1 anyway.
[01:56] <jbailey_> Or you mean yours.
[01:56] <fabbione> jbailey: i do NCPUS * 2 on the buildd's
[01:57] <jbailey_> Do you actualy find a win above NCPUS*2 + 1 ?
[01:57] <fabbione>  yes
[01:57] <jbailey_> Huh, interesting.
[01:57] <fabbione> but that's because of ccache
[01:57] <jbailey_> With glibc that seemed to be about the point where the disk was going mad.
[01:57] <jbailey_> Oh.
[01:57] <fabbione> if the machine has a lot of RAM and good disk I/O
[01:57] <fabbione> the -j200 i run, it's not CPU intensive at all
[01:57] <fabbione> it's question of grabbinb a file from the disk
[01:57] <fabbione> so yes.. i gain and a lot
[01:58] <fabbione> if you don't have a fresh ccache.. you lose
[01:58] <fabbione> but i do in 99% of the cases on the porting boxen
[01:58] <jbailey_> And lose horribly, I suspect.
[01:58] <fabbione> boxes
[01:58] <fabbione> well not terribly, but you slow down.. too much switching
[01:59] <fabbione> specially in the first flavour when the code is not even in cache
[01:59] <fabbione> the second flavour is like building from a ramdisk
[01:59] <fabbione> so it still gain a bit....
[01:59] <fabbione> bah one day i will time all these things :)
[01:59] <fabbione> i need to go and get ready
[02:00] <fabbione> cya either later or tomorrow
[02:00] <jbailey_> I was more thinking gcc eating all your ram at that point. =)
[02:00] <jbailey_> Cool, See you Fabio.
[02:01] <jbailey_> Think good thoughts at me, I'm going to try and get LVM working for initramfs today.  I want you to be able to enable it tomorrow night. =)
[02:01] <fabbione> jbailey: if you can scratch the box and install breezy, it's damn simple :)
[02:01] <fabbione> we just added partman-auto-lvm to the default d-i path
[02:02] <fabbione> that means you hit: "Destroy this device and make it LVM"
[02:02] <fabbione> and it will work
[02:02] <fabbione> but only on i386 and amd64
[02:02] <jbailey_> Not ppc?
[02:02] <fabbione> apparently ppc doesn't have lvm
[02:02] <jbailey_> That would explain the trouble I was having before./
[02:02] <fabbione> not in parted
[02:02] <jbailey_> All my experiments with with ppc.  You can't do raid in the installer there either (in Hoary)
[02:02] <fabbione> oh .. it works.. our d-i just doesn't support it.. yet
[02:02] <jbailey_> 'kay.  I'll frag the laptop then.
[02:02] <jbailey_> Umm.
[02:03] <jbailey_> I just realisaed that this build isn't giving me the gcc command line.
[02:03] <jbailey_> How will I get the info to reproduce the failure when it eventually happens?
[02:03] <fabbione> jbailey: export KBUILD_VERBOSE=1
[02:03] <fabbione> be sure to use export :)
[02:03] <jbailey_> the -e on debuild is suppposed to do that.
[02:04] <fabbione> and do you trust that or me?
[02:04] <fabbione> ;)
[02:04] <fabbione> good luck with lvm
[02:04] <fabbione> but it's damn easy :)
[02:05] <fabbione> later
=== fabbione &
[02:05] <jbailey_> Hmm, done both, I still don't see details.
[02:10] <jbailey_> Oh, the -e needs come to come *before* the -B on the command line.  How *obvious*
[02:10] <jbailey_> sigh.
=== jbailey_ lets this run for a whie
=== bonny [~bonny@ALamentin-103-1-12-237.w81-248.abo.wanadoo.fr]  has joined #ubuntu-toolchain
[02:51] <jbailey_> fabbione: I don't get that error.  I get a segfault on 'mv'
[02:51] <jbailey_> *sigh*
[02:53] <jbailey_> And it appears to have fragged the file in the process. =(
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
[05:06] <lamont> hppa is down to 200 packages in main that it needs to build
[05:07] <fabbione> hey lamont
[05:07] <fabbione> nice
[05:13] <fabbione> jbailey: around?
[05:13] <jbailey> lamont: Nice!  Is the installer the only thing blocking hppa adoption then?
[05:13] <jbailey> fabbione: I'm not getting the same problem during the kernel build.  Just lots of segfaults on things like 'mv' and 'rm' =(  But irreproducable when I do the commands by hand.
[05:14] <fabbione> weird!
[05:14] <fabbione> jbailey: can you try enabling ccache?
[05:14] <fabbione> i wonder if that could be the reason
[05:14] <jbailey> fabbione: Sure.  Is there any way to share the ccache with you?
[05:14] <fabbione> ccache is installed and configured both in my concordia env and the buildd's
[05:14] <fabbione> jbailey: nope.. given that's in my home..
[05:14] <fabbione> just use a fresh one
[05:14] <jbailey> Feh.
[05:15] <jbailey> a'ight then. =)
[05:15] <fabbione> if it is an overabuse of mv and rm, ccache might be the culprit
[05:15] <fabbione> since it does a lot of that stuff
[05:15] <jbailey> Well, but I'm not using ccache, and I'm getting segfaults in that.
[05:15] <jbailey> Spurious segfaults bad.
[05:15] <jbailey> Makes me think of flakey ram.
[05:15] <fabbione> nah
[05:16] <fabbione> it can't be on all the amd64 machines
[05:16] <fabbione> concordia and one of the buildd at least show the same problem
[05:16] <jbailey> I haven't seen other reports of segfaults in coreutils bits.
[05:16] <jbailey> I mean, how complicated is the mv command internally?
[05:16] <fabbione> open, cp, unlink?
[05:17] <jbailey> I thought mv was an atomic operation.  I think it's just a syscall.
[05:17] <jbailey> Plus the usual GNU fluff around it, but there isn't exactly alot of room for a segfault in there...
[05:17] <fabbione> no, i don't think so
[05:18] <jbailey> Hmm.  Do I have to do anything to make sure that my ccache in my amd64 dchroot doesn't chew on my ccache in my i386 dchroot?
[05:18] <fabbione> jbailey: chance the CCACHEPATH?
[05:19] <fabbione> CCACHE_DIR=/usr/src/.ccache
[05:19] <fabbione> change that one in your env
[05:19] <jbailey> Ugh, so it doesn't do arch detection automatically.  Ah well.
[05:19] <fabbione> well i did always share my ccache between amd64 and i386
[05:19] <fabbione> there is no way the 2 will overlap for a mistake
[05:19] <jbailey> With no conflicts?
[05:20] <fabbione> the hash towards the final ccache file will make it impossible
[05:20] <jbailey> Because of the compiler defines?
[05:20] <fabbione> but well.. 
[05:20] <fabbione> exactly
[05:20] <fabbione> compilers define, different gcc version
[05:21] <fabbione> afaik ccache uses gcc --version to detect gcc changes
[05:21] <fabbione> so it's like using 2 different gcc's
=== jbailey waves the voodoo wand at ccache
[05:22] <lamont> jbailey: uh, no... all 3 gcc compilers are part of that list.. :-)
[05:23] <jbailey> lamont: How is ia64?
[05:24] <lamont> jbailey: building, but not very install-happy
=== lamont needs to do more testing this week
[05:26] <jbailey> I should be bringing my ia64 within arms reach soonish.
[05:26] <jbailey> Hopefully I can start helping with that by the end of the month.
[05:31] <jbailey> 'kay ccache wired up and working, restarting build.
[05:33] <lamont> thanks
=== Seveaz [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
=== doko [~doko@a130-233-5-210.debconf5.hut.fi]  has joined #ubuntu-toolchain
=== lamont [~lamont@15.238.5.49]  has joined #ubuntu-toolchain
=== lamont [~lamont@15.238.5.49]  has joined #ubuntu-toolchain
=== Seveaz [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain