Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
Hi Michael,
thanks for your effort to prepare a bamtools Debian package and also
notifying the Debian Med project.
On Tue, Nov 06, 2012 at 03:16:44PM -0700, Michael Crusoe wrote:
> And here's the package,
>
> https://github.com/mr-c/bamtools/tree/debian
I tried to check out this URL using
git clone https://github.com/mr-c/bamtools/tree/debian
Cloning into 'debian'...
fatal: https://github.com/mr-c/bamtools/tree/debian/info/refs not found: did
you run git update-server-info on the server?
In any case I would really love if you would consider maintenance of the
Debian packaging at git.debian.org as it is described in Debian Med team
policy[1] which has a lot of advantages that might not obvious at first
sight (I'd happily elaborate on this if you are curious what these might
be.) I'd volunteer to create an initial repository - write access should
be easy for you because I just verified that you are member of the Alioth
project.
> My packaging skills are a bit rusty, so your feedback would be appreciated.
:)
I checked out the Zip archive from Github and will comment on this basis
below.
> On Tue, Nov 6, 2012 at 1:28 PM, Michael Crusoe
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: debian-med@lists.debian.org
> >
> > * Package name: bamtools
> > Version : 2.2
> > Upstream Author : Derek Barnett
> > * URL : https://github.com/pezmaster31/bamtools
> > * License : Expat
> > Programming Lang: C++
> > Description : C++ API and toolkit for manipulating BAM (genome
> > alignment) files
I intended to answer in response to your ITP bug that a long description
is missing and it is also basically missing in your debian/control file.
Please try to find a more verbose description for the binary packages.
Other issues in debian/control:
Maintainer: great, you obviosely are aware about[1] - did I mention
you should consider maintenance at git.debian.org ;-)
Vcs-{Git,Browser}: see above, several tools are relying on this
Description: short description of lib and devel package should be
different (to tell them appart) and as I said a better
long description is needed
File debian/clean: Uhmm, my packaging skills also do not seem to be up
to date. I never used this because I was not aware about this and
I definitely could have used in some cases. However, I guess you are
specifying most probably the wrong file - I think you want to delete
debian/bamtools.1 there
File debian/libbamtools2.2.0.dir: You most probably want to append an
's' to the file name - or just remove it together with the other
*.dirs file. Both are not needed because dh_install is clever enough
to create the directories. The only need to create directories that
way is if you want to move something around before dh_install
File libbamtools2.2.0.manpages: Are you sure that you want to install
debian/bamtools-2.2.0.1 as manpage? The file name does not look at
all like a manpage - I would simply remove this file
Files *.postints / *.postrm: These files are looking like usual
templates. I have not seen any specific use. Did I missed something?
File debian/rules:
1. Please drop the comment of the dh-make template. This file is
actually no "Sample debian/rules that uses debhelper."
2. override_dh_auto_clean is fine - but why not using debian/clean
for this as well (just wondering)
3. get-orig-source: see below
Missing file debian/watch: It seems bamtools relies totally in Git to
distribute the source. I admit we are facing such situations more and
more however, my personal opinion is that we should try to recommend
upstream to do some versioned source tarball releases to enable tools
like uscan detecting new versions. You could write a reasonable
debian/watch file which would make the get-orig-source target in
debian/rules unneeded. You seem to be connected to upstream and I would
like you to propagate this idea.
Kind regards and many thanks for your work on this
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
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: http://lists.debian.org/20121107075923.ga12...@an3as.eu
FreeMedForms: New stable upstream 0.8.0
Hi, We released a new stable upstream today: v0.8.0. The packaging is updated in the debian med svn. Can you sponsor this update? Thanks Eric, freemedforms.com -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b790846a-e8b7-429c-9059-5e1344248...@gmail.com
Re: FreeMedForms: New stable upstream 0.8.0
Hi Eric, thanks for your preparation. On Wed, Nov 07, 2012 at 01:40:10PM +0100, Eric Maeker wrote: > We released a new stable upstream today: v0.8.0. The packaging is updated in > the debian med svn. > Can you sponsor this update? Yes, I'll have a look. Please note that I'll upload to experimental due to the specific rules in Freeze time. 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: http://lists.debian.org/20121107125942.gk12...@an3as.eu
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
It is also possible to remove the third party code from the source tarball
and from debian/copyright.
Please take a look at the following two patches. They add out-of-source
support to bamtools.
https://github.com/domibel/bamtools/commit/5fc8c1928eaa46fb58618db8ecb93e40cfce54ba
https://github.com/domibel/bamtools/commit/784ff9bbf67d131bce59d548aa911e7ee8698aac
-Dominique
On Wed, Nov 7, 2012 at 2:59 AM, Andreas Tille wrote:
> Hi Michael,
>
> thanks for your effort to prepare a bamtools Debian package and also
> notifying the Debian Med project.
>
> On Tue, Nov 06, 2012 at 03:16:44PM -0700, Michael Crusoe wrote:
> > And here's the package,
> >
> > https://github.com/mr-c/bamtools/tree/debian
>
> I tried to check out this URL using
>
>git clone https://github.com/mr-c/bamtools/tree/debian
> Cloning into 'debian'...
> fatal: https://github.com/mr-c/bamtools/tree/debian/info/refs not found:
> did you run git update-server-info on the server?
>
>
> In any case I would really love if you would consider maintenance of the
> Debian packaging at git.debian.org as it is described in Debian Med team
> policy[1] which has a lot of advantages that might not obvious at first
> sight (I'd happily elaborate on this if you are curious what these might
> be.) I'd volunteer to create an initial repository - write access should
> be easy for you because I just verified that you are member of the Alioth
> project.
>
> > My packaging skills are a bit rusty, so your feedback would be
> appreciated.
>
> :)
> I checked out the Zip archive from Github and will comment on this basis
> below.
>
> > On Tue, Nov 6, 2012 at 1:28 PM, Michael Crusoe
> wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: debian-med@lists.debian.org
> > >
> > > * Package name: bamtools
> > > Version : 2.2
> > > Upstream Author : Derek Barnett
> > > * URL : https://github.com/pezmaster31/bamtools
> > > * License : Expat
> > > Programming Lang: C++
> > > Description : C++ API and toolkit for manipulating BAM (genome
> > > alignment) files
>
> I intended to answer in response to your ITP bug that a long description
> is missing and it is also basically missing in your debian/control file.
> Please try to find a more verbose description for the binary packages.
>
> Other issues in debian/control:
>
> Maintainer: great, you obviosely are aware about[1] - did I mention
> you should consider maintenance at git.debian.org ;-)
> Vcs-{Git,Browser}: see above, several tools are relying on this
> Description: short description of lib and devel package should be
>different (to tell them appart) and as I said a better
>long description is needed
>
> File debian/clean: Uhmm, my packaging skills also do not seem to be up
> to date. I never used this because I was not aware about this and
> I definitely could have used in some cases. However, I guess you are
> specifying most probably the wrong file - I think you want to delete
> debian/bamtools.1 there
>
> File debian/libbamtools2.2.0.dir: You most probably want to append an
> 's' to the file name - or just remove it together with the other
> *.dirs file. Both are not needed because dh_install is clever enough
> to create the directories. The only need to create directories that
> way is if you want to move something around before dh_install
>
> File libbamtools2.2.0.manpages: Are you sure that you want to install
> debian/bamtools-2.2.0.1 as manpage? The file name does not look at
> all like a manpage - I would simply remove this file
>
> Files *.postints / *.postrm: These files are looking like usual
> templates. I have not seen any specific use. Did I missed something?
>
> File debian/rules:
>
> 1. Please drop the comment of the dh-make template. This file is
> actually no "Sample debian/rules that uses debhelper."
> 2. override_dh_auto_clean is fine - but why not using debian/clean
> for this as well (just wondering)
> 3. get-orig-source: see below
>
> Missing file debian/watch: It seems bamtools relies totally in Git to
> distribute the source. I admit we are facing such situations more and
> more however, my personal opinion is that we should try to recommend
> upstream to do some versioned source tarball releases to enable tools
> like uscan detecting new versions. You could write a reasonable
> debian/watch file which would make the get-orig-source target in
> debian/rules unneeded. You seem to be connected to upstream and I would
> like you to propagate this idea.
>
> Kind regards and many thanks for your work on this
>
> Andreas.
>
>
> [1] http://debian-med.alioth.debian.org/docs/policy.html
>
> --
> 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: http://lists.debian.org/20121107075923.ga12...@an3as.eu
Some (minimal?) Java help needed (Was: Bug#670353: ITP: fastqc -- quality control for next generation sequencing data)
Hi, I stumbled upon this one and did some work on it in Vcs-Svn: http://svn.debian.org/debian-med/trunk/packages/babraham/fastqc/trunk/ It is close to lintian clean now but there is some CLASSPATH issue which is probably very easy for Java experts: $ fastqc Exception in thread "main" java.lang.NoClassDefFoundError: uk/ac/babraham/FastQC/FastQCApplication Caused by: java.lang.ClassNotFoundException: uk.ac.babraham.FastQC.FastQCApplication at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Could not find the main class: uk.ac.babraham.FastQC.FastQCApplication. Program will exit. or when trying manually what the wrapper tries to do $ java -jar /usr/share/fastqc/fastqc.jar uk.ac.babraham.FastQC.FastQCApplication Skipping 'uk.ac.babraham.FastQC.FastQCApplication' which didn't exist, or couldn't be read My suspicion is that simply specifying the Main-Class in debian/manifest is not sufficient. Something might be wrong with the Debian home brewn Makefile as quilt patch and ant+built.xml might do a better job to build the Jar functionally. Any hint for doing this properly? Note to obtain the source as easy as possible: Just use the uscan from http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl to call uscan.pl --verbose --force-download --repack-compression xz which gives you a properly stripped source tarball. Kind regards and thanks for any help Andreas. On Wed, Apr 25, 2012 at 01:08:54AM +0200, Steffen Moeller wrote: > Package: wnpp > Severity: wishlist > Owner: Steffen Moeller > > * Package name: fastqc > * URL : http://www.bioinformatics.babraham.ac.uk/projects/fastqc/ > * License : GPL-3 > Programming Lang: Java > Description : quality control for next generation sequencing data > > The Debian Med source code repository has some functional (not lintian clean) > package in > trunk/packages/babraham/fastqc. > -- 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: http://lists.debian.org/20121107142932.gb25...@an3as.eu
Versioned source download for PHYLOViZ?
Hello, I'm writing you on behalf of the Debian Med team that tries to package all Free Software relevant to medical care and bioinformatics straight into official Debian. We've got a hint to your PHYLOViZ package and it seems to be a nice target for us. When inspecting your download page[1] I just learned that your source tarballs are not featuring any versioning. This is generally a bad idea (also for non-Debian users) because it is hard to tell whether there is a new release worth downloading. Thus I would like you to consider providing files like net-phyloviz-core-1.2.3.tar.gz (or whatever version scheme you might choose) instead of just net-phyloviz-core.tar.gz. I hope you might like the idea to create Debian packages and thanks for providing PHYLOViZ as Free Software Andreas. [1] http://www.phyloviz.net/wiki/plugins/ -- 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: http://lists.debian.org/20121107143637.gc25...@an3as.eu
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
Hi, On Wed, Nov 07, 2012 at 01:27:50PM -0700, Michael Crusoe wrote: > > Debian packaging at git.debian.org as it is described in Debian Med team > > policy[1] which has a lot of advantages that might not obvious at first > > sight (I'd happily elaborate on this if you are curious what these might > > be.) I'd volunteer to create an initial repository - write access should > > be easy for you because I just verified that you are member of the Alioth > > project. > > I have no strong feelings though I like having the packaging data > hosted in such a way as to preserve all the git history for the > software itself. Would that still be possible? I admit I'm definitely not a Git expert and thus I'm CCing your (not so private mail) to the list (and we should keep the discussion here). Usually we do commit the source release of each packaged version using pristine-tar - just as it is described in Debian Med policy[1] in the "Git tips" section. I do not have any strong opinion to have more detailed history as long as the branches and tags we are using are properly set to enable git-buildpackage working. > > I intended to answer in response to your ITP bug that a long description > > is missing and it is also basically missing in your debian/control file. > > Please try to find a more verbose description for the binary packages. > > Okay, I've added the overview of commands: > > Available bamtools commands: > convert Converts between BAM and a number of other formats > countPrints number of alignments in BAM file(s) > coverage Prints coverage statistics from the input BAM file > filter Filters BAM file(s) by user-specified criteria > header Prints BAM header information > indexGenerates index for BAM file > mergeMerge multiple BAM files into single file > random Select random alignments from existing BAM file(s), intended more as > a testing tool. > resolve Resolves paired-end reads (marking the IsProperPair flag as needed) > revert Removes duplicate marks and restores original base qualities > sort Sorts the BAM file according to some criteria > splitSplits a BAM file on user-specified property, creating a new BAM > output file for each value found > statsPrints some basic statistics from input BAM file(s) Thanks, this is helpful. > > File libbamtools2.2.0.manpages: Are you sure that you want to install > > debian/bamtools-2.2.0.1 as manpage? The file name does not look at > > all like a manpage - I would simply remove this file > > It appears the second line fails. I created it in response to a > lintian warning as the binary is shipped as 'bamtools' and a symlink > with the name 'bamtools-2.2.0' Hmmm, I wonder whether this is actually a good idea to have versioned binary in this way. Is there any good reason to do so? If yes I would rather try to do some layout like /usr/lib/babtools/... and possibly keep different versions in a reasonable way there which could be dealt by setting PATH properly to refer to a certain version. You could use a symlink /usr/bin/bamtools to the latest version in /usr/lib/bamtools . > > Files *.postints / *.postrm: These files are looking like usual > > templates. I have not seen any specific use. Did I missed something? > > I believe debhelper adds in ldconfig commands. I have not tested in this case but I'm very positive that debhelper is clever enough to do so even without providing these files. > > 3. get-orig-source: see below > > > > Missing file debian/watch: It seems bamtools relies totally in Git to > > distribute the source. I admit we are facing such situations more and > > more however, my personal opinion is that we should try to recommend > > upstream to do some versioned source tarball releases to enable tools > > like uscan detecting new versions. You could write a reasonable > > debian/watch file which would make the get-orig-source target in > > debian/rules unneeded. You seem to be connected to upstream and I would > > like you to propagate this idea. > > I believe if upstream tags using version number then the uscan is > fairly trivial. I've contacted them about this. Thanks for the > reminder. Fine. Kind regards Andreas. [1] http://debian-med.alioth.debian.org/docs/policy.html -- 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: http://lists.debian.org/20121107205205.gf25...@an3as.eu
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
Le Wed, Nov 07, 2012 at 09:52:05PM +0100, Andreas Tille a écrit : > Hi, > > On Wed, Nov 07, 2012 at 01:27:50PM -0700, Michael Crusoe wrote: > > > Debian packaging at git.debian.org as it is described in Debian Med team > > > policy[1] which has a lot of advantages that might not obvious at first > > > sight (I'd happily elaborate on this if you are curious what these might > > > be.) I'd volunteer to create an initial repository - write access should > > > be easy for you because I just verified that you are member of the Alioth > > > project. > > > > I have no strong feelings though I like having the packaging data > > hosted in such a way as to preserve all the git history for the > > software itself. Would that still be possible? > > I admit I'm definitely not a Git expert and thus I'm CCing your (not so > private mail) to the list (and we should keep the discussion here). > Usually we do commit the source release of each packaged version using > pristine-tar - just as it is described in Debian Med policy[1] in the > "Git tips" section. I do not have any strong opinion to have more > detailed history as long as the branches and tags we are using are > properly set to enable git-buildpackage working. Dear Michael, source packages repositories at git.debian.org can have the same layout as you are using on GitHub. All the developers in Debian Med have write access to git.debian.org/debian-med, which is a key difference for collaborative work compared to GitHub. I would recommend to have git.debian.org as the main place to maintain the source package, and to mirror it on GitHub if you would like. For mirroring, you may be interested in https://github.com/Debian/README.Debian. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107223111.gb3...@falafel.plessy.net
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
Hi Andreas !
The github URL provided by Michael Crusoe
is not the git repository.
The actual git repository is
git://github.com/mr-c/bamtools.git
On 11/07/2012 02:59 AM, Andreas Tille wrote:
Hi Michael,
thanks for your effort to prepare a bamtools Debian package and also
notifying the Debian Med project.
On Tue, Nov 06, 2012 at 03:16:44PM -0700, Michael Crusoe wrote:
And here's the package,
https://github.com/mr-c/bamtools/tree/debian
I tried to check out this URL using
git clone https://github.com/mr-c/bamtools/tree/debian
Cloning into 'debian'...
fatal: https://github.com/mr-c/bamtools/tree/debian/info/refs not found: did
you run git update-server-info on the server?
In any case I would really love if you would consider maintenance of the
Debian packaging at git.debian.org as it is described in Debian Med team
policy[1] which has a lot of advantages that might not obvious at first
sight (I'd happily elaborate on this if you are curious what these might
be.) I'd volunteer to create an initial repository - write access should
be easy for you because I just verified that you are member of the Alioth
project.
My packaging skills are a bit rusty, so your feedback would be appreciated.
:)
I checked out the Zip archive from Github and will comment on this basis
below.
On Tue, Nov 6, 2012 at 1:28 PM, Michael Crusoe wrote:
Package: wnpp
Severity: wishlist
Owner: debian-med@lists.debian.org
* Package name: bamtools
Version : 2.2
Upstream Author : Derek Barnett
* URL : https://github.com/pezmaster31/bamtools
* License : Expat
Programming Lang: C++
Description : C++ API and toolkit for manipulating BAM (genome
alignment) files
I intended to answer in response to your ITP bug that a long description
is missing and it is also basically missing in your debian/control file.
Please try to find a more verbose description for the binary packages.
Other issues in debian/control:
Maintainer: great, you obviosely are aware about[1] - did I mention
you should consider maintenance at git.debian.org ;-)
Vcs-{Git,Browser}: see above, several tools are relying on this
Description: short description of lib and devel package should be
different (to tell them appart) and as I said a better
long description is needed
File debian/clean: Uhmm, my packaging skills also do not seem to be up
to date. I never used this because I was not aware about this and
I definitely could have used in some cases. However, I guess you are
specifying most probably the wrong file - I think you want to delete
debian/bamtools.1 there
File debian/libbamtools2.2.0.dir: You most probably want to append an
's' to the file name - or just remove it together with the other
*.dirs file. Both are not needed because dh_install is clever enough
to create the directories. The only need to create directories that
way is if you want to move something around before dh_install
File libbamtools2.2.0.manpages: Are you sure that you want to install
debian/bamtools-2.2.0.1 as manpage? The file name does not look at
all like a manpage - I would simply remove this file
Files *.postints / *.postrm: These files are looking like usual
templates. I have not seen any specific use. Did I missed something?
File debian/rules:
1. Please drop the comment of the dh-make template. This file is
actually no "Sample debian/rules that uses debhelper."
2. override_dh_auto_clean is fine - but why not using debian/clean
for this as well (just wondering)
3. get-orig-source: see below
Missing file debian/watch: It seems bamtools relies totally in Git to
distribute the source. I admit we are facing such situations more and
more however, my personal opinion is that we should try to recommend
upstream to do some versioned source tarball releases to enable tools
like uscan detecting new versions. You could write a reasonable
debian/watch file which would make the get-orig-source target in
debian/rules unneeded. You seem to be connected to upstream and I would
like you to propagate this idea.
Kind regards and many thanks for your work on this
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
Sent from my IBM Blue Gene/Q
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509b13f7.1070...@ulaval.ca
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
On Wed, Nov 7, 2012 at 1:52 PM, Andreas Tille wrote: > Hi, > > On Wed, Nov 07, 2012 at 01:27:50PM -0700, Michael Crusoe wrote: >> > Debian packaging at git.debian.org as it is described in Debian Med team >> > policy[1] which has a lot of advantages that might not obvious at first >> > sight (I'd happily elaborate on this if you are curious what these might >> > be.) I'd volunteer to create an initial repository - write access should >> > be easy for you because I just verified that you are member of the Alioth >> > project. >> >> I have no strong feelings though I like having the packaging data >> hosted in such a way as to preserve all the git history for the >> software itself. Would that still be possible? > > I admit I'm definitely not a Git expert and thus I'm CCing your (not so > private mail) to the list (and we should keep the discussion here). > Usually we do commit the source release of each packaged version using > pristine-tar - just as it is described in Debian Med policy[1] in the > "Git tips" section. I do not have any strong opinion to have more > detailed history as long as the branches and tags we are using are > properly set to enable git-buildpackage working. Pardon me, I forgot to 'reply-all'. Yeah, I'm new to Git as well. I've made the git.debian.org/git/debian-med/bamtools.git repository, renamed my branches, added a pristine-tar based off of the 2.2 release and pushed up the whole lot. >> > I intended to answer in response to your ITP bug that a long description >> > is missing and it is also basically missing in your debian/control file. >> > Please try to find a more verbose description for the binary packages. >> >> Okay, I've added the overview of commands: >> >> Available bamtools commands: >> convert Converts between BAM and a number of other formats >> countPrints number of alignments in BAM file(s) >> coverage Prints coverage statistics from the input BAM file >> filter Filters BAM file(s) by user-specified criteria >> header Prints BAM header information >> indexGenerates index for BAM file >> mergeMerge multiple BAM files into single file >> random Select random alignments from existing BAM file(s), intended more >> as >> a testing tool. >> resolve Resolves paired-end reads (marking the IsProperPair flag as needed) >> revert Removes duplicate marks and restores original base qualities >> sort Sorts the BAM file according to some criteria >> splitSplits a BAM file on user-specified property, creating a new BAM >> output file for each value found >> statsPrints some basic statistics from input BAM file(s) > > Thanks, this is helpful. You are welcome. >> > File libbamtools2.2.0.manpages: Are you sure that you want to install >> > debian/bamtools-2.2.0.1 as manpage? The file name does not look at >> > all like a manpage - I would simply remove this file >> >> It appears the second line fails. I created it in response to a >> lintian warning as the binary is shipped as 'bamtools' and a symlink >> with the name 'bamtools-2.2.0' > > Hmmm, I wonder whether this is actually a good idea to have versioned > binary in this way. Is there any good reason to do so? If yes I would > rather try to do some layout like > > /usr/lib/babtools/... > > and possibly keep different versions in a reasonable way there which > could be dealt by setting PATH properly to refer to a certain version. > You could use a symlink /usr/bin/bamtools to the latest version in > /usr/lib/bamtools . The versioned symlink for the binary is from upstream. My aim here was to diverge the least amount from what previous users expect. >> > Files *.postints / *.postrm: These files are looking like usual >> > templates. I have not seen any specific use. Did I missed something? >> >> I believe debhelper adds in ldconfig commands. > > I have not tested in this case but I'm very positive that debhelper is > clever enough to do so even without providing these files. Testing... Indeed you are correct. I have removed them. -- Michael R. Crusoe -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAD=WrcK6m3LShNW4kVBQVX9xvWqvPN=x2kvmywpskz9po-w...@mail.gmail.com
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
On Wed, Nov 7, 2012 at 6:21 AM, Dominique Belhachemi wrote:
> It is also possible to remove the third party code from the source tarball
> and from debian/copyright.
I've removed it from the master branch and modified the copyright.
What is the best way to update the source tarball?
> Please take a look at the following two patches. They add out-of-source
> support to bamtools.
>
> https://github.com/domibel/bamtools/commit/5fc8c1928eaa46fb58618db8ecb93e40cfce54ba
> https://github.com/domibel/bamtools/commit/784ff9bbf67d131bce59d548aa911e7ee8698aac
> -Dominique
>
>
> On Wed, Nov 7, 2012 at 2:59 AM, Andreas Tille wrote:
>>
>> Hi Michael,
>>
>> thanks for your effort to prepare a bamtools Debian package and also
>> notifying the Debian Med project.
>>
>> On Tue, Nov 06, 2012 at 03:16:44PM -0700, Michael Crusoe wrote:
>> > And here's the package,
>> >
>> > https://github.com/mr-c/bamtools/tree/debian
>>
>> I tried to check out this URL using
>>
>>git clone https://github.com/mr-c/bamtools/tree/debian
>> Cloning into 'debian'...
>> fatal: https://github.com/mr-c/bamtools/tree/debian/info/refs not found:
>> did you run git update-server-info on the server?
>>
>>
>> In any case I would really love if you would consider maintenance of the
>> Debian packaging at git.debian.org as it is described in Debian Med team
>> policy[1] which has a lot of advantages that might not obvious at first
>> sight (I'd happily elaborate on this if you are curious what these might
>> be.) I'd volunteer to create an initial repository - write access should
>> be easy for you because I just verified that you are member of the Alioth
>> project.
>>
>> > My packaging skills are a bit rusty, so your feedback would be
>> > appreciated.
>>
>> :)
>> I checked out the Zip archive from Github and will comment on this basis
>> below.
>>
>> > On Tue, Nov 6, 2012 at 1:28 PM, Michael Crusoe
>> > wrote:
>> > > Package: wnpp
>> > > Severity: wishlist
>> > > Owner: debian-med@lists.debian.org
>> > >
>> > > * Package name: bamtools
>> > > Version : 2.2
>> > > Upstream Author : Derek Barnett
>> > > * URL : https://github.com/pezmaster31/bamtools
>> > > * License : Expat
>> > > Programming Lang: C++
>> > > Description : C++ API and toolkit for manipulating BAM (genome
>> > > alignment) files
>>
>> I intended to answer in response to your ITP bug that a long description
>> is missing and it is also basically missing in your debian/control file.
>> Please try to find a more verbose description for the binary packages.
>>
>> Other issues in debian/control:
>>
>> Maintainer: great, you obviosely are aware about[1] - did I mention
>> you should consider maintenance at git.debian.org ;-)
>> Vcs-{Git,Browser}: see above, several tools are relying on this
>> Description: short description of lib and devel package should be
>>different (to tell them appart) and as I said a better
>>long description is needed
>>
>> File debian/clean: Uhmm, my packaging skills also do not seem to be up
>> to date. I never used this because I was not aware about this and
>> I definitely could have used in some cases. However, I guess you are
>> specifying most probably the wrong file - I think you want to delete
>> debian/bamtools.1 there
>>
>> File debian/libbamtools2.2.0.dir: You most probably want to append an
>> 's' to the file name - or just remove it together with the other
>> *.dirs file. Both are not needed because dh_install is clever enough
>> to create the directories. The only need to create directories that
>> way is if you want to move something around before dh_install
>>
>> File libbamtools2.2.0.manpages: Are you sure that you want to install
>> debian/bamtools-2.2.0.1 as manpage? The file name does not look at
>> all like a manpage - I would simply remove this file
>>
>> Files *.postints / *.postrm: These files are looking like usual
>> templates. I have not seen any specific use. Did I missed something?
>>
>> File debian/rules:
>>
>> 1. Please drop the comment of the dh-make template. This file is
>> actually no "Sample debian/rules that uses debhelper."
>> 2. override_dh_auto_clean is fine - but why not using debian/clean
>> for this as well (just wondering)
>> 3. get-orig-source: see below
>>
>> Missing file debian/watch: It seems bamtools relies totally in Git to
>> distribute the source. I admit we are facing such situations more and
>> more however, my personal opinion is that we should try to recommend
>> upstream to do some versioned source tarball releases to enable tools
>> like uscan detecting new versions. You could write a reasonable
>> debian/watch file which would make the get-orig-source target in
>> debian/rules unneeded. You seem to be connected to upstream and I would
>> like you to propagate this idea.
>>
>> Kind regards and many thanks for your work on this
>>
>> Andreas.
>>
>>
Re: Bug#692498: ITP: bamtools -- C++ API and toolkit for manipulating BAM (genome alignment) files
On Wed, Nov 07, 2012 at 08:59:27PM -0700, Michael Crusoe wrote: > On Wed, Nov 7, 2012 at 6:21 AM, Dominique Belhachemi > wrote: > > It is also possible to remove the third party code from the source tarball > > and from debian/copyright. > > I've removed it from the master branch and modified the copyright. > What is the best way to update the source tarball? If it is removed from the master branch (you are refering to upstream, right?) than it might make sense to release a new minor version. Otherwise it would make sense to write a debian/get-orig-source script and call this in the get-orig-source target of debian/rules. There are a plenty of examples in Debian Med repository - feel free to ask for a more detailed link. 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: http://lists.debian.org/20121108071920.gb17...@an3as.eu
Re: Some (minimal?) Java help needed (Was: Bug#670353: ITP: fastqc -- quality control for next generation sequencing data)
Le 11/7/12 3:29 PM, Andreas Tille a écrit : > Hi, > > I stumbled upon this one and did some work on it in > >Vcs-Svn: > http://svn.debian.org/debian-med/trunk/packages/babraham/fastqc/trunk/ > > It is close to lintian clean now but there is some CLASSPATH issue > which is probably very easy for Java experts: > > $ fastqc > Exception in thread "main" java.lang.NoClassDefFoundError: > uk/ac/babraham/FastQC/FastQCApplication > Caused by: java.lang.ClassNotFoundException: > uk.ac.babraham.FastQC.FastQCApplication > at java.net.URLClassLoader$1.run(URLClassLoader.java:217) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:321) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:266) > Could not find the main class: uk.ac.babraham.FastQC.FastQCApplication. > Program will exit. > > or when trying manually what the wrapper tries to do > > $ java -jar /usr/share/fastqc/fastqc.jar > uk.ac.babraham.FastQC.FastQCApplication > Skipping 'uk.ac.babraham.FastQC.FastQCApplication' which didn't exist, or > couldn't be read I will have a look but: It seems that the file with structure uk/ac/babraham/FastQC/FastQCApplication.class is missing in the jar file /usr/share/fastqc/fastqc.jar (you can check content with jar -tf /usr/share/fastqc/fastqc.jar) > > > My suspicion is that simply specifying the Main-Class in debian/manifest > is not sufficient. Something might be wrong with the Debian home brewn > Makefile as quilt patch and ant+built.xml might do a better job to build > the Jar functionally. Any hint for doing this properly? Main-Class in manifest gives the default class to call when using java -jar myjarfile. If the jar needs other jar files, they need to be specified in Manifest too or at command line in the classpath parameter. Olivier > > Note to obtain the source as easy as possible: Just use the uscan from > > > http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl > > to call > >uscan.pl --verbose --force-download --repack-compression xz > > which gives you a properly stripped source tarball. > > Kind regards and thanks for any help > >Andreas. > > On Wed, Apr 25, 2012 at 01:08:54AM +0200, Steffen Moeller wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Steffen Moeller >> >> * Package name: fastqc >> * URL : http://www.bioinformatics.babraham.ac.uk/projects/fastqc/ >> * License : GPL-3 >> Programming Lang: Java >> Description : quality control for next generation sequencing data >> >> The Debian Med source code repository has some functional (not lintian >> clean) package in >> trunk/packages/babraham/fastqc. >> -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509b61d6.4070...@irisa.fr
