Re: InVesalius packaging (Was: Open source 3D medical imaging software using wxPython)
Dear Andreas, On 23 February 2010 18:17, Andreas (Debian) wrote: > > Hi Tatiana, > > On Fri, Feb 19, 2010 at 01:57:24PM -0200, Tatiana Al-Chueyr wrote: > > > > I've uploaded it to [5]. Please, let me know if there are any problems. > > ... > > [5] > > http://svn.softwarepublico.gov.br/trac/invesalius/browser/releases/invesalius3/ubuntu32 > > I fetched this and did some enhancements regarding packaging while I was > travling by train today. Because I realised that you are a member of the > Debian Med team now I commited my packaging to > > > http://svn.debian.org/wsvn/debian-med/trunk/packages/invesalius/trunk/?rev=0&sc=0 > That is great! Thanks! I've already checked it out, but I have some remarks and doubts. :: Remarks 1. InVesalius is licensed only by GNU GPL 2 (not above) - this is really important because GPL2 is already translated to Portuguese, and according to Brazilian law, the license has to be available in Portuguese. Although FSF doesn't accept the Portuguese translation, that is what is accepted by our legislation. Also, there was a legal study regarding GPL 2 that proved it is constitutional... And there is no study regarding GPL 3. 2. Although we are the authors, the copyright is of the research centre where we work (Centro de Tecnologia da Informação Renato Archer), because they sponsored the project. :: Questions i. What should we do (on the file) regarding dependencies that are not needed, but provide more features to InVesalius? Ins't there a tag "Recommends:"? Currently we provide support to Analyze files on the command line - but this feature depends on python-insighttoolkit_3.16 ii. Is there something like "Authors" on the file? Can we add it? iii. Isn't python-multiprocessing included in python2-6? iv. Some (Ubuntu) users reported a problem regarding InVesalius dependency on python-wxgtk2.8. Apparently if one had a previous version of python-wxgtk installed, InVesalius would try to use that older version, and not 2.8 - even though 2.8 was also installed. This was only solved uninstalling the previous wxgtk version. Do you have any guess about this - so we don't need to unistall the previous version? v. Will these files work under Ubuntu as well? vi. How should we do when InVesalius needs a new dependency that is not available at Debian repository? (e.g. Sigar) or a newer version of a certain library (e.g. imagine VTK 5.6 has just been release and we decide using it in InVesalius, but only VTK 5.4 is available in debian repository...) > Please check this out because the changes will make most probably also your > Ubuntu packages better. I would really welcome if you would commit your > changes to this repository to cooperate in this packaging. > Ok, perfect, thanks! > > I did a lot of polishing which you will see if you compare with your > original version. Please ask if something is not clear to you or you > do not understand the motivation for the change. Thanks! I understood most of it. Just one doubt: What happened to the original makefile? It is not necessary anymore? How should we use the <10_wrapper_is_bash_script.patch>? > The current problem / blocker is the lack of the prerequisite sigar[1]. > I have no idea about this software and I do not know whether I will find > time to package this - probably not in the near future. Any volunteer > to step into this? Tatjana, do you know whether sigar is a really needed > component for InVesalius or is it just enhancing the functionality. Can we (Thiago) pack SIGAR oficially? We only would need some advices and enhacements... I guess this is something more general, not only Debian Med. SIGAR is a very interesting tool. It is multi-platform (GNU Linux, Windows, MacOS,Solaris, among others - both 32-64b) and provides several features for analyzing hardware, such as: memory, file-system, swap, processor, etc. Despite this, it is available for Java, Perl, Python, Ruby, Lua, PHP, among others. SIGAR is really needed in InVesalius. We use it to see the system configuration and, depending on the memory available and if the OS is 32/64 bits, we change the resolution of the image volume, so the user can open really large DICOM sequences in a computer that is not that good. > Kind regards > Best regards and good skiing! :) Tatiana > Andreas. > > [1] http://support.hyperic.com/display/SIGAR/Home > > -- > http://fam-tille.de -- Tatiana Al-Chueyr Sent from Campinas, SP, Brazil -- 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/e4b8e4a61002251029i5c3a94d5je4b043ae893d7...@mail.gmail.com
Re: InVesalius packaging (Was: Open source 3D medical imaging software using wxPython)
On Thu, Feb 25, 2010 at 03:29:07PM -0300, Tatiana Al-Chueyr wrote:
> iii. Isn't python-multiprocessing included in python2-6?
Yes.
> iv. Some (Ubuntu) users reported a problem regarding InVesalius
> dependency on python-wxgtk2.8. Apparently if one had a previous
> version of python-wxgtk installed, InVesalius would try to use that
> older version, and not 2.8 - even though 2.8 was also installed. This
> was only solved uninstalling the previous wxgtk version. Do you have
> any guess about this - so we don't need to unistall the previous
> version?
a) on Debian people can use the update-alternatives
mechanism to tell Debian which wxPython should be
the default one
b) people should install python-wxversion to be able
to programmatically select which wxPython version
to use
c) InVesalius should do something like this to make
sure it got the proper version:
import wxversion
wxversion.ensureMinimal('2.8-unicode', optionsRequired=True)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
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/20100225201555.ga2...@merkur.hilbert.loc
Translation of Debian Med projects
Dear all, I've seen the webpage on Alioth related to the translation of the Debian Med projects [1]. Then, I decided sharing our team experience on this subject, and to learn with those who'd like to share theirs. My experience is: to develop a free software in the medical area is non trivial, due to the generally large gap between surgeons/physicians and developers. We've recently added InVesalius to Transifex [2], so we could have more contribution on the software translation. Transifex is a web application to organize translation teams and check the status of the translations. It allows users to edit translations online, through a very intuitive interface. Unlike Rosetta (Lauchpad), it allows you to add source code from any (supported) external repository (svn, hg, ...). After adding InVesalius to Transifex (end of January 2010) a guy sent to us the complete translation to French. Also, both Greek and Chinese translations are on the way (~60% each). Until then, I was the resposible for Portuguese and Spanish translations and we had no help nor in this languages, nor in new ones... Also, thanks to Transifex, surgeons (medical and odontological) are starting to get involved to translation. As most developers, I'd rather edit the po files on vim. But, even though, Transifex can be really helpful, at least to analyze the translations status. It has helped us to involve the community on the translation process... Also, anyone who is interested on contributing to the translation... is welcome! ;) Best regards, Tatiana [1] http://debian-med.alioth.debian.org/locales.php [2] http://www.transifex.net/projects/p/invesalius/c/gui/
Re: Translation of Debian Med projects
Am Donnerstag 25 Februar 2010 21:17:09 schrieb Tatiana Al-Chueyr: > Dear all, > > I've seen the webpage on Alioth related to the translation of the Debian > Med projects [1]. Then, I decided sharing our team experience on this > subject, and to learn with those who'd like to share theirs. > > My experience is: to develop a free software in the medical area is non > trivial, due to the generally large gap between surgeons/physicians and > developers. > > We've recently added InVesalius to Transifex [2], so we could have more > contribution on the software translation. Transifex is a web application to > organize translation teams and check the status of the translations. It > allows users to edit translations online, through a very intuitive > interface. Unlike Rosetta (Lauchpad), it allows you to add source code from > any (supported) external repository (svn, hg, ...). > We have a similar experience for GNUmed. We use the launchpad feature. I have only recently heard of transifex. Launchpad has helped us. Since a little while ago there is interaction between code and launchpad translations. Sebastian Hilbert -- 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/201002252212.21523.sebastian.hilb...@gmx.net
Re: InVesalius packaging (Was: Open source 3D medical imaging software using wxPython)
Dear Tatiana, On Thu, Feb 25, 2010 at 03:29:07PM -0300, Tatiana Al-Chueyr wrote: > > That is great! Thanks! I've already checked it out, but I have some > remarks and doubts. At first: Please do not take my work as kind of law - while I have some experience in Debian packaging if have none at all in InVesalius - so chances are good that I made mistakes. Just fix them in SVN! > :: Remarks > > 1. InVesalius is licensed only by GNU GPL 2 (not above) - this is > really important because GPL2 is already translated to Portuguese, and > according to Brazilian law, the license has to be available in > Portuguese. Although FSF doesn't accept the Portuguese translation, > that is what is accepted by our legislation. Also, there was a legal > study regarding GPL 2 that proved it is constitutional... And there is > no study regarding GPL 3. So this is simple a bug introduced by me. Feel free to fix any of this you might notice. > 2. Although we are the authors, the copyright is of the research > centre where we work (Centro de Tecnologia da Informação Renato > Archer), because they sponsored the project. Simply inject any information which is needed in debian/copyright. > :: Questions > > i. What should we do (on the file) regarding dependencies > that are not needed, but provide more features to InVesalius? Ins't > there a tag "Recommends:"? Currently we provide support to Analyze > files on the command line - but this feature depends on > python-insighttoolkit_3.16 Yes, please use Recommends for packages which are not absolutely needed. In fact it is suggested to use hard Depends only for packages which would make a package absolutely useless if they would be missing. The packages in Recommends are installed by apt by default if you don't explicitely ask for leaving them out (as you might like to do on embedded systems or things like that). So under normal conditions you can expect the Recommended packages to be installed. > ii. Is there something like "Authors" on the file? Can we add it? Just have a look at http://dep.debian.net/deps/dep5/ as specified in the first row of this file. In this DEP5 it is suggested to use "Maintainers" (I personally see a chance to mix this up with Debian maintainer, but that's the suggestion I would follow). And yes, finally you are free to add a field - there is currently no policy about this and you are free to consider the file as a free form text file. > iii. Isn't python-multiprocessing included in python2-6? That's my fault because I was tricked by the not yet default Python 2.6 and I was running InVesalius under Python 2.5. Perhaps it might make sense to verify the Python version if you are really relying on 2.6 features. PLease also note: While I added python-support in the Build-Depends(-Indep) the package does not yet comply with the Python policy ... I did not yet finished this step until now. > iv. Some (Ubuntu) users reported a problem regarding InVesalius > dependency on python-wxgtk2.8. Apparently if one had a previous > version of python-wxgtk installed, InVesalius would try to use that > older version, and not 2.8 - even though 2.8 was also installed. This > was only solved uninstalling the previous wxgtk version. Do you have > any guess about this - so we don't need to unistall the previous > version? I think Karsten has answered this question yet. > v. Will these files work under Ubuntu as well? I think if you follow Karsten's advise it will work under Debian and Ubuntu (but I admit I'm not sure). > vi. How should we do when InVesalius needs a new dependency that is > not available at Debian repository? (e.g. Sigar) or a newer version > of a certain library (e.g. imagine VTK 5.6 has just been release and > we decide using it in InVesalius, but only VTK 5.4 is available in > debian repository...) Well, care for the needed dependency first. That's hard - but there is no other option and my guess is that this task is the hardest one we will have to tackle. > > Please check this out because the changes will make most probably also your > > Ubuntu packages better. I would really welcome if you would commit your > > changes to this repository to cooperate in this packaging. > > > Ok, perfect, thanks! Obviosely not perfect ... but hopefully helpful as well as these hints. Please trust on this list (no need to CC me personally) the next week because I'll be on vacation from Saturday on. > Thanks! I understood most of it. Just one doubt: > What happened to the original makefile? It is not necessary anymore? Try man dh The line dh --with quilt $@ in debian/rules does "anything which seems to make sense". Calling the upstream Makefile is something which just makes sense. Check the *.build logfile if in doubt. > How should we use the <10_wrapper_is_bash_script.patch>? I'd suggest applying it in upstream InVesalius and removing it from the debian directory. The only reason why I did not yet pointed to it is that I
