Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Hi Sebastien, On Tue, Oct 09, 2012 at 11:04:40AM +0200, Sebastien Jodogne wrote: (1) Should I create a Subversion tag for the upload by myself, or is this the responsibility of the uploader of the package? I think we do not have any written rule for this. I personally ask the sponsee to add the tag once the package is *accepted* in unstable. For the case it doese not pass ftpmaster I do not see any reason for tagging because the package has never hit the official mirrors. (2) I am not sure to understand how I should cope with the unit tests: a. Are they to be automatically run as a part of the build process (if the CMAKE_CROSSCOMPILING flag is OFF)? b. Are they to be distributed along with the Orthanc binaries (e.g. under the name /usr/share/orthanc/UnitTests)? c. Are they to be simply ignored (as it is the case for now)? The tests should be run in the packaging process using identical files that will be inside the package. If dh_auto_test might not trigger running the test suite you should probably enforce this using override_dh_auto_test (3) I would like to put my code on Subversion for backporting Orthanc to squeeze: a. Can I do it now, or should I wait for the sid package to be ready? We do not have much examples for maintaining backports in SVN (probably because most (if not all) of our packages build nicely on backports. If you need to change something I would consider it a good idea if it is accessible via SVN. For this I do see two options: 1. Either really do the tagging of the upload before the package is in unstable while beeing prepared to deal with some rejection from ftpmaster - finally it is no real harm if we might remove a tag and add a proper one in case of some changes needed at ftpmaster request 2. or you jast maintain backports in a branch which is fine as well Feel free to decide which way might fit your workflow best. b. If I can work on this right now, how should I call this package (orthanc-0.2.2-6~bpo60+1 apparently [1]), and in which directory should I put the code in Subversion? In the case of the second way use trunk/packages/orthanc/branches otherwise you might like to keep working in trunk in case you only need to change the d/changelog file for this and use proper tagging. BTW, I personally prefer a versioning 0.2.2-1 for the first upload of a package (independently what might have previousely existed on mentors.d.o) but if Matthieu was fine with sponsering, yes the suggested naming for the bpo package seems to be reasonable. We are working hard at the CHU of Liège on Orthanc, as it will greatly ease our data management for clinical processes. Good luck with this. 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/20121010114946.gd24...@an3as.eu
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
[Filling in the blancs from Andreas email] On Tue, Oct 9, 2012 at 11:04 AM, Sebastien Jodogne s.jodo...@chu.ulg.ac.be wrote: By doing so, I have noticed that I forgot to submit a local copy of the mongoose-3.1.tar.gz third-party dependency yesterday. This means that the build of the package of yesterday will fail on the build machines, since a HTTP download will try and download mongoose. This has been fixed now, but the package should be re-sent. I am sorry for this inconvenience. I contacted ftpmaster and asked for a removal of the package then. Thanks. Please also note that a new version of the upstream package (0.2.3) should be ready in less than two weeks. It will incorporate all the patches, will include more transparent support of Debian hardening and will be able to use the libgtest0-dev system package to build unit tests (as pointed out by Mathieu [2]). I think that working on improved hardening and unit testing in the current 0.2.2 version would thus be some waste of time. ok, that's great ! (1) Should I create a Subversion tag for the upload by myself, or is this the responsibility of the uploader of the package? See Andreas answer. (2) I am not sure to understand how I should cope with the unit tests: a. Are they to be automatically run as a part of the build process (if the CMAKE_CROSSCOMPILING flag is OFF)? Yes. If you have a Arch: any package. The test will be run as part of the rebuild on the specific arch. This is a fantastic tool to test cross-platform exectution. b. Are they to be distributed along with the Orthanc binaries (e.g. under the name /usr/share/orthanc/UnitTests)? No. tests are build run, but not installed. c. Are they to be simply ignored (as it is the case for now)? You could potentially ignore a test on -say- ppc, until the bug is fixed upstream... (3) I would like to put my code on Subversion for backporting Orthanc to squeeze: a. Can I do it now, or should I wait for the sid package to be ready? b. If I can work on this right now, how should I call this package (orthanc-0.2.2-6~bpo60+1 apparently [1]), and in which directory should I put the code in Subversion? Can anyone backport something to oldstable from sid ? I do not believe this is possible. I guess you need to talk to release team about this: http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable To the best of my knowledge, there is nothing in DICOM standard that is stated about such a JSON binding, nor even about a RESTful interface to DICOM stores. The closest match seems to be the WADO specification. In the absence of such a specification, Orthanc implements a custom HTTP API to close the gap. Please also note that besides simple access to DICOM objects (WADO is only for read access over HTTP), Orthanc will ultimately be able to transfer DICOM objects to other modalities (C-Store SCU), to download ZIP files containing series, to modify them (e.g. anonymization),... All this by using a simple RESTful interface that is usable from most programming languages (e.g. Python scripts). We are working hard at the CHU of Liège on Orthanc, as it will greatly ease our data management for clinical processes. I do not understand the difference in between XML and JSON, but if this make your process easier then it is fine with me. What I am worried about is that DICOM is all about interoperability, while I do not recall you ever posted your intentions on comp.protocols.dicom. I have not looked at the implementation details, but how did you avoid the whole BulkData handling of PS 3.19 with XML representation, simply by using JSON instead. Does JSON supports arbitrary binary blobs ? Thanks, -- Mathieu -- 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/ca+7wuszh7qu5j0miucqqdh5ibmyn_9--wkayxyxopd5_xnh...@mail.gmail.com
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 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. 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. 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/20121010205626.gj23...@an3as.eu
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
