Re: Odil : getting back into testing

[Steffen Möller]

For these "leaf" packages in the tree of package dependencies I agree 
with Michael that we should possibly just "leave" them. Then again, 
someone deeply caring for that architecture should have a chance to 
easily find these packages and address the issue.


On 04.01.19 20:32, Michael Crusoe wrote:
I'm increasingly of the opinion that we should not stretch our limited 
resources even thinner by spending so much time on architectures used 
for network routers where it is unlikely that anyone will want to view 
medical image files.


În vin., 4 ian. 2019 la 18:40, Julien Lamy > a scris:


Hi all,
The latest version of Odil does not build on mips64el [1] and if
I'm not
mistaken, this is the only thing preventing the package to migrate to
testing. By going through the logs, one of the unit tests times
out when
building [2]. Since I don't have access to a real mips64el box, I've
tested building in a Qemu guest and got similar results: the build
also
fails with a timeout, albeit earlier in the process.

I've watched the RAM during the Qemu build ("grep Committed_AS
/proc/meminfo"), and it is getting nowhere the limit at this point of
the build, which makes me think that this is not caused by a RAM
problem. The configuration of the Qemu guest differs from the official
builder due to Qemu limitations (less RAM, non-parallel build), so
this
is not the best test setup, and I'm unsure on how to fix this. The
three
options I've thought of are rather unsatisfactory:

- Don't build the unit tests. Later build steps are however much more
resource-intensive, so this will probably not solve the problem
- Increase the build timeout. Not sure whether asking to
reconfigure the
buildd network for a package with such a low popcon is a good idea :)
- Don't build Odil on mips64el

What would be your advice in this situation ?

[1] https://buildd.debian.org/status/package.php?p=odil=sid
[2] test_webservices_WADORSRequest has a start message ("Building CXX
object"), but no end message ("Built target")

Cheers,
-- 
Julien




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 

Re: What ffindex do we want to package

[Steffen Möller]

Heya, I have replied, at least I had typed it :o/

So, yes, I had chosen that version of ffsort_index to get hhsuite to 
compile. I have no idea if there are other reverse dependencies on 
ffindex, my priority is on hhsuite.


Cheers,

Steffen

On 04.01.19 18:17, Michael Crusoe wrote:
I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent 
FTBFS of hhsuite: https://bugs.debian.org/917495 as our packaged 
version is missing the "ffsort_index" function.


The hh-suite github repo contains a submodule pointing at their fork 
of ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib → 
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac


I suggest that we package it as part of hhsuite until another package 
needs it.


hhsuite does provide  "*-Source*" packages that include ffindex, so we 
wouldn't need a multi-source build.




În joi, 20 dec. 2018 la 11:59, Andreas Tille > a scris:


Ping?
Steffen, if you did not had a specific reason I assume it was by
mistake and will replace the Segfaulting code by the original one.
If I do not hear from you I assume you will agree.
Kind regards, Andreas.

On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> Hi,
>
> after reading
https://github.com/soedinglab/ffindex_soedinglab/issues/4
> I came to the conclusion that we somehow picked the wrong fork of
> ffindex.  For me it seems very probable that if we pick the old
codebase
> bug #907624 which was introduced when choosing this will vanish
if we
> revert to the previously packaged code base.  I have a local commit
> which is doing this:
>
>
> diff --git a/debian/changelog b/debian/changelog
> index 6a26115..c409f4f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED;
urgency=medium
> +
> +  * The previous location on Github was an improperly choosen fork
> +    (see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> +    Here the version is now named "0.9.9.7+sog" (Saved On Github)
> +    to make it alphabethically later than the previous one.
> +
> + -- Andreas Tille mailto:ti...@debian.org>>
Wed, 19 Dec 2018 09:16:09 +0100
> +
>  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
urgency=medium
>
>    * Fix watch file (version should actually be
+git20171201.74550c8 but
> diff --git a/debian/watch b/debian/watch
> index 91b4f38..b47f123 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
>
> -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> - https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> + https://github.com/ahcm/ffindex.git HEAD
>
>
>
> Upstream at github.com/ahcm/ffindex
 was extremely quick to tag a
> release and so it is at least active.
>
> Steffen, was your pick intentional or did you just stumbled by
chance
> over the other fork?  Are you OK with reverting to the old code?
>
> Kind regards
>
>       Andreas.
>
> PS: I reported the segfault issue to the according fork anyway
> https://github.com/soedinglab/ffindex_soedinglab/issues/7
>
>
> --
> http://fam-tille.de
>
>

-- 
http://fam-tille.de




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 
+1 480 627 9108 / +370 653 11125

Re: What ffindex do we want to package

[Andreas Tille]

On Fri, Jan 04, 2019 at 07:17:24PM +0200, Michael Crusoe wrote:
> I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent FTBFS
> of hhsuite: https://bugs.debian.org/917495 as our packaged version is
> missing the "ffsort_index" function.
> 
> The hh-suite github repo contains a submodule pointing at their fork of
> ffindex at ~ 2017-06-01:
> https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib  →
> https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac
> 
> I suggest that we package it as part of hhsuite until another package needs
> it.
> 
> hhsuite does provide  "*-Source*" packages that include ffindex, so we
> wouldn't need a multi-source build.

By any means just do something sensible.  I'm way to less educated about
this software and just got my fingers dirty with it since nobody else
cared about the (other!) bugs.
 
Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Odil : getting back into testing

[Michael Crusoe]

I'm increasingly of the opinion that we should not stretch our limited
resources even thinner by spending so much time on architectures used for
network routers where it is unlikely that anyone will want to view medical
image files.

În vin., 4 ian. 2019 la 18:40, Julien Lamy  a scris:

> Hi all,
> The latest version of Odil does not build on mips64el [1] and if I'm not
> mistaken, this is the only thing preventing the package to migrate to
> testing. By going through the logs, one of the unit tests times out when
> building [2]. Since I don't have access to a real mips64el box, I've
> tested building in a Qemu guest and got similar results: the build also
> fails with a timeout, albeit earlier in the process.
>
> I've watched the RAM during the Qemu build ("grep Committed_AS
> /proc/meminfo"), and it is getting nowhere the limit at this point of
> the build, which makes me think that this is not caused by a RAM
> problem. The configuration of the Qemu guest differs from the official
> builder due to Qemu limitations (less RAM, non-parallel build), so this
> is not the best test setup, and I'm unsure on how to fix this. The three
> options I've thought of are rather unsatisfactory:
>
> - Don't build the unit tests. Later build steps are however much more
> resource-intensive, so this will probably not solve the problem
> - Increase the build timeout. Not sure whether asking to reconfigure the
> buildd network for a package with such a low popcon is a good idea :)
> - Don't build Odil on mips64el
>
> What would be your advice in this situation ?
>
> [1] https://buildd.debian.org/status/package.php?p=odil=sid
> [2] test_webservices_WADORSRequest has a start message ("Building CXX
> object"), but no end message ("Built target")
>
> Cheers,
> --
> Julien
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org

Bug#918251: d-shlibs: devlibs error: There is no package matching [libsvm3-dev] and noone provides it

[Michael R. Crusoe]

Package: d-shlibs
Version: 0.83
Severity: normal

Dear Maintainer,

While fixing the missing linkage to libsvm in libpsortb I received the
following message:

devlibs error: There is no package matching [libsvm3-dev] and noone provides
it, please report bug to d-shlibs maintainer

So here I am :-)

d-shlibmove --commit \
--multiarch \
--devunversioned \
--exclude-la \
debian/tmp/usr/lib/*/libsvmloc.so
Library package automatic movement utility
devlibs error: There is no package matching [libsvm3-dev] and noone provides 
it, please report bug to d-shlibs maintainer 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8), 
LANGUAGE=ro_RO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages d-shlibs depends on:
ii  apt   1.8.0~alpha3
ii  binutils  2.31.1-11

d-shlibs recommends no packages.

d-shlibs suggests no packages.

-- no debconf information

Re: Hmmer2 fork / enhancements (Was: Is my post making it to the mailing list?)

[Joshua Marshall]

PVM is no longer maintained, and hasn't been for quite some time.  The use
case for when PVM is relevant is when RAM on individual machines was closer
to 16M.  Given that we have $5 computers with 256MB, I find it reasonable
to tell such users to upgrade.

As for interpro-scan, most of the documents got updated for the project and
it is easier to set up locally.  However, there is still a large amount of
work that goes into updates every few days to a few weeks and users should
rely on the service rather than a package.  If you do want to have the
package, you need a employee charged with it's regular updates and
development because of how involved and federated that particular program
set is.

On Fri, Jan 4, 2019 at 10:41 AM Steffen Möller 
wrote:

> Hello Joshua,
>
> I would be much of a fan to see interpro-scan redistributed with Debian.
> Andreas' concern is that nobody understands what happened. We have
> Hammer2 in our distribution https://packages.debian.org/sid/hmmer2 and
> if your work is plain compatible then I don't see why it should not
> substitute it.  Is there a way to keep hmmer2-pvm? There are not too
> many on https://qa.debian.org/popcon.php?package=hmmer2 using it but I
> would not want to ruin established services anywhere with an apt-get
> update.
>
> Best,
>
> Steffen
>
> On 04.01.19 16:25, Joshua Marshall wrote:
> > Hello all,
> >
> > In Spring 2018 I was working on packaging interpro-scan for some
> > work.  There were a number of packages which has some build or test
> > failures which I worked on.  Of these, Hmmer needed some more
> > attention.  Originally, this was an upstream request to tweak their
> > autoconf but that went bizarrely bad. At that point, I went in to fix
> > up a decade's worth of technical debt.  Of these were removal of
> > Parallel Virtual Machine support, adjusting buffer sizes upwards for
> > memory found on modern systems, hard code enabling of pthreads,
> > renaming executable to hmmer2 in the build to not conflict with hmmer
> > or hmmer3 to allow for parallel installation, and simplification of
> > the configuration header.  All unit tests pass.  There is a need for
> > parallel installation of hmmer2 and hmmer3 because hmmer2 works on a
> > global genome scale, while hmmer3 is build to only operate on parts of
> > the genome.
> >
> > This should have do change in behavior or output in any way except for
> > removal of PVM support and minor runtime changes. This change set
> > should be viewed strictly as a technical debt clean up.
> >
> > On Fri, Jan 4, 2019 at 1:11 AM Andreas Tille  > > wrote:
> >
> > Hi Joshua,
> >
> > On Thu, Jan 03, 2019 at 04:45:33PM -0500, Joshua Marshall wrote:
> > > Is now a better time to bring up my Hmmer 2 fork?
> >
> > Please shortly describe the purpose of your fork the changes you
> > did on the list and than we can (probably/hopefully) replace the
> > existing hmmer2 package by your fork.  I'm *not* a hmmer2 user
> > (nor do I have the slightest idea what hmmer2 is doing - I'm not
> > a biologist) so it makes no sense to discuss this just with me.
> > Thus I'm posting this on the list.
> >
> > For other readers here are some links to previous posts about
> > this issue:
> >
> >
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066203.html
> >
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066757.html
> >
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066762.html
> >
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-November/066997.html
> >
> > My prefered way to deal with this would be to point the debian/watch
> > file of hmmer2 to
> >
> > https://github.com/anadon/hmmer2/releases
> >
> > and package the latest release from there (instead of applying huge
> > patches that nobody can read or maintain) but please document the
> > relation to the official hmmer2, your fork/continuation and hmmer3
> > at an easily accessible place.
> >
> > Kind regards
> >
> > Andreas.
> >
> > > On Sun, Oct 28, 2018 at 4:47 PM jrmarsha  > > wrote:
> > >
> > > > I'm sorry.
> > > >
> > > > On 10/28/18 4:15 PM, Andreas Tille wrote:
> > > > > Hi,
> > > > >
> > > > > the list is archived:
> > > > >
> > > > > https://lists.debian.org/debian-med/2018/10/threads.html
> > > > >
> > > > > Please do not expect always prompt responses - sometimes
> > volunteers
> > > > > have other things to do.
> > > > >
> > > > > Kind regards
> > > > >
> > > > > Andreas.
> > > > >
> > > > > On Sun, Oct 28, 2018 at 09:03:27AM -0400, jrmarsha wrote:
> > > > >> Hello,
> > > > >>
> > > > >>
> > > > >> I've tried sending a few messages but I've gotten no
> > response. Are they
> > > > >> making it to the 

Re: What ffindex do we want to package

[Michael Crusoe]

I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent FTBFS
of hhsuite: https://bugs.debian.org/917495 as our packaged version is
missing the "ffsort_index" function.

The hh-suite github repo contains a submodule pointing at their fork of
ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib  →
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac

I suggest that we package it as part of hhsuite until another package needs
it.

hhsuite does provide  "*-Source*" packages that include ffindex, so we
wouldn't need a multi-source build.



În joi, 20 dec. 2018 la 11:59, Andreas Tille  a scris:

> Ping?
> Steffen, if you did not had a specific reason I assume it was by
> mistake and will replace the Segfaulting code by the original one.
> If I do not hear from you I assume you will agree.
> Kind regards, Andreas.
>
> On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> > Hi,
> >
> > after reading https://github.com/soedinglab/ffindex_soedinglab/issues/4
> > I came to the conclusion that we somehow picked the wrong fork of
> > ffindex.  For me it seems very probable that if we pick the old codebase
> > bug #907624 which was introduced when choosing this will vanish if we
> > revert to the previously packaged code base.  I have a local commit
> > which is doing this:
> >
> >
> > diff --git a/debian/changelog b/debian/changelog
> > index 6a26115..c409f4f 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,12 @@
> > +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED; urgency=medium
> > +
> > +  * The previous location on Github was an improperly choosen fork
> > +(see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> > +Here the version is now named "0.9.9.7+sog" (Saved On Github)
> > +to make it alphabethically later than the previous one.
> > +
> > + -- Andreas Tille   Wed, 19 Dec 2018 09:16:09 +0100
> > +
> >  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
> urgency=medium
> >
> >* Fix watch file (version should actually be +git20171201.74550c8 but
> > diff --git a/debian/watch b/debian/watch
> > index 91b4f38..b47f123 100644
> > --- a/debian/watch
> > +++ b/debian/watch
> > @@ -1,4 +1,4 @@
> >  version=4
> >
> > -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> > -https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> > +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> > +https://github.com/ahcm/ffindex.git HEAD
> >
> >
> >
> > Upstream at github.com/ahcm/ffindex was extremely quick to tag a
> > release and so it is at least active.
> >
> > Steffen, was your pick intentional or did you just stumbled by chance
> > over the other fork?  Are you OK with reverting to the old code?
> >
> > Kind regards
> >
> >   Andreas.
> >
> > PS: I reported the segfault issue to the according fork anyway
> > https://github.com/soedinglab/ffindex_soedinglab/issues/7
> >
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108 / +370 653 11125

Odil : getting back into testing

[Julien Lamy]

Hi all,
The latest version of Odil does not build on mips64el [1] and if I'm not
mistaken, this is the only thing preventing the package to migrate to
testing. By going through the logs, one of the unit tests times out when
building [2]. Since I don't have access to a real mips64el box, I've
tested building in a Qemu guest and got similar results: the build also
fails with a timeout, albeit earlier in the process.

I've watched the RAM during the Qemu build ("grep Committed_AS
/proc/meminfo"), and it is getting nowhere the limit at this point of
the build, which makes me think that this is not caused by a RAM
problem. The configuration of the Qemu guest differs from the official
builder due to Qemu limitations (less RAM, non-parallel build), so this
is not the best test setup, and I'm unsure on how to fix this. The three
options I've thought of are rather unsatisfactory:

- Don't build the unit tests. Later build steps are however much more
resource-intensive, so this will probably not solve the problem
- Increase the build timeout. Not sure whether asking to reconfigure the
buildd network for a package with such a low popcon is a good idea :)
- Don't build Odil on mips64el

What would be your advice in this situation ?

[1] https://buildd.debian.org/status/package.php?p=odil=sid
[2] test_webservices_WADORSRequest has a start message ("Building CXX
object"), but no end message ("Built target")

Cheers,
-- 
Julien



signature.asc
Description: OpenPGP digital signature

Re: Hmmer2 fork / enhancements (Was: Is my post making it to the mailing list?)

[Steffen Möller]

Hello Joshua,

I would be much of a fan to see interpro-scan redistributed with Debian. 
Andreas' concern is that nobody understands what happened. We have 
Hammer2 in our distribution https://packages.debian.org/sid/hmmer2 and 
if your work is plain compatible then I don't see why it should not 
substitute it.  Is there a way to keep hmmer2-pvm? There are not too 
many on https://qa.debian.org/popcon.php?package=hmmer2 using it but I 
would not want to ruin established services anywhere with an apt-get update.


Best,

Steffen

On 04.01.19 16:25, Joshua Marshall wrote:

Hello all,

In Spring 2018 I was working on packaging interpro-scan for some 
work.  There were a number of packages which has some build or test 
failures which I worked on.  Of these, Hmmer needed some more 
attention.  Originally, this was an upstream request to tweak their 
autoconf but that went bizarrely bad. At that point, I went in to fix 
up a decade's worth of technical debt.  Of these were removal of 
Parallel Virtual Machine support, adjusting buffer sizes upwards for 
memory found on modern systems, hard code enabling of pthreads, 
renaming executable to hmmer2 in the build to not conflict with hmmer 
or hmmer3 to allow for parallel installation, and simplification of 
the configuration header.  All unit tests pass.  There is a need for 
parallel installation of hmmer2 and hmmer3 because hmmer2 works on a 
global genome scale, while hmmer3 is build to only operate on parts of 
the genome.


This should have do change in behavior or output in any way except for 
removal of PVM support and minor runtime changes. This change set 
should be viewed strictly as a technical debt clean up.


On Fri, Jan 4, 2019 at 1:11 AM Andreas Tille > wrote:


Hi Joshua,

On Thu, Jan 03, 2019 at 04:45:33PM -0500, Joshua Marshall wrote:
> Is now a better time to bring up my Hmmer 2 fork?

Please shortly describe the purpose of your fork the changes you
did on the list and than we can (probably/hopefully) replace the
existing hmmer2 package by your fork.  I'm *not* a hmmer2 user
(nor do I have the slightest idea what hmmer2 is doing - I'm not
a biologist) so it makes no sense to discuss this just with me.
Thus I'm posting this on the list.

For other readers here are some links to previous posts about
this issue:


https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066203.html

https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066757.html

https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066762.html

https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-November/066997.html

My prefered way to deal with this would be to point the debian/watch
file of hmmer2 to

https://github.com/anadon/hmmer2/releases

and package the latest release from there (instead of applying huge
patches that nobody can read or maintain) but please document the
relation to the official hmmer2, your fork/continuation and hmmer3
at an easily accessible place.

Kind regards

        Andreas.

> On Sun, Oct 28, 2018 at 4:47 PM jrmarsha mailto:jrmar...@mtu.edu>> wrote:
>
> > I'm sorry.
> >
> > On 10/28/18 4:15 PM, Andreas Tille wrote:
> > > Hi,
> > >
> > > the list is archived:
> > >
> > > https://lists.debian.org/debian-med/2018/10/threads.html
> > >
> > > Please do not expect always prompt responses - sometimes
volunteers
> > > have other things to do.
> > >
> > > Kind regards
> > >
> > >         Andreas.
> > >
> > > On Sun, Oct 28, 2018 at 09:03:27AM -0400, jrmarsha wrote:
> > >> Hello,
> > >>
> > >>
> > >> I've tried sending a few messages but I've gotten no
response. Are they
> > >> making it to the debian-med mailing list.
> > >>
> > >>
> >

-- 
http://fam-tille.de

Re: Hmmer2 fork / enhancements (Was: Is my post making it to the mailing list?)

[Joshua Marshall]

Hello all,

In Spring 2018 I was working on packaging interpro-scan for some work.
There were a number of packages which has some build or test failures which
I worked on.  Of these, Hmmer needed some more attention.  Originally, this
was an upstream request to tweak their autoconf but that went bizarrely
bad.  At that point, I went in to fix up a decade's worth of technical
debt.  Of these were removal of Parallel Virtual Machine support, adjusting
buffer sizes upwards for memory found on modern systems, hard code enabling
of pthreads, renaming executable to hmmer2 in the build to not conflict
with hmmer or hmmer3 to allow for parallel installation, and simplification
of the configuration header.  All unit tests pass.  There is a need for
parallel installation of hmmer2 and hmmer3 because hmmer2 works on a global
genome scale, while hmmer3 is build to only operate on parts of the genome.

This should have do change in behavior or output in any way except for
removal of PVM support and minor runtime changes.  This change set should
be viewed strictly as a technical debt clean up.

On Fri, Jan 4, 2019 at 1:11 AM Andreas Tille  wrote:

> Hi Joshua,
>
> On Thu, Jan 03, 2019 at 04:45:33PM -0500, Joshua Marshall wrote:
> > Is now a better time to bring up my Hmmer 2 fork?
>
> Please shortly describe the purpose of your fork the changes you
> did on the list and than we can (probably/hopefully) replace the
> existing hmmer2 package by your fork.  I'm *not* a hmmer2 user
> (nor do I have the slightest idea what hmmer2 is doing - I'm not
> a biologist) so it makes no sense to discuss this just with me.
> Thus I'm posting this on the list.
>
> For other readers here are some links to previous posts about
> this issue:
>
>
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066203.html
>
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066757.html
>
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-October/066762.html
>
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-November/066997.html
>
> My prefered way to deal with this would be to point the debian/watch
> file of hmmer2 to
>
>   https://github.com/anadon/hmmer2/releases
>
> and package the latest release from there (instead of applying huge
> patches that nobody can read or maintain) but please document the
> relation to the official hmmer2, your fork/continuation and hmmer3
> at an easily accessible place.
>
> Kind regards
>
> Andreas.
>
> > On Sun, Oct 28, 2018 at 4:47 PM jrmarsha  wrote:
> >
> > > I'm sorry.
> > >
> > > On 10/28/18 4:15 PM, Andreas Tille wrote:
> > > > Hi,
> > > >
> > > > the list is archived:
> > > >
> > > >  https://lists.debian.org/debian-med/2018/10/threads.html
> > > >
> > > > Please do not expect always prompt responses - sometimes volunteers
> > > > have other things to do.
> > > >
> > > > Kind regards
> > > >
> > > > Andreas.
> > > >
> > > > On Sun, Oct 28, 2018 at 09:03:27AM -0400, jrmarsha wrote:
> > > >> Hello,
> > > >>
> > > >>
> > > >> I've tried sending a few messages but I've gotten no response. Are
> they
> > > >> making it to the debian-med mailing list.
> > > >>
> > > >>
> > >
>
> --
> http://fam-tille.de
>