#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>::cpp_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 use my packages for lkh rather than his own. =(
<infinity> Try with a bat.
<jbailey> Vampire or baseball?
<infinity> Also, when do we get glibc 2.3.5 in sid?
<jbailey> After binutils builds everywhere.
#ubuntu-toolchain 2005-07-15
<doko> jbailey: gotom does use 2.6.12, we use 2.6.11
<jbailey> He uses an entirely different code base than we do.
<jbailey> Our kernel headers are based off the linux libc headers that are cleaned out, and shared with a couple of Linux distros.
<jbailey> gotom produces his own and really strongly would rather use those.
<jbailey> drow agreed with the idea of using linux-libc-headers, as did pb_.
<jbailey> But I don't want to push it, since I don't want it to come across as "In Ubuntu we do this, so you have to follow", and he's willing to do the work anyway.
<doko> ehh, then he should fix it ...
<doko> infinity: I hope, _after_ my 4.0.1 upload
<jbailey> doko: Yes.  I'm' hoping that I can show that the kernel headers I have will be more regularily up to date than his, and overcome his objections until he accepts them.
<lamont> jbailey: you saw the ucontext bug?
<lamont> (ia64/debian)
* lamont wanders off - alsadriver if you haven't seen it..
<lamont> there are several packages ftbfs because of it
<jbailey> lamont: I haven't do you have a bug number handy?
<doko> fabbione: well, yes, I'm tired of gnat-4.0 now ...
<fabbione> doko: ehehhe
<fabbione> anyway thanks for looking at it my friend
<fabbione> since you are a good boy you will get mISDN back... this week
<doko> heh ... :)
<fabbione> i am off for a shower...
<fabbione> later fellas
#ubuntu-toolchain 2005-07-16
<lamont> jbailey: http://buildd.debian.org/fetch.php?&pkg=alsaplayer&ver=0.99.76-5&arch=ia64&stamp=1120845002&file=log&as=raw
<jbailey> Is this a huge blocker for you?  Otherwise, I'd prefer to wait to deal with issues like this until glibc 2.3.5 is in sid.
<lamont> gcc  -g -O2  -Wl,-O1 -Wl,--as-needed -o tsclient  main.o support.o connect.o rdpfile.o mrulist.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2
<lamont> +-lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
<lamont> +-lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0
<lamont> /usr/lib/gcc/hppa-linux-gnu/3.4.5/../../../crt1.o:../sysdeps/hppa/elf/start.S:56: multiple definition of `_GLOBAL_OFFSET_TABLE_'
<lamont> collect2: ld returned 1 exit status
<lamont> ew
<lamont> jbailey: it's blocking about 6 packages, and at least 2 maintainers have asked me about it...
<lamont> (ucontext)
<lamont> and the root of the issue is that the "constant" isn't defined anywhere
<lamont> I'll probably pester dannf et al about ucontext tomorrow
<lamont> it could just be a kernel bug
<lamont>   wcs = new (WorldCoor*)[MULTWCS] ;
<lamont> so that's bad C++, eh?
* daniels stares.
<jbailey> karlheg: Hey!
<jbailey> lamont: Umm, yes.
<jbailey> lamont: The thing is that if it compiled fine in Breezy, then the answer is to just wait for the new glibc.  There's no point in uploading a fix for the current glibc in sid.
<fabbione> morning
<fabbione> jbailey_: yo dude
<jbailey_> yoyosup?
<fabbione> jbailey_: amd64 is borked.. we need to fix it asap
<fabbione> did you get that bug about ld.so assertion something?
<jbailey_> borkage caused how?
<jbailey_> doko mentioned it in two apps that had been recompiled with the new gcc 4.0.1, but I haven't looked for anything.
* ..[topic/#ubuntu-toolchain:jbailey_] : GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: i386 biarch, C++ ABI change: completed in main, some universe work left
<fabbione> see this http://people.ubuntu.com/~lamont/buildLogs/o/ocfs2-tools/0.99.15-0ubuntu2/
<fabbione> check the amd64 FTBFS
<fabbione> i can reproduce that problem constantly just compiling the kernel on concordia
<fabbione> Setting up python2.4 (2.4.1-2ubuntu3) ...
<fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._
<fabbione> dl_rtld_map.l_libname' failed!
<fabbione> on concordia for me it happens at build time
<jbailey_> When using python, probably.
<fabbione> i don't use python to build the kernel dude :)
<jbailey_> But..  But..  This is Ubuntu!
<jbailey_> PYTHON MUST OOZE FROM YOUR PORES!
<jbailey_> er.
<jbailey_> anyhow
<fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
<fabbione> there.. building the kernel :)
<jbailey_> I'll see if I can figure it out on Concordia.  I suspect I'll block very quickly on needing to instll debug packages.
<jbailey_> fabbione: I need the line before that from the log, dude. =)  What triggers it?
<daniels> didn't esr's freakshow config system (CML2?) use Python?
<jbailey_> Running python is a sucky test case.
<fabbione> jbailey_: just try to build the source that's in breezy with KBUILD_VERBOSE=1 in the environment
<fabbione> breezy chroot on concordia has all you need
<fabbione> i need to run away soon....
<jbailey_> Which source package exactly are you using to make sure I get this right?
<fabbione> linux-source-2.6.12
<jbailey_> Tx.
<fabbione> you can grab it from my home on concordia
<fabbione> so you are 100% sure to use the same source as i am developing
<jbailey_> Building..  Does it fail quickly?
<jbailey_> debuild -B -eKBUILD_VERBOSE=1
<fabbione> jbailey_: yes. pretty quickly
<jbailey_> Cool.  i'll grab a bowl of cereal and check on it while I eat, then.
<fabbione> jbailey_: concordia will be faster :)
<jbailey_> Not so far...
<fabbione> because you don't use CONCURRENCY_LEVEL=300 to arrive to the point of failure
<fabbione> and switch it back to 1 to check the real error :)
<jbailey_> Ahahah.
<jbailey_> The glibc build just uses -J$(NCPUS)
<fabbione> i do it only on the buildd...
<fabbione> you know.. it's not nice to kill people's pc
<fabbione> normal pc i mean ;)
<jbailey_> If they have a normal PC, that's -j1 anyway.
<jbailey_> Or you mean yours.
<fabbione> jbailey: i do NCPUS * 2 on the buildd's
<jbailey_> Do you actualy find a win above NCPUS*2 + 1 ?
<fabbione>  yes
<jbailey_> Huh, interesting.
<fabbione> but that's because of ccache
<jbailey_> With glibc that seemed to be about the point where the disk was going mad.
<jbailey_> Oh.
<fabbione> if the machine has a lot of RAM and good disk I/O
<fabbione> the -j200 i run, it's not CPU intensive at all
<fabbione> it's question of grabbinb a file from the disk
<fabbione> so yes.. i gain and a lot
<fabbione> if you don't have a fresh ccache.. you lose
<fabbione> but i do in 99% of the cases on the porting boxen
<jbailey_> And lose horribly, I suspect.
<fabbione> boxes
<fabbione> well not terribly, but you slow down.. too much switching
<fabbione> specially in the first flavour when the code is not even in cache
<fabbione> the second flavour is like building from a ramdisk
<fabbione> so it still gain a bit....
<fabbione> bah one day i will time all these things :)
<fabbione> i need to go and get ready
<fabbione> cya either later or tomorrow
<jbailey_> I was more thinking gcc eating all your ram at that point. =)
<jbailey_> Cool, See you Fabio.
<jbailey_> Think good thoughts at me, I'm going to try and get LVM working for initramfs today.  I want you to be able to enable it tomorrow night. =)
<fabbione> jbailey: if you can scratch the box and install breezy, it's damn simple :)
<fabbione> we just added partman-auto-lvm to the default d-i path
<fabbione> that means you hit: "Destroy this device and make it LVM"
<fabbione> and it will work
<fabbione> but only on i386 and amd64
<jbailey_> Not ppc?
<fabbione> apparently ppc doesn't have lvm
<jbailey_> That would explain the trouble I was having before./
<fabbione> not in parted
<jbailey_> All my experiments with with ppc.  You can't do raid in the installer there either (in Hoary)
<fabbione> oh .. it works.. our d-i just doesn't support it.. yet
<jbailey_> 'kay.  I'll frag the laptop then.
<jbailey_> Umm.
<jbailey_> I just realisaed that this build isn't giving me the gcc command line.
<jbailey_> How will I get the info to reproduce the failure when it eventually happens?
<fabbione> jbailey: export KBUILD_VERBOSE=1
<fabbione> be sure to use export :)
<jbailey_> the -e on debuild is suppposed to do that.
<fabbione> and do you trust that or me?
<fabbione> ;)
<fabbione> good luck with lvm
<fabbione> but it's damn easy :)
<fabbione> later
* fabbione &
<jbailey_> Hmm, done both, I still don't see details.
<jbailey_> Oh, the -e needs come to come *before* the -B on the command line.  How *obvious*
<jbailey_> sigh.
* jbailey_ lets this run for a whie
<jbailey_> fabbione: I don't get that error.  I get a segfault on 'mv'
<jbailey_> *sigh*
<jbailey_> And it appears to have fragged the file in the process. =(
<lamont> hppa is down to 200 packages in main that it needs to build
<fabbione> hey lamont
<fabbione> nice
<fabbione> jbailey: around?
<jbailey> lamont: Nice!  Is the installer the only thing blocking hppa adoption then?
<jbailey> fabbione: I'm not getting the same problem during the kernel build.  Just lots of segfaults on things like 'mv' and 'rm' =(  But irreproducable when I do the commands by hand.
<fabbione> weird!
<fabbione> jbailey: can you try enabling ccache?
<fabbione> i wonder if that could be the reason
<jbailey> fabbione: Sure.  Is there any way to share the ccache with you?
<fabbione> ccache is installed and configured both in my concordia env and the buildd's
<fabbione> jbailey: nope.. given that's in my home..
<fabbione> just use a fresh one
<jbailey> Feh.
<jbailey> a'ight then. =)
<fabbione> if it is an overabuse of mv and rm, ccache might be the culprit
<fabbione> since it does a lot of that stuff
<jbailey> Well, but I'm not using ccache, and I'm getting segfaults in that.
<jbailey> Spurious segfaults bad.
<jbailey> Makes me think of flakey ram.
<fabbione> nah
<fabbione> it can't be on all the amd64 machines
<fabbione> concordia and one of the buildd at least show the same problem
<jbailey> I haven't seen other reports of segfaults in coreutils bits.
<jbailey> I mean, how complicated is the mv command internally?
<fabbione> open, cp, unlink?
<jbailey> I thought mv was an atomic operation.  I think it's just a syscall.
<jbailey> Plus the usual GNU fluff around it, but there isn't exactly alot of room for a segfault in there...
<fabbione> no, i don't think so
<jbailey> Hmm.  Do I have to do anything to make sure that my ccache in my amd64 dchroot doesn't chew on my ccache in my i386 dchroot?
<fabbione> jbailey: chance the CCACHEPATH?
<fabbione> CCACHE_DIR=/usr/src/.ccache
<fabbione> change that one in your env
<jbailey> Ugh, so it doesn't do arch detection automatically.  Ah well.
<fabbione> well i did always share my ccache between amd64 and i386
<fabbione> there is no way the 2 will overlap for a mistake
<jbailey> With no conflicts?
<fabbione> the hash towards the final ccache file will make it impossible
<jbailey> Because of the compiler defines?
<fabbione> but well.. 
<fabbione> exactly
<fabbione> compilers define, different gcc version
<fabbione> afaik ccache uses gcc --version to detect gcc changes
<fabbione> so it's like using 2 different gcc's
* jbailey waves the voodoo wand at ccache
<lamont> jbailey: uh, no... all 3 gcc compilers are part of that list.. :-)
<jbailey> lamont: How is ia64?
<lamont> jbailey: building, but not very install-happy
* lamont needs to do more testing this week
<jbailey> I should be bringing my ia64 within arms reach soonish.
<jbailey> Hopefully I can start helping with that by the end of the month.
<jbailey> 'kay ccache wired up and working, restarting build.
<lamont> thanks
#ubuntu-toolchain 2005-07-17
<doko> hope you don't fail on other things than sleeping ;)
<fabbione> morning
<jbailey> lamont__: Have I fixed all of the packages on the annoying-you list?
<lamont__> dunno...
<jbailey> ISTR iptables (fabio got that one) iputils, and strace.
<jbailey> hfsplus I did already
<lamont__> if you're really bored, moz-thunderbutt is failing with /usr/bin/ld: cannot find -lssl3
<lamont__> limiting mail to "incomplete type", I have:
<lamont__>       144 Log for failed build of deco_3.9-1 (dist=breezy)
<lamont__>      1250 Log for failed build of honeyd_1.0a-rc2-1 (dist=breezy)
<lamont__>       222 Log for failed build of iputils_3:20020927-2 (dist=breezy)
<lamont__>      1608 Log for failed build of iterm_0.5-3.1ubuntu1 (dist=breezy)
<lamont__>       450 Log for failed build of kdrill_6.4-2 (dist=breezy)
<lamont__>       434 Log for failed build of pyspeex_0.2-1ubuntu1 (dist=breezy)
<lamont__>       857 Log for failed build of sam_4.3-18 (dist=breezy)
<lamont__>       256 Log for failed build of strace_4.5.12-1 (dist=breezy)
<lamont__>      6334 Log for failed build of ultrapossum-slapd_0.0.4+2.2.20sb3-1 (dist=bree
<lamont__>       219 Log for failed build of umsdos_1.13-2.1 (dist=breezy)
<lamont__>       525 Log for failed build of wacom-tools_0.6.6-8 (dist=breezy)
<lamont__>      1431 Log for failed build of xcruise_0.30-4ubuntu1 (dist=breezy)
<lamont__>      1435 Log for failed build of xmailbox_2.5-9 (dist=breezy)
<lamont__> but several of those are universe
<jbailey> I'm not bored so much as trying to make sure that I'm not forgetting things.
<jbailey> Are those failing on hppa, or also likely to fail on a released arch during a rebuild?
<lamont__> those are at least hppa, quite possibly other architectures
<lamont__> I haven't tried rebuilding all of them....
<jbailey> deco builds on ppc
<jbailey> honeyd builds on ppc
<lamont__> oh, and universe--> don't really care
<jbailey> Iterm.c:35:28: error: X11/IntrinsicP.h: No such file or directory
<jbailey> universe
<lamont__> tty.c: In function `TtySet':
<lamont__> tty.c:147: error: `TIOCGLTC' undeclared (first use in this function)
<lamont__> iz deco/hppa
<jbailey> Hmm.
<lamont__> tty.c:148: error: `newchars' has an incomplete type
<jbailey> TIOCGLTC isn't defined in the asm* for parisc
<jbailey> Hmm, not for ia32 either, but is for alpha, ppc, ppc64, sparc and sparc64.
<jbailey> lamont__: Is universe required for releasing?
<lamont__> not precisly\
<jbailey> Interesting.
<jbailey> Your build env appears to be confused:
<jbailey> #ifdef TIOCSLTC
<jbailey>         ioctl (CHANNEL, TIOCGLTC, (char *) &oldchars);
<jbailey> You should never get as far as seeing it undeclared.
<jbailey> (That's 146, 147)
<jbailey> No, I'm blind.
<jbailey> In any event, the right solution for you for deco is to figure out why HAVE_TERMIO_H isn't set.
<jbailey> kdrill is also X breakage
<jbailey> pyspeex is a missing build-dep
<jbailey> We're not really going to force a rebuild on universe and pitch FTBFSs are we?
<jbailey> There's no way the MOTUs will get all of these done.
<jbailey> sam is X header breakage.
<jbailey> umdos is lkh brekage, but since it was removed from the kernel, do we care?
<lamont__> we are going to do a breezy-autotest and file ftbfs bugs on everything... what happens from there is an mdz question, not me
<jbailey> wacom-tools builds fine here.
<jbailey> The others I'll assume are X failures.
<jbailey> I'll declare the LaMont box to be empty now and move on
<lamont__> jbailey: works for me, for now
<jbailey> Why do I imagine you saying that in the same tone as "We'll get you next time, Gadget!"
<jbailey> For Hoary, do we now set the distro to "hoary-updates" ?
<lamont__> if it qualifies for hoary-updates
<lamont__> same logic applies for -security and -backports...
<lamont__> if it qualifies for any of the 3, then you use that.
<lamont__> uploads to 'hoary' will be rejected by katie
<jbailey> Cool, thanks.
* jbailey starts the test builds for one last pass and uploads glibc to hoary-updates
<lamont__> jbailey: 2.3.5? :-)
<jbailey> Of course.  You know the backports people did it wrong.  If you're going to break the system, FINISH THE JOB DAMMIT
<doko> lamont: are you caballero's buildd admin?
<lamont__> yes
<lamont__> ya, even
<doko> then please fix it ...
<doko> gcc-4.0 doesn't find the sources for the build
<doko> strange ...
#ubuntu-toolchain 2006-07-11
<doko> jbailey: biarch headers are currently installed in /usr/include/ppc64-linux-gnu on powerpc, which is wrong (but currently gcc and glibc are consistently wrong). to change that, I would need a glibc upload moving /usr/include/ppc64-linux-gnu to /usr/include/powerpc64-linux-gnu, but keeping a ppc64-linux-gnu symlink
<doko> until the biarch compilers are updated
<jbailey> doko: Sure, or we could just ask adam to make sure they go in at the same time and have the right dependancy on one another.
<jbailey> That way we don't have a transition headache at all.
<doko> doesn't work; I need the dir for building gcc , and can map only one directory (multilibdir -> biarchdir)
<jbailey> Meh.  a'ight then.
<jbailey> I'll aim for that after UVF, I have a couple things to do before.
<doko> ok
#ubuntu-toolchain 2006-07-12
<jbailey> doko: the /usr/include/powercp64-linux-gnu problem will affect lkh as well.  Hmm...
<jbailey> doko: Is the problem just that it's not the correct GNU triple?
<doko> jbailey: yes
<jbailey> 'kay.  It'll be a bit of fun.  I suspect that the right thing will be to do the transition locally and hand it all to Adam in binary form to bootstrap and slip in.
<jbailey> Anyhow, need to run!
<doko> infinity: bootstrap ping
<jbailey> doko: He's been sick.
<rodarvus> hi
<rodarvus> any gcc expert online?
<rodarvus> I  had a gcc crash build mesa
<rodarvus> ugh
<rodarvus> I had a gcc crash building mesa, just a few minutes ago
<jbailey> rodarvus: Paste the bug, maybe I can help.
<jbailey> If not, doko will see it when he's back.
<rodarvus> hope nobody bothers if I paste it here :)
<rodarvus> cc -c -I../../include -I../../src/mesa -I../../src/mesa/main -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl -I../../src/mesa/shader -I../../src/mesa/shader/grammar -I../../src/mesa/shader/slang -I../../src/mesa/shader/slang/OSDependent/Linux -I../../src/mesa/shader/slang/OGLCompilersDLL -I../../src/mesa/swrast -I../../src/mesa/swrast_setup -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GN
<rodarvus> U_SOURCE -DUSE_XSHM -DPTHREADS -ansi -pedantic -Wall -fPIC -std=c99 -O3 -march=i686 -msse -mfpmath=387 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM shader/arbprogparse.c -o shader/arbprogparse.o
<rodarvus> shader/arbprogparse.c: In function parse_attrib_binding:
<rodarvus> shader/arbprogparse.c:1425: warning: texcoord may be used uninitialized in this function
<rodarvus> shader/arbprogparse.c:1509: warning: unit may be used uninitialized in this function
<rodarvus> shader/arbprogparse.c: In function parse_arb_program:
<rodarvus> shader/arbprogparse.c:3437: warning: Negate[1]  is used uninitialized in this function
<rodarvus> shader/arbprogparse.c:3437: warning: Negate[2]  is used uninitialized in this function
<rodarvus> shader/arbprogparse.c:3437: warning: Negate[3]  is used uninitialized in this function
<rodarvus> shader/arbprogparse.c:3864: internal compiler error: Segmentation fault
<rodarvus> Please submit a full bug report,
<rodarvus> with preprocessed source if appropriate.
<rodarvus> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
<rodarvus> For Debian GNU/Linux specific bug reporting instructions,
<rodarvus> see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
<rodarvus> The bug is not reproducible, so it is likely a hardware or OS problem.
<rodarvus> make[3] : *** [shader/arbprogparse.o]  Error 1
<rodarvus> make[3] : Leaving directory `/home/rodarvus/canonical/code/merges/mesa/ubuntu/mesa-6.4.1/build/gl-debian_i386/src/mesa'
<rodarvus> make[2] : *** [default]  Error 2
<rodarvus> make[2] : Leaving directory `/home/rodarvus/canonical/code/merges/mesa/ubuntu/mesa-6.4.1/build/gl-debian_i386/src/mesa'
<rodarvus> make[1] : *** [subdirs]  Error 1
<rodarvus> make[1] : Leaving directory `/home/rodarvus/canonical/code/merges/mesa/ubuntu/mesa-6.4.1/build/gl-debian_i386/src'
<rodarvus> make: *** [debian/stamp/target-gl-debian_i386]  Error 2
<rodarvus> jbailey: I'm rebuilding mesa right now, to check if the error is somehow hardware related
<jbailey> rodarvus: Try dropping from -O3 to -O2.
<jbailey> -O3 includes some experimental optimisations sometimes that can cause troubles.
<jbailey> If that fixes it, it's still worth filing a bug.  doko can always work with you to get a reduced testcase.
<rodarvus> hmm, actually I've just bitten my own tongue - I was able to manually compile it, even with -O3
<rodarvus> so indeed it looks like something hardware "or OS" related :/
<rodarvus> jbailey: thanks!
<doko> I like hardware problems :-)
<doko> better than compiler bugs
<Keybuk> "It's your set up"
#ubuntu-toolchain 2006-07-13
<doko> jbailey: please could you temporarily revert the linux-kernel-headers change, moving ia64 and hppa headers to the multiarch location. gcc currently doesn't include that directory on non biarch architectures, but I cannot bootstrap it anymore.
<jbailey> doko: Sure, np.  How long do you need it for?
<doko> jbailey: until it's enabled in all compilers ... so may take a while
<jbailey> Hmm.  Is it hard to do?  I would like this in before feature freeze - it's part of what we spec'd in the roadmap as an optional component.
<doko> jbailey: hard, or not, we need to get at least the default gcc bootstrapping again.
<jbailey> Eh?  I think you misunderstood my  question.  How hard is it to multiarch those architectures to look in those paths?
<jbailey> Like, if I upload lkh today, and you upload a new gcc today, can I upload the old lkh tomorrow?
<doko> jbailey: ohh, yes, it's easy, except that we're frozen for the CD's, and powerpc should be built first. I have to look at gcc-3.4 and gcc-4.0 as well. need to do something else done than the toolchain as well
<jbailey> 'k
<doko> or have infinity build the gcc's with an old lkh
<infinity> That could be done, but eww.
<infinity> Best to just have Jeff revert the change and do it right.
<jbailey> Your call.  Either way, I won't be looking at this for a couple hours.
<infinity> gcc-4.1 on PPC will be fine by tomorrow.
<jbailey> You're welcome to do the revert yourself now if you need.
<jbailey> Just change the installed path in the rules file to go to /usr/include for linux/ and the main asm/ directory.
<jbailey> The biarch systems should still prefer the biarch asm directories.
<jbailey> (linux is already in the common one, I think.. Just the asm/ needs to be moved)
<jbailey> fabbione: sparc64 headers bug in lkh is amusing, looks like the problem is a Kbuild one:
<jbailey> <Clint> -unifdef-y := fbio.h perfctr.h
<jbailey> <Clint> +unifdef-y += fbio.h perfctr.h\
<jbailey> =)
<fabbione> whops...
<fabbione> same as ppc?
<jbailey> Hmm?
<jbailey> this isn't your mesa failure.
<jbailey> Oh wait, you didn't point that one out to me.
<jbailey> Keybuk: ^^
<jbailey> =)
<Keybuk> right
<doko> jbailey, fabbione: hmm, but the gcc-4.1 build failure on sparc is the same?
<Keybuk> sparc64 was one failure
<Keybuk> mesa's failure is still the same symptom (missing asm/errno.h) but a different problem
<Keybuk> ergo gcc not looking in /usr/include/ia64-linux-gnu on ia64
<Keybuk> (on ia64, at least)
<doko> Keybuk: on all non-biarchs, so it should fail on hppa as well
<Keybuk> doko: yes, but we don't care about hppa
<Keybuk> because hppa isn't on our build system
<doko> why not, I thought we had the machines in the data center?
<Keybuk> they don't get builds
<Keybuk> (I don't know _why_ they don't get builds, they just don't)
<fabbione> jbailey: sorry you lose me than...
<fabbione> doko: edgy/hppa is waiting glibc ntpl or the world will chease to exist in one ms
<jbailey> Keybuk: They'renot building atm because they didn't meet the initial upload requirements.  They have no functioning glibc 2.4 with NPTL.
<jbailey> Keybuk: Architectures that can't meet basic toolchain requirements (current kernel, gcc, gdb, glibc) get a fairly serious no-sympathy treatment.
<jbailey> I'm working with the parisc folks to get a workign nptl for parisc, though.
<jbailey> I'm trying very hard to get that arch up and running and working by Feature Freeze.
<Keybuk> jbailey: right, I just mean I don't understand how they're disabled from an LP point of viedw
<Keybuk> I knew they were deliberately down
<jbailey> Oh, yeah.  No idea. =)
<jbailey> I think that they just don't have chroots registered for edgy.
<Keybuk> then they'd be waitingchroot, no?
<Keybuk> though they do not have a chroot, you're right
#ubuntu-toolchain 2006-07-14
<jbailey_> Joy
<jbailey_> /home/jbailey/Programming/packaging/glibc-2.4/glibc-2.4/build-tree/powerpc-libc/libc_pic.a(init-first.os): In function `_dl_start':
<jbailey_> ../sysdeps/unix/sysv/linux/init-first.c:107: dfinitions multiples de  _dl_start 
<jbailey_> Reverted to old lkh, in case I had done something weird.
<jbailey_> doko: Current edgy gcc-4.1 can't build glibc (ppc).  4.1.1-2ubuntu4 can.
<jbailey_> It also needs a fixed lkh, which I'll upload after I confirm it with Tollef.
<jbailey_> Well.
<jbailey_> It needs to be tweaked for the lkh rearrange, rather.
<jbailey_> But either way I'll upload an lkh that will work for you on parisc and ia64.
#ubuntu-toolchain 2007-07-13
<jbailey> doko: ping?
<doko> jbailey: pong
<jbailey> doko: I'm wondering where gdb is maintained.  I'll have a parisc patch to go in.
<doko> no archive
<jbailey> Cool, any objection to me just doing an upload?
<doko> no, please go ahead
<jbailey> Thanks.
<doko> jbailey: did you have a look at gij?
<jbailey> Yes.  There's a segfault in the boehm-gc.
<jbailey> I complained about the fact that I was having to use printf to debug, so tausq fixed gdb for me. =)
<doko> you may want to join #gcj on oftc and ask aph; he just got it on arm working and is willing to help if he has access to hardware
<jbailey> Yeah.  I haven't narrowed it to something to ask others yet.
<jbailey> I suspect that the locks are just wrong for NPTL in the boehm-gc gcj bits, they changed size.
<jbailey> I was hacking mostly last weekend (we're in the middle of selling our place, evenings are busy), and tausq fixing gdb will make a big difference, too.
#ubuntu-toolchain 2008-07-09
<Pizzaboy192> good mornig
<Pizzaboy192> i heed some help with hardware problems
