[12:53] <lamont> aftermppm
[12:53] <lamont> afternoon, even
[12:53] <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
[12:54] <lamont> so I think that means there's a patch to palo in the future...
[01:05] <doko> ?
[01:06] <doko> lamont: you must be more specific, I can't remember all uploads anymore ;)
[01:07] <lamont> heh
[01:07] <lamont> hppa built a b0gus libgnomedb, which is not installable.
[01:08] <lamont> testing the 'force a rebuild' change to verify that it is a sufficient fix.
[01:08] <lamont> (it depends: libgda2-1 instead of -3...)
[01:08] <lamont> but that was a seb128 upload, not yours
[01:09] <lamont> it's from the "versioned build-deps are too much of an annoyance to bother with" camp.
[01:10] <doko> yes, I'm from the "upload many some will get through" camp
[01:36] <lamont> *grumble*
[03:03] <jbailey> lamont: 'kay.  You have a working palo you can use in the meantime?
[03:03] <lamont> jbailey: hoary's works.
[03:04] <lamont> so it blocks debootstrappable breezy, but then, so do gcc-4.0 et al.
[03:04] <jbailey> debootstrap installs a bootloader? =(
[03:05] <lamont> hrm... no
[03:05] <lamont> nm
[03:06] <jbailey> Ah, good.
[03:06] <jbailey> So we get to worry about that when we're far enough along to think about d-i.
[03:07] <lamont> exactly
[03:07] <lamont> and switching it to build with gcc-3.3 is always a workaround. :-)
[03:07] <lamont> possibly even a working one
[03:37] <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.
[04:08] <jbailey> ajmitch: Pasting error message, good.
[04:08] <ajmitch> jbailey: error message requires some source as context
[04:09] <jbailey> Really?  sometimes it's obivous by the error message.
[04:09] <ajmitch> sctpassociation.h:429: error: expected `)' before '*' token
[04:09] <ajmitch> sctpassociation.h:439: error: ISO C++ forbids declaration of 'SCTPSocket' with no type
[04:09] <ajmitch> sctpassociation.h:439: error: expected ';' before '*' token
[04:09] <ajmitch> that requires a bit of context, i think :)
[04:15] <jbailey> Can you feed the g++ through with gcc -E -dD and find the lines that fail and paste them?
[05:02] <desrt> elmo; mwah.
[05:05] <lamont> dh_strip -pgcj-3.4 -plibgcj5-dev
[05:05] <lamont> doko: does that mean it's gonna build"?
[05:06] <jbailey> lamont: That sounds good.  What's different?
[05:06] <lamont> liberal use of 'killall -9 expect' every time the kernel dropped a signal. :=)
[05:06] <lamont> mind you, that has the effect of killing more than just the parent that will never know it's child died...
[05:07] <lamont> daniels: stop staring.  STFU
[05:07] <jbailey> lamont: LOL
[05:08] <lamont> we just need to get doko to quit writing tests that stress the kerrnel bugs... 
[05:08] <lamont> that or fix the kernel bug
[05:09] <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.
[05:09] <jbailey> lamont: She said she approved of my choice of reading material.
[05:09] <desrt> jbailey; reaping, you mean :)
[05:09] <jbailey> desrt: I think this was a GUI programming book.
[05:10] <desrt> ah
[05:10] <desrt> i'm suprised schools haven't banned the learning of C/unix programming due to the obvious violent/suggestive undertones
[05:12] <lamont> dpkg-genchanges!
[05:17] <lamont> now if i could just get logwatch.sh to actually _exit_ by itself
[05:17] <lamont> Built successfully
[05:17] <lamont> Purging chroot-breezy/build/buildd/gcc-3.4-3.4.4
[05:19] <infinity> lamont : logwatch still doesn't exit on its own?... I meant to fix that bug ages ago.
[05:20] <lamont> infinity: there's an hppa issue with child reaping in the signal case...
[05:21] <lamont> that is, there's a signal bug.. it screws up a few things...
[05:21] <infinity> And fixing the kernel bug is too much to ask? :)
[05:22] <jbailey> infinity: You have spare cycles, don't you?
[05:23] <infinity> jbailey : Personally, or hardware-wise?
[05:23] <infinity> I don't think /I/ have much for spare brain cycles, but I have some machines with spare cycles.
[05:23] <jbailey> infinity: persnoally. =)
[05:27] <lamont> infinity: it's on my list...
[05:32] <lamont> to bed soonish
[05:32] <jbailey> lamont: And you've got glibc in there now as well, right?
[05:33] <lamont> pool/main/g/glibc/libc6_2.3.5-1ubuntu3_hppa.deb
[05:34] <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.
[05:38] <jbailey> lamont: Cry in sadness?
[05:38] <jbailey> Do you still need classic sparc supported?
[05:40] <lamont> given that we don't currently even have a 32-bit kernel, it's not like losing glibc makes a big difference...
[05:40] <jbailey> Do you have a real objection to stacking them with the i386 boxes? =)
[05:40] <infinity> Classic sparc was so slow, it drove me to work on m68k cause I craved a modern and speedy architecture.
[05:53] <lamont> jbailey: feh.  I'll ebay 'em if they're totally dead.  Otherwise they can be my native debian test boxes... :-)
[05:53] <lamont> g'night
[05:57] <fabbione> morning
[05:57] <fabbione> night lamont
[06:11] <jbailey> fabbione: We were just talkimg about Sparc. =)
[06:12] <jbailey> Anyhow, you sohwing up means bedtime for me. =)
[06:12] <jbailey> g'n!
[06:12] <fabbione> ehhe
[06:12] <fabbione> good night jb :)
[06:18] <infinity> That's a clever avoidance technique.
[06:18] <infinity> "I, uhh, shouldn't stay awake past when you get up... Yeah, that's it!"
[07:39] <fabbione> yay
[07:39] <fabbione> gcc-4.0 did build fine too :)
[07:39] <fabbione> doko, jbailey: when can i expect a ppc64 toolchain available?
[07:40] <fabbione> possibly updated and installed in a breezy-ppc64 chroot?
[09:26] <doko> good morning
[10:40] <doko> daniels: with which upload will the headers move to /usr/include/X11?
[10:52] <daniels> doko: as I've explained before, as each module moves out
[10:52] <daniels> there will be no one upload
[10:58] <doko> so when will xinerama be available in /usr/include/X11
[11:21] <daniels> doko: when I modularise libxinerama
[11:22] <doko> daniels: looks like I'm pestering? ;-) just want to know, when it will be in the archives
[11:24] <daniels> dude, I really don't know
[11:24] <daniels> i'll let you know when it is, though
[12:04] <\sh> doko: thx for the helping hand in uploading :)
[12:10] <\sh> but where is licoin20c102 in the coin2 package? 
[12:11] <chmj> ermm 
[12:11] <chmj> you stole that for me :P 
[12:13] <\sh> chmj: what? ;)
[12:13] <\sh> there was no name on the list ;) and there is no libcoin20c102 in the debian/control :(
[12:14] <Kamion> er ... libcoin20 is in coin, libcoin40 is in coin2
[12:17] <\sh> why is doko wrinting something like this in coin2?
[12:18] <\sh> anyway..enough work todo
[12:20] <chmj> libcoin40 replaces libcoin20 ;-) 
[12:22] <\sh> then can be...but then I don't understand his remark: http://bugzilla.ubuntu.com/show_bug.cgi?id=11007
[12:22] <\sh> s/then/that/
[12:28] <chmj> doko, ping ?
[12:30] <doko> hmm, I'll have a look, was late yesterday ;)
[12:30] <\sh> doko: but u rock like a hurricane :)
[12:31] <chmj> heh 
[12:32] <\sh> Extra for doko, I will disturb our holy free day with
[01:19] <jbailey> fabbione: Are you in a rush for ppc64 stuff?
[01:20] <fabbione> jbailey: we need to get ppc64 kernels out as soon as we can.. if we can
[01:20] <fabbione> the changes are quite a lot to test
[01:20] <fabbione> so it's not exactly an easy path to follow
[01:22] <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.
[01:23] <fabbione> ehehe
[01:51] <doko> jbailey: not the package, or the library?
[01:52] <jbailey> doko: Both, so I'm guessing I was overenthusiastic in disabling things.
[02:00] <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.
[02:01] <doko> WITHOUT_LANG=ada,java dpkg-buildpackage works
[02:01] <jbailey> That still causes libffi,fortran and g++ to be built.
[02:02] <jbailey> For the initial tests I had been avoiding those.
[02:02] <jbailey> I've also been using WITHOUT_CHECK until it builds all the pieces.
[02:23] <jbailey> I can never remember if zul was they gatekeeper or the keymaster.
[02:24] <jbailey> -y
[02:24] <zul> gatekeeper
[02:25] <jbailey> Cool. =)
[02:26] <jbailey> Bah, forgot pascal in the languages to skip
[02:26] <zul> heh...i never did pascal :)
[02:26] <doko> jbailey: WITHOUT_LANG=ada,java,c++,objc,f77,treelang dpkg-buildpackage
[02:27] <jbailey> Ah, didn't you?  It think it was my 3rd language.  basic then z80 assembler first.
[02:27] <doko> it's f77, I'll add ffi
[02:27] <jbailey> debuild -e WITHOUT_LANG=ada,java,c++,f77,treelang,pascal,objc -e WITHOUT_CHECK=y
[02:27] <jbailey> is what I was about to use.
[02:30] <lamont> basic, 6502, z80, hp21mx asm, hpl (hp9825), spl (hp3000), hp3000 asm, cobol (gak), pascal, modcal, hppa asm, C, hp41 ucode
[02:30] <lamont> I think I didn't forget any before pascal. :-)
[02:31] <doko> lamont: there's not much after pascal :p
[02:32] <lamont> doko: I was getting old at that point. :-)
[02:32] <jbailey> basic, z80, pascal, i386 (*cRy*), telix scripting, C, javascript, c++, php, python, Java (including all the fluffy languages)
[02:32] <lamont> somewhere in there (around kobol timeframe) is DEAL (which looks like algol with fortran printing)
[02:32] <jbailey> YOU MEAN IT'S ALL CAPS AND WHITESPACE SENSITIVE? =)
[02:33] <lamont> jbailey: I only learned it well enough to translate an app or 3 from DEAL to COBOL. :-(
[02:33] <jbailey> lamont: Javascript is the only one of those that I haven't compiled to native code at some point.
[02:33] <lamont> really
[02:33] <jbailey> lamont: Or to some sort of bytecode, I guess (for python)
[02:34] <jbailey> telix's SALT language was terribly cool.  Packet switched networks are lovely when you're still covered by the young offenders act.
[02:37] <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 ...
[02:39] <doko> ok, working around the xorg reorg, building OOo
[02:39] <infinity> jbailey : I used telemaet and TMscript, but SALT was fun too...
[02:41] <Kamion> hmm, BASIC z80-asm x86-asm Pascal C Java ML Prolog arm-asm Perl C++ Python, I think
[02:41] <doko> nice, finally someone for assigning the C++ bugs to ;-)
[02:42] <Kamion> sod off :-)
[02:42] <jbailey> What' Kamion said
[02:42] <jbailey> (I can't pull it off why my accent)
[02:42] <Kamion> I never used the C++ standard library much
[02:42] <jbailey> Eww.  You're one of *those* C++ coders. =)
[02:43] <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
[02:43] <Kamion> and it was so much more comprehensible than libstdc++, anyway. :)
[02:44] <jbailey> I tried desperately to add Scheme to my list for almost a year before deciding that the pain just wasn't worth it.
[02:44] <doko> lamont: please yould you trow all the gnome stuff at the buildd's again, once libenchant1c2 is in main?
[02:46] <doko> yesterday I started a gcc build on my powerbook.
[02:46] <doko> getting too hot, the computer turned off ...
[02:50] <jbailey> Ithought powerbooks were supposed to have decent fans for that sort of thing.
[03:00] <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?
[03:15] <doko> biarch is turn on?
[03:15] <doko> biarch is turned on?
[03:16] <doko> and with_lib64gcc is set?
[03:22] <jbailey> yes to both.  I know biarch is set because the resulting compiler includes the ability to do -m64
[03:22] <jbailey> (It just can't find the missing lib64c_s)
[03:23] <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.
[03:24] <doko> and a find build -name libgcc* doesn't find anything 64bit like?
[03:26] <jbailey> Oh, hmm, it's build/gcc/libgcc_s_64.so
[03:26] <jbailey> I have been grepping the build log for lib64gcc
[03:27] <doko> look at debian/rules.defs, if with_lib64gcc is defined
[03:27] <jbailey> So it's there with no package created.  Excellent.  That gets back into the realm of things I can track. =)
[03:27] <jbailey> ifeq ($(DEB_TARGET_GNU_CPU),powerpc)
[03:27] <jbailey>   biarch := yes
[03:27] <jbailey>   with_lib64gcc := yes
[03:27] <jbailey>   with_lib64cxx := yes
[03:27] <jbailey> endif
[03:28] <jbailey> I know it has to do doing that because of rules2:
[03:28] <jbailey> ifeq ($(findstring powerpc-linux,$(DEB_TARGET_GNU_TYPE)),powerpc-linux)
[03:28] <jbailey>   ifeq ($(biarch),yes)
[03:28] <jbailey>     CONFARGS += --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
[03:28] <jbailey> Nothing else would be setting biarch.
[03:29] <doko> found it
[03:30] <doko> debian/rules.d/binary-libgcc.mk: I assume, if you don't want a normal libgcc, you neither want a 64bit libgcc.
[03:30] <doko> well, you can argue about it ...
[03:31] <jbailey> Right.  Ideally this should be provided by gcc4.
[03:31] <jbailey> The logic's usually right.
[03:35] <jbailey> Mmm, I don't see that.  I see if biarch, files_gcc += 4{gcc_lib_dir}/64/stuff.
[03:36] <jbailey> Where is it taken away if you're not building a regular libgcc?
[03:38] <chmj> i think the meaning of "biarch" has just got a lil confusing to me 
[03:40] <jbailey> chmj: Heya Charles.
[03:40] <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.
[03:40] <jbailey> Some of the biarch setups are really logical, like ppc and ppc64, sparc and sparc64.
[03:41] <jbailey> Some of them are less obvious, like i386 and ia64, or i386 and amd64.
[03:41] <chmj> ohh yes 
[03:42] <doko> jbailey: with_libgcc is set to no in 3.4, move the 64bit test at the top out of the ifeq
[03:43] <jbailey> DOH, binary-libgcc, not binary-gcc
[03:43] <jbailey> You're in a maze of twisty passages, all alike.
[03:44] <jbailey> Lesse if -nc is my friend today.
[03:45] <jbailey> It is, lovely.
[03:46] <jbailey> Need to fix symlnks and such.
[03:46] <jbailey> doko: How do you want the patch to the debian/ directly?
[03:46] <jbailey> directory
[03:46] <jbailey> Bah.
[03:46] <jbailey> Time for a walk soon.
[03:48] <doko> just email the diff 
[03:53] <jbailey> Cool, afk a couple minutes.
[04:23] <infinity> doko : Did you have a list of stuff you wanted thrown back at the buildds?
[04:24] <doko> infinity, no not explicitely, I was working from breezy_probs
[04:27] <jbailey> infinity: Are you so empowered now?
[04:27] <jbailey> infinity: If you are, I swear we're dragging you onto some doko-jbailey friendly timezone. =)
[04:28] <doko> infinity: prove your power, throw back sound-juicer! ;-)
[04:34] <infinity> Alright, kicked.
[04:34] <infinity> jbailey : Yes, I am.
[04:34] <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. :)
[04:37] <doko> well, they know that 3 out of 4 won't get borked ;)
[04:38] <infinity> Or that 1 out of 4 won't. ;)
[04:38] <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.
[04:39] <infinity> My god, the power.  I wish I had w-b rights on all the Debian arches.
[04:39] <infinity> Doing a give-back on all arches at once felt kinda... Tingly.
[04:40] <jbailey> I think I might still have it on sparc in Debian. =)
[04:40] <infinity> Of course, I'm not sure kicking it back was such a fantastic idea..
[04:41] <fabbione> infinity: congratulation :)
[04:41] <jbailey> infinity: It's not m68k, these things can cope with the odd mistaken give-back
[04:44] <infinity> jbailey : Thpt. :)
[04:44] <jbailey> infinity: So does this mean you'll be my build bitch for biarch ppc64?  Svenl's just confirmed it works for me. =)
[04:47] <infinity> svenl confirmed that it works.. for.. you?
[04:48] <jbailey> I don't have a ppc64 kernel.
[04:48] <infinity> There's something very odd about that sentence.
[04:48] <jbailey> He ran my hello world binary.
[04:48] <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.
[04:48] <jbailey> No.
[04:49] <jbailey> Notice that I couldn't test the ppc64 binary but produced one. =)
[04:49] <infinity> Sure, but anything with a test suite would flop.
[04:49] <jbailey> Bah, testsuites.
[04:49] <infinity> Yeah.  For pussies, I know.
[04:49] <jbailey> If it's not in the bootstrap path, who needs a testsuite? =)
[04:49] <jbailey> <sensored comment about pussies and testsuites>
[04:50] <jbailey> Oh wait.
[04:50] <jbailey> That wasn't a very good sensor, was it?
[04:50] <infinity> I assume you meant censor.
[04:50] <infinity> Cause sensored brings odd images to mind.
[04:50] <jbailey> Right. =)
[04:50] <infinity> Of you feeling... pussies.. and testsuites.
[04:51] <infinity> I can only imagine your wife doesn't like where this is going.
[04:51] <jbailey> Anytime now I suspect this should shift from a work channel to a /query window. =)
[04:51] <doko> jbailey: would you mind, if I add some more patches to 3.4?
[04:51] <infinity> Nah, query schmery, we can just stop talking about it.
[04:51] <jbailey> doko: Not at all are you going to make fabio scream^W^W^Wupload it, or send me the patches?
[04:51] <svenl> infinity: i run his ppc64 binaries on the augsbourrg 8-way power5 in pure-64 mode box.
[04:52] <svenl> fabbione: what is the status of the ubuntu kernel on ppc64 ? 
[04:52] <infinity> jbailey : Anyhow, what do you need me for for biarch stuff, when you can build on your own?
[04:52] <doko> jbailey: send me the diff, then I'll send you my diff back
[04:52] <svenl> fabbione: did you already work on it, want me to have a look or whatever ? 
[04:52] <doko> ehh, I mean, the merged one ...
[04:53] <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
[04:56] <fabbione> svenl: without a toolchain i can't do it.
[04:56] <fabbione> svenl: when i tought we had one, the chroot was broken.. so i couldn't install all the kernel build-deps
[04:56] <fabbione> that's why i pinged jb and doko this morning again
[04:57] <fabbione> but clearly.. if you want to do something and help, you are welcome
[04:57] <jbailey> fabbione: Well, you have a toolchain sitting in my p.u.c directory now if you want it.
[04:57] <fabbione> jbailey: can we get installed in a breezy chroot on davis?
[04:57] <fabbione> if so i can start to work on them from monday
[04:57] <fabbione> tomorrow is userland day
[04:58] <fabbione> and i really plan NOT to touch the kernel
[04:58] <jbailey> With any luck they'll be in the archive tomorrow.
[04:58] <fabbione> ok than i won't bother to rush
[04:58] <fabbione> i will wait them as naturale upgrade
[04:59] <fabbione> jbailey: but i will need to know the versions of packages i need to b-d at least
[04:59] <jbailey> fabbione: Yup.  Should hopefully be really obvious by then.
[04:59] <fabbione> jbailey: ehehe
[05:00] <infinity> doko : Any others you want to give the boot?  Or should I just pull a lamont and give-back everything from main?
[05:05] <doko> infinity, no, currently not, have to fix things first ...
[05:06] <jbailey> doko: Umm.  Is debian/README.Debian autogenerated? =)
[05:08] <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.
[05:08] <infinity> But I'm not really sure who'll be here first. :)
[05:09] <jbailey> infinity: We're moving you to an island in the mid-atlantic. =)
[05:12] <doko> jbailey: yes
[05:13] <jbailey> doko: Oh good.  =)
[05:21] <infinity> jbailey : Uhm.  I don't think I like that idea so much...
[05:21] <infinity> jbailey : If you manage to get Mark to override my protests, at least score me a massive raise along with it.
[05:21] <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?
[05:23] <infinity> Right, so I hate you now.
[05:23] <jbailey> doko: http://people.ubuntu.com/~jbailey/biarchppc.diff
[05:23] <jbailey> infinity: You hated me before.  It was a leap of faith to share a room with you at debconf.
[05:23] <jbailey> Trusting that you were still Canadian enough to not kill me in my sleep.
[05:24] <svenl> fabbione: ok, so i will be the first one to build ppc64 kernels.
[05:24] <infinity> Also, it's 1:23am, and I have a girlfriend who wants me either cuddling or dead, and I'd rather the former.
[05:24] <jbailey> But I had an Inuit carving handy, just in case.
[05:24] <svenl> fabbione: the baz infocation you gave me earlier is a good starting point to do that, right ? 
[05:26] <fabbione> svenl: it's the same point i will start from (more or less)
[05:26] <fabbione> svenl: more or less is determined by other guys committing to it for other stuff
[05:26] <doko> jbailey, btw, debian/control is generated as well ...
[05:26] <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.
[05:27] <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.
[05:27] <svenl> fabbione: ok.
[05:28] <fabbione> svenl: i suggest you to learn how to branch and export your local archive
[05:28] <fabbione> svenl: so at a later stage i can merge directly from your archive
[05:28] <fabbione> other than starting a diff -u mess
[05:28] <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 ? 
[05:29] <svenl> somewhere even.
[05:29] <fabbione> svenl: ENOTIME
[05:29] <fabbione> svenl: changing naming is the last of the problems :)
[05:29] <svenl> fabbione: hehe.
[05:29] <fabbione> there is more that needs to be done :)
[05:29] <svenl> fabbione: do you have a summary of the decisions we took back then though ? 
[05:30] <fabbione> svenl: <fabbione> powerpc, powerpc-smp, pseries-smp, pseries-power4,
[05:30] <fabbione>            pseries-power4-smp, iseries-smp
[05:31] <fabbione> that's what we agreed before we decided to kill power4
[05:31] <svenl> ok.
[05:31] <svenl> so nothing more than what we discussed.
[05:31] <fabbione> so remove power4 from there
[05:31] <fabbione> nope
[05:31] <fabbione> i don't talk alone.. usually
[05:34] <svenl> fabbione: :)
[05:34] <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.
[05:34] <jbailey> I talk to myself, my wife finds it funny.
[05:35] <jbailey> Apparently since UDU I now swear at my computer in an English accent
[05:35] <jbailey> (thanks elmo, keybuk, and kamion) =)
[05:35] <fabbione> jbailey: i do it, but only when i am extremely tired. it helps me focusing
[05:35] <fabbione> my wife thinks it's time to take out of the cave when i do that
[05:37] <svenl> Oh, next step is to bring the biarch stuff to 4.0 i guess.
[05:38] <doko> jbailey: how's the libc6-dev-powerpc package called?
[05:39] <jbailey> libc6-ppc64 and libc6-dev-ppc64
[05:39] <svenl> jbailey: would libc6-ppc64-dev not make more sense ?
[05:39] <jbailey> svenl: I'd have thought so, but this matches how it was done for the other archs.
[05:40] <svenl> bah.
[05:41] <svenl> luther@trick:~$ file ./sventest
[05:41] <svenl> ./sventest: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.0, statically linked, not stripped
[05:41] <svenl> luther@trick:~$ ./sventest
[05:41] <svenl> Hello 64bit World!
[05:41] <svenl> Ok, built fine for me, now is kernel building time.
[05:42] <svenl> doko, jbailey: thanks for the great job you did on this.
[06:14] <doko> jbailey, infinity, lamont: gcc-3.4 on chinstrap:~doko/uploads/
[06:16] <jbailey> doko: What magic does this one have?
[06:16] <jbailey> like, is the ppc64 stuff included?
[06:17] <doko> lamont, infinity: please kick back gnome-panel on amd64
[06:17] <doko> jbailey: yes
[06:19] <jbailey> doko: Cool, thanks.
[06:20] <doko> but the i386-biarch wasn't in the patch ;-P
[06:22] <jbailey> Bah, the build failed after stage2. =(  /me checks to see what it died on.
[06:23] <jbailey> doko: Can I post this build log somewhere to get your help looking at it?
[06:23] <doko> yup
[06:25] <jbailey> http://people.ubuntu.com/~jbailey/gcc-3.4_3.4.4-0ubuntu3_powerpc.build 
[06:26] <doko> yes, trying to run a 64bit test program on a 32bit kernel
[06:26] <jbailey> Right, but why?
[06:26] <jbailey> And after stage3...
[06:26] <jbailey> At that point everythin ought to be built.
[06:31] <doko> yes, it's a "sanity" check, before the runtime libs are built
[06:33] <doko> is the i386-biarch patch applied?
[06:33] <jbailey> stamps doesn't have anything that matches *biarch*
[06:33] <jbailey> But I see it in the root directory.
[06:37] <doko> yes, it's disabled, because it didn't work with amd64-libs-dev
[06:40] <doko> so you have to re-enable biarch in debian/rules.defs and rebuild.
[06:40] <jbailey> Sorry - this is still ppc/ppc64 I'm working on.
[06:41] <jbailey> I was doing the full build rather than the just C one that I had been doing before.
[06:43] <doko> hmm
[06:53] <doko> please could you put your current glib packages online?
[06:54] <jbailey> http://people.ubuntu.com/~jbailey/glibc/
[06:54] <jbailey> http://people.ubuntu.com/~jbailey/gcc/
[06:54] <jbailey> for the C-only, no-testsuite-run compiler.
[07:26] <svenl> jbailey: it failed again at the same place :
[07:27] <svenl> Adding multilib support to Makefile in ../../../src/libstdc++-v3
[07:27] <svenl> multidirs=64 nof
[07:27] <svenl> with_multisubdir=
[07:27] <svenl> Running configure in multilib subdirs 64 nof
[07:27] <svenl> pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux/libstdc++-v3
[07:27] <svenl> Running configure in multilib subdir 64
[07:27] <svenl> pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux
[07:27] <svenl> mkdir 64
[07:27] <svenl> ...
[07:27] <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
[07:27] <svenl> checking for C compiler default output file name... a.out
[07:27] <svenl> checking whether the C compiler works... configure: error: cannot run C compiled programs.
[07:27] <svenl> doko: do you have any idea ?
[07:30] <doko> svenl: no
[07:37] <svenl> jbailey: :)
[07:37] <svenl> doko: any hint on where i can check in the Makefiles/whatever what it is doing here ?
[07:39] <doko> svenl: yes
[07:39] <svenl> well, where do i check the code doing that ? 
[07:40] <svenl> in src/libstdc++-v3
[07:40] <svenl> ?
[07:41] <svenl> in the configure script there i guess. Which do i investigate ? configure.ac or .host ? 
[07:43] <svenl> maybe we should set cross compiling in src/libstdc++-v3/configure, or add a special case for biarch if on ppc32 arch ?
[07:44] <svenl> code is :
[07:44] <svenl> # Check the compiler produces executables we can run.  If not, either
[07:44] <svenl> # the compiler is broken, or we cross compile.
[07:44] <svenl> echo "$as_me:$LINENO: checking whether the C compiler works" >&5
[07:44] <svenl> echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6
[07:44] <svenl> # FIXME: These cross compiler hacks should be removed for Autoconf 3.0
[07:44] <svenl> # If not cross compiling, check that we can run a simple program.
[07:44] <svenl> if test "$cross_compiling" != yes; then
[07:44] <svenl>   if { ac_try='./$ac_file'
[07:44] <svenl>   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
[07:44] <svenl>   (eval $ac_try) 2>&5
[07:44] <svenl>   ac_status=$?
[07:44] <svenl>   echo "$as_me:$LINENO: \$? = $ac_status" >&5
[07:44] <svenl>   (exit $ac_status); }; }; then
[07:44] <svenl>     cross_compiling=no
[07:44] <svenl>   else
[07:44] <svenl>     if test "$cross_compiling" = maybe; then
[07:44] <svenl>         cross_compiling=yes
[07:44] <svenl>     else
[07:44] <svenl>         { { echo "$as_me:$LINENO: error: cannot run C compiled programs.
[07:44] <svenl> If you meant to cross compile, use \`--host'.
[07:44] <svenl> See \`config.log' for more details." >&5
[07:44] <svenl> echo "$as_me: error: cannot run C compiled programs.
[07:44] <svenl> If you meant to cross compile, use \`--host'.
[07:44] <svenl> See \`config.log' for more details." >&2;}
[07:44] <svenl>    { (exit 1); exit 1; }; }
[07:44] <svenl>     fi
[07:45] <svenl>   fi
[07:45] <svenl> fi
[07:45] <svenl> echo "$as_me:$LINENO: result: yes" >&5
[07:45] <svenl> echo "${ECHO_T}yes" >&6
[07:45] <svenl> doko, was this the place you also had problems with ?
[08:24] <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.
[08:30] <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.
[08:31] <doko> jbailey: it the case, where the 64bit libs are built. so the compiler call is correct
[08:32] <doko> I'm currently building on 64bit kernel, but it may take a while. it's 600Mhz
[08:44] <svenl> doko: the configure and not configure.ac or something ?
[08:45] <doko> svenl: it's a test from autocof, you can only edit it in configure
[09:05] <svenl> doko: autoconf sucks :/
[09:05] <svenl> doko: it will not be automagically be readded ? I need to prepare a dpatch, right ? 
[09:05] <doko> svenl: yes
[09:05] <svenl> doko: this should be enough, right ?
[09:05] <svenl> -if test "$cross_compiling" != yes; then
[09:05] <svenl> +if false; then
[09:06] <doko> hmm, maybe just if false && ..., so we have a bit of "documentation" =)
[09:06] <svenl> doko.
[09:06] <svenl> Ok.
[09:07] <svenl> doko: there is no 00list to add patches to ? 
[09:07] <doko> debian/rules.patch
[09:10] <svenl> in generic debian patches, or ppc specific ?
[09:12] <doko> ppc specific
[09:12] <svenl> already did :)
[09:13] <svenl> ok, build launched, will take some time.
[09:14] <svenl> doko: how easy do you think it will be to port the biarch stuff to gcc-4.0 ?
[09:15] <\sh> hmm...can it be, that verdansky is out of sync/control?
[09:15] <\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
[09:16] <Kamion> \sh: no, libqscintilla5c2 isn't in main
[09:17] <Kamion> which is because python-qt3 and libqscintilla-dev are scheduled for demotion to universe
[09:17] <Kamion> (nothing in main uses them at the moment)
[09:18] <doko> Kamion: should we promote mysql-4.1 libs to main?
[09:18] <Kamion> doko: not on anastacia's list?
[09:18] <Kamion> libmysqlclient14?
[09:19] <doko> yes
[09:19] <doko> libdbd-mysql-perl is failing
[09:21] <doko> docbook2x is needed as a build dep for gnome-doc-utils
[09:21] <Kamion> python-qt3 was only in main in hoary because hplip build-depended on it
[09:22] <\sh> Kamion: when it will be moved to universe?
[09:22] <Kamion> \sh: dunno, I'm leaving it to elmo
[09:22] <doko> Kamion: no, it was a depends, I did split out the UI in another package
[09:23] <Kamion> doko: hplip.deb was in universe in hoary
[09:23] <Kamion> and it was a build-depends too
[09:25] <doko> backuppc depends on wwwconfig-common, should this enter main?
[09:26] <Kamion> wwwconfig-common is scary crack, I'd rather defer and possibly avoid
[09:26] <Kamion> I think we've avoided it in the past
[09:26] <doko> the hplip debian maintainer didn't accept the patch removing the build-dep
[09:27] <Kamion> doko: oh, germinate's only re-run once a day, it'll show up tomorrow
[09:27] <Kamion> I'm operating in dummy mode and would rather not do anything until anastacia tells me I can :-)
[09:28] <doko> ;)
[09:28] <doko> where can I run anastacia?
[09:29] <Kamion> only if you have an account on jackass
[09:29] <Kamion> hm, I guess libmysqlclient14* would be "obvious"
[09:30] <Kamion> doko,elmo: ok, libmysqlclient14 libmysqlclient14-dev promoted
[09:33] <doko> Kamion: fine
[09:34] <Kamion> I don't know if it needs mysql-common-4.1 - dependencies suggest not, but we'll see
[09:35] <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 ? 
[09:36] <jbailey> svenl: The gcc4 one in the archive ought to work fine.  What's the issue?
[09:36] <svenl> jbailey: am building a sarge chroot with the stuff in it to try.
[09:37] <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 ? 
[09:37] <doko> svenl: it's in experimental
[09:37] <svenl> doko: yes, but do we really need the 4.0 libgcc ?
[09:38] <doko> as soon as 4.0 enters sid
[09:39] <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 ? 
[09:39] <doko> lamont, infinity: please push gnome-panel on amd64
[09:39] <doko> svenl: more symbols
[09:39] <svenl> I mean, you told me that jbailey had trouble building glibc with 4.0, is this still true ? 
[09:39] <svenl> doko: ok.
[09:39] <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.
[09:40] <svenl> doko: but for a sarge chroot, that should not be an issue.
[09:40] <svenl> jbailey: bah :)
[09:55] <doko> Kamion, lamont: FTSTR why gnome-media is not getting installed on the amd64 buildd as a b-d of sound-juicer
[09:56] <Kamion> Get:4 http://jackass.ubuntu.com hoary/main gnome-media 2.9.90-0ubuntu1 [2042kB] 
[09:56] <Kamion> it built fine?
[09:57] <Kamion> oh, wrong version
[09:58] <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
[09:59] <doko> it's a lamont thing ...
[10:50] <svenl> jbailey, doko: do you want me to send you the dpatch ? 
[10:56] <jbailey> svenl: I had c++ disabled for the original build.
[10:56] <svenl> jbailey: ah ...
[10:56] <svenl> do you wnat the patch then ? 
[10:56] <jbailey> svenl: I'd like to review it but will wait for doko's ok on it.
[10:57] <svenl> bah.
[10:57] <svenl> he counseled it to me, and it just does one if false && ... instead of the cross check.
[10:57] <svenl> and is enabled only on ppc, so i think it is ok. I added some comment line too though.
[10:59] <doko> Kamion, elmo: debconf b-d's on libintl-perl, u->m needed
[11:02] <doko> svenl: send it, but I won't do anything about it today
[11:03] <svenl> doko: no problem, just wanting to avoid duplication, even if it is trivial.
[11:03] <svenl> doko: what email address ?
[11:03] <svenl> (ubuntu-toolchain@lists.ubuntu.com ? :)
[11:04] <jbailey> Dear gods, tell me there isn't an ubuntu-toolchain email list...
[11:04] <svenl> jbailey: :)
[11:05] <svenl> jbailey: or as bug report in bugzilla to gcc-3.4 ?
[11:05] <svenl> jbailey@ubuntu.com, doko@ubuntu.com should do i guess.
[11:06] <doko> Kamion, elmo: libwpd8 is needed by abiword-plugins, u->m
[11:08] <jbailey> svenl: Yes, that'll get to me.
[11:09] <doko> svenl, yes
[11:13] <svenl> you have mail.
[11:18] <jbailey> Oh gross.
[11:19] <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
[11:20] <svenl> jbailey: as said, it is a quick and ugly hack doko mentioned.
[11:21] <svenl> jbailey: its powerpc64-linux btw :)
[11:22] <jbailey> svenl: You can feed ppc64-linux to config.sub and it expands it to powerpc64-unknown-linux-gnu =)
[11:24] <svenl> jbailey: he :)
[11:24] <svenl> ok, i am off to bed now, while both my machines build.
[11:24] <jbailey> g'n Sven!