#ubuntu-toolchain 2005-05-30
<doko> you may want to enable building the shared lib64gcc1 package in debian/rules.defs ...
<doko> until gcc-4.0 builds it
<jbailey> Yeah.  The other thought I had was that if we do gcc-4 first for these then a new gcc-3.4 can be built without overriding CC
<jbailey> I discovered this by forgetting to override CC when I updated to thge gcc-3.4 from this morning and it still built.
<doko> upload the 3.4 which builds lib64gcc1, it can be overwritten by 4.0 later
<jbailey> 'k
<fabbione> hey guys
<fabbione> lamont: ping?
<fabbione> lamont: can you kick back db4.2 on i386?
<fabbione> there is no reason why it failed at all
<fabbione> ubuntu5 is exactly as ubuntu4 with one line change in debian/rules that doesn't touch i386
<doko> elmo: please move gnat-4.0 to main
<elmo> doko: please seed it
<daniels> doko: uhm, xbase-clients doesn't depend on xlibmesa-glu
<daniels> doko: unless it crept in through ${shlibs:Depends}, which would be annoying
<daniels> and also shouldn't happen
<doko> daniels: it did happen, and it is annoying :-)
<daniels> elmo: do any of the buildd chroots have xlibmesa-glu-dev installed?  if so, can they please not?
<fabbione> morning
<jbailey> Heya Fabio
<fabbione> hey jeff!
<fabbione> latest glibc is almost done on sparc :)
<jbailey> Nice!
<jbailey> This version decouples the locales dependancy
<fabbione> AH COOL!
<jbailey> So if you want to skip glibc for a rev or two after this, you're welcome to without penalty.
<fabbione> jbailey: you tell me :)
<fabbione> i can ban it from being auto built
<fabbione> specially if you plan to do 3/4 uploads with no benefits for sparc
<jbailey> fabbione: I don't see any reason why not to ban it for most of this week unless I tell you otherwise.  It looks like we'll be in good shape to do some biarch/multiarch work, i386/amd64 and ppc/ppc64.
<jbailey> fabbione: It makes sense to tweak sparc/sparc64 at the same time to look the same.
<jbailey> But it won't be first....
<fabbione> of course :)
<fabbione> dpkg is still fucked
<fabbione> dpkg-architecture -qDEB_HOST_GNU_SYSTEM
<fabbione> linux-gnu
<fabbione> this break at least kernel-package
<jbailey> Well, at least it's now reporting what config.{guess,sub} does so there won't be inconsistancy anymore.
<jbailey> But it took two glibc and two gcc uploads to get it right for us.
<fabbione> jbailey: so the final decision is linux-gnu?
<jbailey> I didn't realise there had been any discussion about it.
<fabbione> well we need to decide and fast
<fabbione> otherwise i can't upload the kernel
<fabbione> that is a big blocker for me atm
<jbailey> dpkg 1.13.2 contains the change pretty explicitely, so it's not an error.
<jbailey> doko and I each fixed other toolchain bits to cope.
<jbailey> Although both of us included bits for backwards compatibility.
<fabbione> well i need to change kernel-package
<fabbione> and hounestly i can just build-dep on a specific version of it
<fabbione> + add a versioned depends on dpkg
<fabbione> that in this case it is allowed due to the mess
<fabbione> (even if dpkg is essential)
<svenl> hi jbailey 
<jbailey> ifeq ($(DEB_HOST_GNU_SYSTEM),linux)
<jbailey> DEB_HOST_GNU_SYSTEM := linux-gnu
<jbailey> endif
<fabbione> that would work too
<fabbione> are you aware of other entries that did change?
<jbailey> svenl: Heya
<jbailey> fabbione: I'm just looking at what doko did in gcc
<jbailey>   # configure as linux, not linux-gnu
<jbailey>   TARGET_ALIAS := $(subst linux-gnu,linux,$(TARGET_ALIAS))
<svenl> jbailey: i want to give rebuilding glibc/gcc a try again.
<fabbione> hmm that can be done too
<jbailey> svenl: I haven't got all the packaging sorted out yet. =(
<jbailey> svenl: The latest gcc-3.4 in Ubuntu is very close, though.
* svenl quite of wonders if there is not some svn/arch/baz/whatever repo with all those changes on it, instead of going begging to jbailey or doko to try stuff out :)
<jbailey> svenl: The source changes aren't the important bits.  It's a tiny change to glibc and to gcc.
<svenl> Ok, i will give it a try. 
<jbailey> The problem is that you need to start from working binaries.
* svenl hoping that today's breezy will cure my powerbook :)
<svenl> Yep.
<svenl> Well, not necessarily, as we have all started in some other way.
<svenl> I mean, you originally built glibc with a cross compiled biarch gcc, didn't you ? 
<jbailey> I don't know how it was generated, doko gave it to me.
<svenl> the glibc ? 
<jbailey> I'd assume so, though.
<svenl> or the gcc ?
<jbailey> the gcc.
<svenl> Oh, so you where not the first one in building it.
<svenl> mmm, no xfonts-utils this morning too.
<jbailey> No.  Before it gets uploaded to Ubuntu, though, I'm tempted to do a clean bootstrap of the whole thing so that I can feel very happy about it.
<svenl> bah, gnome still gives me a message entitled Xession, and a little lamp, but without further text.
<svenl> jbailey: :)
<jbailey> Does recovery mode work for you?
<svenl> session de secours gnome ? 
<jbailey> Sounds right.
<svenl> ah, works much better.
<jbailey> My gdm isn't set to french, only my login sessions.
<svenl> mmm.
<svenl> there it is.
<svenl> all gnome plugin are dead though, i guess because loads of gnome libraries are bogus.
<svenl> mmm, gnome-panel just crashed.
<jbailey> What are you doing to your box? =)
<jbailey> My system has been stable all day..
<jbailey> Unless there was some mid-day update.
<daniels> svenl: i assume the binaries for xfonts-utils are waiting on NEW love
<svenl> daniels: indeed, there are no xfonts-utils on ppc.
<svenl> daniels: do you have unofficial ones ? 
<svenl> (it all started because i wanted to compile biarch gcc :/)
<svenl> oh well, standard session seems to call xsession and not gnome-session.
<daniels> http://people.ubuntu.com/~daniels/xfonts/xfonts-utils_6.8.2-12_all.deb
<svenl> daniels: :)
<svenl> oh, seems better, if i validate the xsession dialogue, i get a working gnome-session.
<svenl> daniels: do you know where that xsession dialog comes from ?
<daniels> probably missing fonts, particularly if you have no text
<jbailey> svenl: I'm uploading to people.ubuntu.com/~jbailey/glibc
<svenl> jbailey: thanks.
<jbailey> I have a slow DSL uplink and I'm headed to bed.
<svenl> daniels: your xfonts-utils will help me on that.
<jbailey> svenl: The most recent gcc-3.4 in the archive is mostly setup for the biarch.  You need to change debian/rules to set CC to gcc-3.4 (the one that you got from me before), debian/rules.defs to enable the biarch config, and debian/binary-gcc.mk to fix the dh_link bug (missing $(PF) and missing some \'s.
<daniels> svenl: maybe.  if it doesn't, remember to change your paths from /usr/lib/X11 to /usr/share/X11 in xorg.conf
<svenl> jbailey: ok, will give a try today.
<jbailey> Sorry, scratch the CC bit in rules.  Current gcc seems to build biarch gcc fine.
<svenl> daniels: yep, i did that.
<daniels> cool
<svenl> daniels: well, actually, they are not in /usr/share/X11 for some reason, so i have them pointing to /usr/X11R6/...
<jbailey> However with all that, the current package doesn't produce lib64gcc_1.so.  That's where I go to before going out for drinks this evening.
<daniels> errrrrrr
<daniels> if they're not in /usr/share/X11, then you're not using the packages from xfonts-core
<daniels> which is xfonts-* 6.8.2-12
<jbailey> svenl: Oh yeah, I had to redo my font config this morning, are you on a pegasos box?
<svenl> daniels: i only have type1 and truetype in shate.
<svenl> jbailey: nope, powerbook.
<jbailey> svenl: Ah, okay.
<daniels> svenl: then you need -75dpi, -100dpi, and others from 6.8.2-12
<jbailey> svenl: Otherwise I'd send you my xorg.conf
<daniels> jbailey: it's not pegasos-specific by any means
<svenl> daniels: i have a couple of fonts upload waiting for xfonts-utils..
<daniels> svenl: um, for ubuntu?
<svenl> daniels: sure.
<daniels> main or universe packages?
<svenl> daniels: all of them, breezy even.
<daniels> cool
<jbailey> daniels: Yeah, I wasn't looking for a good solution to the problem, just to offer him a working config if he happened to be on the same system as I.
<jbailey> =)
<daniels> send the universe ones to the motu guys at #ubuntu-motu
<daniels> heh
<svenl> i did install x-window-system though, which may have been a mistake, as i tried to solve the font dissapeared issue cluelessly.
<svenl> xfonts-utils -16 is conflicting with xutils -10 :?
<svenl> :/ even
<svenl> mmm, forcing it.
<svenl> ok, that seems to fix it, thanks daniels
<svenl> daniels: altough the fonts and co are only at -11
<daniels> yeah, update-fonts-* was in xutils until about -15 or so
<daniels> and the binaries are stuck in NEW
<daniels> but when that gets fixed, we'll have -12 everywhere, and dist-upgrades will pick up what's needed
<svenl> daniels: do you have unofficial fonts package too ?
<daniels> not going to upload them, they take about an hour on my DSL
<svenl> daniels: can i build them from source ? 
<daniels> sure, the .diff.gz is in the repository
<jbailey> Sleep time, g'n all!
<daniels> night dude
<fabbione> night
<fabbione> infinity: ping?
<infinity> fabbione : pong.
<infinity> fabbione : I'm in the middle of insalling Ubuntu on my girlfriend's amd64 machine, so I have something faster to work on.
<fabbione> infinity: eheh neat... i had a question for you.. just a sec i need to find the reference again
<infinity> fabbione : Was it a toolchain question, or are you just picking random channels to ping me in? :)
<fabbione> #$secondary_daemon_threshold = 70;
<fabbione> random chan :)
<fabbione> it's a buildd question
<fabbione> prefer in pvt?
<infinity> Nah, public is cool.
<fabbione> what does that option do exactly?
<infinity> Allows a second daemon to be spawned if the queue is over $x deep, IIRC.
<fabbione> i understand that if there are more than N pkgs in needs-build, buildd will fork.. but how and with what criteria?
<fabbione> what's the point of spawning if the chroot is locked by another package?
<infinity> If you want "whate precisely does it do when it forks?", I'd recommend reading the source.  As you may imagine, that's a feature I never turn on. :)
<fabbione> or there is a way to specify a seconday chroot for the same distro?
<fabbione> well the code doesn't say much..
<fabbione> that's why i was asking :)
<infinity> Heh.  Well, given that all my buildds are really slow single-CPU machines, the very idea of forking more instances is just plain wrong, so I've not examined that codepath.
<infinity> If it's sharing a chroot, though, that does seem broken, I agree.
<fabbione> buildd:# New config var $conf::secondary_daemon_threshold: If not at least that
<fabbione> buildd:         if ($total && $conf::secondary_daemon_threshold &&
<fabbione> buildd:                 $total < $conf::secondary_daemon_threshold) {
<fabbione> it seems only to add a log entry
<fabbione> there is no code basically
<fabbione> or i am misreading it
<fabbione> ahhhh
<fabbione> i get it
<fabbione> if that var is set
<fabbione> and you run a second instance of buildd
<fabbione> than it will fork
<fabbione> but it seems like it will share the same configs and chroots
<fabbione> it looks bad
<infinity> Hrm.  Yeah.
<infinity> I wonder who thought that was a good idea?
<infinity> You'd have sbuilds walking all over each other with package installations/removals...
<fabbione> probably sbuild has some kind of locking protection?
<fabbione> otherwise /var/sbuild/src-lock would have no meaning :)
<fabbione> or whatever is called
<fabbione> meh debbuild
<infinity> srcdep-lock?
<fabbione> sub check_srcdep_conflicts {
<fabbione> yeah
<fabbione> it's done at sbuild level the next check
<fabbione> yeah that one
<infinity> All srcdep-lock does, IIRC, is lock when sbuild is installing packages.
<infinity> It doesn't hold any locks during a build.
<fabbione> well i am not going to turn that on since the code isn't really clear
<infinity> Or, if it's meant to, that feature doesn't work. :)
<fabbione> hahha
<infinity> (Cause the lock dir is pretty much always empty..)
<fabbione> yeah i was checking right now
<infinity> I think the w-b suite is littered with unfinished features, so I wouldn't be surprised if this was another.
<fabbione> yeah i can see that
<infinity> Oh, great.  GRUB blew up the Windows boot sector, and it can't chainload Windows properly.  Yay, I lose!
* infinity tries to remember how to recover WinNT bootsectors without the WinNT install CD...
<fabbione> infinity: eh? you kidding....
<fabbione> it did never happen here
<infinity> Oh, I told it to eat the Windows boot sector.  But I didn't tell it to suck at loading Windows, that part it's done on its own.
<fabbione> infinity: have fun :)
<fabbione> i have no idea on how to recover a wincrap boot sec
<infinity> Well, usually, with the install CD.  Which I don't have a copy of here.
* infinity ponders.
<fabbione> switch the entire box to linux :)
<fabbione> and kill winnt
<fabbione> and i mean.. NT??
<fabbione> put her on XP at least
<daniels> infinity: fdisk /mbr?
<daniels> infinity: you trashed zofia's xp mbr, didn't you?
<infinity> fabbione : It is XP... Which is NT 5.1.
<infinity> daniels : Maybe.
<infinity> daniels : Downloading an install CD right now to fix it. :)
<svenl> doko_: you there ? 
<infinity> (fdisk /mbr is a DOS thing, and also would only work if I had a floppy drive)
<\sh> hmmm
<svenl> hi sh
<svenl> hi \sh 
<\sh> what is the replacement for xlibmesa-gl-dev
<svenl> even
<\sh> g'morning svenl  :)
<\sh> found it :)
<svenl> \sh: what was it ?
<daniels> \sh: xlibmesa-gl-dev is still xlibmesa-gl-dev
<svenl> daniels: don like to install on ppc though, since libglu are not in sync.
<\sh> daniels: i have here build-deps on libglu-dev-xorg (because of libstdc++) xlibmesa-* wasn't compiled against libstdc++6
<daniels> svenl: huh?
<daniels> \sh: xlibmesa-glu-dev wasn't built against libstdc++6; xlibmesa-gl-dev is not C++
<daniels> libglu1-xorg and libglu-dev-xorg were built against libstdc++6, unless there's been a terrible, terrible compiler mishap
<daniels> (on the buildds)
<svenl> daniels: well, my error, it needs :  xlibmesa-dev libglu-dev-xorg libglu1-xorg
<svenl> these are the ones, but they will uninstall half my system for now, including gdm and such stuff.
<svenl> well, half my system is exagerated.
<daniels> seems to work alright for me
<svenl> daniels: 2$ sudo apt-get install xlibmesa-dev libglu-dev-xorg libglu1-xorg
<svenl> Les paquets suivants seront ENLEVS:
<svenl>   freeglut3 gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools hwdb-client libgksu1.2-0 libgksuui1.0-0
<svenl>   libgle3 libglut3 python-opengl python2.4-opengl rss-glx xbase-clients xlibmesa-glu xlibmesa-glu-dev xprint xprint-common
<svenl>   xprt xscreensaver-gl
<\sh> daniels: right..but if xlibmesa-glu-dev is now libglu1-dev-xorg, is there also a name change in xlibmesa-gl?
<svenl> ENLEVE -> REMOVED, obviously.
<daniels> enlevs -> removed?
<daniels> right
<daniels> \sh: no.
<\sh> chaos ;)
<daniels> well, versioned provides just don't work
<daniels> so I want to avoid changing the package name unless I have to
<daniels> bbl
<daniels> dinnertime
<\sh> hmmm
<\sh> libglu-dev-xorg: Depends: libglu1-xorg (= 6.8.2-16), xlibmesa-gl-dev | libgl-dev, libstdc++5-3.3-dev | libstdc++-dev, libc6-dev | libc-dev
<svenl> \sh: welcome to breezy :)
<\sh> svenl: well...
<\sh> it doesn't have to do with breezy
<\sh> because
<\sh> libglu1-xorg: Depends: libc6 (>= 2.3.4-1), libgcc1 (>= 1:4.0.0-7), libstdc++6 (>= 4.0.0-7), libxext6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1
<\sh> ;)
<fabbione> so what is that for???????
<svenl> \sh: bah.
<\sh> fabbione: the dependencies for binary package and dev package are not fitting together :( and I need this stuff to fix a package here
<fabbione> \sh: well but that's for breezy or not?
<\sh> fabbione: yepp
<\sh> think i need a cup of coffee and a cigarette
<doko> morning all
<fabbione> hi doko
<doko> is daniels coming back?
<svenl> hi doko.
<fabbione> doko: he went for dinner.. so i guess yes
<svenl> doko: maybe.
<svenl> doko: what is the latest version of your biarch gcc .debs you have available ? 
<doko> svenl: the same as before, let jbailey sort it out this week, then it should be ready
<svenl> doko: i wanted to build it myself today.
<elmo> is it known locales' dep is SNAFU on amd64?
<svenl> oh well.
<fabbione> elmo: to what level of SNAFU?
<fabbione> because jb did relax the locales depends: 
<fabbione> to something like >= ${Source-Ver}
<elmo> uninstallable SNAFU
<fabbione> instead of =
<elmo> katie@jackass:~$ dpkg -I pool/main/g/glibc/locales_2.3.5-1ubuntu3_all.deb | grep Depends
<elmo>  Depends: glibc-2.3.5-0ubuntu1, debconf (>= 0.2.26)
<elmo> looks fairly = to me
<Kamion> I think that's meant to be provided by everything with the same locale API or similar
<Kamion> amd64 just hasn't built the new glibc yet
<Kamion> $ dpkg -f libc6_2.3.5-1ubuntu3_i386.deb Provides
<Kamion> glibc-2.3.5-0ubuntu1
<elmo> why do they have a virtual package whose version number is divorced from the source version number?  that's just whack
<elmo> the glibc build is just stalled on amd64
<Kamion> same idea as shlibdeps, just done with a virtual package because the package name is different on different architectures
<Kamion> well, not quite the same as shlibdeps
<elmo> root     31196  0.0  0.0   9132   696 ?        SN   May22   0:00      \_ /usr/bin/sudo perl -e kill( -15, 17624 )
<daniels> sudo perl -e kill?
<fabbione> omg
<\sh> argl
<\sh> daniels is working on the xorg stuff right?
<Riddell> \sh: kdebindings and base are in, we could probably try for pyqt pykde?
<\sh> Riddell: no
<\sh> the deps are not as they should
<Riddell> what's needed?
<\sh> xlibmesa-glu is replaced by libglu-xorg and libglu-dev-xorg...but the deps for libglu-dev-xorg are set against libstdc++5-3.3 and not like the bin package libglu1-xorg against libstdc++6-4.0
<doko> \sh: that shouldn't hurt, libstdc++-dev already is installed on the buildd's.
<\sh> doko: but not on my update ;)
<\sh> lunch
<doko> \sh, install build-essential first
<elmo> doko: what's the current state of play with the freeze?
<elmo> did lamont unfreeze c++ apps?
<doko> elmo: as I did write on IRC yesterday, lamont wasn't online yesterday
<elmo> meh
<elmo> can _I_ unfreeze them?
<doko> by unfreeze you mean, put the new cxxapps.txt in effect?
<doko> elmo: yes, if unfreeze is limited to c++ apps in main
<elmo> doko: cxxapps.txt still has main apps?
<doko> yes, those depending on mozilla-dev
<doko> hmm, yes, I can remove the KDE things as well
<doko> elmo: ok, done
<doko> and I removed aptitude from the cxxapps in universe, so mvo can play the apt upgrade game
<mvo> doko: aptitude is main 
<doko> mvo: even better
<doko> never used it ...
<Kamion> the installer kind of does ;)
<mvo> Kamion: is it only used for the installation of the tasks? or for more stuff?
<Kamion> mvo: for task installation, and for fallback if that fails
<mvo> thanks
<Riddell> so the build daemons are now going to go nuts?
<\sh> doko: it's installed :)
<\sh> so lunchtime is over :)
<doko> elmo: is the cxxapps.txt updated on the buildd's? if yes, I could at least upload all packages, for which we have ubuntuN versions
<elmo> doko: no, I want to talk to mdz about buildd stuff
<elmo> + first
<elmo> btw, you might as well upload apps, they just won't get built yet
<elmo> better to have them ready to build than not..
<doko_> hmm, daily disconnect ...
<doko_> elmo: ok, assume a upload a -buildN, which you then sync with a newer version. will the buildd build both versions, if both are available when the buildd restarts building the apps, or will it skip the older one?
<elmo> eh
<elmo> doko: for any given arch, only one version of a package is in a suite at any one time
<doko> elmo: do you sync with the new cxxapps.txt today? then I'll wait with the upload of the -buildN packages until after the sync
<elmo> what about cxxlibs? is that up-to-date?
<elmo> heh, that updated a whole 3 apps
<doko> elmo: cxxlibs updated. yes, we don't have that many C++ stuff in main, and most is modified anyway. which are the three apps?
<elmo> uh, dunno, check breezy-changes?
<elmo> doxygen, lftp and something
<doko> knew about doxygen, still waiting for the mails
<elmo> sorry, it got mixed in with a bunch of your uploads, and it's now hard for me to tell what's what
<doko> ok, uploading the buildN's as well, so one will get rejected
<elmo> that's fine
<elmo> how's the universe transition being handled, given the uploads are blocked on certain keys?
<elmo> oh, we're not anymore, nm me
<svenl> checking whether the C compiler works... configure: error: cannot run C compiled programs.
<svenl> Mmm, i guess something failed badly here :)
<doko> the universe part of cxxlibs.txt and cxxapps.txt shouldn't be synced, but libs should be built.
<doko> elmo, mvo: I made a mistake: uploaded synaptic, would probably be better, if this one does not enter the archive. sorry for that one
<svenl> doko: the above test, does it check that the result from the compilation run is actually runnable, right ?
<elmo> that's all right, the sync will overwrite it?
<svenl> doko: and this is the place where it fails on 3 bit ?
<svenl> 32bit even.
<doko> elmo, mvo: aptitude as well
<lamont> morning
<doko> hi lamont
<lamont> still need cxxapps unblocked on the buildds?
<doko> glibc did timeout in some network tests on amd64
<lamont> _again_.
* lamont whaps jbailey
<lamont> redland-bindings is ftbfs for me... no swig.  Wonder if that's everywhere...
<elmo> I already gave it back
<doko> lamont: yes, but I updated cxxlibs.txt and cxxapps.txt
<lamont> elmo: coolness
<elmo> lamont: but it had hung pretty spectacularly, the 'kill -TERM' invocation was hung too
<lamont> neato
<doko> elmo wanted to talk with mdz about the buildd's first
<elmo> no, that's fine, if lamont's here, go for it
<lamont> doko: so another round of 'replace the list we have with what's currently in cxxapps'?
<doko> lamont: yes please, basically remove all of main, keep all of universe. thom just told me that he's preparing a mozilla upload, so I remove the one's depending on that as well.
<doko> lamont: done
<lamont> chinstrap:~doko/cxxapps.txt, yes?
<doko> correct
<doko> lamont, fabbione: but keep the installed one on the sparc and hppa buildd
<doko> maybe not necessary for sparc, it's building binutils, glibc, gcc-* this week anyway ;)
<jbailey> lamont: Hey, not my fault the kernel hangs in the middle of a syscall. =(
<jbailey> lamont: I've gone over the test-ifaddrs code, as has vorlon - it's a quite simple bit of code.  Following it with strace, it goes in to ask a question and just never seems to come back.
<elmo> it seemed stuck in recvmsg, does that sound right?
<doko> lamont: perl on i386 did fail in network test ... interesting, dist-upgrade now wants to remove build-essential
<jbailey> When I traced it I think it was in getgid or something like that, but I don't have notes handy.
<elmo> ok
<jbailey> I'm surprised to see it triggered twice in a row on amd64, though.
<jbailey> Usually on Debian it would be months between uploads where it would die.
<lamont> doko: fixed perl
<lamont> doko: it kinda assumes that 'localhost' resolves, which isn't necessarily true, but we decided it should....
<lamont> and terranova was down when I upgraded all the chroots by copying in /etc/hosts....
<elmo> lamont: how's yellow been?
<jbailey> elmo: FWIW, I loosened the locales dependancy with this upload, so hopefully if there's glibc problems on an arch in the future it won't bring the whole thing to a grinding halt.
<doko> jbailey: finally ... :)
<elmo> jbailey: yay, thanks
<elmo> tho, to be honest, I don't mind grinding halt in ubuntu
<elmo> our glibc really shouldn't be out of sync
<elmo> at least for release arches
<jbailey> Right.  It's one of those changes that I hope I can convince gotom to pick up that he might not be willing to.
<doko> jbailey: so we won't have a chance to build the compilers, because one of the architectures will be broken at any time ;)
<lamont> elmo: seems to be doing OK
<elmo> lamont: ok
<lamont> doko: I'll have the changes made sometime in the next 20-40 minutes
<jbailey> doko: Nah, elmo said he doesn't mind breakage. =)
<jbailey> Anywho running off to spend the morning with my belle.
<doko> jbailey: well, it may be interesting for sparc and hppa 
<lamont> doko: ia64 is ready for this change too?
<doko> lamont: yes
<lamont> ok.  chroot-upgrade/buildd restart now in progress
<lamont> cc1: error: unrecognized command line option "-fwritable-strings"
<lamont> is there a comparable option in 4.0?
<doko> lamont: no
<lamont> unicode.c:19:26: error: linux/string.h: No such file or directory
<lamont> grumble
<lamont> cool.  dies on i386 too.  /me bugzillas
<Kamion> will take some porting if it expects writable strings, probably ...
<lamont> Kamion: yeah.
<lamont> the i386-too was hfsplus.  the writable strings is palo (which no one but hppa cares about)
<chmj> lamont: powerpc-given-back.gz what does that mean on the build logs ?
<lamont> it means that the buildd decided it shouldn't even try, and gave it back
<lamont> and inside the log should be an error that gives a hint...
<lamont> is the timestamp from somewhere around :03-08 or :33-38?
<doko> jbailey: groff: *** glibc detected *** double free or corruption (!prev): 0x0805a678 ***
<lamont> bad groff
<doko> tetex-bin is another xorg victim
<daniels> tetex?  people still use that crap?
<Kamion> "glibc detected"? wtf?
<Kamion> doko: I'll have a poke at groff
<doko> Kamion: thanks
<\sh> who uploaded sip4?
<Kamion> \sh: breezy-changes says doko
<\sh> yes saw it
<\sh> i'm wandering if the build-deps are correct against xfree
<\sh> and not against xorg
<doko> \sh: unmodified upload, probably needs to be corrected
<\sh> doko: ah ok :)
<lamont> Kamion: glibc (more specifically, malloc, et. al.) do corruption checking now.  most cool, except that it turns heisenbugs into hard failures.
<lamont> daniels: you don't even want to know how many packages (build-)?depend tetex-bin, directly or indirectly.
<daniels> lamont: heavy sarcasm detected
<lamont> it's kinda early on in the bootstrapping pain
<doko> lamont: fix uploaded
<doko> tetex-bin
<lamont> apt-cache showsrc gcc-4.0
<lamont> Build-Depends: ... tetex-bin ...
<doko> cursing the xorg reorganisation again
<lamont> daniels: so that'd be, um, everybody
<daniels> lamont: yeah :) 'twas joking
<lamont> heh
<Kamion> lamont: yeah, it was a double fclose() in grn - fixing
<Kamion> lamont: I misread "glibc detected <stuff>" as "I detected glibc"
<lamont> lol
<lamont> yoda it is not.
<doko> we're nearing the point where the number of needed xorg fixes exceeds the number of needed C++ fixes ;-)
* lamont ^5s doko
<daniels> yeah, and glibc's double-free stuff is fucking us, too :P
<daniels> exposing previously-unseen breakage
<lamont> daniels: nah - it's finding things.
<lamont> the X directory structure was only broken for you pedants.
<daniels> eh, it only worked by accident
<lamont> dude - that's all of X11 :) 
<lamont> I mean when the standard changes everytime some student at MIT sneezes and gets code all over the desk... :-)
<elmo> doko: dude, did you not fix bison?
<doko> ?
<elmo> I just created a breezy chroot and got file overwrite errors
<doko> looking at it
<daniels> lamont: r7 is all about fixing the 'by accident' bit
<lamont> daniels: so r7 is just continuing in the tradition of 'tightening the spec', like gcc-3.x and 4.x have?
<daniels> lamont: that's the one!
<lamont> ah, well then, it must be a good thing...
<daniels> indeed
<daniels> 'xorg, now with 97% more API reinterpretation!'
<daniels> the current 'spec' is largely defined by myself and ajax's definition of good taste
<lamont> as long as it's not being done by some 19 year old radical who's still wet behind the ears.....
<lamont> :-)
* lamont should stop trolling
<daniels> hey, the average age of us two is about 20.5
<daniels> that's old, right? :)
* lamont phears.
<lamont> daniels: add me in ad the average goes to 27.3
<lamont> s/ad/and/
<lamont> yesterday, my daughter reminded me of the apache vs evolution debate 
<daniels> apache vs evolution?
<lamont> yeah - "apache is so much cooler than evolution, you should use that instead."
<daniels> er
<lamont> it was something I threatened to troll #ubuntu with one day
<lamont> (commented in #u-devel, and still got a few takers...)
<daniels> haha, brilliant :)
<daniels> there's a comment to be made about age not having dulled your wit somewhere ;)
<lamont> the funnest part was the number of fully clueful people who got involved in the discussion just to keep it going.
* lamont can't remember what major deadline it was the stress-relief for.
<daniels> heh
<daniels> lamont: feb 10th, so must've been hoary
<daniels> 20:45  * lamont considers draging the "which is better, evolution or apache" debate over to this channel, decides not.
<lamont> was it that recent?
<doko> lamont: how do you like your vacations?
<lamont> doko: lengthy :-)
* lamont is working today, vacation the rest of the wekek
<lamont> Feb 10 10:49:58 <lamont_r> maybe I should start a thread on users on why evolution is better than apache
<lamont> in another chanel
<lamont> s/another/a different/
<daniels> lamont: ahr
<daniels> except the debate in there wasn't exactly long or interesting :P
<doko> lamont: could you remove the dep-wait for xerces2[56] 
<lamont> daniels: no, but it does give the context for the idea....
<lamont> doko: sure
<daniels> lamont: right
<doko> nice, tetex-bin on ia64
<doko> {standard input}: Assembler messages:
<doko> {standard input}:15316: Error: Use of p0 is not valid in this context
<doko> make[4] : *** [writet1.o]  Error 1
<daniels> doko: there you go, now you have something to bitch about other than xorg :P
<fabbione> ahha
<fabbione> ./Redland_wrap.c:13:20: error: Python.h: No such file or directory
<fabbione> neat!
<fabbione> only 200K of error from a missing include :)
<doko> buy a bigger disk :P
<fabbione> that was not the point :)
<fabbione> Alloc PE / Size       123655 / 483.03 GB
<fabbione> Free  PE / Size       33712 / 131.69 GB
<fabbione> i have enough space :)
<fabbione> at least failed for everybody :)
<Kamion> elmo: please sync groff 1.18.1.1-8 from incoming, should fix that build failure
<elmo> Kamion: done
<Kamion> ta
<\sh> fabbione: send me some GB ;)
<doko> elmo: please could update the halley/breezy chroot and install tetex-bin's build deps?
<fabbione> elmo: mind to upgrade breezy and breezy-i386 on concordia and breezy on davis with the new dpkg? (it has been unbanned/built)
<elmo> doko: done
<fabbione> elmo: well if you can do halley too it would be lovely :)
<fabbione> otherwise i will start bouncing ia64 to somebody else... and have an excuse for that :P
<elmo> halley's just been done
<fabbione> cool
<elmo> concordia/native done
<fabbione> thanks
<elmo> concordia/386 done
<fabbione> rocking!
<doko> gv is another xorg victim, fixing ...
<doko> elmo: please could you install g++-3.4 on halley:breezy?
<fabbione> dpkg-architecture: warning: Unknown gcc system type amd64-linux, falling back to default (native compilation)
<fabbione> this is on concordia breezy chroot...
<doko> fabbione: yes filed a dpkg bug
<fabbione> elmo: while at it, can you also install linux-source-2.6.12 build-deps + xmlto ?
<fabbione> (halley/breezy chroot)
<fabbione> doko: it's only amd64 fucked?
<doko> yes
<fabbione> ok
<fabbione> it's only a warning tho
<elmo> fabbione: done
<fabbione> elmo: thanks you rock!
* fabbione puts a pic on elmo in his album of Gods
<fabbione> elmo: can you also do breezy on davis please? i think it's the last one missing
<elmo> fabbione: done
<fabbione> elmo: cheers :)
<doko> halley:
<doko> doko@halley:~$ w
<doko>  17:53:16 up 9 days,  7:52,  2 users,  load average: 6.17, 5.34, 3.72
<doko> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
<doko> doko     pts/0    82.211.81.135    17:05    0.00s  0.02s  0.01s w
<doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048040
<doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048060
<doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048040
<doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048060
* daniels giggles.
<doko> elmo: please could you install g++-3.4 on halley:breezy?
<elmo> doko: done
<doko> thanks
<lamont> daniels: workrave needs your love
<daniels> lamont: file a bug, I'm going to sleep after I upload all this shit
<lamont> right
<lamont> daniels: 11117 assigned to you
<daniels> let's see how xorg -17 ftbfses
<lamont> -17 is uploaded?
<daniels> in the process of doing so
<lamont> daniels: in /etc/sbuild.conf, do these need to change, too???
<lamont>         "xlibs-dev"             => [qw(/usr/X11R6/lib/libX11.a /usr/X11R6/lib/libX11.so /usr/X11R6/lib/libICE.a /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libXp.a /usr/X11R6/lib/libXp.so)] 
<lamont>         "libgl-dev"                     => "xlibmesa-gl-dev",
<daniels> just uploaded all the fun build-deps
<lamont> :-)
<daniels> lamont: aieeeeeee
<elmo> doko: btw, given we're sticking with linux-gnu, we should probably make binutils and gcc match?
<lamont> rather, what do they need to change to?
<elmo> lamont: trash them all
<lamont> woot
<elmo> that's useless these days
<daniels> lamont: libX11.* -> libx11-dev, libICE.* -> libice-dev, libXp -> libxp-dev (which is being removed anyway)
<lamont> well, they're completely gone, now. :0)(
<doko> elmo: yes, I just want Keybuk change _GNU_TYPE to i486-linux-gnu first
<daniels> word
<doko> elmo: should ask jbailey and fabbione first, if that would cause problems with glibc and the kernel
<elmo> yeah, makes sense
<cartman> aspell-en should depend on libaspell15c2
<fabbione> i have no problems on whatever convention you want to use
<cartman> this prevents aspell from upgrading
<fabbione> just tell me your decision so that i can upload a fixed kernel-package
<doko> cartman: ok, taking care of it
<cartman> doko: thank you
<cartman> daniels: ping?
<daniels> cartman: pong
<cartman> daniels: xbase-clients still depends on xlibmesa-glu in case you missed it
<daniels> i certainly didn't miss it
<cartman> daniels: cool ok :)
<daniels> the good news: i know what the problem is
<daniels> the bad news: i might have to wait until libglu1-xorg -17 enters the archive, then upload -18, before it's fixed
<cartman> daniels: alright as far as you are aware, its ok
<doko> daniels: could you put -18 on chinstrap, so somebody else can upload it, while you're sleeping?
<daniels> doko: no
<daniels> i've just uploaded -18 *now*, but that won't fix it (see #u-d)
<daniels> if it's that desperately important that you need to upload your own -19, you can do that
<daniels> but my next upload won't be for about aonther day or so
<daniels> when I remove more modules, fix the keyboard and configuration bugs, and yeah
<doko> daniels: is a simple re-upload supposed to fix the xbase-clients dependency on xlibmesa-glu?
<doko> doko@concordia:~ $ w
<doko>  18:48:22 up 9 days,  9:11,  3 users,  load average: 108.56, 108.98, 100.87
<doko> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
<doko> fabbione pts/0    82.211.81.135    17:24   20:52  21.45s  0.00s /bin/sh /usr/bin/dpkg-buildpackag 
<doko> fabbione pts/2    82.211.81.135    17:24   20:50  12.69s  0.00s /bin/sh /usr/bin/dpkg-buildpackag 
<fabbione> doko: yeah.. 
<fabbione> it's faster with -j100 :)
<fabbione> doko: concordia can easily take up to -j500
<doko> it's nice, if it's 2% faster for you, but for me, it's 500% slower :-(
<fabbione> doko: it's almost finished :)
<fabbione> and it's not just 2% faster :)
<fabbione> it's like a lot faster
<fabbione> elmo: please upgrade condordia to a 128 CPU's and 64Tera of RAM
<doko> :)
<doko> we buy low profile racks only ...
<cartman> humpf
<cartman> apt still not compiled against gcc4
<elmo> WTF?!
<elmo> why is db1-compat back? :P
<elmo> err, and why is none of the X stuff turning up
<doko> NEW?
<elmo> hmm, some of the binaries, are still in queue/accepted, maybe that's it
<elmo> but seriously, did someone restore the db1-compat dpeends on purpose?
<elmo> oh, linux-gnu breakage, meh
<fabbione> i remember Kamion mumbling about it
<daniels> doko: xbase-clients MUST be built with libglu1-xorg >= 6.8.2-18 for the deps to be fixed
<daniels> else it's a waste of an upload
<doko> daniels: ok, will look at it tonight. are you still awake?
<fabbione> doko: a -j50 has basically done...
<fabbione> the other has almost finished
<daniels> doko: can't sleep
<doko> ;)
<fabbione> daniels: what will happen to arches that will not build -18 right away? can they still catch up building xorg -19 ?
<daniels> fabbione: sure, but xbase-clients will still be uninstallable
<fabbione> daniels: who cares :)
<doko> fabbione: maybe you as well, because kdelibs4c2 depends on it :-(
<cartman> kdebase should too
<Kamion> fabbione: I did?
<Kamion> fabbione: I'm entirely happy for libdb1-compat to go away - it was always intended to, post-sarge
<elmo> well, it's back, I suspect it only disappeared Thanks To Keybuk(tm)
<elmo> we show need "keybuk broke my dpkg-architecture" t-shirts
<elmo> s/how/so/
<daniels> can someone please explain to me in very small terms why kdelibs4c2 depends on xbase-clients?
<daniels> terms, words, whatever
<elmo> daniels: autoconf
<elmo> hmm, no, that's xutils
<elmo> I give up
<elmo> daniels: I bet it probably does path checkes for something in xbase-clients
<elmo> I ungive up
<daniels> if that's all it is, I'm going to fucking smash KDE
<elmo> daniels: I think you need some sleep dude
<elmo> whee, anastacia's gone INSANE
<daniels> elmo: yeah, I think I do too, but it's not working out
<elmo> please demote parted, K THANKS BYE
<Kamion> eh?
<elmo> Kamion: check out /home/katie/scratch/x
<elmo> as I said.. INSANe
<elmo> I think I managed to catch it while base was regenerating or something
<fabbione> doko: i didn't build kde stuff yet
<fabbione> Kamion: i think so... i didn't pay particular attention to it
<daniels> kdelibs probably runs glxgears to benchmark it or something
<lamont> ../boost/boost/config/compiler/gcc.hpp:81:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results"
<lamont> heheh
<lamont> aqsis wants some porter-love
<daniels> 'UNDER FIVE BAJILLION FPS, TOO SLOW, TRY A BETTER CARD YOU FRIGGIN' WEENIE'
<daniels> (seriously, xbase-clients stuff requires a connection to an X server, so it can't be *using* it)
<lamont> doko: would it be too much to ask for a list of all cxx{libs,apps} and the first version that is transitioned?
<doko> > ----------------------------------------------------------------------
<doko> > mrvn@mips:~$ amor
<doko> > _KDE_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
<doko> > sh: line 1: iceauth: command not found
<doko> > ICE Connection rejected!
<doko> > ----------------------------------------------------------------------
<doko> > 
<doko> > Iceauth is contained in xbase-clients.
<lamont> that'll help us make sure we have stuff built eventually
<doko> This is almost certainly a general DCOP requirement, not a specific amor
<doko> requirement (certainly the iceauth call doesn't show up anywhere in the
<doko> kdetoys source tree).  I'm reassigning to kdelibs-bin accordingly.
<doko> for the list of libs, see the wiki
<lamont> doko: and that has the version that was uploaded with the change?
<doko> I don't have one for the apps
<doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
<daniels> OH MY GOD IT'S WORSE THAN I THOUGHT
<lamont> cool
<doko> lamont: yes
<lamont> doko: it better not use that during the build...
* fabbione fixes yet another dpkg-arch screwage
<lamont> (ice)
<daniels> agh, thpethul ... thpethul!!!!
<daniels> they include a complete copy of iceauth.c, and build it into libkICE
<daniels> as well as including several other X source files
<daniels> they then completely ignore that, and call the iceauth binary anyway
* daniels stabs his eyes out.
<elmo> yeah, I still can't see why they're b-d-ing on it
<cartman> uhm libICE is dcop only
<elmo> it might actually be easier to test-compile it on concordia
<fabbione> because it's 31337
<elmo> hmm, or nto
<daniels> elmo: not a b-d, only a depends for kdelibs4c2
<daniels> i.e. kdelibs4c2 -> uninstallable
<daniels> the solution here is to fix this fucking schitzrophrenia properly
<elmo> daniels: OH
<daniels> schitzophrenia, even
* fabbione goes back to the movie
<daniels> i'm going to try this whole sleep thing again
<doko> daniels: I'm confused about gstreamer-plugins ... http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.8-3ubuntu2/gst-plugins0.8_0.8.8-3ubuntu2_20050523-1816-i386-failed.gz
<lamont> micropolygon.cpp:41: error: declaration of 'Aqsis::CqMemoryPool<Aqsis::CqMicroPolygon, 512l> Aqsis::CqPoolable<Aqsis::CqMicroPolygon, 512l>::m_thePool' outside of class is not definition
<lamont> micropolygon.cpp:42: error: declaration of 'Aqsis::CqMemoryPool<Aqsis::CqMovingMicroPolygonKey, 512l> Aqsis::CqPoolable<Aqsis::CqMovingMicroPolygonKey, 512l>::m_thePool' outside of class is not definition
<lamont> feh
<lamont> sigh...  that's an motu thing... sorry
<cartman> doko: ping ?
<cartman> doko: new aspell-en still depends on libaspell15 and not libaspell15c2
<cartman> before ping timeouts ;)
<cartman> uhm same for aspell-bin
<doko> which version?
<cartman> one second
<cartman> aspell-en                       6.0-0-3build1
<doko> dpkg -l aspell-bin
<cartman> aspell-bin                      0.60.2+20050121-2ubuntu2
<doko> ubuntu4 is the current
<cartman> maybe fails on amd64 hmm
<cartman> its not under http://people.ubuntu.com/~lamont/buildLogs/a/ or I am blind?
<doko> http://people.ubuntu.com/~lamont/buildLogs/a/aspell/0.60.2+20050121-2ubuntu4/
<cartman> huh thats weird
<doko> no
<cartman> its been kept back
<cartman> ok manual install worked
<cartman> only problem is aspell-en
<lamont> doko: if you do another gcc-3.4 upload, could you do the expect 8.3 hack for hppa there too?
<doko> did it work for 4.0?
<lamont> dunno... it's waiting for 3.4 to finally finish.. :-)
<lamont> Running /build/buildd/gcc-3.4-3.4.4/src/libjava/testsuite/libjava.compile/compile.exp ...
<lamont> and if java segv's, I'm gonna be annoyed'
<doko> lamont: could you me a favour an poke Gannef on #debian-release, so you need it? it's stuck in the new queue (expect-tcl8.3)
<lamont> who's Gannfe?
<doko> Joerg Jaspert, ftp-admin
<lamont> doko: quite possible I only need it on 2.6 kernels --> ubuntu, but will go poke
<doko> thanks
<lamont> the request was really breezy driven
<mvo> lamont: the new apt has finished building. should I upload aptitude now with a versionsied build-dependency? or will the new version now automatically pulled in as a build-depends?
<mvo> I want to upload aptitude now
<elmo> mvo: the former
<elmo> you should always update build-depend appropriately and not assume/hope the latest version will be used
<mvo> ok
<lamont> elmo++
<doko> elmq
<lamont> what happened to elmp?
<doko> hmm, elmp
<doko> ;)
<doko> lamont: does xorg build or is it waiting?
<lamont> it's ftbts
<lamont> ftbfs, even
<lamont> because of xorg headers.  ROCK
<lamont> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
<lamont> ConnDis.c:39:23: error: X11/Xdmcp.h: No such file or directory
<doko> ok, preparing an uplaod ...
<lamont> gcc -c -fsigned-char : now that's just _SICK_
#ubuntu-toolchain 2005-05-31
<doko> hmm, libxau-dev and libxdmcp-dev are in the archives. strange, that they cannot be found ...
<doko> lamont: ^^^
<lamont> missing buildd-deps, I bet
<lamont> actually libxdmcp-dev is installed
<lamont> no -I/usr/X11R6/include though...
<lamont> gcc -c -fsigned-char    -I../.. -I../../exports/include   -Dlinux -D__powerpc__
<lamont> +-D_POSIX_C_SOURCE=199309L                              -D_POSIX_SOURCE
<lamont> +-D_XOPEN_SOURCE                                -D_BSD_SOURCE -D_SVID_SOURCE
<lamont> +-D_GNU_SOURCE                            -DFUNCPROTO=15 -DNARROWPROTO
<lamont> +-DXTHREADS  -D_REENTRANT -DXUSE_MTSAFE_API    -DMALLOC_0_RETURNS_NULL
<lamont> +-DHAS_SNPRINTF -DLIBX11                        -DPOSTLOCALELIBDIR=\"lib\"
<lamont> +-g -O2 -fno-strict-aliasing -g   -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT
<lamont> +-DHAS_FCHOWN -DIPv6   -DX11_t -DTRANS_CLIENT -DFAIL_HARD   ConnDis.c -o
<lamont> +unshared/ConnDis.o
<lamont> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
* lamont wonders if maybe they used to come from ../../exports/include
<doko> yes, maybe ...
<lamont> gst-plugins0.8 is ftbfs on ppc, btw
<doko> wuhuhuhu
<doko> lamont: lying, take a penalty card
<lamont> on which?
<doko> http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.8-3ubuntu3/gst-plugins0.8_0.8.8-3ubuntu3_20050523-2138-powerpc-successful.gz
<lamont> ah, was ubuntu2 that I looked at.   my bad
<lamont> I am taking a penalty card
<doko> talking ;)
<doko> BOOTSTRAPCFLAGS=-I/usr/include/X11
<doko> hmm, but that isn't on the command line either
<doko> elmo: libestools1.2 (speech-tools) needs new/main love
<elmo> doko: no, it needs to build
<elmo> come on dude, these are things you can check yourself
<doko> ok, time to go to bed ...
<doko> libao is a *_GNU_TYPE victim ...
* lamont gets dragged off
<doko> please try to get pike7.6 and then swig1.3 in.
<daniels> huh
<daniels> so, for what it's worth, -I/usr/X11R6/include won't gain you a thing
<daniels> ah, pkg-config and x11proto-core-dev
<daniels> yeah, I remembered pkg-config while I was half-asleep, decided it wasn't worth getting back up for
<doko> heh, and the package is native
<daniels> b-d-i vs b-d?
<daniels> ahr, stupid libGLw
<doko> you did have Build-Depends-Indep, which is wrong, you build for architecture any, not all
<daniels> yeah
<doko> would you mind writing down an email, what kind of things changed, which build-deps are likely to be replaced?
<daniels> hm?  it's only for two packages that I fucked up on
<doko> no, in general: xinerama-dev needs to be added, xlibmesa-glu-dev -> libglu-dev-xorg, and so on ...
<daniels> uhm, the xinerama-dev thing has been taken care of long ago, when we broke out xlibs-static-dev before hoary
<daniels> the only thing I've changed recently in terms of build-deps is xlibmesa-glu-dev -> libglu-dev-xorg
<doko> and libxau-dev was needed for libao ..., and a replacement for xlibmesa-dev, and probably unknown things. *please* write it down, not every MOTU knows about it
<daniels> um, again, this has been around since before hoary
<daniels> and there's no direct mapping
<daniels> there's just 'if it uses this, then it needs this, et al'
<doko> yes, *just*. please document it.
<doko> good night
<fabbione> morning
<lamont> morning fabbione 
<fabbione> doko: gcc-3.3 did built fine :)
<fabbione> 3.4 starting now
* lamont sleeps
<daniels> elmo: when you wake up, could I please have all of xorg's build-deps (in the newest versions) in concordia's chroot?
<fabbione> hey daniels 
<fabbione> daniels: how difficult it is to switch a crappy Makefile to automake?
<daniels> fabbione: not too hard ... program or library?
<fabbione> a mix
<fabbione> there is a bit of everything :)
<daniels> shouldn't be too hard
<daniels> heh
<daniels> what is it?
<fabbione> red hat cluster suite
<daniels> ah
<daniels> just look at the packaging in xorg/lib/Xau
<fabbione> their makefile system is totally retarded
<daniels> and add bin_PROGRAMS = foo, foo_SOURCES = bar.c baz.c
<fabbione> meh dude... i add that to what?
<fabbione> i know >< this much about autocrap
<fabbione> i guess i will need to learn it
<daniels> add that to Makefile.am
<fabbione> i am still puzzled by all the crap :)
* infinity was considering diving into autotools this week too..
<infinity> But then I thought better of it.
<fabbione> infinity: let's switch the kernel to autotools :)
<infinity> NOOOOOOO!
<doko> morning
<fabbione> hey doko
<doko> NOOOOOOOOOOOOOOOOOOOOOO
<fabbione> ?
<doko> Package: x11proto-gl-dev
<doko> Conflicts: xlibmesa-gl-dev (<< 6.8.2-19), xlibmesa-glu-dev (<< 6.8.2-19), libglu-dev-xorg (<< 6.8.2-19)
<doko> we did just change dozens of packages, now again?
<fabbione> doko: and you will keep changing them until the transition is completed
<doko> no, I don't change them anymore, he can do it himself, 
<doko> and he doesn't want to document/tell the needed changes
<daniels> sigh
<daniels> i'm trying not to cause another ftbfs by waiting and testing
<daniels> i can dump yet another version into the archive and see how that turns out, but I'd rather not
<daniels> no-one needs to change anything
<daniels> libglu-dev-xorg in -19 depends on x11proto-gl-dev
<daniels> it's just an internal reorganisation
<doko> I'll only believe it, when I see it. does -19 fix xbase-clients?
<daniels> http://people.ubuntu.com/~daniels/xlibs-static-dev.txt
<daniels> and no, it won't, as I explained to you before
<daniels> one version needs to get built and accepted, and then the next one will fix xbase-clients
<daniels> doko: -19 source is uploading to chinstrap now, if you want to upload it then do that, but for the love of god test it in an up-to-date chroot first
<daniels> i can't because my mirrors' mid-pulse, and I'm stuck in the middle of main -- can't debootstrap
<daniels> i'm leaving soon and will be out for a few hours
<doko> ok, I'll ask elmo for build-deps on concordia, if that builds ok, then I'll upload it. can I start the build with -jN ?
<daniels> don't
<daniels> falls over badly when you try to parallelise it
<doko> ok
<fabbione> is anybody using concordia?
<fabbione> or can i spin its load up?
<doko> fabbione: no, please don't, trying to build xorg, when it's uploaded and build-deps are installed
<fabbione> doko: sure.. no problem
<doko> daniels: you have to fix xorg, to compete with fabbione for CPU time ;-)
<fabbione> doko: tsk :)
<fabbione> don't make me run -j400
<fabbione> doko: btw.. 80% of my load is disk I/O bounded
<fabbione> it's not all real CPU
<fabbione> i have ccache configured on concordia
<fabbione> doko: but you are not even logged in on concordia!
<fabbione> oh great
<fabbione> FUCK
<doko> ?
<doko> _when_ it's uploaded
<fabbione> i hate DPATCH
<fabbione> 1.2 is FTBFS
<fabbione> FUCKING HELL
<fabbione> elmo: can you please install a sane version of vim in halley/breezy chroot? kthxbye
<elmo> fabbione: done
<fabbione> elmo: thanks mucho
<doko> elmo: please could you install xorg deps on concordia/breezy?
<fabbione> elmo: don't :) i am building the kernel :P
* doko slaps fabbione ;)
<elmo> fabbione: err, too late, sorry
<elmo> (sorry, I really did start, like 20 mins ago)
<elmo> I should have realised that's why it was going so slowly
<fabbione> ahha :)
<fabbione> don't worry... i can stop if you need speed
<elmo> nah, it's cool, as long as it doesn't break your build
<fabbione> it shouldn't
<fabbione> just don't switch compiler version :)
<fabbione> that's enough
<elmo> doko/daniels: done
<doko> elmo: please could you move libestools1.2 to main
<elmo> doko: done, 30 mins ago
<doko> thanks
<doko> fabbione, daniels: xorg -19 did cleanly build on amd64. I'm uploading the sources now
<fabbione> doko: hold on
<fabbione> did you change anything in the MANIFEST ?
<fabbione> doko: or can i see the diff please?
<doko> nothing, see /home/daniels on chinstrap
<fabbione> doko: ok... seems alright....
<mvo> it looks like the code in AM_GNU_GETTEXT is no longer working with 64bit/gcc-4.0. this caused aptitude to fail
<mvo> has anyone seen that before?
<mvo> ^--- doko
<doko> no
<doko> hmm, that should be fixed upstream?
<mvo> yes
<mvo> I'll have a look
<jbailey> mvo: I've seen it with g++, I think.
<mvo> the bad code is:
<mvo> return (int) gettext ("") + _nl_msg_cat_cntr + *_nl_domain_bindings
<mvo> conftest.cc:100: error: cast from 'char*' to 'int' loses precision
<mvo> and it comes from gettext.m4
<mvo> its just a matter to change it into long
<jbailey> Yup, that's the beast.
<jbailey> You need to run the gettext -f command or some such like that.
<mvo> -f ?
<jbailey> For some reason autoreconf -f -i didn't seem to be enough, I think because it calls autopoint rather than gettext (which seems a bit uselesS)
<jbailey> force it to overwrite anything it had there before?
<mvo> ok
<jbailey> If that doesn't work, ping me.  My brain is split a few other ways atm so I can't check it out.
<jbailey> mvo: You will need to do an autoreconf after, though, to make sure that configure picks up the changes.
<mvo> yes, I think it will work fine
<\sh> mvo: which package was it, where u had this error?
<mvo> \sh: aptitude, it was fixed by using the latest gettext.m4 from the gettext package
<fabbione> jbailey: impressive.. benc is on irc :)
<jbailey> Wow.
<jbailey> Should we pounce and scare him away? =)
<\sh> mvo: was it something like this? check the last output of the build logs (http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/d/dar/2.2.1-1ubuntu1/dar_2.2.1-1ubuntu1_20050524-1145-ia64-failed.gz)
<jbailey> Last I heard from benc on IRC, he was doing fiarly well in a poker tournament.
<fabbione> jbailey: i am already working on it.. but he has 23 hours of idle
<jbailey> He's apparently not that far of a drive from here.
<fabbione> jbailey: what are you waiting to knock on his door?
<jbailey> But I think the border guards might question me having a body bound and gagged in the trunk to bring home with me.
<jbailey> Nothing.  I've long ago accepted that I will get nothing useful out of him.
<lamont> jbailey: that's why it's _very_important_ that he be quiet
<fabbione> ehehhe
<mvo> \sh: let me check
<lamont> and covered with coffee grounds, to confuse the dogs.
<jbailey> Better that than poppy seeds...
<lamont> heh
* lamont figures border guarddogs are trained to alert on coffee as well...
<jbailey> I'll do it at the Vancouver crossing.
<jbailey> Between Vcr and Seattle, the guards would go nuts if they looked at coffee.
<jbailey> The hard part is getting the trunk full of grinds up to body temperature so that he doesn't show up on a thermograph/
<mvo> \sh: yep, just copy the gettext.m4 from /usr/share/aclocal/gettext.m4 to m4/ and call autoreconf (seems to work for me at least)
<jbailey> mvo: That will probably work.  I usually prefer to update all of gettext so that at least I'm in a somewhat supported config.
<mvo> is there a wiki page about common problems with g++-4.0 and how to fix them? could be interessting for the MOTUs to share experience
<mvo> jbailey: runining "gettexize -f" ?
<mvo> jbailey: runining "gettexize -f -c"
<mvo> ?
<jbailey> ADd -c
<lamont> Group.cpp: In member function 'std::string libfwbuilder::Group::_ZTv0_n16_NK12libfwbuilder5Group11getTypeNameEv() const':
<lamont> Group.cpp:55: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
<lamont> Please submit a full bug report,
<\sh> mvo: ah .. u r my rescue :)
<lamont> woot.  same as arts
<\sh> mvo: i will try this workaround
<mvo> \sh: jbailey advice is probably better, use "gettextize -f -c; autoreconf" instead of just copying the gettext.m4 file
<jbailey> lamont: Still on hppa?
<mvo> \sh: you can check the result by searching in the generated configure file. what should happen is: "return (int)gettext(""); " -> "return * gettext("")" 
<lamont> jbailey: yes
<lamont> it would appear that we have two instances of the same ICE
<lamont> couple more, and we can make a drink. :=)
<jbailey> lamont: Do you have time to reduce it to a testcase?  Sounds like it might be time to punt it to upstream bugzilla.
<lamont> I'll make time in the next day or two
<jbailey> I'm trying to remember is hppa-hpux is a secondary platform.
<\sh> well
<\sh> mvo: first of all I get this after autoreconf: 
<\sh> configure.ac:17: error: possibly undefined macro: AC_PROG_LIBTOOL
<\sh> autoreconf: /usr/bin/autoconf failed with exit status: 1
<\sh> apt-get install autobook for more brain autotools magic
<mvo> \sh: dar?
<jbailey> \sh: apt-get install libtool? 
<doko> mvo: not explicitely, only references to the upstream release notes. Feel free to start one ;-)
<\sh> mvo: yepp
<\sh> jbailey: hmm...strange..
<mvo> doko: http://www.ubuntulinux.org/wiki/GCC4CommonProblems
<\sh> hmmm
<doko> mvo: ok, we need to link it ...
<\sh> gettextize -f -c is asking me to hit return ;)
<\sh> i should go home
<lamont> \sh: that'd be bad for the autobuilder. :-(
<doko> daily aspell orgy ...
<mvo> doko: updated and linked
<doko> mvo: thanks!
<\sh> lamont: yeah
<\sh> mvo: did u see the same behaviour?
<\sh> i have to check again
<mvo> \sh: about the return thing? yes. that's ok. just follow the instructions there and press ok. it needs to be done only once (and not on the buildd)
<\sh> mvo: so on the buildd this behaviour won't happen?
<mvo> \sh no
<\sh> good :)
<mvo> \sh: :) the really interessting bit is "aclocal -I m4; autoconf"
<mvo> \sh: feel free to add you experience to the wiki page!
<jbailey> mvo: I think that's usually set through ACLOCAL_FLAGS or some such.
<jbailey> Upstream shouldn't trust that the user remembers to add -I m4 when running autoreconf.
<mvo> jbailey: ok, thanks
<\sh> mvo: autoreconf should call them all
<\sh> hmmm...
<\sh> i need a faster package mirror
<\sh> de.archive.u.c is not fast enough with syncing ;)
<elmo> use de.archive.u.uc as a fall back
<jbailey> \sh: autoreconf seems to call autopoint now, which is a bit on the useless side.
<\sh> jbailey: soi u mean calling aclocal and friends "by hand" is better then to call autoreconf?
<jbailey> No, autoreconf is always the right thing.
<jbailey> Just that in this case getting the gettext stuff updated seems a bit broken.
<jbailey> Probably because of the risk of screwing up C apis or something.
<doko> elmo: please could you install mysql-dfsg build-deps on halley/breezy?
<elmo> doko: done
<doko> thanks
<daniels> just uploaded xorg -20 and I'm going to bed
<daniels> this means it's sure to FTBFS
<lamont> daniels: lol
<doko> xorg built while daniels was sleeping ;)
<lamont> IDLAny.cc:372: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
<lamont> that's 3.  I guess I'd best start working on that testcase soon...
<jbailey> lamont: Three instances at least makes it sound like it shouldn't be that hard to reduce.
<lamont> jbailey: exactly
<lamont> #3 was libfwbuilder
<doko> Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/hoary/Release  Unable to find expected entry  main/binary-hppa/Packages in Meta-index file (malformed Release file?)
<doko> Reading package lists... Done
<doko> lamont: ^^^
<lamont> yeah. no hoary/hppa
<lamont> hoary/hppa is at http://people.ubuntu.com/~lamont/ubuntu-hppa/tree iirc
<doko> ok, ok, now to the breezy side of life ...
<lamont> that's at ports.ubuntu.com/ubuntu-ports where it belongs
<lamont> and is slowly populating
<lamont> 37 packages queued up to sneak through the upload-straw
<fabbione> bag
<fabbione> bah
<fabbione> i just trashed the gcc-3.4 build 3/4 of the way
<fabbione> suckage
<fabbione> doko: is it safe to start the build again with ./debian/rules build ?
<fabbione> it was running the testsuite when i did stop it
<doko> fabbione: yes, if stamps/*build-stamp exists. do you want to restart the check?
<fabbione> doko: i basically did a killall make :)
<fabbione> i didn't touch the source or the build dir
<fabbione> so i am just re-running ./debian/rules build
<doko> if you do not want to have tstresults, run WITHOUT_CHECK=yes debian/rules binary-arch
<lamont> May 24 13:34:08 buildd-uploader: Setting to Uploaded(breezy): eel2 
<lamont> progress!
<lamont> fabbione: you aren't planning to upload that abused child, are you?
<lamont> evil evil man. :-)
<fabbione> lamont: i plan to do a debdiff before uploading :)
<lamont> hehe
<fabbione> 3 minutes to the meeting
<jbailey> Thanks for the reminder. =)
<jbailey> Hmm.  This is just the maintainer candidates review, right?
<doko> it was an "urgent" meeting ...
<jbailey> Oh?  Hmm.
<doko> fabbione, lamont: please add speech-tools, festival and firefox to the list of libraries to build first (sparc and hppa)
<fabbione> firefox?
<fabbione> i only have mozilla-firefox banned as application
<lamont> doko: actually the state of both architectures is that it's banned all cxxapps building... the rest just build as they come
* fabbione restarts gcc-3.4 build
<fabbione> i didn't like some scary messages while building the debs :)
<doko> which ones?
<fabbione> doko: nothing to be worried about.. it was the interrupted build
<jbailey> Doh.
<jbailey> Helps if I remember that it's a c++ compiler.
<jbailey> doko: Should be an easy fix for mysql.  Removing variable called 'new' from asm-ia64/atomic.h =)
<doko> heh, fine
* lamont wonders if anyone in particular has been babysitting the cxxlibs builds to get them fixed for xorg/dpkg pain
<doko> hey man, doing that for the last 5 days ...
<jbailey> lamont: I see that there's a parisc CVS update for the kernel.  Is there a ChangeLog maintained for those patches?  It would be nice to know when it's time to see if some glibc stuf is happier.
<doko> jabiley: ask on parisc-linux.org
<jbailey> doko: They're now on oftc, but yeah.
<fabbione> doko: now i am 100% sure... gcc on sparc is more strict than on other arches
<fabbione> and this sucks
<fabbione> big times
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/g/gstreamer0.8/0.8.10-0ubuntu1/
<fabbione> cothreads.c: In function 'cothread_switch':
<fabbione> cothreads.c:654: error: invalid lvalue in assignment
<fabbione> make[5] : *** [libcothreads_la-cothreads.lo]  Error 1
<fabbione> on sparc is FTBFS
<fabbione> and that error is usually a macro on lvalu
<fabbione> lvalue
<doko> that's 3.4?
<lamont> fabbione: nah - it's that strict on others too
<fabbione> that's 4.0
<lamont> I have lots of those
<fabbione> i have seen a few..
<fabbione> but why?
<fabbione> given that is the same gcc and same code
<lamont> because gcc-4.0 doesn't let you cast lvalues randomly
<Kamion> that line of code is #ifndef HAVE_MAKECONTEXT
<fabbione> hmmm
<Kamion> I'm guessing sparc doesn't have that
<Kamion> (or else the test is wrong)
<lamont> doko: figured you were.  was wondering if it was helpful for me to announce them as I trip over them, or if you're already just doing it and it's only channel-noise
<fabbione>     GST_ARCH_SETUP_STACK ((char *) cothread->sp);
<jbailey> daniels: Hmm, the default path is now to /usr/bin/X11, but xbase-clients seems to still have things in /usr/X11R6/bin on ppc. =)
<fabbione> that's what gcc doesn't like :/
* fabbione hits seb128 with a sparc64 bat
<jbailey> fabbione: Oo, did I miss something good? =)
<jbailey> Oh, I see.  This is gstreamer.
<fabbione> jbailey: it's all l-k-h fault!
<fabbione>  i know that!
<fabbione> you are hiding it very well :P
<jbailey> fabbione: I try. =)
* jbailey waits for :03 to watch the lkh upload.
<fabbione> it's already :04 :)
<jbailey> Hmm.  /me reruns ntpdate.
<jbailey> Wow, 49 seconds off.
<jbailey> Off an uptime of 3 days. =(
<fabbione> Kamion: wow.. you did really a lot of magic in debootstrap :)
<fabbione> Kamion: but really.. don't get too crazy about sparc, even if i really appreciate the extra work
<Kamion> fabbione: that wasn't extra work
<Kamion> fabbione: that was automatic :-)
<fabbione> ahhhh
<fabbione> ehheh
* Kamion hugs ./breezy-update
<fabbione> i guess breezy will be a porting hell if Debian doesn't switch to gcc-4 soon
<jbailey> Or if they change the transition plan somehow.
* fabbione ponders the idea of making only sparc server
<fabbione> jbailey: can they? ;)
<fabbione> let see...
<fabbione> Kamion for sure will not vote for a different plan...
<jbailey> fabbione: Depends if the release manager and ftp master decide that they hate Ubuntu that day... =)
<fabbione> i know vorlon's wife.. that's like having vorlon's testicle in my hand
<Kamion> it's been run past -release, no objections
<doko> heh, the plan was discussed on -release ...
<fabbione> jvw owns me a few tons of beer
<fabbione> we can buy elmo
<fabbione> do we need anybody else? :)
<jbailey> Just doko, I guess. =)
* fabbione makes doko an offer he can't refuse
<jbailey> I wonder how many packages in Debian will silently grow -#ubuntu# versions as lazy maintainers just upload the Ubuntu version. =)
<doko> we should switch to HEAD in unstable, it can compile KDE ;-)
<fabbione> jbailey: almost nobody..
<doko> heh, pike7.6 was'nt prepared for an "ubuntu" in the release part of the version
<fabbione> i am pretty sure they are too proud of their pure versions
<doko> hmm, but xorg are the same packages, aren't they?
<fabbione> nope
<fabbione> not that i know off at least
<fabbione> had 0 time to look at xorg in debian
<doko> oh no ...
<Kamion> they're pretty similar
<Kamion> they've been merging changes back and forward AFAIK?
<fabbione> Kamion: yes
<fabbione> but they are not the same
<Kamion> and I was under the impression that they more or less imported Ubuntu packaging
<Kamion> I think doko meant "same structure"
<jbailey> fabbione: I thought of doing it with cdbs. =)
<fabbione> Branden is correctly over paranoid about maintainer scripts and code cleanup
<doko> gcc-4.0 (4.0.0-8) experimental; urgency=low
<doko>   * Synchronize with Ubuntu.
<fabbione> Kamion: we are going modular... so there will be not much to share and i doubt daniels and Overfiend will agree on the same way of splitting or pkg names
<doko> Kamion: same "-dev" packages would be very nice
<fabbione> doko: well that's because you upload both of them? :P
<fabbione> doko: i will try to play some mind jedi tricks to make that happen
<fabbione> but i am not sure i can manage
<fabbione> the 3 sides of the Force are all really strong
<doko> yup
<fabbione> Kamion: let's take over ubuntu and make it only a minimal server install! at least i will manage breezy with sparc :P
<Kamion> fabbione: gravity seems to be the guy actually doing most of the xorg work in Debian?
<doko> jbailey, the arch you wanted fix lkh for, did FTBFS
<fabbione> Kamion: probably... i didn't even have the time to check out the tree
<fabbione> i planned some debian work during the next weekend :)
<fabbione> wife is away with scouts :)
<jbailey> doko: And how do you manage to see these so quickly after they happen? =)
<doko> well, I'm looking when I can safely upload next packages or poke lamont retrying some others, the read noise just hurd^Dts ;)
<doko> Kamion: you did have a page with the status of installable/not installable packages. where?
<Kamion> doko: http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html
<doko> thanks
<doko> oops, the list got longer ...
<lamont> Kamion: would it be terribly painful to do another such report containing the scc architectures?
<Kamion> lamont: it's on my list :-)
<lamont> or maybe one-per report - hppa will look really ugly for a while.. :-)
<lamont> ENOGLIBC
<Kamion> need to knock something up on rookery
<lamont> Kamion: why is xorg 6.8.2-10 being used?  -20 should be in the archive...
<lamont> firecall
<doko> lamont: plese retry swig1.3 when the fire is out
<Kamion> lamont: being used for what?
<Kamion> lamont: oh, stale binaries I imagine
<doko> hmm, that's just KDE
<Kamion> those are the latest versions of xlibmesa-glu-{dbg,dev} in breezy
* fabbione heads to bed
<fabbione> good night
<jbailey> g'n Fabio
#ubuntu-toolchain 2005-06-01
<jbailey> doko: Sent off another lkh, should fix both mysql and libgii
<doko> so libgii was a lkh thing?
<jbailey> yeah, the upstream included a define that only exists in 2.4 kernels and earlier.
<jbailey> Given that the case is a noop, I'm surprised to see it in mysql, but ah well.  It's not supposed to be in the 2.6 header.
<lamont> doko: done
<lamont> Kamion: yeah - in the report, they show up... I think those particular ones probably want to get removed from the archive
<doko> lamont: yes, too early, the 2nd pike upload didn't build yet
<doko> enchant did build, so abiword can be retried
<lamont> kicked
<lamont> doko: you are waiting for the cron.daily run after the builds finish before saying anything, yes?
<doko> hmm, I don't do idle waiting ... so from time to time I refresh your web page. that's ok
<lamont> gii now d-w lkh
<lamont> jbailey: thanks
<lamont> was it mysql-dfsg, or the universe package?
<doko> the former
<lamont> only have a failure log on ia64 - d-w'd
<doko> yes, the other archs did succeed
<lamont> kewl.
<lamont> anything else before I run off again for a while?
<jbailey> Not from me, I think.
<lamont> back in 2-3 or so then
<lamont> closer to 2 than 3, I think
<doko> Kamion: could you check out, why unixodbc's build-deps cannot be fulfilled on powerpc?
<Kamion> doko: it's hard for me to check anything in breezy on my own system because of that bash bug :P
<doko> ouch!
<Kamion> but http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html agrees
<doko> yes, first thing I do tomorrow morning
<Kamion> thanks :)
<Kamion> it looks like gnome-libs is out of sync on powerpc
<doko> yes, I read this list, but even the build logs aren't very helpful
<Kamion> libgnome32 |   1.4.2-19 |        breezy | powerpc
<Kamion> libgnome32 |   1.4.2-20 |        breezy | amd64, hppa, i386, ia64, sparc
<Kamion> and gnome-libs FTBFS/powerpc
<Kamion> looks like a missing imlib include?
<doko> worse: libpng error: Call to NULL read function
<doko> hmm, libpng was the cause for xorg build failures on powerpc as well
<jbailey> daniels: Hmm, on the upgrade to the latest X bits, dexconf or whatever it's called now doesn't appear to write the mouse stuff to the xorg.conf file.
<doko> jbailey, libgii and mysql-dfsg did fail
<jbailey> chroots weren't updated with the new lkh
<doko> lamont: after libpng did build and install on powerpc, please build gnome-libs on powerpc
<lamont> ../sigcperl/convert.h:71: error: explicit qualification in declaration of `std::string SigCPerl::get_string(SV*)'
<lamont> bad sigcperl
<lamont> ../include/linux/i2o-dev.h:51: error: variable or field '__user' declared void
<lamont> bad raidutils
<lamont> ../llapi/vector2d.h:120: error: 'cerr' was not declared in this scope
<lamont> bad panorama
<lamont> pension board meeting - back in about an hour
<daniels> jbailey: yeah, the mouse stuff is screwed
<daniels> jbailey: that's -21 material
<doko> daniels: congrats! -20 did build on all archs ;-)
<daniels> fabbione: eh, branden isn't doing any of the xorg work
<daniels> fabbione: gravity and I are doing xorg monolithic stuff ... he's so far caught one mistake and done a bit of syncing from Debian
<daniels> fabbione: joshtriplett and I are working on the modular tree and we're hoping to have the same packages
<daniels> doko: yeah, I noticed ... finally
<zul> gday
<doko> and xbase-clients seems to be built correctly
<doko> daniels: could you have a look at xscreensaver? the changes were necessary when I built the package, but they do fail on the buildd.
<daniels> ok
<jbailey> daniels: That and the path being not where startx is located now. =)
<daniels> jbailey: serves you right for not having /usr/X11R6/bin in your path :P
<daniels> i think i'm just going to dump everything in /usr/bin with the next upload
<daniels> being that /usr/bin/X11 is a REALLY BAD IDEA
<jbailey> I thought the plan was to move everything to /usr/bin ages ago.
<daniels> right, but moving it within the monolith is PAIN
<daniels> so I'm just making all the new modules use it
<daniels> i'm seriously considering moving everything and xbase-clients and xutils with dh_install though
<Kamion> doesn't that break some third-party code using imake?
<Kamion> (due to stuff not being in ProjectRoot where they expect it)
<daniels> that's the tricky part I have to work out
<jbailey> Hmm, libgii seems to be an X casualty this time.
<daniels> \o/
<daniels> does it need to build soon?
<daniels> if it doesn't need to build in the next few days, just wait for it to start building again
<jbailey> It's an rdepends for anything libggi based that needs to make the g++ transition.
<jbailey> I don't know how importnat that makes it.
<daniels> main or universe?
<jbailey> main
<daniels> hum
<jbailey> Given that I'm heading to bed soon, I don't actually care that much for any value that you might consider to mean "today"
<daniels> heh :)
<jbailey> doko punted it to me since the first failure was a linux-kernel-headers one, lamont punted it back when it failed to build the package right because of a missing binary.
<daniels> heh :)
<lamont> was someone fixing gstreamer0.8?  fabbione ?
<jbailey> It wasn't punted to me.
* lamont just remembers someone muttering about it several hours ago...
<lamont> cothreads.c:654: error: invalid lvalue in assignment
<lamont> was sparc ftbfs, iirc... --> fabbione 
<fabbione> daniels: xorg -20 is FTBFS on sparc
<fabbione> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
<fabbione> around 1.5MB in the build log
<daniels> uhm, sure you've got libxau-dev installed?
<daniels> because that should be in /usr/include/X11/Xauth.h
<daniels> (and a recent libxau-dev?  doko uploaded a fixed -2)
<fabbione> checking...
<fabbione> well libxau-dev should be a build-dep
<daniels> it is
<fabbione> Unpacking libxau-dev (from .../libxau-dev_6.8.2-16_sparc.deb) ...
<daniels> that's why it worked on amd64/i386/powerpc
<daniels> hmmmm.  if it doesn't work with that, I guess I'll have to tighten the build-dep. :\
<fabbione> i think it needs the new splitted one, doesn't it?
<daniels> in the meantime, build libxau 1:0.1.2-2 and make sure that gets used
<fabbione> yeah ok
<daniels> yeah, so I'll tighten it up for -21
<fabbione> but please tight the dependencies for the next upload
<daniels> will do
<fabbione> it's not too much of a problem for me
<fabbione> but a new breezy re-build-strap would fail
<fabbione> doko: please pull http://people.ubuntu.com/~fabbione/binary-gcc.mk into gcc-3.4 debian/rules.d/
<fabbione> it fixes biarch install (dh_link) target
<fabbione> there are a couple of \ missing ;)
* netjoined: irc.freenode.net -> clarke.freenode.net
<fabbione> does anybody mind if i spin up concordia a bit?
* fabbione spins it
<doko> good morning
<\sh> hey doko
<ajmitch> hi doko 
<jbailey> daniels: When I added /usr/X11R6/bin back to my path, it seems that /usr/X11R6/lib/X11/xinit/xserverrc referes to a non-existant /usr/bin/X11/X
<daniels> jbailey: ROCK
<Kamion> killing /usr/bin/X11/ this way seems pretty painful, considering that it seems that current Debian policy was written with an eye to *using* /usr/bin/X11/ as part of the migration path away from /usr/X11R6/ ...
* jbailey still wishes everything we in /opt/PACKAGE/{bin,lib} and stow'd or path'd into place.  But ah well.
<fabbione> Kamion: that part of the policy was written by Branden iirc and he said: "If you kill *X11* we will change policy.. i wrote it :D"
<Kamion> yeah, I know Branden wrote it, but using /usr/bin/X11/ to help the transition rather than hindered it seemed like a design feature to me at the time
<Kamion> and still does, fwiw
<Kamion> s/hindered/hinder/
<jbailey> Well, policy is a reflection of current best practice.  If X changes what it does, by definition best practice has changed.
<Kamion> I was kind of hoping that eventually we'd have /usr/bin/X11 -> /usr/bin
<Kamion> so as not to screw over people with hardcoded paths in local config
<Kamion> or, y'know, things like ssh
<Kamion> which hardcodes /usr/bin/X11/xauth because that was the path that was supposed to keep working
<fabbione> Kamion: yup... make sense
<daniels> eh, /usr/bin/X11 isn't going away
<daniels> the plan is to move everything to /usr/bin and make /usr/bin/X11 a symlink to /usr/bin
<daniels> but there are only so many hours in my day, y'know?
<Kamion> oh, ok, that's exactly the opposite impression to the one I'd got
<daniels> dude, I don't hate /usr/bin/X11 any more than I hate /usr/X11R6
<Kamion> you told me in #1685 that /usr/bin/X11/xauth was bad
<daniels> i told you in #1685 that a hardcoded path in general was probably bad, yes
<daniels> i have no intention of killing it off completely
<Kamion> ah
<daniels> i just don't want to put binaries in there
<Kamion> I hadn't realised that, ok
<daniels> bbiab
* desrt gives daniels a big hug
<doko> lamont: 4.0 did sucessfully build on hppa/unstable
<lamont> doko: which kernel?
<lamont> or do you mean on the buildd?
<doko> Linux pampa 2.6.8.1-pa11 #1 SMP Fri Sep 10 10:40:02 MDT 2004 parisc64 GNU/Linux
<doko> no, my machine
<lamont> wow.  that's with the test suite off?  because 2.6.8.1 has lots of issues with the test suite... 
<doko> no, on
<lamont> hrm.. maybe it was everything else that it had issues with...
<doko> I'll restart it on breezy
* lamont just did a massive give-back & dep-wait flush on breezy *4, btw
<lamont> and off to run to town. sigh
<doko> wait, kdelibs for i386?
<doko> lamont: ^^^
<lamont> daniels needs to upload -21 and quit claiming to build xlibmesa-gl*-dev, then they'll not be in the archive, and kdelibs will build
<lamont> alternatively, reversing the order of the build-deps will fix it, but they need to be in the other order for debian...
<doko> hmm, talking with riddell
<Riddell> what's up?
<doko> lamont: no, kdelibs doesn't deal with xlibmesa-gl*-dev, the last qt upload did fix that, and kdelibs should be retried
<daniels> lamont: ?!?!??!?!?!??!
<daniels> lamont: nothing ever happened to xlibmesa-gl-dev
* daniels looks at debian/control, sees nothing about xlibmesa-glu-dev than Conflicts/Replaces/Provides from libglu-dev-xorg, goes to bed.
<daniels> lamont: by the way, I could stop building xlibmesa-gl-dev, but seriously it wouldn't do you any good
<jbailey> daniels: Another upload then sleep? =)
<daniels> no.  just sleep.
<\sh> xorg is against gcc4 now? doesn't look like
<jbailey> fabbione: You there?
<fabbione> jbailey: i am very close to go and cook dinner...
<fabbione> i am hungry to deaht
<fabbione> death
<jbailey> fabbione: No worries.  Just I did some research on Xen this morning.  I can babble about it another time.
<fabbione> jbailey: ok.. btw i solved a big problem with latency
<fabbione> for some reasons my eth0 on the gw was like adding 800ms to the next eth hop :)
<fabbione> ifdown / ifup solved :))
<jbailey> Err. duplexing?
<fabbione> nope
<fabbione> it started all of a sudden
<fabbione> it's connected to a proper swtich
<fabbione> 100Mb FD
<fabbione> it's the first time it does something like that
<fabbione> anyway dinner...
<jbailey> enjoy!
<fabbione> i will pass by later
<fabbione> so you can tell me about xen
<fabbione> thanks
<jbailey> 20 packets transmitted, 15 received, 25% packet loss, time 19189ms
<jbailey> rtt min/avg/max/mdev = 754.573/1149.822/1433.117/166.396 ms, pipe 2
<fabbione> doko: btw.. did you pull in the fix for gcc-3.4?
<jbailey> That's to your router for me. =)
<fabbione> jbailey: can you check where you actually lose packets?
<fabbione> mrt/traceroute...
<jbailey> Weird, I dind't have traceroute installed.
<doko> fabbione: no, jbailey will do the next 3.4 upload
<jbailey> fabbione: In which case, the dh_link \'s are already in my tree. =)
<fabbione> doko: ok
<fabbione> jbailey: thanks :)
* fabbione goes in the kitchen
<fabbione> doko: btw.. it did build fine this time :)
<fabbione> no probs with livtest
<doko> heh, nice
<fabbione> jbailey: so.. want to tell me that stuff about xen?
<jbailey> fabbione: It appears that Xen may run under NPTL these days, but really suckily.
<jbailey> I haven't got an answer yet on my questions, but there's a patch to glibc that should be it generally be better.
<fabbione> jbailey: ah ok.. right now i am slightly more worried of xen not even being able to mount my root partition :)
<fabbione> i need to do another test next weekend
<fabbione> got 2.0.6 ready on my server
<fabbione> with 2.4.30
<fabbione> (can't run 2.6 there yet)
<jbailey> fabbione: Right.  I've been hesitant about Xen if we'd wind up having to drop support for it.
<fabbione> jbailey: i know smurfix and Mith are looking at other options too
<fabbione> like L4+afterburner
<fabbione> that appears to be much more portable and way less intrusive than xen
<jbailey> Hah, it would be funny if L4 were useful in the Linux world.
<fabbione> jbailey: well they run linux at the moment
<fabbione> on top of debian
<fabbione> that's their devel platform
<jbailey> Oh?  Interesting.
<fabbione> that's also why Benno was at UdU
<jbailey> I only know L4 from my Hurd exposure.
<fabbione> Mith and I were at the University there to see a demo
<jbailey> Hmm, wish I had knowm about it
<fabbione> and it was afterburner + xen/l4
<fabbione> it was nice.. 
<jbailey> Ah well. =)
<fabbione> i mean.. it worked :)
<fabbione> but after that they disappeared
<fabbione> the userland wasn't ready yet
<fabbione> so that's probably why
<jbailey> 'l4 afterburner' is apparently not a useful thing to google for.
<fabbione> jbailey: afterburner is not very well known at the moment
<fabbione> the code has been kept private for a while
<fabbione> but they were sorting the last license bits to go public
<jbailey> Can you tell me where I could look to find info on it?
<fabbione> Mith has all the URL's
<fabbione> i don't have them handy.. sorry
<jbailey> Tx, I'll poke him later.
<jbailey> It's not critical, I was just looking at the Breezy tasks this morning and figured I'd look into the glibc on Xen issues a bit.
<fabbione> yeah but i suggest to wait to push patches around
<fabbione> specially if we are not sure we can commit to support it
<jbailey> Well, my i386 asm isn't good enough to understand the implications of the patch.
<jbailey> So I would need help anyway.
<fabbione> ehhe neither is mine
<jbailey> hey doko.. =)
<doko> hi
<jbailey> Sprechen ze i386-asm? =)
<\sh> s/ze/Sie/
<\sh> ;)
<jbailey> \sh: Thanks.  My german is limited to asking if something is vegan.  Ordering by number off a menu.  Asking for Redwine or apple juice.  Looking at someone pleadingly and saying "Haut ban hof?" and telling them that I just shit my pants.
<\sh> hahaha :)
<\sh> jbailey: but in the deepest german slang you say: Sprechen'se <insert your fav language here>
<\sh> jbailey: so u were very close to become an originating NRW inhabitant :)
<doko> jbailey, no assembler ...
<\sh> lda $0a
<\sh> sta $d020
<\sh> the last bit of assembler i remember ;)
<doko> fabbione, lamont: is 3.4.4 built on hppa and sparc?
<desrt> doko; with a few hickups, it looks like linux-2.6.12-rc5 is buildable with my gcc-4 cross-compiler
<jbailey> Wow, I didn't know the kernel was gcc-4 safe.
<desrt> jbailey: only very recently
<desrt> and not entirely... some drivers are still broken
<doko> desrt: nice
<desrt> the ubuntu kernel config is the ideal stress-test platform :)
<jbailey> I can't see Fabio diving at the chance to run an experimental kernel in breezy.
<desrt> 2.6.12 should be soon
<lamont> doko: 3.4.4 of what?
<lamont>  gcc-3.4_3.4.4-0ubuntu3 fails on hppa
<doko> ahh, ok
<lamont>  ../include/linux/byteorder/swab.h:131: error: parse error before '__fswab16'
<lamont> is that a lkh thing, I wonder???
<lamont> configure: Using /var/lib/gstreamer/0.8 as registry cache dir
<lamont> configure: WARNING: Sissy ! By asking to not build the tests known to fail, you hereby waive your right to customer support.  If you do not agree with this EULA, please press Ctrl-C before the next line is printed.  By allowing the next line to be printed, you expressly acknowledge your acceptance of this EULA.
<lamont> checking for valgrind > 2.1... checking for sigaction... yes
* lamont laughs
<lamont> bad gstreamer0.8
<lamont> doko: actually, gcc-{3.3,3.4,4.0} are all ftbfs in their last hppa attempt
<lamont> (all retrying now, just for giggles)
<lamont> anyway, off again for a while
<jbailey> lamont: Possibly.  Why are they using linux/byteorder instead of the glibc functions for that?
<jbailey> byteswap.h is a far better choice, I think.
<lamont> dunno... palo_1.8 on hppa, fwiw
* lamont must leave. supposed to be 5 min away 2 min ago.
<lamont> one more massive giveback executed
<jbailey> I'll take a look at palo in my chroot on bdale's machine.
<jbailey> Might submit a patch for palo isntead, though.
<lamont> kewlness
<lamont> that'd be fine
<lamont> (remember it was written by a kernel hacker.... so the line may be a bit more blurred than it should...)
* lamont flees
<desrt> desrt@gorecki:~$ uname -a; cat /etc/issue
<desrt> Linux gorecki.cas.mcmaster.ca 2.6.12-rc5 #1 SMP Wed May 25 17:34:15 EDT 2005 ppc64 GNU/Linux
<desrt> Ubuntu 5.10 "Breezy Badger" Development Branch \n \l
<doko> heh ;)
<desrt> there's this file in /proc that when you write to it it causes a kernel oops... other than that everything seems ok
<desrt> (/etc/init.d/networking writes to this file)
#ubuntu-toolchain 2005-06-02
<lamont> aftermppm
<lamont> afternoon, even
<lamont> jbailey: <bame> lamont: bunch 'o files copied long ago from the kernel tree -- i hated doing that but there wasn't a good alternative at the time
<lamont> so I think that means there's a patch to palo in the future...
* lamont mutters curses at doko's uploads
<doko> ?
<doko> lamont: you must be more specific, I can't remember all uploads anymore ;)
<lamont> heh
<lamont> hppa built a b0gus libgnomedb, which is not installable.
<lamont> testing the 'force a rebuild' change to verify that it is a sufficient fix.
<lamont> (it depends: libgda2-1 instead of -3...)
<lamont> but that was a seb128 upload, not yours
<lamont> it's from the "versioned build-deps are too much of an annoyance to bother with" camp.
<doko> yes, I'm from the "upload many some will get through" camp
* lamont uploads libgnomedb
<lamont> *grumble*
<jbailey> lamont: 'kay.  You have a working palo you can use in the meantime?
<lamont> jbailey: hoary's works.
<lamont> so it blocks debootstrappable breezy, but then, so do gcc-4.0 et al.
<jbailey> debootstrap installs a bootloader? =(
<lamont> hrm... no
<lamont> nm
<jbailey> Ah, good.
<jbailey> So we get to worry about that when we're far enough along to think about d-i.
<lamont> exactly
<lamont> and switching it to build with gcc-3.3 is always a workaround. :-)
<lamont> possibly even a working one
<ajmitch> doko: g++-4.0 upgrade from -7ubuntu6 to -7ubuntu7 seems to have broken compilation of socketapi, at least :) my c++ skills aren't what they should be to fix it.
<jbailey> ajmitch: Pasting error message, good.
<ajmitch> jbailey: error message requires some source as context
<jbailey> Really?  sometimes it's obivous by the error message.
<ajmitch> sctpassociation.h:429: error: expected `)' before '*' token
<ajmitch> sctpassociation.h:439: error: ISO C++ forbids declaration of 'SCTPSocket' with no type
<ajmitch> sctpassociation.h:439: error: expected ';' before '*' token
<ajmitch> that requires a bit of context, i think :)
<jbailey> Can you feed the g++ through with gcc -E -dD and find the lines that fail and paste them?
* ajmitch can give it a go..
<desrt> elmo; mwah.
<lamont> dh_strip -pgcj-3.4 -plibgcj5-dev
<lamont> doko: does that mean it's gonna build"?
<jbailey> lamont: That sounds good.  What's different?
<lamont> liberal use of 'killall -9 expect' every time the kernel dropped a signal. :=)
* daniels stares at lamont.
<lamont> mind you, that has the effect of killing more than just the parent that will never know it's child died...
<lamont> daniels: stop staring.  STFU
<jbailey> lamont: LOL
<lamont> we just need to get doko to quit writing tests that stress the kerrnel bugs... 
<lamont> that or fix the kernel bug
<jbailey> lamont: My mother was reading one of my programming books when I was still living at home about the importance of killing your children when you were done with them.
<jbailey> lamont: She said she approved of my choice of reading material.
<desrt> jbailey; reaping, you mean :)
<jbailey> desrt: I think this was a GUI programming book.
<desrt> ah
<desrt> i'm suprised schools haven't banned the learning of C/unix programming due to the obvious violent/suggestive undertones
<lamont> dpkg-genchanges!
<lamont> now if i could just get logwatch.sh to actually _exit_ by itself
<lamont> Built successfully
<lamont> Purging chroot-breezy/build/buildd/gcc-3.4-3.4.4
* lamont thinks there should be "" around that successfully. :-(
<infinity> lamont : logwatch still doesn't exit on its own?... I meant to fix that bug ages ago.
<lamont> infinity: there's an hppa issue with child reaping in the signal case...
<lamont> that is, there's a signal bug.. it screws up a few things...
<infinity> And fixing the kernel bug is too much to ask? :)
<jbailey> infinity: You have spare cycles, don't you?
<infinity> jbailey : Personally, or hardware-wise?
<infinity> I don't think /I/ have much for spare brain cycles, but I have some machines with spare cycles.
<jbailey> infinity: persnoally. =)
<lamont> infinity: it's on my list...
<lamont> to bed soonish
<jbailey> lamont: And you've got glibc in there now as well, right?
<lamont> pool/main/g/glibc/libc6_2.3.5-1ubuntu3_hppa.deb
<jbailey> Cool.  I might see if I can get generic function descriptors working next to fix those testcases, but I'll probably focus on breaking sparc.  Fabio's given the okay for dropping classic sparc.
* lamont cries for his sparc boxen
<jbailey> lamont: Cry in sadness?
<jbailey> Do you still need classic sparc supported?
* lamont has an ss5 and an ss20, both classic.  both turned off.
<lamont> given that we don't currently even have a 32-bit kernel, it's not like losing glibc makes a big difference...
<jbailey> Do you have a real objection to stacking them with the i386 boxes? =)
<infinity> Classic sparc was so slow, it drove me to work on m68k cause I craved a modern and speedy architecture.
<lamont> jbailey: feh.  I'll ebay 'em if they're totally dead.  Otherwise they can be my native debian test boxes... :-)
<lamont> g'night
<fabbione> morning
<fabbione> night lamont
<jbailey> fabbione: We were just talkimg about Sparc. =)
<jbailey> Anyhow, you sohwing up means bedtime for me. =)
<jbailey> g'n!
<fabbione> ehhe
<fabbione> good night jb :)
<infinity> That's a clever avoidance technique.
<infinity> "I, uhh, shouldn't stay awake past when you get up... Yeah, that's it!"
<fabbione> yay
<fabbione> gcc-4.0 did build fine too :)
<fabbione> doko, jbailey: when can i expect a ppc64 toolchain available?
<fabbione> possibly updated and installed in a breezy-ppc64 chroot?
<doko> good morning
<doko> daniels: with which upload will the headers move to /usr/include/X11?
<daniels> doko: as I've explained before, as each module moves out
<daniels> there will be no one upload
<doko> so when will xinerama be available in /usr/include/X11
<daniels> doko: when I modularise libxinerama
<doko> daniels: looks like I'm pestering? ;-) just want to know, when it will be in the archives
<daniels> dude, I really don't know
<daniels> i'll let you know when it is, though
<\sh> doko: thx for the helping hand in uploading :)
<\sh> but where is licoin20c102 in the coin2 package? 
<chmj> ermm 
<chmj> you stole that for me :P 
<\sh> chmj: what? ;)
<\sh> there was no name on the list ;) and there is no libcoin20c102 in the debian/control :(
<Kamion> er ... libcoin20 is in coin, libcoin40 is in coin2
<\sh> why is doko wrinting something like this in coin2?
<\sh> anyway..enough work todo
<chmj> libcoin40 replaces libcoin20 ;-) 
<\sh> then can be...but then I don't understand his remark: http://bugzilla.ubuntu.com/show_bug.cgi?id=11007
<\sh> s/then/that/
<chmj> doko, ping ?
<doko> hmm, I'll have a look, was late yesterday ;)
<\sh> doko: but u rock like a hurricane :)
<chmj> heh 
<\sh> Extra for doko, I will disturb our holy free day with
* \sh is playing "Rock you like a Hurricane" by Scorpions on The Essential
<jbailey> fabbione: Are you in a rush for ppc64 stuff?
<fabbione> jbailey: we need to get ppc64 kernels out as soon as we can.. if we can
<fabbione> the changes are quite a lot to test
<fabbione> so it's not exactly an easy path to follow
<jbailey> fabbione: Ah, okay.  I know that svenl wants them fairly soon too.  I'll do another round on gcc-3.4 today then.  Last I left it, it was building the compiler fine, but not giving me the lib64gcc_s.so library.
<fabbione> ehehe
<doko> jbailey: not the package, or the library?
<jbailey> doko: Both, so I'm guessing I was overenthusiastic in disabling things.
<jbailey> doko: Rather than env variables and hacking rules.defs, it would be nice if the end of the file contained a "-include debian/rules.override" which allowed me to set the languages and such definitively if the file exists.
<doko> WITHOUT_LANG=ada,java dpkg-buildpackage works
<jbailey> That still causes libffi,fortran and g++ to be built.
<jbailey> For the initial tests I had been avoiding those.
<jbailey> I've also been using WITHOUT_CHECK until it builds all the pieces.
<jbailey> I can never remember if zul was they gatekeeper or the keymaster.
<jbailey> -y
<zul> gatekeeper
<jbailey> Cool. =)
<jbailey> Bah, forgot pascal in the languages to skip
<zul> heh...i never did pascal :)
<doko> jbailey: WITHOUT_LANG=ada,java,c++,objc,f77,treelang dpkg-buildpackage
<jbailey> Ah, didn't you?  It think it was my 3rd language.  basic then z80 assembler first.
<doko> it's f77, I'll add ffi
<jbailey> debuild -e WITHOUT_LANG=ada,java,c++,f77,treelang,pascal,objc -e WITHOUT_CHECK=y
<jbailey> is what I was about to use.
* lamont ponders where pascal landed in his list
<lamont> basic, 6502, z80, hp21mx asm, hpl (hp9825), spl (hp3000), hp3000 asm, cobol (gak), pascal, modcal, hppa asm, C, hp41 ucode
<lamont> I think I didn't forget any before pascal. :-)
<doko> lamont: there's not much after pascal :p
<lamont> doko: I was getting old at that point. :-)
<jbailey> basic, z80, pascal, i386 (*cRy*), telix scripting, C, javascript, c++, php, python, Java (including all the fluffy languages)
<lamont> somewhere in there (around kobol timeframe) is DEAL (which looks like algol with fortran printing)
<jbailey> YOU MEAN IT'S ALL CAPS AND WHITESPACE SENSITIVE? =)
* lamont skipped all the interpreted langs besides basic...
<lamont> jbailey: I only learned it well enough to translate an app or 3 from DEAL to COBOL. :-(
<jbailey> lamont: Javascript is the only one of those that I haven't compiled to native code at some point.
* lamont hated being a cobol whore.
* lamont goes to play with fire at the power plant
<lamont> really
<jbailey> lamont: Or to some sort of bytecode, I guess (for python)
<jbailey> telix's SALT language was terribly cool.  Packet switched networks are lovely when you're still covered by the young offenders act.
<doko> basic pascal modula-2 C Opal Haskell Prolog Modula-3 Tcl Perl Eiffel Sather Python Lua, yes I'm supposed to do the C++ and Java stuff ...
<doko> ok, working around the xorg reorg, building OOo
<infinity> jbailey : I used telemaet and TMscript, but SALT was fun too...
<Kamion> hmm, BASIC z80-asm x86-asm Pascal C Java ML Prolog arm-asm Perl C++ Python, I think
<doko> nice, finally someone for assigning the C++ bugs to ;-)
<Kamion> sod off :-)
<jbailey> What' Kamion said
<jbailey> (I can't pull it off why my accent)
<Kamion> I never used the C++ standard library much
<jbailey> Eww.  You're one of *those* C++ coders. =)
<Kamion> we had our own standard library, when I was doing C++ seriously - when the project in question started, the C++ standard library was barely standard and certainly not portable
<Kamion> and it was so much more comprehensible than libstdc++, anyway. :)
<jbailey> I tried desperately to add Scheme to my list for almost a year before deciding that the pain just wasn't worth it.
<doko> lamont: please yould you trow all the gnome stuff at the buildd's again, once libenchant1c2 is in main?
<doko> yesterday I started a gcc build on my powerbook.
<doko> getting too hot, the computer turned off ...
<jbailey> Ithought powerbooks were supposed to have decent fans for that sort of thing.
<jbailey> doko: I have a full build log now and I don't see lib64gcc being built at all.  Do I need more than --enable-languages=c passed to configure to get that?
<doko> biarch is turn on?
<doko> biarch is turned on?
<doko> and with_lib64gcc is set?
<jbailey> yes to both.  I know biarch is set because the resulting compiler includes the ability to do -m64
<jbailey> (It just can't find the missing lib64c_s)
<jbailey> the with_lib64gcc doesn't show up in the build log so it's harder to prove, but it's set in the same place that biarch is set.
<doko> and a find build -name libgcc* doesn't find anything 64bit like?
<jbailey> Oh, hmm, it's build/gcc/libgcc_s_64.so
<jbailey> I have been grepping the build log for lib64gcc
<doko> look at debian/rules.defs, if with_lib64gcc is defined
<jbailey> So it's there with no package created.  Excellent.  That gets back into the realm of things I can track. =)
<jbailey> ifeq ($(DEB_TARGET_GNU_CPU),powerpc)
<jbailey>   biarch := yes
<jbailey>   with_lib64gcc := yes
<jbailey>   with_lib64cxx := yes
<jbailey> endif
<jbailey> I know it has to do doing that because of rules2:
<jbailey> ifeq ($(findstring powerpc-linux,$(DEB_TARGET_GNU_TYPE)),powerpc-linux)
<jbailey>   ifeq ($(biarch),yes)
<jbailey>     CONFARGS += --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
<jbailey> Nothing else would be setting biarch.
<doko> found it
<doko> debian/rules.d/binary-libgcc.mk: I assume, if you don't want a normal libgcc, you neither want a 64bit libgcc.
<doko> well, you can argue about it ...
<jbailey> Right.  Ideally this should be provided by gcc4.
<jbailey> The logic's usually right.
<jbailey> Mmm, I don't see that.  I see if biarch, files_gcc += 4{gcc_lib_dir}/64/stuff.
<jbailey> Where is it taken away if you're not building a regular libgcc?
<chmj> i think the meaning of "biarch" has just got a lil confusing to me 
<jbailey> chmj: Heya Charles.
<jbailey> chmj: The context here is a compiler that can produce binaries for what it beleives is it's 32 bit and 64 bit incarnations.
<jbailey> Some of the biarch setups are really logical, like ppc and ppc64, sparc and sparc64.
<jbailey> Some of them are less obvious, like i386 and ia64, or i386 and amd64.
<chmj> ohh yes 
<doko> jbailey: with_libgcc is set to no in 3.4, move the 64bit test at the top out of the ifeq
<jbailey> DOH, binary-libgcc, not binary-gcc
<jbailey> You're in a maze of twisty passages, all alike.
* jbailey has another sip of the bong water.
<jbailey> Lesse if -nc is my friend today.
<jbailey> It is, lovely.
<jbailey> Need to fix symlnks and such.
<jbailey> doko: How do you want the patch to the debian/ directly?
<jbailey> directory
<jbailey> Bah.
<jbailey> Time for a walk soon.
<doko> just email the diff 
<jbailey> Cool, afk a couple minutes.
<infinity> doko : Did you have a list of stuff you wanted thrown back at the buildds?
<doko> infinity, no not explicitely, I was working from breezy_probs
<jbailey> infinity: Are you so empowered now?
<jbailey> infinity: If you are, I swear we're dragging you onto some doko-jbailey friendly timezone. =)
<doko> infinity: prove your power, throw back sound-juicer! ;-)
<infinity> Alright, kicked.
<infinity> jbailey : Yes, I am.
<infinity> jbailey : Though, I only have access to 4 of 12 buildds currently.  One of each arch.  Not sure what the reasoning is for that one. :)
<doko> well, they know that 3 out of 4 won't get borked ;)
<infinity> Or that 1 out of 4 won't. ;)
* infinity sticks his tongue out at lamont.
<infinity> Anyhow, I have full w-b access, which is the more important thing, so I can mangle all your give-back requests and such.
<infinity> My god, the power.  I wish I had w-b rights on all the Debian arches.
<infinity> Doing a give-back on all arches at once felt kinda... Tingly.
<jbailey> I think I might still have it on sparc in Debian. =)
<infinity> Of course, I'm not sure kicking it back was such a fantastic idea..
<fabbione> infinity: congratulation :)
<jbailey> infinity: It's not m68k, these things can cope with the odd mistaken give-back
<infinity> jbailey : Thpt. :)
<jbailey> infinity: So does this mean you'll be my build bitch for biarch ppc64?  Svenl's just confirmed it works for me. =)
<infinity> svenl confirmed that it works.. for.. you?
<jbailey> I don't have a ppc64 kernel.
<infinity> There's something very odd about that sentence.
<jbailey> He ran my hello world binary.
<infinity> Right, well, none of our ppc buildds have ppc64 kernels either.  THat'll need to change if we're meant to be doing ppc64 stuff on them, I guess.
<jbailey> No.
<jbailey> Notice that I couldn't test the ppc64 binary but produced one. =)
<infinity> Sure, but anything with a test suite would flop.
<jbailey> Bah, testsuites.
<infinity> Yeah.  For pussies, I know.
<jbailey> If it's not in the bootstrap path, who needs a testsuite? =)
<jbailey> <sensored comment about pussies and testsuites>
<jbailey> Oh wait.
<jbailey> That wasn't a very good sensor, was it?
<infinity> I assume you meant censor.
<infinity> Cause sensored brings odd images to mind.
<jbailey> Right. =)
<infinity> Of you feeling... pussies.. and testsuites.
<infinity> I can only imagine your wife doesn't like where this is going.
<jbailey> Anytime now I suspect this should shift from a work channel to a /query window. =)
<doko> jbailey: would you mind, if I add some more patches to 3.4?
<infinity> Nah, query schmery, we can just stop talking about it.
<jbailey> doko: Not at all are you going to make fabio scream^W^W^Wupload it, or send me the patches?
<svenl> infinity: i run his ppc64 binaries on the augsbourrg 8-way power5 in pure-64 mode box.
<svenl> fabbione: what is the status of the ubuntu kernel on ppc64 ? 
<infinity> jbailey : Anyhow, what do you need me for for biarch stuff, when you can build on your own?
<doko> jbailey: send me the diff, then I'll send you my diff back
<svenl> fabbione: did you already work on it, want me to have a look or whatever ? 
<doko> ehh, I mean, the merged one ...
<jbailey> doko: Sounds lovely.  I'm just pushing the gcc debs to people.ubuntu.com right now so that I have them as a backup
<fabbione> svenl: without a toolchain i can't do it.
<fabbione> svenl: when i tought we had one, the chroot was broken.. so i couldn't install all the kernel build-deps
<fabbione> that's why i pinged jb and doko this morning again
<fabbione> but clearly.. if you want to do something and help, you are welcome
<jbailey> fabbione: Well, you have a toolchain sitting in my p.u.c directory now if you want it.
<fabbione> jbailey: can we get installed in a breezy chroot on davis?
<fabbione> if so i can start to work on them from monday
<fabbione> tomorrow is userland day
<fabbione> and i really plan NOT to touch the kernel
<jbailey> With any luck they'll be in the archive tomorrow.
<fabbione> ok than i won't bother to rush
<fabbione> i will wait them as naturale upgrade
<fabbione> jbailey: but i will need to know the versions of packages i need to b-d at least
<jbailey> fabbione: Yup.  Should hopefully be really obvious by then.
<fabbione> jbailey: ehehe
<infinity> doko : Any others you want to give the boot?  Or should I just pull a lamont and give-back everything from main?
<doko> infinity, no, currently not, have to fix things first ...
<jbailey> doko: Umm.  Is debian/README.Debian autogenerated? =)
<infinity> doko : Oh.  In that case, I gave back a few things, but I won't touch any more.  I need to get some sleep, and I suspect lamont may be back before I am.
<infinity> But I'm not really sure who'll be here first. :)
<jbailey> infinity: We're moving you to an island in the mid-atlantic. =)
<doko> jbailey: yes
<jbailey> doko: Oh good.  =)
<infinity> jbailey : Uhm.  I don't think I like that idea so much...
<infinity> jbailey : If you manage to get Mark to override my protests, at least score me a massive raise along with it.
<jbailey> infinity: Nah, salaries are market rate, aren't they?  How much can a pineapple cost if you're the only one on the island?
<infinity> Right, so I hate you now.
<jbailey> doko: http://people.ubuntu.com/~jbailey/biarchppc.diff
<jbailey> infinity: You hated me before.  It was a leap of faith to share a room with you at debconf.
<jbailey> Trusting that you were still Canadian enough to not kill me in my sleep.
<svenl> fabbione: ok, so i will be the first one to build ppc64 kernels.
<infinity> Also, it's 1:23am, and I have a girlfriend who wants me either cuddling or dead, and I'd rather the former.
<jbailey> But I had an Inuit carving handy, just in case.
<svenl> fabbione: the baz infocation you gave me earlier is a good starting point to do that, right ? 
<fabbione> svenl: it's the same point i will start from (more or less)
<fabbione> svenl: more or less is determined by other guys committing to it for other stuff
<doko> jbailey, btw, debian/control is generated as well ...
<jbailey> doko: In the patch, you'll see that I removed the leading /'s from the dh_link line.  It's probably not necessary - it was the trailing \'s that turned out to be the problem.
<jbailey> doko: Yes.  I didn't remove generated files, I was going through and verifying them... And scared to see that a README file had changed when I didn't expect it to.
<svenl> fabbione: ok.
<fabbione> svenl: i suggest you to learn how to branch and export your local archive
<fabbione> svenl: so at a later stage i can merge directly from your archive
<fabbione> other than starting a diff -u mess
<svenl> fabbione: but consecutive to the discussion we held about iseries/pseries/pseries-power4 and co, you didn't go ahead and implement that somewhare ? 
<svenl> somewhere even.
<fabbione> svenl: ENOTIME
<fabbione> svenl: changing naming is the last of the problems :)
<svenl> fabbione: hehe.
<fabbione> there is more that needs to be done :)
<svenl> fabbione: do you have a summary of the decisions we took back then though ? 
<fabbione> svenl: <fabbione> powerpc, powerpc-smp, pseries-smp, pseries-power4,
<fabbione>            pseries-power4-smp, iseries-smp
<fabbione> that's what we agreed before we decided to kill power4
<svenl> ok.
<svenl> so nothing more than what we discussed.
<fabbione> so remove power4 from there
<fabbione> nope
<fabbione> i don't talk alone.. usually
<svenl> fabbione: :)
<svenl> fabbione: i will build stuff, will probably take me upto this WE to get kernels done and somewhat tested, i will come back to you then to see if it is worth integrating or need further work or whatever.
<jbailey> I talk to myself, my wife finds it funny.
<jbailey> Apparently since UDU I now swear at my computer in an English accent
<jbailey> (thanks elmo, keybuk, and kamion) =)
<fabbione> jbailey: i do it, but only when i am extremely tired. it helps me focusing
<fabbione> my wife thinks it's time to take out of the cave when i do that
<svenl> Oh, next step is to bring the biarch stuff to 4.0 i guess.
<doko> jbailey: how's the libc6-dev-powerpc package called?
<jbailey> libc6-ppc64 and libc6-dev-ppc64
<svenl> jbailey: would libc6-ppc64-dev not make more sense ?
<jbailey> svenl: I'd have thought so, but this matches how it was done for the other archs.
<svenl> bah.
<svenl> luther@trick:~$ file ./sventest
<svenl> ./sventest: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.0, statically linked, not stripped
<svenl> luther@trick:~$ ./sventest
<svenl> Hello 64bit World!
<svenl> Ok, built fine for me, now is kernel building time.
* svenl wonders if i should try to setup a chroot on the augsbourg 8-way power5 box.
<svenl> doko, jbailey: thanks for the great job you did on this.
<doko> jbailey, infinity, lamont: gcc-3.4 on chinstrap:~doko/uploads/
<jbailey> doko: What magic does this one have?
<jbailey> like, is the ppc64 stuff included?
<doko> lamont, infinity: please kick back gnome-panel on amd64
<doko> jbailey: yes
<jbailey> doko: Cool, thanks.
<doko> but the i386-biarch wasn't in the patch ;-P
<jbailey> Bah, the build failed after stage2. =(  /me checks to see what it died on.
<jbailey> doko: Can I post this build log somewhere to get your help looking at it?
<doko> yup
<jbailey> http://people.ubuntu.com/~jbailey/gcc-3.4_3.4.4-0ubuntu3_powerpc.build 
<doko> yes, trying to run a 64bit test program on a 32bit kernel
<jbailey> Right, but why?
<jbailey> And after stage3...
<jbailey> At that point everythin ought to be built.
<doko> yes, it's a "sanity" check, before the runtime libs are built
<doko> is the i386-biarch patch applied?
<jbailey> stamps doesn't have anything that matches *biarch*
<jbailey> But I see it in the root directory.
<doko> yes, it's disabled, because it didn't work with amd64-libs-dev
<doko> so you have to re-enable biarch in debian/rules.defs and rebuild.
<jbailey> Sorry - this is still ppc/ppc64 I'm working on.
<jbailey> I was doing the full build rather than the just C one that I had been doing before.
<doko> hmm
<doko> please could you put your current glib packages online?
<jbailey> http://people.ubuntu.com/~jbailey/glibc/
<jbailey> http://people.ubuntu.com/~jbailey/gcc/
<jbailey> for the C-only, no-testsuite-run compiler.
<svenl> jbailey: it failed again at the same place :
<svenl> Adding multilib support to Makefile in ../../../src/libstdc++-v3
<svenl> multidirs=64 nof
<svenl> with_multisubdir=
<svenl> Running configure in multilib subdirs 64 nof
<svenl> pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux/libstdc++-v3
<svenl> Running configure in multilib subdir 64
<svenl> pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux
<svenl> mkdir 64
<svenl> ...
<svenl> checking for powerpc-linux-gcc... /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/gcc/xgcc -B/home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/gcc/ -B/usr/powerpc-linux/bin/ -B/usr/powerpc-linux/lib/ -isystem /usr/powerpc-linux/include -isystem /usr/powerpc-linux/sys-include  -m64 -fPIC -mstrict-align
<svenl> checking for C compiler default output file name... a.out
<svenl> checking whether the C compiler works... configure: error: cannot run C compiled programs.
<svenl> doko: do you have any idea ?
* jbailey runs off to meet Angie.
<doko> svenl: no
<svenl> jbailey: :)
<svenl> doko: any hint on where i can check in the Makefiles/whatever what it is doing here ?
* svenl guesses it is trying to run the 64bit binaries built previously with the ppc64 compiler.
<doko> svenl: yes
<svenl> well, where do i check the code doing that ? 
<svenl> in src/libstdc++-v3
<svenl> ?
<svenl> in the configure script there i guess. Which do i investigate ? configure.ac or .host ? 
<svenl> maybe we should set cross compiling in src/libstdc++-v3/configure, or add a special case for biarch if on ppc32 arch ?
<svenl> code is :
<svenl> # Check the compiler produces executables we can run.  If not, either
<svenl> # the compiler is broken, or we cross compile.
<svenl> echo "$as_me:$LINENO: checking whether the C compiler works" >&5
<svenl> echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6
<svenl> # FIXME: These cross compiler hacks should be removed for Autoconf 3.0
<svenl> # If not cross compiling, check that we can run a simple program.
<svenl> if test "$cross_compiling" != yes; then
<svenl>   if { ac_try='./$ac_file'
<svenl>   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
<svenl>   (eval $ac_try) 2>&5
<svenl>   ac_status=$?
<svenl>   echo "$as_me:$LINENO: \$? = $ac_status" >&5
<svenl>   (exit $ac_status); }; }; then
<svenl>     cross_compiling=no
<svenl>   else
<svenl>     if test "$cross_compiling" = maybe; then
<svenl>         cross_compiling=yes
<svenl>     else
<svenl>         { { echo "$as_me:$LINENO: error: cannot run C compiled programs.
<svenl> If you meant to cross compile, use \`--host'.
<svenl> See \`config.log' for more details." >&5
<svenl> echo "$as_me: error: cannot run C compiled programs.
<svenl> If you meant to cross compile, use \`--host'.
<svenl> See \`config.log' for more details." >&2;}
<svenl>    { (exit 1); exit 1; }; }
<svenl>     fi
<svenl>   fi
<svenl> fi
<svenl> echo "$as_me:$LINENO: result: yes" >&5
<svenl> echo "${ECHO_T}yes" >&6
<svenl> doko, was this the place you also had problems with ?
<doko> svenl: yes, try to remove it. the test is executed twice, and maybe for the other runtime libs as well. patch the configure files directly.
<jbailey> Well, the fact that the configure run is called with gcc -m64 I think is really the problem.  For some reason it doesn't think that it's a cross compiler scenario.
<doko> jbailey: it the case, where the 64bit libs are built. so the compiler call is correct
<doko> I'm currently building on 64bit kernel, but it may take a while. it's 600Mhz
<svenl> doko: the configure and not configure.ac or something ?
<doko> svenl: it's a test from autocof, you can only edit it in configure
<svenl> doko: autoconf sucks :/
<svenl> doko: it will not be automagically be readded ? I need to prepare a dpatch, right ? 
<doko> svenl: yes
<svenl> doko: this should be enough, right ?
<svenl> -if test "$cross_compiling" != yes; then
<svenl> +if false; then
<doko> hmm, maybe just if false && ..., so we have a bit of "documentation" =)
<svenl> doko.
<svenl> Ok.
<svenl> doko: there is no 00list to add patches to ? 
<doko> debian/rules.patch
<svenl> in generic debian patches, or ppc specific ?
<doko> ppc specific
<svenl> already did :)
<svenl> ok, build launched, will take some time.
<svenl> doko: how easy do you think it will be to port the biarch stuff to gcc-4.0 ?
<\sh> hmm...can it be, that verdansky is out of sync/control?
<\sh> http://people.ubuntu.com/~lamont/buildLogs/p/python-qt3/3.14.1-2ubuntu2/python-qt3_3.14.1-2ubuntu2_20050526-1945-i386-failed.gz
<Kamion> \sh: no, libqscintilla5c2 isn't in main
<Kamion> which is because python-qt3 and libqscintilla-dev are scheduled for demotion to universe
<Kamion> (nothing in main uses them at the moment)
<doko> Kamion: should we promote mysql-4.1 libs to main?
<Kamion> doko: not on anastacia's list?
<Kamion> libmysqlclient14?
<doko> yes
<doko> libdbd-mysql-perl is failing
<doko> docbook2x is needed as a build dep for gnome-doc-utils
<Kamion> python-qt3 was only in main in hoary because hplip build-depended on it
<\sh> Kamion: when it will be moved to universe?
<Kamion> \sh: dunno, I'm leaving it to elmo
<doko> Kamion: no, it was a depends, I did split out the UI in another package
<Kamion> doko: hplip.deb was in universe in hoary
<Kamion> and it was a build-depends too
<doko> backuppc depends on wwwconfig-common, should this enter main?
<Kamion> wwwconfig-common is scary crack, I'd rather defer and possibly avoid
<Kamion> I think we've avoided it in the past
<doko> the hplip debian maintainer didn't accept the patch removing the build-dep
<Kamion> doko: oh, germinate's only re-run once a day, it'll show up tomorrow
<Kamion> I'm operating in dummy mode and would rather not do anything until anastacia tells me I can :-)
<doko> ;)
<doko> where can I run anastacia?
<Kamion> only if you have an account on jackass
<Kamion> hm, I guess libmysqlclient14* would be "obvious"
<Kamion> doko,elmo: ok, libmysqlclient14 libmysqlclient14-dev promoted
<doko> Kamion: fine
<Kamion> I don't know if it needs mysql-common-4.1 - dependencies suggest not, but we'll see
<svenl> jbailey, doko: if i want to enable the build of the 32bit libgcc1, is this advisable ? In case i don't want to use the 4.0 version of it ? 
<jbailey> svenl: The gcc4 one in the archive ought to work fine.  What's the issue?
<svenl> jbailey: am building a sarge chroot with the stuff in it to try.
<svenl> jbailey: as such, i don't have the gcc4, and i guess it should be ok to run its own libgcc1 in this case, no ? 
<doko> svenl: it's in experimental
<svenl> doko: yes, but do we really need the 4.0 libgcc ?
<doko> as soon as 4.0 enters sid
<svenl> doko: yes, but i mean, do we *NEED* it ? What does it bring more over the 3.4 one ? And in reverse, what does using gcc-3.4 bring over going full 4.0 ? 
<doko> lamont, infinity: please push gnome-panel on amd64
<doko> svenl: more symbols
<svenl> I mean, you told me that jbailey had trouble building glibc with 4.0, is this still true ? 
<svenl> doko: ok.
<jbailey> svenl: We don't need it, no.  But if you're doing this on sarge, your best bet is probably to fiddle with the sarge toolchain.
<svenl> doko: but for a sarge chroot, that should not be an issue.
<svenl> jbailey: bah :)
<doko> Kamion, lamont: FTSTR why gnome-media is not getting installed on the amd64 buildd as a b-d of sound-juicer
<Kamion> Get:4 http://jackass.ubuntu.com hoary/main gnome-media 2.9.90-0ubuntu1 [2042kB] 
<Kamion> it built fine?
<Kamion> oh, wrong version
<Kamion> doko: the buildd appears confused to me (it's not just gnome-media), and the last non-confused build was some time ago when libnautilus-burn2 wasn't in main
<doko> it's a lamont thing ...
<svenl> jbailey, doko: do you want me to send you the dpatch ? 
* svenl wonders though why it then built for jbailey on his ppc32 machine.
<jbailey> svenl: I had c++ disabled for the original build.
<svenl> jbailey: ah ...
<svenl> do you wnat the patch then ? 
<jbailey> svenl: I'd like to review it but will wait for doko's ok on it.
<svenl> bah.
<svenl> he counseled it to me, and it just does one if false && ... instead of the cross check.
<svenl> and is enabled only on ppc, so i think it is ok. I added some comment line too though.
<doko> Kamion, elmo: debconf b-d's on libintl-perl, u->m needed
<doko> svenl: send it, but I won't do anything about it today
<svenl> doko: no problem, just wanting to avoid duplication, even if it is trivial.
<svenl> doko: what email address ?
<svenl> (ubuntu-toolchain@lists.ubuntu.com ? :)
<jbailey> Dear gods, tell me there isn't an ubuntu-toolchain email list...
<svenl> jbailey: :)
<svenl> jbailey: or as bug report in bugzilla to gcc-3.4 ?
<svenl> jbailey@ubuntu.com, doko@ubuntu.com should do i guess.
<doko> Kamion, elmo: libwpd8 is needed by abiword-plugins, u->m
<jbailey> svenl: Yes, that'll get to me.
<doko> svenl, yes
<svenl> you have mail.
<jbailey> Oh gross.
<jbailey> This will certainly get it built for now, but I suspect that we need to make sure that when compiling with -m64 that the target is set to ppc64-linux
<svenl> jbailey: as said, it is a quick and ugly hack doko mentioned.
<svenl> jbailey: its powerpc64-linux btw :)
<jbailey> svenl: You can feed ppc64-linux to config.sub and it expands it to powerpc64-unknown-linux-gnu =)
<svenl> jbailey: he :)
<svenl> ok, i am off to bed now, while both my machines build.
<jbailey> g'n Sven!
#ubuntu-toolchain 2005-06-03
<zul> gcc 3.4 hasnt been touched in breezy has it?
<zul> sorry dumb question
<fabbione> morning
<desrt_> hello.
<desrt_> </time-delay>
<lamont> moo
<desrt_> oow
<lamont> doko: on amd64, gnome-media Depends: libnautilus-burn1, not 2.
<lamont> so gnome-media needs another upload, since the build-deps were clearly wrong on the last upload...
<lamont> Updating the gdk-pixbuf loaders list for GTK+-2.4.0.../usr/sbin/update-gdkpixbuf-loaders: line 25: 27053 Killed                  /usr/bin/gdk-pixbuf-query-loaders >$TMPFILE
<lamont> dpkg: error processing libgtk2.0-bin (--configure):
<lamont>  subprocess post-installation script returned error exit status 137
<lamont> so I shouldn't be killing that 14 hours after it started running, eh?
<lamont> hppa hateses gdk-pixbuf
<lamont> well, libgtk2.0-bin_2.6.7-1ubuntu1
<jbailey> lamont!
<jbailey> lamont: You around tomorrow?
<lamont> yeah
<jbailey> Cool.  Looks like we have ppc64 ready to go.
<fabbione> rocking!
<lamont> oh joy.  Just tell me the dance
<jbailey> Lemme get the requirements from you:  You require that anything installed into the buildd chroot be built by you, and then we upload binaries that use those, right?
* lamont also just gave back most everything in main that was not built. 
* fabbione puts gcc and glibc in no_auto_build
<lamont> jbailey: it's easier to phrase it in the negative...
<jbailey> lamont: Well, I'm looking for an afirmative set of steps to give you.
<lamont> binaries not built by the buildd in a chroot containing only things built by the buildd are not uploaded
<jbailey> I'm less worried about what's uploaded than I am by what you're willing to install in that chroot to build what's going to be uploaded.
<lamont> binaries built by the buildd using binaries built by the buildd using binaries built by $UBUNTU_GOD are ok
<fabbione> haha
* fabbione likes the definition of $UBUNTU_GOD
<lamont> the end-state requirement is that what's in the archive must be able to build what's in the archive.
<jbailey> Okay, so you need one iteration pass.  I wonder if what I have on rookery is signed.
<lamont> hence, if we have the trivial case of A Build-Depends B Build-Depends A, then we build A using random B binaries, build B using the A binaries just built, upload B, and let A just get built
<lamont> fabbione: s/$UBUNTU_GOD/baby jesus/ ??
<fabbione> ehhee
<fabbione> btw.. do we have a way to determine when all c++ libs are built for arch $foo ?
<fabbione> so that we can unban the apps?
<lamont> fabbione: doko tells me. :-)
<fabbione> lamont: good point :)
<lamont> and no, I don't believe that they are, even for the big-3.
<lamont> that is, all 5 arch's that I have still have the banlist.  although I did remove the 3 libs packages that were called apps packages, yesterday or the day before.
<fabbione> yup
<fabbione> so did i
<lamont> hrm... maybe by morning my mirror-sync from yesterday will finish. (new kernel *2, new xorg - sigh.)
<lamont> and maybe even my uploads will catch up with the builds.  that'd be cool
<lamont> jbailey: you know cdbs is ftbfs, yes?
<jbailey> lamont: ocaml's busted.
<lamont> doh.  I remember now
<jbailey> lamont: I should remember to look at that tomorrow.
<jbailey>  /msg jbailey jbailey: look at ocaml
<jbailey> bah
<lamont> hehe
* lamont will sleep now, unless fabbione needs something else... :-)
<jbailey> lamont: The binaries I have on rookery aren't signed.  I'll fix that in the morning and give you some basic step-by-steps.
<lamont> thansk
<jbailey> And since Fabio's here, I know that it must be bed time.
<jbailey> g'n all!
<lamont> and yeah, signed debs is kinda the requirement for installing in the buildd
<fabbione> jbailey: i woke up earlier today :)
<jbailey> fabbione: =)
<jbailey> fabbione: Earlier than 5am?
<jbailey> sick
<jbailey> Zzzz
<fabbione> jbailey: unfortunatly one of the side effects of living in dk is that during the summer the sun is up in the sky at 3am
<fabbione> and it woke me up at 4:something
<fabbione> i need to put some curtains in the bedroom 
<svenl> jbailey, doko: with the patch, ugly as it is, the build succeeded.
<Kamion> doko: there's no libwpd8 any more; abiword-plugins needs to move to libwpd8c2
<Kamion> doko: libintl-perl promoted
<Kamion> elmo: any idea why teri seems to want to promote stuff in hoary even though I said -s breezy?
<elmo> Kamion: because it's shared ?
<Kamion> elmo: is that good?
<elmo> no, but it's a natural consequence of how pools work
<Kamion> oh, it's the same version
<elmo> just run hilaries once you've finished running teri
<Kamion> right, but I thought it could be in dists/hoary/universe/*/Packages.gz and dists/breezy/main/*/Packages.gz simultaneously
<elmo> only via the magic symlinks
<Kamion> ok, I wasn't sure I could safely run that and wanted to check first
<Kamion> libintl-perl |     1.11-1 |         hoary | source, all
<Kamion> still says that though
<elmo> it will madison looks at the database
<elmo> the symlinks only help for things which treat the Packages file as canonical
<Kamion> I guess the fact that the component is set in the database for (package,version) rather than (package,version,suite) is inherited from Debian then
<Kamion> but ok, as long as I didn't break the archive :)
<elmo> (package,version,suite) being unique is a fairly fundamental katie thing ...
<doko> lamont: I disagree, gnome-media's build log on amd64 shows me the libnautilus-burn2 dependency
<fabbione> jbailey, doko: pthread_rwlock_wrlock <- any idea where this one should come from?
<fabbione>  /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/global.c:536: undefined reference to `pthread_rwlock_wrlock'
<fabbione> this is building a 64 bit version of a library.
<fabbione> it's ok at 32 bit
<fabbione>  /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/plugin.c:411: undefined reference to `dlopen'
<fabbione> HMMMM
<fabbione> this smell so much of libc6 borkage
<doko> definitely
<fabbione> ld: warning: sparc:v9 architecture of input file `plugin.o' is incompatible with sparc output
* fabbione sighs
<fabbione> it happens with all kind of gcc
<fabbione> so it's not just gcc the problem
* fabbione summons jbailey 
* jbailey appears
<fabbione> jbailey: see above :)
<fabbione> i am checking with older glibc right now
<jbailey> Are you running the buildd in a sparc32 jail?
<fabbione> it's just a chroot
<fabbione> i didn't execute anything like sparc32 or sparc64
<fabbione> just added -m64 to the gcc call
<jbailey> Without it I can seee occasionally having problems.
<fabbione> (like Debian does)
<jbailey> afk a sec.
<fabbione> yeah no rush
<jbailey> back
<fabbione> hmm nope..
<fabbione> same story in hoary...
<fabbione> hmmmmmmm
<jbailey> Try building it after sparc32'ing. 
<jbailey> I've seen problems like that before. =(
<fabbione> i did try:
<fabbione> sparc{32,64} make CC="gcc-3.{3,4} -m64"
<fabbione> in all combinations
<fabbione> same error both in hoary and breezy...
<fabbione> i wonder..
<jbailey> sparc32 -m64 doesn't make much sense...
<jbailey> Why would it have -m64 on it?
<fabbione> jbailey: because you need to build both 32 and 64 bit?
<fabbione> so basically the source is copied in 2 dirs
<fabbione> one for 32 bit build
<fabbione> and one 64
<jbailey> I'd have to see the build log to guess.  IT sounds like it's just gotten confused and mixed the two along the way somewhere.
<fabbione> jbailey: in glibc or this program?
<jbailey> this program.
<fabbione> sure.. one second
<jbailey> It's ld detecting the mismatch.
<fabbione> do you want the full build log?
<jbailey> IF it were glibc, I'd expect everything to fail.
<fabbione> or just the 64 bit part?
<jbailey> Yes please.
<jbailey> full
<fabbione> ok
<fabbione> jbailey: http://people.ubuntu.com/~fabbione/buildlog
<jbailey> Your link line is at least missing -ldl -lpthread
<jbailey> fabbione: This buildlog is only half there...
<jbailey> fabbione: It looks like you did a debuild -nc and sent me that. =)
<fabbione> ops
<fabbione> sorry about that
<jbailey> =)
<jbailey> doko: l?
<doko> hi
<jbailey> doko: svenl provided a patch do chew libstdc++ configure such that it assumes that we're cross compiling.  I don't understand all the implications of the patch - are you comfortable with it for upload as gcc-3.4?
<jbailey> (I'm assuming that I need to make the patch ppc-only)
<fabbione> jbailey: relaod the log now :)
<jbailey> fabbione: Right, this is terribly confused.  -m32 and -m64 code don't play together.
<jbailey> It's building the modules, but it's never built a -m64 libmagma.so
<doko> yes, I'm merging it now, so that it get's only applied, if we cannot run 64bit binaries. when we can run 64bit binaries, I'm enableing the -m64 tests as well
<fabbione> jbailey: the first part of the log is all 32 bits
<fabbione> the first failure is when i attempt to build the first 64bit module
<fabbione> module = subdirs that needs 64
<jbailey> doko: Sweet, thanks.  When you have that ready, I've already booked LaMont for part of today.
<fabbione> make[2] : Entering directory `/home/sparcbuildd/rhcluster-0.20050527/magma-64/lib'
<fabbione> ^^^note that it is building the same module in another dir :)
<jbailey> doko: I can at least get him with a bootstrap glibc and C-only gcc, after that we only need this for the upload.
<jbailey> fabbione: Right, but it's not actually building the libmagma again.  It's building stuff to go with it without having build a 64bit libmagma.
<fabbione> i don't understand...
<fabbione> magma build is at the top of the file
<fabbione> magma-64 is at the bottom
<fabbione> don't take into account magma-plugins.. that's another story
<jbailey> fabbione: The first -m64 stuff I see is in magma-64/lib
<jbailey> Oh, bah.
<jbailey> My bad, sorry.  I read the ld line wrong.
<fabbione> ehe no problem :)
<fabbione> nothing to be sorry about
<fabbione> that piece of code is a mess :)
<fabbione> now.. the point is that debian does exactly the same way
<fabbione> and it builds
<doko> jbailey: I do have a complete set of packages built with you glibc
<doko> needs copying to chinstrap
<jbailey> Do you prefer chinstrap to rookery?
<doko> lamont must be cheap if he can be booked that easily ;-)
<jbailey> I usually use rookery so that people can wget them.
<jbailey> doko: I promised him oral pleasure...
<jbailey> ... I'm buying him a pack of gum.
<jbailey> =)
<fabbione> ahaha
<lamont> jbailey: say in about 4 hours work for you?
<jbailey> fabbione: Humour me a sec.  ar -v lists sparc64 in the list of emulations at the bottom, right? =)
<jbailey> lamont: Yeah, should be fine.
<lamont> cool.
<fabbione> ar: supported targets: elf32-sparc a.out-sparc-linux elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
<fabbione> hey lamont 
<jbailey> fabbione: Okay, good. =)
<fabbione> jbailey: :)
<jbailey> fabbione: Gcc sets -m elf64_sparc, can you try adding that to the ld line?
<fabbione> jbailey: sure thing
<fabbione> ld -m elf64_sparc -shared -soname libmagma.so.0 -o libmagma.so.0.0 global.o plugin.o localinfo.o ip_lookup.o memberlist.o clist.o -lc
<fabbione> ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc
<fabbione> ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
<fabbione> starts to look MUCH MUCH better!
<fabbione> no idea why it's searching crap in /usr/bin
<fabbione> but the build system is kinda borked :)
<jbailey> gcc does things through relative paths.
<fabbione> hmm
<jbailey> fabbione: Can you redefine ld there?
<fabbione> yeps
<fabbione> make CC="gcc-3.4 -m64" LD="ld -m elf64_sparc"
<fabbione> that's what i used just now
<jbailey> fabbione: If yes, just define it to "gcc-3.4 -m64" and see what happens, please.
<fabbione> that's what i did already
<jbailey> If the compiler notices that it's being used as a linker, hopefully it'll just do the right thing.
<fabbione> or you mean ld?
<jbailey> I mean ld.
<fabbione> ah ok
<fabbione> gcc-3.4: libmagma.so.0: No such file or directory
<fabbione> gcc-3.4: unrecognized option `-soname'
<fabbione> nope...
<fabbione> it didn't like it
<jbailey> Ugh, yeah.  That stuff has to be wrapped in -Wl, magic.
* jbailey boggles a moment.
<doko> jbailey, lamont: chinstrap:~doko/powerpc64
<jbailey> doko: Nice, thanks.
<fabbione> doko: rocking :)
<jbailey> doko: And I think all I have to do is produce for him a libc6 that he can work with and this can be just uploaded.
<jbailey> fabbione: Care to share a screen session on vultus5?
<fabbione> jbailey: sure i can do that :)
<fabbione> just one sec :)
<doko> jbailey, yes, integrating svenl's patch
<fabbione> jbailey: just hook up in my session :)
<fabbione> ehehhe
<fabbione> if it's too big, i can resize mine :)
<jbailey> That's one for the quotefile.
<fabbione> btw.. screen is clever enough to show you the borders if you set a size bigger than the original
<jbailey> Really?  Cool.
<jbailey> Thinking about sparc64 makes me need to listen to Nirvana, CD now playing. =)
<fabbione> ahha
<fabbione> it's a chroot.. there is nothing installed .)
<fabbione> or just the minimum
<jbailey> Hmm.
<jbailey> I would've thought that gcc or glibc would pull in libgcc_s_64 automatically.
<fabbione> oh
<fabbione> what do you want me to install?
<jbailey> Well, I'd like to know whose assumption is broken first.  libgcc_s_64 is something brought in by gcc/the linker in this case, not the user, so the user shouldn't have to know to install it.
<jbailey> doko: ^^ ?
<doko> we don't have dependencies for the non-default arch in gcc
<jbailey> doko: What ought to pull that in?  I don't think the user should have to, but I could do it as part of libc6-dev-sparc64
<fabbione> libc6-dev-sparc64 is installed btw
<jbailey> Yup, it's just figuring out what should pull in lib64gcc1
<doko> jbailey: yes, that might be a good place
<fabbione> oh so if i install that package...
<fabbione> it should build...
<jbailey> No, the last command I ran will work.
<jbailey> We still need to fix the package to do better than it's doing now. =)
<fabbione> yeah the package SUCKS BIG BIG BIG BIG BIG TIME
<fabbione> well the last interesting commands still return error
<jbailey> Are you packaging this for Ubuntu, or is this something we're importing from Debian?
<fabbione> jbailey: for ubuntu
<fabbione> part of it is already in debian
<fabbione> and i did check the build-dep
<fabbione> the point is that debian didn't build this crap in months
<fabbione> so with a very old toolchain
<jbailey> I don't think it would've worked months ago on sparc64 then...
<fabbione> jbailey: no idea if it works.. but it was builded
<Kamion> hmm, binutils bugs come flooding in
<jbailey> For now, let's make this work.
<jbailey> fabbione: Please install lib64gcc1 in this chroot.
<fabbione> sure
<fabbione> jbailey: meh.. it's installed :)
* fabbione smells of deep gcc fuckage here
<jbailey> doko: Thinking of which, I saw drow mention that he was busy because of travelling.  Would you prefer to wait for that update?
<doko> lamont: why is screem_0.12.1-1ubuntu3 not built? 
<doko> jbailey: yes I did look at the ml today, maybe I just fetch a cvs update from the branch
<jbailey> Ah, I haven't read it today.  He mentioned it in the #debian-glibc a couple days ago.
<jbailey> doko: I might have another gcc-3.4 packaging bug.  Still time to get it to you?
<jbailey> fabbione: See that ifeq ($(with_shared_libgcc),yes) bit ?
<fabbione> jbailey: yes
<fabbione> btw.. i installed less :)
<doko> jbailey: yes
<jbailey> fabbione: That's not firing for some reason, so the libgcc is being left in /usr/lib64 instead of being moved to /lib64
<jbailey> fabbione: We need to figure out what it didn't fire and get the patch for it to doko. =)
<fabbione> jbailey: a gcc-3.4 build without checks can take sometimes...
<fabbione> i can stop the buildd to make it faster
<fabbione> otherwise we can fix it in another upload
<fabbione> sparc won't build gcc- automatically anyway
<jbailey> I'd rather not hold up the ppc64 stuff for it.
<fabbione> installing gcc-3.4 build-deps now
<fabbione> yeah sure.. it works for me to wait the next upload
<jbailey> fabbione: There should be no reason why it didn't fire...
<fabbione> i can see that....
<fabbione> but i have no idea....
<jbailey> Oh right.
<fabbione> ahhh
<jbailey> I see. =)
<fabbione> gcc-4.0!
<jbailey> Right. =)
<fabbione> so gcc-3.4 has nothing to do with this problem
<jbailey> Right.
<doko> jbailey, should libgcc1 be installed in /lib64 or /usr/lib64?
<fabbione> do you want gcc-4.0 builddep?
<jbailey> doko: /lib64, in case it's needed for some reason to bring up /usr (encrypted filesystem or whatnot)
<jbailey> doko: The gcc-3.4 packaging appears to have it that way, but the gcc-4 packaging moves it to /usr/lib64.  (Or rather, doesn't include the code snippet that moves it from $(d)/$(PF)/lib64 to $(d)/lib64
<fabbione> jbailey: do you need gcc-4.0 build-deps?
<fabbione> to do a test build?
<jbailey> fabbione: I think it's funny that the Nirvana CD ended just as we figured it out.  I should label it sparc64. =)
<fabbione> ahahaha
<jbailey> fabbione: Umm.  No - I don't think I want to dive into that now.  If we put a symlink in /lib64 for you so that you can hack on this, it'll be overwritten when the package is updated.
<jbailey> fabbione: It won't do you any good for uploading, but it will let you finish testing the build.
<fabbione> jbailey: yeah that's fine
<fabbione> doko: did you understand what you need to do to gcc-4.0?
<doko> hmm, didn't read ... the /lib64 stuff?
<fabbione> doko: yeps
<fabbione> ok
<fabbione> jbailey: it works perfectly!
<fabbione> thanks a lot!
<jbailey> fabbione: Any time. =)
<jbailey> lamont: ocaml is current FTBFS I think from the X transition, I'll poke at it next week.
<infinity> Kamion : I've bitchslapped pitti, and a new upload is on its way.
<Kamion> cool, thanks
<infinity> A little education about why testsuite output should be read and compared, and we're on our way. :)
<jbailey> infinity: Aren't you just the FormatTestPlans bitch now... ;)
<infinity> Well, this does remind me that you should properly XPASS/XFAIL all of binutils' tests and actually error on suite failure.
<infinity> s/you/we/
<infinity> Or me, even.
<infinity> If I had a spare month, I'd do it with gcc too...
<infinity> It was a bit shocking to come home, open up ubuntu-bugs, and see "nothing compiles on hoary anymore".  Yay.
* fabbione declares weekend time
<fabbione> later guys
<infinity> Have a good one.
<fabbione> thansk
<doko> elmo, Kamion: I need libant1.6-java in main as a build dependency for OOo2
<elmo> doko: the java stuff is a mess, and AFAIK, mdz didn't want it migrated till the extraneous crap was dropped
<doko> elmo: I'm not talking about java, just libant1.6-java and ecj-bootstrap to have a working ant. that's all, not crap
<elmo>  o junit: junit
<elmo>    [Reverse-Build-Depends: libant1.6-java] 
<elmo>  o libjaxp1.2-java: libjaxp1.2-java
<elmo>    [Reverse-Build-Depends: libant1.6-java] 
<elmo>  o ecj-bootstrap: ecj-bootstrap
<elmo>    [Reverse-Depends: java-gcj-compat] 
<elmo>  o java-gcj-compat: java-gcj-compat
<elmo>    [Reverse-Build-Depends: gjdoc] 
<doko> elmo: Suggests!!!
<elmo>  o libgcj-dev                                                   {gcc-defaults}
<elmo>    [Reverse-Build-Depends: java-gcj-compat] 
<elmo> doko: germinate doesn't look at suggests
<elmo>  o kaffe: kaffe, kaffe-common, kaffe-pthreads
<elmo>    [Reverse-Depends: kaffe, kaffe-pthreads] 
<elmo>    [Reverse-Build-Depends: junit] 
<elmo>  o classpath: classpath, classpath-common, jikes-classpath
<elmo>    [Reverse-Depends: classpath] 
<elmo>    [Reverse-Build-Depends: antlr, libjaxp1.2-java] 
<elmo> .. do I need to go on? :-P
<doko> ok, forgot about the Reverse-Build-Depends ...
<doko> let's see if I can build it with gcj-4.0
<doko> elmo: please could you dist-upgrade davis/breezy-ppc64 and then install the packages from davis:~doko/gcc/install/ ?
<elmo> I can't dist-upgrade without a fixed glibc packae set
<elmo> are the ones in ~doko safe to install first?
* jbailey reads the backscroll to figure out what he missed.
<doko> hmm, they have the same version as the ones in the archives
<elmo>   libc6-dev: Depends: linux-kernel-headers (<= 2.6.11.2-0) but 2.6.11.2-0ubuntu1 is installed
<doko> elmo: hmm, maybe just install the *64 packages then, the rest from breezy
<jbailey> What are you guys doing?
<doko> jbailey: rebuilding 3.4 in the breezy-ppc64 chroot
<doko> just want to check, that I don't have any new build bugs introduced
<jbailey> doko: Ah, you really probably want the glibc from my directory on rookery.
<doko> jbailey: yes, that's what I copied
<jbailey> Really?  =(  It shouldn't have that lkh bug...
<elmo> it doesn't
<jbailey> Then I'm just confused.
<elmo> Unpacking bison-doc (from .../bison-doc_1%3a2.0-1ubuntu2_all.deb) ...
<elmo> dpkg: error processing /var/cache/apt/archives/bison-doc_1%3a2.0-1ubuntu2_all.deb (--unpack):
<elmo>  trying to overwrite `/usr/share/info/bison.info.gz', which is also in package bison
<elmo> DUDE
<elmo>  Conflicts: bison (<< 2.0)
<doko> hmm, I thought I fixed it ...
<elmo>  Version: 1:2.0-1ubuntu2
<elmo> epochs'r'us
<doko> argh
<elmo> anyway, breezyt-ppc64 done
<doko> thanks
<doko> bison supposed to be fixed now
<doko> elmo: sorry, still need autoconf2.13 automake1.4 automake1.7
<elmo> installed
<doko> jbailey: when did you book lamont?
<jbailey> doko: The 4 hours he quoted would be about 45 minutes from now.
<jbailey> I do need food, though, so I'd be happier if it were a bit later.
<jbailey> And I have a rental car to return over lunch.
<lamont> hrm...
* lamont has lunch in about 2.25 hours time..
<lamont> could start now, if you want...
<lamont> doko: screem was d-w, will see how it does now
<jbailey> lamont: You will need to install a new binary glibc into the buildd.  A source upload of gcc after that is enough to build gcc, and a source upload of glibc after that is enough to get glibc in.
<jbailey> lamont: What's first? =)
<doko> lamont: let's start now
<lamont>  /usr/include/sys/procfs.h:57: error: parse error before 'elf_vrreg_t'
<lamont> go lkh!  kill gdb.
<lamont> (gdb is ftbfs on ppc)
<lamont> jbailey: so what I'm most likely to do is:  (1) glibc binary install, (2) build gcc, install that binary, (3) build/upload glibc, (4) build/upload gcc
<lamont> hrm.. actually, (3) is build, install glibc. :-)
<lamont> (5) is build/upload glibc
<elmo> lamont: what's this?
<lamont> bootstrapping biarch
<jbailey> lamont: Okay.  So for version numbers, glibc 2.3.5-1ubuntu3 is in the archive now, gcc-3.4 3.4.4-0ubuntu3 is in the archive now.
<jbailey> lamont: What binary version do you want the first glibc to be?
<lamont> jbailey: if you want to be kind, something between -1ubuntu3 and -1ubuntu4 :-)
<lamont> or even -1ubuntu4, and the actual source upload be -1ubuntu5 is fine with me
<elmo> lamont: biarch of what?
* lamont points at jbailey
<jbailey> elmo: ppc/ppc64
<doko> elmo: ppc64
<elmo> I thought you needed a 64 bit kernel?
<doko> no, only for a "sanity" check and running the testsuite
<lamont> jbailey: and this is on ppc only, or which architectures am I bootstrapping? :-)
<Kamion> as binutils recently demonstrated, the testsuite is for wimps ;-)
<doko> lamont: I thought jbailey booked you for i386 as well?
<doko> Kamion: to be more precise, testsuite for -m64 is not run
<lamont> doko: i386 was my recollection... ppc64 was the news item... :-)
<jbailey> doko: No, fabio and svenl seemed to be in a rush for ppc.  I can do i386 at the same time I think.  Just need to make sure I have everything merged together for it.
<jbailey> doko: Is the gcc-3.4 source package on chinstrap already tweaked for that too?
<jbailey> doko: Oh wait, I remember.  I also did the ppc stuff first since it's a simple biarch setup without needing Tollef's multiarch stuff at all.
<lamont> jbailey: and remember to disable the gcc- testsuite on hppa, please
<jbailey> lamont: gcc or glibc?
<lamont> gcc-3.4, most notably
<lamont> although 4.0 wouldn't hurt either... :-(
<doko> lamont: please get it from chinstrap:~doko/uploads again
<jbailey> doko: What do you want to have happen?  Mostly the last couple days I've been testing ppc64 and planning to do the proper multiarch path thing after.
<doko> lamont: gcc-3.4 as well?
<doko> jbailey: I don't care that much about biarch on i386, as you like it.
<jbailey> 'kay, I'll ignore it for now, we can do the ppc stuff, and I'll get the rest of it next round.
<lamont> doko: 3.4 either needs tk love, or a hammer.
* jbailey preps 2.3.5-1ubuntu4
<doko> lamont: please could you find out, why gnome-panel is not built on amd64?
<doko>    * On hppa, build-depend on expect-tcl8.3 instead of expect.
<lamont> doko: bug #11024
<lamont> (gnome-panel)
<lamont> build-dep (and therefore dep-wait) on libwnck
<doko> thanks
<lamont> elmo: if libqscintilla5c2 migrated universe->main, python-qt3 et al would be happier.
<doko> lamont: these should leave main, not needed anymore
<lamont> really?
<lamont> as of 1649 today (london), that was the cause of the failure...
<jbailey> Hmm, this should probably grow a build-dep on a particular gcc-3.4 version, shouldn't it...
<lamont> The following packages have unmet dependencies:
<lamont>   libqscintilla-dev: Depends: libqscintilla5c2 (= 1.5.1-1ubuntu1) but it is not installable
<Kamion> lamont: he means that python-qt3's scheduled for demotion to universe
<lamont> ah.  that works too
<fabbione> hmmmmm
<fabbione> guys did you made an estimate of how many pkgs will need ppc64 love?
<fabbione> like libncurses-5 ?
<fabbione> or do you plan to modify the same that are actually built for sparc64?
<jbailey> fabbione: ncurses, zlib, I think maybe procps
<jbailey> fabbione: Right. =)
<fabbione> :)
<jbailey> doko: What should I put as the build-dep version of gcc-3.4 for ppc64?
<doko> 3.4.4-0ubuntu4 should be ok
<jbailey> Tx.
<jbailey> Lovely, glibc build is running
<jbailey> One of these days I have to figure out how to make ccache happier.  I have 3188 cache hits, and 24527 cache misses.  The only thing I compile with ccache is glibc...
<doko> jbailey: I have 0 hits compiling gcc =)
<fabbione> doko: clearly.. gcc sucks
<doko> fabbione: ppc64 kernel ready?
<fabbione> doko: not without toolchain
<fabbione> you will get it either monday or tuesday
<doko> toolchain is on davis/breezy-ppc64. happy weekend ;-)
<doko> infinity: you did remove the gcc4 changes to grub, when merging ...
* lamont runs off for about 15 minutes, so that he can work the following 40 minutes...
<fabbione> doko: welcome to the kernel team. kthxbye
<fabbione> jbailey: i found another weird case :)
<fabbione>  /usr/bin/ld: cannot find -lgcc_s_64
<fabbione> and i didn't update the chroot ;)
<fabbione> anyway.. this is monday stuff :))
<jbailey> fabbione: On gcc-3.4 or gcc-4?
<jbailey> s/On/Using/
<fabbione> jbailey: never mind.. Makefile crap :)
<fabbione> now it builds.. all of it :)
<jbailey> fabbione: I like that answer!
<fabbione> the question is more like... does it work? :P
<fabbione> since you have a G5 you are going to test kernel and userland :)
<fabbione> anyway it's really we time for me now :)
<fabbione> cya tomorrow
<jbailey> Yup.  Dunno if I'll be around much this weekend, but I Should be a little bit.
<jbailey> First real sunny one this year. =)
<fabbione> i will be tomorrow (my morning) and probably a bit of sunday
<fabbione> ehhe
<fabbione> enjoy :)
<jbailey> 2u2!
<fabbione> merci'
<lamont> jbailey: anything for me yet?
<fabbione> (poor mispelled french ;))
<jbailey> lamont: TEstsuite finished, it's just running the install bits.
<jbailey> fabbione: You spelt it right. =)
<lamont> ok
* lamont must be out the door at the next :30
<lamont> jbailey: is this ppc only? or which architectures are we playing with?
<doko> lamont: ppc
<lamont> cool
<lamont> jbailey: you're going to give me a nice repository on rookery or something, right?
<jbailey> lamont: Define nice repository...
<lamont> jbailey: a deb line I can drop into sources.list. :-)
<lamont> from somewhere wget-able on rookery
* jbailey checks to see if I apt-ftparchive is on rookery
<lamont> hrm... without a Release.gpg is OK, I suppose
<lamont> it is
<jbailey> Good, debhelper phase going now.
<jbailey> I have to leave in the next few minutes to get the car back on time.
<jbailey> lamont: I gotta run, I have this copying onto rookery, but it'll have to wait until I come back for me to wave apt-ftparchive over it.
<lamont> hrm... where on rookery?
* lamont can grab bits, just would prefer a repository...
<jbailey> http://people.ubuntu.com/~jbailey/ppc64/
<lamont> ok.  any easy way to tell the copy is done?
<jbailey> There's a signed changes file in there.
<lamont> ok
<jbailey> Restarted the command as:
<jbailey> scp * people.ubuntu.com:public_html/ppc64/; ssh people.ubuntu.com touch ppc64/done
* jbailey redoes with public_html in the touch path
<lamont> chmod g+w public_html/ppc64
<lamont> that'll be easiest.. :-)
<jbailey> Done.
<lamont> ok. /me waits for done to exist
<jbailey> glibc_2.3.5-1ubuntu4.diff.gz glibc_2.3.5-1ubuntu4.dsc glibc_2.3.5-1ubuntu4_powerpc.changes glibc-doc_2.3.5-1ubuntu4_all.deb libc6_2.3.5-1ubuntu4_powerpc.deb libc6-dbg_2.3.5-1ubuntu4_powerpc.deb libc6-dev_2.3.5-1ubuntu4_powerpc.deb libc6-dev-ppc64_2.3.5-1ubuntu4_powerpc.deb libc6-pic_2.3.5-1ubuntu4_powerpc.deb libc6-ppc64_2.3.5-1ubuntu4_powerpc.deb libc6-prof_2.3.5-1ubuntu4_powerpc.deb libc6-udeb_2.3.5-1u
<jbailey> buntu4_powerpc.udeb libnss-dns-udeb_2.3.5-1ubuntu4_powerpc.udeb libnss-files-udeb_2.3.5-1ubuntu4_powerpc.udeb locales_2.3.5-1ubuntu4_all.deb nscd_2.3.5-1ubuntu4_powerpc.deb zoneinfo-udeb_2.3.5-1ubuntu4_all.udeb
<jbailey> Is the order of the files.
<jbailey> bbiab.
<lamont> while [ ! -f done ] ; do sleep 60; done
<lamont> :-)
<lamont> Suggested packages:
<lamont>   locales glibc-doc
<lamont> The following packages will be REMOVED:
<lamont>   build-essential* g++* g++-3.3* g++-4.0* libc6-dev* libstdc++5-3.3-dev*
<lamont>   libstdc++6-4.0-dev*
<lamont> The following packages will be upgraded:
<lamont>   libc6
<lamont> 1 upgraded, 0 newly installed, 7 to remove and 1 not upgraded.
* lamont hands the controls back to jbailey.  please provide a usable glibc
<lamont> lunchtime.  back online in a while
<doko> lamont: just only install the lib64* parts
<jbailey> back
<jbailey> lamont-away: I don't understand why libc6-dev and g++-3.3 would've been removed in there...
<doko> found another bug in 3.4 ... will update the files
<jbailey> packaging bug or source code bug?
<doko> packaging
<doko> elmo: please install on davis/breezy-ppc64 the updated packages in ~doko/gcc/install2
<jbailey> Is that where lamont is working?
<elmo> while you're building stuff?
<doko> sure, testsuite is just running
<doko> I'll try to rebuild jbailey's glibc packages on that machine. if you are still there, if they finish, then please install them as well
<elmo> installed
<doko> thanks
<doko> nice, upstream generated libstdc++-v3/testsuite/Makefile.in with automake 1.9, libstdc++-v3/Makefile.in with 1.7
<doko> the install fails after running the testsuite for both -m32/-m64 ...
<doko> jbailey: did you see the gdb build failure in lkh
<doko> powerpc
<jbailey> doko: Ah, nope, lemme look in a sec.
<doko> In file included from /build/buildd/gdb-6.3/bfd/elf.c:6591:
<doko> /usr/include/sys/procfs.h: At top level:
<doko> /usr/include/sys/procfs.h:57: error: parse error before 'elf_vrreg_t' /usr/include/sys/procfs.h:58: error: parse error before 'elf_vrregset_t'
<doko> make[4] : *** [elf.lo]  Error 1
<jbailey> Joy.
* jbailey watches his machine do an apt-get upgrade in the hopes that it has a greater chance of booting.
<jbailey> Had a brownout and my box lost power.  X isn't really interested in starting right now.
<jbailey> There we go...
<doko> elmo: please install on davis/breezy-ppc64 the updated packages in ~doko/gcc/install2/*2.3.5*deb
<elmo> doko: done
<doko> thanks! have a nice weekend
<doko> lamont: deb http://people.ubuntu.com/~doko/ppc64 ./
<jbailey> doko: Does that have glibc and gcc both in there?
<doko> these are the updated packages, both glibc & gcc-3.4. I didn't modify jbailey's sources, updated gcc-3.4 sources can be found at chinstrap:~doko/uploads 
<doko> jbailey: yes
<jbailey> doko: Cool, thanks. 
#ubuntu-toolchain 2005-06-04
<lamont> moo
<lamont> so where am I at now?
<lamont> should I be using chinstrap:~doko/uploads?
<zul> i just love gcc4 "warning: statement with no effect"
<daniels> that's not just gcc4
<zul> ok
<daniels> put 'foo == bar;' into gcc2 and it will say the same thing
<zul> ah...
<zul> its something in jffs2
<fabbione> morning
<\sh> guys, all cxx trans bugs which r uploaded and compiled successfully on all archs..can I close them?
<\sh> (at least my bugs ;))
<fabbione> jbailey: we need to recheck the linking stuff we worked on yesterday, because it introduced some lintian errors;
<fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libgulm.so.0.0
<fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagmamsg.so.0.0
<fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagma_nt.so.0.0
<fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagma.so.0.0
<fabbione> well.. lintian.. just errors :)
<fabbione> and adding -fPIC seems not to be the right solution
<fabbione> or at least it's not enough...
<svenl> jbailey: please try out the kernel found here : 
<svenl>   http://people.debian.org/~luther/ppc64
<jbailey>  short read in buffer_copy (backend dpkg-deb during `./lib/modules/2.6.11-pseries/kernel/fs/lockd/lockd.ko')
<jbailey> Any idea what that means?
<jbailey> gcc-4.0 seems to have gotten rid of __uint128_t support, hmm.
<jbailey> That's the cause of the gdb failure.
<jbailey> Oy.  glibc mainline uses;
<jbailey> typedef struct {
<jbailey>   unsigned int u[4] ;
<jbailey> } __attribute__ ((aligned (16))) elf_vrreg_t;
<jbailey> lamont: ping
<svenl> jbailey: huh ?
<svenl> let me install it here.
<svenl> jbailey: what glibc are you using ? 
<svenl> jbailey: installed fine here. .../source is double, but apart from that it is ok.
<svenl> jbailey: it did install without problems.
<fabbione> jbailey: well the error comes only after we changed the linking method :)
<fabbione> it was working before ;)
<fabbione> svenl: thanks for the patch
<fabbione> jbailey: but i think we have been attacking a little bug with a huge bottle of spray
<fabbione> apparently there is not even a reason to build 64 bit libs :/
<fabbione> but i will need to ask waldi why he did it in the first place (problably due to clvm...)
<svenl> fabbione: 64bit libs -> not ppc64 kernel related ? 
<fabbione> no
<fabbione> nothing to do with that
<fabbione> sparc64 :)
<fabbione> anyway.. time to cook dinner
* fabbione &
<lamont> jbailey: ack
<jbailey> lamont: heya - wanted to check with you on the ppc64 stuff.  I have a fix for glibc that lets gdb build again.
<jbailey> (ppc, gcc-4 bug)
<jbailey> lamont: I've lost track if where we've gotten to, and I don't want to interfere with it.
<lamont> jbailey: where we're at is that if you have a glibc that I should use instead of what I have for the bootstrap, getting it to me within the next hour would be wonderful.
<jbailey> lamont: I'd rather just wait it through.
<lamont> there were some issues - I'll fire off both builds in about an hour before I go to the movies, and then hopefully be able to upload your changes and push the real build when I get back
<lamont> jbailey: that's fine too
<lamont> jbailey/doko: just so both of you have _source.changes for your source, I'll go ahead and upload it once PPC is primed and ready for the actual source upload
<lamont> which should be in ~6-8 hours or so
<jbailey> Nice. =)
* lamont needs to get a little rest in. back in about an  hour.
<jbailey> Good rest, LaMont.
<doko> lamont: updated package (same version) on chinstrap:~doko/uploads
<lamont> doko: roger
<lamont> build launched.  movie-bound.  back in 3-4 hours
#ubuntu-toolchain 2005-06-05
<doko> got it, gcc-4.0 builds biarch on ppc
<desrt> doko = superhero :)
<jbailey> doko: Nice!
<lamont> gcc-3.4 built, 24 min into 44 min avg glibc build
* lamont wanders off for a bit more
<jbailey> lamont: Does that glibc time include that it's a two-pass build now, or is that pased off the old buildd time?
<lamont> is average
<lamont> 00:44:25 (9 entries, sigma 00:06:00)
<jbailey> Right.  I'd expect it to be twice as long.
<lamont> so I should expect something longer, eh?
<lamont> sigh
<jbailey> Well, a little less.
<lamont> not sure if it'll get done before I sleep.. :-)
<jbailey> It won't run the testsuite on the ppc64 set.
<jbailey> So half again as long, I guess.
<jbailey> But that won't be ccached at all.
<jbailey> Although depending on the hardware, I don't think 44minutes sounds terribly ccached.
<lamont> '
<lamont>  /tst-cancel5.out
<lamont> is where it is now
<lamont> with ~22MB of logfile
<jbailey> Can you see into the chroot?
<jbailey> If you look in the topdir of the package, you can see log-*
<jbailey> If there are two builds, then it's in the testsuite.
<jbailey> tst-cancel5 is a good chunk of the way through.
<lamont> log-test-powerpc-linux-gnu-libc
<lamont> and 2 log-build
* lamont becomes hopeful :-)
<jbailey> lamont: What happens after this builds?
<lamont> then I drop that in the chroot, take gcc-3.4 and glibc for that buildd, and upload the source
<jbailey> Nice, so by morning we have ppc64.
<jbailey> Thanks, dude.
<lamont> gcc-3.4_3.4.4-0ubuntu4_powerpc.changes  glibc_2.3.5-1ubuntu4_powerpc.changes
<lamont> \
<lamont> wOOT!
<jbailey> Nice. =)
<jbailey> lamont: So would I get hurt if I asked if someone had considered ibcs emluation for running hpux binaries under hppa-linux? =)
<lamont> there is a kernel config parameter for supporting hp-ux binaries - dunno how dusty it is though
<lamont> jbailey: so where is your signed source.changes??????
<lamont> huh???
<lamont> nm. I'll fix your ppc_changes and use it.
<jbailey> lamont: Eh?  It's in the http://people.ubuntu.com/~jbailey/ppc64 directory with all the rest of it.
<jbailey> Or did you just make that?
<lamont> I just made that
* jbailey is confused.
<lamont> note the owner...
<jbailey> Lovely.
<lamont> you have a powerpc.changes that has source and ppc.  *whap*
<jbailey> I'm curious what % of the time I upload Debian style.  It wouldn't surprise me if it was near 10%
<jbailey> I need to tweak debuild to assume -S
<lamont> well, it bounces when you do... :-)
<jbailey> I know.
<jbailey> It often takes doko poking me about something I said that I uploaded. =)
<jbailey> At the end of the day, I go through my archive emails to make sure, though.
<lamont> source will hit at :30
<jbailey> Hellacool.
<jbailey> ...
<jbailey> hp-ux parameter?
<jbailey> Does it just do the syscall, you provide all the libraries sort of thing?
<lamont> dunno
<lamont> /boot/config-2.4.17-32:CONFIG_BINFMT_SOM=y
<lamont> seems to be gone from 2.6
* lamont prepares to sleep
<jbailey> g'm lamont
<lamont> g'night
<lamont> builds are running, source better make it.. :-)
<infinity> lamont : So, at what point do I become doko and jbailey's bitch, so you can stop this madness?
<lamont> infinity: come monday my time, I'll walk you through the insanity that is bootstrapping... smlnj and some others will want love from you
<lamont> but for tonight, I'm going to sleep
<infinity> lamont : Check.  I have access to all the machines now, so I expect to be jumping headlong into all of this RSN.
<fabbione> morning
<daniels> wmlnj?
<daniels> er, smlnk
<daniels> er, smlnj
<daniels> morning fabbione
<fabbione> whoooo... new gcc and new libc
<jbailey> infinity: There's still a few more biarch configs coming up.  You'll get your practice. ;)
<fabbione> hey jbailey 
<jbailey> Heya Fabio
<fabbione> jbailey: i think the overall biarch crap in the package is useless
<fabbione> but i am still curios to see how to make the linker working properly :)
<jbailey> fabbione: Right, may as well learn from it. =)
<fabbione> exactly :)
<jbailey> I'm off for the night, g'n all.
<fabbione> night Jeff!
#ubuntu-toolchain 2006-06-01
<jbailey> doko: around?
<doko> jbailey: yes
<jbailey> doko: I think you told me you had gcc-4.1 binaries hanging out somewhere.
<jbailey> I'm wondering if I can have them. =)
<doko> jbailey: I told you that in February ;-P
<jbailey> That's probably why I'm not finding it in my grep, I usually only look in recent dates.
<doko> jbailey: apt-get install gcj-4.1
<jbailey> And that'll bring in gcc silently? =)
<doko> yes
<jbailey> luvly, thanks
<jbailey> Oh right.
<jbailey> I even had it installed already.
<jbailey> *sigh*
<doko> jbailey: you don't need g++, correct?
<jbailey> Correct.  g++ is only used for ABI testing.
<jbailey> 4.0 will do.
<jbailey> Thinking of which, libstdc++-v7 is on the LSB agenda.
<jbailey> Have they announced that this is going to show up eventually?
<doko> no, not on the libstdc++ list. do you have pointers?
<jbailey> http://www.freestandards.org/en/LSB_Summit
<jbailey> Just there.
<jbailey> It's a call I've been on all day and will be on tomorrow.
<jbailey> They didn't really go into it, but I was wondering if it was based on some announcement that I had missed.
<doko> ahh, you participated?
<doko> so tell me about libstdc++-v7 ...
<doko> are there streams available from the call?
<jbailey> There are supposed to be.
<jbailey> But they didn't say anything about it specifically.
<jbailey> They just ranted a bit about ABI changes and said that they were goign to keep the C++ interfaces out of the ISO standard.
<doko> anyway, as long as ISV's still ship libstdc++5 based stuff ...
#ubuntu-toolchain 2006-06-02
<jbailey> infinity: The merged packaging diff is nice and small.
<jbailey> infinity: Since all our locales hackery results in one patch to the source and otherwise disabling the locales package, I got to clear out about 60% of the diff. =)
<infinity> \o/
<jbailey> infinity: It's harmless to have stray packages in debian/control, yes?
<jbailey> ISTR that lintian whines, but that all the archive scripts cope.
<infinity> It's generally harmless.
<infinity> Some archive scripts in the past have used the package list in the .dsc to guage package freshness (which is one reason why Packages-arch-specific has binary-only listings), but soyuz doesn't care at all.
<doko> jbailey: any news regarding the lsb meeting?
<jbailey> doko: The group of vendors are currently pointing out adamantly that core, c++ and desktop need to not be merged into a single module.
<doko> would be better :)
<jbailey> doko: No gcj-4.1 in halley's dapper chroot.  I'm surprised. =)
* jbailey files an RT request.
<jbailey> And having screwed my upstream bandwidth for the next 10 minutes, /me stops ignoring the workrave.
<doko> I didn't need it; OOo runs as i386 on ia64
#ubuntu-toolchain 2007-06-01
<jbailey> doko: Hey, you were in Seville.  Would it be hard to get a PPA setup for the toolchain team?
<Mithrandir> jbailey: shouldn't be, no.  Talk to cprov about how to go about it
<jbailey> Mithrandir: Lovely, thanks.
<jbailey> Eh, nice.  It's done. = )
<doko> didn't follow the ppa discussion yet, but yes, that would be very nice
#ubuntu-toolchain 2008-05-27
<DrkR7> hi
<DrkR7> :)
<DrkR7> !mipsel
<DrkR7> ;\
<DrkR7> :\*
<DrkR7> lamont?
<DrkR7> infinity do u know something about compiling for mipsel?
<DrkR7> :\
<infinity> I'm not involved in the Debian mips* ports in any meaningful way, so not really.
<DrkR7> oh Ok :)
<lamont> infinity: 1) get a mipsel box.  2) dpkg-buildpackage. :-)
<infinity> lamont: :P
<infinity> lamont: I never managed (1)... MIPS was the only Debian arch I never had.
<lamont> heh.  I think I have both mips flavors in the house, although the tivo is dead.
<lamont> and the other one hasn't ever actually been installed... still on the TODO list
<infinity> lamont: Hrm, speaking of porting.  Any urge to build interpid/glibc locally on hppa and see if/why the testsuite is hanging?
<lamont> oh joy.
<infinity> lamont: Seems to be stuck on tst-gettext5.sh on primero, though I'll let it run for a few hours for kicks.
<lamont> I'm still catching the local mirror up on i386 bits...
<infinity> lamont: Then again, hanging testsuite is better than the "it was completely FTBFS" situation we had all through hardy...
<lamont> mebbe I'll just work from the town-office tomorrow so that I can fetch intrepid main for more than just i386
<lamont> lol - yeah
<infinity> lamont: Having a glibc released in the last decade would be a big step for hppa. :)
<lamont> feh
<infinity> Hrm, why am I not surprised that things appear to be hanging in the multithreaded gettext tests?
<infinity> And, is the fact that that testsuite is running with "-j 2" (hence running test4 and test5 together) making hppa even less happy? :)
<lamont> multithread... win
<infinity> lamont: I'd actually be curious, if you have a local machine with a few Ubuntu kernels on it, if you can (A) reproduce the hang on a dapper kernel and then (B) see if it magically goes away with a hardy kernel.
<infinity> lamont: If (B) is true, I get an excuse to upgrade all the hppa buildds to hardy.
<infinity> lamont: Oh, wait, primero's not a dapper kernel anyway... It's 2.6.22, whatever that is...
<lamont> dapper world, gutsy kernel.
<infinity> gutsy, apparently.
<infinity> Yeah.
<lamont> fwiw, I have verified that hardy/hppa is love... you have my permission to upgrade primero/kohnen/castilla  (pick on primero first, mk?)
<infinity> I suspect it's not your permission that I need. :)
<lamont> infinity: heh.  my blessing then
<infinity> Though, given that hppa was never supported in any release, I don't imagine I'll get much push-back from elmo.
<lamont> 'struth
<infinity> (I really want to upgrade the PPC and Sparc machines, but we're in this sticky "dapper was supported, but hardy isn't, do we want to switch from a supported release to an unsupported one just to get newer software?" thing...)
<lamont> see - and that's why we must keep hppa/ubuntu alive. :0)
<lamont> ew
<lamont> hppa/ia64 have always been -ports, iirc..
<infinity> I still argue that PPC/Sparc will be happier running new kernels, at the very least, if not also new userspace, but I can see elmo's argument about losing "official" security support, and having to watch like hawks for security bits that are FTBFS, since the Sec Team won't care about them.
<infinity> Or, won't care much.
<infinity> lamont: Anyhoo, the hppa sbuild timeout has been bumped to 600 mins.  If the glibc testsuite is still stuck here after that, I'll pass it off to someone else to look at "properly".
<infinity> (Or I'll get my machine running here, but that requires some cabling and other madness)
<lamont> makes sense
#ubuntu-toolchain 2008-05-30
<lamont> Sorry: LookupError: ("no codec search functions registered: can't find encoding",)
<lamont> doko: what's that mean?
<doko> lamont: ENOCONTEXT
<doko> ?
<lamont> during a package install, it got that.. clearly something is missing from the chroot that should be there..
<lamont> I guess I'll have to go root out more context
<doko> lamont: could that be a python error?
<lamont> 'twas a python package (python-docutils/edgy)
<lamont> and yes, I'm trying really hard to stop caring about edgy... give me a little more time and I'll be better
#ubuntu-toolchain 2008-06-01
<munckfish> Hi guys, I'm experimenting trying to create a cross compiling toolchain for Power/Cell on x86 using the cross build features in our current intrepid gcc/bintutils.
<munckfish> binutils seems to have worked perfectly
<munckfish> But GCC is throwing up problems as it tries to link the biarch stuff for the target platform
<munckfish> have any of you experimented with the cross build features in our packages much?
<munckfish> What's the status of cross building in our gcc 4.3 package?
<munckfish> The reason I ask is, I have converted and installed the ppc64 libc etc for the second arch, but it doesn't seem to be finding them
