Help needed to update to latest fastqc
Hi, I tried to upgrade to the latest fasqc version. When doing so I decided to move from SVN to Git: Vcs-Git: git://anonscm.debian.org/debian-med/fastqc.git Upstream needs a new Build-Depends libjhdf5-java which I added. However, I was not able to fix the build. When trying I considered switching from the Makefile based build to ant (which sounds natural) Unfortunately I did not succeeded in adapting build.xml. Any help would be appreciated 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/20150503065422.gh5...@an3as.eu
Re: kmer-tools
Hi Afif, On Sat, May 02, 2015 at 10:53:34PM -0700, Afif Elghraoui wrote: I have checked your last commits and would like to comment on it. You have created several binary packages - withpout checking I'm guessing one per binary in /usr/bin. While this is a possible thing to do I think this is over-engineering and creates a lot of work for you with no practical use. I was starting to think the same thing as I saw that I would have to manage the interdependencies if I kept along this route. My only concern was that some of these packages have quite different functions. I suspect they are only distributed together because they share some dependencies and are written by the same developer. Well, if you have strong reasons like these I will not stop you from modularising the packaging. If there are good chances that users might want to use only parts of kmer - than my hint was possibly not the best (since I do not know the source). Please do whatever you consider sensible from a users point of view. It was just unusual to what we are usually doing - but not necessarily wrong in this specific case. But you're right, I think it's not worth all the extra bugs that will undoubtedly come out of it. You are right that there is a chance of missing dependency relations. May be you simply keep your original idea in mind for some later point in time and concentrate on getting something out for your final target first. I think we could go with maximum four packages: libkmersoversion libkmer-dev kmer-tools (or some similar name) libkmer-doc The text you added as descriptions in debian/control might be useful for some manpages for the tools. Sounds good. What could the soversion be? I have a svn snapshot-- can I use what I have for the package version? No, definitely not the package version. Its a sad fact that several upstreams have no idea about this. Please have a look at https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi Does this answer your question? May be we might go without any soname versioning since there seem to be several libraries bundled and we can not trust upstream to change their ABI compatibility in the same manner. Finally in the Git repository the pristine-tar branch is missing. Did you imported the upstream tarball using git import-orig --pristine-tar ? No, I was actually going to ask about this-- there are no official upstream releases, so there's no original tarball. I took the snapshot of the svn repository from sourceforge, which came to me as a zip-file. I unzipped it and then made it a tar.xz archive. The first thing I'm doing in this case is to write a mail to upstream a kind mail pointing to Debian's upstream guide[1] and ask for doing proper release traballs. Please keep this list in CC if you do so. I usually start mails like this with I'm writing you on behalf of the Debian Med team which has the goal to package all free software which is relevant in the field of biology for main Debian. Here you can see a list of what we have done so far: http://blends.debian.org/med/tasks/bio This might be more convincing to upstream as if you wrote as random person who has a crazy idea. For the moment (and if upstream might ignore your request) please add a get-orig-source target to debian/rules. You might like to check out Vcs-Git: git://anonscm.debian.org/debian-med/mauve.git as an example where I basically did the same. Using pristine-tar is specifically important exactly in these case to make sure all team members are using the same tarball. Sp lease commit pristine-tar for whatever you created using get-orig-source. If yes, please push all branches. If no, please do the latter as described in Debian Med policy. I will try to do better about following the policy. I have 4-5 sets of documentation that I keep flipping back and forth between and I sometimes forget to make sure my final work is policy-compliant. That's why we are doing this inofficial MoM right now. I'm happy to guide you into this. Robert Blake has not answered the MoM ping. So may be we do it this way officially. Our mail exchanges are exactly what MoM is about: Making sure you will have an easy start and helping you to fight through relevant docs. If Robert Blake will not answer until Wednesday I simply move you into the MoM table and we start tagging our mails with [MoM]. Thanks for checking my commits :) You are welcome Andreas. [1] https://wiki.debian.org/UpstreamGuide -- 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/20150503072441.gj5...@an3as.eu
Debian Package for kmer
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
--
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/5546da27.9040...@ghraoui.name
