Hi, Afif-

I (finally) added downloads for meryl and some others.  They're linked from
the kmer homepage http://kmer.sourceforge.net/

Documentation remains weak, and might improve in the next few months as we
close out a few projects.

You only need the meryl package:
http://sourceforge.net/projects/kmer/files/meryl-r2008.tar.bz2/download

b





On Wed, May 20, 2015 at 2:03 AM, Afif Elghraoui <a...@ghraoui.name> wrote:

> Thanks for your reply. Please see inline:
>
> On الثلاثاء 19 أيار 2015 07:15, Brian Walenz wrote:
>
>> I'm a little slow on packaging up a release, sorry.  It's on the to do
>> list with a decent priority, but not getting much time yet.  The paying
>> projects are being unruly.
>>
>>
> No problem.
>
>   From the kmer repo, I've created four releases by removing select top
>> level directories.  For 'meryl' the directories are:
>>
>> Make.include
>> Make.rules
>> Makefile
>> README.compiling
>> README.meryl
>> configure.sh
>> libbio
>> libkmer
>> libmeryl
>> libseq
>> libutil
>> meryl
>>
>>
> Thanks; this is very helpful. README.meryl is not on sourceforge, though.
> At least not that I saw.
>
>
>  No changes to Make* are needed.  This is the package needed for
>> wgs-assembler.  The other three are for ATAC, ESTmapper and sim4db
>> (which exists already).
>>
>> I've wanted to get rid of kazlib for a long time, and I think it is only
>> used by the atac package.  Before you expend too much effort on
>> modifications, lets see if the meryl component will compile without it.
>>
>
> I can verify that it does.
>
>  IIRC, it's used only in class 'bigQueue' in libutil.  I wanted to
>> replace it with STL, but last time I looked, it wasn't a drop-in
>> replacement.
>>
>> The test suite(s) are probably quite low level, and not very good.  A
>> functional test should find any major problems.  I can't think of any
>> gotchas for reviving the tests though.
>>
>>
> Ok, so I guess I'm all clear for tackling that.
>
> I'd like to lay out the full status, even though some of these items are
> not for the short-term. The short-term package looks like it will just
> provide meryl so that we can climb the dependency chain to wgs-assembler
> and other packages that use it. The rest of the code requires a little
> clean-up as I understood from you.
>
> * Short-term plan for first version of the package -- meryl only
> I can put this through on my own without additional action from your side
> (but the README.meryl file would be nice to have). I would work on the
> following:
>   - build shared libraries rather than (or in addition to) static, as
> preferred for official Debian packages [1]. If you think this isn't a good
> idea, there is potentially some flexibility here.
>   - create man pages for executables
>
> * longer-term plan -- remaining components + general improvements
> This part can wait until you complete the clean-up you mentioned in your
> first message. The steps here for me are:
>   - include the remaining components and, same as for meryl, make shared
> libraries and man pages
>   - You have a copy of mt19937ar in your distribution, which as of now is
> not packaged in Debian. I haven't checked to see if you patched this code
> or if it's an unmodified copy. At some point, mt19937ar would need to be a
> in a separate Debian package that kmer would just depend on.
>   - fix test suite. I will also see how well this goes for meryl. If it
> doesn't take too long, I can have it be part of the package-build process.
>
>
> Thanks and regards
> Afif
>
> 1. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>
> --
> Afif Elghraoui | عفيف الغراوي
> http://afif.ghraoui.name
>

Reply via email to