ing
Petter Reinholdtsen
checkers
logtail- Print log file lines that have not been read (deprecated)
--
Happy hacking
Petter Reinholdtsen
on the fonts on disk, not the ones
available via the X server, and am thus unsure if the quoted policy
really is intended for the packages you talk about.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble
spell
and myspell by default to use hunspell instead. The only package I
use that are still using ispell is emacs. No idea how hard it would
be to update, but it would be a good thing to support for example
Hungarian and Nothern Sami spell checking in emacs. :)
Happy hacking,
--
Petter Reinholdtsen
be nice if bash didn't use nss functions when it
starts, and instead waited until one of the variables containing user
information was requested, so you could try to submit such patch to
upstream and see if they accept it.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL P
s, and thus loads the shared ldap
library from /usr/ on invocation. This make it unusable in a system
with LDAP users.
Switching to dash as /bin/sh gave us a nice surprise with reduced
memory consumption and faster boots as well, but that was not the
reason why we switched.
Friendly,
--
Petter R
I'm not sure how this could happen, but when I enabled sourcing of the
.sh scripts in rcS.d/, the boot failed because /etc/rcS.d/S01glibc.sh
uses 'exit 0' at the end of the script, and thus terminates the S
runlevel. This script was added in glibc version 2.3.5-5 uploaded
2005-08-27. The strange
[Steve Langasek]
> It's perfectly sensible: if the scripts were meant to be run in
> parallel, they shouldn't have the ".sh" extension...
Eh, are you claiming that policy mention sourcing of .sh scripts to
make sure those scripts are not run in paralell? It does not sounds
reasonable to me, as th
[Brendan O'Dea]
> I'm not quite sure what the initial rationale was, although Adam Heath
> suggested on IRC that it could be to allow scripts to set environment
> variables which would propagate through to subsequent scripts.
I'm not sure why it is documented in policy, but the sysv-rc
implementat
[Brendan O'Dea]
> Debian Policy states (ยง9.3.1):
>
>"Also, if the script name ends `.sh', the script will be sourced
>in runlevel `S' rather that being run in a forked subprocess, but
>will be explicitly run by `sh' in all other runlevels".
What a strange thing for policy to specify.
[Adrian Bunk]
> I'm currently working on things like automated upgrading of many
> (>> 100) computers. Debian already includes much infrastructure that
> makes this task relatively cheap. For packages using debconf for
> prompting the user it's easy to give the answers without pressing enter
> on 1
11 matches
Mail list logo
