Re: help for fixing a bug package does not compile
Fixed Am So, den 03.10.2004 schrieb [EMAIL PROTECTED] um 15:21: On Sun, Oct 03, 2004 at 12:05:40PM +0200, Daniel J. Priem wrote: Hello Listmembers, i try to package capisuite on i386 everything went fine. What wrong with the packages from http://www.capisuite.de/download.php3 ? Not official, not lintian clean, No logrotate, no manpage and much more no But achim and i go to package them for the official archive so we need to have them in a good state. touch ./)].in)].in /bin/sh: -c: line 1: syntax error near unexpected token `)' /bin/sh: -c: line 1: `touch ./)].in)].in' make[1]: *** [)].in] Error 2 make[1]: Leaving directory `/home/admin/capitest/capisuite/trunk/capisuite-0.4.4' make: *** [build-stamp] Error 2 i can not understand why it compiles fine under i386 and not under sparc. fixed. forgot some buildependens (pbuilder give me the help) The filename )].in)].in is really strange. Maybe it's not about architecture but about environment? If you find out where that strange file name comes from... HS signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
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
Re: Lack of 64 bit support in devel tools for stable, current and future.
On Mon, 04 Oct 2004 11:29:01 -0700 [EMAIL PROTECTED] wrote: 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 testing distribution, and what will become the next stable distribution, has everything you are complaining is missing. The technology simply wasn't ready back when sarge was released. It isn't simply a matter of reading the documentation and rebuilding gcc, you also have to provide all of the libraries side-by-side with their 32-bit counterparts and therefore there are packaging, filesystem layout, and build environment issues as well. You want to make the problem seem much simpler than it really is.
Re: Lack of 64 bit support in devel tools for stable, current and future.
On Mon, Oct 04, 2004 at 11:29:01AM -0700, [EMAIL PROTECTED] wrote: 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. You're the first person I've heard complain about it. Just upgrade to testing. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
