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

[Simon Josefsson]

mån 2012-07-30 klockan 20:32 +0200 skrev Aurelien Jarno:
> 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).

Thanks for debugging this.

> 
> 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.

Sure -- should I just upload to unstable?  If you could ask the release
team that would be great.

/Simon

> 
> 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));
> 
> 
>