=== lamont [n=lamont@15.238.5.82] has joined #ubuntu-toolchain [04:13] lamont : Feh, if 'linux32 uname -m' on parisc64 is returning parisc64, not parisc, then parisc64 personalities are broken. I was almost sure that had been addressed long ago, but maybe not (I never owned a parisc64 machine, so this was all from memory) [04:13] My parisc machine was a lowly 32-bit C200. [04:17] lamont : Pretty please, with sugar on top, pester linux-parisc upstream to fix 32/64 kernel personalities, push the patch upstream, and use that patch on your buildd. :) [04:17] infinity: parisc _ALWAYS_ returns parisc64 [04:17] always has (on a 64-bit kernel_) [04:17] No it doesn't. Only when running a parisc64 kernel. [04:17] that's what I said. :-) [04:17] Anyhow, it's broken. It shouldn't. That's what personalities are for (it's ALL they're for) [04:18] We just got it fixed for ppc/ppc64 in 2.6.12, now it's your turn. :) [04:18] yeah - jbailey's going to beat on the parisc folks, but in the mean time, we'll just do the hack to klibc that has been done everywhere else [04:18] [04:19] I assume you had line-of-sight (and perhaps line-of-office-supply-tossing) with some parisc kernel guys. [04:19] s/assume/assumed/ [04:19] well... certainly when I have a mirror... [04:20] but the issue here is talking to the folks that did the implementation, and figuring out what it really should be saying when. [04:20] If so, tell them to search lkml for ppc64 and uname over the last 4 or 5 months. Should tell them what to fix. :) [04:20] and it's not something to change right now... [04:20] (I could provide a patch, but have no way to test anything) [04:20] esp since we can't build/install the new (fixed) ubuntu kernel until we have a working klibc... === infinity wonders idly if this is also broken on s390/s390x.. [04:22] jbailey wondered the same thing, and ran away screaming at 31-bit worlds [04:22] or something like taht [04:22] I think arm/arm64 is okay. [04:22] Yeah, I don't think s390 would bother with a "linux31" binary, they'd just pretend to be 32-bit and carry on. :) [04:23] infinity: The fix is almost tribial, but not quite. [04:23] infinity: They use the personality to change how they handle signals internally. [04:23] It's almost certainly not what they meant. [04:23] Oh, FUN. [04:23] I think I have it mapped out as to what needs to change. [04:23] I'm going to sleep on it and do it then. I have klibc for lamont already. [04:24] Just need to hand it to fabio, and then I think that's done for breezy. [04:24] (unless someone comes up with another !@#$ing filesystem they want to use as a root one) === lamont mutters about big kernel changes right before release... [04:24] Well, there's no docs (afaik) saying you can't extend the use of personalities to do other neat hacks/tricks, just what they SHOULD do (fool userspace into believing you're on a 32/64 bit kernel when you're not) [04:24] oh, klibc, not the kernel. [04:24] nm [04:25] infinity: What they've done in this case is assume that a 32 bit binary means you want a 32 bit personality. [04:25] infinity: I think. I'm having trouble tracing some of this code. =) [04:25] That's possibly reasonable. === lamont waits for his 2.4-kernel-possessing knoppix 3.7 ISO to burn, then he's gonna reboot and head home [04:25] It's not how sparc and ppc do it. [04:25] But they're still not munging uname output, which is the issue. [04:26] No, it's not what sparc and ppc do in the slightest, but it seems a valid extension to the use of personalities. [04:26] sparc and ppc set a threadinfo variable with the info. [04:26] Which frightens me to think that they might have PER THREAD shit^Wstuff going on. [04:26] I suppose this is where I start being greatful that Motorola never announced a 68k-64 CPU. [04:27] infinity: Probably. a 4 mhz 64 bit CPU would really suck for data loads. [04:27] hehe [04:27] [04:27] 64-bit 8051 [04:28] I still like the idea of just runnign the whole m68k buildd in a nice emulated environment on a large ia64 machine. [04:28] Hey, if they opened up the specs, any goober with access to fab flipchips could get the 68060 scaled ridiculously high, I'm sure. [04:28] It's just that Motorola never upgraded their fabrication, ever. New ones are still the old ceramic things you can clock peopl ein the head with. [04:28] Why should they, really? If you wanted a small 32 bit chip, the i386 is good enough. [04:29] Last I checked they were still producing those by the assload. [04:29] [04:29] Well, Motorola still produces 68k stuff by the assload too, just not the desktop chips. [04:29] YEah, they still have the embedded medical market. [04:29] The more popular all-in-one stuff with fancy multimedia controllers and such (but, oddly, no MMU) are in high production still. [04:30] well, I'm off [04:30] g'n LaMont [04:30] Later. [04:38] infinity: The other reason in particular that magic isn't a good idea is that it means that all 32 bit binaries would always report parisc from newuname [04:45] Yes, including a 32-bit 'linux64' binary. [04:45] That would definitely seem wrong. === lamont-away grumbles at doko for uploading gcc-3.3 without switching hppa to expect-tcl8.3 [09:46] laon-taway, ohh, yes, something I forgot ... is it a FTBFS? [09:46] lamont-away: ^^^ === doko_ [n=doko@dsl-084-059-088-000.arcor-ip.net] has joined #ubuntu-toolchain [06:31] doko: well, I can babysit it through, but yeah [06:39] lamont-away: no need, m68k died, so I have to reupload === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain