Re: [MoM] Packaging of python-csb - report #3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Tomas! I see from the mails you've made very nice progress. dh is great, and with the help of a tutor progress can indeed be very fast. Is this a pure Python module or extension? - just curious. >> Once these issues are fixed I consider the package ready for upload. >> However, Laszlo had last time consulted the python-modules team. I >> think this is a very good idea and I would like you to ask for >> additional advise on the Python modules team list on alioth. >> > > Great. As soon as I figure out the 'watch' file I'll get in touch with > the python-modules team. > * If the package, apart of d/watch, is ready, then don't wait with asking. It may take Jakub [1] days to find time and have a look and answer. I think email the Python Modules Team list (sign up to that list) [2], but /address/ Jakub Wilk (to help them decide who should act), asking to review your package if he has time. Possibly also drop a few lines explaining why the package is to be maintained by Debian Med and not the Python Modules Team. A note on who the package maintainer should be: you actually can change this (e.g. to the Python Team), if the package is acceptable by that Team (they do /not/ accept packages that are /more/ than Python modules, that is why librcsb-core-wrapper, which also builds python extensions modules, is not there). * Putting the package to a dedicated team, like the Python or Perl Teams, when it fits that team, is /a good idea/ in my opinion, as that team specializes in the specific details of those modules, and can help you package or maintain them best. At one point Andreas - do I remember well? - - gave me the same advice about some Perl modules (that were also of general interest). => So if it qualifies, I would move your package to the Python Team. Fortunately, this is no problem for upstream data extraction tools of the Debian Med Team: your package can show up on [3] just as well. Best regards, Laszlo [1] Jakub Wilk [2] Debian Python Modules Team [3] http://debian-med.alioth.debian.org/tasks/bio-dev Best regards, Laszlo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQk3rAAAoJEJvS1kCaDFL6RsYP/3Yd6rDphewKIsq1kWmPJ4mB ro1eMaGqTfueWI5WwDj4i8jOWox/8Tesr/UDUAljhdGYdRvgrUcTuJONow7m7BDF nIL2cpIPaHzxX5kDMBAyfurR03eonO1J4qQrujo/iI3YypH7FsKU0bzTKxEwYJpZ MABggKuqWCSGDui0Qt/AdB1d+2NFheIewsRuIhMXXw4zRviDAH4S8yPo8pSWqK5h avTBV9CUpIAQEKUDkjckC8oMpeZFM5g6vBjWnMB+qrp1WGw5fJUGcLsxWA/ftwBT Jr/e49SspCw7QXVIJYBj69dffzfpyyAhNjp9Y1cqkzpaq707pzaeN0PVO1tJbuTu 84NGXfiWcgsxKEU14ux/S2/Uoin6ormMCdpPCvi6SIsEjcA75HKouyRXDqGQTBJ/ MFLnpHHz0a3IFllEFvp4n+H1rRoRIRmTsY7gSEWJTFcD3veWwdYjCOQRE3pbnkLA hEDYHhw3/b0/P+vBe0qOPY30iGkZAr7A+L9MIkrovQBf64DZ6rtAiXHKD5Eo3rZQ Y28aVBLgtuQs+8YX+L7kp/s/hEl2CrDP4K4Dwk4nA+2wDtFdJCt1Tq9O/D2ru9X8 yJ5wyUxAAxw/DrwX1/RxYWCYhFCuuBGLJWg4aSu3oHDDwrFMt2zP1mBPpqxWdS47 bmuX2ZZ+A2ielular9vq =IhJe -END PGP SIGNATURE- -- 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/50937ac0.6010...@rostlab.org
Re: [MoM] Packaging of python-csb - report #3
On Fri, Nov 02, 2012 at 01:17:20AM +0100, Tomás Di Domenico wrote: > > Fine. The ITP is OK in general. As a hint for the future: It is a > > good idea to add a hint that the package is maintained in the Debian Med > > team and it also does not harm to mention the Vcs-Git information where > > you did your packaging. > > > I see. These hints you mention, would they go in the package description? Well, I add this somewere free form in the end of the mail after the package description leaving some extra space to make clear that it is not part of the description. Wenn issuing an ITP bug report you finally are creating some e-mail and human beeings are reading it - so they can perfectly tell appart what belongs to the formal fields and whats an additional hint. > > > > At first some nitpicking: The debian/rules file does contain the > > usual comment of the dh-make template - please remove this or replace > > it by something more reasonable than "Sample debian/rules ..." > > > > Now for the real problems: If you try > > > >lintian -i -I *.changes > > > > in the dir where your packaging results are placed lintian finds two > > issues with formally low priority. However, both deserve fixing. So > > writing a debian/watch file is something we try to approach for every > > package if somehow possible. > > > > I've looked into the upstream site (http://csb.codeplex.com), and I > can't seem to find a page where you would get direct access to the > .tar.gz file. Instead you get a series of redirects. Apparently, the > 'https://csb.codeplex.com/releases/' url will redirect you to the final > release, but the actual link to the sources file is not explicitly > linked from the page source. Would the tool be able to handle this kind > of redirects? Yes uscan is and the manpage of uscan gives some hints. You might also have a look onto the more complex watch files regarding similar upstream masquerading of the download files (for instance [1]). However, IMHO the best way to go in your current situation is to kindly ask on the debian-ment...@lists.debian.org list for some help. This serves two purposes: At first you get some help (I'm currently on some mini-vacation) in the actual issue and secondly you also learn where to get competent help from Debian community in your packaging work. > Great. As soon as I figure out the 'watch' file I'll get in touch with > the python-modules team. Fine. Its nice to see that you are progressing fast. Kind regards Andreas. [1] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/elastix/trunk/debian/watch?view=markup -- 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/20121102081531.ga4...@an3as.eu
Re: Packaging Ray for Debian Med
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 (curre
Re: InVesalius 3 Beta
Hi Thiago, On Thu, Nov 01, 2012 at 03:35:10PM -0200, Thiago Franco Moraes wrote: > > I've just created the first package to ca_smoothing. The package name is > python-casmoothing. > > dget -x > http://dl.dropbox.com/u/817671/packages/packaging/python-casmoothing/python-casmoothing_0.1%7Egit357bbd1-1.dsc Thanks for your preparation. I downloaded this and tried to build it in a clean chroot. This seemed to reveal some missing Build-Depends from libvtk5-dev. After adding this the build failed as well and unfortunately I'm a bit short in time to check this in detail. I would like to suggest that you inject the packaging either in SVN or Git at your preference according to Debian Med team policy[1] to enable more easy. Given that your final target invesalius is just in Debian Med SVN I guess this should be no real problem for you and it would help more simple cooperation (I would have simply added the Build-Depends and some other polishing). > It takes so much time to package because I was busy converting our svn > repository to git. Now, InVesalius code is hosted at > https://github.com/invesalius/invesalius3. It would be perfectly fine to switch the Debian packaging from SVN to Git as well. Just tell me if I should give you a kickstart into this and move the packaging accroding to the layout as described in our policy[1]. Kind regards and 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/20121102094333.gc4...@an3as.eu
Re: Packaging Ray for Debian Med
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. 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
Re: Packaging Ray for Debian Med
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 co
Re: Packaging Ray for Debian Med
Thanks ! This is exactly what I was looking for. On 11/02/2012 10:09 AM, Olivier Sallou wrote: 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
Re: Packaging Ray for Debian Med
Thanks Tim, I merged your patch. I will restructure my files according to the Debian git policy. (I am reading it right now). I added my SSH key so I will get access in less than 1 hour. The Debian project is really organized, I like that a lot ! For ray debian/2.1.0-3, I will do these 4 things: 1. Add Tim Booth for the packaging copyright 2 Restore HAVE_LIBBZ2=y and HAVE_LIBZ=y somewhere Otherwise, the code that uses libz and libbz2 are not compiled at all. Is there a better place than the rules file ? Maybe I can add a patch against the Makefile directly ? What do you think ? 3. Split in 3 packages: ray (Ray + man), ray-doc (Documentation directories), ray-extra (scripts) Ray really just needs mpi-default-bin and bz2 and z libraries for the runtime. The provided scripts should go in ray-extra. As I understand, I can put several packages in the control file, and possibly tell in the rules file where each file should go. Is that right ? 4. move man.1 in a patch in patches Just to be pedantic to what is provided in the upstream tarball. On 11/02/2012 11:31 AM, Tim Booth wrote: Hi Sébastien, Ok, you seem to have got a handle on Debian packaging without much of a problem. I've made some tweaks to the package (see the changelog in the attached patch). The main issue was that compilation failed on Ubuntu at the linking stage: --- tbooth@balisaur[ray_2.1.0]mpicxx -Wl,-Bsymbolic-functions -Wl,-z,relro -lz -lbz2 code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.a -o Ray code/TheRayGenomeAssembler.a(FastqGzLoader.o): In function `FastqGzLoader::open(std::basic_string, std::allocator >, int)': FastqGzLoader.cpp:(.text+0x39): undefined reference to `gzopen' FastqGzLoader.cpp:(.text+0x6f): undefined reference to `gzgets' FastqGzLoader.cpp:(.text+0x8d): undefined reference to `gzclose' FastqGzLoader.cpp:(.text+0x9a): undefined reference to `gzopen' code/TheRayGenomeAssembler.a(FastqGzLoader.o): In function `FastqGzLoader::load(int, ArrayOfReads*, MyAllocator*, int)': FastqGzLoader.cpp:(.text+0x15e): undefined reference to `gzgets' FastqGzLoader.cpp:(.text+0x1b4): undefined reference to `gzclose' code/TheRayGenomeAssembler.a(BzReader.o): In function `BzReader::readLine(char*, int)': BzReader.cpp:(.text+0x82a): undefined reference to `BZ2_bzRead' BzReader.cpp:(.text+0x8f5): undefined reference to `BZ2_bzReadOpen' BzReader.cpp:(.text+0x9fa): undefined reference to `BZ2_bzReadGetUnused' BzReader.cpp:(.text+0xa27): undefined reference to `BZ2_bzReadClose' collect2: ld returned 1 exit status --- But this version works - ie. simply putting the $LD_FLAGS after the input files on line 189 of the Makefile: tbooth@balisaur[ray_2.1.0]mpicxx -Wl,-Bsymbolic-functions -Wl,-z,relro code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.a -lz -lbz2 -o Ray For now I added a patch (see debian/patches) but do you think you want to make the change in the main source code or does that break something else? Cheers, TIM On Fri, 2012-11-02 at 03:55 +, Sébastien Boisvert wrote: Hello Tim, Thank you for your wise guidance regarding Debian package preparation. 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 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. Can you review what I did ? Sébastien -- 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/5093f7ef.3050...@ulaval.ca
Re: Packaging Ray for Debian Med
Hi, On Fri, Nov 02, 2012 at 12:42:23PM -0400, Sébastien Boisvert wrote: > The Debian project is really organized, I like that a lot ! :-) > For ray debian/2.1.0-3, I will do these 4 things: > > 1. Add Tim Booth for the packaging copyright I would also suggest to add him in debian/control as follows: Maintainer: Debian Med Packaging Team Uploaders: Sébastien Boisvert , Tim Booth In the Debian Med team we are using the team mailing list as maintainer so everybody gets informed about uploads, bugs etc. It is easy to add other uploaders (people feeling responsible and adding code to the packaging). > 2 Restore HAVE_LIBBZ2=y and HAVE_LIBZ=y somewhere > > Otherwise, the code that uses libz and libbz2 are not compiled at all. > Is there a better place than the rules file ? No, the rules file is perfectly the correct way to specify this. The only nitpicking I have is that you should please remove the "Sample debian/rules ..." comment template - your rules file is simply no sample, right. ;-) > Maybe I can add a patch against the Makefile directly ? > What do you think ? The result will finally be the same and it is rather a matter of taste. I would leave it in debian/rules because in a patch it might be a bit more hidden. If you prefer a pretty clean debian/rules file a patch is fine as well. > 3. Split in 3 packages: ray (Ray + man), ray-doc (Documentation directories), > ray-extra (scripts) > > Ray really just needs mpi-default-bin and bz2 and z libraries for the runtime. > The provided scripts should go in ray-extra. > > As I understand, I can put several packages in the control file, Yes, your split sounds very reasonable. > and possibly tell in the rules file where each file should go. > Is that right ? You could use override_dh_install in debian/rules however, I (strongly) prefer using files named ray.install ray-doc.install ray-extra.install which organise the moving of files in a more transparent way. Just have a look into man dh_install how it works. > 4. move man.1 in a patch in patches > > Just to be pedantic to what is provided in the upstream tarball. Usually we are keeping freshly written manpages in debian/*.1 and install these using a file ray.manpages containing just this string (see dh_installman). A patch would be fine as well but editing a plain file is way more comfortable than handling a patch and it is easier to point upstream to a plain file when asking upstream to include this file. Keep on your good work and feel free to keep on asking if something else might remain unclear 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/20121102175800.ga18...@an3as.eu
Re: Packaging Ray for Debian Med
Hi ! The Ray Debian package is now at http://anonscm.debian.org/gitweb/?p=debian-med/ray.git;a=summary I fixed everything that lintian reported except these: W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-color-distributions.R #!/usr/bin/Rscript W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-coverage-distribution.R #!/usr/bin/Rscript W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-library-distribution.R #!/usr/bin/Rscript r-base-core installs /usr/bin/Rscript so it is legit. Maybe /usr/bin/Rscript should be added in /usr/share/lintian/checks/scripts (package lintian) Using /usr/bin/env Rscript also throws unusual-interpreter. See below for my specific answers. On 11/02/2012 01:58 PM, Andreas Tille wrote: Hi, On Fri, Nov 02, 2012 at 12:42:23PM -0400, Sébastien Boisvert wrote: The Debian project is really organized, I like that a lot ! :-) For ray debian/2.1.0-3, I will do these 4 things: 1. Add Tim Booth for the packaging copyright I would also suggest to add him in debian/control as follows: Maintainer: Debian Med Packaging Team Uploaders: Sébastien Boisvert , Tim Booth In the Debian Med team we are using the team mailing list as maintainer so everybody gets informed about uploads, bugs etc. It is easy to add other uploaders (people feeling responsible and adding code to the packaging). Done. 2 Restore HAVE_LIBBZ2=y and HAVE_LIBZ=y somewhere Otherwise, the code that uses libz and libbz2 are not compiled at all. Is there a better place than the rules file ? Finally, this was not necessary because Tim's patch did not remove this -- I misread his patch this morning. No, the rules file is perfectly the correct way to specify this. The only nitpicking I have is that you should please remove the "Sample debian/rules ..." comment template - your rules file is simply no sample, right. ;-) Maybe I can add a patch against the Makefile directly ? What do you think ? The result will finally be the same and it is rather a matter of taste. I would leave it in debian/rules because in a patch it might be a bit more hidden. If you prefer a pretty clean debian/rules file a patch is fine as well. 3. Split in 3 packages: ray (Ray + man), ray-doc (Documentation directories), ray-extra (scripts) Ray really just needs mpi-default-bin and bz2 and z libraries for the runtime. The provided scripts should go in ray-extra. As I understand, I can put several packages in the control file, Yes, your split sounds very reasonable. and possibly tell in the rules file where each file should go. Is that right ? You could use override_dh_install in debian/rules however, I (strongly) prefer using files named ray.install ray-doc.install ray-extra.install which organise the moving of files in a more transparent way. Just have a look into man dh_install how it works. Using the .install did the job easily. Thanks. 4. move man.1 in a patch in patches Just to be pedantic to what is provided in the upstream tarball. Usually we are keeping freshly written manpages in debian/*.1 and install these using a file ray.manpages containing just this string (see dh_installman). A patch would be fine as well but editing a plain file is way more comfortable than handling a patch and it is easier to point upstream to a plain file when asking upstream to include this file. I added debian/Ray.1 that is simplier than a patch. Keep on your good work and feel free to keep on asking if something else might remain unclear My question: what's next ? I think debian/2.1.0-4 should do it, unless you have other suggestions, in which case I will gladly implement them. Andreas. -- 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/509435dd.6020...@ulaval.ca
Re: Packaging Ray for Debian Med
Hi ! The Ray Debian package is now at http://anonscm.debian.org/gitweb/?p=debian-med/ray.git;a=summary I fixed everything that lintian reported except these: W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-color-distributions.R #!/usr/bin/Rscript W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-coverage-distribution.R #!/usr/bin/Rscript W: ray-extra: unusual-interpreter ./usr/share/ray/scripts/plot-library-distribution.R #!/usr/bin/Rscript r-base-core installs /usr/bin/Rscript so it is legit. Maybe /usr/bin/Rscript should be added in /usr/share/lintian/checks/scripts (package lintian) Using /usr/bin/env Rscript also throws unusual-interpreter. See below for my specific answers. On 11/02/2012 01:58 PM, Andreas Tille wrote: Hi, On Fri, Nov 02, 2012 at 12:42:23PM -0400, Sébastien Boisvert wrote: The Debian project is really organized, I like that a lot ! :-) For ray debian/2.1.0-3, I will do these 4 things: 1. Add Tim Booth for the packaging copyright I would also suggest to add him in debian/control as follows: Maintainer: Debian Med Packaging Team Uploaders: Sébastien Boisvert , Tim Booth In the Debian Med team we are using the team mailing list as maintainer so everybody gets informed about uploads, bugs etc. It is easy to add other uploaders (people feeling responsible and adding code to the packaging). Done. 2 Restore HAVE_LIBBZ2=y and HAVE_LIBZ=y somewhere Otherwise, the code that uses libz and libbz2 are not compiled at all. Is there a better place than the rules file ? Finally, this was not necessary because Tim's patch did not remove this -- I misread his patch this morning. No, the rules file is perfectly the correct way to specify this. The only nitpicking I have is that you should please remove the "Sample debian/rules ..." comment template - your rules file is simply no sample, right. ;-) Maybe I can add a patch against the Makefile directly ? What do you think ? The result will finally be the same and it is rather a matter of taste. I would leave it in debian/rules because in a patch it might be a bit more hidden. If you prefer a pretty clean debian/rules file a patch is fine as well. 3. Split in 3 packages: ray (Ray + man), ray-doc (Documentation directories), ray-extra (scripts) Ray really just needs mpi-default-bin and bz2 and z libraries for the runtime. The provided scripts should go in ray-extra. As I understand, I can put several packages in the control file, Yes, your split sounds very reasonable. and possibly tell in the rules file where each file should go. Is that right ? You could use override_dh_install in debian/rules however, I (strongly) prefer using files named ray.install ray-doc.install ray-extra.install which organise the moving of files in a more transparent way. Just have a look into man dh_install how it works. Using the .install did the job easily. Thanks. 4. move man.1 in a patch in patches Just to be pedantic to what is provided in the upstream tarball. Usually we are keeping freshly written manpages in debian/*.1 and install these using a file ray.manpages containing just this string (see dh_installman). A patch would be fine as well but editing a plain file is way more comfortable than handling a patch and it is easier to point upstream to a plain file when asking upstream to include this file. I added debian/Ray.1 that is simplier than a patch. Keep on your good work and feel free to keep on asking if something else might remain unclear My question: what's next ? I think debian/2.1.0-4 should do it, unless you have other suggestions, in which case I will gladly implement them. Andreas. -- 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/50943676.6070...@ulaval.ca
Tophat 2.0.6 is ready for upload
Hi, New version Tophat 2.0.6 is ready for upload. I used debian/get-orig-source to make sure SeqAn was removed correctly. This is a bug fix realease. Upstream changelog: TopHat 2.0.6 release 11/02/2012 Version 2.0.6 is a maintenance release addressing some issues found in the 2.0.5 release: - corrected the indel finding algorithm that caused segmentation fault in certain cases (long_spanning_reads and tophat_reports) - fixed the Bowtie version checking code, adding support for newer, non-beta Bowtie2 versions - several minor fixes in the fusion alignment algorithm - fixed an incompatibility issue with Python versions older than 2.6 (restoring Python 2.4 compatibility) - fixed and improved the resuming option (-R/--resume) to better handle various failure/resume situations - added a warning about Bowtie1 and Bowtie2 index files in the same directory (causing trouble if they were built for different genomic sequences) Thanks, Carlos -- 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/cabgghblnplnktv23q5mkxwauxf9ilpawasmzrkggbsza6zw...@mail.gmail.com
Bowtie2 ready for upload?
Hi, I uploaded latest upstream version for Bowtie2, which dropped the beta tag. The package seems ready, but I haven't worked in this package before. Alex, could you please take a look and see if things look good. Thanks, Carlos -- 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/CABgGhBLwpish-Xc0A3pwtDmg1n7cKGAZe=xzkz-b7a5utr+...@mail.gmail.com
