Bug#692032: ITP: python-csb -- Python framework for structural bioinformatics
Package: wnpp Severity: wishlist Owner: Debian Med group * Package name: python-csb Version : 1.1.0 Upstream Author : Michael Habeck * URL : http://csb.codeplex.com/ * License : MIT Programming Lang: Python Description : Python framework for structural bioinformatics Computational Structural Biology Toolbox (CSB) is a Python class library for reading, storing and analyzing biomolecular structures in a variety of formats, with rich support for statistical analyses. CSB is designed for reusability and extensibility and comes with a clean, well-documented API following good object-oriented engineering practice. -- 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/20121101135733.10480.53572.report...@countach.comp.bio.unipd.it
[MoM] Packaging of python-csb - report #3
Hi Andreas, Your last email made things much clearer. This is what I've done since then: 1) Recreated the git repository, as I had missed the first step for creating the Debian Med standard branches 2) Submitted the ITP bug report 3) Committed the current version of the package. It currently builds with no problems (lintian reports nothing), and the resulting .deb is functional. I installed it with dpkg and the Python module is available in the system. So, very happy to have a working package, but I know there are still millions of things to fix and change. If you could take a look and point me towards the next steps, I'd greatly appreciate it. Cheers! -- 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/509287fc.6070...@tdido.com.ar
Re: InVesalius 3 Beta
On Sun, Oct 14, 2012 at 4:33 PM, Thiago Franco de Moraes < totonixs...@gmail.com> wrote: > Em 11-10-2012 03:36, Andreas Tille escreveu: > > Hi Thiago, >> >> On Wed, Oct 10, 2012 at 11:25:35PM -0300, Thiago Franco Moraes wrote: >> >>> I do not think that this was an explicite suggestion of Mathieu - he just intended to write what would be possible / acceptable packaging wise. It is definitely no good packaging practice to use convinience copies of some code which is developed somewhere else as in the source tree of the project in question. In Debian we try hard to modularise software and to not duplicate code. Just assume ca_smoothing could be used by some other imaging project. >>> >>> Ok. A question: Do you think it's better to split the package in >>> libcasmoothing and python-casmoothing or only python-casmoothing? >>> >> >> That's a bit tricky to answer for me because I have no idea about >> casmoothing at all. As a rule of thumb you should be guided by the >> answer to the question: Is there any chance that some libcasmoothing >> could be reasonably used without the Python interface or not? >> >> Kind regards >> >> Andreas. >> >> > > Hi Andreas, > > Sorry for the lack of feedback. I think I'll create only the > python-casmoothing. Before I start to package it I'll have to make some > modifications in cmake script I use to compile it. Modification related to > the installation of the python module generated in the compilation. > > Thanks! > 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 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. regards, Thiago.
Re: [MoM] Packaging of python-csb - report #3
Hi Tomás, On Thu, Nov 01, 2012 at 03:32:28PM +0100, Tomás Di Domenico wrote: > Your last email made things much clearer. Great! As far as I can see the packaging heading quite in the direction of becoming a ready package. > This is what I've done since then: > > 1) Recreated the git repository, as I had missed the first step for > creating the Debian Med standard branches These are looking fine. I had no trouble using git-buildpackage to create a package. > 2) Submitted the ITP bug report 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. > 3) Committed the current version of the package. It currently builds > with no problems (lintian reports nothing), and the resulting .deb is > functional. I installed it with dpkg and the Python module is available > in the system. Yes. > So, very happy to have a working package, but I know there are still > millions of things to fix and change. If you could take a look and point > me towards the next steps, I'd greatly appreciate it. 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. The other warning claims about large /usr/share but if I'm not totally missleaded it is rather the case that the whole package is architecture independant and thus the problem can easily fixed by Architecture: all in debian/control. 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. 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/20121101210400.ga22...@an3as.eu
Re: [MoM] Packaging of python-csb - report #3
Hi Andreas! On 01/11/12 22:04, Andreas Tille wrote: > Hi Tomás, > > On Thu, Nov 01, 2012 at 03:32:28PM +0100, Tomás Di Domenico wrote: >> Your last email made things much clearer. > > Great! As far as I can see the packaging heading quite in the direction > of becoming a ready package. :D > >> This is what I've done since then: >> >> 1) Recreated the git repository, as I had missed the first step for >> creating the Debian Med standard branches > > These are looking fine. I had no trouble using git-buildpackage to > create a package. > >> 2) Submitted the ITP bug report > > 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? >> 3) Committed the current version of the package. It currently builds >> with no problems (lintian reports nothing), and the resulting .deb is >> functional. I installed it with dpkg and the Python module is available >> in the system. > > Yes. > >> So, very happy to have a working package, but I know there are still >> millions of things to fix and change. If you could take a look and point >> me towards the next steps, I'd greatly appreciate it. > > 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? > The other warning claims about large /usr/share but if I'm not totally > missleaded it is rather the case that the whole package is architecture > independant and thus the problem can easily fixed by > >Architecture: all > > in debian/control. > Yes, changing the architecture to "all" seems to solve that issue. > 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. > Kind regards > > Andreas. > -- 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/50931110.2060...@tdido.com.ar
Packaging Ray for Debian Med
[I posted this already, but before confirming my subscription] 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 On 11/01/2012 08:10 AM, Tim Booth wrote: Hi Sébastien, Firstly, do you have regular access to a Debian/Ubuntu machine apart from CloudBioLinux? If so, what exactly is it running (for example, Ubuntu 12.04 "Precise" 64-bit)? Then you could start by reading this documentation: http://developer.ubuntu.com/packaging/html/packaging-new-software.html Do have a go at following it if you're keen, but don't be surprised if you quickly get stuck as there is is a lot to take in. What you're aiming for is to construct a "debian" directory of assorted files that tell the "debuild" system how build a .deb package file from the original tarball, as well as what other packages it depends on, how it should be indexed in the package archive, etc. If your source already supports "make; sudo make install" then the build rules are trivial but you still need to get the other meta-data in order. Here's an example: https://launchpad.net/~nebc/+archive/bio-linux/+sourcepub/2753076/+listing-archive-extra The packaging work is in the "debian.tar.gz" file; the "orig.tar.gz" file is the upstream source; the ".dsc" file is an auto-generated header file, and the two .deb files are compiled packages, made by the Launchpad auto-builders and ready to install. Once you have the "debian" directory in order, you can run the build on your local machine to make an installable .deb package. You can also generate the requisite ".dsc" file to initiate an upload to Launchpad. If you want me to make an initial package for you I'm happy to do that, or if you want to have a go yourself feel free to fire any questions my way. It's probably best to take further discussion of packaging details off the CloudBioLinux mailing list. Cheers, TIM On Thu, 2012-11-01 at 11:13 +, Sébastien Boisvert wrote: I am surely interested in that. Where do I start ? On 11/01/2012 06:21 AM, Tim Booth wrote: Dear Sébastien, Thanks for your contribution of Ray to Bio-Linux. I just wondered if 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 Making a package from scratch is a very steep learning curve, as there are so many factors to consider, but once you have one working it's pretty easy to maintain, so I'd be happy to get you started. Let me know if you are interested. Cheers, TIM On Thu, 2012-11-01 at 02:23 +, Sébastien Boisvert wrote: Hello, I am delighted that you are interested in my patchwork. I edited my work to address your concerns: git://github.com/sebhtml/cloudbiolinux.git ray-v2.1.0-in-CloudBioLinux-edited-for-brad You will find my pull request at https://github.com/chapmanb/cloudbiolinux/pull/56 at your convenience. --- $ git diff --stat master..ray-v2.1.0-in-CloudBioLinux-edited-for-brad cloudbio/custom/bio_nextgen.py | 13 + config/custom.yaml | 1 + 2 files changed, 14 insertions(+) Sébastien On 10/31/2012 10:17 PM, Sébastien Boisvert wrote: Sebastian; This is brilliant, thank you for adding the Ray build. We'd be happy to include this, please do send a pull request on GitHub and I'll merge it in. A couple of quick changes: - manifest/custom-packages.yaml does not need to be manually edited. This is automatically populated via a script when we build new releases, so ray will be included when we roll the next AMI. - contrib/flavor/cloudman/tools.yaml should also not be edited. This is John's work on a minimal Galaxy/CloudMan instance, so has items that have Galaxy wrappers. Longer term, I'd love to include it there as well. Thanks again for doing this, looking forward to rolling in the
Packaging Ray for Debian Med
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 On 11/01/2012 08:10 AM, Tim Booth wrote: Hi Sébastien, Firstly, do you have regular access to a Debian/Ubuntu machine apart from CloudBioLinux? If so, what exactly is it running (for example, Ubuntu 12.04 "Precise" 64-bit)? Then you could start by reading this documentation: http://developer.ubuntu.com/packaging/html/packaging-new-software.html Do have a go at following it if you're keen, but don't be surprised if you quickly get stuck as there is is a lot to take in. What you're aiming for is to construct a "debian" directory of assorted files that tell the "debuild" system how build a .deb package file from the original tarball, as well as what other packages it depends on, how it should be indexed in the package archive, etc. If your source already supports "make; sudo make install" then the build rules are trivial but you still need to get the other meta-data in order. Here's an example: https://launchpad.net/~nebc/+archive/bio-linux/+sourcepub/2753076/+listing-archive-extra The packaging work is in the "debian.tar.gz" file; the "orig.tar.gz" file is the upstream source; the ".dsc" file is an auto-generated header file, and the two .deb files are compiled packages, made by the Launchpad auto-builders and ready to install. Once you have the "debian" directory in order, you can run the build on your local machine to make an installable .deb package. You can also generate the requisite ".dsc" file to initiate an upload to Launchpad. If you want me to make an initial package for you I'm happy to do that, or if you want to have a go yourself feel free to fire any questions my way. It's probably best to take further discussion of packaging details off the CloudBioLinux mailing list. Cheers, TIM On Thu, 2012-11-01 at 11:13 +, Sébastien Boisvert wrote: I am surely interested in that. Where do I start ? On 11/01/2012 06:21 AM, Tim Booth wrote: Dear Sébastien, Thanks for your contribution of Ray to Bio-Linux. I just wondered if 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 Making a package from scratch is a very steep learning curve, as there are so many factors to consider, but once you have one working it's pretty easy to maintain, so I'd be happy to get you started. Let me know if you are interested. Cheers, TIM On Thu, 2012-11-01 at 02:23 +, Sébastien Boisvert wrote: Hello, I am delighted that you are interested in my patchwork. I edited my work to address your concerns: git://github.com/sebhtml/cloudbiolinux.git ray-v2.1.0-in-CloudBioLinux-edited-for-brad You will find my pull request at https://github.com/chapmanb/cloudbiolinux/pull/56 at your convenience. --- $ git diff --stat master..ray-v2.1.0-in-CloudBioLinux-edited-for-brad cloudbio/custom/bio_nextgen.py | 13 + config/custom.yaml | 1 + 2 files changed, 14 insertions(+) Sébastien On 10/31/2012 10:17 PM, Sébastien Boisvert wrote: Sebastian; This is brilliant, thank you for adding the Ray build. We'd be happy to include this, please do send a pull request on GitHub and I'll merge it in. A couple of quick changes: - manifest/custom-packages.yaml does not need to be manually edited. This is automatically populated via a script when we build new releases, so ray will be included when we roll the next AMI. - contrib/flavor/cloudman/tools.yaml should also not be edited. This is John's work on a minimal Galaxy/CloudMan instance, so has items that have Galaxy wrappers. Longer term, I'd love to include it there as well. Thanks again for doing this, looking forward to rolling in the pull request, Brad - show quoted text - Sébastien Boisvert (1):
