[12:20] <lamont> glibc patch inbound from patofiero
[12:20] <lamont> jbailey: debian and ubuntu will want it.. :-(
[12:52] <lamont> fabbione: fwiw, this appears to be "the librsvg2" bug that I've been hitting
[01:19] <jbailey> lamont: Sounds lovely.
[01:20] <jbailey> Ooo, good timing for being back at the terminal. 
[01:20] <jbailey> debhelper pass for gcc-4.0
[01:20] <jbailey> Perhaps I got the biarch stuff right on the first pass for it. =)
[01:22] <jbailey> Or not.  *sigh*  No lib64gcc1.
[01:25] <lamont> jbailey: patch is trivial: comment out glibc234-hppa-remove-mallocdef
[01:25] <lamont> test builds running now
[01:25] <jbailey> lamont: Thanks for taking care of it.
[01:25] <lamont> well, patofiero is doing a debian build, and I'm doing a breezy build
[01:25] <lamont> you want I should upload once I finish testing?
[01:26] <lamont> patch only modifies linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h, so I think the other architectures are safe. :-)
[01:27] <jbailey> No, please don't.
[01:27] <jbailey> I'm in the middle of working up the biarch toolchain for amd64.
[01:27] <jbailey> My glibc is basically set at this point, so if I can avoid rerunning it, I'd rather.
[01:27] <jbailey> I just need to do gcc-4.0 and then I can hand it to you.
[01:31] <jbailey> YAR, found the spot that I missed.
[01:32] <jbailey> I am in a maze of twisty debian/rules files, all alike.
[01:36] <jbailey> Will run the testsuite with -m64: yes
[01:36] <jbailey> Much better.
[01:36] <jbailey> Back in another 3 hours, I guess.
[01:44] <lamont> jbailey: ah, ok.  your soon-to-be-biarch upload will comment out the patch I loathe as well? (assuming that my testing says so)?
=== lamont will be back in ~ 4.5 hours or so, give or take
[02:04] <jbailey> lamont: I guess it can easily enough.
[02:04] <jbailey> I had hoped for a no-op upload, but if it's important.
[02:05] <jbailey> I have to repeat this process for amd64/i386 biarich right after, too
=== martin [~freenode@220-253-54-93.VIC.netspace.net.au]  has left #ubuntu-toolchain [] 
=== ajmitch_ [~ajmitch@port163-24.ubs.maxnet.co.nz]  has joined #ubuntu-toolchain
[04:56] <jbailey> Hmph
[04:56] <jbailey> gcc-4.0 doesn't b uild in 64 bit mode.  Too drunk to fix it now:
[04:57] <jbailey> /tmp/gcc-4.0/gcc-4.0-4.0.1/build/gcc/xgcc -B/tmp/gcc-4.0/gcc-4.0-4.0.1/build/gcc/ -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../src/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -m64 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c ../../../../src/libmudflap/mf-runtime.
[04:57] <jbailey> c  -fPIC -DPIC -o .libs/mf-runtime.o
[04:57] <jbailey> ../../../../src/libmudflap/mf-runtime.c:167: error: conflicting types for '__mf_lc_mask'
[04:57] <jbailey> ../../../../src/libmudflap/mf-runtime.h:19: error: previous declaration of '__mf_lc_mask' was here
[04:57] <jbailey> I'll try in the morning. =)
[05:17] <lamont> jbailey: the bug in question is blocking a whole bunch of packages
[05:17] <lamont> in both debian and ubuntu
[05:17] <lamont> and wedges the buildd outside of timeouts when it trips...
=== lamont tests the fix
[05:20] <lamont> jbailey: dropping that patch fixes the issue.  could you upload it, and also push through getting the same change in debian?  Want a grave bug to use?
[05:22] <lamont> meanwhile, I have this crontab entry that I really don't like....
[05:22] <lamont> 0 */3 * * * sudo killall -9 gdk-pixbuf-query-loaders >/dev/null 2>&1
=== elmo [~james@83-216-156-21.jamest747.adsl.metronet.co.uk]  has joined #ubuntu-toolchain
=== elmo [~james@83-216-156-21.jamest747.adsl.metronet.co.uk]  has joined #ubuntu-toolchain
=== doko [~doko___@dsl-084-059-068-056.arcor-ip.net]  has joined #ubuntu-toolchain
=== fabbione would love to get a fixed binutils for sparc soon
=== fabbione wonders how complicate would be to package the crosstools
[08:52] <fabbione> the amount of packages that come out of that are impressive..
[08:52] <fabbione> but that would be great fun :)
[09:04] <doko> jbailey: just disable the 64bit mudflap at the moment, we don't have it packaged anyway
[10:34] <doko> jbailey:
[10:34] <doko> @@ -93,7 +93,7 @@
[10:34] <doko>                 > debian/$(p_l64gcc).substvars
[10:34] <doko>  else
[10:34] <doko>    ifeq ($(DEB_TARGET_ARCH),i386)
[10:34] <doko> -       echo 'shlibs:Depends=amd64-libs (>= 0.1)' \
[10:34] <doko> +       echo 'shlibs:Depends=libc6-amd64-dev (>= 2.3.5-1ubuntu8)' \
[10:34] <doko>                 > debian/$(p_l64gcc).substvars
[10:34] <doko>    else
[10:34] <doko>      ifeq ($(DEB_TARGET_ARCH),powerpc)
[10:35] <doko> should be libc6-amd64, not libc6-amd64-dev. the version isn't really needed
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
[11:38] <doko> -- Jeff Bailey <doko@ubuntu.com>  Sat,  6 Aug 2005 16:06:44 +0000
[11:39] <doko> split personality ...
[02:28] <doko> Unpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu4_i386.deb) ...
[02:28] <doko> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[02:28] <doko> E: Sub-process /usr/bin/dpkg received a segmentation fault.
[02:28] <doko> apt-get failed.
[02:28] <doko> Package installation failed
[02:28] <doko> lamont, infinity: ^^^ during the openoffice.org build on i386
[04:44] <jbailey> doko: Yeah, I saw the email address, apparently dch coudoln't figure mine out in the chroot so assumed the same one as before. =)
[04:45] <jbailey> Thanks for the other two hints.
[04:45] <doko> jbailey: I sent you an email about the merged stuff
[04:45] <jbailey> lamont: Will regen with that patch.
[04:46] <jbailey> doko: Cool, thanks.
[04:46] <jbailey> I've just crawled out of bed, so I'm moving a bigt slowly.
[04:54] <jbailey> doko: Cool, so I'll grab the gcc-3.4 from chinstrap then.
[04:55] <doko> jbailey: yes please. but don't grab the new bugs introduced in the package ;)
[04:56] <jbailey> Err>
[04:56] <jbailey> I'm still waking up and am a bit hung over.  What do I need to do? =)
[04:59] <doko> jbailey: just grab the diff.gz.
[05:00] <doko> the diff that you sent me didn't include the amd64 biarch support (only the i386)
=== desrt [~desrt@dhcp-0-20-af-d2-7c-3.cpe.mountaincable.net]  has joined #ubuntu-toolchain
[08:45] <jbailey> doko: Right.  So the amd64 will ftbfs until I do the matching changes there.
[08:45] <jbailey> That's no big deal, though
[09:10] <lamont> jbailey: I'm unleashing hppa's buildd with a glibc that you will hopefully supersede soon
[09:12] <doko> lamont: pleasse could you have a look at the openoffice.org build failure on i386?
[09:15] <lamont> doko: thanks
[09:16] <lamont> fixed, 3 packages given back
[09:20] <lamont> doko: you looked at isdnutils recently?
[09:20] <lamont> oh, nm
[09:21] <jbailey> lamont: Ubuntu?  Is there a new glibc?
[09:21] <lamont> jbailey: you're going to upload a new glibc to ubuntu shortly, yes?
[09:22] <lamont> so I dropped my local build into place (...ubuntu7hppa1) with confidence that ubuntu8 would arrive sometime in the next day or so... right?
[09:22] <lamont> and yes, ubunut
[09:22] <lamont> debian is still playing roulette
[09:23] <lamont> and would you like me to file a bug against glibc/debian?
[09:32] <jbailey> Please.
[09:33] <jbailey> Yes, I have ubuntu8 ready, I'll drop that patch and respin it when I do my final verify builds.
[09:33] <jbailey> I'm going to get back to doing the gcc-4.0 builds now for i386/amd64
[09:35] <jbailey> Hmm.  I wonder if elmo would consider nfs mounting chinstrap home dirs onto all the other directories.
[09:35] <jbailey> It's such a pain in the ass to move files between machines.
[09:39] <doko> lamont: it's still the empty xutils
[09:49] <jbailey> doko: Hmm.  What's the best way to disable 64 bit mudflap only?  It doesn't look like you have it differentiated for 32 and 64 bit passes at all.
[09:49] <jbailey> And I don't see how to set with_madflap := no for only onepass.
[09:49] <jbailey> Oh.
[09:49] <jbailey> Duh
[09:50] <jbailey> In rules.d/binary-libmudflap.mk you mention with_lib64mudflap
[09:50] <doko> debian/patches/i386-config-ml.dpatch: remove the mudflap line
[09:52] <doko> or better: make a new patch i386-config-ml-nomf, we need the current one for debian
[09:54] <jbailey> Ah, doing with_lib64mudflap := no, doesn't add --diable-mudflap 
[09:54] <jbailey> I had hoped it would.
[09:55] <doko> yes, because this disables the normal build as well
[09:55] <jbailey> Right.
[09:56] <jbailey> Becase it's actual multilibs, not two build passes.
[09:56] <jbailey> If mudflap building in 64 bit mode on Debian right now then?
[09:57] <doko> it does build, for getting saner testresults. it's not yet packaged
[09:57] <jbailey> Right, but I'm curious then why it's not even building for me.
=== jbailey actually looks at the error.
[09:58] <jbailey> I want to make sure that it's not some side effect of something I did wrong elsewher ein the biarch setup.
[10:00] <doko> yep, not all the runtime libraries are setup to be correctly built as biarch, the C++ includes are one case ...
[10:05] <jbailey> So should I make a complete copy of that config and only included it for Ubuntu?
[10:05] <jbailey> Looking at the code, I don't see how this builds on Debian.
[10:05] <jbailey> It looks like I could possibly just take this line out of the i386-config-ml patch:
[10:05] <jbailey> +                       *"libmudflap" ) multidirs="${multidirs} ${x}" ;;
[10:08] <doko> yes, correct
[10:09] <doko> it builds on Debian (at least it did with glibc-2.3.2 and amd64-libs-dev)
[10:10] <jbailey> Hmm
[10:10] <jbailey> The header file that's being complained about is wrapped if #ifndef _MUDFLAP, and I wonder if the newer glibc causes that to not be defined.
[10:10] <jbailey> But that looks sufficiently minor.
[10:10] <jbailey> Or might be some side effect of building this with gcc-3.4
[10:21] <doko> probably the latter, why don't you use the just built compiler? build/gcc/xgcc -Bbuild/gcc/ ?
[10:21] <jbailey> I'd have assumed that it would have
[10:22] <jbailey> But I know that occasioanlly things get confused.  I have /usr/bin/gcc symlinked to gcc-3.4 right now until I get this biarch gcc-4 built.
[10:22] <jbailey> I'll try it without this patch once I have a working version.
[10:22] <doko> or: make -C build maybe-all-target-libmudflap, but remove the libmudflap directory first
[11:12] <jbailey> lamont: BTW, did you test removing that patch on the other archs?
[11:12] <jbailey> Oh, I see.  it's hppa only.
[11:12] <jbailey> Easy enough then. =)