help-shishi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug#670316: shishi: FTBFS on s390x: testsuite failure


From: Aurelien Jarno
Subject: Bug#670316: shishi: FTBFS on s390x: testsuite failure
Date: Mon, 30 Jul 2012 20:32:21 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

retitle 670316 shishi: FTBFS on 64-bit big endian architecture: testsuite 
failure
tag 670316 + patch
thanks

On Wed, Apr 25, 2012 at 03:55:53PM +0200, Philipp Kern wrote:
> Hi Simon,
> 
> thanks for the followup.
> 
> On Wed, Apr 25, 2012 at 02:54:15PM +0200, Simon Josefsson wrote:
> > Philipp Kern <address@hidden> writes:
> > > your package FTBFSes on s390x because of a crash / failures in the 
> > > testsuite:
> > >
> > > make[3]: Leaving directory
> > > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests'
> > > /usr/bin/make  check-TESTS
> > > make[3]: Entering directory
> > > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests'
> > > shishi_authenticator_seqnumber_get() failed
> > > shishi_authenticator_seqnumber_get() failed
> > > shishi_authenticator_client() failed
> > > shishi_authenticator_client() failed
> > > shishi_authenticator_clientrealm() failed
> > > shishi_authenticator_authorizationdata() failed
> > > shishi_authenticator_cusec_get() failed
> > > shishi_authenticator_ctime() failed
> > > FAIL: authenticator
> > 
> > Hi.  Thanks for the report.  I would either need a shell account on this
> > architecture, or your help in tracking this down.  Could you get a gdb
> > backtrace of the self-test that crashes?  Do you have any ideas on what
> > makes this architecture different from all the others, where it builds
> > and passes self-tests fine?  Does it use the same gcc/glibc/linux
> > versions as other build hosts?
> 
> It's 64bit big endian, which isn't the case for all other Debian architectures
> (except debian-ports ppc64 and sparc64).  As a DM you can request guest access
> yourself by following [1], you don't need anybody to vouch for you or
> something.  If you don't want to do that I can go and collect a backtrace, but
> it might take a few days, too.
> 

The problem is indeed related to 64-bit big endian machines, it also
fails to build on ppc64 ans sparc64. This is due to casting size_t 
pointers (len type in shishi) into int pointers (len type in libtasn1).
The patch below fixes the problem. (Note that there are also plenty of
format warning about size_t values being printed with %u, though they
seem to be harmless).

Given we are in freeze period, would it be possible to upload a new
revision of shishi with only these changes? I believe the release team
would accept such a change and let the package migrate to testing.
shishi is important on s390x in order to get inetutils built.

Regards,
Aurelien


--- shishi-1.0.1.orig/db/file.c
+++ shishi-1.0.1/db/file.c
@@ -435,7 +435,7 @@ read_key (Shisa * dbh,
 
   memset (&tmpkey, 0, sizeof (tmpkey));
 
-  rc = fscanf (fh, "%u %u %u %u %u %u", &tmpkey.etype, &tmpkey.keylen,
+  rc = fscanf (fh, "%u %zu %zu %zu %u %u", &tmpkey.etype, &tmpkey.keylen,
               &tmpkey.saltlen, &tmpkey.str2keyparamlen, &passwdlen,
               &tmpkey.priority);
   if (rc != 5 && rc != 6)
--- shishi-1.0.1.orig/lib/asn1.c
+++ shishi-1.0.1/lib/asn1.c
@@ -124,8 +124,10 @@ shishi_asn1_read_inline (Shishi * handle
                         const char *field, char *data, size_t * datalen)
 {
   int rc;
+  int tmp = (int) *datalen;
 
-  rc = asn1_read_value (node, field, (unsigned char *) data, (int *) datalen);
+  rc = asn1_read_value (node, field, (unsigned char *) data, &tmp);
+  *datalen = tmp;
   if (rc != ASN1_SUCCESS)
     {
       shishi_error_set (handle, asn1_strerror (rc));



-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]