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 <[email protected]> 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 [email protected] http://www.aurel32.net _______________________________________________ Help-shishi mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-shishi
