Hi!
For those that are interested, I have changed my email for Fink-related
matters to [EMAIL PROTECTED] . I should still be contactable at
[EMAIL PROTECTED] for a little bit longer, but I don't know how
long exactly. I'll be changing the emails listed in my packages as soon
as I can, as well
It seems that at some point I aquired a /man directory.
Fermi:/ anthony$ ls -lR /man
total 0
drwxr-xr-x 9 root admin 306 27 Oct 19:33 man3
/man/man3:
total 160
-r--r--r-- 1 root admin 4710 27 Oct 19:22 NetSNMP::ASN.3pm
-r--r--r-- 1 root admin 5463 27 Oct 19:22 NetSNMP::OID.3pm
-r--r--r-
Hi, the version of xplanet in 10.3 unstable is broken. The revision
does not match the names of the package and patch. It must have
happened while someone was updating the package with a script or
something.
I have put an updated version of xplanet in the package tracker that
should be good fo
just sent a fixed (working) version of xdvi to the maintainer...
On 7-Nov-03, at 8:03 AM, TheSin wrote:
I had the same problem with proftpd, but setsid was called after
fork(); I put in a debug printout in between them and it worked...
On 7-Nov-03, at 12:29 AM, Rob Braun wrote:
It appears tha
I had the same problem with proftpd, but setsid was called after
fork(); I put in a debug printout in between them and it worked...
On 7-Nov-03, at 12:29 AM, Rob Braun wrote:
It appears that xdvi is trying to call setsid() after vfork().
Just about the only valid thing to do after vfork() is ex
William and Martin: I've verified that the latest released g77 (3.3.2)
does not have the assembler bug present in 3.1,3.3.1 and Apple's
3.3-20030304. As Martin pointed out, the reason I put the 3.4 package in,
even though it is not a released version of g77, is that it was the only
version that d
William Scott wrote:
[]
Is there any way to have version 3.1 and 3.3 cohabitating in 10.3?
I don't think there is a reasonable way to have two *installed* versions
of g77 cohabitate. For two *package descriptions* cohabitating, the
right way would be to create a g77-3.1 package, i.e. instead of
It appears that xdvi is trying to call setsid() after vfork().
Just about the only valid thing to do after vfork() is exec().
I'll bet this is your problem. You may try examining xdvi's
usage of setsid() after the vfork().
However, it looks like the parent is simply exiting after the
vfork. In th
