The old s390 architecture would have been affected
but retired several years ago.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
ead would be negligible in practice.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Andreas Tille writes:
>Build-Depends libthread-pool 4.0.0 which does not build
>for 32bit architectures[1]
I see a fix in experimental:
https://buildd.debian.org/status/package.php?p=libthread-pool=experimental
Why not just reupload it to unstable?
--
Aaron M. Ucko, KB1CJ
elp of reverse cherry-picks) or
reinstating the bundled 3.x copy.
> Hope my preparation is some welcome kick-start. I wonder whether some
> of our patches could be forwarded upstream to reduce the number of edits
> for any new version.
Upstream still has bigger fish to fry. :-/
--
A
stream maintains this code in
conjunction with ncbi-vdb (lower-level) and ngs-sdk (higher-level), so
it may help to update ncbi-vdb first and you may want to update ngs-sdk
afterwards.
I'll take a closer look when I get a chance.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org
pected a more
appropriate error code.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
could reasonably enough
leave the files as is, declare the package architecture-any accordingly,
and benefit from build-time testing on additional architectures.
Thanks for asking!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.e
e here and in the other unittests/*map.hpp headers to
match the corresponding containers' declarations, per the attached
patch. The relevant platform difference is whether plain char is
signed, as it notably is on x86 but not arm*. (There are other
architectures in each camp.)
--
Aaron M. Ucko,
didats to move, though it's of course better to err on the
side of overstrict build dependencies.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
are if an architecture-independent
package has become buildable on fewer architectures.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
ez-direct, but keeping my changes to
myself so that I can rebase as needed without affecting anything I've
published. My plan is to upload something in a few days even if I'm not
fully caught up, and then see what additional updates I can get in.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.
for the disruption!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
next week if it looked like it needed
help.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
y of your hint
> # 20230126
> # on its way out
> force-badtest ngs-sdk/2.11.2-4
Thanks for helping it along, and sorry for cutting the timing closer
than I should have!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.
Version 3.x of ncbi-vdb and sra-sdk are now in unstable, and looking
good. Please do not make further uploads of either, or of skesa, until
they migrate unless absolutely necessary.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http
u...@debian.org (Aaron M. Ucko) writes:
> Will do, then.
Pushed, along with one more build fix (to accommodate our ncbi-vdb
installation layout fully) and two other tuneups to debian/rules.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | h
Nilesh Patra writes:
> packages, which includes gcc. So unless the bug
> report is very critical, the fix for the said bug _might not_ be
> uploaded.
Good point. :-/
> And so it may be a good idea to go ahead with the workaround.
Will do, then.
--
Aaron M. Ucko, KB1CJC (amu at
ful that an upcoming gcc-12 upload will include a proper fix.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
ile-generate option.
It may be simplest to drop the option, particularly if cross compilation
is otherwise possible.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
"Aaron M. Ucko" writes:
> Meanwhile, I pushed some more tuneups, mostly related to tests; in
> particular, I arranged to label and exclude all online tests, including
> for better or worse some tests that were failing even with Internet
> access. I also made the
riable. Thanks for the report!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
including
for better or worse some tests that were failing even with Internet
access. I also made the Python binary package Architecture: any in the
same binNMU-safe fashion as the main Java package. The source package
still needs a bit more work before uploading, even to experimental, but
it's gettin
i. This is
> less canonical regarding the Java policy but technically that should
> be OK.
I'm all for Multi-Arch in general, but am content to defer to Java
policy in this case.
> Also, I have added a Lintian override for the embedded JS, as we discussed.
Great, thanks!
--
Aaron M. Uck
ipeline turned out to have
tips on this; I successfully set up Aptly here.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
hough it might be nice to have it working.
Meanwhile, I reckon I'll also want to revisit debian/copyright,
particularly with a pass through NEW upcoming. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
"Aaron M. Ucko" writes:
> u...@debian.org (Aaron M. Ucko) writes:
>
>> Ah, right, sra-sdk will need to go through NEW too -- the ngs-sdk code
>> it absorbed underwent an SONAME bump along the way. (All necessary
>> ncbi-vdb changes passed NEW a few week
u...@debian.org (Aaron M. Ucko) writes:
> Ah, right, sra-sdk will need to go through NEW too -- the ngs-sdk code
> it absorbed underwent an SONAME bump along the way. (All necessary
> ncbi-vdb changes passed NEW a few weeks ago, but ncbi-vdb 3.x is sitting
> in experimental until s
by value:
std::unique_ptr&& is
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
rue, so you'll likely need to
repeat at least one library on the command line; with any luck,
... libhts.a -ldeflate -lhtscodecs libhts.a ...
will do the job.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
underwent an SONAME bump along the way. (All necessary
ncbi-vdb changes passed NEW a few weeks ago, but ncbi-vdb 3.x is sitting
in experimental until sra-sdk joins it.) I'll see what I can do.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mi
are cases where its usage would be problematic.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Andreas Tille writes:
> ping about this NCBI suite?
I've continued to have a lot going on outside Debian, but will try to
find time to get back to it soon.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/fin
ules has some explicit references to debian/tmp, and dh_install
moreover fails in this situation with the package's .install list.
These are formalities that would be quick to address, but there's no
point given that the source package will need to build multiple binary
packages soon anyway
right now.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
ncbi-vdb2 and libncbi-vdb3.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Also, PCRE2 is not an option so far -- if you supply it instead of PCRE
3.x, the build system will simply fall back on vendored PCRE 3.x.
> OK, I removed libopenmpi-dev from Build-Depends.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu
ve cleared most of the --without options and added --with-openmp with
> the according Build-Depends.
Thanks! However, please note that OpenMP is a compiler feature and
doesn't require any special build dependencies; OpenMPI, meanwhile, is a
third-party library that doesn't come into play here.
--
Aaron M.
f IgBLAST's origin in a larger tree.
Also, there's one option I'd suggest actively enabling: --with-openmp.
If you specify neither --with-openmp nor --without-openmp, the build
system uses OpenMP on a limited basis, but explicit --with-openmp
enables it across the board, from which (Ig)BLAST generally bene
se cases may want app/igblast's internal_data and optional_file
[...]
>
> Commited to git.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
and please let me know if you'd like further advice on any
of those fronts. Also, sorry for not offering concrete patches; I'm
already spread a bit too thin.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
onfiguring incomplete, errors occurred!
>
> It seems the patch I tried[1] is not working as intended. :-(
Please try patching test/sharq in addition to tools/sharq.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
es to Build-Depends-Arch.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
making a shared object; recompile with -fPIC
Please try arranging to add -shlib to the h5c++ command line to override
that script's preference for static HDF5 libraries.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
K 2,
but that would be a straightforward packaging change.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Steffen Möller writes:
> acedb-other shall step behind anything that is offered from the NCBI
> realm, I suggest.
Thanks, but no need at this point.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
where both executables
come from biology-related packages where a conflict would be more of a
problem: acedb-other and ncbi-entrez-direct (with the latter taking care
of deconflicting in the same fashion).
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~a
js
> E: ncbi-igblast source: source-is-missing c++/src/html/ncbi_menu_dyn.js
These (short!) files have somewhat long lines, but TTBOMK are meant to
be edited directly as needed.
Thanks for checking!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | h
ery
similar set of private shared libraries to what ncbi-blast+ has.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
he review.
No problem.
> So I simply wait. I'm perfectly fine if you would do the upload to
> new if you are ready with what you plan to do.
Sure, will do in due course. Thanks for your initial work on this
version, and for your patience.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, uck
nal
binary package, which I suppose is another reason to hold off on
uploading.
Also, as you noted in another thread, we are still fairly early in the
release cycle.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
; PS: Please note that I'm on vacation next week and will not do anything
> on this package in the next 10 days.
Enjoy your vacation!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
ave my thanks as well for addressing the previous errors.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
everything in GenBank/GenPept, ENA, and DDBJ per [2] and
everything in UniProt per [3].
> [1] https://www.rcsb.org/structure/6fti
[2] https://www.insdc.org/policy.html
[3] https://www.uniprot.org/help/license
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http:/
to match this '{'
AFAICT, you can address it by patching Parser.xs either to
#undef YYEMPTY
before including the Rost Lab header or to include the latter before any
Perl headers.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/c
but they all use this header as an indication of the library's
availability. (I suppose it's still not too late to reinstate it as a stub.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
as-needed is in effect by default, the linker
otherwise discards the libraries as not needed at the time of their
appearance.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Andreas Tille writes:
> Any idea how to fix
[...]
> [1] https://salsa.debian.org/med-team/librostlab-blast/-/jobs/2383360
Please try the attached patch, which eliminates the need to force an old
C++ standard version (which this package can't expect callers to use) in
debian/rules.
--
A
uppose the
conditional usage of _GLIBCXX_DEBUG should get the same treatment, but
that's presumably not relevant to Debian package builds.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Andreas Tille writes:
> Any hint how to fix this would be welcome
I see some more target-specific settings towards the bottom of
CMakeLists.txt; please try extending the use of
TERRAPHAST_PLATFORM_INCLUDE and TERRAPHAST_COMPILE_FLAGS to the new
targets.
--
Aaron M. Ucko, KB1CJC (
Andreas Tille writes:
> I gave the packaging of diann a try but failed[1]. Any idea how
> to fix these goto statements?
Please try adding braces to indicate that the variables in question are
not of interest to these statements' targets, per the attached patch.
--
Aaron M. Ucko, KB1CJ
Andreas Tille writes:
> Hi Aaron,
>
> Am Sun, Jan 16, 2022 at 09:32:08PM -0500 schrieb Aaron M. Ucko:
>>
>> It looks like this code base still goes by an old non-standard notion of
>> the semantics of "inline" with vs. without "extern" in C [
with vs. without "extern" in C [1]. Please
try building with -fgnu89-inline or changing all occurrences of "inline
extern" in headers to just "inline" (or perhaps "static inline").
[1] https://blahg.josefsipek.net/?p=529
--
Aaron M. Ucko, KB1CJC (amu at a
ternatives that were
never the default (such as runit, or upstart if that's still an option),
but I'm fairly certain classic SysV init never attempted to track, let
alone limit, how frequently services restarted.
At any rate, thanks for checking!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko
drop
the T flag from LINK.A (line 72).
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
"Michael R. Crusoe" writes:
> Hey Aaron, thanks for the update and thanks for your continued support!
No problem. I was obviously way too optimistic above, but finally found
time to go through with these tune-ups.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at deb
Andreas Tille writes:
> I hope you can find some spare minutes to check the i386 build[1] since
> migration is blocked. I guess we should also extend the list of
> architectures to some arm* variants - but I'll leave this to your
> decision.
Yes, that's all still on my to-do list.
peaking, yit might have been more appropriate to
have skesa build-depend directly on libzstd-dev and libncbi-vdb-dev
merely recommend it; however, the dependency is lightweight enough that
it doesn't make much difference, and this approach is more foolproof.
--
Aaron M. Ucko, KB1CJC (amu at alum.m
Debian FTP Masters writes:
> ncbi-vdb (2.11.2+dfsg-2) unstable; urgency=medium
> .
>* Binary package libncbi-vdb-dev Depends: libzstd-dev
Thanks! Meanwhile, I'll try to find time to finalize and push my other
tuneups this weekend -- last week obviously didn't happen. :-/
--
later on.
> Any idea how to specify the number of object files more sensibly
> to not explode the command line arguments too much?
You (or upstream) could consider using internal static libraries.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/
for its own use.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
--- End Message ---
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Andreas Tille writes:
> I'm wondering why the makefile stopped working just because a new compiler
> version is used. :-(
Along the way, you pulled in a new upstream version, whose makefile
evidently wasn't quite right.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org
to get back to my own real life, though. :-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Nilesh Patra writes:
> hope that is OK for you?
Absolutely, thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
u...@debian.org (Aaron M. Ucko) writes:
> We may simply need to adjust the mechanics of how we supply the key to use.
The only approach I've gotten to work is setting the environment
variable VDBPWFILEPTR; although we could certainly adjust the test
script accordingly, I'm concerned that w
ldcard source/*.cpp))
OBJECTS+=$(patsubst %.c,%.o,$(wildcard source/*.c))
to match the relevant sources' actual location; sorry if that was unclear.
(The existing setup only covers subdirectories of source, missing that
directory's immediate contents.)
--
Aaron M. Ucko, KB1CJC (amu at alum.
me_src/makefile to add -std=c++14 to CXXFLAGS,
thereby suppressing std::byte for now.
I also found massive link errors, resolvable by correcting the top-level
Makefile to pick up source/*.cpp and source/*.c rather than the
nonexistent *.cpp and *.c.
[1] https://en.cppreference.com/w/cpp/types/byte
--
A
u...@debian.org (Aaron M. Ucko) writes:
> So I see. I've concocted and pushed two more patches, which in
> conjunction yield much saner results on my system; let's see how they do
> on Salsa CI. (Several apps were failing both because they wound up with
Still not quite th
ig.2.11.2 rather than
srapath-orig.)
> BTW, could you ask upstream to make those tests optional to enable
> builds even on not that well equiped hardware?
I filed a request in NCBI's internal ticket tracker, no problem.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
htt
noise from standard CMake
logic, and just appears at the end of the log because debhelper's standard
practice is to dump the contents of CMakeError.log in the event of any
errors, since in other cases that file can provide crucial details.
[1] https://salsa.debian.org/med-team/sortmerna/-/j
Andreas Tille writes:
> AddRealloc (0 s)
> Killed
The following "MiltipleBuffers" (sic) test needs a *lot* of memory -- at
least 4G, quite possibly 8G if there's copying involved. As such, I
suspect it simply ran afoul of the CI host's OOM killer.
Thanks for checking!
-
g to
the package's sole reverse dependency of any sort (ncbi-entrez-direct).
That said, if somebody (e.g. Nilesh) from the Go team wants to take the
package over, they're certainly welcome to it. :-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.e
s from
tools/ngs-pileup/Makefile.
Meanwhile, I see kget has gone away altogether, so debian/rules can and
should stop trying to rename it.
I'll push fixes for both complications shortly.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff
at update will suffice, but it certainly
shouldn't hurt -- it's generally best to update ngs-sdk, ncbi-vdb, and
sra-sdk in lockstep.
Thanks for checking, and for taking care of this update!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuf
OK, thanks! FWIW, testing has had the same glibc version as unstable
(2.32-4) for about a week now, and AFAICT cmake from unstable is
installable in testing (though you will naturally also need to upgrade
cmake-data to match, and likewise for whichever of cmake-doc and/or
cmake-*-gui you have
Steffen Möller writes:
> https://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/lxr/source/src/app/winmasker/
Please try windowmasker from ncbi-blast+.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
149544201|gb|CP014688.1| Acetobacter persici strain TMW2.1084
ACGAGGTCGTTTCTGTCGACCCGCTGGCTATATTCAGGCTGGTAGATGTCGGCGTGGTCTGATTATTACC
[...]
That said, pre-retrieval does have the advantage of letting the tests
work offline.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http:/
t I see no
indication that this is one.
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/?a...@monk.mit.edu
ls, I wanted to make very sure I
wouldn't be able to lose them. Sorry for any resulting confusion.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
plicit python-* prefixes are common, even when
module names contain "py" themselves; see, for instance, python-biopython.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
han the expected relative ones. I'm not sure why
that would be; you might try consulting -python.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
I still think that NO_NETWORK_TESTING=1 should be set in debian/rules
> to make sure there's no internet access attempted during the build,
> as that is a policy violation.
Right, we're just discussing what to do about the autopkgtest.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko
());
> |
> ^~~
It looks like appending .get() to these getChannel() and getFormatter()
calls, as in
SplitterChannel *sc = dynamic_cast(fc->getChannel().get());
should take care of the immediate prob
u...@debian.org (Aaron M. Ucko) writes:
> I see a few other binary packages that contain BLAST databases and may
> need similar treatment:
Looks like these are all OK -- the only BLAST databases in
architecture-all packages other than metastudent-data are copies of
pregenerated upstr
n safe, shipping pregenerated V4 databases)
ncbi-rrna-data (ditto)
openms-doc (needs checking)
staden-common (needs checking)
I'll take a closer look when I get a chance.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
s try
doing the same for other affected platforms in an upload to
experimental.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Whoops, I had a typo in that last command; if you go that route, please
make it
makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastdb_version 4
(I'd first try pushing forward, though.)
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
ase, which would
ironically require cutting out the legacy formatdb wrapper, by
changing the formatdb invocation to
makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastb_version 4
Thanks for checking!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.or
cbi-blast+ as well.
Thanks for checking, and for pointing out the new ncbi-blast+ release,
which I had previously missed.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
d to have been of help, but would give much more
credit to the Hilberts and to your own persistence.
At any rate, I wish you a happy new year as well.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
1 - 100 of 215 matches
Mail list logo
