#ubuntu-toolchain 2005-06-06
<fabbione> morning
<jbailey> Heya Fabio
<fabbione> hey Jeff
<fabbione> scp makediff rookery.warthogs.hbd.com:public_html/rhcluster-make.diff
<fabbione> makediff                                                                                                                    100%   52KB  51.7KB/s   00:00    
<fabbione> Killed by signal 1.
<fabbione> jbailey: are you sure the latest crack is working properly?
<fabbione> i am getting a lot of sig 1
<fabbione> or probably it's just ssh
<fabbione> yeah
<fabbione> indeed
<jbailey> Which crack?
<jbailey> The glibc?
<fabbione> i will bug Kamion
<fabbione> yeah
<fabbione> well i dist-upgraded yesterday
<fabbione> so probably it's ssh
<jbailey> Which arch?
<jbailey> ppc was the only one that got changes, and it just grew ppc64 bits.
<jbailey> The biarch configs aren't really associated with one another, so there should be 0 effect.
<fabbione> i386
<jbailey> Hmm, I don't have a current breezy i386 system.
<fabbione> <fabbione> i will bug Kamion
<fabbione> i think it's only ssh
<fabbione> they looked more apps
<jbailey> Right, but since I'm here I'm just trying to think my way through whether it's possibly my fault. =)
<fabbione> but i realized i was only using a combination of apps with ssh backend :)
<fabbione> so with the ppc64..
<fabbione> what versions and what b-d do i need to add?
<fabbione> for example:
<fabbione> Build-Depends: debhelper (>= 4.2.28), gcc-3.4, libxml2-dev, libncurses5-dev, libc6-dev-sparc64 [sparc] , libc6-dev-s390x [s390] 
<fabbione> do i need to add libc6-dev-powerpc64 ?
<jbailey> libc6-dev-ppc64
<fabbione> or something along that line?
<fabbione> ok
<jbailey> Whatever the current gcc-3.4 is for a versioned dep on that.
<jbailey> 3.4.4-0ubuntu4
<fabbione> Version: 3.4.4-0ubuntu4
<fabbione> rocking
<fabbione> # ifneq (,$(findstring $(DEB_HOST_ARCH), s390 sparc powerpc))
<fabbione> :)
<fabbione> anyway the biarch build of rhcluster is disabled
<fabbione> because of the linking issue
<jbailey> *lol*
<jbailey> Just easiest for now?
<fabbione> i couldn't figure out why it fails
<fabbione> jbailey: as soon as i have the package in archive, we can work on it officially
<fabbione> since there will be ppc binaries :P
<jbailey> Right.
<fabbione> or since we should fix it for ppc64... we perhaps can do it before hand
<fabbione> using sparc for testing...
<fabbione> both ways work for me
<jbailey> Well, it's incentive for you to make me appc64 kernel. ;)
<fabbione> given that the 64bit is purely cosmetic
<jbailey> I tried to install svenl's and got a strange error when unpacking.
<jbailey> mmap error of some sort.
<jbailey> I haven't investigated it at all.
<fabbione> jbailey: i will start working on ppc64 kernels tomorrow
<fabbione> right now i need to do more userland stuff
<fabbione> since the rhcluster package has some implications
<fabbione> like providing b-d for main
<jbailey> Ah, what's today in userlanf?
<fabbione> still rhcluster
<fabbione> i need to split the package and start looking at init scripts
<fabbione> i need to change branch in the kernel patches to match userland
<fabbione> and verify the binary compatibility of my libs with the one in debian
<fabbione> given that the source come from 2 different upstream branches
<fabbione> and that the debian packages are pretty old
<fabbione> since upstream is messy, i might need to do a soname transition
<fabbione> that would probably be the safest thing to do anyway
<fabbione> (and it requires only one or two packages upload)
<fabbione> but one of them is lvm :P
<jbailey> Joy.
<jbailey> I'm hoping to send more time on EarlyUserspace this week, so I may need to poke you a bit.
<fabbione> jbailey: sure...
<fabbione> i saw that initramfs is already supported in the kerne
<fabbione> kernel
<fabbione> and there is a nice debugging message in dmesg about it
<jbailey> Right.  I've been using distro Ubuntu kernels since January.
<fabbione> let me know when we should try to switch
<jbailey> NFS mount works, mounting a harddrive works.
<jbailey> This weeks goals are to get udev finally happy with lkh and klibc and then to make an attempt to port all the logic over from initrd-tools to initramfs for guessing the modules.
<jbailey> Once that happens we can just switch and be done with it.
<jbailey> I can do all the hotplug work as options.
<jbailey> (Which eventually become the default)
<fabbione> if initramfs needs klibc, we need to check if it is built everywhere first
<jbailey> http://people.ubuntulinux.org/~lamont/buildLogs/k/klibc/1.0.10-0ubuntu1/
<jbailey> *success*
<fabbione> i need to build that version on sparc
<fabbione> the one before was FTBFS
<jbailey> Yar.
<fabbione> just creating the chroot right now :)
<fabbione> unfortunatly klibc is in universe
<fabbione> and it takes ages to get there again
<fabbione> remember you will need to seed it to main before switching over
<jbailey> I will start begging on my knees for you to post logs to where the rest of them are.
<fabbione> otherwise we will seriously make boom boom
<jbailey> It simply doesn't occur to me to look elsewhere most of the time.
<fabbione> jbailey: i did talk with elmo already about it
<fabbione> but he didn't give me a full solution yet
<fabbione> jbailey: i understand perfectly the problem
<fabbione> lamont has the same issue
<fabbione> for hppa
<fabbione> i will try to ping elmo again today
<jbailey> Well, he will once he starts to actually build things.. ;)
<fabbione> because it's in everyone interest
* jbailey hides.
<fabbione> ehehe
<fabbione> Get:20 http://debdev.ext.fabbione.net breezy/universe linux-headers-2.6.12-1 2.6.11.92-1.1 [6290kB] 
* fabbione thinks...
<fabbione> we will need the new kernel in main to move klibc
<fabbione> also.. remember that these headers are not final yet
<fabbione> so stuff might break for little while :)
<jbailey> udev will move klibc.
<jbailey> THe kernels will pull in mkinitramfs eventually which will also bring them in.
<jbailey> Which headers?
<jbailey> Oh, Isee.
<jbailey> right.
<jbailey> Right now I'm using lkh for everything else.  I pulled in the real headers for this one to avoid the hacking hassle.
<jbailey> I now have commit rights to upstream lkh, which will be very helpful.
<fabbione> right
<fabbione> but real kernel headers come from me
<jbailey> Upstream linux-libc-headers, rather.
<jbailey> Right, but lkh ought to be good enough for everything.
<fabbione> good :)
<jbailey> Any place where it isn't is a place wher eI'm going to get a bug at some point.
<jbailey> I'm using the linux-libc-headers project becaus eI'm hoping he'll get enough distros using it that it becomes the ABI headers.
<fabbione> specially because we want to avoid to have a huge circular b-d on the kernel
<jbailey> It's annoyingly unlikely, but he's kept at it for a year.  There's two distros using it now.
<fabbione> kernel -> klibc -> initramfs (to boot/install the kernel)
<jbailey> He's hoping to bring Gentoo on board.
<jbailey> Err.  the kernel shouldn't dep on klibc.
<jbailey> it should dep on initramfs-tools
<fabbione> In file included from system.c:13:
<fabbione> ../include/signal.h:81: warning: 'struct sigaction' declared inside parameter list
<fabbione> ../include/signal.h:81: warning: its scope is only this definition or declaration, which is probably not what you want
<fabbione> system.c: In function 'system':
<fabbione> system.c:19: error: storage size of 'ignore' isn't known
<fabbione> system.c:19: error: storage size of 'old_int' isn't known
<fabbione> system.c:19: error: storage size of 'old_quit' isn't known
<jbailey> Hah, joy.
<fabbione> no but klibc needs the kernel to build :)
<jbailey> That means the real kernel headers are fucked.
<fabbione> jbailey: mostlikely yes....
<jbailey> I'll get off my ass and clean up all the signal/socket stuff then.
<jbailey> That's the bits that I had to pull in the real headers for anyway.
<fabbione> jbailey: i think it is more wise to make klibc to use l-k-h or whatever you had in your mind
<jbailey> Upstream for llh stubbed them out because glibc provides it all in private headers.  klibc assumes the use of upstream.
<fabbione> because the kernel changes too fast for userland to follow
<jbailey> Yes and no.
<fabbione> and even a security update can mess up that stuff
<jbailey> If the C library can't keep up with the kernel abi, then nothing can.
<jbailey> Esp. the C library that's intended to be bundled with the kernel. =)
<fabbione> ehhe
<jbailey> Sometime in June is when you drop devfs support, right?
<jbailey> Want to try to make it a goal for Monday next week? =)
<fabbione> jbailey: i will drop devfs together with upstream
<jbailey> What?!?  You're not going to be a bastard and drop it a release early like you did with ipchains/ipfwadm??
* jbailey grumps.
<jbailey> =)
<ajmitch> people still use devfs?
<fabbione> jbailey: "release early" was only a patch from upstream :)
<fabbione> but if you like i can drop it right away
<fabbione> doko: ping?
<fabbione>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
<fabbione>  /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: could not read symbols: Bad value
<doko> hmm, which package?
<fabbione> the package is not in the archive yet
<fabbione> but it builds fine on all other arches
<fabbione> modulo ia64
<fabbione> the source is in my home dir on concordia, if you want to look at it
<fabbione> but from the error it looks like gcc-3.4 is borked on amd64
<fabbione> doko: it happens with gcc-3.3 too
<fabbione> but the code is compiled with -fPIC
<doko> some assembler code?
<fabbione> doko: apparently now
<fabbione> not
<doko> any libs involved?
<fabbione> doko: it's building a lib
<fabbione> actually....
<Kamion> jbailey: the ssh thing can't be your fault; it's happening in Debian too
<doko> fabbione: let have me a look later this weej
<fabbione> doko: nah i think i did something royally stupid merging some changes from upstream
<fabbione> and it shows up only on amd64
<fabbione> yeah.. it builds fine
<fabbione> sorry for the mess :((((
<fabbione> elmo: can you please install libxml2-dev in breezy-ppc64 chroot on davis?
<fabbione> (and also kernel build-deps)
<fabbione> ah hold on... today is holidays in uk...
<fabbione> crap
<fabbione> yeah
<jbailey> fabbione: Is it something you want me to hack on?  I have ppc64 locally.
<fabbione> jbailey: nothing urgent.. i was only trying to build the rhcluster suite on ppc64 multiarch before upload
<fabbione> we can do that anytime later
<jbailey> Ah, yeah.  I could probably build it but not test it until the kernel is done.
<fabbione> jbailey: exactly :)
<fabbione> + actually the 64 bit libs are there just for fun
<fabbione> since no binaries need them atm
<jbailey> Is the cluster done in userspace or is this just hooks into the kernel?
<fabbione> kernel and userspace
<fabbione> jbailey: you around?
<jbailey> fabbione: Yup
<fabbione> jbailey: see /msg
<fabbione> there are more errors after that...
<jbailey> Bah, you should just paste in here.
<jbailey> But anyhow.
<fabbione> does it sound possible that libc6-dev is broken?
<fabbione> this is i386
<fabbione> and i am compiling something that is absolutely unrelated to ubuntu :)
<jbailey> It's always possible.  It's pretty rare.
<jbailey> LEmme see if I get the same on ppc.
<jbailey> (My breezy i386 system is being wiped today for a reinstall)
<fabbione> oh it's not redhatcluster :)
<fabbione> acutally you are right.. i can try that in hoary
<jbailey> Right, what app is it?
<jbailey> Works in Hoary doesn't necessarily mean correct.  There's a new glibc - sometimes things change/break/whatever.
<fabbione> jbailey: http://gridengine.sunsource.net/servlets/ProjectSource
<fabbione> jbailey: there is a page where to get the tar.gz
<fabbione> http://gridengine.sunsource.net/servlets/ProjectDocumentList
<jbailey> Fatal error, aborting.
<jbailey> anoncvs: no such user
<fabbione> here is
<jbailey> Ah good. =)
<fabbione> sge-V60u4
* jbailey fetches
<fabbione> hmm you need java to build
<jbailey> Hmm.
<jbailey> I wonder if gcj is good enough.
<jbailey> (It had better be, or this is headed to multiverse.. =( )
<jbailey> What is it with people and crappy build environments?
<fabbione> hmm sablevm is enough
<jbailey> This is a *solved* problem for the most part.
<fabbione> and it's building in hoary
<jbailey> If sable can do it, then gcj/gij/ecj can.
<fabbione> i think java is used only in the build scripts
<jbailey> Which step is failing for you?
<fabbione> it's the usual java crap from sun to create junk that already exists outside 
<fabbione> read source/README.build
<jbailey> I'm looking at that.
<fabbione> after you run ./aimk depend
<fabbione> that one completes fine
<jbailey> Ugh.
<jbailey> Needs csh
<fabbione> the next step is to just run ./aimk to build
<fabbione> it fails immediatly
<fabbione> at the libs
<fabbione> breezy.. in hoary it's building
<jbailey> ls
<fabbione> you will need libgjcX-dev
<jbailey> YEah, those all come as part of java-gcj-compat
<jbailey> _________C_O_R_E__S_Y_S_T_E_M_____________
<jbailey> ../common/Makefile:67: ../common/common_dependencies: No such file or directory
<jbailey> hmm
<jbailey> Whups, had skipped a step
<jbailey> Wow, more errors than my terminal backscroll. =)
<fabbione> ehhehe
<fabbione> this crack makes me enjoy my pc :))))
<jbailey> Lovely, I see the same error here.
<fabbione> good
<fabbione> because it's building in hoary :)
<fabbione> there are a few tons of build-deps...
<fabbione> but it's fun! :P
<jbailey> No definition for __const
<jbailey> Hmm, what should pull it in?
<fabbione> where do you get that?
<jbailey> typedef int (*__gconv_fct) (struct __gconv_step *, struct __gconv_step_data *,
<jbailey>        __const unsigned char **, __const unsigned char *,
<jbailey>        unsigned char **, size_t *, int, int);
<jbailey> That's what I get running the failing command through -E -dD
<jbailey> Are you familiar with those switches to gcc?
<fabbione> oh...
<fabbione> nope...
<fabbione> i am not a gcc/glibc expert :)
<fabbione> i was trying to see some of the stuff you did last time in screen :)
<jbailey> -E says "spit out what the compiler sees after cpp has had it's way", -dD tells it to let me know where various #defines and such happen.
<fabbione> at least i understood how to read -v :P
<jbailey> Hey glad to help where I can. =)
<fabbione> yeah i learn fast :)
<fabbione> or at least i try to
<jbailey> Although when doing this with glibc headers, it's often helpful to have seen them a few times before.  They occasionally have crazy magic in them.
<fabbione> no shit :)
<jbailey> but gcc -E has to be something a compiler can understand, so that's where I usually start.
<jbailey> fabbione: Can you help me look for something?  Save me loading a bunch of development crap on my wife's machine.
<jbailey> (It's the Hoary one, I don't have any Java dev stuff on it)
<jbailey> Mm, no it looks like __const is a gcc-4 builtin anyway.
* jbailey looks for something else then.
<fabbione> jbailey: sure.. just ask what you need
<jbailey> Erm, on my system anyway it seems to be prefering /usr/include/linux/stddef.h to gcc's one.
<jbailey> It does that with 3.3 on breezy, too.
<jbailey> fabbione: Do you have a build log?  Can you show me the command that it's calling for that file on your hoary install?
<doko> is /usr/include explicitely in the include path (-I option)?
<jbailey> doko: It is here.
<jbailey> But stddef is in /usr/lib/gcc...
<doko> that's just wrong, gcc get's confused with include_next ...
<jbailey> /usr/include/linux is also explicetely in there, which is strange.  I'm used to things #include <linux/FOO.h>
<fabbione> jbailey: yes.. in a few minutes.. i need to figure how to make clean in the source...
<jbailey> fabbione: rm -rf LINUXPPC_26 ? =)
<fabbione> jbailey: hehe possibly.. but i am almost done with the build :)
<fabbione> there is the need of a little patch to make it compile 100%
<fabbione> but that's easy :)
<fabbione> jbailey: it's building now....
<fabbione> as soon as it's done i will upload the log
<jbailey> Tx.
<fabbione> no problem :)
<jbailey> My guess is that the -I flags are slightly different between the breezy and hoary versions for some reason.
<fabbione> hoary_log.txt
<fabbione> on people.u.c/~fabbione
<doko> -I/usr/include -I/usr/include/linux is just evil
<jbailey> Right, so on Hoary it's not feeling the need to include /usr/include and /usr/include/linux in the gcc command line.
<jbailey> fabbione: Can I leave it with you from there?  I suspect once those both go away you'll be fine.
<lamont> doko: evil, and breaks #include_next, iirc
<fabbione> jbailey: sure...
<fabbione> i was only concerned about the error coming from a glibc include file...
<jbailey> fabbione: Right - I just wanted to make sure you didn't need any more info from me before I rm -rf'd my tree locally.
<fabbione> jbailey: if you are sure that's the problem, i am happy with that
<fabbione> jbailey: and i will dig from there
<jbailey> fabbione: Pretty certain.  If you look at the failing command with -E -dD, you'll see that size_t is never definned.  When you look at stddef.h, you see that it's being pulled in from /usr/include/linux instead of /usr/lib/gcc/.../include/stddef.h
<doko> lamont: yes, scroll back a bit more ;)
<jbailey> *bounce*
<doko> lamont: thanks for the buildd toolchain love on the weekend
<lamont> doko: sorry that the family had me as busy as it did...
<doko> lamont: no reason to have an excuse for that :-)
<fabbione> jbailey: that's right... eliminating the -I/usr/include/linux is the right solution
<fabbione> the real problem is that i can't find a single reference to it in the entire source
<jbailey> fabbione: I don't know how to troubleshoot csh.
<fabbione> nah don't worry :) it was just to keep you informed :)
<fabbione> this build system is worst than imake :)
<jbailey> I apprecaite it.  I was curious so I looked.
<jbailey> I enjoy fiddling with build systems.  I suspect this fix will be more than fiddling. =)
<fabbione> AHHHHHH
<fabbione>    if ("$JAVA_ARCH" != "") then
<fabbione>       set CORE_INCLUDE = "$CORE_INCLUDE -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH}"
<fabbione>    endif
<fabbione> this one!
<fabbione> jbailey: for some incredible reasons that entry becomes /usr/include/linux
<fabbione> but it's not meant to
<fabbione> (btw csh accepts -x as bash
<fabbione> )
* jbailey blinks.
<jbailey> It's not something that holds over in $CORE_INCLUDE from before?
<fabbione> i mean.. really....
<jbailey> Mm, no, I guess I can see it.
<fabbione> basically CORE_INCLUDE is expanede with -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH}
<jbailey> JAvA_HOME might be blank
<fabbione> when JAVA_HOME is not empty
<fabbione> but it is empty
<jbailey> JAVA_INCL for gcj might be /usr/include
<doko> fabbione: use java-gcj-compat and set JAVA_HOME=/usr/lib/jvm/gcj-java ...
<fabbione> if ( $JAVA > 0 || $BUILDJAVADOC == 1 || $JNI == 1 ) then
<fabbione>    # Make sure we can find JAVA_HOME
<fabbione>    if ( ${?JAVA_HOME} == 0 ) then
<fabbione>       echo "Please set JAVA_HOME"
<fabbione>       exit 1
<fabbione>    endif
<fabbione> endif
<fabbione> so this check fails
<fabbione> there we go :)
<fabbione> sick sick sick
<fabbione> cat build-progress 
<fabbione> glibc_2.3.5-1ubuntu4: successful
<fabbione> yay!
<doko> jbailey, time for the next glibc upload, i386 biarch/multiarch ;)
<fabbione> doko: die!
<fabbione> first sparc needs to change to NTPL
<fabbione> or whatever is called :)
<fabbione> doko: sparc just started building gcc-3.4
<fabbione> do i need to stop it, or can i let it build?
<doko> fabbione: do you need it?
<fabbione> stop in the meaning of = do you plan an upload within the next 12 hours?
<doko> no, why do you need the latest build on sparc?
<fabbione> doko: i need to get the build fixes from the proper sources...
<fabbione> the previous one was manually munged to make it build :)
<doko> ahh, ok
<fabbione> and it's not nice if sources and binaries do not match
<fabbione> it would also be very nice if we can get the new gcc-4.0 in, to fix the /usr/lib64 /usr/lib thingy...
<jbailey> doko: amd64/i386 multiarch would make more sense to do next.  It's an underused arch if we break it, and it gets you OO.o2 stuff you need.
<jbailey> doko: I'd like to get a few EarlyUserspace things done first, though.
<jbailey> fabbione: Sparcs conversion to nptl is dep's on binutils-2.16
<jbailey> doko: BTW, what do you think of the ia64 workaround bit that I mentioned?  That the testsuite failure goes away if I do a build cycle of binutils, glibc against new binutils and then new binutils again.
<fabbione> jbailey: ok :)
<infinity> jbailey : That's not surprising at all.
<infinity> jbailey : Makes me wonder if maybe our scorched earth bootstrapping shouldn't involve a sick round-robin of gcc/binutils/glibc builds for a few months before we build anything else. :)
<fabbione> infinity: eheheh
<fabbione> and pleople still believes i am sick...
<fabbione> somebody is beating me
<fabbione> well nice...
<fabbione> now the gridengine is built :)
<fabbione> tomorrow we will learn how a computing cluster grid will work :)
<fabbione> thanks a lot guys :)
<fabbione> i am off for dinner
<jbailey> infinity: I beleive that it does - lamont doesn't usually install our binaries in the chroots, but instead rebuilds them with the binaries we provided and installs those in the chroots.
<jbailey> infinity: But the concern I have is inheriting bugs.
<jbailey> infinity: So some interaction that causes ABI instability of some sort that gets inherited down.
<jbailey> infinity: (Given that the testsuite failure is something in static linking.  I don't have the error in front of me...)
<infinity> Oh, fun.
<jbailey> I think it's probably not in this case.  I suspect it's a TLS fix on a static library that is being made correct.
<doko> I've merged these patches to 2.16.  2.16.1 is almost ready now; I'm hoping
<doko> to release it on Friday.
<doko> -- 
<doko> Daniel Jacobowitz
<doko> jbailey: ^^^
<doko> so maybe we can wait until the next weekend?
<\sh> I need some advise
<\sh> ../Ark/ArkObject.h:100: error: 'Cache' has not been declared
<\sh> ../Ark/ArkObject.h:108: error: 'Cache' has not been declared
<jbailey> \sh: Context? =)
<jbailey> doko: That's fine.  I'm in no rush for it.
* jbailey checks ToolchainTransition
<\sh> jbailey: virtual bool Load (Cache *cache, const String &name);
<\sh> the second line is the same thing..
<\sh> Ark::Cache is included
<\sh> its all in a namespace named Ark
<jbailey> \sh: Right.  So is there a declaration of Cache before that in that namespace?
<jbailey> \sh: g++ -E -dD is your friend here...
<\sh> nope
<jbailey> Hmm, I wonder if there's a post-processing phase for g++ where you can see all the calls with namespaces expanded.
<jbailey> doko: Neat.  Looks like after the binutils update that we might be ready to ask for the rebuild of the world to verify that everything's transitionned.
<doko> lamont: please could you remove the dep-wait from ftgl?
<doko> infinity: ^^^
<lamont> doko: done
<doko> jbailey: I'd like to wait with the rebuild for gcc 4.0.1, announced for mid June
<doko> lamont: thanks
<jbailey> doko: That works, I saw Mark's email this morning about it.
#ubuntu-toolchain 2005-06-07
<fabbione> morning
* fabbione sighs
<fabbione> gcc-3.4 did FTBFS :/
<fabbione> guys, did we start building C++ apps in main+
<fabbione> ?
<fabbione> or are they still banned?
<infinity> Any particular ones on your mind?
<fabbione> i am not 100% sure yet, but i think sparc needs to build one or two of them to be able to build C++ libs :/
<fabbione> i am trying to unroll the loop right now
<infinity> The ban list is still massively huge.  I'm going to assume it's main+universe, but I could check random apps.
<fabbione> infinity: that would be great...
<fabbione> i just need a few minutes to understand where i need to start :)
<fabbione> i think the problem is freeglut3...
<fabbione> i hate that there is no easy way to figure it out :)
<infinity> Well, freeglut isn't in the ban list.
<fabbione> but basically the problem starts with pike7.6 build-dep not being installable
<infinity> So, if it's C++, and it's in main, I'd gues main's been unbanned.
<infinity> However, freeglut build-deps on a bunch of xorg stuff, which may well be hideously broken right now.
<fabbione> exactly
<fabbione> that's the overall problem
<fabbione> because as a result i see:
<fabbione> The following packages have unmet dependencies:
<fabbione>   libglu-dev-xorg: Depends: libglu1-xorg (= 6.8.2-20) but it is not going to be installed
<fabbione> E: Broken packages
<fabbione> and that seems to be somekind of conflicts between freeglu3 and xorg
<infinity> Is this on your sparc machine?
<fabbione> yes
<fabbione> but iirc daniels had the same problem on i386
<fabbione> let me check on a chroot
<infinity> What do you see if you turn on apt's problemresolver and try to manually install libglu-dev-xorg?
<fabbione> hmm crap.. it works on i386
<fabbione> infinity: how do i enable the problem solver?
<fabbione> if i install only libglu-dev-xorg it works..
<fabbione> it's when i try to add some of the other build deps that it goes foobar
<fabbione> i think one of the package has been built at different time from the other buildds
<fabbione> so it's carrying wrong dependencies
<infinity> You may have to dig down to that one and rebuild it then.
<fabbione> infinity: yeah.. that's what i was trying to do :)
<infinity> apt-get -o Debug::pkgProblemResolver="true" <action>
<infinity> To turn on the debugger.
<fabbione> meh!
<fabbione> that output is sick
<infinity> You get used to reading it after a while.  It's kinda like talkig to Culus.
<\sh> what output? morning btw
<fabbione> http://people.ubuntu.com/~fabbione/sparc-resolver
<fabbione> infinity: can you help me understand it?
<\sh> uhh...sometimes i should avoid reading documentation
<infinity> fabbione : Is libglu1 installed in the chroot?
<\sh> any c++ cracks online? 
<\sh> :)
<infinity> fabbione : Otherwise, I'm not sure what the problem is, since nothing appears to be depending on it from this output.  But libglu1 is definitely the problem.  Something wants to keep it, but you need the new libglu1-xorg
<fabbione> infinity: nothing is installed in the chroot
<fabbione> it's a buildd chroot
<infinity> fabbione : Oh, unless your libsdl1.2-dev is out of date and depend on the old libglu-dev package.
<fabbione> checking...
<infinity> fabbione : Or, I'm half asleep.  Let me read more.
<infinity> Meh.  Very twisty-turny, your dependencies are.
<fabbione> libsdl1.2 has been built   State-Change        : 2005 May 25 18:18:39
<fabbione> and it's the latest one accoring to what i can see
<\sh> hmmmm
<fabbione> \sh: this is sparc.. nothing is broken
<fabbione> not in the main archive at least
<\sh> fabbione: no...i'm reading the changes.html of gcc3.4
<\sh> I'm stucked with arkrpg cause of c++ build errors
<infinity> Package x11proto-gl-dev has broken dep on xlibmesa-glu-dev
<infinity>   Considering xlibmesa-glu-dev 0 as a solution to x11proto-gl-dev 3
<infinity>   Added xlibmesa-glu-dev to the remove list
<infinity>   Fixing x11proto-gl-dev via keep of xlibmesa-glu-dev
<infinity> (note that xlibmesa-glu-dev and libglu1-dev-xorg conflict)
<fabbione> so X is fucked
<fabbione> but that's nothing new :)
<infinity> Oh, wait.  No, in the main archive that's okay...
<infinity> What version of xorg do you have built?
<infinity> You need something over -20 for this to all work out, it looks like.
<\sh> but now I know why classic music can sometimes help you to understand things better
<fabbione> i have -20
<fabbione> there is nothing newer than that
<infinity> Erm, I meant "-20 or over", so you should be okay there.
<infinity> <grumble>
<infinity> Stupid X.  Who needs GUIs anyway?
<fabbione> i am afraid something has been built with xorg older than -20
<infinity> Almost certainly.  If the problemresolver output doesn't make enough sense, it's time to pick each package out of the problemresolver list and check its deps with apt-cache.
<infinity> Or install each one by hand until the problem leaps out at you.
<infinity> I need to write a good parser for that output.  The longer it gets, the harder it is to decipher. :/
<fabbione> now i am trying to install all the build-deps manually
<fabbione> and keep only the minimum that fails to install
<fabbione> and see if that helps the resolver
<infinity> The first time something tries to install xlibmesa-anything, I think you've found your issue.
<infinity> (You're positive the chroot is clean though, right?)
<fabbione> infinity: yes
<\sh> infinity: for the buildlogs? ogra made a nice attempt..he takes fabbiones .bz2 logfiles and parse it via python :)
<fabbione> \sh: my logs???
<fabbione> i don't even publish logs...
<\sh> lamonts
<\sh> sorry
<fabbione> so xlibmesa-glu is the one that should never appear....
<infinity> Definitely not.
<fabbione> if so there are 2 apps that are guily of trying to pull it in
<\sh> strike... i fixed my build errors with g++4
<\sh> finally i managed it...
<fabbione> infinity: can you reload the log?
<fabbione> if i am not mistaken i can see only freeglut3 and gtkglarea5 
<infinity> Wow, you made it uglier.
<infinity> Congrats.
<fabbione> uh why?
<fabbione> it's shorter :)
<infinity> Yeah, but it has more occurances of the string "gtk", so it's bad.
<fabbione> ahahaha
<infinity> gtkglarea definitely seems to be a problem, at any rate. :)
<fabbione> i could just try to rebuild these packages manually and see if that helps
<fabbione> given that they are buildable
<fabbione> 80 -rw-r--r--  1 sparcbuildd sparcbuildd 75652 May 25 02:10 freeglut_2.2.0-8ubuntu3_20050525-0156
<fabbione> 12268 -rw-r--r--  1 sparcbuildd sparcbuildd 12545643 May 26 21:55 xorg_6.8.2-20_20050526-1446
<fabbione> DA DA!
<infinity> Built them backwards?
<fabbione> infinity: that's the order in which they come in....
<fabbione> at least on the sparc buildd :/
<fabbione> so yeah they have been built in the wrong order
<fabbione> lamont: did you already build freeglut on hppa?
<infinity> He's asleep.
<fabbione> lamont: and if so.. with what version of xorg?
<fabbione> oh ok
<fabbione> yeah he did
<fabbione> so ok.. the first one is freeglut3.. let's check the other one
<fabbione> freeglut (2.2.0-8ubuntu4) breezy; urgency=low
<fabbione>   * Remove | libglu-dev otherwise if libglu-dev-xorg (>= 6.8.2-20) something
<fabbione>     bad is installed.
<fabbione>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Tue, 31 May 2005 07:06:37 +0200
<fabbione> no wonder it did build :/
<fabbione> there was a nice | libglu-dev that is provided by another 39439483 pkgs
<\sh> laters guys
<fabbione> 36 -rw-r--r--  1 sparcbuildd sparcbuildd 33080 May 25 09:09 gtkglarea_1.2.3-2ubuntu1_20050525-0903
<fabbione> and same with this one...
<fabbione> ehheh
<fabbione> infinity: there.. everything should be fixed now
<fabbione> and while we wait for the sources to come back.. 
<fabbione> let's kick back gcc-3.4
<\sh> re
<elmo> fabbione: done (libxml2-dev, davis breezy-ppc64)
<fabbione> elmo: thanks.. do i also have the kernel build-dep installed?
<elmo> fabbione: do now
<\sh> phew
<fabbione> elmo: thanks.. it's nothing urgent
<\sh> arkrpg fixed
<fabbione> elmo: when you have a second i need to know a few internal bits of the autosync from debian stuff because i need to upload a package and i am afraid that it can break
<fabbione> elmo: the scenario is:
<fabbione> debian has package foo coming from source foo
<fabbione> and right now we are syncing it
<fabbione> i am going to upload package bar that will create a binary called foo that is a newer version of foo
<fabbione> but we don't want to get foo from debian anymore
<fabbione> foo as source
<infinity> Then you need to blacklist foo.
<infinity> Most probably.
<elmo> infinity's right, but it's not urgent, you can't really break it any way that upsets me
<fabbione> elmo: i have no rush at all
<fabbione> i am still fucking with the package
<fabbione> and fucking is on purpose
<fabbione> i never seen such a pile of shit inside a single build system
<fabbione> not even X is that complex and fragile
<infinity> elmo : Can I get a sync of mysql-dfsg and mysql-dfsg-4.1, since we're talking syncs? :)
<elmo> [BROKEN]  mysql-dfsg_4.0.24-5build1
<elmo> [BLACKLISTED]  mysql-dfsg-4.1_4.1.11-3
<elmo> BROKEN == we have a different orig.tar.gz to Debian somehow, I suspect
<infinity> Oh, great.
* infinity blames doko.
<elmo> DEAR ANACRON, WHEN I GET UP IS NOT A GOOD TIME FOR CRON.DAILY.  KTHXBYE
<fabbione> rotfl
<infinity> elmo : Hrm.  Our orig.tar.gz matches, and our -5build1 is indentical to their -5, save for a new changelog entry.  (syncing should be updating to Debian's -10, however, which still has the identical .orig)
<elmo> infinity: hmm, you're right, it's been UNBROKEN by someone, synced
<infinity> Danke.
<\sh> elmo: when r u moving python-qt3 to universe? :)
<elmo> \sh: not until the kubuntu guys ack it as unneeded and/or I find out why it's up for demotion in the first place
<\sh> hmm...lemme check it
<infinity> elmo : Oh, can you sync libmysqlclient-lgpl too, and overwrite our changes?
<elmo> done
<infinity> \o/
<infinity> That's the last time I hope to type the string 'mysql' for a couple of days at least.
<doko> fabbione: all C++ apps are rebuilt in main
<fabbione> doko: ok.. i think i need to finish to build the libs first
<fabbione> given doko^Wsomebody fucked a couple of build-deps :)
<doko> yes, and add ftgl to the lib list
<doko> ?
<fabbione> doko: gtkglarea and freeglut :)
<doko> so what's correct?
<fabbione> if you want version dependencies than it's better you also remove the | libglu-dev that is provided by another 2032093829783297 pkgs :)
<doko> ok, fine
<fabbione> doko: just check the changes ;)
<fabbione> i already fixed them
<\sh> The following packages have unmet dependencies:
<\sh>   xlibmesa-gl-dev: Depends: x11proto-gl-dev but it is not going to be installed
<\sh> like this
<\sh> fabbione: u had this issue before this morning, right? with x11proto-gl-dev
<fabbione> nope
<fabbione> it was a different one
<\sh> k...just fixed it
<fabbione> hmmmm
<fabbione> go figure... gcc-3.4 is building now
<fabbione> this is weird
<fabbione> the build system is too weak
<doko> ?
<fabbione> doko: the last gcc-3.4 that was uploaded.. it was FTBFS yesterday for not finding stage2/xgcc or something similar
<fabbione> kick back and it builds
<fabbione> so there is something that is weak
<doko> fabbione: well, yes, but that is only seen on buildd's. never saw this for local builds
<fabbione> doko: *cough*fix it*cough*
<fabbione> ;)
<fabbione> doko: you should definetely install sbuildd
<fabbione> and test with it
<doko> fabbione, would you mind a gcc-4.0 upload introducing powerpc biarch?
<fabbione> doko: not at all, if it fixes the /usr/lib64 -> /lib64 thing
<doko> fine, it does as well
<fabbione> plus if i am told in advance i can still avoid that it will be taken for build
<infinity> <fabbione> doko: *cough*fix it*cough*
<infinity> <fabbione> ;)
<infinity> <fabbione> doko: you should definetely install sbuildd
<infinity> <fabbione> and test with it
<infinity> <doko> fabbione, would you mind a gcc-4.0 upload introducing powerpc biarch?
<infinity> Gah.
<infinity> Bad mouse.  BAD.
<fabbione> infinity: stop playing with it :)
<doko> just curious where he wanted to paste it ... ;-P
<infinity> Didn't want to paste that anywhere. :)
<infinity> I just shouldn't drink and IRC.
<doko> hopefully your keyboard is beerproof ;)
<elmo> daniels: around?
<infinity> He appears to be decidedly not around.
<infinity> If it's urgent, I can call him.  Otherwise, I'd assume he'll be on tonightish.
<fabbione> elmo: can you ping me back when you a few minutes free?
<fabbione> (nothing urgent)
<fabbione> (and it's NOT sparc related :P)
<jbailey> fabbione: But you got this GREAT little m32r on ebay yesterday?
* jbailey hides.
<fabbione> ehhe
<fabbione> you wish :)
<fabbione> i never bought a single thing from ebay
<fabbione> dunno why but i don't trust it
<jbailey> Almost all of the Cisco equipment at my last job came from Ebay.
<jbailey> Rather than buying Smartnet, we simply bought two of every device.
<fabbione> eheh
<jbailey> Aside from it still being half the price, it also was faster - smartnet doesn't promise faster than 4 hours.
<jbailey> Forever in the financial industry.
<fabbione> uh wow
<fabbione> i never needed something faster than 4 hours
<jbailey> They got squirmy about about the 6 minute mark.
<jbailey> (during the day)
<fabbione> wow
<jbailey> In the evening they really wanted to be up in about 30 minutes, but even then the downtown would often take them hours to get all the mirrors sync'd again.
<jbailey> fabbione: Part of the problem is that we ran the CA for the entire mutual fund industry, as well as handling all the cross-company transactions.  When we went down the entire mutual fund industry essentially stopped.
<jbailey> And it was mostly done with used Cisco gear from Ebay. =)
<fabbione> hehe
<doko> jbailey: what's our time plan for java-gcj-compat entering main?
<jbailey> doko: I don't know how these things all work.  I guess it could go in anytime now that we have g[ci] -4 as the default.
<doko> jbailey: elmo doesn't want to do that currently, looking at the dependency chain ...
<jbailey> I've so far just ignored the whole is-it-in-main-or-universe bits...  What do you recommend?
<jbailey> doko: Eventually all of eclipse and its build-deps will wind up in main.
<jbailey> doko: So I'm not sure that there's anything that can be done to reduce the dependancy chain.
<doko> it sucks in jikes and sablevm as well at the moment ...
<jbailey> Ugh.
<jbailey> I can chew through and fix that.  Let's say 2 weeks from now?
<jbailey> That should give me time to get EarlyUserspace a bit further than it is now and still get a good chunk of it done and see where it needs to go.
<doko> ok, no problem, but then we'll have to move OOo2 to universe for that time, currently uninstallable and unbuildable
<jbailey> Probably easiest.
<Kamion> does OOo still work? do you have a plan to keep the desktop working (it currently depends on OOo2)?
<doko> OOo does work, it's already rebuilt
<doko> Kamion: the current snapshot is still the old one, so we really don't want it in main, the current snapshot doesn't build yet, because gcc-4.0 got a bit stricter again
<fabbione> elmo: is there any reason why pqm is running on concordia?
<fabbione> or did we change porting box?
<elmo> fabbione: baz commits auto-build on our 3 main architectures
<elmo> as the 'pqm' user
<fabbione> ahhh ok
<chmj> elmo: can you please install libbluetooth1-dev in concordia's breezy chroot
<daniels> elmo: pong
<daniels> spent most of today unable to remember my password to unlock my laptop.  \o/
<jbailey> *g*
<doko> daniels: so the cocktails were quet good?
<daniels> doko: s/cocktails/painkillers/, but yes
<doko> ah, drug cocktails ;-)
<elmo> daniels: nothings using the new X stuff yet - is it actually targetted for main?
<elmo> chmj: done
<daniels> elmo: all of it; xorg b-ds on it
<daniels> elmo: (and various pieces of gnome, etc, b-d on libice-dev and depend on libice6, ditto libsm{-dev,6})
<chmj> hmm, any reason why avifile is not built on ppc and ai64 ?
<jbailey> daniels: Is there some sort of useful diagnostic I can do to figure out why xorg suddenly will eat 98% of my CPU and do so for 4 or 5 minutes at a time?
<daniels> jbailey: if you have another machine, and you're running xserver-xorg-dbg rather than -xorg, you could break on WaitForSomething and step through to figure out what it's doing with its time
<jbailey> 'kay.  It happens a couple times a day so I'll try to wire that up.
<elmo> daniels: sorry, xorg in the archive, or it will at some stage?
<elmo> I'm just trying to work out why anastacia is keen to demote them; if it's a temporary/pending thing, that's fine, I just need to know before I start trying to work out why germinate/anastacia's confused
<Kamion> xorg probably still delivers libice*
<elmo> it's not ice, it's the new x-proto stuf and libsm
<elmo> (panoramix, render, record, rsrc and screensavere)
<daniels> elmo: will be
<elmo> ok
<daniels> figured there wasn't really much point in uploading them 'till I found out if all its new b-ds were ftbfs or not
<daniels> WHOOHOO!!
<daniels> fuck I'm shit
<chmj> infinity, ping 
<doko> chmj: why did you re-upload avifile?
<chmj> to rebuild 
<chmj> that doesn't seem to have worked ;/
<doko> chmj: you didn't try ...
<chmj> hmmm ?
<doko> infinity, lamont: please retry the build for avifile on powerpc and ia64
<lamont> daniels: my life would be easier if -16 had actually not been FTBFS
* lamont creates -16hppa1 so that he can then build -20, grumbling
<daniels> sorry, I know it's shit
<daniels> nothing I can do about it
<daniels> and I figure I might as well spread the pain as evenly as I possibly can
<lamont> daniels: yeah, understood.
<daniels> which I've been doing a sterling job of by shitting off porters and making it FTBFS on all the main arches anyway
<doko> daniels: it's not a problem, if you tidy up afterwards ;)
<lamont> daniels: seriously, if you would upload something that wasn't ftbfs, before you made xorg's build-deps uninstallable, that'd be a big help... :-)
<lamont> daniels: what's the rules target to unpack and patch again?
<daniels> lamont: setup
<lamont>  /bin/bash: up-scripts: command not found
<lamont> feh
<daniels> lamont: i do my best to not have things ftbfs
<daniels> lamont: that's not fatal
<lamont> -16 had radeon ftbfs issues
<daniels> lamont: unfortunately, not having things ftbfs is difficult when you have people demanding you upload what you have, yesterday
<lamont> hehe
<daniels> lamont: yeah, that didn't trigger on the main architectures ... go figure
<lamont> yeah... did -17 require -16 to build, or when did that build-dep come into play?
<daniels> the only change in -17 was fixing that ftbfs, iirc
<daniels> or something, I can't really remember
<daniels> most of them were done at like 3am after staring at builds going past for long enough to make my eyes bleed
<lamont> ok
<lamont> I'll just create a -16hppa1 then
<lamont> O'
<lamont> I'm going to go out on a limb, and guess that libsigc++-1.2-dev should Depend: libsigc++-1.2-5c102, not libsigc++-1.2-5
<lamont> no, other way around
<Kamion> bad shlibs?
<lamont> bad build order
<lamont> hrm.. actually it appears to be morgifiying things when I shouldn't (in my archive)
<lamont> s/shouldn't/didn't really want to even though I told it to/
<doko> lamont: libsigc++-1.2-5 is correct
<lamont> yeah, I figured that out.
<lamont> closer root cause was that the package was recently? demoted to universe
<doko> Kamion, jbailey: please could you bring up the topic of OOo2's build dep's in universe and OOo2 itself in main up in today's TechBoard meeting? I'm not at home before 22.00 UTC
<jbailey> doko: Just basically whether it could be bumped back to Universe for a couple weeks while we sort it out?
<doko> jbailey: yes
* jbailey adds to the agenda.
<lamont> the buildd's would appreciate that.
<fabbione> hey guys
<doko> we don't have the time to work on java now, and a working OOo2 in breezy would be just good
<jbailey> doko: Added to the agenda.
<\sh> hmm...the maintainer candidates on tbagenda can be removed, 
<Riddell> lamont: python-qt3 couldn't build because of a depend in universe, it's now been moved to universe, will the buildd pick up the change next time it tries to build?
<lamont> Riddell: should
<Riddell> \sh: so hopefully the buildds will get round to it soon and it'll all work
<Kamion> hmm, I uploaded libqt-perl a while ago, but no build yet
<doko> buildd darkness ...
* lamont gets his flood light
* lamont points Kamion at doko (cxxapps.txt)
<lamont> doko: did we get that list of cxxapps that we can release yet?
<doko> lamont: no, just removed libqt-perl
<doko> well, looks like I have to walk through this list and sort out the apps, which can be built ... the MOTU's aren't that fast ...
<lamont> libqt-perl removed.
<lamont> note that changing that list involves stopping and starting the buildd, not just a SIGHUP
<lamont> doko: if possible, would be good to look on ports.u.c and see which ones can be removed for ia64/sparc/hppa at the same time
<Kamion> quality
<lamont> or at least make a list of depends
<lamont> Kamion: heh
<doko> Kamion: quality?
<Kamion> doko: "high-quality", sarcasm
<doko> we should have such kind of dependency checker in soyus?
<lamont> soyuz will know that a package's build-deps are not met, and not build it...  BUT IF YOU DON"T UPDATE THE BUILD-DEPS, HOW CAN IT POSSIBLY KNOW???
<Kamion> not that lamont is bitter or anything
<lamont> :-)
<doko> lamont: ia64 should be same as the release architectures. I don't know about sparc and hppa, they are occupied with toolchain and xorg builds all the time ...
<lamont> Kamion: at least one buildd of each arch has restared, should grab libqt-perl
<lamont> doko: yeah - it's more a question of how to know when the build-deps for cxxapp 'foo' are sane again, and it can be removed.
<Kamion> I mostly only care about i386 ;-)
<Kamion> (for the debconf arch: all build ...)
<lamont> Kamion: ah, yes
* lamont d-w's debconf on qt-perl
<lamont> Kamion: you gonna care about grub next?
<Kamion> why's grub building on ia64 in the first place?
<lamont> Automatic build of grub_0.95+cvs20040624-17ubuntu1 on vernadsky by sbuild/i386 1.170.5
<lamont> or is there a newer one?
<Kamion> oh, looking at the wrong version, sorry
<lamont> %grub: i386 hurd-i386 amd64                                           # i386 boot loader
<jbailey> lamont: Ugh.  Type type-handling add amd64 for i386-all? 
<Kamion> lamont: it's ok, I was looking at some ancient version by mistake
<jbailey> s/Type/Does/
<lamont> jbailey: what's type-handling?  we don't have that in main
<Kamion> can I make infinity fix grub? he touched it last.
<lamont> and yes, grub should be there for amd64
<lamont> Kamion: hehe.  no objections here
<jbailey> lamont: I think grub uses type-handling in Debian - did you really add hurd-i386 to the result in Ubuntu? =)
<jbailey> (when removing t-h)
<lamont> jbailey: that's looking at Packages-arch-specific
<Kamion> Package: grub
<Kamion> Architecture: darwin-i386 freebsd-i386 hurd-i386 kfreebsd-i386 knetbsd-i386 i386 netbsd-i386 openbsd-i386 amd64
<Kamion> looks like we just kept the generated debian/controol
<Kamion> control
<Kamion> lamont: grub has significant DEB_*_GNU_* fun; fixing
* #ubuntu-toolchain  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
(lamont/#ubuntu-toolchain) jbailey: I'm sure that there is... I just need to figure out how exactly... there are some code changes to be done before it would be trivial
<lamont> doko: I'd be interested in knowing how to tell if a cxxapp can be released for building, btw.
<lamont> that is, what your check is.
<\sh> damn
<\sh> what about c libs with unresolved deps?
#ubuntu-toolchain 2005-06-08
<Kamion> lamont: check that all its build-dependent -devs have corresponding runtimes built against libstdc++6?
<Kamion> (or something ...)
<daniels> lamont: if you're around and could kick libsm for me, that'd be good (for a rebuild)
<daniels> infinity: or you
<lamont> daniels: libsm is d-w libice6
<lamont> (>= whatever the first busted libice upload was...)
<lamont> or does it need to actually be kicked?
<lamont> daniels: and build/installed. :-)
<daniels> well, I assume libice is in the archive now
<fabbione> morning
<fabbione> lamont: any luck with X
<fabbione> ?
<lamont> doh. 
<lamont> -20.3 built fine.
<lamont> anything before I sleep?
<infinity> Kamion : What did I break with grub?
<daniels> infinity: the world!
<infinity> Yay!
<infinity> (I don't see any "new grub broke the world" bug reports..)
<infinity> Oh, dpkg-architecture fixes.  Bleh.
<Kamion> infinity: yeah, it wasn't anything you changed
<\sh> hmm...what about c-libs which have to be recompiled?
<lamont> infinity: but it's still your fault. :0)
<infinity> lamont : Thpt.
<jbailey>  ___/:
<jbailey>  \o.O:
<jbailey> =(___)=
<jbailey>    U
* daniels stares at jbailey.
<jbailey> daniels: If Adam's going to make bill the cat noises...
<daniels> who's bill the cat?
<chmj> do you have to ask ?
<daniels> oh, that thing
<jbailey> daniels: http://alcyone.cc.uch.gr/~kosmas/ACK.html
<daniels> jbailey: right
<jbailey> I can't find one where he's going 'Thpppt', though.
<daniels> jbailey: i see you were also feeling lucky
<jbailey> =)
* infinity wonders if he should admit that he used to have that particular piece of ASCII art on a macro in Telemate back when he was a BBS whore...
<infinity> Probably best not to admit such things, so I won't.
<\sh> i think libqt3-mt needs some new love ;) at least a rebuild
<infinity> What's wrong with it?
<\sh>   libqt3-mt-dev: Depends: libglu-dev-xorg but it is not going to be installed or
<\sh>                           libglu1-mesa-dev but it is not going to be installed or
<\sh>                           libglu-dev
<jbailey> infinity: I'd expect you would have.  Although I think I learned it when going on ddials.
<lamont> <daniels> who's bill the cat?
<lamont> someone quote-file that
<jbailey> lamont: I was too busy feeling old, sorry.
<elmo> lamont: has yellow been ok?
<daniels> \sh: it sounds like you still have something depending on xlibmesa-glu
<daniels> \sh: since libglu--dev-xorg is what you want
<\sh> daniels: well...libqt3-mt is actual in breezy :) and the universe libs with wrong build-deps I can upload, but not libqt3-mt. this qt thing stopped working after the last Xorg update
<\sh> and finally nagra screwed up
<daniels> \sh: no, what I'm saying is that you need to work out why libglu-dev-xorg won't be installed
<daniels> likely it's something that still depends on xlibmesa-glu-dev
<doko> yes, for some reason xlibmesa-glu-dev is preferred over libglu-dev-xorg, that's a likely thing, if you have universe apps installed, which still depend on the old package
<\sh> xlibmesa-gl-dev (16 (null)) libgl-dev (0 (null)) libglu-dev-xorg (16 (null)) libglu1-mesa-dev (16 (null)) libglu-dev
<\sh> these r the deps of libqt3-mt
<daniels> \sh: 15:13 < daniels> \sh: no, what I'm saying is that you need to work out why libglu-dev-xorg won't be installed
<daniels> xlibmesa-glu-dev: old package
<daniels> libglu-dev-xorg: new package
<daniels> apt not wanting to install new package: bad
#ubuntu-toolchain 2005-06-09
<fabbione> morning
<lamont> elmo: yellow has been behaving, yes
<elmo> doko_: ?
<fabbione> hey elmo
<doko_> morning
<doko_> elmo: hi
<elmo> doko: dude, why are we still blacklisting apps?
<doko> because I didn't do my homework yet to reduce the cxxapps list
<elmo> no, I mean, in general
<doko> not all libs in universe are already converted
<elmo> right, but the same question I asked the other day, applys - couldn't we not blacklist stuff and once we've done the transition determine what we need to recompile?
<elmo> AFAICS, the only thing we'll miss is stuff linking statically with C++, and I'm not sure missing that is worth the pain of managing the c++ apps list on the buildds
<doko> hmm, let me reduce the list today for one time, please. for another reason it's a bad time to push all the packages to the buildd's now: uninstallability of xbase-clients will break all kde builds
<elmo> the blacklist is a BIG BLOODY HAMMER, we shouldn't be using it to avoid random breakage
<doko> yes, and a clean reduction seems to be doable and easy
<elmo> I'm talking in general, I don't think the app blacklist is the right way to handle this
<elmo> I think we can assume that someone is uploading an app, it's their responsiblity to ensure that everything it's built against is transitioned
<elmo> I don't mind the sync blacklist, but the buildd blacklist is just PAIN
<elmo> and this concept is entirely not going to work for Debian, I can tell you that right now
<doko> I know, the right way are modified build deps, but we didn't want this at the start. I know that it doesn't work for Debian, but we didn't want to modify the 800 blocked packages. that was the price
<elmo> lamont: dude, why on earth didn't we use NFU?
<doko> NFU?
<elmo> not-for-us
<elmo> the wanna-build state
<elmo> rather than altering 18 config files on buildds
<doko> jbailey: have a 32bit libgcj working, but 21 test suite failures, 1 is a bug in the testcase, the others all signal related :(
<jbailey> doko: This is amd64?
<lamont> elmo: IIRC, NFU still gets a should-I-build message, which we told buildd to just answer 'ok'.
<lamont> OTOH, I could have dep-waited them on 'cxxlibs' or something
<lamont> and it's only 15 config files (across 6 architectures)
<lamont> and sed -i does a reasonable job.  At the same time, I was given to expect that we'd be adding/removing the list as a unit (haven't decided if I should reasonably have expected that or not...)
<lamont> having looked, NFU doesn't seem to get a should-build msg, but I seem to remember something annoying with email related to that state, etc.
<elmo> that's fails
<elmo> nfu is fairly permanent
<elmo> dep-wait would have worked too
<lamont> elmo: I'll burn some time today and switch the blacklist into a breezy NFU state
<lamont> or maybe a dep-wait on something bogus
<lamont> or better yet, if doko does his homework and tells me which version of which package each thing is actually blocked by, then I can use a real depwait....
<lamont> but right now, I need to get ready and go to work.
<infinity> NFU would have worked fantastically for this purpose.
<lamont> gcc-3.3 ICE in debian.  sigh.
<infinity> GCC never ICEs, you must be imagining things.
<doko> jbailey: yes, amd64
<jbailey> doko: 'kay.  So I need to get on with getting Tollef's multiarch stuff in and happy, I guess.
<jbailey> doko: He mentioned a baz patchset that he thinks needs to be applied.  I haven't looked at it yet.
<lamont__> doko: so are you going to work through the list of what each cxxapp should d-w on?
<infinity> lamont__ : If he does, I can implement it.
<doko> lamont__, yes, working on it now ...
<lamont__> infinity: it's just a slew of wanna-build --dep-wait commands, followed by dropping the massive sledge hammer that is @no_auto_build
<infinity> <nod>
<infinity> S'what I assumed.
<infinity> And I'm pretty darned fast at doing mass dep-waits. :)
<infinity> Someone used to send me complete lists of build-order for gnome uploads on m68k.
<lamont__> especially when they can be scripted... :-)
<infinity> Which was pretty handy.  I wish more maintainers were that nice.
<lamont__> infinity: of course, if the packages just had correctly versioned build-deps, then it doesn't really matter, modulo download speed
* lamont__ discovers that he needs to reconfigure the serial port on his laptop, so that the 3rd ide controller is usable
<infinity> Yeah, the gnome team moved from hand-massaging to tighter build-deps.
<infinity> Though the hand-massaging actually worked better anyway.
<infinity> (Well, if there was communication, obviously.. Otherwise, it all blew up horribly)
<lamont__> feh
<infinity> 3rd IDE controller on your laptop?... Dude, where would you even plug in a third IDE drive?
<lamont__> docking station
<infinity> That seems excessive to me.
<lamont__> ide1 at 0x170-0x177,0x376 on irq 15
<lamont__> ide2: I/O resource 0x3EE-0x3EE not free.
<lamont__> ide2: ports already in use, skipping probe
<infinity> Ahh.  Right.  I forgot people still had those.
<infinity> That's a werid place to put a serial port.
<lamont__> the current solution for a desktop for me is a laptop+docking station
<infinity> weird, too.
<lamont__> serial is 3f8-3fe, 3e8-3ee
<lamont__> hrm... maybe that's just the kernel being excessive...
<infinity> COM1/COm2 is 2f8-2fe/3f8-3fe, aren't they?
<lamont__> lspci only shows one IDE interface
<infinity> (Or reversed from that)
* lamont__ ponders the meaning of /proc/ide/ide0/mate
<infinity> Still, 3ee is very not normal to be used by... Anything.
<lamont__> 0170-0177 : ide1
<lamont__> 01f0-01f7 : ide0
<lamont__> 0376-0376 : ide1
<lamont__> 03e8-03ef : serial
<lamont__> 03f6-03f6 : ide0
<lamont__> 03f8-03ff : serial
<lamont__> but yeah.
<lamont__> and OT anyway
<infinity> Sure, it is. :)
<infinity> (If that's two ports, reconfigure the first one in the BIOS to 2f8-2fe where it belongs)
<infinity> And now I stop being OT.
<\sh> lamont__: u have the nc6000? it's not the serial, it's the irda port u should fix
<\sh> 3ee comes from this nasty irda chip..the chipset is in the kernel, but on the wrong sir/fir addr..i tried to patch it to work..but no success
<lamont__> \sh: ah, cool.
<\sh> lamont__: hp bugged
<\sh> lamont__: another thing, u mentioned the portreplicator...
<\sh> lamont__: don't use it, it will kill your laptop at some time...in our company we're using now those nc6000 with portreps...and 3 of them died using it...if it's not connected properly :(
<lamont__> \sh: when it kills the laptop, I'll make 'em get me a new one....
* lamont__ is using the multi-bay replicator
<lamont__> is pretty common in the lab here - doesn't seem to be a big issue for folks
<\sh> lamont__: yeah...this one i have, too..it killed my mainboard and cpu and ram at the same time...for the other 2 it was only the mainboard and cpu
<fabbione> re
<\sh> lamont__: sometimes the connectors are not fitting correctly and as we found out, it's a common failure of this hw
<fabbione> lamont__: did you already do the de-wait magic?
<infinity> fabbione : For the CXX stuff?
<fabbione> yeah
<infinity> Nope.
<infinity> doko's supposed to be making a list. :)
<doko> infinity: shhtt ...
<infinity> doko : You're missing an "i" in there somewhere.
<doko> nfnty: which one? ;-)
<infinity> Between the hh and tt, I'd say. :)
<infinity> (or, perhaps in place of one of each...)
<lamont__> infinity: if you want to handle the DC buildd's that'd be cool.  hppa/sparc still need me/fabbione though...
<infinity> lamont__ : Yup.  I can do the DCs and provide a script for the others, if you guys feel lazy.
<doko> infinity, lamont__: are you allowed to build a package without one build dependency?
<fabbione> infinity: yes :)
<fabbione> i am lazy to death
<infinity> doko : Define "allowed".  I could build it for bootstrap purposes, but not upload it.  It'd have to be rebuilt for uploading.
<doko> infinity: trying to find a way to build zlib without updating ia32-libs two times.
<infinity> doko : Just waste the CPU and bandwidth and do it twice?
<lamont__> infinity: laziness is next to godliness
<lamont__> doko: dpkg-buildpackage fails if debian/control lists a build-dep that isn't resolved.
<doko> hmm, ok
<lamont__> why would building zlib requre building ia32-libs twice?
<doko> you currently cannot build it, because of a broken dependency (missing lib32z1), but you need it for the 32bit libc
<doko> 1) upload old ia32-libs, 2) build zlib, 3) redo the ia32-libs change
<infinity> So just do it?... It would have been done in the time you spent talking about it.
<doko> ahh, yes, that's not m68k speed
<infinity> doko : Also, I give up on your java stuff. :)
<infinity> doko : E: Package libant1.6-java has no installation candidate
<infinity> (From ecj-bootstrap)
<doko> ?
<infinity> Oh, feh.  ecj-bootstrap went to main.  Was it supposed to be in universe?
<infinity> (I assume that libant is in universe)
<doko> it is in universe ...
<infinity> ecj-bootstrap appears to be in main.  Did someone re-seed it?
<doko> we should really have the java stuff still in main ... that's development work.
<infinity> At any rate, until ecj-bootstrap gets seeded back to universe, or libant moves to main, this build will go nowhere.
<infinity> So, I suggest you get that fixed. :)
<doko> java-gcj-compat was in main, AFAIK, because OOo2 needed it
* infinity decides to go back to bed in an effort to get back on his own timezone.
<infinity> doko : If you work out the CXX transition build-dep/dep-wait tree, can you mail it to me, and I'll do the DC buildds when I wake up (in 5 or 6 hours) and forward the script off to lamont and fabbione for the private buildds.
<infinity> doko : If you don't get around to it, I'll just bug you about it again tomorrow. :)
<doko> infinity: let's see ;-)
<doko> lamont__, infinity: are the buildd's running? zlib, ia32-libs
<fabbione> lamont__: you around?
<fabbione> jbailey; ?
<lamont__> fabbione: yeah
<fabbione> lamont__: how are you hadling xbse-client fuckups on the buildd?=
<lamont__> clarify
<fabbione> i get some FTBFS because xbase-clientes 6.8.2-21 is not installable
<fabbione> or better
<fabbione> it fails to install
<lamont__> ah...  generally speaking, I've just been giving back everything that didn't build due to build-deps a couple times, then bitching about it..... (truth be told)
<lamont__> but in the ideal world, one would determine why it wasn't installable, and then dep-wait on the right thing
<fabbione> ok about dep-wait..
<fabbione> i do the same too
<fabbione> but right now kde* can't build because xbase-client doesn't install
<fabbione> and it's not due to dependencies
<fabbione> but because it fails to unpack or something
<lamont__> gack
<jbailey> fabbione: Hey!
<jbailey> fabbione: Oh, you replyied to my ping earlier too, hmm.  Lemme dig that up.
<fabbione> jbailey: i saw you did ping me before...
<fabbione> yeah i have only a few minutes...
<fabbione> and i need to go away
<fabbione> i just passed to give a huge kickback on sparc
<jbailey> lustre patches...
<jbailey> Apparently their goal is to get everything in kernel.
<jbailey> So the person I was talking with thinks that they might be willing to provide recent versions / security fixes and such.
<fabbione> jbailey: ok.. we need to go in details for that.. can we do it when i wake up in few hours or tomorrow that my wife is away?
<jbailey> Yup.  Tuesdays and Thursdays are support days for me, anyway.  I've been making about avoiding hacking on them and am trying to be better about it. =)
<fabbione> ehhehe ok :)
<jbailey> g'n =)
<fabbione> for me tuesday/thursday are userland days :)
<fabbione> wed is a mis ;)
<fabbione> monday/friday kernel
<jbailey> Yup, Monday is my mix day.
<jbailey> Catch up from the weekend and such.
<fabbione> ehhe
<fabbione> i am off than
<jbailey> Thu/Fri hacking days.
<jbailey> See you!
<fabbione> good night folks
<fabbione> cya in few hours
<doko> lamont, lamont__, infinity: new frozen app list (2nd column): chinstrap:~doko/frozenapps.txt
#ubuntu-toolchain 2005-06-10
<infinity> doko : Hrm. That list doesn't really give me a terribly good indication of what to dep-wait on.
<fabbione> morning
<fabbione> jbailey: ping?
<fabbione> infinity: did you get the script done?
<infinity> fabbione : Have you looked at doko's frozenapps.txt?... It's not particularly evident what one should be dep-waiting on.
<infinity> (I suppose I could dep-wait on package renames as I hope/expect them to be, but that's kinda icky)
<fabbione> infinity: no i didn't
<fabbione> and there is no way to track what pkg needs what
<fabbione> so basically i have sparc stalling
<fabbione> and i think i did build all the libs
<fabbione> but we can't really check if not manually
<infinity> Well, you can check his list and those should be the only packages that need to be left unbuilt.
<infinity> But I can't do proper dep-waits for them without some more input.
<infinity> I might just not-for-us the mess of them, and have doko tell me when to release them, though.
<infinity> Since it's pretty simple to toggle a -n.
<fabbione> yeah
<doko> morning alll
<fabbione> here is the guilty boy
<doko> infinity: what do you need?
<infinity> doko : An indication of what each of those frozen packages should actually build-dep on? :)
<infinity> doko : Erm, dep-wait, I mean.
<infinity> doko : Knowing that foo build-deps on libbar0 isn't as helpful as knowing that foo should dep-wait on libbar0c2, but i don't want to make assumptions about package renames.
<doko> infinity: so, you do need the new package names?
<doko> infinity: added a column, let mw knwo what you need as the format
<infinity> doko : I'm not so picky on format, I just want to know that "when package (or package_version) is in the archive, this should be built"
<infinity> doko : So, if that's "foo dep-wait libbar0c2, libbaz1c2, libquux2", or will need versioned build-deps for some, I need to know.
<infinity> doko : So that needs ot take into account c102 libs being names back, libs being names to c2, and god knows what else.  If it's easier for you to just ping me each time you think an app can/should be tried, we can do that instead, but automating it is nice. :)
<doko> and foo is the source name?
<doko> infinity: list updated
<infinity> foo is the source package, libbar, etc are binary packages.
<doko> is this the kind of thing you need?
<infinity> Beautiful.
<infinity> Even better if it's all correct. :)
<doko> wait ...
<infinity> I have to go grocery shopping with my girlfriend, when I get back, whatever the state of that file is, I'll hammer it all into wanna-build and remove the blacklists from the buildds.
<daniels> infinity: hoorah for safeway
<daniels> infinity: get some Thai for me
<doko> for this going to work, I'll have to update the list in the wiki with the new library names ...
<infinity> Hooray indeed.  Those bastards are holding my cow hostage, and I want it back!
<daniels> infinity: mmm.  it's thai night for me, tonight.
<doko> infinity, when are you back?
<infinity> doko : To make sure the MOTUs upload with the right renames?
<infinity> doko : 1.5-2 hours tops.
<infinity> However long it takes to get some steaks and other essentials and head home.
<doko> ok. well I need to give YOU the new names well ...
<infinity> doko : I'll ping you as soon as we're back.
<\sh> doko: what should we do with this ocaml gcc4 issue on i386? i didn't find anything yesterday about a solution...and I'm not this asm hacker ;)
<doko> \sh, build-dep on GCC 3.4
<\sh> doko: that means all packages depending on ocaml in any way, have to be transistioned to gcc-3.4
<doko> \sh why? do all the packages use this assembler code?
<\sh> doko: no, but if i want to compile a g++ app with g++ 4 and it's linking against ocaml it breaks at linker stage
<doko> hmm, what does break?
<\sh> shit..i'm searching..i need a konqui shortcut for buildlogs ;)
<\sh> forget it...gcc-3.4.gcc-opt: not found...
<\sh> something else
<doko> \sh that looks like a buildd problem
<fabbione> no it's not
<fabbione> doko: that's a missing b-d on gcc-3.4
<doko> or that
<doko> \sh, what are you looking for?
<fabbione> gcc-3.4.gcc-opt is only a wrapper for gcc-3.4
<fabbione> but if gcc-3.4 is missing it reports exactly the error as it should be
<\sh> fabbione: it is a missing b-d 
<fabbione> that's what i said :)
<fabbione> i see the same errors in the sparc buildd
<doko> \sh: add it ;-)
<\sh> ok..that means, all ocaml universe apps has to be touched e.g. findlib
<\sh> doko: on my way ;)
<fabbione> doko: it is probably simpler to add a Depends: gcc-3.4 deps to the ocaml-dev thingy
<fabbione> given that's a reasonable solution
<doko> fabbione: yes, sounds good, and then I can do automatic uploads for the remaining things.
<\sh> fabbione: there is no ocaml-dev
<\sh> Binary: ocaml-interp, ocaml-nox, ocaml-base, ocaml, ocaml-compiler-libs, ocaml-base-nox, ocaml-native-compilers, ocaml-source
<\sh> but anyways, some packages are b-d on ocaml-base-3.08 (as package name) or ocaml-nox-3.08 (as packagename)
<fabbione> afaik it's ocalm calling gcc-3.4 automatically
<fabbione> so it is ocalm that has to pull it in
<fabbione> and not the 3000 apps
<\sh> fabbione: ocaml has gcc-3.4 as b-d
<doko> so, on which package b-d all the 3000 apps?
<\sh> first of all, we have to get rid of things like this:
<\sh> Depends: libncurses5-dev, ocaml-base-nox (=${Source-Version}), ocaml-base-nox-3.08.3, ocaml-interp-3.08.3
<fabbione> \sh: ocalm needs to have it as Depends:
<fabbione> so that gcc-3.4 is pulled in for apps to build
<\sh> because those ocaml-base-nox-3.08.3 is a provides in one of the packages resulting of source ocaml
<\sh> i think to be compatible to debian?
<doko> heh, did you have a look at the package maintainer ...
<doko> svenl: your ocaml package is b0rked ;-)
<fabbione> ahahha
<fabbione> doko: i am almost done with ppc64 kernels :)
<fabbione> if i feel lucky i will upload them today
<doko> heh, cool. time to upload GCC 4.0 ;-)
<fabbione> it slightly depends on how it builds 
<fabbione> doko: go ahead really
<fabbione> doko: until all this C++ crap is sorted at buildd level, i am just trashing time in universe
<doko> \sh, what is a typically build-dep for an ocaml related package?
<fabbione> and i need the /lib64 fix for sparc
<doko> ahh, sure
<doko> well, it cannot be built at the moment. lib32z1-dev is missing in main
<\sh> doko: ocaml-3.08.3
<fabbione> well that's a dep-wait
<fabbione> but why does it need that new lib?
<\sh> doko: as well for Runtime Depends
<doko> well, yes looking at the package description, fabbione is right, just add g++-3.4 as dependency to ocaml
<fabbione> doko: and gcc-3.4 please
<doko> fabbione: building 32bit libgcj on amd64
<fabbione> ah ok
<doko> fabbione: not needed
<fabbione> this multiarch crap is crap :P
<\sh> doko: can u do it, cause it's main ;)
<doko> ok
<\sh> thx
<doko> ahh, it only needs gcc, not g++ ...
<\sh> what about the ocaml-3.08.3 package name? we should get rid of it
<doko> anyway, can't hurt ...
<fabbione> doko: speaking of "can't hurt"
<\sh> ok..lets fix some digital tv stuff
<fabbione> what about ncurses for ppc64
<fabbione> ?
<fabbione> i don't need it as kernel b-d but quite a lot of users that recompiles kernels need it
<doko> fabbione: do it, I don't need it ;-)
<fabbione> doko: me neither.. i don't even a damn ppc at home!
<fabbione> :)
<doko> heh, "our priority are our users" ;)
<fabbione> so send me a g5 :)
<fabbione> and make me a ppc user
<Mithrandir> fabbione: this aint multiarch. :P
<fabbione> unknown Debian architecture powerpc64, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 214.
<fabbione> grrr
<svenl> doko: nope.
<svenl> doko: x86 sucks.
<svenl> doko: works fine on all other arches but loosy x86 with gcc-4.0.
<doko> svenl: fix it ;)
<svenl> There is already a bug report upstream though, so will probably be fixed in the next release.
<svenl> doko: amd64 works fine, so throw away all that loosy legacy x86 hardware you have around and get real stuff instead :)
<svenl> seriously, mark this upstream, and let some time pass, or write a follow up to the bug report.
<svenl> http://pauillac.inria.fr/bin/caml-bugs/incoming?id=3637;expression=uther;user=guest
<infinity> Back.
<infinity> doko : Is your dep-wait stuff deinifely accurate and ready to go into wanna-build?
<doko> I did ...
<doko> 1) get the pairs of oldlib/newlib
<doko> 2) looked, which oldlib's are still in the archive
<doko> 3) looked for packages, which depend on those old libs
<infinity> 4) Match source package to new libs
<infinity> 5) PROFIT
<fabbione>   Maximum number of CPUs (2-128) (NR_CPUS) [32]  (NEW) 
<fabbione> ok.. how many CPU should we support for ppc64-smp ?
<fabbione> i had say 32 is more than enough :)
<doko> ahh, you do want the source names instead of the new libnames?
<infinity> Eek.  THis looks scary.
<infinity> Use of uninitialized value in scalar assignment at /usr/bin/dh_shlibdeps line 138, <COMPAT_IN> line 82.
<infinity> (repeat about 100 times, with different line numbers)
<infinity> doko : No, no.  The source packages we're building.
<infinity> doko : source apps, binary libs.
<infinity> fabbione : How much memory do you lose for each CPU?
<doko> so why step 4)
<doko> ?
<infinity> fabbione : I can't imagine people installing Debian on a pcc64 system/partition with 128 CPUs, but such systems exist (with 4096 CPUs, even)
<infinity> doko : Oh, I meant "match the source of the apps with the new libs they dep-wait on"
<doko> yes, that's done in frozenapps.txt
<doko> ahh, source ...
<doko> no, that's already there ...
<infinity> Excellent.  Kay.  I'll shove it in wanna-build in a few mins.
<doko> okay, and then, all frozen C++ apps should build?
<infinity> They all should build automagically as the libraries they depend on get installed, that's the theory.
<fabbione> infinity: if there only was a help entry......
<infinity> For?
<fabbione> for the cpu thingy
<fabbione> now i remember why i didn't want ppc64
<fabbione> just the config part is rather frigging boring
<infinity> Okay, script looks goodish.
<infinity> doko : Would it be bothersome to get those dep-waits comma-separated, so I can be even lazier? :)
<doko> you're eyes are still ok, aren't they? ;-)
<infinity> Last time I checked...
<doko> check the file, not your eyes ;-P
<infinity> Dude, you just changed that.
<infinity> You must have.
<doko> :)
* infinity stares.
<infinity> MY COPY HAS NO COMMAS, DAMNIT!
<infinity> Also, thanks.
<doko> be honest, you removed the commas ;)
<infinity> <cartman> Seriously, I hate you guys.. </cartman>
<infinity> Oh, cock.
<infinity> Those source packages need versions too.
<infinity> Maybe I can just fudge it.
<infinity> On, no I can't.  Whose silly idea was this?  <glances at lamont>
<infinity> I can't dep-wait stuff that's installed.  Only stuff that needs building (or is building/failed, etc)
<doko> hmm, so which versions do you need?
<infinity> One version higher than the current installed one, I guess. :)
<infinity> And they all need to be in a state other than installed.  Which is ludicrous.  Unless they already are all uploaded but just not building due to the blacklist.
<infinity> (THis seems unlikely)
<infinity> Maybe not-for-us on all of them was a better idea. :)
<infinity> Easy to toggle it on and off at will.
<infinity> Just requires more human interaction, fewer crap perl scripts.
<doko> well, then just take the first column and freeze these again
* infinity sighs.
<infinity> It was such a GOOD crappy perl script too.
* infinity kicks sand.
<doko> you did it in perl?
<infinity> I stole the wanna-build interface from buildd-mail, which is in perl.
<infinity> So it made sense to just put the glue around that in perl as well.
<infinity> Anyhow.  Suck.  I'll just Not-for-us the whole bunch.
<infinity> That means I can remove the blacklist from buildd.conf, right?...
<infinity> (Yes, i realise if I admit to using anything other than python I can get fired from Canonical)
<infinity> (I better not mention that I use SVN and CVS all the time, even in places where I could switch to arch but don't)
<doko> :)
* infinity sobs.
<infinity> for i in libopenhbci-plugin-ddvcard pingus glcpu qalculate fwbuilder gnomemm xbsql libprinterconf race libaqhbci libaqhbci libccaudio octave-forge ginac trophy gnunet gnucash python-omniorb2 libsdl-ruby valknut clanbomber acovea lablgtkmathview rsplib libaqbanking fwbuilder bakery-gnomeui2.0 qalculate php4-interbase xmule libccscript debtags fwbuilder rezound libbonobouimm1.3 xfe dbbalancer ginac libaqhbci-qt-tools doodle monopd debtags-edit bayo
<infinity>  echo "$i"; for j in i386 amd64 powerpc ia64; do wanna-build -b $j/build-db -n $i; done ;done
<infinity> At least it's a more familiar language. :)
<infinity> Neat, there were duplicates in that list.
<infinity> fabbione : Do that, but make the final argument "$i"_1 (so you get a package version), and remove the duplicates from the list (or they'll toggle NFU, and then back again in the loop)
<infinity> doko : Okay, can I remove the blacklist from the config files completely, then?
<infinity> doko : Those were all the apps we care about not building?
<doko> infinity: yes, modulo the bugs that I probably made
<infinity> Mmkay.  The floodgates will open soon, then.  Making config file changes on all the hosts.
<fabbione> infinity: sorry.. i wasn't following...
<fabbione> infinity: what should i do?
<fabbione>  /usr/bin/make -j15 EXTRAVERSION=-1-powerpc64-smp  ARCH=ppc64 \
<fabbione> BTW :)
<infinity> fabbione : Well, you only have one buildd, right?
<fabbione> yes
<infinity> fabbione : You can either not-for-us everything in the list above (which is what I did), or just put that list in no_auto_build.
<infinity> (I not-for-us'd it cause I have 12 buildds to deal with..)
<infinity> The dep-wait thing won't actually work, since all but 2 of those packages are in state "Installed".. Whoever wasn't thinking of that earlier wasn't thinking clearly.
<fabbione> i already have the apps in no_auto_build
<infinity> Right, is it just that set?
<infinity> (it's a lot smaller than the old set)
<fabbione> yeps
<infinity> Kay, then you have nothing more to do except wait for people to whine at us each time one needs to be removed. :/
<fabbione> but i have still the full list banned becuase we don't have a way to check if all the libs have been built
<fabbione> at least not automatically
<infinity> We can't do much better than that, unless someone wants to upload updated versions of all of them right now.
<infinity> Then we can dep-wait them all.
<doko> infinity: I'll uploading things, after I know, what is currently in the queue and builds now
<infinity> doko : Right, there were about 30 in the queue when I restarted buildd on the first machine.
<fabbione> interesting...
<fabbione> HAS_BIARCH      := $(call cc-option-yn, -m64)
<fabbione> this one fails miserably on ppc64
<fabbione> well i need food now
<infinity> I need rest and real life now, I think.
<infinity> As soon as I'm done restarting all the buildds.  (sure, buildd re-reads its config, but it doesn't remove things from no_auto on re-read... clever, eh?... Feh)
<doko> fabbione: do you know about the correct fix to the xbase-clients postinst?
<jbailey> fabbione: pong
<jbailey> fabbione: You usually start at midnight my time, which is why when you show up I kow it's time to go to bed. =)  (But I went to bed early last night *g*)
<\sh> doko: looks like now we have a new issue with ocaml ;)
<doko> which one?
<fabbione> re
<fabbione> doko: no, i didn't even look at it.
<fabbione> doko: daniels promised a fix asap
<fabbione> jbailey: ehhe no problem dude
<fabbione> elmo: ping?
<fabbione> doko, jbailey: at this point in time, is there any difference in build ppc64 in breezy-ppc64 or breezy chroot on davis?
<doko> if breezy is up-to-date, no
<fabbione> ok it is
<jbailey> fabbione: I am not aware of the states of the david choots.
<jbailey> (sorry, the only one I use often is Concordia)
<fabbione> Version: 3.4.4-0ubuntu3
<fabbione> is this enough to build ppc64?
<jbailey> fabbione: Look for libc6-dev-ppc64
<fabbione> mehhhh
<jbailey> I depends on a new enough gcc-3.4, and will also mean that the ppc64 bits have been loaded.
<fabbione> if neither thom or elmo are around i am stocked
<fabbione> breezy-ppc64 doesn't have kernel-build deps
<fabbione> and breezy is not updated
<fabbione> jbailey: we need to talk about that lustre thing
<\sh> doko: labltk
<fabbione> do you have time now?
<jbailey> fabbione: Yup.
<fabbione> ok
<fabbione> let's hook up jdub too
<jbailey> For you, my dear, I always have time.
<fabbione> lovely :)
<doko> should we other leave the channel for a few minutes?
<chmj> hahahah 
<jbailey> doko: Voyeur.  
<jbailey> doko: You would just read the logs anyway.
<ajmitch> sure, wouldn't you? 
<jbailey> Oh sure.  =)
<jbailey> Well, the first few paragraphs anyway. I like my erotica to be well written.
* chmj clears the screen 
<fabbione> hey ppc64 guys.. you need to modify dpkg to understand powerpc64
<fabbione> dpkg-architecture -apowerpc64 -qDEB_BUILD_ARCH
<fabbione> unknown Debian architecture powerpc64, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 214.
<infinity> Why are you building ppc64 packages?
<infinity> I thought you were working on biarch 64-bit-on-ppc32 stuff?
<doko> fabbione, it's ppc64
<jbailey> fabbione: Does it do it that way for sparc64 too?
<fabbione> jbailey checking
<fabbione> jbailey: yes it does... 
<fabbione> bah what a fucking mess
<chmj> doko, ping 
<jbailey> Ugh, that's insane.
<jbailey> I don't think there should ever be a _powerpc64.deb - nothing would know what to do with it.
<fabbione> jbailey: dpkg-arch needs to tell me that powerpc64 is built as powerpc
<fabbione> nothing more than that
<jbailey> Oh, dpkg-architecture, right.
* jbailey smokes another one.
<fabbione> but i think the overall crap can be worked around from kernel-package
<jbailey> keybuk's not online.  hmm.
<jbailey> I can just update the package, but I'd hate for the change to be lost if he thinks everything is in some VCS somewhere.
<fabbione> i might as well doing something wrong
<doko> infinity: why is libgnomemm2.0 2.0.1-2ubuntu2 not in the archives?
<infinity> Because it's shy?
<infinity> Or did you want a better reason?
* infinity goes to look.
<doko> built an hour or so before
<infinity> doko : It's uploaded by all 4 buildds, if it's not made it past katie, blame elmo.
<infinity> doko : katie's been acting up all day :/
<doko> infinity, thanks for looking
<infinity> I've bugged elmo on your behalf.
<infinity> He can rescue the builds, but with any luck he can actually find and fix the problem instead. :)
<infinity> And I think this is now WAY past the end of my work day.
<doko> looks like he already did start the party :)
<doko> 1am?
<infinity> 11pm, but I was supposed to quit at 6ish.
<infinity> Mmm, so that's what divorce smells like.
<jbailey> *lol*
<jbailey> I read that as s/bugged/buggered/
<infinity> I wish.. <whistful sigh>
<infinity> Erm.
<fabbione> ehehhe
<infinity> Out loud voice.
<infinity> La la la.
<jbailey> Well it would've explained the divorce...
<infinity> See, and the next sentence was just too rude for a public channel.  Shame.
<fabbione> infinity: how is Xfree86 going on m68k???
<infinity> About to sign and upload.
<fabbione> cool
<infinity> And up she goes.
<jbailey> Mithrandir: I meant to be in this channel, sorry, ping. =)
<jbailey> So many "#ub..." tabs, all alike.
<chmj> are there any known problems with dbus ?
<Mithrandir> jbailey: pong
<jbailey> Mithrandir: I'd like to start assembling some of the multiarch stuff, starting with getting amd64 building an i386 glibc and putting the files in the right places.
<jbailey> If there's a file in /usr/include and a file in /usr/include/i386-linux, the one in -i386-linux takes prioirty under your setup, right?
<Mithrandir> I don't remember.
<Mithrandir> look at the patch :-)
<jbailey> bah. ;)
<jbailey> Mithrandir: Do you know off hand if it's been applied yet?  Wondering if the gcc-3.4 I have downloaded would have it in already or if I need to fetch it from you.
<Mithrandir> jbailey: ask doko.  I don't think so.
<jbailey> doko: *poke*
<Mithrandir> jbailey: but then, asking me when I've been fed champagne might not be wise. :-)
<jbailey> Ah, is there an occasion?
<infinity> Yeah, elmo and doko's birthdays.  We're all celebrating.
<infinity> I've been drinking for hours.
<infinity> What's wrong with YOU?  Funspoiler.
<jbailey> infinity: You're pretending to be Australian now.
<jbailey> infinity: You've been drinking for *months*
<jbailey> It's sort of like being in Vancouver.  After you've been there you can always tell a vancouverite by the smell of pot oozing from their pores.
<jbailey> It takes years to go away.
<jbailey> (It's a theory Angie and I have as to why we only seem to meet people from Vancouver in Toronto)
<Mithrandir> jbailey: end of studies thing, aka "exmatriculation".
<jbailey> ;)
<Mithrandir> which means I've drunk close to a bottle of champagne.
<desrt> jbailey; but what about the pot smokers in toronto?
<jbailey> desrt: It's not the same.  People here aren't proud of their pot smoking the way folks in Vancouver are.
<jbailey> desrt: Here they seem to be more drug addicts.  It's sort of like finding someone who drinks as much as an Australian outside of Australia.
<desrt> hmm.  so the smell-oozing-from-pores thing goes along with pride
<desrt> heh.
<desrt> it's funny, though... everyone has a different metric for who drinks a lot
<desrt> germans, australians, canadians, ...
<infinity> Vancouverites don't smoke pot, they just live in a constant cloud of burning week.
<infinity> It's a whole different ballgame.
<jbailey> infinity: Right. =)
<infinity> d/week/weed/
<Mithrandir> jbailey: do australians drink?
<infinity> s/d/s/
<infinity> Mithrandir : Australians pretend not to be alcoholics, but they seem to drink far more than anyone else I've ever met.
<infinity> Mithrandir : The whole country is in denial.
<jbailey> Mithrandir: No, it's like how Adam described it for Vancouverites.  They bathe in it.
<Mithrandir> infinity: I didn't see much alcohol in sydney.
<infinity> We drank on the job at my last job.
<infinity> Frequently.
<infinity> And copiously.
<infinity> TO drunkenness.
<infinity> And we dealt with clients in that state.
<infinity> And that was "normal".
<Mithrandir> infinity: yes?
<jbailey> The clients were also in that state, probably.
<Mithrandir> is that special?
<infinity> Mithrandir : Well, it is to us anal-retentive north americans. :)
<Mithrandir> we did the same, hot dogs and beer, then back to coding at Opera.
<infinity> Mithrandir : Maybe Australians are just scandinavians of the south.
<Mithrandir> infinity: this sounds perfectly normal to me. :-)
<Mithrandir> infinity: you coming to debconf?
<infinity> Mostly, it was the complete lack of social activities that didn't involve drinking that got to me.
<infinity> And still does on occasion.  But then I get drunk and forget about it.
<infinity> And no, not coming to debconf.  Can't afford it. :/
<Mithrandir> bah, you should have proposed a toast^Wtalk and gotten sponsorship
<infinity> Meh.  Next year.
<jbailey> Mexico city.
<infinity> Oh.
<infinity> The year after, then.
<infinity> Mexico City and I have a longstanding agreement to disagree.
<jbailey> Scottland, I think?
<Mithrandir> what's mexico city like?
<Mithrandir> yeah, edinburgh
<infinity> Mithrandir : The world's nastiest city.  Period.
<Mithrandir> how so?
<jbailey> Mithrandir: You're less likely to get mugged than in Sao Paolo...
<infinity> Over 30 million people, and nowhere near enough of them are employed in the cleaning business.
<Mithrandir> jbailey: I guess we'll just have Fortress Debconf, then?
<jbailey> Mithrandir: It worked in Porto Alegre...
<Mithrandir> jbailey: mpe
<infinity> (I think it's cause all the cleaners are working illegally in the US, but I'm not sure)
<jbailey> Of course, it would've been nice if the guards had been more cautious or more explicit with their guns.
<Mithrandir> even jonas smedgaard didn't manage to get mugged.
<Mithrandir> which guards?
<infinity> If Jonas got hit hard enough to forget about Debian, that might be nice.
<infinity> But I didn't say that out loud.
<Mithrandir> I would be happy if he just forgot about bitching on debian-edu about _everything_
<fabbione> hey lamont
<Riddell> infinity: edinburgh is the world's nastiest city?
<infinity> Riddell : No, Mexico City is.
<Riddell> phew :)
<Riddell> what's happening in Edinburgh then?
<Mithrandir> Riddell: debconf7
<Riddell> Mithrandir: where is that decided?
<Mithrandir> in porto alegre
<Mithrandir> iirc
<Riddell> google knows nothing of it
<Mithrandir> google doesn't know _everything_
<Riddell> ah, found one reference http://listas.softwarelivre.org/pipermail/debconf4/2004-June/000651.html
<elmo> fabbione: 'sup?
<desrt> elmo; how's biarch coming?
<desrt> (or going, i suppose)
<elmo> desrt: I've no idea
<\sh> hmmm...g77 is not available for the 4.0 toolset?
#ubuntu-toolchain 2005-06-11
<jbailey> \sh: Right, fortran 90 is.
<jbailey> It will eventually be fully backward compatible to f77 but isn't now.
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<fabbione> doko: did you finish to upload gcc????
<fabbione> it's the 3rd time i get to the test suite and i need to restart it :)
<doko> heh, didn't see the ppc build fail ...
<doko> should be the last one before 4.0.1
<fabbione> ok
<doko> 3.4 will need another upload not to build lib32*, which are now built by 4.0
<fabbione> ok
<fabbione> elmo: ping?
<elmo> fabbione: ?
<fabbione> hey dude!
<fabbione> did you get my sms yesterday?
<elmo> yes, thanks
<fabbione> :)
<fabbione> nice
<doko> elmo: you're currently working?
<fabbione> elmo: if you have time, can you do me a little favour? i would love to get breezy chroot on davis updated so that i can build ppc64 kernels on monday
<fabbione> elmo: and i need you to apply a little patch to kernel-package that is a fix i need to test
<elmo> breezy or breezy-ppc64?
<elmo> doko: kind of
<fabbione> elmo: if you upgrade breezy, you can trash breezy-ppc64 since they are the same
<fabbione> or they will be the same
<doko> infinity mentioned that binary packages are built, but don't enter the archive
<infinity> doko : They were in queue/NEW, which elmo processed.
<doko> ohh, nice
<fabbione> elmo: and once you are done with the upgrade of breezy, can you please apply http://people.ubuntu.com/~fabbione/kpkg-rules.diff to /usr/share/kernel-package/rules ?
<fabbione> elmo: so that i can test that fix
* fabbione would love to be able to do it himslef without having to bitch
<elmo> meh, xbase-clients failure
<elmo> annyway, updated, patch applied
<fabbione> elmo: thanks a lot
<fabbione> monday you will get some ppc64 kernels to play with :)
<daniels> elmo: edit xbase-clients.postinst, change /usr/X11R6/bin/xkbcomp to /usr/bin/xkbcomp
<elmo> fabbione: ok, that's good timing, I'll be back @ the DC
<fabbione> elmo: rocking :)
<elmo> daniels: thanks
<doko> daniels: when do you upload a new X with the xbase-clients fix. currently all KDE doesn't build
<daniels> elmo: no worries
<daniels> doko: i don't know.  soon.
<infinity> doko : Some might see that as a feature.
* infinity hides from Riddell...
<doko> daniels: that looks like not soon enough. It's an easy fix, please don't burden other people ...
<daniels> doko: shit dude, if you want to upload it, then you can upload it
<doko> daniels: thanks, will do.
<daniels> for the meantime, I'll just keep working along my own timescale and keep trying not to break stuff.  it's also a sunday night where I am, and I have a bajillion other things to do, like fill out about ten application forms for houses.
<doko> daniels: that might all be true, and I can understand it. but the upload was on Wednesday.
<daniels> doko: and?
<infinity> daniels : It's Saturday night.
<daniels> infinity: jesus, it is too
<infinity> There, you just won a whole day. :)
<doko> daniels: I don't care about your timescale as long as my timescale is untouched by it. it does cost you maybe 30minutes to fix, but it's delaying builds/updates/whatever for everybody else.
<daniels> doko: it costs me a crapload more than 30 minutes to fix, and I don't want to upload xorg as long as the upgrade path is still broken.  which it is.
<daniels> so you can fix your timescale if you want, but I don't see the point when xorg will still end up reasonably broken.
<doko> daniels: does the xbase-clients.postinst fix make things worse than they currently are in the archives?
<daniels> no
<daniels> for most people with problems outside of not being able to compile kde (because kdelibs4 has crap dependencies), it also doesn't make things any better
<doko> ok, I'll prepare an upload and send you the diff before upload
<daniels> if the diff is just that change to shell-lib.sh, go ahead and upload it directly
<doko> ok
<\sh> when do we get f77 into the gcc4 toolset? ;)
<doko> \sh, never
<\sh> doko: ok..can u take a look over fftw3? it needs f77
<\sh> thats on reason i got build errors on gnuradio
<\sh> one
<doko> build depend on g77, where's the problem?
<\sh> sorry..g77 ..
<\sh> g77-4?
<doko> g77
<infinity> \sh : g77 is still a valid binary package, it just doesn't come from gcc-4.0
<\sh> infinity: so I should build all packages against gcc-3.4 again? so that I get rid of the build errors
<\sh> ?
<\sh> doko: btw...libboost didn't recognized gcc4 as correct compiler...i fixed this issue
<doko> \sh: which build errors do you see?
<doko> \sh, seen that, thanks!
<\sh> doko: i will give u the build errors in one hour..i have to get rid of some other problems...then I will concentrate on gnuradio again 
* \sh needs a clean system first ;)
<\sh> bbl
<infinity> Off to get a bucket of soapy water?
<infinity> doko : libgnomecanvasmm2.0 is broken.
<doko> gconfmm2.0 as well
<infinity> Erm.
<infinity> It is?
<infinity> Oh, it is.  But only half broken.
<infinity> Or, only broken on 64bit arches, anyway.
<infinity> libgnomecanvasmm2.0 is just completely broken. :)
<infinity> And bakery is still waiting on libglademm2.0..
<infinity> Which I need to give back.  Yay.
* infinity fixes.
<infinity> There.  That should keep you busy a bit longer.
<infinity> doko : And, since I know you care deeply about all these GNOME libs, libglademm2.0 just failed in really special ways too (the build logs should be synced over soon)
<doko> I LOVE these packages ...
<infinity> I knew it.
<infinity> I love taking a weekend off, so I can only be moderately helpful instead of very helpful.
<infinity> In other words, I'll happily wrangle wanna-build for you, but I won't touch any packages until Monday. :)
<infinity> Ahh, there's your new failure logs for libglademm2.0 now.
<fabbione> well guys.. congratulation... gcc-3.4 -m64 on ppc seems to work :)
<fabbione>   gcc-3.4 -m64 -Wp,-MD,drivers/base/power/.suspend.o.d  -nostdinc -isystem /usr/lib/gcc/powerpc-linux/3.4.5/include -D__KERNEL__ -Iinclude  -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2     -fomit-frame-pointer -msoft-float -pipe -mminimal-toc -mtraceback=none -mcall-aixdesc -mtune=power4 -funit-at-a-time -Wdeclaration-after-statement     -DKBUILD_BASENAME=suspend -DKBUILD_MODNAME
<doko> elmo: please could you promote lib32z1{,-dev} to main, build dependency for gcc-4.0 now
<\sh> doko: ping
<\sh> g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/benchmark_dotprod benchmark_dotprod.o  -pthread ../../src/lib/.libs/libgnuradio-core.so -lrt /usr/lib/libcppunit.so -ldl /usr/lib/libfftw3f.so
<\sh> ../../src/lib/.libs/libgnuradio-core.so: undefined reference to `gr_fxpt::TWO_TO_THE_31'
<\sh> ../../src/lib/.libs/libgnuradio-core.so: undefined reference to `gr_fxpt::PI'
<daniels> TWO_TO_THE_31?
<daniels> that's, um, scary.
<\sh> and upstream has no clue as well
<lamont> that sounds like a missing #define somewhere
<\sh> what?
#ubuntu-toolchain 2005-06-12
<lamont> ../../src/lib/.libs/libgnuradio-core.so: undefined reference to `gr_fxpt::TWO_TO_THE_31'
<lamont> sounds like a missing define, normall
<lamont> y
<\sh> lamont: but compiles on debian normally
<\sh> anyways..will check it tomorrow 
* lamont expects that grepping for TWO_TO_THE_31 could be informative
<\sh> find . -type f -exec grep -H "TWO_TO_THE_31" {} \; 
<\sh> no hit
<\sh> as i said, i will check the cvs tomorrow
<lamont> interesting.
<lamont> anyway, off with the family for a while
* \sh is going to sleep now
<e0f> hi, anyone here?
<fabbione> morning
<fabbione> doko: hey dude
<fabbione> i might have ppc64 kernel binaries by this evening
<fabbione> it's building now :)
<doko> heh, cool.
<doko> 4.0 did build as well on ppc, so it's time for the 3.4 update as well.
<fabbione> it's FTBFS on sparc :)
<doko> oh no ...
<fabbione> but it's weird.. so i just gave it back
<doko> testsuite?
<fabbione> it failed that there was no activity for 150 minutes linking a library
<fabbione> so i guess it was just the sparc going slower than usual
<fabbione> i increased the timeout to 600 minutes
<doko> hmm, I've seen this on the debian buildd's as well
<fabbione> well it's slowly building
<fabbione> we will see later today or tomorrow
<fabbione> time to get some life :)
#ubuntu-toolchain 2006-06-06
<doko> infinity, mdz: is edgy already open?
<infinity> doko: No.
<infinity> doko: Some infrastructure still needs to be verified before it can open, and I'm also planning on hand-holding the new glibc and gcc before I put the buildds into free-for-all mode.
<fabbione> infinity: i assume glibc 2.4 ?
<infinity> fabbione: yes.
<fabbione> infinity: do we have package ready for it?
<fabbione> i wouldn't mind to give it a pre-spin on sparc
<fabbione> i know gcc-4.1 will break some sparc stuf
<infinity> Jeff's still polishing it.  He should be done his tomorrow morning.
<fabbione> ok
* fabbione wonders how much Niagara stuff will break with edgy
<infinity> I expect the whole world to break in edgy on every arch, so no big deal.
<fabbione> infinity: eheh yea
<mdz> doko: today is the day
<doko> hmm, infinity told that he still needs buildd babysitting 
<doko> or should that be builddsitting
<doko> infinity: we cannot sync gcc-4.1 and gcj-4.1; sparcv9 patch is missing ...
<infinity> doko: Okay, then can you give me a gcc-4.1 and gcj-4.1 on chinstrap somewhere that I can do the chroot bootstrap with as soon as Jeff hands me a final glibc?
<doko> infinity: yes, waiting on a final test build
<infinity> doko: You rule; thanks.
<doko> infinity: chinstrap:~doko/uploads -> gcc-4.1
<jbailey> Ah, sorry 'bout that.
<jbailey> I'm on my laptop so I don't auto-login to all my usual channels.
<doko> so maybe it's safer to first build gcc-4.1 and gcj-4.1, then glibc?
<doko> I do not want to block edgy for too long
<infinity> We're not blocking anything yet.  Don't worry about it.
<infinity> Anyhow, I've already got a plan laid out and it should go just fine.
<jbailey> sparc did need the same fix, I've added it to my tree.
<jbailey> infinity: My biggest weakness right now is that for all but ppc/ppc64 I'm only doing chroot tests for these.
<jbailey> And I don't have a sparc.
<jbailey> I need to keep my systems pure dapper right now for LSB
<infinity> chroot tests are good enough for me.  <shrug>
<infinity> We'll find out soon enough if you broke the world anyway.
<doko> infinity: gcj-4.1 online as well
<jbailey> you know my OCD ;)
<infinity> jbailey: It's trivial to run a full GNOME environment from a chroot, if you really want to give it your acid test.
<jbailey> How do you get access to X, just bindmount tmp?
<infinity> Yeah, bindmount /tmp and don't kill your environment on chroot.
* jbailey waffles.
<infinity> (so, "chroot /chroot su" instead of "su -", or "dchroot -d -c edgy" if using dchroot)
<infinity> Alternately, for the full test, kill your X session, chroot into the chroot, then startx from there, so your whole test is ground-up running in the chroot.
#ubuntu-toolchain 2006-06-07
<fabbione> -Wa,--noexecstack
<fabbione> hmm
<fabbione> wasn't that supposed to be disabled by default?
<doko> if it's the default in the compiler, then no.
<fabbione> that's gcc-4.1 in dapper
<fabbione> (sparc)
<jbailey> glibc uploaded for edgy, enjoy.
#ubuntu-toolchain 2006-06-08
<doko> Keybuk, infinity: packages are rejected ... (gcc-4.1)
<Keybuk> doko: sssh
<Keybuk> don't tell anyone
<Keybuk> (hey, at least he got _that_ mail)
<Keybuk> we managed to get two copies of gcc-4.1 in the new queue
<Keybuk> we reallly don't know how
<doko> ohh, I see, I got the accepted message twice
<doko> promised, I did upload only once ;-P
<Keybuk> actually, we had to shove it through LP with a bulldozer
<Keybuk> the changes files were sent by me, by hand :p
<jbailey> doko: do you remember off hand the difference between -march=pentium3 and -march=i686 ?
<doko> jbailey: sorry, no
<jbailey> np, thanks.
<jbailey> doko: I need to look at specs tonight.
<jbailey> do you think edgy is a good time to move glibc out of /usr/lib and /usr/lib64 into full multiarch paths? =)
<doko> heh, write a spec =) but I think Mithrandir is working on it?
#ubuntu-toolchain 2006-06-09
<jbailey> 'kay, I'll ping him.
<jbailey> I was more thinking just in the toolchain roadmap side.
<jbailey> And I guess we should also do another toolchainroadmap-ng
<doko> jbailey: we should call that spec toolchainroadmap-edgy+1
#ubuntu-toolchain 2006-06-10
<fabbione> Unpacking cpp-4.1 (from .../cpp-4.1_4.1.1-2ubuntu1_i386.deb) ...
<fabbione> dpkg: error processing /var/cache/apt/archives/cpp-4.1_4.1.1-2ubuntu1_i386.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/man/man1/cpp-4.1.1.gz', which is also in package gcj-4.1
<fabbione> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<fabbione> Errors were encountered while processing:
<fabbione>  /var/cache/apt/archives/cpp-4.1_4.1.1-2ubuntu1_i386.deb
<fabbione> doko: ^^
<jbailey> doko: 
<jbailey> /usr/share/doc/gcc-4.1-base/copyright
<jbailey> /usr/share/doc/gcc-4.1-base/.copyright
<jbailey> /usr/share/doc/gcc-4.1-base/changelog.Debian.gz
<jbailey> /usr/share/doc/gcc-4.1-base/.changelog.Debian.gz
<jbailey>  ?
<doko> see the changelog, it's there to fix an upgrade from a bad version
<jbailey> I don't see that from a quick search, but as long as it's known =)
<jbailey> I wish I knew how many people were running the edgy glibc.
<fabbione> jbailey: i am :)
<fabbione> xine -> gtk crash on i386
<fabbione> dhcpclient hang on ppc
<fabbione> that's all i have seen for no
<fabbione> +w
<jbailey> Oh interesting.  I don't see the dhclient on my ppc.
<jbailey> I wonder what's different.
<fabbione> no idea
<fabbione> and i didn't have time to look at it yet
<fabbione> too busy with sparc/dapper
<jbailey> No worries. =)
#ubuntu-toolchain 2006-06-11
<jbailey> Huh, weird.
<jbailey> When I'm following the strace through, it's not that it's not looking at langpacks, it's not looking for *any* of the localised messages.
<jbailey> I just realised that.
<jbailey> So even things like apt which aren't langpack'd still aren't in the local language.
<doko> fabbione: fixed for the next upload
<fabbione> doko: thanks dude
#ubuntu-toolchain 2008-06-04
<jroth> ping doko
<doko> ?
<jroth> I heard that you are the maintainer for libspe in ubuntu, is that right?
<doko> I did the initial packaging, now it's a community port
<doko> just reading the backlog on #cell
<doko> so what is the issue with the libspe package?
<jroth> well there is no issue
<jroth> I'm about to maintain it for fedora
<jroth> and I had a look where you guys put the spu include files 
<jroth> ubuntu puts it into /usr/spu/include and gentoo in /usr/spu-elf/include
<jroth> and I thought it would be nice if there is a common understanding about cross-compiling include files and libs.
<jroth> Before fedora decides to put it into /usr/spu-linux/include for example ....
<doko> ahh, ok. I did look at the rpm packages of the barcelona supercomputing center, and then tried to stick to those as a reference
<jroth> yes, the Cell SDK3.0 puts them in /usr/spu/include and all these crappy SDK makefiles have these paths hardcoded
<doko> arthur- is working as well on the packages (also on the #cell channel).
<jroth> I won't care about breaking these makefile infrastructure. 
<doko> I think it doesn't matter that much; if you like spu-elf instead, then maybe provide a symlink to spu
<jroth> I just want to do the right thing
<jroth> ok
<doko> but once this symlink is in place you may have a hard time to replace it with a directory
<doko> at least that's the case for deb based packages
<arthur-> doko: cool you're up, you can write an email for my AM report ;^P
<doko> oops
<jroth> yes, and that is also the reason why I care about it. I want to avoid trouble in the future ;-)
<doko> yeah, the weather was fine in the beer garden yesterday ...
<doko> looks like /usr/spu is less trouble 
<arthur-> I also think so
<arthur-> doko: eheh. I bouced you the mail, should be 20080602082848.GE10696@artemis.madism.org
<jroth> ok, good. I'm preparing a discussion on the fedora-devel list. Would you mind if I put you on cc ? 
<doko> np
<arthur-> jroth: please also Cc arthur.loiret@u-psud.fr
<doko> we use the gnu system alias for other names as well (instead of the canonical gnu system name)
<doko> ohh, and munckfish seems to be interested in cell as well
<arthur-> doko: btw I answered pitti's mail on BTS, perhaps should have Cc'ed you
<arthur-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399#20
<arthur-> doko: please don't forget my AM mail this time ;-)
<chef123> hello how do i get ubuntu support
#ubuntu-toolchain 2008-06-05
<arthur-> doko: please also add --enable-targets=all to configure flags on sparc on gcc-snapshot
<arthur-> doko: http://ada.lri.fr/~arthur/sparc-enable-targets-all.diff.txt
