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