#ubuntu-toolchain 2005-11-28
<doko> infinity: looks, like I messed up the archive ... did upload both gcc-4.0_4.0.2-4ubuntu3 and gcj-4.0_4.0.2-4ubuntu3, but didn't see the dependency libgcj6: gcc-4.0-base (= 4.0.2-ubuntu3), which did break with the ubuntu4 upload. now ubuntu5 doesn't build anymore ...
<infinity> doko : Yeah, we've noticed this.
<doko> infinity: anyway, just uploaded another package to build without gettext
<lamont> doko: another _what_ package?
* lamont notest that gcj6 is FTBFS on hppa (using the old stuff)
<lamont> doko: gcj-4.0 still build-depends debhelper, which is uninstallable...
<lamont> or do we just downgrade the chroots, I wonder...
<fabbione> morning
<fabbione> doko: why does gjc run the gcc testsuite?
<fabbione> gcj
<fabbione> make[3] : Entering directory `/build/sparcbuildd/gcj-4.0-4.0.2/build/gcc'
<fabbione> doko: ubuntu6 is still FTBFS
<infinity> doko : Meh, I'm going to jave to bootstrap this to unbreak it, aren't I?
* infinity puts that on his TODO for later tonight.
<fabbione> doko: please stop uploading now and give us the time to bootstrap it
<fabbione> otherwise katie is NOT happy about old binaries with new sources around
<fabbione> infinity: afaict it's debhelper that can't be installed
<fabbione> checking how to unroll the loop
<infinity> Unrolling it is simple enough.
<fabbione> infinity: yeah it gets down to gettext libgcj6 again
<fabbione> nothing fancy if you have the old binaries somewhere
<infinity> Yup, which is easy enough to fix.
<infinity> Easy enough if ou don't have the old binaries, too.
<infinity> dpkg has --force flags for a reason. :)
<fabbione> yeah
<fabbione> there we go
* infinity goes to fix things on the DC arches.
* fabbione looks at gcj build log and he can't understand why on earth it's building the all gcc to ship only java
<fabbione> this is like
<fabbione> cp gcc... gcj
<fabbione> vi debian/rules
<fabbione> upload
<infinity> Oh, cock.
<fabbione> what?
<infinity> E: Package libc6-dev-i386 has no installation candidate
<fabbione> eh?
<infinity> Oh, never mind, that's just apt being retarded.
<lamont-away> dpkg-gencontrol: error: package gcc-4.0-hppa64 not in control info
<lamont-away> dh_gencontrol: command returned error code 65280
* lamont-away beats doko with gcj-4.0
<fabbione> lamont-away: i won't be surprised if it will FTBFS on all arches at the end of the build
<fabbione> lamont-away: there is ubuntu6 out anyway
<fabbione> you might want to give it a shot
<lamont-away> did anyone start uploading new packages for the transition, or is that still waiting?
<lamont-away> that was ubuntu6
<lamont-away> gcj-4.0_4.0.2-4ubuntu6_20051122-1842
<fabbione> i think nobody is uploading giving that everything is FTBFS
<fabbione> and it will be until this gcj thing is fixed
<infinity> Well, gcj is being built right now in the DC.
<infinity> So you guys better sort your issues. :)
<fabbione> infinity: let see if it builds at DC :)
<fabbione> it might as well be FTBFS there too
<infinity> I have faith.
<infinity> Alright, gcj-4.0 has built on all the DC arches.
<fabbione> infinity: i hate you :)
<infinity> Meh, it doesn't matter anyway, doko messed up that upload too.
<fabbione> ah
<fabbione> how?
<infinity>   libgcj6: Depends: gcc-4.0-base (>= 4.0.2-4ubuntu6) but 4.0.2-4ubuntu3 is to be installed
* fabbione sighs
<doko> hrm, I shouldn't do uploads in the early morning ...
<doko> lamont-away: what is this thing about gcc-4.0-hppa64?
<infinity> doko : Thanks for the upload, I'll bootstrap it in 5 mins.
<doko> infinity: hmm, it should build on it's own?
* fabbione restarts the build AGAIN
<infinity> debhelper -> po-debconf -> gettext -> libgcj6
<fabbione> doko: is there any reason for gcj to build gcc and even run the testsuite?
<infinity> Anyhow, seedin chroots and doing manual builds right now.
<doko> fabbione: you have to build gcc to build gcj, yes, I'll disable the testsuite for all but libjava
<fabbione> doko: can't we use external gcc?
<fabbione> given that we build it with testsuite and stuff
<infinity> Okay, building everywhere.
<infinity> doko : Please don't upload again until these binaries are all installed.
<doko> fabbione: but then you'll miss the bootstrap comparision for gcj
<doko> infinity: yes ...
<fabbione> (including SCC please)
<fabbione> doko: hmm ok.. 
<fabbione> ubuntu7 building here
<fabbione> let's hope it's not FTBFS
<doko> Riddell: looks like you can't use 4.0 for KDE on hppa yet. See PR21123
<doko> fabbione: how far did the previous gcj-4.0 versions build?
<fabbione> about 3.6MB of log
<fabbione> probably more
<fabbione> let me check
<fabbione> 4708 -rw-r--r--  1 sparcbuildd sparcbuildd 4808189 Nov 23 06:32 gcj-4.0_4.0.2-4ubuntu5_20051122-2142
<fabbione> but then i did stop it
<fabbione> because of the new versions coming in
<fabbione> and gcj is not exactly ccache friendly
<infinity> It would be if it used the system compiler instead of bootstrapping its own. :/
<infinity> doko : I hope that's something you intend to fix before you push these changes to Debian...
<fabbione> it appears it can't be done
<infinity> Don't see why not.
<fabbione> fabbione doko: can't we use external gcc?
<fabbione> doko fabbione: but then you'll miss the bootstrap comparision for gcj
<doko> infinity: so ccache does understand java?
<infinity> Where there's a will, there's a way.
<infinity> doko : Oh, no, but isn't gcj itself in C?
<doko> think about it ... 
<infinity> Or does it build with gcj?
<doko> yes, you'll save about 10 source files
<doko> it's libjava which does consume the time
<infinity> Well, yes, libjava is huge and painful.
<doko> java doesn't know anything about "preprocessed source", so ccache is not possible
<infinity> But you're bootstrapping a full GCC as well here.
<doko> no, not full, just java
<infinity> Surely that can be done away with.
<doko> fabbione doko fabbione: but then you'll miss the bootstrap comparision for gcj
<infinity> doko : I see a full n-stage xgcc build going on here...
<infinity> With some makefile fiddling, I don't see why one couldn't start a bootstrap of gcj using the system C compiler, s'all I'm saying.
<doko> infinity: you can do that, but that's not longer a "bootstrap"
<infinity> (The eventual goal being to split out most of the esoteric compilers to their own self-contained source packages)
<infinity> doko : Sure, it's a gcj bootstrap, just not a gcc bootstrap.
<doko> no that's crap, and I won't do that
<Riddell> doko: yeah, I saw the debian guys had problems
<Riddell> doko: all other arches OK for gcc 4?
<doko> Riddell: looks so
<Riddell> doko: am I ok to start uploading?
<infinity> Riddell : Nothing will build until gcj is in the archive anyway.
<Riddell> bah, who uses gcj anyway :)
* infinity needs to do a mass give-back when that happens.
<doko> Riddell: gettext
<fabbione> java sucks
<fabbione> it should die 
<fabbione> infinity: a global give back is fine.. assuming ubuntu7 is ok 
* fabbione hides from doko
<lamont-away> doko: that's the gcj-4.0 build failure on hppa
* lamont-away patiently waits for -4ubuntu7
<lamont-away> http://buildd.mmjgroup.com/buildLogs/g/gcj-4.0/4.0.2-4ubuntu6/gcj-4.0_4.0.2-4ubuntu6_20051122-1842-hppa-failed.gz
<lamont-away> dh_testroot
<lamont-away> : # provide as and ld links
<lamont-away> dh_link -p gcc-4.0-hppa64 \...
<lamont-away> now that's amusing...  for gcj-4.0 :-)
<lamont-away> wow.  -4ubuntu7 started building 2.5 hours ago.  that's cool
<lamont-away> 2/3 of the way to where it died last time
<lamont-away> infinity: btw, thanks for dealing with all the DC architectures
<doko> lamont-away: it will fail again
<lamont-away> doko: I see.
<lamont-away> eta for -7?
<lamont-away> er, -8?
<lamont-away> I should just kill the build of -ubuntu7 then?
<doko> lamont-away: infinity did tell me to wait with a new upload until the packages are in the archive
<infinity> doko : They're in.
<doko> infinity, fabbione: sparc as well?
<infinity> Negative.
<infinity> When sparc has gcj binaries uploaded, you'll see them here:
<infinity> http://ports.ubuntu.com/ubuntu-ports/pool/main/g/gcj-4.0/
<infinity> I suspect it may have failed to build.. Or fabio's sparc is even slower than I thought.
<infinity> lamont-away : What's the URL for ports logs again?
<lamont-away> sparc has not sent a -4ubuntu7 log yet
<lamont-away> buildd.mmjgroup.com/buildLogs/...
<lamont-away> buildLogs/g/gcj-4.0
<lamont-away> Build needed 05:31:26, 878096k disk space
<lamont-away> that was to the failure point on -4ubuntu6
<infinity> Oh, ouch.
<infinity> Kay, it may be a while, then.
* lamont-away considers jumping up and down screaming that he "wants -4ubuntu8"
<lamont-away> fabbione: you admitting to being around?
<infinity> I think he took off over an hour ago.
<lamont-away> hrm.. actually, that -6 log is 5:31 to the point where he killed it
<lamont-away> and was working on stamps/05-build-stamp at that point
<lamont-away> doko: how confident are you that -4ubuntu7 will build on sparc?
<infinity> Modulo goofy packaging errors like hppa, it should work fine.
<doko> lamont-away: I don't see anything special on sparc, it's comparable to i386 and powerpc
<lamont-away> any reason for me to _not_ kill the hppa build of -7?
<doko> no
* fabbione yawns
<fabbione> sparc is building
<lamont-away> doko: and none of the transition uploads have happened yet, correct?
<doko> lamont-away: correct
<lamont-away> fabbione: how big is your log file?
<fabbione> 2.3M on ubuntu7
<fabbione> almost as long as my penis
<fabbione> it's a long way to go
<fabbione> what's the problem?
<lamont-away> hppa is ftbfs
<lamont-away> so we're waiting for sparc to upload and unblock before uploading -4ubuntu8
<fabbione> do you already have a fix?
<lamont-away> I expect doko knows the fix
<fabbione> doko: ?
<lamont-away> (it's trying to package something it didn't build...)
<fabbione> well if you want to upload ubunt8 go ahead
<lamont-away> E: Couldn't find package libgtk+2.0-directfb-dev
<lamont-away> that'd be why cdebconf keeps retrying every cron.daily
<fabbione> it just means if ubuntu7 does build i can use it from the local cache
<fabbione> if it doesn't sparc is screwed and we will ubuntu9
<fabbione> just go for it
<lamont-away> fabbione: sounds OK to me... doko?
<lamont-away> infinity: any objections?
<infinity> None here.  I already got all my binaries in. :)
<lamont-away> meh
<fabbione> i am not sure how long it takes to build.. and i am heading out to have dinner with my wife
<lamont-away> fabbione: you killed -6 at 5.5 hours
<fabbione> so it's unlikely i will look at the buildd for the next 12 hours or more
<lamont-away> ah, cool.
<fabbione> -5 went much deeper in the build
<lamont-away> doko: ready for that upload...
<lamont-away> 2142->0632 on that one
<lamont-away> about 9 hours
<fabbione> yeah and 4.8M of log
<lamont-away> before sbuild received SIGINT -- shutting down
<fabbione> gcc-4 takes about 19 hours to build here
<fabbione> so you can make your calculation
<fabbione> but again just go ahead
<fabbione> i will sort it out later on
<fabbione> gotta run and fast
<fabbione> i am late :)
<fabbione> cya later or tomorrow
<doko> fabbione, lamont-away: yes, I have a fix
<lamont-away> doko: may as well upload - fabbione will use -4ubuntu7 locally if it succeeds
<lamont-away> and if you upload in the next 11 minutes or so, it'll make the next cron.daily
<doko> lamont-away: done
<elmo> err
<elmo> I've  got  a bunch of c2a libraries in new
<elmo> should I be not processing them?
<doko> elmo: yes, should be safe, all buildd's are running the new gcc packages
<elmo> doko: kthx
<lamont-away> doko: hppa is running the old gcc
<lamont-away> since that's what has to be installed to build gcj
<lamont-away> gcj-4.0 build started
<doko> lamont-away: ok, but you can shut it down/upgrade after the gcj-4.0 build
<lamont-away> doko: yes
<lamont-away> given a .deb, how can I tell whether it is pre-transition or post-transition?
<doko> it depend on one of the libraries, which we are going to rename
<lamont-away> ok
<lamont-away> is krb4 one such animal, I wonder
<lamont-away> ?>
<doko> no
<doko> elmo: please sync boost, overwriting Ubuntu changes
<lamont-away> boost_1.33.0-5..
<lamont-away> ..failed updating 2 targets...
<lamont-away> ...skipped 2 targets...
<lamont-away> ...updated 1487 targets...
<lamont-away> make: *** [build-stamp]  Error 1
<lamont-away> doko: for extra credit, make it compile on hppa
<lamont-away> interesting... I wonder who uploaded it, since all Ihave is a build failure
<lamont-away> echo timestamp > javax/xml/datatype.stamp
<lamont-away> make[4] : *** [javax/xml/datatype.stamp]  Segmentation fault
<lamont-away> ew
<doko> lamont-away: didn't see that in unstable
<lamont-away> yeah, I've pushed it to the top of the hill again
<fabbione> ok ubuntu7 did build
<fabbione> so i guess i can just build ubunut8 and get along with it
* lamont-away is still known as lamont-away
<lamont-away> fabbione: you could even just drop ubuntu7 in your local cache and let it go from there
<lamont-away> and 8 will "just happen"
<fabbione> lamont-away: that's what i did basically
<fabbione> but i am prioritizing ubuntu8 to unsuck the other buildd
<fabbione> that's waiting for 7/8
<fabbione> but 7 will never hit archive
<fabbione> so...
<fabbione> 8 it is
<doko> Riddell: ping
<Riddell> doko: hi
<Riddell> doko: hmm?
<doko> Riddell: ?
<Riddell> doko: you pinged?
<doko> ahh, yes, arts upload?
<doko> Riddell: ^^^
<Riddell> doko: arts and kdelibs uplo
<Riddell> doko: arts and kdelibs uploaded
<doko> Riddell: thanks
<doko> elmo: please process the changed allocator packages in NEW, should be nearly all libs in main
<doko> ahh, crap, these are already in, but in universe ...
<Riddell> which are?
<doko> mdz: please can you promote: libgdome2-cpp-smart0c2a libid3-3.8.3c2a libwpd-stream8c2a libwpd8c2a, or do you need inclusion reports?
<doko> Riddell: ^^^
<Riddell> also libarts1c2a and kdelibs4c2a
<Riddell> also libakode2 and libakode-dev which are about to replace akode and akode-dev
<doko> Riddell: they are not yet in the anastacia output
<Riddell> ok, just fore-warning :)
<lamont-away> doko: 2nd try is past the first failure
<mdz> doko: the usual rules apply; if they're just package renames and not new code, they don't need reports
<mdz> doko: however, I can't do any promotions right now; elmo needs to do some maintenance on katie
<mdz> Riddell: amarok-gstreamer shouldn't depend on mp3 stuff
<Riddell> mdz: I'll investigate
<mdz> thanks
#ubuntu-toolchain 2005-11-29
* lamont-away wanders off for a while
<elmo> mdz: I'm done for now, the next stage will require some more scripting, which I can do out of band
<mdz> elmo: ok
<mdz> doko: done
<mdz> doko: please use source package names in the wiki
<mdz> reports are only needed for source packages anyway
<doko> mdz: thanks
<doko> mdz: please process NEW / main promotions of *c2a* binaries at the end of your workday again, if possible. I hope we can accelerate this thing a bit.
<doko> heading to bed now ...
<elmo> GRR
<elmo> E: libakode2 in dapper is in the overrides more than once.
<elmo> ERAHAERHGQ%#YQ#$%YQ#$%YQ%#YH
<Riddell> is that my fault?
<elmo> no
<mdz> elmo: must be mine then
<mdz> elmo: were you new-ing at the same time that I was?
<lamont> woo hoo.  gcj-4.0/hppa is in the install stage
<lamont> dh_movefiles: Compatibility levels before 4 are deprecated.
<lamont> bad gcj-4.0
<lamont> NOTE: The package could have used binaries from the following packages
<lamont> (access time changed) without a source dependency:
<lamont>   gettext: /usr/bin/xgettext /usr/bin/msgfmt /usr/bin/msgmerge
<lamont>   python-dev: /usr/bin/python
<lamont> it still build-depends gettext
<lamont> hppa is now unstuck and building
* lamont begins creating a second hppa buildd on a 4-way J7000
* lamont -> dinner
<Riddell> gcj-4.0: Depends: libgcc (>= 4.0.2)
<Riddell> shouldn't that be libgcc1?
<jbailey> Probably,  yes.
<Riddell> why isn't gettext-kde in anastacia?
<Riddell> mdz: gettext-kde main inclusion report http://wiki.kubuntu.org/MainInclusionGettextKDE
<elmo> Riddell: is it seeded?
<Riddell> no, new build-dep
<elmo> since when?  cron.sync only runs once a day
<Riddell> since about 6 hours ago
<Riddell> or whenever I uploaded new kde stuff
<elmo> yeah, wait a while; unfortunately germinate is an expensive operation for 6 arches + 3 distros, so it only runs once a day
<Riddell> right
<elmo> mdz: yes
<Riddell> anyone know where libjvm.so should be found?  it's wanted by kdebindings
<elmo> usr/lib/j2se/1.4/jre/lib/i386/client/libjvm.so              multiverse/devel/j2re1.4
<Riddell> hmm, multiverse, didn't think of that.  maybe best do without java bindings then
<lamont> elmo: still about?
<lamont> wanted to make sure that buildd@bld-4.mmjgroup.com wasn't going to cause barfage
<elmo> added
<lamont> danke
* lamont goes to actually hook said beast up to the network and power.
<chmj> is the archive still broken? 
<infinity> Define broken.
<chmj> broken = we can't start with the c++/kde uploads
<infinity> Have we not already been doing c++ transition uploads?
<infinity> I'm sure I've seen some.
<fabbione> yeah
<fabbione> at least a couple of libs
<infinity> gcj appears to be uninstallable, but if you're not building java stuff you should be okay.
<chmj> bah, I am building java stuff :-/
<chmj> mostly 
<infinity> Oh.  Sucks to be you, then. :)
<doko> yes, looks like it's a mistake
<fabbione> doko: since you are going to push ubuntu9, can you please disable the unrequired test-suites?
<fabbione> it will save some hours in building gcj
<doko> fabbione: they currently are disabled anyway
<doko> fabbione: 8 did succeed otherwise?
<fabbione> doko: yup
<chmj> is dapper gonna come with ai64 ? 
<chmj> or dapper+1 
<infinity> We won't officially release on ia64, afaik, but the ia64 port is fairly healthy.
<jbailey> SCCs don't "officially" release, or do you think it'll suck in other random ways?
* doko hides, we need -4ubuntu10 ...
<fabbione> doko: well be fast than
<fabbione> i didn't start building 9 yet
<doko> no, test build and install first.
<infinity> jbailey : I don't see ia64 sucking.  It looks to be in pretty good shape.
<lamont-away> elmo: mucho UNACCEPT mail... fix pls
<jbailey> infinity: I haven't tracked ia64 beyond glibc builds. =)  I thought SCC archs could release, but we just didn't care about them for security?
<lamont-away> doko: with a multi-hour build time, could you queue up your gcj fixes and upload them at once, instead of camm-style?
<doko> lamont-away: that was the last one
<lamont-away> doko: you're sure this time, eh?
<lamont-away> :-)
<jbailey> lamont-away: It's only fun if you can get all three of the primary arches buildds building your package at the same time.
<lamont-away> heh
* lamont-away throws fruit at jbailey
<jbailey> lamont-away: Isn't today the biggest holiday of the year in the US?  Does your wife know that you're at the computer? =)
<lamont-away> nah - the "canonical dead dude" holiday in a month or so is bigger.
* jbailey 's first thought was "Someone DIED?"
<lamont-away> (quote derived from _Bill_and_Ted's_Excellent_Adventure_.  Or was it Fast_Times?)
<jbailey> But, little c.  right.
<lamont-away> "so what you're telling me is that Napoleon was a short, fat, dead dude?" "Yeah."
<lamont-away> holidays tend to be commemorating dead dudes.
<jbailey> Sure.  The living that name holidays after them are usually the type that the US army is trying to get rid of.  Fairly actively. =)
<lamont-away> cute factoid on Fast Times...  One of the actors is "Nicolas Cappola", who later changed is name to "Nicolas Cage", to separate himself from nepotism charges because of his uncle (Francis Ford Coppola).
<lamont-away> lots of big-name 80/90's actors in that movie... all very young and very just-starting.
<lamont-away> wow. that's really on-topic.
<lamont-away> :-(
#ubuntu-toolchain 2005-11-30
<chmj> doko: ping 
<doko> chmj: pong
<chmj> doko: seems the new gij is broken 
<chmj> have a look at http://people.ubuntu.com/~charles/gij-errors.txt
<doko> what happens, if you directly use gij-4.0-wrapper?
<chmj> get same error 
<chmj> hmm, clean dapper chroot builds 
<doko> please wait for java-gcj-compat_1.0.44
<chmj> ETA ?
<doko> it was uploaded 12 hours ago
<infinity> And built and installed ages ago too, so what are you waiting for
<infinity> ?
<chmj> thats what the clean chroot used..
<infinity> Right, so blame doko. :)
<doko> chmj: did you adjust the ant home dir?
<doko> syncing from debian means now:
<doko> - replace the build dependency libant1.6-java with ant
<doko> - use /usr/share/ant instead of /usr/share/ant1.6
<doko> - the jar ecj-antadapter.jar is now found inside the ecj.jar
<chmj> yes, I did all that 
<chmj> the new chroot built fine 
<chmj> the old one doesn't build, even though I dist-upgraded
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: mind if i ask you to look at zlib merge?
<fabbione> i am glad to take another one from you
<fabbione> but the merge talks about ia32-libs
<fabbione> that i am not familiar with
<doko> fabbione: no, please delay that until jbailey has a libc6-i386(-dev) ready
<fabbione> doko: ok i am cool with that
<jbailey> doko: pitti and I will be talking in a few moments about the locales separation.  I'll try to do both in the same pass.
<doko> fabbione: please could you try to build gcj-4.1 on sparc (if you have free cpu time). it builds ok for me, but fails on the debian buildd (gcc-snapshot)
<lamont-away> doko: looking at http://buildd.mmjgroup.com/buildLogs/l/linux-source-2.6.15/2.6.15-4.5/linux-source-2.6.15_2.6.15-4.5_20051124-2047-hppa-failed.gz and trying to figure out why installing gcc-3.4-hppa64 left us with this error:
<lamont-away>  /build/buildd/linux-source-2.6.15-2.6.15/debian/build/build-hppa64/scripts/gcc-version.sh: line 12: hppa64-linux-gcc: command not found
<lamont-away> ah, because it's called /usr/bin/hppa64-linux-gnu-gcc-3.4
<lamont-away> is it supposed to be?
<lamont-away> jbailey: ^^^???
<doko> lamont-away: hmm, it should install an alternative
<lamont-away> doko: someone did, but it's dangling now.
<lamont-away> build-dapper/chroot-dapper/etc/alternatives/hppa64-linux-gcc -> /usr/bin/hppa64-linux-gcc-3.4
<lamont-away> and that file is not delivered by the package
<doko> ahh, ok, the kernel maintainers did sleep ...
<doko> it's hppa64-linux-gnu-gcc
<lamont-away> ok
<lamont-away> and you'll stop delivering the broken alternatives stuff next upload?
<doko> yes, that's gcc-3.4 only
<doko> anyway, have to run ...
<lamont-away> thanks
<fabbione> doko: it should be re-scheduled automatically pretty soon
<fabbione> gcj-4.1_4.1ds2-0ubuntu2: currently building
<fabbione> doko: ^^
#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 2006-11-27
* Starting logfile irclogs/ubuntu-toolchain.log
<Dvalin> doko: around?
#ubuntu-toolchain 2006-11-29
<Dvalin> doko isn't much around, is he?
#ubuntu-toolchain 2006-11-30
<Dvalin> fabbione: anyone around than doko who is wiz of gcc?
#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 2007-11-26
<jbailey> doko: ping
<doko> jbailey: pong
<jbailey> doko: Heya!  I was trying to catch you during your working hours earlier.  How much did I miss by?
<doko> jbailey: maybe by minutes; I did leave early today
<jbailey> Ah, too bad.
<jbailey> doko: I'm bouncing around dayjob tasks right now.  Mostly I wanted to check with you.  I hadn't seen a 2.7.1 announcement yet, and I don't see it on ftp.gnu.org
<jbailey> Did you mean 2.7-1?
<doko> jbailey: I did mean 2.7-1
<jbailey> Cool.  That's what I'm working with.
<doko> and: <CIA-4> debian-glibc: aurel32 * r2704 /glibc-package/tags/2.7-2/ (20 files in 9 dirs): Tag glibc 2.7-2
<jbailey> Yeah, I'll finish the merge I've got going now.
<jbailey> I'm hoping the thousand lines of Sparc patch made it into 2.7 upstream.
#ubuntu-toolchain 2007-11-27
<arthur-> doko: can I send a gcc-defaults diff to aurel32, for gdc? now that gdc-4.2 is comming...
<doko> why?
<arthur-> doko: because some package build-dep on gdc which is a virtual package, which is bad, and when we'll switch to gdc-4.2 it would be good to be able to keep 4.1 as the default on some archs where 4.2 would be problematic, for example
<doko> arh, why send them to aurel32?
<arthur-> doko: oh, I was just thinking you wouldn't have time to take care about this, and aurel32 told me he could commit himself if you were ok
<arthur-> doko: so as you prefer... :-)
<doko> jbailey: please don't drop the glibc patch which debian did drop (see #453072)
#ubuntu-toolchain 2007-11-29
<doko> jbailey: glibc ping (although I'm away for some hours now)
#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 2010-12-01
<alf_> does anyone know if gcc 4.5 has become more strict with regards to link order? (eg I can't build using gcc -o foo -lX11 foo.c)
<doko> alf_: ld --as-needed is the default. link order is relevant, so move the objects before the libraries
<alf_> doko: thanks, it turned out this was the fault of a program using AM_LDFLAGS instead of AM_LDADD.
