[Top][All Lists]
[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
- Bug#670316: shishi: FTBFS on s390x: testsuite failure,
Aurelien Jarno <=