<div dir="ltr"><div>Hello all,<br><br></div>Can I get a firm stance on this?<br><div><div><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Fabian,<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13.04.2018 19:47, Joshua Marshall wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmmer2 upstream is listed at 2.4i<br>
</blockquote>
The current version of hmmer2 in Debian is 2.3.2+dfsg-5, see [1].<br>
Judging from the official homepage of Hmmer [2] that is indeed the<br>
latest release.<br>
</blockquote></span>
Not so.  If you check the github repo tags, or the bottom of <a href="http://hmmer.org/download.html" rel="noreferrer" target="_blank">http://hmmer.org/download.html</a> it is at 2.4i.  I tried dealing with upstream, but something is wrong with the guy (a less than fun email chain my office gives me sympathies for).<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a few cleanups and fixes […] fix a few uninitialized variables<br>
</blockquote>
Most of these look minor, if not even superfluous [4, 5].<br>
</blockquote></span>
They are minor, but still probably fix a few stability issues mentioned in some of the logs -- mainly through initializing uninitialized variables.  However, there was a setting on when to switch from a faster to a slower algorithm that happened at 32MB which I upped to 1GB.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
which enable pthreads by default, remove support for PVM<br>
</blockquote>
Could you please go into detail, why you think this change is<br>
necessary/an improvement?<br>
</blockquote></span>
Right!  So there was pthread support baked in, but seemed to be a somewhat hidden option in the version 2 series of the program. Everything tests fine, but development of version two was largely abandoned before pthreads predominated the free development space as they do today.  In terms of PVM, it is no longer supported or maintained or even for this domain useful anymore.  It made sense when memory was extremely constrained so you could have one program use the memory space of several machines.  That isn't a problem with any current data set -- even the biggest plant genomes.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
adding a default suffix of '2'<br>
</blockquote>
Debian already does that, I think [3]. And if not, renaming binaries<br>
between two releases of a package will break existing workflows and<br>
confuse a lot of users.<br>
</blockquote></span>
Debian does do it, but when I was going back and forth with mschu over with the arch packages [1] it was a pain and there was no built in way for lone sys-admins to just do it.  Speaking of which, hmmer version 3 should be appended with a '3' soon because version 4 is going to be released eventually and I'm not sure it is going to be strictly compatible.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So with that, I'd like to make the request to update to 2.5j.  Humor me<br>
if something with this is incorrect.  I think all guidelines are being<br>
met for posting.<br>
<br>
</blockquote>
There are basically two ways to incorporate your changes into Debian. 1)<br>
We could declare upstream as dead (even though they are not) and use<br>
your repository as the "new official version". 2) We pile your changes<br>
on top of the last public release 2.3.2. For this we require small patch<br>
files each implementing one of the fixes you mentioned above. Having<br>
just one big commit (your words) is problematic.<br>
<br>
My favourite solution would be 2). I am looking forward to receiving<br>
your patches.<br>
</blockquote></span>
Once a course of action is settled, I'll be happy to generate them.<br>
<br>
[1] <a href="https://aur.archlinux.org/packages/hmmer2/" rel="noreferrer" target="_blank">https://aur.archlinux.org/pack<wbr>ages/hmmer2/</a><br>
</blockquote></div><br></div></div></div></div></div>