#ubuntu-toolchain 2005-06-27
<fabbione> morning
<jbailey> Fabio!
<fabbione> hey jbailey 
<fabbione> jbailey: apparently the kernel errors on sparc (2.6.12) is something to do with the toolchain
<jbailey> Joy
<fabbione> jbailey: in debian the same kernel (or almost) builds fine
<fabbione> so i am building now in a hoary chroot to see
<jbailey> Both using gcc-3.4?
<jbailey> Or just using the usual default?
<fabbione> both using gcc-3.4
<jbailey> Odd
<jbailey> It shouldn't be any of the glibc bits that I've done.
<fabbione> oh you mean in debian?
<fabbione> debian was the default
<jbailey> So from 3.3 to 3.4
<fabbione> for hoary/breezy i am using gcc-3.4
<fabbione> but
<fabbione> i did try in breezy with gcc-3.3
<fabbione> same results
<jbailey> Hmm, I won't have much time to help you this week.
<fabbione> don't worry
<jbailey> I forgot that gcc summit was this week, so I'll be away a good chunk of the week.
<fabbione> i am only trying to figure out what is causing the breakage
<jbailey> But I'll have my laptop.
<fabbione> once we know what does it, we will have a better idea of what to hunt down
<fabbione> right now there are too many vars in place
<fabbione> infinity: i think i have almost done with ghc6 :)
<fabbione> oh crap
<fabbione> battle star concordia is down
<fabbione> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309317
<fabbione> jbailey: confirmed.. kernel on sparc is a toolchain problem. i am going to update one bit at a time to see what make it fail
<doko> fabbione: ocaml: we have to try it again with 3.4 again, when the X headers are in place
<fabbione> ok
<fabbione> doko: i was only reporting svenl "let's bitch fabbione for doko's stuff" rant on #d-kernel
<fabbione> oh fun
<fabbione> jbailey: you are not going to like this... the kernel link failures happen with the new glibc :)
<fabbione> jbailey: clean hoary -> kernel ok
<fabbione> jbailey: hoary + breezy glibc -> failure
<fabbione> jbailey: please fix libc6. kthxbye
<fabbione> (oh btw.. it does the same with or without NTPL
<fabbione> )
<jbailey> fabbione: Joy.  I need more details.  Like why is your kernel linking with glibc? =)
<fabbione> jbailey: pleasure :)
<Mithrandir> jbailey: I guess makedepend and such is linking with glibc?
<fabbione> probably all the tools are....
<doko> Mithrandir: could you have a look at updating amd64-libs to be able to build the biarch compiler again?
<fabbione> doko: don't even think about uploading gcc-4
<doko> fabbione: no, 3.4 first ;)
<fabbione> or i am going to send you a dead horse :)
<Mithrandir> doko: could you get jbailey to do it?  He's, afaik, working on some stuff for glibc to make it go away.
<fabbione> 3.3 and 3.4 are ok
<fabbione> 4.0 is insane to build
<doko> Mithrandir: promised, I'll pester him ;)
<jbailey> doko: I still need your help on that to get the includedir working right.
<jbailey> The problem is still that glibc doesn't consider i386 and amd64 biarch to one another, so I need to be able to have different headers looked at for -m32 and -m64
<jbailey> I think Tollef's multiarch patch for just the cppFOO.c file
<jbailey> (looking up the actual file name)
<doko> ahh, ok
<jbailey> cppdefault.c
<doko> so let's experiment with 3.4 first, and break the kernel builds
<Mithrandir> jbailey: actually not, it doesn't look at switches, it just adds to the list of include files, IIRC.
<Mithrandir> jbailey: but with a nice set of #ifdef __i386__ and __amd64__ it could work fine.
<jbailey> I'm not really interested in screwing with the glibc headers in ways that they won't accept for the 2.3 branch if I can avoid it.
<jbailey> Since the goal is to have the multiarch patch in anyway....
<jbailey> Basically, I think I just need to move bits/ and the kernel headers into the multiarch include directories, and I should be fine.
<karlheg> Right, no need for that.  Was trying to get xchat to open a separate channel for us, but there isn't really any need.
<karlheg> I've looked over initramfs-tools and am making some changes.
<jbailey> karlheg: #ubuntu-kernel is a better choice. =)
<karlheg> I have it (untested) able to support module arguements, so far, and now I'm looking at hook scripts that run when mkinitramfs is run.
<karlheg> Ok.
<jbailey> lamont: I'll be in a car with Carlos for 7 hours tomorrow.  I imagine hppa hacking will come up at some point.  Anything in particular you want covered? =)
<lamont> hrm... lets see.  Fixing the current 4.0 ICE's would be cool.
<lamont> working TLS would be cool
* lamont will ponder other things to have you beat him with
<lamont> oh, and (of course) getting a gcc-4.0 with the optimizer regression fixed.
<jbailey> And of course to finish his NM. =)
<elmo> concordia is back, for those who care
<jbailey> elmo: Tx.
<lamont> gcj: : No such file or directory
<lamont> make[5] : *** [gnu/java/security/x509/ext/IssuerAlternativeNames.lo]  Error 1
<lamont> doko: is that expected  for -9ubuntu1?
<doko> hmm, interesting ...
<lamont> that's about 4.5 hours into the build, -9ubuntu2 is 2.5 hours into its build
<doko> that won't change
<doko> lamont: hppa?
<lamont> yes
<doko> fix it ;)
* lamont installs gcj into the chroot
<lamont> (missing build-dep?)
<lamont> build-depends on gcj, but does not declare such a build-dep.
<lamont> doko: fix that.  kthxbye
* lamont isn't sure which of the build-deps _should_ be bringing that in, but it probably relates to hppa not having java at all until 4.0, yes?
<doko> heh, hppa does have java starting with 3.3 :-)
<lamont> well, okj
<lamont> hrm.. not in ubuntu main, though. :-)
<lamont> anyrate, it runs the gcj command, which winds up being 4.0 these days.
<doko> ehh, it doesn't run gcj from the build tree?
#ubuntu-toolchain 2005-06-28
<lamont> doko: if it does, it doesn't find it.
<lamont> but the command is a naked 'gcj', not any long path to something local
<lamont> so unless it's editing the path....
<lamont> otoh, we're now past where the failure was, I expect... (logfile is 64KB beyond the size of ubuntu1's failure)
<doko> hmm, can you restart the build with USE_NJOBS=1, if that's a SMP machine?
<lamont> it is SMP, but it's running a uni-processor kernel
<doko> strange
<lamont> I
<lamont> I'll give you a logfile once the build finishes
<jbailey> doko: We should pick a DEB_BUILD_OPTIONS that means 'use -j1' and use it for both glibc and gcc.
* lamont scratches his head
<lamont>  /build/buildd/gcc-4.0-4.0.0ds1/build/gcc/gcj -B/build/buildd/gcc-4.0-4.0.0ds1/build/gcc/ -B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/include -isystem /usr/hppa-linux-gnu/sys-include -fclasspath= "" --encoding=UTF-8 -Wno-deprecated -g -O2 -c ../../../src/libjava/gnu/java/security/x509/ext/IssuerAlternativeNames.java -fPIC -o gnu/java/security/x509/ext/.libs/IssuerAlternativeNames.o
<lamont> gcj: : No such file or directory
<lamont> sigh.  failed anyway
<lamont> doko: people.ubuntu.com/~lamont/toolchain/gcc-4.0_4.0.0ds1-9ubuntu2_20050620-1217.bz2   
<lamont> and -9ubuntu1_20050619-0550.bz2
<fabbione> morning
<doko> fabbione: java not found -> clean up the chroots, there are alternatives laying around, which were not removed
<fabbione> doko: ok
<fabbione> doko: testing now with a clean chroot
<fabbione> or better.. a rebootstrapped chroot
<fabbione> doko: any objections if i fix ocaml FTBFS?
<doko> no
<doko> on i386 as well?
<fabbione> doko: i am checking the reasons why it's FTBFS
<fabbione> one of them is Xorg split
<fabbione> yeah it's the same i see on sparc
<fabbione> yeah it's the same everywhere
<\sh> fabbione, ocaml with with gcc-4?
<\sh> fabbione, you rock dude
<fabbione> no
<fabbione> gcc-3.4
<fabbione> it's still FTBFS because of Xorg
<fabbione> doko: thanks.. upgrading the chroot fixed
<fabbione> jbailey: can you please take a look at the recent iptables FTBFS on all arches?
<fabbione> the logs are full of "AHHHH L-K-H IS CRAP!"
<fabbione> :P
<doko> fabbione: he's on his way to ottawa
<fabbione> doko: oh right
<fabbione> well he will read the scroll back i guess
<elmo> ok, so what am i meant to do about  overrides for  hoary-backports?
<infinity> elmo : Merge any new packages from breezy into the hoary overrides, leave the rest alone?
<infinity> elmo : s/hoary/hoary-backports/ of course.
<jbailey> fabbione: Will do. =)
<fabbione> jbailey: thanks mate
<jbailey> fabbione: I Don't understand your email "any idea if we are safe with this?"
<fabbione> jbailey: forget it sorry.. i found the thread on lkml
<jbailey> 'kay.
<jbailey> The kernel should probably grow a versioned dep on udev.
<fabbione> exactly
<fabbione> but the problem is Md that isn't happy with the latest udev upstream release
<fabbione> so we might be in trouble
<jbailey> In what sense?
<jbailey> We're about to hit UVF aren't we?  What we have has to be good enough.
<fabbione> jbailey: because 2.6.12 Depends: a version of udev that's not even in experimental
<fabbione> that's the problem
<jbailey> Oh?  I thought the update had happened already.
<fabbione> nope
<fabbione> i didn't uplaod .12 final as soon as i heard of this udev issue
<doko> infinity, lamont: please throw poker3d to the buildd's again
<jbailey> The change wasn't between -rc6 and -final, so I think the upload should be fine.  Just don't do linux-meta yet.
<jbailey> I think the change was -rc4 ish, wasn't it?
<fabbione> jbailey: i am not sure there were other changes after
<fabbione> i will have to check with a machine here
<elmo> infinity: hoary-backports now exists, enough for you to setup buildd stuff for it
<elmo> +/lamont
<jbailey> NAh, don't make poor lamont do that stuff. =)
<jbailey> This pain should be ALL Adam's....
* jbailey runs.
* fabbione sighs
* zul sniffles
<fabbione> i guess i won't build it for sparc...
<jbailey> fabbione: What would be the point?  You have no release to backport to.
<fabbione> well hoary was at least installable
<fabbione> as server...
<fabbione> so i still build -security for it
<jbailey> Ah, neat.
<zul> jbailey: where are you leaving ottawa?
<jbailey> via the diefenbunker.
<zul> hehe...they played dr. strangelove there once
<zul> er...when even
<jbailey> Ah, lovely.  I Was trying to guess what you meant.  I apparently guesssed wrong. =)
<jbailey> Saturday morning.
<zul> still too early for irc
<jbailey> Dude.  I used measure that as before midnight. =)
<jbailey> I think I'm getting old...
<zul> you are
<zul> i think i can head downtown on friday, i got to clean the house tomorrow and thrusday i have another itnerview
<zul> crap..i cant spell
<jbailey> Doesn't you work at a government job?
<jbailey> I thought 3 hours lunches were required?
<zul> jbailey: contract ended
<jbailey> Ouch.
<zul> yeah hence the lots of interviews
<jbailey> Right, I thought it was just because you thought the contract might end some day.
<zul> well it did ;)
<lamont-away> elmo: is hoary-backports just another hoary-based suite (hoary + hoary-backports in the list)?
<elmo> lamont: hum.  good question
<lamont-away> and did we decide that -autotest gets the current -test config, and what are we doing with -test?
<lamont-away> because once I know all that, I'll get those changes into the script, and push it everywhere, and you can have all those suites.
<fabbione> morning lamont
<elmo> lmaont, ok, give me a sec, I need to get this CC meeting finish
<elmo> +ed
<lamont-away> morning fabbione 
<elmo> I'm doing far too much context switching
<elmo> and handling it about as well as a Xeon
<lamont-away> elmo: np.  I need to run out the door to get bonnie to school anyway - back on in about 60 min or so
<fabbione> elmo/lamont/infinity: can you please kick back libgtk2-perl_1:1.090-1 on all arches and make sure that it will use the latest glib2.0 to build? (2.7.0a-0ubuntu2)
<\sh> DOKO: YOU ROCK DUDE
<\sh> no...FABBIONE ROCKS AS WELL ;)
<fabbione> uh?
<fabbione> \sh: what did you smoke today? since when doko rocks?
<fabbione> :P
<\sh> fabbione, ocaml :)
<doko> \sh: don't drink before the evening, I know, it's hot
<fabbione> dude i fix the crap doko leaves around and he rocks? ;)
<\sh> doko, only coffee..no alc no drugs during the week ;)
<fabbione> \sh: go and sit in a corner :P
<doko> fabbione: xorg --> daniels
<fabbione> doko: you uploaded ocaml as last :)
<fabbione> you get to fix it ;)
<fabbione> now i just started building xorg...
<fabbione> wanna-bet that they will upload -33 before i get to upload the build?
<doko> infinity, lamont, lamont-away: please throw poker3d to the buildd's again
* lamont is bakc
<doko> infinity, lamont: why does ginac not build? it's dep-wait, but the dep is there
<lamont> main vs universe??
* lamont looks
<lamont> um, ginac_1.3.0-2 is successfully built for all 4 architectures, as of april.
<lamont> or is there a newer one?
<doko> lamont: yes
<doko> 1.3.0-2ubuntu2, hmm, but I didn't get the ack for the upload
<doko> u ginac_1.3.0-2ubuntu2.diff.gz upload.ubuntu.com Tue Jun 21 14:31:29 2005
<doko> u ginac_1.3.0-2ubuntu2.dsc upload.ubuntu.com Tue Jun 21 14:31:30 2005
<doko> u ginac_1.3.0-2ubuntu2_source.changes upload.ubuntu.com Tue Jun 21 14:31:30 2005s ginac_1.3.0-2ubuntu2_source.changes upload.ubuntu.com Tue Jun 21 14:31:30 2005
<doko> "coordinate very closely with laminity" (elmo quote)
<doko> lamont, infinity: please highlight laminity in your log
<doko> hmm, sounds like calamity ... ;)
<lamont> it's NFU --> waiting for release.
<lamont> I'll do all 3 of them.
<lamont> kicked
<lamont> all of the blacklisted apps will require manual intervention before they next build
<lamont> (just as an "oh by the way"
<lamont> )
<lamont> any elmo-sign lately?
<doko> lamont: all packages given back
<lamont> are those all 3 universe packages
<lamont> ?
<lamont> yep.
* lamont kicks them harder, this time without the attempt at optimizing
<lamont> they should try just after :33
<elmo> fabbione: can you please get 2.6.12 seeded?
<lamont> doko: they'll try eventually... given-back things are delayed on their retries
<lamont> elmo: -test and -autotest will use rockhopper?
<elmo> yes
* lamont notes that -backports should already "just work" in the script, assuming that hoary-backports is derived from hoary, and not hoary-updates or some such
<lamont> and I changed -test to -*test, so we can have lots of them. :-)
<lamont> and I'll need to know once -cat is in w-b
<lamont> does  breezy+1 have a name yet?
<elmo> etch
<elmo> oh, wait, that's not right
<lamont> someone quotes file that
* daniels giggles.
<elmo> FABBIONE 
<zul> i think he is having a break elmo
<elmo> concordia is down again.  coincidence??? I DON'T THINK SO\
<elmo> ;p
<lamont> iz gtk bug
<zul> hehe
<elmo> lamont: do you need anything more from me for hoary-backports?
<lamont> elmo: I don't think so - assuming it's basically the identical template as -updates
<lamont> wow.  and english is my native tongue.  go figure.
<lamont> and assuming that -autotest is identical in config to -test
<lamont> then the only thing I have to pester you about is setup for logs@buildd.u.c
<lamont> elmo: is there stuff for hoary-backports to build now, if I created it?  or can I build all them chroots in a few hours?
<elmo> -backports exists enough for chroots
<elmo> none of them are in w-b yet
<elmo> rockhopper's stalled on overrides, I think
<elmo> which I'll try and fake in a bit and get ready, but mdz's stressing over -backports, so don't stall that on the other 3
<lamont> ok.
<lamont> creating -backports is a simple matter of 'sudo build-chroot buildd hoary -backports' in ~buildd - but adding that to the config will result in bitchiness from buildd until w-b has it
* lamont creates the chroots, but doesn't put them in the config
<lamont> hrm.. and speaking of overrides - /me tries to remember the process for getting libgcc2/hppa into main
<lamont> elmo: hoary updates doesn't exist for ia64, fwiw
<lamont> after a bit of thought, that doesn't surprise me terribly
<elmo> yes, feature
<fabbione> elmo: both Kamion and mdz were working on 2.6.12 seeded..
<fabbione> and no.. i didn't even login on concordia today
<fabbione> i am using davis as my test bitch
<lamont> fabbione: so you have a cronjob, eh?????
<fabbione> given that davis > concordia
* lamont ducks
<fabbione> concordia is teh suck
<fabbione> lamont: ahah
<\sh> lamont: can u check this please: aqsis_0.9.1-2ubuntu1 on ia64 failed to build because he couldn't find the source?
<\sh> forget it ...wrong one
<lamont> \sh: uh, that's a long time ago...
<fabbione> \sh: just say to give it back :)
<lamont> and the current bits are good
<\sh> yeah ;) 
<lamont> fabbione: remind me to throw something at you sometime, eh?
<\sh> i'm not be here...just fall asleep and got up :(
<fabbione> lamont: sure :)
<fabbione> speaking of which
<fabbione> lamont: can you give back libglib-perl on all arches?
* lamont goes to see which definition of "give-back" we're using atm
<fabbione> lamont: now that the fixes glib2.0 is in the archive, it should build fine
<fabbione> lamont: --give-back
<fabbione> wanna-build -d breezy --give-back libglib-perl
<fabbione> (arch all please)
<lamont> I don't think --arch=all will do the right thing, will it?
<lamont> in any case, given back
<\sh> ah.is there a documentation for those commands?
<lamont> apt-get install wanna-build
<fabbione> lamont: we might need to ensure that glib2.0 will be the last one builded
<lamont> fabbione: otherwise it'll fail again and I can retry it again?>
<fabbione> lamont: exactly :)
<lamont> np
<fabbione> lamont: danke
<lamont> doko: any chance of fixing that hppa regression in our gcc-4.0?
<lamont> ahead of upstream, that is
<doko> did you talk with tausq about it?
<doko> should we go back to 3.4 for hppa?
<lamont> elmo: how do you feel about flushing hppa .debs from the archive, for a full rebuild with 3.4?
<lamont> haven't talked with tausq yet
<elmo> lamont: *shrug*
<lamont> will that tend to mirror well?
<elmo> that's why it's on ports.u.c ;)
<elmo> doesn't affect our main mirrors
<lamont> that is, the mirrors use something that checks md5sums, yes?
<lamont> ah, coolness.
<lamont> gcc-3.4 will need binutils-hppa64 promoted to main, fwiw
<lamont> doko: g++-3.4 will still get us to libstdc++6, yes?
<doko> lamont: yes
<lamont> sigh... much though it pains me, having a totally untrustworty archive is worse than having a less complete one...
<lamont> doko: you want to upload a new gcc-defaults with hppa set to 3.4, or shall I?
<doko> lamont: please do, then I won't have to fiddle with it ;)
<lamont> doko: np./
<doko> I'm away until 22:30 UTC
<lamont> elmo: can you clone the hppa bits on ports.u.c somewhere for me, and then nuke them?
<lamont> from ports, that is.
<lamont> I've killed the uploader, and I'll get it building once I upload a new gcc-defaults and clean up the home archive.
<lamont> on the bright side, I should have 2 A500's working on the problem sometime this week
<lamont> hrm... guess I should send email to ubuntu-devel, eh?
* lamont lunches.  back on in a while
<lamont> on the down side, one of those A500's will be in my cube.
<Riddell> doko: wv2-0.2.2 havn't been recompiled for new ABI
<\sh> doko, I trying again gnuradio...there were some new things and fixes in CVS so I'm building cvs head now of new gnuradio-core
#ubuntu-toolchain 2005-06-29
<fabbione> morning
<infinity> Grr.
<infinity> fabbione : DO you really need to drive davis's load up to 140, leaving no headroom for me to do simple things like "ls"?
<zul> ahahaa
<infinity> (Seriously, it just took about 20 seconds for "ls" to return on a directory with 3 files)
<fabbione> infinity: ops.. i tought i was alone
<fabbione> there.. only 50 :)
<infinity> How thoughtful of you. :P
<fabbione> infinity: i am only doing disk I/O
<fabbione> and not even that much
<fabbione> the CPU's are almost free
<doko> elmo: please sync gcc-3.3 from unstable
<elmo> done
<doko> lamont: please see gcc-defaults-1.24 in my home on chinstrap.
<fabbione> doko: or from incoming? :)
<doko> yep, hppa specific
<fabbione> eheh
<doko> elmo: please sync java-gcj-compat from unstable
#ubuntu-toolchain 2005-06-30
<fabbione> morning
<elmo> NO WAY
<elmo> fabbione: dude, now you've killed crested :-P
<fabbione> no shit :)
<fabbione> i have no access to it :P
<lamont__> elmo: ping
<jbailey-gcc> lamont, lamont__: ping?
<lamont__> jbailey-gcc: yo
<jbailey-gcc> lamont__: Was chatting with an IBM ppc guy, and he recommended that we do -mtune=power4 on ppc.
<lamont__> iz certainly possible
<lamont__> prolly wants to be an overridable tune, thouhg.
<jbailey-gcc> Are we able to do that?
<jbailey-gcc> I don't know how important allowing the package to override tune is, mind you.
<lamont__> overrides come in 'if they don't say anything', always clear, and always force varieties.
<jbailey-gcc> -mcpu is far more important to let the package override.
<lamont__> yeah, but when the, oh say video/audio app, specifically builds things tuned for each of 3 processor families, overriding all of them to one specific family is, um, not so good.
* lamont__ whistles
<jbailey-gcc> Right. =)
<jbailey-gcc> Hmm, just chatting with James Morrison who hacks on the gcc sparc backend, and he's suggested that we might want to give similar treatment to sparc.
<jbailey-gcc> although in that case we should do both mcpu and mtune, and possible mvis
<lamont__> happy to take tunes - if you could email me the lot of them, I'll probably push new bits sometime soonish
<lamont__> like after the weekend
<lamont__> as it sits, the only thing we force on !i386 is -pipe
<jbailey-gcc> I remember that, so I've been trying to find out interesting settings. =)
<lamont__> please.  and thanks
<jbailey-gcc> Will do.
* jbailey-gcc runs off.
<cfan>  hi.. i want to shift to debian from fedora core 3.. can people tell me what flavour i should use in debian
#ubuntu-toolchain 2005-07-01
<doko> fabbione: ping
<daniels> doko: i don't think he's going to be back until monday
<doko> ahh, ok
<zul> quiet today
<jbailey-gcc> fabbione: *pout* New kernel upgrade breaks my suspend-to-ram...
<lamont__> elmo: ping
<jbailey-gcc> g'm LaMont
<lamont__> morning jbailey-gcc 
#ubuntu-toolchain 2005-07-02
<fabbione> morning
<infinity> Morning, Fabio.
<fabbione> hey infinity 
<fabbione> AYE
<fabbione> they will upgrade my adsl soon
<fabbione> 6Mb/768k
<infinity> See, now I hate you.
<infinity> I'm stuck at 1.5/256 for at least the next 6-9 months.  Maybe longer.
<fabbione> i didn't decide to upgrade
<fabbione> my ISP did lower the prices
<fabbione> and they did send me a notification that they will increase my bw for the same price
<fabbione> from 2M/512 to the above
<fabbione> i can decide to lower the price and keep the bw :)
<fabbione> but more bw > *
* fabbione increases the ubuntu and debian mirrror partitions a bit more
<infinity> I assume you just carry partial mirrors?
<Riddell> doko: did you see that wv2 needs recompiled for gcc 4?
<daniels> christ, 6mb
<daniels> infinity: armadale doesn't have the iinet dsl2 infrastructure?
<elmo> infinity/lamont?
<elmo> sorry, my bad.
<elmo> laminity: ?
<elmo> daniels: I got suckered into upgrading a breezy chroot and have a fucked X (libx11-6 vs xlibs-data, file overwrites and conflicts)
<elmo> daniels: is there a safe way to get out of this, or shall I just brute --force my way out?
<Mithrandir> elmo: --force-depend-ing in the libx11-6, then just running apt-get -f install works, iirc.
<elmo> Mithrandir: good call, that seems happy.  thx
<daniels> elmo: yeah, need to fix that, thanks
<infinity> elmo : You rang?
<infinity> daniels : No, our exchange (Malvern) is scheduled to get iinet DSLAMs in Q3 this year.
<daniels> nice
<infinity> elmo : Also, when do my two dead buildds get CPR? :/
<elmo> infinity: tomorrow, I hope
<elmo> infinity: hoary-backports is ready
<elmo> on the katie side - are buildds ready?
<daniels> you're shitting me
<infinity> They will be first thing in the (my) morning, tomorrow.
<daniels> backports.
<infinity> daniels : Bring it up tomorrow, if you want to hear a drunken rant on the subject.
<daniels> sounds like a plan
<daniels> it sounds like arseloads of crack though
<daniels> (and I do mean literal arseloads -- snorting it off a hooker's arse, in this case)
<infinity> elmo : Does it allow source-only uploads from the main keyring, or only automated source "copies"?
<elmo> nothing yet
<elmo> well, everything atm
<elmo> I'm not sure how best to tie it down and/or import source atm
<infinity> Right. :)
<infinity> Yeah, me neither.
<infinity> The whole thing is kinda making me want to cry.  I don't think anyone's really thoguht this through.
<infinity> ie: Without compartmentalising this in small "package groups" (ie: backport foo, bar, and baz, which al interdepend, but nothing else, lather, rinse, repeat), are we not going to end up with all backports being built against each other to the point where hoary-backports looks a lot like "breezy on hoary's glibc"?
<infinity> I'm frightened. :)
<infinity> Oh well.  I'll whine later.  I'll make the buildds go in ~12 hours, and we can shove some source packages through to make sure it's happy or something.
<fabbione> infinity: ahhaah
<fabbione> "breezy on hoary's glibc"?
<fabbione> infinity: what does make you feel so sure that new glibc won't land in backports?
<infinity> Because we'll blacklist it?
<jbailey> fabbione: If it does, I quit. =)
<infinity> I'd prefer to blascklist all of main, but I don't think that'll fly. :/
<fabbione> but new glibc are sooooo 31337
* infinity -> anywhere without a computer.
<fabbione> cya infinity 
<fabbione> i am going to stop soon too
<fabbione> for once i want to try the experience to stop within the contract working hours
* fabbione goes offline for a little while
<chmj> jbailey, 
<jbailey> Heya Charles
<chmj> jbailey, ping 
<chmj> hello 
<lamont> elmo: buildd's are just waiting to be told to add it to the dist list
<lamont> unless infinity already did that
<lamont> hrm... crested doesn't seem to be happy
<fabbione> hey lamont 
<fabbione> isn't crested one of the 2 dead amd64 buildd?
<fabbione> together with king
<jbailey> lamont: Heya, lagging on the gcc-opt stuff I owe you, I'll try soon.
<lamont> yeah
<doko> jbailey: I was looking into multiarch support, and discovered, that we always include i486-linux, even if we are compiling with -m64. Mithrandir did tell me you do know about it. So currently we cannot add multiarch support until it's fixed.
<jbailey> doko: ISTR that I also suggested how to fix it...  I can cook up a patch and pass it around for review.
<doko> jbailey: did I miss something? I cannot find a report or an email
<jbailey> No, when I told Tollef.
<doko> ahh, ok
<doko> infinity: ping
#ubuntu-toolchain 2005-07-03
<infinity> doko : pong.
<fabbione> morning
<doko> infinity, lamont: please push tulip to the buildd's on powerpc and ia64
<lamont> doko: given back
<doko> lamont: clanlib as well please
<lamont> doine
<doko> thanks
* lamont sleeps, noting that it's 0130 local
<fabbione> hey good night lamont
<doko> elmo: do you removals of packages from universe, or do the MOTU's handle these (i.e. librudiments0 source)
<jbailey> fabbione: ping?
<fabbione> jbailey: pong
<jbailey> I donj't see that initrd-tools bug anymore, did you steal it back from me?
<jbailey> Or am I just sleepy still and missing it? =)
<fabbione> 12040
<jbailey> OH, I See.  Just highi on the list from no comments, my bad.
<jbailey> Did you get a chance to look at it at all?
<fabbione> jbailey: yes.. i told you what the problem was and you said you were going to fix it before this morning :)
<fabbione> so that i could test it on carlos machine
<fabbione> but we are anyway too late to get it in for today
<fabbione> we need to upload a kernel asap
<jbailey> Umm, I told you that I would have it for you for today.  I attached it to the bug last night.
<jbailey> There's a new mkinitrd on there.
<fabbione> CRAP
<fabbione> i didn't get the mail
<jbailey> Oh, you're not cc:'d on the bug.
<jbailey> Hadn't even though to look. =(
<jbailey> thought, rather.
<jbailey> Although the QA contact is setu.
<fabbione> let see if carlos is around..
<fabbione> otherwise tough luck
<fabbione> jbailey: bingo
<fabbione> modprobe -k  unix 2> /dev/null
<fabbione> modprobe -k  megaraid_mbox
<fabbione> modprobe -k  megaraid
<fabbione> modprobe -k  sd_mod
<fabbione> jbailey: ok.. we are still in time...
<fabbione> can you upload the changes on the fly and tell me the initrd version?
<jbailey> Sure, gimme a sec.
<fabbione> perfect
<jbailey> initrd-tools-0.1.78ubuntu2
<fabbione> perfect
* jbailey wonders if there's anything else that needs to go in here urgently.
<jbailey> Suck, bugzilla doesn't let me go directly from needsinfo to pending upload.
<fabbione> yeah just close it
<fabbione> if you can also upload it.. the kernel i am uploading in 10 minutes will be more happy :P
<jbailey> Off she goes, check for her at the :03
<fabbione> yup.. great
<fabbione> kernel is on the way too
<fabbione> i am having a stupid problem with linux-meta
<fabbione> Package: linux
<fabbione> Architecture: i386 amd64 sparc ia64
<fabbione> Section: restricted/base
<fabbione> Priority: optional
<fabbione> Depends: linux-386 [i386] , linux-amd64-generic [amd64] , linux-sparc64 [sparc] , linux-itanium-smp [ia64] 
<fabbione> Description: Generic complete Linux kernel.
<fabbione>  This package will always depend on the latest generic complete Linux kernel
<fabbione>  available.
<fabbione> for some reasons building it...
<jbailey> I don't think you can do depends like that.
<fabbione> the Depends line doesn't appear at all in the control file inside the deb
<jbailey> Only build-dep
<jbailey> Depends lines are supposed to be generated if you need that type of magic.
<fabbione> ah crap
<elmo> jbailey: you can do that with modern dpkg, actually
<jbailey> Oh, cool. =)
<elmo> err, I think.
* fabbione checks what version of dpkg is using
<elmo> I thought you could - it was something doogie added quietly
<elmo> scott may have un-added it :)
<jbailey> When a gave a shit about hurd-i386^UThat would have been handy a while ago...
<fabbione> elmo: no it doesn't.. :/
<jbailey> fabbione: BTW, James Morrison said he'll look at the sparc generation bug for us as soon as I get him a sparcstation online to hack on or get one shipped to him (since I have his old sparc box)
<fabbione> ah cool
<jbailey> I'll get the U5 hooked up after I move, but I will probably start a hunt for a slightly sexier box shortly after that. =)
<jbailey> We need someone big and corporate to be interested in sending us sunblades. =)
<fabbione> i know
<jbailey> I wonder if BenC is still willing to send me one on the Debian side.
<jbailey> He had mentioned that I Should talk to him about it.
<fabbione> substvars hates me
<fabbione> cat linux-meta-2.6.12.2/debian/substvars 
<fabbione> generic-depends=linux-386
<fabbione> Depends: ${generic-depends}
<fabbione> dpkg-gencontrol: warning: unknown substitution variable ${generic-depends}
<fabbione> GRRR
<fabbione> what am i missing?
<fabbione> the substvars file is created way before the call to gencontrol
<Mithrandir> try dpkg-gencontrol -Vgeneric-depends=linux-386  ?
<Mithrandir> not that it should make a difference, tho
<jbailey> Is it being masked by a per-package substvars?
<Mithrandir> or you could make it be Depends: linux-${Arch} if that was appropriate.
<fabbione> unfornatly it's not map 1:1
<fabbione> for arch i mean
<fabbione> jbailey: nope.. it's the only one
<fabbione> dh_gencontrol -s -Vgeneric-depends=linux-386
<fabbione> dpkg-gencontrol: warning: unknown substitution variable ${generic-depends}
<fabbione> tho
<jbailey> fuckage with -'s?
<jbailey> try genericDepends ?
<fabbione> dh_gencontrol -s -VgenericDepends=linux-386
<fabbione> dpkg-gencontrol: warning: unknown substitution variable ${genericDepends}
<fabbione> nope
<fabbione> there fixed
<fabbione> you need to tell gencontrol from what file to grab the vars.. go figure
<elmo> laminitiy: crested/king are back
<elmo> pls don't retry ruby until I get a chance to upgrade the kernel
<elmo> speaking of - fabbione, what's the status of 2.6.12, is the one I just de-NEWed good to go?
<lamont__> hppa builds gcc-3.4, preparing for a fresh start
* lamont__ seems to recall that the order was {doxygen,expect-tcl8.3}, gcc-3.4, glibc, the world
<lamont__> oh - gcc-defaults too.
* lamont__ tries to remember if he wants the new glibc before or after gcc-{3.[34] ,4.0}
<lamont__> before.
* lamont__ notes that toolchain deps are even worse now
<lamont__> order is: {doxygen, expect-tcl8.3[hppa] , dpkg}, {linux-kernel-headers, binutils}, binutils, glibc, gcc-{3.[34] ,4.0}, gcc-defaults 
<lamont__> oops, scratch that second binutils. :-)
<lamont__> and then there's xorg. :-
<lamont__> (
#ubuntu-toolchain 2006-06-29
<fabbione> doko: ping?
<fabbione> doko: do i need to rebuild also gcj-4.1 to test? or gcc is enough?
<doko> fabbione: what do you want to test?
<fabbione> the patch to fix glibc build
<fabbione> the one i did past to you in the mail
<fabbione> glibc on sparc is FTBFS because of gcc
<doko> no, shouldn't be needed
<fabbione> ok thanks
<fabbione> dear doko, please make gcc build support -j
<doko> fabbione: USE_NJOBS=yes dpkg-buildpackge ...
<fabbione> why isn't it on by default?
<doko> broken for gpc, currently on hppa, logs easier to read, and I don't care how long a build takes on the buildd. 
<fabbione> ok.. how do i disable the test suite?
<fabbione> actually.. it might be a good idea to run it
<doko> WITHOUT_CHECK=yes WITHOUT_LANG=ada,treelang,objc,f95 might help as well
<fabbione> with 24 CPU i am ok :)
<fabbione> it was just taking toooooo long
<doko> fabbione: so when do we get developer access to this machine? ;-P
<fabbione> doko: there are 2 at the datacenter.. access is under jbailey and elmo control afaik
<fabbione> doko: i completed the install tests and returned the boxes
<fabbione> i think they are in cr3 hands right now for hw certification
<fabbione> but after that we should be able to share access to them
<fabbione> doko: you should try to ping elmo/jbailey in canonical and ask them directly
<fabbione> they really should be able to give you a better answer than me
<fabbione> *** glibc detected *** ./pthread1.exe: malloc(): memory corruption (fast): 0x0002fbb8 ***
#ubuntu-toolchain 2007-06-25
* Starting logfile irclogs/ubuntu-toolchain.log
<bashelier> hello mr doko_ :)
<doko_> hi
<bashelier> doko: I have a few patches for gcc build system, because it ftbfs when cross compiling, there are several issue to bi fixed, do you have a minute ?
<doko> sure, best thing would be to submit these patches as an attachment to a bug report, so we both see these patches
<bashelier> doko: will do, thanks :)
<bashelier> (have to finish gdc for gcc-4.1 too... :p)
<bashelier> doko: the easier problem to fix come from gcc-4.2, see https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/121843
<bashelier> doko: and here is a sample of package I have built with my patches, http://packages.mefab.effraie.org/ :)
<bashelier> (there are about 4 or 5 problems in build system, but nothing realy serious)
<Mithrandir> doko: have you uploaded the LPIA-enabled gcc yet?
<doko> Mithrandir: no, test builds running, needing a fixed dpkg  as well
<Mithrandir> oh, what needs changing in dpkg?
<doko> dpkg-architecture, i486 -> i686
<bashelier> doko: will the 686 be the default x86 architecture in ubuntu ?
<doko> no
<bashelier> ok thx
<Mithrandir> doko: can you just change it then?
#ubuntu-toolchain 2007-06-29
<bashelier> doko_: thanks for mentioning my name in the changelog... this was nice :)
#ubuntu-toolchain 2010-07-04
<jussi> jbailey: ping
