> Erick Branderhorst writes ("New package: die"):
> > Description:
> > die: Kill a job by process name, instead of number.
>
> Can I ask a stupid question ? In what way does this program differ
> from `killall', and wouldn't it be better to integrate this a bit
> better into killall or miscutil
>Having lots of packages is good, but half a dozen (probably often
>poor) implementations of the same tiny script in half a dozen
>different packages doesn't seem optimal to me.
Of course, there is always...
alias zap 'kill \!:2* `ps -e | grep \!^ | grep -v grep | awk \{print\ \$1\}`'
Crude, bu
In article <[EMAIL PROTECTED]> Bill Mitchell <[EMAIL PROTECTED]> writes:
> > We should document what we ship as we ship it.
>
> No argument, but that implies lots of work for maintainers
> when initially building packages and when upgrading to new
> upstream releases. I'm not sure that it's prac
On Thu, 23 Nov 1995, Ian Jackson wrote:
> We should document what we ship as we ship it.
No argument, but that implies lots of work for maintainers
when initially building packages and when upgrading to new
upstream releases. I'm not sure that it's practical.
Some quick grepping around in my fa
>
> I've been seeing this since I installed the elf upgrade packages.
> I was hoping that someone with a better handle on it than me would
> report it, but I've seen no report. I'm not casting this as a
> bug report since I'm not sure where to attribute it.
>
> The error I see accurs during p
On Thu, 23 Nov 1995, Ian Jackson wrote:
>[...]
> I Having lots of packages is good, but half a dozen (probably often
> poor) implementations of the same tiny script in half a dozen
> different packages doesn't seem optimal to me.
I'd expect a rash of package contributions as hordes of new
debian
Erick Branderhorst writes ("Bug#1894: install syslogd and /var/logs/nes"):
> Setting up syslogd ...
> mkdir: cannot make directory `/var/logs/news': No such file or directory
> ~
> chmod: /var/logs/news: No such file or directory
> chown: /var/logs/news: No suc
This discussion went to email to spare debian-devel the noise.
Sven Rudolph has explained it, and I thought I'd close this off
in debian-devel in case anyone is wondering.
It turned out that my alleged 486-40 machine had a 386-40 CPU,
which explained the 6.36 BogoMips I get. Sven pointed out tha
Bill Mitchell writes ("Bug#1887: cfengine 1.2.14-2: documentation errors"):
> In my own packages, I've been trying to provide debianized docs
> which change references to /usr/local to just plain /usr where
> it's clear from the context that this would be incorrect on
> a debian system. I've come
Richard Kettlewell writes ("Re: Bug#1881: Majordomo UID wrong?"):
> When I announced my intention to create a Majordomo package I posted
> to debian-devel asking about acquiring a fixed uid/gid pair for it
> (which would have made the job of Debianising it slightly easier).
> The only response was
Chris Fearnley writes ("Bug#1888: pari 1.39: a few minor Debian bugs"):
> CFLAGS in src/debian.rules gives the -g flag for debugging (almost
> certainly not necessary).
There's nothing wrong with that, so long as it is linked without -g
and with -s.
-g shouldn't change the generated code; it's su
Chris Fearnley writes ("Bug#1886: cern-httpd 3.0-4: a couple of bugs"):
> In http-conf, section "Users' Public HTML Directories", says that the
> default location for users' pages is in public_html, but the script
> sets the default to public-html. Note the '-'. The problem is in
> line 71 of /u
Erick Branderhorst writes ("New package: die"):
> Description:
> die: Kill a job by process name, instead of number.
Can I ask a stupid question ? In what way does this program differ
from `killall', and wouldn't it be better to integrate this a bit
better into killall or miscutils or something
Bill Mitchell writes ("Re: convenience script for building a.out packages"):
> I don't see the conflict between a program name in /usr/local/bin and
> a directory name in /usr/bin. I'll happily change my local program
> name to something else, but I don't understand the concern.
>
> Actually, I t
I've been seeing this since I installed the elf upgrade packages.
I was hoping that someone with a better handle on it than me would
report it, but I've seen no report. I'm not casting this as a
bug report since I'm not sure where to attribute it.
The error I see accurs during processing of /etc
> Dx -- dunno. Didn't take note when I had it open. I grepped
> /var/log/messages for a bogomips figure, but that's apparently
> no longer part of the startup. As I recall under earlier kernels,
> it was low -- perhaps 6.something. Better than the 386 I used
> to run, which was about 4.3.
>
>
Package: miscutils
Version: 1.3-5
Run-parts does not run scripts not beginning with #!/... This may not be
a bug, but it should be documented. run-parts --test, however, displays
_all_ scripts, which is rather confusing, and not a test at all.
Harald Schueler
Universitaet Essen
Andrew Howell writes:
>Bill Mitchell writes:
>>Dx -- dunno. Didn't take note when I had it open. I grepped
>>/var/log/messages for a bogomips figure, but that's apparently
>>no longer part of the startup. As I recall under earlier kernels,
>>it was low -- perhaps 6.something. Better than the 3
Bill Mitchell writes:
> Dx -- dunno. Didn't take note when I had it open. I grepped
> /var/log/messages for a bogomips figure, but that's apparently
> no longer part of the startup. As I recall under earlier kernels,
> it was low -- perhaps 6.something. Better than the 386 I used
> to run, whic
On Thu, 23 Nov 1995, Andrew Howell wrote:
> Is your 486 a dx? Do you have any video memory left over for a font cache?
> How much RAM do you have? What kind of video card?
Dx -- dunno. Didn't take note when I had it open. I grepped
/var/log/messages for a bogomips figure, but that's apparently
Bill Mitchell:
In my own packages, I've been trying to provide debianized docs
which change references to /usr/local to just plain /usr where it's
clear from the context that this would be incorrect on a debian
system. I've come to think that even this amount of twiddling the
upstre
Forwarded message:
> From [EMAIL PROTECTED] Thu Nov 23 20:18:43 1995
> From: Mail Router (smail 2.9 dl,da,fa,tu,po,qf,lo,dbm 03/23/95 43) <[EMAIL
> PROTECTED]>
> Message-Id: <[EMAIL PROTECTED]>
> Date: 23 Nov 95 12:18:28 GMT
> Subject: Returned mail
> To: [EMAIL PROTECTED]
>
> Your mail could n
Package: syslogd
Version: 1.2-17
On my (Erick) system:
# dpkg -i syslogd-1.2-17.deb
(Reading database ... 20881 files and directories currently installed.)
Preparing to replace syslogd (using
/home/ftp/pub/debian/base/syslogd-1.2-17.deb) ...
Unpacking replacement syslogd ...
Setting up syslogd .
Bill Mitchell wrote:
> When either xtet42 or chimera are started up on my 486-40 system,
> the system appears to hang while these apps are initializing. During
> this period, mouse movement is unrecognized, ctl-alt-F1 and friends
> don't work, ctl-alt-backspace doesn't work, and ctl-alt-del doesn'
On Wed, 22 Nov 1995, Ian Jackson wrote:
> Are you sure this is true in at 2.9a-1 ? My source tree seems to
> suggest that they use `mail'. I should probably add a dependency.
Yes, I'm pretty sure (unless there is more than one at-2.9a-1 out there).
The following diff works for me:
--- debian.s
If you have problems with dipconfig please apply the following patch:
--- dipconfig.0 Thu Nov 23 09:48:51 1995
+++ dipconfig Thu Nov 23 09:48:44 1995
@@ -5,7 +5,8 @@
$dialog = "dialog --backtitle 'Debian GNU/Linux DIP setup'";
# redirect STDERR and STDOUT
-$rd = "2>&1 >/dev/tty";
+$tty = `tty
Kenny Wickstrom writes:
> The only problem I noticed is at installation time xtet42 depends on
> X11R6 and I don't run an X server on my Debian machine. My X server is
> on my Win 95 machine. So to get xtet42 to install I needed to add the
> --force-depends to the dpkg command line.
xtet42 de
On Wed, 22 Nov 1995, Bill Mitchell wrote:
> I'm wondering if this is (1) normal? (2) antisocial apps needing
> upstream attention? (3) something else?
I just installed xtet42 on my system and is runs fine. I didn't notice
any delay in starting (up and playing in less than 20 seconds).
The o
> Karl Ferguson writes ("Re: md5sum passwords"):
> > I know what you're all saying, but I'd definately like the MD5 in place as
> > an
> > optional extra. Isn't that possible? The extra security as an Internet
> > Provider is a much needed asset...
>
> As I wrote earlier, MD5 used in this way
Bill Mitchell writes:
>
>
> I'm not sure that this behavior is buggy, so I'm not casting this
> as a bug report.
>
> I previously reported as a bug that xtet42 hung my system. That
> was dismissed as a probable problem with my system. I've characterised
> this a bit more, and thought I'd repor
I'm not sure that this behavior is buggy, so I'm not casting this
as a bug report.
I previously reported as a bug that xtet42 hung my system. That
was dismissed as a probable problem with my system. I've characterised
this a bit more, and thought I'd report the additional info.
When either xte
31 matches
Mail list logo
