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 <pk...@debian.org> 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));
>
>
>
_______________________________________________
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
