#ubuntu-toolchain 2005-12-06
<fabbione> Nov 25 15:11:16 doko    fabbione: no, please delay that until jbailey has a libc6-i386(-dev) ready
<doko> yep, better
<fabbione> that was you :)
<fabbione> not me
* lamont__ prepares to upload libtorrent to get the new libsigc++2.0
<lamont__> doko: ping
<doko> lamont__: pong
<lamont__> so for libtorrent, which picks up its Depends: libc6 (>= 2.3.4-1), libgcc1 (>= 1:4.0.1), libsigc++-2.0-0c2 (>= 2.0.2), libssl0.9.7, libstdc++6 (>= 4.0.1)
<lamont__>  from the build, I just need a rebuild, yes?
<lamont__> that is, no control file changes, right?
<doko> lamont__: yes looks fine. I usually name these "build1" instead of "ubuntu1"
<lamont__> right
<lamont__> and uploaded
* lamont__ grumbles and kills the build of gcc-3.4_3.4.5-1ubuntu1
<lamont__> which was into it's tests
<lamont__> s/'//
<lamont__> doko: did another round on bash for /dev/std{in,out,err} as well. sigh
<lamont__> fabbione: btw, you'll need to have /dev/{fd,std{in,out,err}} symlinks in chroot-dapper on your buildds, or bash will hate you
<lamont__> well, ok... stdout and stderr might be optional
<fabbione> lamont: i have a standard /dev in my chroots
<fabbione> like done by MAKEDEV
<lamont__> ah, ok
<doko> lamont__: I need these, or else something goes wrong. this is exactly the test from the configure script
<lamont__> right
#ubuntu-toolchain 2005-12-07
<lamont__> cp -p build-min/bash debian/bash-minimal/bin/bash-minimal
<lamont__> make: : Command not found
<lamont__> make: *** [binary-minimal]  Error 127
<lamont__> doko: ^^^
<lamont__> hrm.. maybe doko_ needs this too..
<lamont__> cp -p build-min/bash debian/bash-minimal/bin/bash-minimal
<lamont__> make: : Command not found
<lamont__> make: *** [binary-minimal]  Error 127
<doko_> lamont, ?
<doko_> lamont__, ?
<lamont__> that's bash
<lamont__> although I must admit that it's strange
<doko_> yes, i386/powerpc/amd64 did succeed ...
<lamont__> ok
<doko> infinity: please requeue gcc-4.0 on i386
<infinity> Done.
<doko> hmm, maybe the same for amd64
<infinity> (Did that too at the same time)
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: do you happen to know if binutils is foobar on ppc?
<fabbione> if not, do you have a ppc handy to do a test for me?
<doko> a) no, b) sorry, no.
<fabbione> ok
<fabbione> let me explain the problem
<fabbione> perhaps we can reproduce it on davis
<fabbione> i compile libfoo with bar support
<fabbione> that gets linked properly
<fabbione> and i can see from objdump -x |grep NEEDED
<fabbione> that bar requires libfoo
<fabbione> bar pkg also ships a libbar
<fabbione> that's still linked properly
<fabbione> now
<fabbione> there is libbaz that B-D on libbar-dev
<fabbione> meh
<fabbione> no sorry
<fabbione> wrong example
<fabbione> doko: wipe it
<fabbione> let's start from scratch
<fabbione> with real names
<fabbione> i have devmapper that B-D on libselinux1-dev
<fabbione> devmapper produces a libdevmapper that's linked with libselinux
<fabbione> (verified via objdump
<fabbione> and up till here everything is nice and dandy
<fabbione> later on comes to play lvm2
<fabbione> that B-D on libdevmapper
<fabbione> lvm2 has the option to build with or without libselinux
<fabbione> the first case is done for the .deb
<fabbione> the latter for the .udeb
<fabbione> now
<fabbione> the interesting part is that lvm2 pulls in selinux only to do a call to:
<fabbione> #ifdef HAVE_SELINUX
<fabbione>         if (!set_selinux_context(lv_path, S_IFLNK)) {
<fabbione>                 stack;
<fabbione>                 return 0;
<fabbione>         }
<fabbione> #endif
<fabbione> so if we agree.. lvm2 needs libselinux for set_selinux_context symbol
<fabbione> am i right?
<fabbione> now
<fabbione> the build is done without selinux
<fabbione> grep set_selinux_context lvm
<fabbione>  | wc -l = 0
<fabbione> so the binary doesn't have any reference to that symbol
<fabbione> but
<fabbione> objdump -x lvm | grep NEEDED
<fabbione>   NEEDED      libdevmapper.so.1.01
<fabbione>   NEEDED      libdl.so.2
<fabbione>   NEEDED      libc.so.6
<fabbione>   NEEDED      libselinux.so.1
<fabbione> DA DA DA
<doko> and it looks ok on other architectures?
<fabbione> libselinux is there
<fabbione> yes.. it looks ok on other arches and in Debian
<fabbione> the problem seems to be Ubuntu specific
<fabbione> i did check the build logs and stuff
<fabbione> i am sure -DHAVE_SELINUX is not defined
<doko> just checked binutils, no powerpc patches in ubuntu
<fabbione> what else could it be that causes such a thing?
<fabbione> it could also be that Debian has a different binutils?
<doko> how is lvm linked?
<fabbione> powerpc-linux-gnu-gcc -o lvm dumpconfig.o formats.o lvchange.o lvconvert.o lvcreate.o lvdisplay.o lvextend.o lvmchange.o lvmcmdline.o lvmdiskscan.o lvreduce.o lvremove.o lvrename.o lvresize.o lvscan.o polldaemon.o pvchange.o pvcreate.o pvdisplay.o pvmove.o pvremove.o pvscan.o reporter.o segtypes.o toollib.o vgcfgbackup.o vgcfgrestore.o vgchange.o vgck.o vgcreate.o vgconvert.o vgdisplay.o vgexport.o vgextend.o vgimport.o vgm
<fabbione> erge.o vgmknodes.o vgreduce.o vgremove.o vgrename.o vgscan.o vgsplit.o lvm.o -Wl,--export-dynamic -L../lib -L/lib -llvm -ldevmapper -ldl  -rdynamic
<fabbione> this is the call to link lvm
<doko> is the symbol in liblvm?
<fabbione> grep set_selinux_context liblvm.a
<fabbione> fabbione@daltanius:/usr/src/lvm2-2.01.14/debian/build/build-udeb/lib$ 
<fabbione> nope
<fabbione> it's used there if -DHAVE_SELINUX
<fabbione> brb
<doko> any of the .la files reference the library?
<fabbione> hmm
<fabbione> fabbione@daltanius:/usr/src/lvm2-2.01.14/debian/build/build-udeb$ find . -name "*.la"
<fabbione> fabbione@daltanius:/usr/src/lvm2-2.01.14/debian/build/build-udeb$ 
<fabbione> libdevmapper matches.. but that's ok on the other arches
<fabbione> or better
<fabbione> it matches everywhere
<fabbione> but libselinux is not pulled on i386 or amd64
<fabbione> i am getting workraved
<fabbione> brb
<fabbione> re
<fabbione> any idea?
<doko> no, currently not.
<fabbione> ok
<fabbione> we will have to ask jbailey to recheck
<fabbione> or actuall
<fabbione> there is a test i could do
<fabbione> trying to use a libdevmapper.a that doesn't use libselinux
<fabbione> and see if it actually comes from there
<fabbione> yes, it definetely comes from there
<fabbione> if i use a libdevmapper without selinux, lvm doesn't NEEDED libselinux
<fabbione> this is definetely something to do with binutils
<jbailey> fabbione: Sorry, what am I checking?
<jbailey> I'm just catching up on the backlog.
<fabbione> jbailey: read the backlog.. if there is something not clear i will explain again.. i need to take a break
<fabbione> re
<jbailey> fabbione: Without having looked it up, my best guess is that it's not a binutils issue so much as somethings reducing the symbols not being used or something.
<jbailey> I'll take a look a bit later, I'm still going through email.
<fabbione> jbailey: ok. is everything i wrote understandable?
<jbailey> Sort of.
<fabbione> the pkgs we have in the archive now are all libselinux disabled
<fabbione> so you will need to renable them
<jbailey> AFAICT, you think seliniux should be in the NEEDED set and it isn'
<jbailey> t on PPC.
<jbailey> ?
<fabbione> the other way around
<fabbione> it's NEEDED and it shouldn't
<fabbione> but only for the build that explicitly define --disable-selinux
<jbailey> Ah, okay.
<fabbione> note: build-udeb
<jbailey> Can I reproduce this on ppc?
<jbailey> Or sparc?
<jbailey> Those are my two easily-acceisble dapper machines atm.
<fabbione> ppc
<fabbione> i386 and amd64 looks ok
<fabbione> it seems to be a specific ppc problem
<jbailey> Lovely.
<jbailey> Always nice to use the faster machine for debugging.
<jbailey> =)
<fabbione> ehehe
<jbailey> And that's lvm2, right?
<fabbione> yes
<fabbione> you need to start from devmapper
<fabbione> enable selinux on devmapper
<jbailey> Hmm, silly question.
<fabbione> eheh ok :)
<jbailey> Lemme get this straight again (sorry, I'm still sleepy.. *g*)
<jbailey> I see devmapper has --disable-selinux.
<jbailey> And it's still pulling in libselinux anyway?
<fabbione> fabbione let's start from scratch start from here
<fabbione> fabbione let's start from scratch <- start from here
<jbailey> Or perhaps I should grab breakfast. =)
<fabbione> exactly
<fabbione> wake up first :)
<jbailey> a'ight.
<jbailey> fabbione: 'kay.  I think I'm awake now.
<fabbione> ok
<jbailey> So, the ultimate goal here is to enable selinux, or not?
<jbailey> doko was saying to me that enabling selinux is a dapper+1 goal.
<doko> ehh, no, ssp first ...
<doko> jbailey: great that pitti isn't here ...
<fabbione> jbailey: ok
<fabbione> simple nice and dandy
<fabbione> selinux support should be enabled in the .debs
<fabbione> but NOT in the udebs
<fabbione> on ppc due to something fucking up
<fabbione> lvm gets linked with libselinux (the udeb build)
<fabbione> it doesn't happen on other arches
<fabbione> the build logs are the same
<fabbione> there is no HAVE_SELINUX defined
<fabbione> nothing in the udeb build uses symbols from libdelinux
<fabbione> libselinux
<fabbione> the only thing is libdevmapper
<fabbione> it uses libselinux
<fabbione> libdevmapper is used both for .debs and .udebs build
<fabbione> this still doesn't explain why an objdump on PPC shows NEEDED libselinux
<fabbione> and it doesn't on other arches
<fabbione> this makes lvm2 fails on ppc
<fabbione> make more sense now?
<fabbione> anyway i need to go offline
<fabbione> i might pass by later
<jbailey> 'k
<jbailey> I'll dig through and get this.
<jbailey> See you after your nap. =)
<doko> nice one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199
<jbailey> Jakub's comment: Finding a bug in 1M of assembly is really hard without knowing where exactly
<jbailey> to look at.
<doko> yes, but he already posted the patch
<jbailey> Yes.  Jakub scares me. =)
<doko> I like our gcc-opt adding -mtune=pentium4 ...
<fabbione> jbailey: ok thanks.. i don't think i can do more debugging really..
<jbailey> Yup, it's all good.
<fabbione> jbailey: i need to go off for the night.. my wife invited mother and sister
<jbailey> I haven't looked at it yet, but I'm having a slow day today.
<jbailey> 'kay.  Sometime next week I want to grab you for a server kernel discussionwith benc.
<fabbione> jbailey: no problem.. i am pretty sure it's something not related to the pkg itself
<jbailey> You're the approver. =)
<fabbione> you might notice is that in Debian doesn't happen
<fabbione> jbailey: sure
<fabbione> let's plan a meeting..
<jbailey> After your nap on Monday, maybe?
<fabbione> perhaps monday evening around 20:00 UTC would be lovely
<fabbione> no after the nap i have the danish exam
<jbailey> 20 UTC should be fine.
<fabbione> but i will finish early -> early dinner -> put wife to bed and i am up for *
* jbailey checks with Ben.
<fabbione> jbailey: please coordinate with Ben
<fabbione> i need to go offline again now
<jbailey> Doing.  G'night, see you around this WE.
<fabbione> i might pass by later..
<fabbione> not sure yet :/
<fabbione> it depends if wife's sister's kids will allow me ;)
<lamont__> doko: I think I gave back whatever package it was you wanted given back on hppa/unstable
<jbailey> lamont__: I tried a build of glibc cvs last night, requires a newer toolchain.
<jbailey> lamont__: I'll do the work on bdale's j5k box for now.
<jbailey> (I have root there)
<lamont__> 'k
#ubuntu-toolchain 2005-12-08
<lamont> make[1] : Leaving directory `/build/buildd/gcj-4.0-4.0.2'
<lamont> make: *** [check]  Error 2
<lamont> Build killed with signal 15 after 150 minutes of inactivity
* lamont kicks doko
<doko> lamont: ?
<lamont> not sure what gcj-4.0 hung up on, but &*%^_ 
<lamont> neato.  qt-x11-free built. wtf?
<lamont> not sure what gcj-4.0 hung up on, but &*%^_ 
<lamont> anyway, just grumbling... hope you dodged the kick alright...
<doko> send me the log please
<lamont-away> doko: http://buildd.mmjgroup.com/buildLogs/g/gcj-4.0/....
<lamont-away> the latest one
<doko> lamont-away: ok, that's my mistake, silly hppa special case :-(
<lamont-away> ah, ok
* lamont-away off for a date with his 10-year-old.  back in a few hours
<lamont> dear toochain guys.  please have gdb build-depend expect-tcl8.3.  kthxbye
#ubuntu-toolchain 2005-12-09
<infinity> lamont : I made the change to dejagnu instead.  One dejagnu has built and installed (it's arch:all, so it should be quick), you can give-back gdb.
#ubuntu-toolchain 2005-12-10
<fabbione> WO HOOO
<fabbione> another gcc-4.0 regression on sparc
<fabbione> ../../ghc/compiler/ghc-inplace -H16m -O -cpp -fffi -Iinclude  -ignore-package X11 -O -Rghc-timing -fgenerics  -package base -fgenerics -split-objs -hisuf p_hi -hcsuf p_hc -osuf p_o -prof   -c Graphics/X11/Xlib/Misc.hs -o Graphics/X11/Xlib/Misc.p_o  -ohi Graphics/X11/Xlib/Misc.p_hi
<fabbione> gcc: Internal error: Segmentation fault (program as)
<fabbione> Please submit a full bug report.
<fabbione> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
<fabbione> For Debian GNU/Linux specific bug reporting instructions, see
<fabbione> <URL:file:///usr/share/doc/gcc-4.0/README.Bugs>.
<fabbione> <<ghc: 296405008 bytes, 62 GCs, 4390005/8691260 avg/max bytes residency (4 samples), 20M in use, 0.01 INIT (0.00 elapsed), 17.04 MUT (84.43 elapsed), 4.34 GC (4.36 elapsed) :ghc>>
<doko> isn't that as?
<fabbione> dunno.. you are the expert :)
<doko> you are the sparc expert :)
<fabbione> well that's general toolchain stuff :P
<fabbione> seriously.. what should i look for?
<fabbione> if it's really as
<doko> does ghc allow you to run gcc with -v ? then you should at least see the as command line, and then determine, if it fails in as or cc1
<fabbione> then it's binutils fuckage
<fabbione> i have NO idea
<fabbione> i can try to do that
<fabbione> it fails at 1.6M in the log that's pretty deep in the build
<fabbione> i will try that asap. thanks
<doko> didn't debian experience some problems with ghc lately?
<fabbione> dunno
<fabbione> they did experience glibc problems on sparc
<fabbione> that's for sure
<fabbione> it didn't even start to build in debian
<fabbione> B-D issues
<fabbione> doko: is the new gcc-4.0 good to build or should i wait a bit?
<doko> fabbione: I tested on i386 and amd64, so maybe you want to wait until these succeed on the buildd
<fabbione> ok
<doko> infinity, lamont, lamont__: gcc-opt ping
<fabbione> doko: anything that needs to be tuned on sparc?
<fabbione> otherwise i am taking off to go to school
<doko> fabbione: gcc-4.0 did succeed
<doko> gcj-4.0 as well
<fabbione> yup i saw that
<doko> gcc-3.4 as well
<fabbione> they will build "soon"
<fabbione> i am also scheduling oo2
<fabbione> but i have to go now
<fabbione> ttyl
<doko> fabbione: new oo2 upload needed
<fabbione> doko: ok
<fabbione> doko: when do you plan to upload oo2?
<doko> uploading ...
<fabbione> oh cool
<fabbione> thanks
<doko> the build did succeed on powerpc and amd64, there must be some problem with parallel make, which I didn't see with my testing
<fabbione> oh ok
<jbailey> doko: Around?
<jbailey> I'm curious if you think it's safe to make the biarch amd64 package "libc6-i686" instead of "libc6-i386"
<jbailey> Since I'm fairly sure that amd64 can support all the i686 instructions including CMOV.
#ubuntu-toolchain 2005-12-11
<doko> hmm, interesting. I didn't look at the default for -m32 on amd64
<jbailey> Bah.
<jbailey> I already have a different libc6-i686, and debian/control can't cope with multiple stanzas targetted to different arches.
<doko> well, do we care, waht happens, if somebody tried to run an executable built with gcc -m32 on i486 or i586?
<jbailey> Mmm.
<jbailey> But off the cuff response is "No"
<jbailey> We're providing biarch for application compatability, not development.
<jbailey> Might be worth asking mdz for a ruling on that, though.
<jbailey> mdz: Around?
<mdz> jbailey: yep
<mdz> reading
<mdz> gcc -m32 on amd64 -> i486/i586 -> don't care
<jbailey> mdz: Thanks.
<doko> heh
<jbailey> I like Ubuntu.  If nothing else, we're efficient. =)
<doko> ;)
<jbailey> Lovely.  The build is running.  I'll poke it over the next day or so until I'm happy with it an upload.
<lamont__> gcc-3.4.gcc-opt: f~D@$V@={=p@;QP@=y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
<lamont__> gcc-3.4.gcc-opt: P@=y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
<lamont__> gcc-3.4.gcc-opt: y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
<lamont__> gcc-3.4.gcc-opt: @=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
<lamont__> gcc-3.4.gcc-opt: @=U=-prototypes: No such file or directory
<lamont__> <command line>:4:1: macro names must be identifiers
<lamont__> wth???
<lamont__>  gcc-3.4_3.4.5-1ubuntu3
<doko> test results are ok
<doko> lamont__, while you are here, please can you change gcc-opt, so that it doesn't add -mtune=pentium4 on i386? all gcc packages are configured to default to that option
<lamont__> doko: that's on dapper, as of now, yes?
<elmo> doko: err, I know I suggested that, but come to think of it, it's a very big change
<lamont__> elmo: yeah
<elmo> we're going from defaulting to -mtune=pentium4 for our builds, to -mtune=pentium4 for _all_ our _users_' builds
<lamont__> note that the current gcc-opt only, um, inserts as the first arg '-mtune=pentium4' if no -mtune option is present
<elmo> lamont: doko's change does  the same thing
<elmo> the thing we're changing here is scope
<lamont__> right
<lamont__> rather significantly.  they were defaulting to -mtune=i686 before, yes?
<elmo> no?
<elmo> -mtune=i386 AFAIK
<lamont__> it was -march=i486
<lamont__> so tune=i386 would be kinda silly...
<lamont__> doko: and btw, tahtwas a fatality in the gcc-3.4 build..
<lamont__> maybe it doesn't like smp
<mdz> doko: wouldn't that be the same thing as disabling gcc-opt altogether?
<elmo> mdz: no, it still does some other stuff
<elmo> like default to -O2, force -pipe etc.
<elmo> but it would get rid of it's major raison d'etre, yeah
<elmo> that was the point tho.  doko didn't like the "hidden" -mtune forceage
<lamont> elmo: has not defaulted to -O2 since we did the archive flush in oxford
<lamont> -O2 by default was, um, bad.
* lamont -> bed
<mdz> I thought on that rebuild we changed from forcing -O2 to forcing -O2 only if it wasn't specified (e.g., -O0 debug builds)
<fabbione> doko: for some reasons OOo2 on ppc gets removed.. 
<fabbione> on a dist-upgrade or upgrade
<fabbione> gonna check why
<fabbione>   openoffice.org2-l10n-en-us: Conflicts: openoffice.org2-core (>= 1.9.130) but 2.0.0m143-0ubuntu2 is to be installed
<fabbione> apt-get install openoffice.org2-common openoffice.org2-core
<fabbione> The following packages have unmet dependencies:
<fabbione>   openoffice.org2-common: Depends: openoffice.org2-l10n-en-us (>= 1.9.129) but it is not going to be installed
<fabbione>   openoffice.org2-core: Depends: openoffice.org2-common (> 2.0) but 1.9.129-0.1ubuntu4 is to be installed
<fabbione> apt-get install openoffice.org2-common openoffice.org2-core openoffice.org2-l10n-en-us
<fabbione> The following packages have unmet dependencies:
<fabbione>   openoffice.org2-core: Depends: openoffice.org2-common (> 2.0) but 1.9.129-0.1ubuntu4 is to be installed
<fabbione>   openoffice.org2-l10n-en-us: Conflicts: openoffice.org2-core (>= 1.9.130) but 2.0.0m143-0ubuntu2 is to be installed
<fabbione> strange that it doesn't happen on amd64
<fabbione> hmm nevermind it might be my mistake
<fabbione> hmm no
<fabbione> oh well after the shower :)
<fabbione> must have been a transient error with mirror syncs
<doko> elmo, lamont__: the previous default was -mtune=i686, we didn't optimize for i386 at any time.
<doko> fabbione: maybe because the i386 build wasn't yet ready?
<fabbione> doko: now it's there
<fabbione> ppc installs
<fabbione> amd64 doesn't
<doko> yes, need to upload the i386 binaries for amd64 as well (what we had before)
<fabbione> ahhhhh
<fabbione> ok
<fabbione> that makes sense
<fabbione> still -experimental- is borked too
<lamont> doko: it would be nice if SyncTest.exe didn't hang around forever (gcj-4.1, iirc)
* lamont -> work
<doko> lamont-away, lamont: hppa?
<jbailey> Nice!  I have libc6-i386 building on amd64.
<jbailey> Assuming it passes the testsuite (I don't see why it wouldn't), then I just need to sort out the conflicts/replaces/build-dep pieces and libc6 biarch can go in.
<jbailey> doko: Should I just conflicts/replaces ia32-libs do you think?
<jbailey> doko: The idea is that it goes away entirely, isn't it?
<infinity> Is there nothing else in ia32-libs anymore?
<infinity> Erk, not there's a bunch of stuff in there.
<infinity> Make it Replaces, but not conflicts.
<infinity> (And if you co-ordinate with Mithrand1r to actually remove libc6 from ia32-libs, than can be a nice versioned Replaces)
<jbailey> infinity: I think the idea is that they were supposed to ultimately all get replaced now.
<jbailey> Something needs to finally remove it.  Last I checked ia32-libs contained egcs, gcc-2.95 and crap that ought to be taken away.
<infinity> No, I don't see any of that junk, but I do see a mess of X libs and such.
<infinity> It should be pared away one file at a time.
<infinity> When it's completely "replaced", dpkg will be smart enough to remove it.
<infinity> (dpkg marks packages removed if they have an empty file list)
<jbailey> Won't /usr/share/doc/ia32-libs always be there?
<infinity> Alternately, once they're all replaces, ia32-libs cna become a metapackage for smooth upgrades.
<infinity> Whatever.
<jbailey> Mm, yeah.
<jbailey> Okay, so just a replaces, and a build-dep on the newer lkh.
<infinity> At any rate, there's amess of stuff in there right now and systems will go tits up without it.
<infinity> (Well, systems like mine where I run 32-bit apps..)
<jbailey> Woot, only one test failure and it's the expected one.
<infinity> If you feel like making it a versioned replaces and getting someone to update ia32-libs to remove the libc6 bits, more power to ya'.
<infinity> I'd do it, but ia32-libs disagrees with my complete lack of bandwidth.  It's a HUGE upload.
<jbailey> infinity: I don't think I care enough across the development cycle.
<jbailey> It's actively going away, so if a replaces will handle it for now and we can just power through the rest of the packages, that's more ideal.
<infinity> Should do, assuming you're installing to the same paths..
<jbailey> Yeah, checking that now. =)
<infinity> I hope you are. :)
<jbailey> 45 meg source file.  That just hurts.
<infinity> The binary isn't drastically better.
<jbailey> Wow.  There's a remarkable pile of crap in here.
<infinity> Yup.
<infinity> Everything one needs to run a whole host of crappy 3rd party binary apps.
<infinity> Multi-arch can't come too soon.
<jbailey> I don't see any coreutils bits in the breezy ia32-libs.
<jbailey> I wonder what that's for then.
<infinity> ...?
<infinity> Why would you want coreutils in ia32-libs?
<jbailey> It's in there now.
<infinity> Oh, you mean the .deb is in the "source" package?
<jbailey> The source for coreutils is in the source for ia32-libs
<infinity> Yeah, uhm.  Who knows.
<jbailey> I have to be careful, if I do more recursion than that I start adding ( )'s all over the place.
<infinity> I think Tollef lost all will to care about ia32-libs long ago, so whatever cruft it's gathered over time hasn't been cleaned up.
<infinity> I can't really blame him.
<infinity> It's a hack that just needs to Go The Fuck Away.
<jbailey> No mention of coreutils in the rules file.
<jbailey> Lovely. =)
<jbailey> Ooo, in fact it hasn't been updated since breezy.  Perfect.  I can assume the output on Angie's machine is right.
<doko> jbailey: yes, Replaces ...
<infinity> The dpkg -L output?
<infinity> Yeah, that's what I was looking at too. :)
<jbailey> Mmm.  It's not going to perfectly the same.
<jbailey> infinity: How many apps do you think will break if I drop linuxthreads on the biarch version?
* jbailey grumps
<jbailey> I had originally planned to drop LT on regular i386 for this release, but it makes sense to keep it on the native side for the long lived release.
<doko> hmm, so what happens, when we move apps built on i386/LT to i686/NPTL?
<jbailey> The theory is that it works. =)
<jbailey> In practice we've tested that theory.
<jbailey> All the machines we install have libc6-i686 installed already.
<jbailey> So the HWCAP seeking will be always using the i686/nptl libraries.
<doko> please test oo2 before you do that ;)
<jbailey> Do you mean for amd64 biarch, test OOo2 that was compiled with i386?
<jbailey> Why would anyone ever do that? =)
<doko> no, but we probably need to ship that, if the native build is too unstable
<jbailey> Ah, I thought we were doing native builds with OOo2
<doko> _if_ they are stable, upstream/novell says, they are not yet production quality
#ubuntu-toolchain 2006-12-05
* Starting logfile irclogs/ubuntu-toolchain.log
* Starting logfile irclogs/ubuntu-toolchain.log
<Dvalin> doko_: around?
#ubuntu-toolchain 2006-12-06
* Starting logfile irclogs/ubuntu-toolchain.log
<fabbione> foo
<Dvalin> doko: around?
<Dvalin> where does stubs-64.h
<Dvalin> oh, glibc I guess..
<jbailey> =)
#ubuntu-toolchain 2006-12-08
<Dvalin> doko_: around
<doko_> Dvalin: usually you can just ask
<Dvalin> okay :)
<Dvalin> I really need help with the sparc-biarch.dpatch
<Dvalin> I get tons of errors
<Dvalin> and I'm unable to figure out what it relies on
<Dvalin> also I'm kind of reluctant asking as I'm being on the "other team"
<Dvalin> you  said there was no other patches it depended on, but I feail to see thjat acgtually being trutgh :(
<Dvalin> fabbione promised to help me out one day with these things, I hope you have the kindness and all to help me look into it too :)
<Dvalin> _(basically is' the mandriva sparc port, so that might be some conflict of interest, but hey, it's all linux, right?:)
<Dvalin> (I also hato to be of bother, so pleaqse tell me to fuckk of if you get annoyed, Ir eallt don't want to be that guy)
<doko_> $ ls debian/patches/*sparc*
<doko_> debian/patches/sparc-biarch.dpatch       debian/patches/sparc-niagara.dpatch
<doko_> debian/patches/sparc-g7.dpatch           debian/patches/sparc64-build.dpatch
<doko_> debian/patches/sparc-niagara-doc.dpatch
<doko_> did you check these patches?
<Dvalin> es
<Dvalin> I h<ve them all appplied witr hout no louck :(*
<doko_> hmm, and how do you configure?
<Dvalin> lemme see
<Dvalin>     echo "running ${CONFIG_SHELL-/bin/sh} ../configure   --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --host=sparcv9-mandriva-linux-gnu --with-long-double-128 --with-cpu=v8 --with-system-zlib --disable-libgcj --enable-ssp --disable-libssp --disable-libmudflap --enable-languages=c --no-create --no-recursion"
<doko> we don't configure with --host, our default compiler is 32bit
<bluefoxicy> I thought Ubuntu didn't use the .50 branch of binutils?
<bluefoxicy> Feisty seems to have it
<Keybuk> what made you think that?
<elmo> possibly because I've said loudly before that I think using h.j.lu's binutils is something best left to lunatics
<elmo> (and although I'm nothing to do with binutils in Ubuntu, my name is on the package from Debian)
<bluefoxicy> yes that
<bluefoxicy> well
<bluefoxicy> it seems that nothing in Feisty is built using --hash-style=both (fedora core 6 does this IIRC); if you're gonna use a binutils that supports it, you should really look into building with -Wl,--hash-style=both
<bluefoxicy> http://lwn.net/Articles/192624/  <-- dynsort and precomputed hashes are what you get from this
<bluefoxicy> But I'll leave that up to you
<bluefoxicy> hmm... https://wiki.ubuntu.com/FeistyToolchainRoadmap does mention DT_GNU_HASH support.
#ubuntu-toolchain 2007-12-03
<jbailey> doko: 'k
<jbailey> doko: Awake?
<jbailey> lamont: Around?
<lamont> jbailey: about to lunch.  sup?
<jbailey> lamont: ME too, wondered if you'd got a chance to start the hppa glibc build.
<jbailey> If not, I'll try to setup a chroot on gsyprf11 after lunch.
<lamont> head deep in a hotsite
<jbailey> I was off getting my license to kill this morning.
<jbailey> no worries.  See you!
 * lamont wonders how high the state of california has managed to count so far...
<lamont> my last one started C049
<jbailey> You don't just reinstate your license when you move here?
<lamont> jbailey: if it's been less than 4 years.
<lamont> in fact, i did reinstate it once, after losing my wallet on the plane ride out.  'twas fastest
<jbailey> It's vaguely tempting to renew my Quebec driver's license just to make sure it's no problem when I move back there.
<doko> jbailey: back
<jbailey> doko: Heya
<doko> the sparc build did succeed. I'm uploading to the ppa now
<jbailey> Lovely!
<doko> doko@gb:/scratch/packages/glibc/glibc-2.7$ bzr commit
<doko> No handlers could be found for logger "bzr"
<doko> bzr: ERROR: Could not acquire lock "(remote lock)"
<jbailey> After we get this into the archive, I'll fix a couple of things in the debian svn to help reduce our diff further.
<jbailey> There's a few things where we quote package versions and such that can easily go in there.
#ubuntu-toolchain 2007-12-04
<lamont> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: error: 'THREAD_SELF' undeclared (first use in this function)
<lamont> hppa doesn't like glibc_2.7-3ubuntu1~ppa
<sivang> howdy fellas ;)
<sivang> I'm trying to set up a cross compilation environment for mipsql
<sivang> err
<sivang> linux-mipsel
<sivang> following http://people.debian.org/~debacle/cross/
<sivang> however, it appears toolchain-source is missing from gutsy's repos?
<sivang> (have an AU1550 based board I want to try boot strapping and want to build a compatible vmlinux image, root fs is mounter over nfs, the board already works with a from source built toolchain but I want to explore the true debian way (e.g. using apt commands to install stuff etc)
 * sivang wonders if all are a sleep :)
 * sivang wonders if setting up a chroot to overcome missing .debs in ubuntu repos would do
 * sivang tries
<sivang> oh well, anyway if anyone has an idea I'd appreciate if you could mail me at sivan--@--ubuntu.com
<sivang> thanks duded, regards to you all. (long time)
<sivang> err, dudes
<doko_> jbailey: ping
<jbailey> doko: heya!
<jbailey> lamont: Suck. =(  I wonder how it's missing that macro.
#ubuntu-toolchain 2007-12-05
<lamont> jbailey: I was wondering if maybe it was because of us keeping a patch we shouldn't have... dunno
<jbailey> lamont: It's possible, but I'm not sure.  I haven't had a chance to start a build so I can see the files myself.  Did you do it somewhere I can get to?
<jbailey> (You might need to refresh my ssh keys from launchpad if it's on bld-4(
<lamont> jbailey: not easily.  I could make it happier.
<jbailey> Or I could just start a build somewhere.
<jbailey> I'll do that before I leave today.
<jbailey> That way I can see it in the morning.
<lamont> it takes less than 5 minutes to die...
<jbailey> Oh, cool.
<jbailey> then I'm more inclined to look sooner.
<jbailey> Otherwise we risk doko uploading it, I think it's ready to go on other arches.
<jbailey> lamont: debootstrap started on gsyprf11
<lamont> yeah - the first try died with some stupid error (checksum error on a build-dep deb), so I thought round 2 was more of the same.  'twasn't.
<jbailey> W: Failure trying to run: chroot /chroots/feisty dpkg --force-depends --install var/cache/apt/archives/base-files_3.1.9ubuntu7_hppa.deb var/cache/apt/archives/base-passwd_3.5.11_hppa.deb
<jbailey> *sigh*
<jbailey> Any way to restart a failed debootstrap?
<jbailey> nm, restarting with edgy instead of feisty.
<jbailey> Feisty probably wasn't finished when this debootstrap got put in.
<lamont> debootstrap gutsy from launchpad.
<lamont> or debootstrap hardyu
<lamont> since you need hardy to build that glibc
<jbailey> I need the script to be in the local launchpad
<jbailey> gsyprf11 is running some debian variant.
<jbailey> "unstable"
<jbailey> Ah, 16:50.  Sundown.
<jbailey> Happy Hannukah.
<jbailey> Hmm edgy fails.
 * jbailey tries upgrading deboostrap
<jbailey> Already the latest version.
 * jbailey tries dapper instead.
<jbailey> I should probably just get that c3000 from grant and put it under my desk.
<lamont> or just install the hardy debootstrap on gsyprf11. :-)
<jbailey> I'm trying to be polite.
<jbailey> It does dapper fine.
 * jbailey thwaps it up to hardy.
<jbailey> lamont: I finally have a hardy chroot, but I need to run.  I'll get the build going and look in the morning.
<jbailey> If doko winds up uploading it, hopefully we'll be along with it within a couple of day.s
<jbailey> lamont: Reproduced.  Heading home.  ttul
<lamont> thanks
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> doko: Is hppa the only blocker at this point?
<doko> jbailey: I think so, but I don't have time to look at it
<jbailey> doko: Assumuing I can get hppa sorted today, what will you want in order to upload tomorrow.
<jbailey> ?
<doko> well, I'm currently using the current package on amd64, i386 and lpia, so it should be fine from my point of view
<jbailey> Cool.  I think that only leaves ia64 and ppc as not tested.  I'm generally okay with that.  They're solid arches upstream.
 * jbailey beats hppa with a "Go faster" stick./
<jbailey> lamont: Can't you get us something cool, like a gazillion-way 8800 or something? =)
<lamont> jbailey: heh
<doko> get an a500 cluster and use disr-cc
#ubuntu-toolchain 2007-12-06
<jbailey> doko_: Unless Carlos screams really loudly, the patch I just cc:'d you on is what's needed to fix it.  Testsuite results on hppa are no more deplorable than usual.
<jbailey> doko_: since we've been having trouble with bzr, could you just apply it to the tree and upload glibc to hardy?
<jbailey> doko_: I've even tested the result in a chroot now. =)
<doko_> jbailey: ok, will upload; btw:
<doko_> <slangasek> doko: kees is telling me that there may be some issue with hardy pulling in glibc 2.7, and he doesn't have details and I don't know what he's talking about, can you enlighten me?
<doko_> * kees didn't know what doko meant, to be clear (as mud)  :)
<jbailey> doko_: Eh, I have no idea what that's about.
#ubuntu-toolchain 2007-12-07
<jbailey> doko: Anything left you need from me for the upload?
<lamont`> jbailey: goat's blood?
<jbailey> It'll be vegan goat's blood.  Somewhat less potent.
<jbailey> Which means that it'll be some sort of crazy pr0n flick with me hosing him down with a firehose of tempeh sauce.
<jbailey> We'll sell ticket.
<jbailey> +s
<jbailey> Well, unless we can sell one at a high enough price to cover the bills.
<jbailey> infinity: Interested?
 * jbailey hides
<lamont`> lol
<doko> jbailey: no, will upload tonight
<jbailey> doko: Cool, thanks
<jbailey> doko: Carlos has ok'd the hppa for upstream, too, which is nice.
<jbailey> +patch
<infinity> jbailey: Freak.
<jbailey> infinity: Didn't you just move to Calgary?
<infinity> jbailey: Yes.... And?
<jbailey> "Takes one to know one" then certainly applies.
<infinity> Thpt.
<infinity> I missed snow.
<infinity> You will too, one day.
<infinity> lamont`: You need to make your way up here sometime, so Zofia can meet you and understand the horror implied in jbailey's statement that our offspring would be "just like LaMont".
<jbailey> Actually, we didn't miss the cold until we went to UDS in Boston.  Then it was a case of "Oh yeah.  There's supposed to have been a season change."
<infinity> Best.  Birth control.  Method.  Ever.
<jbailey> Eheheh
<infinity> You're not in Quebec anymore, you don't have to laugh backwards.
<infinity> Say it with me, "Hehehe, hahaha."
<infinity> Embrace your rich anglophone heritage.
<jbailey> Thinking of which and your former home, I assume you've seen this: http://www.reuters.com/article/oddlyEnoughNews/idUSN0558178520071205?feedType=RSS&feedName=oddlyEnoughNews
<jbailey> My 'airitidge you say hein?
<infinity> Oh man, I love political correctness gone awry.
<infinity> Cause you know a 70-year old santa is totally hip to american gangsta rap slang.
<infinity> Probably been collectin' bitches and poppin' caps in his off hours.
<jbailey> "Yo 'ho.  You wanna come sit on my lap?  Oh yeah baybee.."
<jbailey> Cunningly abbreviated to "Ho Ho Ho"
<jbailey> Sort of like a circus caller.
<infinity> ... and people wonder why I prefer cats to people.
<jbailey> infinity: Enjoy: http://catsinsinks.com/
<lamont`> infinity: lol
<doko> jbailey: glibc uploaded
<jbailey> doko: Yay!
<jbailey> doko: Anything else you need from me for now?
<doko> jbailey: well, just did see the unanswered glibc bug reports ... probably not something for this year
<jbailey> There we go.  I did the one labeled high priority.
#ubuntu-toolchain 2007-12-08
<jbailey> lamont`: Nice, hppa build status is tracked in LP.
<lamont`> oops
