#ubuntu-toolchain 2005-09-12
<fabbione> morning
* netjoined: irc.freenode.net -> kornbluth.freenode.net
#ubuntu-toolchain 2005-09-13
<lamont> jbailey: doko: one of you want to take a look at http://people.ubuntu.com/~lamont/buildLogs/h/haddock/0.6-2ubuntu1/haddock_0.6-2ubuntu1_20050907-2011-powerpc-failed.gz and then figure out what the right fix to haddock is so that it'll build correctly on ppc64...
<lamont> for test-building, you'll need: deb http://people.ubuntu.com/~lamont/ghc6 /
<doko> morning
<doko> lamont: do we support ppc64?
<lamont> doko: that's the issue... we're running a 64-bit kernel on the buildd's, and 32-bit user space.
<lamont> hence the build failure.
<lamont> what we really want to know is whether the userspace is 32 or 64, and say the right thing accordingly.
<lamont> right now, it assumes that kernel-size == userspace-size
<fabbione> morning guys
<lamont> morning fabbione
<doko> lamont: ok, will look
<doko> lamont-away, jbailey, infinity: I can only reproduce this, if the chroot is started without linux32. maybe a buildd problem?
<lamont-away> doko_: it's possible that I trashed his change...
<lamont-away> sigh
<lamont-away> but I didn't think I had.
<lamont-away> I'll see about fixing that in a short bit - gotta get ready and head officewards shortly
<lamont> doko: I figured out my ppc64 issue... PEBKAC.
<doko> anyway, I did send you my guess: linux32 forgotten?)
<lamont> PEBKAC == "problem exists between keyboard and chair"
<lamont> and yes, it's precisely because I said 'sbuild ...' instead of 'linux32 sbuild ...'
<lamont> while manually bootstrapping
<doko> :)
#ubuntu-toolchain 2005-09-14
<fabbione> morning guys
#ubuntu-toolchain 2005-09-17
<elmo> lamont/infinity: any objections to a b-at rerun, all components?
<lamont> elmo: sounds good to me.
* lamont removes his old breezy-autotest logs
<jbailey> Anyone know if ben's going to be around today?
#ubuntu-toolchain 2005-09-18
<infinity> elmo : I have no objections to it, in fact, I sent dholbach your way.
<jbailey> w/in 4
<elmo> GRR
<elmo> lamont/infinity: royal's chroot is ghc-fux0red
#ubuntu-toolchain 2006-09-15
* Starting logfile irclogs/ubuntu-toolchain.log
<fabbione> score
<fabbione> gcc in edgy miscompiles silo
<fabbione> both 4.0 and 4.1
<fabbione> doko_: so.. what do you need to debug this one?
<doko_> does it work with -O0 or -O1?
<fabbione> getting there.. it takes ages to reboot the NIagara
<fabbione> it seems to be niagara specifc the problem
<fabbione> the netra boots fine
<fabbione> but the code is exactly the same
<fabbione> we are building with -Os
<fabbione> want me to switch to -O0 ?
<infinity> Try 0, 1, and 2.
<infinity> Could try 2 first, since the difference between 2 and s aren't many, and the problematic optimisations in that variance tend to be known.
<fabbione> gcc-4.1 -m32 -fno-stack-protector -O2 -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000    bin2h.c   -o bin2h
<fabbione> which one wins here?
<infinity> The last one, I think.  Not positive, though.
<fabbione> ok.. got rid of -Os
<infinity> (base)adconrad@cthulhu:~$ gcc -O2 -o hello2 hello.c 
<infinity> (base)adconrad@cthulhu:~$ gcc -Os -o hellos hello.c 
<infinity> (base)adconrad@cthulhu:~$ gcc -O2 -Os -o hello2s hello.c 
<infinity> -rwxr-xr-x 1 adconrad adconrad 7786 2006-09-15 18:40 hello2
<infinity> -rwxr-xr-x 1 adconrad adconrad 7754 2006-09-15 18:40 hello2s
<infinity> -rwxr-xr-x 1 adconrad adconrad 7754 2006-09-15 18:40 hellos
<infinity> So, the last one wins.
<fabbione> no.. i win.. i removed -Os :)
<infinity> ;)
<fabbione> -O2 -> no win
<fabbione> doko_: what was the last thing you read?
<doko_> just my sugestion to build with -O0 and/or -O1
<fabbione> -01 booting now
<fabbione> or better.. trying no
<fabbione> +w
<fabbione> -O1 -> no win
<fabbione> -O0 -> no win
<fabbione> so what's next?
<infinity> Assume it's not miscompilation, but rather incorrect code that was relying on an old GCC bug?
<doko_> do I understand it right, that the "hello" testcase is self-contained?
<infinity> Hrm?  hello.c was just a printf.
<fabbione> infinity: on both gcc-4.0 and 4.1? unlikely
<fabbione> infinity: and it works on one sparc but not another
<fabbione> note that i am building the same code as in dapper and it was working on both
<fabbione> so there is no code change in the middle
<fabbione> only the compiler
<fabbione> and that part is pure asm
<fabbione> written by davem ...
<infinity> If it's pure asm, then perhaps you're barking up the wrong tree here and you have a binutils bug.
<fabbione> hmm that's something to try
<fabbione> as soon as this mofo boots up
<fabbione> no luck downgrading binutils
<fabbione> so what is next guys?
<bluefoxicy> doko_:  ping?
<doko_> what's up?
<bluefoxicy> did you get my e-mail?
<bluefoxicy> (about potential global toolchain settings for Edgy+1)
<doko_> we usually prepare the toolchain before we open the archive for the next release. If you do have tested patches for new things, then you should have them prepared now. everything else should go into edgy+2
<bluefoxicy> Edgy+1 is not open yet is it?
<bluefoxicy> The patches I was primarily looking at are actually in Binutils CVS now
<bluefoxicy> (since some time around Jul 10 actually)
<bluefoxicy> http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html <-- there's the announcement and patches
<doko_> we usually don't use unreleased versions. If you would like to see some feature in edgy, please provide the patches as debdiffs, tested for more than one platform
<bluefoxicy> Edgy+1, not edgy.  Any idea where I can find the version planned for use to check if it made it down from CVS yet?
<bluefoxicy> I was hoping to discuss with you, infinity, and mdz at some point.. when's a good time?  You're probably all busy as hell preparing for edgy release (next month?)
<bluefoxicy> ok, it's in 2.17.50.0.3 at ftp://ftp.kernel.org/pub/linux/devel/binutils/binutils-2.17.50.0.3.tar.bz2    ....  It seems it's not in a released glibc (glibc has a patch that makes it use the DT_GNU_HASH during dynamic linking)
<bluefoxicy> but i don't know if Ubuntu uses the .50 releases or just the straight 2.16 2.17 etc line
<bluefoxicy> it looks like it's in .50.0.1 too
<bluefoxicy> either way Jelnek doesn't stick his changes in the ChangeLog because he's a brat :|
<doko_> the .50 releases are unsupported versions release by H.J. Lu. Again, if you do want to see it, post the debdiff's.
<bluefoxicy> Alright, yeah, I wasn't sure.
<bluefoxicy> that means i have to figure out how to make a debdiff... maintainer's guide probably has that
<bluefoxicy> <-- noob
<bluefoxicy> I have other things to do here, I'll come back to this in a couple days.
#ubuntu-toolchain 2007-09-10
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> doko: Is there anything in particular you need help with right now?
<doko> glibc merge from unstable?
<jbailey> Err.  It's September 10th, dude.  Aren't we a month late for that?
<doko> sure, then extract the fix
<jbailey> for James' bug?
<jbailey> The IPv4 DNS round-robbining one, that is.
<jbailey> Or rather, the failure to do it.
<doko> right
<jbailey> Sure.
<jbailey> That'll be a nice warm up to me getting chroots setup and such.
<doko> jbailey: and then, I'm wondering if a new gdb would be more helpful than the old one
<jbailey> I haven't followed gdb lately, what's up?
<doko> they are preparing for a release in september
<jbailey> Ah, new features and such?
<jbailey> That probably would be nice to have in now if the next release is an LTS one.
<doko> more bug fixes
<jbailey> * Resolved 101 resource leaks, null pointer dereferences, etc. in gdb, 
<jbailey> bfd, libiberty and opcodes, as revealed by static analysis donated by
<jbailey> Coverity, Inc. (http://scan.coverity.com).
<jbailey> And a couple handy c++ improvements.  I suspect it's worth it.  But again, we're a ways past UVF.
<lamont> sounds like a new gdb would be wonderful.
<lamont> speaking of gdb... jbailey: got a patch for offsets.h yet?
<jbailey> lamont: Nope, but I do have stuff setup on gsyprf11 now.
* doko didn't want to be that direct and let somebody else ask =)
<lamont> heh
<jbailey> So at least I've got an hppa box to play with again.
<lamont> doko: I'm poking elmo to see what we can do to get the dev-machine for ia64 up in the DC as well
<jbailey> Hmm.  My 20% time is supposed to be directly useful to Google.  I wonder if "Keeping the Canonical toolchain maintainer and an archive admin happy" counts.   Let's assume yes. =)
* lamont also really wants to make time to understand the diffs between doko's A500 and lamont's A500, and why gcj-4.2 only works on the former.
<lamont> jbailey: sounds about right
<lamont> google's big on ubuntu
<doko> lamont: sorry for the noise, but ia64 did become worse during gutsy
<jbailey> My dapper chroot is just updating to gusty atm, and my new ssh key is in on launchpad.
<lamont> yeah - it gets neglected by me large parts of the tiem
<jbailey> lamont: Is my LDAP password supposed to work when connecting from the outside world to gsyprf11?
<jbailey> Or is it only when hopping through 10?
<jbailey> Or if helps if I use the right username.
<jbailey> Whee, so I'm in to gsyprf11 from my work account now.
<lamont> jbailey: it doesn't care where you come from, just that you spell your username/pass the same :)
* lamont is building a dapper git-core
<lamont> well, dapper-backport of current gutsy git-core
* jbailey lunches
#ubuntu-toolchain 2007-09-11
<jbailey> The hppa box I have access to (gsyprf11) doesn't have the build-dep's installed for gdb, so I'm trying to figure out how to get those in.  glibc next.
<jbailey> (lamont got palo already)
<jbailey> l_: *poke*
#ubuntu-toolchain 2007-09-13
<arthur-> doko: D ping
<arthur-> doko: do you plan to upload gcc 4.1 -17 soon? I'm in contact with upstream and he has checked in some Debian patches (kfreebsd-gnu port) and perhaps fixed the sqrt bur on powerpc
<arthur-> doko: so I have to update SVN, I'll try to do it the evening
<doko> no, currently not.
<arthur-> ok, thanks
<arthur-> have a nice day
#ubuntu-toolchain 2015-09-10
<thell> Hello, I'm looking at the ppas for both ubuntu-toolchain-r and /test and am wondering why vivid isn't listed in ubuntu-toolchain-r and the entries for vivid in /test are older? I was looking to add the ppa to a build script to get the latest gcc binary ...
<thell> ping doko ^^
<thell> I'll just have the ppa point at /test for now and have 5.1 install instead of 5.2, it won't be long after wily is released for repos to have wily binaries.
<doko> sorry, ENOTIME, but usually I'll only update for the LTS releases
<thell> doko: kk, thanks for the notice on that. I'm in the gap... nothing new :) 5.1 will work until Wily :) Have a good day!
