#ubuntu-toolchain 2006-01-09
<fabbione> doko:
<fabbione> dpkg: error processing /var/cache/apt/archives/openoffice.org2-common_2.0.1-0ubuntu2_all.deb (--unpack):
<fabbione>  trying to overwrite `/usr/lib/openoffice2/help/en/sbasic.idx/DICTIONARY', which is also in package openoffice.org2-help-en-us
<doko> fabbione: upgrade from which version?
<fabbione> doko: ubuntu1
<doko> hmm
<fabbione> this was on amd64 btw
<fabbione> it that's of any help
<doko> ahh, yes, thinko ... the english help is built by both source packages, but not removed in one build
<jbailey> I'm quite surprised that there's no negative feedback on dropping pre-i686
<jbailey> I figure we should give Matt until the end of the week to catch up on his email, though.= )
<doko> jbailey: you're avoiding Matt's irc nick name so it doesn't highlight? ;-P
<jbailey> *lol*
<jbailey> No, nothing like that.
<jbailey> I  pretty much always refer to people by real name rather than pseudonym.
<jbailey> But, I also nick highlight on "Jeff" =)
<doko> lamont, infinity: the buildd complains about: /bin/bash: line 1: ulimit: stack size: cannot modify limit: Operation not permitted
<doko> gcc-4.0 on ia64
#ubuntu-toolchain 2006-01-11
<fabbione> doko_: ping?
<fabbione> http://people.ubuntu.com/~fabbione/oo2-ftbfs.bz2
<fabbione> hey doko
<fabbione> did you read before?
<fabbione> http://people.ubuntu.com/~fabbione/oo2-ftbfs.bz2 <-
<fabbione> this is ubuntu3
<fabbione> the last one you did upload
<doko_> fabbione:  seen, don't see why. it's during the oo installation phase, so the build was ok
<fabbione> doko_: i still have all the chroot
<fabbione> anything you might need out of it?
<doko_> is there anything else important in /home/sparcbuildd/openoffice.org2-2.0.1/ooo-build/build/ooa680-m1/instsetoo_native/util/OpenOffice//logging/en-US/log_OOA680__en-US.log
<fabbione> doko_: getting to it
<fabbione> i have 2 secs latency to that box
<fabbione> doko_: log_OOA680__en-US.log.bz2 it's on people.u.c/~fabbione/
<doko_> regcomp.bin: pthread_mutex_lock.c:108: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
<doko_> strange
<doko_> fabbione: was this gcc-4.0_4.0.2-6ubuntu1, or the previous gcc?
<fabbione> it's the top of the build log
* fabbione checks
<fabbione> ah no
<fabbione> i need to login again..
<fabbione> Version: 4.0.2-5ubuntu2
<fabbione> i guess i will need to update and rebuild...
<fabbione> doko: i am going to rebuild with the new toolchain
<fabbione> do you plan to upload OOo2 again soon?
<fabbione> it will take a good 24 hours to get there again
<doko_> fabbione: no, but I really don't know where I get this error from, was glibc new?
<fabbione> yeps
<fabbione> i can't even start the build
<fabbione> some of the B-D are uninstallable
<fabbione> oh well
<fabbione> tomorrow
<fabbione> thanks a lot doko
<fabbione> i will let you know
<lamont__> fabbione: it's times like this when I'm glad no one has made oo.o work on hppa yet.
<doko> didn't tausq voluteer for it?
<lamont__> maybe slightly
<lamont__> but in any case, he's not _done_ with it and the patches in upstream
<lamont__> gcc-3.4 is built with gcc-3.4?  and glibc?
<lamont__> doko/jbailey: ^^^
<doko> lamont__: with gcc-3.4 as well
#ubuntu-toolchain 2006-01-14
<infinity> So, who feels like debugging the gcj-4.0 build failure on ia64?
<infinity> Without gcj-4.0, gettext (and debhelper) are uninstallable, so the world just ground to a halt for that port until it's sorted.
<doko> infinity: gcc-4.0 did build?
<infinity> On ia64?  No.  Probably hung up on the debhelper unistallable issue.  I can manually pre-seed the chroot to make gcc-4.0 build, and will gladly do so, if you think that'll magically fix gcj-4.0's build. :)
<infinity> I'll whack it with a stick first thing tomorrow.  It's bedtime now.
#ubuntu-toolchain 2006-01-15
<jbailey> doko: ping
<doko> jbailey: pong
<jbailey> doko: glibc uploaded last night.
<doko> jbailey: great!, I did see it, preparing the other packages now
<jbailey> doko: Cool.  Have they made it thorugh NEW?  If not, I think there are still .debs in ronne:~jbailey/amd64/glibc/
<doko> jbailey: no, not yet, will ping the masters of the archive
<jbailey> doko: 'kay.  Lemme know if you need anything.
<doko> jbailey, lamont, infinity: the glibc build did fail on amd64, I suspect gcc-opt problems again ...
<jbailey> Ah, I'm on a call, lagging.
<infinity> doko: gcc-opt shouldn't be breaking on amd64 like it was on i386, since we don't have a default tune on amd64..
<infinity> doko: And, for that matter, jbailey is setting his own march and mtune anyway, which would override ours, if we had one.
<doko> ok
<doko> jbailey: maybe you still need the ia32-libs-dev b-d for the first build?
<jbailey> doko: Yes, that looks more likely.
<infinity> Quite possible.
<infinity> I can just bootstrap it tomorrow.
<jbailey> infinity: If you're okay with that, I'm running quite short on time today.
<jbailey> Although that means I should make sure that a future upload b-d's on itself, too.
<infinity> jbailey: It won't hurt to fake it once, under the assumption it'll build fine a second time without it.
<infinity> If it needs a build-dep on itself, I can add that and upload a new one.
<infinity> After I do the bootstrap and prove that's the issue.
<jbailey> infinity: It is the issue.  It'll need libc6-dev-i386 [amd64]  added to the b-d in control.in/main.
* infinity nods.
<jbailey> infinity: What's the best thing?  It needs two uploads.  One built against ia32-libs, one built against libc6-dev-i386
<infinity> Nah, I'll bootstrap it with ia32-libs, then upload -0ubuntu4 with the libc6-dev-i386 build-dep.
<infinity> (After testing that it will, indeed, work, so the bootstrapped one isn't a strange fluke)
<elmo> LALALALALALALALALALALA
<infinity> Or, we can do 2 uploads, since elmo's watching.
<infinity> elmo : Can I get mysql-dfsg-5.0_5.0.18-3 synced from incoming, overwrite OK.
* infinity notes that lack of relevance for this channel, and decides to go to bed.
<doko> infinity: if we're going with two uploads anyway, I can do these now
<infinity> We don't generally do multiple uploads to bootstrap stuff.
* infinity remembers bootstraping biarch on i386, which involved crazy hand-compiled stuff that build-deps on itself, then rebuilding, blah blah.
<infinity> I see no reason why this should be any different, as long as -0ubuntu4 is the first version to hit the archive, and it's obviously built against the correct build-deps (generated from the bootstrapped -0ubuntu3)
<infinity> But if you want to do it in two uploads, go nuts.  It won't hurt any, except for CPU time, and Fabio and LaMont crying. :)
<doko> usually we do without manual bootstraps if we can? but it's long that I did hera lamont and fabbione squeak ;)
<jbailey> infinity: I'm just as happy with the bootstrap.
<jbailey> It means that I'm not doing a flood of uploads if a tiny problem is discovered.
<infinity> Well, if people don't flood incoming while I'm asleep, I'll do it my way in about 8 hours.
<fabbione> doko, jbailey i would be really glad if you can wait about 30/45 minutes before uploading the next glibc or whatever you have decided :)
<fabbione> ubuntu3 is installing as i write
<doko> fabbione: infinity will do the bootstrap
<fabbione> ok thanks
#ubuntu-toolchain 2007-01-09
<fabbione> jbehey dude
<fabbione> whops
<fabbione> jbailey: dude...
<jbailey> fabbione: yayaya
<jbailey> Fine, don't remember who I am.
<jbailey> See if my feelings are hurt... 8'{ *cRy*
<fabbione> (gdb) run
<fabbione> Starting program: /root/a.out 
<fabbione> we are set
<fabbione> Program received signal SIGUSR1, User defined signal 1.
<fabbione> 0xf7e9536c in nanosleep () from /lib/v9v/libc.so.6
<fabbione> (gdb) next
<fabbione> Single stepping until exit from function nanosleep, 
<fabbione> which has no line number information.
<fabbione> Program terminated with signal SIGILL, Illegal instruction.
<fabbione> The program no longer exists.
<fabbione> (gdb) That was all, folks
<fabbione> this is bad.. 
<fabbione> i can't figure why we are getting a SIGILL 
<fabbione> and only on Niagara machine
<jbailey> SIGILL is a kernel or processor trap.
<fabbione> i am afraid the last gcc updates are generating wrong code
<fabbione> because it's not triggered on non Niagara machines
<jbailey> That or the kernel is dissallowing something it should allow.
<fabbione> and usually that's a sign of badly generated code
<fabbione> unlikely
<jbailey> Depends on how the protection bits all work on Sparc.
<fabbione> i have seen a lot the other way around
<jbailey> Is there a test failure in either LTP or glibc's testsuite for it?
<fabbione> i have a reduced case
<fabbione> and i am trying to reduce it even more
<jbailey> Even better. =)
<fabbione> no idea about LTP or glibc
<fabbione> jbailey: can you get access to fluorine?
<jbailey> Well, you're looking at a glibc function yes?
<fabbione> from cr3?
<jbailey> I can, but don't have time for 4 to 6 hours.
<fabbione> i want to show you the code
<fabbione> feh ok
<jbailey> Sorry, my morning is lined up with customer appointments.
<jbailey> Does your reduced testsuite still call nanosleep?
<jbailey> Or have you extracted that out?
<fabbione> i am pretty sure the problem is either gcc or binutils
<fabbione> declaring an int foo; makes the code explode
<fabbione> removing that line = works
<fabbione> and that so should not happen
<fabbione> root@fluorine:~# gcc -Wall -g -O0 main.c 
<fabbione> root@fluorine:~# ./a.out 
<fabbione> root@fluorine:~# gcc -Wall -g -O0 main.c 
<fabbione> main.c: In function 'main':
<fabbione> main.c:36: warning: unused variable 'i'
<fabbione> root@fluorine:~# ./a.out 
<fabbione> Illegal instruction
<fabbione> doko: ping?
<jbailey> Right, so once you've got that, do a disassemble and a stepi to find the offending instruction.
<fabbione> do you recall the gdb sintax to do that?
<jbailey> 'dis' I think.
<fabbione> no that's disable..
<jbailey> Hmm, lemme look it up after this call.
<fabbione> sure thanks
<jbailey> fabbione: disass
<jbailey> You didn't try, did you? =)
<jbailey> So break before the sigill.
<jbailey> step to find the offending C statement.
<jbailey> Do the disass there
<jbailey> then stepi to the sigill.
<fabbione> jbailey: ok
<fabbione> dis was claiming disable.. but i might have been at the wrong point
<fabbione> hoooowwwowowowoowow
<fabbione> this is a mess
<doko> fabbione: pong
<fabbione> doko: do you have access to fluorine?
<doko> no
<fabbione> the T1000 at the london DC from -support?
<fabbione> i was told you had acccess
<doko> ohh right, didn't use it yet
<fabbione> doko: see your email about that niagara test case
<fabbione> it's possible to reproduce it on fluorine
<fabbione> there is a feisty chroot in /src/chroots/feisty
<fabbione> and the sources are in ~/root
<doko> fabbione: could you check with gcc-4.2?
<doko> what are working gcc/binutils versions?
<fabbione> doko: i have been staring at that code for 10 hours now.. i can't look at it anylonger
<fabbione> doko: i did test the latest in feisty... and no.. i didn't check back yet
<fabbione> i thought it was a coding error
<fabbione> but i just arrived at toolchain not too long ago when removing the int i;
<fabbione> (unused)
<fabbione> because i was killing code to the minimum to reduce the test case
<fabbione> the original parted_server is 2200 lines :)
<fabbione> also.. flourine has 32 threads.. it takes nothing to build gcc with make -j :)
#ubuntu-toolchain 2008-01-09
<tmarble> lamont: ping
<lamont> si>?
<tmarble> hi, sorry to bug you, as doko is out I need some newbie help with bzr
<tmarble> a packaging repo is at rev 12: https://code.edge.launchpad.net/~ubuntu-java/uj/icedtea7 
<tmarble> but when i do bzr update
<tmarble> all I get is
<tmarble> Tree is up to date at revision 9.
<tmarble> ?
<tmarble> my bad... just missing the bzr pull
<tmarble> nevermind
#ubuntu-toolchain 2010-01-13
<Phurl>  error: redefinition of class . Using include blocker and pch. anyone use pch? i am getting a problem with class redefinition 
<Phurl> https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/506728
#ubuntu-toolchain 2010-01-15
<veronica> hi veronica is that u
