#ubuntu-toolchain 2005-07-18
<lamont__> doko: I'll take a look and see what I can do
<fabbione> morning
<desrt> fabbione; do you still need access to gorecki?
<fabbione> desrt: nope.. thanks :)
<desrt> awesome
* desrt resumes the crashing :)
<fabbione> desrt: i am confident you did try the new headers.. didn't you?
<desrt> fabbione; actually, no
<desrt> fabbione; i've been avoiding too much kernel hacking so that i didn't accidentally crash the box when you needed to use it :)
<fabbione> oh 
<fabbione> thanks :)
<fabbione> well crash it and let me know :)
<desrt> k.  lemme check
<fabbione> i need to go offline soon for approx 20 minutes
<desrt>   MODPOST
<desrt> modpost: /home/desrt/coconet/coconet.o no symtab?
<desrt>  /bin/sh: line 1: 14814 Aborted                 scripts/mod/modpost -m -a -i /usr/src/linux-headers-2.6.12-3-powerpc64-smp/Module.symvers /home/desrt/coconet/coconet.o /home/desrt/coconet/large-page.o
<desrt> very possibly my fault :)
<fabbione> yes
<fabbione> i saw that too
<fabbione> but given that all the rest compiles...
<fabbione> i sort of assumed it was a specific coconet problem
<desrt> let me check
<desrt> no.  it's a -headers problem, i think
<desrt> i'll try and find out more about it while you're offline
<fabbione> i don't think it is
<desrt> (compiles just fine against the full kernel source 2.6.12 with ubuntu patches)
<fabbione> hmmmm
<fabbione> ok... leave my account around..
<fabbione> i will look at it later
<fabbione> desrt: did you actually upgrade the kernel and headers to the latest version or are you just using the one i hacked locally?
<desrt> whatever is currently in /usr/src/linux-kernel-headers
<fabbione> currently as in?
<fabbione> currently can be that you dist-upgraded the box 2 minutes ago
<fabbione> or currently is what i left there a few days back :P
<desrt> i just did dist-upgrade now.. the only difference was a new yaboot
<fabbione> yeah the yaboot we fixed together 
<desrt> nod.  i'm only running ubuntu-base... so not many updates
<fabbione> ok gimme a bit and i will come back
<desrt> ok.. i've found the problem.. and it's one of those big sort of problems that won't easily go away
<fabbione> desrt: re
<desrt> /usr/src/linux-headers-2.6.12-3-powerpc64-smp/scripts is a symlink to linux-headers-2.6.12-3/scripts
<desrt> ie: all the various different arch versions share the same scripts/ directory
<fabbione> that's right...
<desrt> the modpost script has a compile-time flag for 32bit or 64bit mode
<desrt> if you run the 32bit version on a 64bit .o file you get the "missing symtab" error
<desrt> it gets its settings from elfconfig.h
<desrt> which contains this: #define KERNEL_ELFCLASS ELFCLASS32
<desrt> you'll basically need 2 versions of the modpost script... one for 32bit kernels and one for 64bit
<fabbione> crack
<fabbione> we need a completely different approach here :/
<fabbione> bah
<fabbione> ok.. i got the problem thanks...
<desrt> thanks again for all your work on this :)
<fabbione> this is going to be a real problem
<desrt> btw: there is a working version of the kernel source in /usr/src/linux-source-2.6.12 that you can use for comparison
<fabbione> nah i got it thanks
<desrt> if you compile coconet the top line in the Makefile is LINUX=/path/to/source
<fabbione> this is going to cost me an extra amount of painful work
<desrt> anything i can do to help?
<fabbione> desrt: not really.. this needs to be fixed in the source package...
<desrt> (just think -- you're solving the problem for biarch amd64 too) :)
<fabbione> when we build the kernel on the buildd's
<fabbione> that's the real problem
<fabbione> desrt: nope.. ppc64 is a "special case" all over the Makefiles
<desrt> ah
<fabbione> because it's the only one that's cross compiled
<daniels> god I hate building the monolith
<daniels> even with it not building anything in programs/ except for the server and most of lib/
<daniels> hate hate hate
<fabbione> don't worry.. the machine i use to build is fast :)
<desrt> daniels; Xc?
<daniels> desrt: yeah
<desrt> i really like the fd.o broken-out-everything approach with pkgconfig help
<fabbione> my back is hurting a lot
<fabbione> crap i must have slept really bad this night
<desrt> clearly an indication that you require a mid-morning nap :)
<fabbione> desrt: i am not just tired.. my back is really hurting a lot
<daniels> desrt: you're telling me
<mirak> hello
<mirak> I am trying to cross compile
<mirak> my two architectures are ppc and i386
<mirak> I tried the howto
<mirak> but it both fail when I try to build gcci386 for ppc and gcc-ppc for i386
<jbailey> Which howto?
<jbailey> If it was anything other than http://kegel.com/crosstool/ you'd probably do better to start for there.
<mirak> jbailey /usr/share/doc/toolchain/howto
<mirak> I use this how to
<mirak> I already followed the http://kegel.com/crosstool/ 
<mirak> some month ago but it failed as well
<mirak> I use tpkg-make
<karim> hi
<karim> how important are the glibc version and kernel version for cross compiling
<karim> ?
<karim> jbailey: hey
<jbailey> The versions shouldn't really matter.  Cross compiling on older stuff might be a bit more finicky but not much.
<jbailey> You generally want to make sure your libraries that you're using for cross compiling are the same or older than the ones you'll be executing with.
<jbailey> Otherwise you risk symbol mismatches and stuff.
<karim> here is what I want to do
<karim> I want to set up a cross compile gcc 
<karim> to use with distcc
<karim> my goal is to use this ubuntu i386 box to help this poor ppc G3
<karim> so I don't think I need all the gdb and stuff to do that
<karim> jbailey: I don't understand why toolchain tpkg-make script fails 
<karim> it's a pity because it's very handy
<jbailey> I haven't used that script, so I don't know.
<jbailey> I have some vague dreams of making it so that building cross compilers from the standard toolchain packages is trivial, but I haven't taken them past the dream stage.
<karim> well it IS trivial
<karim> but the compile fail
<karim> a problem with some files missing it seems
<karim> signal.h
<jbailey> IIRC, signal.h means you don't have glibc headers in place.
<zul|working> someone should start an arm port..
<jbailey> Planning on it.
* jbailey needs to get around to writing up the buntu spec.
<zul|working> wasnt there a paper at debconf for porting debian to another arch?
<jbailey> Dunno.  I've done it twice, so wouldn't need much of a paper.
<karim> jbailey: how do I put them in place ?
<jbailey> karim: It depends where you've configured gcc to look for them.
<jbailey> I tend to use --with-sysroot
<karim> hem I am trying to use distcc
<karim> I can remotely connect and compile
<karim> but I don't know how to tell distccd to use the ppc gcc cross compiler
<jbailey> Dunno.  I've read about doing that but have never done so.
<jbailey> I thought about doing that for the Debian hurd-i386 buildd. =)
<jbailey> Have a huge ccache tied in with distcc and cross compilers.
<jbailey> Make the hurd the fastest compile farm in Debian. =)
<jbailey> Of course, doko might kill me for thinking that thought out loud. =)
<doko> ?
<doko> so you did fix the biarch i386 builds?
<doko> ;)
<jbailey> karim: Or he'll play dirty. =)
<karim> what ?
<karim> I give up
<karim> if I compile for ppc on the i386 I can execute the binary on the ppc host
<karim> so cross compile work
<karim> but however distcc fail
<karim> it produce a little binary
<karim> that can't be executed
<doko> lamont, lamont-away: 4.0 did fail on the ia64 and hppa unstable buildds
<lamont> figures
<jbailey> Eh?  What's different than in breezy?
<doko> nothing is different. the ia64 buildd looks seriously broken
#ubuntu-toolchain 2005-07-19
* lamont makes a note to really make time to look at debian's ia64 buildd tonight
<lamont> otoh, it's been building lots of _other_ stuff just fine
<fabbione> morning
<desrt> hello.
<fabbione> hi desrt 
<desrt> fabbione; do you guys have anything that needs doing?
<fabbione> desrt: fix all the kernel bugs? ;)
<desrt> well, i'd certainly be glad, for example, to look at the headers problem
<desrt> but i doubt i'd do a very good job... seems like a fairly significant issue
<fabbione> desrt: nah i was kidding.. don't worry
<fabbione> i am going to fix that soon
<daniels> fabbione: done
<fabbione> daniels: thanke
<zul> hey
<lamont-away> build/chroot-unstable/w?Z?8???%=s?f??i?|??????L?G}F??c?:??E_A?2~?V?X??? ??N????????-@??a?????!
<lamont-away> hrm... I wonder if filenames like that could have anyting to do with ia64's issues...?
<jbailey> Are the ??'
<jbailey> s really just random high-order characters?
<lamont> yeah
* lamont reboots to see if magic just happens.
<lamont> mnt
<lamont> m????????????4????????e?{M???i??vo?????Z??5??\P?b??E??'??(u????.D+???h"?
<lamont> opt
<lamont> hrm...
<jbailey> Anyone know if Stage2 gcc actually finished on July 8th?  I see a reference from Mark saying that "it will end tomorrow" on the 7th, but no message saying it did, and the website isn't up to date.
<jbailey> Mmm, looks like: http://gcc.gnu.org/ml/gcc/2005-07/msg00315.html
<doko> infinity, lamont: please requeue openoffice.org2 (if it's not currently building)
<lamont> openoffice.org2_1.9.116-0.pre1ubuntu1 given back on i386,ia64,ppc
<doko> thanks
#ubuntu-toolchain 2005-07-21
<lamont> sparc: 75%, hppa: 61%
<jbailey> lamont: Load up another 4 machines, LaMont!
<jbailey> ;
<jbailey> )
<lamont> i386 88.9
<lamont> powerpc 88.6
<lamont> ia64 87.7
<lamont> amd64 87.1
<lamont> sparc 75.0
<lamont> hppa 61.3
<lamont> jbailey: that's not the issue
<lamont> the one-second power outage the house took 3.5 hours into the gcc-3.4 build hurt...
<lamont> I really need to replace the dead UPS.
<jbailey> Ouch.
<jbailey> I thought you had moved all the machines to your office.
<lamont> my bad.  7:55 into the build
<lamont> the work network has a not-so-transparent proxy that totally screws things up sometimes...
<lamont> so there's one A500 at home, and one at the office
<lamont> meanwhile. my next-gen-just-mirror-what-I-want scripts are getting closer to being done.
<lamont> they don't use rsync, etc, etc.
<jbailey> Don't use rsync?
<lamont> and, certainly, bring me a whole set of other bugs, different from the current script.
<jbailey> I would've thought going from a -1 to a -2 package would be a bit of a win with rsync.
<lamont> gzip sucks
<lamont> and, you still have to actually copy -1 into -2 to preseed it..
<jbailey> Right, but that's relatively easy logic.
<jbailey> Hmm, I thought gzip --rsyncable was the default.
<lamont> yeah.  more of an issue was that the rsync could take several hours, during which time local uploads couldn't process.
<lamont> so whether I use http or rsync to fetch the individual files, it'll now just process archive-mirrored packages as "just another upload"
<jbailey> Ah, cool.
<lamont> yeah - the logic for figuring out what to import is mostly done, albeit only in my head.
<lamont> current state can read an archive, seed packages, resolve dependencies, and spit out the new packages/sources files, all nice and signed.
<lamont> verifying the signature at readtime is on the TODO list.:-(
<lamont> I still have to teach it how to prune dead packages/source from the archive,  as well as how to generate and import .changes
<lamont> although, pruning is trivial.
<lamont> I just ran out of time before charlie and the chocolate factory last night
<jbailey> =)
<lamont> btw, worth the price of admission
* jbailey wishes again for package sigs.
<jbailey> Really?  Cool.
<lamont> it's a truly sick movie
<jbailey> I've never read the book - it was required reading for the English students, but we got things like "Les Misrables" instead.
<lamont> "everything in this room is eatable. edible.  including me.  But that, boys and girls, is called 'canabilism', and is very frowned upon in many societies."
<jbailey> Err..  This wasn't written by Heinlein was it? =)
<lamont> johny depp in a wonderful impersonation of michael jackson as willy.  Tim Burton directing.
<lamont> there's a little bit of Fred Rogers in the willy character as well.
<jbailey> "<lamont> there's a little bit of Fred Rogers in the willy character as well."
<jbailey> I wonder how much blackmail money that's worth.
<jbailey> Oh willy....
<lamont> he's the sort of character that you'd have to kill if you were stuck dealing with him for any period of time.  But he's a very good willy wonka
<lamont> oh. and the oompa loompa's.  very interesting
* lamont wonders how big a trebuchet would need to be to hit ottawa from here.
<lamont> or is it toronto?
<jbailey> Oh you think I'm going to tell you now?
<jbailey> MWAAHAHAHAHAHAHA
<lamont> lol
<jbailey> Montral.  Delayed the trip to Ottawa by a day due to a round of food poisoning last night.
<lamont> the really cool part of the movie was that there were _many_ places where the whole audience was laughing.  And several where only a handful were.
<lamont> bad food.  spank it
<lamont> fwiw, my gcc-3.4 build was here when the power died: Running /build/buildd/gcc-3.4-3.4.4/src/gcc/testsuite/g77.f-torture/compile/compile.exp ...
<jbailey> Mm, yeah.  Angie and I were fine.  Yay veganism.  Angie's mom ate the egg-based dressing on the salad at the resto.
<jbailey> Ouch.
<jbailey> And gcc sucks for ccache.
<lamont> _oh_.. so you poisoned the inlaw.  got it.
<jbailey> No motive.  We're heading to Ottawa for a week and have no other cat sitter.
<jbailey> If it happened on the day we got back, we'd have a harder time of it.
<lamont> so the machine at home is building gcc-3.4 (since 13:31), and the machine at the office is building gcc-4.0 (since 15:20)
<lamont> iz now 15:22
<lamont>       ("^E: There are problems and -y was used without --force-yes","give\n"),
<lamont> that just hurts to have there.
<lamont> binutils-hppa64(inst 2.15-5ubuntu2 ! >= wanted 2.16.1)
<lamont> grumble
<lamont> any elmo/mdz sign, I wonder?
<jbailey> Probably in transit
#ubuntu-toolchain 2005-07-22
<lamont> jbailey: btw, Packages.gz doesn't rsync to save it's life.
* lamont wanders
<fabbione> jbailey: ping?
<jbailey> fabbione: pong
<fabbione> jbailey: hey.. 
<fabbione> do you remember how to disable the gcc test suite at build time?
<jbailey> export WITHOUT_CHECK=foo
<fabbione> cool thanks
<jbailey> I should offer doko a patch to make it a DEB_BUILD_OPTION
<fabbione> yeah
<jbailey> glibc uses 'nocheck', and I think cdbs does too
<fabbione> it would make sense to propagate such option as standard
<fabbione> http://home.cwru.edu/~jnt5/Planarity/ <- nice way to trash time :)
<jbailey> It would.  But since policy is a reflection of current best practice, I need to get it in use in a few places first.
<jbailey> If the whole toolchain + cdbs does it, I think it's a good argument.
<jbailey> I'll get that URL from you later.  Currently I don't have X installed. =(
* jbailey shakes his fist at Daniel.
<jbailey> =)
<fabbione> heheh
<fabbione> not too bad.. 8:15 on level 9 :=)
#ubuntu-toolchain 2005-07-23
<jbailey> Eh?
<fabbione> morning
<jbailey> Hey Fabio
<fabbione> hey jbailey 
* jbailey wanders off to sleep.
<fabbione> good night Jeff!
<fabbione> hey doko
<doko> hi fabio
<fabbione> doko: can you give me the mISDN download url please?
<fabbione> i can't find the bug report in that mess
<doko> hmm, I did talk to Simon Richter on Debconf, and he told me that mISDN currently is rewritten, and at the moment more unstable than before.  anyway, it's ftp://ftp.isdn4linux.de/pub/isdn4linux/CVS-Snapshots/
<fabbione> amen
<fabbione> doko: how important it is to get it in?
<fabbione> because extra instability is not exactly what we can efford :/
<doko> I think, I'll try it myself, if I have the time, then eventually ask again for inclusion
<doko> do we stay with 2.6.12?
<fabbione> yes
<fabbione> 2.6.12
<fabbione> doko: btw.. that gcc-4.0 FTBFS on sparc related to gnat
<fabbione> it seems that an extra kick did it
<fabbione> i am going to retest the ICE with 4.0.1 if it manage to build
<fabbione> same for that PAGE_RELINK thingy
<fabbione> if we can't get that fixed in time, we can forget to make breezy
<doko> the gnat thing could be resolved by disabling gnat as well
<fabbione> doko: i think it was the usual moon ray hitting the console cable
<fabbione> because i am the second build now.. with no problems
<fabbione> including gnat
<daniels> meanwhile gcc4 miscompiles i810_drv (as well as libvgahw) and makes my video BIOS try to execute invalid code
<fabbione> daniels: we have the same problem for the kernel with gcc-3.4
<fabbione> we might be forced to switch to gcc-3.3
<daniels> yaaaay
<fabbione> but that introduces another interesting problem in building ppc64 kernels :)
<daniels> heh
<doko> meanwhile xorg is further split, so packages fail to build. meanwhile, there is no l-r-m supporting 2.6.12. daniels, please file bug reports about these miscompilations
<daniels> i'm trying to track down the video BIOS thing, but it's just in my meantime
<daniels> xorg will start working in the next couple of days, l-r-m is less certain
<daniels> the libvgahw one already has a bug report and a xorg patch to hack around it
<doko> daniels: can we make a l-r-m with fewer modules supported? I.e. I could do something to just build the isdn stuff
<daniels> not at this stage
<doko> that's bad. why is this a problem?
* infinity considers updating l-r-m, and wonders if it may result in free alcohol.
<doko> infinity: ahh, you're awake. kdelibs-dev seems to be installable again. please could you requeue OOo2 on i386 and powerpc?
<infinity> Consider it done.
<doko> I would love to hear that about l-r-m too ;)
<doko> so what dose of alcohol do you need?
<fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.1/../../../../lib/crt1.o:../sysdeps/sparc/sparc32/elf/start.S:60: multiple definition of `_PROCEDURE_LINKAGE_TABLE_'
<fabbione> this is the same error as before
<fabbione> (let's forget about the timezone one for a sec)
<fabbione> this is stalling all gnome on sparc
<fabbione> and it's due to -Wl,--as-needed
<fabbione> if i remove that flag it works
<fabbione> but i cannot fork 30 or more gnome packages
<fabbione> and it works in Debian
<fabbione> (buildd shows that at least)
<fabbione> doko: who can we ask?
<doko> jbailey/bcollins?
<fabbione> jbailey: ?
<fabbione> i guess he is vac
<fabbione> Benc is 104 hours idle
<fabbione> oh interesting
<fabbione> crt1.o is from glibc
<fabbione> FUCK all this spent for nothing
<fabbione> ok.. given that's not a gcc problem...
<fabbione> let's dig glibc
<fabbione> no wonder it works on Debian
<fabbione> they didn't switch glibc
<fabbione> i knew that it was too early to do that
<fabbione> i think i found the problem
<fabbione> or better.. what introduced the problem
<fabbione> now the fun is to get the proper fix
<fabbione> doko: how are we doing with C++ transition in universe?
<doko> fabbione: looks ok, the status is still the same as posted to u-d.
<fabbione> doko: so everythin has been uploaded...
<fabbione> i only need to check that i did build the right libs.. right?
<doko> yes, I think one or two libs still don't build, but can't remember which ones
<fabbione> doko: ok..
<fabbione> now it's time to remember where i did put all the info :)
<fabbione> doko: iirc:
<fabbione> || universe || cppunit || libcppunit-1.10-2 || libcppunit-1.10-2c2|| 1.10.2-3ubuntu1 || [http://bugzilla.ubuntu.com/show_bug.cgi?id=10769 10769]  || doko || ||
<fabbione> the 4th field is the one i need to check
<fabbione> '''New Bin'''
<doko> yes
<fabbione> if New Bin is empty ?
<doko> it's the same, i.e. an application, or an KDE app
<fabbione> ok, but i don't care at that point, do i?
<fabbione> i just need to ensure that the libs are built
<doko> yes, you can ignore the empty fields
<fabbione> ok
<jbailey> fabbione, doko 'sup?
<doko> ?
<doko> jbailey: ping?
<jbailey> doko: pong
<doko> <jbailey> fabbione, doko 'sup?
<jbailey> 11:39 < doko> jbailey/bcollins?
<jbailey> 11:41 < fabbione> jbailey: ?
<jbailey> From my /lastlog
<doko> ahh, yesm kast what he did note:
<doko> <fabbione> no wonder it works on Debian
<doko> <fabbione> they didn't switch glibc
<doko> <fabbione> i knew that it was too early to do that
<doko> <fabbione> i think i found the problem
<doko> <fabbione> or better.. what introduced the problem
<doko> <fabbione> now the fun is to get the proper fix
#ubuntu-toolchain 2005-07-24
<jbailey> Oh, I see, it's his sparc fun.
<jbailey> Yeah, I should try to fix that this week.  At least see what the symbol conflict is.
<jbailey> There should be enough of the right people at OLS if I can't answer it myself/
<daniels> doko: http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
<fabbione> morning
<fabbione> jbailey: you around?
<doko> daniels: yep, I'd like to have a test bot which builds some apps with such a modified compiler ...
<doko> lamont, infinity: any news about the 4.0 amd64 build?
<infinity> doko : Hrm, did -2ubuntu2 work around the bootstrap issues?
<infinity> doko : I kicked off a manual bootstrap build on yellow, and noticed that an automatic build on crested was going just fine..
<doko> infinity: no, it cannot
<fabbione> sh[22008] : segfault at 0000000000000000 rip 0000000000000000 rsp 00007fffffe00860 error 14
<fabbione> ld[11285]  general protection rip:2aaaaaaac180 rsp:7fffffbc04f0 error:0
<fabbione> YAY
<fabbione> kiko: thanks a lot
<fabbione> ops
<infinity> doko : Interesting, cause it's well into the testsuite by now.
<infinity> doko : And the chroot wasn't pre-seeded.
<doko> hmm, which lib32gcc1 was installed?
<infinity> 4.0.0-12ubuntu2
<doko> strange
<infinity> Rather, yes.  Either way, I see no obvious failures, and the suite is so far quite happy.
<infinity> I assume the gcc summary should be half failures if -m32 was broken?
<infinity> 34629 expected passes, 2 unexpected failures, 1 unexpected success, 97 expected failures, 28 untested, 433 unsupported.
<infinity> Oh, wait.  That was just for unix.  unix/-m32 is still in progress.  But I don't see any failures output there yet.
<infinity> I'm going to let the manual build run through, just in case the automagic one dies somewhere, but it looks like it'll probably finish, get signed, and upload without my intervention.
<infinity> (Granted, I had a hand earlier in the day in fixing up all the other build-deps, but that was X breakage, not lib32gcc1...)
<doko> looks fine
<jbailey> fabbione: I'm here now for a few minutes.
<doko> infinity: what's the state of the amd64 gcc-4.0 build?
<lamont> Moved gcc-3.3_1:3.3.6-7 to upload-breezy
* lamont does a "semi-happy" dance
<lamont> hrm.. gonna have to bludgeon that upload a bit, since it has 'libstdc++5' in it...
<lamont> (and my scripts strip those from the upload list)
<lamont> and _finally_ gcc-4.0 is trying to build
<lamont> actually, it appears that nothing in gcc-3.3 Depends: libstdc++5.  kewl
* lamont hopes that doko doesn't upload a new gcc-4.0 anytime in the next 10 hours or so
<doko> lamont: desperate hope
<doko> I'll have to do that, because seb128 did upload an API incompatible libcairo :-/
<lamont> I have libcairo1_0.5.1-0ubuntu2 - is the build going to b0rk (and I'll just kill it now), or will it succeed?
<lamont> and if it'll succeed, will it do so before you upload -2ubuntu3...
<doko> the new gcc-4.0 upload will require 0.5.2
<lamont> and besides, you want to wait for infinity to finish amd64, so he doesn't have to hurt you...
<lamont> and you're sleepy... :)
<doko> yep, that's what I'm waiting for
<lamont> still rather early in his day for him to be awake
<lamont> he was fighting with some underlying libraries as of last night when I went to bed...  dunno where he was before he went to bed.
<doko> he said, testsuite was runnign
<lamont> so does that mean that you expect to upload gcc-4.0 w/in 8 hours?
<doko> if infinity wakes up before, yes.
* lamont kills his gcc-4.0 build
<lamont> but no gcc-3.3 upload for an hour or 2, ok???
<lamont> :-)
<doko> no, no 3.3 anymore
<lamont> doko: looking to see what c++ apps I can build on hppa... do you have a list of the build-depended c++libs for each c++app?
<doko> lamont: no
<doko> looking at debian-devel, mfurr did post somethings like this, didn't look, if he was sorting it by lib-dependencies.
* lamont will check d-0d
<lamont> doko: what failure mode would we expect if the apps were built before the libs were?
<doko> libgcj doesn't build, so you would have to disable java
<lamont> doko: it occurred to me that all of hppa is built after the transition, so if I can meet build-deps with pure breezy, it's OK to build.
#ubuntu-toolchain 2006-07-17
* Starting logfile irclogs/ubuntu-toolchain.log
* Starting logfile irclogs/ubuntu-toolchain.log
<BenC> is there a reason that libc6-dev includes scsi/* stuff?
<doko> BenC: no clue, but jbailey currently is not online
<BenC> the three scsi/*.h headers are the only thing in libc6-dev that conflict with linux-kernel-heades
<BenC> that's very interesting, it actually has these files in the glibc source tree
<BenC> so I guess that trumps me including them in lkh...time for another kernel upload :/
<jbailey> doko: thanks. =)
<jbailey> BenC: The opinion that I've always heard was the the Linux SCSI headers were out of date.
<BenC> the ones in glibc's source?
<jbailey> I'd like to start a discussion on the libc list about just using kernel headers now that upstream has decided that they'll actually export usable headers to userspace.
<jbailey> No, the ones in the kernel source for some reason.
<jbailey> So the glibc ones were preferred.
<BenC> makes sense to me
<BenC> ah, ok
<jbailey> I came up against this over the weekend when I was helping out with the NPTL port.
<BenC> well, I reverted lkh exporting scsi/* for now
<jbailey> for hppa, that is.
<jbailey> thanks.
<jbailey> Have you uploaded yet?
<BenC> about 2 minutes ago
<BenC> so it will work its way in
<jbailey> Cool.
<jbailey> oooo..  new lrm.
<jbailey> I wonder if my wireless will work with the edgy kernel./
<BenC> theory is that it will :)
<jbailey> I'll give it a try.  The folks here seem surprised that I was concerned my airplane isn't on the departurs board.
<jbailey> There is, after all, 40 minutes until it leaves.
<jbailey> *sigh*
<jbailey> But I'm guessing that I don't need to rush. =)
* Starting logfile irclogs/ubuntu-toolchain.log
#ubuntu-toolchain 2007-07-16
<marcin_ant> hi all
<marcin_ant> jbailey: hello
<marcin_ant> jbailey: I got a question to you - are you available?
<jbailey> marcin_ant: Well, I woke up less than 5 minutes ago and noticed the nick highlight.
<jbailey> But if you'll accept that I might make no sense, ask away.
<marcin_ant> jbailey: ok
<marcin_ant> jbailey: I hope that now you can talk
<infinity> jbailey: I'd like to ask you some glibc questions, but only if you can guarantee that you won't make sense.
<infinity> jbailey: The bug in question doesn't make sense, so if your response doesn't make sense, we may be in two-wrongs-making-rights territory.
<jbailey> infinity: If you're a true euclidian, you'll know that you need three wrongs to make a right.
<marcin_ant> jbailey: so, my question is about cdbs - because I found your mail in cdbs documentation
<infinity> jbailey: That's three lefts.
<jbailey> infinity: Sure, but they were one-way streets.  I live in Montral.
<marcin_ant> jbailey: I'm trying to prepare package that has source in *.zip file
<jbailey> If there was CDBS documentation, my name probably wasn't on it. =)
<jbailey> At least, not as a copyright holder.
<marcin_ant> jbailey: then I use tarball.mk to unpack this source to build-dir
<infinity> marcin_ant: You're almost certain to get better CDBS support from #ubuntu-motu than from jbailey...
<marcin_ant> jbailey: problem is that I cannot create dpatch because when I run dpatch-edit-patch there is no source in debian directory.. 
<marcin_ant> jbailey: any idea what to do with this problem?
<jbailey> marcin_ant: I have never used dpatch and cdbs together.
<jbailey> I know that quilt works reasonably well, but once you're willing to use tarball.mk, simple-patchsys.mk is a nice choice.
<jbailey> Much less overhead than dpatch.
<marcin_ant> infinity: I did already - no response as far
<jbailey> At that point, just put diffs in debian/patches
<jbailey> They can be either -p0 -p1 or -p2 to apply, it'll figure it out per patch.
<infinity> marcin_ant: The problem with asking Jeff how to use CDBS is the above -- he just tells you to use it the way he does. :)
<marcin_ant> infinity: :D
<jbailey> Given that I have never read any documentation for cdbs, I can't say whether it's well documented or not.  The trick is generally to refer to the source code, which is well commented.
<infinity> We have plenty of packages using tarball.mk and dpatch together, I'm sure.  And some of the MOTUs are sure to know which those are. :)
<jbailey> Although you may need to understand some of the finer points of GNU Make.
<marcin_ant> infinity: can you point me to such package? 
<infinity> marcin_ant: Nope, hence why I suggested the MOTUs. :)
<marcin_ant> infinity: ehh to be honest they are not helpfull but maybe this time ;)
<jbailey> marcin_ant: A Monday morning may not be the best time to find volunteers.  Europe is in their workday, north america isn't awake yet.
<marcin_ant> jbailey: well you are propably right
<infinity> Oh, FFS.
<infinity> as SEGV on lpia...
<marcin_ant> jbailey: another thing is that popably most Europeans are just pretending that they work (it's so hooot here) ;) and studens have holidays
<infinity> Good thing we don't need that.
<infinity> marcin_ant: I'm not pretending to work, I assure you.
<jbailey> infinity: When did you become a European?
<jbailey> Or do you mean racioethnically.
<jbailey> ?
<infinity> jbailey: I'm in London.
<infinity> doko: Be awake, I need someone to yell at.
<jbailey> infinity: Ah, cool.  I hadn't realised you were still there.
<infinity> jbailey: To be fair, I hadn't realised either until a few minutes after I woke up this morning.
<jbailey> heh
<infinity> (I hate that "waking up in a strange place" feeling)
<infinity> "This is not my beautiful flat panel TV, this is not my uncomfortable bed..."
<jbailey> And on Canonical sprints "Who's that in the bed beside me?"
<marcin_ant> London is not in hot part of Europe today (as usual they got ugly weather)
<infinity> Yeah, I have the room to myself now.  No more wondering whose beautiufl wife that was.
<jbailey> And thinking of skieving off, I probably shouldn't my last week of work.
* jbailey heads off to the office.
<doko> infinity: ?
<infinity> doko!
<infinity> doko: Your gcc-4.2 (lpia) and the i386 binutils don't seem to get along.  as SEGVs during the binutils build.
<infinity> doko: And you showed up just as I was considering leaving for the day...
<doko> infinity: which binutils version?
<infinity> The latest.
<infinity> (In both cases: the latest i386 build is being used, and the latest source is being built with it)
<doko> infinity: when built with the lpia gcc?
<infinity> doko: When built with the lpia gcc-4.2, yes.
<infinity> doko: When built using the i386 gcc-4.1, it goes fine.  Haven't tested the i386 gcc-4.2.
<doko> how did you setup your current chroot? do you have gcc-4.1 / gcc-4.2 / binutils / dpkg /apt packages availabel somewhere?
<infinity> doko: I can throw the whole chroot at you, if you have the bandwidth...
<infinity> Including, for bonus points, the failed build tree, and the log.
<doko> infinity: the chroot would be fine
<infinity> Taring now...
<infinity> doko: chinstrap:~adconrad/binutils-failure.tar.bz2
<infinity> doko: For extra points, that tarball is huge because I left all my packages in /tmp ... So, if you need to fiddle around with installing other versions, then reinstalling the lpia stuff, it's there.
<infinity> doko: And the build was as the buildd user in /build/buildd (with a build.log there too)
<jbailey> infinity: Are you sending that of the thread and tin-cans from .au? =)
<infinity> jbailey: I'm not in .au...
<jbailey> Sure, but your build boxes probably are.
<infinity> Nah, this is on molybdenum, in the DC.
<infinity> And if it wasn't, it'd be on my laptop, the fastest x86 machine I own.
<jbailey> Heh.
<infinity> (Also the only x86 machine I own...)
<jbailey> But dude, if you put wheels on it, is there enough surface area to put a grip strip and use it for boarding? =)
<infinity> Nah, I have more purchasing sense than that. :P
<infinity> You're still using the surfboard, I take it?
<jbailey> Angie's going to inherit it soon.
<jbailey> It's a great machine for playing Age of Mythology under wine.
<jbailey> Or Caesar 3.
#ubuntu-toolchain 2007-07-17
* Starting logfile irclogs/ubuntu-toolchain.log
<infinity> doko: Around yet?
<doko> infinity: yes, but didn't succeed with binutils yet, currently another compiler building ...
<infinity> doko: Kay, I have other things to work on, so I'm not blocking on you yet... Just keep me posted.
<infinity> doko: Obviously, this is important to some people. :)
<infinity> doko: And if you want to triple-check with Intel that our spec file is exactly what they want before I go and build the whole archive with it, that will cure some of my anxiety. :)
<doko> infinity: we don't know that ... but I will ask ...
<infinity> doko: I just really, really don't want to have to dump the architecture in a week or two and build it all over again.
<infinity> doko: partially because it'll be a waste of time, mostly because deleting anything from launchpad is unbelievably difficult.
<Mithrandir> doko: are you winning your argument with the toolchain?
<doko> Mithrandir: well, currently experimenting with different optimization iptions ...
<Mithrandir> ugh
* Starting logfile irclogs/ubuntu-toolchain.log
#ubuntu-toolchain 2007-07-18
* Starting logfile irclogs/ubuntu-toolchain.log
<infinity> doko: Any luck with lpia toolchain madness
<infinity> ?
<doko> infinity: small steps, but something usable ... not yet :-(
<doko> already using all x86 computers I have
<infinity> doko: Mmkay... Keep me posted.
<infinity> doko: We can find you DC hardware, if you're low on resources.
<infinity> doko: If it's just time you need, can't help you there. :/
<doko> well, doing more in parallel results in more mistakes ...
<infinity> Story of my life.
#ubuntu-toolchain 2007-07-19
<lamont> doko: can we make the toolchain default to -pipe?
<infinity> doko: ping
<doko> infinity: pong
<infinity> doko: Guten Tag.
<infinity> doko: What do you have for me to play with today?
<doko> ohh, wait ... nice things
<infinity> !
<infinity> I like nice things!
#ubuntu-toolchain 2015-07-19
<zaytsev> doko: hi, just a short question and specifically, any plans for toolchain test build of gcc 5.2 for precise?
<zaytsev> doko: i'm enjoying the gcc 5.1 builds from the toolchain ppa, simply indispensable
