#ubuntu-toolchain 2005-05-19
* #ubuntu-toolchain  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
(fabbione/#ubuntu-toolchain) 1 2 3.. test!
<fabbione> ok logs to appear on the web within the next hour
<jbailey> fabbione: Thanks Fabio!
<svenl> hi all.
<fabbione> now.. you got the logs... FIX SPARC YOU WANKERS!
<fabbione> gcc-3.4 is FTBFS
<fabbione> l-k-h is teh SUX!
<jbailey> Is that "fix" like how I had my cat "fixed"?
<fabbione> i have no idea about your cat....
<jbailey> fabbione: In N. America (possibly all of english) to have an animal "fixed" is to have it neutered.
<fabbione> no seriously.. if we start the transtion before sparc has even a toolchain i might as well consider dropping the port
<fabbione> oh... poor cat
<svenl> why does gcc-4.0 depend on libcairo-dev ?
<fabbione> anyway i must run to cook dinner
<fabbione> cya tomorrow
<dholbach> weren't we supposed to start 7 minutes ago? ;-)
<ogra> 6 here
<Riddell> poke doko 
<doko> svenl: libgcj
<svenl> doko: oh.
<doko> svenl: you can drop it, it's not a hard dependency
<svenl> bah, i just installed it.
<Riddell> so doko, why have you called us all here?
<doko> fabbione: you could just change gcc-defaults to have g77 -> g77-3.3, then g77-3.4 won't be touched.
<doko> heh, yes, let's start ...
<Riddell> do we have a version of gcc which includes this fix?  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
<doko> you are aware of https://www.ubuntulinux.org/wiki/BreezyToolchainTransition ?
<ogra> yep
<dholbach> me too, excellent work!
<doko> ok, we are converting all the library packages first
<dholbach> any specific order? dependency-wise?
<doko> for a better view, see https://www.ubuntulinux.org/wiki/CxxLibraryList
<doko> dholbach: heh, good question, answer is in the wiki:  Wait until all of your dependencies have been uploaded in c2 versions, and rebuilt on all architectures.
<dholbach> so we will rely on dep-wait?
<dholbach> or will elmo "freeze" every *c2 package until we are finished?
<doko> new lib packages cannot enter the archive, if there's already an 'ubuntu' package.
<doko> we will freeze all the application packages ...
<doko> Riddell: yes
<dholbach> could you explain it with  libtest  libtestc2  and  program  test  which uses those? :-)
<Riddell> doko: in the archives now?
<dholbach> i didnt quite get what will will happen
<doko> Riddell: of course
<Riddell> excellent
<doko> dholbach: what didn't you get?
<ogra> dholbach, all apps that depend on a c++ lib will be rejected if i undestood it right
<ogra> until doko pulls the lever
<doko> ogra: correct
<dholbach> ok, but installing for example  inkscape  won't work in the transition time, because libgtkmm*c2 is available but not libgtkmm*
<dholbach> or didnt i understand it yet
<ogra> dholbach, yep, gtkmm apps will break for a while...
<doko> dholbach: yes, that's correct, as you call it "Schmerz im Hintern"
<dholbach> alright
<dholbach> the "new" libraries will be built and put in the archive still?
<doko> dholbach: and all of KDE will break, that will be fun :-)
<ogra> yep
<dholbach> alright... sounds good
* ogra pats his gnome
<dholbach> what guidelines can i pass for the packaging
* ogra comforts Riddell 
<Riddell> "Some of them are handled specifically (mostly KDE)"  doko, what's handled specially about KDE?
<doko> some KDE packages are not renamed, even if they contain shared libs. we'll only rename qt and kdelibs
<Riddell> doko: why does kdelibs have to be renamed?
<Riddell> it depends on qt too
<doko> but not every kde package depends on qt
<Riddell> I'm yet to find any
<doko> Riddell: we discussed that in Sydney ... and found some IIRC
<Riddell> not I, amu said he found some, I'll see if he knows which
<Riddell> doko: how much is going to be done automatically and how much by hand?
<doko> Riddell: the library packages by hand, the application packages automatically. you have to make the call for the KDE packages, which are applications, and which are libraries ...
<dholbach> ok, so what guidelines can i pass for the packaging, what do i need to tell the guys explicitly? about 1) the libraries 2) the applications?
<dholbach> what is the general attack plan for a MOTU? :-)
<doko> dholbach: you should delegate packages to people, all other things should be mentioned in the wiki
<dholbach> they will pick
<doko> if not, then we should complete the docs ...
<dholbach> i'll have to re-read the wiki then some dozen times to make sure i got everything
<ogra> doko, will a rebuild and renaming be enough ? 
<dholbach> we need to change the build-dependencies
<ogra> doko, or do we have to expect odditys
<dholbach> and tell them to use a proper patching system
<ogra> ?
<dholbach> and tighten the build-depends as well
<doko> dholbach: yes, the new ones enter the archive immediately
<doko> dholbach: no, please NO other changes in these uploads. we will use the bug reports to feed back exactly the transition changes to Debian
<Riddell> doko: how do I mark packages as libraries or applications?
<doko> ogra: ICEs
<ogra> hmm... but thats nothing MOTU could fix... i mean compile issues we have to regard.... extra options, conflicting options, etc
<dholbach> doko: ok, need to read the wiki again
<dholbach> i seem to not get it yet and as i will need to tell people a couple of times, i want to understand it thoroughly
<doko> Riddell: we did talk about it in UDU, didn't we? maybe we should meet again with amu
<doko> dholbach: start with one package, and I can review it
<ogra> dholbach, dont worry, i think i understand it and i was around during the big transition in debian some time ago....
<ogra> so i know what to expect worst .... ;)
<dholbach> little dumb dholbach will have to read it again
<Riddell> doko: don't think we need to meet again, just that it was amu not me who said there were packages that depended on kdelibs and not qt, I havn't found any
<doko> Riddell: in universe as well?
<Riddell> doko: dunno, is there an easy way to search?
<doko> lamont: how does the hppa toolchain look, or don't you care at the moment?
<jbailey> doko: He's waiting on me for glibc love on hppa
<jbailey> doko: Should be early next week.  I just can't do that hacking on a single monitor system.  I'm hoping p'haps Sunday evening.
<doko> ogra: for ICE's, a MOTU should extract the preprocessed source, add the command line, submit a bug report and put the bug report number in the comment field. then other people can continue
<ogra> doko, would you mind to write some lines about how to do that on the wiki....
<amu> moin'
<doko> ogra: it's just recompiling with -save-temps, compress and send the resultint '.i' or '.ii' file
<lamont> doko: what jbailey said
<ogra> we have some very inexperienced guys in the MOTU wannabe league, so it sould be as easy as possible to "step in to help out" ;) 
<ogra> doko, 
<ogra> ok
<doko> ogra: it's even ok, if somebody else does this, but we have to know about ...
<ogra> yep
<ogra> we'll put a column on the wiki table for it...
<dholbach> we will keep the c2 suffix only until there's a new soname, right?
<doko> jbailey: that should be ok
<doko> dholbach: yes
<doko> so when do we start? Next Monday is bank holiday in Germany, and maybe somewhere else, so what about Tuesday?
<ogra> sounds good
<Riddell> amu: do you know which packages depend on kdelibs but not qt?
<dholbach> this will mean that universe will start a week later, right?
<amu> monday is fine :)
<ogra> dholbach, why ? 
<ogra> dholbach, anything we have to wait for ?
<dholbach> because most universe-c++-libraries will depend on main-crack
<amu> Riddell: all gnomepackages ? 
<amu> ;)
<dholbach> amu: on kdelibs?
<doko> dholbach: no, universe at the same time, for those, that don't depend on libs in main
<ogra> hmm, i think there is a good bunch essential stuff in universe too...
<doko> amu: we talked about the necessity of renaming kdelibs4 ...
<chmj> evening 
<lamont> fabbione: btw, if you haven't already, please add this channel to the logbot
<dholbach> lamont: he did: "<fabbione> now.. you got the logs... FIX SPARC YOU WANKERS!"
* ogra points at ubuntulog
<lamont> hehe
* dholbach pipes innocently
* lamont make a note to finish waking up sometime today
<Riddell> how about not renaming kdelibs4 and anything which is crazy enough to depend on kdelibs4 but not qt we just add a depend on qt
<doko> Riddell: doesn't work for existing apps
<Riddell> hmm yes
<dholbach> ok, now i see it clearer
<doko> amu, Riddell: please be careful about that issue, so that we have a solution, which works for Debian as well. A difference here would be a major PITA
<Riddell> so amu, where did you find packages that depend on kdelibs and not qt?
<amu> Riddell: good question ... at least they if they will not depends against qt kdelibs depend it 
<doko> Riddell: you could search all dependencies of packages, which have kdelibs4, but not libqt3-mtc102 (or something like this)
<dholbach> ok.. the meetin in #u-meeting will start
<dholbach> i well tell the crowd that the KDE solution is still worked on, ok?
<Riddell> dholbach: what's happening in #ubuntu-meeting?
<dholbach> the briefing for the MOTU crew
<ogra> Riddell, you should be there for qt/kde
<Riddell> ah kde-i18n* depends on kdelibs but not qt
<doko> ogra, dholbach: maybe just discuss the universe topics here as well, or point people here for questions
<dholbach> yes
<ogra> yep
<Riddell> grep-available -Fdepends kdelibs4 --and --not -Fdepends libqt3
<Riddell> looks to be quite a few, guess we will have to rename kdelibs4
<Riddell> the question is are there other kde libraries which are also depended upon without qt
<doko> jbailey: just decided that you will be pestered about java specific things by the motu's
<svenl> doko: can i have your tentative gcc ppc64 biarch packages or something ? 
* lamont glares at cdbs, fix0rs it
<lamont> q
<doko> svenl: http://people.ubuntu.com/~jbailey/glibc
<doko> svenl: http://people.ubuntu.com/~doko/gcc-powerpc
<svenl> doko, the gcc will work on ppc32 too ? 
<doko> svenl: heh, I never tried on ppc64 ...
<svenl> doko: the above gcc packages, they are using the headers from suse as the older ones, or the real thing ?
<svenl> doko: and you didn't provide the source packages.
<doko> svenl: these are built with jbailey's packages
<svenl> ok.
<doko> source: apt-get gcc-3.4
<doko> and edit debian/rules.defs
<svenl> doko: no magic config option, apart from jbaileys ackages installed ? 
<svenl> ah, ok.
<svenl> doko: i could then try building a biarch gcc-4.0 with those ? 
<doko> yes, you can try, sure
<svenl> :)
<svenl> any chance of it actually working ?
<doko> I didn't try yet ... run the testsuite ;-P
<svenl> doko: so, by installing all of the above, i should be able to create ppc64 executables, and also to build ppc64 kernels, right ? 
<svenl> doko: oh usable are the above on a debian system ?
<doko> svenl: I didn't test ... what about if you install them in a chroot? it shouldn't matter for a kernel build
<svenl> bah, the packages need a newer version of linux-kernel-headers than the one in breezy.
<svenl> doko: well.
<svenl> doko: am runnin in a breezy chroot on a hoary powerbook right now.
<doko> sven: please ask jbailey about l-k-h
<svenl> i found them
<svenl> mmm, maybe.
<svenl> damn.
<svenl> jbailey: please ping me when you come back.
<svenl> jbailey: your glibc is forced to use a l-k-h which is older than the one in breezy :/
<svenl> ls
<svenl> doko: your gcc won do, it is too old for either the glibc currently in breezy or jbailey packages.
<jbailey> svenl: Ooh, that might be the one I had the typo in, sorry.
<jbailey> doko: The gcc you gave me before for building glibc on ppc64 worked fine for my testcases.
* lamont waits to be told "go" on the bootstrapping process...
<jbailey> lamont: Working on it, still (again).  elmo and I got rt up and running this morning.
<lamont> jbailey: cool
<jbailey> Wow, ncftp isn't in main.
<lamont> jbailey: you really want to support that???
<lamont> ISTR vomiting the last time I was hacking on that.
#ubuntu-toolchain 2005-05-20
<jbailey> Eh?  I have 2 RT installations that I help manage now, and I used it at my last job.
<jbailey> It's a nice little package.
<jbailey> Have you seen it version >= 3?
<lamont> ncftp, not rt
* lamont has remained blissfully unencumbered by RT knowledge
<jbailey> ah, I've never hacked on the ncftp code. =)
<jbailey> -march=i686 -mcpu=i686
<jbailey> Err.
<jbailey> -march=i486 -mcpu=i686
<jbailey> Should that be -march=i386 -mtune=i686 ?
* jbailey watches the glibc build continue.
<jbailey> I *definetly* need better ia32 hardware.
<jbailey> lamont-away: It's building fine for me here...
<jbailey> I'm using gcc-3.4 from Debian, current lkh and amd64-libs{-dev} from Ubuntu
<jbailey> libgcc1 4.0 from Ubuntu
<fabbione> morning
<svenl> about biarch ppc64 compilers and 4.0 : 
<svenl> 10:37 < alanm> svenl, gcc-4.0 cvs might be ok, but it hasn't been tested anywhere near as much as gcc-3.4.  eg. the 4.0
<svenl>                release is known to miscompile the linux kernel
<svenl> doko: do you have any insight on this ? 
<doko> we have gcc-4.0 CVS 20050509
<svenl> doko: ok.
<svenl> doko: question is if you can compile 64bit kernels with it.
<svenl> doko: btw my debian/experimental gcc-4.0 build failed with : 
<svenl> fatal error: file gnat1drv.ali is incorrectly formatted
<svenl> make sure you are using consistent versions of gcc-3.3/gnatbind
<svenl> doko: are you sure the gnat build-dependency is as strict as is needed ? 
<doko> if you disable add, no
<svenl> doko: disable add ? 
<doko> ada
<svenl> doko: i just did a plain dpkg-buildpackage -B
<doko> WITHOUT_LANG=ada dpkg-buildpackage ...
<svenl> so i didn't touch the package.
<svenl> mmm.
<svenl> doko: so you want me to build and upload gcc-4.0 for powerpc without ada ? 
<doko> svenl: ehh? no!
<svenl> doko: so ? 
<svenl> doko: i just did a plain dpkg-buildpackage -B, and the gnat stuff failed to build.
<doko> misunderstanding, I thought you had problems wuth the biarch setup ...
<doko> is gnat-3.3 or gnat-3.4 installed?
<svenl> doko: so i was wondering if this was because i have gnat-3.3 or something.
<svenl> ii  gnat-3.3       3.3.6-4        The GNU Ada compiler
<doko> very strange ... you can check with gnat-3.4 maybe
<svenl> but the build-depends are ok, so if gnat-3.4 is needed, the build-depends need tightening.
<doko> save the build logs
<svenl> yep, will do a build this evening.
<svenl> doko: you want the gnat-3.3 build log ? 
<doko> yes, could you email it?
<svenl> doko : http://people.debian.org/~luther/gcc-4.0-gnat-3.3.log
<doko> strange, it did build before, and on the ubuntu buildd's as well
<svenl> with gnat-3.3 ? 
<doko> yes
<svenl> doko: on powerpc ? 
<doko> http://people.ubuntu.com/~lamont/buildLogs/g/gcc-4.0/4.0.0-7ubuntu1/gcc-4.0_4.0.0-7ubuntu1_20050509-2138-powerpc-successful.bz2
<svenl> strange.
<svenl> I will let aba build it, and we will see.
<fabbione> hey ladies
<fabbione> doko: did you read what i wrote on #ubuntu-devel ?
<doko> fabbione, that's not an under 18 channel ;-P
<fabbione> ahhaa
<jbailey> lamont, doko: I can't reproduce the configure time failure here for glibc on i386 targetting amd64.
<jbailey> I did notice, however, that my thing moving the -O0 hack to a generic place didn't work. =(
<lamont> jbailey: ew...
<lamont> hrm...
<svenl> jbailey: hi.
<svenl> jbailey: glibc build failed because the 64bit build dir was not populated.
<jbailey> svenl: Eh?
<jbailey> svenl: Here, lemme produce a .deb for you.
<jbailey> With both passes, it'll take about 40 minutes.
<jbailey> ...
<jbailey> to build.
<jbailey> Lemme assemble it first.
<svenl> jbailey: i rebuild glibc-2.3.5 (from your web page), with the gcc from doko, and it failed when it tried to build the ppc64 stuff, because that dir was empty.
<svenl> jbailey: that's not the problem, i am investigating the build on ppc32 part of it.
<svenl> jbailey: let me relocate on the powerbook, so i can tell you more about this error.
<jbailey> svenl: 'kay.  I can't talk long today.  I munged my wrist last night, so I'm avoiding typing today.
<svenl> jbailey: but you can read :)
<jbailey> Right. =)
<svenl> jbailey: or we can try a voip debugging session :)
<jbailey> True.  If I were at home, I'd just call you, it's 5 a minute for me to europe.
<jbailey> I should setup voip sometime.
<svenl> root@tael:~/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64# ls
<svenl> config.log  configparms
<svenl> you see there is only this.
<svenl> /usr/bin/make -C build-tree/powerpc-ppc64 -j 1 \
<svenl>   install_root=/home/sven/ubuntu/glibc-2.3.5/debian/tmp-ppc64 install
<svenl> make[1] : entrant dans le rpertoire  /home/sven/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64 
<svenl> make[1] : *** Pas de rgle pour fabriquer la cible  install . Arrt.
<jbailey> What's the failure at the bottom of the log file?
<svenl> and there it fsails.
<jbailey> No, it fails before that.
<svenl> well, i guess there is no Makedile in that dir.
<jbailey> It just doesn't kill the build.
<jbailey> We pipe stuff through tee, so we lose return codes.
<jbailey> It can fail *way* before that point.
<svenl> touch /home/sven/ubuntu/glibc-2.3.5/stamp-dir/install_libc
<svenl> Installing ppc64
<svenl> rm -rf /home/sven/ubuntu/glibc-2.3.5/debian/tmp-ppc64
<svenl> /usr/bin/make -C build-tree/powerpc-ppc64 -j 1 \
<svenl>   install_root=/home/sven/ubuntu/glibc-2.3.5/debian/tmp-ppc64 install
<svenl> make[1] : entrant dans le rpertoire  /home/sven/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64 
<svenl> make[1] : *** Pas de rgle pour fabriquer la cible  install . Arrt.
<svenl> make[1] : quittant le rpertoire  /home/sven/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64 
<jbailey> The the top directory of the tree, there should be a log-powerpc64-*
<svenl> make: *** [/home/sven/ubuntu/glibc-2.3.5/stamp-dir/install_ppc64]  Erreur 2
<svenl> ah, ok.
<jbailey> I need to see where configure failed.
<svenl> i have the fukll log normally, let me check.
<jbailey> Right.  The full log doesn't make sense in our case, because there's many places it can fail.
<jbailey> And just to piss lamont off, it's 40 megs.
<svenl> configure: error: forced unwind support is required
<svenl> make[1] : entrant dans le rpertoire  /home/sven/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64 
<jbailey> Because he *loves* getting those in his email. =)
<svenl> make[1] : *** Pas de cibles spcifies et aucun makefile n'a t trouv. Arrt.
<svenl> make[1] : quittant le rpertoire  /home/sven/ubuntu/glibc-2.3.5/build-tree/powerpc-ppc64 
<jbailey> That'd be the one. =(
<svenl> ok.
<svenl> checking for forced unwind support... no
<svenl> configure: error: forced unwind support is required
<jbailey> I need a typing break, back in a couple of minutes (sorry)
<svenl> no problem
<jbailey> Bah, found ice, can't find anything to wrap it in.
<svenl> how did you damage your hand ?
<jbailey> Can you take a look at that config.log file, please?
<jbailey> svenl: Playing pool last night.
<jbailey> svenl: I have hypermobile joints, so if I'm not careful I can do incredibly bad things to them.
<svenl> yep.
<jbailey> I was a little too enthusiastic on a shot.
<jbailey> (On the upside, I did sink two balls off of it)
<svenl> :/
<svenl> :)
<svenl> so what you want to see in config.log ?
<jbailey> It's not horrible, just throbby.  The nurse I spoke to says that I've likely just pulled something, given that there's no swelling and whatnot, and that I need to ice it and rest it when it gets uncomfortable.
<jbailey> Look for the word "unwind" and find a failure near there.
<svenl> configure:5402: checking for libunwind-support in compiler
<svenl> configure:5419: result: no
<jbailey> Next one, force unwind is later.
<svenl> jbailey: you could plug out that liquid cooling system of the pmac G5 and put it around your hand :)
<jbailey> svenl: The pmac is 5000km from here.  I haven't finished travelling home from UDU yet. =)
<svenl> /usr/bin/ld: cannot find -lc
<svenl> Ah.
<jbailey> Eh?  It shouldn't need a working C library to build the biarch compiler.
<jbailey> Oh...
<jbailey> wait
<svenl> configure:27: checking for forced unwind support
<svenl> configure:51: gcc-3.4 -m64 -o conftest -g -O2 -isystem /home/sven/ubuntu/glibc-2.3.5/debian/include  conftest.c  >&5
<jbailey> DAMMIT
<svenl> /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux/3.4.4/../../../libc.so when searching for -lc
<jbailey> I forgot about that.
<svenl> /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux/3.4.4/../../../libc.a when searching for -lc
<svenl> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc
<svenl> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
<svenl> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
<svenl> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
<doko> jbailey: it does for libgcc
<svenl> /usr/bin/ld: cannot find -lc
<svenl> collect2: ld returned 1 exit status
<svenl> configure:57: $? = 1
<svenl> configure: failed program was:
<jbailey> doko: No, it's a bug in the nptl configury.
<jbailey> doko: Linuxthreads doesn't need it.
<doko> ahh, better :)
<svenl> mmm.
<jbailey> svenl: Lemme send you my backup copy of glibc with lt. =)
<svenl> doko: btw, i also trried building gcc 3.4.3 cvs from scratch to build a biarch toolchain by hand.
<svenl> huh ?
<svenl> doko: but it failed too with a libiberty error.
<jbailey> svenl: I have a copy of glicb that you need to install for this build to work.
<svenl> jbailey: :)
<svenl> jbailey: a glibc package ?
<jbailey> svenl: Yes.
<jbailey> svenl: A transitional one.
<jbailey> I need to remember to get this bug fixed.
<svenl> mmmm.
<svenl> ok.
<svenl> jbailey: how will you send me the copy and when ?
<jbailey> http://testhaus.cns.utoronto.ca/~jbailey/ppc64-lt/
<jbailey> lamont: It just occured to me this is probably our amd64 failure too. =(  Same bootstrap case, really.
<lamont> ??
<svenl> jbailey: you know that you just violated the GPL :)
<jbailey> svenl: I have not, if you ask me for the source I will provide it.
<svenl> (meaning the above does not contain the source packages :)
<svenl> jbailey: you didn give me a written offer for it though :)
* lamont would be terribly shocked if jbailey actually violated the GPL.
<jbailey> Just as soon as a self addressed stamped envelope with an international postage voucher shows up with a blank cdrw. ;)
<svenl> ok, i am downloading the stuff.
<lamont> I had a very confused person recently who didn't realize that you could make a derivitive work based on a GPL'ed work and not return your patches upstream.
<lamont> (specifically, source must be made available to anyone who can get the binaries, which is not necessarily everyone)
<jbailey> lamont: Right.  I've wondered a few times when we'll start to see embedded linux devices with a spare chip, not hooked up to anything, that has the entire kernel source in it.
<svenl> BTW, why does sudo need to do a gethostbyname ?
<svenl> jbailey: it needs the prefered form of modification, so this wouldn work.
<lamont> svenl: hostname is one of the components of the sudoers file
<jbailey> svenl: It's still in source form.  If you have the tools to modify the embedded binary, you have the tools to get the source code.
<lamont> so you can have one file that goes everywhere, and only grants bob access to reboot _his_ machines
<lamont> jbailey: socketed?
<svenl> lamont: ah.
<svenl> would add about 15$ per board though as of today.
<jbailey> lamont: Could even be soldered as long as you could reasonably dump it with the some tools you'd use to program the roms.
<lamont> mind you, an sudod would be nice to jave, so you didn't have to push said file everywhere...
<jbailey> lamont: The trick is that every bios update would have to also update the source image.
<lamont> true
<jbailey> svenl: Right, cost prohibative for now, but given that it can be quite slow to write to, it might be cheaper than the support overhead of making source available for 3 years, or shipping it on demand if they managed to get quantities up.
<svenl> jbailey: yep.
<svenl> jbailey: especially as flash sizes grow.
<svenl> jbailey: launched the build with your transitional glibc.
<svenl> will take a while.
<jbailey> lamont: Do you still have that chroot lying arond that you used for the i386/amd64 biarch build?
<lamont> uh, used?
* lamont hasn't done that yet, since doko said it was ftbfs
<doko> ehh, yes, jbailey wanted to fix it ...
<jbailey> doko: You there?
<doko> yes
<jbailey> We currently have -march=i486 -mcpu=i686
<jbailey> (In various configs)
<jbailey> I get a gcc-3.4 warning saying that one of those is deprecated.
* jbailey digs up the warning.
<jbailey> -mcpu
<jbailey> Should that just change to -mtune ?
<doko> yes, I mailed you about it
<jbailey> You did?
* jbailey looks.
<jbailey> I see the thing where you point out the message...
<jbailey> But a'ight, I'll change it to -mtune
<doko> yes, I meant that :)
<jbailey> Thanks.  Starting another build and running off for lunch.
#ubuntu-toolchain 2005-05-21
<jbailey> Ah, bugger, I see my thinko
* jbailey grumbles.
<jbailey> Don't you love those moments where you realise that something shouldn't have worked the first time around? =)
<jbailey> doko: After this glibc upload, are you uploading the gcc with the fix for 260710?
<lamont> jbailey: so you got bits for me yet?
<jbailey> lamont: No, I figured out why it won't build when it gets that far...
<lamont> jbailey: -mcpu was 3.3, -mtune is 3.4/4.0
<lamont> oh.
<jbailey> lamont: eh...
<jbailey> lamont: hppa64.
<jbailey> lamont: Should we eventually be doing a biarch setup for that?
<doko> jbailey: biarch on hppa doesn't work yet, it needs a cross - binutils packaged in binutils-hppa64
<jbailey> Ah, okay.
<jbailey> glibc has this now: # hppa64 needs symlink /usr/hppa64-linux/include to /usr/include
<doko> 260710, yes it's better, the patch to fix -g1 was dropped from 3.4.4
<jbailey> Eh?  Dropped?
<jbailey> Do you plan to put it back in?
<doko> currently it is, but it shows some regressions in the testsuite
<jbailey> Ugh. =(
<doko> so, leave it out.
<jbailey> Upstream PR still has it listed as committed.
<jbailey> 'kay.  I've forced -g0 right now for our main arch's + sparc.
<jbailey> I've fired off another round of this, it'll take a few hours to build, so I'll have to get it tomorrow.
<ercxy> hi everybody
<ercxy> does anybody know how to increase stack size of a process ?
<fabbione> doko: ?
<doko> fabbione: ?
<fabbione> doko: gcc-3.4 on sparc status:
<fabbione> i could reproduce the problem with a perfectly clean chroot
<fabbione> this time i kept the tree
<fabbione> well it seems like make all is not called in that direcotry before calling make install
<fabbione> otherwise it works perfectly
<doko> nice :(
<fabbione> the reason why it can't find libv3test.a is because it's not there
<svenl> doko: i managed to rebuild the biarch glibc yesterdat.
<doko> fabbione: you build with sparc32 dpkg-buildpackage ... ?
<fabbione> doko: yes
<fabbione> that's automatic
<svenl> doko: so, now i want to rebuild your biarch gcc packages, and you told me that the standard gcc packages will do.
<svenl> doko: but i suppose i need to tweak some config options or something ? 
<doko> yes, set biarch in debian/rules.defs. it's currently disabled.
<svenl> doko: that's the only thing ? 
<fabbione> doko: i am going to binNMU gcc-3.4 for sparc so that i can have the full toolchain but i would really love you to get it fixed properly, since this bug is a regression introduced recently
<fabbione> ah ok
<fabbione> ops
<svenl> doko: i can just apt-get source gcc-3.4 modify it, and build it, and this will trigger the cannot-build-on-ppc32 bug, right ? 
<doko> does jbailey still build using -g1?
<svenl> doko: that was for me ? 
<doko> svenl: yes
<svenl> doko: any hint on it ? 
<svenl> doko: or will you help me hunt it down or something ?
<doko> svenl: sorry, currently not the time, trying to have something for sparc when we start the transition
<svenl> doko. Ok.
<svenl> doko: not even a summary of what you have found out so far about this ? 
<svenl> doko: and i guess i will hit the problem sometime tomorrow only.
<doko> svenl: what do you mean? as it looks, you cannot build glibc with -g1 due to PR16676
<svenl> huh ? 
<svenl> doko: i built glibc, so i guess it is not the issue.
<svenl> doko: about gcc.
<svenl> doko: BTW, any idea of what will happen if i install these biarch glibc and gcc on a debian system ? 
<doko> hmm, haven't tried yet. maybe install l-k-h as well?
<svenl> yep.
<svenl> but the glibc will be backward binary compatible, even if we enabled NPTL and biarch, right ? 
<svenl> doko, what is XXX_powerpc_XXX ? 
<svenl> doko: and should i also set with_lib64gcc and with_lib64cxx ? 
<doko> svenl, that's the switch which needs to be enabled.
<svenl> oh.
<svenl> doko: so i should just remove the XXX stuff ? 
<doko> yes
<svenl> doko: and how will this handle the guys doing true-ppc64 and having a ppc64 or powerpc64 arch ? 
<doko> the architecture is called powerpc64, not powerpc
<svenl> doko: but the current package doesn't make provision for it, right ? 
<svenl> or you should change the XXX by powerpc64 or something ?
<svenl> Anyway, this is not my problem ATM.
<doko> ask aj ... I think he did it prepare for 4.0 only
<svenl> we will see once this happens.
<svenl> Damn.
<svenl> lot of build depends to load, and apt-get is not happy with the gcc packages i have installed :/
<svenl> doko: do i need a biarch gcc to build the biarch gcc, or will just the biarch glibc do ? 
<doko> biarch glibc is enough
<svenl> ok, so i can install the standard gcc over the one i used to build glibc in the first place.
<doko> should work
<svenl> i will tell you if it does not.
<svenl> doko: so, is it better to start with gcc-3.4 or gcc-4.0 ?
<doko> according to jbailey, gcc-4.0 doesn't work to build glibc.
<svenl> well.
<svenl> let's start with gcc-3.4 for now then.
<svenl> doko: am i supposed to rebuild glibc with this new gcc once i have it ? 
<svenl> doko: and how did you manage that ? Did you first build a biarch gcc bi hand for jbailey to use, or did he build one from upstream locally to build the first glibc ? 
<doko> jbailey meant, that wouldn't be possible
<svenl> doko: with 4.0 ? 
<svenl> doko: but ok with the biarch 3.4 i am building.
<doko> svenl: yes
<svenl> doko: you didn't reply to my question about the way you originally built it :)
<svenl> ARG.
<svenl> it seems it didn't fix the linux-kernel-headers bad dependency :/
<svenl> hand fixed that.
<svenl> ok, gcc-3.4 build started.
<fabbione> doko: at what time do you plan to start the transition on monday?
<doko> evening, when lamont and elmo are awake
<fabbione> doko: ok thanks
<fabbione> i am going to crontab the sparc buildd to stop at 2pm our local time
<fabbione> please do not start before that ok?
<fabbione> i should be already back at that time
<doko> fabbione: ok
<fabbione> but i can't be 100% sure
<fabbione> 0 14 * * Mon touch $HOME/EXIT-DAEMON-PLEASE
<fabbione> there
<fabbione> doko: if there are big issues, please tell lamont to stop it. he has access to the buildd
<fabbione> i should be already home by that time.. but you may never know :)
<\sh> mmm..
<\sh> do i need to rename kdelibs4?
<svenl> Mmm, it kind of failed. stopped building and lot of gcc tests marked as FAIL.
<svenl> doko: is this supposed to happen ? 
<svenl> doko: or more to the point, is this a symptom of the ppc64-kernel failure, or something else ? 
<doko> svenl: which tests fail?
<svenl> doko: i don't see any other obvious error message in the log.
<svenl> doko: all of them
<svenl> doko: which is why i think that something else went wrong.
<doko> look at the build logs to see why they fail
<svenl> doko: where can i find it ? 
<svenl> i get stuff like :
<svenl> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
<svenl> Using /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
<doko> find -name '*.log'
<svenl> Running /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
<svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O0  (test for excess errors)
<svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O1  (test for excess errors)
<svenl> FAIL: gcc.c-torture/compile/20000105-1.c  -O2  (test for excess errors)
<svenl> output is :
<svenl> spawn failed
<svenl> Mmm.
<doko> better mount /proc
<doko> and /dev/pts
<svenl> oh well.
<svenl> Can i restart the build from where it left ? 
<svenl> nope, proc was mounted, but not /dev/pts.
<svenl> mmm, how do i mount /dev/pts. ...
<svenl> Mmm.
<svenl> will installing that glibc in my real system break it horribly ? 
<svenl> Oh hell, let's try.
<doko> debian/rules check should work
<svenl> doko: does running the build as root could have affected it ? 
<doko> don't think so, although I work with fakeroot only
<svenl> i am inside a chroot as root, /proc is mounted, but not /dev/pts.
<doko> so mount it and re-run
<svenl> doko: how do i mount /dev/pts ? 
<doko> proc    /org/chroots/breezy/proc        proc    defaults,auto           0 0
<svenl> no, proc is ok, i know about it, /dev/pts is the one.
<doko> devpts          /data/chroot/breezy32/dev/pts   devpts  defaults,auto   0 0
<svenl> ok.
<svenl> mount: special device ptsdev does not exist
<svenl> no fun :/
<svenl> err, the message was
<svenl> mount: special device devpts does not exist
<svenl> strange,
<svenl> oh, well, need to go.
<svenl> oh, well, no way to build gcc without moving to breezy will try again later on.
<jbailey> lamont: hAround?
<lamont> jbailey: am now
<jbailey> lamont: Cool, got source for you.
<jbailey> Just have one last dependancy to sort out.
<jbailey> doko: There?
<jbailey>  lib64gcc1 depends on amd64-libs (>= 0.1)
<jbailey>   amd64-libs is to be removed.
<jbailey> What do you want done about that?
<jbailey> I'm now conflicting with amd64-libs as we'd talked about.
<jbailey> lamont: The chroot basically needs to be:  Current Breezy, add amd64-libs amd64-libs-dev from breezy, add:
<jbailey> cpp-3.4_3.4.3-13_i386.deb       lib64gcc1_3.4.3-13_i386.deb
<jbailey> gcc-3.4-base_3.4.3-13_i386.deb  libgcc1_3.4.3-13_i386.deb
<jbailey> gcc-3.4_3.4.3-13_i386.deb
<jbailey> from Debian
<doko> no
<doko> jbailey: away for the evening
<lamont>    features' might be clobbered by `longjmp' or `vfork'
<lamont> {standard input}: Assembler messages:
<lamont> {standard input}:59358: Error: Unrecognized opcode: `vand'
<lamont> make[3] : *** [libkdefx_la.all_cpp.lo]  Error 1
<lamont>  /build/buildd/kdelibs-3.4.0/kdefx/kcpuinfo.cpp:75: warning: variable `int
<lamont> that last line should be first
<lamont> bad gcc
<svenl> jbailey: hi.
<jbailey> svenl: hi.
<svenl> jbailey: it is not possible to build stuff from inside hoary :/
<jbailey> svenl: 'stuff'?
<svenl> jbailey: gcc-3.4
<jbailey> Errr.
<jbailey> Usually one of the last steps to a release is that we rebuild the archive to make sure there aren't FTBFSs
<svenl> jbailey: at least not the biarch version from doko.
<svenl> jbailey: the blocker is doxygen.
<svenl> and doxygen depends on libgcc >= 1:4.0-2
<svenl> which is a breezy gcc-4.0 package i think.
<svenl> and which overwrote my biarch libgcc.
<svenl> so i am moving my box to breezy.
<jbailey> Breezy won't be a great improvement for you.
<svenl> well, i will be able to install the build-depends of gcc-3.4
<jbailey> I've started another build of a biarch glibc on ppc, I'll just post it for you.
<svenl> but then, i wonder if the libgcc1 4.0.0-7ubuntu1 is compatible with the libgcc1ppc64 or whatever i just built.
<jbailey> the lib gcc1's should be completely unrelated to one another.
<svenl> and the -dev ppc64 package of glibc depends on libgcc64.
<svenl> ah.
<jbailey> It's only important when you're looking at optimsed libs for the same architecture.
<jbailey> There's pretty much no commonality otherwise, to the point where they use completely separate linkers and search paths.
<svenl> jbailey: ok.
<svenl> jbailey: BTW, what does this one glibc mean for userland libs ?
<jbailey> one glibc?
<svenl> the biarch one i built ? 
<svenl> this one
<jbailey> Right, but it should really be two glibcs.
<jbailey> They just happen to coninstall.
<svenl> Ok.
<svenl> well, this way of doing things :)
<jbailey> co-install, rather.
<jbailey> It doesn't affect existing libs in any way.  They will link against /lib/ld.so.1 (or whatever PT_INTERP is on ppc, I don't remember).
<jbailey> Any libs built for ppc64 will link against /lib64/ld.so.1
<jbailey> So there's truly no relationship between them.  That ld.so should be wired to look in different search paths and whatnot.
<svenl> ok.
<svenl> what does this mean for 64bit libs ? 
<svenl> they go in /lib64 and /usr/lib64 ? 
<jbailey> Yes.
<jbailey> In practice very few of them get built.
<jbailey> Usually a few minor things like ncurses, zlib and such.
<jbailey> Whatever the bare minimum we need for an LSB system, basically.
<svenl> I think we need ncurses, which is a build dependency of the 64bit procutils.
<jbailey> See two lines up. =)
<svenl> )
<svenl> only comenting on why ncurses is needed, which is not really an important lib to 64bit-is.
<svenl> alternatively, we can build a static procutils-64.
<jbailey> Well, we'd still need the library.
<svenl> jbailey: this would be in the case of just ppc64 kernels.
<svenl> jbailey: Now, if i want to upgrade my debian/sid system to use the new NPTL and biarch enhanced glibc, will this break my system ? 
<svenl> Obviously i will not be able to use it anymore to build debian packages, but that is another issue.
<jbailey> svenl: The best I can say is that it shouldn't.
<jbailey> I've been running the nptl-based stuff for a while with no issues.
<jbailey> But that was all on Hoary, etc.
<\sh> anyone awake?
<jbailey> \sh: Just got back, sup?
<\sh> jbailey: my question is already answered.
<\sh> jbailey: kdelibs4 has to be renamed
<jbailey> svenl: l?
<jbailey> svenl: I have the glibc-ppc64 bits if you want.
#ubuntu-toolchain 2005-05-22
<jbailey> lamont: ping when you're back.
<jbailey> The glibc is on chinstrap in my homedir.  Builds here.  The only thing you need is a current breezy chroot and gcc-3.4 from Debian.
<jbailey> I'll check my mail tomorrow sometime, and then I'll be online Sunday evening.
* jbailey heads off.
<svenl> doko: well, all tests failed again, but the package built, except for libgcc1 and co, it seems.
<svenl> doko: correction, some tests failed.
<svenl> doko: i guess the 64bit tests failed, and that is the problem, message is -m64 not supported in this configuration.
<svenl> oh well.
<lamont> WARNING: The following essential packages will be removed
<lamont> This should NOT be done unless you know exactly what you are doing!
<lamont>   apt dpkg dselect (due to dpkg) sysvinit initscripts (due to sysvinit)
* lamont smacks jbailey and doko
<lamont> I wonder if I can just force dpkg to do the install and tweak /var/lib/dpkg/status to lie about the version number
<lamont> well, off to get out of trouble with the wife for a few hours
<doko> ?
<lamont> trying to install the debian gcc-3.4 bits to build the glibc jbailey has for me.
<lamont> downgrades libgcc1, causing all those packages to be selected for removal.  -> bummer
<lamont> but must run for a bit - was just going to start the first step before I ran away.
<lamont> the debian version is newer than hoary?
<lamont> no.  hoary had libgcc1=4.0-0pre6ubuntu7
<lamont> grumble
<lamont> anyway, I need a working set of packages to build the glibc bits with.  I'll let you two ponder that until I get back in a few hours.
<svenl> lamont: :)
<svenl> lamont: i had also trouble with that.
<svenl> doko: you there ? 
<svenl> doko: something funny happened.
<doko> svenl: really funny?
<svenl> doko: some of the tests failed, but not all, the package build a couple of .debs (most of them i think, including lib64stdc++ and gcc) but no trace of any libgcc1 or libgcc1_64.
<svenl> doko: yep.
<doko> find build -name libgcc1_* ?
<svenl> doko: how do you come clear with this huge build log ?
<svenl> doko: doesn't find anything such.
<svenl> there are a couple libgcc.a and libgcc_s.so in build/gcc though.
<doko> sorry, find build -name libgcc_* ?
<svenl> $ find build -name libgcc\*
<svenl> build/gcc/libgcc
<svenl> build/gcc/libgcc/nof/libgcc.map
<svenl> build/gcc/libgcc/libgcc.map
<svenl> build/gcc/nof/libgcc.a
<svenl> build/gcc/nof/libgcc_eh.a
<svenl> build/gcc/libgcc.a
<svenl> build/gcc/libgcc_eh.a
<svenl> build/gcc/libgcc_s.so.1.backup
<svenl> build/gcc/libgcc_s.so.1
<svenl> build/gcc/libgcc_s_nof.so.1.backup
<svenl> build/gcc/libgcc_s_nof.so.1
<svenl> build/gcc/libgcc_s_nof.so
<svenl> build/gcc/libgcc.mk
<svenl> build/gcc/libgcc_s.so
<doko> hmm, no 64bit libgcc ...
<doko> or is this 4.0 for experimental?
<svenl> the fun thing is that not even the 32bit libgcc did build.
<svenl> no, the ubuntu gcc-3.4
<svenl> doko: any hint on what i could be looking at there ?
<doko> hmm, no currently not.
<svenl> can i try building the libgcc stuff without rebuilding the whole stuff ? To get a smaller log or something.
<doko> ugh, you may want to look at gcc/Makefile, where it builds libgcc, but if the compiler isn't configured for 64bit, then that won't help at all ...
<svenl> doko: what i don't understand is why : 1) the 32bit libgcc didn't build, or 2) why the whole lot of other .debs where built.
<doko> and the lib64stdc++6 does contain a shared lib?
<svenl> nope, its empty.
<svenl> and there is no non-64bit libstdc++ now that i look at it.
<svenl> strange.
#ubuntu-toolchain 2006-05-20
<lamont> doko: glibc (ia64) uploaded
#ubuntu-toolchain 2007-05-15
<lamont> doko: ping
* Starting logfile irclogs/ubuntu-toolchain.log
<Mithrandir> doko: do you know if lpia is going to have a different prefix than i386?
<doko> Mithrandir: lpia? no, didn't get a reply on the flags/gnu triplet yet
<Mithrandir> it seems like dpkg isn't entirely happy with having multiple arches with the same gnu triplet.
<Mithrandir> so switching to something like i486-lpia-linux-gnu might be useful.
<doko> right, but probably we'll use i686 or something else like this to get rid of i486.
<Mithrandir> that's another option
<doko> did you already choose the architecture name?
<Mithrandir> no, I'm trying to work out something with dpkg upstream since having the same gnu triplet for multiple architectures makes dpkg unhappy.
<Keybuk> yeah, it uses the config.guess output to determine the architecture string
<Mithrandir> and config.guess pokes various bits of the system to find out, but is part of the source package and not all update from autotools-dev
#ubuntu-toolchain 2007-05-16
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> doko: Heya!  Is there any sort of regression checker in the gcc testsuite?
<doko> no, there was one running upstream for checkins; usually I inspect the logs manually. elmo wrote something for binutils, which now runs in the build as well (comparing against the installed version).
<jbailey> Hmm.
<jbailey> I was thinking that the simplest one would be no FAILs
<jbailey> And just mark everything that currently FAILs as XFAIL and move on.
<jbailey> IIRC, dejagnu can give a different return code for that.
<doko> It's difficult to automatically tell about regressions, new failing testcases show up as false positives
<jbailey> Sure, I'm just thinking at the release point for gcc-4.1 and such.
<jbailey> I don't think new test cases are usually added to the stable branch.
<doko> they are.
<jbailey> Ah, hmm.
<jbailey> That could suck.
<jbailey> In this case, the hppa patch is totally localised to the machine descriptor, but in general, I'm happier if I know that I'm not going to break something elsewhere.
<doko> you would have to save the .log files instead of the .sum files for all tests, then you can detect added testcases as well
<jbailey> Well.  I think I was hoping more that sometime in stage 3, we just submit a list of current fails, mark them as XFAIL and move on. =)
#ubuntu-toolchain 2009-05-15
<doko> jbailey: https://edge.launchpad.net/~doko/+archive/toolchain
 * jbailey waits for it to load.
<doko> load? install!
<jbailey> No, the https link you gave me hasn't come up yet.
<doko> maybe https://launchpad.net/~doko/+archive/toolchain
<jbailey> launchpad has speed problems, news at 11 ;)
<jbailey> Eh, nice!
<jbailey> You thinking of doing it for karmic?
<jbailey> It should be an easy drop-in.
<doko> still in evaluation
<jbailey> It would be nice to do it, assuming that licking llama is an LTS.
 * jbailey heads home.
 * doko heads to bed
<jbailey> g'n =)
