[12:04] <doko> hmm, interesting. I didn't look at the default for -m32 on amd64
[12:08] <jbailey> Bah.
[12:08] <jbailey> I already have a different libc6-i686, and debian/control can't cope with multiple stanzas targetted to different arches.
[12:10] <doko> well, do we care, waht happens, if somebody tried to run an executable built with gcc -m32 on i486 or i586?
[12:10] <jbailey> Mmm.
[12:10] <jbailey> But off the cuff response is "No"
[12:11] <jbailey> We're providing biarch for application compatability, not development.
[12:11] <jbailey> Might be worth asking mdz for a ruling on that, though.
[12:11] <jbailey> mdz: Around?
[12:13] <mdz> jbailey: yep
[12:13] <mdz> reading
[12:13] <mdz> gcc -m32 on amd64 -> i486/i586 -> don't care
[12:13] <jbailey> mdz: Thanks.
[12:14] <doko> heh
[12:14] <jbailey> I like Ubuntu.  If nothing else, we're efficient. =)
[12:14] <doko> ;)
[12:17] <jbailey> Lovely.  The build is running.  I'll poke it over the next day or so until I'm happy with it an upload.
[12:44] <lamont__> gcc-3.4.gcc-opt: f~D@$V@={=p@;QP@=y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
[12:44] <lamont__> gcc-3.4.gcc-opt: P@=y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
[12:44] <lamont__> gcc-3.4.gcc-opt: y8@=@=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
[12:44] <lamont__> gcc-3.4.gcc-opt: @=q$@=c=B @=u~@@=U=-prototypes: No such file or directory
[12:44] <lamont__> gcc-3.4.gcc-opt: @=U=-prototypes: No such file or directory
[12:44] <lamont__> <command line>:4:1: macro names must be identifiers
[12:44] <lamont__> wth???
[12:45] <lamont__>  gcc-3.4_3.4.5-1ubuntu3
[12:48] <doko> test results are ok
[12:49] <doko> lamont__, while you are here, please can you change gcc-opt, so that it doesn't add -mtune=pentium4 on i386? all gcc packages are configured to default to that option
[03:29] <lamont__> doko: that's on dapper, as of now, yes?
[03:30] <elmo> doko: err, I know I suggested that, but come to think of it, it's a very big change
[03:30] <lamont__> elmo: yeah
[03:30] <elmo> we're going from defaulting to -mtune=pentium4 for our builds, to -mtune=pentium4 for _all_ our _users_' builds
[03:31] <lamont__> note that the current gcc-opt only, um, inserts as the first arg '-mtune=pentium4' if no -mtune option is present
[03:31] <elmo> lamont: doko's change does  the same thing
[03:31] <elmo> the thing we're changing here is scope
[03:32] <lamont__> right
[03:32] <lamont__> rather significantly.  they were defaulting to -mtune=i686 before, yes?
[03:33] <elmo> no?
[03:33] <elmo> -mtune=i386 AFAIK
[03:33] <lamont__> it was -march=i486
[03:33] <lamont__> so tune=i386 would be kinda silly...
[03:46] <lamont__> doko: and btw, tahtwas a fatality in the gcc-3.4 build..
[03:46] <lamont__> maybe it doesn't like smp
[04:57] <mdz> doko: wouldn't that be the same thing as disabling gcc-opt altogether?
[05:00] <elmo> mdz: no, it still does some other stuff
[05:00] <elmo> like default to -O2, force -pipe etc.
[05:01] <elmo> but it would get rid of it's major raison d'etre, yeah
[05:01] <elmo> that was the point tho.  doko didn't like the "hidden" -mtune forceage
[05:36] <lamont> elmo: has not defaulted to -O2 since we did the archive flush in oxford
[05:36] <lamont> -O2 by default was, um, bad.
[06:29] <mdz> I thought on that rebuild we changed from forcing -O2 to forcing -O2 only if it wasn't specified (e.g., -O0 debug builds)
[07:18] <fabbione> doko: for some reasons OOo2 on ppc gets removed.. 
[07:18] <fabbione> on a dist-upgrade or upgrade
[07:18] <fabbione> gonna check why
[07:24] <fabbione>   openoffice.org2-l10n-en-us: Conflicts: openoffice.org2-core (>= 1.9.130) but 2.0.0m143-0ubuntu2 is to be installed
[07:24] <fabbione> apt-get install openoffice.org2-common openoffice.org2-core
[07:24] <fabbione> The following packages have unmet dependencies:
[07:24] <fabbione>   openoffice.org2-common: Depends: openoffice.org2-l10n-en-us (>= 1.9.129) but it is not going to be installed
[07:24] <fabbione>   openoffice.org2-core: Depends: openoffice.org2-common (> 2.0) but 1.9.129-0.1ubuntu4 is to be installed
[07:25] <fabbione> apt-get install openoffice.org2-common openoffice.org2-core openoffice.org2-l10n-en-us
[07:25] <fabbione> The following packages have unmet dependencies:
[07:25] <fabbione>   openoffice.org2-core: Depends: openoffice.org2-common (> 2.0) but 1.9.129-0.1ubuntu4 is to be installed
[07:25] <fabbione>   openoffice.org2-l10n-en-us: Conflicts: openoffice.org2-core (>= 1.9.130) but 2.0.0m143-0ubuntu2 is to be installed
[07:25] <fabbione> strange that it doesn't happen on amd64
[07:37] <fabbione> hmm nevermind it might be my mistake
[07:38] <fabbione> hmm no
[07:38] <fabbione> oh well after the shower :)
[08:07] <fabbione> must have been a transient error with mirror syncs
[09:04] <doko> elmo, lamont__: the previous default was -mtune=i686, we didn't optimize for i386 at any time.
[09:04] <doko> fabbione: maybe because the i386 build wasn't yet ready?
[09:04] <fabbione> doko: now it's there
[09:04] <fabbione> ppc installs
[09:04] <fabbione> amd64 doesn't
[09:06] <doko> yes, need to upload the i386 binaries for amd64 as well (what we had before)
[09:06] <fabbione> ahhhhh
[09:06] <fabbione> ok
[09:06] <fabbione> that makes sense
[09:06] <fabbione> still -experimental- is borked too
[02:54] <lamont> doko: it would be nice if SyncTest.exe didn't hang around forever (gcj-4.1, iirc)
[03:04] <doko> lamont-away, lamont: hppa?
[04:00] <jbailey> Nice!  I have libc6-i386 building on amd64.
[04:01] <jbailey> Assuming it passes the testsuite (I don't see why it wouldn't), then I just need to sort out the conflicts/replaces/build-dep pieces and libc6 biarch can go in.
[04:01] <jbailey> doko: Should I just conflicts/replaces ia32-libs do you think?
[04:01] <jbailey> doko: The idea is that it goes away entirely, isn't it?
[04:09] <infinity> Is there nothing else in ia32-libs anymore?
[04:10] <infinity> Erk, not there's a bunch of stuff in there.
[04:10] <infinity> Make it Replaces, but not conflicts.
[04:10] <infinity> (And if you co-ordinate with Mithrand1r to actually remove libc6 from ia32-libs, than can be a nice versioned Replaces)
[04:10] <jbailey> infinity: I think the idea is that they were supposed to ultimately all get replaced now.
[04:11] <jbailey> Something needs to finally remove it.  Last I checked ia32-libs contained egcs, gcc-2.95 and crap that ought to be taken away.
[04:11] <infinity> No, I don't see any of that junk, but I do see a mess of X libs and such.
[04:12] <infinity> It should be pared away one file at a time.
[04:12] <infinity> When it's completely "replaced", dpkg will be smart enough to remove it.
[04:12] <infinity> (dpkg marks packages removed if they have an empty file list)
[04:12] <jbailey> Won't /usr/share/doc/ia32-libs always be there?
[04:12] <infinity> Alternately, once they're all replaces, ia32-libs cna become a metapackage for smooth upgrades.
[04:12] <infinity> Whatever.
[04:12] <jbailey> Mm, yeah.
[04:13] <jbailey> Okay, so just a replaces, and a build-dep on the newer lkh.
[04:13] <infinity> At any rate, there's amess of stuff in there right now and systems will go tits up without it.
[04:13] <infinity> (Well, systems like mine where I run 32-bit apps..)
[04:14] <jbailey> Woot, only one test failure and it's the expected one.
[04:14] <infinity> If you feel like making it a versioned replaces and getting someone to update ia32-libs to remove the libc6 bits, more power to ya'.
[04:14] <infinity> I'd do it, but ia32-libs disagrees with my complete lack of bandwidth.  It's a HUGE upload.
[04:14] <jbailey> infinity: I don't think I care enough across the development cycle.
[04:14] <jbailey> It's actively going away, so if a replaces will handle it for now and we can just power through the rest of the packages, that's more ideal.
[04:15] <infinity> Should do, assuming you're installing to the same paths..
[04:15] <jbailey> Yeah, checking that now. =)
[04:15] <infinity> I hope you are. :)
[04:15] <jbailey> 45 meg source file.  That just hurts.
[04:16] <infinity> The binary isn't drastically better.
[04:16] <jbailey> Wow.  There's a remarkable pile of crap in here.
[04:16] <infinity> Yup.
[04:17] <infinity> Everything one needs to run a whole host of crappy 3rd party binary apps.
[04:17] <infinity> Multi-arch can't come too soon.
[04:17] <jbailey> I don't see any coreutils bits in the breezy ia32-libs.
[04:17] <jbailey> I wonder what that's for then.
[04:17] <infinity> ...?
[04:17] <infinity> Why would you want coreutils in ia32-libs?
[04:18] <jbailey> It's in there now.
[04:18] <infinity> Oh, you mean the .deb is in the "source" package?
[04:18] <jbailey> The source for coreutils is in the source for ia32-libs
[04:18] <infinity> Yeah, uhm.  Who knows.
[04:18] <jbailey> I have to be careful, if I do more recursion than that I start adding ( )'s all over the place.
[04:18] <infinity> I think Tollef lost all will to care about ia32-libs long ago, so whatever cruft it's gathered over time hasn't been cleaned up.
[04:19] <infinity> I can't really blame him.
[04:19] <infinity> It's a hack that just needs to Go The Fuck Away.
[04:19] <jbailey> No mention of coreutils in the rules file.
[04:19] <jbailey> Lovely. =)
[04:19] <jbailey> Ooo, in fact it hasn't been updated since breezy.  Perfect.  I can assume the output on Angie's machine is right.
[04:20] <doko> jbailey: yes, Replaces ...
[04:20] <infinity> The dpkg -L output?
[04:20] <infinity> Yeah, that's what I was looking at too. :)
[04:30] <jbailey> Mmm.  It's not going to perfectly the same.
[04:30] <jbailey> infinity: How many apps do you think will break if I drop linuxthreads on the biarch version?
[04:34] <jbailey> I had originally planned to drop LT on regular i386 for this release, but it makes sense to keep it on the native side for the long lived release.
[04:36] <doko> hmm, so what happens, when we move apps built on i386/LT to i686/NPTL?
[04:36] <jbailey> The theory is that it works. =)
[04:36] <jbailey> In practice we've tested that theory.
[04:36] <jbailey> All the machines we install have libc6-i686 installed already.
[04:37] <jbailey> So the HWCAP seeking will be always using the i686/nptl libraries.
[04:37] <doko> please test oo2 before you do that ;)
[04:37] <jbailey> Do you mean for amd64 biarch, test OOo2 that was compiled with i386?
[04:37] <jbailey> Why would anyone ever do that? =)
[04:40] <doko> no, but we probably need to ship that, if the native build is too unstable
[04:41] <jbailey> Ah, I thought we were doing native builds with OOo2
[04:41] <doko> _if_ they are stable, upstream/novell says, they are not yet production quality