#ubuntu-toolchain 2005-08-15
<lamont> doko_: btw, sid's buildd is totally clusterfied atm, too.
<lamont> same toolchain issue.
<jbailey> doko_: lib64g2c0_3.4.4-6ubuntu4_i386.deb
<jbailey> doko_: (Insert utf-8 thumbs-up icon here)
<lamont> jbailey: any hints on the _GLOBAL_OFFSET_TABLE_ borkage issue?>
<lamont> (hppa, although istr fabbione bitching about something similar on sparc...)
<jbailey> lamont: Got something I can read about it somewhere?
<jbailey> HAving a broken GOT would really suck. =)
<lamont> uh, yeah.
<lamont> for i in build/chroot-unstable/usr/lib/*.so.*; do x=$([ -f $i ]  && objdump -T $i | grep _GLOBAL); [ -n "$x" ]  && echo $i $x; done | wc
<lamont>      25     200    2600
<lamont> that's a virgin-ish buildd chroot
<lamont> just load current sid on an hppa box - then look at libz
<lamont> or current breezy.
<lamont> both are rather b0rked
<lamont> build/chroot-unstable/usr/lib/libz.so.1.2.3 000234a0 g DO *ABS* 00000000 Base _GLOBAL_OFFSET_TABLE_
<lamont> jbailey: oh, and the best part is that it segv's fakeroot on 90%+ of builds.
* jbailey blinks
<jbailey> Any idea when this started?
<doko_> lamont: breezy as well?
<lamont> doko_: same issue
<lamont> the fakeroot b0rkage is timed with gcc-2.3.5 going into the chroot
<lamont> zlib is a wonderful test case, since it takes < 2 minutes to build on an a500
<doko_> lamont: and we didn't notify this earlier?
<lamont> doko_: it takes a while to notice the fatality of it all, since one object with it exported isn't fatal
<doko_> :-(
<lamont> been trying to get attention on it for a few days now, but then it was just breezy that was broken, and noone cares about breezy/hppa.. :-(
<lamont> but now that sid
<lamont> 's broke....
* lamont will be leaving the office semi-soon, and outside of one or two passes in the next 13 hours, offline until sunday evening UTC-0600
<jbailey> lamont: I need to hunt bdale down so that I can get my access on j5k restored.
<lamont> bdale was mumbling about a hectic day today, tomorrow travelling, and thursday picking up the reigns on debian's  buildd sigining for me (ia64/hppa)
<jbailey> Hmm.  thu-mon I'm travelling so I guess I won't sync up with him until next week.
<jbailey> Thu I'll be online subject to the grace of wifi connections at the chicago airport.
<lamont> ---Mutt: =buildd/universe [Msgs:1692/6648 New:6644 Post:3 341M] ---(subject/date)------------------------(1%)---
<lamont> there's something wrong with that picture
<jbailey> That is 341MB for the mbox, not for the message, right?
<lamont> right
<lamont> that's the index page
<jbailey> amd64 test glibc build going.
<jbailey> infinity: If this works, I have some fun for you. =)
* jbailey pokes infinity Awake yet?
* infinity grunts.
<infinity> jbailey : pong.
<jbailey> infinity: Hey
<jbailey> I thougt I was ready for the upgrade dance, but then I discovered that my glibc build had frozen (the testsuite doens't like my chroot)
<jbailey> And then I reran it without -nc.
<infinity> Sweet.
<jbailey> So soonish, I'll have finished the testing.
<jbailey> Unless you want to start now with the pieces that we know about either way. =)
<infinity> I'll wait for you to be sure it's all good to go, then you can hand me the whole mess.
<jbailey> infinity: 'k
<jbailey> infinity: Found a slight bug in the final amd64 install (native)
<doko> infinity: the OOo2 build did fail, because it couldn't find the archives?
<infinity> doko : On i386?
<doko> yes
<infinity> That's a transient error that always results in an auto-give-back.
<doko> so it's currently building?
<infinity> It's building right now on rothera, and seems t obe doing fine.
<doko> wow, finally :-)
<infinity> Yeah, I'm keeping an eye on it.  I'd kinda like to see it build. :)
<jbailey> feh, stat spits out numbers in hex.
<jbailey> I need them in decimal.
<jbailey> Heya doko.  I found one tweak that I needed to do in the amd64 native build.  Testing the i386 biarch build and then I hand it to Adam. =)
<jbailey> In about 20 minutes thanks to ccache. =)
<jbailey> I think, anyway.
<jbailey> Time is an illusion.  Lunchtime doubly so.
<doko> glibc biarch build?
<jbailey> doko: right.
<infinity> ccache and I are going to get married and have babies.
<jbailey> infinity: Is that so you don't have to remember how?
<infinity> See, if you could just take the high road for once and not go for the nerd interpretation... :)
<jbailey> Mm, I suppose
<jbailey> I wonder if I could detect a succesful ccache hit somehow and force make -j 500 after that?
<infinity> watch ccache -s, see if the hits are going up, if so, clean and restart with -j 500?.. I dunno.. Ugly to automate it, easy to do by hand.
<jbailey> Woot, looks good.
<jbailey> sending her up.
<infinity> Where to?
<infinity> And do you have nice instructions on what order this stuff needs to be bootstrapped in?
<jbailey> infinity: The idea is that you fill the chroot with the pieces from all three, and then you should be able to just build it all.
<jbailey> It's going into chinstrap:~jbailey/i386-amd64
<infinity> doko : I assmue the OOo2 build failure on amd64 is expected (or, at least, understood)?
<infinity> jbailey : No particular order I should need to build them in?
<infinity> jbailey : Since they're all ready to go, I guess that makes sense.
* infinity will just do something random and see how it goes.
<jbailey> Right. =)
<jbailey> All the build-deps will be satisfied already, you're just masturb^Wrebuilding them.
<infinity> And the source packages are signed?
<infinity> So once I've done the initial bootstrap, I can upload the sources and have them rebuild again?
<infinity> (Not like I couldn't sign them myself, but I want all this stuff signed by you anyway, so I have a scapegoat if you root us...)
<jbailey> Dude, if I root you, I'd be sure you never kne.
<jbailey> +w
<jbailey> It's not like a kernel root, where you might replace it with one you built yourself.
<jbailey> Only insane people build their own glibc.
<infinity> I always build my own custom glibc, yo, cause that's the l33t thing to do.
<infinity> I turn on the sooper sekrit options.
<jbailey> Dude.
<jbailey> lamont told me that -pipe is a known optimisation that Ubuntu is using.
<jbailey> Make sure to use *that* on your build.
<infinity> I use -fno-slow-code, it really helps.
<infinity> Does this need to be bootstrapped on all 4 arches, or is it just one or two that need by-hand love?
<doko> infinity: yep, the build is missing a bit ... (exit 63)
<jbailey> infinity: i386 only.
<jbailey> infinity: amd64 migiht be tomorrow. =)
<infinity> Alright, cool.
<infinity> rsync?
<infinity> paranoid about scp cutting out?
<jbailey> rsync is apparently faster.
<jbailey> I've read a number of rants about scp having buffering issues that somehow rsync over ssh doesn't have.
<infinity> Interesting.
<infinity> I have such shit upstream, and shit bandwidth/latency to the DC that I really wouldn't care or notice.
<jbailey> I usually don't care, except that this takes so bloody long as it is, I can't bear to make it longer.
<infinity> Heh.
<infinity> jbailey : Where's the glibc?
<jbailey> infinity: Dude, gcc-3.4 ihasn't finished going up yet.
<jbailey> karlheg: Hey!
<jbailey> karlheg: I just pushed initramfs-tools 0.16 up.
<infinity> jbailey : Hrm, I didn't see any rsync tempfiles...
<infinity> jbailey : Still don't.  So I kinda assumed you'd stopped uploading.
<jbailey> karlheg: I still haven't integrated everything from you, I needed to push this stuff first.
<jbailey> Hmm
<jbailey> That ssh session appears to be hung
<infinity> jbailey : And, you have stopped.  At least, there's no rsync processes on chinstrap.
<jbailey> In fact, Angie machine appears to be hang.
<jbailey> No, just the network
* jbailey resets her machine.
<jbailey> infinity: See?  Another good reason to use rsync.
<infinity> Heh.
<infinity> I fall back torsync when my first scp fails. :)
<infinity> (which isn't often)
<jbailey> Have network again.
<jbailey> So it just sort of went insane.  Lovely.
<jbailey> I now have a ping running as well.
<infinity> Dude, why are you sending the orig?
<infinity> No wonder you complain about how long it takes. :)
<jbailey> I thought I'd be polite and not make you fetch it.
<jbailey> I'll remove them from the next ones.
<infinity> Well, that's sweet of you, but still. ;)
<jbailey> I was mostly complaining before because the session was hung, I think.
<infinity> Yeah, I wouldn't complain if I had your upstream.
<infinity> Looks to be, what?  1Mbit or so?
<infinity> Mine's 256 kbps.
<jbailey> A little less ;)
<jbailey> Yeah, sucks to be you.
<infinity> Thpt.
<jbailey> But we were the first kids on the block with 1200bps modems too, so nyaah
<infinity> Pfft, I revel in my oldskoolery with the 110 baud accoustic coupler in the closet.
<jbailey> You still have yours?
<infinity> Yeah.
<infinity> Tossed most of the ones in between.
<jbailey> Our 50bps and 110bps modems are barely at the edge of my earliest memories.
<jbailey> I do remember the 300 clearly.
<infinity> The coupler is somewhat of a novelty, so I kept it.
<jbailey> "For novelty use only"? 
<infinity> My 300 was my first self-contained modem.  FANY.
<infinity> No phone required.
<infinity> s/FANY/FANCY/
<jbailey> Our 300 would auto-answer (That's how we ran the bbs), but we had to use the rotary to dial in.
<infinity> Then the 2400bps Hayes "smart" modem.  Still not sure what was so smart about it.
<jbailey> The AT command set.
<infinity> Yeah, brilliant.
<jbailey> Hayes sold two lines.
<jbailey> And then the US Robotics 9600 SysOp deal.
<jbailey> Everyone openning BBSs for a month so they could get a cheap modem.
<infinity> I skipped 9600, but got a USR 14.4/16.8 Courier DST.
<infinity> I was so l33t.
<jbailey> Ah, I took a detour with the telebit trailblazer.
<infinity> And then we upgraded the BBS to 12 lines, all with ZyXEL 19.2's, just cause we got a volume deal on them.
<jbailey> Upside: Unlike hayes, it got the speeds that it claimed.   Downside: Unlike hayes, noone else had one.
<infinity> No one else had a 19.2, but like we cared, we were COOL.
<jbailey> Creepy.  What software?
<infinity> TBBS.
<jbailey> Ah, I did rbbs-pc and then..
<jbailey> maximizer?
<jbailey> I can't remember what it was called.
<infinity> Wow... TBBS.org... Neat... I had no idea anyone still used it.
<infinity> Old fans die hard, I guess.
<jbailey> infinity: Get better ago.
<jbailey> amo
<jbailey> Because you KNOW the g and the m are close on the keyboard.
<infinity> Fat fingers.
<jbailey> Reminds me.
<jbailey> In Toronto you can get doughnuts delivered.
<infinity> !
<infinity> Krispy Kreme?
<infinity> If so, I'm moving.
<infinity> doko : OOo2 on i386 looks successful.
<infinity> doko : dpkg-shlibdeps really hates you, though.
<jbailey> Yeah, KK
<doko> infinity: great!
<jbailey> infinity: W00h00
<jbailey> It should be there.
<doko> infinity: I'm unable to reproduce the failure of expect-tcl8.3 on i386. even the configure check on the buildd looks correct to me.
<doko> speeding up grep on amd64 by a factor of 40 ...
<jbailey> doko: Eh?
<jbailey> ccache for grep?
<jbailey> =)
* jbailey wonders what sort of speedups in life would be possible if sha1 hashes were stored as metadata in the filesyste,
<infinity> doko : I can't reproduce it either, neat.
<doko> infinity: so try again?
<doko> jbailey: not exactly, but the debian patches seem to add something, what is not optimized by -O2 ...
<doko> I did have to wait some minutes for grepping 600MB language data ...
<infinity> doko : I am retrying them.  Then again, it wasn't that long ago that they failed, so I don't have high hopes.
<doko> infinity: ok, and what to do, if they fail again?
<infinity> Dig deeper, I guess.
<doko> infinity: so, I don't have access to the buildd :-)
<infinity> Yes, I know.  I'll look into it.  Right now, I'm working on some bootstrapping issues.
<infinity> And it's also 2am. :/
<doko> infinity: gcc/glibc?
<jbailey> doko: It seems to have shown up with a symbol error on his build.  I've asked him to paste it here in case it's something obvoius to you.
<jbailey> Dunno why it didn't show up here.
<doko> nice ... :-/
<infinity> http://people.ubuntu.com/~adconrad/
<infinity> That was building against Jeff's gcc and glibc.
<infinity> I could try again against the glibc I just built, if that may make a difference.
<jbailey> It ought not to.  Those were all clean builds from yesterday using my own builds.
<infinity> Well, yes, I was assuming it shouldn't make a difference, hence the not installing new packages between builds.
<infinity> Was just going to build all three, install them all, then kick fresh rebuilds via wanna-build.
<jbailey> Lemme do a test in my chroots with -lm
<infinity> But.  Y'know.  Nothing's ever simple.
<jbailey> Oh.
<jbailey> *sigh*
<jbailey> Symlink points to /lib.  I thought I had fixed that. =(
* jbailey boggles.
<infinity> In glibc?
<jbailey> Erm.
<jbailey> Right
<jbailey> But I've build gcc-3.4 with this glibc.
<infinity> Toss me a patch, and I'll rebuild glibc.
<jbailey> Oh, I know what happened.
<jbailey> Hmm.
<jbailey> I need to think about this for a sec.
<jbailey> This was the fix for amd64 native.
<jbailey> then I did a build test of i386-amd64 biarch
<jbailey> Didn't rebuild gcc-3.4 after that.
<jbailey> *sigh*
* jbailey wants a real multiarch setup
<infinity> Wasn't that supposed to be halfway there for breezy?
<infinity> I was kinda surprised to see lib/lib64 popping up all over, personally.
<infinity> I thought we really, really didn't want that.
<doko> infinity: yeah, that doesn't exist on m68k ;-P
<infinity> doko : Thpt.
<doko> infinity: it makes ia32-libs a bit lighter
<doko> gets rid off amd64-libs
<jbailey> infinity: The problem isn't we don't have a better mechanism for handling biarch atm.
<jbailey> I really have to wonder if ia32-libs can *actually* still be built atm.
<doko> yep, you now have a build dependency on amd64-libs :-)
#ubuntu-toolchain 2005-08-16
<jbailey> infinity: ping
<jbailey> Fixed the bug.  I needed to be far less clever than I was trying to be at 4am. =)
<jbailey> infinity: I'm uploading now.  You'll notice two glibc directories. Clever inspection will show that I followed your advice and moved the .orig. file out of the way so that my rsync was faster.
<jbailey> Consequently my rebuild didn't involve an orig file.
<jbailey> So don't use that source, but the binaries will be good in the glibc-debs.  The proper source will be in glibc-source. =)
<doko> jbailey: heh, nice. are these on chinstrap as well?
<jbailey> Yup, all on chinstrap.
<jbailey> I'm just generating the source now
<jbailey> All there now
<jbailey> in ~jbailey/i386-amd64
<jbailey> doko: ping?
<doko> jbailey: pong (seems to be later for you)
<jbailey> Eh? =)
<jbailey> It's only 01h40 here.
<jbailey> But I am about to go to bed.  Is t here anything else you need from me before I fall asleep?
<doko> not, if biarch works :-)
<jbailey> All the stuff is on chinstrap, and I have tested building binaries (The problem with the stuff that infinity had was symlink mistakes in everything *but* libc and libpthread)
<doko> replacing the amd64-libs stuff can be done later
<jbailey> Yup
<doko> I'm talking with Mithrandir for the ia32-libs update
<jbailey> Cool.
<jbailey> My only wishlist there is for libasound. =)
<jbailey> Without it Cedega (transgaming wine) can't do alsa on amd64 =)
<doko> ok, I'll ask
<jbailey> Thanks
<doko> so, have a good night
<jbailey> Thanks, and good morning to you. =)
<doko> I'll need a nap today, did only sleep 4 hours
<doko> infinity, jbailey: please use the gcc-4.0 from my home on chinstrap, not jbailey's version. contains an addtional fix for a bug in the java frontend
<infinity> doko : Alright, I assume it also includes all of jbailey's work?
<doko> infinity: yes
<infinity> Okay to use his gcc-3.4 sources though>
<infinity> ?
<doko> yes
<jbailey> doko: Is that the wrong code fix for Java?
<doko> jbailey: yes
<infinity> gcc-3.4's in the testsuite.  That's looking promising.
<jbailey> infinity, How's the i386-amd64 stuff going?
<doko> jbailey: he just uploaded it
<jbailey> Ooo Ooo Ooo
<jbailey> Ah, I see the glibc notice in my email.
<jbailey> Handy. =)
<infinity> Yeah, uploaded, the final (official) build is spinning on i386 with a chroot pre-seeded with known-good packages from my last build.
<infinity> All should go smoothly.  I hope.
<jbailey> I hope too. =)
#ubuntu-toolchain 2005-08-17
<doko> dh_shlibdeps -pzlib1g-udeb -pzlib1g-udeb -lbuild-tree/zlib-1.2.3
<doko> /usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute binary file
<doko> dpkg-shlibdeps: failure: ldd on `debian/zlib1g-udeb/usr/lib/libz.so.1.2.3' gave error exit status 1
<doko> dh_shlibdeps: command returned error code 256
<infinity> That looks... Ungood.
<doko> yes ...
<doko> that's i386
<doko> the glibc amd64 packages are still in NEW
<infinity> Ahh, that would do it, yes.
<doko> ?
<doko> infinity: the new lib32gcc1 has a bug: it depends only on ia32-libs, which becomes a bit nasty ... I did upload a new gcc-4.0 which changes the dependency to libc6-i386 | ia32-libs
<doko> elmo: please don't ack the glibc packages in NEW, before the new gcc-4.0 was built (using the glibc packages from NEW)
<elmo> there's nothing in NEW
<doko> libc6-i386 ?
<elmo> n-o-t-h-i-n-g
<doko> yes, but where is libc6-i386 ?
<ajmitch> elmo: can you kill off editex from universe? it's removed from debian now
<elmo> one wasn't built
<elmo> doko: please check this stuff out yourself, it's pretty obvious from the build log
<elmo> ajmitch: 
<elmo>  + done
<ajmitch> thanks
* doko wonders ...
<doko> elmo: non-main-in-main-or-universe.txt
<doko> lucene & eclipse are ok
<elmo> ok
<doko> the hype packages need to be removed. the are derived from latex (GPL), but distributed under the LGPL
<elmo> wtf; how does that work?
<elmo> how are they even in Debian?
<doko> nvidia-kernel-source is part of l-r-m
<infinity> doko : There was no libc6-i386 built in this run, are you thinking of libc6-amd64?
<doko_> infinity: no, just thinking that jbailey would prepare both architectures for biarch at the same time.
<infinity> No, he did i386-amd64 first, then will feed me amd64-i386 later, apparently.
<infinity> Not sure if it was  alack of time thing or a "one change at a time, see how badly it breaks" thing.
<infinity> The latter makes sense, though.
<doko_> elmo: http://sourceware.org/ml/binutils/2005-08/msg00190.html
<elmo> the --as-needed stuff?
<elmo> if so, I saw it
<doko_> yes
<doko_> infinity: dpkg on one amd64 build still segfaults, oopenoffice.org2-amd64 is the victim
<elmo> that only affects Debian right?
<doko_> and fabbione's sparc ...
<elmo> ok, but not ubuntu's primary platforms, I mean
<doko_> no
<elmo> ok
<infinity> doko_ : Yes, known issue, working on making it happy.
<elmo> dpkg: error processing /var/cache/apt/archives/libatomic-ops_1.0-1_ia64.deb (--unpack):
<elmo>  trying to overwrite `/usr/lib/libatomic_ops.a', which is also in package libatomic-ops-dev
<doko_> elmo: will fix it
#ubuntu-toolchain 2005-08-18
<desrt> elmo; word?
<desrt> elmo; daniels said that i should talk to you because i got yaboot working properly on a headless xserve
<desrt> elmo; unfortunately, my fix prevents it from working properly on a powermac with a monitor... so i'm going to try and do a better fix on monday
<desrt> elmo; i'll keep you informed, i guess :)
#ubuntu-toolchain 2005-08-19
<zul> where did the /topic go?
#ubuntu-toolchain 2005-08-20
<fabbione> morning
#ubuntu-toolchain 2005-08-21
<fabbione> morning
<lamont> jbailey: if you're bored (or doko is) and want to help kyle with the gcc patch to fix GOT, that'd be really cool....  I really don't know if we have the same issue in gcc-3.4 or not, but I kinda fear that we do.
<jbailey> lamont: Is he in #parisc?
<jbailey> I don't really have time at the moment, but I'd like to at least follow his thoughts.
<doko> lamont: which one?
* lamont digs
<lamont> Aug 15 17:42:06 <tausq> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00923.html
<lamont> Aug 15 17:42:16 <tausq> ^ jda's proposed patch for the glibc cffc problem
<lamont> hrm... although that may or may not be the GOT issuel.
<lamont> gcc.gnu.org/PR23369
<lamont> actually, while very interesting, I don't think that's actually the GOT issue.
<doko> lamont: yes, I can add this one for breezy as well, that's hppa only
<lamont> doko: thanks.  NFC if that fixes the GOT issue or not, but if you upload something with it in, I'll hammer through testing it
#ubuntu-toolchain 2007-08-13
* Starting logfile irclogs/ubuntu-toolchain.log
<lamont> doko: is there any reason to have gcc-3.4 (the binary) in main in gutsy?
<lamont> I expect that there are still packages that need/want gcc-3.4-base
<doko> lamont: grub, plus it's a dependency of g77-3.4
#ubuntu-toolchain 2007-08-14
<lamont> doko_: ah, ok
<lamont> doko_: btw, I'm planning to upload gcc-defaults (dropping hppa/java for now) sometime tomorrow US-time.
<lamont> I would have done it earlier, but I had some issues with the workstation I was using.
<doko_> lamont: still now debugger for hppa?
<lamont> no.  and no jbailey atm either.
<lamont> so easiest to upload about 8 packages dropping java support for the moment - if we get it in before release, we'll turn it back on
<lamont> otherwise we turn java back on for gutsy+1
<lamont> wow.  bedtime for real
#ubuntu-toolchain 2007-08-15
* Starting logfile irclogs/ubuntu-toolchain.log
<lamont> doko: and could you get me an address for that java guy and I'll see what I can toss his way
<lamont> or point him at lamont@h.c
<lamont> or any of my other addresses
<doko> lamont: join #gcj on oftc
* Starting logfile irclogs/ubuntu-toolchain.log
#ubuntu-toolchain 2007-08-16
<lamont> doko_: gdb to go with the gutsy-stage0 hppa archive: http://people.ubuntu.com/~lamont/gdb_6.6.dfsg-1ubuntu4_hppa.deb
#ubuntu-toolchain 2016-08-15
<wemeetagain> is there any documentation/information about how ubuntu is handling the transition to the c++11 abi?
<wemeetagain> and are c++ packages in 16.04 compiled with dual abi/c++11 abi support? is this planned for yakkety or the future? 
#ubuntu-toolchain 2016-08-17
<N3o> hello guys!
<N3o> I have a short question regarding the installation of a specific gcc version on 12.04 LTS: was gcc 5.3.1 built for 12.04?
<N3o> I was looking on https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=precise and saw only 4.x or 5.4
