Re: mafft [was Re: VIP]
Hi Tony, thanks for your trust and reaching out here. Since it seems to be a complex problem its probably sensible to open a bug report also for the Debian package (and please be so kind to refer with explicitly links to the bug you was talking about). I also think that the issue should be reported upstream since they actually know the code and where to debug which is not the case for random Debian / Ubuntu maintainers. Thanks again, Andreas. On Mon, Sep 28, 2020 at 01:32:27PM +0100, Tony Travis wrote: > On 08/07/2020 14:56, Michael Crusoe wrote: > > [...] > > Could be that mafft has reached a point in the computation that is still > > single threaded. > > > > Their script specifies 8 threads: > > https://github.com/keylabivdc/VIP/blob/d69b5e7615d8da76ef0dd66e51867c8ec42588d4/MSA.sh#L28 > > > > Though that is a different script than in the container, where it > > references `--thread $total_cores` where `total_cores` appears to be set > > to half of your available cores. Which matches your 12 of 24 cores > > report. > > > > You could replace that `--threads $total_cores` with `--threads -1` to > > see if that helps. > > Hi, Michael. > I've been struggling to find out what the problem is for some time now and > I've tried the version of "mafft" packaged by you for Debian-Med. > > The problem is not with "mafft", which is a shell script, but with the > "disttbfast" program spawned by "mafft", which hangs at 100% CPU on one > thread for more than seven days without completing and returning control > back to "mafft" regardless of how many threads are actually specified. > > This only seems to happen with certain viral sequences and might be because > "disttbfast gets stuck in a local minimum and never converges? > > I've just posted a bug-report including a 'problem' sequence to the Ubuntu > bug-tracker that should, presumably, find its way to you as the Debian > "mafft" package maintainer. > > Thanks for looking into my VIP "mafft" problem, > > Tony. > > -- > Minke Informatics Limited, Registered in Scotland - Company No. SC419028 > Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK) > tel. +44(0)19755 63548http://minke-informatics.co.uk > mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk > > -- http://fam-tille.de
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi Andrius, Le 29/09/2020 à 07:57, Andrius Merkys a écrit : > Hi Pierre, > > On 2020-09-28 22:47, Pierre Gruet wrote: >> Thanks for your advice! Nevertheless, this seems to rank before the >> current version number, as >> >> echo "2.6.3+dfsg-2,2.6.3+dfsg1-1" | tr ',' '\n' | sort --version-sort >> >> outputs >> >> 2.6.3+dfsg1-1 >> 2.6.3+dfsg-2 > > Debian (dpkg) uses slightly different mechanism for version comparison > than 'sort': > > dpkg --compare-versions 2.6.3+dfsg-2 '<<' 2.6.3+dfsg1-1 && echo LESS > > outputs 'LESS'. > Thank you for pointing this out! I should have referred to the Developer's reference as i have just seen dpkg --compare-versions is presented there. > > Thus AFAIK it is usual for '+dfsg1' to follow '+dfsg'. > Very well then :-) > > Best, > Andrius > Best regards, Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi Pierre, On 2020-09-29 10:54, Pierre Gruet wrote: > Thank you for pointing this out! I should have referred to the > Developer's reference as i have just seen dpkg --compare-versions is > presented there. Glad this helped! This was not immediately evident for me also :) Best, Andrius
[RFS] dcm2niix
gbp clone --pristine-tar https://salsa.debian.org/med-team/dcm2niix OR dcut dm --uid npatra...@gmail.com --allow dcm2niix Thanks and Regards Nilesh
Re: [RFS] dcm2niix
On Tue, Sep 29, 2020 at 06:10:30PM +0530, Nilesh Patra wrote: > dcut dm --uid npatra...@gmail.com --allow dcm2niix Done. Thanks for your work on this, Andreas. -- http://fam-tille.de
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Dear Andreas, On 9/28/20 10:00 PM, Andrei Rozanski wrote: Hi Andreas, On September 28, 2020 21:35:07 Andreas Tille wrote: Hi Andrei, On Mon, Sep 28, 2020 at 09:20:11PM +0200, Andrei Rozanski wrote: Its definitely OK. I do not think whether there is any "good practice" to work around broken upstream Makefiles. this will fail on all other build architectures than amd64 under Linux. May be its sensible to replace it simply by sys.*/ I will look into libsmithwaterman. Thanks! Unfortunately I cannot make it happen. I have been checking d-shlibmove, soname but I cannot put pieces together. I have worked on a few changes. Can you please check if it make sense? https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/patches/fix-makefile-shared-lib.patch Thanks! Best AndreiR Thanks. I will try it out. May be I was not clear enough. Please *ignore* d-shlibmove for the moment. What we need first is a shared library since this is mandatory. If you manage to tweak the build system in a way we can have *.so **and** *.a then (and only then) we might consider d-shlibmove since it requires both kind of libs. I was pointing to libsmithwaterman for binary package names as well as a potential way to create automake stuff in a patch (but that's not required). Sorry if I have dragged you into a to complex dead end street. Kind regards Andreas. -- http://fam-tille.de Best AndreiR
Re: [RFS] hyphy update 2.5.18
Hi Andreas, Andreas Tille, on 2020-09-29 08:48:00 +0200: > On Mon, Sep 28, 2020 at 10:21:04PM +0200, Étienne Mollier wrote: > > namely fix_brace_mismatch.patch. > > In an early version I think I misplaced the missing brace, but > > it did not result in a build error. > > I think having a comment from upstream here would be the best idea. Do > you want to open an issue about this? I remember upstream was very > responsive when I had some contact several years ago. I probably should have had a look at the homepage a bit earlier, I saw this evening that there is a fix[1] that is semantically identical to the one I wrapped up, which is quite reassuring. The patch header is updated accordingly to reflect this is fixed upstream and might make it to the next version. [1] https://github.com/veg/hyphy/pull/1215 > > There are a few things that might be worth highlighting, but > > that would probably be a repetition of the debian/changelog[2]. > > > > [2] https://salsa.debian.org/med-team/hyphy/-/blob/master/debian/changelog > > > > I'm afraid I ended up being a bit short on free time to hunt for > > the extra points with integration of SIMDe, and free a slot in > > Michael's todo list[3], > > Hihi, same idea as I had above. I think if there is no free slot we > should simply upload as is - may be waiting until weekend for a comment > from upstream. I removed the tag for the moment since I made some minor > polishing changes and to remember that the package is not uploaded yet. Okay, I removed the tag on my side as well, before updating the patch metadata, so we should be on par. The existing patch on upstream side seems also to validate the one on our side. > > There are also a few misspelling minor issues > > that might need a wee bit of care. > > Similar here. May be pasting the lintian output into an upstream > issue is the easiest way to deal with this. Good idea, I opened an issue so upstream is aware of them[4]. [4] https://github.com/veg/hyphy/issues/1226 Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: [RFS] hyphy update 2.5.18
Hi Étienne, great. I uploaded as is. Thanks a lot for your work on this package. Kind regards Andreas. PS: In case you feel competent for a Python3.6 -> Python3.8 port you might like to have a look at https://github.com/qiime2/qiime2/issues/520#issuecomment-700809456 Seems upstream is not willing to do such a port right in time for us. :-( On Tue, Sep 29, 2020 at 08:56:50PM +0200, Étienne Mollier wrote: > Hi Andreas, > > Andreas Tille, on 2020-09-29 08:48:00 +0200: > > On Mon, Sep 28, 2020 at 10:21:04PM +0200, Étienne Mollier wrote: > > > namely fix_brace_mismatch.patch. > > > In an early version I think I misplaced the missing brace, but > > > it did not result in a build error. > > > > I think having a comment from upstream here would be the best idea. Do > > you want to open an issue about this? I remember upstream was very > > responsive when I had some contact several years ago. > > I probably should have had a look at the homepage a bit earlier, > I saw this evening that there is a fix[1] that is semantically > identical to the one I wrapped up, which is quite reassuring. > The patch header is updated accordingly to reflect this is fixed > upstream and might make it to the next version. > > [1] https://github.com/veg/hyphy/pull/1215 > > > > There are a few things that might be worth highlighting, but > > > that would probably be a repetition of the debian/changelog[2]. > > > > > > [2] https://salsa.debian.org/med-team/hyphy/-/blob/master/debian/changelog > > > > > > I'm afraid I ended up being a bit short on free time to hunt for > > > the extra points with integration of SIMDe, and free a slot in > > > Michael's todo list[3], > > > > Hihi, same idea as I had above. I think if there is no free slot we > > should simply upload as is - may be waiting until weekend for a comment > > from upstream. I removed the tag for the moment since I made some minor > > polishing changes and to remember that the package is not uploaded yet. > > Okay, I removed the tag on my side as well, before updating the > patch metadata, so we should be on par. The existing patch on > upstream side seems also to validate the one on our side. > > > > There are also a few misspelling minor issues > > > that might need a wee bit of care. > > > > Similar here. May be pasting the lintian output into an upstream > > issue is the easiest way to deal with this. > > Good idea, I opened an issue so upstream is aware of them[4]. > > [4] https://github.com/veg/hyphy/issues/1226 > > Kind Regards, > -- > Étienne Mollier > Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d > New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > Sent from /dev/pts/2, please excuse my verbosity. -- http://fam-tille.de
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Dear Andrei, On Tue, Sep 29, 2020 at 03:31:21PM +0200, Andrei Rozanski wrote: > > > I have worked on a few changes. Can you please check if it make sense? > > https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/patches/fix-makefile-shared-lib.patch I think this makes sense. I added two commits: 1. DEP3 header 2. Actually install the *.so file into the binary package The latter is not the final state. I volunteer to do some d-shlibs patch tomorrow which also involves creating two binary packages: One package libampl-netlib-solvers0 and one libampl-netlib-solvers-dev. But this will not be done today. Meanwhile you might like to read about multiple binary packages - also the libsmithwaterman control file will be a nice reading about this. Kind regards Andreas. -- http://fam-tille.de
