Re: What is the relation ncbi-magicblast and magicblast
Andreas Tille <tille@debian.org> writes:
> I did this. I'm a bit worried about those errors but if you say so
> I think we can go with this.
Thanks! I could in principle track down the upstream change(s) that
bring this test back in sync, but I'm not sure there's much point, given
that AFAICT official autobuilders don't permit any network access at
all. If we're looking at trimming build coverage anyway, a better
option might be to focus the build on magicblast and the handful of
tests capable of succeeding offline. I'll elaborate on how to focus the
build below, but if we do go that route I would tweak this rule slightly
to
override_dh_auto_test:
-dh_auto_test || \
(cd c++/*/build && ./check.sh concat_err && cat check.sh.out_err; \
exit 1)
so that test suite errors are both verbose and fatal.
> Is there any chance to skip the build of makeblastdb to save computing
> power and time if we ignore the build result anyway?
Yes. For a fully minimal build, you can add the target name
magicblast.exe to the dh_auto_build command. (The .exe suffix is an
legacy of Makefile.flat's generator's origin as a tool to generate MS
Visual Studio project files, and has no effect on the actual build
product's name.)
Throwing in offline-friendly tests as discussed above is a little
trickier, but it should work to add, instead,
all_projects="magicblast.exe datatool.exe gene_info_unit_test.exe proteinkmer_unit_test.exe blastdiag_unit_test.exe misc/jsonwrapp/test/"
(Due to some additional build-system quirks, the trailing slash is
mandatory and supplying multiple target names via all_projects rather
than directly should save a little time.)
> Droping sra-toolkit works fine.
Great, thanks for confirming it!
> E: ncbi-magicblast: custom-library-search-path usr/bin/magicblast /lib/x86_64-linux-gnu
Please try running configure.orig ... --without-runpath ...
> E: ncbi-magicblast source: license-problem-json-evil c++/include/misc/jsonwrapp/rapidjson10/license.txt
> E: ncbi-magicblast source: license-problem-json-evil c++/include/misc/jsonwrapp/rapidjson11/license.txt
AFAICT, these are false positives -- upstream just bundles two rapidson
versions' headers, which fall under the Expat license. (Per #840333 and
the top of .../rapidjson11/license.txt, the only part of the full
rapidjson tree that falls under the problematic JSON license is a
jsonchecker subtree already omitted here.) It would of course be better
practice to arrange to use packaged rapidjson, but there's at least no
DFSG violation here.
> If I'm not misleaded the JS errors can be overridden - its just a false
> positive.
Right, these aren't minified, just poorly formatted in spots. Lintian
should perhaps consider average rather than maximum line length.
Thanks for checking!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu
Reply to: