Re: Bug#474724: [DRE-maint] RC bug #474724
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 [EMAIL PROTECTED] http://people.softwarelivre.org/~terceiro/ GnuPG ID: 0F9CB28F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#474724: [DRE-maint] RC bug #474724
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#474724: [DRE-maint] RC bug #474724
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Wed, May 07, 2008 at 11:29:49AM +0200, Bastian Blank wrote: Package: libc6 Version: 2.7-10 Severity: important On Wed, May 07, 2008 at 09:34:12AM +0200, Matthias Klose wrote: the build failure on s390 is unexpected; is it possible to extract a test case? | java: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. So another package failed about that (after mono and libto$bla). It looks like a race condition somewhere in the libpthread. Looking quickly at the code the problem is that LLL_MUTEX_LOCK (mutex) fails to acquire the mutex. It can be a bug in atomic.h or a bug in the futexes implementation of the kernel. It would be nice to have an strace of the problem to see the futex syscall before this assertion. Also a small testcase of the problem would be really helpful to debug it. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#474724: [DRE-maint] RC bug #474724
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 - [EMAIL PROTECTED] - (+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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
