Package: ncbi-blast+
Version: 2.16.0+ds-6
Severity: normal

Dear Maintainer,

While working on #1079439, a test failure in python-biopython
that appeared only on riscv64 turns out to be symptomatic of the
following issue:

	$ makeblastdb -dbtype nucl -in GenBank/NC_005816.fna -parse_seqids -hash_index -max_file_sz 20MB -taxid 10


	Building a new DB, current time: 09/04/2024 20:41:00
	New DB name:   /build/python-biopython-1.83+dfsg1/Tests/GenBank/NC_005816.fna
	New DB title:  GenBank/NC_005816.fna
	Sequence type: Nucleotide
	Keep MBits: T
	Maximum file size: 20000000B
	Adding sequences from FASTA; added 1 sequences in 1.68889 seconds.

	No volumes were created.

	BLAST Database creation error: LMDB runtime error: mdb_env_open: Operation not supported

Falling back to blastdb version 4 works around the issue:

	# makeblastdb  -blastdb_version 4 -dbtype nucl -in GenBank/NC_005816.fna -parse_seqids -hash_index -max_file_sz 20MB -taxid 10


	Building a new DB, current time: 09/04/2024 20:43:59
	New DB name:   /build/python-biopython-1.83+dfsg1/Tests/GenBank/NC_005816.fna
	New DB title:  GenBank/NC_005816.fna
	Sequence type: Nucleotide
	Deleted existing Nucleotide BLAST database named /build/python-biopython-1.83+dfsg1/Tests/GenBank/NC_005816.fna
	Keep MBits: T
	Maximum file size: 20000000B
	Adding sequences from FASTA; added 1 sequences in 1.52792 seconds.

As far as I can witness this is machine specific (not accounting
for similar looking symptoms with s390x, although the big endian
factor was not innocent in the matter; we're speaking little
endian in this case):

	$ uname -m
	riscv64

I plan to skip test_NCBI_BLAST_tools.py in python-biopython in
the meantime: this package is not subject to serious bug or
autoremoval whatsoever, but in its current state it hogs debci
riscv64 runners due to another problem.

Have a nice day,  :)

Étienne Mollier <emollier@debian.org> writes:

Hi, Étienne.

Can you still reproduce this error?  I can't on ricci, either directly
or as part of Biopython's test suite (with test_NCBI_BLAST_tools
reinstated).  I'm not sure whom to thank, as neither BLAST+ nor LMDB has
had an intervening sourceful upload; both have had subsequent rebuilds,
but AFAICT both were formalities as far as makeblastdb is concerned.
BLAST+ does of course have other dependencies beyond the toolchain --
for instance, its rebuild served to pick up Mbed TLS 3.x -- but none I'd
expect to be pertinent here.

Sorry for the delayed response -- I normally go through
*-porterbox.debian.net aliases, but ricci didn't have one (and still
doesn't!), so I'd missed the possibility of investigating directly.

Hi Aaron,

I can still reproduce this error, but only in qemu-user context.
It is quite possible that I could be running into a limitation
of the emulation layer.  I attempted to reproduce the problem on
ricci and my reproducer ran just fine, same as your observation.

I'm not sure what to make of it.  Perhaps the issue can be
closed.

Thanks for having had a look!  :)

Étienne Mollier <emollier@debian.org> writes:

Thanks for clarifying!  I see it there too, but not under qemu-system
(let alone actual hardware).

Indeed; we saw something similar in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969608, though this
error is different and adjusting BLASTDB_LMDB_MAP_SIZE doesn't affect it
AFAICT.  I also tried increasing qemu-user's stack size, but that made
no difference either.  (I didn't try the combination, though.)

I'm on board with leaving it open for now but on hold until after
Trixie.