[03:53] <jbailey> lamont: Are you power building universe with the older gcc? =)
[05:35] <lamont> jbailey: 3.4
[05:53] <jbailey> Nice.  How caught up are you?
[06:02] <fabbione> morning
[07:39] <doko> good morning
[07:39] <fabbione> hey doko
[07:39] <fabbione> doko: OO2 is FTBFS on sparc :)
[07:39] <fabbione> the error message is quite strange tho
[07:40] <doko> which one, 108 or 113?
[07:40] <fabbione> 113
[07:41] <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()':
[07:41] <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
[07:41] <fabbione> i will put the log online somewhere.. it's quite big atm
[07:42] <fabbione> but it's not high priority for me
[07:42] <fabbione> i would be more happy to get the gcc ice fixed
[07:43] <fabbione> and to understand what's wrong with the mail i just forwarded to you
[07:50] <fabbione> doko: the build log is online on people.u.c/~fabbione/
[07:51] <doko> hmm, the gnome-games one is about a symbol in two libc files.
[07:53] <fabbione> where is jbailey when i need to objectifing him a bit
[07:56] <doko> he smells the trouble, pretending "switching machines." ;)
[11:54] <doko> fabbione: where can I find the file.i for the unionfs ICE, where the command line args?
[03:06] <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
[03:08] <jbailey> Right,  but I remember that you said that you wanted to build as much of universe as possible, first.
[03:09] <lamont> jbailey: I said I was racing doko
[03:15] <jbailey> *lol*
[03:15] <jbailey> Right, and I'm sure there were 12 buildds participating in the racing.
[03:17] <lamont> exp.c:75: warning: conflicting types for built-in function 'exp2'
[03:17] <lamont> three cheers for csh!
[03:30] <doko> jbailey: hi
[03:30] <doko> jbailey: we need the multiarch stuff for gcc, libstdc++ header files aren't correct for biarch's
[03:30] <jbailey> Heya Matthias
[03:31] <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.
[03:32] <jbailey> lamont: Yes, I don't consider it version-freeze material.
[03:41] <lamont> doko: eta on a gcc-3.4_3.4.4-3ubuntu2 (or later) upload?
[03:41] <lamont> brb
[03:43] <doko> lamont: did I forget something?
[03:43] <lamont> 3ubuntu1 was ftbfs on hppa
[03:44] <lamont> bad multiarch patch
[03:46] <lamont> ??
[03:46] <doko> ahh, yes
[03:46] <lamont> (I think that was the issue.
[03:46] <lamont> yeah - died in build-hppa64
[03:46] <lamont> back in a few
[03:48] <doko> months?
[03:51] <jbailey> Wow  590kB/s off of archive.ubuntu.com.  I do like this new ISP.
[03:52] <jbailey> My last one was like 30kB/sec
[04:08] <lamont> doko: sigh... I might upload it if it's gonna be months..
[04:09] <jbailey> i think he was completing your sentence...
[04:09] <lamont> jbailey: feh!
[04:10] <jbailey> Right, you don't have one of those.  Bloody americans.  /me tries again on the humor filter this time...
[04:10] <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..)
[04:10] <lamont> jbailey: hehe
[04:10] <doko> lamont: yes, I know ... please submit a bug report to bugzilla ...
[04:11] <lamont> ok
[04:11] <lamont> uh - for which?
[04:11] <doko> gcc-4.0 ?
[04:11] <lamont> ok.
[04:11] <lamont> (was multiarch gcc-3.4 bug vs X build-dep)
[04:12] <lamont> that I was asking, that is
[04:13] <doko> was uploaded while you were taking your nap ;)
[04:16] <lamont> huh?
[04:16] <lamont> I think we may be talking about 3 issues here:
[04:16] <doko> sorry, s/taking your nap/away/
[04:16] <lamont> 1) gcc-3.4 has a multiarch bug that you will upload sometime
[04:17] <lamont> 2) /me to file a bug about gcc-4.0's insane build-deps
[04:17] <lamont> 3) gcc-4.0 currently not building on hppa because xorg isn't installable, see 2
[04:18] <doko> 1) done
[04:19] <doko> disable java until 3) is fixed
[04:19] <lamont> 12444, assigned to doko
[04:19] <lamont> well, X might be installable
[04:19] <lamont> it tripped over 4) archive updates aren't atomic, so apt-get update fails randomly in a transient manner
[04:20] <lamont> 1) way cool
[04:21] <jbailey> I thought archive updates were made atomic  by uploading debs first, then updating package files then deleting old debs?
[04:21] <lamont> 3) modifying the source isn't really a solution for me, since I can't upload the resultant binaries to the archive
[04:21] <lamont> jbailey: yeah
[04:21] <doko> I'll disable java for the next 4.0 upload
[04:21] <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
[04:21] <lamont> doko: shouldn't be needed
[04:22] <doko> ok
[04:22] <lamont> doko: lets leave it enabled, and I'll just have to get through the rest of my issues..
[04:22] <jbailey> lamont: lockd?
[04:22] <lamont> hrm... how much lead shot is a dollar's worth.....
[04:22] <jbailey> =)
[04:23] <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
[04:28] <doko> ok
[10:29] <lamont> jbailey: /usr/include/sys/ucontext.h:49: error: array bound is not an integer constant
[10:30] <jbailey> hppa?
[10:31] <jbailey> Hmm.
[10:31] <jbailey> That's not an arch specific file
[10:31] <jbailey>         unsigned int vrregs[32] [4] ;
[10:35] <lamont> hppa
[10:35] <lamont> typedef struct fpregset
[10:35] <lamont>   {
[10:35] <lamont>     double fp_dregs[32] ;
[10:35] <lamont>   } fpregset_t;
[10:35] <lamont> line 49 is the "typedef struct fpregset"
[10:36] <jbailey> This is breezy?
[10:36] <lamont> hrmpf.  one for me to investigate later. yes breezy
[10:37] <lamont> er...
[10:39] <lamont> feh
[10:39] <lamont> ia64, sid
[10:40] <lamont>             unsigned long _pad[_SC_GR0_OFFSET/8] ; 
[10:40] <lamont> clearly I was looking at too many logfiles in rapid succession