Re: Sparc status ?
On Mon, Apr 28, 2014 at 9:06 PM, Axel Beckert a...@debian.org wrote: Hi, Sébastien Bernard wrote: I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Not only them. All my Sparcs run Squeeze kernels, too, because neither Wheezy (3.2) nor Sid kernels (3.12 was the last one I tried IIRC) can provide uptimes more than a month. Sometimes they freeze just after a few days of uptime. Since I'm back on 2.6.32, I never had issues again. Current uptime 92 days. Example uprecords: From a Sparc installed with Sid in autumn 2013: # Uptime | System Boot up +--- - 192 days, 20:22:44 | Linux 2.6.32-5-sparc64-s Sat Jan 25 21:38:13 2014 224 days, 09:18:08 | Linux 3.10-2-sparc64-smp Sat Sep 7 16:16:29 2013 3 5 days, 23:12:41 | Linux 3.12-trunk-sparc64 Fri Nov 29 04:12:01 2013 4 4 days, 01:35:01 | Linux 3.12-trunk-sparc64 Sat Dec 7 15:32:05 2013 5 2 days, 22:44:57 | Linux 3.12-trunk-sparc64 Mon Jan 20 21:36:35 2014 6 2 days, 14:21:37 | Linux 3.10-3-sparc64-smp Wed Oct 2 04:16:49 2013 7 1 day , 15:14:57 | Linux 2.6.32-5-sparc64-s Tue Jan 19 04:14:07 2038 +--- From a Sparc running Wheezy since July 2013, stripped to those uptimes since the upgrade to Wheezy: 14 0 days, 00:19:43 | Linux 3.2.0-4-sparc64 Mon Jul 15 12:22:26 2013 15 0 days, 00:53:29 | Linux 3.2.0-4-sparc64 Mon Jul 15 13:14:06 2013 16 0 days, 00:07:17 | Linux 3.2.0-4-sparc64 Mon Jul 15 14:10:26 2013 17 209 days, 21:29:54 | Linux 2.6.32-5-sparc64Mon Jul 15 14:18:30 2013 - 1877 days, 07:11:40 | Linux 2.6.32-5-sparc64Mon Feb 10 10:50:23 2014 The latter has not much load, it's just an NTP server. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). It's good to hear that there are least some hardware architectures where recent kernels are more stable than on all my UltraSparcs. I have successfully installed wheezy (debian-7.2.0-sparc-DVD-1.iso) today to SF V215 hardware. Installation went clean. Upgraded to unstable, now running 3.14-1-sparc64-smp . Meanwhile compiling 3.14.4 kernel sources as a test with gcc-4.9. Going to leave this machine running, just to see how stable it will be. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadxrzqxof7aekx+mvlpgtgss4_8fu7ryrjfivxx5-upifp7...@mail.gmail.com
Re: Sparc status ?
Le 26/04/2014 22:59, Julien Cristau a écrit : On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote: No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. Are you refering to the #731806 ? Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Cheers, Julien The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Cheers. Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535e12c3.4070...@nerim.net
Re: Sparc status ?
The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Interesting. I have a SB 2500 (2xUltraSPARC III) and I faced some instability when using 'git clone' on a kernel I compiled, but stock debian was OK. I wrote it off since I changed the default memory allocator and enabled a few experimental features, but maybe there is something more to this. Perhaps we should compare some kernel configurations and see where the source of instability might be. Patrick
Re: Sparc status ?
No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. OK, what are the major issues and the bug # assigned to them? I'd like to keep sparc alive, I have working hardware, and I am very knowledgeable in C/C++ and to a lesser extent SPARC assembly. The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. That sounds bad. Suppose I have a kernel that I believe will resolve the issue. What is the process to test and verify that it's OK? Cheers, Julien
Re: Sparc status ?
Le 28/04/2014 16:12, Patrick Baggett a écrit : The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Interesting. I have a SB 2500 (2xUltraSPARC III) and I faced some instability when using 'git clone' on a kernel I compiled, but stock debian was OK. I wrote it off since I changed the default memory allocator and enabled a few experimental features, but maybe there is something more to this. Perhaps we should compare some kernel configurations and see where the source of instability might be. Patrick My kernel are plain debian kernel, without modification. I had no issue at all with new kernel. I've been running 3.2 for 1-2 year with no issue. S. Bernard
Re: Sparc status ?
Hi, Sébastien Bernard wrote: I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Not only them. All my Sparcs run Squeeze kernels, too, because neither Wheezy (3.2) nor Sid kernels (3.12 was the last one I tried IIRC) can provide uptimes more than a month. Sometimes they freeze just after a few days of uptime. Since I'm back on 2.6.32, I never had issues again. Current uptime 92 days. Example uprecords: From a Sparc installed with Sid in autumn 2013: # Uptime | System Boot up +--- - 192 days, 20:22:44 | Linux 2.6.32-5-sparc64-s Sat Jan 25 21:38:13 2014 224 days, 09:18:08 | Linux 3.10-2-sparc64-smp Sat Sep 7 16:16:29 2013 3 5 days, 23:12:41 | Linux 3.12-trunk-sparc64 Fri Nov 29 04:12:01 2013 4 4 days, 01:35:01 | Linux 3.12-trunk-sparc64 Sat Dec 7 15:32:05 2013 5 2 days, 22:44:57 | Linux 3.12-trunk-sparc64 Mon Jan 20 21:36:35 2014 6 2 days, 14:21:37 | Linux 3.10-3-sparc64-smp Wed Oct 2 04:16:49 2013 7 1 day , 15:14:57 | Linux 2.6.32-5-sparc64-s Tue Jan 19 04:14:07 2038 +--- From a Sparc running Wheezy since July 2013, stripped to those uptimes since the upgrade to Wheezy: 14 0 days, 00:19:43 | Linux 3.2.0-4-sparc64 Mon Jul 15 12:22:26 2013 15 0 days, 00:53:29 | Linux 3.2.0-4-sparc64 Mon Jul 15 13:14:06 2013 16 0 days, 00:07:17 | Linux 3.2.0-4-sparc64 Mon Jul 15 14:10:26 2013 17 209 days, 21:29:54 | Linux 2.6.32-5-sparc64Mon Jul 15 14:18:30 2013 - 1877 days, 07:11:40 | Linux 2.6.32-5-sparc64Mon Feb 10 10:50:23 2014 The latter has not much load, it's just an NTP server. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). It's good to hear that there are least some hardware architectures where recent kernels are more stable than on all my UltraSparcs. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428170618.gi6...@sym.noone.org
Re: Sparc status ?
On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote: Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit : I'd guess skilled hacker time is more needed than hardware. Reading https://release.debian.org/jessie/arch_qualify.html , it seems major blocking issues are: Using gcc-4.6 as default compiler and Have to run oldstable kernels. Related to this: only 1 porter, only partial upstream support. Bye, Joost - who'd _love_ to have a fully supported Debian on sparc So, if I have understood correctly, the main problem is that 32bit compilation is not supported in the current releases of gcc ? No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Cheers, Julien signature.asc Description: Digital signature
Re: Sparc status ?
Le 20/04/2014 18:26, Patrick Baggett a écrit : Also, a lot of the messages about removing v8 support or upstream dropping sparc32 is confusing. SPARCv8, sometimes called sparc32 (more specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, SPARCv9) is used by just /one/ CPU that is modern -- Leon. The remaining CPUs are all 64-bit since 1997. However, a 32-bit /ABI/ (note ABI, NOT ISA) used on a v9 platform seems like a sane idea, and that is the current case of Debian and Solaris. This is because it's absolutely a terrible idea to remove a 32-bit ABI for v9 CPUs. This ABI is called v8+, which incidentally is a terrible name. I don't care if Debian or other upstream packages drops sparc32 aka v8 support, because the current kernel will only boot on SPARCv9 CPUs, so it doesn't make any sense to add a constraint that binaries must run on v8 CPUs. And I mostly don't care if GCC removes the ability to generate sparc32 aka SPARCv8 code. What I /do/ care about it the removal of the ability to build 32-bit binaries on SPARCv9, because 64-bit only binaries is a ridiculous idea. So Jurij, I don't see any reason to believe that upstream support is disappearing. None of the messages are from GCC maintainers directly, and nothing on GCC's website about 4.7 / 4.8 states this to be the case. Patrick Ok, so, if I make a long story short: first showstopper (a.k.a. no/partial upstream support from gcc) for jessie is a red herring, nothing should prevent the switch to the gcc-4.8 toolchain. second old kernel - Well, how to put that... the machine I have is running 3.13, so maybe the obligation to run old kernel does not really stand for all hardware. Then, maybe sparc porter must tell debian release team that the two problem identified really aren't that much problem. Seb
Re: Sparc status ?
On Fri, Apr 18, 2014 at 6:11 PM, Sébastien Bernard sbern...@nerim.netwrote: Doh, beat me to it by a minute. Yeah, you see what I mean. :) It would be platform suicide to drop 32-bit code generation. Like many RISC architectures, switching to 64-bit is only done for apps that need it, because it is not free and will not, in general, make apps faster. Anyone who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a heartbeat, and no doubt gcc-sparc maintainers are aware of this as well. Patrick So this does not really help to understand why the switch to gcc-4.8 didn't happened on the sparc architecture. Because GCC maintainers have been saying for years, that they are unwilling to support the weird use case of Debian sparc port, which has 64-bit kernel but 32-bit userspace. I can find discussions about it going back as far as 2009: https://lists.debian.org/debian-sparc/2009/08/msg00010.html Another possibly relevant bit is that Aurelien Jarno started working on an unofficial sparc64 port a while ago, but the current status of it is unknown to me. See, for example https://wiki.debian.org/Sparc64 Cheers. Sébastien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53515cb3.7030...@nerim.net -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Re: Sparc status ?
Because GCC maintainers have been saying for years, that they are unwilling to support the weird use case of Debian sparc port, which has 64-bit kernel but 32-bit userspace. I can find discussions about it going back as far as 2009: https://lists.debian.org/debian-sparc/2009/08/msg00010.html This is a weak case. I have 64-bit MIPS hardware running debian and it doesn't seem to matter to anyone that the userspace is 32-bit, though the kernel is 64-bit and I can also run 64-bit MIPS binaries on it. GCC is also used on Solaris/SPARC which has a 64-bit kernel and 32-bit userland. I just don't buy the debian sparc is a [uniquely] weird use case. It's not even unique to Debian, and it's not even unique to SPARC. Patrick
Re: Sparc status ?
Because GCC maintainers have been saying for years, that they are unwilling to support the weird use case of Debian sparc port, which has 64-bit kernel but 32-bit userspace. I can find discussions about it going back as far as 2009: Also, a lot of the messages about removing v8 support or upstream dropping sparc32 is confusing. SPARCv8, sometimes called sparc32 (more specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, SPARCv9) is used by just *one* CPU that is modern -- Leon. The remaining CPUs are all 64-bit since 1997. However, a 32-bit *ABI* (note ABI, NOT ISA) used on a v9 platform seems like a sane idea, and that is the current case of Debian and Solaris. This is because it's absolutely a terrible idea to remove a 32-bit ABI for v9 CPUs. This ABI is called v8+, which incidentally is a terrible name. I don't care if Debian or other upstream packages drops sparc32 aka v8 support, because the current kernel will only boot on SPARCv9 CPUs, so it doesn't make any sense to add a constraint that binaries must run on v8 CPUs. And I mostly don't care if GCC removes the ability to generate sparc32 aka SPARCv8 code. What I *do* care about it the removal of the ability to build 32-bit binaries on SPARCv9, because 64-bit only binaries is a ridiculous idea. So Jurij, I don't see any reason to believe that upstream support is disappearing. None of the messages are from GCC maintainers directly, and nothing on GCC's website about 4.7 / 4.8 states this to be the case. Patrick
Re: Sparc status ?
I really don't understand why this 32-bit gone myth is happening. It was poor wording at least. Debian doesn't even support the ancient 32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running in 32-bit code, it's like x32 ABI in x86 land. SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just fine. And just so we can finally kill this rumor dead: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options GCC still supports the 32-bit ABI: With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference from the V8 ABI is that the global and out registers are considered 64 bits wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9 processors. So no, you don't need to rebuild everything as 64-bit binaries, or should I say, rebuild under LP64 model. That wouldn't even make sense and would hurt performance. Please refer anyone who believes this to this message. Patrick On Fri, Apr 18, 2014 at 3:44 AM, Sébastien Bernard sbern...@nerim.netwrote: Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit : I'd guess skilled hacker time is more needed than hardware. Reading https://release.debian.org/jessie/arch_qualify.html , it seems major blocking issues are: Using gcc-4.6 as default compiler and Have to run oldstable kernels. Related to this: only 1 porter, only partial upstream support. Bye, Joost - who'd _love_ to have a fully supported Debian on sparc So, if I have understood correctly, the main problem is that 32bit compilation is not supported in the current releases of gcc ? Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5350e5e0.1090...@nerim.net
Re: Sparc status ?
Le 18/04/2014 14:16, Patrick Baggett a écrit : I really don't understand why this 32-bit gone myth is happening. It was poor wording at least. Debian doesn't even support the ancient 32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running in 32-bit code, it's like x32 ABI in x86 land. Debian sparc userland is v8+. It only is usable on v9 CPU, not v8. I have reinstalled all my old sparc v8 under NetBSD. SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now You have forgotten Leon CPU that are v8e (32 bits), not v8+ or v9. SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just fine. There are some bugs in userland (mainly due to endianess). Regards, JKB -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53511a08.8090...@systella.fr
Re: Sparc status ?
Yeah, I understand why you would believe that. I'm not blaming you, I just want to let everyone know the sentence 32-bit code generation as we use it is no longer supported upstream is incorrect. You can see on the GCC 4.7 [1] and 4.8 [2] changes list that removing any SPARC code generation features is NOT mentioned. In fact, the only SPARC related change was GCC 4.7 dropping Solaris 8, which has been EOL for a long time. There is no need to switch to a 64-bit userland. I can already build both 32-bit and 64-bit apps on my system, right now. [1] http://gcc.gnu.org/gcc-4.7/changes.html [2] http://gcc.gnu.org/gcc-4.8/changes.html On Fri, Apr 18, 2014 at 11:35 AM, Sébastien Bernard sbern...@nerim.netwrote: Le 18/04/2014 14:16, Patrick Baggett a écrit : I really don't understand why this 32-bit gone myth is happening. It was poor wording at least. Debian doesn't even support the ancient 32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running in 32-bit code, it's like x32 ABI in x86 land. SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just fine. And just so we can finally kill this rumor dead: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options GCC still supports the 32-bit ABI: With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference from the V8 ABI is that the global and out registers are considered 64 bits wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9 processors. So no, you don't need to rebuild everything as 64-bit binaries, or should I say, rebuild under LP64 model. That wouldn't even make sense and would hurt performance. Please refer anyone who believes this to this message. Patrick So, if I have understood correctly, the main problem is that 32bit compilation is not supported in the current releases of gcc ? Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5350e5e0.1090...@nerim.net Maybe it was poor understanding by my side. I read the https://release.debian.org/jessie/arch_qualify.html and at the bottom line, there is this mention of this : sparc Upstream Support According to the gcc maintainer 32bit code generation as we use it is no longer supported upstream and we should aim for a switch to 64bit userland anytime soon. This is quite clear, and maybe plain wrong according to you. This seems to prevent switch from gcc 4.6 to gcc 4.8. Seb
Re: Sparc status ?
I don't understand, there is no warning of abi or architecture deprecation in the release notes of gcc, neither 4.7 nor 4.8. Maybe they have information I don't, but I doubt it. I'll dig in the gcc mailing list to see if I can find something related. Sébastien Doh, beat me to it by a minute. Yeah, you see what I mean. :) It would be platform suicide to drop 32-bit code generation. Like many RISC architectures, switching to 64-bit is only done for apps that need it, because it is not free and will not, in general, make apps faster. Anyone who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a heartbeat, and no doubt gcc-sparc maintainers are aware of this as well. Patrick
Re: Sparc status ?
Doh, beat me to it by a minute. Yeah, you see what I mean. :) It would be platform suicide to drop 32-bit code generation. Like many RISC architectures, switching to 64-bit is only done for apps that need it, because it is not free and will not, in general, make apps faster. Anyone who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a heartbeat, and no doubt gcc-sparc maintainers are aware of this as well. Patrick So this does not really help to understand why the switch to gcc-4.8 didn't happened on the sparc architecture. Cheers. Sébastien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53515cb3.7030...@nerim.net
Sparc status ?
Reading the 2 or 3 warning from from debian-devel-announce, I'm afraid that the sparc architecture is going legacy the same way that it did for the hppa. What could it be done to keep this architecture as a first class citizen ? If I understood correctly, the debian port of debian is on watch and should improve or it'll be removed from testing, which would be unfortunate. What could be done to improve the situation of this port ? Is the sparc architecture no more relevant to modern computing ? I'm willing to dedicate a share of my time or hardware if there's something to be done. Cheers S. Bernard -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53506b97.7000...@nerim.net
Re: Sparc status ?
On Fri, Apr 18, 2014 at 02:02:31AM +0200, Sébastien Bernard wrote: Reading the 2 or 3 warning from from debian-devel-announce, I'm afraid that the sparc architecture is going legacy the same way that it did for the hppa. What could it be done to keep this architecture as a first class citizen ? If I understood correctly, the debian port of debian is on watch and should improve or it'll be removed from testing, which would be unfortunate. What could be done to improve the situation of this port ? Is the sparc architecture no more relevant to modern computing ? I'm willing to dedicate a share of my time or hardware if there's something to be done. I'd guess skilled hacker time is more needed than hardware. Reading https://release.debian.org/jessie/arch_qualify.html , it seems major blocking issues are: Using gcc-4.6 as default compiler and Have to run oldstable kernels. Related to this: only 1 porter, only partial upstream support. Bye, Joost - who'd _love_ to have a fully supported Debian on sparc -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140418045627.gv2...@beskar.mdcc.cx
Sparc status and Re: Sparc progress
Hi, sorry for my absence during the past week. My girlfriend and I got a small baby boy on Wednesday which mixed up my timetable. I guess that's a usual feature of children that they mix up your life ;-) First of all a big thankyou to Steve Dunham and Eric Delaunay for making the Sparc release happen. I really appreciate your hard work (boot floppies, sparc kernels, various package uploads, cd image creation, ...) The packages I wanted to get done for slink should be in. The last issue remaining is to sort out the patches which are needed for several source packages to compile on sparc. I'll file appropriate bug reports and will provide a tarball (possibly a .deb) of the source patches. This should take care of the public availablity of the complete sources for the slink Sparc release. Issues remaining like the outdated lrzsz will be fixed in 2.1r2. I guess we've done it ;-) Debian GNU/Linux 2.1 (kernel 2.2.1) running on Sparc with a prerelease of glibc2.1 On Sun, Mar 07, 1999 at 01:54:15PM +, Steve McIntyre wrote: I'm still seeing the following package errors on a CD build run. Do we pull them? virgo:~/debian/slink_cd/slink_cd-1.11$ ./pkg-order --check-recommends --nocheck-conflicts --nooutput-order /debian/local/slinkcd-sparc/Packages-all == Failed: Package: dia libglib1.1(= 1.1.3-2.1) Compiled with a wrong dependency on glib1.1. Will be fixed in r2. Should work if you install it with --force-depends Package: ivtools-dev ivtools(= 0.6.7-7) Needs a new source upload. ivtools-dev is binary-all. ivtools is 0.6.7-7.1 on sparc (glibc2.1 patch). Should work if you install it with --force-depends. I'll ask the package maintainer if he'll upload a fixed version for r2. Package: libcompface1 libc5(= 5.4.0.0) libc5 compat package which has an incorrect hardcoded dependency. will be fixed in r2 Package: libdl1-altdev libc5-altdev(= 5.4.0-0) ditto. Package: libwcsmbs libc6( 2.0.8) Pull it. wcsmbs support is included in glibc2.1 == == Unknown: Package: dialdcost diald diald isn't available on Debian slink sparc. Package: econfigedit libgtk-imlib-perl(= 0.3-3) libgtk-perl isn't available on Debian slink sparc. Package: felt-doc felt felt isn't available on Debian slink sparc. Package: gstep-base-examples gstep-base-dev(= 0.5.0.981229-1) gstep-base isn't available on Debian slink sparc. Package: iceconf libgtk-perl see above Package: libdb1-dev libc5-dev Package: palm-doctoolkit palmpython(= 0.5.2) palmpython isn't available on Debian slink sparc. Package: pilot-manager pilot-link-perl pilot-link-perl isn't available on Debian slink sparc. Package: python-history python-numeric python-pdb python-numeric isn't available on Debian slink sparc. Package: wml eperl(= 2.2.14-0.1) eperl isn't available on Debian slink sparc. Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau)
Re: Sparc status and Re: Sparc progress
On Mon, 8 Mar 1999, Christian Meder wrote: sorry for my absence during the past week. My girlfriend and I got a small baby boy on Wednesday which mixed up my timetable. I guess that's a usual feature of children that they mix up your life ;-) :-) Congratulations on becoming a dad. -- Steve McIntyre, Allstor Software [EMAIL PROTECTED] a href=http://www.rpg-soc.ucam.org/curs/CURS home page/a Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I...
current binary-sparc status
I just have to say I am extremely impressed at the speed that Chris is pumping out the sparc binary packages. Question, if the sparc release is now aiming at making slink shouldn't there be a split for slink/potato? This might avoid any confusion on what distribution the binaries are based on. -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: Sparc status/my two cents
Derrick J Brashear writes: I've been meaning to have a look at it, I just haven't had the time yet. The repeat delay does seem rather short (I counted about 0.2 s), and as far as I can tell it's kernel related (though, as I said, I haven't really had the time to look at it yet). I can tell you: -The code you care about is in drivers/sbus/char/sunkbd.c -The interesting values: static int kbd_delay_ticks = HZ / 5; static int kbd_rate_ticks = HZ / 20; -The interesting code bits are in sunkbd_inchar and and keyboard_timer in aforementioned file (and in the ioctl handler, which appears to correctly handle ioctls to change keyboard rates If someone with this problem has some time, try instrumenting the code with printks and see what you can find out. Thanks for the info. I certainly would like to recompile the kernel and change those settings. But I don't have a sparc to spare. The one which has linux installed have to serve a an X terminal so I can compile things in the background. But with the keyboard broken, I have to switch it back to solaris. --- PHAM Dinh Tuan | e-mail: [EMAIL PROTECTED] Laboratoire de Modelisation et Calcul | Tel: +33 4 76 51 44 23 BP 53, 38041 Grenoble cedex (France) | Fax: +33 4 76 63 12 63 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package versions (Was: Sparc status/my two cents)
One question presetns itself. Versions. Do we add a non-maintainer version bump? What about if absolutely no change was made? (libungif, for example, I recompiled as a no-brainer). As I have understood it, when doing a no-brainer, thus making a package that didn't needed any editing from the source maintainers version, one should make a binary-only upload (ie. no change in debian-version). When having to do some slight change in the source to have it compile, one should do a non-maintainer upload (adding an index to the version number) and send corrections to the source maintainer asking it to be included in future releases. -- Jonas - http://www.mds.mdh.se/~kmm96jog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Jules == Jules Bean [EMAIL PROTECTED] writes: [snip] Jules in itself, but key to compiling some other things) and this Jules ldd bug seems annoying, possibly serious. I saw your post about ldd but have never seen it mis-behave so I didn't comment. BTW, I've also never had any problems with tftpboot.img. I have had problems with the boot-floppies but those all derived from loopback devices not working on NFS mounted volumes. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On 21 Jul 1998, Stephen Zander wrote: Jules == Jules Bean [EMAIL PROTECTED] writes: [snip] Jules in itself, but key to compiling some other things) and this Jules ldd bug seems annoying, possibly serious. I saw your post about ldd but have never seen it mis-behave so I didn't comment. Does 'ldd /usr/lib/libm.so' (to pick one example) work for you? It doesn't for me... BTW, I've also never had any problems with tftpboot.img. I have had problems with the boot-floppies but those all derived from loopback devices not working on NFS mounted volumes. I suspect these only affect *some* models in the SPARC range. SS2 and SS classic seem to have trouble with boot-floppies (IIRC). At least one other user has reported trouble with tftpboot.img. Possibly the problems are in 4c-class machines? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On Wed, 22 Jul 1998, Jules Bean wrote: On 21 Jul 1998, Stephen Zander wrote: Jules == Jules Bean [EMAIL PROTECTED] writes: [snip] Jules in itself, but key to compiling some other things) and this Jules ldd bug seems annoying, possibly serious. I saw your post about ldd but have never seen it mis-behave so I didn't comment. Does 'ldd /usr/lib/libm.so' (to pick one example) work for you? It doesn't for me... To follow up my own message, it seems that we aren't using the glibc version of ldd. I don't know why. I wish I knew who'd done the sparc port so far.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Jules == Jules Bean [EMAIL PROTECTED] writes: Jules Does 'ldd /usr/lib/libm.so' (to pick one example) work for Jules you? It doesn't for me... Yep, sure does. libc6: 2.0.93-980414-1 ldso: 1.9.9-1 which are the latest that I'm aware of. Jules I suspect these only affect *some* models in the SPARC Jules range. SS2 and SS classic seem to have trouble with Jules boot-floppies (IIRC). At least one other user has reported Jules trouble with tftpboot.img. Possibly the problems are in Jules 4c-class machines? Could be, I only lhave sun4m sun4u machines here. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On 21 Jul 1998, Stephen Zander wrote: Jules To satisfy my curiousity, would you execute the following Jules on your machine: Jules md5sum /usr/bin/ldd /lib/libc-2.0.93.so 3519891fb43b6a1d5ff81c9e69034359 /usr/bin/ldd 547e0385a5a3b8c604aa9a3b6d17323e /lib/libc-2.0.93.so These check out. It must be a 4c problem. Well you will live in GMT. So much more daylight in Northern California. :) *grin* Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Jules == Jules Bean [EMAIL PROTECTED] writes: Jules Well, actually, the intel versions of libc6 is 2.0.7pre. Jules (while we're on a pre of 2.1) But anyway, it does rather Jules sound like my problems are specific to my machine (which I Jules doubt) or to the SS2 or 4c architectures. I'm aware of the difference between the architectures re glibc. I meant that there isn't a more recent *sparc* libc6 that I've not installed. Jules To satisfy my curiousity, would you execute the following Jules on your machine: Jules md5sum /usr/bin/ldd /lib/libc-2.0.93.so 3519891fb43b6a1d5ff81c9e69034359 /usr/bin/ldd 547e0385a5a3b8c604aa9a3b6d17323e /lib/libc-2.0.93.so Jules ..but I'm clutching at straws. Jules *yawn* Well you will live in GMT. So much more daylight in Northern California. :) -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sparc status/my two cents
I've been reading this list for a while now, so maybe I can answer a few questions about Debian/sparc's status. I may be wrong about the status of a few things, but if I am the main developers will probably hurry to correct me, so here goes. Debian sparc has some degree of problems with the kernel, libc, basic utils, and compilers. Most of these problems are fairly minor, but it helps to know that they're there. I don't know much about bootdisks or the tftp image (other than what's already been mentioned), but the main developers, Jonnie Ingram, Anders Hammerquist, Miguel, etc., would probably know more. If you search back in the mailing list logs a month or so you should find a lot of talk about uploading new bootdisks. The kernel works in most cases. I've had some problems in low-memory situations on my SS4 (sun4m) and a few people have reported serious problems with the kernel on ftp.debian.org and a Sparc20. As of the 2.0.34 snapshot on vger.rutgers.edu (there's a 2.0.35 out now) the FPU emulation has been fixed up, so those few machines that are short a couple FPU ops should work. Unfortunately, this doesn't magically fix everything; programs like emacs have been known to have some issues with FPUs, even with FPU emulation. Libc is much better now, but has a few lingering problems. First of all, Debian's libc is actually a modification of glibc-2.1 and is therefore incompatible with RedHat 5.1 for sparc (which uses glibc 2.0, I think). But it does seem pretty stable nonetheless. Compiling things against it is another problem; last I checked (which admittedly was a while ago) a few header files were not included. If you are trying to compile something with network (socket) code in it and get errors involving #includes for linux/rose.h and netatalk/at.h, these files should be in the libc-dev package on ftp.debian.org. A few weeks ago one of the main programmers was talking about uploading a version with the appropriate headers, but I don't know if this was done. linux/rose.h can be found in an unstable kernel source tree (linux/include/linux/rose.h) and netatalk/at.h can be found in the netatalk-dev package (you'll probably need to get it from the x86 package). If you don't want to go to all the trouble you should be able to just comment out the offending lines in sockunion.h to make things compile. I'd suggest getting the headers before building anything that you intend to upload, though, just to be safe. The basic utils (things like mount, psutils, util-linux, etc.) work well, in most cases, but could use some rebuilding since none of them are at the latest version. In particular, someone should look into rebuilding mount. That would fix several dependency problems. Also, something should (I think) be done about fdisk and util-linux. I wasn't able to find source for the fdisk package on ftp.debian.org; I'm not sure where the debian source is. The upstream source for util-linux normally compiles fdisk but this fdisk will not work on a Sun (it doesn't know about Sun partition tables). If someone wants to patch the latest version of util-linux to make a newer fdisk, that would be swell. :-) The current sparc fdisk bus errors if you try to make a new DOS partition table and should probably be built by the main source anyway. If you're looking for fdisk patches to make it work on a Sun, look at UltraPenguin's util-linux SRPM. The sourcepackage for RH 5.1 will not compile. Like most things, the compilers (in general) work. Gcc works fine for me (and most people). G++ has a few bugs, particularly with exceptions (which is one reason why the menu package is hard to build), but works for simple things. Several large packages have been built and are known to work. TeX is available and X has been built (just not uploaded yet). However, there are still lots of packages to build. If you're a developer and can get your favorite missing package to compile, test it and upload it. If you hit a big problem, post something about it here; maybe someone can help you with it. If enough developers start uploading packages we just might be able to get a sparc distribution rivaling RedHat's, which I think would be pretty darned cool. -- Mike No .sig for you Shuey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sparc status/my two cents
Michael Shuey writes: I've been reading this list for a while now, so maybe I can answer a few questions about Debian/sparc's status. I may be wrong about the status of a few things, but if I am the main developers will probably hurry to correct me, so here goes. I would like to add the problem of keyboard repeat. No one seems to care but it is very important to me. I have to enter my password many times just to login because I can't make my keyborad not repeating my password. May be I have a special type of typing with my finger staying on the key longer than ordinary folk. Anyway, the kernel (or whatever) seems unable to control the keyboard repeat. kbdrate dosn't works: it reports a new delay and rate, but they aren't changed. I have set the delay to a maximum value of 1000 ms, but still have apparently the same repeat delay (it is inconceivable that my finger stay on the key more than 1 sec). Using X with option -r -ar1 -ar2 (which supposely would change the delay and repeat rate) dosn't seem to change anything. I have launched xset r off to turn off the keyboard repeating but it still repeats. Obviously the Xserver is unable to control this behaviour. (For curiosity, I have tried this command on every unix stations and linux PC which I have acces: it works as advertized). By the way, I have tried the redhat sparc distribution and still get the same problem. I suspect I should tell them but I don't know how. I am not their client. I would prefer debian (unless of course, the redhat people have a solution to this problem). --- PHAM Dinh Tuan | e-mail: [EMAIL PROTECTED] Laboratoire de Modelisation et Calcul | Tel: +33 4 76 51 44 23 BP 53, 38041 Grenoble cedex (France) | Fax: +33 4 76 63 12 63 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On Tue, 21 Jul 1998, Joel Klecker wrote: At 15:25 -0700 1998-07-21, Jules Bean wrote: Well, not *all* that much. See my original message. Things that spring to mind are - menu, lots of the graphics stuff (we have GIMP though, yay!), libg++272 (not valuable in itself, but key to compiling some other things) I'm pretty sure every libg++ dependency has been fixed. A strict dependence on libg++272 should be considered a bug (at the very least libg++2.8 should work). I tried to compile menu the other day, and it hit a lot of problems which I tentatively diagnosed as being incompatibilities between the 'String.h' provided by libstdc++2.8-dev and libg++272-dev. Maybe you'd have a quick look and see if I'm right. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On Tue, 21 Jul 1998, Joel Klecker wrote:
At 17:06 -0700 1998-07-21, Jules Bean wrote:
To follow up my own message, it seems that we aren't using the glibc
version of ldd. I don't know why.
sparc has libc5, glibc ldd can't deal with libc5 binaries, ldso ldd handles
libc5 and libc6 binaries, which is why it is used. This is also true of
every other Debian port that has libc5.
Now I'm confused.
I don't see libc5 here:
bash-2.01$ ls -l {,/usr}/lib/libc*
-rwxr-xr-x 1 root root 1011264 Apr 30 08:14 /lib/libc-2.0.93.so
lrwxrwxrwx 1 root root 14 Jul 19 14:20 /lib/libc.so.6 -
libc-2.0.93.so
lrwxrwxrwx 1 root root 17 Jul 19 14:19
/lib/libcom_err.so.2 - libcom_err.so.2.0
-rw-r--r-- 1 root root 5692 May 3 17:35
/lib/libcom_err.so.2.0
-rwxr-xr-x 1 root root26428 Apr 30 08:14
/lib/libcrypt-2.0.93.so
lrwxrwxrwx 1 root root 18 Jul 19 14:20 /lib/libcrypt.so.1
- libcrypt-2.0.93.so
-rw-r--r-- 1 root root 2284486 Apr 30 08:19 /usr/lib/libc.a
-rw-r--r-- 1 root root 178 Apr 29 11:16 /usr/lib/libc.so
-rw-r--r-- 1 root root 6690 Apr 30 08:19
/usr/lib/libc_nonshared.a
-rw-r--r-- 1 root root26104 Apr 30 08:19 /usr/lib/libcrypt.a
lrwxrwxrwx 1 root root 23 Jul 19 14:37
/usr/lib/libcrypt.so - ../../lib/libcrypt.so.1
lrwxrwxrwx 1 root root 12 Jul 19 14:38
/usr/lib/libcurses.a - libncurses.a
lrwxrwxrwx 1 root root 22 Jul 19 14:39
/usr/lib/libcurses.so - /lib/libncurses.so.3.4
Jules
/+---+-\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd|
| Jules aka | [EMAIL PROTECTED] | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* |
++---+-+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\--/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc status/my two cents
On Wed, 22 Jul 1998, Jonas Oberg wrote: latest version. In particular, someone should look into rebuilding mount. That would fix several dependency problems. Actually, I did this just a few hours ago :-) I've got a mount-2.7l, debian revision 5 working just fine here. If someone could tell me how I should get it up on the ftp, I'd be happy to place it there :-) In particular I'm interested toknow which files should be placed where and if I should do anything to indicate it beeing a NMU. If you're not a developer, you can't. If you're interested in helping, then perhaps consider becoming a debian developer (see the developer's corner on the website). I am a developer, and I will install my development machine today (giving me access to my PGP key) and I will do some uploads later. Including mount, unless someone beats me to it. So, any requests for particular packages which need compiling, feel free to email me, or, better, post them here. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Wow, just found it in my mirror - guess I should look there more often. The FPE problem still exists though Yes, but presumably this is your TurboSparc, and you're using the pathetic attempt at TurboSparc support I did. The FPE problem is a) only interesting if people (including you) with non-TurboSparcs are having it and b) in that case, you may wish to define DEBUG_MATHEMU (at least I think that's it) in arch/sparc/math-emu/Makefile and build the module, because presumably something isn't being emulated. At least, that's my guess. Peter Maydell did all the work on the math emu stuff, so I'm hardly authoritative for it. -D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc status/my two cents
I've been meaning to have a look at it, I just haven't had the time yet. The repeat delay does seem rather short (I counted about 0.2 s), and as far as I can tell it's kernel related (though, as I said, I haven't really had the time to look at it yet). I don't have any problem with any of my sparcs, so I can't do useful testing. I can tell you: -The code you care about is in drivers/sbus/char/sunkbd.c -The interesting values: static int kbd_delay_ticks = HZ / 5; static int kbd_rate_ticks = HZ / 20; -The interesting code bits are in sunkbd_inchar and and keyboard_timer in aforementioned file (and in the ioctl handler, which appears to correctly handle ioctls to change keyboard rates If someone with this problem has some time, try instrumenting the code with printks and see what you can find out. -D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On Wed, 22 Jul 1998, Jules Bean wrote: I tried to compile menu the other day, and it hit a lot of problems which I tentatively diagnosed as being incompatibilities between the 'String.h' provided by libstdc++2.8-dev and libg++272-dev. Maybe you'd have a quick look and see if I'm right. The String problems can be fixed relatively easily by casting char*'s to class Stings's. I got to problems at link time dealing with the STL vector template. Actually, I get the same problems on my hamm x86 system, so I'm not sure how that binary got compiled either. The errors that I get are some of the oddest that I've seen, but here they are: gcc -o update-menus -g -fhandle-exceptions -Wall update-menus.o adstring.o -lstdc++ #-lg++ update-menus.o: In function `vectorint, __default_alloc_templatetrue, 0 ::~vector(void)': /usr/include/g++/stl_vector.h(.gnu.linkonce.t.construct__H2Zt4pair2ZC6StringZ6StringZt4pair2ZC6StringZ6String_PX01RCX11_v+0x14): undefined reference to `operator new(unsigned int, void *)' /usr/include/g++/stl_vector.h(.gnu.linkonce.t.construct__H2Zt4pair2ZC6StringZP11trans_classZt4pair2ZC6StringZP11trans_class_PX01RCX11_v+0x14): undefined reference to `operator new(unsigned int, void *)' /usr/include/g++/stl_vector.h(.gnu.linkonce.t.construct__H2Zt4pair2ZC6StringZt8multimap4Z6StringZP11trans_classZt4less1Z6StringZt24__default_alloc_template2b1i0Zt4pair2ZC6StringZt8multimap4Z6StringZP11trans_classZt4less1Z6StringZt24__default_alloc_templat e2b1i0_PX01RCX11_v+0x14): undefined reference to `operator new(unsigned int, void *)' /usr/include/g++/stl_vector.h(.gnu.linkonce.t.construct__H2Z6StringZ6String_PX01RCX11_v+0x14): undefined reference to `operator new(unsigned int, void *)' /usr/include/g++/stl_vector.h(.gnu.linkonce.t.construct__H2ZiZi_PX01RCX11_v+0x14): undefined reference to `operator new(unsigned int, void *)' update-menus.o(.gnu.linkonce.t.construct__H2ZP7istreamZP7istream_PX01RCX11_v+0x14):/usr/include/g++/stl_vector.h: more undefined references to `operator new(unsigned int, void *)' follow make[1]: *** [update-menus] Error 1 Dave Broudy [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
menu_1.5-12 (was: Re: sparc status? A cry for information, and an , offer to help)
On Wed, 22 Jul 1998, Anders Hammarquist wrote: That's an error I've seen more places. Try linking with g++ instead of gcc and see if the errors go away. There are all sorts of tidbits that Thanks, that did it. I'll put the menu_1.5-12_sparc.deb file on ftp://home.broudy.net/pub/debian for now. I got a fair number of warnings, so I'll probably look at them and the do a patch and become a developer and mess with PGP and sign it and upload it (all in one breath). It seems to work on my sparc2, YMMV. I haven't tested it hardly at all, and I have to catch a bus. Dave Broudy [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Stephen == Stephen Zander [EMAIL PROTECTED] writes: Stephen Actually, my Sparc5/85 (non-Turbo) also had this problem. Stephen I'm going to try loading the math-emu module I built as Stephen part of the .35 kernel and see if it's fixed. Following up on myself: loading math-emu.o doesn't help. MOre digging soon. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc status/my two cents
At 02:26 -0700 1998-07-22, Jonas Oberg wrote: I am a debian developer. It's just that I'm not sure what to do about these sparc packages, I mean, nothing is changed from the maintaners package so it's an NMU, whilst at the same time it itsn't :-) When I compiled the package for sparc, I got these files; mount_2.7l-5.diff.gz mount_2.7l-5.dsc mount_2.7l-5.dsc.asc mount_2.7l-5_sparc.deb mount_2.7l.orig.tar.gz Is there a need for something more? Yes, you're missing the .changes file. The normal procedure for a arch-specific upload it this: 1. cd package-version 2. dpkg-buildpackage -B -mYour Name [EMAIL PROTECTED] 4. cd .. 4. dupload --to master ../package_version_arch.changes The -B tells dpkg-buildpackage not to build source, and not to build architecture independent packages. -- Joel Espy KleckerDebian GNU/Linux Developermailto:[EMAIL PROTECTED] http://www.espy.org/ ftp://ftp.espy.org/pub/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sparc status? A cry for information, and an offer to help
Hi all. There seem to be quite a few problems with the sparc port, and I'm more than happy to help - but this list seems to be almost dead. No one with an 'air of authority' is around here... I see the following problems with my SS2: 1) The boot disks don't work. Not an issue for me, but important to some people. 2) tftpboot.img has to be null-padded to work. 3) 'ldd' doesn't work - and possibly other components of ld-linux.so. Random segfaults are probably related to this. This makes packaged compilation tricky, since dpkg-shlibs won't work. 4) There are problems with the virtual console/X code. X sometimes 'steals' a vc for no apparent reason. Sometimes keymaps get messed up too. 5) We have no libg++272 - which means that we can't compile some packages, notable menu. 6) zsh segfaults (!! - maybe this is problem 3 reincarnated) So, I think there are some things we could do with here. I would like to see a debian-sparc web page, and a debian-sparc FAQ. I will happily put these together. I would like to know where I'm suppose to report architecture bugs like 1) and 2). boot-floppies? But presumably the boot-floppies maintainer is an i386 person... I would like to know who put together our current libc6 support and ldso support. Presumably 3) above belongs to one of these, and it may even be upstream, for all I know... But it's very quiet in here... Cheers, Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
I've had no problems with the boot disks on a Sparc 5. Just figured i'd let everyone know. ;) What I would like, and can't find, is a graphical Xclient. I tried just tossing in Redhats CG6 client, but it didn't seem to work too well, and I don't have the time right now to play with it. Any ideas? -- Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
You didn't Cc: your reply back to the list. In general, you should, since my answers will be valuable to others. I am taking the liberty of Cc:ing this all back to the list now. On Tue, 21 Jul 1998, Michael Mattice wrote: Jules Bean writes: I see the following problems with my SS2: 1) The boot disks don't work. Not an issue for me, but important to some people. Really?? They worked wonderfully for my SS5 after not getting ARP/RARP to work with my i386 linux box. They work fine on some machines, but the fail on others. Sufficiently reproducibly that I suspect a genuine problem, not just bad floppy drives. 3) 'ldd' doesn't work - and possibly other components of ld-linux.so. Random segfaults are probably related to this. This makes packaged compilation tricky, since dpkg-shlibs won't work. I've had some problems with compiling things for sparc repackaging as well. I haven't even been able to get to that point though. To many include deps. 4) There are problems with the virtual console/X code. X sometimes 'steals' a vc for no apparent reason. Sometimes keymaps get messed up too. Where did you find X for the Sparc? I can't find the server anywhere. If there is more setup involved to getting it limping than on i386, we probably need a HOWTO. Getting it to work is *far* easier than on the i386. As to finding it - check the mailing list archives, at www.debian.org (this list). There are some messages about a fortnight ago about it. I forget the precise URL, it is on netg.se somewhere. So, I think there are some things we could do with here. I would like to see a debian-sparc web page, and a debian-sparc FAQ. I will happily put these together. Extremely agreed. www.debian.org mentions the sparc port, but the packages pages totally neglect everything but the i386 version. If you'd like some help, I'm lacking some overall direction as to where to begin. I'd like to get ncpfs running but overall, the lack of packages is overwhelming. I'm glad I have a second. I now would like some response from the people who got the port as far as it is, so I know the current status of things... Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
On Tue, 21 Jul 1998, Chris Trainor wrote: I've had no problems with the boot disks on a Sparc 5. Just figured i'd let everyone know. ;) What I would like, and can't find, is a graphical Xclient. I tried just tossing in Redhats CG6 client, but it didn't seem to work too well, and I don't have the time right now to play with it. Any ideas? You mean Xserver, right? Go to www.debian.org, browse the archives of this mailing list, and look for a message about X about a fortnight ago. Someone has compiled up some Xserver that seem to work very well, although they have the problems I mentioned in the first message. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
OK, I found where to get the Xserver. I figured i'd just repost it here again. ;) ftp.netg.se:/pub/Linux/sparc/X Has the deb packages for XSUN (CG3/6,etc) XSUN24 (zx, other 24bpp cards) and Mono. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Jules == Jules Bean [EMAIL PROTECTED] writes: Jules I'm glad I have a second. I now would like some response Jules from the people who got the port as far as it is, so I know Jules the current status of things... Before you can get terribly far at all, you need a perl package (most of the deb* stuff relies on it). I've buit perl a couple of time (as have a number of others) but there's a problem with the kernel support for FP. I'm currently (as tuits come to hand) trying to find a kernel which resolves this issue. My next attempt will be Derrick Brashear's 2.0.35 source snapshot which may or may not get touched today (R/L all that). After that, UltraSparc here I come... -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Jules == Jules Bean [EMAIL PROTECTED] writes: Jules Huh? Jules Perl works! Wow, just found it in my mirror - guess I should look there more often. The FPE problem still exists though Jules I have 201 packages on my debian-sparc machine... including Jules perl, X, ssh, netstd, and so on. So what do you think is missing? -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Thank god... This list has been dead for a while. With the way the redhat sparc 5.0 release went i was afraid debian-sparc was going to go the way of the dodo. Let's get going... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Thank god... This list has been dead for a while. With the way the redhat sparc 5.0 release went i was afraid debian-sparc was going to go the way of the dodo. Let's get going... I hereby declare that I shall do all that is in my power to further Debian-sparc. Of course, since I'm stuck on intel, I guess that's not much. ; But whatever I can do. :P -Kysh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc status? A cry for information, and an offer to help
Everything is working mostly OK for me. I only have a few SunIPC's to play with, and am waiting on a couple of large SCSI Hdd's for them before I can go too mad. The boot disks work fine on my IPC's too by the way. Richard Parkinson Ph 64 7 8399090 Systems Consultant Fax 64 7 8389333 Encomium Retail Systems E-Mail [EMAIL PROTECTED] 1139 Victoria St. Hamilton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
