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
