#ubuntu-toolchain 2005-12-01 <doko_> fabbione, jbailey: please have a look at PR20126, gcc* build failure on sparc <jbailey> doko: PR20126 in gcc? <jbailey> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126 appears to be an x86-64 regression <doko> jbailey, no ubuntu bugzilla <jbailey> fabbione, doko: Oh. Yeah. That's easy enough. It's the new binutils enabling TLS on our arches without needed patches. We don't have this problem. <jbailey> Marking it as NOTWARTY. #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 djennings@example.org 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 djennings@example.org. :) <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 2005-12-12 <doko> fabbione: I don't see the as failure building libjava on unstable, at least the gcc-snapshot package did build ok in the past <fabbione> doko: i get the error building ghc6 and gcj-4.1 <fabbione> so i think it might "as" as you suggested <fabbione> i will have to find time to look into it <elmo> jbailey: around? <jbailey> elmo: Yup <elmo> jbailey: 121_i386_x86_64_biarch.dpatch in binutils - could you provide me with a rationale for that, so I can submit it upstream, or maybe even could you do that yourself? <jbailey> Are you digging through the Ubuntu patches, or did it crawl into the Debian binutils? <elmo> drow had me pull it into Debian <jbailey> ... <jbailey> And didn't then just commit it himself? =) <elmo> ? <fabbione> hey guys <elmo> no, he doesn't have global write <elmo> AIUI <elmo> he's just the release manager. which is strange, I know, but <jbailey> Ah, okay. =) <fabbione> gcj: 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> jbailey: do you have any idea of what could case that on sparc? <jbailey> elmo: I can take care of it. I already have assignment on file and such anyway, so it's just as easy if I do it. <elmo> jbailey: k, thanks <jbailey> fabbione: To make as segfault? <fabbione> i can reproduce it building both building ghc6 and gcj-4.1 <fabbione> i am not sure about the error <fabbione> gcj: Internal error: Segmentation fault (program as) <.' <fabbione> as is binutils stuff <jbailey> fabbione: Can you get the asm output from gcj so that we can generate the segfault from gas on its own.? <fabbione> jbailey: yes, it will take some time tho <fabbione> it's deep into the build when it happens <fabbione> jbailey: any trick to build gcj so that it will keep the ASM output? <jbailey> Nah, just call it by hand. <fabbione> meh ok <jbailey> Do you still have the old tree lying around? <fabbione> do i need to add any flag? <fabbione> no i don't <jbailey> Suck. <fabbione> it was in sbuildd but i purge * otherwise i run out of space <jbailey> ghc6 is at least smaller. =) * jbailey tosses a nickel to Fabio. <jbailey> Here kid, get yourself some drivespace. =) <fabbione> ehehhe #ubuntu-toolchain 2005-12-14 <fabbione> doko: ping? <doko_> fabbion: pon <fabbione> doko_: ooo2 on sparc is installing now :) <fabbione> we are almost there <doko_> heh, nice <fabbione> building OOo2 + randomg gcc = teh sux <fabbione> gcc-3.4 did FTBFS because sbuild did timeout <fabbione> so much cpu power waste <doko> during the testsuite? <fabbione> yeah <fabbione> well it was my fault <fabbione> but it's ok... <fabbione> i did build it on another machine <fabbione> gcc-4.0 will be soon in i think <fabbione> gcj-4.0 did destroy Ben's sparc <fabbione> so it needs to be rescheduled <doko> ohh, memory? <fabbione> no i think it's a kernel bug <fabbione> with SMP boxes <fabbione> it is known on that hw class <doko> ahh, just did saw http://gcc.gnu.org/ml/gcc/2005-12/msg00231.html <fabbione> i was actually building gcj-4.0, 4.1 and ghc6 <fabbione> no mem is not a issue <fabbione> it has 6GB of ram that machine <fabbione> it was barely at the beginning of the build on all 3 of them <fabbione> the problem (according to David M.) is that in some situations (SMP) one of the CPU is wedged, but the others have problems to unwedge it <fabbione> = boom boom <fabbione> david is getting the hw as we speak to debug and fic <fabbione> fix <fabbione> dh_strip <fabbione> it's at dh_strip :) <fabbione> doko: now please.. don't upload another OOo2 before this one is in :) <fabbione> otherwise the binaries will be rejected <doko> heh <fabbione> uhuhuh dh_shlibs * fabbione is almost excited :) <fabbione> dpkg-gencontrol: warning: unknown substitution variable ${Binary-Version} <fabbione> ALMOST THERE BUDDY! <fabbione> signfile openoffice.org2_2.0.0m143-0ubuntu3_sparc.changes C14C0CBD <fabbione> it's uploading :) <fabbione> openoffice.org2_2.0.0m143-0ubuntu3_sparc.changes ACCEPTED <- doko <doko> :) <doko> so you'll have live cd's ready tonight? <fabbione> nope <fabbione> i am not building livecd yet <fabbione> d-i needs fixing first #ubuntu-toolchain 2005-12-15 * #ubuntu-toolchain [freenode-info] If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks! * #ubuntu-toolchain [freenode-info] If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks! <fabbione> doko: ping? <fabbione> bash completion in 3.1 is broken <fabbione> ssh trised: -e expression #1, char 20: unterminated `s' command <fabbione> der-g7 <fabbione> that's the result of ssh tri<tab> <fabbione> that completes to trider-g7 #ubuntu-toolchain 2005-12-16 <fabbione> doko: it is line 2479 in /etc/bash_completion that seems to be the one making noise <fabbione> doko: i suggest you also run a sh -n on it. there is another error at like 370 <fabbione> perhaps it's a good idea to do it at build time to <fabbione> it's costless and it gives info * netjoined: irc.freenode.net -> brown.freenode.net * #ubuntu-toolchain [freenode-info] If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks! #ubuntu-toolchain 2005-12-18 <infinity> doko / jbailey : <poke> <infinity> Does either of you feel like taking ownership of binutils bugs today? <jbailey> infinity: I'll answer only once you /msg me where you poked me. <infinity> jbailey : You have an ia64 box, right? <doko> infinity: are there any? <jbailey> I do, yeah. <jbailey> ALthough don't we have one at the DC as well? <jbailey> I was trying to find the name of it yesterday. <infinity> jbailey : ld segfaults on ia64 when building libapt-front, and according to Debian bug #342777, several other packages. <infinity> I don't much care about the several other packages, but libapt-front is in main and blocking working LiveCDs on ia64 (well, other things may be blocking those too, but Shhhh..) <infinity> And if we have an ia64 box at the DC (other than the buildds), I don't know its name... <doko> closes 50% of these ... <fabbione> jbailey: halley <fabbione> halley is the ia64 porting box <jbailey> fabbione: Yup, thanks. Got it from Karl earlier, and I've listed it in the machine page now. <jbailey> (And ask for the build deps for klibc to be installed...) <fabbione> no problem <fabbione> doko: it seems like the new gcj-4.1 is building now.. i will have to kick ghc6 too.. <fabbione> either it did autofix or the new gcc in background is doing a better job <fabbione> doko: gcj-4.1 is ok now.. it did build fine <fabbione> testing ghc6 now #ubuntu-toolchain 2005-12-19 <doko> fabbione: nice #ubuntu-toolchain 2005-12-29 <lamont> dejagnu: Depends: expect-tcl8.3 but it is not going to be installed <lamont> poor llvm #ubuntu-toolchain 2006-12-01 <Dvalin> fabbione: hoi! <fabbione> Dvalin: hi <Dvalin> 'sup? <fabbione> busy ... as usual <Dvalin> :/ #ubuntu-toolchain 2006-12-02 <Dvalin> doko: around? <Dvalin> http://pastebin.ca/264372 <Dvalin> this is what I get when I apply the sparc-biarch patch :( <Dvalin> vanilla 4.1.2 <Dvalin> any ideas? #ubuntu-toolchain 2006-12-03 <Halcy0n> Is this channel normally this quiet? :) <infinity> Halcy0n: Yes. <Halcy0n> Hmm, not sure if that is a good thing or a bad thing :) <fabbione> it's all good.. it means that our toolchain doesn't need discussion <Halcy0n> Heh, if discussion were to happen, where should I look? <fabbione> here <Halcy0n> Alright, good. I'll stick aroudn then :) <Halcy0n> I'm switching most of my boxes over to Ubuntu soon, and I'll be looking to get involved, so I'm just trying to see where to hang out so I know what is going on. <infinity> I don't mean for this to sound insulting, since it's not really meant to be, but if you're "looking to get involved" the toolchain is probably the last place you'd want to start. <infinity> Unless you're a compiler hacker, or have deep knowlege of ELF formats, or other such fun things. <Halcy0n> infinity: I worked on toolchain stuff for another distro for a year and a half. Its my niche :) <infinity> Fair enough. Having no idea who you are doesn't help. ;) <Halcy0n> I maintained GCC for Gentoo. <Halcy0n> So, I've seen my fair share of random really fun bugs to deal with. <doko_> heh, nice to hear <fabbione> hey doko_ <doko_> good morning (damn jetlag) <fabbione> doko_: feeling better? <Halcy0n> Are you guys working toward using SSP on everything? I saw some hardened docs on the wiki, but nothing much besides that. <infinity> Halcy0n: We have SSP on by default, and have done so for the last 6 months. <fabbione> Halcy0n: it's already enabled by default on arches that support it <Halcy0n> Oh, interesting. <infinity> Halcy0n: Disabled on a case-by-case basis for stuff that hideously breaks, or stuff that doesn't link glibc. <Halcy0n> For you guys mentioning Gentoo in the hardened docs, you have surpassed them already. <doko_> fabbione: yes, temperature is down (using drugs) <infinity> Mm, drugs. <fabbione> doko_: ok... <infinity> Someone needs to staple a sign to my forehead that says "stop chatting on ubuntu channels, it's Sunday". <infinity> I was doing so well all weekend, too. <Halcy0n> If we stapled it to your head, how would you see it to remember? :) <fabbione> he is a beauty because he spends hours in front of a mirror ;) <fabbione> we use that trick very often <Halcy0n> hehe <doko_> fabbione: I didn't notice ;-P <fabbione> doko_: haha <infinity> doko_'s just too dillusional right now to remember all the time he spends hitting on me. :P <infinity> delusional too. I need a nap, apparently. #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 2006-12-14 <jbailey> doko: around? <doko> jbailey: pong <jbailey> doko: The SIGILL, is it common? <jbailey> doko: I'm wondering if it's better to dig out the binaries, do an objdump -d and search for the bad instruction, and target those for rebuilds. <doko> jbailey: we do have two bug reports, one found in mysql, the other just reported to gcc <jbailey> So by implication, probably gnome, kernel, basic shell stuff, etc. is mostly working fine. <doko> jbailey: yeah, need to lear all instructions which are affected <doko> s /lear/learn/ <jbailey> I wonder how ugly it is for us to do that search? I remember we did something like that for looking for a symbol leak at one point. <doko> apparently he could install on this machine <doko> I have to find out about the instructions <doko> jbailey: for the __builtin_prefetch case it's enough to scan the sources <jbailey> Well, if we can look for a particular set of instructions it might be nice to do a scan once. <jbailey> Dunno how easy that is, though. #ubuntu-toolchain 2006-12-18 <Toadstool> hi here <Toadstool> quick question: why would a package ftbfs on all archs except for i386 due to conflicts in header files? <Toadstool> http://librarian.launchpad.net/5420830/buildlog_ubuntu-feisty-amd64.ifplugd_0.28-2.1ubuntu1_FAILEDTOBUILD.txt.gz <-- the buildlog on amd64 <doko> Toadstool: these are linux headers. you may want to ask on #ubuntu-kernel as well. <Toadstool> doko: ok, thanks <doko> and/or file a bug report <Toadstool> yep #ubuntu-toolchain 2007-12-02 <jbailey> doko: Just finished the merge except for a couple things. Just doing a test build where I am to make sure that it's all good. <jbailey> I need to twiddle the IPv6 patch, and some of the sparcv9v2 patch to make sure they apply right. <jbailey> I'm curious about the lpia redefine of i686. <jbailey> There was also alot of cruft in the scripts that isn't needed anymore, so I've done my best to remove that so that the diff isn't any bigger than it needs to be. <jbailey> I also have my gpg key now, so there should be a version in the PPA by the end of the day. <doko> jbailey: cool, please merge the 2.7-3 package as well at least the amd64, i386/local-clone.diff patch #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 #ubuntu-toolchain 2007-12-10 <lamont> doko: should I expect pycentral to deal with creating python2.5 packages for me? <doko> lamont: the package has to be set up to actually build for 2.5 <lamont> ah, ok <lamont> got any examples of things building with both? <lamont> 2.4 and 2.5, that is <lamont> and time for this one to run kids to school. <lamont> offline for about an hour. <jbailey> doko: 2.7-3ubuntu1 bulit fine on sparc, but 2.7-4ubuntu1 has a segfault in as. Was there a binutils update in there that I missed, or a gcc update or something? <jbailey> Otherwise I think you broke something in the update. <doko> jbailey: no other update; it did build fine on a t1000, I'll reschedule it, assuming it's the machine ... <jbailey> 'k #ubuntu-toolchain 2007-12-12 <lamont> dpkg-gensymbols: failure: Can't open debian/libgomp1/DEBIAN/libgomp1.symbols.common: : No such file or directory * lamont grumbles at http://launchpadlibrarian.net/10859510/buildlog_ubuntu-hardy-hppa.gcc-4.2_4.2.2-4ubuntu2_FAILEDTOBUILD.txt.gz <lamont> http://launchpadlibrarian.net/10859830/buildlog_ubuntu-hardy-i386.gcc-4.2_4.2.2-4ubuntu2_FAILEDTOBUILD.txt.gz has the same error. <lamont> this bodes well for the upload fixing everyone... <lamont> doko: so far, lpia, i386, and hppa have failed, amd64, ia64 and ppc are building, and sparc is needs-build <lamont> should sparc bother trying? <doko> lamont: hmm, no. however I can't see the mistake yet <lamont> ok. I scored sparc's build down low, so it won't happen before several others <lamont> I can't prevent it from trying eventually though <lamont> doko: any reason to not kill the builds on the 3 architectures where it's still building? <doko> no * lamont kills <lamont> the logs will look hurt :-) <lamont> amd64 beat me... it finished failing before I got there <doko> lamont: found it, too old debhellper <lamont> doko: the package's usage, or the version on the system? <lamont> (and hence a bad build-depend version...) <doko> lamont: the version on the system; updated now <doko> gcc-4.2 should be a retry then <lamont> given that (1) it already failed most everywhere, and (2) won't build with the older debhelper, maybe we could do a new upload with build-depends: debhelper (>= right version) so as to not cause undue pain for some idiot backporting or such? <lamont> please? <doko> lamont: yes, with the next merge from the svn #ubuntu-toolchain 2007-12-14 <lamont> doko: https://edge.launchpad.net/ubuntu/+source/rpm/156.14.161.142-1ubuntu1/+build/465226 iz ICE <lamont> (hppa, rpm) * lamont sleeps <infinity> lamont: Sleep? At 8:30pm? <infinity> lamont: How old ARE you? <lamont> dude. she told me to come to bed.................... <infinity> That's not "sleep". <lamont> well, yeah. <lamont> however, in polite society, we say "sleep." :-) <lamont> and yeah, just out of the tub, dealing with getting the rest of the house to sleep <infinity> lamont: Kay. <lamont> and back to bed with me. g'night this time. <infinity> lamont: I was going to beg you to have a glance at the sparc/dash SIGBUS, since you're all smart and "community"ish. <infinity> lamont: But I'll poke at it on my own "community" time. * lamont will look in the morning. <lamont> look
{'channel': 'ubuntu-toolchain', 'month': 12}