#ubuntu-toolchain 2005-06-20
<fabbione> morning
<jbailey> fabbione: Still not sleeping well?
<fabbione> jbailey: no.. not really
<fabbione> there was too much light in the bed room
<fabbione> and i woke up 
<fabbione> oh well i need to fix that problem asap
<fabbione> otherwise i will get stupid
<jbailey> at 4am?
<jbailey> Too much light?
<jbailey> sick.
<fabbione> when it's summer in dk, the sun goes up at 3am and down at 00am :/
<fabbione> it's like 20 hours of light
<fabbione> in winter is the other way around
<jbailey> The further north I've lived was 49
<jbailey> I think we're at like 45 now.
<fabbione> i can't remember how much we are now
<fabbione> it's +56 (almost) here
<chmj> doko, ping 
<chmj> jbailey, ping 
<doko> chmj: pong
<fabbione> doko: fix gcc-3.4. kthxbye
<fabbione> doko: fix gcc-3.4. kthxbye
<doko_> fabbione: waiting for elmo to approve binutils 2.16 before. kthxbye
<fabbione> doko_: the kernel is FTBFS due to the i486-linux-gnu-gcc-wtf-gth symlinks
<doko_> fabbione, and it doesn't help you without i486-linux-gnu-ld symlinks. be patient
<chmj> doko, can you have a look at http://people.ubuntu.com/~charles/glibc_232.debdiff please 
<chmj> that should fix binutils FTBFS
* chmj lunch 
<fabbione> doko_: do i have any other option? ;)
* fabbione -> food
<doko_> chmj: I'm waiting for jbailey, if that's still necessary with binutils 2.16 ...
<chmj> doko_, ok 
<jbailey> doko: Eh?
<doko> jbailey: chmj's patch ...
<chmj> jbailey, hi 
<chmj> jbailey ---> http://people.ubuntu.com/~charles/glibc_232.debdiff
<jbailey> Right, this is for gdb compiling on ppc, yes?
<chmj> binutils 
<jbailey> 2.15 or 2.16?
<jbailey> chmj: I'm a bit confused, because the patch is against the version in Hoary.
<chmj> http://people.ubuntu.com/~lamont/buildLogs/b/binutils/2.15-5ubuntu3/
<chmj> oh, doko uploaded a new version 
<jbailey> But in general, the glibc patch you made is against the version in Hoary. =)
<jbailey> doko: I hadn't realised binutils wasn't being updated as well, I'll do the new glibc upload right away then.
<jbailey> Oh, not in the new version.
* jbailey is a bit confused, but it's morning. =)
<chmj> jbailey, erm, just disregard it
<daniels> jbailey: 'morning' and 'confused' are redundant
<jbailey> Well, the patch is one that I need in 2.3.5 anyway, so thanks.  If you're hacking on glibc in the future, we have a template.dpatch file in the patches subdir that we usually use for the top so that we have the comments in a prefered format.
<jbailey> Just makes it a bit easier. =)
<jbailey> daniels: =)
<chmj> jbailey, sweet 
<jbailey> chmj: Are you looking to dive in more to toolchain stuff?
<fabbione> jbailey: he is 0wn3d by the kernel team! put your hands off
<chmj> sure 
<chmj> heheh 
<fabbione> ehhehe
<chmj> jbailey, oh btw, cdbs2 and kernel build ? 
<jbailey> fabbione: I'll mud wresstle you for 'im!
<fabbione> jbailey: any time :)
<jbailey> chmj: Sounds lovely. =)  The module doesn't exist yet.  Got hack time?
* fabbione wears his sumo underwear
<chmj> jbailey, I remember we discussed doing that 
<jbailey> Right.  If you have hack time, I suspect that it's doable now.
<chmj> jbailey, ok
<jbailey> Probably the best thing to do would be to do a proof-of-concept and then bribe Fabio.
<doko> jbailey, as it looks like, the patch is still needed for powerpc, and now ..., so I point fabbione to you for the non-working toolchain ;-P
<fabbione> toolchain is broken = i can't build the kernel
<fabbione> fix it
<fabbione> kthxbye
<jbailey> Erm, that doesn't make sense.
<jbailey> Your kernel shouldn't be using glibc to build it, dude. =)
<fabbione> no but it needs gcc-3.4
<chmj> heh
<fabbione> that is actually broken
<fabbione> and still part of "toolchain"
<doko> fabbione, you're still annoying, I thought you got some food ... ;)
<daniels> hey, if the toolchain is broken, then I can't build xorg, either
<jbailey> fabbione: What part is broken?  We built gcc-3.4 with breezy recently for the ppc64 stuff, so it built then.
<fabbione> jbailey: the borkage is introduced by the new dpkg
<fabbione> missing i486-linux-gnu-gcc-ld-wtf-gth-fym symlinks :)
<fabbione> doko: that's only because i love you :)
<jbailey> doko: Sounds like you just need to push a new gcc-3.4 so that it builds as i486-linux instead of i386-linux...
<doko> daniels: nah, no excuse for you, you're not using the symlinks ;-P
<doko> jbailey: yes, depending on the new binutils, which do have this change as well, failing on powerpc, because of a glibc bug ...
<doko> remember, it's c-h-a-i-n in toolchain :)
<fabbione> like in nuclear C-H-A-I-N reaction?
<daniels> doko: hah, I'll start using the symlinks if it gives me an excuse :P
<fabbione> anyway i am off for a nap
<fabbione> later guys
<jbailey> fabbione: More like a c-h-a-i-n gang, where we all shovel coal.
<daniels> night fabbione
<doko> jbailey: one more glibc change: please add an /usr/hppa64-linux/gnu symlink
<jbailey> Eh?  I thought that was in there already..
<doko> no /usr/hppa64-linux/include, but not /usr/hppa64-linux-gnu/include
<jbailey> Oh, I see.
<jbailey> So have two symlinks, or just change it?
<doko> two would be ok for some time until all compilers are rebuilt
<jbailey> 'k
<doko> so, need this in unstable as well ...
<jbailey> fabbione: ping?
<doko> jbailey uploads glibc:
<doko> * Drop support for Neanderthal Sparc systems (fabbione, it was a nice time, kthxbye)
<jbailey> lamont__: Confirm okay to disable glibc testsuite for hppa to make it just build for you?
<lamont__> jbailey: works for me...
<lamont__> of course, we'll want to work towards being able to enable it again, eh?
<jbailey> Yes, dear.
<jbailey> I have an idea what the problem is, but ENOTIME
<lamont__> heh
* lamont__ finds that the first half of that sometimes applies, but the 2nd half almost always does
<lamont__> in my case, that is.
<jbailey> doko:
<jbailey> ln -sf /usr/include debian/$(curpass)/usr/hppa64-linux/include
<jbailey> ln -sf /usr/include debian/$(curpass)/usr/hppa64-linux-gnu/include
<jbailey> yes?
<doko> yes, the former should already exist
<fabbione> jbailey: pong
<jbailey> Yup
<jbailey> fabbione: Two things.
<fabbione> jbailey: yes?
<jbailey> 1) I'd like to do some of the sparc magic, but I didn't have time for a test round this weekend.  Is there any way you tell the buildd not to auto-sign glibc so I can look at the log before it gets pushed?
<jbailey> (I don't type that fast, dude. *g*)
<jbailey> 2) What am I looking for in the ppc kernel build?
<fabbione> 1) i can blacklist it and build it manually.. yes
<fabbione> 2) a possible FTBFS at the end of the process
<fabbione> 2) if it works is a davis issue
<jbailey> 1) Please.  I expect it to work, but I don't actually know.  If you'd rather I can delay it and do a testing round later.
<fabbione> jbailey: i had say that you upload it, i build it, but not upload the binaries. we install them in a chroot and play a bit
<jbailey> Sounds gt
<fabbione> jbailey: ok.. glibc is blacklisted
<fabbione> upload anytime you want :)
<jbailey> I've just started the amd64 and i386 test builds.
<jbailey> ppc testbuild started.
<jbailey> ia64 is just updating its chroot.
<fabbione> jbailey: how is the kernel build going?
<jbailey> It's in drivers/sata
<jbailey> err. drivers/scsi/sata
<fabbione> of what flavour? :)
<jbailey> How do I tell?
<fabbione> jbailey: the old fashion way ;)
<fabbione> cd debian/build && for i in `ls`; do du -sk $i; done
<jbailey> Guess and hope noone notices if you're wrong?
<fabbione> you will see by the size :)
<jbailey> Ah. =)  With glibc, we keep a local log file for each one, so I just look to see which one is growing. =)
<fabbione> jbailey: Manoj accepted both our patches
<fabbione> and that's perfect
<fabbione> iirc there is only one inliner left :)
<fabbione> and i need to go off
<fabbione> time to prepare dinner
<fabbione> cya tomorrow guys
<jbailey> 423952  build-powerpc64-smp
<jbailey> Is the one getting bigger atm.
<fabbione> linux-* doesn't get bigger
<fabbione> only the build-*
<fabbione> so you should have almost done
<fabbione> but the failure happens after all the build-* are done
<fabbione> anyway thanks a lot
<fabbione> cya later
<jbailey> fabbione: glad to help =)
<jbailey> ia64 build started.
<jbailey> doko: These four should finish about when I get back from lunch.  Assuming success, I'll push it up.
<doko> fine
<doko> http://gcc.gnu.org/ml/gcc/2005-06/msg00420.html
<BenM_> doko, ?
<BenM_> tseng sent me to you
<BenM_> I am a mono dev, and am having trouble on gcc 4.0
<jbailey> Tests fine on my 4 systems, uploading.
<jbailey> glibc_2.3.5-1ubuntu5_source.changes ACCEPTED
<lamont__> jbailey: do you want to know that the ppc build of glibc failed?
<jbailey> lamont__: I hadn't checked up on it yet.  Did you see why it failed?
<lamont__> jbailey: no - just got the mailer daemon notification for over-size mail
* lamont__ looks
<jbailey> np, dl'ing
<jbailey> wtf?
<lamont__>   install_root=/build/buildd/glibc-2.3.5/debian/tmp-ppc64 install
<lamont__> make[1] : Entering directory `/build/buildd/glibc-2.3.5/build-tree/powerpc-ppc64'
<lamont__> make[1] : *** No rule to make target `install'.  Stop.
<lamont__> make[1] : Leaving directory `/build/buildd/glibc-2.3.5/build-tree/powerpc-ppc64'
* lamont__ giggles
<jbailey> checking for forced unwind support... no
<jbailey> configure: error: forced unwind support is required
<jbailey> That's the real failure.
<lamont__> ah, ok
#ubuntu-toolchain 2005-06-21
<jbailey> Bah.
<jbailey> I just retested locally, and it doesn't fail there.
* jbailey sets up a minimal chroot.
<lamont__> jbailey: minimal chroot?  (maybe missing build-deps?)
<jbailey> Right, I usually test in a chroot I use for development.
<jbailey> I don't see how it built before if it was missing a build-dep, but I've slimmed down the chroot for this build.
<jbailey> I think I need to hack glibc (and maybe cdbs) so that if a build fails at configure time that config.log is spit to stdout.
<jbailey> Mm, missing build-dep on the bit the provides libcgcc_s_64
<jbailey> erm
<jbailey> or not.
<jbailey> That's provided by gcc-3.4 supposedly.
<jbailey> doko: Still around?
<doko> yep
<jbailey> doko: I figured it out.  collect2 was acting strange, but I hadn't realised that gcc would change its arguments to collect2 based on what was available.
<jbailey> lamont__: In Debian (and in Ubuntu if you know...) is libc6-dev-sparc64 usually already in the base chroots / is it part of build essential?
<jbailey> lamont__: I'd like to have ppc64 be consistant with current practice for sparc/s390
<lamont__> jbailey: nfc
<lamont__> for it to be there (properly), it needs to either be essential, or a Depend: of build-essential
<doko> only for sparc, not s390
<BenM> Hey doko, tseng sent me to you
<doko> BenM: i
<doko> BenM: hi
<BenM> mono is failing its regression test on gcc4
<BenM> and tseng thought you might be able to help out
<doko> jbailey, lamont__: b-e lists the 64bit dev only for sparc, not s390
<doko> BenM: I do? hmm. all of them?
<BenM> well, one specific test case gets a segfault
<BenM> we are pretty sure something is getting miscompiled
<BenM> http://primates.ximian.com/~bmaurer/mono-1.1.8.tar.gz
<BenM> its reproducable on that
<BenM> you just have to configure; make; make check
<doko> what does happen, if you reduce the optimization level? any warnings?
<BenM> it happens both on -O2 and -O0
<BenM> no warnings for the file other than pointer signedness
<doko> ahh, you know the file. does gcc-3.4 work?
<BenM> yes
<BenM> well, by that i mean "the file where the backtrace says the segfault happens"
<BenM> there isn't anything suspcious in the entire build log though
<jbailey> lamont__: Any objection to it being added to b-e?
<doko> so, if you compile the testcase with 3.4, the testcase works? or a file from the distribution?
<lamont__> jbailey: that gets back to the question of whether or not it is build-essential...
<BenM> well, the test case is c# :-)
<lamont__> jbailey: for which, I'd recommend a discussion with the build-essential maintainer
<lamont__> == keybuk
<BenM> the issue is, if I compile mono using gcc4, it fails
<BenM> if i compile mono with gcc!=4, it works fine
<jbailey> lamont: I couldn't remember your email address, so I didn't cc: you, but I've emailed scott.  If it turns out that it gets added to b-e, we just need to respin the build, otherwise I'll need to add the build-dep
<jbailey> lamont: Did you keep your ubuntu.com address?  I remember that sabdfl was talking about them being available to members, so thought you might be  testcase. =)
<lamont> jbailey: yes, still have ubuntu.com
<jbailey> Luvly
<BenM> doko, gotten a chance to try that tarball yet
<BenM> ?
<fabbione> morning
<fabbione> lamont: ping?
<lamont> ack
<fabbione> lamont: we will need to revert the gcc-3.4 b-d stuff...
<lamont> fabbione: having difficulty verifying that ipsec traffic is passing back through INPUT once unencapsulated.
<lamont> iz annoying
<lamont> fabbione: why?
<fabbione> unfortunatly we need the latest gcc and latesr k-p to build
<lamont> on all architectures?
<fabbione> 11753
<fabbione> no only i386
<lamont> because the relaxed check made it so that I could build... :-)
<fabbione> yeah i know
<lamont> ah, so make the build-dep be powerpc i386
<fabbione> yeah that too
<fabbione> kernel-package (>= 8.135ubuntu4) [powerpc] , kernel-package (>= 8.132ubuntu2) [!powerpc]  ???
<fabbione> kernel-package is arch all
<fabbione> but we will need to upgrade that too :/
<fabbione> gcc-3.4 (>= 3.4.4-0ubuntu6) [powerpc i386] , gcc-3.4 [!powerpc !i386] 
<fabbione> does it look sane?
<fabbione> i can never remeber how to add more than arch to [] 
<lamont> I believe that's it
<lamont> (comma is right out..)
<fabbione> yeah i did check with other packages too :)
<fabbione> lamont: what did you change in the configs?
<lamont> fabbione: I added the missing lines.
<lamont> R2[45] 00, SQUASHFS, HOSTAP
<fabbione> ah ok
<fabbione> it was just an update
<lamont> well, it was a 'fix hppa configs since they didn't get updated with the addition of the drivers'... but I shortened that...
<fabbione> humm
<fabbione> sorry.. i might have done that in a different way recently
<chmj> jbailey, thanks for the patch 
<jbailey> chmj: Glad to show it to you. =)  IT's just really nice to have all that information for tracking.
<jbailey> chmj: We found that we were starting to lose track of where things things came from and why we did them. =)
<chmj> oh ok, that format sure has enough info 
<jbailey> doko: I thought sparc killed the wrapper a couple years ago on the grounds that it was unpredictable and that it sucked? 
<jbailey> lamont, fabbione: ping re: builds of glibc on your archs. =)
<fabbione> jbailey: i am still building gcc-*
<fabbione> jbailey: once it's done i will do glibc
<jbailey> fabbione: Cool.
<fabbione> it's running the test-suite right now
<fabbione> it shouldn't take too long
<jbailey> Any idea how the hack is going to get the build-logs onto people so I can just see them myself?
<doko> jbailey: no, the thread on d-sparc
<doko> jbailey: so you upload a glibc with fixed b-d's?
<jbailey> doko: Ah, a'ight.
<fabbione> jbailey: i didn't manage to talk with elmo in a few days
<fabbione> jbailey: i will need to check with him
<jbailey> doko: I haven't.  If we're adding it to build-essential, it just needs a give-back.
<jbailey> doko: (I've also been awake for about 10 minutes)
<doko> jbailey: as you like it, but for packages like zlib1g and others, we should explicitely add it.
<jbailey> Why?
<doko> push back a package to Debian and it will fail
<doko> it's not a big job to add that b-d for these few packages
<jbailey> True.  I just hate b-d'ing on b-e packages.
<doko> so we should add amd64-libs-dev to b-e as well?
<jbailey> That's the question. =)
<jbailey> Or should sparc be made like the others and have sparc64 dropped from b-e?
<doko> no, then we have to change the gcc wrapper as well ...
<jbailey> We should be treating biarch configs consistently.
<doko> but what about an update for amd64-libs to match our current glibc before we go multiarch?
<doko> Mithrandir: ^^^
<jbailey> But I tend to fall on the side of thinking that the sparc-gcc wrapper is teh suck.
<jbailey> right!  That's what I was going to ask you yesterday! =)
<jbailey> To just clarify the include directories so I could do the glibc work for i386/amd64 and amd64/i386 biarch
<doko> jbailey: I don't like it either, but BenC defends it
<jbailey> Is benc the only one who defends it?  At this point I'd take joshk's word over ben's for the sparc port.
<fabbione> jbailey: did you complete the kernel build with a ppc32 kernel?
<doko> I would have to look
<jbailey> fabbione: BAh, that's what I was supposed to do last night, sorry.  No, lemme reboot and start it now.
<fabbione> eheh ok :) thanks
<fabbione> there is no rush really
<fabbione> i am not going to upload anytime soon
<fabbione> i need to go and prepare food
<fabbione> bbl
<jbailey> doko: I'm just updating the status of my stuff for the wiki.  Want me to update ToolChainRoadmap?  I was thinking "C++ transition still in progress, ppc64 uploaded"
<doko> sure
<jbailey> Mm, and java bits in main?
<jbailey> and C++ done for main
* jbailey adds b-d for now to ppc
<doko> still waiting for the OOo2 build ...
<jbailey> glibc with added build-dep uploaded
<infinity> doko : Which OOo2 build are you waiting on?
<infinity> doko : It was successful on i386/ppc, failed on amd64/ia64.
<doko_> infinity: oh, nice, I didn't see them succeed, you know, the upload was done some months ago ;)
<lamont> ln -sf /usr/include debian/libc6-dev/usr/hppa64-linux-gnu/include
<lamont> ln: creating symbolic link `debian/libc6-dev/usr/hppa64-linux-gnu/include' to `/usr/include': No such file or directory
<lamont> jbailey: that's the error I get from -5...
<lamont> seems kinda familiar.. :-)
<lamont> -6 is downloading now, build will happen sometime today, I expect.
<Mithrandir> doko: amd64-libs is utterly uninteresting to me and jbailey have some things up his sleeve to get rid of it, afaik.
<doko> Mithrandir: ok, would it be possible to keep building gcc-4.0 biarch in unstable ? would be a good thing to point people to it as a test for 64bit compatibility
<Mithrandir> doko: yes, I think that would be a good thing.
<doko> Mithrandir: asking, because it's NOT possible to build gcc-4.0 biarch in breezy at the moment
<doko> I think we face the same problem in unstable once glibc get's updated?
<jbailey> lamont: Don't bother with -6 then.
<Mithrandir> doko: why isn't that possible?
<doko> Mithrandir: build failure, just try to build the package with an installed amd64-libs-dev.
<doko> IIRC, even if biarch is disabled
<jbailey> doko: ln: creating symbolic link `debian/libc6-dev/usr/hppa64-linux-gnu/include' to `/usr/include': No such file or directory
<jbailey> doko: Who provides /usr/hppa64-linux-gnu ?
<jbailey> Do we?
<doko> hmm, glibc should provide that
<jbailey> 'kay, I'll add the mkdir.
<doko> it doesn't hurt. ok, it' currently not yet available, because I didn't build a hppa64 compiler yet.
<doko> infinity, lamont, lamont__: please requeue binutils for powerpc, if this is built and in the archives, then gcc-3.3 and gcc-3.4 for powerpc.
<lamont__> doko: binutils kicked
<doko> lamont__: thanks
* lamont__ sighs, updates the chroots on ppc, and prepares to give binutils back again
<jbailey> doko: Thanks
<jbailey> lamont__: If you can do the same for ppc that would be lovely.
<jbailey> err
<jbailey> gdb on ppc
<lamont__> jbailey: ok.  but grumbling about gdb just doesn't seem kind until after an incomplete statement of work. :-)
* lamont__ grumbles about gdb.
<lamont__> there -you happy>
<jbailey> Wha...? =)
<lamont__> you just want it given back?  or do I need to actually _do_ something to the chroot first?
<lamont__> ah, same 'needs new procfs.h' issue
<jbailey> Sorry, I had assumed this was in the queue after the "updates chroots on ppc" =)
<lamont__> lol
<jbailey> Bad optimiser!  Stop applying yourself to human interactions!
* lamont__ is fighting with ipsec.  makes for a cranky mood
<elmo> doko: have you seen this fun "gcc-4 miscompiles glibc" bug?
<jbailey> elmo: Doesn't affect us, we use gcc-3.4 to compile glibc.
<elmo> score
<elmo> can we make it a goal to not be using gcc-3.4 for anything by breezy?
<elmo> or is there anything that's unlikely to be compilable by 4.0 by release?
<jbailey> I think we'd planned on glibc and the kernel staying with 3.4
<jbailey> We still need 3.4 in the archive for g77 anyway, so we're not losing much.
<elmo> whine
<elmo> ok
<jbailey> Neither upstream is advocating gcc 4 anyway.  glibc 2.3.5 doesn't compile with gcc-3.4 without patches.  The bug you're thinking of is for CVS HEAD of glibc.
<elmo> yeah, it just makes me cry that we're carrying 4 compilers around
<elmo> and using one of them to only compile basically two packages
<jbailey> 4?
<elmo> 2.95/3.3/3.4/4.0
<jbailey> I thought we had dropped 2.95 already
<elmo>   gcc-2.95 | 2.95.4.ds15-22 | breezy/universe | source
<jbailey> Oh, hmm.
<jbailey> NEeded to compile silo for sparc still.
<elmo> it's kind of nice for some commerical crap too
<jbailey> Feh
<elmo> well, if you have a better way to monitor hardware raid array on big 3 servers, lemme know :p
<jbailey> But 3.4 will probably need to stick around until the 4.2 timeframe when fortran catches up.
<elmo> that long?  ouch
<jbailey> Follow 4.1, it doesn't look like fortran is moving fast to get the old g77 specific bits in.
<jbailey> s/Follow/I've been following
<jbailey> Is it build errors in software that you can change, or linking problems from precompiled modules?
<elmo> latter
<elmo> not modules tho, just binary progs
<elmo> usually linked to old libstdc++
<elmo> it's not a huge problem, there are newer versions for FC 4 and so on, but I've had other problems with them
<elmo> (glibc symbol errors RUN AWAY)
<jbailey> afk a sec
<jbailey> Right.  Those should probably all work fine against the breezy glibc.
<jbailey> elmo: (And everyone knows that backports of glibc are a good idea.. Right kids?)
<lamont__> jbailey: B4CKP0R75 RUL3Z!
<lamont__> hey, I know.  lets backport breezy to Bo.
<lamont__> All of it.
<jbailey> lamont__: package by package or feature by feature?
<lamont__> package-by-package in one fell swoop
<lamont__> and build it twice, of course. :-)
<jbailey> (/me fears how hard allowing bo to seamlessly dist-upgrade to breezy would be)
<elmo> jbailey: chicken
<lamont__> jbailey: best accomplished via rapid injection of lead into the crainal cavity
<lamont__> cranial?
<jbailey> I'm a tofudebeast, a far fiercer animal.
<lamont__> jbailey: call the result frankenstein - people will expect seams that way.
<fabbione> jbailey: right now silo is building with the default gcc... i removed the strict b-d to allow silo in main
<jbailey> fabbione: Ah?  I thought benc said it didn't work?
<fabbione> it doesn't ALWAYS work
<fabbione> it does most of the time
<jbailey> But..  it's *silo*
<jbailey> That's the way it is even with gcc-2.95 compiling it.
<fabbione> jbailey: tough.. i am not going to commit to support gcc-2.95 in main because of silo
<fabbione> if it boots.. good.. otherwise bitch upstream to fix silo :)
<jbailey> benc doesn't answer *questions* I have, I can't imagine him answeing me asking him to do actual work. =)
<fabbione> jbailey: he is busy working to make his own business
<fabbione> but i can still ping him on irc when he is around
<fabbione> : idle     : 61 hours 24 mins 0 secs (signon: Sun Jun 12 08:14:43 2005)
<fabbione> anyway
<fabbione> time to be with my wife :)
<fabbione> cya tomorrow guys
#ubuntu-toolchain 2005-06-22
<elmo> jbailey: DUDE
<doko> elmo: do you want to demote 3.3 from main to universe?
<jbailey> elmo: eh?
<elmo> jbailey: are you going to undo that CDBS brain damage where the build-depends get generated ont he fly?
<elmo> doko: a bunch of stuff still uses it?
<jbailey> elmo: What jrg and I talked about for cdbs2 (since it's too late to undo it for cdbs1) is that we'll still provide the facility, but that it will be wired such that if debian/control is out of date at build time, it'll just fail the build.
<doko> well, yes. so we'll have 3 in main and the 4th in universe
<jbailey> elmo: cdbs is in a good position to know information for calculating build-deps, but it needs to really not happen at buildd time.
<elmo> jbailey: why's it too late? :P
<jbailey> elmo: Things are using it.
<elmo> SATAN WORSHIPPERS 
<jbailey> elmo: dh_make --cdbs for some reason uses it by default. =(
<jbailey> Just insanity.
<elmo> ARGH
<elmo> those  people are THROWING BABY JESUS ONTO A PYRE AND LAUGHING ALL THE WHILE\
<jbailey> Wow, elmo is channelling a mix of mjg59 and overfiend.
* jbailey runs.
<elmo> jbailey: why is it _ever_ adding build-essential tho?
<elmo> ignoring for one moment the whole auto-update insanity
* jbailey glances at the ubuntulog bot and sensors what he was going to say.
<jbailey> nfi
<jbailey> Wasn't my hack. =(  It went quite a bit further than I expected it would, even under Robert Millan's care.
* jbailey wanders off to the gym singing "Sam Hall"
<lamont> jbailey: censors
<lamont> sensoring is something much more touchy-feely
<jbailey> lamont: Right.  I get that wrong because of a church conference I went to called 'unsensored' as a pun.
<daniels> heh
<fabbione> morning
<elmo> infinity/lamont: d-i daily auto-builds are being flaky
<elmo> as in, not turning up for a random 2/4 arches
<fabbione> elmo: did you install the ppc64 kernel on any of the buildd??
<elmo> fabbione: not yet - do you need me to?
<fabbione> elmo: perfect. no don't :)
<fabbione> i found a regression in building ppc kernels on ppc64 running machines
<elmo> hehe
<fabbione> elmo: somehow it breaks headers build
<fabbione> and i didn't have the time to track it down yet
<fabbione> it took a while to understand why davis was FTBFS while it was ok on the buildd :)
<fabbione> elmo: if you have time i need a dist-upgrade on breezy/{concordia,davis,hally} and breezy-i386/concordia to get all the latest kernel-packages, gcc-3.4
<elmo> btw has davis' stability continued?
<fabbione> elmo: yup.. not a single problem other than that regression
<elmo> woo
<fabbione> elmo: i pushed it up to -j300 with no problems
<fabbione> the ppc scheduler >> *
<fabbione> and you know i am good at pushing machine.. given nagios waking you up everytime i upload :P
<elmo> fabbione: done
<fabbione> elmo: thanks
* fabbione starts a build orgy
<jbailey> fabbione: ping?
<fabbione> jbailey: pong
<jbailey> fabbione: Tell me good things about glibc on sparc? =)
<fabbione> it's building :)
<fabbione> it's half way trough
<jbailey> Can you peek into the source directory?  It would be interesting to see if it's finished the first pass, and if so, was it succesful or did it error?
<fabbione> jbailey: i am saving the entire buildlog
<fabbione> so you can look at it when it's done
<fabbione> actually.. you can check yourself too :)
<fabbione> you can still ssh to the sparcbuildd :)
<fabbione> it's building in chroots/manual/home/sparcbuildd/
<jbailey> BAh.  Cat just threw up for the 6th or 7th time this morning. =(
<fabbione> *sighs*
<jbailey> fabbione: First pass looks good as sparcv9 minimum and nptl
<fabbione> jbailey: cool
<jbailey> It's way less than halfway done, though, I think.
<fabbione> yeah it's around half way
<fabbione> the previous log was 43MB
<fabbione> this is around 20
<fabbione> but if you disabled stuff around, i expect the log to be smaller
<jbailey> Right, I disabled one full pass.
<jbailey> I don't see any reason why the v9b build would fail from here.  sparc64 didn't change yet.
<fabbione> so no NTPL?
<jbailey> Not for sparc64, yes for the others.
<fabbione> ok
<jbailey> It needs binutils 2.16.1 and some extra patches.
<fabbione> ah ok
<jbailey> So early next week maybe...
<fabbione> yeah no rush dude :)
<jbailey> Yeah, but it would be nice to have kickass sparc support in a mainstream distro. =)
<fabbione> than we should get more buildd's :)
<fabbione> we are in catch 22 right now
<fabbione> but i am getting a nice buildd from maswan
<fabbione> i hope to get it up and running soon
<jbailey> fabbione: I can probably fire up this u5 to help along, too, after I move.
<fabbione> jbailey: with the u5 it would be better to test the installer and so on
<fabbione> we really need somebody to test :)
<fabbione> and i can do it when i am not building
<jbailey> 'k =)
<jbailey> I almost brought an E250 home with me from my last place of employment, but the thing is too loud, I never would've run it.
<fabbione> when are you going to finish your relocation btw?
<fabbione> yeah i know the e250 :)
<fabbione> nice toy
<jbailey> I do my actual move on July 4th.
<jbailey> It's to a new city, so I'm not doing one of these 'spread out over 4 days' types of moves. =)
<fabbione> lucky you
<fabbione> it took me ages to change city
<fabbione> moving stuff myself
<chmj> <-- has to move also 
<jbailey> fabbione: We're loading everything into one big truck, driving for 7 hours, and unloading.
<fabbione> jbailey: that's the best.. really
<fabbione> one shot and that's it
<jbailey> Yup.
<jbailey> And we've hired people in the remote city to handle getting it from the truck into the appt.
<jbailey> We'll be way too tired after all that to figure out how to get furniture up two tight flights of stairs.
<fabbione> wise :)
<jbailey> I've gained so many things over the years.  I can only hope that wisdom is one of them. ;)
<jbailey> s/hope/pray... beg..../
<fabbione> ehhehe
<jbailey> fabbione: Neat, v9b compiled fine.
<fabbione> jbailey: cool
<jbailey> I wonder how much difference there really is between v9 and v9b
<fabbione> no clue :)
<fabbione> that's your playground :)
<jbailey> Fabio, my friend...
<jbailey> *you're* the sparc port guy. =)
<fabbione> jbailey: you are the glibc guys :P
<jbailey> I've asked someone.  I'm curious if just the hwcap was different, so v9b systems weren't picking up the v9 optimisations. 
<jbailey> It would be nice if we could drop that pass completely, too.
<jbailey> And then my last big dream for sparc:  Kill the gcc wrapper. =)
<fabbione> ahhaha
<chmj> jbailey, 
<jbailey> chmj: Here
<chmj> I forgot what I wanted to say 
<jbailey> I've started to give comments after the word ping now so that I stop forgetting. =)
<chmj> good idea 
<jbailey> Bah, strip/tls fuckage.
* jbailey hunts.
<jbailey> lamont / lamont__ / infinity: Is it possible to tell what versions of the base packages were in the buildd chroot at package build time?
<jbailey> I'm looking for binutils in this case.
<lamont__> build-essential Depends are in the log file
<lamont__> Checking correctness of source dependencies...
<lamont__> Toolchain package versions: libc6.1-dev_2.3.2.ds1-20ubuntu11 linux-kernel-headers_2.5.999-test7-bk-17 gcc-3.3_1:3.3.5-8ubuntu2 g++-3.3_1:3.3.5-8ubuntu2 binutils_2.15-5ubuntu1 libstdc++5_1:3.3.5-8ubuntu2 libstdc++5-3.3-dev_1:3.3.5-8ubuntu2
<lamont__> for example
<jbailey> Poifect, thanks.
<lamont__> (I _THINK_ it pulls the list of packages-to-dump-versions-for from build-essential....
<lamont__> jbailey: and  you asking is pretty much the reason it's there.
<lamont__> well, for correct values of 'you'...
<jbailey> It may very well have been me at some point in the past. =)
<jbailey> Hmm, no ia64 success or fail message for http://people.ubuntu.com/~lamont/buildLogs/g/glibc/2.3.5-1ubuntu6/\
* lamont__ goes looking
* jbailey whines about there being no hppa or sparc ones there either, but at least that's expected...
* jbailey hides.
<lamont__> buildLogs/g/glibc/2.3.5-1ubuntu6/glibc_2.3.5-1ubuntu6_20050614-1141-ia64-successful.gz
<lamont__> uh....
<lamont__> _AMD_64, otoh...
<jbailey> Umm.  Right.
* jbailey smokes another one.
<lamont__> amd64 is only 29 hours into the build... do you suppose it hung?
<lamont__> GCONV_PATH=/build/buildd/glibc-2.3.5/build-tree/amd64-libc/iconvdata LC_ALL=C   /build/buildd/glibc-2.3.5/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.5/build-tree/amd64-libc:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3
<lamont__> .5/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.5/build-tree/amd64-libc/inet/test-ifaddrs  > /build/buildd/glibc-2.3.5/build-tree/amd64-libc/inet/test-ifaddrs.out
<lamont__> OK... so can we just kill test-ifaddrs????
<infinity> Bah, 29 hours is normal!
<lamont__> infinity: it's not an m68k box
<lamont__> glibc_2.3.5-1ubuntu6_20050614-1139       00:20:50 (12 entries, sigma 00:04:02)
<infinity> (It's not normal on m68k, either... glibc isn't that big)
<doko> infinity: you don't build for m68k ...
<jbailey> lamont__: Right, or possibly just fix the kernel.
<jbailey> lamont__: But yeah, I think I'll prune test-ifaddrs
<infinity> (Also, sbuild doesn't pull the list from build-essential, since that wouldn't work at all)
<infinity> You would just get the gcc/g++ metapackages, not the current gcc-X.X...
<infinity> And no binutils.
<infinity> On the flipside, you'd get dpkg-dev, which I've been considering adding to the list to log ever since keybuk started seriously screwing with us. :/
<lamont__>                 foreach $name (@main::toolchain_pkgs) {
<jbailey> Bah, busybox-cvs fails because of old binutils.  (Me cries at the thought of wondering why it worked before....)
<jbailey> infinity: *please*
<lamont__> @toolchain_regex = ( 'binutils$', 'gcc-[\d.] +$', 'g\+\+-[\d.] +$', 'libstdc\+\+', 'libc[\d.] +-dev$', 'linux-kernel-headers$' );
<infinity> Yeahp.  That's the one.
<lamont__> I'll add dpkg-dev now
* jbailey does a snoopy dance!
<lamont__> then pester elmo about breezy-test, and push a config this week sometime
<infinity> Thanks.  I need to branch your arch repo and start merging in meuro's changes.
<lamont__> yes.
<infinity> neuro, too.
<lamont__> upstream neuro is there, so it's really a 3-way merge
<lamont__> jbailey: want any more packages while I'm there?
<jbailey> I don't think so, nothing else has been getting churn that usually sits in the chroots that I can think of.
<lamont__> note that we do a dist-upgrade of all the chroots starting shortly(heh) after 0215 DCT
<lamont__> and that's still pending on yellow, because of glibc.
<lamont__> glibc_2.3.5-1ubuntu6_20050614-1139       02:33:52 (13 entries, sigma 07:59:40)
* lamont__ giggles
<lamont__> GO test-ifaddrs
<jbailey> Joy
<lamont__> infinity: pushing a mirror to chinstrap now
<jbailey> Yeah, I'll prune it next time around.
<jbailey> I'll also bump the build-dep to 2.16 to avoid the strip error.
<lamont__> and fix hppa's missing directory. :-)
<lamont__> mirror fresh
* infinity ponders heading to bed soon and getting back on a "correct" sleep schedule...
<infinity> lamont__ : Huzzah.
<lamont__> hppa finally passed sparc for %installed
<lamont__> which reminds me...
<jbailey> lamont__: Wow.
<lamont__> jbailey: actually, I've been watching #installed the last couple of days...
<lamont__> hppa:Total 3342 Installed.
<lamont__> hppa:Total 2842 Needs-Build.
<lamont__> hppa:Total 6184
<lamont__> sparc:Total 3312 Installed.
<lamont__> sparc:Total 2905 Needs-Build.
<lamont__> sparc:Total 6217
<jbailey> Nice!
<jbailey> Are thos eboth on track for breezy then?
<lamont__> that is, it's a relative-suckage thing
<lamont__> I really need to make some time to see about arts (and 4? others) ICE.
<lamont__> which kinda blocks a large chunk of main
<jbailey> Bah, just not-for-us them...
<jbailey> ;)
* lamont__ goes christmas shopping... back in 20-40 minutes
* infinity checks the date.
<jbailey> You have to admit...
<jbailey> A Christmas tree is probably really cheap right now.
<infinity> Much more unexpected when you chop down the one in the neighbour's front yard in July...
<infinity> Erm.. June, even.
<jbailey> While yelling 'Merry fucking christmas!'
<jbailey> fabbione: Around?
<jbailey> fabbione: It appears to build fine.  the make check sequence didn't run since sparc != sparcv9.  I'll poke that in the next upload.
<fabbione> jbailey: it builds, but it doesn't create the .debs
<fabbione> jbailey: so it's FTBFS
<fabbione> the overall is still exactly where i did show you
<fabbione> lamont__: eh.. hopefully numerbs will change soon.. i am getting another buildd :)
<lamont__> fabbione: ditto. :-)
<lamont__> although I may have to wait for monday before I can scrounge good hardware
<fabbione> i will get it sometime during this week
<fabbione> so i can finally dedicate one machine to main and one to universe :)
<jbailey> fabbione: Is that the usual split?
<fabbione> jbailey: ?
<fabbione> jbailey: you mean for building?
<jbailey> Yes, sorry. =)
<fabbione> jbailey: yeah
<jbailey> cp: cannot stat `./debian/tmp-libc/usr/lib/librpcsvc.a': No such file or directory
<jbailey> wha?
<fabbione> jbailey: funny eh?
<jbailey> Oh!
<jbailey> That'll be fixed in the next build too. =)
<jbailey> It doesn't build any of the sunrpc stuff when cross compiling.
<fabbione> uh ? cross compiling?
<fabbione> i don't want to know
* fabbione covers his ears with the hands and start yelling TRALLA LA' TRALLA LA'
<jbailey> I set the libc_configure_target=sparcv9-linux
<jbailey> _build was still set to sparc-linux
<jbailey> different processors == cross compiling.
<jbailey> Even if its on the same glibc.
<jbailey> err gcc.
<fabbione> TRALLLAAAAAAAAAAAAA LAAAAA
<fabbione> TRALLLAAAAAAAAAAAAA LAAAAA'
<fabbione> TRALLLAAAAAAAAAAAAA LAAAAA'
<fabbione> eheh ok
<fabbione> stick the source somewhere
<fabbione> so i can do a test build
<jbailey> It'll be pulsed out at :33 (Unliekly to make :03), mind just fetching it then?
<fabbione> jbailey: oh you already upload?
<fabbione> than it's ok
<fabbione> i understood you wanted me to test before
<jbailey> No, I'm still running a test.
<jbailey> I'd just like you to start it before you go to sleep.
<fabbione> ok
<jbailey> That way when I get up in the morning, I'll have testsuite results.
<fabbione> hm ok
<fabbione> i guess i will have to come later to start it
<jbailey> Okay, lemme send you the source then.
<jbailey> Sheesh
<jbailey> ;)
<fabbione> jbailey: that's fine.. i can wait
<jbailey> I don't want your wife to hurt me for making you come back.
<fabbione> it's just the mirror round-robin adds at least one hour
<jbailey> Can I safely drop the .diff.gz and .dsc in ~ on the sparc buildd?
<fabbione> yup
<jbailey> YAR BLOODY STUPID KERNEL BUG
<jbailey> lamont__: Well, it doesn't seem to be test-ifaddrs that's the problem.
<jbailey> lamont__: Removing it, I happened to get the failure on the test immediately after it.
<jbailey> And lucky me on ppc64, it seems to prevent me from running sudo
<jbailey> fabbione: Is there any way to catch state information at this point, or should I just hit the power button like I usually do?
<lamont__> jbailey: so nuke the test _before_ test-ifaddrs :-)
<jbailey> lamont__: Ayup =)
<fabbione> jbailey: ctrl+sysrq+s ?
<jbailey> That might explain why noone's been able to hunt this down, though.
<fabbione> bah i can't never remember the sequences
<jbailey> Which one is sysrq on a mac keyboard?
<fabbione> MEHHH
<fabbione> no idea
<fabbione> i think it's the same where it says: "HIT HERE TO POWER OFF THE MACHINE"
<fabbione> i never had a ppc
<fabbione> so i dunno
<fabbione> but i will be glad to host a few here at home :)
<jbailey> fabbione: So, yeah, best to come back.  This package isn't baked yet.
<jbailey> How long until you go to bed?
<fabbione> 2/3 hours
<fabbione> but i can still build it if you put the sources on vultus5
<jbailey> Okay good, so I have time for another full run with the testsuite to make sure there isn't some place after this that I need to remove the test too.
<fabbione> ok
<jbailey> Yeah, I'll do that.  The .diff and .dsc safe to drop in ~ ?
<fabbione> yup
<jbailey> fabbione: I've uploaded it.
<jbailey> fabbione: err, scp'd it rather.
<fabbione> jbailey: rocking
<fabbione> yeah
<jbailey> fabbione: With any luck this will be what I upload, even. =)
<jbailey> It's off of a 'debuild', not debuild -S
<fabbione> i will build it.. if you add or change i will just rebuild
<fabbione> otherwise we can test/upload that set of packages
<jbailey> Thanks.
<jbailey> Yup
<fabbione> i have no issues building glibc.. 
<fabbione> it's relatively fast :)
<jbailey> What's the usual time that it takes?
<fabbione> 7 hours more or less
<fabbione> but it might take longer
<jbailey> Nice, so it might be finished before I go to bed.
<fabbione> i doubt.. it takes 7 hours when it builds alone
<fabbione> it's running in parallel now
<fabbione> but it has been ccached with the previous run
<fabbione> so it's a tricky build :)
<fabbione> anyway it's already building
<jbailey> Cool
<jbailey> I'm off to get food, back in a bit.
<fabbione> sure later
<jbailey> *Sigh*
<jbailey> Killing the previous test doesn't do it either.
<jbailey> Then test-ifaddrs kills it.
<jbailey> I've never hit this bug so many times in a row
<fabbione> i am off :)
* jbailey disables that patch and builds this on a power4 kernel instead
#ubuntu-toolchain 2005-06-23
<doko> ohh, jbailey does the glibc dance ;)
* lamont__ heads out
<jbailey> doko: Yeah. =(
<jbailey> doko: Glibc is much happier with everything being old binutils or everything being new binutils, which worries me a bit, but everything seemed to check out with some readelf love.
<jbailey> Feh.  module-init-tools needs a give back after the chroot is updated, too.
<jbailey> (ppc and amd64)
<fabbione> morning
<lamont> jbailey: done
<lamont> *2
<lamont> (glibc. module-init-tools)
<lamont> Jun 15 18:51:05 buildd: breezy: total 963 packages to build.
<lamont> woot!
<fabbione> hey lamont
<lamont> morning fabbione 
<fabbione> i guess hppa is catching up :)
<lamont> gcc-snapshot ICE.  kewl. :(
<lamont> that number is from the local w-b, not the one on p.u.c
<fabbione> oh
<fabbione> jbailey: glibc is building now on sparc
<lamont> on that one, the numbers are a bit closer...
<lamont> 3551/2634/6185 for hppa, 3329/2889/6218 for sparc (installed, needs, total)
<fabbione> yup
<lamont> and given that all of kde Depends: arts (ICE), you'll eventually get ahead again, big time.. -)
<lamont> and libgtk2.0 install hangs :-(
<lamont> life sucks these days
<fabbione> ah
<lamont> but once the buildd catches up as best it can, then I can actually spend a little time making everything sync up nicely, and maybe even do some debugging
<fabbione> yeah
<lamont> but frankly, if I can get the server install to work, along with the useful server packages, I'm happy.
<fabbione> when i will get the other buildd up, i can free some time from my sparc to do it
<fabbione> i need to move w-b on another machine
<lamont> yeah - that's on my list of things to do this week as well.
<lamont> 3) migrate w-b to another machine, so that both buildd's can share it.
<fabbione> i lost the first 2)
<lamont> sadly, 2) is to create world pease
<lamont> peace, even
<fabbione> (netsplit of death)
<lamont> nah - didn't post #1 or #2
<fabbione> ehehhe ok
<lamont> but when I headed home tonight, there was a B180 doing a sarge install in a screen session
<lamont> 1) is working ipsec configuration :-)
<fabbione> ehhe
<fabbione> now i need to understand why ppc is FTBFS on ppc64 kernels
<fabbione> apparently i am leaking a ppc64 somewhere
<lamont> 893 Building, 589 Dep-Wait, 29 Failed, 2779 Installed, 952 Needs-Build, 860 Uploaded, Total 6102
<lamont> ouch
<lamont> (ppc64)
<fabbione> well basically it FTBFS building the headers
<fabbione> it's ok if the buildd is running ppc kernels
<lamont> those numbers are with a 3-day old mostly-current binary archive, and current as of 3.5 hours ago source
<fabbione> but not with ppc64
<fabbione> heh not bad
<lamont> so are any of the DC buildd's running ppc64, or just davis?
<fabbione> only davis
<fabbione> but the ppc64 kernel fixes the random segfaul/segkill problem
<fabbione> and trust me.. it's flying
<fabbione> ahhhh
<fabbione> it's getting the wrong defconf
<lamont> hrm.. so how do I format a fat16 partitiion, I wonder
<fabbione> isn't there a vfat or fat utils?
<lamont> there's mformat, but it wants details I don't want to generate.. :-)
<lamont> and there's mkntfs, but I want FAT
<fabbione> AHHH FOUND IT!!!
<fabbione>                 make defconfig; \
<fabbione> DIE!
<lamont> nice
<fabbione> now... go figure why it prefers ppc64 over ppc
<fabbione> now.. patch to the kernel Makefile or usual tons of workarounds in debian/rules???
<lamont> I'
<lamont> d be incinled to fix the makefile
<fabbione> i think the makefile is correct
<fabbione> it's the way we call it that's wrong
<lamont> well, then fix debian/rules, of course. :-)
<fabbione> i am trying to think...
<fabbione> SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
<fabbione>                                   -e s/arm.*/arm/ -e s/sa110/arm/ \
<fabbione>                                   -e s/s390x/s390/ -e s/parisc64/parisc/ )
<fabbione> this is where we fail
<fabbione> or better ..
<fabbione> where the kernel makefile fails
<fabbione> it uses uname -m to determine ARCH= via SUBARCH
<fabbione> ARCH            ?= $(SUBARCH)
<fabbione> it looks to me that we should instead set ARCH properly
<fabbione> there....
<fabbione> fixed
<fabbione> doko: i think gcc-4.0 is doomed on sparc
<fabbione>  /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a(errno.o) section .tbss mismatches non-TLS reference in 
<fabbione>  /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a(check_fds.o)
<fabbione>  /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a: could not read symbols: Bad value
<fabbione> i have seen this already in 2 packages
<doko> which packages are these?
<fabbione> busybox-cvs and modules-init-tools
<fabbione> do you want the build logs?
<fabbione> but the error is exactly the same
<doko> works with 3.4 on sparc?
<fabbione> doko: dunno.. i will have to check
<fabbione> they are really fresh build logs
<fabbione> infinity, lamont: ping?
<fabbione> unpong
<fabbione> elmo: i fixed the ppc kernel build on ppc64 kernels.. you can upgrade anytime, but we might find other packages with the same problem
<fabbione> specially the ones that use uname -m to detect what they should do
<infinity> fabbione : We could (should?) just linux32 ppc buildds, like we do with sparc buildds.
<infinity> (But, I agree, packages using `uname -m` for anything are pretty broken)
<fabbione> infinity: i don't think it even exists linux32/64 for ppc
<fabbione> smurflogbot ??
<smurflogbot> fabbione: Error: "??" is not a valid command.
<fabbione> ubuntu-toolchan is already logged
<fabbione> amen
<fabbione> smurflogbot: !die
<smurflogbot> fabbione: Error: "!die" is not a valid command.
<fabbione> amen
<fabbione> speaking of which
<fabbione> i need to log #ubuntu-java
<infinity> fabbione : Well, if it doesn't it should.
<infinity> fabbione : But apt-cache tells me it already does.
<fabbione> linux32
<fabbione> -su: linux32: command not found
<fabbione> that's on davis breezy chroot
<fabbione> anyway.. foooooooooooooooood
<doko> smurflogbot: help
<smurflogbot> doko: (help [<plugin>]  [<command>] ) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
<doko> smurflogbot: help help
<smurflogbot> doko: (help [<plugin>]  [<command>] ) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
<doko> smurflogbot: help die
<smurflogbot> doko: Error: There is no command die.
<doko> smurflogbot: helpyourself kill
<smurflogbot> doko: Error: "helpyourself" is not a valid command.
<infinity> smurflogbot : quit
<smurflogbot> infinity: Error: ":" is not a valid command.
<infinity> smurflogbot: quit
<smurflogbot> infinity: Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
<infinity> Bah.
<infinity> (If anyone's curious, the bot is one of these: http://supybot.sourceforge.net/docs/commands.html)
<fabbione> who has op in here?
<fabbione> and ban that bot?
* #ubuntu-toolchain  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<jbailey> lamont, fabbione: thanks
<jbailey> Sparcv9 testsuite Errors: tst-align2, tst-getpid1, tst-timer, tst-mqueue1, tst-mqueue2, tst-mqueue4, tst-timer4, tst-timer5
* jbailey digs up a previous log for sparc.
<jbailey> At least two of those, I have a patch for from davem
<jbailey> BAH
* jbailey cries to Fabio about getting sparc build logs put somewhere.
<jbailey> I have no basis for comparison here... =(
<fabbione> jbailey: they are all in the usual place.. and yes i know.. they should go to people, but i need to get elmo to do it
<fabbione> you can get the old logs in ~/logs
<jbailey> You can't just scp them into your homedir? =)
<fabbione> jbailey: it means duplicating the effort i already did to get them to people atm
<jbailey> My imap client doesn't like your imap server.  Can I ask you to extract a previous glibc success log for me?
<fabbione> jbailey: ok wait. i will scp them on people.. even if you have ssh access to where logs are stored
<jbailey> Do I?
<jbailey> I thought I had to look in the imap server to get to them...
<fabbione> no
<fabbione> you can either ssh or look via imap
<fabbione> i have you an alternative :)
<fabbione> now i am compressing them...
<fabbione> and scping them to people :)
* jbailey does a snoopy dance!
<jbailey> afk a sec
<fabbione> jbailey: since you can ssh .. i did stop the bzip2 :)
<fabbione> i think it's easier for you to run diffs there than having to download 4 * 43MB of files
<jbailey> =)
<jbailey> grep rather than diff, but yeah. =)
<fabbione> yeah
<fabbione> and the manual build is at 36MB
<fabbione> it seems that it is almost done
<jbailey> YEah, it's a good chunk of the way through the sparc64 testsuite that I added.
<fabbione> and that's fine for me :)
<jbailey> Old sparc testsuite errors: tst-mqueue1, tst-mqueue2, tst-mqueue4
<jbailey> So we're gaining timer test failures.
<fabbione> jbailey: do these tests rely on some kind of timeouts?
<fabbione> because the machine has been pretty overloaded
<jbailey> I'll check.
<fabbione> so a test failure due to machine load is nothing i would be too worried about
<jbailey> sparc64 fails with: tst-regex2..  Weird. =)
<fabbione> jbailey: you are killing sparc! you bastard :P
<jbailey> Oh, I see.
<jbailey> segfaults on the timer tests. =(
<jbailey> Nope, only the first one.
<jbailey> Not, #4, and #5
<jbailey> I don't see an error message, though.
<jbailey> No they did segfault.
<jbailey> It just didn't percolate the error up.
<jbailey> Didn't expect signal from child: got `Segmentation fault'
<jbailey> make[3] : *** [/home/sparcbuildd/glibc-2.3.5/build-tree/sparc-libc/rt/tst-timer5.out]  Error 1
<jbailey> It should look like:
<jbailey> make[3] : *** [/home/sparcbuildd/glibc-2.3.5/build-tree/sparc-libc/rt/tst-timer.out]  Error 139
<jbailey> For a segfault
<jbailey> weird weird weird.
<infinity> The former looks more readable...
<infinity> (Where is this output, though?)
<infinity> 139 is just "1 + 138 from child"
<infinity> The textual version is much saner, despite being different. :)
<jbailey> infinity: I scan for the error codes.
<jbailey> infinity: "Error 1" is a simple testsuite failure, so I usually check the output.  There's no obviously failure in the message, so it threw me.
<jbailey> lamont__: Did the last glibc do fine on hppa, btw?
<lamont__> libs/glibc_2.3.5-1ubuntu7: Dep-Wait by buildd+smallone [required:out-of-date] 
<jbailey> HAven't got the new binutils yet?
<lamont__> devel/binutils_2.16.1-0ubuntu1: Dep-Wait by buildd+smallone [standard:out-of-date] 
<lamont__>   Dependencies: dpkg (>= 1.13.7)
<lamont__> base/dpkg_1.13.9: Needs-Build [required:out-of-date] 
<jbailey> Joy..  So check you with again tomorrow sometime. =)
<lamont__> ==> archive issues... let me fix things
<lamont__> (issues in my mirror, that is)
<jbailey> Haven't you moved that thing to under your desk at work yet? =)
<lamont__> that's an in-progress thing
<lamont__> yesterday I configured the DMZ box for it
<lamont__> archive kicked around a bit, should actually build things now
<lamont__> jbailey: some quick packages ahead of it, then dpkg'll build
<jbailey> Cool.
<jbailey> I expect hppa should be happy now.
<lamont__> and I fixed the sources.lists so that my lazy archive management shouldn't hurt it much anymore
<jbailey> I was telling Fabio that I intend to have all of the glibc hacking for sparc and hppa finished by UVF.
<lamont__> (it was preferring the mirror that only has current hppa bits for source. :-(
<lamont__> that's a good goal
<jbailey> And whatever state it's in at that point, to basically keep it that way until Breezy+1 hacking starts.
<jbailey> So I have some function pointer stuff to do on hppa, and I think that's all I'll get in for you.
<lamont__> at least feature wise, sure
<jbailey> Bug fixes, sure.
<lamont__> no TLS, eh?
<fabbione> jbailey: i was looking that even if we get the toolchain in place before UVF, both hppa and sparc are gcc-4.0 doomed
<fabbione> a lot of stuff doesn't build with gcc-4.0 yet
<jbailey> Like what?
<jbailey> There really shouldn't be that much that's arch specific...
<fabbione> gclcvs in main :)
<jbailey> Is that in ~/logs ?
<fabbione> yes
<fabbione> there are a bunch of libs that don't build..
<fabbione> i will need to check them again
<fabbione> universe is a mess
<fabbione> a lot of stuff doesn't build with gcc-4.0
<fabbione> lamont__: i can i check buildd stats?
<fabbione> per buildd.. not globally
<fabbione> i am curious to see how much the new buildd is crunching :)
<jbailey> fabbione: Is that sparc-specific or all over the place?
<fabbione> (nothing urgent.. i will be back later)
<fabbione> jbailey: the point is that most of these packages haven't been rebuilt in universe after the gcc transition
<fabbione> so basically sparc is building them for the first time
<fabbione> with gcc-4.0
<fabbione> and i guess hppa will hit the same problem
<fabbione> since it's building universe
<fabbione> i am pretty sure that if we do a real testbuild of i386 from scratch we will hit most of the same errors
<fabbione> and that's something we should really do asap
<fabbione> at least to check: main compiles out of main
<fabbione> universe.. well tought luck
<jbailey> Oh,  I see.
<jbailey> I think we can be pretty certain of main.
<jbailey> There is very little there that doesn't get movement during a dev cycle.
<fabbione> jbailey: i wouldn't :)
<fabbione> warty -> hoary there was one package that was not updated :P
<jbailey> Right, one is not significant in the set of 800 or so. =)
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/g/ghc6/ this is an example
<doko> libx11-6 conflicts with xlib-data?
<doko> fun
<fabbione> jbailey: that compiler or whatever it is.. it's a b-d for many packages
<fabbione> jbailey: probably it has been bootstrapped ok.. builded all the whatever
<fabbione> jbailey: but now.. it's not buildable anymore
<fabbione> because of gcc-4.0
<fabbione> so that's one of the example of packages that will not be built on sparc/hppa
<fabbione> because they are not there yet
<doko> fabbione: only the packages, that were not compiled in the breezy cycle
<fabbione> and all the packages that b-d on it will follow
<fabbione> doko: right.. but that assume that you have all of hoary already there
<fabbione> doko: that's not exactly true on arch that are bootstrapping :)
<fabbione> doko: i know you hate me because of sparc.. i still love you a lot :P
<fabbione> anyway i need to fold the washing :)
<fabbione> i will be back later after dinner
<jbailey> fabbione: Setup a "Hoary" repo with gcc set to gcc-3.3.  Build them and inherit like everyone else. =)
<lamont__> there are _LOTS_ of build failures - we're supposed to get breezy-autotest up and running RSN (elmo -nudge nudge), and then we'll have good build logs that people will actually look at
<elmo> AWW MAN
<elmo> binutils is just a fricking blackhole of unrobustness
<daniels> elmo: H J Lu!!
<lamont__> jbailey: I'll be filing RC bugs on all of them once breezy-autotest is live, maybe sooner as time permits
* lamont__ is tempted to just upload ...build1 versions of the borken ones, just to get them worked on... :-)
<jbailey> lamont__: In Debian or in Ubuntu? =)
<jbailey> Mind you, I guess UVF is soon, isn't it?
<daniels> jbailey: WHAT?
<jbailey> err..
<doko> daniels: will you upload an xlib-data, which doesn't conflict with libx11-6 ?
<doko> or should things be recompiled
* daniels looks at doko.
<daniels> ... you want me to remove the Conflicts?
<doko> no, just know, what needs to be done to get libs like kdelibs4c2 installed again
<lamont__> jbailey: ...build1 versions are ubuntu-specific
<daniels> could you please explain the specific problem?
<daniels> libx11-6 Conflicts xlibs-data << 6.8.2-25
<daniels> this is because, up until 6.8.2-25, xlibs-data contained files that are now in libx11-6
<daniels> i don't know what you want me to do other than this, nor do I even know what the actual problem is
<doko> The following packages will be REMOVED:
<doko>   gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools
<doko>   gnome-volume-manager hwdb-client kdelibs-bin kdelibs4c2 libdbus-qt-1-1c2
<doko>   libgksu1.2-0 libgksuui1.0-0 x-window-system-core xbase-clients xterm
<doko> The following packages will be upgraded:
<doko>   libtext-iconv-perl x-dev x11proto-core-dev
<doko> 3 upgraded, 0 newly installed, 15 to remove and 2 not upgraded.
<daniels> doko: *shrug* worked fine for me
<doko> trying to upgrade breezy
<lamont__> daniels: +/home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/libglu1-mesa-dev
<lamont__> +_6.2.1-5_hppa.deb (--unpack):
<lamont__>  trying to overwrite `/usr/include/GL/glu.h', which is also in package
<lamont__> +x11proto-gl-dev
<lamont__> that'd be nice to fix...
<daniels> doko: want to run the dependency resolver and see what's actually causing it?
<daniels> lamont__: 6.2.1-5? wtf?
<daniels> oh, -mesa-
<daniels> yeah, I'll get that fixed up with a Conflicts and a mesa upload
<daniels> tomorrow, though; it's 0241
<lamont__> thanks
<doko> daniels: hmm, my current xlibs-data is 6.8.2-24, the -25 build did fail on i386
<daniels> hm, but succeeded on amd64 and powerpc.  wtf?
<doko> via_xvmc.c:51:16: error: Xv.h: No such file or directory
<doko> via_xvmc.c:52:18: error: XvMC.h: No such file or directory
<doko> via_xvmc.c:188: error: 'XVMC_CHROMA_FORMAT_420' undeclared here (not in a function)
<doko> via_xvmc.c:194: error: 'XVMC_MPEG_2' undeclared here (not in a function)
<doko> via_xvmc.c:195: error: 'XVMC_OVERLAID_SURFACE' undeclared here (not in a function)
<doko> yes, but fails on ia64 as well
<daniels> argh, the fucking via driver!
<daniels> my recommendation for now is that ou don't dist-upgrade
<elmo> DOKO
<daniels> unless you actually want to remove all that stuff
<doko> ok
<elmo> doko: dude, what's up with the blacklists
<elmo> am I still blacklisting syncs?
<doko> elmo: hmm, I thougth we replaced them with dep-waits on the buildds?
<elmo> that was for building of stuff
<elmo> you never told me to do anything about the blacklists of the sync program
<doko> yes, to be able to enable the syncs
<doko> hmm, didn't we talk together with infinity?
<doko> sorry
<elmo> so I can remove blacklists?
<doko> from my point of view, yes. all packages, which depend on not yet converted libs, are marked as b-d on the expected new libname
<elmo> ok
<fabbione> elmo: ping?
<elmo> fabbione: sup
<fabbione> hey elmo
<fabbione> elmo: jbailey and i were wondering if you had any time to think on how we can get sparc build logs on people...
<fabbione> elmo: last time i suggested that the mail2htmllog could perhaps run directly on people
<jbailey> elmo: In truth, I've been snivveling at Fabio...
<jbailey> His threats to beat me only got me excited, you see...
<jbailey> err.
<jbailey> NM
<fabbione> elmo: iirc correctly the problem was that the main machine that processes them can't be used
<fabbione> elmo: so perhaps the main machine could just send a copy to people that will do the log2html processing
<fabbione> elmo: and external buildd could send a copy there too
<elmo> yeah, we can't have sanae receiving external mail.  if this going to work, I think the way forward is:
<elmo> our buildds mail sanae forward the mail to a log2html processor on another box, your buildds are also allowed to mail that other box
<elmo> but I may just be repeating myself here
<fabbione> that's exactly what i suggested :)
<fabbione> i suggested people.. but it could be any other box
<fabbione> i don't think my .promailrc will ever care :)
<elmo> or I could be repeating you.. either works ;)
<fabbione> elmo: i love when we say the same thing in 20 different ways :) it makes hot :P
<elmo> hum, people's in danger of suffering from chinstrap disaease, if it's not already in the advanced stages
<fabbione> -ETOOMUCHCRAP?
<elmo> right
<elmo> anyway, fuck it.  people's fine.  if you can get the lamont/infinity hybrid to agree to do the work and choose a domain name, I'll set up our mail double-bounce madness to allow the mail into rookery
<fabbione> elmo: sure :)
<fabbione> elmo: i am going to hunt them down to death and set it up :)
<elmo> heh
<lamont__> elmo: "choose a domain name"??
<fabbione> lamont__: $domainname@ubuntu.com :)
<elmo> lamont: or an LHS for @ubuntu.com
<fabbione> i was asking the same thing right now
<elmo> which/whatever
<infinity> elmo : What happened to buildd.u.c that we discussed a few days ago?> :)
<daniels> infinity: go to bed, dude
<infinity> daniels : You too, punk.
<fabbione> daniels: go to bed kid
<daniels> yeah, I'm off to sleep now
<fabbione> and don't forget to change the diaper or i will tell mamma
<elmo> infinity: it got stalled on the httpd2.1 thing
<infinity> Alright.  I'll read the backscroll on this convo tomorrow.
<elmo> I'll rip it out in a sec
<infinity> elmo : Right.
<fabbione> infinity: ok :)
<lamont__> elmo: we could just go with logs@buildd.u.c or some such, yes?
<infinity> Which is sane.
<elmo> lamont: sure
<infinity> And easy to remember, since it's the same for Debian. :)
<fabbione> ehehe
* infinity -> bed, for real.. Maybe.
<fabbione> infinity: night dude
<lamont__> elmo: that would also let me retire the rsync from sanae, which would be cool.
<lamont__> (have sanae still archive all the DC builds, but not make it push stuff out..)
<lamont__> elmo: do we want to then migrate the logfiles to live under http://buildd.ubuntu.com/ as well?
<fabbione> hmm speaking of which... it will require me to increase the max email size
* fabbione goes and pokes with postfix here and there
<infinity> lamont__ : That was my plan, and I was going to slap up a simple interface on it that didn't completely suck.
<infinity> Yay, sleep-typing.
<lamont__>  /usr/sbin/postconf -e message_size_limit=0
<lamont__> infinity: I'm figuring that the initial dump is mv ~lamont/public_html/buildLogs /srv/buildd.ubuntu.com/buildLogs
<lamont__> and set things up to save there.  Once there's a pretty interface to it, people can stop drilling down on their own.
<lamont__> or not. :-)
<fabbione> lamont__: does it also add it to the config files?
<lamont__> fabbione: that only edits the config file
<fabbione> ah ok :)
<fabbione> i still need to restart it...
<fabbione> suckage.. 
* fabbione files a wishlist bug ;P
<lamont__> fabbione: actually, the daemons regularly kill themselves off, so you don't _need_ to say reload
<lamont__> (and, in fact, reload just causes master to tell all the current children to exit upon finishing whatever they're doing)(
<fabbione> lamont__: what can i say... *point
<lamont__> it'll be +wontfix
<fabbione> lamont__: that would make sense...
<lamont__> elmo: lets go with logs@b.u.c - that _could_ be an alias to lamont+logs, or better yet, we could just deliver it to a properly adjusted version of savelog.py
<lamont__> whcih adjustment requires knowing the root of the web tree.
<fabbione> not too bad... only 2400 pkgs to go for sparc :)
<fabbione> in an eon or two we will get there ;)
<fabbione> actually.. i need to see if i can auto check the libs
<fabbione> and unban the apps
<lamont__> something to autocheck and unban would be most cool
<lamont__> buildd thinks it has 1126 packages to build, with 782+41 failures
<jbailey> Hmm.
<jbailey> /usr/lib/gcc/sparc-linux/4.0.1/libgcc.a(_muldi3.o)(.text+0xa8): In function `__muldi3':
<jbailey> : undefined reference to `.umul'
<jbailey> /usr/lib/gcc/sparc-linux/4.0.1/libgcc.a(_muldi3.o)(.text+0xb8): In function `__muldi3':
<jbailey> : undefined reference to `.umul'
<jbailey> fabbione: That might actually be a gcc error.
<jbailey> fabbione: Do you see similar things in other packages?
<doko> nice
<fabbione> jbailey: only the other 2 i did show to you before
<fabbione> doko: ping?
<\sh> doko: ping2
<doko> ping pong
<fabbione> doko: ok.. i verified that sparc did build all the c++ libs in main
<fabbione> now i am supposed to allow c++ apps in
<fabbione> in order to do that i need to get the list of:
<fabbione> 1) all c++ application in mains that have been banned
<fabbione> or
<fabbione> 2) a list of c++ applications in universe that still need to stay banned
<doko> 1) cxxapps-20050520.txt
<fabbione> doko ~ on chinstrap?
<doko> 2) frozenapps.txt
<doko> yes
<fabbione> perfect
<doko> i know :)
<fabbione> yeah yeah... you damn germans are like swiss clocks.. everything has to be perfect :P
<doko> heh, got my notebook back from the repair, bought a wifi access point, sitting outside in a cafe as long as the battery lasts, fun ...
<doko> still 28 degrees ;)
<\sh> fabbione: this is something for a blog entry ;)
<\sh> bashing the old german history ;)
<lamont__> doko: I want hppa's ICE fixed. :-( :-)
<lamont__> so as long as you're still hot..... :-)
<lamont__> I know. test case
<fabbione> doko: only 70 apps in universe???
<doko> yes, thanks to \sh 
<fabbione> the list looked much much longer
<\sh> oh I have to check again
<fabbione> doko: what means.. that all libs have been uploaded or that there were too many apps in your list?
<doko> hmm, wait, if all libs did build for sparc and hppa as well ...
<fabbione> lamont__: btw.. i am drafting a script.. even if doing main manually takes 10 minutes
<lamont__> doko: none of kde is built for hppa, for starters (arts ICE)
<\sh> fabbione: most of the libs are done for universe...I'm waiting for a couple of ajmiches libs and danielNs I'm playing with him to fix it.
<fabbione> \sh: that's not my question.. 
<fabbione> i need to know on what is the frozen list i got from doko is based off
<fabbione> does it contain all the c++ apps in universe?
<doko> fabbione: please build firefox-dev and festival-dev for main as well, they are static C++ libs
<fabbione> doko: already done that eons ago
<fabbione> doko: 70 c++ apps in universe looks wrong
<lamont__> doko: those are binary packages...
<doko> no, the list of all C++ apss in universe is cxxapps.txt
<fabbione> so what is frozen?
<doko> frozen are the apps for our 4 archs, where I did check, that these 70 apps depend on C++ libs, which are not yet converted
<fabbione> are they part of cxxapps.txt?
<fabbione> or do i need to merge the 2 lists?
<doko> they should be a subset of cxxapps.txt
<fabbione> ok
<fabbione> in cxxapps the source package is in $3, right?
<doko> lamont__: which ones are binary?
<lamont__> festival-dev, firefox-dev
<doko> yes
<doko> lamont__: yes
<fabbione> doko: ok
* fabbione unleashes sparc on all main
<lamont__> doko: what's in libgcc1?
<doko> \me watches the sparc/hppa race ...
<doko> libgcc_s.so.1
<fabbione> doko: there is no real race.. hppa has much more hw :)
<lamont__> fabbione: atm there is only one hppa buildd
<fabbione> ah
<fabbione> ehehe
* fabbione gets the idea that he might win on the short distance
<doko> we could do a buildd admin race instead ;-P
<lamont__> hehe
* lamont__ takes another stab at debootstrapping a buildd chroot on his sarge-turned-breezy hppa box at work
<fabbione> lamont__: how do you prefer to check the libs?
<fabbione> against a Package file or what's in a local availble archive?
<lamont__> well, given that the local archive is the same format as a remote archive, I expect that the package file is the way to go
<fabbione> lamont: for me it's the same :)
<fabbione> but i am doing it against Package
<fabbione> lamont__: ready to copy?
<fabbione> for i in `cat wiki-all-list.txt | grep " main " | awk -F "\|\|" '{print $3}' | sort -u`; do name=`grep "$i" wiki-all-list.txt | awk -F "\|\|" '{print $5}'` && name=`echo $name | awk '{print $1}'` && if [ -n "$name" ] ; then if ! grep -q "Package: $name$" Packages; then echo $name not found; fi ; fi ; done
<fabbione> it needs in the directory:
<fabbione> wiki-all-list.txt from doko ~ on chinstrap
<fabbione> and an unpacked Packages from main/binary
<fabbione> and i can tell you from now that i got 2 false positives due to 2 typos in that file
<fabbione> actually... more than typos...
<fabbione> the 2 it didn't find are there in new major upstream releases but builded properly
<doko> fabbione: yes new upstreams are not in this list, but they are compiled with the new ABI when the enter, but make another transition when Debian does it.
<fabbione> actually.. i can rewrite that in half
<fabbione> for i in `cat wiki-all-list.txt | grep " main " | awk -F "\|\|" '{print $5}' | sort -u`; do if ! zgrep -q "Package: $i" /mirrors/ubuntu-sparc/archive/dists/breezy/main/binary-sparc/Packages.gz; then echo $i not found; fi ; done
<fabbione> lamont__: ^^ simplified version with zlib support :P
#ubuntu-toolchain 2005-06-24
<fabbione> morning
<fabbione> infinity: ping?
<fabbione> lamont: ping?
<lamont> fabbione: ack
<fabbione> lamont: yo..
<lamont> gcc-4.0 -8ubuntu3 is at 9.5 hours.  sigh
<fabbione> lamont: i was asking infinity as well.. do you remember the commands that a buildd needs to have in sudo privileges without passwd?
<fabbione> right now we figured apt-get and dpkg
<lamont> I know it passes lots of cruft in - generally the machines I've seen just gave buildd all commands, prolly out of lazyiness
<lamont> it's going to need chroot as well, I expect
<fabbione> and if any of you 2 remembers how to get stats out of a single buildd?
<fabbione> lamont: hm right..
<fabbione> like i have N buildds.. but i want to know exactly how much work one buildd is doing
<lamont> more ~buildd/stats/Summary
<fabbione> there is no Summary :)
<lamont> dunno why I have one then
<fabbione> some of your scripts generate it?
* lamont shrugs.  all of the (neuro-based) buildd's I'm running have stats...
<fabbione> this is the one from db.d.o
<lamont> yep
<fabbione> sparcbuildd@test7:~/stats$ ls
<fabbione> build-time  builds  taken
* fabbione scratches his head
<fabbione> is it a config option?
<lamont> buildd-watcher creates summary
<fabbione> hmm i don't think i am running it.. should i?
<lamont> it'll give you a summary :-)
<lamont> and keep buildd running..
<lamont> 20,50 * * * *    nice -10 /usr/bin/buildd-watcher
<lamont> is what debian has
<fabbione> buildd keeps running anyway :)
* lamont needs to sleep
<fabbione> lamont: last question :)
<fabbione> the option to fork buildd if more than N packages needs-build
<fabbione> did you ever use it?
<fabbione> does it actually work?
<fabbione> (i know infinity i did ask you already ;))
<lamont> haven't used it
<fabbione> ok
<lamont> but I expect that works
<lamont> since some of the slower debian architectures have been using it at least in the past
<fabbione> i wonder who i could ask for sure...
<lamont> any more 'one last question's?
<fabbione> nope :)
<lamont> ok.  gonna sleep, I think.
<infinity> Are you talking about the secondary threshold?
<fabbione> infinity: yes
<lamont> bah - /me looks at the buildd source for a minute
<fabbione> lamont: don't worry.. 
<fabbione> have a good night :)
<infinity> Revisiting that recently, I'm not sure it's an option to fork at all.
<fabbione> please it's really nothing urgent
<fabbione> Build daemon statistics from 19700101-0100 to 20050617-0715 (12951.22 days):
<fabbione> haah
<infinity> But rather to declare the this particular buildd is a "secondary", and should only --take and build packages if needs-build is > foo
<fabbione> the first run is sick :)
<lamont>                 logger( "$dist: total $total packages to build.\n" ) if $total;
<lamont>                 if ($total && $conf::secondary_daemon_threshold &&
<lamont>                         $total < $conf::secondary_daemon_threshold) {
<lamont>                         logger( "Not enough packages to build -- ".
<lamont>                                         "secondary daemon not starting\n" );
<lamont>                         next;
<lamont>                 }
<lamont> looks right to me
<lamont> infinity: exactly
<infinity> See? :)
<infinity> No forking.
<lamont> so the buildd just idles along doing nothing until such time as the rest have fallen behind.  then it kicks in and actually does something for a bit
* lamont sleeps
<fabbione> good night lamont
<lamont> infinity: forking wouldn't help, since it's on the same machine... /me just figured that fabbione was using words in a slightly european manner. :)
<fabbione> ehhe
* lamont cries.  I'll deal with caballero tomorrow when I'm awake
<lamont> starting with a fresh kernel build for it.
<lamont> esp if fabbione has finished and uploaded -1.2
<fabbione> lamont: i am almost done :)
<fabbione> i miss usb-modules, pcmcia* and nic*
<fabbione> the latter is a real pain :(
<infinity> lamont : No, forking obviously wouldn't work, hence the confusion. :)
<infinity> (Well, forking could work if you made dead sure that you were always building for two different dists in parallel, and never two packages on the same dist)
<infinity> Could be handy to get RIGHT NOW, DAMNIT security builds without runinng a second buildd.
<fabbione> infinity: it can't be that hard to implement
<fabbione> but i am hounestly far away motivated to do so
<fabbione> or given a good design
<fabbione> get sbuild to understand the concept of target chroot
<fabbione> and get buildd to for N instances of sbuild
<fabbione> at that point the concept of suite can be easily implemented in buildd to run sbuild N times
* fabbione thinks....
<fabbione> can't be that hard
<infinity> I think all you really need here is target locking.
<fabbione> with target locking you can run only one instance of sbuild for breezy for ex
<fabbione> and one for hoary-security
<infinity> Also handy if a machine goes down in the middle of a build.  No more @reboot touch ~buildd/NO-DAEMON-PLEASE, but instead you get a buildd that comes up building for all the non-locked chroots, and you get the clean the locked on.
<fabbione> that's because sbuildd is hardcoded for the target chroot
<infinity> Why would I want more than one for breezy?...
<infinity> Oh, I guess if you want to take advantage of multiple CPUs and fast disk.
<fabbione> exactly
<infinity> But that's a use case I don't care about as much as timely security updates.
<daniels> and timely xorg updates
<fabbione> so the first step would be to let sbuild understand in what chroot it should build
<fabbione> no option = use the default
<fabbione> otherwise switch to the specified chroot
<infinity> Just have it pick a random unlocked chroot at build-target/chroot-target[0-9] 
<fabbione> buildd at that point can really for N instances of sbuild
<infinity> Or whatever.
<infinity> (And don't spawn new instances if all available chroots are locked)
<fabbione> and buildd will need to understand the concept of forking and forking per release/security or whatever
<fabbione> exactly
<infinity> No config file changes to add new chroots that way.  And when you fix a locked chroot, it magically comes back online.
<fabbione> it doesn't sound impossible.. just boring to death to do it :)
<infinity> It sounds like something I'd happily do... If I was allowed to.
<infinity> <cough>
<fabbione> elmo: did you already setup logs@u.c ?
<elmo> fabbione: no
<fabbione> elmo: ok thanks :)
<\sh> make[4] : *** [Sequence.o]  Segmentation fault
<\sh> ppc..if anybody is interessted to check: http://people.ubuntu.com/~lamont/buildLogs/o/openscenegraph/0.9.8-4ubuntu2/openscenegraph_0.9.8-4ubuntu2_20050617-0944-powerpc-failed.gz
<fabbione> \sh: ppc is known to send spurios segfaults
<fabbione> it's probably enough to kick the package back
<fabbione> that problem will go away as soon as we can install ppc64 kernels on the buildd
<\sh> so...version+1 and do it again
<fabbione> no
<fabbione> you wait for lamont/infinity/elmo to kick it back
<\sh> oh ok
<fabbione> uploading to trigger a rebuild is BAD
<fabbione> and pointless
<infinity> And BAD.
<infinity> Also, it's not good.
* jbailey crawls towards being alert.
<lamont> fabbione: ppc is known to send spurious SIGILL, not SEGV
<jbailey> HPPA on the other hand...
* jbailey hides.
<fabbione> lamont: well whatever :)
<fabbione> lamont: ppc64 kernels fix that 
<fabbione> lamont: i did try to be extremely careful changing the d-i stuff on hppa
<fabbione> lamont: but i can't be 100% sure it's ok
<fabbione> of all the changes i missed one on ppc.. (the HACK ALERT )
<lamont> so I should do another test build, eh?
<fabbione> if it fails on hppa please send me the last 30 lines of the log
<fabbione> lamont: i already uploaded
<fabbione> mdz wants .12 in main asap
<lamont> buildd   18155  0.0  0.2  37800 17068 ?        SN   02:15   0:00 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18156  0.0  0.2  37800 17068 ?        SN   02:15   0:00 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18157 20.4  0.2  37800 17068 ?        RN   02:15  62:11 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18158 20.4  0.2  37800 17068 ?        RN   02:15  62:16 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18159 20.4  0.2  37800 17068 ?        RN   02:15  62:19 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18160 20.4  0.2  37800 17068 ?        RN   02:15  62:06 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe
<lamont> buildd   18161  0.0  0.0   2224   564 ?        SN   02:15   0:00  \_ c++filt -s java
* lamont throws SyncTest.exe at doko
* doko ducks
<lamont> otoh, your ada-test-b0rkage-killer seems to work fine
* lamont --> work
<doko> hmm, but somebody reported something with the acats-killer ...
<lamont> wow.  after killing all those doko-be-damned SyncTest.exe's, gcc-4.0 may actually finish building (it's installing now)
<lamont> Subject: Log for successful build of gcc-4.0_4.0.0-8ubuntu3 (dist=breezy)
<lamont> Build needed 19:17:02, 2076384k disk space
<lamont> admittedly, something around 5 hours of that was waiting for some nice admin to killall -9 SyncTest.exe
<lamont> I'm not sure if it's worse that I have a 24-port managed switch under my desk, or that there are 8 ports currently lit in it.
<lamont> wow. binutils wants 7 min on i386, 21 on ia64, and 94 on hppa.  WTH?
<lamont> hrm. probably binutils-hppa64
<\sh> lamont: libtool: link: `../lib/libh5tools.la' is not a valid libtool archive <- hdf5 only on ppc all other archs ok 
<doko> lamont: tausq did just email me:
<doko> fyi gcc-4.0 is significantly broken for hppa until #22051
<doko> (gcc bugzilla) is fixed....
<lamont> as in I should turn off the autobuilder until it is?
<doko> your decision, you're the port maintainer :)
<doko> forwarding the mail ...
<lamont> doko: we already switched to 4.0 for breezy, though.....  Time to go find out what "significantly broken" means
<doko> lamont: we did? ;) yes, sure, we have to.
<lamont> jbailey: you around?
<jbailey> lamont: Yup
<lamont> why did we disable glibc test suite for hppa (besides "because lamont said to")
<lamont> (see #parisc)
<lamont> doko: still awake by chance?
<doko> it's 10:30pm
<jbailey> lamont: We're Canonical employees, we're not permitted sleep.
<lamont> is our gcc-4.0 built using gcc-4.0?
<doko> no
<doko> 3.3
* lamont hugs doko
<doko> you're talking on #paris?
<lamont> yes
<lamont> uh....
<lamont> gcc-4.0 does not Build-Depend: gcc-3.3
<doko> gnat-3.3
<lamont> no, I meant gCC-4.0
* lamont is trying to work around the gcc-bug
<lamont> 22051, that is
<doko> gcc-4.0 b-d on gnat-3.3. gnat-3.3 depends on gcc-3.3
<lamont> ah, ok
<lamont> and how does the build invoke gcc to build things?  the only place that the string 'gcc-3.3' appears in the log file is in a Conflicts...
<doko> gnatgcc
<lamont> how, um, bizare
<lamont> so we know that no gcc-4.0 compiler is used in the building of gcc-4.0, right?
<lamont> er, that is: so we know that no -4.0 compiler is used in the building of gcc-4.0, right?
<doko> correct. unless you disable ada
<lamont> which hppa doesn't?
<doko> which server was #parisc on
<doko> no
<doko> but I should make it more robust and use gcc-3.3 explicitely.
* lamont nods
<doko> or 3.4 ...
<doko> so, what did you find out?
<jbailey> doko: #parisc is on oftc
<jbailey> (god, I almost said efnet for a sec...)
#ubuntu-toolchain 2005-06-25
<lamont> gcc-opt: forcing -O1
* lamont smiles
<jbailey> lamont: Can you tell me if hppa has succesfully built klibc?
<lamont> on debian?
<lamont> or ubuntu?
<lamont> latest, or ever?
<lamont> make[1] : Entering directory `/build/buildd/klibc-1.0.14'
<lamont> MCONFIG:90: klibc/arch/parisc64/MCONFIG: No such file or directory
<lamont> make[1] : *** No rule to make target `klibc/arch/parisc64/MCONFIG'.  Stop.
<lamont> fix your uname -m crap to strip the 64...
<jbailey> Okay.
<jbailey> Just that initramfs-tools 0.11 works for booting off of a harddrive, software raid1 and nfsroot now.
<jbailey> Is 2.6.13 really does drop devfs, then this will be it from then on. =)
<jbailey> s/Is/If/
<jbailey> Should I map hppa* to hppa, or just hppa64 ?
<lamont> parisc* -> hppa
<lamont> jbailey: way cool.
<jbailey> Hmm.
<lamont> and yeah, good that it's working that well.
<lamont> well, let me rephrase that...
<jbailey> No, the kernel considers your arch to be "parisc"
<lamont> kernel knows it as parisc or parisc64, depending on which kernel is running
<lamont> and in fact, has an ifdef that appends the 64...
<lamont> user space knows it as hppa
<lamont> so whichever is appropriate for your environment...
<jbailey> klibc is using this to grab the kernel headers.
<jbailey> for syscalls and such.
<lamont> hrm...
<lamont> package names have hppa{,64}{,-smp} versions, iirc
<jbailey> But it looks like there isn't really a separate parisc64 header set.
<lamont> there isn't - it's purely config diffs
<jbailey> I'm going to go with s/parisc*/parisc/ then.
<lamont> sounds correct for kernel space.
* lamont must run to meet family for dinner
<jbailey> Have a good one, I'll push this to upload now.
<lamont> hrmpf.  hppa is at 56.5%, sparc at 57.9% (installed)
<fabbione> morning
<fabbione> lamont: :)
<lamont> fabbione: but my builds go faster now, since I'm forcing -O1 for a max optimization level in g{cc,++}-4.0.
<lamont> otoh, ccache is slowly flushing
<fabbione> i am not using ccache on the external buildd
<fabbione> and i leave standard opts
<fabbione> but well.. i am ok at this speed :)
<lamont> dpkg: error processing tetex-bin (--configure):
<lamont>  subprocess post-installation script returned error exit status 30
<lamont> stupid tetex
<lamont> gonna have to fix that tomorrow
<fabbione> eh good idea :)
<lamont> already done, it appears
<lamont> tex/tetex-bin_2.0.2-30ubuntu3: Needs-Build [optional:out-of-date] 
* lamont moves tetex-bin to the head of the queue
<lamont> and depwait gtk+2.0 and linux-source-2.6.12 on the newer tetex-bin.  sigh
<fabbione> oh l-s-2.6.12 is FTBFS on sparc :)
<fabbione> i need to fix that ;)
<lamont> eventually, at least, eh?
<fabbione> probably, maybe, mostlikely :)
<lamont> the -O1 is a workaround for a g*-4.0 regression in the optimizer.  annoying
<fabbione> ah
<lamont> I'd rather be able to leave it at 0..3
<fabbione> i wonder if that also fixes some of my FTBFS
<lamont> might... although it's an hppa-specific regression
<fabbione> ah ok
<lamont> it would appear that some code misbehaves when it compares two function pointers for equality and gets told 'not equal', when in fact they are.
<fabbione> ah
<fabbione> YEAH
<fabbione> .12 is out
<lamont> so how soon will we upload 2.6.12-1.1?
<fabbione> that will be mostlikely 2.6.12-2.1
<fabbione> or do you truely believe that from rc6 to final they did not break the ABI?
<lamont> ah, we started being good and tracking, eh?
<fabbione> yes.. because we moved .12 in main yesterday :(
<lamont> we really should deliver the abi files as part of one (or each) of the kernel packages
<lamont> rather than scaping them from the log files
<fabbione> yeah that's in the spec..
<fabbione> we need to think deeper about it :)
<lamont> yeah - the proper place to put it would be linux-source, but that's arch: all --> no can do
<lamont> maybe add a package that is nothing but the abi spec files?  then you can install that and linux-source-2.6.NN, and have everything you need to build a kernel properly
* lamont realizes that he said he was going to bed about an hour ago.
<lamont> g'night
<fabbione> re
<fabbione> there is the b-d problem to do that
<lamont> hrm.. /me needs to deal with gcc-opt it appears.
<fabbione> good night
<fabbione> what's wrong with it?
<fabbione> it's a global problem or local?
<lamont> -O gets misparsed
<lamont> only if you restrict to < 2
<lamont> is it a problem, that is
<fabbione> ah ok
<lamont>                     else if (c=='\0')
<lamont>                         OptLevel=1;
<lamont> DOH!!!
<lamont> -O is == -O2, yes?"
<fabbione> whoops
* lamont kills the atlas build
<lamont> that hurts
<lamont> gcc -O
<lamont> gcc-opt: forcing -O1
<lamont> gcc-4.0.gcc-opt: no input files
<lamont> much better
<fabbione> r/sc
<fabbione> meh jb is not around
<fabbione> Total 1594 package(s)
<fabbione> Needs-Build :)
<fabbione> Total 621 package(s)
<fabbione> Building
<fabbione> -20 in the buildd
<fabbione> 601 in DepWait/FTBFS
<fabbione> not really encouraging
<fabbione> but most of them are missing B-D on X and DepWait
<fabbione> hey jbailey 
<jbailey> Fabio!
<fabbione> jbailey !
<jbailey> Tell me about klibc on sparc.
<fabbione> i did prepare a chroot with the new libc on sparc
<jbailey> I want it working on sparc and hppa today. =)
<jbailey> Ooo ooo ooo!
<fabbione> klibc is FTBFS
<fabbione> i think i told you already
<fabbione> now.. i have the chroot.. what do you want me to test with it?
<jbailey> Assume since you can get into it that shell and ls and friends work.
<jbailey> +I
<fabbione> yeah they do
* fabbione uploads
<jbailey> *lol* alright then. =)
<jbailey> I've only been awake for 6 or 7 minutes. =)
<fabbione> that's fine :)
<jbailey> Did you seriously just upload?
* doko things it's time to make fabbione unhappy ...
<fabbione> no.. i moved it to the upload dir...
<doko> s/g/k/
<fabbione> jbailey: i did test apt and such
<jbailey> t would be nice if you could test something that uses getpid
<jbailey> Like top
<fabbione> hmm
<fabbione> sure
<jbailey> REmember that this instance has the known clone bug in it.
<jbailey> Next upload will have that fixed (and hopefully some langpack love for pitti)
<fabbione> i trash langpacks
<fabbione> there is no way LP can access external buildds
<jbailey> Sounds like a bug.
<fabbione> doko: what are you going to upload?
<fabbione> jbailey: LP is designed to access only DC buildds
<jbailey> Then it's broken.
<jbailey> Becuase ports will never be DC.
<fabbione> jbailey: rule is: given port foo with a community, Mark will buy buildds to put at the datacenter
<fabbione> sparc and hppa are 2 exceptions
<fabbione> very special cased because it's lamont and me running them
* doko feels the level of uncertainty raise
<jbailey> How big does the community need to be? =)
<fabbione> jbailey: at least 50/100 users?
<jbailey> Oh, that's easy enough.
<jbailey> Hell, we have that many Hurd users. =)
<fabbione> we can start faking email addresses and domains to mail bomb Mark asking for them :)
<doko> fabbione: 4.0.1
<fabbione> but hounestly.. i did stop Mark from buying sparc buildd's
<fabbione> doko: dude.. get it right or i might knock on your door this evening
<jbailey> AH did 4.0.1 release?  I'm a couple days behind on the toolchain lists.
<doko> RC2
<jbailey> BUt initramfs now works for the three cases that I claim it should.
<jbailey> head is in stage 3 now, right?
<fabbione> jbailey: top seems to work fine
<fabbione> anything fancy you want me to test?
<jbailey> You don't have a spare machine, right?
<fabbione> nope
<jbailey> Oh well.  I would suggest booting with it usually.
<jbailey> Just because the change is so drastic.
<jbailey> GA and upload then. =)
<fabbione> yeah who cares :)
<fabbione> there are probably 4 sparc users out there
<fabbione> jbailey: in case it works.. you have to add a changelog entry for libc in debian:
<fabbione> "NTPL on sparc is dedicated to that Kamikaze of fabbione"
<fabbione> ;)
<jbailey> It won't happen in Debian until the sparc porters say clearly that they want it to happen.
<fabbione> ahaha
<fabbione> that will never happen
<fabbione> no.. really..
<jbailey> Exactly.
<fabbione> they can't even agree on what kind of toilet papers to use...
<fabbione> generally speaking i mean
<jbailey> Right.
<fabbione> Benc and davem are pretty sane tho
<jbailey> benc's last directive was 'don't to nptl'
<jbailey> A quick poll of the other Debian glibc folks say that they are not in a rush to move away from LinuxThreads.
<jbailey> So I do not expect to roll out nptl in Debian the way I have in Ubuntu.
<fabbione> you can still use a very good argument
<fabbione> "I overabused my Ubuntu powers to get it tested on 6 arches and it works...."
<jbailey> 5.  Hppa isn't there yet. =)
<fabbione> ".. but it's your call to decide"
<fabbione> ah right.. hppa is even behind on the buildd!
<jbailey> Right, and drow said "No.  Ubuntu may be able to get away with it, but Debian has a different situation"
<fabbione> for once i am satisfied for not being the slowest arch :)))
<jbailey> LOL
<doko> ohh, I didn't know that infinity did join the porting team ;-P
<fabbione> doko: no. i got the second buildd running
<doko> no m68buntu :-/
<fabbione> probably.. if we start m68buntu i will add 2 buildds here :)
<fabbione> anyway it's saturday.. the sun is shining.. my wife has backed a cake
<fabbione> cya later fellas
<fabbione> Uploading via ftp glibc_2.3.5-1ubuntu7_sparc.changes: done.
<fabbione> Successfully uploaded packages.
<fabbione> ENJOY THE RIDE
<jbailey> fabbione: Lovely.  Unblock glibc from the buildd then, please? =)
<fabbione> i did already
<fabbione> ;)
<fabbione> i am off
<jbailey> c'ya Fabio!
<doko> lamont, infinity: please could you look at the build failure of db4.2 on i386? gij-4.0 is supposed to install the /usr/bin/java symlink as an alternative
#ubuntu-toolchain 2005-06-26
<infinity> doko : TBH, I'm more curious about why it didn't fail on amd64, not why it did fail on the other 3 arches...
<doko> heh, you finally did wake up? :P
<infinity> Hey, it's a weekend, give me a break. :)
<doko> it does build locally, anyway, it's not that urgent
<infinity> Nothing's urgent on a Sunday.
<doko> true :)
<infinity> If there was any urgency at all today, I'd be fixing Xorg.
<doko> it' 1am, so good night!
<infinity> But, y'know.  Watch me not care until tomorrow.
<infinity> G'night. :)
<lamont> doko: configure:21121: gcj-wrapper  Test.java
<lamont> ../dist/configure: line 21122: gcj-wrapper: command not found
<lamont> configure:21124: $? = 127
<lamont> Build-Depends: tcl8.4-dev, procps [!hurd-i386] , fastjar [!hppa !mips !mipsel !hurd-i386] , gij [!hppa !mips !mipsel !hurd-i386] , libgcj-dev [!hppa !mips !mipsel !hurd-i386] 
<lamont> although that just explains the failure on hppa...
<lamont> please remove the !hppa from all those doko.  kthxbye
<fabbione> morning
<fabbione> jbailey: interesting:
<fabbione> Unpacking replacement libc6 ...
<fabbione> FATAL: kernel too old
<fabbione> but right :)
<doko> infinity, lamont: please could you get the config.log file from the failed db4.2 builds?
<infinity> doko : Yeah, I'll have to spin it again.  Gimme a few minutes.
<infinity> doko : Yeah, I'll have to spin it again.  Gimme a few minutes.
<infinity> doko : rookery:~adconrad/ has the failed tree.  config.log doesn't appear terribly enlightening, though.
<doko> infinity: hmm, and is it possible to verify, that /usr/bin/java exists?
<doko> or I make an upload and just add an ls
<infinity> If it's shipped in the build-deps, it exists...
<doko> gij-4.0 adds an alternative to java
<infinity> Ahh, I wonder if the alternatives are broken, due to a broken package in the past.
<infinity> That can happen.
<infinity> Let me stop the buildd and fiddle in the chroot.
<infinity> And that's the issue, alright.
<infinity> In a clean chroot:
<infinity> root@vernadsky:~ # update-alternatives --display java
<infinity> java - status is manual.
<infinity>  link currently points to /usr/lib/jvm/java-gcj/bin/java
<infinity> No versions available.
<infinity> So, somewhere in the past, a broken package fucked the alternatives.
<doko> looks like java-gcj-compat ...
<infinity> You may want to see if the package in question is still buggered.
<infinity> But I can hit all the chroots and manually reset the alternatives to automatic to fix it for now.
<infinity> (But if a package is breaking it, that package may break it again when it's installed)
<jbailey> fabbione: Mmm, yeah.  I forgot the preinst guard, thanks.
<jbailey> doko: I've been thinking of adding something to cdbs where if the configure step fails that it spews out config.log to stdout (so it'll get caught by the build log)  Interested?
<doko> yes, found it :-/ wasaaaaabi !!!!
<infinity> doko : Alright, I'm resetting all the chroots' alternatives and will respin db4.2 for you.  If you want to fix gcj-compat so this doesn't happen again, that'd be nice. :)
<doko> jbailey: yes, sounds nice, but it doesn't catch the alternatives thing
<jbailey> doko: Shouldn't the list of packages installed at the top catch that?
<doko> ?
<jbailey> The top of the logs shows which packages were installed.
<infinity> jbailey : If a package fails to remove its alternative, things can go seriously tits-up.  The alternatives system is a bit fragile.
<infinity> jbailey : There are bugs in the Debian BTS about this.  It breaks buildds from time to time.
<jbailey> Oh, I see.
<jbailey> Oh, I see.
<jbailey> bah
<infinity> In fact...
<infinity> doko : Didn't the amd64 build complete because gcj-compat was still installed (dirty chroot, I suspect)?
<infinity> doko : I remember the log looked different for amd64 than other arches, WRT java stuff.
<doko> infinity: I didn't look at the amd64 log ;)
<infinity> There, all the chroots fixed.  Respinning the builds now.
<infinity> Woo.
<infinity> doko : Did you break gij between the last db4.2 builds and now? :)
<infinity> gij: Depends: gij-4.0 (>= 4.0.0-7) but it is not going to be installed
<doko> infinity: yes, fixed in -ubuntu2
<doko> infinity: yes, fixed in -9ubuntu2
<doko> I did not break it, I did improve it.
<infinity> Ahh, that version is still building on powerpc and ia64.  Feh.
<doko> yes, we should have a ppc64 kernel on the buildd's
<infinity> We'll get there soon.
<infinity> Need to get elmo to install said kernel, and we need to unilaterally linux32 buildd on all the buildds, on the off chance that packages do Very Bad Things when they see they're running on ppc64.
<infinity> Not a lot of work, just needs some co-ordination this week, and someone to prioritise it.
<infinity> Wow, creepy.  powerpc and ia64 are at exactly the same place in the testsuite right now.
<infinity> (Which is "nowhere near the end")
<fabbione> jbailey: no no.. the test is fine.. it detected correctly a 2.4 kernel
<infinity> doko : db4.2 was happy on i386, though, where gcc-4.0 is up to date.
* infinity sets db4.2 to dep-wait on the other two arches.
<doko> cool, thanks
<fabbione> oh crap
<fabbione> doko: another gcc upload eh?
<infinity> doko : Any other weird failures on your "to investigate" list?
<doko> fabbione: no
* infinity hates broken alternatives with a passion.
<doko> next one is 4.0.1 when it gets released
<infinity> Yay!
<fabbione> doko: you upload 9ubuntu2
<infinity> What's the time frame for 4.0.1?
<fabbione> don't lie!
<fabbione> ;)
<fabbione> i don't think we will manage to get it before UVF
<fabbione> doko: UVF is in less than 2 weeks
<doko> fabbione, you didn't ask for the version :P
<doko> fabbione: we will. release should be next week
<fabbione> doko: well after 12 hours in the build..gettting the other one is a pain
<fabbione> given that all the build time is wasted
<infinity> Aww, pumpkin.
<infinity> FEEL MY PAIN.
<fabbione> infinity: we need to find a way to bootstrap ghc6 :)
<fabbione> right now we are in one big unbreakable loop
<infinity> Yu and ghc are having issues?
<infinity> I remember bootstrapping it not that long ago, actually.
<infinity> On Debian, but same shit.
<fabbione> no ghc6 is having issues everywhere
<fabbione> infinity: wanna better in Ubuntu is more complicate?
<fabbione> s/better/bet
<infinity> Ian and I went through the pain of bootstrapping it on m68k together, IIRC.
<fabbione> yes but you had ghc5 available.. didn't you?
<infinity> If it mixes and matches stuff from main and universe, that could make it worse.  Otherwise, it should be exactly the same pain.
<infinity> No, ghc5 only existed on i386.
<fabbione> hm ok
<infinity> All other ghc6 arches had to be bootstrapped by hand.
<fabbione> because upstream bootstrap is broken as it is
<fabbione> and of course nobody cared to fix it while bootstrapping
<infinity> Yeah.  This is known.
<infinity> I'd recommend getting Ian involved.
<infinity> Unless he's an Ubuntu-hating nut (and I doubt it), he's pretty keen on making ghc6 widely-available and bootstrappable.
<fabbione> does he do irc?
<infinity> No idea...
<fabbione> because we might have to bootstrapping it again on all arches
<infinity> Yup, igloo.  Idle 11 mins.
<infinity> Should be around.
<fabbione> ok
<infinity> I just invited him to come play in here.
<fabbione> ah ok
<\sh> could someone be so nice and check this out? http://people.ubuntu.com/~lamont/buildLogs/h/hdf5/1.6.4-2ubuntu1/hdf5_1.6.4-2ubuntu1_20050617-1417-powerpc-failed.gz
<infinity> I make it a policy not to look at build logs with the word "libtool" in the failure...
<fabbione> good policy
<infinity> In the tradition of "all things powerpc suck until we get a new kernel", I'm just going to retry it for you.
<fabbione> i use the same :)
<fabbione> infinity: .12 final is out.. i hope i can get it in the archive tomorrow or tuesday
<fabbione> after that i am pretty sure elmo will be quite happy to install it around
<infinity> fabbione : Rock.
<infinity> fabbione : My PPC mahcine gets here in a day and a half!  Yay!
* infinity missed it terribly.
<fabbione> doko: do you plan to upload another gcc-4.0 in the next 24 hours?
<doko> no
<fabbione> doko: are you sure?
<doko> no
<fabbione> doko: are you ABSOLUTELY sure?????
<doko> :)
<doko> 4.0.1 won't get released tomorrow ...
<fabbione> ok
<Igloo> Hello
<fabbione> hi Igloo 
<infinity> fabbione : You're the man with the questions, Igloo's (hopefully) the man with the answers.
<Igloo> If you're worrying about ghc6 6.2.2 not being able to buld 6.4, that's hopefully a rare event
<fabbione> Igloo: we have some ghc6 fun atm.. i was hoping you could help :)
<infinity> Igloo : More about scorched-earth bootstrapping.
<fabbione> Igloo: we need to bootstrap from scratch :)
<fabbione> because of libgmp3 c++ transition.. ghc6 becomes uninstallable
<fabbione> so we need to rebootstrap ghc6 to build on top of the new libgmp3c2
<fabbione> but my attempts are failing miserably.
<fabbione> infinity: remeber you will have to do the same dance on i386/ppc/amd64/ia64 :)
<infinity> A static compile of the old ghc would solve that problem.  But we still need to be able to do a scroched-earth bootstrap anyway, so it's worth investigating.
<fabbione> Igloo: so i was wondering if you have time to go trough it with me
<infinity> scorched, even.
<Igloo> Ah, rats. Is libgmp entirely C++, or is it possible ghc is only using C bits?
<fabbione> libgmp3-dev Depends: libgmp3c2
<fabbione> i think it's pure c++
<fabbione> Igloo: but i was more concerned to make the overall clean..
<infinity> Not true.
<doko> Igloo: perl -pi -e 's/libgmp3/libgmp3c2 | libgmp3/' debian/<pkg>.substvars
<infinity> It's two libs in one package, cause the maintainer SUCKS.
<fabbione> like being able to bootstrap, setting a var in debian/rules
<infinity> It's a C lib and a CXX lib.
<doko> fabbione: no
<Igloo> Have you seen the instructions on http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html#unregisterised-porting ? Those should work if nothing else does
<doko> gmp (4.1.4-6.1) unstable; urgency=high
<doko>   * NMU coordinated with the maintainer. Upload as a build dependency
<doko>     for building gfortran-4.0 with the changed library name.
<doko>   * Split out the C++ library in it's own package libgmp3++. The libgmp3
<doko>     package is renamed to libgmp3c2, or else packages relying on the C++
<doko>     library in libgmp3 will break.
<doko>   * Let a dependency on libgmp.so.3 be satisfied by 'libgmp3c2 | libgmp3',
<doko>     allowing transition of packages to etch, which do not depend on the C++
<fabbione> Igloo: no i did try to use several ./configure options... but i can look at it
<doko>     library, before libgmp3c2 and libgmp3++ reach etch.
<doko>   * Explicitely build using g++-4.0, build for i486, not i386.
<doko>   * Call dh_makeshlibs in the install target, not the binary-common target.
<infinity> doko : Ah-ha.  Did you do that?
<infinity> doko : If so, I love you.
<doko>  -- Matthias Klose <doko@debian.org>  Sun, 12 Jun 2005 10:32:34 +0200
<infinity> doko : Why did you never upload? :)
<fabbione> doko: see.. don't sell me shit you uploaded this morning in Debian :)
<doko> waiting for binutils ...
<infinity> Ah.
<infinity> Well, can we get that uploaded to Ubuntu, like, two days ago?
<fabbione> doko: because iam trying to work with what's in the archive :)
<infinity> (Or has it already?)
<doko> nah.
<infinity> Did you split all three libs, or just the CXX lib?
<Igloo> /usr/lib/ghc-6.4/ghc-6.4 is linked against libgmp.so.3 but not libgmpxx.so.3, so I'd guess it would work to just forcibly install the new libgmp3 and old ghc6 together to build the new ghc6?
<doko> infinity: just C++
<infinity> Igloo : Yes, that would work for the problem at hand.
<infinity> Igloo : Of course, the question of scorched-earth bootstrapping is still a curious one. :)
<fabbione> Igloo: yeah but we don't have the previous ghc6 on all arches.. yet :)
<Igloo> fabbione: The above URL should help you with that. Or just bootstrapping from the Debian packages.
<fabbione> Igloo: i am bootstrapping from the Debian packages.
<Igloo> infinity: First you'll need to write a Haskell compiler in C which supports the extensions GHC's source uses.
<infinity> Hrm, good point.  We're missing it on ia64 (and I assume sparc and hppa?)
<Igloo> Oh...do you have more arches than Debian then?
<fabbione> infinity: we can probably use ghc6 from Debian, but that means doing a lot of extra rebuilds
<infinity> Igloo : No, fewer.  We have amd64, i386, and powerpc officially (and those all have ghc6 builds already), and ia64, sparc and hppa unofficially (none of which do, I suppose, but we have Debian packages for all of them)
<infinity> fabbione : A two-pass bootstrap should be good enough.
<fabbione> infinity: for 2/3 reiterations required to build ghc6 and haddock (and another 2 pkgs iirc)
<fabbione> infinity: yes but it is extended to more than ghc6 :(
<infinity> fabbione : But I'll test this theory on ia64, since I need to anyway.
<fabbione> that's why i would prefer direct bootstrap
<infinity> How many packages are stuck this way right now?
<fabbione> Igloo: only i386/ppc/amd64 are official
<fabbione> Igloo: the others are unofficial ports
<infinity> doko : And can we get that split gmp upload done as 6ubuntu2 ASAP?
<fabbione> infinity: i think it's a 3 pkgs loop. ghc6 haddock and a b-d for haddock (that b-d on ghc6
<infinity> That doesn't sound so bad.
<fabbione> infinity: so i think it's easier to just bootstrap ghc6 from scorched earth
<fabbione> infinity: and break the overall
<infinity> Where does haddock come in?
<infinity> I don't see it as a build-dep for ghc...
<Igloo> haddock is used to build ghc's documentation
<doko> infinity: yes, do you need it now? not really. and in ubuntu, libgmp3c2 needs to depend on libgmp3++ anyway.
<fabbione> infinity: it's in the b-d
<infinity> Oh, docs are no big deal.  That's part of a 2-pass bootstrap.
<infinity> Like we need arch:all stuff in a bootstrap compiler.
<infinity> doko : Not if we do a mass-rebuild to fix the deps in Ubuntu.  We have this poower.
<infinity> doko : Breaking breezy is not only okay, it's encouraged.  So we should do it.
<infinity> doko : I see no reason (except for breezy->breezy upgrades, which are so NOT supported right now) for libgmp3c2 to depend on libgmp3++
<infinity> Igloo : All this aside, is there any reason why the ghc6 packages can't currently do a pure bootstrap on their own the handholding of that readme you pointed us to? :)
<infinity> s/their own/their own without/
<fabbione> make[1] : *** No rule to make target `Apply.o', needed by `libHSrts.a'.  Stop.
<fabbione> make: *** [all]  Error 1
<fabbione> that's the same place where i crashed before
<fabbione> Don't worry if the build falls over in the RTS, we don't need the RTS yet.
<fabbione> AH
<fabbione> crap
<fabbione> yeah but later libraries don't build
<infinity> \sh : hdf5 on powerpc went fine with a retry, by the way.
<infinity> doko : Still around?
<infinity> doko : That dpkg build-dep is utterly useless.  I assume you wanted a versioned build-dep on dpkg-dev, not dpkg...
<infinity> doko : Not worth an upload to fix, since the Ubuntu chroots are all up to date anyway, but worth fixing in your local repo before you do a -10 upload to Debian, or another Ubuntu upload.
<doko> infinity: ok, will fix it.
<infinity> Danke.
<fabbione> hmmm
<fabbione> of what package?
<fabbione> infinity: you will need gcc-3.3 for ghc6
<doko> fabbione: did you have fun on the TV ;-)
<lamont> historically, we've just bootstrapped from debian if that's an option
<fabbione> doko: haven't seen the race yet.
<fabbione> they didn't broadcast it yet
<fabbione> (fsckuers)
<fabbione> lamont: doesn
<fabbione> lamont: doesn't build anyway :)
<fabbione> bah
<fabbione> they did broadcast only the first lap
<fabbione> bastard
<zul> fabbione: you are up late
<fabbione> zul: i was hoping to see the F1 race
<zul> ah..
<zul> let me guess ferrari fanboy right?
<fabbione> yeah
<fabbione> and than they show the first lap and stop bradcasting
<fabbione> danish tv is the sucks
<fabbione> i need to get some satellite stuff
<fabbione> i think i am going to get some sleep
<fabbione> cya tomorrow
<jbailey> fabbione: Right, but for all the other archs there's a preinst check that verifies the kernel version and gives a sensible error message.
#ubuntu-toolchain 2006-06-21
<jbailey> dwmw2: Heya. =)
<dwmw2> afternoon
#ubuntu-toolchain 2006-06-22
<jbailey> doko: In the edgy roadmap, I thought I was going to look at fully multiarch'ing glibc?
<jbailey> And I could do lkh easily.
<doko> jbailey: sure, let's add this as a target, maybe marking it as non-essential (may be moved to edgy+1)
<jbailey> Right.
#ubuntu-toolchain 2007-06-21
<bashelier> doko: ping
#ubuntu-toolchain 2008-06-16
<jbailey> lamont, OyOyOy
<lamont> ??
<jbailey> "hi"
<lamont> meeting atm, should be over soonish
<jbailey> np =)
#ubuntu-toolchain 2008-06-18
<lamont> jbailey: you awake?
<jbailey> lamont, Whups, forgot to close IRC last night.
<lamont> heh
<lamont> g'morning
<lamont> you were gonna look at bind9 autocrap?
<jbailey> Right, had forgotten.  Sure. =)
 * jbailey fires up the laptop.
<jbailey> Is this upstream or a package?
<jbailey> And which distro?
