#ubuntu-toolchain 2005-07-01 <doko> fabbione: ping <daniels> doko: i don't think he's going to be back until monday <doko> ahh, ok <zul> quiet today <jbailey-gcc> fabbione: *pout* New kernel upgrade breaks my suspend-to-ram... <lamont__> elmo: ping <jbailey-gcc> g'm LaMont <lamont__> morning jbailey-gcc #ubuntu-toolchain 2005-07-02 <fabbione> morning <infinity> Morning, Fabio. <fabbione> hey infinity <fabbione> AYE <fabbione> they will upgrade my adsl soon <fabbione> 6Mb/768k <infinity> See, now I hate you. <infinity> I'm lauren32@example.com/256 for at least the next 6-9 months. Maybe longer. <fabbione> i didn't decide to upgrade <fabbione> my ISP did lower the prices <fabbione> and they did send me a notification that they will increase my bw for the same price <fabbione> from 2M/512 to the above <fabbione> i can decide to lower the price and keep the bw :) <fabbione> but more bw > * * fabbione increases the ubuntu and debian mirrror partitions a bit more <infinity> I assume you just carry partial mirrors? <Riddell> doko: did you see that wv2 needs recompiled for gcc 4? <daniels> christ, 6mb <daniels> infinity: armadale doesn't have the iinet dsl2 infrastructure? <elmo> infinity/lamont? <elmo> sorry, my bad. <elmo> laminity: ? <elmo> daniels: I got suckered into upgrading a breezy chroot and have a fucked X (libx11-6 vs xlibs-data, file overwrites and conflicts) <elmo> daniels: is there a safe way to get out of this, or shall I just brute --force my way out? <Mithrandir> elmo: --force-depend-ing in the libx11-6, then just running apt-get -f install works, iirc. <elmo> Mithrandir: good call, that seems happy. thx <daniels> elmo: yeah, need to fix that, thanks <infinity> elmo : You rang? <infinity> daniels : No, our exchange (Malvern) is scheduled to get iinet DSLAMs in Q3 this year. <daniels> nice <infinity> elmo : Also, when do my two dead buildds get CPR? :/ <elmo> infinity: tomorrow, I hope <elmo> infinity: hoary-backports is ready <elmo> on the katie side - are buildds ready? <daniels> you're shitting me <infinity> They will be first thing in the (my) morning, tomorrow. <daniels> backports. <infinity> daniels : Bring it up tomorrow, if you want to hear a drunken rant on the subject. <daniels> sounds like a plan <daniels> it sounds like arseloads of crack though <daniels> (and I do mean literal arseloads -- snorting it off a hooker's arse, in this case) <infinity> elmo : Does it allow source-only uploads from the main keyring, or only automated source "copies"? <elmo> nothing yet <elmo> well, everything atm <elmo> I'm not sure how best to tie it down and/or import source atm <infinity> Right. :) <infinity> Yeah, me neither. <infinity> The whole thing is kinda making me want to cry. I don't think anyone's really thoguht this through. <infinity> ie: Without compartmentalising this in small "package groups" (ie: backport foo, bar, and baz, which al interdepend, but nothing else, lather, rinse, repeat), are we not going to end up with all backports being built against each other to the point where hoary-backports looks a lot like "breezy on hoary's glibc"? <infinity> I'm frightened. :) <infinity> Oh well. I'll whine later. I'll make the buildds go in ~12 hours, and we can shove some source packages through to make sure it's happy or something. <fabbione> infinity: ahhaah <fabbione> "breezy on hoary's glibc"? <fabbione> infinity: what does make you feel so sure that new glibc won't land in backports? <infinity> Because we'll blacklist it? <jbailey> fabbione: If it does, I quit. =) <infinity> I'd prefer to blascklist all of main, but I don't think that'll fly. :/ <fabbione> but new glibc are sooooo 31337 * infinity -> anywhere without a computer. <fabbione> cya infinity <fabbione> i am going to stop soon too <fabbione> for once i want to try the experience to stop within the contract working hours * fabbione goes offline for a little while <chmj> jbailey, <jbailey> Heya Charles <chmj> jbailey, ping <chmj> hello <lamont> elmo: buildd's are just waiting to be told to add it to the dist list <lamont> unless infinity already did that <lamont> hrm... crested doesn't seem to be happy <fabbione> hey lamont <fabbione> isn't crested one of the 2 dead amd64 buildd? <fabbione> together with king <jbailey> lamont: Heya, lagging on the gcc-opt stuff I owe you, I'll try soon. <lamont> yeah <doko> jbailey: I was looking into multiarch support, and discovered, that we always include i486-linux, even if we are compiling with -m64. Mithrandir did tell me you do know about it. So currently we cannot add multiarch support until it's fixed. <jbailey> doko: ISTR that I also suggested how to fix it... I can cook up a patch and pass it around for review. <doko> jbailey: did I miss something? I cannot find a report or an email <jbailey> No, when I told Tollef. <doko> ahh, ok <doko> infinity: ping #ubuntu-toolchain 2005-07-03 <infinity> doko : pong. <fabbione> morning <doko> infinity, lamont: please push tulip to the buildd's on powerpc and ia64 <lamont> doko: given back <doko> lamont: clanlib as well please <lamont> doine <doko> thanks * lamont sleeps, noting that it's 0130 local <fabbione> hey good night lamont <doko> elmo: do you removals of packages from universe, or do the MOTU's handle these (i.e. librudiments0 source) <jbailey> fabbione: ping? <fabbione> jbailey: pong <jbailey> I donj't see that initrd-tools bug anymore, did you steal it back from me? <jbailey> Or am I just sleepy still and missing it? =) <fabbione> 12040 <jbailey> OH, I See. Just highi on the list from no comments, my bad. <jbailey> Did you get a chance to look at it at all? <fabbione> jbailey: yes.. i told you what the problem was and you said you were going to fix it before this morning :) <fabbione> so that i could test it on carlos machine <fabbione> but we are anyway too late to get it in for today <fabbione> we need to upload a kernel asap <jbailey> Umm, I told you that I would have it for you for today. I attached it to the bug last night. <jbailey> There's a new mkinitrd on there. <fabbione> CRAP <fabbione> i didn't get the mail <jbailey> Oh, you're not cc:'d on the bug. <jbailey> Hadn't even though to look. =( <jbailey> thought, rather. <jbailey> Although the QA contact is setu. <fabbione> let see if carlos is around.. <fabbione> otherwise tough luck <fabbione> jbailey: bingo <fabbione> modprobe -k unix 2> /dev/null <fabbione> modprobe -k megaraid_mbox <fabbione> modprobe -k megaraid <fabbione> modprobe -k sd_mod <fabbione> jbailey: ok.. we are still in time... <fabbione> can you upload the changes on the fly and tell me the initrd version? <jbailey> Sure, gimme a sec. <fabbione> perfect <jbailey> initrd-tools-0.1.78ubuntu2 <fabbione> perfect * jbailey wonders if there's anything else that needs to go in here urgently. <jbailey> Suck, bugzilla doesn't let me go directly from needsinfo to pending upload. <fabbione> yeah just close it <fabbione> if you can also upload it.. the kernel i am uploading in 10 minutes will be more happy :P <jbailey> Off she goes, check for her at the :03 <fabbione> yup.. great <fabbione> kernel is on the way too <fabbione> i am having a stupid problem with linux-meta <fabbione> Package: linux <fabbione> Architecture: i386 amd64 sparc ia64 <fabbione> Section: restricted/base <fabbione> Priority: optional <fabbione> Depends: linux-386 [i386] , linux-amd64-generic [amd64] , linux-sparc64 [sparc] , linux-itanium-smp [ia64] <fabbione> Description: Generic complete Linux kernel. <fabbione> This package will always depend on the latest generic complete Linux kernel <fabbione> available. <fabbione> for some reasons building it... <jbailey> I don't think you can do depends like that. <fabbione> the Depends line doesn't appear at all in the control file inside the deb <jbailey> Only build-dep <jbailey> Depends lines are supposed to be generated if you need that type of magic. <fabbione> ah crap <elmo> jbailey: you can do that with modern dpkg, actually <jbailey> Oh, cool. =) <elmo> err, I think. * fabbione checks what version of dpkg is using <elmo> I thought you could - it was something doogie added quietly <elmo> scott may have un-added it :) <jbailey> When a gave a shit about hurd-i386^UThat would have been handy a while ago... <fabbione> elmo: no it doesn't.. :/ <jbailey> fabbione: BTW, James Morrison said he'll look at the sparc generation bug for us as soon as I get him a sparcstation online to hack on or get one shipped to him (since I have his old sparc box) <fabbione> ah cool <jbailey> I'll get the U5 hooked up after I move, but I will probably start a hunt for a slightly sexier box shortly after that. =) <jbailey> We need someone big and corporate to be interested in sending us sunblades. =) <fabbione> i know <jbailey> I wonder if BenC is still willing to send me one on the Debian side. <jbailey> He had mentioned that I Should talk to him about it. <fabbione> substvars hates me <fabbione> cat linux-meta-502.619.2016/debian/substvars <fabbione> generic-depends=linux-386 <fabbione> Depends: ${generic-depends} <fabbione> dpkg-gencontrol: warning: unknown substitution variable ${generic-depends} <fabbione> GRRR <fabbione> what am i missing? <fabbione> the substvars file is created way before the call to gencontrol <Mithrandir> try dpkg-gencontrol -Vgeneric-depends=linux-386 ? <Mithrandir> not that it should make a difference, tho <jbailey> Is it being masked by a per-package substvars? <Mithrandir> or you could make it be Depends: linux-${Arch} if that was appropriate. <fabbione> unfornatly it's not map 1:1 <fabbione> for arch i mean <fabbione> jbailey: nope.. it's the only one <fabbione> dh_gencontrol -s -Vgeneric-depends=linux-386 <fabbione> dpkg-gencontrol: warning: unknown substitution variable ${generic-depends} <fabbione> tho <jbailey> fuckage with -'s? <jbailey> try genericDepends ? <fabbione> dh_gencontrol -s -VgenericDepends=linux-386 <fabbione> dpkg-gencontrol: warning: unknown substitution variable ${genericDepends} <fabbione> nope <fabbione> there fixed <fabbione> you need to tell gencontrol from what file to grab the vars.. go figure <elmo> laminitiy: crested/king are back <elmo> pls don't retry ruby until I get a chance to upgrade the kernel <elmo> speaking of - fabbione, what's the status of 2.6.12, is the one I just de-NEWed good to go? <lamont__> hppa builds gcc-3.4, preparing for a fresh start * lamont__ seems to recall that the order was {doxygen,expect-tcl8.3}, gcc-3.4, glibc, the world <lamont__> oh - gcc-defaults too. * lamont__ tries to remember if he wants the new glibc before or after gcc-{3.[34] ,4.0} <lamont__> before. * lamont__ notes that toolchain deps are even worse now <lamont__> order is: {doxygen, expect-tcl8.3[hppa] , dpkg}, {linux-kernel-headers, binutils}, binutils, glibc, gcc-{3.[34] ,4.0}, gcc-defaults <lamont__> oops, scratch that second binutils. :-) <lamont__> and then there's xorg. :- <lamont__> ( #ubuntu-toolchain 2005-07-04 <jbailey> lamont__: What are you rambling about? <lamont__> jbailey: doing the hppa archive-event <lamont__> hence rebootstrapping gcc-* <jbailey> Has the fix for hppa-hpux gone into 4.0.1 now? <lamont__> dunno <lamont__> this is g{cc,++}-3.4 <jbailey> Yeah, but for the rest of the archive, it would probably make sense to wait for that. <lamont__> that is, gcc-defaults points to 3.4 on hppa now. (1.24) <jbailey> Err, just because of the function pointer bit? <lamont__> yes <jbailey> Or is this to get past the everything-sucks-on-4.0 stage? <lamont__> just because pinters are completely b0rked <lamont__> pointers, even <lamont__> the everything-sucks thing is just a perk <lamont__> the pointer bug in 4.0 renders every .deb suspect <jbailey> In another day or two that bug will be fixed on 4.0 <jbailey> http://gcc.gnu.org/ml/gcc/2005-06/msg01192.html <lamont__> well then I'd better hurry and get through the sucky stage.. :) <jbailey> Yup. =) <lamont__> or at least put the gcc-default binaries on hold. :-) <jbailey> That would probably be better. =) <lamont__> lol <lamont__> binutils built. now for glibc <jbailey> lamont__: Have comendered(sp?) a nice 8-way PA system? =) <lamont__> _2_ hours. sigh <lamont__> I have an A500 that I'll be commandeering tomorrow <lamont__> (likewise, sp??) <lamont__> 2-way, 8GB RAM <jbailey> You seem to have it right. <lamont__> sadly, the buildd's run UP kernels, since they work better... <jbailey> I thought recent PA kernels were supposed to behave better. * jbailey shuts down spare machines in prep for the rolling blackouts. <lamont__> jbailey: they're much better, but.. :-( <jbailey> Is there risk of memory corruption leading to wrong-code generation, or just hangs and crashes? <lamont__> it tends to generate random segv's, from what I've seen <lamont__> but only under semi-heavy memory-pressure <lamont__> does -1ubuntu7 (glibc) have hppa tests disabled? <jbailey> lamont__: Looks like, yes. <jbailey> I haven't done an -1u8 yet since we asked me to reenable it. <lamont__> kewl... will build faster. :-) <lamont__> Total 2 package(s) in state Building. <lamont__> Total 5 package(s) in state Installed. <lamont__> Total 6091 package(s) in state Needs-Build. <lamont__> :-( <doko> lamont__, no need for doxygen if you build with -b -B <lamont__> doko: ah, coolness. <lamont__> but it builds fast. :-) <lamont__> s/builds/built/ * jbailey wanders off for a little bit. <lamont__> doko: with g++-3.4, nothing should need libstdc++5 any more, correct? <doko> lamont__: correct <lamont__> ok. I'll just make it hard to upload anything that Depends: libstdc++5 :-) <doko> well, the stuff that needs libstdc++5, doesn't build on hppa. like OOo1 <lamont__> hehe <lamont__> and let us not forget gcc-3.3 :-) <lamont__> basically, I'll just make the automated uploader bounce anything that mentions libstdc++5, and then manually figure out what it really means <lamont__> some of that can get uploaded, the bulk just needs to be built in the right order <doko> with the last batch of uploads I dropped the libstdc++5 rdepends from 880 to 530. at least on i386. <lamont__> nice <lamont__> this is more just me trying to make sure that I'm not accidentally building out-of-order. <lamont__> glibc is in install target. coolness <lamont__> and then comes 24 hours to build all 3 versions of gcc :( <lamont__> doko: what's the minimum set of gcc-* to build? 3.4 and 4.0? (do I really need the current gcc-3.3, or can I let the one from hoary [3.3.5-8ubuntu2] get used?) <doko> lamont__: the one from hoary should be ok, although I don't plan any further gcc-3.3 uploads now. 3.3 is currently synced from Debian and I don't plan to update that one for a while. the next 3.3 uploads will just drop support for languages like java, treelang, objc, <lamont__> ok. <lamont__> I'll let gcc-3.3 eventually catch up, then <lamont__> X.o.r.g.................................. <doko> I'm innocent :-) <lamont__> you build-depend on it. That's enough. :-( * lamont__ tries ignoring breezy's arch: all packages for the momenbt <doko> lamont__, for a bootstrap, you can disable java and ignore all the X b-d's <lamont__> pb is that I want to actually build the real source. <lamont__> after all, I have hoary/main * lamont__ cheers - gcc-3.4 is actually unpacking source to build... build-deps met <lamont__> with luck, it'll even build <lamont__> doko: would be nice if you hollered before uploading gcc-* this week - I'd like to let these builds finish and upload before I have to start new ones. <fabbione> morning <lamont> Total 6 package(s) in state Installed. <lamont> Total 6091 package(s) in state Needs-Build. <lamont> fabbione: I think sparc is ahead. :-( <fabbione> lamont: doh! <fabbione> i guess you are restarting with gcc-3.4? <lamont> yeah <fabbione> well actually sparc has a bigger problem <lamont> saddest part of it is that 33% of that 6 packages Depend: libstdc++5 <fabbione> breezy libc6 is triggering a bug in gcc <fabbione> and the kernel miscompile <lamont> (dpkg and doxygen) - I'll need to rebuild them eventually, but there's a new dpkg in debian (albeit FTBFS) <lamont> ew. poor sparc <fabbione> so sparc has 3/4 of the archive.. but no kernel :) <lamont> hppa has almost .1% of the archive. :-) <fabbione> how are you going to cope with the g++ transition? <lamont> g++-3.4 is libstdc++6 <fabbione> will you do it later? or are you swutching only gcc- ? <lamont> so I get the transition <fabbione> ah ok <lamont> the later switch from 3.4 to 4.0 is not an abi event * lamont is most happy that 3.4 exists <fabbione> yeah that's right <lamont> but must get to bed <fabbione> ehhe <lamont> with luck, I'll have 3.4 and 4.0 by morning, and can semi-unleash the beast. <fabbione> it sounds like i am the "GO TO BED" alarm clock in here ;) <lamont> yeah - that's the one... :-) <fabbione> ahah <fabbione> good night lamont <lamont> the other thing I'd like to get is a list of all the packages that I need to build before I can build xorg, so that I can queue those up <fabbione> i think it will just go DepWait now <fabbione> so it shouldn't be too difficult <fabbione> but take into account daniels is going to upload/if he didn't already <fabbione> some extra crack soon <fabbione> (i can't check.. my server crashed and secondary MX flushing) <lamont> fabbione: no, the issue is that things Conflict with older packages from xorg, so it's an ugly failure, not a pretty auto-depwaited thing <fabbione> oh <fabbione> crap <lamont> fabbione: but I got the list from daniels, so life is better. <fabbione> ehhe <elmo> * glibc_2.3.5-1ubuntu7 builds: <elmo> [...] <elmo> but no longer builds: <elmo> o 2.3.5-1ubuntu4: libc6-sparcv9 <elmo> fabbione: deliberate? <fabbione> elmo: yeps <fabbione> we are killing sparc32 support <fabbione> sparc32 is going the same way as m68k <fabbione> doorstep use basically <fabbione> elmo: did you have any time to setup logs@ ? <elmo> meh, no, let me try and do that now <fabbione> elmo: ok :) <doko_> lamont-away: gcc-3.4_3.4.4-3ubuntu1 will FTBFS on hppa. <jbailey> Oy, Fabio. =) <fabbione> hey jbailey <jbailey> Do I owe you anything still, or should I dive back into my task list. <jbailey> ? <fabbione> jbailey: a fix for glibc so i can compile the kernel? ;) <fabbione> i was told that also gentoo is hitting the same problem as we do <Mithrandir> jbailey: did you get your fix tested yesterday? <fabbione> nah go ahead with your list :) <fabbione> there is nothing in my list for you today :P <jbailey> Mithrandir: I didn't - there was some cool things in parliament yesterday and so I spent my evening glued to news sites rather than working. <jbailey> (And a chunk of the day...) <fabbione> anyway i am off for the next hour/today <fabbione> i had enough <fabbione> catch you later guys <jbailey> g'n Fabio. <Mithrandir> this vax is sloooooooooow <Mithrandir> jbailey: ok, tell me if you want me to power up my box. <jbailey> Mithrandir: In about 30 minutes okay? <jbailey> +Is <Mithrandir> jbailey: sure, I just have to extend my hand to press the power button. :-) <Mithrandir> it's booting now <jbailey> Thanks. <doko> jbailey: did you have a chance for the ecj-bootstrap upload? <jbailey> doko: No, wasabi's box crashed before I fetched it, and he said that he had an ecj.1 for me in his other package. <jbailey> Also, the ant he had posted was corrupted. <jbailey> java-common was fine, though, so I did upload that. <jbailey> I pinged him in #ubuntu-java a few minutes ago, I'm hoping to get this all done while he's still at home and has access to the box. <doko> ok, fine <lamont-away> ../../src/gcc/cppdefault.c:75: error: `LOCAL_INCLUDE_DIR' undeclared here (not in a function) <lamont-away> WTH? <lamont> -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" * lamont scratches his head <jbailey> lamont: Run it through with gcc -E -dD into a file, and I can take a look for you. <lamont> gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5\" -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5/hppa64-linux-gnu\" -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5/backward\" -DLOC <lamont> AL_INCLUDE_DIR=\"/usr/local/include\" -DCROSS_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../../hppa64-linux-gnu/sys-include\" -DTOOL_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../../hppa64-linux-gnu/include\" -DTARGET_MACHINE=\"hppa64-linux-gnu\" \ <lamont> -c ../../src/gcc/cppdefault.c -o cppdefault.o <lamont> ../../src/gcc/cppdefault.c:75: error: `LOCAL_INCLUDE_DIR' undeclared here (not in a function) <lamont> build directory is purged - I'll rebuild it once gcc-4.0 finishes dying <jbailey> If you have to rebuild anyway, can you do it on j5k? <jbailey> That way I can poke into your build env. <lamont> yeah - but then I have to create said build environment <lamont> or do you already have a hoary chroot there? <jbailey> I had a breezy one I think. <jbailey> I suspect for this build, though, it wouldn't make that big of a different. Dunno for sure. <lamont> given that we tossed the entire breezy hppa world..... <lamont> may just be easier to create access for you on this machine... wanna email me an ssh key? <fabbione> hey lamont <lamont> morning fabbione <lamont> ah, libcairo. sigh <doko> <doko> lamont-away: gcc-3.4_3.4.4-3ubuntu1 will FTBFS on hppa. <doko> lamont: ^^^ <lamont> doko: GAH! <lamont> I need a buildable gcc-3.4.... <elmo> doko: dude, I think you need to add some conflicts to gcc <elmo> almost all my buildds got fucked by partial upgrades of gcc and not g++ <doko> lamont: chinstrap:~doko/multiarch-include.dpatch <doko> elmo: how does it fail? <elmo> doko: c++ compiler can not create excutable, or massive include file fuckage <elmo> see e.g. the apt build log for ssparc <doko> where can I get the log? <doko> ahh, Debian? <elmo> yes, sorry, wildly and abusively OT <doko> hmm, buildd only has a log of a sucessful build <elmo> blink? <doko> 0.6.38 (sparc) (latest build at Jun 29 05:45: maybe-successful) <elmo> http://buildd.debian.org/build.php?&pkg=apt&ver=0.6.38&arch=sparc&file=log <elmo> follow the link of version num <elmo> http://buildd.debian.org/fetch.php?&pkg=apt&ver=0.6.38&arch=sparc&stamp=1119821334&file=log&as=raw <doko> ahh, yes, that's the changed internal gcc_lib_dir (/usr/lib/gcc-lib/...) <doko> so, basically, I would have to add conflicts in cpp-3.3 to all previous versions of gcc-3.3, gobjc-3.3, g77-3.3, g++-3.3, gnat-3.3, treelang-3,3, gpc-3.3 <doko> interesting. <elmo> or Breaks: if we had that <doko> hmm, I did promise lamont not to upload gcc-3.3 again ;-) <elmo> oh, don't do it again in a hurry, or I suspect ryan will fly over to kick your ass <elmo> but I think we should fix it at some point <elmo> most buildds are or will be fixed anyway <lamont> doko: feel free to upload 3.3 <elmo> feel free not to <elmo> :P <lamont> hehe <lamont> doko: if the 3.4 build works for me on hppa, should I upload the source? <doko> lamont: no, elmo surely wants the dont-break-the-stupid-buildd patch there as well ;) <lamont> yeah <lamont> doko: I just need to drop that into debian/patches? or add it's name to something as well <lamont> ? <doko> just drop it in, it's a corrected patch. <lamont> replaces the one there... got it. <lamont> doko: so there will be a -3ubuntu2 or such sometime soonish? <doko> lamont: yes * lamont grumbles at doko for uploading ardour -1build1 when -1 was FTBFS everywhere <doko> lamont: tell me, where I can get this information (besides scanning the build logs) ... <lamont> archive.ubuntu.com/ubuntu/pool/universe/a/ardour/ <lamont> :-) <lamont> OTOH, -1build1 is far better than -1ubuntu1 :-) <doko> lamont: when do you want a gcc-3.4 -3ubuntu2 upload? <lamont> anytime is fine <lamont> I <lamont> I'll let -3ubuntu1hppa1 finish building, and use that locally to let things run. <doko> ok, finishing a test build here. <lamont> given hppa's gcc-defaults.... do I need to build gcc-4.0 before I open the floodgates? (No hppa debs from gcc-4.0 in my archive) <lamont> hrm... actually, gcc-4.0 uses gcc-3.4 to build, correct? <doko> no, do you have an libgcc2 and libstdc++6? <lamont> no libgcc2 <doko> you need that one. it's built from the gcc-4.0 sources ... <lamont> libstdc++6_4.0.0-8ubuntu3_hppa.deb <lamont> that work for you? <doko> yes, I think so. <lamont> I'll run with that then #ubuntu-toolchain 2005-07-05 <fabbione> morning <lamont-away> doko: Moved gcc-3.4_3.4.4-3ubuntu1hppa1 to upload-breezy <lamont-away> that's with your PATH hack, and the good patch <lamont> Unresolved Dependency: cpp Depends: cpp-3.4 (>= 4.0.0-7) (breezy/main/hppa) * lamont grumbles at doko <lamont> Package: gpc <lamont> Depends: cpp (>= 4:4.0.0-2), gpc-2.1-3.4, gcc-4.0 (>= 3.4.3) <lamont> hrmpf * lamont decides to ignore that one. * lamont uploads gcc-defaults_1.25 * lamont works on iterating over xorg until it builds <jbailey> g'm all <Riddell> doko or anyone: could you review this http://dev.kubuntu.org.uk/~jr/kubuntu/wv2.diff <doko> Riddell: the files in debian/ are not renamed, the name in the shlibs file needs to be changed <Riddell> doko: fixed patch up <doko> Riddell: no, the package name in the shlibs file is wrong <Riddell> oops, sorry <Riddell> doko: ok, third try now <doko> looks ok, although there is a Makefile in the diff now. <fabbione> elmo: any luck with logs@ ? <elmo> working on it, just talked to lamont <fabbione> oh ok :) <fabbione> i am off for a shower :) <fabbione> and dinner... <fabbione> i will ping you tomorrow again :P <lamont> fabbione: with luck, it'll be happy by then.. :0) <desrt> 'sup guys. is ppc biarch toolchain in breezy yet? <elmo> yes <jbailey> desrt: Yes, awhile ago. <desrt> rocking <desrt> any word on the kernel? <jbailey> Any particular kernel? <desrt> ppc64 <jbailey> Also done awhile ago. <desrt> my life is complete. <jbailey> Will you die now? If yes, I'm sure I could break part of it to keep you around. <jbailey> I'd hate to have someone dying on my concience. <desrt> :) <desrt> this is enough to keep me around for a while <jbailey> Oh good. <desrt> if anything you've saved me from committing suicide faced with the prospect of another manual kernel cross-compile <desrt> jbailey++ * desrt headscratch <desrt> so i have this nice kernel running and linux-headers-2.6.12-3-powerpc64-smp installed <desrt> but whenever i go to build something it uses gcc-3.4 and seems to be trying to build a 64bit kernel in 32bit mode <desrt> (ie: building a module out-of-tree) <jbailey> Make sure you add -m64 to the command line. <desrt> nod. it definitely builds 64bit code... just the linux-headers-2.6.12-3-powerpc64-smp package seems to be misconfigured <jbailey> Best to try #ubuntu-kernel <desrt> thanks. <fabbione> desrt: that can be possible.. <fabbione> that the header package isn't correct... <fabbione> i hounestly forgot to check it <desrt> fabbione; eek. <desrt> fabbione; lemme try installing the full source <fabbione> desrt: if you can kindly mail me the details of what you are trying to do, it would be very nice <fabbione> i don't have a ppc64 at home to play with <jbailey> fabbione: Got a sec for chatting? <fabbione> and doing tests is quite of a problem for me <fabbione> jbailey: sure <fabbione> for you always <desrt> fabbione; lauren32@example.com? <jbailey> fabbione: After I move, I can give you access to mine easily. <fabbione> desrt: yes that would be perfect <desrt> fabbione; i can also give you access here if you like <fabbione> jbailey: nice :) <fabbione> desrt: see the problem is that to install/uninstall stuff i need basically root access :) <desrt> fabbione; that's fine <desrt> fabbione; it's a fresh box that i installed yesterday and just moved hoary->breezy. i don't care about it very much :) <fabbione> desrt: well i don't like to use "users" machines, but if you want you can send me an account info with the mail <fabbione> and i can look at what you are doing <fabbione> so i can see what's wrong with the headers <desrt> ok. first i'll see if i can get it working with the full sources <fabbione> sure <desrt> oh wait. there exist no fully-preconfigured source packages that correspond to the built kernel images, do there? <desrt> fabbione; do you have an ssh key somewhere? <fabbione> desrt: there is the source.. you can grab the config from /boot <fabbione> desrt: sure i can send it to you <desrt> fabbione; it looks like there are some Makefile modifications here... <fabbione> desrt: uh? <desrt> like $(CROSSCOMPILE)gcc changed to gcc-3.4 <fabbione> desrt: yes. that's correct... we force gcc-3.4 <fabbione> because it's the minimum that can compile ppc64 <desrt> right.. but will just copying in the .config change that? <fabbione> nope <desrt> k. i'll just diff the Makefiles to see if there's anything else <desrt> fabbione; please send your key <fabbione> desrt: i need your email address at least? <desrt> lauren32@example.com <zul> whats with all these canadians <desrt> :) <fabbione> eheh <desrt> that's one heck of a long key :) <fabbione> dont' confuse the gpg key with the ssh one <fabbione> one it's only the signature <fabbione> so you can verify the mail is coming from me <desrt> ok. try to ssh to copacetic.mcmaster.ca <fabbione> The authenticity of host 'copacetic.mcmaster.ca 502.619.2016)' can't be established. <fabbione> RSA key fingerprint is 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab:33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab. <desrt> uh. i guess that's right :) <fabbione> yeah i am in <desrt> ok. the ppc64 box is called gorecki <fabbione> but you are running 2.6.10 there... <fabbione> ah i need another op? <desrt> ya. gorecki is behind the firewall <fabbione> Failed to add the host to the list of known hosts (/home/fabbione/.ssh/known_hosts). <desrt> your password on gorecki is 'secret' <desrt> oh. sorry. <fabbione> amen ok :) <fabbione> you left .ssh as root <desrt> yes. fixed now., <desrt> you should be able to sudo on gorecki <fabbione> root@gorecki:~ # <desrt> excellent :) <fabbione> i would say it works... <fabbione> desrt: can you send me now the info of what needs to be done via email? <fabbione> it's like 10pm here <desrt> ok <fabbione> and i plan to crash in not too long from now :) <desrt> btw: it works much better when i use the source <desrt> so it must be a problem with the headers package <fabbione> desrt: it is possible.. yes.. as i said before :) <desrt> will email info. <desrt> thanks :) <fabbione> desrt: thanks for the cooperation <desrt> no problem. #ubuntu-toolchain 2005-07-06 <lamont> jbailey: you around? <lamont> doko: ping <lamont> gij: Depends: gij-3.4 (>= 3.4.3) but it is not installable <lamont> libgcj4-dev: Depends: gcj-3.3 (>= 1:3.3.5-8ubuntu2) but it is not going to be installed <lamont> Depends: libgcj4-common (>= 1:3.3.5-8ubuntu2) but it is not going to be installed <lamont> do we expect that from hppa? <doko> lamont: looks ok, don't know what is wrong. sorry, I'm too tired. I'm currently uploading a 4.0 with PR22051 fixed. <lamont> doko: ok. <lamont> doko: gij-3.4 does not exist, for starters... <lamont> doko: hold off on changing the defaults for hppa back to 4.0 for a little bit - if it's OK with you, I'll plan on uploading a new gcc-defaults once I've done some testing. <doko> lamont: hppa is your call .. <lamont> doko: thanks <lamont> unicode.c:19:26: linux/string.h: No such file or directory <lamont> \ * lamont grumbles at jbailey <jbailey> lamont: The whole header is wrapped with an #ifdef __KERNEL__ and doesn't have any definitions in it... <jbailey> The leading comment is: /* We don't want strings.h stuff being user by user stuff by accident */ <lamont> jbailey: hfsplus, fwiw <lamont> and then there's: /usr/include/linux/socket.h:10: error: redefinition of `struct sockaddr' <lamont> /usr/include/linux/socket.h:17: error: redefinition of `struct linger' <jbailey> Is this on hppa? <jbailey> hfsplus includes socket stuff? <jbailey> Sounds like the program is a mess. <jbailey> Can you email it to me? I'll fix it on Tuesday / Wednesday. * doko grumbles at lamont not syncing packages (i.e. dhcp3) <lamont> jbailey: that was iproute <lamont> jbailey: I'll send you some mail, yes. <jbailey> lamont: Cool. I can chew through them pretty quickly and try to get the patches in upstream. <lamont> fabbione: _2_ buildd's now chunking along on hppoa <fabbione> morning <desrt> fabbione; word. <fabbione> hey desrt <desrt> found a couple of other issues with the actual kernel <desrt> basically, some options are off that should be on <fabbione> can you be more specific? <desrt> mouse button emulation and openfirmware tree under /proc <fabbione> i think they are built as module <fabbione> but if you can tell me the CONFIG_ option it's easy to check <desrt> looking. <desrt> ok. the mouse button emulation is definitely missing, but for a good reason <desrt> it depends on ADB support which is (quite reasonably) disabled <fabbione> ok <desrt> it gives an error on startup.. no big deal <fabbione> error or warning? <desrt> warning <desrt> missing sysctl variables <fabbione> ok <desrt> the other one is a bit more serious since it prevents yaboot from working <fabbione> mostlikely possible.. not everything has been ported to 64bit yet <fabbione> hmmm.. i understood there was no reason to use yaboot.. <desrt> this definitely works on ppc64. i've done it before <fabbione> can you still tell me option so i can check with others? <desrt> k. gotta find it :) <fabbione> thanks :) * fabbione blames GTK for not shipping a ppc64 in this direction <desrt> what am i supposed to use instead of yaboot? <fabbione> desrt: no idea... <fabbione> i don't own a ppc <desrt> :) <fabbione> i ask around usually what is the best thing to do <desrt> fair enough :) * desrt raises an eyebrow * lamont --> bed <desrt> fabbione; ok. the device tree is enabled, but broken <fabbione> broken how? <desrt> root@gorecki:/proc/device-tree# ofpath /dev/sda2 <desrt> ofpath: /proc/device-tree is broken. Do not use BootX to boot, use yaboot. <desrt> ofpath: The yaboot HOWTO can be found here: http://www.alaska.net/~erbenson/doc <desrt> (having booted using yaboot) <desrt> i'm gonna google a bit <fabbione> ok.. <fabbione> are you sure it's not just a warning? <desrt> quite sure <fabbione> if you booted with yaboot, it somehow means that the device-tree is there <desrt> it needs to know the openfirmware device path of the harddrive <desrt> (in order to load the kernel image from it) <fabbione> so how did you booted before? <desrt> after i installed the ppc64 image i ran yaboot from inside the 32bit kernel <desrt> (which works fine) <fabbione> hold on a sec.. <fabbione> hmm ben is not around... <fabbione> i will ask him when he shows up <desrt> ok. i'm still looking into it <fabbione> desrt: you could try to look at device-tree with a 32bit kernel and compare the diff with a 64? <desrt> fabbione; doing that now <fabbione> perhaps it is easy to spot <desrt> ofboot works by grepping the output of ls -l | ^lr (ie: looking for readable symlinks) <desrt> the ppc32 kernel is full of symlinks... none in the 64bit one <fabbione> hmmm interesting <fabbione> ok i will ask him <fabbione> doko: ping? <desrt> fabbione; ok, basically the check performed by ofpath is stupid <desrt> fabbione; if i disable the check (or change it to check for the presence of directories instead of links) then yaboot is fine <fabbione> desrt: can you test the same change on 32bit kernels? <desrt> hm. ok <fabbione> if that change works, i see no problem in pushing it in the archive <fabbione> if it was checking for symlinks there might be a reason that we don't know <desrt> works fine <desrt> well, in the event that it doesn't find symlinks it aborts <desrt> anyway.. the fix is positively trivial <desrt> line 674 of /usr/sbin/ofpath <fabbione> ofpath is part of yaboot? <desrt> change ^lr to ^d <desrt> yes <fabbione> (on i386 is a bit less trivial to check ppc packages ;)) <desrt> also change at line 432 <fabbione> that checks look completely dumb <desrt> it just checks if there's any files that have ls -l output starting with lr (ie: symlinks...) <desrt> yet it works perfectly fine without the presence of these symlinks <desrt> i guess it just assumes that if the device tree is present it will always have symlinks in it <desrt> (oops) <fabbione> ok i will ask Kamion to double check.. he is the ppc guy <desrt> rockin' <fabbione> given that i can't test it locally <fabbione> no problem :) thanks a lot for the debugging :) <desrt> thanks for your swift reply :) <fabbione> :) <desrt> http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.12 <desrt> commit 5f64f73957f6cae3222f97f2599199ee562f7f3f <desrt> Author: Benjamin Herrenschmidt <lauren32@example.com> <desrt> ^^ see this <fabbione> oh benh :) <fabbione> the same ben i was going to ask ;) <desrt> ya. i know :) <desrt> benh did some particularly heroic stuff in the kernel right around the time i got my ibook :) <fabbione> yeah he still does :) <fabbione> and he hangs here on freenode <fabbione> if he did that.. i am confident in doing the change :) <desrt> so it's really a 2.6.10 vs 2.6.12 issue, i guess... not ppc32 vs ppc64 <fabbione> yeps <desrt> probably means a new version of yaboot will be released soon anyway <fabbione> probably.. in the meantime let's fix it :) <desrt> sounds good to me <fabbione> yaboot (1.3.13-3ubuntu3) breezy; urgency=low <fabbione> * ofpath: fix checks of /proc/device-tree: <fabbione> According to commit 5f64f73957f6cae3222f97f2599199ee562f7f3f <fabbione> in 2.6.12: <fabbione> <fabbione> [PATCH] ppc32/ppc64: cleanup /proc/device-tree <fabbione> [....] <fabbione> - Do not create symlinks for the short name and unit address parts of a <fabbione> node. These were never really used, bloated the memory footprint of <fabbione> the device-tree with useless struct proc_dir_entry and their matching <fabbione> dentry and inode cache bloat. <fabbione> ofpath always assumed the presence of symlinks to verify a valide <fabbione> /proc/device-tree. Change them to verify presence of directories instead. <fabbione> Patch and tests kindly done by Ryan Lortie. <fabbione> -- Fabio M. Di Nitto <lauren32@example.com> Fri, 01 Jul 2005 07:46:39 +0200 <desrt> rocking. when will that be on the archives? <fabbione> in about one hour if it build properly... <desrt> the infra you guys have going is seriously cool :) <fabbione> let me see if i can test build it first <fabbione> yaboot didn't get an upload in ages <desrt> so how did you swing a powermac (promise) from gtk? <fabbione> nah i was just kidding :) <desrt> oh :) <fabbione> everything that doesn't work is GTK's fault ;) <desrt> hah. <desrt> ok. i thought that was sort of weird :) <desrt> we bought about 20 dual G5s at work half a year ago <desrt> the work all you guys are doing on the toolchain and kernel to get ppc64 supported is vastly appreciated <fabbione> :) <fabbione> hmm it doesn't build with gcc-4.0 <desrt> precious little does :P <fabbione> meh sorry i was talking about yaboot <desrt> that's what i understood <desrt> oh wow. this code is special :) <desrt> it looks like the guy implemented KMP strstr() using intentionally-obfuse code <desrt> anyway.. it's just one problem and it's pretty easy to fix in a disgusting way :) <desrt> line 79 of lib/strstr.c should read "shloop: 0; }" :) <fabbione> oh yeah <fabbione> uploaded now.... <desrt> hopefully this one works out a bit better <fabbione> it will hit the archive in approx 1 hour <fabbione> i hope it won't break compiled with gcc-4.0 :) <desrt> i did a build here with the 2 patches and dpkg -i'd the .deb <desrt> seems to be working <fabbione> did you boot with it? <desrt> nope :) <desrt> it's the long weekend. dare me to? :) <fabbione> up to you :) <desrt> actually. i have a G5 beside me <desrt> i'll try on it <fabbione> rocking <desrt> uh. i patented "rocking" <desrt> pay up or cease and desist <fabbione> ehehe <fabbione> ok back to userland now... <fabbione> gotta fix some stuff today <fabbione> desrt: enjoy the long we btw :) <desrt> surely will :) <fabbione> i will come back to you for the headers stuff soon... <fabbione> today is userland work :) <desrt> :) <desrt> ya.. this channel is called -toolchain, after all <desrt> <just testing yaboot now... had to upgrade to breezy> <desrt> works in 32bit mode <desrt> and 64. doesn't look like gcc4 hurt it too badly <desrt> i'm off to sleep now. have a good day :) <fabbione> good night :) <doko> fabbione: pong <fabbione> doko: mind if i upload OO2?? <fabbione> missing at least one B-D on libxkbfile-dev <doko> hmm, I'll add it, have a new milestone here finally. <fabbione> doko: ok.. i am completing a test build on i386 <fabbione> (saw the failure on sparc) <fabbione> and i will let you know if more is required #ubuntu-toolchain 2005-07-07 <lamont> Total 351 package(s) in state Installed. <lamont> Total 5443 package(s) in state Needs-Build. <lamont> Total 67 package(s) in state Uploaded. <lamont> getting there <fabbione> :) <fabbione> there is something wrong with gnome-alsamixer.. <fabbione> sparc and ia64 keeps giving it back <fabbione> it's really weird <fabbione> because it has been built before <fabbione> lamont: regarding the NEW.. i think it was also due to the ABI change... <fabbione> doko: i confirm that adding that b-d makes it go at least on i386 <doko> fabbione: ok <doko> lamont: gcc-4.0 4.0.0-12 has PR22051 fixed. <lamont> unknown/gnome-alsamixer_0.9.6-1: Needs-Build [-:uncompiled] <lamont> fabbione: ^^^ <lamont> unknown is main, but it's not really there... <lamont> iz override edit for elmo <fabbione> <lamont> iz override edit for elmo <fabbione> <fabbione> lamont: look at your build-logs <fabbione> <fabbione> it has been built and suddenly needs build again <fabbione> <fabbione> + i get error fetching the sources... it's weird.. <fabbione> <fabbione> but it's saturday and building gcc-4.0 that won't finish before <fabbione> tomorrow anyway ;) <fabbione> bah damn efnet #ubuntu-toolchain 2005-07-09 <lamont> mframe.m: In function 'mframe_decode_return': <lamont> mframe.m:1579: warning: pointer targets in passing argument 2 of 'NSGetSizeAndAlignment' differ in signedness <lamont> mframe.m:1711: internal compiler error: in assign_stack_temp_for_type, at function.c:605 <lamont> woot <lamont> gnustep-base ICE <lamont> (ppc) <lamont> interesting... ISTR ICE there before on either hppa or ia64, gcc-3.x <fabbione> morning <lamont> elmo: could you locate glibc_2.3.5-1ubuntu7_hppa and tell me what I did wrong that it's not in the archive??? (iz NEW, maybe???)_ <elmo> Rejected: libnss-dns-udeb_2.3.5-1ubuntu7_hppa.udeb: can not overwrite existing copy already in the archive. <elmo> guess it was uploaded too soon - try again? <lamont> ok. re-uploading <lamont> note that the .debs don't seem to have actually been removed from the archive (at least initially) - could that be the issue? <lamont> Packages didn't list things that had .debs in the archive.. #ubuntu-toolchain 2005-07-10 <fabbione> morning <doko> lamont: time to make 4.0 the default on hppa again? <lamont__> doko: once gcc-4.0 is built and in the archive for hppa with the fix, go ahead and bump gcc-defaults. it'll take a bit before I actually build/upload gcc-defaults with the change, but I'll coordinate that with the buildd chroots. #ubuntu-toolchain 2005-07-11 <jbailey> lamont: Are you power building universe with the older gcc? =) <lamont> jbailey: 3.4 <jbailey> Nice. How caught up are you? <fabbione> morning <doko> good morning <fabbione> hey doko <fabbione> doko: OO2 is FTBFS on sparc :) <fabbione> the error message is quite strange tho <doko> which one, 108 or 113? <fabbione> 113 <fabbione> /build/sparcbuildd/openoffice.org2-1.9.113/ooo-build/build/src680-m113/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx: In function 'void<unnamed>33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abpp_vtable_call()': <fabbione> /build/sparcbuildd/openoffice.org2-1.9.113/ooo-build/build/src680-m113/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx:423: error: memory input 0 is not directly addressable <fabbione> i will put the log online somewhere.. it's quite big atm <fabbione> but it's not high priority for me <fabbione> i would be more happy to get the gcc ice fixed <fabbione> and to understand what's wrong with the mail i just forwarded to you <fabbione> doko: the build log is online on people.u.c/~fabbione/ <doko> hmm, the gnome-games one is about a symbol in two libc files. <fabbione> where is jbailey when i need to objectifing him a bit <doko> he smells the trouble, pretending "switching machines." ;) <doko> fabbione: where can I find the file.i for the unionfs ICE, where the command line args? <lamont> jbailey: gcc-4.0 had a bug that caused us an archive event... doko has uploaded the fix, but I the default hasn't been switched back in the chroots yet <jbailey> Right, but I remember that you said that you wanted to build as much of universe as possible, first. <lamont> jbailey: I said I was racing doko <jbailey> *lol* <jbailey> Right, and I'm sure there were 12 buildds participating in the racing. <lamont> exp.c:75: warning: conflicting types for built-in function 'exp2' <lamont> three cheers for csh! <doko> jbailey: hi <doko> jbailey: we need the multiarch stuff for gcc, libstdc++ header files aren't correct for biarch's <jbailey> Heya Matthias <jbailey> Right then. Today is uvf, right? I'd like to get a new udev in and then I can focus on that with you. * lamont wonders if his lkh stuff is going to make it... <jbailey> lamont: Yes, I don't consider it version-freeze material. <lamont> doko: eta on a gcc-3.4_3.4.4-3ubuntu2 (or later) upload? <lamont> brb <doko> lamont: did I forget something? <lamont> 3ubuntu1 was ftbfs on hppa <lamont> bad multiarch patch <lamont> ?? <doko> ahh, yes <lamont> (I think that was the issue. <lamont> yeah - died in build-hppa64 <lamont> back in a few <doko> months? <jbailey> Wow 590kB/s off of archive.ubuntu.com. I do like this new ISP. <jbailey> My last one was like 30kB/sec <lamont> doko: sigh... I might upload it if it's gonna be months.. <jbailey> i think he was completing your sentence... * jbailey tweaks lamont's humour filter. <lamont> jbailey: feh! <jbailey> Right, you don't have one of those. Bloody americans. /me tries again on the humor filter this time... <lamont> doko: also, it'd be _WAY_COOL_ if we could deliver say java as a separate source package, and get the build-deps for gcc back down to something sane (e.g., not requiring X to build a compiler..) <lamont> jbailey: hehe <doko> lamont: yes, I know ... please submit a bug report to bugzilla ... <lamont> ok <lamont> uh - for which? <doko> gcc-4.0 ? <lamont> ok. <lamont> (was multiarch gcc-3.4 bug vs X build-dep) <lamont> that I was asking, that is <doko> was uploaded while you were taking your nap ;) <lamont> huh? <lamont> I think we may be talking about 3 issues here: <doko> sorry, s/taking your nap/away/ <lamont> 1) gcc-3.4 has a multiarch bug that you will upload sometime <lamont> 2) /me to file a bug about gcc-4.0's insane build-deps <lamont> 3) gcc-4.0 currently not building on hppa because xorg isn't installable, see 2 <doko> 1) done <doko> disable java until 3) is fixed <lamont> 12444, assigned to doko <lamont> well, X might be installable <lamont> it tripped over 4) archive updates aren't atomic, so apt-get update fails randomly in a transient manner <lamont> 1) way cool <jbailey> I thought archive updates were made atomic by uploading debs first, then updating package files then deleting old debs? <lamont> 3) modifying the source isn't really a solution for me, since I can't upload the resultant binaries to the archive <lamont> jbailey: yeah <doko> I'll disable java for the next 4.0 upload <lamont> but tell me how they get all the Packages, Sources, Release and Release.gpg files in with an atomic op, and I'll give you a dollar <lamont> doko: shouldn't be needed <doko> ok <lamont> doko: lets leave it enabled, and I'll just have to get through the rest of my issues.. <jbailey> lamont: lockd? * jbailey hides. <lamont> hrm... how much lead shot is a dollar's worth..... <jbailey> =) <lamont> doko: and I have gcc-defaults on no-auto-build until I have the newer gcc-4.0 in the archive, so you're welcome to upload 1.26 with the switch to gcc-4.0 <doko> ok <lamont> jbailey: /usr/include/sys/ucontext.h:49: error: array bound is not an integer constant <jbailey> hppa? <jbailey> Hmm. <jbailey> That's not an arch specific file <jbailey> unsigned int vrregs[32] [4] ; <lamont> hppa <lamont> typedef struct fpregset <lamont> { <lamont> double fp_dregs[32] ; <lamont> } fpregset_t; <lamont> line 49 is the "typedef struct fpregset" <jbailey> This is breezy? <lamont> hrmpf. one for me to investigate later. yes breezy <lamont> er... <lamont> feh <lamont> ia64, sid <lamont> unsigned long _pad[_SC_GR0_OFFSET/8] ; <lamont> clearly I was looking at too many logfiles in rapid succession #ubuntu-toolchain 2005-07-12 <fabbione> morning <daniels> yo fabbione #ubuntu-toolchain 2005-07-13 <desrt> fabbione; 'sup? <fabbione> morning <desrt> how's gorecki? <desrt> mmm. /me -> bed. <fabbione> desrt: sorry.. i didn't login in a while <fabbione> i fixed it in the last kernel upload <fabbione> so an upgrade should do and work <fabbione> if you want to check it yourself too <fabbione> and let me know * ..[topic/#ubuntu-toolchain:doko] : GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch, C++ ABI change: completed in main, some universe work left <doko> jbailey: do you have the multiarch-include patch, for different include directories having the arch in the include path? <jbailey> doko: Not handy. Want me to cook that up again today? <doko> that would be nice. the libstdc++ headers are wrong as well <jbailey> Feh. a'ight. <doko> I'm planning the 4.0.1 upload for tonight/tomorrow <jbailey> Can you aim for tomorrow instead? bradb is coming over in an hour or so for user testing of malone. I was hoping to cook it up after that. <doko> could you point me to your preliminary patch? <jbailey> Yes, was just uploading it. <jbailey> http://people.ubuntu.com/~jbailey/multiarch-include.dpatch <jbailey> (and then distracted, sorry) <jbailey> I think this is the one that still includes the base arch always. <jbailey> I also think that the TARGET_MACHINE macro should probably be available some other way so that Makefile.in doesn't need to be touched, but I didn't go digging for that. <doko> jbailey: hmm, this patch is outdated. it breaks cross compilers. an updated one is already applied in the gcc-4.0 sources. <doko> and it doesn't solve the problem to exchange the i.e. i486-linux-gnu in the include paths with x86_64-linux-gnu <lamont> Jul 8 09:18:23 buildd: breezy: total 1067 packages to build. <lamont> Unpacking gettext (from .../gettext_0.14.5-1ubuntu1_hppa.deb) ... <lamont> dpkg: error processing /home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/gettext_0.14.5-1ubuntu1_hppa.deb (--unpack): <lamont> trying to overwrite `/usr/share/info/dir.gz', which is also in package gzip <lamont> GAH! #ubuntu-toolchain 2005-07-14 <doko> jbailey: <doko> Setting up python2.4 (2.4.1-2ubuntu3) ... <doko> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! <doko> seen as well, when building gnat from gcc-4.0 on powerpc <doko> s/powerpc/amd64/ <jbailey> Are these both on amd64? <doko> jbailey: yes <doko> you can find the python one in the openoffice.org2 build log <jbailey> I wonder what happened. There hasn't been a glibc upload recently. <doko> I know, but python was rebuilt using the current gcc-4.0 <jbailey> Ugh, so maybe 4.0.1 is causing this now where your pre-snapshot wasn't? <doko> jbailey: binutils FTBFS on unstable powerpc due to the new l-k-h. just in case you do want to have a look ... <jbailey> new lkh? <jbailey> Oh, in unstable. <jbailey> I should try harder to convince gotom to just
{'channel': 'ubuntu-toolchain', 'month': 7}