| doko | hmm, interesting. I didn't look at the default for -m32 on amd64 | 12:04 |
|---|---|---|
| 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:08 |
| 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:10 |
| 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:11 |
| 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:13 |
| doko | heh | 12:14 |
| jbailey | I like Ubuntu. If nothing else, we're efficient. =) | 12:14 |
| doko | ;) | 12:14 |
| 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:17 |
| === doko_ [n=doko@dslb-084-059-078-133.pools.arcor-ip.net] has joined #ubuntu-toolchain | ||
| 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:44 |
| lamont__ | gcc-3.4_3.4.5-1ubuntu3 | 12:45 |
| doko | test results are ok | 12:48 |
| 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 | 12:49 |
| lamont__ | doko: that's on dapper, as of now, yes? | 03:29 |
| 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:30 |
| 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:31 |
| lamont__ | right | 03:32 |
| lamont__ | rather significantly. they were defaulting to -mtune=i686 before, yes? | 03:32 |
| 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:33 |
| lamont__ | doko: and btw, tahtwas a fatality in the gcc-3.4 build.. | 03:46 |
| lamont__ | maybe it doesn't like smp | 03:46 |
| mdz | doko: wouldn't that be the same thing as disabling gcc-opt altogether? | 04:57 |
| elmo | mdz: no, it still does some other stuff | 05:00 |
| elmo | like default to -O2, force -pipe etc. | 05:00 |
| 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:01 |
| lamont | elmo: has not defaulted to -O2 since we did the archive flush in oxford | 05:36 |
| lamont | -O2 by default was, um, bad. | 05:36 |
| === lamont -> bed | ||
| 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) | 06:29 |
| 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:18 |
| 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:24 |
| 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:25 |
| fabbione | hmm nevermind it might be my mistake | 07:37 |
| fabbione | hmm no | 07:38 |
| fabbione | oh well after the shower :) | 07:38 |
| fabbione | must have been a transient error with mirror syncs | 08:07 |
| === chmj [n=chmj@dsl-146-143-211.telkomadsl.co.za] has joined #ubuntu-toolchain | ||
| 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:04 |
| 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 | 09:06 |
| === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain | ||
| lamont | doko: it would be nice if SyncTest.exe didn't hang around forever (gcj-4.1, iirc) | 02:54 |
| === lamont -> work | ||
| doko | lamont-away, lamont: hppa? | 03:04 |
| === lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-toolchain | ||
| jbailey | Nice! I have libc6-i386 building on amd64. | 04:00 |
| 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:01 |
| infinity | Is there nothing else in ia32-libs anymore? | 04:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| infinity | I can't really blame him. | 04:19 |
| === chmj [n=chmj@dsl-146-143-211.telkomadsl.co.za] has joined #ubuntu-toolchain | ||
| 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:19 |
| doko | jbailey: yes, Replaces ... | 04:20 |
| infinity | The dpkg -L output? | 04:20 |
| infinity | Yeah, that's what I was looking at too. :) | 04:20 |
| 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:30 |
| === jbailey grumps | ||
| 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:34 |
| 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:36 |
| 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:37 |
| doko | no, but we probably need to ship that, if the native build is too unstable | 04:40 |
| 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 | 04:41 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!