[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Re: kmer-tools



Hi, Andreas,

On السبت  9 أيار 2015 08:51, Andreas Tille wrote:
Hi Afif,

On Sat, May 09, 2015 at 03:34:22AM -0700, Afif Elghraoui wrote:
- Remove convenience copies of packaged dependencies (via
get-orig-source) and modify the build system (using quilt patches)
to use existing Debian packages for them

The other dependency seems to be a strange
case. It is mt19937ar[1] (I'm not 100% if this is the correct link,
but I believe it is), which I thought was in Debian as the package
libghc-mersenne-random-dev [2], but that looks to be a different
implementation. I still need to look into this more, but if you know
anything offhand about this kind of situation, that would help speed
things up for me. In the kmer upstream source, it is the directory
libutil/mt19937ar.

If you need help on this please state explicitly.  Otherwise I'd wait
for further reports of yours, OK?


Yes, I need help. I've done some more reading and the situation is that:

- upstream uses an apparently modified version of the random number generator mt19937ar [1] - The developers of mt19937ar have a whole suite of implementations [2-3], and only some of them appear to be in Debian. - mt19937ar is apparently not one of those versions that are in debian, but given that it is modified anyway, I'm not sure what should be done.

Should I just leave the included copy in there?



For kazlib, I have a slight concern. The version in Debian is newer than what was bundled in the source (not by much: it looks like 1.21 vs 1.20), but I have seen while grepping the kmer source comments like "My hacked kazlib returns pointers". Should I rely on the package's tests to pick up and potential problems resulting from this?

I suppose this is one of those cases where it helps to have a responsive upstream developer. But I suppose I can also compare the bundled version with kazlib upstream's v1.20 and see if there really are changes and, if so, whether those have been included in v1.21.

Also, for quilt, I saw in the group policy to add some rules for quilt:

include /usr/share/quilt/quilt.make

Uhhhh, oooooh, nooo.  Thanks for pointing this up.  I deleted the
deprecated part from policy.  If you use debian/source/format
3.0 (quilt) this is not needed or rather should not be used at all.

Am I supposed to add quilt as a build-dependency?

Definitely not.  Sorry for misguiding you by outdated text.


It's no problem.


In any case I have added kmer and libkmer-dev to the bio and the bio-dev
task respectively.


Thanks. I have created the ITP [4] and somehow managed to mess it up. I inadvertently left out the X-Debbugs-Cc (?) field when copying the text into an email and so debian-devel and debian-med got left out of the recipients. I haven't yet looked into how to fix this besides just forwarding the email to these two lists.


Regards,
Afif

1. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html
2. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
3. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/eversions.html
4. bugs.debian.org/784863

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


Reply to: