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
