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