Re: Andreas@FOSDEM
Hi Yaroslav, On Wed, Feb 06, 2013 at 10:08:05PM -0500, Yaroslav Halchenko wrote: I wonder if there was/is/will be a video? Not yet - I'm waiting for the video upload. Andreas -- were there (interesting) questions? Not specifically interesting. sorry for ruining the show if you are about to release a full featured report ;) No need to be sorry. :-) I'll keep you informed - thanks for the interest. Kind regards Andreas. - Forwarded message from Google Alerts googlealerts-nore...@google.com - Date: Thu, 07 Feb 2013 01:06:29 + From: Google Alerts googlealerts-nore...@google.com To: yarikop...@gmail.com Subject: Google Alert - Debian Med === Web - 1 new result for [Debian Med] === Debian Med - A service for scientists in medicine and ... - Fosdem A service for scientists in medicine and biomedical research. Andreas Tille. Debian. Brussels, 02. February 2013. Andreas Tille (Debian). Debian Med. Brussels ... https://fosdem.org/2013/schedule/event/debian_med/attachments/slides/171/export/events/attachments/debian_med/slides/171/1110_Andreas.pdf - End forwarded message - -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130207030805.gv8...@onerussian.com -- 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/20130207082842.gd20...@an3as.eu
Re: New version of EDFbrowser 1.49
Hi Teunis, many thanks for keeping us updated about the new version. I can confirm that the package builds nicely. However, currently Debian is in Freeze for the new release (expected somewhen in Spring.) The rules for freeze are no new features and thus we can upload only to Debian experimental. If you consider this helpful I could do this. On the other hand I guess not so many users will see the new version there because experimental sources are not included on normal users machines. If you consider an upload to experimental sensible under this circumstances please tell me and I will do so. Otherwise I'd upload after the new Debian release. Kind regards and thanks again for keeping us updated Andreas. On Tue, Feb 05, 2013 at 04:25:45PM +0100, Teunis van Beelen wrote: EDFbrowser 1.49 is available here: http://www.teuniz.net/edfbrowser/ A viewer/toolbox for timeseries storage files like EDF, BDF, EDF+, BDF+ EDFbrowser is a viewer/toolbox/converter for timeseries storage files containing data such as EEG, EMG, and ECG signals. It supports EDF(+) and BDF(+) file formats. Apart from viewing the files, it also supports some editing operations and can convert to/from other formats. Best Regards, Teunis van Beelen -- C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee! -- 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/CAHK3Xzhe6F-9brO+LcNwaFTKnEVD=kntuwgmcjg+ezq_5az...@mail.gmail.com -- 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/20130207084954.ge20...@an3as.eu
Re: Sprint question
Hi Olivier, from a *very* quick look there is also a fast line 102 http://linienverkehr.vkp.de/docs/1322749526_102i.pdf I have put Ingo who did the wiki edit about traveling in BCC - perhaps he might like to clarify a bit. I also hope that there is some connection from Schönberg to Kiel main station on Monday morning at 6:00 ... See you Andreas. On Thu, Feb 07, 2013 at 09:21:11AM +0100, Olivier Sallou wrote: hi, I was looking at venue details, and wondering about bus 201 to Schonberger. Looking at timetable [0], line 201 does not seem to go up to Schonberger strand (though not easy for me to read, I do not read German at all). And lines from Kiel to Schoneberger takes one hour long. Thanks Olivier [0]: http://linienverkehr.vkp.de/docs/1322749561_200i.pdf -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/511363f7.1020...@irisa.fr -- 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/20130207090637.gf20...@an3as.eu
Re: Sprint question
Le 2/7/13 10:06 AM, Andreas Tille a écrit : Hi Olivier, from a *very* quick look there is also a fast line 102 http://linienverkehr.vkp.de/docs/1322749526_102i.pdf I have put Ingo who did the wiki edit about traveling in BCC - perhaps he might like to clarify a bit. I also hope that there is some connection from Schönberg to Kiel main station on Monday morning at 6:00 I think I will rent a car at Hambourg airport (travel is already long from france). As I leave on monday, I may drop you there if needed. Olivier ... See you Andreas. On Thu, Feb 07, 2013 at 09:21:11AM +0100, Olivier Sallou wrote: hi, I was looking at venue details, and wondering about bus 201 to Schonberger. Looking at timetable [0], line 201 does not seem to go up to Schonberger strand (though not easy for me to read, I do not read German at all). And lines from Kiel to Schoneberger takes one hour long. Thanks Olivier [0]: http://linienverkehr.vkp.de/docs/1322749561_200i.pdf -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/511363f7.1020...@irisa.fr -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/511370a9.1010...@irisa.fr
Re: New version of EDFbrowser 1.49
On Thu, Feb 7, 2013 at 9:49 AM, Andreas Tille andr...@an3as.eu wrote: Hi Teunis, Hello Andreas, many thanks for keeping us updated about the new version. I can confirm Many thanks to you for the packaging. that the package builds nicely. However, currently Debian is in Freeze for the new release (expected somewhen in Spring.) The rules for freeze are no new features and thus we can upload only to Debian experimental. If you consider this helpful I could do this. On the other hand I guess not so many users will see the new version there because experimental sources are not included on normal users machines. If you consider an upload to experimental sensible under this circumstances please tell me and I will do so. Otherwise I'd upload after the new Debian release. If it's not too much effort, please upload it to experimental. Kind regards and thanks again for keeping us updated Thanks to you and all the other people for the packaging for Debian. Andreas. Best Regards, Teunis On Tue, Feb 05, 2013 at 04:25:45PM +0100, Teunis van Beelen wrote: EDFbrowser 1.49 is available here: http://www.teuniz.net/edfbrowser/ A viewer/toolbox for timeseries storage files like EDF, BDF, EDF+, BDF+ EDFbrowser is a viewer/toolbox/converter for timeseries storage files containing data such as EEG, EMG, and ECG signals. It supports EDF(+) and BDF(+) file formats. Apart from viewing the files, it also supports some editing operations and can convert to/from other formats. Best Regards, Teunis van Beelen -- C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee! -- 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/CAHK3Xzii=v9ul6mibzgiqti5bjfe7gxjtehz8k68vxjky3k...@mail.gmail.com
Re: New version of EDFbrowser 1.49
Hi Teunis, If it's not too much effort, please upload it to experimental. Done. 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/20130207102728.gd6...@an3as.eu
Re: Packaging InVesalius
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. ;-)
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?
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.)
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
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/20130207130854.ga9...@an3as.eu
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: [fis-gtm] builds with pbuilder
On Thu, 07 Feb 2013, Amul Shah wrote: Andreas/Yaroslav, Thanks to Luis, I setup a pbuilder environment and built GT.M. There are a few lintian warnings and some package naming oddities that I am unsure about. How do I grab the build log, aside from using tee? spoiled me uses git-buildpackage (could be called with --pbuilder option) and that generates a nice .log for me I say package naming oddity, because the generated deb is named fis-gtm-6.0-001_6.0-001-1_amd64.deb, where I expected to see a deb named fis-gtm_6.0-001-1_amd64.deb. per our discussion at kitware some time ago -- we agreed to have versioned binary package (i.e. version in the name) to signal that per se you can't just upgrade fis-gtm to a new major.minor version to still access previous DB -- it needs to be migrated. And that is why it is better to be able to co-install 2 (or more) versions at the same time. I do not remember though having -001 revision in there, and would have expected fis-gtm-6.0_6.0-001-1_amd64.deb, but I could be wrong. I can't find the lintian warnings in pbuidler's output, but I did see them in debuild's output. This is what I see in debuild: W: fis-gtm source: changelog-should-mention-nmu W: fis-gtm source: source-nmu-has-incorrect-version-number 6.0-001-1 are you listed in Maintainers/Uploaders as well (with identical name in the last changelog entry signature)? W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr 4755 root/root W: fis-gtm-6.0-001: non-standard-dir-perm usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755 W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root W: fis-gtm-6.0-001: executable-is-not-world-readable usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 I think we had discussion on those security measures -- would need to look in emails to rehears what was our conclusion ;) I'm not sure what nmu is. http://wiki.debian.org/NonMaintainerUpload The flagged permissions for gtmsecshr are what we require and check for. Do I need to suppress those warnings? probably These are the warnings that I see in pbuilder's output: dpkg-shlibdeps: warning: debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so contains an unresolvable reference to symbol gtm_free: it's probably a plugin dpkg-shlibdeps: warning: 6 other similar warnings have been skipped (use -v to see them all) dpkg-shlibdeps: warning: package could avoid a useless dependency if and it is a plugin, so might rely on the main process to have the namespace loaded for it.,.. so should be safe to ignore (not sure if there is a way to suppress) debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/ftok debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_server debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/lke debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mumps debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mupip debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_gnp_server debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_pkdisp debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/dse debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_shmclean debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_play were not linked against libncurses.so.5 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so was not linked against libgpg-error.so.0 (it uses none of the library's symbols) gtm_free is provided by debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so. if those statements are correct -- you might like to adjust your CMake* files ... but that is not critical really Do I need to suppress this warning? I will look into whether or not we can avoid the dependency for libncurses and ligpg-error. probably it is not that you need to avoid dependency -- it is just that you are linking against them where needed and not. You might like (not sure if tollerable ;) ) use -DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed -DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed ? What are the next steps? let's decide on versioning and above NMU false-positives. And I guess Andreas' blessing ;) -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
Re: [fis-gtm] builds with pbuilder
On 02/07/2013 12:21 PM, Yaroslav Halchenko wrote: On Thu, 07 Feb 2013, Amul Shah wrote: Andreas/Yaroslav, Thanks to Luis, I setup a pbuilder environment and built GT.M. There are a few lintian warnings and some package naming oddities that I am unsure about. How do I grab the build log, aside from using tee? spoiled me uses git-buildpackage (could be called with --pbuilder option) and that generates a nice .log for me I say package naming oddity, because the generated deb is named fis-gtm-6.0-001_6.0-001-1_amd64.deb, where I expected to see a deb named fis-gtm_6.0-001-1_amd64.deb. per our discussion at kitware some time ago -- we agreed to have versioned binary package (i.e. version in the name) to signal that per se you can't just upgrade fis-gtm to a new major.minor version to still access previous DB -- it needs to be migrated. And that is why it is better to be able to co-install 2 (or more) versions at the same time. I do not remember though having -001 revision in there, and would have expected fis-gtm-6.0_6.0-001-1_amd64.deb, but I could be wrong. [amul:2] That -001 is the sub minor version. Our next release is going to be V6.0-002. I think we need that in there to allow V6.0-001 and V6.0-002 to coexist. Correct? We don't need one of those version numbers, that's for sure. Where are they coming from? I know one is in debian/control. I can't find the lintian warnings in pbuidler's output, but I did see them in debuild's output. This is what I see in debuild: W: fis-gtm source: changelog-should-mention-nmu W: fis-gtm source: source-nmu-has-incorrect-version-number 6.0-001-1 are you listed in Maintainers/Uploaders as well (with identical name in the last changelog entry signature)? [amul:2] I'm listed as an uploader (or at least I think I am). I don't have a GPG key yet (well I did, but I forgot the password). My name is in both files, but the email address case is different. grep -i fisglobal debian/* debian/changelog: -- Amul Shah amul.s...@fisglobal.com Fri, 25 Jan 2013 23:13:11 -0500 debian/control: Amul Shah amul.s...@fisglobal.com W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr 4755 root/root W: fis-gtm-6.0-001: non-standard-dir-perm usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755 W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root W: fis-gtm-6.0-001: executable-is-not-world-readable usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 I think we had discussion on those security measures -- would need to look in emails to rehears what was our conclusion ;) [amul:2] Sure. I'll dredge them up. I'm not sure what nmu is. http://wiki.debian.org/NonMaintainerUpload [amul:2] Ah, I guess I'm not an uploader. The flagged permissions for gtmsecshr are what we require and check for. Do I need to suppress those warnings? probably [amul:2] Ok, I'll take care of them. These are the warnings that I see in pbuilder's output: dpkg-shlibdeps: warning: debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so contains an unresolvable reference to symbol gtm_free: it's probably a plugin dpkg-shlibdeps: warning: 6 other similar warnings have been skipped (use -v to see them all) dpkg-shlibdeps: warning: package could avoid a useless dependency if and it is a plugin, so might rely on the main process to have the namespace loaded for it.,.. so should be safe to ignore (not sure if there is a way to suppress) [amul:2] Ignoring works for me. :) debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/ftok debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_server debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/lke debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mumps debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mupip debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_gnp_server debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_pkdisp debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/dse debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_shmclean debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_play were not linked against libncurses.so.5 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so was not linked against libgpg-error.so.0 (it uses none of the library's symbols) gtm_free is provided by debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so. if those statements are correct -- you might like to adjust your CMake* files ... but that is not critical really [amul:2] That's the plan. I won't change the current release unless it is needed. Do I need to
Re: [fis-gtm] builds with pbuilder
On Thu, 07 Feb 2013, Amul Shah wrote: On 02/07/2013 12:21 PM, Yaroslav Halchenko wrote: On Thu, 07 Feb 2013, Amul Shah wrote: Andreas/Yaroslav, Thanks to Luis, I setup a pbuilder environment and built GT.M. There are a few lintian warnings and some package naming oddities that I am unsure about. How do I grab the build log, aside from using tee? spoiled me uses git-buildpackage (could be called with --pbuilder option) and that generates a nice .log for me I say package naming oddity, because the generated deb is named fis-gtm-6.0-001_6.0-001-1_amd64.deb, where I expected to see a deb named fis-gtm_6.0-001-1_amd64.deb. per our discussion at kitware some time ago -- we agreed to have versioned binary package (i.e. version in the name) to signal that per se you can't just upgrade fis-gtm to a new major.minor version to still access previous DB -- it needs to be migrated. And that is why it is better to be able to co-install 2 (or more) versions at the same time. I do not remember though having -001 revision in there, and would have expected fis-gtm-6.0_6.0-001-1_amd64.deb, but I could be wrong. [amul:2] That -001 is the sub minor version. Our next release is going to be V6.0-002. I think we need that in there to allow V6.0-001 and V6.0-002 to coexist. Correct? We don't need one of those version numbers, that's for sure. Where are they coming from? I know one is in debian/control. ah ok -- so you do want co-installability all the way to minor version... then ok in fis-gtm-6.0-001_6.0-001-1_amd64.deb fis-gtm-6.0-001 -- is the source name (find it in debian/control and changelog) then _ to separate the actual version which consists of two pieces -- upstreamversion-debianrevisionout which in this case is 6.0-001-1 ;-) so all legit... if it was an NMU there would be also e.g .1 suffix in debian revision. I can't find the lintian warnings in pbuidler's output, but I did see them in debuild's output. This is what I see in debuild: W: fis-gtm source: changelog-should-mention-nmu W: fis-gtm source: source-nmu-has-incorrect-version-number 6.0-001-1 are you listed in Maintainers/Uploaders as well (with identical name in the last changelog entry signature)? [amul:2] I'm listed as an uploader (or at least I think I am). I don't have a GPG key yet (well I did, but I forgot the password). My name is in both files, but the email address case is different. here you go -- probably that is it -- make them identical since Steve Smith !=== Steve Smith and email is used also -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130207203058.gb8...@onerussian.com
Re: Packaging InVesalius
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. 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. 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/20130208073545.ga31...@an3as.eu
