Re: blast+ packaging
Hi, I tried debuild -rfakeroot but it still fails. I cannot build anymore the package. dpkg-source -b ncbi-blast-2.2.25+-src dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying legacy_rename_rpsblast dpkg-source: info: applying fix_checks dpkg-source: info: applying fix_gcc46_errors dpkg-source: info: building ncbi-blast+ using existing ./ncbi-blast+_2.2.25.orig.tar.gz dpkg-source: info: building ncbi-blast+ in ncbi-blast+_2.2.25-1.debian.tar.gz dpkg-source: internal error: add_directory() only handles directories dpkg-buildpackage: error: dpkg-source -b ncbi-blast-2.2.25+-src gave error exit status 29 Olivier Le 5/30/11 7:23 PM, Aaron M. Ucko a écrit : Olivier Sallou olivier.sal...@irisa.fr writes: configure: error: Do not know how to build MT-safe with compiler /usr/bin/g++ Updating debian/rules to r6893 should fix that, though I'd still recommend using fakeroot only as needed (e.g., via debuild -rfakeroot). Once again, thanks for pointing out the problem and sorry you ran into it. -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de50afc.7090...@irisa.fr
Re: blast+ packaging
hi, after updating to your code, there is a compil (configure) error at build time: configure: error: Do not know how to build MT-safe with compiler /usr/bin/g++ Maybe a missing dependency, do you have any idea? Olivier Le 5/29/11 6:12 PM, Aaron M. Ucko a écrit : Olivier Sallou olivier.sal...@irisa.fr writes: please feel free to commit in my dir. It will indeed be easier than merging. Done, thanks. I also threw in some improvements to the copyright file that I'd meant to propose earlier: * Remove the stanza for (c++/)scripts/projects/xmlwrapp/*, whose LICENSE file documents material absent from the ncbi-blast+ archive. * Adjust other upstream-related stanzas' Files specifications to prefix c++/ and cover include in addition to src as appropriate. For dir updates, be it ncbi-blast+ or ncbi-blast-plus, I would rather like you update directly in my branch. We can, after that, mv the svn dir to ncbi-blast+ once everything is ok from packaging point of view. That's fair, and no problem -- quite the contrary, when I was starting to commit to ncbi-blast+ (before the Alioth glitch and your latest reply), I didn't split my changes into individual commits quite as cleanly as I'd meant to, so re-committing them in ncbi-blast-plus gave me a good opportunity to correct that. Please tell me once you have included your updates so that I recheck the package on my side. I have. Here are the remaining issues of which I'm aware, none of which should necessarily hold up an initial upload: * As previously mentioned, the linkage is still somewhat of a mess. * Also as mentioned, there are no individual manpages. * The standards version is slightly outdated; somebody should review the upgrading checklist to see if advancing it requires any packaging changes. * As I recall, there was some interest in incorporating RMBLAST, the patch for which risked changing the standard applications' behavior. I expect it should be possible to stay out of trouble by building it in a separate copy of the source tree and linking it statically against any patched libraries (and their reverse dependencies). Regarding legacy, I prefered keeping it as separate package to avoid some confusion and get it only if required on backward compatibility. Though, if you think we should keep it in the same package, it is ok for me. OK, thanks for the explanation; I've kept the split. -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de34ab1.6030...@irisa.fr
Re: blast+ packaging
That's a puzzling error; please send your c++/config.log, which should shed more light on it. nbsp;Thanks! -- Sent from my Palm Pre On May 30, 2011 3:44, Olivier Sallou lt;olivier.sal...@irisa.frgt; wrote: hi, after updating to your code, there is a compil (configure) error at build time: configure: error: Do not know how to build MT-safe with compiler /usr/bin/g++ Maybe a missing dependency, do you have any idea? Olivier Le 5/29/11 6:12 PM, Aaron M. Ucko a écrit : gt; Olivier Sallou lt;olivier.sal...@irisa.frgt; writes: gt; gt;gt; please feel free to commit in my dir. It will indeed be easier than merging. gt; Done, thanks. I also threw in some improvements to the copyright file that gt; I'd meant to propose earlier: gt; gt; * Remove the stanza for (c++/)scripts/projects/xmlwrapp/*, whose LICENSE gt; file documents material absent from the ncbi-blast+ archive. gt; * Adjust other upstream-related stanzas' Files specifications to prefix gt; c++/ and cover include in addition to src as appropriate. gt; gt;gt; For dir updates, be it ncbi-blast+ or ncbi-blast-plus, I would rather gt;gt; like you update directly in my branch. We can, after that, mv the svn gt;gt; dir to ncbi-blast+ once everything is ok from packaging point of view. gt; That's fair, and no problem -- quite the contrary, when I was starting to gt; commit to ncbi-blast+ (before the Alioth glitch and your latest reply), I gt; didn't split my changes into individual commits quite as cleanly as I'd gt; meant to, so re-committing them in ncbi-blast-plus gave me a good gt; opportunity to correct that. gt; gt;gt; Please tell me once you have included your updates so that I recheck the gt;gt; package on my side. gt; I have. Here are the remaining issues of which I'm aware, none of which gt; should necessarily hold up an initial upload: gt; gt; * As previously mentioned, the linkage is still somewhat of a mess. gt; * Also as mentioned, there are no individual manpages. gt; * The standards version is slightly outdated; somebody should review the gt; upgrading checklist to see if advancing it requires any packaging changes. gt; * As I recall, there was some interest in incorporating RMBLAST, the patch gt; for which risked changing the standard applications' behavior. I expect gt; it should be possible to stay out of trouble by building it in a separate gt; copy of the source tree and linking it statically against any patched gt; libraries (and their reverse dependencies). gt; gt;gt; Regarding legacy, I prefered keeping it as separate package to avoid some gt;gt; confusion and get it only if required on backward compatibility. Though, gt;gt; if you think we should keep it in the same package, it is ok for me. gt; OK, thanks for the explanation; I've kept the split. gt; -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: blast+ packaging
Here is config.log 25+-src/c++$ cat config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by ncbi-tools++ configure 0.0, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./src/build-system/configure --srcdir=. --with-dll --with-mt --without-autodep --without-makefile-auto-update --with-flat-makefile --without-dbapi --without-lzo --with-runpath=/usr/lib/ncbi-blast+ --with-build-root=BUILD --without-debug ## - ## ## Platform. ## ## - ## hostname = debiansid uname -m = x86_64 uname -r = 2.6.32-5-amd64 uname -s = Linux uname -v = #1 SMP Wed Jan 12 03:40:32 UTC 2011 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/local/games PATH: /usr/games PATH: /usr/local/ec2/bin ## --- ## ## Core tests. ## ## --- ## configure:1708: loading site script ./src/build-system/config.site | #!/bin/sh | # $Id: config.site 157355 2009-04-14 21:08:11Z ucko $ | | # Customize configure's default behavior; see config.site.ex or | # config.site.ncbi for examples of how to do so. | | if [ -d $NCBI ]; then | . $srcdir/src/build-system/config.site.ncbi | elif [ -r /usr/local/etc/config.site ]; then | . /usr/local/etc/config.site | else | echo 2 EOF | | ** | | Warning: unable to find config.site information. If you would like to | build the C++ Toolkit against third-party packages in non-standard | locations or otherwise customize build settings, you may wish to edit | | $srcdir/src/build-system/config.site | | using .../config.site.ex and .../config.site.ncbi as examples. | | ** | | EOF | fi configure:1719: loading cache config.cache configure:3027: checking build system type configure:3045: result: x86_64-unknown-linux-gnu configure:3053: checking host system type configure:3067: result: x86_64-unknown-linux-gnu configure:3111: checking for a BSD-compatible install configure:3166: result: /usr/bin/install -c configure:3232: checking for gcc configure:3248: found /usr/bin/gcc configure:3258: result: gcc configure:3502: checking for C compiler version configure:3505: gcc --version /dev/null 5 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. gcc (Debian 4.4.6-3) 4.4.6 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3508: $? = 0 configure:3510: gcc -v /dev/null 5 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-3' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.6 (Debian 4.4.6-3) configure:3513: $? = 0 configure:3515: gcc -V /dev/null 5 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. gcc: '-V' option must have argument configure:3518: $? = 1 configure:3541: checking for C compiler default output file name configure:3544: gccconftest.c 5 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. configure:3547: $? = 0 configure:3593: result: a.out configure:3598: checking whether the C compiler works configure:3604: ./a.out ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. configure:3607: $? = 0 configure:3624: result: yes configure:3631: checking whether we are cross compiling configure:3633: result: no configure:3636: checking for
Re: blast+ packaging
It looks like you're trying to run the whole build under fakeroot, which is unnecessary. nbsp;I can improve debian/rules to allow for that, but would regardless recommend switching to debuild -rfakeroot. Sorry you ran into trouble!
Re: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: configure: error: Do not know how to build MT-safe with compiler /usr/bin/g++ Updating debian/rules to r6893 should fix that, though I'd still recommend using fakeroot only as needed (e.g., via debuild -rfakeroot). Once again, thanks for pointing out the problem and sorry you ran into 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlboykksqn@dr-wily.mit.edu
Re: blast+ packaging
since we are on the subject, i have been trying to compile ncbi-blast on my own, for my own use. i would like to enable ever single one of it's features; eg, UUIDs . or xalan. I cannot find any info on how to activate UUIDs (it's not an option in ./configure --help) and I cannot find the proper debian package for xalan. googled, and all. do you have a list of the packages needed in order to compile blast with full features? thank you -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim0h2ovahrz5plypsvs-pnqzj_...@mail.gmail.com
Re: blast+ packaging
Hi, are you talking of blast or blast+ ? Regarding features, I do not see what you mean by xalan feature, or uuid (sounds like java packages). Olivier - Mail original - De: George Marselis geo...@marsel.is À: Debian Med Project List debian-med@lists.debian.org Envoyé: Dimanche 29 Mai 2011 13:57:28 Objet: Re: blast+ packaging since we are on the subject, i have been trying to compile ncbi-blast on my own, for my own use. i would like to enable ever single one of it's features; eg, UUIDs . or xalan. I cannot find any info on how to activate UUIDs (it's not an option in ./configure --help) and I cannot find the proper debian package for xalan. googled, and all. do you have a list of the packages needed in order to compile blast with full features? thank you -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim0h2ovahrz5plypsvs-pnqzj_...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1534645192.2546425.1306670642693.javamail.r...@zmbs1.inria.fr
Re: blast+ packaging
ncbi-blast+ . am I mistaken? On Sun, May 29, 2011 at 3:04 PM, Olivier Sallou olivier.sal...@irisa.fr wrote: Hi, are you talking of blast or blast+ ? Regarding features, I do not see what you mean by xalan feature, or uuid (sounds like java packages). Olivier - Mail original - De: George Marselis geo...@marsel.is À: Debian Med Project List debian-med@lists.debian.org Envoyé: Dimanche 29 Mai 2011 13:57:28 Objet: Re: blast+ packaging since we are on the subject, i have been trying to compile ncbi-blast on my own, for my own use. i would like to enable ever single one of it's features; eg, UUIDs . or xalan. I cannot find any info on how to activate UUIDs (it's not an option in ./configure --help) and I cannot find the proper debian package for xalan. googled, and all. do you have a list of the packages needed in order to compile blast with full features? thank you -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim0h2ovahrz5plypsvs-pnqzj_...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimzpjzqnyigf8-fghk1fqwcwzn...@mail.gmail.com
Re: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: please feel free to commit in my dir. It will indeed be easier than merging. Done, thanks. I also threw in some improvements to the copyright file that I'd meant to propose earlier: * Remove the stanza for (c++/)scripts/projects/xmlwrapp/*, whose LICENSE file documents material absent from the ncbi-blast+ archive. * Adjust other upstream-related stanzas' Files specifications to prefix c++/ and cover include in addition to src as appropriate. For dir updates, be it ncbi-blast+ or ncbi-blast-plus, I would rather like you update directly in my branch. We can, after that, mv the svn dir to ncbi-blast+ once everything is ok from packaging point of view. That's fair, and no problem -- quite the contrary, when I was starting to commit to ncbi-blast+ (before the Alioth glitch and your latest reply), I didn't split my changes into individual commits quite as cleanly as I'd meant to, so re-committing them in ncbi-blast-plus gave me a good opportunity to correct that. Please tell me once you have included your updates so that I recheck the package on my side. I have. Here are the remaining issues of which I'm aware, none of which should necessarily hold up an initial upload: * As previously mentioned, the linkage is still somewhat of a mess. * Also as mentioned, there are no individual manpages. * The standards version is slightly outdated; somebody should review the upgrading checklist to see if advancing it requires any packaging changes. * As I recall, there was some interest in incorporating RMBLAST, the patch for which risked changing the standard applications' behavior. I expect it should be possible to stay out of trouble by building it in a separate copy of the source tree and linking it statically against any patched libraries (and their reverse dependencies). Regarding legacy, I prefered keeping it as separate package to avoid some confusion and get it only if required on backward compatibility. Though, if you think we should keep it in the same package, it is ok for me. OK, thanks for the explanation; I've kept the split. -- 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlhb8dscyg@dr-wily.mit.edu
Re: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: for info I could make a few changes ot blast+ packaging: Please don't let the length of this message alarm you; as I mentioned, you're off to a great start, but there are plenty of details to packaging anything well, and BLAST is no exception. Moreover, my suggestions mostly cover relatively minor issues that I probably wouldn't bother reporting if not specifically asked to review the package. At any rate, I'm all for enabling shared libraries and putting them in a private directory, but adding that directory to the global search path defeats the purpose of doing so. Instead, I'd suggest using the --with-runpath=... option (easy to overlook among all the others) to build in the right path, at which point you'll be good to go, with no need for chrpath or ldconfig. I propose some other changes to configure flags as well: * Add --with-flat-makefile to make it easy to build just the libraries the BLAST applications and tests need. (For this to be effective, it is also necessary at the moment to run configure with LD_LIBRARY_PATH set.) * Add --without-lzo to avoid picking up extra dependencies when its -dev package happens to be installed. * Add --without-autodep and --without-makefile-auto-update to streamline the build and (in the latter case) simplify cleanup. * Set an explicit build root (BUILD) to which other rules can then refer. * Substitute --with-optimization for --without-debug when DEB_BUILD_OPTIONS contains nostrip. It would be cleaner to do so unconditionally, as that change also switches from -DNDEBUG to -D_DEBUG, but if you don't have the resources to link debug binaries, so be it. * Drop --without-gbench, --without-internal, and --with-3psw=std:netopt (superfluous) and --bindir=... and --libdir=... (in favor of manual installation). Passing --with-flat-makefile as proposed above yields a Makefile.flat that override_dh_auto_build can proceed to invoke from the build directory with a suitable all_projects setting (algo/blast/ app/ objmgr/ objtools/align_format/ objtools/blast/). You can also set DLL_LDFLAGS=-Wl,--as-needed at that point to address some of dpkg-shlibdeps's warnings about useless linking. (Alas, we can't do the same for applications without changing library makefiles.) I'd also suggest reporting test suite errors in more detail but otherwise ignoring them, as some tests will likely fail on autobuilders that use jails lacking network connectivity. Speaking of the test suite, adding a build dependency on time should avoid the need for your existing fix_checks patch, but other changes (freshly integrated upstream) are in order to handle unpacking under .../src/... directories. As I mentioned earlier, I'd install the binaries and libraries manually; doing so is straightforward because upstream's build system collects them all in one place and actually beats running upstream's installation rule, which lacks DESTDIR support and needs a build-dependency on cpio so that it can install headers that aren't of interest at the moment anyway. Also, I'd leave a few more binaries out of /usr/bin and lose the /usr/bin scripts' extensions per Policy 10.4. (Doing so calls for a corresponding change to legacy.sh, though it can keep its name because it's an internal script in a non-standard directory. Incidentally, there's no need for a separate ncbi-blast+-legacy package if the commands it provides are in a special directory anyway.) Also, ncbiconf_unix.h is just the tip of the iceberg in terms of generated files; override_dh_clean should take care of the others as well, and build-depending on autotools-dev has no effect if you don't also invoke dh --with autotools_dev. I've attached a patch implementing all of these changes and some other cleanups (notably to the build and runtime dependencies); would you like to commit them, or should I? (In the latter case, should I factor it into smaller commits?) I've left some issues unaddressed, though, as they generally require less experimentation to handle: * As I alluded to, the linkage is a mess, with many libraries' DLL_[D]LIB settings missing or incomplete; applications still build successfully with default linker settings because they specify indirect dependencies for the sake of static builds, but cannot safely use --as-needed. That's not actively a problem, but it does generate a lot of warnings. * There are no individual manpages, just one for the suite as a whole. In the long term, adding them (perhaps based on -help or -xmlhelp output) would be awesome; for the time being, symlinks to ncbi-blast+.1 would still help. * A couple of patches could stand to be renamed: lecagy_rename_rpsblast has a typo, and fix_gcc46_include_error wound up with a second compatibility fix as well. * For that matter, you could perhaps rename the tree to match the package name (which I'm glad to see you changed per my suggestion), but that's really superficial.
Re: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: did you had time to look at ncbi-blast+ package before pushing it ? I'm trying out your packaging now; although I will have some further suggestions (detailed patch to follow later this week), I must say that you've gotten off to a great start, and would like to thank you for taking the lead 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udly61yoyu1@dr-wily.mit.edu
Re: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: did you had time to look at ncbi-blast+ package before pushing it ? I'm terribly sorry, but I still haven't had time. Perhaps this weekend. -- 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlwrhkyaam@dr-wily.mit.edu
Re: blast+ packaging
Hi, for info I could make a few changes ot blast+ packaging: - rename package to ncbi-blast+ (instead of -plus). - create a ncbi-blast+-legacy which adds some scripts for legacy blast that calls the blasT_legacy perl script to keep available previous command line (shell scripts in /usr/share/ncbi-blast+/bin) - keep libboost-test only at build time. Olivier -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc8fff4.2060...@irisa.fr
Re: blast+ packaging
Hi, thanks for your reviews. I won't have time to progress in next 2 weeks. I will refresh svn and have a look at this time For boost, I did not know what was exactly required, I just saw that it was required for compil. For zlib etc... included in code, I think we should keep the copies (even if not using them). Removing them may be complex 'cause it would also require makefile stuff updates... I'd like to be as close as possible form original source code for maintenance For additional package, do you mean an identical blast package with just binaries renamed. to avoid conflicts? to be used in place of basic package? Olivier Tim Booth ava...@fastmail.fm writes: I'm having a look at the package now. I've pushed some changes to SVN already - I hope you don't mind. To explain... Thanks for getting the review process started! I'll give more feedback once I've had time to take a closer look at the packaging, but in the meantime here's my take on the points you've raised. I don't think you need to repack the source in this case. The guidelines say to rename the tarball file, but not to change the contents unless there is a pressing reason to do so. I've tweaked the rules file to work with the pristine source. Indeed; while there's no need for the convenience copies of zlib, bzlib, or libpcre, their presence poses no legal complications, so it should suffice to document them in debian/copyright. For that matter, there's also no need to spell out -plus. Do we really need all boost libs installed to build and run correctly? No, libboost-test-dev should suffice, and even then only if you want to build (and presumably run) the test suite. I also see no need for build dependencies or explicit runtime dependencies on shared libraries. I don't think we can get away with having this package conflict with blast2. Right, coexistence would be better, and I like the renaming idea. That said, I would consider alternatives and diversions to be legitimate possibilities as well; likewise for shipping an additional package that just arranges by whatever means for rpsblast et al. to run BLAST+ binaries. -- 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: blast+ packaging
Olivier Sallou olivier.sal...@irisa.fr writes: thanks for your reviews. I won't have time to progress in next 2 weeks. I will refresh svn and have a look at this time No problem; I know how that goes. I'd like to be as close as possible form original source code for maintenance That's fair, though I will note for the record that the build system adapts well to missing subtrees, as long as they weren't actually necessary. For additional package, do you mean an identical blast package with just binaries renamed. to avoid conflicts? to be used in place of basic package? I had envisioned a package that would depend on ncbi-blast+ (or ncbi-blast-plus if you insist) and just contain the necessary symlinks. That said, such an approach would probably be excessive; instead, one further possibility would be for the regular package to contain a directory (/usr/lib/ncbi-blast+/bin, perhaps) containing such symlinks, which users could then add to their PATHs as desired. -- 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udl8vuhrg4b@dr-wily.mit.edu
Re: blast+ packaging
Hi Olivier, I'm having a look at the package now. I've pushed some changes to SVN already - I hope you don't mind. To explain... I don't think you need to repack the source in this case. The guidelines say to rename the tarball file, but not to change the contents unless there is a pressing reason to do so. I've tweaked the rules file to work with the pristine source. Do we really need all boost libs installed to build and run correctly? It might be worth looking which are really needed. I think I need to do this in any case as libboost-all doesn't exist on Ubuntu Lucid. I don't think we can get away with having this package conflict with blast2. Though legacy_blast.pl handles some issues, there will be many people who have old scripts that rely on old BLAST but also want BLAST+. I considered using dpkg-divert to push rpsblast to rpsblast.old but I don't think adding a package should modify an existing one like this. The alternatives system might be appropriate but probably confusing to most users in this case. The solution used previously on BL is to have the newer rpsblast renamed rpsblast+, so I've done this for your package for now. What do you think? Cheers, TIM On Tue, 2011-05-03 at 15:30 -0400, Aaron M. Ucko wrote: Olivier Sallou olivier.sal...@irisa.fr writes: Would you mind having a look ? It is in svn at ncbi-blast-plus I'll be happy to, but probably won't have time until this weekend at the very soonest. -- 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 -- To Err is human. To Arrr is Pirate! -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304668725.30708.431.camel@barsukas
Re: blast+ packaging
Tim Booth ava...@fastmail.fm writes: I'm having a look at the package now. I've pushed some changes to SVN already - I hope you don't mind. To explain... Thanks for getting the review process started! I'll give more feedback once I've had time to take a closer look at the packaging, but in the meantime here's my take on the points you've raised. I don't think you need to repack the source in this case. The guidelines say to rename the tarball file, but not to change the contents unless there is a pressing reason to do so. I've tweaked the rules file to work with the pristine source. Indeed; while there's no need for the convenience copies of zlib, bzlib, or libpcre, their presence poses no legal complications, so it should suffice to document them in debian/copyright. For that matter, there's also no need to spell out -plus. Do we really need all boost libs installed to build and run correctly? No, libboost-test-dev should suffice, and even then only if you want to build (and presumably run) the test suite. I also see no need for build dependencies or explicit runtime dependencies on shared libraries. I don't think we can get away with having this package conflict with blast2. Right, coexistence would be better, and I like the renaming idea. That said, I would consider alternatives and diversions to be legitimate possibilities as well; likewise for shipping an additional package that just arranges by whatever means for rpsblast et al. to run BLAST+ binaries. -- 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlsjsrwuul@dr-wily.mit.edu
Re: blast+ packaging
Hi Olivier, On Wed, Apr 27, 2011 at 02:35:55PM +0200, Olivier Sallou wrote: Has anyone started something? Or should I go for it ? If you are brave enough to tackle this there are several people who would be happy about this (and some other programs depend from it. I would strongly advise to CC Aaron Ucko (as I did now) because he is the ncbi / blast expert and I think I remember he had given some statement about blast+. While Aaron is a member of the Debian Med team he does not follow this list strictly - so CCing him makes sense. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110427125349.ge21...@an3as.eu
Re: blast+ packaging
Hi, thanks for the info. Regarding binaries size vs compiled from source, I know that by default, compilation is done with debug enabled, and increase size/lower performance. For uscan I did not have a look yet, for the moment I will try to get compilation done... The legacy_blast.pl is given in the source code. I will have a look at alternatives when basic compile/install is ok. Olivier Le 4/27/11 4:32 PM, Tim Booth a écrit : Hi Olivier, This was on my RADAR but I'm currently about to tackle AmplicoNoise (must remember to file an ITP before I start...) so please go ahead. I had a look at it at the sprint and this is what I found: 1) This may have been down to our rubbish wireless link but there appeared to be something stopping automated downloads (ie. Uscan) from NCBI. I know they do have anti-leeching on some of their sites. Do you get any problems? 2) The current blast2 package has a version that tallies with the blast+ version - ie. 1:2.2.24.20100808-2, yet the blast2 package doesn't contain Blast+ and I can't see where this version is coming from in blast2 given that it is built from the NCBI C toolkit which is versioned by date. I started to look into this and ran out of time - any idea? 3) There is a handy script called legacy_blast.pl that emulates blastall and thus allows BLAST+ to be used with tools like T-Coffee. I can't remember if this is in the upstream tarball or not, but if so it might be worth using the alternatives system to allow BLAST+ to fill in for legacy BLAST. 4) The BLAST+ binaries, if downloaded pre-compiled from NCBI, come in at a whopping great size compared to the source code. I was meaning to look into what was going on (muchos static linking??) but never got around to it. 5) There should be a default $BLASTDB directory, I think. Can't remember what the Debian policy is on apps that need a certain environment set before they will run but I'm sure the basic idea is to try and set defaults so the app will run out-of-the-box. Anyway, I gather BLAST+ should be less of a beast to package then the original, so have fun. I'm not very good at reading the list so if you are able to CC me on any messages that would be appreciated. Cheers, TIM On Wed, 2011-04-27 at 14:53 +0200, Andreas Tille wrote: Hi Olivier, On Wed, Apr 27, 2011 at 02:35:55PM +0200, Olivier Sallou wrote: Has anyone started something? Or should I go for it ? If you are brave enough to tackle this there are several people who would be happy about this (and some other programs depend from it. I would strongly advise to CC Aaron Ucko (as I did now) because he is the ncbi / blast expert and I think I remember he had given some statement about blast+. While Aaron is a member of the Debian Med team he does not follow this list strictly - so CCing him makes sense. Kind regards Andreas. -- http://fam-tille.de -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db82a58.4030...@irisa.fr
Re: blast+ packaging
Hello, On 04/27/2011 02:35 PM, Olivier Sallou wrote: I see in tasks the ncbi Blast+ software, not packaged. Has anyone started something? Or should I go for it packages/ncbi-tools-cxx I once had a closer look at ... but then there was something with the build the let me stop ... don't recall. Steffen -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db82a69.90...@gmx.de
Re: blast+ packaging
Hi Olivier, This was on my RADAR but I'm currently about to tackle AmplicoNoise (must remember to file an ITP before I start...) so please go ahead. I had a look at it at the sprint and this is what I found: 1) This may have been down to our rubbish wireless link but there appeared to be something stopping automated downloads (ie. Uscan) from NCBI. I know they do have anti-leeching on some of their sites. Do you get any problems? 2) The current blast2 package has a version that tallies with the blast+ version - ie. 1:2.2.24.20100808-2, yet the blast2 package doesn't contain Blast+ and I can't see where this version is coming from in blast2 given that it is built from the NCBI C toolkit which is versioned by date. I started to look into this and ran out of time - any idea? 3) There is a handy script called legacy_blast.pl that emulates blastall and thus allows BLAST+ to be used with tools like T-Coffee. I can't remember if this is in the upstream tarball or not, but if so it might be worth using the alternatives system to allow BLAST+ to fill in for legacy BLAST. 4) The BLAST+ binaries, if downloaded pre-compiled from NCBI, come in at a whopping great size compared to the source code. I was meaning to look into what was going on (muchos static linking??) but never got around to it. 5) There should be a default $BLASTDB directory, I think. Can't remember what the Debian policy is on apps that need a certain environment set before they will run but I'm sure the basic idea is to try and set defaults so the app will run out-of-the-box. Anyway, I gather BLAST+ should be less of a beast to package then the original, so have fun. I'm not very good at reading the list so if you are able to CC me on any messages that would be appreciated. Cheers, TIM On Wed, 2011-04-27 at 14:53 +0200, Andreas Tille wrote: Hi Olivier, On Wed, Apr 27, 2011 at 02:35:55PM +0200, Olivier Sallou wrote: Has anyone started something? Or should I go for it ? If you are brave enough to tackle this there are several people who would be happy about this (and some other programs depend from it. I would strongly advise to CC Aaron Ucko (as I did now) because he is the ncbi / blast expert and I think I remember he had given some statement about blast+. While Aaron is a member of the Debian Med team he does not follow this list strictly - so CCing him makes sense. Kind regards Andreas. -- http://fam-tille.de -- To Err is human. To Arrr is Pirate! -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303914754.3295.1595.camel@barsukas
Re: blast+ packaging
Tim Booth ava...@fastmail.fm writes: 1) This may have been down to our rubbish wireless link but there appeared to be something stopping automated downloads (ie. Uscan) from NCBI. I know they do have anti-leeching on some of their sites. Do you get any problems? This shouldn't be a problem. How does your watch file read, and what errors do you get? 2) The current blast2 package has a version that tallies with the blast+ version - ie. 1:2.2.24.20100808-2, yet the blast2 package doesn't contain Blast+ and I can't see where this version is coming from in blast2 given that it is built from the NCBI C toolkit which is versioned by date. I started to look into this and ran out of time - any idea? BLAST+ comes from NCBI's C++ Toolkit, but the version numbers line up because they share the same underlying engine (written in C without any dependencies on code specific to either Toolkit). 3) There is a handy script called legacy_blast.pl that emulates blastall and thus allows BLAST+ to be used with tools like T-Coffee. I can't remember if this is in the upstream tarball or not, but if so it might be worth using the alternatives system to allow BLAST+ to fill in for legacy BLAST. It is present in the upstream tarball, and that would be a reasonable use of the alternatives system, which I'd be happy to accommodate from the C side. Another option would be to ship the symlinks to legacy_blast.pl in a separate package that would provide, conflict with, and replace blast2. 4) The BLAST+ binaries, if downloaded pre-compiled from NCBI, come in at a whopping great size compared to the source code. I was meaning to look into what was going on (muchos static linking??) but never got around to it. The precompiled binaries are statically linked C++ code, hence huge. ;-) The C++ Toolkit's build system moreover defaults to producing extra-huge debugging-oriented executables, but that doesn't affect the distributed binaries, which arrange to use different options. 5) There should be a default $BLASTDB directory, I think. Can't remember what the Debian policy is on apps that need a certain environment set before they will run but I'm sure the basic idea is to try and set defaults so the app will run out-of-the-box. ncbi-data (on which you'll probably want to depend anyway) ships an /etc/ncbi/.ncbirc to which I could trivially add a [BLAST] BLASTDB setting. Anyway, I gather BLAST+ should be less of a beast to package then the original, so have fun. It's differently beastly: the build system is far less idiosyncratic, but the tree is much bigger, and the full C++ Toolkit features other major applications (Genome Workbench and Cn3D++) that not only have independent release cycles but also come from different upstream branches. None of that's insurmountable; I just haven't had time to work on packaging any NCBI C++ code. I'm not very good at reading the list so if you are able to CC me on any messages that would be appreciated. Likewise, as Andreas noted. 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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udloc3rzaq9@dr-wily.mit.edu
