Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote: Hi there, I am in the process of packaging dicom3tools: * http://debian-med.alioth.debian.org/tasks/imaging.html One important step of the packaging is the DICOM UID. In order to write a DICOM file, one need a unique UID for each instance of a DICOM object. For more details: http://www.dclunie.com/medical-image-faq/html/part2.html#UID As documented at: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration I wonder whether it is possible/feasible to come up with a single OID suiteable for all users. IMHO every user/institution would need an OID -- since somehow each DICOM generated by that OID needs to result in a unique UID. In a medical context there is probably already an OID available that could be used for this purpose. For all others it might be helpful to provide some guidance for the users how such an OID can be constructed. Maybe it is possible to generate 'dummy' OIDs in a Debian namespace to ease the life of people who are not interested in generating 'official' DICOMS but simply need to convert files from one format into another. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
debian OID / dicom3tools packaging
Hi there, I am in the process of packaging dicom3tools: * http://debian-med.alioth.debian.org/tasks/imaging.html One important step of the packaging is the DICOM UID. In order to write a DICOM file, one need a unique UID for each instance of a DICOM object. For more details: http://www.dclunie.com/medical-image-faq/html/part2.html#UID As documented at: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration ... To use SNMP one needs an Enterpise UID assigned by IANA, which is free and may also be used for any other purpose that requires a UID root. * http://www.iana.org/cgi-bin/enterprise.pl to register * http://www.iana.org/assignments/enterprise-numbers to see the registry You use the assigned enterpise number as in 1.3.6.1.4.1. ... Which would mean for debian that I could simply be using 1.3.6.1.4.1.9586 (https://dsawiki.debian.org/dsawiki/iana). Would that be ok ? Should I be using some kind of subspace of this UID ? Since this would be done for debian-med I would suggest: $ echo med | od -b 000 155 145 144 012 1.3.6.1.4.1.9586.155.145.144 This would be the toplevel (root) of all UID generated from the dicom3tools package. Thanks for comments, -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, 27 Jan 2009, Mathieu Malaterre wrote: $ echo med | od -b 000 155 145 144 012 1.3.6.1.4.1.9586.155.145.144 This would be the toplevel (root) of all UID generated from the dicom3tools package. Hmm, I'm not sure whether this helps. May be I missunderstood the problem but is the UID per *package* or per *installation*. IMHO assigning a UID to a Debian package makes not much sense because it is finally interesting for the organisation which *installs* this package. So rather than generating the UID in the build process it should be created in the postinst and the admin who is installing the package should register this UID at IANA. So we should find a way how to find some reasonable means to *generate* a UID which was not registered yet. Asking for an Organisation name per debconf and perhaps using a part of the MD5 sum or something like that and *combining* it with a *template* for the package comes to mind. Did I missed something? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 1:16 PM, Michael Hanke michael.ha...@gmail.com wrote: On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote: Hi there, I am in the process of packaging dicom3tools: * http://debian-med.alioth.debian.org/tasks/imaging.html One important step of the packaging is the DICOM UID. In order to write a DICOM file, one need a unique UID for each instance of a DICOM object. For more details: http://www.dclunie.com/medical-image-faq/html/part2.html#UID As documented at: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration I wonder whether it is possible/feasible to come up with a single OID suiteable for all users. IMHO every user/institution would need an OID -- since somehow each DICOM generated by that OID needs to result in a unique UID. I never really understood the theory of the UID, but yeah one day or the other they'll be conflicts, esp. if you multiply by user and time space... You can store 64bytes ([0-9\.]+) for a UID, so this leave some room. In a medical context there is probably already an OID available that could be used for this purpose. For all others it might be helpful to provide some guidance for the users how such an OID can be constructed. Maybe it is possible to generate 'dummy' OIDs in a Debian namespace to ease the life of people who are not interested in generating 'official' DICOMS but simply need to convert files from one format into another. In real (wild) life I know very few people producing massive amount of DICOM files. As a side note when converting a DICOM file to another (lossless) DICOM representation you are not required to modify the UID. So depending on the scenario you do not even need to create a new one. So IMHO only large institution would need to change that to their own OID, unfortunately this is a compile time variable... that's why I am stuck on the packaging right now :( Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 1:27 PM, Andreas Tille til...@rki.de wrote: On Tue, 27 Jan 2009, Mathieu Malaterre wrote: $ echo med | od -b 000 155 145 144 012 1.3.6.1.4.1.9586.155.145.144 This would be the toplevel (root) of all UID generated from the dicom3tools package. Hmm, I'm not sure whether this helps. May be I missunderstood the problem but is the UID per *package* or per *installation*. IMHO assigning a UID to a Debian package makes not much sense because it is finally interesting for the organisation which *installs* this package. So rather than generating the UID in the build process it should be created in the postinst and the admin who is installing the package should register this UID at IANA. So we should find a way how to find some reasonable means to *generate* a UID which was not registered yet. Asking for an Organisation name per debconf and perhaps using a part of the MD5 sum or something like that and *combining* it with a *template* for the package comes to mind. Did I missed something? the ideal solution would be indeed that a conf file would indicate what is the root UID being used. GDCM has one, DCMTK has one. David Clunie (author of dicom3tools) has one, SIEMENS, GE, Philips, my actual company. the problem is for one time user, converting a MINC file to DICOM. Any larger organisation would have there own UID, but would need to -painfully- recompile dicom3tools. -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: sl-modem (updated package)
On Mon, Jan 26, 2009 at 09:04:42PM -0600, Raphael Geissert wrote: أحمد المحمودي wrote: I think that it is fine too, because that package actually builds another package (if module-assistant is used), or just builds some module files (if DKMS is used). Have you read the tag's description? it is not as to what the package does. You mean the long description ? I fixed it uploaded. I fixed uploaded, except for one patch (04_sregs_init.diff). That was introduced by previous maintainer. And I don't know what it does. Then that's your homework :) Thanks for the push ! I found out that it is an obsolete patch ! Previous maintainer had to remove it since 2.9.9e-pre1a. (I had to dig into snapshot.debian.net to find out). Again, please advise me about the use of usermod in the postinst. Looks fine, but I have one question: why did you disable the version check? Was trying something, and forgot to uncomment it back ! Sorry ! Anyways, it is fixed now in the current upload. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net) GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: battery-stats (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.3.4-1 of my package battery-stats. It builds these binary packages: battery-stats - collects statistics about charge of laptop batteries The package appears to be lintian clean. The upload would fix these bugs: 512701 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/battery-stats - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/battery-stats/battery-stats_0.3.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Antonio Radici -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: ddclient
Dear mentors, I am looking for a sponsor for my package ddclient. * Package name: ddclient Version : 3.7.3-6 Upstream Author : Paul Burry p...@burry.ca * URL : http://ddclient.sf.net * License : GPL-2 Section : net It builds these binary packages: ddclient - Update IP addresses at dynamic DNS services The package appears to be lintian clean. The upload would fix these bugs: 493469 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/ddclient - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/ddclient/ddclient_3.7.3-6.dsc I would be glad if someone uploaded this package for me. -- Marco Rodrigues http://Marco.Tondela.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: sl-modem (updated package)
أحمد المحمودي wrote:
On Mon, Jan 26, 2009 at 09:04:42PM -0600, Raphael Geissert wrote:
Have you read the tag's description? it is not as to what the package does.
You mean the long description ? I fixed it uploaded.
No, I mean this:
$ lintian-info -t debhelper-but-no-misc-depends
N: debhelper-but-no-misc-depends
N:
N: The source package uses debhelper but it does not use ${misc:Depends}
N: in the given binary package's debian/control entry. This is required
N: so the dependencies are set correctly in case the result of a call to
N: any of the dh_ commands cause the package to depend on another
N: package.
N:
N: Refer to the debhelper(7) manual page for details.
N:
N: Severity: normal; Certainty: certain
N:
I fixed uploaded, except for one patch (04_sregs_init.diff). That was
introduced by previous maintainer. And I don't know what it does.
Then that's your homework :)
Thanks for the push ! I found out that it is an obsolete patch !
Previous maintainer had to remove it since 2.9.9e-pre1a. (I had to dig
into snapshot.debian.net to find out).
Good
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration ... To use SNMP one needs an Enterpise UID assigned by IANA, which is free and may also be used for any other purpose that requires a UID root. * http://www.iana.org/cgi-bin/enterprise.pl to register * http://www.iana.org/assignments/enterprise-numbers to see the registry You use the assigned enterpise number as in 1.3.6.1.4.1. ... I'm not online at the moment, so I can't read the FAQ reference given, but this most categorically *not* what an OID is supposed to be used for, *especially* in the SNMP context. An OID is supposed to provide a globally-unique but *stable* tree path to retrieve an SNMP value. You can't write a MIB if your OIDs are always changing out from underneath you. Instead, the SNMP MIB for this device should provide a table mapping the UUID of the device to entries in a table, or (if there's only one device per SNMP agent) then you can shortcut the table part of the whole thing. Which would mean for debian that I could simply be using 1.3.6.1.4.1.9586 (https://dsawiki.debian.org/dsawiki/iana). Would that be ok ? Should I be using some kind of subspace of this UID ? Since this would be done for debian-med I would suggest: $ echo med | od -b 000 155 145 144 012 1.3.6.1.4.1.9586.155.145.144 This would be the toplevel (root) of all UID generated from the dicom3tools package. Despite the similarity in acronym, an OID is not like a (U)UID. If you need a globally-unique value to identify a device or otherwise, we have whole RFCs dedicated to the task of describing how to generate one. Trying to brutalise an OID tree into doing the job is just plain *weird*, not to mention a bunch of other less-complimentary phrases. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 01:32:34PM +0100, Mathieu Malaterre wrote: So IMHO only large institution would need to change that to their own OID, unfortunately this is a compile time variable... Fix that. Making something that has to be unique to each installation a compile-time flag is stupendously stupid. Read it out of a config file. Then have the postinst generate a UUID properly, and you're pretty much guaranteed global uniqueness. See my other message about (not) using an OID for this purpose. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ddclient
On Tue, Jan 27, 2009 at 07:48:48PM +, Marco Rodrigues wrote: Dear mentors, I am looking for a sponsor for my package ddclient. * Package name: ddclient Version : 3.7.3-6 Upstream Author : Paul Burry p...@burry.ca * URL : http://ddclient.sf.net * License : GPL-2 Section : net It builds these binary packages: ddclient - Update IP addresses at dynamic DNS services The package appears to be lintian clean. The upload would fix these bugs: 493469 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/ddclient - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/ddclient/ddclient_3.7.3-6.dsc I would be glad if someone uploaded this package for me. As the person listed as Maintainer for this is a DD, would it not be best to work with them? signature.asc Description: Digital signature
RFS: libgstreamer-perl (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.14-1 of my package libgstreamer-perl. It builds these binary packages: libgstreamer-perl - Perl interface to the GStreamer media processing framework The package appears to be lintian clean. The upload would fix these bugs: 456924 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libgstreamer-perl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libgstreamer-perl/libgstreamer-perl_0.14-1.dsc I would be glad if someone uploaded this package for me. Kind regards Antonio Radici -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libgstreamer-perl (updated package)
On Wed, Jan 28, 2009 at 12:38:32AM +, Antonio Radici wrote: I am looking for a sponsor for the new version 0.14-1 of my package libgstreamer-perl. Are you aware of the Debian Perl Group? Maybe your package can be team maintained there. The package appears to be lintian clean. A few observations: You have a couple of lintian warnings that comes from upstream manpages, they are easy to fix: W: libgstreamer-perl: manpage-has-bad-whatis-entry, You might want to fix those. Also your package install some .pod files on usr/lib/perl5/, those .pod files are also installed as a manpages on the correct place (usr/share/man/man3/), the .pod files are needed? If not, it might be a good idea to remove the .pod files from the package. Cheers. -- Rene Mauricio Mayorga | jabber: rmayo...@jabber.org http://rmayorga.org | -- 08B6 58AB A691 DD56 C30B 8D37 8040 19FA A209 C305 signature.asc Description: Digital signature
