#ubuntu-toolchain 2005-05-23
<doko> fabbione: you can find the gcc-3.4 build for sparc in my home on chinstrap. did build properly in a fresh breeeezy chroot
#ubuntu-toolchain 2005-05-24
<jbailey> lamont: *poke*
<doko> jbailey: I cannot reproduce fabbione's build failures of 3.4 on sparc, so the toolchain seems to be in shape for all archs except hppa ...
<jbailey> doko: Great.  I'm just about to do the hppa work.
<jbailey> doko: Did you and lamont touch the -0ubuntu4 glibc that I put on chinstrap to enable biarch amd64?
<jbailey> Oo, looks like goto might have already done a bunch of the porting work.
* jbailey builds what Debian has on hppa to see.
<doko> jbailey: no
<doko> gcc cannot do biarch for hppa
<jbailey> doko: 'kay.  The last point was the libgcc1 depends on amd64-libs, and I'm conflicting against it.
<jbailey> No, I meant the biarch i386/amd64 stuff
<doko> haven't tried yet, I'm currently working on the C++ ABI transition
<jbailey> It works fine.  I need to know what you want to do about the amd64-libs confict.  I'd like to just conflict against it, and ask for it to be removed from breezy.
<jbailey> But I don't want to cause you more problems enabling the biarch compiler.
<jbailey> Or I can drop this all until the C++ transition is done.
<doko> yes, the latter would be nice
<jbailey> 'kay.  I will get hppa in shape today hopefully and get a glibc uploaded.
<jbailey> I have ppc64 ready to go and amd64 ready to go as soon as you have time for either of those.
<doko> yes, let's decouple these, although svenl is poking about ppc biarch
<jbailey> No prob decoupliung them, but there's no reason not to do them in the same day.
<jbailey> Given that we have to coordinate them at the time, it might be easiest if one of us handled them, or if we locked down a time for you and I to sit down at the same time and slug through them when we're ready.
<doko> feel free to update the gcc packages :-)
<jbailey> Cool, I can do that.
<jbailey> I'll do the c++ transition with you first though.
<doko> jbailey: looks like it's finished for the libraries in main, although the motus may need some support converting the remaining universe libraries
<jbailey> WOw, that's incredible.
<jbailey> Did you sleep? =)
<doko> a bit
<jbailey> When are you bumpding gcc-defaults?
<doko> anyway, I'll sleep *now*
<doko> when lamont and elmo are awake and syncs & uploads for same packages are frozen, maybe Mo/Tu
<jbailey> Cool, good sleeps doko.
<lamont> jbailey: note that the new glibc is still waiting for a usable libgcc1
<jbailey> lamont: Right, Sounds like we'll wait until later this week when gcc-defaults bumps, and I'll pick a time to sit down with you and Just Do It from all sides, including gcc.
* infinity stares at doko.
<jbailey> infinity: It's not nice to stare at someone when they're sleeping.
<infinity> When did we go from "help us out on Monday/Tuesday" to "finished for the libraries in main"?
<infinity> Oh well.  I'd feel more guilty, if I hadn't been moving all weekend.
* jbailey fires up an hppa glibc build with Carlos' patches.
<jbailey> Off to watch a show while this builds.
<svenl> hi jbailey 
<svenl> jbailey: did you not want to send me some new biarch glibc packages ?
<jbailey> svenl: I posted them, didn't I?
<jbailey> Nope, I didn't.
<jbailey> svenl: Sending, I'll let you know when it's done.
<jbailey> Hmm.  I think I need to spend part of tomorrow moving glibc bits into baz or something.
<jbailey> svenl: http://testhaus.cns.utoronto.ca/~jbailey/ppc64-nptl/
<jbailey> svenl: Bed time now. I'll be back in around 6 hours.
<svenl> jbailey: ok, thanks.
<svenl> I want the source packages also :)
<doko> morning all
<chmj> morning doko 
<doko> hi chmj 
<doko> infinity: there are more things to do ...
<Riddell> doko: what's the status of the toolchain transition?  has any qt/kde stuff been uploaded or is that tomorrow?
<doko> Riddell: qt and kdelibs are prepared, amu did a qt 3.3.4 merge
<doko> Riddell: please search the BTS for gcc-4.0 and prepare patches for the kde specific things. I don't know, if amu did work on these
<Riddell> doko: how can I change over to g++ 4 to test things?
<doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
<doko> see the sources line at the top
<Riddell> thanks
<chmj> doko, is the g++4.0 app test build been done ?
<doko> chmj: which one?
<chmj> I mean,all apps. there is surpose to be an automatic rebuild right ?
<chmj> so we can see which ones fail? 
<doko> chmj: yes, this one is prepared as well. Riddell, do you want to do this for the KDE apps?
<Riddell> doko: sounds like a good idea, what would I have to do?
<doko> Riddell: make a chroot, add my test builds to it and rebuild all of KDE in main ;)
<Riddell> doko: I'll give it a shot
<chmj> doko, what do you mean prepared?
<doko> chmj: sources ready for upload
<chmj> doko: sweet 
<doko> svenl: ocaml FTBFS with 4.0
<svenl> doko: mmm.
<svenl> doko: on ubuntu ? 
<svenl> doko: i will have a look later on ppc.
<svenl> doko: or maybe you do have a log ? 
<svenl> doko: what version of ocaml is this anyway ?
<doko> svenl: should fail in unstable/experimental as well.
<svenl> doko: well.
<svenl> doko: i prefer working on the ubuntu/breezy machine, i have killed the hoary install by installing random glibc/gcc upgrades anyway.
<svenl> doko: i will contact upstream if we have something serious and get a patch.
<fabbione> re
<fabbione> doko: as i said.. right in time :)
<svenl> doko: if i have both gcc-4.0 and gcc-3.4 installed, which one will it default to ? 
<jbailey> svenl: That's up to gcc-defaults
<svenl> jbailey: hi.
<jbailey> svenl: Check to see what /usr/bin/gcc points to.
<svenl> jbailey: so how do i make sure gcc-4.0 is used ? CC=gcc-4.0 ? 
<jbailey> Yup
<jbailey> Although in Breezy, that's the default now.
<jbailey> CXX is still gcc-3.4, though
<jbailey> err.
<jbailey> 3.3
<svenl> gcc-3.3
<doko> ocaml? no, there's something like -cc gcc-4.0 in debian/rules
<doko> svenl:  deb  http://people.ubuntu.com/~doko/GCC-4.0/i386 ./
<svenl> launch started.
<svenl> doko: what should i do with that ? I have some serious doubt it will be usefull on my powerbook.
<doko>  deb  http://people.ubuntu.com/~doko/GCC-4.0/powerpc ./
<svenl> doko: not the official gcc-4.0 in breezy ? 
<doko> you did want to change the defaults, didn't you?
<svenl> nope, its ok, i use the -cc gcc-4.0 trick, should do just fine.
<svenl> ok, build launched, will tell you how it goes. Is using jbailey's latest glibc.
<jbailey> svenl: the ppc64 snap that I gave you?
<svenl> doko: i would really like to build a biarch compiler myself though.
<svenl> jbailey: sure.
<jbailey> Cool.
<svenl> jbailey: i killed my hoary install anyway, upgraded to breezy, and installed your snaps.
<doko> why do you try to compile ocaml on powerpc?
<jbailey> svenl: Remember to pin glibc.
<doko> it works
<svenl> doko: do you think i will have more chances in the gcc-4.0 ?
<jbailey> svenl: There's a newer one than that in the archive that doesn't have ppc64 support.
<svenl> doko: because i have powerpc machines.
<svenl> jbailey: mmm.
<svenl> jbailey: how do i pin glibc ?
<jbailey> svenl: Something in some apt configuration.  In practice, I just don't run apt-get upgrade after.
<svenl> jbailey: :)
<svenl> jbailey: maybe better would be to always rebuild newest ppc64 enabled glibc for each official version, so you don't have this problem.
<jbailey> svenl: I was thinking earlier that I might move the glibc packaging into bzr so that it's easy for me to do updates of the biarch i386/amd64 and ppc/ppc64 glibcs that aren't in the archive yet.
<svenl> jbailey: when will they be in the archive ? 
<svenl> doko: do you mean the gcc-4.0 on powerpc will not manifest the ocaml bug ? 
<jbailey> svenl: amd64 support will go in the archive after the c++ transition is finished (I don't want to interfere with that)
<jbailey> svenl: ppc64 will go in the archive as soon as we figure out how to make the biarch compiler build on a 32 bit kernel.
<jbailey> (subject to the same limitation as amd64 beyond that)
<doko> svenl: http://people.ubuntu.com/~lamont/buildLogs/o/ocaml/3.08.3-3/
<svenl> doko: oh.
<svenl> doko: well.
<svenl> doko: i guess gcc-4.0 is buggy on i386.
<svenl> bng_ia32.c: In function 'bng_ia32_mult_add_digit':
<svenl> bng_ia32.c:111: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
<svenl> well.
<svenl> doko: i don't deal with register starved broken archs :)
<svenl> doko: i can't really help you there, i have one amd64 with a pure64 install and only ppc boxes apart from that, and one m68k.
<doko> svenl: install a i386 chroot on your amd64 ;-P
<jbailey> svenl: Going to start the Ubuntu m68k port? =)
<svenl> doko: i would write to http://pauillac.inria.fr/bin/caml-bugs
<svenl> jbailey: nope.
* jbailey would love to see m68k and arm as the first buntu targets.
<svenl> jbailey: i lost my apus card, so only an mmu-less 68020 in it.
<svenl> oh, but i have an amiga 4000 waiting for me in oberursel.
<svenl> will try to get it next week.
<svenl> doko: i could do that.
<svenl> doko: not today though.
<svenl> doko: what is your email address ? 
<fabbione> hey doko
<fabbione> hi svenl
<svenl> doko@ubuntu.com ? 
<doko> hi fabbione 
<doko> svenl: yes
<svenl> doko: does gcc 4.0 eat up more registers than 3.4 used to do ? 
<svenl> doko: i just filled a bug upstream, CCed you on it even.
<doko> svenl: thanks
<doko> <doko> fabbione: you can find the gcc-3.4 build for sparc in my home on chinstrap. did build properly in a fresh breeeezy chroot
<jbailey> fabbione: YEs, and regular sparc ideally, but still need to figure out whether we continue to care about pre sparc9
<fabbione> i did complete the build manually
<jbailey> (For those that are confused, consider this the equivalent of renaming a file in CVS)
<fabbione> jbailey: pre v9 are 32 bits, right?
<fabbione> if so just kill them
<jbailey> fabbione: 32 bits only.
<fabbione> i don't care
<jbailey> All the classic sparc joy.
<fabbione> perfect.. KILL THEM ALL
<jbailey> 'kay.  Then in that case, we have opt packages for sparcv9 and sparcv9b.
<jbailey> Should the sparcv9 one go away?
<fabbione> whatever fits you better is ok with me :)
<fabbione> see.. i am very simple
<fabbione> doko: what kind of chroot did you creat?
<doko> breezy
<fabbione> doko: try to bootstrap a buildd chroot :)
<doko> why?
<fabbione> debbootstrap --variant=buildd
<fabbione> it's a different set of base packages?
<fabbione> doko: at what time are we going to start?
<doko> sorry, why is it different to deboostrap breezy and install the build-deps?
* lamont wanders off for a while
<fabbione> doko: because breezy has plenty of things that are not installed on a buildd
<doko> fabbione: elmo around, lamont around, xorg packages updated
<doko> what about sparc-utils?
<fabbione> also sparc-utils
<fabbione> you need to install that manually on the buildd... i forgot to add it to the list when i did debootstrap ubuntu34
<doko> why is sparc-utils not in the buildd?
<fabbione> because i forgot to add it to the list when i did debootstrap ubuntu34
<jbailey> afk a sec.
<fabbione> doko: when are we going to start the transition?
<fabbione> (also.. elmo is not here ;))
<doko> fabbione: elmo needs to freeze the import of C++ packages, lamont needs to prepare the buildd's, daniels needs to upload xorg compiled with 4.0
<fabbione> is it going to happen today?
<doko> I have my doubts now ...
<fabbione> well fuck i come back from holidays for this transition
* fabbione goes for a smoke
<fabbione> checking whether the C++ compiler (g++-4.0 -O -DDEBIAN ) works... no
<fabbione> configure: error: installation or configuration problem: C++ compiler cannot create executables.
<fabbione> hmmm
<doko> which package?
<fabbione> mozilla
<fabbione> same error on all arches
<doko> yes, firefox works, mozilla maybe needs an update
<jbailey> fabbione: Well, now my client won't talk to CAnonical's imap server.
<jbailey> *cRy*
<fabbione> jbailey: get a serious client...
<jbailey> fabbione: I use evo because that's what I have to support.  It makes sense for me to know it very well.
* jbailey turns on various debugs.
<fabbione> jbailey: well.. i use thunderbird.. it's crap.. it crashes, but i can open N imap mboxes without any problem :)
<jbailey> fabbione: This was all working on my laptop on Friday.
<jbailey> No idea why it deteriorates on my main box.  Main difference is that the laptop is i386 and this is ppc.
<jbailey> fabbione: Oh ouch.  This client is going through and doing a STATUS on each file in buildLogs. =(
<fabbione> amen
<fabbione> no wonder it takes ages
<fabbione> well i am not too worried about bw usage...
<fabbione> it will just be slow for you
<fabbione> jbailey: if you prefer i can even setup a forward to you, but that means getting all the logs from the buildd...
<jbailey> I'm trying to beg for better behaviour in #evolution
<fabbione> doko: wouldn't be a good idea to start bitching elmo, lamont and daniels?
<fabbione> otherwise you can forget to start the transition :)
<doko> :(
<fabbione> should we revisit all the steps, one by one just to be 200% sure before we start?
<lamont> doko: "prepare the buildds" == ??
<fabbione> lamont: i think he means installing the new gcc-defaults
<lamont> fabbione: ok
* lamont needs to run to the post office this morning sometime, but that's only 15 min from home
<fabbione> lamont: we are still waiting for elmo, so i think it's safe to go right away :)
<fabbione> lamont: do you think it's worth to let the new gcc-defaults in so that it can be built?
<fabbione> but not installing it in the chroots?
<fabbione> that would probably save sometime for the process
<lamont> the chroots will install it at the start of a build if it's a dependency.  Likewise, around 0215 DCT (Data Center Time), the chroots are automatically upgraded
<fabbione> ok than we should wait i guess
<fabbione> but nothing build-dep on gcc-defaults
<fabbione> it's pulled in as part of build-essential iirc
<lamont> libtool: build-depends gcj which comes from gcc-defaults.
<fabbione> hmm right
<fabbione> yeah it does here too
<fabbione> ops
<lamont> yeah - that's currently uninstallable, hence the ease of finding it... :-)
<lamont> if I have 40 minutes, I'm going to run away and visit the postoffice.
<fabbione> lamont: probably much more than that :)
<lamont> right.  back in a bit then
<fabbione> oky
<jbailey> lamont: Around?
<lamont> yo
<jbailey> lamont: Are you brave enough to step me through reading hppa assembler, or should I wait until Carlos is around? =)
<lamont> hppa assembly is my frien d
<jbailey> lamont: Lovely, might be something for the evening hacking session then.
<lamont> woot
<jbailey> lamont: The story so far is basically:
<lamont> still no elmo?
<jbailey>     10: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND memcmp
<jbailey>     11: 00000000   764 FUNC    GLOBAL HIDDEN    1 __GI_memcmp
<fabbione> apparently no
<jbailey> lamont: And the similar file on ppc has it defined.  So I think I need to see what's up. =)
<lamont> hrm.. that's not assembly... that's .o format. :-)
<jbailey> Right, but I want to see what it's feeding to the assembler.
<jbailey> For the symbol to not exist at all.
<lamont> ok.  note that gas and I are not always good friends, but the actual machine code is one of my oldest friends...
<jbailey> 'kay. =)
<fabbione> still no elmo?
<fabbione> lamont: still around?
<fabbione> bah eek.. brb
<lamont> heh
* jbailey can smell the pizza in the oven.
<fabbione> lamont: we don't know where elmo is, do we?
* lamont bets on .uk.
<lamont> (that'd be a "no")
<fabbione> ahaha
<lamont> mind you, I could be wrong... :-)
<fabbione> sorry... phone call
<fabbione> re
<fabbione> lamont: i need to go offline soon
<fabbione> and without elmo we cannot do the transition
<fabbione> lamont: can you check if you still have access to the sparcbuildd
<fabbione> and stop it when needed
<lamont> have I mentioned that I hate transitions that require manual steps on all the buildd's?
<lamont> esp since hppa isn't able to do the walk at the same time as the rest?
<fabbione> lamont: yes and i am with you
<fabbione> since sparc is the slowest
* lamont glares at doko/jbailey, just for good measure
<lamont> fabbione: just vultus5
<lamont> ?
<lamont> br
<lamont> b
<fabbione> lamont: yes.. there is only vultus5
<lamont> coolness
<lamont> back in a couple
* jbailey runs off for lunch, ecaping the glares from lamont.
<doko> leave me alone ...
<doko> jbailey: stop!
<fabbione> later guys
<jbailey> doko: Eh?
<fabbione> doko: try to summon me.. if i won't respond in a decent time lamont will stop the buildd
<fabbione> and we will look at it tomorrow...
<fabbione> but this really suck
<doko> jbailey: please have a look at the latest directfb build failure on amd64.
<fabbione> and sparc....
<doko> conflicting types in {sys,asm}/types.h ?
<fabbione> bbl
<jbailey> doko: Does it have to be before lunch?  The timer just rang.
<doko> fabbione: have fun
<doko> no
<jbailey> Lovely. =)
* jbailey goes for lunch. =)
* lamont is informed that lunchtime approaches
* lamont makes sure that jbailey has his cell, on the off chance that elmo surfaces before he gets back from lunch...
* lamont goes to lunch with the wife, back in a while - holler if/when I'm needed
<jbailey> Enjoy.
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> Was just following glibc on hppa and noticed that upstream actually released the new binutils.  Do you want me to add that to my queue of things to test?
<jbailey> doko: I'll look at directfb on ppc first, since I have one of those here.
<doko> jbailey: yes, these are already packaged and tested. one regression on ia64, just waiting for elmo's ok
<jbailey> Nice.  Did you see http://sources.redhat.com/ml/binutils/2005-05/msg00360.html ?
<doko> interesting
<jbailey> directfb is a cast-as-lvalue failure, I'm trying to figure out what the current best practice is supposed to be.
<jbailey>         data8 = (unsigned char *)data16 = (void*)0;
<jbailey> Isn't allowed anymore.
<doko> jbailey, did you get the .22 version from the archive
<doko> jbailey: ^^^
<doko> current dirctfb version should be 0.9.22-0ubuntu1
<jbailey> Ah, nope.  apt-get source had fetched me .20-0ubuntu1
* jbailey fetches.
<jbailey> err .20-5
<fabbione> morning
<fabbione> damn my server died again
<fabbione> how is it going guys?
<svenl> jbailey: hi.
<svenl> Mmm, gcc 4.0 is better, since it builds libgcc1 package, but not the 64bit stuff.
<svenl> need to find how gcc decide wheter to build lib64gcc1 or not, doesn't seem obvious.
<chmj> morning 
<fabbione> hey doko
<chmj> hey doko 
<doko> hi fabbione 
<fabbione> doko: so what is the status for the transition?
<doko> fabbione: let me wade through my mail first ...
<fabbione> ok
<svenl> doko: hi.
<svenl> doko: i built gcc-4 biarch.
<svenl> doko: it is better, since there is a non-empty libgcc1, but still no 64bit libs.
<svenl> doko: i have searched some, but am at a loss on where in the gcc makefiles the building of the 64bit stuff is defined. Do you have any hint on that ? The debian stuff tries to build the 64bit packages but fails.
<svenl> doko: also, i was told to use --added-target=powerpc64-linux when building by hand. I see no trace of this in the debian files.
<svenl> --enable-targets=powerpc64-linux that is.
<daniels> represent
<doko> fabbione, daniels, lamont, jbailey, elmo: ping
<lamont> Running /build/buildd/gcc-4.0-4.0.0/src/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
<lamont> make[1] : *** [stamps/06-check-stamp]  Terminated
<lamont> make: *** [check]  Terminated
<lamont> Build killed with signal 15 after 150 minutes of inactivity
* lamont grumbles at doko
<lamont> morning doko
<daniels> doko: wassup
<lamont> morning elmo
<doko> time plan for tomorrow ...
* lamont is about to get dragged off for breakfast for 20-30 minutes
<doko> 1) freezing the imports/syncs 2) upgrading the buildd's 3) freezing the archive for C++ application uploads 4) library uploads
<doko> 1) and 2) make only sense, if things for 4) are ready, xorg is outstanding. for 1) and 2) we need lamont and elmo
<daniels> xorg is going to be fun
<daniels> we need to get 3 arch: all NEWs in, then xorg
<fabbione> doko: why not today?
<doko> fabbione: daniels prepares the final xorg source upload
<fabbione> daniels: i understood it was ready....
<daniels> i've been working with joshtriplett so we have the same stuff between debian and ubuntu
<daniels> and i want to try some more upgrade tests
<daniels> in any case, it's 2220 here and I'm fucking tired, so I'd love if I could do it tomorrow
<daniels> but if it needs to be done tonight, sure
<lamont> doko: I'd also be interested in hearing how this will work for the buildd's that don't even have a gcc-4.0 right now.
<lamont> (hppa)
<doko> lamont: is hppa ok?
<lamont> hppa has the build failure pasted aboge
<lamont> above, even
<doko> ohh, they don't?
<lamont> no.  still don't
<lamont> back in about 20 minutes. sorry
<doko> lamont: disable the testsuite :-(
<fabbione> well the sooner the better
<fabbione> daniels: what is missing from your packages?
<doko> hmm, ok. so let's sort out hppa later
<fabbione> only upgrade tests?
<daniels> fabbione: yeah, and I need to reversion it too
<fabbione> daniels: but are you going to upload the monolithic tree right?
<fabbione> reversion it?
<daniels> the monolithic tree ... plus modular packages of xc/include/*.h and lib/xtrans/*
<fabbione> wouldn't be wise to just do the C++ transition with the monolithic and split everything else later?
<daniels> unfortunately I only did the C++ transition later
<daniels> and it would take more time to split out all the patches with gcc4 fixes etc and fix all the offsets than it would to test all this
<fabbione> is there any option to upload only libglu from the splitted?
<daniels> hmm?
<fabbione> iirc that's the only library that has to do the C++ transition
<fabbione> xorg 6.8.2-$foo
<fabbione> -> libgluwhateversoname-$foo
<daniels> yeah, it's libglu1-xorg now
<daniels> from xlibmesa-glu
<fabbione> if you upload libgluwhateversoname-$bar
<fabbione> where $bar is > $foo
<fabbione> that's all you need to start with
<fabbione> but can libglu1-xorg build abe uploaded that way?
<daniels> from the modular tree?  nope
<fabbione> if so there is no need to get the entire splitted tree in
<daniels> mesa is going to be the hardest part of this lot
<fabbione> doko: how much can we do without X?
<doko> not much, the whole KDE depends on it. and other libs as well.
<fabbione> KDE is an application :)
<fabbione> what about the other libs?
<fabbione> how many of them?
<daniels> it's ok, we can do libglu
<daniels> so, i'll try to get x-common, x11proto-core-dev and xtrans-dev in tonight
<daniels> and get packages of xorg up on chinstrap for testing and building on powerpc
<daniels> and then upload that tomorrow morning?
<doko> fabbione: it doesn't make sense to have the archive in an unusable state for too long. this just adds 24 hours
<doko> daniels: sounds ok. do the packages need new love? i.e. is elmo awake tomorrow morning?
<daniels> the first 3 packages need NEW love
<fabbione> they will mostlikely need elmo's love for NEW
<fabbione> all the sources are new
<daniels> libglu1-xorg will need NEW love for the binary package too tho
<daniels> would preseeding be useful here?
<fabbione> that's sure thing
<fabbione> elmo will still need to do the manual uni->main
<daniels> ahr
<doko> same for all these new library binary packages ...
<daniels> elmo: will you be around for the next couple of hours?
<elmo> mostly, yes
<doko> elmo: how long does it take for a package to enter main from universe?
<daniels> ok, so if I upload x-common, x11proto-core-dev and xtrans-dev, would you be able to new them?
<elmo> daniels: yes
<daniels> phat, thanks
<jbailey> doko: I'm here now, sorry about the lag.
<doko> jbailey: elmo delegated the decision about binutils in breezy to us
<jbailey> doko: Lovely, I'll go over the list again of what changed.
<elmo> (FWIW, I think it's a no brainer; if Debian wasn't frozen, I'd be uploading it)
<doko> there's one regression in the testsuite on ia64
<fabbione> is there somebody that still cares about ia64?
<doko> <doko> drow: one binutils 2.16 ld testcase did regress on ia64, compared to 2.15
<doko> <drow> ?
<doko> <doko> +Running /home/doko/binutils/binutils-2.16/ld/testsuite/ld-bootstrap/bootstrap.exp ...
<doko> <doko>  PASS: bootstrap
<doko> <doko>  PASS: bootstrap with strip
<doko> <doko> -PASS: bootstrap with --static
<doko> <doko> +FAIL: bootstrap with --static
<doko> <drow> wird
<doko> fabbione: lamont?
<daniels> i bet the latest hj lu binutils would fix that
<daniels> let's use that
<elmo> HA FUCKING HA
<doko> :-)))
<jbailey> mmm..  crack.
<fabbione> ahahah
<jbailey> elmo: The biggest concern I have is yet another variable in all the toolchain changes.
<doko> jbailey: what the ppc64 patch applied to the 2.16 branch?
<elmo> [I'm off to get some breakfa^Wlunch, bbiab] 
<jbailey> doko: Required for glibc to build acc. to modra.
* lamont back
* doko decides to go for lunch if elmo is back ;)
<lamont> fabbione: I still care about ia64.  moreso now.
<fabbione> lamont: ehehe ok :)
<lamont> more to the point, I can't evangelize Ubuntu with my team when it doesn't even run on the platform in question......
<fabbione> lamont: make sense
<jbailey> lamont: It generally works... ;)
<jbailey> lamont: Thinking of which.  Do you know efi at all? =)
<lamont> I know of it.  I expect to know it well sometime this year...
<jbailey> <voice who="Mr. Burns">Eexcellent</voice>
<fabbione> ahah
<jbailey> The grub folks have decided that they'd rather not use libefi because of copyright assignment hassles.
<jbailey> So I may have questions.
<fabbione> daniels: do you have i386 binaries somewhere for xorg?
<fabbione> daniels: i have a machine or 2 i can trash testing an upgrade
<daniels> fabbione: only amd64 at the moment ... i'm building up an i386 chroot because my laptop just ran out of space mid-build
<fabbione> ENOAMD64
<fabbione> and i guess you can't build on concordia.. right?
<jbailey> daniels: Are you looking for testers?  I can do ppc if you want (and can build it quite fast)
<fabbione> doko, jbailey: did anybody fixed the ppc64 chroot on davis?
<daniels> fabbione: concordia doesn't have a chrot
<daniels> although, erk
<fabbione> daniels: yes it does...
<daniels> packages will take a fucking long time on my system
<daniels> since I can't strip on an XFS /home
<daniels> fabbione: an i386 chroot?
<fabbione> yeps
<lamont> daniels: breezy-i386 isn't there???
<jbailey> fabbione: I didn't know there was one.
<fabbione> linux32 dchroot -c breezy-i386
<fabbione> jbailey: it's where your ppc64 libc packages are installed...
<jbailey> fabbione: Oh?  I didn't know that they had been installed anywhere.
<daniels> ah shit, need build-deps first
<daniels> elmo: ping
<jbailey> fabbione: Thinking of which, I'd like to upload a glibc that wakes up hppa.
<jbailey> fabbione: No sense wasting cycles building it on sparc, though.  You'll get your love later in the week.
<lamont> doko: you have a gcc-4.0 upload planned anytime soon?
<doko> lamont: no
<jbailey> lamont: I do after the transition gets underway.
<doko> besides the one I did one minute ago
<lamont> ok.  if turning off the testsuite for hppa fixes it, I'll have jbailey include that in his upload
<jbailey> Maybe Friday?  For getting biarch working on i386/amd64 again.
<jbailey> Ouch.
<jbailey> lamont: BTW, I've asked Carlos whether there's suckage-reduction for hppa in binutils 2.16 that we really need.
<fabbione> jbailey: ok. i will kill it as soon as it arrives here
<fabbione> no actually i can't
<fabbione> because that would make locales uninstallable
<fabbione> and some packages build-dep on it
<jbailey> Oh right, bugger.
<fabbione> no big deal..
<fabbione> it's ccached :)
<jbailey> 'k
<jbailey> I'd do a build locally on my u5, but I haven't wired it up yet.
<fabbione> jbailey. don't worry :)
<lamont> fabbione: the other trick is to just keep the right locales locally...
<fabbione> lamont: yeah taht would work too, but it's not a big deal
<fabbione> libgc is faster and ccachable
<lamont> yeah
<fabbione> the real issue is gcc...
<fabbione> it takes ages
<fabbione> and it's not ccache friendly
<lamont> doko: 2) upgrading the buildd's 
<lamont> is that just to get the new gcc-defaults stuff there?
<lamont> well, and g++-4.0
<doko> lamont: yes
<fabbione> lamont: should we review debootstrap in the meantime?
<lamont> ok.  We'll also want to make sure that debootstrap gets some love sometime this week
<doko> oops, yes, g++-4.0 is not in main?
* jbailey reads this as "last chance for a bathroom break" =)
<lamont> doko: is in main
<daniels> elmo: any chance of getting some thpethul chroots, or telling everyone else to fuck the fuck off out of them?
* fabbione goes for more coffee before we start
<lamont> I more meant that gcc-defaults would drag in g++-4.0
<daniels> xorg build now kind of requires /usr/{lib,include,share}/X11 to be directories
<lamont> daniels: WTH is it looking at the real directories, instead of it's copies?
<daniels> lamont: hm?
<lamont> and what are they if not directories, anyway?
<lamont> <daniels> xorg build now kind of requires /usr/{lib,include,share}/X11 to be directories
<daniels> right
<daniels> they used to point to /usr/X11R6/...
<daniels> which is an utter anachronism
<daniels> and the transition is sort of starting now
<lamont> ah, right
<jbailey> daniels: I wonder if that is *supposed* to make me feel old... ;)
<lamont> jbailey: nah - you _are_ old
<daniels> jbailey: r7 coming yo' way
<jbailey> daniels: Do you mean in general, or do you want a test build/use cycle on a ppc?
<daniels> jbailey: in general
<jbailey> Ah. =)
<doko> lamont: do you want the testsuite disabled on hppa? then maybe you have to cancel the current build
<lamont> doko: I'll live
<doko> who's in your way?
<lamont> doko: running a testbuild with the suite disabled now, we'll see how well it does.  Once I have that, then I really don't mind if it's out of date for a day or 6... or do I need something in the last upload?
<lamont> freshening the local mirror (for source) now.
<fabbione> ahh almost nothing is better than dark choccolate + biscuits + coffee
<jbailey> How does that far side comic go?  The ideal life of the archaeologist, a beautiful woman in one arm, and the focilised skull of a homo habilis in the other...
<chmj> O.O
<lamont> doko: no need to kill any builds, since hppa hasn't managed to _start_ autobuilding of breezy yet.
<lamont> (still trying to get a gcc-4.0, you see... and then there were the glibc issues, that jbailey fixed yesterday)
<jbailey> lamont: Ah, are you running on that glibc now?
<lamont> yes
<lamont> well, the buildd chroot is.
<jbailey> That'll certainly exercise it. =)
<lamont> yeah.  built glibc, doxygen, l-k-h, and now chunking on gcc-4.0.
<lamont> of course, maybe it's glibc's fault that gcc-4.0 hangs in the test suite. 
<lamont> nah..
<doko> lamont, if you get the buildd to set an env var WITHOUT_CHECK=yes ...
<jbailey> lamont: I did a summary of the testsuite changes from the previous glibc.  If you're interested I can /msg them to you.
<lamont> doko: actually, I just created -0ubuntu2hppa1, with "check_no_cpus := hppa # arm m68k"
<daniels> fabbione: do you have a chroot you want to fuck shit up on?
<fabbione> daniels: sure
<lamont> jbailey: actually, email would be even better
<daniels> grab the packages from p.u.c/~daniels/newx/
<daniels> build and install x-common, x11proto-core and xtrans, in that order
<daniels> you should have /usr/{lib,include,share}/X11 as a directory
<daniels> and I'll throw a xorg source package (and later binaries) up as soon as it's finished building here
<jbailey> lamont: lamont@u.c?
<lamont> daniels: the packages take care of transitioning those links->dirs, yes?
<lamont> jbailey: sure
<daniels> lamont: yah
<daniels> x-common does, and x11proto-core-dev is a replacement for the old x-dev
<daniels> it should dist-upgrade cleanly; i'm just building a chroot to test that hypothesis now
<jbailey> lamont: cym
<lamont> tnx
<fabbione> daniels: bootstrapping the chroot now
<daniels> cool
<fabbione> Setting up x-common (1.0) ...
<fabbione> ok what should i check after this install
<fabbione> it's a completely empty package?
<fabbione> except the copyright)
<daniels> oh, fucking shit
<daniels> yeah, I just noticed that myself
<daniels> had the real package on my laptop, sigh
<daniels> ok, new one uploaded -- sorry
<fabbione> x-dev is empty?
<fabbione> daniels: i builded all the 3 sources.. and installed them
<daniels> yep, just depends on x11proto-core-dev
<fabbione> other than x-dev is empty.. the others look ok
<fabbione> want to give me libglu?
<daniels> that's no accident :)
<daniels> still in the xorg source package; i can't run debuild -S until this build has finished, for obvious reasons
<fabbione> i understood that libglu was already splitted...
<daniels> er, no
<daniels> it changed its package name, that's it
<daniels> mesa is going to be one of the hardest things to split, because it's so deeply tied in with the x server at the moment
<fabbione> ok so what do you want me to build now?
<daniels> i'm in dh_builddeb of xorg, so I'll give you that next
<fabbione> ok
<daniels> since it needs elmo to install build-deps in the concordia chroot
<fabbione> i guess now xorg build-deps on these 3 new packages.. right?
<daniels> it build-deps on x11proto-core-dev and xtrans-dev
<daniels> which in turn build-dep on x-common
<fabbione> right
<fabbione> do you want to uplaod the source somewhere?
<fabbione> so i can start downloading it?
<fabbione> at least the orig
<daniels> yep, just waiting for dh_builddep to finish
<daniels> the orig is just the same
<fabbione> ah ok
<daniels> uploading that over my DSL would take about an hour
<daniels> there we go, finished building
<elmo> remoo
<daniels> hello sunshine
<fabbione> doko: do yo have a gcc-defaults ready?
<fabbione> doko: if so can you handle the i386 version to me please?
<daniels> fabbione: xorg sources up
<fabbione> downloading now
<fabbione> daniels: i just need the new gcc-defaults to be sure that we are building with g++4.0
<daniels> sure
* fabbione summons doko
* fabbione hits doko with a get-here-bat
* fabbione power ups the sodomotron and inserts doko's coordinates in the system
* lamont wonders if overfiend knows fabbione has the somdomotron
<fabbione> lamont: i have the EU version :)
<fabbione> that runs on 220v/50hz
<jbailey> Does it have gears?
<fabbione> jbailey: do you happen to have gcc-defaults?
<fabbione> the new one?
<jbailey> Is that different that what's at  deb  http://people.ubuntu.com/~doko/GCC-4.0/powerpc ./  ?
* lamont is more partial to the colostomizer
<fabbione> jbailey: thanks.. it seems to be the correct one
<jbailey> "We call this gun the fecalator.  One look at it and the target shits his or her self."
<fabbione> daniels: building x now
<daniels> cool
<fabbione> hmmm
<fabbione> this is not going to work
<doko> ?
<fabbione> daniels: the problem seems to be installing xorg build-deps
<daniels> fabbione: hm?
<fabbione> daniels: xorg build-deps on some of its own packages
<fabbione> that depends on xorg-common
<fabbione> that fails to install due to x-common
<daniels> oh, cock
<daniels> cock, cock, cock, cock, cock, cock, cock
<fabbione> xorg-common preinst error: /usr/include/X11 exists and is not a symbolic link;
<fabbione>    this package cannot be installed until this directory is removed
<daniels> right
<daniels> which is fixed in -11's xorg-common
<fabbione> cock
<fabbione> because that can't be built
<daniels> correct, for ten points
<fabbione> so we need a transitional package
<fabbione> or
<fabbione> make x-common Provides: Conflict: Replaces: xorg-common ?
<daniels> hmmm
<fabbione> tho i am not 100% sure that's enough
<daniels> what's even in xorg-common?
<fabbione> a bunch of files iirc
<daniels> shit, mainly conffiles
<daniels> moving them is way too hard to consider right now
<doko> fabbione, jbailey, lamont: I'm not at the TBM tonight, but will read my backlog later
<daniels> i suppose I could upload -10.1 with the relaxed check, get that built everywhere, and then we can do the rest
<fabbione> i am not sure i will be at TBM either
<daniels> but MY GOD THAT'S NASTY
<jbailey> I'll be there.  Anything you want mentioned specifically?
<fabbione> daniels: i don't think there is any other way
<daniels> fabbione: le sigh
<lamont> TBM?
<fabbione> daniels: let's think for a minute or 2
<daniels> lamont: tech board
<lamont> tech board
<lamont> doh
<fabbione> Tech Board Mee
<jbailey> lamont: Took me a sec too. =)
<lamont> yeah - kept thinking of Martin
<jbailey> As much fun as visiting MArtin would be. =)
<fabbione> daniels: i think that we can make it easier, but we need to be extremely syncronized
<daniels> fabbione: how so, though?
<daniels> we'll still need to get -11 through the buildds somehow
<fabbione> daniels: let's say we upload x-common that PRC xorg-common, we upload the new xorg and we reupload the new x-common
<daniels> hm
<daniels> i have an idea
<fabbione> without PRC
<daniels> maybe x-common could pre-depend on xorg-common
<daniels> so the apt run is unpack/configure xorg-common, unpack/configure x-common, then do the rest
<fabbione> that's even more scary :)
<daniels> so xorg-common's postinst would get run when the symlinks were still present
<fabbione> let me try
<daniels> then when -11 hits the archive, we could remove it
<fabbione> Predepends: xorg-common
<fabbione> or was it Pre-Depends?
<daniels> Pre-Depends
<fabbione> just a sec...
* fabbione performs the big purge of death manually
<daniels> heh :)
<fabbione> well that seems to work
* daniels beams.
<fabbione> at least installing only x-common and xorg-common
<fabbione> now let me see if i can install all the build-deps
<daniels> yep
* lamont mumbles bad things about uploading packages just to get past the buildd
<daniels> lamont: i'm sorry, I'm a bad man
<fabbione> lamont: yes i agree.. the best would be a transitional xorg
* lamont just feels sorry for the alpha/mips/m68k ports next month, when they have to recreate the whole thing as part of a bootstrap
<lamont> then again, if the new one is just plain ftbfs, that's actually not _too_ bad.
<daniels> lamont: the whole xorg thing?
<doko> lamont: you still have to time to mumble before hppa is in shape again? ;-)
<lamont> it's when it builds, wrong, that it's really evill
<lamont> doko: gcc-4.0 takes _forever_ to build
<fabbione> nah it's building wrong.. 
<lamont> of course, it'd go faster if I wasnt' building a test kernel, too.
<fabbione> lamont: 17 hours on sparc :)
<lamont> fabbione: sparc sucks
<fabbione> daniels: xorg building now
<lamont> gcc-4.0:                04:02:12 (2 entries, sigma 01:53:34)
<fabbione> lamont: sorry.. but i can't find a single _hppa.deb on ports....
* doko is watching, if sparc or hppa wins 
<fabbione> doko: you better STFU :P
<fabbione> doko: or do i need to remind you that thanks to a missing build-dep on gcc-4 sparc didn't make hoary?
<fabbione> :)
<lamont> fabbione: dunno if my key is there yet, or if I'm a muppet
<fabbione> daniels: well.. it SEEMS to work
<fabbione> xorg is building
<daniels> oh dear :)
<daniels> x-common 0.99 it is, then
<fabbione> well i am just a bit scared of the Pre-Depends to be hounest, but apt-get should do the right thing
<daniels> it's scary, but less scary than uploading a whole new xorg imo
<fabbione> daniels: s/scary/timeconsuming
<fabbione> doko: i think we are ready with X
<fabbione> doko: your call now :)
<fabbione> daniels: xorg-common is arch: all
<fabbione> so once it's builded on i386, we can basically upload x-common 1.0
<daniels> fabbione: sure, but everyone get a whole new set of binary packages
<daniels> unless we binary-NMUed xorg-common with source changes
<daniels> but that would be REALLY REALLY BAD
<doko> fabbione, lamont: assume we can rebuild all C++ libraries on all architectures for the release archs, I'd like to continue building the C++ apps, but if sparc and hppa didn't finsish with the libs at this time, you have to make sure that no C++ app is built before. can you manage this for your buildds?
<fabbione> doko: not sure...
<fabbione> lamont: do we have a way to filter the output from wanna-build -d breezy --take ?
<doko> fabbione: I'm away in one hour ..., let's start this at 22:00 UTC, if X is ready
<daniels> i can upload x-common 0.99 now if we're confident with it
<daniels> then x11proto-core-dev and xtrans-dev, then xorg
<fabbione> daniels: if you need to go to sleep, please make all the sources available on people
<daniels> sure
<fabbione> daniels: i would rather prefer to get them in at the right time
<daniels> i'm good for a couple more hours now
<fabbione> daniels: apparently doko is going away
<daniels> so we can at least get the prerequisites in, elmo can give them some NEW loving, and we can throw xorg in when I wake up in about 7 hours
<lamont> doko: if you have a list of the library and app source packages, then sure. no problem.
<daniels> fabbione: have you got an X build going?
<fabbione> daniels: yes
* lamont hopes to have a breezy hppa buildd up sometime soonish
<doko> lamont: ok, I'll update these when we start
<lamont> elmo: do the lib packages all wind up sorted ahead of the rest of the world?
* lamont doubts that
<doko> lamont: yes, why not?
<daniels> fabbione: cool
<fabbione> daniels: prepare x-common 0.99 on people with the Pre-Depends
<fabbione> daniels: if you are asleep i will upload the packages for you in order
<daniels> sure
<fabbione> just sign them all
<fabbione> so i can just lftp from there
<lamont> doko: because it would be too convenient. :-)
<daniels> ok
<fabbione> lamont: can't we just add a filter to wanna-build?
<daniels> i'll put all the sources on people, and signed changes files in my homedir on chinstrap
<lamont> fabbione: so the plan is 2 xorg uploads?
<fabbione> lamont: no. one.
<doko> lamont: let's see, at least on i386 they all build, and I did check half of it for amd64 as well.
<daniels> lamont: one xorg upload, two x-common uploads
<fabbione> lamont: x-common -> xorg -> x-common
<lamont> fabbione: I suspect we could, but the source package names are not necessarily aligned well with whether or not they happen to deliver a binary lib package.
<fabbione> lamont: i was hoping for doko to give us the list of sources :)
<lamont> doko: was talking about wanna-build, not compiles
<fabbione> doko: you have a list of sources, don't you?
<lamont> (specifically doubting that the answer to my question to elmo was 'yes')
<doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
<doko> http://www.ubuntulinux.org/wiki/CxxApplicationList
<lamont> fabbione: so add CxxApplicationList to @no_auto_build
<lamont> until the libs are all built
<doko> I'm updating these when we freeze
<fabbione> doko: does the App lists includes universe?
<doko> yes
<daniels> fabbione: x-common 0.99 and 1.0 both on p.u.c/~daniels/newx/, signed changes files for everything on chinstrap:~daniels
<fabbione> doko: also the library list?
<fabbione> daniels: rocking.
<fabbione> daniels: good night kid
<doko> fabbione: maybe I should split this one into two
<daniels> eh, I'm still good for a couple of hours yet
<fabbione> keep the mobil phone on :) just in case ;)
<daniels> any reason why I shouldn't upload x-common 0.99 now?
<doko> fabbione: read!
<daniels> fabbione: yeah, it'll be next to my bed
<doko> daniels: cool!
<fabbione> doko: ETOOLAZY :P
<doko> so who wakes up daniels first? ;-)
<fabbione> daniels: because it will change the symlinks to dir on installed systems, where Xorg is not ready?
<daniels> ack, wait, I think I have broken Pre-Depends, lemme check
<daniels> fabbione: ah, but it won't get installed
<daniels> because nothing will depend on it yet
<doko> daniels: what's the name and version of the glu-dev package?
<daniels> doko: libglu-dev-xorg, 6.8.2-11
<daniels> currently it's xlibmesa-glu-dev 6.8.2-10
<fabbione> daniels: better to wait... 
<doko> ok, just for the wiki and thighended build deps. so xlibmesa-glu-dev (>= 6.8.2-11) should be still fine?
<fabbione> lamont: where do i define the @no_auto_build ?
<daniels> doko: libglu-dev-xorg (>= 6.8.2-11)
<lamont> buildd.conf
<lamont> # list of packages which shouldn't be picked up by buildd
<lamont> @no_auto_build = qw();
<lamont> @weak_no_auto_build is the list of packages to build when there is _nothing_ else to do
<fabbione> yup.. found it
<daniels> fabbione: don't worry about it now, but I've just updated my xorg sources on p.u.c and chinstrap to rename libglu1-xorg-dbg to libglu1-dbg-xorg and libglu-xorg-dev to libglu-dev-xorg.  no build changes.
<fabbione> doko: before you go away...
<fabbione> the gcc-defaults and build-essential on people.u.c.~doko/GCC-4.0/source are the ones that need to hit the archive?
<fabbione> daniels: did you also rename all the install/links/etc files?
<doko> yes, nobody did complain about these
<daniels> fabbione: yep
<fabbione> doko: ok, is there anything we can start to do while you are away?
<lamont> no cxx libs in multiverse?
<doko> lamont: yes, only three in the list
<lamont> ah, and multiverse sorted before universe. sigh
* lamont tends to sort in ogre-model order
<doko> fabbione: if you want to start, upload the library packages for main (except kdelibs) from chinstrap:~doko/cxxsrc
<lamont> doko: those are signed and all?
<lamont> and note that  the buildds aren't updated yet...
<fabbione> doko: don't we need to switch gcc-defaults first?
<lamont> are we ready for that?
<doko> but xorg should be installed on the buildd's before
<fabbione> no i don't think we are
<doko> fabbione: sure
<fabbione> ok stop
<lamont> WHY???      <doko> but xorg should be installed on the buildd's before
<fabbione> let's start again the list of things that needs to be done and in what order
<lamont> fabbione: ++
<fabbione> because i think we are skipping some steps here
<doko> lamont: because I did not updated the build-deps for libraries, which depend on libglu-dev-xorg (>= 6.8.2-11)
<fabbione> 1) we need to stop the syncs from debian of all the libs and app from the 2 lists on the wiki
<doko> fabbione: elmo did prepare this, and stop the import of NEW sources
<fabbione> elmo: is that in place already?
<elmo> yes
<fabbione> ok
<elmo> well err, no
<fabbione> ok :)
<elmo> I only did the first list no the wiki
<elmo> s/no/on/
<elmo> 12:12 <elmo> https://www.ubuntulinux.org/wiki/CxxLibraryList
<elmo> ^-- that one
<fabbione> doko: do we need to stop syncing the applications too i guess...
<doko> yes, the current one has to be replaced by the second one, if we start building the libs
<fabbione> doko: i am not sure i understand what you mean by second one....
<fabbione> daniels: xorg is FTBFS here
<fabbione> Xrandr.c:32:36: error: X11/extensions/Xrender.h: No such file or directory
<doko> the one at http://www.ubuntulinux.org/wiki/CxxApplicationList
<doko> containing all packages with a dependency on libstdc++5
<daniels> fabbione: hrm, doesn't happen here
<daniels> fabbione: can you check whether Xrender.h is in /usr/include/X11/extensions or /usr/X11R6/include/X11/extensions please?
<fabbione> daniels: it's in /usr/X11R6/include/X11/extensions
<daniels> ok, I'll sort that out
<fabbione> doko: ok i understand now
<fabbione> so the next step would be to update the buildd's with new gcc-defaults and build-essential + the CxxApp list to @no_auto_build
<fabbione> once we have done that...
<fabbione> we need to upload x-common x-x11proto-core and xtrans
<fabbione> xorg
<fabbione> new x-common
<fabbione> and after that we are ready to go with doko's libs...
<fabbione> once all the libs are built, we can release apps...
<fabbione> doko: ?
<fabbione> did we miss anything?
<jbailey> Which parts the rest of us do. =)
<jbailey> Looking through libs, looks like almost everything but kde is done.
<lamont> jbailey: once we start building libs, aggressively attack any FTBFS packages
* jbailey still dreams of an rss feed, and a one click 'claim' option.  I've wanted that for new arch porting in Debian for ages too. =)
<fabbione> lamont: afaik doko did build all of them already
<lamont> on at least i386, yes
<fabbione> well... should we start?
<lamont> elmo: any great ideas besides @no_auto_build for blocking builds of the CxxApps?
<lamont> jbailey: that's what IRC is for. :-)
<lamont> just pick a letter, it's all yours./
<jbailey> Pitty the poor sod stuck with 'l' =)
<lamont> l != lib*
<lamont> those are 4-octet letters
<elmo> lamont: not really, sorry
<lamont> elmo: np.  I think that means you don't have to disable syncing of the apps, though.
<lamont> since it's really just 'don't build any of these until all the libraries are in the archive', right?
<doko> lamont: yes, or else you have to check for build-deps on C++ libs, which I didn't do
<lamont> right
<fabbione> 12 -rw-r--r--  1 sparcbuildd sparcbuildd 10235 May 17 17:39 buildd.conf
<lamont> doko: is the app list golden at this point?
<fabbione> meh!
<fabbione> it got huge :)
<lamont> fabbione: it's an 8500+ byte _line_
<fabbione> lamont: yes i know :)
<doko> lamont: no. wait, I'll update the list before I go ...
* lamont goes on a paste frenzy
<lamont> doko: thanks.  holler when it's golden
<daniels> fabbione: the X order you listed is right
<daniels> i'm just fixing xorg now so it's happier with Xrender.h
<fabbione> daniels: ok.
<lamont> l-r-m-2.6.10 is in the list?? wow
* lamont phears
<fabbione> we can just skip that one forever
<daniels> oh wait, there's a simpler option
<daniels> i'm a fucking moron
<daniels> fabbione: stick with the xorg you have
<lamont> nah - we're breaking hoary-* builds right now...
<daniels> i'll do the render/xrender transition
<lamont> fabbione: you gonna add that to the quotes file??? :-)
<fabbione> lamont: your pleasure :)
<lamont> nah, you can have it
<fabbione> i need more coffee :)
<fabbione> ok i will :)
<daniels> fabbione: ok, new render/xrender versions with changes in the usual place
<daniels> i'm putting a new xorg up now, with explicit versioned build-deps on the new versions
<fabbione> daniels: let me test first
<daniels> sure
<daniels> nothing uploaded anywhere but p.u.c/~daniels/newx/ and chinstrap:~daniels
<fabbione> daniels: do you want to bump xrender Build-Dep on render-dev version too?
<fabbione> or there is no need to?
<daniels> nah, no need
<fabbione> i confirm with the new *render* xorg is building again...
<daniels> autoconf is smart enough to deal with it; imake is not
<fabbione> ok
<fabbione> restart xorg build from scratch
<daniels> fabbione: i believe the phrase is 'the truth, the whole truth, and nothing but the truth'
<fabbione> daniels: i remember a similar one, but apparently ameringlish says that one
<daniels> weird
* fabbione hugs ccache
<lamont> fabbione: actually, daniels is more correct in this case. :-(
<fabbione> lamont: he must be because of his experience with the court :)
<doko> fabbione, lamont, elmo: updated cxxlibs.txt and cxxapps.txt in my home on chinstrap
<daniels> fabbione: haha
<daniels> yeah, so much experience with american courts :P
<daniels> i'm going back to bed now, tired as hell
<fabbione> daniels: are render and xrender signed too?
<daniels> i'll be back at 2300 UTC (7h from now)
<daniels> fabbione: yep
<fabbione> ok
<daniels> i'm phoneable before then if xorg is ftbfs though
<fabbione> daniels: ok.
<fabbione> doko: ok thanks
<daniels> fabbione: i'm just updating x11proto-core and xtrans to fix their pre-depends now
<fabbione> do they need pre-depends too?????
<fabbione> i didn't see the problem here
<elmo> doko: should I freeze both?
<daniels> they had a Pre-Depends on x-common (>= 1.0)
<fabbione> ah ok
<daniels> which needs to be changed to 0.99 for the work-around-the-buildd thing
<daniels> nothing major
<fabbione> doko: the 3rd one is the source package, right?
<daniels> fabbione: ok, x11proto-core and xtrans updated in the usual spots
<daniels> night all
<fabbione> daniels: night
<doko> elmo: hmm, the library list for syncs only, or else we can't upload bug fixes
<elmo> uh, ok
<lamont> doko: don't all the lib packages have -ubuntu versions?
<lamont> which would let the merge process do its thing...
<fabbione> yup
* lamont disappears into the other workspace to update buildd.conf on 12 machines
<doko> lamont: yes, but not yet
<fabbione> doko: he is blocking the CxxApps
<elmo> ok, cxxlibs + cxxapps blocked from syncs
<elmo> cxxlibs blocked from uploads except by doko's key
<doko> heh, then I can upload gcc-defaults and buid-essential?
<fabbione> doko: you should be greenlight for it now
<fabbione> once they are built, we need to update all the chroots on the buildds
<doko> elmo: maybe add amu's and jbailey's key?
<fabbione> elmo: mine and daniels for X please
<fabbione> we have c++ libs in X
<elmo> meh
<fabbione> elmo: it's probably easier to just bless them manually?
<doko> elmo: ready to start?
* fabbione makes the drums sound for doko
<fabbione> doko: probably tell to #u-d :)
<elmo> added amu, jbailey, fabbione and daniels' keys
<fabbione> elmo: thanks
* lamont tries to decide if he wants to be able to fix bugs, or if he'll be busy dealing with other things
<fabbione> lamont: i did test X build order locally... 
<fabbione> better you keep free is something goes wrong on the buildd
<fabbione> s/is/if
<fabbione> AYE
<fabbione> another Xorg FTBFS
<fabbione> there... fixed...
<fabbione> hopefully this is the last one
<fabbione> elmo: can you please let nvu from sparc in?
<fabbione> i am sure it has been built sanely
<fabbione> it was building way before we started the transition
<elmo> eh?
<elmo> it's not in the list to exclude?
<elmo> hum
<fabbione> yes it is
<fabbione> that's why i was asking :)
<elmo> err, rather it's in the apps list
<elmo> and doko told me only to exclude source stuff
<fabbione> so it should go in..
<fabbione> well i am sure it is built properly
<fabbione> danke
* fabbione kicks Xorg in the code
<fabbione> humpf
<fabbione> this will need an Imake patch to get fixed properly
* lamont told the neighbor that he'd come look at his install issue in about 45 min... so I need to wander off for a few soon..
* lamont looks to see if he can update chroots yet
<fabbione> lamont: i don't see build-essential around yet
<fabbione> yay there it is another package
<lamont> fabbione: I'm busy being confused...
<fabbione> lamont: ehehe
<lamont> we should have gcc-defaults and build-essential there for all  architectures after the :33 pulse, I think
<fabbione> yes i think so
<fabbione> build-essential missed the :33
<fabbione> gcc-defaults source is there....
<fabbione> or it seems like
<fabbione> ok i got xc to compile..
<fabbione> let's see xc-debug
<fabbione> bah crap
<fabbione> it does a make clean
* lamont runs off for about 8 minutes
<fabbione> i will need to get some food soon
<fabbione> wow.. this was easy :)
<fabbione> lamont: the GCC34_MMX macro is simply broken
<fabbione> it doesn't know about gcc-4
<fabbione> so killing the -D works
<fabbione> even if it is not the cleanest solution
<lamont> build-essential_11.0ubuntu1 is installed in all the data center chroots
<lamont> we are _GO_ for library infusion
<fabbione> lamont: ok thanks
<lamont> at least from my perspective
<fabbione> but we are not ready for the libs yet
<fabbione> we need xorg first
<lamont> ah, well then. get on it.
<fabbione> i am almost done i think
<fabbione> there are a couple of things that still don't match
<fabbione> ok if i got everything right, this is the last xorg build (at least on i386)
<fabbione> i just need to revisit a second the upload order
* lamont back in a bit
<fabbione> elmo: i am almost ready to start uploading X packages
<fabbione> some of them will need NEW love
<elmo> ok
<fabbione> this is going to be the upload order:
<fabbione> in parallel:
<fabbione> render_0.9-0ubuntu2_source.changes
<fabbione> x-common_0.99_source.changes
<fabbione> x11proto-core_6.8.99.7-1_source.changes
<fabbione> xtrans_0.2+cvs.20050513-1_source.changes
<fabbione> (3 of them needs NEW)
<fabbione> xrender_0.9.0-0ubuntu5_source.changes
<fabbione> (build-dep on render-dev)
<fabbione> and again in parallel:
<fabbione> xft_2.1.7-1ubuntu1_source.changes
<fabbione> xcursor_1.1.3-1ubuntu1_source.changes
<fabbione> (both build-dep on xrender-dev)
<fabbione> and as last xorg
<fabbione> this should do
<fabbione> yeah x is installing
<fabbione> dh_install --sourcedir=debian/tmp
<fabbione> COME ON
<fabbione> install bitch!
<fabbione> lamont: are you back?
<fabbione> elmo: first 4 packages on the way
<fabbione> elmo: katie hates me :)
<fabbione> or hates daniels
<elmo> REJECT
<elmo> Rejected: Unknown distribution `unstable'.
<elmo> that you mean?
<fabbione> i don't get the rejects.. daniels did the packages
<fabbione> what package was that?
<elmo> render_0.9-0ubuntu2_source.changes
<elmo> x-common                | 0.99                    | source                  | 9 minutes old
<elmo> x11proto-core           | 6.8.99.7-1              | source                  | 9 minutes old
<elmo> xtrans                  | 0.2+cvs.20050513-1      | source                  | 9 minutes old
<elmo> ^-- all got to NEW
<fabbione> ok.. thanks
<fabbione> i am repreparing render
<elmo> eh, what's the point of x-common?
<fabbione> elmo: to make the X11 symlink disappear 
<fabbione> as far as i understood at least
<elmo> a whole package for it?
<fabbione> elmo: daniels is killing X11R6 and soing modular
<fabbione> x-common will get more stuff later
<fabbione> new render is up
<fabbione> you can let them in at any time
<fabbione> s/soing/going
<elmo> I assume these packages have to all be in main?
<fabbione> elmo: yes
<elmo> ok, processed
<fabbione> great
<fabbione> did they make the :33 daily?
<fabbione> sorry for pushing/asking but it's like 15 hours that i am here :)
<fabbione> if i can save 30 minutes, that would be really nice :)
<elmo> hmm
<lamont> back
<fabbione> lamont: rocking.. the first 4 pkgs have been accepted
<elmo> hsssssssssssssssssssssssst
* fabbione watches elmo melting down
<elmo> hppa broke cron.daily
<elmo> once the current one finishes, I'll rerun it
<fabbione> ah ok
<fabbione> thanks
* lamont boggles
<fabbione> hmm it looks like the list of packages for no_auto_build is a bit too long
<elmo> ?
<fabbione> ah crap no
<fabbione> never mind
<elmo> btw, cron.daily done
<fabbione> rocking
<elmo> is there any reason you can't just upload all this stuff and let the buildds figure it out based on the b-d's?
<fabbione> elmo: because i am not too confident in these packages. they got very little testing
<elmo> ok
<fabbione> so i prefer to break only one piece at a time if the Build-Deps are wrong
<elmo> these -dev packages have .c files in /usr/include?!?!?!?!?!!?!?!?!
<fabbione> eh??????
<elmo> drwxr-xr-x root/root         0 2005-05-17 20:45:55 ./usr/include/X11/Xtrans/
<elmo> -rw-r--r-- root/root      3070 2005-05-17 20:45:55 ./usr/include/X11/Xtrans/transport.c
<elmo> -rw-r--r-- root/root     31104 2005-05-17 20:45:55 ./usr/include/X11/Xtrans/Xtrans.c
<fabbione> daniels !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<fabbione> bah
<fabbione> that can be fixed as soon as daniels wakes up
<fabbione> brb
<fabbione> i need 5 minutes break at least to see my wife
<elmo> sure
<fabbione> re
<lamont> hrm... does ccache do gcj stuff too?
<elmo> no
* lamont grumbles
<jbailey> lamont: Shouldn't be alot of gcj stuff.
<jbailey> lamont: It should be mostly arch: all with a bit in the postinst.
<jbailey> lamont: That rare exception being the bits that use JNI
<lamont> ah, that makes sense... the gcc-4.0 test build is -A
<fabbione> ok it looks like all the 4 packages did build properly...
<fabbione> xrender is on the way
<fabbione> this one should still be safe....
<fabbione> actually also xft and xcursor should be safe...
<fabbione> there.. up
<fabbione> as soon as these 3 packages are available we should be able to upload Xorg
<lamont> fabbione: which packages am I babysitting?
<fabbione> lamont: xrender_0.9.0-0ubuntu5_source.changes (chinstrap)
<fabbione> xft_2.1.7-1ubuntu1_source.changes (me)
<fabbione> xcursor_1.1.3-1ubuntu1_source.changes (me)
<fabbione> they should hit the buildd at the next :33 daily
<fabbione> the other 4 already builded fine
<fabbione> all ACCEPTED
<fabbione> elmo: if you want to speed up things, you could run .daily again
<elmo> running
<fabbione> rocking
<elmo> done
<lamont> May 17 21:29:28 buildd: breezy: total 3 packages to build.
<fabbione> lamont: i guess it's them :)
<fabbione> lamont: are they building or did they destroy the chroots?
<lamont> pretty much uploading, without digging around too much
<fabbione> ok
<lamont> built on all 4
<elmo> I'm running cron.daily again
<elmo> AFAICS everything's built
<fabbione> ok
<fabbione> uploading xorg now :)
<fabbione> if this one break we are fucked
<lamont> fabbione: no.  we'll be annoyed.
<lamont> there's a subtle difference.
<fabbione> lamont: eheheh
<fabbione> well the point is that i am tired and i am not 200% sure i can manage to debug X 
<fabbione> so.. somehow somebody is fucked until daniels wakes up :)
<fabbione> so you and elmo can be annoyed
<fabbione> i will be fucked for the next 2/3 hours
<fabbione> :)
<fabbione> xorg is up
<fabbione> if this one goes ok, we can push all the libs from doko
<fabbione> xorg_6.8.2-11_source.changes ACCEPTED
<lamont> make[4] : *** No rule to make target `gnu/java/net/protocol/https/Handler.java', needed by
<lamont> +`gnu/java/net/protocol/https/Handler.class'.  Stop.
<lamont> make[4] : *** Waiting for unfinished jobs....
<lamont> make[4] : Leaving directory `/build/buildd/gcc-4.0-4.0.0/build/x86_64-linux/libjava'
<lamont> oh doko!!!!
<lamont> gcc-4.0_4.0.0-7ubuntu3 times 4
<fabbione> lamont: yeah he told me that ubuntu3 was FTBFS
<lamont> do we have -4?
<fabbione> not yet
<fabbione> he told me one minute before leaving
<fabbione> lamont: keep a close eye on xorg
<fabbione> it will pull in all the crap in one go
<elmo> xorg's building
<fabbione> elmo: cool.. on all 4 arches?
<elmo> (sorry about the delay, I was (re)building a 2nd archive.ubuntu.com, and it was slaughtering jackass' performance
<elmo> I assume so
<fabbione> no problem about the delay.. i am almost dead anyway :)
<fabbione> lamont: ?
<elmo> yep, all 4
<fabbione> cool
<fabbione> we need to wait Xorg, upload a clean x-common and the libs from doko
<elmo> clean x-common?
<fabbione> elmo: yes. 0.99 had a Dependency hack to build xorg -11
<fabbione> once .11 is built, the hack can be removed
* elmo puts his hands in his ears and sings LALALALA
<fabbione> ahhaha
<fabbione> elmo: either 2 x-common or 2 xorg uploads
<fabbione> considering the size and the arch: all we opted for x-common
<fabbione> we did agree that it was dirty
<lamont> elmo: I told them it was evil at least...
<fabbione> but definetely faster :)
<lamont> we need to make sure that we have a URL for the morgue-ed source for the 0.99 x-common package to put on the evilness-you-must-endure-when-porting page
<fabbione> lamont: there will be no need
<lamont> oh?
<fabbione> the reason is that xorg-common is arch: all
<fabbione> so once it is built, it will be there and cooperating properly with x-common 1.0
<lamont> and how will xorg build with the old new x-common installed on a debian chroot?
<fabbione> at the end of the transition xorg will not exists anymore
<fabbione> there will tons of little tiny source packages
<lamont> ah, ok
<fabbione> unfortunatly we did hit a bad timing for X
<fabbione> because daniels was splitting xorg to the modular tree, killing X11R6 at the same time that we need to do the C++ transition
<lamont> right
<fabbione> so look at this sequence of uploads as something you won't need after
<lamont> right.  But I will need it this week, when I finally get hppa started on building breezy.  sigh
<fabbione> lamont: once i386 build the arch: all, you will have no problems
<lamont> are we planning to bump all the cxxapps, or just let time and transition deal with that?
<fabbione> no idea about the apps
<fabbione> we will need to ask doko
<fabbione> he should be around soon enough
<lamont> fabbione: once i386 builds the second x-common arch:all package, then it can take the place of the first?  huh???
<fabbione> lamont: yes. 
<lamont> even though I have a hoary xorg?
<fabbione> the problem is the interaction between xorg-common -10 postinst and x-common
<lamont> which seemed to me to be the whole reason for the hacked upload....
<lamont> fabbione: that's hppa's current state... has xorg -10
<fabbione> lamont: you still get _all.deb from i386
<fabbione> that will be -11
<lamont> ok
<fabbione> if you are building arch: all locally.. well.. yeah you will need to go trough the same harassment
<lamont> it does mean that I need to have my mirror current before I get to xorg though....
<fabbione> yeps
<lamont> only arch-all building locally is either testing, debian uploads, or glibc hacking.  damn locales
<fabbione> eh
<fabbione> ehehe
* lamont watches the glibc build go through Testing IBM500....
* fabbione wonders how long is going to take
<lamont> fabbione: until about :20 ish
<lamont> based on history, that is
<fabbione> ok
* fabbione gives back a bunch of packages in Dep-Wait for gcc-4 & co
<fabbione> i need to find a way to automatically set the packages in Dep-Wait
#ubuntu-toolchain 2005-05-25
<fabbione> hmm i can't find the archive
<fabbione> ops
<doko> back again
<fabbione> hey doko
<lamont> ftbfs on ppc
<fabbione> fuck
<doko> where are we? xorg?
<fabbione> doko: yes. xorg
<lamont> LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale  ../../../exports/bin/xcursorgen
<lamont> +X_cursor.cfg X_cursor
<lamont> libpng error: Call to NULL read function
<lamont> PNG error while reading X_cursor-16.png!
<lamont> xorg
<fabbione> ENOCLUE
<lamont> ^5
<lamont> I don't think a give-back will help
<lamont> otoh, why are we building the cursor here?  isn't that arch-indep?
<doko> lamont: all the buildd's do have the new built-essential?
<lamont> doko: yes
<fabbione> it's a library or something for the server
<lamont> just waiting on xorg to finish up in the next 20-30 min, then we can play with libraries
<doko> ok, then I'll go through the libs in main and upload libs, which don't depend on glu-something
<fabbione> doko: please wait
<fabbione> let's get Xorg to build first
<lamont> doko: given that we build pretty much all of main in < 6 hours or so, it's not like there's a big hurry.../
<fabbione> and we can upload all the libs in one go
<fabbione> doko: the Xorg deps and build-deps aren't stable yet
<fabbione> so something might need to change
<doko> ok, will wait
<fabbione> + after X there is still one x package that needs upload
<fabbione> once that one is in, you are clear to go
<lamont> fabbione: so about the ppc xorg ftbfs....
<lamont> thoughts?
<fabbione> lamont: no.. not really
<fabbione> i am checking the buildlog now
<lamont> i386 and amd64 == uploaded
<lamont> ia64 is about 5/14's done
<fabbione> it looks like an error in libpng to me
<lamont> which leads to the question of what to do to fix it...
<fabbione> lamont: try to kick back
<lamont> given back
<fabbione> it's not an X problem imho
<fabbione> the error comes from libpng attempting to read that file
<fabbione> and the file is valid
<lamont> is the abuse in x-common such that we could stall on uploading 1.0?
<fabbione> lamont: do you feel more confortable to wait to upload x-common 1.0?
<fabbione> it's just question of removing a Pre-Depends
<lamont> well, if we did that, then ia64 could catch up...
<fabbione> sure it can wait
<fabbione> i don't see a big problem with that
<fabbione> sparc will catch up too
<fabbione> but again.. once xorg-common -11 is in, the pre-depends can disappear :)
<lamont> right.  and that's the next cron.daily run
<fabbione> sure.. i didn't plan to upload x-common until at least the 3 major arches have all the binaries in place
<lamont> doko: you planning to upload a fixed gcc-4.0 (is ftbfs) soon?
<fabbione> even if i would pay gold to go to sleep now :)
<doko> lamont: no
<doko> have to find out, why it fails
<fabbione> daniels: you awake yet?
<lamont> ah, right
<fabbione> lamont: ?
<lamont> doko: while you're in there, could you disable the testsuite on hppa?
<fabbione> ahah
<lamont> fabbione: was aimed at doko and gcc-4.0
<fabbione> ehhe yeah
<fabbione> fuck
<fabbione> server died again for no reasons
<fabbione> i had the time to hear all the disks spinning down nicely
<fabbione> and puff... it was frozen
<lamont> overtemp?
<lamont> fabbione: on the bright side, with ccache, it only takes 10 minutes for powerpc to reproduce the failure
<fabbione> lamont: nope.. it would send the alarm
<fabbione> hmmm
<fabbione> what version of libpng gets installed in the different chroots?
<fabbione> is it the same?
<lamont> was the same buildd, same chroot
<lamont> libpng12-0 
<fabbione> i mean across the arches :)
<lamont> should be the same... /me checks
<lamont> libpng12-0_1.2.8rel-1 on all 4
<lamont> OTOH, ppc is the only big-endian arch in the pile
<fabbione> yeah
<jbailey> Bah, /me fixes the typo and starts again.
<lamont> short gym trip, eh>?
<fabbione> so is sparc... but it will take time to get there
<lamont> yeah.  gcc-4.0 build running now
<jbailey> lamont: I felt guilt, so I started the build on amd64 and ia64 as well, by the time I got them running, ppc had failed.
<fabbione> i wonder if libpng is broken on ppc 
<jbailey> fabbione: It is.
* lamont hugs jbailey 
<jbailey> fabbione: sb had me test that yesterday 
<lamont> is fix known?
<lamont> because it's blocking the transition
<jbailey> Ugh, really?
<lamont> xorg is ftbfs/ppc
<lamont> fabbione: you saw that xorg/amd64 was rejected, yes?
<fabbione> don't tell me that there is known fix and it had not been uploaded...
<fabbione> lamont: meh.. no why?
<jbailey> Gimme a sec to fire these things up.
<lamont> <lamont> Rejected: xprt_6.8.2-11_amd64.deb: old version (1:0.1.0.alpha1-10) in breezy >= new version (6.8.2-11) targeted at breezy.
<lamont> <lamont> so that's 2/3
<jbailey> fabbione: Nope, I was just asked to test it.  I was hacking on other stuff so didn't explore it any further.
* lamont hopes we get things settled in the next 90 minutes, so he can go to his fire dept training
<lamont> doko: ew... patch fuzz in gcc-4.0... :-)
<fabbione> hmmm
<fabbione> that should have happened on i386 too
<fabbione> xprt is an arch: any
<fabbione> and why on heart daniels still ship that shit
<fabbione> ok let's make a summary
<fabbione> libpng is fucked on ppc
<fabbione> that is a blocker for xorg
<fabbione> xorg needs xprt love
<fabbione> and another upload
<lamont> sounds about right.
<fabbione> otherwise we cannot go for libs
<fabbione> or ppc will lag eons behind
<lamont> and dropping ppc from breezy is _not_ an option...
<doko> should we reupload libpng compiled with 3.3 on powerpc?
<lamont> doko: is that known to fix it?
<fabbione> doko: are we sure that is the right thing to do?
<doko> no
<fabbione> than no
<lamont> fabbione: you have ppc at your place?
<fabbione> somebody needs to investigate the real issue
<fabbione> lamont: no
<fabbione> i have been begging for one for a long time
* lamont does, but not really... would take 24 hours or more to test-build xorg
<fabbione> i keep getting i386trash
<fabbione> lamont: davis?
<lamont> davis is an option..
<lamont> elmo about?
<fabbione> elmo can upgrade a chroot and that's it
<lamont> exactly
<fabbione> jbailey, lamont: there is nothing more i can do for today
<fabbione> i am crashing
<elmo> lamont: ?
<lamont> g'night fabbione
<fabbione> daniels should be awake soon
<doko> good night
<lamont> can you freshen the breezy chroot on davis?
<lamont> elmo^^
<fabbione> elmo: with the new xorg build-dep ;)
<lamont> then I'm going to try building libpng with gcc-3.3, and have you install that in the chroot.
<lamont> and then we'll see if that fixes the xorg build problem
<fabbione> if there is something, i will have my mobile phone with me
<lamont> and then I'll cry
<fabbione> lamont: no.. just wake up the kid :)
<lamont> heh
<fabbione> i am off
<fabbione> good night guys
<jbailey> lamont: I have to go in 10 minutes, is there anything you need me to do nowish?
<jbailey> g'n Fabio!
<lamont> jbailey: not unless you can upload a fix for libpng. :-(
<lamont> jbailey: any hints on what it was?  or you just verified it was NFG?
<jbailey> Just verified it was nfg.
<lamont> that is, braindump would be cool.
<lamont> and done. sigh.
<lamont> way quick braindump
<elmo> lamont: doing
<lamont> elmo: and libpng3 build-deps, of course.
<elmo> nothing to install?
<elmo> and done
<lamont> probbaly nothing to install
<elmo> ARGH
<elmo> Rejected: xprt_6.8.2-11_ia64.deb: old version (1:0.1.0.alpha1-10) in breezy >= new version (6.8.2-11) targeted at breezy.
<lamont> yeah - we discussed that a bit a while back.
<lamont> it's on the list of things to deal with.
<lamont> but libpng is a bigger blocker...
<lamont> unless you wanna make the old xprt just go away... :-)  But that would be, well, wrong.
<lamont> elmo: in davis:breezy-chroot: dpkg -i ~lamont/breezy/libpng12*.deb please
<elmo> eh, what are they?
<lamont> they're the same source, built with gcc-3.3
<elmo> installed
<lamont> dpkg-checkbuilddeps: Unmet build dependencies: xtrans-dev
<elmo> installed
<lamont> so if the libpng3 build fixes things, we'll know in about 50 minutes... if it doesn't, then I'll actually have a tree to start debugging on.
<lamont> meanwhile, sort break time
<doko> lamont: what do you sort?
<lamont> short
<doko> :-)
<doko> lamont: ok, I found the 4.0 bootstrap failure. mind, if I upload a fixed one?
<elmo> doko: why would lamont mind?  unlike Debian, he has 3 buildds per arch on a GB LAN :P
<elmo> not that I'm bitter every time vore grinds to a halt after one of your upload sprees or anything
<doko> elmo: yes, that' why I uploaded the last one built for sparc ...
<elmo> doko: dude, you REALLY shouldn't do that
<lamont> please don't upload binaries unless you're a buildd
<lamont> oh. debian.  well, still shouldn't
<lamont> doko: upload away
<doko> heh, it doesn't even go to sarge. lamont: will do
<lamont> doko: this has my hppa fix too?
<elmo> heh, in Ubuntu, you CAN'T upload binaries unless you're a buildd
<elmo> (or have access to their secret key)
<elmo> I wish I could enforce that level of facism in Debian :(
<doko> lamont: fix? crappy workaround of disabling the testsuite a fix? ;-)
<lamont> doko: yeah. that "fix". :-)
<lamont> doko: I'm willing to bet that it's the long-standing bug in signals, but really can't say for sure
<daniels> i'm here now
<daniels> elmo: xprt isn't something we care about for the time being
<daniels> if the rest of the upload goes through, that's a win
<elmo> the rest of the upload so doesn't go through
<elmo> if it did, I'd shoot myself
<lamont> daniels: it's kinda this atomic thing, you see...
* lamont pictures elmo-with-a-gun, fears for sesame street
<daniels> elmo: the xtrans stuff isn't a bug, mmkay
<daniels> elmo: this is why I've said several times that I despise xtrans and want it to die
<lamont> daniels: one option is to just not deliver the xprt binary package...
<lamont> although I expect that breaks some other packages down the line
<daniels> elmo: ok
<doko> hi daniels, short night ... ;)
<daniels> i'll prepare a new xorg
<daniels> heh
<lamont> doko: he was gone almost 8 hours...
<lamont> daniels: we also need to figure out what's up with libpng/ppc
<doko> lamont: you're right, that's too much
<lamont> and note that fabbione had to do some stuff to xorg to make it build with gcc-4.0....
<lamont> if you have a shared source archive, greate... if not, you need to fetch from the archive...
<daniels> yeah, I slept in by an hour
<lamont> doko: and I need ccache bindings for ada, so that the gcc-4.0 build can go fast.
<lamont> ditto for gcj
<doko> lamont: hmm, these are not yet upstream?
<elmo> night all
<elmo> lamont: a lot of the gcc slowness is hte test suite ..
<lamont> elmo: not when it's disabled. :-)
<lamont> g'night elmo
<doko> night
<doko> ccache doesn't help in the testsuite
<lamont> right\
* lamont is watching the ada build churn along
<lamont> while waiting for the xorg build to fail agian
<lamont> elmo: if you're still around, I'm wondering why xorg seems to have made it in on i386 - was there no xprt agony there?
<daniels> was xprt ftbfs on i386?
<daniels> nigt elmo
<lamont> daniels: dunno
<lamont> what source package?
<daniels> xprt
<lamont> xprt doesn't show up in wanna-build for i386
<lamont> or any arch, for that matter
<lamont> hoary or breezy
<daniels> um
<daniels> so this might sound a little bit nasty
<daniels> but is there any chance you could hack the changes file to exclude xprt and shepherd the rest of the upload through?
<lamont> no
<daniels> agh
<lamont> (not just because all the .debs and the .changes file get deleted...()
<lamont> the ubuntu archive remains unviolated by hand-edited changes files, and shall remain so on my watch.
* infinity violates is when lamont isn't looking.
<infinity> s/is/it/
<lamont> infinity: you don't have the key to violate it
<doko> infinity: looks like your buildd career did finish before it did begin ;-P
<infinity> ;)
<doko> lamont: http://people.ubuntu.com/~lamont/buildLogs/j/java-gcj-compat/1.0.28-0.0ubuntu1/ ???
<lamont> doko: any chance something Provides: libgcj-dev?
<daniels> lamont: what, you're telling me you're the paragon of cleanliness and archive sanctity now? :P
<lamont> daniels: I always play by the specified rules.
<lamont> that's what makes it so much fun. :-)
<doko> ehh, yes ... libgcjX-dev ... looks like I should remove it
<lamont> daniels: my forte lies in analyzing complex systems and determining how to accomplish a specified task within the structure imposed by that system.
<lamont> some call it hackish and kludgy, others also call it necessary.
<lamont> s/it/it only/
<lamont> ubuntu is nice because we have a very minimal set of complexity in the system.  mostly, it's just implemented correctly to begin with.  hence we can keep it more pure and clean...
<lamont> that, and one of the rules is 'it shall remain unviolated' :-)
<infinity> lamont : If that's your forte, you should have been a tax accountant, not a programmer. :)
* lamont _does_ do his own taxes...
<daniels> heh
<lamont> infinity: note that said forte also applies very well in computer security, forensic analysis, and so forth
<lamont> our family calls it "rules lawyering"
<infinity> Oh, I realise it has many uses, it just happens that good tax accountants make a lot more than those other professions. :)
<lamont> although, I must admit, life is more interesting when you have to explain both the letter of the law and the intent of the law to your kids, so as to avoid hearing "but dad, you said ..."
<infinity> (I consulted to one who worked exclusively with clients who had salaries of over a million a year... His income was significantly higher)
<lamont> heh
<lamont> infinity: fwiw, I apply it pretty much to all aspects of my existance
<doko> lamont: please build 4.0-5, not -4 on your slooow hppa box
<lamont> debian?
<doko> breeeezzzzyyy
<lamont> so 0ubuntu5.  check
<lamont> actually, I think  I'm going to let 0ubuntu2hppa1 finish building first. :-)
<doko> yes, skip 0ubuntu4
<lamont> ew.
<doko> hmm, I'm going to sleep, doing more harm then good
<lamont> doko: given hoary/hppa's pseudo-existance
<lamont> I really can't build any of the cxxlibs before you upload them, yes?
<lamont> given breezy/hppa with g++4.0
<doko> build them using g++-3.4, hack around gcc-defaults
<lamont> actually, it just means adding build-essential and gcc-defaults to the no_auto_build list
<lamont> since they haven't built yet.
* lamont screams, uploads his libpng3 hack
<lamont> dpkg-genchanges: binary-only upload - not including any source code
<lamont> dpkg-buildpackage: binary only upload (no source included)
<doko> lamont: I don't understand what you gain
<lamont> doko: fix gcc-{3.4,4.0} so that it builds libpng3 correctly
<lamont> doko: gain with not building build-essential, gcc-def?  it means that I don't have to hack around gcc-defaults...
<lamont> then once you upload the libs, then it's no issue again
<doko> yes, but you end up with the wrong C++ ABI
<doko> so you verified, that libpng3 is miscompiled with gcc-3.4 _and_ 4.0 on powerpc?
<lamont> libpng doesn't Depend: C++
<lamont> seems to be wrong on gcc-4.0.  didn't check 3.4
<doko> I didn't write this
<doko> ahh, ok
<doko> daniels: could you destill a testcase from the xorg build?
<daniels> um, possibly
<lamont>  Depends: libc6 (>= 2.3.4-1), zlib1g (>= 1:1.2.1)
<lamont>  Depends: libpng12-0 (= 1.2.8rel-1ubuntu1), zlib1g-dev
<doko> lamont: if you do have time, could you recheck with a libpng3 compiled with -O2 and/or -O1?
<lamont> sure
<lamont> doko: except that I was testing it by using the package installed in the chroot...  and I can't update that...
<lamont> actually, it's built without -O
<lamont> see debian/patches/makefile.patch
<doko> ?
<lamont> nm
<lamont> gcc -Wall -D_REENTRANT  -g -O3    -c -o pngset.o pngset.c
<lamont> ah.  that part comes from debian/rules
<daniels> -O3??
<lamont> daniels: yeah. crack
<doko> DEB_BUILD_OPTIONS overwrites this ...
<lamont> doko: yes
<doko> looking at the archives I see issues with -funroll-loops, which is enabled by default in 4.0 at -O3. So I assume -O2 will help here ...
<lamont> hrm... I suppose LD_LIBRARY_PATH could help force things to the rebuilt package.
<daniels> (breezy-chroot)daniels@davis:~/redglass $ xcursorgen X_cursor.cfg X_cursor
<daniels> (breezy-chroot)daniels@davis:~/redglass $ dpkg -l libpng\*
<daniels> [...] 
<daniels> ii  libpng12-0                1.2.8rel-1ubuntu1         PNG library - runtime
<lamont> that's the new version.
<lamont> which is built with gcc-3.3
<daniels> note the lack of segfault
<lamont> you have ppc there?
<daniels> note the 'daniels@davis' ;)
<lamont> ah, that's in the same chroot where I just verified my fix.
<daniels> oh, so you installed it?
<lamont> note that -1ubuntu1 source will be in the archive in about 8 minutes
<lamont> no, elmo did.  before he left.
* lamont has no root on the porting boxes
<doko> ok, going to bed now, 3am ...
<doko> good night
<lamont> g'night doko
<lamont> daniels: once we have xorg/xprt love, then we can upload doko's libraries
<lamont> doko: before you leave...
<doko> yes?
<lamont> where do all the libs live, so we can upload them once X is happy?
<doko> chinstrap:~doko/cxxsrc, but without kdelibs please
<lamont> no kdelibs.  check
<daniels> lamont: yep, I'm testing the xprt-less build
<lamont> daniels: once you get an xorg that is xprt-happy, let me know.  (then we can see about finishing debugging the libpng thing...)
<daniels> doko: in any case, xcursorgen, and davis:~daniels/redglass/X_cursor*, is your testcase
<daniels> lamont: will do
* #ubuntu-toolchain  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
(fabbione/#ubuntu-toolchain) at what time did i go offline?
(jbailey/#ubuntu-toolchain) daniels: if gcc-3.3 fixed it, then it's probably altivec fuckage.  I can try to take a look at that tomorrow.
<jbailey> And in the meantime, Fabio showing up for his morning work is my hint that it's bed time.
<jbailey> g'n all!
<fabbione> hey jb
<fabbione> jbailey: klibc is FTBFS on sparc :)
<fabbione> goot night
<daniels> night jbailey
<lamont> daniels: want to try a -14 that has fabbione's fixes from -11?????>????"??
<daniels> fabbione: 3h17m before you joined
<jbailey> fabbione: Forward me a build log?  It's working everywhere else. =(
* lamont goes to bed
<daniels> lamont: the what now?
<lamont> all the bugs that fabbione fixed so that it actually builds with gcc-4.0 were reintroduced in your upload.
<lamont> please fix them.
<daniels> oh, biteage
<daniels>    * Add patch 991_ubuntu_gcc_flags.diff as a temporary workaround to a borked
<daniels>      gcc-3.4 check.
<fabbione> oh fuck.. daniels you didn't merge from the archive?
<lamont> also, please test your upload in a gcc-4.0 chroot, k?
<daniels> fabbione: no, I didn't know you made any changes to xorg
<daniels> lamont: this is with gcc4
<jbailey> fabbione: I want to work magic of some sort that combines all the build daemon activity, including ports into an rss feed that I can just look at and show even things that would be on ports.ubuntu.com.
<daniels> fabbione: is it just #991?
<fabbione> daniels: and build-deps
<daniels> ok
<lamont> daniels: go back about 6 hours in your scrollback...
<lamont> <lamont>        daniels: we also need to figure out what's up with libpng/ppc
<lamont> May 17 18:03:12 <doko>  lamont: you're right, that's too much
<lamont> May 17 18:03:14 <lamont>        and note that fabbione had to do some stuff to xorg to make it build with gcc-4.0....
<lamont> May 17 18:03:39 <lamont>        if you have a shared source archive, greate... if not, you need to fetch from the archive...
<lamont> although maybe that was pre-coffee
<lamont> anyway, past my bedtime
<fabbione> good night lamont
<daniels> night lamont
<lamont> fabbione: -13 is ftbfs, libpng should be fixed, just need a gcc-4.0 friendly -14, and xorg should actually make it into the archive.
<fabbione> lamont: ok thanks
* lamont will be back in about 7-8 hours, modulo getting kids out the door to school
<fabbione> i won't be around that long
<fabbione> not after 19 hours of yesterday
<daniels> fabbione: sure
<lamont> heh
<lamont> at any rate, if things need buildd love, I expect you'll see elmo before me.,
<daniels> indeed, i'll get it sorted out somehow
<daniels> i need to do a mirror sync to get the new packages, so I'll go afk for about an hour while my internet connection is useless
<fabbione> daniels: my archive is synced
<fabbione> do you want me to merge for -14?
<fabbione> it will take me the same amount of time as for you to wait
<daniels> it's ok, i'll do more testing in chroots and stuff
<fabbione> hmmm something is already pulling in x-common
<fabbione> oh right
<fabbione> xrender
<daniels> yep
<daniels> the /usr stuff should pull it in
<fabbione> yeah it does
<daniels> else it'll be stuck in /usr/X11R6
<fabbione> but it's ok
<fabbione> the buildd likes it
<daniels> do xft and xcursor have the pre-depends?
<fabbione> no, but they depends on xrender
<fabbione> that pre-depends on x-common
<fabbione> so that's enough to pull in * in the proper wat
<fabbione> way
<daniels> mmmmmmm
<daniels> i'd still rather it was explicit, but just as long as it works
<doko> morning all
<fabbione> hi doko
<fabbione> doko: FYI we are waiting for xorg
<fabbione> -14 will hit the archive sometime in the next 3 hours
<fabbione> after that we should have greenlight
<doko> heh, cool
<fabbione> i am tired to death
<fabbione> why my wife needs to wake up at 6am
<\sh> it's a problem with all wifes ;)
<doko> did jbailey notice about the glibc build failure?
<\sh> doko: did u upload kdelibs4c2?
<fabbione> \sh: no libs have been uploaded yet
<fabbione> doko: doh! it's building here
<\sh> hmmm....
<\sh> ok..in dokos repos ;)
<doko> ? building?
<doko> lamont: hmm, the glibc patch, which fails to apply in the datacenter, applies cleanly here 
<fabbione> it works here to
<fabbione> i think it's a LANG= thing
<doko> does work with LANG= as well.
<fabbione> no i mean.. how it has been setup on the buildd
<fabbione> but it's weird
<fabbione> probably a kick back would do
<fabbione> so at the end
<fabbione> the only arch that doesn't need new libc, is the only one building it
<doko> :(
<fabbione> oh well
<fabbione> it will refresh the ccache :)
<fabbione> daniels: how is -14 coming?
<daniels> good; my mirror pulse just hit universe not too long ago, so I'm in the middle of refreshing the chroot
<fabbione> doko: can i build gcc-4 7ubuntu5 or are you planning an upload in 3 minutes?
<doko> sorry, I won't make it in 3 minutes ;)
<doko> no, built ok.
<fabbione> doko: well do you plan any upoad withing the next 24 hours?
<fabbione> upload even
<doko> hmm, do we save some time, if we reupload glibc?
<fabbione> doko: no
<fabbione> let see why it fails on the buildd first
<fabbione> otherwise it is pointless
<\sh> so..if the old name is libsomelibc102  the new name will be libsomelib right?
<daniels> correct
<\sh> thx :)
* fabbione wishtles xorg in daniles' hear
<daniels> yeah, it's in the install target now :P
<fabbione> daniels: goody
<fabbione> daniels: btw.. 991 was just a workaround to get it to build
<fabbione> the real issue is the macro that changes HasGCC34
<fabbione> that doesn't know gcc-4
<daniels> yeah, I'll look into that for -15
<fabbione> yeah
<\sh> hmmm
<elmo> morning
<\sh> any explanation why the resulting package for libqssl2 (recompiled with g++4) is named like _hurd-i386?
<fabbione> hey elmo
<fabbione> elmo: can you please kick back glibc on all arches?
<fabbione> elmo: for some reasons it FTBFS at the DC, but it is building fine both on doko machine and my buildd
<elmo> given back on i386
<elmo> it looks like a fairly generic failure
<fabbione> yeah it is
<elmo> are you sure it's not something like patch ordering due to locale?
<fabbione> elmo: i have the same overrides here as lamont does
<fabbione> LANG=C
<fabbione> but that was the same impression i got
<fabbione> # Environment variables to set/override:
<fabbione> %ENV_OVERRIDES = {
<fabbione>         'LC_ALL' => 'C',
<fabbione> };
<fabbione> and my buildd is choaking on it right now
<doko> let's fix dpkg-architecture first :(
<elmo> dpkg-buildpackage: host architecture hurd-i386
<elmo> ?!?!?!?!
<fabbione> does dpkg-architecture come from dpkg?
<elmo> what the FUCK?
<doko> $ dpkg-architecture -qDEB_HOST_GNU_TYPE
<doko> i386-gnu
<fabbione> if so we are doomed
<\sh> elmo: ah ;)
<fabbione> dpkg is C++ application
<fabbione> and banned from being built
<\sh> so i'm not the only one who pushed the button for the Infinite Improbability Drive
<elmo> DEAR SCOTT, PLEASE STOP BREAKING THE WORLD.  K THANKS BUH BYE
<fabbione> you know what??!?!?!??!
<\sh> at least we know for sure: Hurd is not dead ;)
<fabbione> I AM SO FUCKING HAPPY THAT SPARC IS SO SLOW THAT DIDN'T GET TO BUILD THE BROKEN DPKG!!!
<doko> fabbione: dpkg was just uploaded before we stopped ...
<fabbione> doko: but it didn't get builded on sparc :)
<fabbione> it was in the queue
<fabbione> so i am still running a good dpkg
<fabbione> MUHA MUHA MUHA
<fabbione> now
<fabbione> let's think how to unfuck this mess
<\sh> fabbione: but r lame ;) U r not able to fly withus in the "Heart of Gold"
<daniels> fabbione: step 1: call scott.  step 2: shout.
<fabbione> daniels ++
<fabbione> but the main issue is that dpkg is a C++ application
<fabbione> i wonder if we still have some pre-transition-breezy chroots
<fabbione> if so we could manually build a working dpkg
<fabbione> install it in the chroots
<elmo> eh, it's a C++ apps that only links against libstdc++ ?
<fabbione> complete the transition
<elmo> what's wrong with just compiling it?
<fabbione> elmo: doko banned it.. no idea why
<fabbione> doko: ?
<doko> no reason, should un-ban it
<doko> elmo: removed it from cxxapps.txt
<fabbione> elmo: that needs to be manually removed on all 12 buildd
<elmo> undone here too
<elmo> oh, BLAH, seriously?
<fabbione> elmo: yes from buildd.conf
<fabbione> @no_auto_build = qw(....);
<elmo> actually, no it doesn't, only one per arch
<elmo> anyway, when you guys have a fix, lemme know
<doko> hmm, gcc already picked up the wrong architecture, and dpkg-architecture relies on gcc -dumpmachine
<fabbione> dpkg-buildpackage: host architecture hurd-i386
<fabbione> ahhaha
<fabbione> amazing
<fabbione> we need to stop the buildd
<fabbione> and see how many pkgs have been affected
<elmo> I don't think many well?
<elmo> s/well/will/
<elmo> but yeah, I'll stop katie now
<fabbione> in the worst case around 60 pkgs
<fabbione> that's according to -changes
<chmj> oh my, this is a a worm, speading as buildd goes on 
<fabbione> doko: are you sure that the gcc build was affected?
<doko> yes, it was configured for the target 'i386-linux-gnu', which is not the hurd, but i386, not i486 ...
<fabbione> xorg -11 was affected
<fabbione> let's go back
<fabbione> well should we consider affected all packages that have been built with the new dpkg?
<fabbione> i think that would be a sage threshold
<elmo> we can grep the logs for the 'host architecture' line
<fabbione> i fount it
<fabbione> at least on i386 the last safe package is build-essential
<daniels> elmo: please kick xorg through as soon as dpkg is !fucked, it was uploaded about 10-15 minutes ago
<fabbione> already java-gcj-compat has the wrong host architecture
<daniels> i'll be down at dinner; my phone will get me
<fabbione> daniels: we will need to rebuild and reupload all the packages before that :/
<daniels> ok, well I need to eat :P
<daniels> but phoneable if you need.  will be back in ~30.
<fabbione> elmo: do you want to grep as well to be 100% sure?
<fabbione> and is it only i386 affected?
<elmo> hum?
<elmo> dpkg-buildpackage: source package is xorg
<elmo> dpkg-buildpackage: source version is 6.8.2-11
<elmo> dpkg-buildpackage: host architecture i386
<elmo> were you just grepping for 'hurd'?
<fabbione> elmo: no i was checking the version of dpkg used to build
<elmo> $ find . -newer d/dpkg/1.13.4/dpkg_1.13.4_20050517-1340-powerpc-successful.bz2 -type f | xargs bzgrep "host architecture hurd-" -l
<fabbione> i didn't grep.. i just manually checked
<elmo> ./g/glibc/2.3.5-1ubuntu1/glibc_2.3.5-1ubuntu1_20050518-0934-i386-failed.bz2
<elmo> ./j/java-gcj-compat/1.0.28-0.0ubuntu1/java-gcj-compat_1.0.28-0.0ubuntu1_20050518-0545-i386-successful.bz2
<elmo> is all I get
<fabbione> elmo: i think we need to consider the option that debian/rules might use the output of dpkg-arch to set build parameter
<fabbione> and you won't catch it from host archi
<Kamion> elmo: dpkg 1.13.4ubuntu1 uploaded, please let it through
<fabbione> packages might have been miscompiled 
<elmo> Kamion: does dpkg use dpkg-architecutre? :>
<elmo> fabbione: eh?
<elmo> fabbione: that host architecture hurd-<blah> is output from dpkg-buildpackage
<elmo> fabbione: if the chroot had the right version of dpkg-dev and gcc, it'd _always_ trigger?
<Kamion> haha
<Kamion> elmo: yes
<Kamion> elmo: this build will probably think it's cross-compiling
<fabbione> elmo: hmm point
<Kamion> since DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE in the Brave New Linux/Hurd World
<elmo> ok, so I have to downgrade chroots? :(
<Kamion> probably a good plan
<elmo> or, hum, build dpkg-dev on concordia and nstall it there
<elmo> s/there/from there/
<fabbione> amen
<fabbione> God just called that needs to know asap if we can include Oracle FS in our kernel
<Kamion> hmm, how does all this interact with daniels' complicated scheme with x-common for the X transition?
<fabbione> i am around if needed, but kinda busy
<fabbione> Kamion: that x doesn't build anymore?
<Kamion> at all, ever
<elmo> ok, building dpkg on vernadsky only (hopefully)
<daniels> Kamion: um, should be OK
<daniels> if not, I want someone to go to Birmingham and extract BLOOD
<doko> people tend to believe that all bugs during a toolchain transition can be blamed to the toolchain ;)
<doko> ok, prepared a 4.0 upload which only trusts dpkg-architecture for the cpu, elmo, let me know, when it's safe for an upload
<Kamion> doko: is that the right fix, long-term?
<Kamion> I mean where do you get the system type from?
<elmo> oh, christ
<elmo> buildd doesn't delete stuff from no_auto_build on a config reread
<doko> no, but as long as dpkg-architecture picks up the '-gnu' from gcc -dumpmachine, we need an intermediate solution
<\sh> hmmm
<elmo> doko: eh?
<Kamion> doko: the point of the builds elmo's doing is to fix that
<Kamion> I'd expect a no-change gcc-4.0 upload to be enough?
<doko> yes, but that doesn't help the current gcc in breezy.
<Kamion> if people are going to upgrade gcc-4.0, they could just as easily upgrade dpkg
<Kamion> er, dpkg-dev
<doko> no, the dpkg-architecture patch makes it a bit more correct, but still prints i386-linux-gnu instead of i386-linux
<Kamion> daniels: my point being, is the x-common etc. in the archive usable for building xorg against, despite the hurdishness?
<doko>   # overwrite ix86 CPU defaults
<doko>   ifeq ($(TARGET_ALIAS),i386-linux)
<doko>     TARGET_ALIAS := i486-linux
<doko>   endif
<Kamion> doko: oh, I thought that was desirable ... ok
<doko> so, we build for i386, not i486
<infinity> Kamion : The -gnu has never been there before, adding it would break any package that matches on that string.
<Kamion> k
<fabbione> Kamion: yes x-common in the archive is ok
<doko> but some time ago, rms requested it to have the -gnu suffix ...
<elmo> eh, I doubt it has anything to do with RMS
<elmo> and much more to do with making dpkg-architecture match what the auto* tools do
<elmo> the only binonly (or no-source-change) upload we'll need is java-gcj-compat I think
<doko> the mail I got was definitely from RMS, but anyway
<fabbione> and glibc
<doko> elmo: I'll reupload java-gcj-compat
<elmo> fabbione: no?
<elmo> it didn't suceed anywhere
<fabbione> elmo: ah right...
<elmo> doko: what's your mail got to do with Scott's motives for changing dpkg?
<fabbione> elmo: it's like. i didn't sleep shit in the last 36 hours :)
<elmo> doko: please upload your gcc
<elmo> I think we need that built and installed first
<doko> ok, I'll disable the testsuite, no code change
<elmo> eh, why disable the testsuite?
<doko> because I want to have something done today? that's two hours saved
<Kamion> elmo: you're talking at cross-purposes - there's the matter of what dpkg-architecture says, and there's the matter of what gcc -dumpmachine says; doko's talking about the latter I think
<doko> yes, I did mean gcc -dumpmachine
<elmo> doko: please don't disable the testsuites
<elmo> it's two hours of machine time not human time
<doko> hmm ...
<fabbione> i am off for a while
<fabbione> if there is something important i have my mobile phone with me
<doko> elmo: 4.0 uploaded
<elmo> ok, all 12 buildds using fixed dpkg-dev
<elmo> pushing gcc-4 through
<elmo> once that's built + installed, I'll re-enable katie
<doko> elmo: could you make sure, that configure runs for target <cpu>-linux, i486-linux on i386?
<doko> s/sure/check/
<doko> s/make//
<elmo> checking host system type... i486-pc-linux-gnu
<elmo> checking target system type... i486-pc-linux-gnu
<elmo> checking build system type... i486-pc-linux-gnu
<doko> thanks
<daniels> Kamion: x-common, x11proto-core-dev, xtrans-dev, and x-dev are arch: all
<Kamion> ah, ok
<daniels> i'm going to be afk for a while, got visitors
<daniels> but i'm phoneable
<elmo> gcc's just reached testing on i386
* jbailey phases back into reality.
<\sh> ah...infos concerning my juniper training
<jbailey> So, erm.  Is the theory that a broken dpkg is somehow keeping glibc from applying its patches? 
<elmo> don't know yet, but we'll find out in a bit
<jbailey> Oh good. =)  lamont /msg'd me about the failure just as I was turning off the monitors.  I got as far as "this built in 5 separate chroots, 2 of which were on Concordia.  wtf?" and then went to sleep. =)
<elmo> actually, no, that theory doesn't work
<elmo> oh, yes, it does, blah, ignore me
<fabbione> guys is there anything you need from me before i will go away?
<fabbione> (until tomorrow morning)
<elmo> doko: only x86 has been affected by this dpkg-dev thing, right?
<doko> no, Kamion did paste something about powerpc-linux-gnu here as well
<doko> Kamion: ^^^ ?
<elmo> yes, but no gcc was built with the broken gcc
<elmo> blah broken dpkg-dev
<lamont> moo
<doko> hi lamont, we did have some dpkg fun in the meantime
<elmo> doko: he's in here too
<elmo> and what's it matter?
<elmo> we're not overriding anything for powerpc are we?
<lamont> elmo: just forcing -pipe, if that's what you mean
<Kamion> yes, it was powerpc-linux-gnu
<elmo> lamont: no, I mean 386 vs 486 overriding
<lamont> ah, ok
<Kamion> and gcc-4.0 was definitely built on powerpc with the broken dpkg-dev
<elmo> eh?
<elmo> dpkg-buildpackage: host architecture powerpc
<elmo> ^-- from the build log?
<doko> dpkg-architecture prings powerpc-linux-gnu, not powerpc-linux
<Kamion> it wasn't built on powerpc with the broken dpkg-dev+gcc-4.0 combination
<elmo> meh, ok
<lamont> doko: make[2] : *** No rule to make target `current_symbols.txt', needed by `check-abi'.  Stop.
<lamont> or did you fix that between -ubuntu2 and -ubuntu5?
<elmo> bottom line: do we care about gcc-4.0 on !i386?
* fabbione goes offline
<elmo> AFAICS, there's no breakage, and so no?
<doko> lamont: ohh no ...
<doko> elmo: if a package uses this string to detect the architecture, then it is built different than before.
<elmo> doko: ?
<doko> ifeq ($(shell dpkg-architecture -q ...),powerpc-linux)
<doko> I don't know, if/how many packages do that
<doko> lamont: on which architecture do you see the error?
<lamont> hppa
<lamont> could it be from turning the tests off?
<elmo> doko: but that only applies if broken dpkg-dev+gcc-4 was installed right?
<doko> elmo: yes
<elmo> right, well, we know only one package was built like that
<elmo> gcj-java-compat
<elmo> so.  again, is there any other reason to not re-enable the buildds?
<doko> lamont: hmm, please put the log file somewhere
<doko> elmo: no, we can restart then
<elmo> lamont: have you just updated the chroots?
<lamont> 0215 DCT
<doko> gcc-4.0_4.0.0-7ubuntu6 is the current
<elmo> ok, i386 updated, katie cron jobs re-enabled
<elmo> lamont: caveat emptor: removing stuff from no_auto_build isn't sufficent, you need to kill and restart the buildd
<lamont> elmo: right.  note also that buildd-config is on hold, since it'll overwrite buildd.conf
<lamont> elmo: libs all got uploaded while I slept?
<elmo> lamont: no, I mean as, in, the buildd auto-config-rereading stuff DOESN'T WORK for removals
<lamont> doko: people.ubuntu.com/~lamont/gcc-4.0_4.0.0-7ubuntu2hppa1_20050517-1658.bz2
<lamont> ah, ok.
<doko> lamont: ok, I assume, you already did remove the build?
<lamont> doko: actually, it's mid-run on ubuntu5
<lamont> but it's almost done...
<lamont> otoh, I did say: touch chroot-breezy/build/buildd/gcc-4.0-4.0.0/src/libstdc++-v3/config/abi/hppa-linux-gnu/current_symbols.txt
<lamont> and no, that won't get uploaded to the archive elmo
<lamont> besides, it's out-of-date now
<doko> lamont: yes, should work
* lamont needs to deal with getting the kids out the door.  Back in about 30-40 minutes.
<doko> lamont: gcc-4.0-nocheck.diff on chinstrap
<\sh> can we update? ,-)
<jbailey> \sh: I think we're still in phear-the-apt mode. =)
<\sh> jbailey: and I'm thinking of writing a blog entry like: "Ubuntu made it. Transition from Debian-Linux to Debian-Hurd on the way, read more here" ,-)
<jbailey> \sh: I didn't feel quite brave enough at UDU to propose a Hubuntu bof.  Had one day of the conference fallen on *April* 1st, however... =)
<\sh> jbailey: hehe :) 
<doko> \sh: heh, attach the patches for ABI changes in bugzilla first ... ;-)
<\sh> doko: well...qssl is compiling just fine with your version of libqt ;) 
<\sh> i only was unsure if _hurd-i386 is quite right for a linux system ;)
<\sh> and in between the transition you should watch this movie: http://www.douglasadams.com/movie/
<Kamion> \sh: we all went to see that at the end of UDU
<\sh> Kamion: ah :) 
<\sh> Kamion: it's not showing here in the cinemas right now...i just watched a screener ;)
<doko> lamont: did you look at the libpng3 miscompilation?
<doko> I think, a recompile with 4.0 and -O2 would be worth a try
<lamont> doko: I built it, was going to pester elmo to cycle through a few debs in davis' chroot to see if I could reproduce the failure with any of the bits
<lamont> doko: fwiw, touching the file didn't fix things.
* lamont applies the patch
<doko> elmo, lamont: what's the state of archive now?
<elmo> waiting for you guys to do stuff?
<doko> so xorg is built/building?
<doko> glibc is requeued?
<lamont> doko: last I heard, we were waiting for xorg, followed by libraries.
* lamont checks on xorg
<elmo> I've given back glibc again
<elmo> for i386 first
<elmo> and same death
<lamont> xorg finished on amd64 (and is NEW, elmo)
<lamont> still building on the other 3
<doko> elmo: could you update the breezy32 chroot on concordia and install the glibc build-deps?
<elmo> it is not NEW
<lamont> no jbailey yet this morning?
<lamont> well, is byhand then...
<lamont> gah.
<lamont> that's -13, not -14.
<lamont> nm
<elmo> doing concordia breezy chroots
<lamont> -14 is packaging xorg debs
<doko> lamont, elmo: fix the buildd?, glibc patches fine on concordia
<elmo> doko: please don't be such a troll
<doko> elmo: I'll try ...
<elmo> Unpacking libstdc++6-dev (from .../libstdc++6-dev_3.4.3-13ubuntu4_amd64.deb) ...
<elmo> dpkg: error processing /var/cache/apt/archives/libstdc++6-dev_3.4.3-13ubuntu4_amd64.deb (--unpack):
<elmo>  trying to overwrite `/usr/share/doc/gcc-3.4-base/C++/README.libstdc++-baseline', which is also in package libstdc++6-0-dev
<elmo> doko: seriously, how is that a helpful comment?
<elmo> the buildd chroots aren't obviously broken since they've compiled all of breezy so far
<elmo> "it works for me - you suck" is stunningly unhelpful
<doko> elmo: that's amd64? yes, I fixed it.
<jbailey> lamont: I'm here.
<doko> elmo: no, I didn't say that, not did I mean it that way
<lamont> elmo: to be fair, there have been 1 or 2 issues with gcc -v not behaving the same as gcc -pipe -v... sucky command line parsing, and all that...
<lamont> clues on the glibc failure jbailey ?
* lamont tweaks a buildd to capture config.log
<lamont> etc
<jbailey> lamont: I can't reproduce on any of my boxes here, with LANG=C or anything. 
<elmo> and besides concordia isn't remotely representative of current breezy
<elmo> so your test is rather fatally flawed
<jbailey> lamont: It's noto even getting as far as config.log from what you pasted last night.  It's just failing during the patching.
<jbailey> lamont: I don't know what could cause that.  Maybe a skew in the version of patch?
<jbailey> But my boxes here are pretty current breezy.
<lamont> yeah
* lamont stops the buildd on terranova - someone distract elmo while I look at WTH is going on
<daniels> sorry, amnesiac went down for a while
<daniels> how are we looking?
<elmo> lamont: please wait till I upgrade concordia
<daniels> successful on amd64 \o/
<elmo> or rather till dselect finishes
<jbailey> lamont: If you can step inside the chroot, from a clean dpkg-source -x glibc*dsc, you should be able to run "debian/rules patch"
<daniels> dselect?  isn't that in universe?
<lamont> --- linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h  15 Oct 2003 04:40:10 -0000      1.1
<lamont> buildd@terranova:/build/buildd/glibc-2.3.5/build-tree/glibc-2.3.5$ find . -name malloc-machine.h
<lamont> ./nptl/sysdeps/pthread/malloc-machine.h
<lamont> ./sysdeps/generic/malloc-machine.h
<lamont> ./sysdeps/mach/hurd/malloc-machine.h
<lamont> interesting... but that's not clean either
<lamont> jbailey: what's the target to unpack the beast, but not patch?
<elmo> BZZT
<elmo> it failes on concordia/breezy now too
<elmo> as I said, lamont, please stop fucking around with the buildd chroots, there's nothing wrong with them
<jbailey> Lovely, lemme dive in.
<lamont> elmo: turning off purge=always and looking at the remains is benign.
<jbailey> lamont: debian/rules unpack, in case you ever need it again, btw.
<jbailey> dpkg-architecture: warning: Unknown gcc system type amd64-linux, falling back to default (native compilation)
<jbailey> -l looks like it's giving me the right answers, though.
<elmo> jbailey:'linux32 dchroot -c breezy-i386'
<elmo> patches to make dchroot auto do that, welcome
<jbailey> elmo: I'm in the amd64 one.  Is i386 a better choice right now?
<elmo> jbailey: oh, no, I just thought i saw you in i386 in ps
<elmo> sorry, don't mind me if you're not
<elmo> they're both uptodate, I reproduced the failure in i386
<doko> me too
<Kamion> daniels: dselect> not since I added it to the standard seed yesterday to stop it disappearing, it isn't
<elmo> Kamion: don't feed the troll; it wasn't going out of main as long as I had root on jackass in any event :-p
<Kamion> hah
<jbailey> err..  linuxthreads tarball isn't unpacking?
<jbailey> nor is libidn.
<jbailey> Output from dpkg-architecture -qDEB_HOST_GNU_SYSTEM changed.
<jbailey> =(
<jbailey> Is this permanent breakage?
<Kamion> believe so, it's now *-linux-gnu not *-linux
<lamont> is dpkg 1.13 feature
<Kamion> it's the main thing Keybuk flagged about 1.13
<jbailey> Ah, I must've missed the post on it.
<jbailey> So do I build-dep on the newer dpkg?
<elmo> either that or have the make magic handle either
<jbailey> Erm.  I wonder if I lose my accounts on the gnu systems if I s/linux-gnu/linux/... =)
<lamont> hehe
<lamont> you could s/linux$/linux-gnu/ instead...
<lamont> the gentoo users backporting your glibc to warty will appreciate it if the make magic handles both... :)
<lamont> s/users/refugees/
<Kamion> hmm, no dpkg build for powerpc or amd64 yet?
<elmo> it's in the exclude list
<elmo> dpkg-dev is arch: all, so does it matter?
<Kamion> true, hadn't thought of that
<doko> xorg did finish on i386 and powerpc
<doko> do we have to wait for it on sparc and hppa?
<lamont> I'm just glad this wasn't an hppa bug causing the glibc failure... :-)
<lamont> doko: no
<daniels> until the binaries are in the archive, no rest for the wicked
<lamont> about 30 minutes more on the xorg build for ia64, etc.
<daniels> oh, -14 binaries on the archive
<daniels> wicked sick
<daniels> s/on/in/
<lamont> daniels: I'm not wicked.  and I'm going to take a break in a very short while
<daniels> well, sort of.
<daniels> lamont: um, dude
<daniels> http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/
<daniels> libdmx-dev is there, but not xserer-xorg
<doko> maybe we have a chance to compile the libraries, before somebody uploads libtool or a new kernel ;)
<daniels> nothing past libxxf86dga-dev is there
<lamont> daniels: did you look in universe?
<elmo> daniels: err?
<elmo> if you mean -14, that's cos it's still syncing
<elmo> archive.u.c is still running on one machine which is hurting it badly
<daniels> xserver-xorg is not in universe
<daniels> elmo: thank fucking christ
<daniels> thanks
* daniels breathes.  deeply.
<lamont> daniels: good catholics would tell you He didn't do that...
<cartman> ha :)
<daniels> lamont: i'd smile and tell them we'd have to agree to disagree
<lamont> daniels: ditto
<daniels> and that's about all I'm going to say on the topic, because I still recall the last time I talked about Christian religious groups
<cartman> yeah transition is more important than religion 
* cartman hides
<jbailey> tested with old dpkg and new.  Any other last requests?
<daniels> ouch, ouch, goddamn ouch
<daniels> my fonts are fucked
<cartman> daniels: all X apps? ( because here Tcl apps got fscked after last tcl update )
<jbailey> pushed./
<daniels> cartman: nope, seems to be either just firefox, or freetype
<daniels> freetype doing strange things wouldn't surprise me in the least
<cartman> hmm I use freetype from cvs :/
<lamont> daniels: see the logs of #u-devel from early april, where milli was bitching about sid's fonts and what he had to do to fix them
<elmo> ok, what's holding up this #&%"* transition actually starting now?
<lamont> elmo: jbailey, I think...
<elmo> new glibc needs built?
<lamont> needs to be uploaded, at least.
<jbailey> I've uploaded it - it should only hold you up if you're counting on hppa participating, though.
<lamont> jbailey: hppa's still working on having a breezy gcc-4.0 :-(
<lamont> it is _so_ not participating yet.
<lamont> although it hopes to have a gcc-4.0 in about 2.5 hours
<elmo> ok.  anything else?
<elmo> doko?
<lamont> I think ia64 needs to stop building stuff and wait for xorg to hit the archive 
<lamont> ia64 is packaging
<doko> glibc? not necessarily
* lamont stops the sparc buildd
<lamont> right??  order (at this point) is: (1) make sure xorg -14 is in the archive, (2) build all the libs that doko uploads, (3) make sure they hit the archive, (4) unleash cxxapps.txt stuff
<lamont> right?
<doko> yes
<lamont> ok.
<doko> hope we finish tomorrow ...
<lamont> elmo, my life would be easier if we had one more cron.daily run in before doko's mass upload (in about 5 minutes time)
<lamont> ia64 is in dpkg-deb
<elmo> shout when
* lamont disappears to babysit the log
* lamont ponders, drags the xchat window to the other workspace
<lamont> fabbione: you're out and about, not here, correct?
<doko> daniels: libglu1-xorg-dev does not appear to be available
<daniels> doko: libglu-xorg-dev
<doko> xlibmesa-dev depends on libglu1-xorg-dev
<daniels> oh, fuck it all to hell
<lamont> doko: I don't think that needing -15 to happen really needs to hold up the cxxlibs upload
<daniels> doko: does this *need* to be fixed?
<lamont> that is, we have a good set of xlibs, and some build dep issues to fix.
<lamont> daniels: yes, it needs to be fixed.  But I don't think it needs to be fixed before doko's mass upload of libs
<doko> yes, I hope, the packages on it will just break to build
<lamont> it'll block sfuff
<lamont> doko: sure.
<daniels> go upload and I'll sort another xorg upload; I have more things to keep on doing, anyway
<lamont> doko: please wait before uploading
* lamont wants this cron.daily run.
<lamont> (at xserver-common)
<doko> anyway, the KDE people need it
<lamont> daniels: soon would be good, but not before I tell doko he can upload libs
<lamont> (the non-data-center architectures all have but single buildd's - which makes handholding them past xorg a bit less painful.)
<lamont> dpkg --info spewage.. almost there
<lamont> May 18 15:47:53 buildd-uploader: Setting to Uploaded(breezy): xorg 
<lamont> elmo: cron.daily after the next cron.hourly, if you please
<daniels> is 'about ten hours from now' an acceptable answer for xorg -15?
<daniels> it's now 0102, and I'm tired as hell
<daniels> you've got two minutes; speak now or forever hold your peace
<lamont> daniels: that depends entirely on how much stuff it blocks
<lamont> but worst case, I'll upload -14.1
<lamont> or maybe I'll call it -15. :0-)
<lamont> since it's literally just the Depends: change, yes?
<daniels> there's a couple of Depends changes to do
<daniels> just look for 'libglu'; it should be either libglu1-xorg, libglu1-dbg-xorg, or libglu-dev-xorg
<daniels> (if in doubt, check the Packages: line)
<lamont> (1) try to install all of the packages, and (2) fix the broken build-deps.  right?
<daniels> the B-Ds are fine
<lamont> s/build-//
* lamont is tired too
<daniels> tell you what.  i've got a couple of other things I'd like to do that I can do in about an hour if need be.  so if it's too much of a spanner in the works, call me and I'll be up.
<doko> hmm, can't you just make an upload with the fixed build-dep?
<lamont> s/build-//
<daniels> doko: um, I'd really rather not just for one line
<lamont> daniels: I'd really rather you did...
* daniels grumbles.
<lamont> this isn't debian.  we have cycles
<daniels> give me an hour or two
<lamont> daniels: meaning that you're already hip deep in some other changes?
<daniels> i'll send the mirror admins to you when they come lynching
<lamont> I'd rather have _JUST_ this fix.
<daniels> lamont: however did you guess?
<daniels> lamont: which would make it about six uploads in two days ...
<lamont> mind if I toss -14.1 into the fray?
<lamont> daniels: so we'll start calling you cam
<lamont> camm
<daniels> camm
<daniels> ?
<lamont> nm
<Kamion> camm maguire, maintainer of a bunch of maths packages in Debian
<doko> an what about the libglu stuff?
<lamont> he has big packages that he uploads 6 times in a day to debian...
<daniels> erk
<lamont> but he only does it about once every 6 months or so...
<daniels> well, I'll finish up the stuff I was working on now
<daniels> run it through another cycle, and have the fixed xlibmesa-dev deps up asap
<lamont> daniels: could I pretty please have an upload with _JUST_THE_DEPENDS_FIX???
<daniels> bear in mind that only stuff which B-Ds on xlibmesa-dev is affected
<lamont> right
<daniels> how many packages B-D on xlibmesa-dev?
<doko> that's about 25% of all uploads
<doko> KDE
<lamont> doko: in any case, you are go for library uploads as far as I'm concerned
<lamont> (with apologies to sparc)(
<doko> hmm, even qt b-deps on it
<doko> ok, then I'll go :-)
<doko> lamont: ok to go, jbailey, ready for FTBFS fixing? ;-)
<jbailey> More or less.
<doko> elmo: ok to go?
<doko> poor fabbione, but the sparc buildd is stopped ...
<jbailey> doko: From where do we get the list of ftbfs' and how do we avoid race conditions?
<doko> lamont's pages
<elmo> doko: sure?
<doko> elmo: what do you mean?
<daniels> a very dull -15 coming right up
<doko> elmo: what do you mean? that the sparc buildd is stopped?
<elmo> 16:12 < doko> elmo: ok to go?
<elmo> in response to that
<doko> uploading the library packages
<daniels> -15 uploaded, *grumble*
<lamont> doko: is gcc -7ubuntu6 needed for the library builds?
<lamont> jbailey: ditto for glibc
<lamont> ?
<jbailey> lamont: Nope.  It only exists to keep you happy with hppa.
<lamont> jbailey: sshhhh  don't say that...
<lamont> daniels: thank you
<daniels> i live to give
<lamont> daniels: now go to sleep and upload -16 in 10+hours. :-)
<jbailey> lamont: Err, I mean.  The Debian merge doesn't affect the C++ transition in any way.
<lamont> jbailey: LOL
<doko> lamont: I know of two C libs failing, which is fixed in -7ubuntu6, don't know of any C++ libs
<lamont> doko: but it's an FTBFS in any case, not a 'built but bogus' issue.   coolness. (ia64 is still building -7ubuntu6, you see..)
<doko> lamont: how long?
<lamont> doko: another hour or two.
<lamont> I don't mind the ftbfs, if it's really that...
<lamont> don't worry about ia64... I'll do that enough for all of us
<doko> heh, but -7ubuntu5 is there ...
<lamont> yeah
<doko> no code changes
<lamont> hence no worries
<lamont> oh, even better
<elmo> is someone going to upload a fix gcj-java-compat, btw?
<doko> just configured for ia64-linux-gnu, not oa64-linux
<doko> elmo: will do, but it's arch all
<lamont> elmo: doko's going to fix the package it depends on, iirc.
<lamont> but first he's uploading boatloads of libraries, I expect
<lamont> elmo: versioned depends on a package that is also Provided: elsewhere
<lamont> but you probably knew that
<doko> lamont: that should be fixed in gcc-4.0, not yet in gcc-3.x
<daniels> night.  phone next to bed and all that.
<doko> daniels: good night
<lamont> doko: libs all uploaded?
<doko> no, taking with the hppa build admin ;)
<lamont> I wanted to do that _after_ you uploaded libs...
<lamont> sigh
<lamont> doko: please ignore me and do the library uploads now
<doko> :)
<doko> lftp jackass:~> mput [a-z] *
<doko> 13168521 bytes transferred in 2 seconds (6.96M/s)
<doko> Total 170 files transferred
<doko> lftp jackass:/>
<lamont> yeah, kinda neat.  isn't it?
<Kamion> *thunk*
<lamont> hrm.. that's still less than 100mbps.
<lamont> of course, for larger uploads, you want to put the .changes files last...
<lamont> hrm.. sorts that way too
<Kamion> lamont: surely poppy shouldn't care
<elmo> lamont: no, doesn't matter with poppy
<lamont> elmo: awesom
<lamont> er
<lamont> awesome, evne.
<lamont> gah.
<lamont> elmo: some cron.daily love for us impatient types?
<doko> the ocaml reject is ok
<lamont> jbailey: do you wat to know that cdbs_0.4.28-1ubuntu2 is ftbfs
<lamont> because of bad Depends: in ocaml*
<lamont> (there is no gcc-3.4)
<doko> in main?
<lamont> doko: build-dep
<lamont> gcc-3.4 is not build-essential, and ocaml does not Depend: on it.
<lamont> but yet it executes gcc-3.4 explicitly
<doko> Build-Depends: gcc-3.4, debhelper (>> 4.0.2)
<jbailey> P'haps I'm confused.  You mean ocaml is ftbfs, or cdbs is because of this?
<lamont> jbailey: cdbs is ftbfs because ocaml lacks a Depends:
<doko> ahh, a Depends?
<lamont> doko: yes.
<jbailey> lamont: Thanks.  I think I'll avoid tossing ocaml into the build mess of the moment, but I'll note it for later.
<doko> fixing it
<lamont> jbailey: works for me
<lamont> anyone need anything before I go finish my beauty sleep?
<doko> lamont: does it really help?
* doko ducks
<lamont> doko: no.
<lamont> but it makes me _feel_ better.
<lamont> less cranky and all that
<doko> could go to bed as well ;-) ... who tells us about build failures?
<lamont> http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<doko> nice
<lamont> that's pushed by an rsync that happens every 20 minutes
<lamont> phones will ring if all hell breaks free
<doko> at 00/20/40?
<lamont> doko: yeah, but it runs for > 5-10 minutes...
<lamont> see ~lamont/buildLogs/Lists/Time for the time of the most recent run
<lamont> (part of the delay is that it dumps the entire wanna-build database for all architectures on breezy)
<jbailey> Is w-b still an underindexed db4 database?
<elmo> hahaha
<elmo> it's a gdbm database
<elmo> ENTIRELY UNINDEXED
<jbailey> Ah.  I had obviously blocked that out. =)
* lamont really wanders off for a nap
<doko> elmo: can we open the uploads for cxxlibs.txt for everyone, but not the Debian sync?
<Kamion> doko: hasn't there previously been a libdb3++?
<Kamion> i.e. before the last C++ transition?
<doko> yes, but we don't support upgrades from pre-sarge
<Kamion> just seems a bit needlessly fragile ...
<Kamion> i.e. aggressive non-support rather than passive non-support
<doko> hmm, that's what neuro proposed on #debian-release, and nobody complained about the updated proposal
<doko> we did rename all c102 packages back to their original name
<elmo> doko: done
<Kamion> ok ...
<elmo> doko: ugh
<elmo> that's hideous
<doko> DIFFS/aiksaurus.diff
<doko> DIFFS/aspell.diff
<doko> DIFFS/flac.diff
<doko> DIFFS/fltk1.1.diff
<doko> DIFFS/libsidplay1.patch
<doko> DIFFS/qt-x11-free.diff
<doko> DIFFS/sablotron.diff
<doko> DIFFS2/db3.diff
<doko> DIFFS2/fam.diff
<doko> DIFFS2/gtkmm2.0.diff
<doko> DIFFS2/icu.diff
<doko> DIFFS2/libsigc++-1.2.diff
<doko> DIFFS2/zipios++.diff
<doko> these are affected
<doko> hmm, I don't want to change the naming policy at this point. If we (or Debian) decide on a changed naming policy, then we'll have to rename them again. I'm sorry the plans for this hyperexpressway were shown at alpha centauri some time ago ...
<jbailey> Wow, 1pm.  I should go eat soon.
<jbailey> elmo: May I get the build-deps for directfb installed in the breezy (amd64) chroot on concordia, please?
<lamont> FTBFS: arts/ppc (sym vesions), libmusicbrainz (cast loses precision), smpeg (missing build-dep)
<lamont> so far, that is
<doko> ia64 buildd running?
<jbailey> lamont: Can you requeue glibc on amd64 please?
<doko> what do we gain from the xorg restructering besides changing build dependencies?
<lamont> elmo: where did gcc-4.0 -7ubuntu6 for ia64 go?
<lamont> jbailey: oh yeah.. that one got annoyed in if_addr, btw
<doko> daniels: libx11-dev is not contained in xlibs-dev?
<jbailey> lamont: Yeah, I saw.  That's random kernel suckage, not glibc sucks.  All it's doing is asking for an interface list and getting hung in the syscall.  All arch's show this behaviour sometimes.
<lamont> jbailey: given back
<jbailey> lamont: tx.
<lamont> doko: smaller packages
<lamont> and no huge bump to rebuild identical fonts each upload
<jbailey> I thought fonts were split out a while back?
<doko> not from the source 
<lamont> jbailey: you may be right.  dunno
<jbailey> source: xorg, weird.  I thought they had at least split the fonts out.  my bad.
<lamont> the biggest thing will be that little trivial fixes in one package don't require a 200MB bump of the archive
<lamont> jbailey: as of -10, they weren't.  as of -14, they appear to be.
<lamont> hoary shipped -10
<doko> jbailey: does cdbs1 know about amd64?
<jbailey> doko: Does cdbs1 know about archs in general?
<jbailey> doko: I think we defered to type-handling for that level of evilness.
<doko> dpkg-architecture: warning: Unknown system type amd64-linux
<jbailey> doko: dpkg appears to be broken, that's all.
<jbailey> doko: I see that without using cdbs.
<doko> let's upload binutils, nobody will notice the breakage, and if somebody notices it, we blame dpkg for it :)
<lamont> jbailey: no type-handling in ubuntu's cdbvs
<jbailey> doko: Sounds good.  Will you take a snapshot from the branch to get the ppc64 fixes?
<lamont> unless you'd rather move to universe....
<jbailey> lamont: Hey, I don't use type-handling for anything. =)
<lamont> FTBFS: aspell/amd64: can't stat /usr/share/locale
<jbailey> lamont: Although I wish that someone would come up with a better solution for the problem that it solves.
<lamont> jbailey: btw, you might want to verify that I didn't screw up the depends/build-depends for cdbs when I ripped type-handling out of it
<jbailey> lamont: skew between locales and glibc from the amd64 build failure?
<lamont> jbailey: aspell?  remotely possible
<jbailey> No build-dep on locales.
<jbailey> Probably just needs it added, I'll get it.
<lamont> amd64 in dpkg-builddeb for glibc, btw
<jbailey> lamont: Nice.  At some point I'll get annoyed enough to dive into the kernel to fix that.  But I might finish the Hurd first...
<minghua> Hi, I am wondering if there are any official words on Fortran packages
<minghua> I am working on the c++ transition of arpack++
<minghua> which is a c++ wrapper for arpack
<minghua> and arpack is a Fortran package
<minghua> the default fortran compiler is g77
<jbailey> Erm, no that's not right.  bash and dpkg provide /usr/share/locale as well, it can't be just a missing build-dep on that.
<minghua> but g77 is only in GCC 3.4, and GCC 4.0 has gfortran instead
<minghua> gfortran is a completely different code base
<jbailey> gfortran isn't completely backwards compatible to g77 yet, it's planned to be eventually.
<minghua> jbailey: yes I know that
<jbailey> AIUI, the gfortran testsuite is pretty complete, though, so you can generally expect it to work.
<minghua> my problem is, it seems g77 depends on gcc-3.4 and g++-3.4
<minghua> or libg2c0
<jbailey> g++-3.4 shares the 4.0 abi.
<minghua> anyway, when I do "apt-get build-dep arpack++" I got gcc-3.4, g++-3.4 and stuff
<minghua> jbailey: so are you suggesting to just use gcc-4.0 and g++-4.0?
<elmo> jbailey: done
<minghua> I haven't looked at the code yet
<jbailey> If you just use 'gcc' and 'g++', it should all work as normal.  gcc-4.0 and g++-4.0 will still be on the system as the defaults.
<minghua> but I think it uses gcc and g++, which will give 4.0 in breezy
<lamont> jbailey: debian/tmp/usr/share/locale...
<lamont> (sorry)
<jbailey> lamont: I'd flog you for it, but I change money for that sort of thing now...
<jbailey> elmo: Thanks
<lamont> hehe
<minghua> jbailey: okay thanks.  I think I'll just use 4.0 here, and see if anything breaks
<jbailey> minghua: Thanks.  Poke your head in here if it does.  We're all on weird schedules, so sorry if it takes us a bit to respond.
<doko> lamont, jbailey: debian/tmp/usr/share/locale is from aspell?
<lamont> doko: yres
* lamont hasn't looked at aspell at all, just the failure log
<doko> lamont: yes, I'm looking at it. hmm, interesting ...
<doko> lamont: is the ia64 buildd running?
<lamont> doko: still looking for gcc-4.0
<lamont> elmo: any chance that gcc-4.0/ia64 is NEW?
<elmo> no, it's in accepted
<elmo> unbreaking cron.daily ..
<lamont> ah, that would also explain it... :-(
* jbailey  puts on gloves for more directfb surgery.
<jbailey> This truly was broken in a different way on each arch.
<jbailey> Amazing.
<doko> directfb?
<jbailey> doko: Yeah.  It's one of the gcc4 breakages you gave me before.  I got an answer a little bit ago on how the syscall they use is supposed to work on ia64.
<lamont> jbailey: coolness
<lamont> btw, fonts came out in -11
<doko_> no new breakages, or are the buildds busy?
<lamont> no new breakages
<lamont> heh.  let me rephrase that.
<lamont> no new breakages in main/restricted. :-)
<doko_> the last log I see is for: glibc_2.3.5-1ubuntu2_20050518-1857-amd64-successful.bz2
<lamont> After installing, the following source dependencies are still unsatisfied:
<lamont> libicu21-dev(inst 2.1-2 ! >= wanted 2.1-2ubuntu1)
<lamont> from xerces26
<lamont> seems to be about the last one
<doko_> no, see http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<lamont> right
<lamont> ia64 starts building
<lamont> doko: is depwait tree from hell, it would appear.
<lamont> so it may just take extra cron.daily love and iterations
<lamont> vdk2_2.4.0-3ubuntu1 on ppc/amd64
<lamont> doko: the depwait chains have to make it through the cron.daily iterations, so time will tell.....
<elmo> all the NEW stuff is going to universe too, which is going to make things... fun
<lamont> elmo: NOOOOOOOOOOOOOoooooooooooooooo  :-(
<lamont> that sounds, um, fun. yeah.. that's the right word
<doko> elmo: can we speed up things in some way?
<lamont> elmo: Rejected: file 'libcwd0c2_0.99.39-1ubuntu2_powerpc.deb' has unknown component 'non-free'.
<lamont> Rejected: file 'libcwd0c2-dbg_0.99.39-1ubuntu2_powerpc.deb' has unknown component 'non-free'.
<elmo> meh
<elmo> crackwhoreness
<lamont> hehe
<elmo> how many other non-free packages are there?
<elmo> they'll all be like that
* lamont points at doko
<elmo> fixed libcwd anyway
<doko> elmo: that's the only one
<elmo> cool
<elmo> hmm, crap
<elmo> lamont: I just did a bunch of promotions which might cause unaccept spam, yell if it does
<lamont> ok
<lamont>  opencv_0.9.6-1ubuntu1
<lamont> amd64
<lamont> apyramids.cpp:189: error: cast from 'void*' to 'int' loses precision
<lamont> bad opencv
<lamont> tulip/amd64 same storry
<doko> hmm, I don't understand the db4.2 build failure yet
<lamont> bad build-deps????
<lamont> nfc
<lamont> was down-rev build-deps before, fwiw
<lamont> that is, -18ubuntu1 was dep-wait
<doko> yes, I fixed that
<lamont> ew.  smpeg is really SDL bug.
<lamont> In file included from gtv.c:14:
<lamont> /usr/include/SDL/SDL_syswm.h:56:22: error: X11/Xlib.h: No such file or directory
<lamont> missing Depends
<fabbione> re
<fabbione> lamont: did you stop the sparc buildd??
<doko> go sparc, go !
<lamont> fabbione: yes
<fabbione> why?
<lamont> well, it needs to have xorg built and in the archive before it starts building libraries.  also good to get gcc-4.0...-7ubuntu6 built first
<lamont> and then trider-g7 stopped talking to me...
<fabbione> right...
<fabbione> i was thinking to use it as a guine pig to see if the build-deps are correct
<fabbione> guinea even
<fabbione> hmm trider is having weird issues
<lamont> ISTR that doko didn't bother fixing the X depends to be versioned...
<doko> ?
<lamont> doko: for why we needed to have X built before we did lib building...
* lamont is perfectly willing to be wrong tough
<lamont> though
<fabbione> so ok.. xorg, gcc-4 and the rest
<doko> they have to be changed, versioned provides don't work. how should I know that x-dev packages get renamed?
<lamont> doko: wasn't blaming.  just explaining that "testing the build-deps" was probably a fruitless exercise...
<jbailey> aspell is gettext b0rkage, which in turn stopped building ages ago because they added java support to it and we don't have classpath in main.  Should I just disable the java bits for now and go back to it when we have java bits in main?
<doko> lamont, sorry, maybe I need a break ...
<lamont> doko: no, my bad.
<lamont> but you can have a break anyway. :-)
<lamont> "java is a mess"
<lamont> jbailey: personally, I'd drop java from gettext, and file a bug in the bts saying that we need to add it back once we have classpath in main
<fabbione> so ok.. xorg, gcc-4 and the rest?
<lamont> fabbione: yes
<fabbione> ok
<fabbione> what about dpkg?
<lamont> well, no cxxapps.txt packages
<jbailey> lamont: This seems to be a lovely example of what you were talking about though: http://people.ubuntulinux.org/~lamont/buildLogs/g/gettext/0.14.4-2/ =)
<fabbione> i still have the very old one working in the sparc chroot
<lamont> jbailey: yeah.
<lamont> exactly
<fabbione> lamont: yes, they are still hardencoded in buildd.conf
<lamont> fabbione: dpkg probably doesn't hurt, but it's more the DEB_*_ARCHITECTURE stuff that got tweaked from *-linux to *-linux-gnu
<lamont> so building dpkg early will enhance your experience.
<fabbione> lamont: yes  i know the story
<lamont> xorg, gcc-4.0, dpkg, and let 'er rip
<fabbione> i need to build x build-dep first
<fabbione> hmm no, they are just new versions
<lamont> jbailey: btw, any word on iptraf?
<jbailey> lamont: Sorry, had slipped my mind.  Grabbing it while this builds.
<fabbione> jbailey: do i need to rush to build the new glibc?
<fabbione> i have it all ccache so it would be fast anyway
<lamont> cp -p debian/README.libstdc++-baseline \
<lamont>         debian/libstdc++6-4.0-dev/usr/share/doc/gcc-4.0-base/C++/README.libstdc++-baseline
<lamont> cp: cannot stat `debian/README.libstdc++-baseline': No such file or directory
<lamont> make[1] : *** [stamps/08-binary-stamp-libstdcxx-dev]  Error 1
<lamont> make[1] : Leaving directory `/build/buildd/gcc-4.0-4.0.0'
<lamont> fabbione: glibc is unrelated to the transitiuon
<fabbione> ok
* lamont looks for tomotoes to lob in doko's direction
<fabbione> i guess i can build dpkg before xorg and gcc...
<fabbione> mainly because i can suffer 3 hours more or less for x
<fabbione> but clearly i am not going to stay aware 17 for gcc
<doko> debian/rules.d/binary-libstdcxx.mk: unmodified: line 318 
<lamont> doko: thanks
<doko> lamont: move the ifdef two lines up
<jbailey> fabbione: For locales stuff, probably.  Otherwise, there's no real magic in there for sparc.
<fabbione> yeah that's why 
<lamont>   x-common: PreDepends: xorg-common (= 6.8.2-10) but 6.8.2-14 is to be installed
* lamont screams
<fabbione> EH????
<fabbione> what package is that?
<fabbione> no i mean
<fabbione> wtf
<lamont> time to upload x-common? 1.0
<fabbione> why a versioned pre-depends?
<fabbione> we didn't add that
<fabbione> or at least I did NOT
<lamont>  Pre-Depends: xorg-common (= 6.8.2-10)
<lamont>  Package: x-common
<lamont>  Version: 0.99
<fabbione> BAH
<fabbione> lamont: the one i did local was not so binding
<fabbione> that's why my i386 didn't catch it
<fabbione> lamont: i think it is safe to upload 1.0 without that
<lamont> yes
<lamont> it is
<lamont> you wanna do that?
<lamont> or shall I?
<fabbione> go ahead
<lamont> (and where is the source repository for it if I do...)
<fabbione> just get it from the archive
<lamont> ok
<fabbione> 1.0 is 0.99 without the Pre-Depends
<lamont> drop the predepends entirely, right?
<fabbione> yes afaik
<fabbione> let me check on chinstrap
<fabbione> daniels left some pkgs there
<lamont> given the contents, I think we're safe
<fabbione> no changes... so yes
<fabbione> it's safe
<lamont> uploaded
<doko> fabbione: adding a build-dep to get X11/Xlib.h ... should that be libx11-dev ?
<lamont> +-Wl,xineplug_decode_mad.so -o .libs/xineplug_decode_mad.so
<lamont> /usr/bin/ld: cannot find -lmad
<lamont> xine-lib
<fabbione> doko: i am not 100% sure with the X transition going on
<fabbione> doko: you will need to check the new packages 
<doko> xine-lib: merge error, will fix
<fabbione> lamont: btw.. building dpkg on sparc is not the same mess as it happened at the DC
<fabbione> because sparc didn't even get closer to build the broken dpkg
<jbailey> lamont: in http://people.ubuntu.com/~lamont/buildLogs/i/iptraf/ - why is the dtime on the directory 11-may, when the contents of the files are late 2004?
<lamont> interesting how much 'fakeroot debian/rules binary-arch' rebuilds
<lamont> 11 may sounds about right for when I did the 'find . -type f | xargs bzip2'
<jbailey> Huh.  Surprising that bzip2 left the mtime alone on the files themselves.
<jbailey> thx.
<lamont> same as gzip does
<fabbione> lamont: confirmed that x-common 1.0 is safe once all the buildd have xorg-common -11 or higher
<fabbione> and given that it is arch: all
<fabbione> you are clearly green light
<lamont> fabbione: s/are/were/
<lamont> :-)
<fabbione> right :)
<fabbione> good
<fabbione> xorg is building on sparc
<fabbione> but i am pretty sure something is going to break
<lamont> fabbione: of course: it's X
<fabbione> i am more worried about the amount of sparc asm in it
<fabbione> than the real build system
<fabbione> i can cope with the build system easily
<fabbione> but not with asm :/
<fabbione> this evening i was at a neighbour meeting stuff
<fabbione> we might get fiber soon :)
<fabbione> up to 20Mb as MBR
<fabbione> and higher when the net is unloaded
<lamont> MBR?
<fabbione> Min. (guaranteed) Bit Rate
<lamont> kewlness
<fabbione> yup
<fabbione> i only need to convince 70 families in the neighbourood that they *REALLY* need fiber at home
<lamont> gcc-4.0_4.0.0-7ubuntu6hppa1_hppa.changes
<doko> lamont: :)
<fabbione> rocking!
<fabbione> go hppa!
<lamont> of course, I had to get out and push...
<lamont> but gcc-4.0_4.0.0-7ubuntu6hppa2 (and -7ubuntu7) will really build
<fabbione> ehehe
<fabbione> so when will you start uploading breezy to ports?
<lamont> fails 6.5 hours into the build
<lamont> already diud
<fabbione> and btw.. it's time you send me an ia64 and a hppa :)
<lamont> doxygen and lkh are there already
<fabbione> i told bdale but he bounced me to some local dk offices that are pretty useless
<lamont> I'll see what I can scrounge up for you next month
<fabbione> coolness :)
<fabbione> i am already using twice amount of energy of a normal 2 person dk family
<fabbione> but i can do better..
<fabbione> on the other side i used only 30% for the house heating
* lamont uses roughly 100KWH/day
<fabbione> i didn't check how much tbh
<fabbione> my wife gave me a briefing :)
<lamont> LOL
* lamont does the bills
<fabbione> nah my wife gets them.. i pay
<fabbione> and since i still pay with or withou details...
<lamont> hehe
* lamont builds dpkg, xorg
* lamont debates giggling or crying
<fabbione> uhuh???
<lamont> libsdl1.2 fails to build:   libarts1-dev: Depends: libqt3-mt-dev (>= 3.3.3) but it is not going to be installed
<lamont> i386, ppc, and maybe more
<fabbione> ahaha gotta love circular build-dep
<doko> elmo: libid3-3.8.3c2 needs main love
<lamont> is easy to fix though... just add the x build-dep to arts :-(
<fabbione> i guess i am going to watch some TV while X builds
<fabbione> looking at the log file growing isn't really that sexy
<doko> watching sexy tv instead? ;)
<fabbione> doko: xXx 2
<lamont> fabbione: someone beat me to x-common
* lamont back in a few
<fabbione> lamont: right
<fabbione> daniels did
<lamont> heh
<lamont> wfm
<lamont> anyway, back in a few
<fabbione> later
<jbailey> fabbione: The ia64 will possible double what you're using now.  I think it was mdz who estimated that his ia64 would cost him about $80 US a month to run.
<jbailey> fabbione: That's what data centres are for. =)
* lamont has somewhat cheaper power than mdz does
* jbailey imagines that lamont probably lives on an acre of solar cells.
<lamont> jbailey: nah
<lamont> 1-600           .0730
<lamont> 601-1100        .0690
<lamont> 1101-           .0650
<lamont> sadly, I'm around 2900-3200kwh/month
<lamont> wish there was a 4th tier.... :-)
<jbailey> I phear what mine is.  Right now it's included in my rent.
<lamont> much better that way
<jbailey> In the new place I have to cover it, as well as purchase fridge/stove/washer/dryer.
<jbailey> But the upshot is that I'll have multiple rooms!
<lamont> WOOHOO!!!
<lamont> computer room, and sleeping room? :-)
<jbailey> Someone looking at xerces yet?
<jbailey> lamont: A separate room for the kitchen even.
<jbailey> lamont: I'll have to buy my own clock, I won't be able to read it off the stove anymore.
<lamont> build-dep, istr
<lamont> hehehe
* lamont has finished building xorg-15's build-deps, now building xorg
<jbailey> On hppa?
<jbailey> Right, it's given-back.  I was sitting far enough back I couldn't see the difference between orange-on-white and red-on-white.
<doko> jbailey, xerces seems to build, missing deps on ia64
<lamont> jbailey: yes, on hppa.
<lamont> sorry about the orange vs red
<jbailey> np, now that I know to look for it, I can see it pretty clearly.
<doko> lamont, make it violent
<doko> s/n//
<jbailey> *g*
<lamont> basically, every 30 minutes, there's this few-minute window where everything gets given back. :-(
* lamont needs to run into town for a bit... anything before I disappear for 2-3 hours?
<jbailey> Not from me, I have stuff this evening, so I'll be signing off shortly.
<doko> hmm, no I'll go bed. I think, the new libs will be in main tomorrow without manual intervention?
<lamont> I think they'll be there by sometime tomorrow, possibly with some muppet-intervention...
<fabbione> jbailey: well my server now sucks aroun 700W
<fabbione> it has 2 PSU
<fabbione> and it's loaded
* lamont goes to town
<fabbione> so i guess it won't be too much of a difference
<fabbione> later lamont
<elmo> fabbione: you're up late
<fabbione> elmo: yeah
<fabbione> unfortunatly i crashed for 45 minutes this afternoon and now i am all awake :)
<jbailey> elmo: BTW, Do you generally want us to tell you when we're done with build-deps that you put in repo's for us, or do you just reap them from time to time?
<elmo> jbailey: nah, I like to leave the chroots fat
<jbailey> elmo: Cool, thx.
#ubuntu-toolchain 2005-05-26
<doko> elmo, any chance to move some more libs to main?
<elmo> doko: I've been doing them?
<elmo> as they come up
<elmo> any ones in particular?
<doko> id3lib3.8.3, needed for fltk
<elmo> did that a while ago
<doko> ok, thanks
<jbailey> back in a few hours.
* ..[topic/#ubuntu-toolchain:doko] : GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch, C++ ABI change: 33/55 library packages in the archives
<doko> ok, going to sleep
<doko> elmo, Kamion: could you move libgcj-dev to main, it's a (not yet) build-dep to db4.2. as an alternative, java-gcj-compat would be ok. at least we do need the Java support for OOo2.
<doko> good night
<fabbione> night doko
<doko> one more upload ....
* fabbione heads to bed too
<Kamion> doko: I think I probably technically have the ability to do it at the moment, but I'd rather leave universe->main promotion to elmo
<lamont-away> moo
<daniels> doko: libx11-dev is depended upon by xlibs-dev
<daniels> jbailey: fonts *were* split out a while back
<daniels> doko: the main thing we gain is that eventually we'll end up with lots of tiny packages, almost all of which never, ever change
<daniels> so uploads to X packages are really small and easy to do
<daniels> lamont: that's not a missing Depends on SDL, that's a missing -I/usr/X11R6/include, BTW
<minghua> Hi, a c++ transition question:  If a source package foo build libfoo1 and libfoo1-dev, I know I should rename libfoo1 to libfoo1c2, but do I need to rename libfoo1-dev to libfoo1c2-dev as well?
<minghua> I think not, since the API is not changed
<minghua> but just to make sure
<daniels> nope
<minghua> daniels: good to have confirmation, thanks
<lamont> daniels: woot
<lamont> r128_driver.c:98:29: extensions/dpms.h: No such file or directory
<lamont> make[8] : *** [r128_driver.o]  Error 1
* lamont grumbles at daniels
<lamont> make[8] : Entering directory `/build/buildd/xorg-6.8.2/build-tree/xc/programs/Xserver/hw/xfree86/drivers/ati'
<lamont> daniels: thoughts on making xorg compile on hppa?
* daniels grunts; that should be fixed already.
<lamont> that's in -156
<lamont> -15
<daniels> -16 will fix it
<lamont> thank you.  when will that be?
<lamont> or can I get a -15.1 from you?
<lamont> (doesn't need to be uploaded immediately, mind you...)
<daniels> -16 will be by the end of today
<daniels> more modularisation, merging from gravity
<daniels> the easy fix is to:
<daniels> fakeroot debian/rules clean setup
<daniels> cd build-tree/xc/programs/Xserver/hw/xfree86/drivers/ati
<daniels> cp r128_driver.c{,.orig}
<daniels> vim r128_driver.c
<daniels> %s/extensions\/dpms\.h/X11\/&/
<daniels> :wq
<daniels> cd ../../../../../../
<daniels> diff -urN xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c{.orig,} > ../debian/patches/999_lamont_special.diff
<daniels> cd ..
<daniels> debuild -us -uc -b
<lamont> woot
<lamont> heh.. missed one ../ :-)
<daniels> oops
<lamont> np
<fabbione> morning
<fabbione>  /usr/include/linux/pci.h:453: error: parse error before 'pci_power_t'
<fabbione> crap
<minghua> <minghua> Hi, I've got a problem for c++ transition of arpack++
<minghua> <minghua> In configure I get:
<minghua> <minghua> checking how to run the C preprocessor... /lib/cpp
<minghua> <minghua> configure: error: C preprocessor "/lib/cpp" fails sanity check
<minghua> <minghua> See `config.log' for more details.
<minghua> <minghua> make: *** [build]  Error 1
<minghua> <minghua> and /lib/cpp is a symlink to /usr/bin/cpp-4.0
<minghua> <minghua> nothing seems related in config.log, the last lines:
<minghua> <minghua> #ifdef __cplusplus
<minghua> <minghua> extern "C" void std::exit (int) throw (); using std::exit;
<minghua> <minghua> configure: exit 1
<minghua> I asked in #ubuntu-motu but got no reply.  Any insights here?
<fabbione> ops
<fabbione> ECHAN
<fabbione> ops
<fabbione> no
* lamont finds 1400x1050 to be a _strange_ resolution
<fabbione> jbailey: i really really need a good l-k-h
<lamont> nice, but strange
<fabbione> xorg is FTBFS on sparc
<lamont> r128_driver.c?
<fabbione> nope.. the above
<fabbione> l-k-h related
<fabbione> not sure if it will fail later
<lamont> hrm... I got 5.5MB into the logfile
<fabbione> 3.3 here
<fabbione> i think
<fabbione> 5656 -rw-r--r--  1 sparcbuildd sparcbuildd 5776501 May 19 01:50 xorg_6.8.2-15_20050518-2215
<fabbione> but what gets builded changes quite a lot between arches
<lamont> true
<daniels> sparc doesn't build r128 anyway
<daniels> i'm wondering why it wasn't ftbfs on i386, amd64 or powerpc, which all built r128
<fabbione> where is jbailey?
<lamont> given that it's about midnight his time....
<fabbione> and he is not here? *BAD*
* fabbione ponders hijacking l-k-h
<daniels> hijacking is bad, mmkay? :P
* lamont throws xorg back into the chompers
<lamont> xorg_6.8.2-15hppa1 building
<lamont> daniels: fix is already in -16-to-be, yes?
<daniels> mmm-hmm
<daniels> hm
<lamont> well, the last failure was 2 hours in...  I don't think I'm going to wait up for it
<daniels> sure
<daniels> night dude
<fabbione> night lamont
<lamont> didn't say I was going to bed...
<lamont> anything I can do to speed up graphics on a: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<lamont> ?
<daniels> you can try the stuff from r300.sf.net
<fabbione> binary drivers?
<daniels> or yeah, fglrx
<lamont> daniels: I'll bug you more tomorrow on setting that up then
<lamont> 0000:02:04.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
* lamont wonders which restricted-package he needs for firmware
<daniels> none for firmware
<daniels> just l-r-m-$(uname -r)
<lamont> right
<fabbione> where did you get this new toy? :)
<fabbione> where/when
<lamont> liberated an nc6000 from my new bos
<lamont> s
<daniels> nice
<lamont> so I can have it installed before I start work
<fabbione> oh i had one too
<fabbione> it was doing pretty well
<lamont> daniels: on the first boot, it had lots of tearing on the screen, as well as some echos.  restarting X made it all better
* lamont found that somewhat concerning
<daniels> um, cool
<daniels> odes this happen reproducibly?
<lamont> not since
<lamont> but changing the resolution from 1400x1050 to 1280x1024 didn't make it go away either.
<daniels> if you can reproduce it, let me know
<lamont> will do
<daniels> you *are* using hoary/breezy, right?
<lamont> hoary+security
<daniels> righto
<lamont> warty is like, OLD
<daniels> indeed
<daniels> sid is like, older
<daniels> (in terms of X)
<lamont> yeah
<lamont> ath0 doesn't find the accesspoint that my palm does.
<lamont> grumble
<daniels> you have brought the interface up, right?
<fabbione> uhuuhuh
<fabbione> configfs on /config type configfs (rw)
<fabbione> now i want you to guess what is that :)
<lamont> daniels: how absolutely strange.  I much prefer aironet cards... :)
<lamont> hrm.. /me has gmail invites
<fabbione> is gmail any good?
<lamont> dunno - don't use it.
<lamont> but I do have an account
<infinity> I think just about everyone (except fabbione, apparently) has an account and a mess of invites.
<lamont> yeah
<infinity> I check mine once every 2 or 3 months when someone reminds me about it.
* lamont just logged in for the first time in a few months
<lamont> feb 17 was last login
<lamont> You are currently using 0 MB (0%) of your 2207 MB.
<fabbione> infinity: well it's like i don't really need it? :)
<infinity> Where did you find the last login info?
<lamont> from my one and only mail message (the intro one)
<infinity> Ahh. :)
<lamont> haven't logged in since I created it, until tonight.
<lamont> at which point I deleted about 6 bounce messages
<infinity> My last read message is Feb 17th, so I'm assuming that's my last login.
<infinity> Creepy.
<lamont> all for spam that I didn't send
<infinity> And I have 50 invites.
* lamont considers inviting his cat
<minghua> lamont: so your cat has a email address already? ;-)
<infinity> Why wouldn't it?
<infinity> Cats need spam too.
<lamont> 'zactly
<infinity> lamont : So, when did/do you start back at HP?
<lamont> June 1
<infinity> Looking forward to it?
<lamont> yes
<infinity> You've been institutionalised, haven't you? :)
<lamont> not just because I'm getting paid to keep hacking on linux
<infinity> A year without an HP ID badge must have been hell.
<fabbione> ahaha
<lamont> infinity: it was the lack of health insurance that made it hell...
<lamont> but yeah.  I've been institutionalized
<infinity> Ahh, that too.
<infinity> I keep forgetting about the US and its lack of public health system.
<lamont> pisser is that someone stole lamont@hp.com from me
<infinity> You're kidding?
<infinity> I hope thye enjoy all the spam it gets.
<lamont> no.  there were 3 other lamont's at HP.
<lamont> one  of them took it... bastard.
<infinity> That was a pretty widely publicised email address.
<lamont> Results 1 - 10 of about 846 for lamont@hp.com. (0.32 seconds) 
<lamont> not bad for something a year stale
<lamont> well. anyway, time for bed I think.
<fabbione> cfdisk 
<fabbione> Segmentation fault
<fabbione> interesting :)
<infinity> lamont : 'Night.
<infinity> fabbione : I blame ncurses.
<fabbione> infinity: possibly
<fabbione> night lamont
<cartman> daniels: up for a small X-on-breezy question?
<daniels> the answer is 'don't' ;)
<daniels> what's up/
<daniels> ?
<cartman> :)
<cartman> daniels: as nvidia driver will look for /usr/X11R6 and X is going to /usr
<cartman> will be there symlinks?
<daniels> not for a while though
<cartman> from X11R6 to /usr ?
<daniels> yeah, when xorg all hits /usr, there will be symlinks
<daniels> but the server, Mesa, and drivers, will all be the last to go
<cartman> daniels: cool thanks
<daniels> since that's Tricky
<cartman> yeah :)
<cartman> I was worried :)
<daniels> it shouldn't be too painful, hopefluly
<daniels> gotta run now, though
<cartman> see you
<\sh> morning
<\sh> something new about dpkg?
<fabbione> what is wrong with dpkg?
<cartman> hmm X.org still compiled with old gcc ?
<cartman> libGLU still links to libstdc++.so.5 here
<doko> good morning all
<fabbione> hi doko
<cartman> morning
<doko> so the buildd's have stopped?
<fabbione> doko: hmm not that i know off
<fabbione> why?
<doko> on i386 the failed packages don't get a rebuild
<doko> flac, qt-x11-free, libsdl1.2, gtkmm2.4, ...
<fabbione> failed != dep-wait
<doko> there's nothing to dep-wait
<fabbione> dep-wait is kicked automatically
<fabbione> failed no
<doko> http://people.ubuntu.com/~lamont/buildLogs/g/gtkmm2.4/2.6.2-0ubuntu2/
<doko> ?
<doko> After installing, the following source dependencies are still unsatisfied:
<doko> libglibmm-2.4-dev(inst 2.6.1-0ubuntu1 ! >= wanted 2.6.1-0ubuntu2)
<doko> Source-dependencies not satisfied; skipping gtkmm2.4
<doko> but the dependency is already built
<fabbione> probably the chroot hasn't been updated
<doko> lamont, elmo: please could you check for the chroots, so that flac, qt-x11-free, libsdl1.2, gtkmm2.4 can be rebuilt?
<doko> elmo: some time for C++ ABI stuff (as long as lamont is not awake)?
<elmo> what stuff?
<doko> fail to see why db4.2 is failing to build, but all build-deps are in main ...
<doko> wvstreams (main) needs some stuff from the xplc package, which is still in universe
<fabbione> doko: can you confirm we can build the new dpkg?
<fabbione> and that it was in the list by miskate?
<fabbione> (at least i remember this way)
<doko> fabbione: I don't have any problems with it now. yes, I removed it from the list at chinstrap:~doko/cxxapps.txt
<fabbione> doko: thanks
<fabbione> elmo: we can push it :)
<doko> qt-x11-free isn't tried to build on two archs
<elmo> i386 buildds are turned off
<elmo> I don't know why - did lamont say anything in here?
* fabbione checks the irclogs
<doko> no, nothing
<doko> nothing in the logs
<fabbione> nope
<elmo> meh, timezones are just teh suck
<fabbione> humpf
<fabbione> i wonder if he just forgot to turn them on again
<fabbione> i guess we will have to wait a bit
<elmo> I'm going to have a shower, but once I'm back I'll have a look around, and if there's nothing obvious, turn one on again
<doko> :)
<fabbione> ok
<fabbione> i need food and i will be off soon today
<doko> take a cold shower ...
<jbailey> fabbione: Heya fabio - I still haven't seen a failure that shows that lkh is bad.  The failures you showed me were all other things...
<fabbione> jbailey: xorg :)
<jbailey> Got a build log? =)
<fabbione> usual place
<fabbione> needsreallove/xoef_6.8.2-15
<fabbione>  /usr/include/linux/pci.h:453: error: parse error before 'pci_power_t'
<jbailey> The imap server takes me almost 10 minutes to get connected to.  I tried arguing with the evo developers and they claim that they need to walk the entire tree in order to know the folder structure. =(
<cartman> am I correct that Xorg is still compiled with g++3.3 ?
<fabbione> cartman: no
<fabbione> it's builded with gcc-4
<fabbione> jbailey: you can ssh to vultus5
<cartman> fabbione: -15 still links to libstdc++.so.5 here
<cartman> fabbione: need -16 or something?
<fabbione> less logs/xorg_
<jbailey> Tx.
<fabbione> jbailey: imap and logs are strictly binded
<cartman> 6.8.2-15 here
<fabbione> i was working with elmo to get the logs on people
<jbailey> A failure in linux/ should affect all arch's.  I'm curious.
<fabbione> cartman: what is still linked to libstdc++.so.5?
<jbailey> Oh, probably a definition of __bitwise.
<cartman> [~] > ldd /usr/X11R6/lib/libGLU.so|grep stdc++
<cartman>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00002aaaab0ca000)
<cartman> fabbione: ^^
<jbailey> ssh: connect to host vultus5.fabbione.net port 22: Network is unreachable
<fabbione> jbailey: you need to bounce via trider-g7
<fabbione> or get ipv6 :)
<fabbione> cartman: check with daniels
<jbailey> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
<jbailey> joy
* jbailey eyes fabbione suspiciously...
<fabbione> cartman: also.. what version of libglu did you install?
<fabbione> jbailey: what ssh command are you trying to use?
<jbailey> ssh trider-g7.fabbione.net
<jbailey> I think that's what I did before...
<fabbione> hmm no
<fabbione> i did open a port for you to do that
<fabbione> that was bouncing to vultus5 in ipv4
<fabbione> that's why
<jbailey> Ah, non-standard port?  Gimme a sec.
<jbailey> Actually, FWIW I could probably just enable my ipv6 stuff again.
<fabbione> if you can tell me the port again, that would be nice
<fabbione> jbailey: well it needs to be routed too :)
<jbailey> Yes, dear. =)
<fabbione> jbailey: do you still have my mail with the port handy?
<jbailey> Somewhere.  Enabling by freenet6 daemon will be faster, though.  I just need to move the config from my belle's box to mine.
<fabbione> doesn't freenet6 provide a /64?
<jbailey> You can either get them to provide a network or a host endpoint.
<fabbione> jbailey: ok hold on a sec
<fabbione> jbailey: ssh trider-g7 -p 1000
<fabbione> that should redirect you to vultus5
<fabbione> modulo slowliness
<jbailey> And this isn't biting other arch's?  Only sparc? =(
<jbailey> Nothing about this line should be arch specific.
<fabbione> yeah only sparc
<jbailey> Is my breezy chroot still there?
<fabbione> jbailey: yes. it might need to be updated tho
<fabbione> or do you want me to recreate one for you?
<fabbione> (that's probably faster)
<jbailey> Please.
<fabbione> ok
<jbailey> At this point I'm at 2 or 3 seconds lag to a keystroke, so the least I have to type on this the better.
<fabbione> jbailey: yes i know
<fabbione> upload is the sux from here
<fabbione> hopefully within the next year we will get fibers
* fabbione is looking forward to 20Mb MBR
<jbailey> =)
<fabbione> it's almost there :)
<jbailey> My new appt will have better bandwidth too.  Right now if I upload, it cuts out the phone connection.
<fabbione> ok... gcc-4 is building on sparc now
<doko> jabailey: you want to make a gcc-4 upload today or tomorrow?
<doko> I did hear some rumors
<doko> elmo: just as a status, is the i386 buildd running?
<jbailey> doko: Well, you said that I could just upload a biarch-enabled gcc, I said that I would do it after the transition was done.  Originally that sounded like Friday. =)
<doko> jbailey, well, yes, provided we don't have dpkg, xorg, and other uploads. I'll put a new tarball on chinstrap tomorrow, so you can work from this one?
<Kamion> how come linux-kernel-headers got demoted from ship to supported in today's CD build? did something stop depending on it?
<jbailey> Right.  Nothing to interfere, just to make it so that I'm maintaining fewer glibc trees here. =)
<jbailey> Kamion: Err...
<jbailey> Kamion: Is libc6-dev usually in ship?
<Kamion> yes
<Kamion> build-essential is in ship
<Kamion> libc6-dev doesn't depend on l-k-h any more though
<jbailey> apt-cache rdepends on ppc seems to show it still.
<jbailey> What arch are you looking at?
<Kamion>  Version: 2.3.5-1ubuntu2
<Kamion>  Architecture: powerpc
<Kamion>  Depends: libc6 (= 2.3.5-1ubuntu2)
<Kamion> same on i386 and amd64
<Kamion> looking in the archive on rookery with dpkg -I
<jbailey> Ah, bugger, yeah I see it too.
<jbailey> Lemme troll the logs to see why the perl script didn't run. =(
<jbailey> Kamion: Thanks for the headsup
<Kamion> np
<jbailey> Oh, I know what it will be, probably.
<jbailey> More linux/linux-gnu mapping fallout from the dpkg change.
<Kamion> ah, yes
<Kamion> +if ($DEB_HOST_GNU_SYSTEM eq "linux") {
<Kamion> that?
<jbailey> Ayup
<jbailey> Well, no.
<jbailey> That's where I'm setting it to linux-gnu internally.
<jbailey> even if I get linux - older versions of dpkg will make us behave consistantly.
<lamont> morning
<jbailey> Err, sorry that looked like the debian/rules snippet for a sec.
* lamont curses , visits the buildd
<jbailey> Perhaps I'll eat breakfast before attempting to hack more.
<doko> lamont, action now! ;-)
<cartman> now gcc changed target to amd64-linux on amd64
<cartman> will this stop? :)
* lamont finds that 1 of the i386 buildd's was offline.  that's a far cry from "all"
<jbailey> Hmm.  m/^i386-linux$/ could just as easily be m/^i386-linux/ with probably no sideeffects, right?
<Kamion> jbailey: should imagine so ...
* lamont grumbles at daniels
<cartman> amd64-linux is final target for amd64 gcc? ( it was x86_64-linux then x86_64-linux-gnu and now amd64-linux )
<jbailey> From lwn: The usual fallback is to identify all the stakeholders and get them to say "yes Andrew, this code is cool and we can use it", but I don't think the clustering teams have sufficent act-togetherness to be able to do that.
<jbailey> Does this mean the clustering people are poorly clustered?
<cartman> jbailey: haha
<lamont> jbailey: most certainly
* lamont is going to take a few hours of downtime this morning
<lamont> starting shortly
<lamont> mostly because I'm going to fall over
<jbailey> lamont: Can I have a glibc build log from you for hppa?
<jbailey> Or could you make them generally appear with the others in ~lamont? =)
<lamont> dude - I gotta get X to build
<lamont> then I was going to build glibc
<jbailey> Ah?  okay.  I thought for some reason you had fired up glibc last night.
<lamont> and making sparc/hppa appear is on the list of things that we're trying to figure out
<lamont> no - I fired up X, and it's still FTBFS
<lamont> must flee - will be back on in about 75-90 min or so
<jbailey> lamont: Travel safely. =)
<lamont> jbailey: you want me to run glibc now, and X later?
<lamont> eep.
<lamont> had hoped it wasn't :45 yet
<doko> lamont: could we have a look at some packages?
<lamont> I'll start glibc and then xorg
<lamont> doko: ??
<doko> db4.2
<jbailey> lamont: It doesn't matter that much.  I just want to tell Carlos what the final failure set is.  We're going to hack on generic function descriptors after that to solve a couple more of them.
<doko> can't see why gcj-wrapper should fail
<jbailey> IT won't be today either way, though.
<lamont> jbailey: well, glibc will finish in good time this morning -gives the buildd something more to do, etc, etc.
<doko> lamont: qt-x11-free was not started on amd64 and ia64
<lamont> doko: I'll be back online once I drop kids at school, but just for a few
<jbailey> lamont: Actually, scratch that.
<lamont> doko: is it dep-wait?
<jbailey> lamont: Please do glibc first.
<lamont> jbailey: not stopping it now... (glibc _is_ first.)
* lamont must flee - 8 mminutes late now.
<jbailey> lamont: I will need to do another upload today anyway to fix the lkh dependancy, I may as well get any last fixes you need in case of build failure in there.
<doko> lamont: when are you back?
<doko> lamont: no
<doko> lamont: flac: needs rebuild on i386, amd64, powerpc
<jbailey> lamont: I think his morning dissapearance is usually about 90 minutes.
<jbailey> err. doko: ^^
<doko> jbailey: please could you have a look at http://www.openoffice.org/issues/show_bug.cgi?id=49374
<jbailey> doko: Crazy.  Is this actually affecting us as well?
<doko> _rene_ just told me
<jbailey> Right, but this bug report is for rpm.  If this were going to affect us, I would've expected other things using debhelper to puke.
<doko> jbailey: sysui is using rpm internally to prebuild the packages ;)
<doko> ooo does have a build dep on rpm ...
<jbailey> You've got to be kidding...
<elmo> lamont: no, they were all offline
<elmo> I brought them back
<elmo> or some of them
<doko> heh, flac finally built :)
<elmo> err, dude
<elmo> you are doing no-change uploads with something other than 'ubuntu' as the version string right?
<jbailey> doko: 2004-09-29 from drepper "Don't blindly trust readdir results; for symlinks or files of unknown type check using stat whether the file exists."
<doko> elmo: yes, they should be synced from Debian, if the next version is available.
<Kamion> he's been doing *buildN
<doko> and i asked: do we have a version schema to mark an -ubuntu version as syncable again, maybe -ubuntu1 -zapit1
<doko> hmm, -ubuntu1 -> -zapit1
<elmo> uh?
<elmo> why would you need that?
<Kamion> presumably for when you've reverted changes
<jbailey> "In order to have access to a pathname, glob() requires search permission on every component of a path except the last, and read permission on each directory of any filename component of pattern that contains any of the following special characters: '*', '?', and '['."
<doko> Kamion: exactly
<jbailey> I wonder if they interpret that as the symlink has to point to a valid filename - otherwise there's no read permission.
<doko> Unpacking libx11-6 (from .../libx11-6_6.8.2-15_i386.deb) ...
<doko> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process
<doko> dpkg: error processing /home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/libx11-6_6.8.2-15_i386.deb (--unpack):
<doko>  subprocess pre-installation script returned error exit status 1
<doko> Errors were encountered while processing:
<doko>  /home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/libx11-6_6.8.2-15_i386.deb
<doko> E: Sub-process /usr/bin/dpkg returned an error code (1)
<doko> lamont: ^^^ avifile build log, chmj is working on it
<elmo> kamion: I still don't get it, why would up upload a zapit1 rather than just having it synced?
<Kamion> elmo: because there's no new version in Debian yet
<Kamion> doko: er, debconf db being locked doesn't sound like a package bug?
<doko> Kamion: no, I assume the buildd, but I don't want look like trolling around ;)
<elmo> right, but that forces a rebuild which is wasteful for the archive ,mirrors, users and buildd?
<Kamion> it does force a rebuild later, but you might need to revert the changes now
<Kamion> and you can't sync because that would be going backwards in versions
<Kamion> it doesn't happen often and I don't know why doko needs it now; I have needed something like that once or twice
<elmo> well, in that case anything > ubuntu and !~ ubuntu will do, but I'd definitely perfer it is only used for that rare case when you have to revert the changes immediately
<doko> elmo: sure, it's less common than -buildN
<Kamion> (in my case I'm usually in a position where I can find some reasonably good reason to upload to Debian ...)
<lamont_r> hrm.. this chan isn't in the laptop's default list
<doko> lamont: please could you check the build state of qt-x11-free on amd64 and ia64?
<lamont_r> ok
<lamont_r> doko: was depwait on a virtual package.
* lamont_r grumbles.  fixed
<doko> which one?
<lamont_r> libmysqlclient-dev
<doko> ahh, ok
* lamont_r points at p.u.c/~lamont/buildLogs/Lists/breezy.all.amd64
* lamont_r needs to get out of here by about :10, fwiw
<jbailey> lamont_r: This is up to date? =(
<lamont_r> and then I expect to be offline for a few hours... I need to sleep
<lamont_r> jbailey: never.
<lamont_r> :-)
<doko> hmm, that's no fun ...
<lamont_r> doko: figured I'd warn you.
<jbailey> Right.  That explains why it claims glibc is out of date. =)
<lamont_r> jbailey: it shouldn't be more than about 20 minutes out of date
<doko> please let's get qt, arts, and kdelibs in shape. that's the major blocker in main :(
<lamont_r> what does the full line for glibc say>?
<jbailey> libs/glibc_2.3.5-1ubuntu2: Installed by buildd+king [required:out-of-date] 
<lamont_r> doko: and a circular depwait from hell.
<jbailey> However,
<jbailey> glibc_2.3.5-1ubuntu2_20050518-1857-amd64-successful.bz2   18-May-2005 19:13  294K  
<lamont_r> jbailey: 2.3.5-1ubuntu2 is installed, was previously out-of-date
<lamont_r> vs 'uncompiled'
<jbailey> In the []  is previous state?
<lamont_r> () is priority and previous-state-indicator
<lamont_r> prev state == 'out-of-date' or 'uncompiled' (or 'partial', but you'll never see that
<lamont_r> so it's not truely previous state.  (since that would - boringly - be 'Uploaded' for all the installed stuff...)
<lamont_r> it's quinn-diff state, not w-b state
<jbailey> Right.
<lamont_r> doko: the process for arts et al is to upload a new arts that does what it needs to in order to survive the xorg changes of late.  Then fix and upload sdl to actually do the right thing.  then upload a clean arts next week
<lamont_r> (sdl is including an X header incorrectly... however, sdl is d-w arts.
<doko> lamont_ok: r
<lamont_r> anything more before I run away for a while?
<jbailey> fabbione: This is cute.  It's a section of code that may only be run on Sparc.  It includes <sys/kd.h> to get some headers, which forces it to not include linux/types.h.  It then includes linux/pci.h.  As of 2.6.9 or so, linux/pci.h now requires a defintion from linux/types.h in order to compile.
<doko> lamont_r: maybe db4.2?
<doko> gtkmm2.4?
<lamont_r> doko: I'll focus on those once I'm back online and figure them out.
* lamont_r needs to run
<doko> fine, I'm away then
<fabbione> jbailey: told you that it was l-k-h :P
<jbailey> Right, but it's a problem in the upstream kernel headers too.
<fabbione> jbailey: can we get it fixed in the meanwhile?
<jbailey> fabbione: Yes.  I haven't decided the right way to fix it.
<jbailey> fabbione: I see why they do it - inclusion of sys/kd.h shouldn't bring in a pile of kernel symbols.
<jbailey> I guess the simplest is to remove the __bitwise stuff from lkh
<fabbione> ok :)
<fabbione> do you think you can manage to get it fixed today?
<fabbione> or within the next 12 hours?
<fabbione> so that tomorrow i can build X and unleash sparc on the libs?
<jbailey> I'll try for in the next 12 minutes.
<fabbione> ehhe cool, i don't need it THAT soon
<fabbione> i am building gcc and it i will take another 10/12 hours
<fabbione> but that would be rocking hard!
<fabbione> i need to go to help my wife for some gardening stuff
<jbailey> Do you have anything else handy that you suspect is an lkh failure?
<fabbione> hmmm nope...
<jbailey> I like that answer. =)
<fabbione> but i mean, it's a package that can be uploaded without breaking the world
<fabbione> if something shows up we can always attack it later
<jbailey> YEs, sure.
<fabbione> + after the transition i want to clean up the logs and kick-back all of the unbuilt 
<fabbione> and see what happens
<jbailey> You've just mentioned a few times that you've thought you had various lkh failures, and I'm pleased that so far this is the only one that is actually an lkh failure. =)
<fabbione> there is one that probably is glibc
<fabbione> util-linux
<fabbione> but i will need to check with the new ones
<fabbione> let's do it after the c++ transition
<fabbione> or during
<fabbione> right now i need to kill the gcc/x queue because it's the slowest one to get rid of
<jbailey> fabbione: I'll be tossing another glibc on top of that in a moment, too.
<daniels> cartman: do you have libglu1-xorg, or xlibmesa-glu?
<fabbione> oh ok
<jbailey> Hmm
<fabbione> me must go
* jbailey wonders if he can loosen the locales dependancy a bit before this upload
<fabbione> cya later
<fabbione> jbailey: thanks again
<jbailey> 'bye Fabio
<cartman> daniels: lemme see
<cartman> daniels: xlibmesa-glu and xlibmesa-glu-dev
<cartman> daniels: dist-upgrade didn't handle well?
<daniels> cartman: you just need to wait for stuff to depend on libglu1-xorg
<daniels> which it will when it gets built with it
<cartman> daniels: ok
<cartman> daniels: uhm also xkb stuff gone mad
<cartman> daniels: open xev press Esc,1,2,3 etc and all those keys show as "noname"
<daniels> awesome
<daniels> probably /etc/X11 vs /usr/lib/X11 insanity
<cartman> possibly yep
<daniels> try sudo ln -s /usr/X11R6/lib/X11/xkb /usr/lib/X11/xkb
<cartman> still same
<daniels> even after restarting?
<cartman> restarting X?
<cartman> I did a : setxkbmap -model a4techKB21 -layout tr -variant basic from konsole
<cartman> should I restart X?
<daniels> what does ls /usr/lib/X11/xkb/, show you?
<cartman> [~] > ls /usr/lib/X11/xkb/
<cartman> compat      compiled  geometry.dir  keycodes.dir  keymap.dir  README.config     rules      symbols      types      xkbcomp
<cartman> compat.dir  geometry  keycodes      keymap        README      README.enhancing  semantics  symbols.dir  types.dir
<daniels> weird
<daniels> try restarting X, yeah
<cartman> ok brb
<cartman> daniels: still same :/
<daniels> there should be an instructive error message ta the bottom of Xorg.0.log
<cartman> nothing interesting
<cartman> http://rafb.net/paste/results/ggO8LX43.html
* jbailey wanders away for food and to turn his brain off for a bit.
<daniels> hrm
<daniels> cartman: no idea, sorry; will look at it in the morning
<daniels> hm and that same command works for me
<daniels> nsert a comma where that  s
<daniels> and  have werd s as well
<daniels> much better
<daniels> (and all in iso-8859-1, thanks to irssi's newfound stupidity)
<daniels> night all
<cartman> daniels: internet keys work and night
<Kamion> doesn't look like ISO-8859-1 to me, it's something new and spethul
<doko> jbailey: could you have a look at the arts build failure on powerpc, I'm away for the rest of the day
<fabbione> doko: ???
<fabbione> gnatbind -C -I- -I. -Iada -I../../src/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali
<fabbione> fatal error: file gnat1drv.ali is incorrectly formatted
<fabbione> this is the latest gcc on sparc
<fabbione> yeah i understand that
<fabbione> ops
<fabbione> doko: i am kicking it back
<fabbione> but hell.. this sucks hard
<\sh> hmm...how can I be sure, that debuild or pbuilder is using the right g++? is g++4 set as default?
<Kamion> readlink -f `which g++`
<\sh> thx
<jbailey> doko: No prob. =)
<\sh> doko: ping
<\sh> doko: kdelibs4c2 is available from your repos?
* lamont_r eats lunch, ponders buildds
<lamont_r> jbailey: ping
* \sh needs kdelibs4c2 ;) but i will compile it by myself now with dokos patches
<jbailey> lamont_r: Pong!
<lamont_r> how are we looking
* jbailey flexes for LaMont
<lamont_r> bogus perms issues in my hppa buildd -> glibc relaunched
<lamont_r> :-(
<jbailey> Oh feh. =(
<lamont_r> anybody bludgeoned arts into submission yet?
<jbailey> I haven't, I'm mostly just sitting back down to the 'puter.
<lamont_r> you want it, or is it mine?
<lamont_r> arts, db4.2, gtkmm*
<lamont_r> pick 2 - you're that good
<jbailey> Nah, I'll take it.  I want to think about glibc for a moment longer before uploading.
<jbailey> arts and db4.2 then. =)
<lamont_r> heh
* lamont_r looks at gtkmm*
<jbailey> I'm trying to make sure that I don't miss anything before I loosen the dependancy on locales to just the most recent cvs bump.
* lamont_r prepares to cheer
<jbailey> lamont_r: What at?
<lamont_r> locales dep
<jbailey> Oy.  the aspell library change is going to suck.
<lamont_r> glibc actually compiling this time.
<jbailey> w00t!
<jbailey> lamont: What speed is your box?
<lamont_r> and xorg_6.8.2-15hppa2 built
<lamont_r> A500/550 (running UP)
<lamont_r> glibc:                  02:04:13 (19 entries, sigma 00:42:29)
<lamont_r> Build needed 01:58:14, 500772k disk space
<lamont_r> more significantly, ^^
<jbailey> I wonder how ccached that was.
<lamont_r> it was pretty ccached.
<lamont_r> and still is
<lamont_r> or should be
<jbailey> Oh right, because you did the test build.
<lamont_r> yeah.  that was -0ubuntu3pre4
<jbailey> I was thinking first build since 2.3.2.ds1
<lamont_r> -rw-r--r--  1 buildd buildd   459880 May 16 18:17 logs/glibc_2.3.5-0ubuntu3_20050516-1815
<lamont_r> -rw-r--r--  1 buildd buildd      501 May 17 06:13 logs/glibc_2.3.5-0ubuntu3_20050517-0613
<lamont_r> -rw-r--r--  1 buildd buildd   582942 May 17 14:15 logs/glibc_2.3.5-0ubuntu3_20050517-1411
<lamont_r> -rw-r--r--  1 buildd buildd 13004123 May 17 16:25 logs/glibc_2.3.5-0ubuntu3pre4_20050517-1426
<lamont_r> -rw-r--r--  1 buildd buildd      989 May 19 06:51 logs/glibc_2.3.5-1ubuntu2_20050519-0651
<lamont_r> -rw-r--r--  1 buildd buildd  5788977 May 19 12:38 logs/glibc_2.3.5-1ubuntu2_20050519-1220
<lamont_r> ops... spamage. sorry
<jbailey> All good.  This is a flood-friendly channel.
<lamont_r> so, once you get arts to build, let me know...that'll free up libsdl1.2 a couple places...
<jbailey> Won't wb hand it from a depwait state?
<lamont_r> it's not depwaited
<lamont_r>   libarts1-dev: Depends: libarts1 (= 1.4.0-0pre1ubuntu3) but it is not going to be installed
<lamont_r> I could _put_ it in depwait, but I'm lazy
<jbailey> Right.
<jbailey> Why put off until tomorrow what can be put off until the day after?
<lamont_r> days are short, and all that.. :)
<jbailey> Hey - did we ever put in the "-x c" hack into the buildds?
<lamont_r> not yet.  can I do it as one arg?
<lamont_r> that is, '-xc' vs '-x c'?
<jbailey> Dunno, I'll test it in a sec.
<lamont_r> gcc-opt wouldn't really like it to be 2 args
<jbailey> Yes, dear.
<lamont_r> you stud you
* jbailey flexes for LaMont
<jbailey> I may need heavier narcotics for this.  arts is compiled with g++ -shared -nostdlib -lstdc++ -lm -lc -lgcc_s and all the various crtFOO*
* lamont_r is really glad you took arts....
* lamont_r plays with db4.2
<lamont_r> gtkmm* seem to just be a matter of throwing things against the fan
<lamont_r> configure:20937: result: .so
<lamont_r> configure:21107: checking if gcj-wrapper works
<lamont_r> configure:21121: gcj-wrapper  Test.java
<lamont_r> ../dist/configure: line 21122: gcj-wrapper: command not found
<lamont_r> configure:21124: $? = 127
<lamont_r> configure:21128: error: The Java compiler gcj-wrapper failed (see config.log, ch
<lamont_r> so who's missing the *Depend?
<lamont_r> db4.2
<jbailey> lamont: Is gcj in main?
<lamont_r> 9.7M of 13
<jbailey> I didn't think it had been promoted yet.
<lamont_r> hrm... should be
<lamont_r> that could be the issue there then
<jbailey> Nope, it is.
<lamont_r> but it should be failing for want of dependency, not just trying to build
<lamont_r> run-iconv-test.sh is running, should you care
<jbailey> Angie thinks that UDU might have been bad for my health, apparently when I swear at the computer, I've started doing it in a Brit. accent.
<lamont_r> LOL
<jbailey> Probably too much time in the vibe out room sitting next to james and scott.
<lamont_r> brit? or 'stralian?
<lamont_r> hrm... done in town, I'm going to head home, I think
<jbailey> Nah, we didn't leave the hotel enough to pick up an Aussie one.
<jbailey> TTU in 45 or so?
<lamont_r> if you don't need anything in the next minute or so, I'm gonna vanish for about 20
<lamont_r> about 20 minutes - this coffee shop is on the north end of town
<lamont_r> more properly about 25
<jbailey> Coo.
<lamont_r> of course, that's 25 min _after_ I really leave... :-
<lamont_r> )
<lamont_r> later
<jbailey> Heya Matthias.
<lamont> hrm... how was that timing
<lamont> jbailey: 12/13 MBN
<lamont> s/N$//
<jbailey> lamont: Excellent timing.  About 40 minutes from when I said 45. =)
* lamont would have been more accurate if he'd remembered that he had to go purchase petrol.
<lamont> you play with db4.2 yet, or shall I test my theory?
<jbailey> No, I've figured out that this symbol only looks like it should be part of the standard library set.  It isn't really.
<lamont> uh.. .no you're messing with db4.2, or no, I should?
<jbailey> No, I'm still on arts.
<lamont> ah, right.
<\sh> grmpf
<lamont> I think this means I owe you a beer or something
<\sh> kvirc has shlibs attached...do i have to rename it or not? 
<jbailey> Oh ew...
<jbailey> Rather than including all of the files in the Makefile, they've #include'd all the .cc's into one file.
<jbailey> Then compiled *that* into a helper libtool library.
<lamont> hehehehehe heh heh huh.
<lamont> db4.2 uploaded
<amu> cool
<lamont> checking whether we are using the GNU Fortran 77 compiler... no
<lamont> checking whether  accepts -g... no
<lamont> hrm....
<amu> ... a blocker for kdelibs
<jbailey> Hey, it's accurate.
<lamont> jbailey: heh
* lamont tries to remember if he needed to build anything after xorg/dpkg/gcc-4.0/glibc before he unleashed the world
<lamont> (hppa buildd, that is)
<jbailey> I think anything else was a preq of one of those.
<jbailey> Got a build log for me? =)
<lamont> I would if your tests would finish
<lamont> buildd   16629  0.2  0.0   6452  4528 ?        SN   13:22   0:09                          |       \_ /usr/bin/make -C elf tests
<lamont> buildd   18799  0.0  0.0   2876  1276 ?        SN   13:24   0:00                          |           \_ /bin/sh -c GCONV_PATH=/build/buildd/glibc-2.3.5/build-tree/hppa-libc/iconvdata LC_ALL=C   /build/buildd/glibc-2.3.5/build-tree/hppa-libc/elf/ld.so.1 -
<lamont> buildd   18800  0.0  0.0   2788   628 ?        RN   13:24   0:00                          |               \_ /build/buildd/glibc-2.3.5/build-tree/hppa-libc/elf/ld.so.1 --library-path /build/buildd/glibc-2.3.5/build-tree/hppa-libc:/build/buildd/glibc-2.3.5
<lamont> buildd   23116  0.0  0.0   1736   536 ?        SN   12:54   0:00                          \_ tee -a /build/buildd/glibc-2.3.5/log-test-hppa-linux-gnu-libc
<lamont> ew.  that's ugly.  sorry
<jbailey> It's not stuck mid sort is it?
<lamont> well, time is currently 14:16, so it could be
<lamont> I suppose I could kill the test...
<jbailey> That mighit be the same thing I saw on bdale's machine then. =(  Carlos had me up the test timeout.
<lamont> to how long?
<jbailey> But after that I didn't see it kill the test at all, nor did I see it finish.
<lamont> > 150 minutes???
<jbailey> 20 secds.
<lamont> ah, so I should kill the test?
<jbailey> pinging carlos first. =)
<lamont> client.cc: In member function 'GSList* Gnome::Conf::Client::get_list(const Glib::ustring&, GConfValueType) const':
<lamont> client.cc:237: error: cast from 'void*' to 'int' loses precision
<lamont> client.cc:240: error: cast from 'void*' to 'gboolean' loses precision
<lamont> bad gconfmm
<lamont> gconfmm2.6, even
* lamont launches the hppa buildd
<lamont> May 19 14:44:21 buildd: breezy: total 523 packages to build.
<lamont> (ok, so it's a partial mirror)
<jbailey> Anyone happen to know the C++ name mangling is consistant across all arch's or if it's arch specific?
* lamont needs to go fetch kids
<amu> jbailey: do you still work on arts? 
<jbailey> amu: Yes.
<jbailey> amu: The code path appears to be the same between ia64 (success) and ppc (fail)
<jbailey> Looking through there doesn't seem to be anything wrong with the headers or whatnot, so next I want to double check the symbols in libstdc++
<cartman> arts is hall of shame for c++ :/
<amu> Riddell pointed me before to this: http://lists.kde.org/?l=kde-devel&m=110642979722873&w=2
<lamont> back in a bit over an hour
<jbailey> arts is certainly... interestingly written.
<Riddell> it's because arts was done without qt or glib to keep everyone happy, and ended up pleasing nobody
<jbailey> I'm getting undefined references rather than shared library errors.
<jbailey> It's in the libtool convenience libraries.
<jbailey> Riddell: Does glib have C++ helpers?
<jbailey> I always thought of it as the STL without type safety.
* jbailey needs to wander away a bit to clear his head.
<Riddell> no glib is C only I'm pretty sure
#ubuntu-toolchain 2005-05-27
<jbailey> Riddell: You around for a moment or two?
<Riddell> jbailey: yes
<jbailey> Riddell: I've discovered that a newer snapshot of arts doesn't fail.  How ugly is it if I just update it?
<Riddell> jbailey: from svn?
<jbailey> From ftp.kde.org, but it was in the unstable directory.  I can slowly work back and converge, or cherry pick a patch out if that's a better idea.
<Riddell> jbailey: well it's not a problem at all, there will be a new KDE point release in a week anyway
<\sh> 3.4.1?
<jbailey> Riddell: This package doesn't appear to have a ChangeLog, so I don't have any hints as to how far apart they are in development.
<Riddell> \sh: yes
<\sh> Riddell: nice
<Riddell> jbailey: arts isn't really maintained
<Riddell> jbailey: from daily snapshots?  ftp.kde.org/pub/kde/unstable/snapshots 
<Riddell> jbailey: it would be better to get it from 3.4 brach if that works
<Riddell> branch
<jbailey> Right, that's where it was from.
<jbailey> 'k, I'll look at that too then.
<Riddell> jbailey: http://dev.kubuntu.org.uk/~jr/kubuntu/arts-svn20050519.tar.bz2
<Riddell> that's from kde 3.4 branch
<Riddell> but if it doesn't work just use a snapshot from head
<jbailey> Makefile.am.in?
<jbailey> What's the right tool to generate a build env out of that?
<\sh> Makefile.cvs?
<\sh> or was it a script under admin/
<jbailey> Trying makefile.cvs
<jbailey> seems good.
<jbailey> Thx. =)
<jbailey> Riddell: This one works.  I'll try to see if there's something quick between the two.  I'm only worried because the failure shows up only on ppc.
<Riddell> make -f debian/rules buildprep   (which runs make -f Makefile.cvs which runs make -f admin/Makefile.common cvs)
<doko> back again
<jbailey> doko: arts bug appears to be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
<jbailey> doko: Newer snapshot has a workaround for it, but maybe consider it for out 4.0 package?
<jbailey> s/out/our/
<doko> doh! 54 comments, maybe we just found the regression mark asks for ..
<doko> jbailey: maybe you could add your comments to the report?
<jbailey> "spent 3 hours chasing why old software didn't work.  That really sucked.  Please apply."
<jbailey> s/didn't work/didn't work on ppc only, but worked fine on ia64, i386 and amd64/
<jbailey> I'll do a test run overnight first to make sure this patch actually fixes it. =)
<doko> heh, yes
<jbailey> Riddell: Erm, does that make -f admin/Makefile.common cvs overwrite acinclude.m4? 
<Riddell> jbailey: yes, it'll replace it with the one from admin/acinclude.m4
<jbailey> Riddell: This packaging is going to drive me to drink.
<jbailey> lamont: -xc is fine.
<jbailey> lamont: arts uploaded, ready to watch her spin.
<lamont> jbailey: coolness
<infinity> doko : How goes the transition, and are there things you want help with?
<infinity> (upload monkeying, whatever)
<lamont> doko: what's the story with gnome-menus?
<lamont>   libgnome-menu-dev: Depends: libgnome-menu2 (= 2.11.1.1-0ubuntu1) but it is not installable
<fabbione> morning guys
<lamont> morning fabbione 
<fabbione> hmm coolness
<fabbione> kicking back gcc made it compile this time
<lamont> fabbione: when seb128 is awake again and/or doko, wanna ping them wrt gnome-menus?  (see above)
<fabbione> sure
<fabbione> are you already compiling C++ apps?
<lamont> libs
<fabbione> ok
<lamont> eel2 et al are backed up.  could be that we need to deal with bootstrapping something, but ew.
<fabbione> uh? crap
<lamont> libgnome-menu0 2.10.<mumble> is current in the archive
<lamont> gnome-menu is not listed in cxxapps.txt
* lamont wipes his brow
<lamont> jbailey: you probably don't want to know that arts_1.4.0-0pre1ubuntu6 is ftbfs on ppc,  do you?
<lamont> actually, that is pretty old news
<fabbione> night lamont
<lamont> g'night
<infinity> 'night lamont.
* infinity decides that lamont going to bed is his cue to actually wake up and get to work.
<jbailey> lamont: ubuntu7 is the one I uploaded. =)
<jbailey> fabbione: I did an lkh upload - Can you give back xorg?
<fabbione> jbailey: yup! i saw that
<\sh> hmmm
<fabbione> i need to wait gcc-4.0 to finish
* \sh is compiling c++ apps for cxx trans ;)
<fabbione> \sh without all the libs, is really BAD to build apps
<infinity> Indeed.
<\sh> fabbione: well...i needed only arts kdelibs4c2 
<\sh> right now :) and libqt
<\sh> and everything is there
<\sh> with some tricks, yes;)
<infinity> Note that the app recompiling is going to be done automagically once the libs are done.
<\sh> infinity: problem is adjusting the build-deps and finding out bugs in the c++ code itself...and I need at least a testing env for some other things like qt bindings/kde bindings :) 
<\sh> and other question is, has anybody the resources to have a "remote access possibility" to ppc and amd64 machines to do a test breezy chroot on it?
<infinity> Adjusting build-deps?... The -dev packages shouldn't be changing names, only the library packages..
<\sh> infinity: as I learned yesterday, we should tighten the build-deps to the latest libs compiled with g++4
<\sh> so it means the -dev package must be something like >= version-ubunturev
<infinity> Interesting.  That wasn't (and still isn't) in the transition plan.  And it also means mangling every single C++ app, which was previously not going to be done.
<\sh> so there are >1 real truth
<jbailey> I don't know how much value there is in tagging every build-dep.  The only value is people backporting, and with a 6 month release cycle it's hard to feel any sympathy.
<\sh> in the end, I adjusted some nice pitfalls with packages directly from debian and on cxxtransition list
<\sh> wrong makefiles etc. 
<infinity> \sh : If those bugs are relevant to both Debian and Ubuntu, could you get them filed upstream?
<\sh> infinity: sure
<infinity> As for having all our build-deps diverge with Debian, that seems ludicrous, as we're suddenly carrying around a bunch more patches that prevent us from syncing easily.
<jbailey> infinity: We have that anyway - But Debian is at least on a path to convergeance.
<infinity> And in the Ubuntu case, it's pointless from a buildd perspective, cause we keep tight control over how each package is compiled anyway.
<infinity> And it's not even relevant for backports, since the packge IS buildable with the old build-deps.
<\sh> well...sometimes it's only a pitfall cause some packages are using cdbs with autotools.mk and behaving not as expected 
<infinity> If anything, updating the build-deps makes backports harder for no real reason (it doesn't help the archive's consistency)
<\sh> is gcc/g++ 4.0.x default in debian unstable now?
<infinity> \sh : No.  Won't be until after Sarge releases.
<infinity> That doesn't seem relevant, though.  There's no law that states a source package has to produce specific binary dependencies outside of a specific archive/suite.
<\sh> hmmm..after hurd release then ;)
<infinity> (example being someone who builds a package on woody that happens to have the build-deps satisfied, and ends up with different glibc/stdc++/ncurses/whoknows deps)
<\sh> in my point of view, if we're trying to compile apps now to test if the upstream source works to compile nicely with 4.0.x suite
<infinity> Inverse example is all the stuff we recently synced from Debian that is uninstallable on Debian systems, because we have a newew glibc.
<\sh> or not makes sense and fixing it
<infinity> \sh : Oh, by all means, compile away, using new libs, I'm just arguing that tightening build-deps is broken, and isn't what build-deps are for.
<infinity> If we seriously think that's what build-deps are for, then we need to change every package in Ubuntu to build-dep on libc6-dev >= 2.3.5
<\sh> infinity: ok, then I can change the build-deps not to be tightend, but some packages are having g++ as build deps (tightent to 3.3 or at least 3.1)
<infinity> Which is, obviously, retarded.
<infinity> \sh : Any packages with g++ (unversioned) as a build-dep are wrong (it's in build-essential), but won't break.
<infinity> \sh : Any package with a versioned g++ build-dep, find out why first. :)
<infinity> (And, odds are, most of them are wrong too.. Except for stuff depending on qt2... Which should just go away)
<\sh> k..lets see what to change anyways..
<daniels> it's my mum's birthday today, and she's showed up a few hours earlier than expected, so I'm going to be AFK until very late tonight.  will be working on the weekend, though.
<infinity> Have fun birthdaying.
<infinity> I'm working all weekend too, to make up for moving/immigration time wasteage.
* infinity wonders when the monitor for the amd64 machine will finally get here.
<daniels> heh.  wot fun.
<fabbione> daniels: did you plan to upload zorg any time soon?
<fabbione> let say within the next 12 hours...
<daniels> fabbione: that's the plan, I'm just fixing the last bits now
<daniels> do you need something done, or just wondering whether or not to kick off a sparc build?
<fabbione> daniels: well if you upload -16 soon it's ok
<fabbione> i just don't want to kick -15 and get -16 in the queue 4 hours after :)
<fabbione> i think the fix to l-k-h should be enough to build X
<fabbione> but i can't test until gcc-4.0 is finished
<daniels> cool
<daniels> ok, bbiab
<fabbione> ok
<doko> hi fabbione
<fabbione> hey doko
<doko> how's sparc going?
<chmj> hey doko 
<fabbione> doko: weird enough gcc-4 didn't build at the first shot
<fabbione> it's installing right now
<doko> hi chmj
<doko> lamont, elmo: please requeue libsdl1.2 on powerpc, the build deps should be there now (and if that's built, xine-lib as well)
<doko> lamont, elmo: libtunepimp on all archs
<doko> Kamion: libxplc0.3.11-dev (universe) is a build dependency of wvstreams (main), could you update the seeds?
<Kamion> there is no need to update the seeds for that
<Kamion> germinate follows dependencies and build-dependencies; the *point* of seeds is not to have to list all that stuff. :)
<doko> hmm, the buildd doesn't know about it yet
<Kamion> yes, elmo needs to move it to main
<Kamion> universe->main propagation is only semi-automatic
<doko> elmo: please move xplc to main
<elmo> is there any point in maintaining the sync blacklists still?
<doko> elmo: which ones?
<elmo> cxxapps and cxxlibs
<doko> we can drop the cxxlibs for main, every library package now should have a ubuntuX upload.
<doko> I'll start uploading -buildN packages today (C++ apps in main), then we can drop the cxxapps from main as well.
<elmo> but, a sync would have the same affect as -buildN wouldn't it?
<elmo> well, I suppose not for non-main, ok, blah, nm
<fabbione>  signfile gcc-4.0_4.0.0-7ubuntu6_sparc.changes C14C0CBD
<fabbione> yay
<doko> elmo, yes, for main we can sync again, if all libs are built, but they are not yet. kdelibs wasn't yet uploaded.
<\sh> doko: upload it ;)
<\sh> doko: or do u want to wait until 3.4.1 is out?
<doko> Riddell and amu are preparing the package ...
<doko> they do have the needed patches
<fabbione> daniels: ping?
* jbailey fades into reality.
<fabbione> hey jb
<fabbione> going to kick back X in a few minutes
<fabbione> food first :)
<jbailey> Yeah, I need breakfast and then to do the glibc upload to fix the dependancy.
<fabbione> can you also check that ulti-linux FTBFS on sparc?
<fabbione> it claims an error in one include file shipped by glibc
<jbailey> Yeah, umount2 redefinition.
<jbailey> I just love these things that show up on one arch only. =)
<fabbione> :)
<jbailey> Hmm, this will be fun.
<jbailey> I have a workshop that I'm supposed to go to this afternoon and I forgot to rent a car.
<jbailey> May long weekend - biggest party WE of the year in this city. =(
<doko> elmo: please move libdc1394-13-dev to main, build dependency of pwlib
<jbailey> fabbione: Oh right, I did look at this before.  Sparc and arm specific define, stupid.
<jbailey> I should try harder to get sysutils to where it replaces util-linux.
<doko> elmo: could you give me a list of main cxxapps, for which newer debian versions exist?
<jbailey> fabbione: Uploaded.
<fabbione> eheh i see thanks
<fabbione> so it was not glibc
<jbailey> Nope.  #if defined (MNT_FORCE) && !defined(__sparc__) && !defined(__arm__)
<fabbione> ok xorg kicked back
<fabbione> elmo: thanks for ocfs2-tools NEW love :)
<fabbione> daniels: please please please do NOT upload xorg -16 now that i started building -15
<lamont> elmo: gconfmm2.6 UNACCEPT
<lamont> Rejected: libgconfmm-2.6-1c2_2.10.0-0ubuntu3_amd64.deb is NEW for breezy.
<fabbione> hey lamont
<lamont> morning fabbione 
<jbailey> g'm lamont
<doko> hi lamont
<fabbione> hmm lamont 
<fabbione> perhaps you want to kick back ocfs2-tools
<fabbione> or update the chroots
<fabbione> E: Package debhelper has no installation candidate
<doko> lamont: ross sbuild/powerpc still tries to install an outdated libarts-dev, when building libsdl1.2
<doko> lamont: please build openh323
<doko> lamont: please build libtunepimp
<daniels> fabbione: uhm, ok
<fabbione> daniels: you were too slow :)
<fabbione> sorry ;)
<fabbione> daniels: if you want to go to sleep, just stick the sources somewhere and i will upload them for you if it fails 
<fabbione> or after it completes the build and i can uplaod the bins
<daniels> nah it's ok, I'll do it tomorrow morning
<daniels> it's not urgent, just more modularisation and some hppa love
<fabbione> ok
<fabbione> so if it still doesn't build you can give sparc love too :)
<daniels> fo'sho
<doko> daniels: do you have a chance to investigate the libpng3 miscompilation on powerpc?
<daniels> doko: not now I don't
<daniels> how urgent is it?
<daniels> i plan to spend all tomorrow (saturday) catching up on xorg stuff, which would mean that monday or tuesday would be the first chance I got to look at libpng stuff
<doko> it's wrong code generation in our default compiler, so it's not minor, just wanting to have the testcase in the bug report, so I can investigate it on ppc without building xorg
<daniels> the testcase should already be there
<daniels> grab davis:~daniels/redglass/X_cursor*, and run xcursorgen X_cursor.cfg X_cursor, on powerpc with the affected libpng
<doko> are the xcursorgen sources there as well?
<daniels> nope
<daniels> you can pull it out of xbase-clients tho
<daniels> ar x xbase-clients_6.8.2-16_powerpc.deb data.tar.gz && tar zxvf data.tar.gz usr/X11R6/bin/xcursorgen, or something
<doko> ok thanks, will look at it
<daniels> np
<doko> lamont: did you reschedule openh323 and libtunepimp?
<lamont> doko: once I see what exactly "reschedule" means in buildd-ese
<lamont> libs/openh323_1.15.3-2ubuntu1: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
<lamont>   Dependencies: libpt-dbg (>= 1.8.4-1ubuntu1)
<doko> openh323 needed pwlib, which is built now. maybe it needs some main love from elmo?
<lamont> so does that mean that you changed pwlib?
<lamont> or rather, changed the dependency?
<doko> no, lib package
<lamont> because libpt-dbg_1.8.4-1 is current in the archive
<doko> libpt-1.8.3c2 isn't there ...
<lamont> is NEW?
<lamont> libs/libtunepimp_0.3.0-2ubuntu6: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
<lamont>   Dependencies: libid3tag0-dev (>= 3.8.3-4.1ubuntu1)
<lamont> and that one's even cuter
<lamont> libid3tag0-dev_0.15.1b-6 is the current version
<lamont> so, no.  I haven't rescheduled them.  since it won't do a damn thing
<doko> Accepted:
<doko> id3lib3.8.3_3.8.3-4.1ubuntu1.diff.gz
<doko> elmo: ^^^
<doko> Accepted:
<doko> pwlib_1.8.4-1ubuntu1.diff.gz
<lamont> yeah - is likely an elmo-requiring issue, if you've uploaded them, and they've been accepted, and they're not in the archive...
<doko> oh, and same for kdelibs ...
<lamont> libs/pwlib_1.8.4-1ubuntu1: Uploaded by buildd+rothera [optional:out-of-date] 
<lamont> but that's a patience issue, not an archive issue.
<lamont> as for libtunepimp, it's blocked on libid3tag, not id3lib3.8.3
<doko> archive issues are patience issues ;-)
<daniels> fabbione: would it hurt too much if I uploaded xorg now?
<lamont> daniels: that depends on how many more things it'll break
<daniels> hopefully nothing, and it will unbreak some crappy scc architectures :P
<lamont> the timing of retiring /usr/X11R6/ and the links from /usr was, um, poor.
<daniels> but it will dep-wait on stuff in NEW
<daniels> lamont: nothing I could do, dude
* lamont will accept that excuse, for now.
<daniels> lamont: i was arse-deep in a new upload by the time I was told it would be nice if I could transition libGLU an hour ago
<lamont> :-)
<daniels> the whole three-ring circus knocked me back outside the timeline for XRoadmap
<lamont> that transition caused some FTBFS's in a rather inopportune time.  see arts. :-(
<doko> daniels: sorry, no, I told you the week before
<daniels> doko: sure, that was a 'can you handle libGLU and dbus'
<lamont> daniels: yeah.. just grumbling... don't mind me
<daniels> speaking of dbus, need to do that still
<doko> daniels: done it already
<doko> just waiting for kdelibs
<daniels> oh cool, thanks
<daniels> libdbus-qt-1-1c2?
<doko> yes
<doko> hmm, I can upload it, even if it won't build
<daniels> lamont: uhm, looking at arts, I just see C++ errors?
<doko> daniels: the latest arts build by jbailey should be fine
<lamont> the first one was the 'libsdl is missing the -I directive' or some such
<lamont> after that was jbailey dealing with things
<lamont> including kludging around the fact that libsdl was missing the -I, since libsdl1.2 was d-w arts.
<doko> libsdl1.2 is fixed as well
<lamont> doko: yes.  I was bitching about the past problem.
<doko> BitchingBOF 
<daniels> i planned to do the xorg transition in larger chunks
<daniels> which would have not as much pain
<daniels> also while we weren't attempting to rebuild half the archive
<lamont> (specifically, that the xorg directory transition caused a circular build-dep loop in arts/sdl, that jbailey had to kludge around as part of fixing arts CXX issues)
<lamont> right
* lamont continues to have issues with all the magical build-ordering that isn't encapsulated in build-deps.
<daniels> anything in X?
<daniels> x should be pretty nicely bootstrappable these days
<lamont> no.  all I've seen recently are in the g++ transition
<daniels> the mots pain we're hitting right now is possible circular symlinks
* lamont pitys any new architectures that come along after last week.
<lamont> doko: what happens when something is built with mixed (pre- and post- transition) libs?  does the link fail ( hope oh hope), or does it happen to work (that'd be ok too), or does it just successfully build something that is completely useless?
<doko> well, hope is near, you'll detect it (hopefully) as something with a dep on libstdc++5 _and_ libstdc++6
<doko> it may work ...
<lamont> so scc architectures may just have a longer trip through the land of transition
<lamont> and they could do builds/uploads to deal with that.  except that we don't like binNMU's....  hrm...
<doko> but you can just keep the cxxapps list as no-build ... why not?
<lamont> doko: yeah - it just means that the initial bootstrapping also gets to deal with the magical ordering of the g++-4.0 transition as well.
<lamont> if it's really a new architecture (hppa has a hoary port, hence the pain), then it's just more ordering constraints for the bootstrap.  that's all
<doko> lamont: yes, but that the only way we don't have to touch the cxxapp packages
<lamont> right
<doko> jbailey: does glibc still builds with -g1? 3.4.4 doesn't have this patch anymore, so I'll drop that one as well, and you should use -g2.
<fabbione> daniels: x is fTBFS on sparc
<fabbione> -mv
<fabbione> 8
<fabbione> humpf....
<fabbione> daniels: i will send you a patch for that
<fabbione> it's quite annoying
<fabbione> daniels: in any case go ahead and upload -16
<fabbione> we can catch on sparc with -17
<doko> elmo, Kamion: we need some universe->main love ... kdelibs4c2
<Kamion> ok, give me a moment while I work out what to do
<Kamion> er, elmo already did it
<Kamion> kdelibs4c2 | 4:3.4.0-0ubuntu6 |        breezy | amd64, i386, ia64, powerpc
<doko> oops, yes, must be within the last hour or so. sorry the noise. 
<doko> lamont: so we can rebuild dbus?
<doko> lamont: same for openh323
<doko> lamont: libgnomeuimm2.6 should be retried on amd64 and ia64? had bugs in dbus and openh323
<fabbione> doko: are you already compiling apps?
<fabbione> or still libs?
<doko> still libs, but I we can start soon ...
<fabbione> daniels: i have a patch to fix the first FTBFS on sparc. it's building the rest of the tree now...
<fabbione> daniels: p.u.c/~fabbione/992_ubuntu_sparc_fix_ftbfs.diff for now
<lamont> doko: openh323 will rebuild as soon as libpt-dbg is there
<lamont> that's what Dep-Wait in buildLogs/Lists/* is for
<doko> lamont: no, I had a wrong version in the build deps
<lamont> so what you really want is for me to clear the dependency?
<doko> ?
* lamont notices that openh323 didn't go Dep-Wait, gives it back
<lamont> anybody working on the smpeg ftbfs, or is that fixed already
<lamont> ?
<doko> libgnomeuimm2.6 ?
<doko> lamont: smpeg is fixed, that's what http://people.ubuntu.com/~lamont/buildLogs/s/smpeg/ is for ;-)
<lamont> doko: heh
* lamont considers him self properly bitchslapped
<doko> jbailey: Bugzilla Bug 21657: [4.0 regression]  TLS reference miscompiled, ia64 only, so fabbione and lamont don't necessarily need to build it.
<lamont> doko: I expect I might in my ia64 buildd hat, no?
<doko> yes, I did mean, for the poor hppa and sparc machines
<lamont> well, if you upload, we have to build it eventually...
<lamont> this is gcc-4.0?
<lamont> because the current version in the archive doesn't build on hppa...
* lamont is running 4.0.0-7ubuntu6hppa1 :-)
* lamont says to hell with it, gives back all the failure logs he has for main.
<doko> lamont: is there a status, which things are not up to date in main?
<lamont> doko: in Lists/breezy.all.$ARCH, grep out-of-date | grep -v Installed
<doko> lamont: can you blacklist the packages in cxxapps.txt on the hppa and fabbione's sparc buildd?
<lamont> doko: already doen
<lamont> or rather, fabbione did sparc, I did hppa
<lamont> or did you change the list since we started this game?
<doko> no, I think I removed dpkg from it, but didn't add anything
<lamont> doko: fresh build of libgnomeuimm2.6 on amd64 says:    libgconfmm-2.6-dev: Depends: libgconfmm-2.6-1 (= 2.10.0-0ubuntu1) but it is not going to be installed
<lamont> mind you, it may try to build kdebase with the old kdelibs
<doko> no, it will fail
<doko> new qt and old kdelibs don't like each other
<doko> lamont: libgconfmm-2.6-1c2 is in main, why isn't it installed?
<lamont> because libgconfmm-2.6-dev Depends: libgconfmm-2.6-1
<doko> no
<doko> $ apt-cache show libgconfmm-2.6-dev
<doko> Package: libgconfmm-2.6-dev
<doko> Priority: optional
<doko> Section: libdevel
<doko> Installed-Size: 1048
<doko> Maintainer: Bradley Bell <btb@debian.org>
<doko> Architecture: i386
<doko> Source: gconfmm2.6
<doko> Version: 2.10.0-0ubuntu2
<doko> Depends: libgconfmm-2.6-1c2 (= 2.10.0-0ubuntu2), libgconf2-dev (>> 2.6.0), libgtkmm-2.4-dev
<lamont> i386 != amd64
<lamont> amd64 has libgconfmm-2.6-dev_2.10.0-0ubuntu1
<doko> but the build succeeded on amd64 ...
<lamont> ubuntu2 only has i386/ppc in the archive, and ubuntu3 is source only
<lamont> oh hell.  kids
<lamont> back in a while
* lamont is already 15 min late, and 30 min away from where he should be...
<doko> lamont: come you back again today?
<lamont> yes.  I live here.
<lamont> :-(
<doko> ;)
<lamont> back in ~90 min or so
<lamont> but poppy is alive again, that'll help
<doko> I want to finish C++ tonight ...
<fabbione> daniels: i confirm that the patch make X build. I am going to do the full build/install dance now
<fabbione> and tell you tomorrow morning as soon as i wake up
<doko> Kamion, elmo: just in case you're reading this ... last three libraries, which need promotion to main: libdbus-qt-1-1c2, libopenh323-1.15.2c2, libtunepimp2c2
<doko> then we need a rebuild of kdebase (lamont?), and then we're done
<doko> lamont: please remove the Dep-Wait for xerces25 and xerces26
#ubuntu-toolchain 2005-05-28
<lamont> sigh.  that took _WAY_ too long
<daniels> fabbione: which patch?
<daniels> oh, I see
<daniels> fabbione: got it
<jbailey> doko: Around?
<fabbione> morning
<fabbione> daniels: ping?
<daniels> pong
<fabbione> daniels: did you see my patch on people?
<daniels> yeah, already merged it
<fabbione> thanks
<fabbione> i am uploading -15 right now
<daniels> no worries
<daniels> -15 of what?
<fabbione> as soon as i get the accepted you are free to go for -16 :)
<fabbione> xorg
<daniels> oh, for sparc
<fabbione> yes
<daniels> phew
<fabbione> if you upload -16 before, the -15 bins will be rejected
<daniels> sure
<fabbione> finally i can start buildd again :)
<fabbione> http://www.theregister.co.uk/2005/05/18/vibrating_knickers/
<fabbione> AHAHHAHAHA
<fabbione> daniels: ok you can go anytime
<fabbione> -15 has been accepted
<daniels> cool
<fabbione> thanks dude
<lamont-away> fabbione: are you uploading binaries that are non-virgin???  you bad man you.
<fabbione> lamont-away: yeah it's cheating on a package :)
<fabbione> aren't you supposed to be sleeping?
<lamont-away> yeah - came out to check on the buildd, and change the laundry
* lamont-away notes that his local archive has xorg_6.8.2-15hppa2 in it. :-)
<lamont-away> anyway, g'night again
<fabbione> btw kernel: i need updated chroots on concordia and davis otherwise i can't test build
<lamont-away> yeah - saw that in -kernel.
<fabbione> lamont-away: too lazy to change the version
<fabbione> specially because -16 with the fix will hit archive soon
<fabbione> lamont-away: before you go... xorg gcc -> buildd?
* lamont-away bets it was the same fix that he gave daniels earlier in the week.
<fabbione> is there anything else i need to take care of?
<fabbione> lamont-away: i doubt... the fix was sparc specific
<daniels> lamont-away: uhm no, it was a sunffb-specific fix :P
<fabbione> sunffb driver compilation options
<daniels> i didn't know what -mv8 was before I started on -15
<daniels> and I still don't
<daniels> unless it specifies the particular sparc revision or some shit
<lamont-away> prior to unleashing the buildd: 1) cxxapps.txt -> @no_auto_build, 2) fresh versions of gcc-4.0, gcc-defaults, dpkg, xorg (and their build-deps, of course).
<fabbione> i think it's some gcc optimization flag
<lamont-away> ah, ok
<fabbione> lamont-away: yeps.. all of that it's already in place
<lamont-away> then you're _go_ for sparc buildd
<fabbione> coolness
<lamont-away> once those are in the archive, that is.
<fabbione> they are
<fabbione> i did build all of them manually
<lamont-away> yeah
<fabbione> yup
* fabbione unleashes buildd on breezy 
<fabbione> good night lamont :)
* lamont-away has 30 failed builds sitting in his hppa buildd mailbox
<fabbione> yeah i wonder how many i will get here
<lamont-away> some of those are hppa specific (console-tools, ubuntu-meta)  But a bunch of them are /usr/include/X11 or gcc-4.0 or such
<fabbione> + i still have some old craft to cleanup
<lamont-away> 232 packages built, 151 of them uploaded... damn straws
<fabbione> i guess i am going to hit some build-deps madness...
<lamont-away> oh yeah, big time.
<fabbione> ehhehe
<lamont-away> not to mention lots of NEW packages, depending on how you have your overrides set up...
<fabbione> i didn't setup overrides
<lamont-away> there are still a few packages in universe that need to move to main to fix the archive.
<fabbione> oh
<fabbione> well i don't mix universe/main anymore
<fabbione> after ports has been up
<lamont-away> is in scrollback from doko just before he left.
<lamont-away> that's good
<fabbione> so the ogre model is complete again
<fabbione> now the local pkg cache is down to 2 hours
* lamont-away cheers
<fabbione> so possiblities to hit a mix are very very very low
<lamont-away> anyrate, time to sleep again.  g'night
<fabbione> night lamont
<fabbione> daniels: btw.. elmo mentioned that xtrans had some .c files in /usr/include/X11
<fabbione> dunno if you fixed that already
<daniels> it's not fixable
<daniels> that's how xtrans works
<fabbione> eh?
<daniels> you #define a bunch of crap and then #include the .c files
<daniels> it's utterly, utterly disgusting
<fabbione> JEEEEE
<daniels> now you see why I have such a deep-seated hate for xtrans
* fabbione pukes
<fabbione> can't we move the .c files somewhere like /usr/share/ ?
<fabbione> just for the goddam sake of it?
<daniels> we've already had that argument upstream, the consensus was that we'd put it in /usr/include and try to kill xtrans
<fabbione> BRRRRRRR
<fabbione> we need to get an #u-x chan or something
<daniels> this is the sort of shit I have to deal with upstream as well as downstream :P
<fabbione> daniels: you are d00m3d
<daniels> indeed
<fabbione> omg! doko! another gcc-3* full set upload?
<fabbione> i wonder if i will ever get to the point to actually build something else than toolchain
<doko> morning all
<fabbione> hey doko
<fabbione> infinity: ping?
* doko starts to hate the change to DEB_*_GNU_SYSTEM
<Kamion> doko: all those libraries are still in NEW - I'm leaving them to elmo
<doko> hmm, getting all these renamed libraries into the archives is really suboptimal :-(
<doko> Kamion: the debconf build needs kdebindings fixing for amd64 from Riddell
<cartman> koffice will need http://janeway.no-ip.org/~cartman/filters_gcc4.patch btw
<cartman> just in case
* Riddell is working on kdebindings just now
<Riddell> might take a few hours
<Riddell> cartman: which version of koffice is that against?
<cartman> head
<cartman> but filters rarely changed
<cartman> should apply cleanly
<Riddell> cartman: have you sent it back to the koffice developers?
<cartman> Riddell: trying now, psn resisting ;)
<Riddell> cartman: is that compiled on 64 bbit or 32 bit?
<cartman> Riddell: only errors on amd64+gcc4
<Riddell> cartman: ah, then you'll be adding errors to x86 :)
<cartman> hmm no
<cartman> similar fix went into kmail last week
<cartman> :/
<cartman> should be safe
<cartman> you cast it to long before casting to something else to preserve precision
<Kamion> doko: debconf hasn't built for ages anyway :(
<Riddell> cartman: ok, maybe you're right
<cartman> Riddell: I will wait for dfaure to be sure
<Riddell> he's the man
<cartman> yep
<Riddell> out->fScratch = ((int)(long)in & 1);   is there really no better way?  just looks ugly
<cartman> well I stole the solution from kmail where they were casting int* to int
<Kamion> erm. what's the type of 'in'?
<fabbione> ehy Kamion 
<fabbione> Kamion: do you still have katie suppah p0w3r? :)
<cartman> Kamion: const char* I think
<Kamion> cartman: EWWWW. so you're basically working around crappy typing elsewhere.
<Kamion> fabbione: yes ...?
<cartman> Kamion: its msword/mswrite filters, what do you expect? honest :)
<fabbione> Kamion: just for curiosity... what is the status of knetworkconf 0.6.1-3ubuntu4 (hoary-updates)?
<Kamion> fabbione: same as it was when the last two people asked about it :P
<Kamion> fabbione: source is in the archive, but I don't think hoary-updates is building ...
<fabbione> Kamion: i am asking becuase i could see the source and the sparc buildd got it in needs-build, but it was not taking it
<fabbione> ah ok, but it is safe for me to upload it?
<fabbione> sparc did built it fine
<Kamion> I'm assuming it's turned off in w-b or something, I'm not actually sure
<fabbione> ok, don't worry
<Kamion> I don't know if it's safe or not - it probably is, but that's an elmo question
<fabbione> ok, i will just keep it stand-by somewhere
<fabbione> thanks a lot
<Kamion> it might get rejected by the C++ transition check in jennifer
<fabbione> uh right...
* fabbione checks
<Kamion> which isn't distribution-guarded
<fabbione> no it's banned as c++apps in buildd.conf
<fabbione> i forgot that kde is all c++ 
<fabbione> or almost :)
<fabbione> so yeah.. it can be built, but it's not since @no_auto_build is not distro aware
<fabbione> and the filter is applied 
<Kamion> ah, buildd.conf, ok
<fabbione> yeah it was the simplest solution to filter apps
<fabbione> i just forgot to look there before asking :)
<Riddell> kdebindings doesn't want to compile
<Riddell> it gets stuck on sipqtpart0.cpp and sits there chewing up CPU cycles forever
<doko> Riddell: try to lower the optimization for that file
<Riddell> doko: that did it
<Kamion> elmo: I NEWed dbus_0.33-0ubuntu3, openh323_1.15.3-2ubuntu2, libtunepimp_0.3.0-2ubuntu7 for c2 changes
<Riddell> not sure how to lower the optimisation other by hand though
<doko> Riddell: please save the preprocessed file, and put it in a bug report, need the architecture and command line options as well
<\sh> morning
<lamont> jbailey:  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../grove -g --pipe -O3 -ffunction-sections -D_REENTRANT -MT GroveApp.lo -MD -MP -MF .deps/GroveApp.Tpo -c GroveApp.cxx  -fPIC -DPIC -o .libs/GroveApp.o
<lamont> /usr/include/OpenSP/RangeMap.cxx: In member function 'unsigned int OpenSP::RangeMap<From, To>::inverseMap(To, From&, OpenSP::ISet<OpenSP::WideChar>&, OpenSP::WideChar&) const':
<lamont> /usr/include/OpenSP/RangeMap.cxx:50: error: 'wideCharMax' was not declared in this scope
<lamont> wanna fix openjade?
* lamont should learn C++ better sometime
<doko> lamont: hi
<doko> I'm looking at it
<lamont> thansk
<doko> lamont: kdebase needs some love, the deps are in main now
* lamont kicks kdebase, unixodbc/ppc and libgnomeuimm2.6/*64
<doko> lamont: openjade did build on all archs ...
<lamont> that's from hppa - haven't double checked to make sure it dies on i386
<lamont> ruby1.8. otoh is another dpkg victim
* doko would like to play hang-man ... ;)
<lamont> ruby1.8 => #11040
<doko> it's ok, if you see the breakage, but there's silent breakage as well. hmm, maybe it's better to just revert this change until Debian switches to the new dpkg as well
<lamont> interesting idea
<fabbione> hey lamont
<fabbione> lamont: it would be interesting to implement @no_auto_build per distro
<lamont> fabbione: heh
<fabbione> today digging in the w-b database i noticed a knetworkconf (hoary-updates) not taken for build
<fabbione> because it's banned in breezy
<lamont> it would also be good to to make SIGHUP re-read it
<fabbione> hm?
<fabbione> yeah
* fabbione kicks gcc test suite
<fabbione> it's too slow!
<fabbione> doko: you must do something about it
<lamont> doko: might be that doing a breezy-test world with dpkg changed might be the right answer.
<doko> ifeq arch=sparc and bbuilder=fabbione, then fail. exit 0
<doko> that's fast!
<doko> fabbione: did I tell you that I need another 3.4?
<fabbione> doko: i am still building gcc-3.3
<fabbione> so i don't really care
<fabbione> doko: did you fix that problem with libvtest thing?
<fabbione> doko: so if you upload the new gcc-3.4 now it's ok
<doko> well, 3.3 does have interesting libc dependencies now ...
<fabbione> i am still building 3.3
<fabbione> but i care more about 3.4
<doko> fabbione: I don't know, I built it, and I don't see the failure
<fabbione> since we build the kernel with 3.4
<fabbione> doko: bah you suck :P
<fabbione> i told you.. the target is not called 
<fabbione> come on dude...
<fabbione> you can manage :)
* fabbione whispers to doko: "FIX IT!"
<fabbione> doko: i will see if it happens again with the next build
<fabbione> if so i will put our buildd chroot somewhere so you can look at it
<doko> fix ruby1.8 while you're waiting ;-)
<fabbione> doko: are you going to do cleaning in my house in the meanwhile?
<doko> lamont: could you remove the Dep-Wait for xerces25 and xerces26?
<lamont> doko: sorry sure
<lamont> done
<doko> fabbione: hmm ...
* lamont hopes the new 3.4 actually builds on ppa
<fabbione> doko: trust me.. you will be more happy fixing ruby1.8 too :)
<fabbione> + i hate c++
<fabbione> with all myself
<\sh> jesus
<\sh> kdelibs4c2 is in
<lamont> \sh: that was doko et. al., not jesus
<fabbione> doko has short hair...
<\sh> when doko uploaded it, he's jesus ;)
<doko> \sh, call me as you like it ;-)
<\sh> fabbione: and? in africa, jesus has a dark skin colour
<doko> naa, Kamion did give it some love ...
<fabbione> doko drinks beer... jesus doesn't
<fabbione> or didn't...
<fabbione> depends how you want to see it :)
<lamont> fabbione: wine, beer, what's the diff?
<fabbione> jesus was more for wine...
<\sh> fabbione: we can't be sure
<\sh> jesus had something with maria magdalena
<fabbione> lamont: beer is like so... german.. wine is more italian :)
<lamont> well, if the books are to be believed, he was of jewish descent...
<doko> Riddell, amu: kdebase fails ...
<doko> kate.la.o(.text+0xe): In function `main':
<doko> collect2: ld returned 1 exit status
<doko> make[4] : *** [kate]  Error 1
<\sh> the life, the universe and the rest
<fabbione> anyway... time to go and do some cleaning
<\sh> let me finished libchasen
<lamont>  /build/buildd/kdebase-3.4.0/obj-i386-linux-gnu/kate/app/kate.la.cpp:2: undefined reference to `kdemain'
<\sh> -ed
<lamont> doko: you forgot that line
<doko> yes, xchat did grab it
<lamont> yeah
<doko> fabbione: one idea ...
<fabbione> doko: ?
<lamont> hppa's uploader is only 86 packages behind...  sigh.
<doko> are there dangling symlinks in /usr/lib/gcc/3.4.4/sparc*/64/
<doko> or in  /usr/lib/gcc/3.4.4/sparc*/
<doko> to libgcc*
<fabbione> doko: i dunno...
<fabbione> and i can't really check
<doko> fabbione, look and you will see ...
<fabbione> do you want me to look if the build fails?
<doko> it's a small miracle ;)
<fabbione> one moment
<doko> hmm, no, that can't be the reason, we don't use the stage1 compiler at this point
<doko> just found out, why gcc-3.4 -m32 is broken on amd64, jbailey could be interested ...
<doko> lamont: could you make sure, that all the buildd's get the current state of the archive, so that I could start uploading cxxapps from main?
<fabbione> are all libs builded?
<fabbione> doko: you should still be sure that the apps build-dep on a proper version of the libs
<doko> fabbione: no, in this case we have to touch all 700 cxxapps packages.
<fabbione> doko: dude.. that will make another breezy debootstrap impossible
<fabbione> doko: you need to change the apps to versioned build-dep
<doko> fabbione: why will it be impossible?
<doko> apps which get synced from Debian don't have changed build-deps either
<fabbione> because you can build packages on top of old libs if you are not extremely carefull
<doko> I did always think, that the hppa and sparc buildd admins are careful, but I can be wrong ;-)
<lamont> doko: you can upload cxxapps, but they won't get built until we change @no_auto_build... :-)
<fabbione> doko: it's not just hppa and sparc..
<fabbione> i think not changing the build-deps is just wrong
<doko> lamont: elmo told me that I could upload anyway
<lamont> fabbione: they build-dep on foo-dev, which is unchanged...
<doko> fabbione: what do you make in case of the synced apps?
<lamont> ISTR doko saying they might just work...
<fabbione> usr/lib/gcc/sparc-linux/3.4.4 # ls -lR
<fabbione> no dangling symlinks
<lamont> fabbione: it can be handled as an archive event... painful, but it works...
<fabbione> hmmm
<fabbione> ok
<doko> lamont: archive event?
<lamont> doko: what we're doing.
<fabbione> probably i am just too much of a purist
<lamont> draw a line, and make sure that nothing on the right side needs anything that wasn't fixed on the left side.
<doko> fabbione: we'll get these build-deps, when Debian is doing the transition
<fabbione> given that sparc was out of hoary thanks to gcc-4.0 unversioned build-deps....
<lamont> note that archive events are, by definition, a royal pain in the tail for any buildd admin
<fabbione> lamont: oh yeah.. i agree
<fabbione> i need to go.. doko: last offer to come and clean my house in exchange of kernel upload with mISDN
<fabbione> (our kernel is really free like in beer ;))
* lamont cries.  b180 took xorg
<fabbione> b180?
<fabbione> is the slowest one?
<doko> slow hppa ...
<lamont> 180MHz 32-bit UP hppa
<fabbione> amen
<lamont> well, there's only 2 of them,.
<doko> heh, and it fails ...
<fabbione> lamont: why don't you add it to @no_auto_build ?
<lamont> I just did
<fabbione> a bit too late i guess :)
<fabbione> lamont: you can still share the ccache between the 2 buildds
<lamont> it had never built it (since it _was_ in n-a-b), so it didn't show up when I added all the really long build-time stuff to n-a-b
<fabbione> it will be less painful when packages hit the slow one
<lamont> fabbione: yeah, but that's so much like work
<lamont> and disk I/O isn't exactly the fastest here...
<fabbione> uh why?
<fabbione> NFS my friend
<lamont> well, for starters, the machines are 2-switches away from each other
<fabbione> that's what i use here to share ccache all over
<lamont> Not a File System
<fabbione> lamont: OCFS2 with the next kernel upload :)
<lamont> OCFS2?
<fabbione> Oracle Cluster Filesystem2
<fabbione> my wife is so going to kill me if i don't go and clean
<fabbione> http://people.ubuntu.com/~fabbione/Screenshot.png
<doko> lamont: does openoffice.org build?
<lamont> on hppa? no
<fabbione> me must go now
<fabbione> cya later
<doko> lamont: i386 and powerpc
<lamont> it's in the @no_auto_build list
<lamont> so it's not going to even try anywhere
<\sh> hmmm...
<lamont> ommmmm
<\sh> i was just informed, that I'm now have a new portable 160gb usb2 hd
<\sh> it's ready to pick up
<\sh> strange thing is, i've never ordered one
<\sh> and I don't have to pay it
<\sh> weired
<doko> lamont: are you able to change the @no_auto_build lists?
<lamont> are we ready for me to?
<lamont> and note that when I do, it'll be 'empty the list' on each buildd as it's done... I'm not going to do it one package at a time
<doko> lamont: all cxxapps in main but KDE. but we can enable KDE as well, it will just fail, because kdebase isn't installable.
<doko> yes, let's wait for kdebase, then we can do it
* lamont adds cxxlibs to his package list for his local mirror, and starts a sync, cringing
<lamont> openjade is an hppa-specific issue.  sihg
<\sh> hmm
<\sh> think i will setup an ubuntu mirror
<doko> lamont: could you report it upstream?
<lamont> doko: will do, although I want to investigate it a bit first...
<doko> jbailey: just noticed that gcc-3.4 -m32 didn't work
<\sh> doko: u reviewed some of those debdiff outputs?
<jbailey> doko: For which arch?
<jbailey> (I'm lagging a bit at the moment, I updated to the new X and it won't start.  I'm just poking it a bit)
<doko> \sh, ok, will do
<doko> jbailey: -m32 ...
<jbailey> doko: I think it worked fine for me the other day on amd64.  It may have been sparc, though.
<\sh> doko: i saw some u reviewed :) u r working too much i think ;)
<doko> hmm, the 32bit libgcc symlinks are dangling links
<jbailey> doko: I'll take a look in a moment then.  
* jbailey kicks his computer.
<Riddell> doko: I think kdebase just needs visibility turned off, checking now
* lamont heads to town for a while
<doko> Riddell, yes, I did see this as well ... hope, that not every KDE packages has this check ...
<jbailey> Ah, lovely.  got X again.
<jbailey> *bounce*
<jbailey> mps
<Riddell> doko: compiles now, should I upload?
<jbailey> doko: Now that I'm actually paying attention.. =)
<jbailey> doko: I have 3 questions:
<jbailey> 1) What was that about -m32?
<jbailey> 2) I've confirmed that glibc builds with -g2 on ppc at least, so I'll set that for the next upload.
<jbailey> 3) What would be good timing for me to do the i386/amd64 biarch stuff so that I don't interfere with you.
<\sh> Riddell: that means we will have a running kdebase at least today? ,-)
<Riddell> \sh: it means we should have a compiling kdebase 
<Riddell> running is a different matter
* Riddell awaits doko's command to upload
<doko> Riddell: please do
<doko> jbailey: 1) dangling symlinks
<doko> 2) now ;) get the 0ubuntu2, that I did upload some minutes ago
<doko> no, this was 3) ;)
<jbailey> Does #3 also solve #1? =)
<doko> yes
<jbailey> Excellent! =)
<Riddell> doko: that file that I said didn't compile did finish after two hours.  I innocently gave up hope after 1 hour
<jbailey> doko: Do you have brainspace for me to ask you about biarch setups and ppc64?
<Riddell> kdebase_3.4.0-0ubuntu21_source.changes ACCEPTED
<jbailey> fabbione: If you're bored at some point, I had asked the main Splack guy about his throughts on requiring v9 or newer for a Sparc distro.  He says that he gots alot of requests for support from classparcs.
<jbailey> fabbione: I Don't know if that's a good reason to support them, or a good reason to run screaming. =)
<fabbione> jbailey: the latter :)
<fabbione> jbailey: btw xorg did build fine with your fix
<jbailey> fabbione: Yay!
<jbailey> fabbione: Any other crazy blockers?
<fabbione> jbailey: not right now.. util-linux did build as well
<doko> Riddell: anyway, having the preprocessed source would be very useful
<doko> jbailey, yes, why not
<Riddell> doko: it's a 9MB file
<jbailey> doko: Right now our bi-arch configs, i386, sparc, and s390 all succesfully build a biarch setup on a 32 bit kernel.
<Riddell> KDE bindings is a bit crazy
<doko> Riddell: doesn't matter
<\sh> Riddell: do u want to disable the python qt/kde bindings in kdebindings?
<doko> yes, do they? I did assume that the buildd's for s390 and sparc are 64bit
<jbailey> doko: From looking at the logs, it looks like ppc is trying to actually run a built ppc64 binary.  Is that something in our packaging, or is that something upstream that needs to be poked?
<Riddell> \sh: arn't they already apart from qt-dcop?
<fabbione> doko: nope.. sparc userland is almost all at 32bit
<fabbione> and it doesn't matter what kernel are you running to build
<\sh> Riddell: i don't know...they're only disabled (in the last source tree i saw) I wanted to use the normal upstream packages...
<Riddell> \sh: "do u want to disable" "they're only disabled" which are they?
<doko> that should be coded in gcc/config.ml (guessing if the compiler works)
<\sh> Riddell: I saw u complaining about python-qt sip things...I just wondered if they're enabled again
<doko> config-ml.in in the toplevel directory
<Riddell> \sh: right.  I suspect they're compiled and then no package is made of them
<Riddell> which is a bit silly
<\sh> Riddell: so remove them from configure.in and makefile.am ;)
<\sh> I will come to python-sip4-qt and kde stuff later this day 
<\sh> patches are already there for pkde
<Riddell> great
<\sh> i don't like this "copy upstream packages into kdebindings"
<jbailey> Heya Bastian.
<waldi> hi
<fabbione> hey waldi
* fabbione goes back cleaning
<doko> waldi: moin
<jbailey> doko: When should we do the binutils update?
<doko> 2.16.1 will be released next week. I didn't had a chance yet for testing on ia64 with glibc 2.3.5
<jbailey> doko: Do you mean with the new bintuils or in general?
<jbailey> ia64 with glibc 2.3.5 in general is working fine.
<jbailey> I can give you access to my box with the breezy chroot if you'd like,.
<doko> with 2.16, I see one regression in the binuitls testsuite (on unstable)
<jbailey> Ah, drow message about releasing 2.16.1 I had missed it.  Cool.
<doko> jbailey: no need, just build the package from experimental in this chroot
<jbailey> doing
<jbailey> Feh, getting false testsuite failures because it's failing to spawn and such.
<jbailey> Lemme boot the box, there's some d-i build processes lying around probably tying up resources.
<fabbione> doko: can i push you a clean breezy chroot somewhere, so you can test a gcc build?
<Kamion> hm, not a good time for a debootstrap upload - aptitude needs to be rebuilt first
<fabbione> uh?
<Kamion> depends on libsigc++*c102
<fabbione> Kamion: i have a diff for the buildd variant
<fabbione> but i am waiting for the last c++ stuff to complete the transition
<fabbione> or do you test that one too?
<Kamion> mail it to me and I'll do it in one upload when everything else is done?
<fabbione> Kamion: sure.. buildd isn't that important and can be done "anytime"
<Kamion> but if you turn out to be in a hurry for it, then feel free
<doko> fabbione: ok
<fabbione> no no.. it's no hurry
<Kamion> the main scripts just need unusual handling
<doko> Kamion: mvo told me that he did test apt and aptitude on all four archs, so maybe I'll just build it
<doko> Riddell: "Bash 3.0-14ubuntu1 hangs on amd64 after any command taking up 99% CPU cycles", I cannot reproduce this behaviour, the testsuite looks ok  as well
<Riddell> doko: hmm, it's definatly very reproducable on amu's machine
<Riddell> doko: old chroot and fresh one
<doko> lamont: ^^^ maybe do not update the buildd's while we are working this out
<fabbione> oh great
<fabbione> doko: gcc-3.3 fails too
<fabbione> mv debian/tmp/usr/lib64/lib*c++*.{a,so} debian/tmp/usr/lib/gcc-lib/sparc-linux-gnu/3.
<fabbione> 3.6/64/.
<fabbione> mv: when moving multiple files, last argument must be a directory
<fabbione> Try `mv --help' for more information.
<fabbione> make[1] : *** [stamps/08-binary-stamp-libstdcxx-dev]  Error 1
<fabbione> btw.. it did start building gcc-3.4
<fabbione> should i stop it?
<fabbione> this is weird
<fabbione> gcc-3.3 did create the debs and failed?
<fabbione> oh yeah.. it was building the debs when it failed
<doko> hmm, why is the target directory not present ... strange
<fabbione> doko: i have almost done with the chroot :)
<jbailey> Mmm.  It's not harmful to have packages in debian/control that are never built, is it?
<fabbione> jbailey: given that you don't create the deb...
<lamont> jbailey: not unless they ever were built
<lamont> I think...
<lamont> anyway, really running off now
<fabbione> later lamont
<jbailey> 'bye lamont
<jbailey> 'k thanks.
<doko> jbailey: no, that's ok
<jbailey> I'm trying to reduce what I have to do to enable ppc64 in my build. =)
<doko> debian/rules.defs: look for biarch
<jbailey> Sorry, still on glibc.
<doko> ;)
<fabbione> guys when do you think i can start working on a ppc64 kernel?
<fabbione> to do that i need the toolchain in place
<fabbione> and breezy-ppc64 chroot is borked afaik
<daniels> night folks
<fabbione> configure: WARNING: I have to compile Test.class from scratch
<fabbione> checking if java works... configure: error: The Java VM java failed (see config.log, 
<fabbione> check the CLASSPATH?)
<fabbione> db4.2 
<fabbione> night kid
<fabbione> ../dist/configure: line 21554: 28092 Bus error               $JAVA $JAVAFLAGS $TEST
<fabbione> interesting :)
<jbailey> g'n Daniel.
<jbailey> fabbione: The ppc64 toolchain is blocked on the fact that it wants a ppc64 kernel to build.
<jbailey> I'm trying to convince it otherwise.
<jbailey> doko: Was it an ld failure?
<jbailey> I see on unepxcted, but schwab posting something to the binutils list that I Can try.
<jbailey> http://sourceware.org/ml/binutils/2005-05/msg00601.html
<doko> jbailey: yes, that's the regression I did see
* fabbione goes off line for the evening...
<doko> ok, submitted #11050 for the dpkg behaviour
* fabbione goes off line for real
<doko> lamont: where can I find the icu build? it's marked as uploaded, but not installed
<jbailey> Wow.  The binutils patch system *doesn't fail* if a patch fails to apply.
<doko> could be dpkg-breakage? ;-) sorry, couldn't resist
<jbailey> If only/  I confirmed it with debian/rules patch =(
<jbailey> So doing the ia64 test.
<jbailey> +re
<jbailey> I'm leaving in a moment, too, so I'll let you know how it goes later.
<jbailey> I'm also building a ppc64 glibc.
<elmo> jbailey: err, it so does?
<jbailey> It didn't for me.  A lovely bit in debian/patched/123_ldwhatever_I_called it
<jbailey> that nicely logged that the patch hadn't applied.
<jbailey> And it merrily carried on.
<jbailey> Anyhow, Angie's poking me to go, back in a few hours.
<elmo> well, new dpatch might not, but new dpatch grew crackful maintainers :(
<doko> elmo: packages from cxxapps cannot be built, even if I upload them signed with my key?
<elmo> doko: I didn't restrict building of apps, that's lamont
<elmo> I only restricted source uploads
<elmo> well, you CERTAINLY can't upload binaries, signed by your key
<doko> ;)
<doko> where's icu currently stuck, is it buildd or new?
<elmo>        icu | 2.1-2ubuntu1 | breezy/universe | source, amd64, ia64, powerpc
<elmo> REJECT
<elmo> Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in breezy >= new version (2.1-2ubuntu1) targeted at breezy.
<elmo> Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in hoary >= new version (2.1-2ubuntu1) targeted at breezy.
<doko> hmm, where can I see this?
<elmo> you can't
<elmo> the queue/REPORT stuff is not visible because it contains security uploads too
<elmo> kamion/mdz can see it.  and lamont gets the REJECT mails
<doko> hmm, well, something we should talk about
<doko> anything else rejected from the cxx stuff?
<elmo> I've no idea, I'm not trawling through all the possible rejects :P
<elmo> as I said, the buildd admin gets the emails ...
#ubuntu-toolchain 2005-05-29
<lamont> moo
<lamont> elmo: I don't recall seeing a reject for icu...
<Riddell> lamont: error on powerpc kdebindings compile "virtual memory exhausted: Cannot allocate memory"
<lamont> Riddell: most cool.
<lamont> which machine?
<lamont> (top of the file...)
<Riddell> Automatic build of kdebindings_4:3.4.0-0ubuntu3 on ross by sbuild/powerpc 1.170.5
* lamont will give it back
<jbailey> doko: Feh, shwab's fix doesn't seem to work.
<jbailey> It's actually in there this time, and it's the right test, but I still get the failure.
<jbailey> Oh, hm..
<jbailey> lt-ld-new: __libc_errno: TLS definition in /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a(errno.o) section .tbss mismatches non-TLS reference in /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a(check_fds.o)
<jbailey> /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a: could not read symbols: Bad value
<jbailey> FAIL: bootstrap with --static
<jbailey> feh, I thought this chroot was up to date.
<jbailey> No, gcc is point at 4.0.  So why the 3.3.6 reference?
<jbailey> Right, so I'm on total crack.
<jbailey> Two tabs to the machine, one is in the chroot, one is not.
<jbailey> Ran the build in the wrong tab.
<jbailey> =)
<doko> heh, /etc/debian_chroot in the prompt is your friend ;)
<jbailey> The sad part is that it's even there =)
<jbailey> I'm still not used to having bind mounts of my home dir in the chroots.
<jbailey> I have a new libc6-ppc64 that's current with what I'm going to upload RSN.  Do you want it for anything?
<doko> hmm, no, going to bed now. trying to understand why libjava doesn't build on amd64 with -m32, so heck, mithrandir can put it in ia32-libs-openoffice.org as well
<jbailey> Joy.
<jbailey> doko: I'm going to look at gcc-4.0 for biarch ppc64 now.  That's what waldi said he was working with.
<jbailey> doko: Have a good night.
<doko> night
<lamont>  /build/buildd/arts-1.4.0/./mcop/dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
<lamont> Please submit a full bug report,
<lamont> with preprocessed source if appropriate.
<lamont> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
<lamont> ICE baby!
<lamont> arts/hppa
<lamont> that's with the -7ubuntu6hppa2 compiler
<daniels> ice ice baby
* daniels giggles:
<daniels>   ICE:
<daniels>         * configure.ac:
<daniels>         Add ICE_t #define required by Xtrans headers. Replace static defines
<daniels>         of LOCALCONN & UNIXCONN with new XTRANS_CONNECTION_FLAGS macro.
<jbailey> doko: home/jbailey/Programming/packaging/glibc/glibc-2.3.5/build-tree/ia64-libc/csu/crtn.S:22: Error: `_init#' was not defined within procedure
<jbailey> /home/jbailey/Programming/packaging/glibc/glibc-2.3.5/build-tree/ia64-libc/csu/crtn.S:36: Error: `_fini#' was not defined within procedure
<jbailey> doko: That's building glibc with binutils 2.16
<jbailey> I got curious about the failure, since it claims that it's a TLS mismatch within glibc.
<jbailey> So I decided to try and build glibc with the new binutils to see if there was something that got fixed along the 2.15 path.
<jbailey> The closest reference I found to the failure was: http://www.darkliquid.co.uk/?item=lfs-trouble-fixed and http://lists.parisc-linux.org/pipermail/parisc-linux/2005-April/026289.html
<fabbione> morning
<fabbione> yay... build-dep madness
<jbailey> Seem CVS HEAD of glibc has a fix for the _init# stuff in the new binutils.
<jbailey> Off to sleep in the meantime....
* #ubuntu-toolchain  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<fabbione> doko: you around?
<doko> morning fabbione
<fabbione> morning dude
<fabbione> doko: the latest bash fails on sparc :(
<fabbione> i am trying to build it manuallt
<fabbione> but it hangs on a test case
<fabbione> like the original one was doing on all arches
<fabbione> run-jobs
<fabbione> and it hangs there
<fabbione> 27342 pts/0    S+     0:00 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs.tests
<fabbione> 27343 pts/0    R+     2:19 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs1.sub
<fabbione> these are the jobs running
<doko> hmm ... didn't see this on the other archs
<fabbione> jobs.tests is the main caller
<fabbione> yeah i know
<fabbione> jobs1.sub is running (100% of CPU)
<fabbione> but stracing:
<fabbione> waitpid(-1, 0xefffed8c, WUNTRACED|0x8)  = -1 EINVAL (Invalid argument)
<fabbione> it's a infinite seq of the above
<doko> amu reported something like this on amd64
<fabbione> what info can i provide you to check what is wrong?
<doko> can you try to compile with 3.3 as a workaround to lower the urgency?
<fabbione> doko: sure..
<fabbione> checking for sparc-linux-gnu-gcc... gcc-3.3
<fabbione> it's building
<fabbione> i just forced CC=gcc-3.3 in debian/rules
<fabbione> i guess that should be enough....
<doko> gcc-3.3 build for sparc:
<doko> debian/rules.d/binary-libstdcxx.mk: line 226: add a mkdir -p $(d)/$(gcc_lib_dir)/64
<doko> sparc is our only biarch gcc-3.3
<fabbione> doko: ok, do you want me to upload it? or will you?
<fabbione> or do you want me to do a test-build before upload?
<doko> have to do other fixes as well (dpkg-architecture things)
<fabbione> ok
<fabbione> did you also start building gcc-3.4?
<fabbione> i will pass by later.. gotta cook lunch
<fabbione> wife is sick
<fabbione> and my "attributes" are breaking down
<doko> hmm, it's something else, the compiler isn't built biarch :-(
<\sh> guys.../usr/X11R6/include/X11/Xlib.h should be normally /usr/include/X11/Xlib.h, right? I'm a bit confused right now ;)
<daniels> \sh: <X11/Xlib.h> is guaranteed to exist if you have libx11-dev installed and -I/usr/X11R6/include
<daniels> it may be in /usr/X11R6/include/X11/Xlib.h (where it is right now), or it may be in /usr/include/X11/Xlib.h
<daniels> (where it will be soonish)
<doko> hi daniels 
<doko> what is soonish? we could wait fixing stuff, when it ends in /usr/include soon
<daniels> doko: maybe next week, I don't know.  depends on how much time I have to spend working on other stuff
<doko> heh, it would _save_ lots of work for other people ;)
<fabbione> doko: compiling with gcc-3.3 makes no difference
<fabbione> the test case still hangs
<doko> hmm
<doko> found out, that we don't configure gcc-3.3 as biarch for sparc anymore, some more dpkg-architecture fallout
<fabbione> doko: amen....
<doko> sorry, didn't see it on the other archs
<fabbione> doko: don't worry.. it's fixable :)
<doko> before the next upload, we should decide on the target_alias, is it <cpu>-linux or <cpu>-linux-gnu ? at least binutils and gcc should match.
<daniels> doko: how many packages are ftbfs because of it?  i didn't think it was too many
<fabbione> doko: i don't care :)
<doko> daniels: from the 50 I did upload 3 or 4.
<fabbione> you guys are the toolcrap maintainers :)
<daniels> doko: heh
<fabbione> anyway.. i need to wash dishes.. and later F1 :)
<elmo> things generally broke because they were testing the output of dpkg-architecture right?
<doko> elmo: yes
<elmo> it wouldn't be hard to grep the source and see how many packages are even using that
<doko> you get many false positives, if you grep for GNU_TYPE
<doko> and you miss many, if you grep for dpkg-architecture
<elmo> how come?
<elmo> I mean just: a) get a list of packagers using dpkg-architecture, then b) eyeball them to see what they're checking
<elmo> + for
<elmo> s/rs/s/
<doko> yes, but you can use *_GNU_TYPE without calling dpkg-architecture, can't you?
<elmo> err, how?
<doko> or is on only *_ARCH set by dpkg-buildpackage?
<doko> no, they are all set by default
<doko> elmo: how should we set the target alias for binutils/gcc ? currently binutils sets a different one, depending on the dpkg version it's built with.
<doko> add the -gnu for <arch>-linux, or remove it?
<elmo> gar, that's so much crack
<elmo> well can we not grep for DEB_HOST/DEB_TARGET ?
<elmo> doko: I dunno - has keybuk appeared yet? 
<elmo> I'd really like to know why this change was made
<doko> no, i didn't see him after the dpkg upload :(
<doko> ok, for now, I'll manally set it to <arch>-linux, we shouldn't break more things at the moment, I'll fix binutils to do the same, or else the hppa64 gcc will be broken
<fabbione> F1 is starting...
<fabbione> ops
<fabbione> ECHAN :)
<doko> fabbione: why do you still watch it, or is it a must to see Ferrari loose? ;-)
<fabbione> doko: die! :P
<fabbione> there is always a hope
<daniels> of what, Ferrari losing? :)
<fabbione> i guess Keybuk is upset to death
<fabbione> since BAR has been disqualified for 3 races
<fabbione> ok let see how many damanges at the first turn
<fabbione> impressive
<fabbione> not even one!
<daniels> heh
<daniels> bar aren't exactly the best, though
<fabbione> same quality as dpkg these days
<doko> so we should disqualify keybuk as well ;)
<fabbione> eheh good point
<doko> elmo: I did upload binutils for breezy to stick with <arch>-linux, need to fix gcc-* now
<fabbione> yay
<fabbione> does that mean another gcc-* upload round?
<doko> yes, starting with 3.3
<fabbione> good.. i am happy i didn't build 3.4 yet :)
* jbailey fades into reality.
<cartman> jbailey: low priority ping
<jbailey> cartman: 'sup?
<doko> hi jbailey
<cartman> jbailey: is a binutils 2.16 update planned? I guess you take care of binutils too?
<doko> do you plan any gcc uploads today?
<jbailey> doko: Heya Matthias.
<jbailey> 'take care of' is the wrong term for my relationship with the toolchain.
<jbailey> But in any event, I'm interested in the binutils update, and am testing a  patch on glibc to make it build with binutils 2.16 on ia64 right now.
<doko> 2.16.1 is scheduled for next week
<jbailey> doko: I have questions for you.  I think I'm missing something in the biarch setup, becuase it's trying to create the 64bit packages, but isn't attempting to build the 64bit binary.
<doko> which arch?
<jbailey> ppc64
<doko> with 3.4?
<jbailey> I have it, and it's local, so I figured I'd use that to learn the biarch setup.
<doko> what does gcc-3.4 -v say?
<cartman> jbailey: thanks for info. whats the right term btw? :) for your relationship with toolchain?
<jbailey> I tried both 4.0 and 3.4
<jbailey> I notice that you usually have 2 patches to apply to the toolcahin to enable it, though.  .40 doesn't have either of them, and 3.4 only has one of them.
<jbailey> jbailey@ppc64:~$ gcc-3.4 -v
<jbailey> Lecture des spcification  partir de /usr/lib/gcc/powerpc-linux/3.4.4/specs
<jbailey> Configur avec: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gt
<jbailey> k --enable-targets=powerpc-linux,powerpc64-linux --disable-softfloat --disable-softfloat powerpc-linux
<jbailey> Modle de thread: posix
<jbailey> version gcc 3.4.4 20050408 (prerelease) (Debian 3.4.3-13ubuntu1)
<jbailey> doko: It produces a hello world binary with gcc-3.4 -m64
<doko> hmm, does it really need --enable-targets=powerpc-linux,powerpc64-linux ?
<doko> oh, yes, you are right, that is a change from 2005-03-31
<doko> at least for 3.4
<jbailey> doko: Aside from that, timing-wise I would need lamont to be around, and he's not often here on Sundays so it's not likely to be today.  Tomorrow is a holiday here and I'll be away from the computer most of the day, so Tuesday probably?
<jbailey> Ah, I see Modra's change, right.
<jbailey> I had been thinking it was entirely the packaging, my bad.
<doko> jbailey, I'll leave early on Tuesday, so maybe Wednesday.
<jbailey> doko: Sounds lovely.
<jbailey> doko: Did you read your backlog when you came on?  What do you think of the idea of just doing the biarch stuff multiarchish.
<doko> I'll do one more upload today to fix more dpkg stuff ...
<jbailey> doko: It'll make the OOo stuff you're doing a bit easier for me to fix.
<doko> yes, sounds good
<jbailey> doko: Lovely, so I'll test that config after I get this running too.
<jbailey> doko: Then do the match glibc upload and lkh upload.  Hopefully have it all the way you need by the end of the week or so?
<doko> cool
<jbailey> cartman: You could probably say 'quite interested' and 'stupid enough to hack on it when I need to'
<cartman> jbailey: ok :)
<cartman> jbailey: one of the tough things to mess
<cartman> so kudos to you :)
* jbailey points to doko.
<jbailey> cartman: Give him kudo's, he's the true madman. =)
* cartman bows to doko 
<cartman> =)
<cartman> and the debian maintainer the japanese guy I can't spell his name :/
<jbailey> doko: When I build the new binutils, install it, build the new glibc (with a patch to make it like the new gas), and then rebuild the binutils the failure goes away.
<jbailey> doko: I'm not sure the best way to track to see that this isn't corruption leaking in, or if it's a bug that was fixed.
<\sh> ah jbailey :) 
<\sh> the right person
<jbailey> \sh: Eh?
<jbailey> \sh: I'm just wandering off to play a video game...  Anything you need urgently?
<\sh> jbailey: problem with cdbs magic
<jbailey> Joy.
<jbailey> 'sup?
<\sh> arkrpg...i need to update some files (config.sub and config.guess to aclocal-1.7/automake-1.7) and it's using simple-patchsys ;)
<\sh> so whats the best way to take diffs for it ;)
<jbailey> Usually I either use the tarball method, or I cp FOO /tmp; fiddle FOO; diff -u /tmp/FOO FOO >debian/patches/###-description.patch; vi debian/patches/###-description.patch to fixup the diff headers.
<jbailey> In that case, I often fix upstream though and try to get them on a recent version of automake and autoconf.
<jbailey> There's also some stuff in the autotools.mk that you can use to auto update config.sub and config.guess
<\sh> jbailey: i read about it, but I also read that it can break ;)
<\sh> anyways, the tarball method I was thinking about :)
<jbailey> tarball method is a bit nicer for that
<jbailey> simple-patchsys sucks in a couple ways, like if you get the patch wrong, you have to back out all the applied patches by hand.
<jbailey> (patches to fix that welcome, it should be pretty easy)
<\sh> applying the patches from the debian packages beforehand, then do the work inside the source, take the patches and diff 
<jbailey> Yup.
<jbailey> We need a make_patch method.
<jbailey> Again patches welcome, but you'd probably be happier hacking it into cdbs2.
<\sh> jbailey: well..I would like to exchange simple-patchsys with dpatch magic
<jbailey> Ugh.
<jbailey> I'd really like to see dpatch go away.
<\sh> why? 
<jbailey> Simple-patchsys does a better job in that you don't have to add crap to the top of each patch.
<jbailey> And simple-patchsys will auto detect -p0 -p1 or -p2
<\sh> ok...let me try this out :) 
<jbailey> What we really need is all of the dpatch magic for handling patch files with simple-patchsys' application methods.
<jbailey> Cool, I'll be lagging for about 90 minutes to play a round, I'll check in after.
<\sh> jbailey: can I use the orig.tar.gz ? or should I use a real clean one
<\sh> sorry ;)
<jbailey> For the tarball method?  You can use the .orig.tar.gz, just dump it in the directory, then take a tarball of that to make the new .orig
<jbailey> You still don't want a Debian Native package.
<jbailey> (What we really want is Scott to implement the Wig and Penn proposal.  But *sigh*)
<jbailey> Really off now.
<jbailey> =)
<\sh> jbailey: thx and have fun now :)
<\sh> anybody up for some libGLU.so.1.3 magic?? ,-)
<fabbione>   xorg_6.8.2-16: successful
<fabbione> GO DANIELS!
<cartman> xbase-clients still depend on xlibmesa-glu instead of  libglu1-xorg
<cartman> in case its simple to fix :/
<\sh> cartman: right
<\sh> we have to recompile some packages after it's fixed i think
<cartman> yup
<\sh> kdelibs4c2 etc. gksu bla
<cartman> bzflag,libfox, rezound and some more possibly
<cartman> but they might be from universe
<cartman> not sure
<fabbione> cartman, \sh: it's pointless to spend too much time fixing xorg as it is
<fabbione> the only reason why it is still there is to provied build-deps for other packages
<cartman> fabbione: well lemme know when you want to hear whats borked =)
<fabbione> xorg as source will die pretty soon and fast
<fabbione> no we don't really care because we are going modular
<\sh> fabbione: so, replacing Build-Deps: xlibmesa-glu with libglu1-xorg?
<fabbione> once we are modular we will care again
<fabbione> \sh: it depends on what package, but yeah that should be it
<\sh> doko: please review your kdelibsc2 patch ;)
<doko> \sh, there's nothing wrong with the patch, it's the *ing xorg reorganisation at the wrong time
<fabbione> doko: can i build gcc-3.* on sparc or should i expect failures?
<doko> fabbione: it "should" work ...
<fabbione> doko: ok.
<fabbione> in that case i don't mind trashing a few hours :)
<fabbione> if it doesn't i am going to bitch slap you :P
<\sh> doko: hmmm..libglu1-xorg is replacing xlibmesa-glu so kdelibs4c2 will be removed as well..
<\sh> but it could be more worse...
<fabbione> \sh: please ... don't worry..
<fabbione> all this stuff will be sorted pretty soon
<\sh> ah...I'm a bit tired ;) I just fixed one error and the next is approaching 
<fabbione> there are automatic scripts checking these kind of stuff
<fabbione> uhuh binutils... gcc.. glibc...
<\sh> fabbione: so...right now, libglu1-xorg(-dev) is the right package for build-deps
<doko> no, libglu-dev-xorg
<\sh> or this way ;) but libglu is the right one, linked against libstdc++6
<cartman> right
<cartman> also libtunepimp2 needs to recompiled with new libmusicbrainzc2
<\sh> anyways...it doesn't solve my problems...cause libsdl1.2-dev depends on xlibmesa-glu
<cartman> \sh: isn't that just a simple depends fix + a recompile ?
<\sh> cartman: think so, but not for me today anymore...I'm stopping right here right now, trying to watch at least 2 episodes of "Lost" and then I'll try to sleep, cause tomorrow morning i have to go to work at least at 4:00am
<cartman> \sh: :/
<doko> \sh, yes, but the real problem is the xbase-client's dependency on xlibmesa-glu, which daniels has to fix
<\sh> doko: yeah
<\sh> but tomorrow is also a day...so I have to think about our BMR reboot and Divitech SI Server reboot
<\sh> it means, all non-upgrade dtv network areas in NRW are without DTV at least for 5 mins
<\sh> and those 5 mins means: please report to CTO why this had to be done :(
<doko> fabbione, daniels: do you know what the replacement for xlibmesa-dev is?
<fabbione> doko: no sorry.
<fabbione> doko: btw did you read the scrollback? bash with gcc-3.3 still hangs
<cartman> doko: libglu1-mesa-dev looks like the xlibmesa-dev replacement
<cartman> doko: looking at the conflicts at least
<doko> hmm, yes, so xlibmesa-dev -> xlibmesa-gl-dev, libglu-dev-xorg
* doko doesn't like scrollbacks today ...
* fabbione -> dinner -> cinema
<fabbione> cya tomorrow guys
<doko> see you, sparc toolcarp builder ;)
<jbailey> toolcarp?
<doko> s/ar/ra/g
<jbailey> I was imagining a fish with "gcc" written on the side. =)
<doko> sparcling carp ?
<jbailey> doko: That sounds like a nasty drink. =)
<jbailey> Fizzy cod liver oil. =)
<jbailey> doko: In the gcc-3.4 I pulled from the archive this morning, rules2 has an ifeq ($(DEB_TARGET_GNU_TYPE),powerpc-linux) and another one against ia64-linux
<jbailey> doko: How do you want things like that reported?
<doko> jbailey: fetch the fresh sources and don't complain ;-P
<jbailey> Ah, did you upload one newer than this morning?
<doko> yep, because it was broken on ia64 and sparc
<jbailey> 'kay.  I'll see how for this build gets first.
<doko> finished on i386
<jbailey> Sorry, I mean locally.
<jbailey> The biarch one.
<jbailey> Should we be updating ToolchainRoadmap directly now?  It's an approved spec, but there's things in the TODO that need tweaking (because they're done, mostly)
<jbailey> afk for food.
<doko> hmm, yes, we could, but the libraries aren't convert yet, some are still missing
<doko> daniels: we need a fixed xbase-clients package, which doesn't depend on xlibmesa-glu, but on libglu-xorg. kdelibs4-dev currently cannot be installed.
<jbailey> doko: Right, but there's a few steps done that we should probably have listed there.
<jbailey> doko: I'll ping JaneW to find out how she wants that done - then she doesn't have to chase us for status updates.
<jbailey> zul: Heya Chuck.
<zul> hey jeff how goes?
<jbailey> zul: Good, just on the phone. =)
<jbailey> Build finishes, produces libgcc_s_64.so this time, sweet.
<jbailey> there's a bad dh_link call, I'll tweak it.
<jbailey> But aside from that I might have a useful biarch ppc64 toolchain now, yay. =)
<doko> jbailey: which package?
<jbailey> doko: gcc-3.4 in rules.d/binary-gcc.mk
<jbailey> Lemme open an Xterm so I can cut and passte.
<jbailey> Under the ifeq ($(biarch),yes)
<doko> hmm, glibc for amd64 did not build
<jbailey> I think it should probably be:
<jbailey>         dh_link -p$(p_gcc) \
<jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/libgcc_s_64.so
<jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s_64.so
<jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s.so
<jbailey> You didn't have the $(PF) in there.
<doko> ok, not /lib64, but /usr/lib64
<jbailey> Right, that's where it is under debian/tmp anyway.
<doko> hmm, glibc for amd64 didn't build
<jbailey> Did it fianlly come back with a failure?
<jbailey> Probably the kernel bug again, /me checks.
<jbailey> No build log yet.
<jbailey> Where do you see the failure?
<jbailey> Hmm, no env variable for disabling libffi?
<doko> no, set with_libffi by hand ...
<doko> adding it in 4.0
<jbailey> Thanks. =)
<jbailey> The dh_link failed.  I've taken off the leading /'s but I screwed up the debuild command so I have to redo the build again. *sigh*
<doko> lamont, elmo: I updated chinstrap:~doko/cxxapps.txt, removing most of the C++ apps, after checking, that the dependencies are in. KDE stuff and stuff with mozilla-dev deps is still blocked. this new list could be updated anytime on the buildds.
<doko> then htmldoc needs to be built, which is a build-dep for fltk1.1. after fltk1.1 is built, the new cxxapps.txt can be enabled for the package syncing/package uploading. 
<jbailey> BAH! found the second typo. =)
<jbailey> testing.
<jbailey> Hmm, it's still not putting everything in the right place, although the package run goes fine.
<jbailey> doko:  Each line of that dh_link bit that I pasted above needs to grow \'s. =)
<jbailey> I'm guessing that I disabled too much, though, since it didn't make a libgcc1 package at all.
<jbailey> Oh. hmm.
<jbailey> No, that would probably be disabled for 3.4
<jbailey> *sigh*
<jbailey> So I quite possibly have a gcc-3.4 package that would work. =)
#ubuntu-toolchain 2007-05-23
<jbailey> doko: Around?
<doko> jbailey: not really, but what's up`
<doko> ?
<jbailey> doko: I think I want to make glibc on hppa build with gcc-4.2.  We're then planning a big build.
<jbailey> Should we move gcc-defaults to 4.2 for us as well to give you more info?
<jbailey> It fixes more than it regresses, it seems, so I'd like to go ahead with it.
<doko> well, maybe you should consider moving to gcc-4.2 for hppa only, that would not affect supported archs at all
<jbailey> Sorry, that's what I mean.
<doko> sure, just upload a new gcc-defaults
<jbailey> 'k.  There's no repo for it?
<doko> no, not really. I'll have to setup a separate branch in svn.debian.org
<jbailey> Sounds good.  Do you want me to make the glibc change just in the repo and wait for you to upload, or do you mind if I upload?
<doko> please do the upload and checkin, I have not plans for a glibc update at the moment
<jbailey> doko: lovely, thanks.
<jbailey> lamont: Any last requests?
* doko heads to bed now
<jbailey> doko: g'n, thx!
<lamont> jbailey: rock on!
<lamont> and tell me, since I'll have to manually kick the build(s)
<lamont> as in package and version :)
<jbailey> lamont: Will do.
<jbailey> Leif is almost asleep
<jbailey> so i'll get started shortly
<Mithrandir> meh, why does dpkg-architecture not include the vendor field in the default output?
<Keybuk> we've never used it
<Mithrandir> we might want to use it for lpia.
<Mithrandir> do you think anything would break if I added it?
<Keybuk> nothing should break
<Keybuk> as long as you use the same variable names
<Keybuk> adding DEB_*_*_VENDOR= should be fine
<Keybuk> I've done far worse things to dpkg-architecture in the past
<Keybuk> I added the DEB_*_ARCH_OS and DEB_*_ARCH_CPU and that didn't break anything
<Keybuk> though you probably don't need DEB_*_ARCH_VENDOR since that would involve creating i386-linux-intel type Debian arch strings
<Keybuk> it's enough to have DEB_*_GNU_VENDOR and change DEB_*_ARCH_CPU based on that
<Keybuk> DEB_BUILD_ARCH=lpia
<Keybuk> DEB_BUILD_ARCH_OS=linux
<Keybuk> DEB_BUILD_ARCH_CPU=lpia
<Keybuk> DEB_BUILD_GNU_CPU=i386
<Keybuk> DEB_BUILD_GNU_VENDOR=intel
<Keybuk> DEB_BUILD_GNU_SYSTEM=linux-gnu
<Keybuk> DEB_BUILD_GNU_TYPE=i386-intel-linux-gnu
<Keybuk> or something
<Mithrandir> yeah, that's what I was thinking.
<Mithrandir> (apart from making vendor = lpia, but that's a detail)
<Mithrandir> pondering if I should have a vendortable, in the spirit of ostable and cputable
<Keybuk> no
<Keybuk> ostable and cputable are the two sides of the "linux-i386" type strings that dpkg uses
<Keybuk> linux-i386 being the proper, long name of i386
<Mithrandir> so where should the vendor string be encoded then?
<Mithrandir> s/encoded/recorded/
<Keybuk> fix cputable
<Keybuk> so the i386 Debian CPU name is based off both the cpu and vendor parts of the triplet
<Keybuk> and lpia likewise
<Keybuk> otherwise you could, I guess, have something like
<Keybuk> lpia    i386    lpia
<Keybuk> in a vendortable; saying that if the config.guess vendor bit is "lpia", and the Debian CPU is "i386" then the Debian CPU becomes lpia
<Keybuk> I'd just add a extra field to cputable though
<Mithrandir> yeah, I guess I can do that.
<Keybuk> since it's been documented that awk '{print $1}' of that is the full list of Debian CPU names
<Keybuk> and you'd want lpia to be in that list
<Keybuk> i386            i486            (i[3456] 86|pentium)
<Keybuk> lpia            i486            (i[3456] 86|pentium)        lpia
<Keybuk> (extra field matches against vendor part?)
<Keybuk> they might have to be the other way around, I think it's first match wins
<Mithrandir> it's stuffed into a hash
<Mithrandir> and it should then try to do a best-match, probably
<Keybuk> is it?
<Keybuk> ah, remember, dpkg-architecture is backwards
<Mithrandir>             $cputable{$1} = $2;
<Mithrandir>             $cputable_re{$1} = $3;
<Mithrandir> it does  push @cpu, $1;
<Mithrandir> though
<Keybuk> there's also some m4 in dpkg's build scripts
<Keybuk> m4/arch.m4
<Keybuk> ah, that uses dpkg-architecture now
<Keybuk> interesting
<Mithrandir> hmm, I wonder if I should have a default vendor name for arches where none is specified
<jbailey> doko: Hey - why does gcc-defaults insist on installing packages as part of build-deps?
<doko> jbailey: "installing packages"?
<jbailey> We don't have a functional gij on hppa yet, which is causing us a bit of grief.
<jbailey> It looks like the rules file doesn't need anything more than build-essential.
<doko> right, the b-d's on the base packages are there so that the gcc-defaults package is not built before all dependencies on an arch are available
<jbailey> Ah, okay.
<jbailey> Hmm
<doko> but just drop the b-d on gcj-4.1-base, it doesn't work
<jbailey> 'kay.
<jbailey> Thanks.  I'll squeeze this in during a break later.  I think I otherwise got all of the adding 4.2 stuff right.
#ubuntu-toolchain 2009-05-21
<rch00441> Testing message
