Accepted dcmtk 3.5.4-3 (source i386 all)

2007-07-23 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 22 Jul 2007 20:41:22 +0200 Source: dcmtk Binary: dcmtk-www libdcmtk1-dev dcmtk-doc libdcmtk1 dcmtk Architecture: source i386 all Version: 3.5.4-3 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Accepted dcmtk 3.5.4-2 (source i386 all)

2006-02-17 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 15 Jan 2006 17:31:38 + Source: dcmtk Binary: dcmtk-www libdcmtk1-dev dcmtk-doc libdcmtk1 dcmtk Architecture: source i386 all Version: 3.5.4-2 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Accepted dcmtk 3.5.4-1 (source i386 all)

2006-01-15 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 20 Dec 2005 20:29:15 + Source: dcmtk Binary: dcmtk-www libdcmtk1-dev dcmtk-doc libdcmtk1 dcmtk Architecture: source i386 all Version: 3.5.4-1 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Powerfulness (was: tioga : a powerful plotting system in ruby)

2006-01-07 Thread Juergen Salk
* Vincent Fourmond [EMAIL PROTECTED] [060107 14:13]: Description : tioga : a powerful plotting system in ruby First of all: This is not against you, Vincent. :-) I am just wondering if we shouldn't be more chary of using meaningless (or soliciting) phrases like powerful in package

Accepted dcmtk 3.5.3-5 (source i386 all)

2005-10-26 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Oct 2005 20:16:56 + Source: dcmtk Binary: dcmtk-www dcmtk-doc libdcmtk0c2 libdcmtk0-dev dcmtk Architecture: source i386 all Version: 3.5.3-5 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Accepted dcmtk 3.5.3-4 (source i386 all)

2005-07-29 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 22 May 2005 22:02:31 +0200 Source: dcmtk Binary: dcmtk-www dcmtk-doc libdcmtk0c2 libdcmtk0-dev dcmtk Architecture: source i386 all Version: 3.5.3-4 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Re: (Re)Build problem with g++ 4.0

2005-07-08 Thread Juergen Salk
* Hendrik Sattler [EMAIL PROTECTED] [050708 02:48]: Hi Hendrik, all, thank you for your responses. :-) Cited the wrong file for pthread_t definition :-/ It's /usr/include/bits/pthreadtypes.h:typedef unsigned long int pthread_t; :-) Still, no casting is needed Yes, it's true that no

(Re)Build problem with g++ 4.0

2005-07-07 Thread Juergen Salk
Hi, first of all: if this is not the appropriate list for this kind of question, please give me pointer to better one. I am having problems with rebuilding my dcmtk package with g++ 4.0 on Sid. The problem seems to be related to type casting between pthread_t and unsigned long int types and

Bug#310290: ITP: libccl0 -- Interface to configuration files containing key/value pairs

2005-05-22 Thread Juergen Salk
Package: wnpp Severity: wishlist Owner: Juergen Salk [EMAIL PROTECTED] * Package name: libccl0 Version : 0.1.1 Upstream Author : Stephen F. Booth [EMAIL PROTECTED] * URL : http://sbooth.org/ccl * License : GPL Description : Interface to configuration

Policy and FHS-2.3? (was: /usr/lib vs /usr/libexec)

2005-05-09 Thread Juergen Salk
* Peter Samuelson [EMAIL PROTECTED] [050509 03:07]: Well, the reason */libexec exists is to avoid overloading the meaning of */lib to include things other than libraries. Just as /sbin was invented (way back in the day) to stop overloading /etc with things other than config files. I think

Accepted dcmtk 3.5.3-3 (i386 source all)

2005-04-27 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Apr 2005 20:13:09 +0200 Source: dcmtk Binary: dcmtk-www libdcmtk0 dcmtk-doc libdcmtk0-dev dcmtk Architecture: source i386 all Version: 3.5.3-3 Distribution: unstable Urgency: low Maintainer: Juergen Salk [EMAIL PROTECTED

Accepted dcmtk 3.5.3-2 (i386 source all)

2005-04-11 Thread Juergen Salk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 19 Mar 2005 22:58:21 +0100 Source: dcmtk Binary: dcmtk-www libdcmtk0 dcmtk-doc libdcmtk0-dev dcmtk Architecture: source i386 all Version: 3.5.3-2 Distribution: unstable Urgency: medium Maintainer: Juergen Salk [EMAIL PROTECTED

Privileged Port Puzzle

2005-03-11 Thread Juergen Salk
Hi all. I am working on the imagectn DICOM image archive application. imagectn opens a port and waits for remote applications to connect to this address. The dedicated port number is 104 (see /etc/services) but any user should be allowed to run a private imagectn process on unprivileged ports.

Re: Privileged Port Puzzle

2005-03-11 Thread Juergen Salk
Steve Greenland [EMAIL PROTECTED] wrote: However, this is obviously not the way imagectn is supposed to work. Uh, why not? If (uid==0) { bind to specified port; setuid(imagectn); /* or nobody */ setgid(imagectn); } else { bind to specified non-privileged port

Accepted dcmtk 3.5.3-1 (i386 source all)

2004-12-06 Thread Juergen Salk
] Changed-By: Juergen Salk [EMAIL PROTECTED] Description: dcmtk - The OFFIS DICOM toolkit command line utilities dcmtk-doc - The OFFIS DICOM toolkit documentation dcmtk-www - The OFFIS DICOM toolkit worklist www server application libdcmtk0 - The OFFIS DICOM toolkit runtime libraries libdcmtk0

How to handle libssl support?

2004-11-11 Thread Juergen Salk
Hi all, what's the current policy for packaging software that can optionally linked with libssl support? For Woody it seemed to be common practice to provide two separate packages, one with ssl support enabled and another one with ssl support disabled (like fetchmail/fetchmail-ssl or