[Debian-med-packaging] Bug#915460: Bug#915450: staden-io-lib FTBFS on big endian: test failures

[Andreas Tille]

Control: reopen 915460

Hi James,

as always thanks for your timely and elaborate answer.

On Tue, Dec 04, 2018 at 06:12:26PM +0000, James Bonfield wrote:
> On Tue, Dec 04, 2018 at 07:53:35AM +0100, Andreas Tille wrote:
> > unfortunately there is a series of new errors on different architectures.
> > Here comes the first one.
> 
> Hmm. Some of this at least appears to be a Debian specific thing.

I can not exclude this but the fact that the issues are happening only
on certain architectures while other architectures are fine is a good
sign that there are other Debian systems that are OK.  In general I'd
recommend to have a look at

   https://buildd.debian.org/status/package.php?p=staden-io-lib

to see what architectures are building nicely as well as links to
the build logs of the others.
 
> > > === testing ./data/c1#bounds.sam ===
> > > ./scram.test: 27: [: ./data/c1#bounds.sam: unexpected operator
> 
> The [ .. unexpected operator normally comes about due to bashisms,
> like if [ "$a" == "$b" ] then (etc).  However this line doesn't do
> that - it is a single equals (I *did* have a bashism there at one
> point, but not in 1.14.11).

I agree that this smells heavily like bashism and for sure we could
even enforce bash for the specific build.  When looking at

    https://salsa.debian.org/med-team/staden-io-lib/blob/master/tests/scram.test

line 27 really contains the '==' (double equal) - I guess replacing it
by '=' might (or might not) fix the issue.  It seems that while it is
actually a sh syntax error this does not lead to an actual failure of
the test.  I simply patched this in

    https://salsa.debian.org/med-team/staden-io-lib/blob/master/debian/patches/remove_bashism.patch

and uploaded to exclude this as the source of any issue.  In fact
as you can see on the status page (first link above) the change did
not changed anything - so this bashism has nothing to do with the
underlying problem.

> I've tested the test harness using both bash and dash and I do not get
> these errors.  I'm struggling to work out how come it reports this and
> then continues regardless.  It looks like the shell just has a warning
> and doesn't treat it as a hard error.  I'm confused!

I guess the confusion is based on the assumption that the bashism
was causing the failure - but it is not and there is some other
issue causing the problem.
 
> I'm curious to know if you're getting the same issue on x86-64 and
> i386, but the more recent automakes sadly hide all test output if it
> works even with VERBOSE=1 on, grrr.  (The only reason I stick with
> autotools is because cmake is even worse!)
> 
> > >  ../progs/scramble  ./data/c1#bounds.sam test.out/c1#bounds.sam
> > >  ../progs/scramble  -r ./data/c1.fa ./data/c1#bounds.sam test.out/c1#bounds.full.cram
> > >  ../progs/scramble  ./data/c1#bounds.sam > test.out/tmp.sam
> > >  ../progs/scramble  test.out/c1#bounds.full.cram > test.out/c1#bounds.full.sam
> > >  ../progs/scramble  -O bam test.out/c1#bounds.full.cram > test.out/c1#bounds.full.bam
> > >  ../progs/scramble  test.out/c1#bounds.full.bam test.out/tmp.sam
> > > Invalid CRC in Deflate stream: 6614764d vs 00006614
> > > Failed to open file test.out/c1#bounds.full.bam
> > > FAIL scram.test (exit status: 1)
> 
> This however appears to be a genuine bug.  I'll try and reproduce it.
> 
> I'm guessing I'll need the exact OS rather than the RedHat based AWS
> image I launched last time to test non-intel platforms.
> Do you have AWS-ified Debian ARM images for people test launch tests
> against?

Debian has developer machines with purpose "Porterbox"[1] where Debian
developers can get ssh access.  If externals want access they can apply
for it and it needs a signed mail from a DD to confirm that application.
The process is not really straightforward and I for myself prefer to ask
on the according mailing lists for help from porters since I usually
have no idea about those architectures and porters to my perception are
very helpful (in most cases).

Kind regards

        Andreas.

[1] https://db.debian.org/machines.cgi 

-- 
http://fam-tille.de