#ubuntu-toolchain 2005-08-08
<lamont-away> i386 0.908390
<lamont-away> powerpc 0.902284
<lamont-away> amd64 0.895863
<lamont-away> ia64 0.891580
<lamont-away> hppa 0.758311
<lamont-away> sparc 0.753473
<lamont-away> hppa pulls ahead!! /me does a happy dance while looking over his shoulder to see if fabbione is looking
<lamont-away> OTOH, at <91%, I think i386 is about as low as it's ever been.
<lamont-away> hoary looks like this:
<lamont-away> i386 0.970231
<lamont-away> powerpc 0.960853
<lamont-away> amd64 0.954392
<lamont-away> ia64 0.953001
<fabbione> ahah
<lamont-away> 5% of 6400 packages is "quite a few"
<fabbione> lucky that i don't have much time to look at sparc right now :)
<lamont-away> LOL
<fabbione> i would love to get my second buildd up again
<fabbione> btw did you manage to bootstrap ghc6?
<lamont-away> ghc6 needs gcc-4.0 love
* lamont-away is currently running on one buildd as well
<lamont-away> well, hppa is. :-)
<fabbione> i think i can unleash the other 600pkg i am stalling with C++
<fabbione> universe has been given-back several times by now
<fabbione> and i basically get only FTBFS or missing B-d
* lamont-away needs to figure out WTH librsvg2-common hangs gdk-pixbuf-query-loaders, then he'll be able to actually build some significant chunks of gnome (e.g, eel2)
<fabbione> oh i had that problem for sparc a long long time ago
<fabbione> but we fixed it somehow
<lamont-away> if you remember how, I'd love to know.
<lamont-away> but really to bed
<fabbione> god night
<fabbione> good even
<elmo> lamont/infinity: amd64 isn't doing daily d-i
<lamont> grumble
* lamont checks
<doko> lamont, infinity: please requeue imagemagick, now that libexif12 is in main
<lamont> doko: was it in universe before?
<lamont> nm
<lamont> kicked
<doko> <doko> two brown paper bugs ... please resync gcc-defaults-1.27 from unstable, which FTBFS on ia64 and hppa
<doko> <doko> the other is java-gcj-compat from incoming (1.0.30-4)
<doko> lamont: ^^^ I already did ask elmo for a sync
<doko> with these, gcc-4.0 is the default on hppa
<lamont> doko: ok
* lamont wonders what dchroot does on SIGHUP
#ubuntu-toolchain 2005-08-09
<Seveas> hmm
<Seveas> dchroot must have done something bad
#ubuntu-toolchain 2005-08-10
<jbailey> doko: ping?
<doko> jbailey: pong
<jbailey> doko: I'm having a bitch of a time tracing down this last error from ld, hoping you can suggest something.
<jbailey> When I install the libc6{-dev}-amd64 packages, ld tells me:
<jbailey> /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, not found (try using -rpath or -rpath-link)
<jbailey> The NEEDED section doesn't list a path in libc.so.6, so the implicit -L/lib../lib64 that collect2 hands over ought to be enough, I think.
<jbailey> If I make a symlink in /lib to /lib64/ld-linux-x86-64.so.2, it compiles, and I can remove it after, so there's no runtime requirement.
<jbailey> Just that for some reason ld beleives that there's a link time requirement.
<jbailey> If I add an -rpath line to it, it works fine, but I think that it shouldn't be needed.
<jbailey> (The warning is follow by some symbol errors which are in the ld-...so.2 - so it's not just randomly warning me)
<doko> hmm, look at the i386-biarch patch in gcc-3.4. LINK_SPEC wants /lib64/libc.so.6
<jbailey> Which is right.
<jbailey> is it possible to get ld to dump out a list of what it thinks are the available libraries and howit resolved them?
<jbailey> It seems almost certainly like a glibc problem, the same collect2 line done with amd64-libs works fine, but readelf -a looks basically the same between the two.
<doko> hmm, not that I know of
<doko> you see this with gcc-3.4 or gcc-4.0 ?
<jbailey> -3.4
<jbailey> So far I'm onyl working with that until I get the glibc built.
<doko> and does the link step work with 4.0 (if you're doing only this one with 4.0)?
<jbailey> Dunno.  I'll dig up a biarch gcc-4.0 to try that with.
<jbailey> glibc doesn't build with gcc-4.0, so I hadn't been looking at that at all.
<doko> just compared the biarch patches. 4.0 is missing the LINK_SPEC chunk
<jbailey> Oh, hmm.
<jbailey> YAR
<jbailey> I wish I smoked so that I could stomp off and have one.
<jbailey> It seems that biarch amd64 wants /lib64 and /usr/lib64 added to ld.so.conf
<jbailey> doko: So my glibc is fine.  I just need to either put this hackery into ld.so.conf, I guess. =(
<jbailey> Or fix it properly in the linker, I guess.
<doko> jbailey: How is this solved for amd64 native?
<doko> or isn't this an issue, because lib is a symlink to lib64?
<jbailey> amd64 native has hackery in glibc to mke this all just work.
<jbailey> My current build has the hackery in for i386 too.
<jbailey> amd64 will need additional hackery to deal with /lib32 correctly.
<jbailey> (but it's all in the same .h file in glibc)
<doko> oh, fine.
<elmo> fuck's sake
<elmo> does anyone know how CONFIG_MAC gets defined?
<jbailey> elmo: Context?
<elmo> powerpc kernel builds
<elmo> it's not mentioned in .config, but I'm getting some compile errors with breezy kernel and a custom config
<jbailey> elmo: Try #ubuntu-kernel, better audience there.
<elmo> meh
<elmo> i'm about ubuntu'ed out of channels, never mind
<jbailey> I'm thinking specifically zul, who does alot of kernel stuff with Fabio
<fabbione> hey elmo
<fabbione> elmo: iirc CONFIG_MAC is defined only on PPC32..
<fabbione> if you need, i can check but arch/ppc/Kconfig (grep for MAC) is a good place to start
<doko_> fabbione: gettext on sparc: please look at the config.log file to see, why the jar test fails.
<fabbione> doko_: thanks i will :)
<doko_> fabbione: do you have a sparc live CD, either hoary or breezy?
* lamont digs
* lamont undigs
#ubuntu-toolchain 2005-08-11
<jbailey> BOOYAH!
<jbailey> doko: One line patch to binutils solved my problem.  No more ld.so.conf hackery required. =)
<fabbione> doko: no CD's yet... 
<fabbione> doko: the net install should work as well as creating chroots
* lamont-away wonders what fabbione's sparc-solution was to librsvg2 & gdk-pixbuf-query-loaders
<lamont-away> i386 91.13% 5918 of 6494
<lamont-away> powerpc 90.50% 5714 of 6314
<lamont-away> amd64 89.83% 5633 of 6271
<lamont-away> ia64 89.51% 5590 of 6245
<lamont-away> hppa 76.41% 4765 of 6236
<lamont-away> sparc 74.86% 4695 of 6272
<fabbione> ehhehe
<fabbione> ya know
<fabbione> binutils is doomed on sparc
<lamont> fabbione: does that mean you don't remember, or you won't tell me?
<fabbione> that hppa is faster? ;)
<lamont> fabbione: * lamont-away wonders what fabbione's sparc-solution was to librsvg2 & gdk-pixbuf-query-loaders
<fabbione> no i don't remember :(
<lamont> sigh
<fabbione> it was something to do with a missing directory
<lamont> that means work for me.
<lamont> during the librsvg2 build, or during install?
* fabbione tries to remember...
<fabbione> installing the B-D
<fabbione> no .. sorry
<fabbione> building..
<fabbione> i think..
<lamont> ok.  I'll stare at that some
<fabbione> that gdk- blabla was searching something in a directory that's not there..
<fabbione> or something like that
<fabbione> and it was segfaulting for that reason
<fabbione> i am sure i told seb
<lamont> ah, my case it seems to be spinning on something
<fabbione> try to strace a manual call
<fabbione> being in holidays and not being able to sleep is a PAIN
<lamont> yeah
<fabbione> lamont: do you know if all the main arches did complete the c++ transition for universe?
<lamont> dunno - infinity was tracking that, I thought
<lamont> hppa has it easy - I just turned off the hoary repository
<fabbione> yeah i know that :)
<fabbione> i am checking the sparc status, but some package versions don't match
<fabbione> and either they forgot to transition them
<fabbione> or there is no need to transition
<lamont> ew
* lamont points at doko/infiinity
* fabbione checks -changes
<fabbione> hmm it's clearly not completed...
<fabbione> lamont: there is a bunch of libs, that either didn't do the transition.. or they don't need it..
<fabbione> problem is for you if you did actually build these libs
<lamont> neato
* lamont sleeps
<fabbione> night lamont
* jbailey sings away as he watches gcc-3.4 build.
<jbailey> make[2] : Entering directory `/tmp/gcc-3.4/gcc-3.4-3.4.4/build/gcc'
<jbailey> make[2] : *** No rule to make target `gnatlib-shared'.  Stop.
<jbailey> Hmm
<fabbione> sounds like the moon ray hitting the console cable during an eclipse :)
<jbailey> *lol*
<jbailey> Actually, I don't have the right version of gnat installed.
<jbailey> But morgue.ubuntu.com seems to be broken.
<jbailey> All the directories are empty.
<fabbione> i told elmo a while ago about morgue
<fabbione> i have the nasty feeling that we lost it
<jbailey> That would be sad.
<jbailey> It'll make doing this biarch toolchain quite a bit harder.
<jbailey>  gnatgcc -c conftest.adb
<jbailey> gnatgcc: installation problem, cannot exec `gnat1': No such file or directory
<jbailey> Yup, that'd be my problem.
<jbailey> *sigh*
<doko_> which gnat package is installed?
<doko> jabiley: ^^^
<doko> jbailey: ^^^
<jbailey> doko: I had the current gcc-3.4 one and it gave that error.  I managed to downgrade to the one at http://morgue.ubuntu.com/2005-04-03/ and it seems to work.
<jbailey> So I'm starting a new build.  I'll let you know in a couple of hours.
<jbailey> (Seems to work with a simple ada test now)
<jbailey> Ooo!  It's already made the ada directory
<jbailey> Good, if it's going to fail, it will do so in a different place next time. =)
* jbailey goes out to enjoy the sun.
<jbailey> doko: BTW, I've posted the new diff at http://www.raspberryginger.com/jbailey/gcc-3.4_3.4.4-6ubuntu3.diff.gz
<jbailey> Since I have various bits of gcc and amd64-libs and such half installed, apt won't work well enough for me to install interdiff into the chroot and Angie's waiting for me.
<jbailey> But if you have time for a review that would be lovely, otherwise I'm pretty certain that I got all the bits that I need.
<doko> I'll have a look, but which gnat package is installed? gnat-3.4 ?
<jbailey> ii  gnat-3.4       3.4.3-9ubuntu3 The GNU Ada compiler
<jbailey> (which works)(
<doko> ok
<jbailey> angie is tapping her foot at me, gotta run. =)
<doko> run!
<jbailey> I'm back.  It looks like it's runing make check fine.
<jbailey>                 === gpc Summary ===
<jbailey> # of tests                4946
<jbailey> # of expected passes      4939
<jbailey> # of unexpected failures  6
<jbailey> # of unsupported tests    1
<jbailey> Should I worry about the FAILs at all?
<jbailey> (Still mostly afk, just pasting things here occasionally)
<jbailey> Ooo Ooo Ooo debhelper stuff!
<jbailey> Yay!  I have a prompt!
<jbailey> Woot, it works.
<jbailey> Hmm.
<jbailey> Now I need to do gcc-4 I guess, to get my lib64gcc1
<doko> jbailey: yes, that one should be easy
#ubuntu-toolchain 2005-08-12
<lamont> glibc patch inbound from patofiero
<lamont> jbailey: debian and ubuntu will want it.. :-(
<lamont> fabbione: fwiw, this appears to be "the librsvg2" bug that I've been hitting
<jbailey> lamont: Sounds lovely.
<jbailey> Ooo, good timing for being back at the terminal. 
<jbailey> debhelper pass for gcc-4.0
<jbailey> Perhaps I got the biarch stuff right on the first pass for it. =)
<jbailey> Or not.  *sigh*  No lib64gcc1.
<lamont> jbailey: patch is trivial: comment out glibc234-hppa-remove-mallocdef
<lamont> test builds running now
<jbailey> lamont: Thanks for taking care of it.
<lamont> well, patofiero is doing a debian build, and I'm doing a breezy build
<lamont> you want I should upload once I finish testing?
<lamont> patch only modifies linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h, so I think the other architectures are safe. :-)
<jbailey> No, please don't.
<jbailey> I'm in the middle of working up the biarch toolchain for amd64.
<jbailey> My glibc is basically set at this point, so if I can avoid rerunning it, I'd rather.
<jbailey> I just need to do gcc-4.0 and then I can hand it to you.
<jbailey> YAR, found the spot that I missed.
<jbailey> I am in a maze of twisty debian/rules files, all alike.
<jbailey> Will run the testsuite with -m64: yes
<jbailey> Much better.
<jbailey> Back in another 3 hours, I guess.
<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
<jbailey> lamont: I guess it can easily enough.
<jbailey> I had hoped for a no-op upload, but if it's important.
<jbailey> I have to repeat this process for amd64/i386 biarich right after, too
<jbailey> Hmph
<jbailey> gcc-4.0 doesn't b uild in 64 bit mode.  Too drunk to fix it now:
<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.
<jbailey> c  -fPIC -DPIC -o .libs/mf-runtime.o
<jbailey> ../../../../src/libmudflap/mf-runtime.c:167: error: conflicting types for '__mf_lc_mask'
<jbailey> ../../../../src/libmudflap/mf-runtime.h:19: error: previous declaration of '__mf_lc_mask' was here
<jbailey> I'll try in the morning. =)
<lamont> jbailey: the bug in question is blocking a whole bunch of packages
<lamont> in both debian and ubuntu
<lamont> and wedges the buildd outside of timeouts when it trips...
* lamont tests the fix
<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?
<lamont> meanwhile, I have this crontab entry that I really don't like....
<lamont> 0 */3 * * * sudo killall -9 gdk-pixbuf-query-loaders >/dev/null 2>&1
* fabbione would love to get a fixed binutils for sparc soon
* fabbione wonders how complicate would be to package the crosstools
<fabbione> the amount of packages that come out of that are impressive..
<fabbione> but that would be great fun :)
<doko> jbailey: just disable the 64bit mudflap at the moment, we don't have it packaged anyway
<doko> jbailey:
<doko> @@ -93,7 +93,7 @@
<doko>                 > debian/$(p_l64gcc).substvars
<doko>  else
<doko>    ifeq ($(DEB_TARGET_ARCH),i386)
<doko> -       echo 'shlibs:Depends=amd64-libs (>= 0.1)' \
<doko> +       echo 'shlibs:Depends=libc6-amd64-dev (>= 2.3.5-1ubuntu8)' \
<doko>                 > debian/$(p_l64gcc).substvars
<doko>    else
<doko>      ifeq ($(DEB_TARGET_ARCH),powerpc)
<doko> should be libc6-amd64, not libc6-amd64-dev. the version isn't really needed
<doko> -- Jeff Bailey <doko@ubuntu.com>  Sat,  6 Aug 2005 16:06:44 +0000
<doko> split personality ...
<doko> Unpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu4_i386.deb) ...
<doko> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<doko> E: Sub-process /usr/bin/dpkg received a segmentation fault.
<doko> apt-get failed.
<doko> Package installation failed
<doko> lamont, infinity: ^^^ during the openoffice.org build on i386
<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. =)
<jbailey> Thanks for the other two hints.
<doko> jbailey: I sent you an email about the merged stuff
<jbailey> lamont: Will regen with that patch.
<jbailey> doko: Cool, thanks.
<jbailey> I've just crawled out of bed, so I'm moving a bigt slowly.
<jbailey> doko: Cool, so I'll grab the gcc-3.4 from chinstrap then.
<doko> jbailey: yes please. but don't grab the new bugs introduced in the package ;)
<jbailey> Err>
<jbailey> I'm still waking up and am a bit hung over.  What do I need to do? =)
<doko> jbailey: just grab the diff.gz.
<doko> the diff that you sent me didn't include the amd64 biarch support (only the i386)
<jbailey> doko: Right.  So the amd64 will ftbfs until I do the matching changes there.
<jbailey> That's no big deal, though
<lamont> jbailey: I'm unleashing hppa's buildd with a glibc that you will hopefully supersede soon
<doko> lamont: pleasse could you have a look at the openoffice.org build failure on i386?
<lamont> doko: thanks
<lamont> fixed, 3 packages given back
<lamont> doko: you looked at isdnutils recently?
<lamont> oh, nm
<jbailey> lamont: Ubuntu?  Is there a new glibc?
<lamont> jbailey: you're going to upload a new glibc to ubuntu shortly, yes?
<lamont> so I dropped my local build into place (...ubuntu7hppa1) with confidence that ubuntu8 would arrive sometime in the next day or so... right?
<lamont> and yes, ubunut
<lamont> debian is still playing roulette
<lamont> and would you like me to file a bug against glibc/debian?
<jbailey> Please.
<jbailey> Yes, I have ubuntu8 ready, I'll drop that patch and respin it when I do my final verify builds.
<jbailey> I'm going to get back to doing the gcc-4.0 builds now for i386/amd64
<jbailey> Hmm.  I wonder if elmo would consider nfs mounting chinstrap home dirs onto all the other directories.
<jbailey> It's such a pain in the ass to move files between machines.
<doko> lamont: it's still the empty xutils
<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.
<jbailey> And I don't see how to set with_madflap := no for only onepass.
<jbailey> Oh.
<jbailey> Duh
<jbailey> In rules.d/binary-libmudflap.mk you mention with_lib64mudflap
<doko> debian/patches/i386-config-ml.dpatch: remove the mudflap line
<doko> or better: make a new patch i386-config-ml-nomf, we need the current one for debian
<jbailey> Ah, doing with_lib64mudflap := no, doesn't add --diable-mudflap 
<jbailey> I had hoped it would.
<doko> yes, because this disables the normal build as well
<jbailey> Right.
<jbailey> Becase it's actual multilibs, not two build passes.
<jbailey> If mudflap building in 64 bit mode on Debian right now then?
<doko> it does build, for getting saner testresults. it's not yet packaged
<jbailey> Right, but I'm curious then why it's not even building for me.
* jbailey actually looks at the error.
<jbailey> I want to make sure that it's not some side effect of something I did wrong elsewher ein the biarch setup.
<doko> yep, not all the runtime libraries are setup to be correctly built as biarch, the C++ includes are one case ...
<jbailey> So should I make a complete copy of that config and only included it for Ubuntu?
<jbailey> Looking at the code, I don't see how this builds on Debian.
<jbailey> It looks like I could possibly just take this line out of the i386-config-ml patch:
<jbailey> +                       *"libmudflap" ) multidirs="${multidirs} ${x}" ;;
<doko> yes, correct
<doko> it builds on Debian (at least it did with glibc-2.3.2 and amd64-libs-dev)
<jbailey> Hmm
<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.
<jbailey> But that looks sufficiently minor.
<jbailey> Or might be some side effect of building this with gcc-3.4
<doko> probably the latter, why don't you use the just built compiler? build/gcc/xgcc -Bbuild/gcc/ ?
<jbailey> I'd have assumed that it would have
<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.
<jbailey> I'll try it without this patch once I have a working version.
<doko> or: make -C build maybe-all-target-libmudflap, but remove the libmudflap directory first
<jbailey> lamont: BTW, did you test removing that patch on the other archs?
<jbailey> Oh, I see.  it's hppa only.
<jbailey> Easy enough then. =)
#ubuntu-toolchain 2005-08-13
<doko> lamont: the openoffice.org build did fail again on i386, same reason
<doko> same with openoffice.org2
<jbailey> Cool, it's into the testsuite this time, so disabling the mudflap thing was hopefully enough.
<doko> infinity: ^^^ I don't know what lamont did before requeing the OOo* builds, but it didn't help
<lamont> doko: I did a dpkg --configure on the annoyed package, and removed all the crap.
<lamont> doko: which is to say, there's a pretty b0rked package in there.
<infinity> lamont, doko : That dpkg segv is known, but some preliminary debgging has gotten knowhere, except "jee, looks like a horribly smashed stack, yay".
<infinity> I'm hoping that drastically rearranging the mesa packages in the next few days will "work around" the dpkg bug, but I won't hold my breath either.
<doko> it's just that during the past months OOo* packages only build on Mondays at new moon, when the tide is high and a new planet in our solar system is discovered :-(
* lamont thought that was normal for oo.o, figured it really just needed to be broken up into more managable pieces.
<lamont> :-)
<doko> as more as you try to depend on external build dependencies, as more it becomes broken. obviously we don't have a different understanding of "broken" ;)
<lamont> heh
<lamont> and hppa climbs to within 14% of #1. :-)
<lamont> aka #5 :-(
<jbailey> Hmm.  g++-4.0 -m64 tests appear to be sucking wind.
<jbailey> # of expected passes            215
<jbailey> # of unexpected failures        1710
<jbailey> # of unexpected successes       1
<jbailey> # of expected failures          5
<jbailey> # of unsupported tests          9
<jbailey> I'm curious about the unexpected success. =)
<lamont> that was testing to make sure something failed, maybe?
<jbailey> No, dear.
<lamont> hehe
<jbailey> lamont: The glibc fix is working right for you then?
<lamont> beautifully
<jbailey> Cool.
<jbailey> I'll need to hear from doko before I know what to do with this compile, assuming it produces packages correctly.
<jbailey> I have this vague suspicion that it didn't actually produce the binaries or something.
<jbailey> And sometime around then I need to get initramfs-tools made the default.
<jbailey> lamont: If I do the upload of the kernel package, and a noop upload of the linux-source based on the new kernel package, will you take care of getting the changes into you repo?
<lamont> ??
* lamont thought the kernel package _was_ linux-source
<infinity> It is.
<infinity> jbailey : There's no such thing as a "noop upload of linux-source", all the linux-image binaries are generated by it.
<jbailey> lamont: Umm.  Whatever bits contains make-kpkg
<jbailey> lamont: Which is the bit that needs changing.
<infinity> Oh, "kernel-package"
<jbailey> Right.
<infinity> But still, no such thing as a noop upload of linux-source.  Unless you mean "no source change upload", with an non-op of rebuilding every kenrel image. :)
<jbailey> no-op from my point of view.
<jbailey> ;P
<infinity> Oh.  No-effort, then. :)
<lamont> ah, right.
<infinity> I'll accept that.
<lamont> so you upload kernel-package with the change, then fix the build-deps and upload the kernel
<jbailey> Yup
<infinity> (Though, you'll want to put in at least minimal effort to bump the kernel-package build-dep, if you don't want stuff to blow up)
<jbailey> But I want to make sure that I don't make it hard to keep your baz repo happy for the kernel stuff.
<lamont> ah, ok.  I get it...
<lamont> how soon you want to do this?
<infinity> Merging in a 1 line change plus a changelog entry shouldn't be too tough. ;)
<lamont> ah, doesn't much matter...
<jbailey> lamont: Tongiht, ideall.
<jbailey> +y
<lamont> jbailey: you hooked up for baz hackery?
<lamont> or is that what you're asking me to do?
<jbailey> infinity: I think they name the branches after the version numbers.
<jbailey> lamont: I'm asking you to do that.  baz and I don't get along.
<lamont> ok.
<lamont> either I'll do it or I'll dump it on fabbione. :-)
<infinity> jbailey : You're not alone.  baz and I have had some pretty heated arguments.
<jbailey> Sound slovely. =)
* lamont has an all-day offsite tomorrow, work like hell on tuesday, and out of town wed-sun
<jbailey> infinity: I suggest hanging out on #bzr and encouraging mpool to ignore any heritage they consider taking from baz. =)
<infinity> I figure the path of least resistance there is to re-brand svn as bzr and let it loose on the world.
<jbailey> infinity: I think they've found it helpful to have me occasionally say "What?  Why would I want to know what the hell a library is before I do a checkout?"
<infinity> While I may like that, however, I suspect it may irk others.
<jbailey> Rebranding git as bzr would be a better match.
<jbailey> At the moment they serve about the same goals.
<desrt> 'git' is a much cooler name, though
<jbailey> git/cogito
<jbailey> desrt: I've assumed the pronounciartion of 'bzr' is 'buzzer', which is kinda fun, too.
<desrt> jbailey; you pronouce it like "cathedral" backwards :)
<lamont> jbailey: I've heard it pronounced bazzer
<jbailey> I like the Linus quote on the OLS t-shirts this year, something to the effect of "I'm an egotistical bastard.  I name all my projects after myself. First Linux, now git"
<lamont> lol
<jbailey> Ooo Ooo!  debhelper time!
<jbailey> BOOYAH
<jbailey> I have a biarch gcc-4.0 now, too
<jbailey> And no amd64-libs on my system
<infinity> \o/
<jbailey> infinity: What hours are you working these days?
<jbailey> infinity: If LaMont's away, I'm goign to need you for the bootstrap fun.
<desrt> jbailey; dude.  infinity is a busy guy
<jbailey> desrt: YEs, and I'm about to make him busier...
<infinity> In theory, 10-6 AEST (2400 - 0800 UTC, I think)
<infinity> In practice, I'm in and out all evening, unless I have something else to do.
<infinity> desrt : I appreciate the 3rd party atempt to dodge work, but jbailey's asking e to do something suqarely in my job description (for once, yay), so I can't very well cop out with "I'm budy". :)
<infinity> s/budy/busy/
<infinity> Although, how anyone could want help from someone whose typing is this horrible, I don't know.
<infinity> Maybe I need to turn off all the filesharing applications on my girlfriend's computer, so I'm not typing 12 words ahead of my visual feedback.
<jbailey> infinity: 'kay.  Once I get doko's final okay on the gcc-4.0 failures, I have the binaries that you need to install in the chroots.
<jbailey> infinity: Doing the rebuilds shouldn't take any of your attention (Just one each, about 3 hours per gcc, 2 hours for glibc)
<jbailey> infinity: Then drop those in the buildd chroot and feed it the source packages that I'll have signed for you.
<infinity> jbailey : <nod>.. I understand the concept. :)
<jbailey> infinity: Cool, it's as much to confirm the steps for me as anything. =)
<infinity> jbailey : Just be a dear and sign the binaries you expect me to bootstrap with as well.
<jbailey> infinity: Sure.  Signed changes file good enough?
<infinity> Good enough for me, yeah.
<lamont> better be... :-)
<lamont> infinity: thanks man
<infinity> Unless you're a l33t MD5 hax0r.
<jbailey> infinity: Will you be fussed if the glibc you build with is slightly different that the one you're building?
<jbailey> infinity: My current build doesn't have lamont's hppa patch in it yet.
<infinity> Doesn't hurt my feelings any.
<jbailey> And the gcc-3.4 that I'll be building suggests libc6-dev-amd64 instead of libc6-amd64
<jbailey> So basically stupid little changes like that.
<jbailey> But that I'd rather not piss away 8 hours on rebuilding for if I can avoid it.
<infinity> I'll get over it.  So long as the final binaries produces at the end of the bootstrap are correct.
<jbailey> That's the promise.
<infinity> That's the whole point, really.  The intermediate shit is expected to be goofy anyway.
<lamont> jbailey: and technically, it's two builds of each....  That is, what gets uploaded is built using only debs built in the data center
<infinity> He doesn't need to care about that last step, mind you. :)
<lamont> infinity: true
<jbailey> Right. ;)
<infinity> Well, he does if the new gcc/glibc combo somehow fails to build itself, but that shouldn't happen.
<jbailey> lamont spent alot of time convincing me to not care about buildd time.
<lamont> I just wanted him to understand that it was actually a small amount of work..
<jbailey> Something or other about Ubuntu not having m68k whiners^Wmachines that we have to worry about bogging down.
<infinity> buildd time in Ubuntu is pretty.. Plentiful.
<lamont> yeah.  cycles we got
<infinity> It's not the "lack of m68k" factor, so much as the "overkill redundancy" factor.
<jbailey> True.
<lamont> OTOH, if you don't have my glibc fix, we'll have to talk...
<lamont> :-[)
<infinity> We can rebuild the archive in n otime flat on a single buildd of any of the 3 release arches... So what do we do?.. Have 3 buildds for each.  Yay.
<jbailey> But fundamentally when I upload, I usually think about "Is this change enough to merrit bogging down an m68k machine for a day or two?"
<jbailey> (In Debian, obviously)
<jbailey> Or an arm machine.
<infinity> jbailey : I wouldn't worry about the m68k case in Debian either, if I were you.
<infinity> jbailey : If we're backlogged, your 5 uploads in a day will go unnoticed anyway, and if we're caught up, we're caught up, so what do you care? :)
<jbailey> True. =)
<jbailey> Does the buildd still kill in-progress builds when w-b notifies that a newer version is going?
<infinity> If the buildd gets the mail, sure.
<infinity> (Well, it doesn't kill the build, it just purges the build directory, which causes it to fall the fuck over miserably and confuse people reading the logs)
<infinity> But, in essence, it works.
<jbailey> Ahahaha
<jbailey> sweet
<jbailey> The buildd software is such cruft.
<infinity> Removing the build tree out from under the build is the most reliable way to make it fail in a hurry.
<infinity> It's just confusing to understand why it died, if you're not used to it.
<lamont> mind you, I don't think hppa/ia64 do the nuke-the-build-tree trick
<jbailey> Oh sure.  And a tire-iron is the fastest way to get a cyclist off his bicycle.
<jbailey> But still...
<infinity> No, a new driver in Germany is.
<infinity> Which is a joke that my adopted countrymen here iN Australia may find in poor taste...
<infinity> (Did you guys get that news story over there?)
<jbailey> I do remember a friend of mine remind me that the fastest way to a man's heart is through the breastplate.
<jbailey> Followed by someone else pointing out the through the base of the throat might be faster because you're pretty guarnateed to get it right in one hit.
<jbailey> infinity: I don't think so...
<jbailey> Ahahaha
<infinity> jbailey : Oh, a few weeks ago, the entire Australian women's cycling team was run over in Germany by someone who had been licensed for only a few months.
<jbailey> Google images gives this hit first for "Tire Iron":
<jbailey> http://www.dot.wisconsin.gov/safety/motorist/behaviors/aggressive/
<jbailey> infinity: Oh ouch. =(
<infinity> http://news.bbc.co.uk/sport1/hi/other_sports/cycling/4695385.stm
<jbailey> infinity: Oh ouch. =(
<infinity> That's okay, I didn't know any of them, and besides, it's against my religion to offer condolences.
<jbailey> Oh, I know why I missed that.
<jbailey> I spent the 20th sitting in the senate watching the same-sex marriage debate.
<infinity> Oh, I came up with the solution to the same-sex marriage debate yersterday evening, in a fit of absolute brilliance.
<jbailey> Oh?
<jbailey> I'm happy enough with the solution that Canada came up with.
<infinity> I was sitting here, filing my taxes, and noted that several government agencies, from two different governments, consider Zofia and I to be husband and wife, despite having never been issued a marriage certficate, realised that in modern western society, the "legal marriage certificate" has become completely meaningless (from a legal standpoint), and decided the fastest way to end to debate is to stop issuing them altogether, to any couples.
<jbailey> That was one option that was debated.
<desrt> jbailey; seriously though.  infinity has to fix X and the kernel :)
<jbailey> The problem with it is that 'marriage' is an initernationally recognised term protected by various treaties.
<jbailey> If we were to stop issuing marriage certificates, there are a number of legal inconveninences.
<infinity> It even seems to have a positive side, that people who hook up, get drunk, and get married that night won't be considered "married" by the government, since you'd need defacto status (12 months or more, etc) to be considered actually committed to each other.
<jbailey> It would be far better to issue one to everyone at birth.
<jbailey> Relax the rules of marriage to be from 1 to N people.
<jbailey> And just make everyone marries. =)
<infinity> Hah, that's a curious option, too. :)
<infinity> From the government standpoint, though, I do like the "only recognise people who pass the defacto test" concept.
<desrt> what government is this?
<infinity> My ficticious one.
<infinity> That I will set up when I invade Tasmania.
<desrt> so.... .nz?
<ajmitch> infinity: on another note, is a test rebuild of the archive planned sometime before release?
<infinity> ajmitch : It's ongoing.  elmo dumps and reloads the breezy-autotest wanna-build database every few days, and wee see how badly off everything is.
<infinity> ajmitch : I've only been holding off on FTBFS bug filings, because I know a large number of those bugs are rooted in specific problems with packages that are being fixed.
<ajmitch> alright
<ajmitch> we'll probably need to get onto a few of those for universe
<infinity> Once I /think/ things should be buildable, I'll start irritating the packages which clearly still aren't.
<jbailey> infinity: I want lkh related bugs sooner rather than later!
<jbailey> (Of course, lamont has been diligently finding most of those for me...)
<jbailey> interdiff: gcc-4.0_4.0.1-4ubuntu2.diff.gz doesn't contain a patch
<jbailey> hmm
<jbailey> Ah, need -z
<infinity> What have you got against debdiff? :)
<jbailey> I want to send doko what I changed in the source package for review.
<infinity> Yes, and?
<infinity> 'debdiff 1.dsc 2.dsc' is a lot less typing.  Something I'm rather fond of.
<jbailey> debdiff looks like it works on .deb files
<jbailey> I did interdiff -z *diff*
<infinity> Yeah, I do "debdiff *dsc". :)
<infinity> Close enough, I guess, if your fingers are trained for the former.
<lamont> jbailey: see http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/breezy-autotest.all.$ARCH
<lamont> iirc
<jbailey> lamont: Nice, thanks.
<lamont> of course, if something is failed there, and failed in buildLogs/Lists/breezy.all.$ARCH, then it could just be broken.
<lamont> installed in breezy, and Failed/Building in breezy-autotest is generally bad.
<lamont> (unless we're actually doing a build at that moment, which is rare)
<jbailey> lamont: Grep from "Failed", yes?
<jbailey> Cool, thanks.
<lamont> grep Building
<lamont> unless infinity has been marking them failed...
<infinity> No, that's something I wanted to change.
<lamont> Building --> really building, or failed-if-done
<infinity> We should update the autosigner on sanae to auto-fail failed logs for -autotest, rather than leave them in building.
<infinity> Since -autotest is supposed to be, y'know, automated.
<lamont> hrm... good point..
<lamont> you feel safe hacking that?
<infinity> Yep, it's just awaiting a round tuit.
<infinity> Which I should find after today.
<lamont> well, if you haven't done it before I'm back on the 15th, I'll get to it..
<infinity> (I have to attack a few BreezyGoals, before mdz and I meet this afternoon and he gives me hell for only doing half my job)
* lamont makes sure his baz mirror is fresh
<lamont> hehe
<lamont> good idea
* lamont heads off to go to sleep.  night all
<lamont> jbailey: that means fabbione love later tonight for the kernel, in all likelihood
<jbailey> lamont: 'kay, thanks.
<jbailey> lamont: Good sleeps, my friend.
* mode/#ubuntu-toolchain [-s]  by ChanServ
<doko> lamont, infinity: any news about the OOo* build failures / buildd b0rkage ?
<doko> lamont, infinity: any news about the OOo* build failures / buildd b0rkage ?
#ubuntu-toolchain 2005-08-14
<lamont> doko: hppa's toolchain has an issue or 23
<lamont> gcc -shared -Wl,-soname,libz.so.1 -lc -o libz.so.1.2.3 adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o
<lamont> using 3.4
<lamont> produces a .so that has _GLOBAL_OFFSET_TABLE_ defined, which it absolutely should not.
<lamont> thoughts?
<lamont> doko_: and using 4.0
<fabbione> lamont: it's probably binutils fuckage
<fabbione> same as sparc and alpha
<lamont> fabbione: yeah
<doko> lamont, infinity: please fix the i386 buildd, dpkg is segfaulting again :-/ the OOo2 -ubuntu6 build did work, but -ubuntu7 fails again ...
<lamont> doko: AFAIK, the cause of dpkg segving is unknown.  OOo2 being the prime example of a package that initiates it
<doko> should I file a bug report?
<doko> lamont: requeued?
<lamont> ISTR there might already be a bug open
<elmo> please make sure there is, dpkg sigsev == pain
<lamont> elmo: OTOH, it seems to be vernadsky each time...
<lamont> so I've stopped buildd there, cleaned the chroot, and given oo.o2 back
<lamont> elmo: if you're in the DC, some memtest love on vernadsky might be good
<elmo> memtest doesn't work on that machine
<doko> elmo, lamont: submitted as 13306 
<elmo> or that machine class
<lamont> elmo: feh
<elmo> yeah, rocks doesn't it
<elmo> is it at all reproduceable?
<elmo> 'cos we can invoke keybuk's mad debugging skillz, he can probably tell if it's bad memory
<lamont> elmo: infinity knows more about it
<elmo> ok
<lamont> I'm just parroting him on the subject.
* lamont has been a bit busy with day-job stuff this week, getting ready to be gone tomorrow-sun
<doko> lamont: please requeue debhelper (if that helps ...)
<doko> You might want to run `apt-get -f install' to correct these:
<doko> The following packages have unmet dependencies:
<doko>   file: Depends: libmagic1 (= 4.12-1) but it is not going to be installed
<doko>         Depends: libmagic1 but it is not going to be installed
<doko>   libgl1-xorg-dev: Depends: xlibmesa-gl (= 6.8.2-44)
<doko> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
<doko> Build environment unusable, giving back
<lamont> yeah, it looks to have been a victim of oo.o2
<doko> s/oo.o2/dpkg/memory/g
<elmo> lamont: btw, ia64's not doing dailies; not sure if you know/care
<lamont> elmo: I turned them off, since they're worthless without a kernel
<elmo> ok
<infinity> The dpkg segv is NOT bad RAM.
<infinity> I can reliably reproduce it here on two machines, one ppc32 and one i386.
<infinity> And it's happened on several buildds.
<infinity> And debugging with Keybuk got nowhere. :/
<jbailey> infinity: Is there a nicer testcase than OOo2?
<infinity> I have yet to slim it down to a tiny testcase, but you should be able to reproduce it 100% with "debootstrap a clean variant=buildd breezy chroot ; apt-get install libqt3-mt-dev mesag-dev'
<infinity> Somewhere along the way, the stack gets hideously smashed, and the backtrace on the core is utterly useless.
<infinity> And the assumption that it may be a GCC bug went out the window when I rebuilt with 3.4 and 3.3 (and maybe 2.95 as well, don't recall now) with the same results.
<infinity> With any luck, the archive hasn't changed enough since the last time I played to make that testcase invalid.
<infinity> (tests now)
<elmo> if you need a snapshot  of the archive, let me know - it's important we be able to reproduce this
<infinity> I'll let you know when my bandwidth catches up with my brain.
<infinity> Yup, that testcase still works smashingly.
<infinity> elmo : If you want to snapshot the state of the union as it is right now, it happily segv's.
<doko> jbailey, infinity: did you already start bootstrapping the biarch builds?
<jbailey> doko: No, I haven't hunted down that g++-4.0 bug yet.
<doko> jabiley: we can stop building the lib64stdc++ packages for now, then the bootstrap dance can be done now, and fabbione can build a kernel, when he'S back
<lamont> doko/jbailey: any ideas on the _GLOBAL_OFFSET_TABLE_ crap that hppa is seeing with the current binutils and gcc-{3.4,4.0}?
<doko> lamont: it's not seen with gcc-3.3 ?
<lamont> haven't checked
<lamont> and probably won't have time before I leave in the morning... -> next week for me to test things out.
<lamont> building zlib produces a bad libz.so.1
<lamont> and that's a quick testcase
* lamont goes heads down, ignoring all but /query
<jbailey> doko: Well, it won't kill bootstrap we could even leave it in, which would let me hand over what I have now I guess.
<doko> yes, that would be nice
<elmo> lamont/infinity: terranova is back; with a newer kernel
<lamont> elmo: woiot
<lamont>  /me goes to kick that buildd
<lamont> launched
#ubuntu-toolchain 2006-08-07
<doko> jbailey: how did the powerpc glibc packages look like?
<jbailey> We're having DNS difficulties at the office, i'm just packing up to go home.
<jbailey> (where my wife is experiencing her first real morning sickness)
<jbailey> I'll hopefully hop back on that tonight.
<jbailey> The current things I have are on Davis, but does the symlink move in the way that adam told me not to do it.
#ubuntu-toolchain 2007-08-09
<Mithrandir> hm, http://launchpadlibrarian.net/8743442/buildlog_ubuntu-gutsy-lpia.hildon-thumbnail_0.11ubuntu1_FAILEDTOBUILD.txt.gz ; is this due to a gcc problem or just glib which needs a bit of adjustment?
<doko> Mithrandir: I filed a bug report on this, I don't know if it shows up in other packages as well, but the -hildon packages all build with -Werror ...
<Mithrandir> yes, that's intentional
#ubuntu-toolchain 2008-08-07
<slushpupie> anyone here know why libssp.so isnt provided by anything in ubuntu?
<infinity> slushpupie: Why would we need an external library for ssp?
<slushpupie> infinity: debian does, which makes building packages that depend on it more frustrating to build
<slushpupie> I cant use the same .deb file for both
<infinity> slushpupie: ...
<infinity> slushpupie: SSP supoprt is built in to glibc.
<infinity> slushpupie: If we had a libssp at all, it would be a no-op stub.
<slushpupie> when I build my custom openssh package on debian, it uses /usr/lib/libssp.so, and thus depends on the libssp0 package
<slushpupie> no such package exists in ubuntu, so I need to rebuild the package just to get the dependancies stright 
<infinity> Which is often the case anyway...
<infinity> We don't ever guarantee binary compatibility with Debian.
<slushpupie> I know, Im just tryng to simplify things if possible
<infinity> slushpupie: Note that only etch provides "libssp0", lenny does not.
<infinity> slushpupie: So, honestly, I think you're just going to have to build twice, if you want etch packages and intrepid and/or lenny packages.
<slushpupie> thats a bummer for me..  well thanks
#ubuntu-toolchain 2011-08-12
<robtow> I'm trying to build Ubuntu for Beagleboard under Ubuntu 1.10, and rootstock hangs with 100% cpu while "setting up xrulrunner-1.9.2 (1.9.2.10+build1+nobinonly-0unbuntu1)"
<robtow> Any advice?
