Le 11/2/12 2:58 PM, Sébastien Boisvert
a écrit :
Hi
Andreas,
I have a Alioth account (sboisvert-guest).
I have read the policy and I will use
git://git.debian.org/git/debian-med/ray.git
However, I have not found how I can create this Debian-hosted
git repository.
You have
http://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures
(#
Pushing to git.debian.org, creating a new bare repository on
Alitoh.)
Olivier
On 11/02/2012 05:12 AM, Andreas Tille wrote:
Hi Sébastien,
many thanks for your work and for your interest into Debian Med.
On Fri, Nov 02, 2012 at 12:08:23AM -0400, Sébastien Boisvert
wrote:
[I posted this already, but before
confirming my subscription]
(Remark: you do not necessarily need to subscribe the list to be
able to post - but if you are interested in this field I hope
you
will profit from the discussion here.)
I successfully created a Debian package for Ray 2.1.0.
You will find packages here in a git repository:
https://github.com/sebhtml/ray-debian-package
This looks good for a first attempt but needs some further
polishing.
The Debian package policy checker lintian claims some issues
that need
fixing before we can upload the package to the official Debian
mirrors.
I installed my .deb with dpkg -i, tested
it with some data,
checked what's in it with dpkg -L ray|less, and finally
removed it
from my virtual machines (i386 and amd64).
I will add a sparc package tomorrow.
I have no idea in how far you personally will need a sparc
package.
Regarding Debian there is no real need to manually build
packages for
different architectures because so called autobuilders grab
uploaded
packages from one architecture and build all other official
Debian
architectures.
Can you review what I did ?
See my more detailed remarks below - I'll add some comments to
Tim's
posting as well.
On 11/01/2012 08:10 AM, Tim Booth wrote:
Then you could start by reading this
documentation:
http://developer.ubuntu.com/packaging/html/packaging-new-software.html
I havn't read this but I would also consider the Debian Med team
policy[1] a nice reading for your purpose. It links to some
other
introductionary documentation and also describes some rules we
are using
here in the team. If you are mainly targeting at Ubuntu please
be not
disturbed that the document is quite Debian centric. The basic
idea is
that those packages that are properly integrated into Debian
will easily
move to Ubuntu. We intend to feed the source (Debian is
upstream for
Ubuntu) properly here in the Debian Med team which makes Tim's
job for
deriving BioLinux from Ubuntu hopefully as simple and
straightforeward
as possible.
you were interested in making Ray
into a .deb package that could be
hosted on Launchpad.net? This is slightly more effort
in the first
place but has several benefits:
* The .deb package will be usable by every user
of Debian, Ubuntu
and derivatives
* The .deb package could, in future, be
submitted to the main
Debian archive via Debian-Med so it would
start appearing in the
Software Centre etc.
* CloudBioLinux will be able to add Ray without
the patch to
bio-nextgen.py, and will also see updates
automatically rather
than being hard-coded to 2.1.0
* The Launchpad auto-build system will build
binaries for multiple
architectures, run unit tests, and check for
build issues after
any dependency updates
Considering that you are writing to the Debian Med mailing list
I assume
you might not only target at a LaunchPad PPA but rather at an
official
Debian package which as I mentioned above would have additional
advantages to the ones mentioned above by Tim (for instance
autobuilders
as I mentioned above). Please correct me if my assumption is
wrong and
if you wonder about those advantages.
Now to your actual work at
https://github.com/sebhtml/ray-debian-package
I cloned this and before I will go into the technical packaging
details
I would like to suggest to consider maintaining the packaging in
the
Debian Med team repository at alioth.debian.org as described in
Debian
Med team policy[1]. The suggested repository layout (using
pristine-tar
for injecting the upstream source) is quite helpfull if you want
to use
nifty tools like git-buildpackage and others.
I'm personally no Git expert but there are people reading this
list who
can give you advise how to maintain clones at alioth.debian.org
as well
as on github.com if you like to stick to github for whatever
reason. I
guess if you might consider your time better spend by sticking
to your
current workflow and do not want to subscribe at
alioth.debian.org
somebody from our team can perfectly take over it here. The
great
advantage would be that anybody from the team (also Tim) can
immediately
fix things in your packaging which probably could speed up the
finishing
of the package.
Now to your actual packaging. I have build it as well and while
I
can confirm that some working package is builded there are
several
issues found by the policy checker lintian:
$ lintian ray_2.1.0-1_amd64.changes
E: ray source:
depends-on-build-essential-package-without-using-version make
[build-depends: make]
E: ray source: build-depends-on-build-essential build-depends
W: ray source: ancient-standards-version 3.8.4 (current is
3.9.3)
W: ray: hardening-no-relro usr/bin/Ray
W: ray: hardening-no-fortify-functions usr/bin/Ray
W: ray: new-package-should-close-itp-bug
E: ray: helper-templates-in-copyright
E: ray: description-starts-with-package-name
W: ray: description-starts-with-leading-spaces
W: ray: package-contains-upstream-install-documentation
usr/share/doc/ray/INSTALL.txt
W: ray: extra-license-file usr/share/doc/ray/LICENSE.txt
W: ray: binary-without-manpage usr/bin/Ray
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/NCBI-Taxonomy/Create-Taxon-Names.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/NCBI-Taxonomy/GenerateTaxonNames.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/NCBI-Taxonomy/getName.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/NCBI-Taxonomy/getNameInFile.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/getSeq.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/illumina-split-linked-sequences-fastq.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/interleave-fasta.py
E: ray: python-script-but-no-python-dep
usr/share/ray/scripts/interleave-fastq.py
W: ray: unusual-interpreter
usr/share/ray/scripts/plot-color-distributions.R
#!/usr/bin/Rscript
W: ray: unusual-interpreter
usr/share/ray/scripts/plot-coverage-distribution.R
#!/usr/bin/Rscript
W: ray: unusual-interpreter
usr/share/ray/scripts/plot-library-distribution.R
#!/usr/bin/Rscript
If you call lintian with option '-i' you get some more detailed
information about what might be the actual problem and how to
fix it in
your packaging. I could easily go into more detail if something
remains
unclear to you but it seemed easier to me to agree to a common
workflow
first. So please just tell me what you think and we will try to
fix
this together after agreeing to a wrokflow that fit our needs
best.
Kind regards and thanks for your interest in Debian Med
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
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
|