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: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Sébastien On Mon, Oct 8, 2012 at 6:19 PM, Sebastien Jodogne s.jodo...@chu.ulg.ac.be wrote: Well, I wasn't really happy about the following (but I uploaded anyway): $ cat d/rules ... override_dh_auto_install: cp $(CURDIR)/Build/Orthanc $(CURDIR)/debian/orthanc/usr/bin/orthanc gzip -c -9 $(CURDIR)/NEWS $(CURDIR)/debian/orthanc/usr/share/doc/orthanc/changelog.gz What were you trying to do ? The cp command is used to convert the name of the binary to lowercase. The camel case naming in the upstream package is a convention I use for Windows builds. debian only enforce lower case for package name. This is unneeded IMHO. Some users might even be confused that suddenly debian package uses orthanc, while Orthanc is used on *NIX boxes... The gzip command is used to install the upstream changelog. There are certainly better ways of doing so, unfortunately this is my first Debian packaging attempt :) See Andreas comment. Also I'll remove -DDEBIAN_HARDENING=ON on the next upload, I just do not understand why it was used in the case of an explicit debian packaging... Indeed, this flag is not required on Debian sid. I have implemented this flag to allow backporting to squeeze, whose debhelper version is apparently not able to natively cope with hardening. Technically there is nothing wrong, some duplicate work that is all. What I fear is rather for advanced user: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options Technically you should be able to control such compilation flags outside of the cmake build system, eg if the user wants something different from the default hardening. Not running the test suite is not a good idea. I have been obliged to do so, since it seems that the libgtest-dev package does not come with the required shared library. I could however easily modify the CMake files to statically link against gtest (only for the test suite of course). When all else fails, read the instructions: $ cat /usr/share/doc/libgtest-dev/README.Debian Finally, I would not use -DCMAKE_BUILD_TYPE=Debug, maybe something like MinSizeRel would be slightly better (-O2) I have indeed forgotten to replace Debug with Release. Release is fine too. I will submit the last three modifications tomorrow morning. I will warn you when I will have done so. I will also try and close the ITP and the RFS bugs tomorrow. ...And thank for uploading the package! Thanks for your contribution to the DICOM community ! As a side note, where is the implementation coming from, is this JSON binding describe anywhere in the DICOM standard ? 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+7wUsx7EbOvyUkp=rvfud47s3osmyuye5yyo6j2ahjyap2...@mail.gmail.com
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Dear Andreas and Mathieu, I have just committed some modifications we have discussed yesterday. 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. 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. I have some additional questions: (1) Should I create a Subversion tag for the upload by myself, or is this the responsibility of the uploader of the package? (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)? (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? As a side note, where is the implementation coming from, is this JSON binding describe anywhere in the DICOM standard ? 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. Cheers, Sébastien- [1] http://wiki.debian.org/BuildingFormalBackports#Modifying_the_package [2] # cat /usr/share/doc/libgtest-dev/README.Debian -- 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/5073e8a8.8030...@chu.ulg.ac.be
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Hi Andreas, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ Just back from vacation I read your conversation about orthanc packaging. Besides the obvious helpful technical hints I would like to come back to the initial hint from Mathieu to join the Debian Med team. [...] To learn about the workflow in Debian Med team you might like to read our policy document[1]. Feel free to ask if you have some remaining questions. Thank for your suggestion! I have successfully applied for membership to the Debian-Med project. It seems that I will not have write access to the Subversion repository before tomorrow [1]. As soon as I am able to sync against Subversion, I will try and upload the source code of the Orthanc package to Debian-Med. Regards, Sébastien- [1] http://wiki.debian.org/Alioth/SSH#A..._and_I.27ve_only_recently_been_added_to_a_project -- 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/5072ca80.9030...@chu.ulg.ac.be
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Dear all, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ Just back from vacation I read your conversation about orthanc packaging. Besides the obvious helpful technical hints I would like to come back to the initial hint from Mathieu to join the Debian Med team. I have just uploaded the source code for the Debian packaging of Orthanc [1] to the Subversion repository of the Debian Med project [2]. I have not been able to append Orthanc to the imaging task of the debian-med Blends repository [3], presumably because of user restrictions. Here is a tentative description for Orthanc in Debian Med tasks: Depends: orthanc Homepage: https://code.google.com/p/orthanc/ WNPP: 689029 Responsible: Sebastien Jodogne s.jodo...@gmail.com License: GPL Pkg-Description: RESTful DICOM server for healthcare and medical research Orthanc aims at providing a simple, yet powerful standalone DICOM server. Orthanc can turn any computer running Windows or Linux into a DICOM store (in other words, a mini-PACS system). Its architecture is lightweight, meaning that no complex database administration is required, nor the installation of third-party dependencies. . What makes Orthanc unique is the fact that it provides a RESTful API. Thanks to this major feature, it is possible to drive Orthanc from any computer language. The DICOM tags of the stored medical images can be downloaded in the JSON file format. Furthermore, standard PNG images can be generated on-the-fly from the DICOM instances by Orthanc. . Orthanc lets its users focus on the content of the DICOM files, hiding the complexity of the DICOM format and of the DICOM protocol. Could someone explain how I could further improve the package? I thank you much in advance! Cheers, Sébastien- [1] https://code.google.com/p/orthanc/ [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/ [3] http://debian-med.alioth.debian.org/tasks/imaging -- 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/5072efb7.9080...@chu.ulg.ac.be
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Well, I wasn't really happy about the following (but I uploaded anyway): $ cat d/rules ... override_dh_auto_install: cp $(CURDIR)/Build/Orthanc $(CURDIR)/debian/orthanc/usr/bin/orthanc gzip -c -9 $(CURDIR)/NEWS $(CURDIR)/debian/orthanc/usr/share/doc/orthanc/changelog.gz What were you trying to do ? The cp command is used to convert the name of the binary to lowercase. The camel case naming in the upstream package is a convention I use for Windows builds. The gzip command is used to install the upstream changelog. There are certainly better ways of doing so, unfortunately this is my first Debian packaging attempt :) Also I'll remove -DDEBIAN_HARDENING=ON on the next upload, I just do not understand why it was used in the case of an explicit debian packaging... Indeed, this flag is not required on Debian sid. I have implemented this flag to allow backporting to squeeze, whose debhelper version is apparently not able to natively cope with hardening. Not running the test suite is not a good idea. I have been obliged to do so, since it seems that the libgtest-dev package does not come with the required shared library. I could however easily modify the CMake files to statically link against gtest (only for the test suite of course). Finally, I would not use -DCMAKE_BUILD_TYPE=Debug, maybe something like MinSizeRel would be slightly better (-O2) I have indeed forgotten to replace Debug with Release. I will submit the last three modifications tomorrow morning. I will warn you when I will have done so. I will also try and close the ITP and the RFS bugs tomorrow. ...And thank for uploading the package! Sébastien- -- 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/5072fd08.8040...@chu.ulg.ac.be
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
On Mon, Oct 8, 2012 at 6:19 PM, Sebastien Jodogne s.jodo...@chu.ulg.ac.be wrote: I will also try and close the ITP and the RFS bugs tomorrow. Please do not touch the ITP. This is part of the upload process, once the package is uploaded the ITP is automagically closed. 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+7wUsyW9jKHunBihcEd3bgbOx=przklgnex56ezp2sghmu...@mail.gmail.com
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Hi Sebastien, On Mon, Oct 08, 2012 at 05:22:31PM +0200, Sebastien Jodogne wrote: I have just uploaded the source code for the Debian packaging of Orthanc [1] to the Subversion repository of the Debian Med project [2]. From a (very quick!) view this looks good. (I hope imaging experts will keep on helping you - if not please ping me again at end of this week.) I have not been able to append Orthanc to the imaging task of the debian-med Blends repository [3], presumably because of user restrictions. The Debian Med tasks are defined in the Blends project of Alioth where you need to subscribe as well (or need to become a Debian Developer ;-).) Because I do not think it makes real sense to subscribe just to inject this single package I added it for you. Here is a tentative description for Orthanc in Debian Med tasks: Depends: orthanc Homepage: https://code.google.com/p/orthanc/ WNPP: 689029 Responsible: Sebastien Jodogne s.jodo...@gmail.com License: GPL Pkg-Description: RESTful DICOM server for healthcare and medical research Orthanc aims at providing a simple, yet powerful standalone DICOM server. Orthanc can turn any computer running Windows or Linux into a DICOM store (in other words, a mini-PACS system). Its architecture is lightweight, meaning that no complex database administration is required, nor the installation of third-party dependencies. . What makes Orthanc unique is the fact that it provides a RESTful API. Thanks to this major feature, it is possible to drive Orthanc from any computer language. The DICOM tags of the stored medical images can be downloaded in the JSON file format. Furthermore, standard PNG images can be generated on-the-fly from the DICOM instances by Orthanc. . Orthanc lets its users focus on the content of the DICOM files, hiding the complexity of the DICOM format and of the DICOM protocol. Thanks for this nice preparation! The good news is that everything except the first line (Depends) is obtained automagically if a package is in VCS ... modulo some delay where some cron job needs to fetch the information. So if everything will went fine tomorrow evening the package should be updated. Feel free to check this and ping me if this is not the case. Could someone explain how I could further improve the package? I thank you much in advance! I'm slowly working down some past vacation backlog. As I said above please ping me in case you might need further help. Many thanks for your interest in Debian Med and the preparation of the package 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/20121008205437.ga7...@an3as.eu
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
On Mon, Oct 08, 2012 at 06:19:20PM +0200, Sebastien Jodogne wrote: override_dh_auto_install: cp $(CURDIR)/Build/Orthanc $(CURDIR)/debian/orthanc/usr/bin/orthanc gzip -c -9 $(CURDIR)/NEWS $(CURDIR)/debian/orthanc/usr/share/doc/orthanc/changelog.gz What were you trying to do ? The cp command is used to convert the name of the binary to lowercase. The camel case naming in the upstream package is a convention I use for Windows builds. OK. The gzip command is used to install the upstream changelog. This should rather be done using override_dh_installchangelogs There are certainly better ways of doing so, unfortunately this is my first Debian packaging attempt :) That's perfectly fine - its our pleasure to teach you to finally enhance our team. Also I'll remove -DDEBIAN_HARDENING=ON on the next upload, I just do not understand why it was used in the case of an explicit debian packaging... Indeed, this flag is not required on Debian sid. I have implemented this flag to allow backporting to squeeze, whose debhelper version is apparently not able to natively cope with hardening. That's OK in principle - if I'm not totally missleaded it does not harm in sid and if it is helpful for backporting (I'm not really sure if this is actually the case) it might remain. Not running the test suite is not a good idea. I have been obliged to do so, since it seems that the libgtest-dev package does not come with the required shared library. Filing a bug report against libgtest-dev? I could however easily modify the CMake files to statically link against gtest (only for the test suite of course). This might help to successfully run the test suite however, what you would test in this case is not what finally will end up inside the package so the point of running the test suite is not fullfilled. Finally, I would not use -DCMAKE_BUILD_TYPE=Debug, maybe something like MinSizeRel would be slightly better (-O2) I have indeed forgotten to replace Debug with Release. I will submit the last three modifications tomorrow morning. I will warn you when I will have done so. I will also try and close the ITP and the RFS bugs tomorrow. As Matthieu said this is not needed. 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/20121008210349.gc7...@an3as.eu
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Hi Sébastien, On Sun, Sep 30, 2012 at 06:29:33PM +0200, Mathieu Malaterre wrote: Salut Sébastien, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ Just back from vacation I read your conversation about orthanc packaging. Besides the obvious helpful technical hints I would like to come back to the initial hint from Mathieu to join the Debian Med team. You would profit from several advantages - for instance you could bypass the uploads to mentors and commit your packaging to a VCS (either Git or SVN at your choice) where potential sponsors of the team could drop changes with helpful comments directly which might make the process much more smooth. To learn about the workflow in Debian Med team you might like to read our policy document[1]. Feel free to ask if you have some remaining questions. Kind regards Andreas. [1] 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/20121006214945.gd18...@an3as.eu
Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Salut Sébastien, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ On Fri, Sep 28, 2012 at 5:54 PM, Sébastien Jodogne s.jodo...@gmail.com wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package orthanc: * Package name: orthanc Version : 0.2.1-3 Upstream Author : Sebastien Jodogne s.jodo...@gmail.com * URL : https://code.google.com/p/orthanc/ * License : GPL It builds those binary packages: orthanc - A lightweight, RESTful DICOM server for healthcare and medical research To access further information about this package, please visit the following URL: http://mentors.debian.net/package/orthanc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.1-3.dsc More information about orthanc can be obtained from: https://code.google.com/p/orthanc/. Regards, S. Jodogne- -- 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/CA+Rg+VxAnw9RX4=yluq1dgyug7xveffzd2_ay9qwbr7q21g...@mail.gmail.com -- 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+7wUswQPih9hD4vmWBLhUCFqHoÞg66l9pfbb8uajyusn...@mail.gmail.com
