Re: Account on sparc machine(s) wanted
I have a Ultrasparc here - It boots as a UltraSparc 5/10 - running gentoo. Would that help? On 21 Sep 2005 at 20:13, Jurij Smakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I am a member of Debian kernel team, working (to the extent of my abilities) on sparc-specific bugs. Recently I have moved and thus was forced to get rid of all my sparc hardware which I used for d-i testing and kernel work. The plans to get some new machines are on the way (Blars Blarson has a sparc32 box waiting for me and Andres Salomon is planning to ship an Ultra 5 my way), but it will take at least a few more weeks before I can lay my hands on them. In the meantime I can't even do test kernel builds or any basic testing/porting. If you have a possibility to open an account for me on a sparc box for this purpose, I would really appreciate it. If the box can be rebooted remotely or accessed via the serial console, that would be a huge plus. Thanks and best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDMiGYjjectMmeA8wRAnzAAKC+ekhrmtY/XG1zbHFbkVeXKOcJ+wCguwlU qNdk0ELZfiAZcz+iutuVHKU= =y36W -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lack of 64 bit support in devel tools for stable, current and future.
The lack of a 64 bit compiler able to compile to a 64bit sparc version 9b instruction set is really, really, really, really pissing me and hundreds if not thousands of other people off. The versions of gcc available in the current stable is lacking this MUCH NEEDED SUPPORT and since all you have to do is read the documentation and use the correct host in your configure of gcc I really see no reason why such idiocy needs to continue. The development tools available for linux in any distribution are the lifeblood of the open source community surrounding it. Without the correct tools I as a developer and my fellow porting brethren do not have the ability to continue the effort. The lack of correctly compiled packages to take advantage of the added speed and power of the additional instruction sets Ultrasparc cpus are able to use is severely hindering the development effort in the support of not only the hardware in question, but the development community surrounding it. I understand the need to support the 'sparclite' type of low power (When compared to a ultrasparc cpu) cpu but I really firmly believe the option of having available packages compiled for this support with the default of at least the version 8 instruction set should be available if they are not already due to the sheer power gained in taking advantage of the increased instruction set. SSH is a perfect example of this as anyone with a ultrasparc system running a ssh server using debian stable is familiar with. The very slow exaction times brought on by the current package build system that does not take advantage of the hardware and as such users are forced to wait as long at 3 extra seconds as the libs compiled for the version 7 instruction set have to generate and authenticate its key. While this instruction set is clearly ABLE to do it, it is NOT the best way. The lack of these tools is also hindering porting efforts and keeping the available packages small. My own efforts as a Asterisk (A gpl PBX system) developer and my own private goal of porting it to sparc based systems has only been halfway successful due to this lack. While I have been able to get the application itself working on my sparc based system I remain unable to finish the job by finishing the kernel modules for its supporting hardware. The current development environment is not only incomplete but incompatible without allot of work that in my recent (yesterday) experience breaks the system. All we as a community need is the development tools with new enough versions numbers compiled with the correct support. Even if only as optional alternative packages. Once we have that things will take off. So please don't BREAK debian for sparc64 platforms by leaving us out when the time comes. Create and include official packages for the next release unlike you did the current release. Not including what we developers need only hurts the debian community. - D
