Re: I'd like to move Invesalius packaging from SVN to Git (Was: r23899 - in trunk/packages/invesalius/trunk/debian: . source)
Hi Andreas, Ah, I'm using different emails at changelog and in the control files. Sorry. I prefer to use CTI email, since it's the one I use here in Debian-Med. This happen, maybe, because I created an Ubuntu-PPA [1] to package InVesalius, and there I'm using my gmail email. I used git clone ssh://git.debian.org/git/debian-med/invesalius.git to get files. I need to generate the orig file or *gbp buildpackage *will create to me? Thanks for the help! [1] - https://launchpad.net/~tfmoraes/+archive/ubuntu/invesalius-ppa On Tue, Aug 15, 2017 at 12:20 PM Andreas Tille <andr...@fam-tille.de> wrote: > Hi Thiago, > > On Mon, Aug 14, 2017 at 05:44:35PM +, Thiago Franco Moraes wrote: > > Hi Andreas, > > > > Yeah, we released a new version of InVesalius in the last friday. Now I'm > > packaging it. > > > > Git is much better to work then SVN. You'll notify me when its complete? > > It is moved now to Git and uploaded with > > Vcs-Git: https://anonscm.debian.org/git/debian-med/invesalius.git > > Just let me know if you need some hints for gbp (git-buildpackage). > May be the Debian Med policy gives you sufficient hints about this. > > Please remember in general: The ID of the changelog owner should always > match the Uploaders field in debian/control. No idea what you want to > use there but if you want to use something different in debian/changelog > please adapt in debian/control next time. > > Thanks for maintaining invesalius > > Andreas. > > -- > http://fam-tille.de >
Re: InVesalius 3.0.1 with VTK6 support
I've added the keyword and comment fields to the .desktop file and commited to Debian-med SVN. It seems to be correct because if I search the invesalius's keywords in the krunner, it show InVesalius. But I'm not sure, since I don't use Debian unstable and the Ubuntu lintian doesn't search for this error in the .desktop file. On Thu, Jun 30, 2016 at 3:05 PM Thiago Franco Moraes <tfmor...@cti.gov.br> wrote: > Hi Andreas, > > On Thu, Jun 30, 2016 at 11:56 AM Andreas Tille <andr...@an3as.eu> wrote: > >> Hi Thiago, >> >> On Thu, Jun 30, 2016 at 10:18:00AM -0300, Thiago Franco de Moraes wrote: >> > >> > I've updated InVesalius 3 to the new version. This version has support >> to VTK6. The changes are in the Debian-Med svn. It seems to be lintian >> clean. >> >> VTK6 is very good news! Thanks for your work on this. >> >> > Thanks! I was out for some time because our project ended temporarily. Now > we are back again. Because of that, the conversion to VTK6 was delayed. > > >> The package was not fully lintian clean (under unstable lintian) but I've >> fixed some small issues. There is one left that might interest you also >> as upstream since you might like to provide a proper desktop file: >> >> >> I: invesalius: desktop-entry-lacks-keywords-entry >> usr/share/applications/invesalius-3.0.desktop >> N: >> N:This .desktop file does either not contain a "Keywords" entry or it >> does >> N:not contain any keywords not already present in the "Name" or >> N:"GenericName" entries. >> N: >> N:.desktop files are organized in key/value pairs (similar to .ini >> files). >> N:"Keywords" is the name of the entry/key in the .desktop file >> containing >> N:keywords relevant for this .desktop file. >> N: >> N:The desktop-file-validate tool in the desktop-file-utils package is >> N:useful for checking the syntax of desktop entries. >> N: >> N:Refer to >> N: >> https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html >> , >> N:https://bugs.debian.org/693918, and >> N:https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords >> for >> N:details. >> N: >> N:Severity: wishlist, Certainty: certain >> N: >> N:Check: menu-format, Type: binary >> >> >> I have uploaded despite this minor issue and may be we can fix this in a >> later version. >> > > Ok. I'll take a look into this problem. > > >> >> Thanks again >> >> > Thank you for your work! > > >> Andreas. > > >> >> -- >> http://fam-tille.de >> >
Re: Updated the package to new invesalius version
On Fri, Jul 17, 2015 at 3:10 PM Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Fri, Jul 17, 2015 at 02:46:46PM -0300, Thiago Franco de Moraes wrote: Thanks! I've just seen that InVesalius package was accepted at Unstable. :-) BTW, in your development you should concentrate on Python3 migration. Sooner or later Debian will drop Python2 support and it seems sensible to keep that in mind rather sooner than later. I was thinking about this some days ago, not only about Python3 but also about the migration to VTK6. 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: https://lists.debian.org/20150717180944.gq13...@an3as.eu
Re: InVesalius 3b5
Hi Andreas, On Thu, Apr 24, 2014 at 3:32 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, thanks for updating the invesalius package. On Wed, Apr 23, 2014 at 03:06:45PM -0300, Thiago Franco de Moraes wrote: Hi all, We released a new version of InVesalius on the last thursday and now I'm working on the Debian package. I updated all necessary fields from debian folder and created some new files. Since we are using now Cython (so is necessary to compile) in one of the modules we use, I created a new sub-package, called invesalius-bin to keep it. The invesalius-bin is arch-dependent, and my idea is to put all cython stuff we develop in this sub-package. Apparently it's all OK except for 2 things: - When I create the packages it runs the command to compile the cython two times, one in dh_auto_build and other in dh_auto_install. It's not a problem exactly, but it's processing lost ... To solve this I'll have to override dh_auto_install? Most probably you need to tell dh_auto_install not to repeat this step. I suspect that Invesalius' build system might deserve some optimisation to prevent this. I guess you can get more detailed help at debian-pyt...@lists.debian.org. OK! - Lintian gives me this warning invesalius-bin: arch-dependent-file-in-usr-share usr/share/invesalius/invesalius/data/mips.so. But invesalius-bin is arch dependent, in debian/control it's marked as Architecture: any, is there some details I'm forgetting? I have the impression it happens because this file (mips.so) is placed in a folder created by the invesalius package (which is arch independent), but I'm not sure. Well, lintian does not say that the package is arch independent. It says that there is an arch-dependent file in /usr/share where such files do not belong to - and lintian is correct here. You need to move this file to /usr/lib. In case the file will be found by Invesalius there I also recommend to consult the Debian Python list where you can most probably get helpful hints for a sensible placement of files. I've understood. I'll post this problem there. I think I'll have to tell the setup.py to install this file in python dist-packages and I'll have to patch InVesalius to import this file from there. PS. I saw invesalius will be removed from Debian Testing because of a problem with libvtk-java. What's the situation of this? Sorry for not manifest me earlier, but I was out for more than a month and I had some problems with my email. Several packages were removed and I really hope that libvtk maintainers will care about this. As far as I understood the issue is not too hard to fix and packages will automigrate back to testing once this has happened. Providing libvtk maintainers with patches (if not yet done) is always welcome. :-) Kind regards Andreas. -- http://fam-tille.de Thanks Andreas!
Re: Please upload screenshot of invesalius (and others for sure if you like)
Hi Andreas, Done! A interesting news about the use of InVesalius and Blender. Cicero Moraes, a guy here from Brazil, is working on the reconstruction of Saint Anthony of Padua (or Lisbon) face using InVesalius and Blender. Saint Anthony is very popular here in Brazil, in Portugal and Italy. Here a detailed text about this http://www.bwcomunica.com.br/noticia/4607 (pt-br) Thanks! On Tue, Jan 28, 2014 at 6:19 PM, Andreas Tille andr...@an3as.eu wrote: Hi, I checked Debian Med tasks pages and specifically noticed that invesalius might be easily be enhanced by a nice screenshot: http://blends.debian.org/med/tasks/imaging#invesalius For sure everybody can feel free to provide screenshots at all places where you can see the yellow button featuring the string Upload screenshot Just follow the link and enhance Debian (Med) with nice screenshots! 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/20140128181950.ga25...@an3as.eu
Re: InVesalius new version and copyright
Hi Andreas, On Tue, Apr 2, 2013 at 6:21 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Mon, Apr 01, 2013 at 03:10:18PM -0300, Thiago Franco de Moraes wrote: We released a new InVesalius version some days ago. I committed the changes related to packaging this new version. The only question blocking me to submit this new version is a issue about copyright. As I've said in my last email to Debian Med, we are using some preset files from OsiriX. OsiriX is a LGPL-3 [1], and its copyright is 2003-2010 (c) Antoine Rosset. As far as I can see, the preset files have the same license and copyright. I sent an email to OsiriX to ensure those informations, but they didn't answered me. My question to you is: What do I do in this case? As far as I can obtain from this information we need to assume that the preset files are released under the same lincense as the software itself. This is under the assumption that the preset files can be downloaded inside the same archive as the complete software. It is usual to assume that everything in one tarball follows the main license statement except some explicite exception is given. The debian/copyright files are following the same logic when specifying Files: * and mentioning single Files: exceptions later. Done. I did not inspected such a preset file as you are mentioning but simply guessing from the name it looks like configuration and I do not think that such files are some specific copyright property compared to the remaining code - so I guess we are safe here. I Found another software (it seems to be open source) which use these files: http://www.atamai.com/cgi-bin/viewvc.cgi/MacOSX/Epilepsia/CLUTs/?logsort=cvshideattic=0sortby=filesortdir=downpathrev=HEAD Simply mention the files in debian/copyright with an explicite Comment to make ftpmasters aware of this - they have the final say anyway. Done. Kind regards Andreas. -- http://fam-tille.de I took the opportunity and I updated the InVesalius homepage in debian/control and debian/invesalius-3.0.1. Yes, InVesalius have a new homepage[1] now. Ah, I added a new patch to make invesalius opens the sample file inside the /usr/share/doc/invesalius-examples/examples/ since the sample file is not inside the source code folder. I think it's a good idea. I checked the package and it seems to be lintian free. Thanks! [1] - http://www.cti.gov.br/invesalius/
Re: InVesalius new version and copyright
On Tue, Apr 2, 2013 at 11:15 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago On Tue, Apr 02, 2013 at 11:02:16AM -0300, Thiago Franco Moraes wrote: ... I checked the package and it seems to be lintian free. Does this mean I should have a look whether it is ripe for an upload to unstable? Yes. :) Kind regards and thanks for your work on this I must thank you too. If you come to Brazil near where I live I'll pay you a beer (or caipirinha) :) Andreas. -- http://fam-tille.de
Re: Packaging InVesalius
Hi Andreas, On Fri, Feb 8, 2013 at 5:35 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Thu, Feb 07, 2013 at 01:25:01PM -0200, Thiago Franco Moraes wrote: I created a branch (beta3) where I'm committing and cherry-picking some fixes to beta3. After these commits I update the the tag v3.0-b3. I don't know if its the better thing to do. To get the last version you need to re-download the tarball. Hmmm, while this actually helped to solve the issues I reported in my previous mail we should find some way to make sure that the content of a file with the same name will not change over time. This would specifically very important if we decide to upload the package to Debian. It would be really bad if we ship some orig.tar.gz in Debian that might be different from the downloadable file. I'd suggest to either increase the beta version number on new tarballs or you either add a date string like mmdd or alternatively some revision number from VCS to the version string. I understand. Maybe it's better to wait to the next version. I think the next is close to be released. It was fixed. You need to re-download to get the fixed one. Done and confirm that this is fixed. I also added a slight change to the packaging to prevent that .inv3 files will be compressed (to enable simply loading the examples. I found some further runtime problem: I tried File - Exit but invesalius remained (this happens with or without the inv3 example opened, if the example was opened only the images are vanishing.) I needed to press ^C in the xterm from were I started invesalius to stop the program. As a cosmetic suggestion: I really like some Ctrl-Q keybinding to exit a program - it is boring to be forced to use the mouse to quit a program. Thanks for the bug report. The Ctrl-Q is a great idea, I like a lot when I can use C-q to close an application. Kind regards Andreas. -- http://fam-tille.de Thanks! -- 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/CAMmoLX_gQP=p9YutxiO_SWAgnzwRG=Q6PnR3F3+bK7N0d==t...@mail.gmail.com
Re: Packaging InVesalius
On Thu, Feb 7, 2013 at 11:08 AM, Andreas Tille andr...@an3as.eu wrote:
On Thu, Feb 07, 2013 at 10:48:05AM -0200, Thiago Franco Moraes wrote:
sample/sample2.inv3 was created using an old InVesalius version. The
new InVesalius is not able to open, so this file is useless. It just
happened that nobody removed that file (I removed it these days).
Debian is good in QA also for upstream. ;-)
Very true. :-)
I guess it might be reasonable to wait for a new upstream tarball before
uploading to the Debian mirror to avoid distributing ftpmirrors with
unneeded bytes of some noticeable amount. What do you think?
I created a branch (beta3) where I'm committing and cherry-picking
some fixes to beta3. After these commits I update the the tag v3.0-b3.
I don't know if its the better thing to do. To get the last version
you need to re-download the tarball.
How did you realise this?
Ah, sorry. It was my mistake. I was using fakeroot debian/rules
binary to create the package, this command doesn't apply the patch.
If I use debuild it applies the patch.
I always use debuild (or rather pdebuild.)
Good to know about pdebuild. Thanks!
but this is definitely cosmetics and does not have a real influenze.
Apropos cosmetics on patches: It would be nice if you could add some
Description fields as described in DEP3[1] to let others understand
the rationale of the patch (and who wrote it when).
Done! I have not filled all fields.
Fine!
File /usr/share/invesalius-3.0/invesalius/session.py, line 269, in run
debug(Session: trying to write into inexistent file)
File /usr/share/invesalius-3.0/invesalius/utils.py, line 74, in debug
if session.debug:
AttributeError: 'Session' object has no attribute 'debug'
Fixed. It was missing python-gdcm and python-vtkgdcm as invesalius
dependency.
Probably. Unfortunately I found another issue (wonder why this did not
happened yesterday, hmmm):
$ LC_ALL=C sudo dpkg -i invesalius_3.0~b3-1_all.deb
(Reading database ... 313204 files and directories currently installed.)
Preparing to replace invesalius 3.0~b3-1 (using invesalius_3.0~b3-1_all.deb)
...
Unpacking replacement invesalius ...
Setting up invesalius (3.0~b3-1) ...
Sorry: IndentationError: ('expected an indented block',
('/usr/share/invesalius/invesalius/data/styles.py', 128, 7, 'def
OnLeftButtonDown(self, evt, str_evt):\n'))
dpkg: error processing invesalius (--install):
subprocess installed post-installation script returned error exit status 101
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for menu ...
Errors were encountered while processing:
invesalius
It was fixed. You need to re-download to get the fixed one.
Kind regards
Andreas.
--
http://fam-tille.de
There one more problem. The files in the presets/raycasting I'm using
from OsiriX. I'm almost forgot about the presets files. I contacted
them to get informations about copyright and license to put these
informations in debian/copyright. As far as I know the license is
LGPL3 and the copyright is from Antoine Rosset. But contacted them to
get the right information.
Thanks!
--
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/CAMmoLX-CVfbFdp5ik7=yrqwe_wksfnws8pgzq11+0l954hu...@mail.gmail.com
Re: Packaging InVesalius
Hi Andreas, On Mon, Jan 14, 2013 at 11:59 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Sun, Jan 13, 2013 at 05:39:11PM -0200, Thiago Franco Moraes wrote: I updated the debian/watch to match the last invesalius release. I have to use opts=dversionmangle to match the package version to git tag. I wrote a get-orig-source too (well, actually, I copied the one Andreas Tille wrote python-casmoothing :) ). Could you imagine how frequently I copy myself from other packages? :-) :) I checked the build and it creates a package. Please note that the watch file does not work 100% - I needed to manually ln -s invesalius_3.0.0b3.orig.tar.gz invesalius_3.0~b3.orig.tar.gz Without testing I think an additional filenamemangle is your friend - please check the `man uscan?. I got today (sunday) to try to resolve this, but I was not able to get filenamemangle work. Maybe I need to try more. Ah, I have to wrote a patch to change the shebang from #!/usr/local/bin/python to #!/usr/bin/python. Yep - and there are some other lintian warnings - perhaps you simply use your upstream hat to fix some permissions. I'd also think that you could do the patch above upstream - I can not really imagine that there are production boxes where you find the Python interpreter in /usr/local these days (or use env). Using the git tag invesalius-3.0.0b3 as base, I created a new branch (beta3) and I resolved these problems with permissions and the shebangs. Ah, I took the opportunity to backport some commits from trunk into this branch (Thanks git for makes it easier :) ), some of these commits fix bugs in InVesalius 3 beta 3. After the backport, I created a new tag v3.0-b3. Kind regards Andreas. -- http://fam-tille.de Thanks again! -- 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/cammolx9rj+u1gpr8ke4pt-goqrpow26ggtasrn2nr00bkir...@mail.gmail.com
Re: Packaging InVesalius
I updated the debian/watch to match the last invesalius release. I have to use opts=dversionmangle to match the package version to git tag. I wrote a get-orig-source too (well, actually, I copied the one Andreas Tille wrote python-casmoothing :) ). Ah, I have to wrote a patch to change the shebang from #!/usr/local/bin/python to #!/usr/bin/python. Best regards. On Wed, Jan 9, 2013 at 8:15 PM, Andreas Tille andr...@an3as.eu wrote: On Wed, Jan 09, 2013 at 04:25:08PM -0200, Thiago Franco Moraes wrote: I was very busy working in InVesalius source code and solving other problems, so I wasn't working in packaging InVesalius. Now I'm on vacation and I think I can take some time to work in packaging :) :-) On Mon, Dec 17, 2012 at 2:13 PM, Andreas Tille andr...@an3as.eu wrote: Please also note that `dpkg --compare-versions` does consider 3.0.0.b3-1 larger than 3.0.0-1 - so uscan might fail identifying your real release as a higher version than your beta release. I was reading [1] about this issue with version. So I'll need to use something like this as version to InVesalius: 2.99+3.0b3-0tfmoraes1? And I'll need to create a git tag with that version? Yes, this would be a possible solution. You could also simplify it by using 3.0~b3-1 As the name of invesalius repository is invesalius3, when I tag a version as 3.0~b3-1, the tarball created will be named invesalius3-3.0~b3-1. So I think I'll need to create manually a tarball named invesalius-3.0~b3-1, isn't it? Or there is a way to workaround it in github or in the watch file? Well, you download the upstream tarball invesalius-whatever_version.tgz. You rename it mv invesalius-whatever_version.tgz invesalius3-3.0~b3-1 and you be done. Usually uscan even does the renaming (or symlinking) for you. which is also considered smaller than 3.0-1. This is a bit more handsome for reading but finally it does not matter much as long as the relation of the version numbers is correct. Whatever you decide you need to use versionmangling in debian/watch file. Just tell me what kind of version numbering you prefer and whether you need help in adapting debian/watch (which is sometimes a bit tricky and some experience is helpful in the beginning). I'll try by myself. Any help I need I write here. Good luck 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/20130109221503.gt27...@an3as.eu -- 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/CAMmoLX9k5qYjkQrN_rHjU-hadg3=wktpgnxx3hw74bvdgsf...@mail.gmail.com
Re: Packaging InVesalius
Hi Andreas, I was very busy working in InVesalius source code and solving other problems, so I wasn't working in packaging InVesalius. Now I'm on vacation and I think I can take some time to work in packaging :) On Mon, Dec 17, 2012 at 2:13 PM, Andreas Tille andr...@an3as.eu wrote: Hi Tiago On Mon, Dec 17, 2012 at 01:43:34PM -0200, Thiago Franco Moraes wrote: Hi Andreas, Please also note that `dpkg --compare-versions` does consider 3.0.0.b3-1 larger than 3.0.0-1 - so uscan might fail identifying your real release as a higher version than your beta release. I was reading [1] about this issue with version. So I'll need to use something like this as version to InVesalius: 2.99+3.0b3-0tfmoraes1? And I'll need to create a git tag with that version? Yes, this would be a possible solution. You could also simplify it by using 3.0~b3-1 As the name of invesalius repository is invesalius3, when I tag a version as 3.0~b3-1, the tarball created will be named invesalius3-3.0~b3-1. So I think I'll need to create manually a tarball named invesalius-3.0~b3-1, isn't it? Or there is a way to workaround it in github or in the watch file? which is also considered smaller than 3.0-1. This is a bit more handsome for reading but finally it does not matter much as long as the relation of the version numbers is correct. Whatever you decide you need to use versionmangling in debian/watch file. Just tell me what kind of version numbering you prefer and whether you need help in adapting debian/watch (which is sometimes a bit tricky and some experience is helpful in the beginning). I'll try by myself. Any help I need I write here. Kind regards Andreas. Best regards. [1] - http://people.debian.org/~calvin/unofficial/ -- 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/20121217161313.ge3...@an3as.eu -- 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/CAMmoLX8UD8EUkrGHs06h7_kZe+r=rgvj+khvuccf2nnhuv4...@mail.gmail.com
Re: Packaging InVesalius
Hi Andreas, On Wed, Dec 12, 2012 at 5:15 PM, Andreas Tille andr...@an3as.eu wrote: On Wed, Dec 12, 2012 at 03:40:33PM -0200, Thiago Franco Moraes wrote: I've done and committed that trick with debian/links. I saw I'll need create a man to InVesalius because the package adds a script file in /usr/bin/. I think I'll work on it after the next invesalius release. Seems it is time to have a sponsor-centric view onto invesalius now. So I tried :) $ uscan --verbose --force-download -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: http://svn.softwarepublico.gov.br/trac/invesalius/browser/releases/invesalius3/ubuntu32/ http://svn.softwarepublico.gov.br/trac/invesalius/browser/releases/invesalius3/ubuntu32/invesalius_(.+)\.orig.tar.gz uscan warning: In debian/watch, no matching hrefs for watch line http://svn.softwarepublico.gov.br/trac/invesalius/browser/releases/invesalius3/ubuntu32/ http://svn.softwarepublico.gov.br/trac/invesalius/browser/releases/invesalius3/ubuntu32/invesalius_(.+)\.orig.tar.gz -- Scan finished Seems your debian/watch file is not fit to download the latest invesalius source tarball. Considering you are upstream and have some influence how to structure your download area I'd recommend making things a bit simpler for uscan. I admit the ubuntu32 location looks a bit suspicious. We are seeking for plain souce tarballs - and probably other distributors are trying the same (or just people who want to install from source). Putting this into a distributionarchitecture named directory just sounds wrong. Also the naming with 'orig' inside the names makes things quite distribution specific - usually the orig is added by uscan later on. I'd recommend to have a website which contains links to files named invesalius-version.tar.[gx]z I haven't worked at debian/watch yet. I didn't event know about the source tarball being inside the ubuntu32 folder. Now we are using Github, when I create a new tag it creates automatically an tarball following this filename pattern : https://github.com/invesalius/invesalius3/archive/invesalius-3.0.0b3.tar.gz Please also note that `dpkg --compare-versions` does consider 3.0.0.b3-1 larger than 3.0.0-1 - so uscan might fail identifying your real release as a higher version than your beta release. Ok. I'll take a look at this. Thank you! 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/20121212191509.gm30...@an3as.eu -- 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/cammolx-_bgq9gzsk4q3gkkgb29bagx4hyuqv1_xpzzt+whz...@mail.gmail.com
Re: Packaging InVesalius
Andreas, On Wed, Dec 12, 2012 at 8:46 AM, Andreas Tille andr...@an3as.eu wrote: On Tue, Dec 11, 2012 at 10:47:23AM -0200, Thiago Franco Moraes wrote: Please make very sure that the source also contains the *source* of this PDF file (whatever it might be). Yes. It contains the latex files used to build the pdf file. That's good to know. On the other hand: You also could put a symlink using a file debian/links and just symlink to the original location which might save you the patch. I chose this one. It's simpler :) Yes. That's why I was mentioning it. BTW, if the documentation is only in pt_BR I'd advise upstream to try to give at least an English translation. This is complicated. We are eager to release a new version very soon. I don't know if we'll have time to translate to English before the release. No problem with this. I just wanted to say that while documentation in /usr/share/doc/pkgname is a very important thing to have but from a general point of view if the documentation is not in English I would reduce the effort I'm investing into it (like patches etc.) Keeping things simple is in this case quite reasonable and once there might be a translation we might consider rethinking what should be done to serve our users best. I've done and committed that trick with debian/links. I saw I'll need create a man to InVesalius because the package adds a script file in /usr/bin/. I think I'll work on it after the next invesalius release. 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/20121212104655.gc30...@an3as.eu Thanks! -- 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/cammolx90xcejed3yr5c1yqn+_tmg-sf8dphhvnf+vvozpoq...@mail.gmail.com
Re: Packaging InVesalius
Hi Andreas On Mon, Dec 10, 2012 at 5:29 PM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Mon, Dec 10, 2012 at 04:14:11PM -0200, Thiago Franco Moraes wrote: InVesalius has a docs and its only file is a pdf file. Please make very sure that the source also contains the *source* of this PDF file (whatever it might be). Yes. It contains the latex files used to build the pdf file. It seems me that it is more correct put this file at the folder /usr/share/doc/invesalius/. OK. So I overrode dh_installdocs at debian/rules; code override_dh_installdocs: dh_installdocs dh_installdocs docs/user_guide_pt_BR.pdf /code Same as for dh_install you can also use the file debian/docs containing just docs/user_guide_pt_BR.pdf And I created a patch to InVesalius to change where InVesalius will find this pdf file. The problem is the process of package creation is compressing this files using gzip. I'm not sure if all pdf viewer can open gzip pdf files. Is it possible to dh_installdocs without it compressing my pdf file? override_dh_compress: dh_compress --exclude=.pdf On the other hand: You also could put a symlink using a file debian/links and just symlink to the original location which might save you the patch. I chose this one. It's simpler :) BTW, if the documentation is only in pt_BR I'd advise upstream to try to give at least an English translation. This is complicated. We are eager to release a new version very soon. I don't know if we'll have time to translate to English before the release. Thanks again Andreas. 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/20121210192942.ga21...@an3as.eu -- 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/cammolx_ygisaua8dd1nic0c6bxxsbcaoeczt+y3vtejfy0e...@mail.gmail.com
Packaging InVesalius
Hi, After the packaging of python-casmoothing I started today the packaging of InVesalius 3. I've already packaged the last version to distribute to our users [1], but this package does not follow the Debian policies. As InVesalius source code [2] does not have a Makefile I created one and put it in the InVesalius source code and the package is read to done. Now I'm trying to do the packaging in the right way, following the Debian policies. I have the following question: How can I add a file (Makefile in my case) when doing the package? I was thinking in add the Makefile in the debian folder and put in debian/rules file a command to move the Makefile to the source code. Is this a good idea. Thanks! Thiago F. Moraes [1] - http://svn.softwarepublico.gov.br/trac/invesalius/wiki/downloads/3.0-beta-3#GNULinuxInstaller [2] - https://github.com/invesalius/invesalius3 -- 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/cammolx_0iar50grh4xkv1rx_g+rqjncs3apd4xmk61wdvum...@mail.gmail.com
Re: Packaging InVesalius
On Fri, Dec 7, 2012 at 12:01 PM, Mathieu Malaterre ma...@debian.org wrote: Hi, On Fri, Dec 7, 2012 at 2:52 PM, Thiago Franco Moraes tfmor...@cti.gov.br wrote: I have the following question: How can I add a file (Makefile in my case) when doing the package? I was thinking in add the Makefile in the debian folder and put in debian/rules file a command to move the Makefile to the source code. Is this a good idea. d/rules is already a Makefile... why not copy/paste your existing Makefile into d/rules ? You may even make use of `dh_install` syntax instead of the lower level `install` command. 2cts -M Hi Mathieu, It's a great idea. I'll take a look at 'dh_install' syntax. Thanks!. -- 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/cammolx8gpxz-vcu4-wm3qx1e95hkgel4zfewcm5cwglg9rj...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, On Thu, Nov 22, 2012 at 10:31 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Thu, Nov 22, 2012 at 08:51:22AM -0200, Thiago Franco Moraes wrote: Done. The bug number is #693963. I CCed debian-med. Congratulations, I just sponsored your first Debian package. I have no idea how quick it will pass ftpmaster - in the current freeze time the delay for initial uploads might be longer than usual. Great. Many thanks! I owe you a beer :) I hope this will be helpful to let InVesalius follow soon. Sure. Thanks for your work on this Andreas. -- http://fam-tille.de Thanks again. -- 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/20121122123123.gf21...@an3as.eu -- 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/cammolx-ewxwmbreh6vhgdacyg16opwcczuyj_w_xefgy9kt...@mail.gmail.com
Bug#693963: ITP: python-casmoothing -- Context-aware mesh smoothing for biomedical applications
Package: wnpp Owner: Thiago Franco de Moraes tfmor...@cti.gov.br X-Debbugs-CC: debian-med@lists.debian.org Severity: wishlist * Package name: python-casmoothing Version : 0.1.0 Upstream Author : Thiago Franco de Moraes tfmor...@cti.gov.br * URL : https://github.com/tfmoraes/python-casmoothing * License : GPL-2.0 Programming Lang: C++, Python Description : Context-aware mesh smoothing for biomedical applications Smoothing algorithms allow to reduce artifacts from mesh generation, but often degrade accuracy. The method described in the paper Context-aware mesh smoothing for biomedical applications identifies staircase artifacts which result from image inhomogeneities and binary segmentation in medical image data for subsequent removal by adaptive mesh smoothing. Thus, context-aware smoothing enables to adaptively smooth artifact areas, while non-artifact features can be preserved. This is a implementation of this method in Cpp with Python bindings. -- 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/CAMmoLX8NrZYgaDV=NnDymT1Pj+CG6FaLysskBidBf9=pvt7...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, On Wed, Nov 21, 2012 at 12:25 PM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Wed, Nov 21, 2012 at 09:57:34AM -0200, Thiago Franco Moraes wrote: Done. I tagged the version 0.1 in github. Ah, To get a tarball that matches python-casmoothing-version pattern I had to rename the github repository to python-casmoothing. I updated this information in control and changelog files from debian packaging. Great - I verified this and commited a watch file to SVN that fetches the source package. I also think that the package deserves a bit better long description - some cut-n-pasted phrases from the paper abstract might do the trick. Done. I think it's better now. Yep - it is. Thanks for working on this. So the only remaining thing before we can upload is to file a so called ITP bug. Do you want to fire up reportbug wnpp and fill in this form to do this once you have done most of the work. If not I could do it for you. Done. The bug number is #693963. I CCed debian-med. Kind regards Andreas. -- http://fam-tille.de Thanks! -- 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/CAMmoLX_WbZtH0xm2rwbSeWP_Nc=20muxgbemngbd_wvg2cq...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, On Tue, Nov 20, 2012 at 6:16 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Mon, Nov 19, 2012 at 03:25:50PM -0200, Thiago Franco Moraes wrote: 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). Injected. Fine thanks. I had a look into this and fixed several things in the packaging specifically I now got the Build-Depends right - at least the binary package is created now. 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]. Injected using svn-inject. Not without doing some local testing before. I think I did it in the right way. The injection was perfectly fine - as I said I fixed some things - just do `svn up; svn log` . Thanks for your help! To continue with this I would really like you to consider releasing some kind of versioned source tarball to enable us writing a watch file. As far as I was told even proper tagging at github might do the trick. In case you create the tarball please make sure that it untars into a directory like python-casmoothing-version and not just simply throws all its content into the current directory. Done. I tagged the version 0.1 in github. Ah, To get a tarball that matches python-casmoothing-version pattern I had to rename the github repository to python-casmoothing. I updated this information in control and changelog files from debian packaging. I also think that the package deserves a bit better long description - some cut-n-pasted phrases from the paper abstract might do the trick. Done. I think it's better now. Kind regards and thanks for your work on this 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/20121120081609.gb27...@an3as.eu Thanks! -- 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/CAMmoLX8P3=t280-wltjwzoao9sdr_tmv_-+opzwuufk0u9m...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, I had to go to a workshop ... I could only take a look at this today. On Fri, Nov 2, 2012 at 7:43 AM, Andreas Tille andr...@an3as.eu wrote: 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). Injected. 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]. Injected using svn-inject. Not without doing some local testing before. I think I did it in the right way. 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 Thanks for your help! -- 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/cammolx8mhjn7e-druw8ipab4arueyeal8ejmb3z+2vyx-x9...@mail.gmail.com
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: InVesalius 3 Beta
On Tue, Oct 9, 2012 at 8:59 AM, Thiago Franco Moraes tfmor...@cti.gov.br wrote: On Mon, Oct 8, 2012 at 9:57 AM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: On Mon, Oct 8, 2012 at 2:47 PM, Thiago Franco Moraes tfmor...@cti.gov.br wrote: [...] already packaged in Debian. But now InVesalius is using a library I developed called Context aware smoothing [1], which is not package in Debian. Temporarily, I hope, I packaged Context aware smoothing inside the InVesalius package I created. To do that, I created a Makefile which is responsible to download, compile and put the necessary files at the right places in the InVesalius package. Yeah, it's an ugly workaround. And because of that, I duplicated the work. Don't do that. buildd machine do not have access to network when building a package. Either completely provide a convenient copy, and/or provide a debian package for Context. 2cts -- Mathieu Hi Mathieu, Thanks! Good to know that. We are planing to put all c/c++ lib we've been developing inside a folder in InVesalius. I've just seen the message from Andreas Tille. For some reason, the email with his message wasn't to me. Andreas, you are suggesting me to package Context aware smoothing (ca_smoothing to the close friends :) ) ? As We, InVesalius' developers, are planing to put all C/C++ libs together with InVesalius code (inside a proper folder) in the following versions, don't you think it's better to provide a copy of ca_smoothing inside the invesalius***.orig.tar.gz, like Mathieu suggested? Thanks! -- 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/cammolx-81lw-e9sxeex0r-ghm8s1unlpnq0nhtxkwk5hypb...@mail.gmail.com
Re: InVesalius 3 Beta
On Wed, Oct 10, 2012 at 5:56 PM, Andreas Tille andr...@an3as.eu wrote: On Wed, Oct 10, 2012 at 04:19:27PM -0300, Thiago Franco Moraes wrote: Good to know that. We are planing to put all c/c++ lib we've been developing inside a folder in InVesalius. I've just seen the message from Andreas Tille. For some reason, the email with his message wasn't to me. The reason why the mail was not explicitely send to your e-mail was most probably that I blindly followed general debian mailing list policy to *not* CC posters because it is simply assumed that people are subscribed to the list. I try to respect that newcomers might not do this and try to remember CCing them - but I might blindly fall back to the policy by simply forgetting this caution. Subscribed. Andreas, you are suggesting me to package Context aware smoothing (ca_smoothing to the close friends :) ) ? Yes! As We, InVesalius' developers, are planing to put all C/C++ libs together with InVesalius code (inside a proper folder) in the following versions, don't you think it's better to provide a copy of ca_smoothing inside the invesalius***.orig.tar.gz, like Mathieu suggested? 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? Kind regards Andreas. -- http://fam-tille.de Thanks! -- 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/CAMmoLX9+EXMjdAXiVvH_nZJnPEmXZKg0QJg3=jfw8ox8e35...@mail.gmail.com
Re: InVesalius 3 Beta
On Mon, Oct 8, 2012 at 9:57 AM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: On Mon, Oct 8, 2012 at 2:47 PM, Thiago Franco Moraes tfmor...@cti.gov.br wrote: [...] already packaged in Debian. But now InVesalius is using a library I developed called Context aware smoothing [1], which is not package in Debian. Temporarily, I hope, I packaged Context aware smoothing inside the InVesalius package I created. To do that, I created a Makefile which is responsible to download, compile and put the necessary files at the right places in the InVesalius package. Yeah, it's an ugly workaround. And because of that, I duplicated the work. Don't do that. buildd machine do not have access to network when building a package. Either completely provide a convenient copy, and/or provide a debian package for Context. 2cts -- Mathieu Hi Mathieu, Thanks! Good to know that. We are planing to put all c/c++ lib we've been developing inside a folder in InVesalius. -- 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/CAMmoLX_omz4TMQ=dghyyblmcn5qax7veusjkaf4b5u5g9pk...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, On Sat, Oct 6, 2012 at 5:14 AM, Andreas Tille andr...@an3as.eu wrote: Hi Thiago, On Fri, Sep 21, 2012 at 03:39:25PM -0300, Thiago Franco Moraes wrote: Hi, I'm one of InVesalius developers. InVesalius is a free software to visualize and handle medical images (RMI and CT), it allows the generation of stl files which can be used for rapid prototyping. InVesalius is developed at CTI (Renato Archer Technology of Information Center), a research institute of the Brazilian Science and Technology Center and is available at the homepage of Public Software Portal homepage [1]. We, the invesalius developers, have interest in including InVesalius at Debian Med project. I created a package which is available to downloading at [2]. To get the files necessary to create the package: dget -x -u http://dl.dropbox.com/u/817671/packages/packaging/invesalius3b3/invesalius_3.0.0.b3-1.dsc thanks for your interest in Debian Med and the introduction into InVesalius. As you can see in a search site:lists.debian.org/debian-med/ invesalius we had some past discussion about this (where you took part yourself as well) and we also try to keep a record about all Debian relevant information on the so called web sentinel task page http://debian-med.alioth.debian.org/tasks/imaging#invesalius As you can see there we just have some packaging stuff for InVesalius in our packaging SVN and I hope you did not duplicated the work done there. I'm afraid I will not find the time to check your work (just working down a backlog after beeing two weeks offline) but the best way to work for an integration of InVesalius into Debian would be to join the Debian Med team at Alioth as described in Debian Med policy [1]. As far as I remember Tatiana Al-Chueyr just subscribed (see [2]) to do this but so far I never observed a single commit from her. I remember that. I made some attempts at debian-mentors. In that time I had some problems with packaging SIGAR. As far as I remember, that's why InVesalius wasn't included in Debian-med. Now, InVesalius is not using SIGAR anymore, we replaced it with python-psutils, which is already packaged in Debian. But now InVesalius is using a library I developed called Context aware smoothing [1], which is not package in Debian. Temporarily, I hope, I packaged Context aware smoothing inside the InVesalius package I created. To do that, I created a Makefile which is responsible to download, compile and put the necessary files at the right places in the InVesalius package. Yeah, it's an ugly workaround. And because of that, I duplicated the work. I've just requested to join Debian Med [2]. I have no experience at creating packages, so it may be not so good. As I suggested above it would be a good idea to verify the packaging in Debian Med SVN. If you need some advise in Debian Packaging you might like to check the Mentoring Of Month [3] effort I'm running and by chance we now have a new Month without a student - so if you like we could try to push InVesalius in October 2012. It sounds great to me. Yes, I'd like to. What I need is some help to get InVesalius included at Debian Med. This could exactly be done in a MoM effort. What is necessary ... and this type of things. Hope these hints might be helpful - please excuse if my answers are more delayed than usual because of my backlog. They were very helpful. Kind regards Andreas. [1] http://debian-med.alioth.debian.org/docs/policy.html [2] https://alioth.debian.org/users/tatiana_alchueyr-guest [3] http://wiki.debian.org/DebianMed/MoM -- http://fam-tille.de Thanks! Thiago Franco de Moraes. [1] - https://github.com/tfmoraes/context_aware_smoothing [2] - https://alioth.debian.org/users/tfmoraes-guest -- 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/cammolx_jkp1hkkh05ny6_xd4ch2gssxwbmxzjqz2ubij3j8...@mail.gmail.com
InVesalius 3 Beta
Hi, I'm one of InVesalius developers. InVesalius is a free software to visualize and handle medical images (RMI and CT), it allows the generation of stl files which can be used for rapid prototyping. InVesalius is developed at CTI (Renato Archer Technology of Information Center), a research institute of the Brazilian Science and Technology Center and is available at the homepage of Public Software Portal homepage [1]. We, the invesalius developers, have interest in including InVesalius at Debian Med project. I created a package which is available to downloading at [2]. To get the files necessary to create the package: dget -x -u http://dl.dropbox.com/u/817671/packages/packaging/invesalius3b3/invesalius_3.0.0.b3-1.dsc I have no experience at creating packages, so it may be not so good. What I need is some help to get InVesalius included at Debian Med. What is necessary ... and this type of things. Thanks! [1] - http://svn.softwarepublico.gov.br/trac/invesalius [2] - http://svn.softwarepublico.gov.br/trac/invesalius/wiki/downloads/3.0-beta-3#GNULinuxInstaller -- 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/cammolx_thxckcnta1jsxu2_shn8jh9hadeflf9bna5idpcy...@mail.gmail.com
Re: Ping (Was: Status of InVesalius packaging (Was: Status of SIGAR))
On Mon, Apr 11, 2011 at 5:29 PM, Andreas Tille andr...@an3as.eu wrote: On Mon, Apr 11, 2011 at 11:18:26AM -0300, Thiago Franco Moraes wrote: Sigar is used in InVesalius to get some informations about the system, like available memory RAM, to know if it's necessary to resize the images. I don't know if it will be necessary in the next release. It would be an important piece of imformation if the SIGAR dependency would be dropped in the future. This would probably simplify packaging. Kind regards Andreas. -- http://fam-tille.de Hi Andreas, Sorry, Andreas, I don't have this information today, but it has a good probability sigar won't be necessary anymore. Thanks! -- 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/banlktimzmy1-pyortaowx0lqcxlaqcs...@mail.gmail.com
Re: Ping (Was: Status of InVesalius packaging (Was: Status of SIGAR))
On Sat, Apr 9, 2011 at 11:21 AM, Michael Hanke m...@debian.org wrote: On Thu, Apr 07, 2011 at 12:06:19PM +0200, Andreas Tille wrote: after my presentation at Med@Tel [1] I was explixitely asked for Invesalius packaging. Can somebody please give a status update about SIGAR as prerequisite. Is there any progress? If not what are the problems? AFAIK the only problem is lack of time for all involved parties. If you can afford to spend some of yours, I'm pretty sure everybody would be happy. I'm CC'ing Thiago, maybe he knows more. Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de Hi, Sigar is used in InVesalius to get some informations about the system, like available memory RAM, to know if it's necessary to resize the images. I don't know if it will be necessary in the next release. About the Sigar packaging, I did some modifications when we were talking by email, they are are in github [1]. Thanks, Thiago Franco de Moraes. [1] - https://github.com/tfmoraes/sigar -- 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/BANLkTi=bSYjfCKXUk=ka88ssf50ktgo...@mail.gmail.com
Re: Status of InVesalius packaging (Was: Status of SIGAR (Was: InVesalius packaging))
On Thu, Mar 17, 2011 at 7:36 AM, Andreas Tille andr...@an3as.eu wrote: Hi, Hi Andreas, I just wanted to give a ping about the status of InVesalius. It seems that sigar did not made some progress (at least I can not find it in Debian). Can you please give an update whether some help is needed or what issues are open? I was in touch with Michael Hanke some months ago about sigar packaging. Acording to him, these were the problems: - build dependency 'ant' seems to be missing - changelog doesn't list ITP bug number - in debian/control libsigar package has section 'lib' but should be 'libs' or removed - there are lots of *.ex files in the dsc (but not in git) - any reason to use --with-quilt in debian/rules explicitely? If yes, then quilt build-dep is missing - I saw that you build a shared lib of libsigar -- did you talk to upstream about SO version management yet? - debian.copyright is still a template - a debclean doesn't clean things properly I was trying to package the java binding but I wasn't able, so I thought to not package the java binding. But the other problems I haven't seen yet. Michael Hanke created a branch in github to do the sigar packaging (https://github.com/hanke/sigar/tree/debian) and I forked that (https://github.com/tfmoraes/sigar/tree/debian), but I didn't have time to work in it. Kind regards Andreas. Thanks! Thiago Franco de Moraes. On Mon, Mar 29, 2010 at 03:27:55PM -0400, Michael Hanke wrote: Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N: Compiled python source files should not be included in the package. N: These files should be removed from the package and created at package N: installation time in the postinst. N: N: Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.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/20100329192755.GA22928@meiner -- 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/AANLkTiÊsbJk=Y41NSta+uWMBvF+REuDPW=N=j67...@mail.gmail.com
Re: Status of InVesalius packaging (Was: Status of SIGAR (Was: InVesalius packaging))
On Thu, Mar 17, 2011 at 10:30 AM, Andreas Tille ti...@debian.org wrote: Hi, On Thu, Mar 17, 2011 at 09:08:54AM -0300, Thiago Franco Moraes wrote: I was in touch with Michael Hanke some months ago about sigar packaging. Acording to him, these were the problems: - build dependency 'ant' seems to be missing ?? $ LANG=en apt-cache policy ant | head -n 2 ant: Installed: 1.8.0-4 Ant is available since ... h, ages. Ah, that was my fault. I was only trying to package the java binding, only tests. I just forget to put ant in dependencies. - changelog doesn't list ITP bug number You should file a bug report against the virtual WNPP package - just tell me if this hint is not enough and you need more detailed information. I filled a bug report here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575873 - in debian/control libsigar package has section 'lib' but should be 'libs' or removed So why not changing to libs? Michael did that. - there are lots of *.ex files in the dsc (but not in git) This should be easy to fix. (see below) - any reason to use --with-quilt in debian/rules explicitely? If yes, then quilt build-dep is missing This should be easy to answer if there is a debian/patches dir. - I saw that you build a shared lib of libsigar -- did you talk to upstream about SO version management yet? That's a more interesting question. So did anybody talked to upstream? About that no. And it something I don't have any knowledgment. I need some help here. - debian.copyright is still a template Do you need help to fill in the text into this template? If yes just let us know. Yes, I need some help. Here http://forums.hyperic.com/jiveforums/thread.jspa?threadID=9833 I asked the sigar developers about copyright. - a debclean doesn't clean things properly This just needs to be checked (Git URL would be helpful). I was trying to package the java binding but I wasn't able, so I thought to not package the java binding. I have no idea whether this binding is actually needed for some purpose. If not we might ignore this for the moment. Otherwise it would be interesting to know exactly what the exact problem was what you stopped you. I don't have any experience with java.I don't know what files are necessaries and how to test if the java sigar bindings is working. But the other problems I haven't seen yet. Michael Hanke created a branch in github to do the sigar packaging (https://github.com/hanke/sigar/tree/debian) and I forked that (https://github.com/tfmoraes/sigar/tree/debian), but I didn't have time to work in it. Is there any reason not to use git.debian.org/git/debian-med/sigar Because sigar is using github. (or any other location at git.debian.org because it is not really Debian Med centric)? I mean finally it does not matter where the repository is located but having everything Debian packaging related at debian.org makes perfectly sense to me (and BTW has actual technical advantages for me personally). So I would really love to push this a bit. For the future: If a sponsor / mentor finds problems like those you mentioned above in a package and you have no idea how to proceed - just ask here. We are interested to move these things foreward. OK. Thanks! Kind regards and thanks for your work on this so far 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/AANLkTi=jwrbxmcxddc2esmek3b958_nof4bvegsef...@mail.gmail.com
Re: Status of InVesalius packaging (Was: Status of SIGAR (Was: InVesalius packaging))
On Thu, Mar 17, 2011 at 12:51 PM, Andreas Tille ti...@debian.org wrote: On Thu, Mar 17, 2011 at 11:45:38AM -0300, Thiago Franco Moraes wrote: Ah, that was my fault. I was only trying to package the java binding, only tests. I just forget to put ant in dependencies. OK. - changelog doesn't list ITP bug number You should file a bug report against the virtual WNPP package - just tell me if this hint is not enough and you need more detailed information. I filled a bug report here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575873 So you need to close the bug in the changelog - that's all. So why not changing to libs? Michael did that. Fine. - I saw that you build a shared lib of libsigar -- did you talk to upstream about SO version management yet? That's a more interesting question. So did anybody talked to upstream? About that no. And it something I don't have any knowledgment. I need some help here. OK, this will be left to do. - debian.copyright is still a template Do you need help to fill in the text into this template? If yes just let us know. Yes, I need some help. Here http://forums.hyperic.com/jiveforums/thread.jspa?threadID=9833 I asked the sigar developers about copyright. IMHO regarding copyright this is quite simple: Just look into the COPYRIGHT file provided inside the upstream tarball and you know what license they have. But this forum thread obviosely discusses also the SO version issue (without a reliable outcome anyway). I have no idea whether this binding is actually needed for some purpose. If not we might ignore this for the moment. Otherwise it would be interesting to know exactly what the exact problem was what you stopped you. I don't have any experience with java. Me neighter - but in case it would be needed for InVesalius we should consult Debian Java team. Could you please confirm whether Invesalius needs the Java binding or not? No, only python binding is necessary. I don't know what files are necessaries and how to test if the java sigar bindings is working. Is there any reason not to use git.debian.org/git/debian-med/sigar Because sigar is using github. That's NO reason at all. We are developing the packaging directory debian/ which can be perfectly separated from the original source code. Our SVN workflow does only store this in SVN (see Debian Med policy[1] - you might like to store this document under your pillow ;-) ). The Git addicts keep a copy of the source code as pristine-tar import in the repository (for reasons I did not fully understood but that should be discussed somewhere else and its probably me who has to learn some bits about Git - probably it is easier to create patches). However, what we are changing is the debian/ dir plus patches we are forewarding upstream. It makes perfectly sense to have this stuff all together in git.debian.org/debian-med and submit the patches to the official upstream repository (but NOT the debian/ dir which does not belong to the upstream source). I now cloned the git repository from github and realised that there is no debian/ dir which in turn I have found via I'm a novice in git. I think you have to change to debian branch. dget http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc Could anybody of you please make a proper clone of the current state *including* the latest version of debian/ in git.debian.org? I'm also fine with just keeping the debian/ dir simply in SVN because it seems not to be under Git control anyway. When inspecting all this stuff I also realised that there is one stable release of SIGAR which has version 1.6.4 and version 1.7 was (long = one year ago) promised to be released. I'd be in favour of packaging a stable release - provided that this fits the requirements of our final target InVesalius. Could you please comment whether InVesalius would build with SIGAR 1.6.4? (Sorry if this was discussed previousely.) I wasn't able to compile python binding in SIGAR 1.6.4. Kind regards 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/AANLkTi=4UWasDz9J3egemAkgtjQ=rbnnzcextpem0...@mail.gmail.com
Re: Status of InVesalius packaging (Was: Status of SIGAR (Was: InVesalius packaging))
Ah, I've done some modifications in the copyright and changelog https://github.com/tfmoraes/sigar/tree/debian/debian On Thu, Mar 17, 2011 at 2:51 PM, Thiago Franco Moraes tfmor...@cti.gov.br wrote: On Thu, Mar 17, 2011 at 12:51 PM, Andreas Tille ti...@debian.org wrote: On Thu, Mar 17, 2011 at 11:45:38AM -0300, Thiago Franco Moraes wrote: Ah, that was my fault. I was only trying to package the java binding, only tests. I just forget to put ant in dependencies. OK. - changelog doesn't list ITP bug number You should file a bug report against the virtual WNPP package - just tell me if this hint is not enough and you need more detailed information. I filled a bug report here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575873 So you need to close the bug in the changelog - that's all. So why not changing to libs? Michael did that. Fine. - I saw that you build a shared lib of libsigar -- did you talk to upstream about SO version management yet? That's a more interesting question. So did anybody talked to upstream? About that no. And it something I don't have any knowledgment. I need some help here. OK, this will be left to do. - debian.copyright is still a template Do you need help to fill in the text into this template? If yes just let us know. Yes, I need some help. Here http://forums.hyperic.com/jiveforums/thread.jspa?threadID=9833 I asked the sigar developers about copyright. IMHO regarding copyright this is quite simple: Just look into the COPYRIGHT file provided inside the upstream tarball and you know what license they have. But this forum thread obviosely discusses also the SO version issue (without a reliable outcome anyway). I have no idea whether this binding is actually needed for some purpose. If not we might ignore this for the moment. Otherwise it would be interesting to know exactly what the exact problem was what you stopped you. I don't have any experience with java. Me neighter - but in case it would be needed for InVesalius we should consult Debian Java team. Could you please confirm whether Invesalius needs the Java binding or not? No, only python binding is necessary. I don't know what files are necessaries and how to test if the java sigar bindings is working. Is there any reason not to use git.debian.org/git/debian-med/sigar Because sigar is using github. That's NO reason at all. We are developing the packaging directory debian/ which can be perfectly separated from the original source code. Our SVN workflow does only store this in SVN (see Debian Med policy[1] - you might like to store this document under your pillow ;-) ). The Git addicts keep a copy of the source code as pristine-tar import in the repository (for reasons I did not fully understood but that should be discussed somewhere else and its probably me who has to learn some bits about Git - probably it is easier to create patches). However, what we are changing is the debian/ dir plus patches we are forewarding upstream. It makes perfectly sense to have this stuff all together in git.debian.org/debian-med and submit the patches to the official upstream repository (but NOT the debian/ dir which does not belong to the upstream source). I now cloned the git repository from github and realised that there is no debian/ dir which in turn I have found via I'm a novice in git. I think you have to change to debian branch. dget http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc Could anybody of you please make a proper clone of the current state *including* the latest version of debian/ in git.debian.org? I'm also fine with just keeping the debian/ dir simply in SVN because it seems not to be under Git control anyway. When inspecting all this stuff I also realised that there is one stable release of SIGAR which has version 1.6.4 and version 1.7 was (long = one year ago) promised to be released. I'd be in favour of packaging a stable release - provided that this fits the requirements of our final target InVesalius. Could you please comment whether InVesalius would build with SIGAR 1.6.4? (Sorry if this was discussed previousely.) I wasn't able to compile python binding in SIGAR 1.6.4. Kind regards 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/aanlktinmo+fyjbik84ovex292swjhz5vhufiojqhp...@mail.gmail.com
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: On Mon, Mar 29, 2010 at 10:11:09AM -0300, Tatiana Al-Chueyr wrote: Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? I had a (quick) look at Thiagos packaging[2] and while the package builds somehow there are several lintian warnings. If you try lintian -i *.dsc *.deb you get explanations and several of these are relatively easy to fix. An absolute no go is the missing copyright information which definitely needs fixing. Please try to work down the list of lintian problems and feel free to ask for any help if something remains unclear. BTW, it might make sense to join a packaging team on alioth (python-modules-team ??) and use their SVN for the packaging stuff. This enables potential helpers for packaging to commit changes easily. Hope this helps for the moment Andreas. [1] http://lists.debian.org/debian-mentors/2010/03/msg00324.html [2] http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc -- http://fam-tille.de Thanks Andreas, I fixed some of lintian problems. One of the problems that remains is: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) Thanks!
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 4:27 PM, Michael Hanke michael.ha...@gmail.comwrote: Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.de wrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329192755.ga22...@meiner Hi Michael, No, it's not needed to stay close to the current state. I only packaged the python-bindings because the project I work [1] needs only the python-bindings. The last stable version from sigar doesn't compile, then it was necessary to compile the trunk version (svn or git). The package is in our Download page [2] (Ubuntu and Fedora). Thanks for help! [1] - http://svn.softwarepublico.gov.br/trac/invesalius/ [2] - http://svn.softwarepublico.gov.br/trac/invesalius/wiki/downloads/3.0-beta-2#GNULinuxInstaller
