Re: Emboss not migrating due to autopkgtest error on s390x
Steven Robbins writes: > Perhaps that is something worth transmitting to the s390 porters list? > If true, it may mean the issue lies elsewhere and fixes there will mean > emboss > works again. s390x is a 64-bit architure, so the time_t64 transition was a pure formality there. (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
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Steven Eker writes: > This is harmless on 64-bit architectures since Index will be a signed > 64-bit integer and if it works on 32-bit architectures, it's a work > around until GMP is fixed (hopefully before 2038). I know this suggestion is unorthodox, and quite possibly moot at this point in the context of official Debian packages -- but you might want to consider formally going through double here, at least on the relevant platforms. Precision loss shouldn't be a concern for another 140 million years or so by my reckoning, and I expect the additional conversion overhead 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
Re: Should we restrict libtread-pool to 64bit only
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, 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
Re: Attempt to upgrade sra-sdk
Andreas Tille writes: > No mbedtls libs found installed in the system, using local copy... Because env/common.cmake doesn't actually try to use a system installation: #check_include_file_cxx(mbedtls/md.h HAVE_MBEDTLS_H) set(HAVE_MBEDTLS_H 0) # TODO: disabling system mbedtls since it may be outdated Patching that logic to enable and honor the check reveals that its concerns are legitimate, with upstream bundling and evidently relying on a 3.x version whereas Debian still ships 2.28.5; arranging to use the Debian version yields several compilation errors in libs/cloud/gcp.c's Sign_RSA_SHA256, and quite possibly more errors elsewhere. Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036231, Debian packaging of mbed TLS 3.x is waiting on a long-term-support release series thereof, so our options are either backporting ncbi-vdb to build against 2.28. (perhaps with the help 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. :-/ -- 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
Re: Attempt to upgrade sra-sdk
Andreas Tille writes: > I've spent some time into the new version of sra-sdk and tried to adapt > the patches to the new upstream version. Hi, Andreas, and thanks! AFAICT, the immediate problem is that label_online_tests.patch refers to at least one removed or renamed test: CMake Error at test/internal/vdb-diff/CMakeLists.txt:42 (set_tests_properties): set_tests_properties Can not find test to add properties to: Test_VDB_Diff_Check_success Temporarily disabling this patch will let you focus on compilation issues for the time being. Please also bear in mind that upstream 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) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Adding autopkgtest to Orthanc-python
Andreas Tille writes: > I have no idea what this might mean. Could you have a look at the > test? I also realised that you are installing There's a more specific error a few lines up: E1020 09:35:18.908283 OrthancException.cpp:61] The TCP port of the DICOM server is privileged or already in use: (port = 4242) cannot create network: TCP Initialization Error: Address already in use I don't know what else would be listening there, though, or if the actual issue is that the container doesn't allow listening for network connections at all, though in that case I might have expected 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
Re: Issues with concurrentqueue
Andreas Tille writes: > E: libconcurrentqueue-dev: triplet-dir-and-architecture-mismatch is for > amd64 instead of all [usr/lib/x86_64-linux-gnu/] These files are not appropriate to move as is, for two reasons (unless I missed anything): - concurrentqueueConfig.cmake and concurrentqueueTargets.cmake both embed the directory name and would need to be adjusted accordingly. - concurrentqueueConfigVersion.cmake embeds the expected pointer size as a sanity check, even though there are no actual build products to worry about matching. That said, the package is so small that you 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.edu/cgi/finger/?a...@monk.mit.edu
Re: C++ help needed
tags 1034369 + patch
thanks
Andreas Tille writes:
> I guess the fix will boil down to a type casting in this line
>
>
> https://salsa.debian.org/med-team/libcereal/-/blob/master/unittests/map.hpp#L65
>
> o_esplmap.insert({random_value(gen), { random_value(gen),
> random_value(gen) }});
>
> unfortunately my C++ knowledge is too limited to know whether it is
> really that simple nor how exactly this line needs to be fixed. The fix
> should be tested at least on arm64 (since the test passes on amd64).
#1034369 looks very similar to #1021394, which worked around
corresponding build-time errors by disabling -Werror but I see left the
autopkgtest's cmake invocation as is; there may be merit in disabling
-Werror on that front too. At any rate, I would recommend properly
addressing the compiler's concerns by changing random_value to
random_value 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, 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
Index: b/unittests/map.hpp
===
--- a/unittests/map.hpp
+++ b/unittests/map.hpp
@@ -62,7 +62,7 @@ void test_map()
std::map o_esplmap;
for(int j=0; j<100; ++j)
- o_esplmap.insert({random_value(gen), { random_value(gen), random_value(gen) }});
+ o_esplmap.insert({random_value(gen), { random_value(gen), random_value(gen) }});
std::ostringstream os;
{
Index: b/unittests/multimap.hpp
===
--- a/unittests/multimap.hpp
+++ b/unittests/multimap.hpp
@@ -71,7 +71,7 @@ void test_multimap()
std::multimap o_esplmultimap;
for(int j=0; j<100; ++j)
{
- auto key = random_value(gen);
+ auto key = random_value(gen);
o_esplmultimap.insert({key, { random_value(gen), random_value(gen) }});
o_esplmultimap.insert({key, { random_value(gen), random_value(gen) }});
}
Index: b/unittests/unordered_map.hpp
===
--- a/unittests/unordered_map.hpp
+++ b/unittests/unordered_map.hpp
@@ -54,7 +54,7 @@ void test_unordered_map()
std::unordered_map o_esplunordered_map;
for(int j=0; j<100; ++j)
- o_esplunordered_map.insert({random_value(gen), { random_value(gen), random_value(gen) }});
+ o_esplunordered_map.insert({random_value(gen), { random_value(gen), random_value(gen) }});
std::ostringstream os;
{
Index: b/unittests/unordered_multimap.hpp
===
--- a/unittests/unordered_multimap.hpp
+++ b/unittests/unordered_multimap.hpp
@@ -71,7 +71,7 @@ void test_unordered_multimap()
std::unordered_multimap o_esplunordered_multimap;
for(int j=0; j<100; ++j)
{
- auto key = random_value(gen);
+ auto key = random_value(gen);
o_esplunordered_multimap.insert({key, { random_value(gen), random_value(gen) }});
o_esplunordered_multimap.insert({key, { random_value(gen), random_value(gen) }});
}
Re: python-cogent fails to build on armhf - any idea or just removing this architecture?
Andreas Tille writes: > Any idea how to fix this? I personally would probably simply > exclude this architecture, to not loose any time. I see that debian/rules already skips building docs on armel and mipsel, presumably for similar reasons; extending the exclusion to armhf ought to work. For that matter, why not just change override_dh_auto_build to override_dh_auto_build-indep and drop the conditional exclusion? The latter approach would probably also let you move some build dependencies to Build-Depends-Indep. (Offhand, pandoc and python3-*sphinx* look like plausible candidats 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
Re: Snippy autopkgtest claims that snpeff is version 0
Andreas Tille writes: > +Architecture: amd64 arm64 Indeed. Sorry for making this restriction necessary, and for missing the need for it earlier -- I suppose Britney doesn't check very far up the reverse dependency tree for autopkgtest regressions, just for buildability ones, and doesn't care 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
Re: We are right before the freeze now - please update anything to latest version that needs updating
Andreas Tille writes: > as subject says we are right before the freeze since packages need some > time to migrate to testing to reach the next stable release. We should > upload what should be in the next release *right now*. I've explicitly I've been working on ncbi-entrez-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.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Thanks for helping sra-sdk 3 migrate!
Andreas Tille writes: >> paleomix (probably by asking for it's removal on ppc64el and mips64el as I >> think they FTBFS there now and can't be installed either). > > ACK, perfectly fine to remove paleomix on anything than amd64. Ah, yeah, I completely overlooked htsjdk's reverse dependencies, oops. AFAICT, paleomix was the only affected architecture-dependent package; I've filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029987 (with debian-med looped in for the initial report) to get the now unusable binaries removed. Thank you both very much, and sorry 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
Re: Thanks for helping sra-sdk 3 migrate!
Paul Gevers writes: > You're welcome. Next time in similar situations, don't hesitate to > contact us. I don't think our tools could have handled this situation > without interference. OK, thanks! I wasn't sure, so I'd been keeping an eye on it and planning to get in touch early 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
Thanks for helping sra-sdk 3 migrate!
Hi, Paul. I see that https://qa.debian.org/excuses.php?package=sra-sdk now has > autopkgtest for ngs-sdk/2.11.2-4: amd64: Pass, arm64: Pass, armel: > Ignored failure, armhf: Ignored failure, i386: Ignored failure, > ppc64el: Ignored failure, s390x: Ignored failure presumably courtesy 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.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Finishing ncbi-vdb and sra-sdk
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://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Help needed to upgrade ncbi-igblast
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/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Help needed to upgrade ncbi-igblast
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 alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Help needed to upgrade ncbi-igblast
Hi, Andreas. Andreas Tille writes: >https://salsa.debian.org/med-team/ncbi-igblast/-/jobs/3822434 This compiler crash looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137 , already fixed in the gcc-12 branch. I can supply a workaround if necessary, but am hopeful 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
Re: Bug#982384: [Help] Bug 982384: Warnings profile count data file not found
Andreas Tille writes: > Could anybody comment on it / fix it? Per https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fprofile-use: Before you can use this option, you must first generate profiling information. See Instrumentation Options, for information about the -fprofile-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
Re: Finishing ncbi-vdb and sra-sdk
"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 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 getting late in the day. I found time to wrap up sra-sdk 3.0.0+dfsg-1, which I've now uploaded to experimental by way of NEW (where it is of course still sitting). I gave architecture support the benefit of the doubt for now; in the likely event that we have to rein it back in, I'm inclined to do so for all architecture-dependent packages rather than trying to arrange for builds on semi-supported architectures to build only some architecture-dependent packages. I realized at the last minute (in the course of confirming that sra-sdk passes its autopkgtest) that I never merged in ngs-sdk's, which is likely to need formal adjustments per layout changes; we should try to remember to do so before uploading to unstable. Also, while scanning for copyright notices, I observed convenience copies of several separately packaged libraries. I left their handling as is for now, but it would be good to look into switching to the separately packaged copies. -- 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
Re: Htslib plugins
James Bonfield writes: > > --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' I haven't been involved with this package, but I suspect that line was supposed to have a double dollar sign so as to yield a reference to your build system's plugindir variable. 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
Re: Finishing ncbi-vdb and sra-sdk
Pierre Gruet writes: > Hmm, I did not have in mind that the package is ready for amd64 > only. If this is the case, then yes, we should not use Architecture: > all at the moment (which is otherwise the general rule for -java > packages). Ah, never mind, I misunderstood what you meant by "it"; sorry for the confusion. > After giving it some thoughts, I convinced myself it would be better > to fit Multi-Arch: same and put the symlink in /usr/lib//jni, > which only violates a "should" in the Java policy but is nevertheless > done for many packages. Also this architecture-specific path is > searched when loads shared libraries from Java code, so I have pushed > the change to Salsa. Great, thanks again! 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 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 getting late in the day. -- 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
Re: Finishing ncbi-vdb and sra-sdk
Pierre Gruet writes: > I have just pushed some changes. I adopted the -- I believe -- least > invasive solution by creating a new package libngs-jni which depends > on the shared lib package (not the -dev one), only ships a symlink to > the shared lib with full version number, and on which the -java > package depends. By the way I also made it Architecture: all and > ensured it was binNMU-able. That ought to work, thanks, but shouldn't it be Architecture: amd64? We could get away with all as long as the package is otherwise amd64-only, but we may be able to revisit getting it to build on either or both of ncbi-vdb's other supported architectures (arm64 and x32). > As such, the new -jni package is not Multi-Arch: same as it ships the > shared lib symlink in /usr/lib/jni. But if you think it should be, > then we could install the symlink in /usr/lib//jni. 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. 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
Re: Finishing ncbi-vdb and sra-sdk
Pierre Gruet writes: > Indeed, this warning should be overridden, usually I do so and add a > pointer to the discussion in > https://lists.debian.org/debian-java/2018/06/msg00021.html in the > comment in the .lintian-overrides file. Got it, thanks! > Do you have an idea of the exact way the .so is loaded by the Java > code? The methods in LibManager.java are a bit involved and I am > unsure to see which behaviour is expected exactly. If you don't, I > shall investigate further in order to help, no worry. No, sorry. That said, this issue is neither new nor urgent; I just noticed it and wanted to take the opportunity to address it if it would be reasonably easy to do so. >>> A comment to your question in your other mail: Sorry, I have no idea >>> how to teach CI to pick from experimental. FTR, https://salsa.debian.org/salsa-ci-team/pipeline 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > I wanted to set you "Owner" of the Debian Med team repository since this > is the maximum power. I realised you are owner. So either someone has > beaten me and just did so or something is wrong if you can't do what you > want to do. OK, thanks. A closer look indicated that GitLab doesn't normally allow *anyone* to force-push to protected branches: https://docs.gitlab.com/ee/user/project/protected_branches.html I temporarily enabled force pushes for this one just long enough for my needs. I would have preferred to be able to relax the policy just for owners, but AFAICT nobody else pushed in the interim anyway. >> - The javadocs contain embedded copies of files from libjs-jquery and >> libjs-jquery-ui that should become symlinks (with dependencies added). > > I've seen packages where this is ignored. If you want to approach this > and need helping hands just ask here. I reckon it should be straightforward enough, thanks; it just wasn't a priority. >> - Lower priority: I have not yet taught the Java bindings to look for >> full SONAMEs, so they still depend on a -dev package. I'd appreciate >> help from someone more familiar with Java. > > I admit I do not understand the problem but I have put Pierre in CC. More concretely, the bindings should directly load libncbi-ngs.so.3, and depend directly on libncbi-ngs3, rather than going through the unversioned libncbi-ngs.so symlink and depending on libncbi-ngs-dev. I made appropriate changes on the Python front, but I'm not so clear on how to do the same for Java. > A comment to your question in your other mail: Sorry, I have no idea > how to teach CI to pick from experimental. OK, thanks. No big deal, though 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
Re: Finishing ncbi-vdb and sra-sdk
"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 weeks ago, but ncbi-vdb 3.x is sitting >> in experimental until sra-sdk joins it.) I'll see what I can do. > > I've made a fair bit of progress, and pushed what I have so far -- > though one commit accidentally wound up with a stray change, so I'd > appreciate it if somebody could please grant me whatever access I need > to proceed with a force-push to master so I can clean that up properly. > > It's still not entirely ready, though. In particular: > - Three tests are failing; I need to investigate why. (I've been > building in nocheck mode for now to sort out everything else.) > - On a possibly related note, I should see if anything from ngs-sdk's > debian/patches is of interest here. > - The javadocs contain embedded copies of files from libjs-jquery and > libjs-jquery-ui that should become symlinks (with dependencies added). > - Lower priority: I have not yet taught the Java bindings to look for > full SONAMEs, so they still depend on a -dev package. I'd appreciate > help from someone more familiar with Java. I'll also need help getting CI to pick VDB build dependencies up from experimental; as it is, it complains of an unsatisfiable version constraint. 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
Re: Finishing ncbi-vdb and sra-sdk
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 sra-sdk joins it.) I'll see what I can do. I've made a fair bit of progress, and pushed what I have so far -- though one commit accidentally wound up with a stray change, so I'd appreciate it if somebody could please grant me whatever access I need to proceed with a force-push to master so I can clean that up properly. It's still not entirely ready, though. In particular: - Three tests are failing; I need to investigate why. (I've been building in nocheck mode for now to sort out everything else.) - On a possibly related note, I should see if anything from ngs-sdk's debian/patches is of interest here. - The javadocs contain embedded copies of files from libjs-jquery and libjs-jquery-ui that should become symlinks (with dependencies added). - Lower priority: I have not yet taught the Java bindings to look for full SONAMEs, so they still depend on a -dev package. I'd appreciate help from someone more familiar with Java. -- 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
Re: [Help] anfo: ftbfs with GCC-12
Étienne Mollier writes: > I believe in the case of anfo, that warnings about auto_ptr / > unique_ptr are red herrings. If I search for "error:"s, then I > get some errors about no match for operator<: Oops, good catch. As for unique_ptr, this is evidently one of those situtations where whoever makes the substitution (possibly upstream after all at some point) will need to make additional changes to make it clear that their usage is safe. In particular, the ...Reader constructors will probably want to accept auto_ptr<> by rvalue reference rather than 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
Re: [Help] New version of htslib does not build
Andreas Tille writes: > I tried to catch up with htslib since we are lagging behind two releases > (counted from experimental - its three release in unstable). > Unfortunately it does not build since the linker does not find some > symbols ... despite these are inside libhts.a when grepping the strings > output for it. Interestingly the missing symbols are mentioned in some > warnings higher up in the changelog![1] Any idea what might be wrong > here? Looks like a library order issue, with libhtscodec needing symbols from libhts. I suspect the reverse is also true, 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > This would be really helpful since we are approaching the next freeze > with an unpredictable migration time through new queue due to name > change of the library package. 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 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.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: [Help] anfo: ftbfs with GCC-12
Andreas Tille writes: > Could anybody have a look at this gcc failure? Per GCC's hint, please try formally substituting unique_ptr for auto_ptr. I haven't tested that approach for this package, but it's typically a safe drop-in replacement, and generally yields compilation errors in the rare 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
Re: Finishing ncbi-vdb and sra-sdk
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/finger/?a...@monk.mit.edu
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > I noticed that another upload does not keep the position of the package > in the new queue but pulls it down at the end again. :-( BTW, what is Oops. I've gone ahead with 3.0.0+dfsg2-2 now, then; I'm confident in those changes and don't want to let the position slip much more. > your rationale to push the old version 2.11.2+dfsg-5 as well? Wouldn't > that be overridden by 3.0.0+dfsg2-1? Not immediately, because they're going to different suites, with 3.x still targeting experimental for now. The idea is to allow for a maximally clean transition to having a separate ncbi-vdb-data binary package in systems running testing or unstable and updated reasonably often. (Stable will of course be another matter, but still smooth enough.) > Thanks for working on this. No problem. > Without checking the background I think > debhelper uses debian/tmp for multiple binary packages and > debian/pkgname for single binary packages. Right, though I think that may vary by compatibility level. > I fail to understand in > what way the name of that temporary dir might be an issue but I can't > check in the next two weeks. debian/rules 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. -- 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > This would mean another trip through new. I think it would be good to > upload this quickly sinnce the package is currently hanging in new and > ftpmaster can inspect your changed package. I wasn't quite as quick as I'd hoped, but still managed to avoid a separate NEW cycle. I subsequently discovered the need for some additional tuneups, which I've pushed but not uploaded because I might not be entirely done. I've likewise pushed a couple of sra-sdk commits that in conjunction with my latest ncbi-vdb changes get the build step to succeed. The installation step fails because debian/control currently lists just a single binary package, so debhelper directs the upstream build system to install directly into debian/sra-toolkit. Accounting for ngs-sdk's incorporation should reinstate the use of debian/tmp, but I don't have time to look into that 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > CMake Error at test/sharq/CMakeLists.txt:42 (add_dependencies): > The dependency target "RE2_" of target "test-sharq-parser" does not exist. I'll try to take a look soon, but most likely your patch didn't go quite far enough. Meanwhile, I have made more (local) progress on ncbi-vdb; I'm pleased to report that we should be able to drop its NGS build dependencies as of version 3.0, so there won't be a cycle to contend with after all. Also, I'm going to want to split out a small -data package to allow (temporary) coinstallation of libncbi-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
Re: igblast accepted - how can it be used to test igdiscover
Andreas Tille writes: > H, very strange. I "simply" pushed and wanted to show you in Salsa-CI > to show you the problem ... but there is no such error as here: OK, thanks. > "no"s by the according Build-Depends if we have the actual library (not > sure yet what is checked by NCBI C toolkit but others are clear, thought. Most of these checks are artifacts of fully sharing a build system with a much larger tree containing some projects that need them. The only additional build dependencies that would specifically make sense here are libbackward-cpp-dev libbz2-dev libdw-dev liblmdb-dev libmbedtls-dev libpcre3-dev zlib1g-dev generally to be used in lieu of vendored copies thereof. (The two exceptions are libbackward-cpp-dev and libdw-dev, which this code base uses if available to yield clearer stack traces if anything goes wrong. I suppose ncbi-blast+ could stand to gain build dependencies on both too.) NB: Switching to system libmbedtls-dev requires some additional tweaks: adding --with-mbedtls to the configure command line and applying https://salsa.debian.org/med-team/ncbi-blastplus/-/blob/master/debian/patches/system_mbedtls_only 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/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: igblast accepted - how can it be used to test igdiscover
Andreas Tille writes: >> --with-vdb=/usr VDB_INCLUDE=-I/usr/include/ncbi-vdb > > Hmmm, this was running into an error which I tried to fix with Do you happen to remember what the error was? It worked for me, albeit in a rather non-minimal build environment. > I'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. 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
Re: igblast accepted - how can it be used to test igdiscover
Steffen Moeller writes: > Thank you both for your help. No problem. > Am 02.08.2022 um 10:48 schrieb Andreas Tille: [...] >> Do you have any other hint how to create the main binaries reliably? Ah, sorry, a closer look indicates that the build system needs additional hints to find system VDB: --with-vdb=/usr VDB_INCLUDE=-I/usr/include/ncbi-vdb > I wanted to see it compile and thus withouted as much as possible in a > first run to reduce the complexity. That's fair. FWIW, most of these options have no bearing on the package anyway and are just artifacts of 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 benefits. -- 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
Re: igblast accepted - how can it be used to test igdiscover
Andreas Tille writes: > thanks again a lot for your helpful comments. No problem. > I wonder what needs to be done to create the said binaries. Ah, right, they need VDB; please try adding a build dependency on libncbi-vdb-dev and removing --without-vdb from the configure command line. Also, you can perform a more targeted build by adding --with-flat-makefile and then changing the build command to cd c++/*/build && make -f Makefile.flat app/igblast/ where the trailing slash is mandatory. (This approach will still yield some ancillary binaries, namely internal builds tools.) > I think that controverse is over and implemented in the package > template which contains the according lintian-override[1] OK, thanks. :-) > OK, pushed Recommends to Salsa (will drop superficial executables) Great, thanks! > I admit that's too much for a "Team upload" done by a person who has no > idea about all the ncbi stuff. That's fair; you can leave the build static for now and I'll take care of those adjustments when I get a chance. Likewise for portability issues, though as noted you probably won't have to look far for patches. >> - Some use 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
Re: igblast accepted - how can it be used to test igdiscover
Andreas Tille writes: > into igdiscover changelog. Igblast is accepted now. However, despite I did > the final upload I did not checked for actual binaries which are all "hidden" > in usr/lib/ncbi-igblast/bin. I simply took over your and David's packaging > layout and cared that it builds latest upstream. Thanks for taking IgBLAST on in general. This packaging is off to a good start, but I'm sorry to say still not quite right. In particular: - The executables to build and install directly are igblastn and igblastp along with the edit_imgt_file.pl script (which Policy 10.4 says should be installed without its extension, though I know that's somewhat controversial within this team). All come from app/igblast and should in fact wind up in /usr/bin. - As for other executables, supporting tools can and should come from ncbi-blast+ (for which I reckon a Recommends should suffice) and you don't need to install tests at all. - Because you're installing multiple binaries (even if fewer than at present), building supporting libraries dynamically should save space; please see ncbi-blast+ for an illustration of how to do so and subsequently install only those shared libraries you'll actually need at runtime. To avoid possible skew or missed IgBLAST-specific tuneups, it's probably best for the IgBLAST packaging to supply its own versions of these files, rather than building against libraries from ncbi-blast+ once a corresponding development package happens. (I realize that this approach goes against policy, but the libraries in question are at least generally native to both source bases.) - Some use cases may want app/igblast's internal_data and optional_file subtrees, which I'd suggest installing to /usr/share/ncbi/igblast; I can adjust the ncbi-data package to facilitate finding those subtrees there. - The package FTBFS on some architectures. Future releases should do better, at least on those specific fronts, but meanwhile you might want to copy some patches from ncbi-blast+. Thanks again, 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes: > -- Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_AWT_INCLUDE_PATH). > > (which is probably caused at the end of file >ngs/ncbi/ngs-jni/CMakeLists.txt ) More likely the find_package(Java ...) call on line 159 of build/env.cmake. At any rate, it looks like CMake might want the full (non-headless) JDK; I don't see an obvious way around that requirement short of setting the relevant variables explicitly, so I'd suggest keeping it simple and upgrading the build dependency. > test/sharq/CMakeLists.txt:44 (ExternalProject_Add) > > -- Configuring 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
Re: Finishing ncbi-vdb and sra-sdk
Andreas Tille writes:
> I think ncbi-vdb version 3.0.0 is finished in Git. I'm just uploading it to
> experimental (needs to pass new queue due to the changed binary names). I
Thanks, but I still have some unpushed changes from some time back. As
noted at the time, I went to +dfsg2 to sidestep formal line-ending
discrepancies in files we don't actually need. I subsequently
considered devendoring more third-party code while I was at it, but
never found time; I suppose I should just proceed with what I have.
Sorry for sitting on them for so long; I've had a lot going on outside
Debian.
> VDB_LIBDIR="" does not exist - ncbi-vdb was not installed in that location.
Does -DVDB_LIBDIR=/usr/lib/${DEB_HOST_MULTIARCH} help?
Meanwhile, I'm concerned about how to handle ngs-sdk's incorporation
into sra-sdk 3.x, since sra-sdk needs ncbi-vdb libraries but ncbi-vdb at
least historically needed to build against ngs-sdk. Given the lack of
runtime dependency, it might just need headers, in which case splitting
them out into an architecture-independent binary package should help --
particularly if we can move sra-sdk's build dependencies on VDB
development packages 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
Re: [Help] unifrac-tools: symbol `_ZTVN2H511IdComponentE' can not be used when making a shared object; recompile with -fPIC
Andreas Tille writes: > h5c++ -shared -fopenmp -o libssu.so tree.o biom.o unifrac_internal.o > unifrac_cmp_cpu.o unifrac.o cmd.o skbio_alt.o api.o -lc -lhdf5_cpp -llz4 > -llapacke -lblas -L/lib > /usr/bin/ld: > /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a(H5Exception.o): warning: > relocation against `_ZTVN2H518DataTypeIExceptionE' in read-only section > `.text' > /usr/bin/ld: > /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a(H5IdComponent.o): > relocation R_X86_64_PC32 against symbol `_ZTVN2H511IdComponentE' can not be > used when 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
Re: Accepted ebook-tools 0.2.2-5 (source) into unstable
Andreas Tille writes: >#967243: acedb: depends on deprecated GTK 2 That looks like a separate matter. Also, I see no direct runtime dependency on GTK 2 at this point, so I presume it would simply(?) be a matter of adjusting the upstream build system to build only efetch and to do without any third-party libraries, and trimming build dependencies accordingly. I'll believe that the upstream changes may be easier said than done, though. I suppose we might also need to drop the transitional acedb-other-belvu and acedb-other-dotter packages if seqtools can't move on from GTK 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
Re: Accepted ebook-tools 0.2.2-5 (source) into unstable
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
Re: Accepted ebook-tools 0.2.2-5 (source) into unstable
Debian FTP Masters writes: >* Make epub-utils conflict with ncbi-entrez-direct, as both ship the einfo > executable & manpage. I appreciate the thought, but ncbi-entrez-direct goes out of its way to avoid any such conflict: it diverts epub-utils' instances of those files, substituting a wrapper script that takes advantage of major command-line syntax differences to determine which tool the user presumably meant to run (and a manpage that notes the diversion). AFAICT, this arrangement works fine; have you found otherwise? FTR, there's a similar situation around efetch, 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/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: ncbi-igblast - compiles so much redundant general NCBI bits - wrong source tree?
Andreas Tille writes: > This hint enabled me to finally build the package. Unfortunately there Glad to hear it! > are lots of lintian errors[1]. I think I'll be able to deal with the > RUNPATH issues (if I would have time which is not the case the next > three days). Please try adding --without-runpath to the configuration flags. > I'm more concerned about Long story short, these are all false positives; I'd suggest copying debian/source/lintian-overrides from ncbi-blastplus. > E: ncbi-igblast source: license-problem-json-evil > c++/include/misc/jsonwrapp/rapidjson11/license.txt As this file explains, the problematic JSON license applies only to a jsonchecker subtree NCBI already doesn't redistribute. > E: ncbi-igblast source: source-is-missing c++/src/html/ncbi_menu.js > E: ncbi-igblast source: source-is-missing c++/src/html/ncbi_menu_dnd.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/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: ncbi-igblast - compiles so much redundant general NCBI bits - wrong source tree?
Andreas Tille writes: > ERR [127] -- [util/lmdb] lmdb_test.sh 1 (unparsable timing stats) Please try declaring a build dependency on time. FTR, my previous suggestion (switching from --with-dll to --without-dll) addressed an unrelated concern Steffen had raised, namely using a very 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
Re: Please review ncbi-vdb
Andreas Tille writes: > Ahhh, good catch. I admit I did not stumbled upon any dpkg-source errors > but I absolutely agree that we should drop VS files from upstream source. Thanks! To be clear, I mean to drop the convenience googletest copy altogether. > Ups, thanks a lot for the 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, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Please review ncbi-vdb
Andreas Tille writes: > If you think the package structure is OK I might upload to new. > Any other fine tuning that might be needed could be done in some > source-only upload. Good point, but I did already find two other things that would be best to fix before any upload: - dpkg-source errors concerning formal line-ending mismatches for Visual Studio files under vdb3/jwt-tool/googletest; I'm inclined to drop that subtree altogether, formally calling for 3.0.0+dfsg2 to avoid the need for force-pushes. - Even with that subtree out of the picture, debian/copyright is out of date on various fronts, to which the FTP Team may well object. > I absolutely agree ... but I have no idea about a test. We might > re-use the build time test partly. Or can you get some hints from > upstream? Reusing the build-time test could work, and might call for an additional 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
Re: Please review ncbi-vdb
Andreas Tille writes: > I managed the packaging now at the state where it builds binary packages > that are technically basically OK from a Debian point of view (one RPATH > issue left). Aaron, I would love if you could give it a review with > your specialist hat on. Great, thanks! I'll review the result when I get a chance. > I have no idea whether it makes sense to split up the libraries. Don't worry, it definitely does -- I anticipate it will sooner or later be common, if not typical, to need only libncbi-vdb. > Please also check whether we should keep the Architecture restriction > to certain architectures or whether cmake now enables us to simply use > "any". Last I checked, the CMake setup had some architecture-specific logic that would call for not only keeping but tightening the restriction, by dropping i386. We could perhaps attempt to reinstate i386 support, but I'm not sure it's worth the effort nowadays. > I'd really welcome some sensible autopkgtest which could prevent me > making mistakes in future. I've found sra-toolkit's to be a fairly effective stand-in, but a dedicated autopkgtest certainly wouldn't hurt. > 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
Re: Cmake help needed for ncbi-vdb
Andreas Tille writes: > but for some reason this does not have any effect. Do you have any > idea how to set SONAME correctly? I'm not sure offhand, but FWIW I already filed an internal bug report on the lack of versioned SONAMEs; I'll pass along any patches that crop up. Mathieu, you have 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
Re: Datasets to design autopkgtests for our packages
Andrius Merkys writes: > It depends whether you need simple protein FASTA sequences or > alignments. You may find simple sequences in PDB, for example [1], go to > "Download Files" and FASTA format is just there. AFAIR, PDB data is > freely distributable. Likewise for 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://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: [Help] librostlab-blast fails its autopkgtest with C++ issue
Andreas Tille writes:
> However, what I do not understand is that the build of
> librg-blast-parser-perl remains on failing[1] (versioned Build-Depends on
> fixed librostlab-blast0-dev was set):
Looks like fallout from a clash between Perl headers' definition of
YYEMPTY as a macro and Rost Lab headers' use of it as an enum name:
In file included from
/usr/lib/x86_64-linux-gnu/perl/5.32/CORE/perl.h:3938,
from Parser.xs:9:
/usr/lib/x86_64-linux-gnu/perl/5.32/CORE/parser.h:12:25: error: expected
identifier before '(' token
12 | #define YYEMPTY (-2)
| ^
/usr/lib/x86_64-linux-gnu/perl/5.32/CORE/parser.h:12:25: error: expected
'}' before '(' token
In file included from /usr/include/rostlab/blast-parser-driver.h:26,
from Parser.xs:15:
rostlab/blast-parser-parser.h:246:7: note: 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/cgi/finger/?a...@monk.mit.edu
Re: libcifpp transition
"Maarten L. Hekkelman" writes: > The Config file was no longer needed thanks to the switch to > cmake. The API should be roughly the same. It might have been helpful to leave a stub in place, perhaps with a deprecation warning; AFAICT, there are only a few reverse dependencies, 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
Re: [Help] librostlab-blast fails its autopkgtest with C++ issue
Andreas Tille writes: > /usr/bin/ld: /tmp/ccv6wJk4.o: in function `main': > parseblast.cpp:(.text+0x7c): undefined reference to > `rostlab::blast::parser_driver::parse(bool, bool)' Please try adjusting the test script to list parseblast.cpp ahead of the -l flags; now that --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
Re: [Help] librostlab-blast fails its autopkgtest with C++ issue
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.
--
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
--- a/lib/rostlab/blast-parser-driver.h
+++ b/lib/rostlab/blast-parser-driver.h
@@ -37,7 +37,7 @@
YY_DECL;
#define YY_DECL_FRIEND \
rostlab::blast::parser::token_type\
- ::yylex( rostlab::blast::parser::semantic_type* __yylval, \
+ (::yylex)( rostlab::blast::parser::semantic_type* __yylval, \
rostlab::blast::parser::location_type* __yylloc, \
rostlab::blast::parser_driver& __drv, \
void* yyscanner )
@@ -88,7 +88,7 @@ class parser_driver {
/// Parse one result from the input stream.
/** Each call returns a reference to the filled result structure. The structure may be empty in case there are no more results in the stream. */
const result_type&
- parse( bool __trace_parsing = false, bool __trace_scanning = false ) throw (rostlab::blast::parser_error);
+ parse( bool __trace_parsing = false, bool __trace_scanning = false );
/// Get tracing of scanning.
bool trace_scanning();
--- a/lib/blast-parser-driver.cpp
+++ b/lib/blast-parser-driver.cpp
@@ -19,7 +19,7 @@
#include "rostlab/blast-parser-driver.h"
const rostlab::blast::parser_driver::result_type&
- rostlab::blast::parser_driver::parse( bool __trace_parsing, bool __trace_scanning ) throw (rostlab::blast::parser_error)
+ rostlab::blast::parser_driver::parse( bool __trace_parsing, bool __trace_scanning )
{
rostlab::blast::parser parser(*this, _scanner);
parser.set_debug_level( __trace_parsing );
Re: [Help] Any idea how to patch cmake code of terraphast properly to get shared libraries
Andreas Tille writes: > But there is some remaining syntax error[1]: [...] > [1] https://salsa.debian.org/med-team/terraphast/-/jobs/2386305#L857 Ah, yeah, it looks like you should also extend the GMP settings (around line 90); sorry for missing that earlier. In principle, I suppose 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
Re: [Help] Any idea how to patch cmake code of terraphast properly to get shared libraries
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 (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Any idea how to fix this C++ code in diann
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, 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
Index: b/src/diann.cpp
===
--- a/src/diann.cpp
+++ b/src/diann.cpp
@@ -2551,6 +2551,7 @@ struct Feature {
if (pos == frm.end()) continue;
while (pos->mz < high) {
if (open && iter == 1 && pos->charge != 1) goto finish;
+{
auto = precursors[pos->pr];
if ((open || (pr.first > min && pr.first < max)) && pr.second == charge) {
if (size <= pos->pr) size = ((pos->pr * 5) / 4) + 1, temp.resize(size);
@@ -2581,6 +2582,7 @@ struct Feature {
if (open) match[j].fr = fr;
}
}
+}
finish:
pos++;
if (pos == frm.end()) break;
@@ -5397,6 +5399,7 @@ public:
goto save;
}
+ {
int ni = indices.size();
B.resize(ni); A.resize(ni, ni);
for (i = 0; i < ni; i++) {
@@ -5441,6 +5444,8 @@ public:
A.resize(0, 0);
}
+ }
+
save:
for (i = 0; i < prs_n; i++) {
int pr = pg.precursors[i];
Re: Any idea how to deal with multiple definitions in new version of genometester?
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 [1]. Please >> try building with -fgnu89-inline or changing all occurrences of "inline >> extern" in headers to just "inline" (or perhaps "static inline"). > > Thanks a lot for your hint. I tried with just "inline" and "static inline" > (which I finally commited) with no success[2]. Any further ideas? No problem. AFAICT, injecting -fgnu89-inline works with no patching needed; the one catch is that due to a quirk of the upstream build system, you'll need to supply them via CXXFLAGS (or DEB_CXXFLAGS_MAINT_APPEND) even though this is a C project. I suspect it would also work to patch *both* word-map.c (as you had before) *and* word-map.h (as you have now). With that issue (locally) out of the way, I see gdistribution.c:32:10: fatal error: wordmap.h: No such file or directory ... presumably a typo for word-map.h. -- 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
Re: Any idea how to deal with multiple definitions in new version of genometester?
Andreas Tille writes: > I tried to build genometester but my attempt to avoid redefinition of > some functions failed obviously[1]. Any help would be appreciated. Hi, Andreas. 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 [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 alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Fwd: [Debian-med-packaging] Bug#1003314: orthanc package: startlimitburst too low
Sébastien Jodogne writes: > Please could someone indicate how I can modify such a postinst script > so as Orthanc is only restarted once if multiple Orthanc plugins are > installed/upgraded at once? Please try using dpkg's trigger mechanism, per /usr/share/doc/dpkg/triggers.txt.gz (and the manpages it cites). > Or should I modify the main "orthanc.service" to set > "StartLimitBurst=10", as proposed by Gerald? But in this case, how to > ensure the compatibility with non-systemd deployments? Do they even have such limits? I can't speak for alternatives 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 at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Help with possibly broken ar archive
Andreas Tille writes: > I've never seen this before and I wonder whether this is something > I should be concerned about before uploading. Yes, it looks like the build system is set up to produce "thin" archives that can't stand on their own; please try patching the Makefile to 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
Re: ncbi-vdb plans (fixing i386, enabling arm64)
"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 debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: ncbi-vdb does not build on i386 thus migration is blocked
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. -- 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
Re: Accepted ncbi-vdb 2.11.2+dfsg-2 (source) into unstable
Andreas Tille writes: > it was actually an accident that I uploaded so late. I pushed the > changes way earlier and made skesa depending from that Debian revision > ... and forgot to upload. I only realised since skesa did not build on > autobuilders. :-( Ah, I see. Strictly speaking, 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.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Accepted ncbi-vdb 2.11.2+dfsg-2 (source) into unstable
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. :-/ -- 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
Re: Bug#984243: Help: mothur: ftbfs with GCC-11
Andreas Tille writes: > which has an incomplete number of arguments that is interrupted > by '/usr/bin/ld') That looks like it might simply be an artifact of different buffering policies for standard output and standard error; I expect you'll find the remainder of the command line 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/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: [Help needed] eegdev: FTBFS: ./doc/examples/library-usage/eegdev_acq.c:214: undefined reference to `rpl_free'
Nilesh Patra writes: > I have no idea why it can not find free() -- looks like something changed > with new autotools. > I don't know much about autotools, and need help to figure out what might be > wrong -- would you have any pointers? These errors look like fallout from a new check: > checking whether free is known to preserve errno... no Please try patching doc/examples/Makefile.am to add $(top_builddir)/lib/libgnu.la to both eegdev_acq_LDADD and recinxdf_LDADD. (libeegdev incorporates rpl_free and other needed rpl_* functions with hidden visibility, so purely 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
ncbi-vdb plans (fixing i386, enabling arm64)
sra-sdk in unstable fixes this bug, but is blocked by ncbi-vdb, which FTBFS on i386 as of the latest release. I have a fix worked out (disabling vdb3 for now, which AFAICT has no effect on the resulting binaries), and plans for some other tune-ups, perhaps most notably enabling arm64 builds. I ran out of time for them today, but hope to take care of them later in the week. --- Begin Message --- sra-sdk 2.10.9+dfsg-2 is marked for autoremoval from testing on 2021-12-06 It is affected by these RC bugs: 997280: sra-sdk: FTBFS: ld: /usr/lib/x86_64-linux-gnu/libncbi-vdb.so: undefined reference to `ZSTD_freeDCtx' https://bugs.debian.org/997280 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl --- 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
Re: Bug#984243: Help: mothur: ftbfs with GCC-11
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) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: sra-sdk is lacking libngs
Andreas Tille writes: > Real life is taking over for me this week - so if you think this is > somehow ready please feel free to upload. It hadn't been quite ready yet, but I got it ready now (complete with a quick update to today's point release) and proceeded with an upload. The reason a portion of the autopkgtest was still failing turned out to be that VDB 2.11.0 had dropped support for centrally defined protected repositories; I adjusted the test setup to switch to the new --ngc approach, using an .ngc file cribbed from upstream's test/prefetch directory. Now I definitely need 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
Re: golang-github-dataence-porter2 fails autopkgtest
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
Re: sra-sdk is lacking libngs
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 we'd be papering over a genuine regression. :-/ Meanwhile, I did push a changelog update adding a closer for #997280. -- 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
Re: Bug#984243: Help: mothur: ftbfs with GCC-11
Andreas Tille writes: > OK, I've implemented this in my last commit. Great, thanks! > Isn't > > # Get the list of all .cpp files, rename to .o files > # > OBJECTS=$(patsubst %.cpp,%.o,$(wildcard $(addsuffix *.cpp,$(subdirs > OBJECTS+=$(patsubst %.c,%.o,$(wildcard $(addsuffix *.c,$(subdirs > OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard *.cpp)) > OBJECTS+=$(patsubst %.c,%.o,$(wildcard *.c)) > > the right way to get the path correctly? Or what do you mean? Please try changing the last two lines to OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard 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.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Bug#984243: Help: mothur: ftbfs with GCC-11
Steffen Möller writes: > My C++ skills are a bit rosty but would removing the typedef for byte > solve the problem? No, because std::byte supports far too few operations [1]. Instead, I'd suggest encouraging upstream to rename their type, and meanwhile locally patching source/uchime_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 -- 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
Re: sra-sdk is lacking libngs
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 there, alas: >>>>>Running vdb-encrypt... 2021-10-19T01:47:38 vdb-encrypt.2.11.2 err: libs/vfs/manager.c:903:VFSManagerGetConfigPWFile: encryption key not found while opening manager within virtual file system module - unable to obtain a password 2021-10-19T01:47:38 vdb-encrypt.2.11.2: exiting: RC(libs/vfs/manager.c:903:VFSManagerGetConfigPWFile rcVFS,rcMgr,rcOpening,rcEncryptionKey,rcNotFound) (2615479768) We may simply need to adjust the mechanics of how we supply the key to 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
Re: sra-sdk is lacking libngs
Andreas Tille writes: > I had to exclude the test following MiltipleBuffers as well. Now the > package builds also on Salsa CI. However, the autopkgtest fails[1]. > Do you have any more hints? 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 multiple declarations of --help, to which an internal sanity checker objected, and because they were then trying to run other tools with explicit version suffixes, e.g. srapath-orig.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) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: sortmerna: "/usr/bin/ld: cannot find -lpthreads"
Andreas Tille writes: > from time to time I'm stumbling upon cmake based project about this > linker error ... and I always forget what to do. If anybody could have > a look at sortmerna I would be happy. Please look (much) earlier in the log for the actual error, in this case[1] CMake Error at src/sortmerna/CMakeLists.txt:15 (find_package): Could not find a package configuration file provided by "RocksDB" with any of the following names: RocksDBConfig.cmake rocksdb-config.cmake Add the installation prefix of "RocksDB" to CMAKE_PREFIX_PATH or set "RocksDB_DIR" to a directory containing one of the above files. If "RocksDB" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! In general, the -lpthreads error is harmless 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/-/jobs/2090520#L1205 -- 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
Re: sra-sdk is lacking libngs
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! -- 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
Re: golang-github-dataence-porter2 fails autopkgtest
First off, thanks for taking care of the update! Andreas Tille writes: > Am Thu, Oct 14, 2021 at 01:18:06PM +0530 schrieb Nilesh Patra: > >> And on a related note, do you think it makes sense to move this package to >> the golang team instead? >> This also doesn't look exactly bioinformatics either, rather a >> porter-stemmer. So for the sake of consistency, it'd IMO be good to move it >> there -- thoughts? > > I'm perfectly fine with this. Just do what you consider sensible. I'd opted to go with a team to which I already belong, corresponding 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.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: sra-sdk is lacking libngs
Andreas Tille writes: > Ahhhm my failure. Usually I do it in this sequence. No problem; thanks for getting ngs-sdk now. > Yep, I'm aware of this in principle and I've added a versioned > Build-Depends now. Unfortunately it did not helped - may be since I > did not do a correct ngs-sdk update? The error remains unfortunately. I was afraid the ngs-sdk upgrade might not suffice. It looks like the existing ngs-c++ library does the job; I was able to get past these errors by substiting -sngs-c++ for both occurrences of -sngs in tools/vdb-sql/Makefile and simply removing -sngs 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.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: sra-sdk is lacking libngs
Andreas Tille writes: > Is libngs a new project or is it possible that I failed to update > ncbi-vdb or some other related project properly and those sources also > contain the missing code? Please try updating ngs-sdk to 2.11.2 -- AFAICT, it's still at 2.10.9. I'm not entirely sure that 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://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Please update sight packaging
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 installed). -- Aaron Flavien Bridault writes: > Hi Andreas, > > Thanks for the notice, actually I already started working on it few weeks > ago. I just forgot to push my changes. > > I just did it however, I am currently stuck because of the current version of > CMake in testing. Patching would be really tough, so I am waiting for CMake > 3.21 > to reach testing, which should occur quite soon. We could still upload to > unstable though, but before I would like to test the apps running in a VM with > debian unstable (I only have testing at the moment and the libc is not > compatible, so I can't use my package generated with unstable on testing). > > I'll keep you aware. > > Cheers > > Dr. Flavien BRIDAULT IRCAD France > > Director of Software Development http://www.ircad.fr/ > > IRCAD France & IRCAD Africahttp://www.ircad.africa/ > > > flavien.brida...@ircad.frSuivez l'IRCAD sur Facebook > > Tél. : +33 (0)3 88 119 201 > > >IRCAD France > > Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex - > FRANCE > Le 01/10/2021 à 13:13, Andreas Tille a écrit : > > Hi Flavien, > > sight watch file needed to be fixed which I did and I realised there is > a new upstream version. Please update the patches (if needed) and ping > here once the package is ready for uploading. > > Kind regards and thanks for caring for this package > > Andreas.
Re: ncbi-toolbox: building winmaster, need help with assignment to source package
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
Re: Autopkgtests for pilercr
Nilesh Patra writes: > Since fetching it directly from a file location or a sort of API doesn't seem > the way out, writing a script directly looks not easy. Programmatic retrieval is very much possible, via ncbi-entrez-direct: $ efetch -db nuccore -id CP014688.1 -format fasta | head -n175 >CP014688.1 Acetobacter persici strain TMW2.1084 plasmid pAC1084_1, complete sequence ACGAGGTCGTTTCTGTCGACCCGCTGGCTATATTCAGGCTGGTAGATGTCGGCGTGGTCTGATTATTACC [...] or, with a slightly different defline, ncbi-tools-bin: $ idfetch -t5 -s 'gb|CP014688.1' | head -n175 >gi|1149544201|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://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Autopkgtests for pilercr
Andrius Merkys writes: > investigate which license is appropriate for NCBI Nucleotide database. Normally public domain, as with NCBI software. There have been occasional (apparent?) exceptions, as notably found within the UniVec data I had to drop from ncbi-tools6 a couple of years ago, but 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
Re: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > Thanks a lot for your investigation. Unfortunately I have no idea how > to proceed from here. Does anybody have an idea? I mean a better idea > than just stating this package does not work on arm64 which would > probably some last resort. Don't worry, I am still looking into this crash, and had primarily intended that comment as a public note to myself -- the crash occured within a (presumably valid) call to ncbi-blast+, and wound up taking quite a few tries to reproduce on the porterbox I was using (amdahl), so once I finally obtained more details, 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
Re: python3-scanpy 1.6.0 patched, could you take a look?
Nilesh Patra writes: > [1]: > https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names By my reading, this documents how binary package names should related to module names (as found in import directives) and says nothing about source package names. Explicit 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
Re: review+help for loguru would be nice
Steffen Möller writes: > tests/test_exceptions_formatting.py AFAICT, this test deliberately raises and catches exceptions, to confirm that backtraces come out as expected, but runs into discrepancies because they wind up containing absolute paths (whose prefixes may of course vary) rather than 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
Bug#983239: libbio-db-ncbihelper-perl: (autopkg)test failures when network is available
Étienne Mollier writes: > I have been looking in the issue below in the package > libbio-db-ncbihelper-perl. If I understood correctly, the main > point of the package is to rely on resources made available on > the Internet. I'm not sure I've been personally involved with this package, but that's my understanding as well. > a perhaps magic index to refer to human genome, but maybe it is > a "well known index".) Per [1], taxonomic ID *numbers* are stable in general, but the associated *names* occasionally change to reflect improved understandings of the underlying science. AFAICT from [2] (as linked from [3]), this change is correct and legitimate; moreover, it looks like 'Actinobacteria' should now appear in $n->common_names, if anyone wants to verify that. [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7408187/ [2] https://www.microbiologyresearch.org/content/journal/ijsem/10.1099/ijsem.0.003920 [3] https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Info=1760=3=f=1=1 > In any case, I though upstream would be interested, so I took > the liberty to open an issue in their VCS. Thanks! gregor herrmann writes: > 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 at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Building roadrunner from your salsa branch
Andreas Tille writes:
> /build/libroadrunner-1.5.4/source/rrLogger.cpp: In function
> ‘Poco::SplitterChannel* rr::getSplitterChannel()’:
> /build/libroadrunner-1.5.4/source/rrLogger.cpp:353:29: error: cannot
> ‘dynamic_cast’ ‘Poco::Logger::getChannel() const()’ (of type ‘using Ptr =
> class Poco::AutoPtr’ {aka ‘class
> Poco::AutoPtr’}) to type ‘class Poco::FormattingChannel*’
> (source is not a pointer)
> 353 | FormattingChannel *fc =
> dynamic_cast(pocoLogger->getChannel());
> |
> ^~
> /build/libroadrunner-1.5.4/source/rrLogger.cpp:355:27: error: cannot
> ‘dynamic_cast’ ‘Poco::FormattingChannel::getChannel() const()’ (of type
> ‘using Ptr = class Poco::AutoPtr’ {aka ‘class
> Poco::AutoPtr’}) to type ‘class Poco::SplitterChannel*’
> (source is not a pointer)
> 355 | SplitterChannel *sc =
> dynamic_cast(fc->getChannel());
> |
> ^~~~
> /build/libroadrunner-1.5.4/source/rrLogger.cpp: In function
> ‘Poco::PatternFormatter* rr::getPatternFormatter()’:
> /build/libroadrunner-1.5.4/source/rrLogger.cpp:363:29: error: cannot
> ‘dynamic_cast’ ‘Poco::Logger::getChannel() const()’ (of type ‘using Ptr =
> class Poco::AutoPtr’ {aka ‘class
> Poco::AutoPtr’}) to type ‘class Poco::FormattingChannel*’
> (source is not a pointer)
> 363 | FormattingChannel *fc =
> dynamic_cast(pocoLogger->getChannel());
> |
> ^~
> /build/libroadrunner-1.5.4/source/rrLogger.cpp:365:28: error: cannot
> ‘dynamic_cast’ ‘Poco::FormattingChannel::getFormatter() const()’ (of type
> ‘using Ptr = class Poco::AutoPtr’ {aka ‘class
> Poco::AutoPtr’}) to type ‘class Poco::PatternFormatter*’
> (source is not a pointer)
> 365 | PatternFormatter *pf =
> dynamic_cast(fc->getFormatter());
> |
> ^~~
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 problem. (I'm not specifically
familiar with either poco or roadrunner, but this is a common C++
pattern.)
--
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
Re: BLASTDB v5 arch-dependency (was Re: [Help] metastudent keeps on failing on certain architectures)
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 upstream V4 databases. -- 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
BLASTDB v5 arch-dependency (was Re: [Help] metastudent keeps on failing on certain architectures)
Andreas Tille writes: > I think it was some enhancement to follow Aarons hint to use blastdb > format 5. However, the test keeps in failing for i386 and armhf > architecture. For armhf the log[1] says: Ugh, it looks like format 5 is architecture-dependent -- attempting to point a 32-bit binary at a V5 database from a 64-bit binary fails with Error: mdb_env_open: MDB_INVALID: File is not an LMDB file even if I regenerate the database with BLASTDB_LMDB_MAP_SIZE set to a 32-bit-friendly value, as does attempting to point a 64-bit binary at a V5 database from a 32-bit binary. metastudent-data is far too large to make architecture-dependent if we have any other recourse, so it looks like we should explicitly use V4 here after all; as previously noted, this would entail replacing the formatdb command with makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" I see a few other binary packages that contain BLAST databases and may need similar treatment: emboss-test (needs checking) hhsuite (architecture-dependent, so presumably OK) hmmer-examples (needs checking) kleborate (architecture-dependent, so presumably OK) ncbi-data (known 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
Re: Failed build for seqan2 on i386
Andreas Tille writes:
> But other 32bit architectures like armel and armhf are passing[2]. So I
> fail to see why exactly i386 is failing. Is this possibly an effect of
> bug #917851?
Probably not; dropping the bug to a Bcc. Experimentation in an i386
chroot reveals the problem to be specifically with yara_mapper, which
https://salsa.debian.org/med-team/seqan2/-/blob/master/debian/patches/skip-some-apps-on-some-archs
explicitly excludes (along with yara_indexer) on several other 32-bit
platforms. We could go the same route for i386, but AFAICT it suffices
to drop the optimization level back down to -O2 for this specific
application, by adding
# Drop back from global -O3 on i386 to avoid
# "virtual memory exhausted: Operation not permitted"
if ("$ENV{DEB_BUILD_ARCH}" STREQUAL "i386")
target_compile_options (yara_mapper PRIVATE "-O2")
endif ()
to apps/yara/CMakeLists.txt following the add_executable call for
yara_mapper. (If and when debian/rules honors noopt, we should further
conditionalize this call accordingly, but I'm not familiar enough with
cmake to come up with the correct syntax offhand.) We could perhaps 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
Re: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
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) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Control: tags -1 + upstream Andreas Tille writes: > Aaron (or whoever might want to check), do you have any idea? Due to metastudent-data's unwieldiness, I haven't tested thoroughly, but AFAICT the immediate, and with any luck only, problem is more fallout from the switch to BLASTDB version 5 format by default, which we can address in one of two ways: - Patch metastudent-data's build system to include more generated output in install-data-local. It should at minimum allow *.pdb in addition to *.phr, *.pin, and *.psq. Additionally allowing *.pot, *.ptf, and *.pto would cover the full range of current BLAST database components (though the files with those three extensions appear to be relatively specialized and perhaps not strictly necessary), and allowing all of *.p?? would make for best futureproofing. OR - Patch the build system to produce a legacy V4 database, 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.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Please upgrade ncbi-blast+ and ncbi-entrez-direct to latest versions
Andreas Tille writes: > our outdated table[1] that there are updates for ncbi-blast+ and > ncbi-entrez-direct avialable. Will you be able to update these right in > time for the freeze? Hi, Andreas. I'm already working on ncbi-entrez-direct, and should be able to take care of ncbi-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
Re: Acquiring Dental RVG on Linux
Sonali Warunjikar writes: > I think it will need some experiments with exposure, brightness and > contrast. I don't think there is any software issue left. You might conceivably also need some non-linear gamma correction. > Thanks and best wishes for the new year. No problem; I'm glad 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
