Re: Bug#474724: [DRE-maint] RC bug #474724

View: New views

5 Messages — Rating Filter: Alert me

	Re: Bug#474724: [DRE-maint] RC bug #474724 by Antonio Terceiro :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Gunnar Wolf escreveu isso aí: > Paul van Tilburg dijo [Fri, May 09, 2008 at 11:03:24AM +0200]: > > Hello everyone, > > > > I am at a conference this week and also away for the weekend. > > Could someone have a look at RC bug #474724 if you have the time? > > Umh... Looks quite simple to solve - We would only have to add the > proper definition in posh.h before line 514: > > #if !defined POSH_CPU_STRING > # error POSH cannot determine target CPU > # define POSH_CPU_STRING "Unknown" /* this is here for Doxygen's benefit */ > #endif > > POSH_CPU_STRING is defined in the immediate preceding lines (421 > onwards), in this fashion: > > #if defined ARM \|\| defined __arm__ \|\| defined _ARM > # define POSH_CPU_STRONGARM 1 > # define POSH_CPU_STRING "ARM" > #endif > > So we would only have to get (and I'm sorry, I'm completely lost in > this area) the proper CPU string for s390 and add it here. Blindly > asking Google makes me believe the proper string for the submitter's > environment (64-bit s390) is z900. Besides #define'ing the proper symbols, there are issues like endianess and other stuff that need to be properly defined for such architecture, somewhere in posh.h, and it needs to be tested on an actual s390 machine. I already tried hercules to emulate s390, but it's so slow that makes it impractical (really). There is a s390 mainframe in my university's datacenter, and I'm working together with its administrator to install etch on it. We had no success yet, and these days I was on a trip. I intend to try again on Monday morning. If some DD with instant access to a s390 machine [1] could help, it would be nice. [1] http://db.debian.org/machines.cgi?host=raptor I'm copying the debian-s390 list, in the case some of the porters want and/or can help. -- Antonio Terceiro <terceiro@...> http://people.softwarelivre.org/~terceiro/ GnuPG ID: 0F9CB28F -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Adam Thornton :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On May 10, 2008, at 10:08 AM, Antonio Terceiro wrote: >> >> #if defined ARM \|\| defined __arm__ \|\| defined _ARM >> # define POSH_CPU_STRONGARM 1 >> # define POSH_CPU_STRING "ARM" >> #endif >> >> So we would only have to get (and I'm sorry, I'm completely lost in >> this area) the proper CPU string for s390 and add it here. Blindly >> asking Google makes me believe the proper string for the submitter's >> environment (64-bit s390) is z900. > > Besides #define'ing the proper symbols, there are issues like > endianess > and other stuff that need to be properly defined for such > architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. > > I already tried hercules to emulate s390, but it's so slow that > makes it > impractical (really). There is a s390 mainframe in my university's > datacenter, and I'm working together with its administrator to install > etch on it. We had no success yet, and these days I was on a trip. I > intend to try again on Monday morning. z900 is a particular model of a System z (64-bit) machine. I think the generic architecture definitions are "s390" for 31-bit (which is what Debian is), and "s390x" for 64-bit. Adam -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Bastian Blank :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Sat, May 10, 2008 at 12:08:35PM -0300, Antonio Terceiro wrote: > > So we would only have to get (and I'm sorry, I'm completely lost in > > this area) the proper CPU string for s390 and add it here. Blindly > > asking Google makes me believe the proper string for the submitter's > > environment (64-bit s390) is z900. Linux/s390 uses s390 and s390x. But the correct way on a Debian system is to use dpkg-architecture outside and the architecture specific defines like __s390__ inside the compiler. > Besides #define'ing the proper symbols, there are issues like endianess > and other stuff that need to be properly defined for such architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. Endianess is specified by endian.h. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8 -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Gunnar Wolf :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Antonio Terceiro dijo [Sat, May 10, 2008 at 12:08:35PM -0300]: > Besides #define'ing the proper symbols, there are issues like endianess > and other stuff that need to be properly defined for such architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. Of course, endianness and datatype sizes and such. But that is... well, almost a mechanical step AFAIK :) > I already tried hercules to emulate s390, but it's so slow that makes it > impractical (really). There is a s390 mainframe in my university's > datacenter, and I'm working together with its administrator to install > etch on it. We had no success yet, and these days I was on a trip. I > intend to try again on Monday morning. > > If some DD with instant access to a s390 machine [1] could help, it > would be nice. As it is obvious from this, I'm as close as I can be from being a complete C newbie. But still, getting the right definitions for this architecture should even be enough to push this package to the buildds, if no other s390-like machine can be used. Greetings, -- Gunnar Wolf - gwolf@... - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Bastian Blank :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Sat, May 10, 2008 at 11:51:19PM +0200, Bastian Blank wrote: > Linux/s390 uses s390 and s390x. But the correct way on a Debian system > is to use dpkg-architecture outside and the architecture specific > defines like __s390__ inside the compiler. The following seems to work. \| #if defined __s390__ \| # define POSH_CPU_S390 1 \| # define POSH_CPU_STRING "S/390" \| #endif Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...

	Re: Bug#474724: [DRE-maint] RC bug #474724 by Antonio Terceiro :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Gunnar Wolf escreveu isso aí: > Paul van Tilburg dijo [Fri, May 09, 2008 at 11:03:24AM +0200]: > > Hello everyone, > > > > I am at a conference this week and also away for the weekend. > > Could someone have a look at RC bug #474724 if you have the time? > > Umh... Looks quite simple to solve - We would only have to add the > proper definition in posh.h before line 514: > > #if !defined POSH_CPU_STRING > # error POSH cannot determine target CPU > # define POSH_CPU_STRING "Unknown" /* this is here for Doxygen's benefit */ > #endif > > POSH_CPU_STRING is defined in the immediate preceding lines (421 > onwards), in this fashion: > > #if defined ARM \|\| defined __arm__ \|\| defined _ARM > # define POSH_CPU_STRONGARM 1 > # define POSH_CPU_STRING "ARM" > #endif > > So we would only have to get (and I'm sorry, I'm completely lost in > this area) the proper CPU string for s390 and add it here. Blindly > asking Google makes me believe the proper string for the submitter's > environment (64-bit s390) is z900. Besides #define'ing the proper symbols, there are issues like endianess and other stuff that need to be properly defined for such architecture, somewhere in posh.h, and it needs to be tested on an actual s390 machine. I already tried hercules to emulate s390, but it's so slow that makes it impractical (really). There is a s390 mainframe in my university's datacenter, and I'm working together with its administrator to install etch on it. We had no success yet, and these days I was on a trip. I intend to try again on Monday morning. If some DD with instant access to a s390 machine [1] could help, it would be nice. [1] http://db.debian.org/machines.cgi?host=raptor I'm copying the debian-s390 list, in the case some of the porters want and/or can help. -- Antonio Terceiro <terceiro@...> http://people.softwarelivre.org/~terceiro/ GnuPG ID: 0F9CB28F -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Adam Thornton :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On May 10, 2008, at 10:08 AM, Antonio Terceiro wrote: >> >> #if defined ARM \|\| defined __arm__ \|\| defined _ARM >> # define POSH_CPU_STRONGARM 1 >> # define POSH_CPU_STRING "ARM" >> #endif >> >> So we would only have to get (and I'm sorry, I'm completely lost in >> this area) the proper CPU string for s390 and add it here. Blindly >> asking Google makes me believe the proper string for the submitter's >> environment (64-bit s390) is z900. > > Besides #define'ing the proper symbols, there are issues like > endianess > and other stuff that need to be properly defined for such > architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. > > I already tried hercules to emulate s390, but it's so slow that > makes it > impractical (really). There is a s390 mainframe in my university's > datacenter, and I'm working together with its administrator to install > etch on it. We had no success yet, and these days I was on a trip. I > intend to try again on Monday morning. z900 is a particular model of a System z (64-bit) machine. I think the generic architecture definitions are "s390" for 31-bit (which is what Debian is), and "s390x" for 64-bit. Adam -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Bastian Blank :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Sat, May 10, 2008 at 12:08:35PM -0300, Antonio Terceiro wrote: > > So we would only have to get (and I'm sorry, I'm completely lost in > > this area) the proper CPU string for s390 and add it here. Blindly > > asking Google makes me believe the proper string for the submitter's > > environment (64-bit s390) is z900. Linux/s390 uses s390 and s390x. But the correct way on a Debian system is to use dpkg-architecture outside and the architecture specific defines like __s390__ inside the compiler. > Besides #define'ing the proper symbols, there are issues like endianess > and other stuff that need to be properly defined for such architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. Endianess is specified by endian.h. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8 -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Gunnar Wolf :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Antonio Terceiro dijo [Sat, May 10, 2008 at 12:08:35PM -0300]: > Besides #define'ing the proper symbols, there are issues like endianess > and other stuff that need to be properly defined for such architecture, > somewhere in posh.h, and it needs to be tested on an actual s390 > machine. Of course, endianness and datatype sizes and such. But that is... well, almost a mechanical step AFAIK :) > I already tried hercules to emulate s390, but it's so slow that makes it > impractical (really). There is a s390 mainframe in my university's > datacenter, and I'm working together with its administrator to install > etch on it. We had no success yet, and these days I was on a trip. I > intend to try again on Monday morning. > > If some DD with instant access to a s390 machine [1] could help, it > would be nice. As it is obvious from this, I'm as close as I can be from being a complete C newbie. But still, getting the right definitions for this architecture should even be enough to push this package to the buildds, if no other s390-like machine can be used. Greetings, -- Gunnar Wolf - gwolf@... - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...
	Re: Bug#474724: [DRE-maint] RC bug #474724 by Bastian Blank :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Sat, May 10, 2008 at 11:51:19PM +0200, Bastian Blank wrote: > Linux/s390 uses s390 and s390x. But the correct way on a Debian system > is to use dpkg-architecture outside and the architecture specific > defines like __s390__ inside the compiler. The following seems to work. \| #if defined __s390__ \| # define POSH_CPU_S390 1 \| # define POSH_CPU_STRING "S/390" \| #endif Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-s390-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@...