Re: Policy wrt mail lockfile (section 4.3)
[EMAIL PROTECTED] said: > Hmm, but why would that cause a problem with mailers/programs that use > lockfile locking *and* flock/fcntl locking at the same time? Last time this discussion came up, Bruce found some info in the debian mail archive related to this. Can't find it now, though. If I remember correctly, the problem is that flock/fcntl locking on NFS mounted filesystems can cause complete lockup ( :-) ) of the process. cheers, Lukas --- Dr. Lukas Nellen | Email: [EMAIL PROTECTED] Depto. de Fisica Teorica, IFUNAM | Apdo. Postal 20-364 | Tel.: +52 5 622 5166 01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Do we ever retire packages?
> [EMAIL PROTECTED] writes:
> > I have argued before that a2ps and a2gs are effectively replaced by
> > genscript, and that we should remove them. I think a similar case could be
Please don't do that. Personally, I am used to a2ps and I'm a lot more attached
to my habits than to genscript :-). And I don't see why we should retire a
package just because some other package with similar functionality is provided.
Think of the different flavours of vi which are available as debian packages.
But I see the point that lack of interest might be a reason to retire a
package. I can see two cases in which a package would be considered obsolete:
a) The package is obsolete because the functionality (in the low level sense
of, say, the programs provided) is moved into some other package(s). An example
would be what happened to libgr.
b) A package is orphaned for a long time and similar functionality (in the high
level sense, like genscript vs. a2ps) is provided by another package available.
Or the package is considered to be irrelevant for all but a small minority
which doesn't express its interest. Maybe such a package should be moved into
one directory like {unstable,non-free,contrib}/obsolete for a longer period (to
preserve the effort of debianizing the package in case someone wants to take it
up later). Eventually, packages can get purged from the obsolete directories if
nobody expresses interest in maintaining them.
By moving a package into one of the obsolete directories, the distribution
maintaines and/or the developers express their opinion that a given package is
not sufficiently important from their point of view. At the same time, this
acts as a final call for a new maintainer to step forward and express his
interest in keeping the package alive.
Lukas
-------
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4130: Old motif applications don't run
[EMAIL PROTECTED] said: > [EMAIL PROTECTED] wrote: > > > > Thomas> But they're loaded by irisVxm, the graphical front end: > > > >Which I don't use ..., I use the xmaple shell script (see below). > ... > > $ strace -f -e trace=open,execve,uselib,fork,_exit -o ~/xmaple.log xmaple > > (and immediately exiting once it's come up). ... I got a strace output similar to yours. My fix to get xmaple up and running was to create the following symlinks: /usr/X386 -> X11R5 /usr/X11R5/lib/X11/nls -> ../../../X11R6/lib/X11/nls Cheers, Lukas ------- Dr. Lukas Nellen | Email: [EMAIL PROTECTED] Depto. de Fisica Teorica, IFUNAM | Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218 01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Re: CC's on this mailing list
[EMAIL PROTECTED] said: > Dale Scheetz <[EMAIL PROTECTED]> writes: > > > In fact it would be nice if this message didn't go to you twice, but ... > > I may have already said this, but for those interested, gnus will > generally remove duplicates for you if you want it to. It keeps a > cache of incoming mail message ID's and can be cofigured to do The procmail package also allowes you to set up a message-id cache. Have a look at formail(1) and at the `vacation' example in procmailex(5). Cheers, Lukas ------- Dr. Lukas Nellen | Email: [EMAIL PROTECTED] Depto. de Fisica Teorica, IFUNAM | Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218 01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4090: /etc/init.d/kerneld uses grep
Package: modules
Version: 2.0.0-6
The script /etc/init.d/kerneld uses grep - which might not be available. The
problem is that if you put `auto' into /etc/conf.modules, kerneld is started
before any extra mounts are done. So if you have /usr on a separate partition,
/usr/bin/grep (which is where grep lives) is not yet available.
Possible solution: If /etc/init.d/kerneld accepts `auto' as an argument, it is
possible to distinguish if it is called by /etc/init.d/modules or as part of
the links in one of the /etc/rc?.d.
I include a patch which works on my system which does the following:
- /etc/init.d/modules calls /etc/init.d/kerneld with the argument `auto'
instead of `start' if the keyword `auto' is found in /etc/conf.modules.
- /etc/init.d/kerneld interprets `auto' like `start', except that it skips the
test if the keyword `noauto' is present in /etc/conf.modules
Feel free to use the patch if you like my solution and if my patch looks ok to
you.
Cheers,
Lukas
--- modules.origFri Aug 9 16:55:11 1996
+++ modules Fri Aug 9 16:55:33 1996
@@ -34,7 +34,7 @@
do
case "$module" in
auto) [ ${startkerneld} -eq 0 -a -x /sbin/kerneld ] && \
- echo && /etc/init.d/kerneld start && startkerneld=1;
+ echo && /etc/init.d/kerneld auto && startkerneld=1;
continue ;;
noauto) continue ;;
\#*|"") continue ;;
--- kerneld.origFri Aug 9 16:53:26 1996
+++ kerneld Fri Aug 9 16:54:57 1996
@@ -6,7 +6,9 @@
test -f /sbin/kerneld || exit 0
# Check if noauto is set
-grep "^[ ]*noauto" /etc/modules 2>&1 > /dev/null && exit 0
+if [ "$1" != "auto" ]; then
+grep "^[ ]*noauto" /etc/modules 2>&1 > /dev/null && exit 0
+fi
KDOPT=""
@@ -14,7 +16,7 @@
[ -d /lib/modules/`uname -r` ] || exit 0
case "$1" in
- start)
+ start|auto)
#
# is /proc mounted ?
#
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4064: sendmail should recommend deliver, not depend
[EMAIL PROTECTED] said: > You (Michael Shields) wrote: ... > > perfectly without deliver. sendmail should only recommend it. > > And as a result you can install sendmail without deliver and your > mail installation won't work at all.. One could introduce another virtual package (e.g., local-mail), have sendmail depend on this. Both procmail and deliver could provide this package. Sounds like a bit of an overkill for this problem, though. > Sendmail should come with mail.local instead of deliver IMHO. I think that is the simpler and better solution. Cheers, Lukas ------- Dr. Lukas Nellen | Email: [EMAIL PROTECTED] Depto. de Fisica Teorica, IFUNAM | Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218 01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
