Re: Scythe in Debian Med Git
Hi Kevin, please note that I'm forwarding my answer to the list. I would always advise to send questions like yours to the list since it enhances your chances to get an answer more quickly. Please always remember that Debian Med is a team and not a single person. On Mon, May 11, 2015 at 02:11:41PM +1000, Kevin Murray wrote: To build a Debian package you need a *.orig.tar.gz. *That* is what you should import as pristine-tar. It would be great if you can get this from upstream. If not please provide a get-orig-source target to create such a tarball and import it as pristine-tar. I've added a get-orig-source rule to d/rules, which wgets a tarball using the github API. This tarball is specific to the git SHA hash of upstream's current master, which defined version 0.994 (i.e., will always download the same content, even if upstream's master changes). I hope this is acceptable. As a temporary solution until upstream might be convinced to do proper releases this is OK. It also serves for others as documentation how we obtained the tarball. Do I need to add wget as a build-dependency? And/or use cURL instead? No extra Build-Dependency needed since it is not needed to actually build the package. To the package itself: I did a couple of minor changes and commited these. It would have been more work to describe what you should do than doing it quickly myself. Please check the log thoroughly. There is one remaining issue: You are creating the manpage at build time but the result is quite poor regarding line spacing etc. It also adds a ruby build-dependency. Could you please preprocess the manpage and commit it right to the debian/ dir after checking that the syntax is OK? Kind regards and thanks for your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511061825.ga17...@an3as.eu
Re: Scythe in Debian Med Git
Hi Kevin, thanks for your quick reply. On Mon, May 11, 2015 at 05:26:33PM +1000, Kevin Murray wrote: As a temporary solution until upstream might be convinced to do proper releases this is OK. It also serves for others as documentation how we obtained the tarball. OK, I'll leave it as is until Vince gets back to me about tagging a released version. That's fine. To the package itself: I did a couple of minor changes and commited these. It would have been more work to describe what you should do than doing it quickly myself. Please check the log thoroughly. There is one remaining issue: You are creating the manpage at build time but the result is quite poor regarding line spacing etc. It also adds a ruby build-dependency. Could you please preprocess the manpage and commit it right to the debian/ dir after checking that the syntax is OK? OK, I have made a new and improved d/scythe.1 and removed the ronn-based system (including from build-depends, and d/rules). I'll check this out and will probably upload soon. Is it worth doing something similar with the README.html which we now generate, to avoid a build-dep on python-markdown? The problem was not only the extra build dependency but also the poor result we get from it. So I think it is OK as it is now. Thanks again for your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511073359.gb17...@an3as.eu
Re: [MoM] Re: kmer-tools
Hi, Andreas, On السبت 9 أيار 2015 23:44, Andreas Tille wrote: From my point of view the tests are designed to reproduce expected results. A software should not break if a depencency is upgraded. The later is a totally normal thing and happens all the time. So if you do not have any strong reasons to assume that the newer versions might create any trouble I think this is OK. I was concerned more about potential modifications of the bundled code than the version upgrade alone, but I think you are right in that the test suite should pick up any errors resulting from this. OK, that's a fair point. I recently had this point in the (not yet finished) mugsy package where upstream admitted to have patched the included code copy of mummer version 3.20 while Debian ships mummer 3.23. I did the following: Download mummer version 3.20 from upstream and create a diff from mugsy's code copy. This is basically what I proposed to do before. I applied this diff to Debian's mummer version 3.23 and this is now part of the official Debian package. While I still think the tests should pick up any errors resulting from using a newer, vanilla release, I think the possibility of something like this happening and eventually making its way upstream would be worth doing. So to be sure you can at least check the diff whether kmer upstream has patched the lib to some extend. If there is no diff you are done - if not it might be worth inspecting it more deeply. I will check. Like I said before, while grepping the source I found some signs that this is likely the case. About the shared/static library issue. I looked through the Debian Policy Manual again and came across the section about static libraries (Section 8.3) [1]. The exceptions listed there look like they match this package's situation. Should I just keep the static libraries as they are for early versions of this package? Just for the sake of interest: Which of the three items do apply? I thought the second one and possibly also the third one. The second one because the lack of versioning makes it difficult to say anything about the interface's stability. The third one depends on what upstream would say. In general: While it makes perfectly sense to do the library packaging the proper way (TM) I think we could apply some pragmatism here and see what approach will be the more direct way to a usable package without any practical constraints. So if you think static libraries are OK - at least for the moment - I have no problem if you do so. I think so. I'm hoping upstream will cooperate if he sees there is an upload to the official archive. I didn't get to work on the package today, but I just need to take care of the manpages as discussed before. Regards, Afif 1. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55505a71.2050...@ghraoui.name
Re: Scythe in Debian Med Git
Hi Andreas, On 08:18 11/05, Andreas Tille wrote: Hi Kevin, please note that I'm forwarding my answer to the list. I would always advise to send questions like yours to the list since it enhances your chances to get an answer more quickly. Please always remember that Debian Med is a team and not a single person. Apologies, I absent-mindedly replied to you personally again. I'll endeavour to group-reply in future. snip I've added a get-orig-source rule to d/rules, which wgets a tarball using the github API. This tarball is specific to the git SHA hash of upstream's current master, which defined version 0.994 (i.e., will always download the same content, even if upstream's master changes). I hope this is acceptable. As a temporary solution until upstream might be convinced to do proper releases this is OK. It also serves for others as documentation how we obtained the tarball. OK, I'll leave it as is until Vince gets back to me about tagging a released version. snip To the package itself: I did a couple of minor changes and commited these. It would have been more work to describe what you should do than doing it quickly myself. Please check the log thoroughly. There is one remaining issue: You are creating the manpage at build time but the result is quite poor regarding line spacing etc. It also adds a ruby build-dependency. Could you please preprocess the manpage and commit it right to the debian/ dir after checking that the syntax is OK? OK, I have made a new and improved d/scythe.1 and removed the ronn-based system (including from build-depends, and d/rules). Is it worth doing something similar with the README.html which we now generate, to avoid a build-dep on python-markdown? Cheers, Kevin --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511072633.ga2...@klaptop.kdmurray.id.au
Re: [MoM] Re: kmer-tools
On Mon, May 11, 2015 at 12:29:53AM -0700, Afif Elghraoui wrote: OK, that's a fair point. I recently had this point in the (not yet finished) mugsy package where upstream admitted to have patched the included code copy of mummer version 3.20 while Debian ships mummer 3.23. I did the following: Download mummer version 3.20 from upstream and create a diff from mugsy's code copy. This is basically what I proposed to do before. Fine. I might need to read more thoroughly than. I applied this diff to Debian's mummer version 3.23 and this is now part of the official Debian package. While I still think the tests should pick up any errors resulting from using a newer, vanilla release, I think the possibility of something like this happening and eventually making its way upstream would be worth doing. So to be sure you can at least check the diff whether kmer upstream has patched the lib to some extend. If there is no diff you are done - if not it might be worth inspecting it more deeply. I will check. Like I said before, while grepping the source I found some signs that this is likely the case. OK, feel free to discuss the diff here in case you might be in doubt. In general: While it makes perfectly sense to do the library packaging the proper way (TM) I think we could apply some pragmatism here and see what approach will be the more direct way to a usable package without any practical constraints. So if you think static libraries are OK - at least for the moment - I have no problem if you do so. I think so. I'm hoping upstream will cooperate if he sees there is an upload to the official archive. I didn't get to work on the package today, but I just need to take care of the manpages as discussed before. Just take your time and thanks for your thorough work on this. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511074717.gc17...@an3as.eu
Re: Debian Package for kmer
Hi-
Nice list.
This project is a container for a set of useful (to our group) tools
developed over the years. The intent was to release the more useful ones
individually -- as was done for leaff/sim4db -- but the time and/or support
was never quite there. The wiki page
http://kmer.sourceforge.net/wiki/index.php?Main_Page lists the most useful
tools. Unfortunately, there is also a lot of crap in there that shouldn't
be installed.
I can probably package up those tools -- ESTmapper, ATAC, and meryl --
without too much trouble. The meryl package will be the same bits that are
included in wgs-assembler/kmer now. Looking at what is built now, there
will still be some crap left over. wgs-assembler needs only the libraries
and header files. I'll drop a line when this gets done.
seagen/seatac are components of ESTmapper/ATAC (respectively) that aren't
useful standalone. tapper and trie are two (of many) tools that failed to
pan out.
Unrelated to kmer, wgs-assembler also needs several of the PacBio codes (
https://github.com/PacificBiosciences) to run a specific use case. I don't
have a list of what is required - I've never installed these personally.
Perhaps https://github.com/PacificBiosciences/SMRT-Analysis will capture
everything. That is, at least, their primary analysis suite, if not the
latest bits.
b
On Sun, May 3, 2015 at 10:32 PM, Afif Elghraoui a...@ghraoui.name wrote:
Hello,
I'm contacting you on behalf of the Debian Med team. We are a group within
the Debian project that focuses on packaging software for medicine and
biology, making them easier to install and work with for users of Debian
and its derivatives. Here is a list of biology software that we have
packaged so far: http://blends.debian.org/med/tasks/bio
By way of trying to bring the Celera assembler into Debian, I have taken
up packaging your project Kmer. I just have some questions/requests for you
about issues that have come up.
Firstly, the licensing terms are not explicit in the source distribution
for all components of your project. I only see license terms described for
LEAFF sim4db. Although the sourceforge download page says GPLv2, We would
feel more comfortable with an indication of this in the source distribution
itself.
I also see that you offer the code only as subversion snapshots. Our
packaging system works best with compressed tar archives
(tar.{gz,bz2,lzma,xz}) and versioned releases. We would also like to avoid
packaging a snapshot in the middle of partial development. What I have been
working with so far is the snapshot matching that which was bundled with
the latest version of wgs-assembler.
Finally, although not all components of kmer are used in wgs-assembler, I
thought it would be good to include them all. I noticed, however, that
there are some directories in your distribution that are not explained. I
do not know the roles of some of these subcomponents. These are seagen,
seatac, tapper, and trie. If you could please explain these, that would
help me with creating their manpages.
The Debian project has a guide for upstream developers [1] that explains
further some of these issues, but I have explained my main issues in this
message. I'm sorry about its being a bit long.
Many thanks and regards,
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
1. https://wiki.debian.org/UpstreamGuide
Humble RFP RPostgreSQL
Dear Debian Med folks, I am packaging hedgehog (tool for a DNS data modeling) and one of it's requirements is RPostgreSQL that's not yet packaged. I could probably quickly cook something up, but I thought I ask first here whether I find some poor soul that would do that since I guess the result will be in much better shape if done by anybody with the right skill. So what do you say? Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431354102.1477422.265649265.42add...@webmail.messagingengine.com
Re: Humble RFP RPostgreSQL
Hi Ondřej, On Mon, May 11, 2015 at 04:21:42PM +0200, Ondřej Surý wrote: Dear Debian Med folks, I am packaging hedgehog (tool for a DNS data modeling) and one of it's requirements is RPostgreSQL that's not yet packaged. Could you please provide any link? While as a German native speaker I could assume that with DNS you don't mean Domain Name Service but rather the English DNA I would like to be sure about this. I would invite you to package any DNA related stuff in Debian Med team. I could probably quickly cook something up, but I thought I ask first here whether I find some poor soul that would do that since I guess the result will be in much better shape if done by anybody with the right skill. So what do you say? At first I say that I'm impressed about the trust you have in our group. ;-) There are people who are not that happy about the fact that we try to pick a lot of CRAN packages. In principle these are simple but we only take what we consider as preconditions for packages in our workfield. So if hedgehog is a DNA tool we'd gladly help you to maintain both in Debian Med VCS. Otherwise we could serve with several useful examples which will bring you (hopefully) quickly on track. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511143737.gh17...@an3as.eu
Re: sponsor upload aghermann-1.0.4 please?
Hi Andreas, As my trusty sponsor Yaroslav seems to have been preoccupied by other matters since some weeks ago, could you please stand in his stead and push the button for my package? There's a fix for some unfortunate regression on GTK3's part which screws the font sizes (they were rendered at 1pt), and it makes me feel for those 20-ish users who did install it. The link to the .dsc file is below: Using this opportunity, I would like to ever so slightly poke Yaroslav to push the upload button on my own package, aghermann, where I fix a FTBFS with gcc-5 to close #69 (http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.0.4-1.dsc). Cheers, Andrei -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512005002.0ecdadc9@ra
Re: Humble RFP RPostgreSQL
Hi Andreas, On Mon, May 11, 2015, at 16:37, Andreas Tille wrote: Hi Ondřej, On Mon, May 11, 2015 at 04:21:42PM +0200, Ondřej Surý wrote: Dear Debian Med folks, I am packaging hedgehog (tool for a DNS data modeling) and one of it's requirements is RPostgreSQL that's not yet packaged. Could you please provide any link? While as a German native speaker I could assume that with DNS you don't mean Domain Name Service but I do mean Domain Name System :) - hedgehog is located here: - http://dns-stats.org/ - https://github.com/dns-stats/hedgehog rather the English DNA I would like to be sure about this. I would invite you to package any DNA related stuff in Debian Med team. I could probably quickly cook something up, but I thought I ask first here whether I find some poor soul that would do that since I guess the result will be in much better shape if done by anybody with the right skill. So what do you say? At first I say that I'm impressed about the trust you have in our group. ;-) There are people who are not that happy about the fact that we try to pick a lot of CRAN packages. In principle these are simple but we only take what we consider as preconditions for packages in our workfield. So if hedgehog is a DNA tool we'd gladly help you to maintain both in Debian Med VCS. Otherwise we could serve with several useful examples which will bring you (hopefully) quickly on track. If that's inevitable :), I would still very much prefer if team of packagers would take care of this package... But as we spoke, I packaged this under collab-maint as r-cran-rpostgresql and the repo is here: git://anonscm.debian.org/collab-maint/r-cran-rpostgresql.git So if anybody could review (or take over :) this it would be appreciated. You can push the fixes directly to the repository, I am not overly protective of my (leaf) packages. Co-maintainers are welcome. Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431363556.1645735.265704321.7e045...@webmail.messagingengine.com
