* 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
* 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
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 vice
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 c
* 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 th
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 n
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.
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 lynx/lyn
8 matches
Mail list logo