Got the following with up to the minute sources:
cc -O -pipe
-I/usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/../ktrace
-I/usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/../.. -c
/usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/kdump.c
sh /usr/amd/realmounts/slav
The Pyramid series of machines used to have block tape devices, such that one
was able to boot a repair kernel and ro root fs off the 1600bpi reel-to-reel
deck. Not unaturally, one was discouraged from doing a recursive find on that
fs.
Stephen (who used to have thoughts of doing the
I have a suggestion for pkg_delete: Very often when I'm deleting a package
(such as kde, after testing the port) I want to delete that package, and
all it's dependancies; instead of going around looking for the
dependancies, I think it would be a nice idea to add an option to
pkg_delete to automat
Ok, I stand corrected.
Rahul
On Sun, 7 May 2000, Bill Fenner wrote:
>
> >By "gratuituous arp" I was really saying "gratuitous arp reply".
> >The machine needs to send a packet of the type
> >
> > arp reply 1.2.3.5 is-at 0:40:5:42:d6:de
>
> The ARP processing specified in RFC 826 says that i
On Sun, 7 May 2000, Garrett Wollman wrote:
# It wouldn't cover the particular obscure case, but this is the sort of
It was a pretty bizarre case, but the old code did cover this.
Not saying whether I think it to be correct or not but... :)
# thing that SUSv2's basename(3) would be appropriate f
>By "gratuituous arp" I was really saying "gratuitous arp reply".
>The machine needs to send a packet of the type
>
> arp reply 1.2.3.5 is-at 0:40:5:42:d6:de
The ARP processing specified in RFC 826 says that if you have an entry for
the source IP address you update the hardware address no matt
< said:
> I've been experiencing a problem with 'pkg_delete m4-1.1/'
> hanging. Attached is a patch that fixes this problem, cleans
> the code up a bit (IMHO), and still covers all the corner
> cases like 'pkg_delete /var/db/pkg/m4-1.1//./..///' like the
> old code did. :)
It wouldn't cover the
By "gratuituous arp" I was really saying "gratuitous arp reply".
The machine needs to send a packet of the type
arp reply 1.2.3.5 is-at 0:40:5:42:d6:de
Rahul
On Sun, 7 May 2000, Bill Fenner wrote:
> fenestro# ifconfig de1 1.2.3.5 alias
> 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: ar
FreeBSD 4.0-RELEASE does the gratuitous ARP when ifconfig'ing an alias:
fenestro# ifconfig de1 1.2.3.5 alias
18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5
FreeBSD 3.4-STABLE also does:
mango# ifconfig xl0 135.197.2.250 netmask 255.255.255.255 alias
18:39:12
Greg Lehey <[EMAIL PROTECTED]> wrote:
> I suspect that's an assumption on your part. I think we've come up
> with enough man pages to support naddy's statement.
Which, btw, was drawn from inspection of MAKEDEV in the various
4.xBSD releases in the CSRG archives (Kirk's CD set). Personally,
I ta
On Sunday, 7 May 2000 at 16:48:36 -0700, Mike Smith wrote:
>> Mike Smith <[EMAIL PROTECTED]> wrote:
>>
>>> The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix
>>> for disk devices.
>>
>> I'd like to see some backup for this assertion. Historically, BSD
>> (up to 4.4) used to h
Jordan,
I've been experiencing a problem with 'pkg_delete m4-1.1/'
hanging. Attached is a patch that fixes this problem, cleans
the code up a bit (IMHO), and still covers all the corner
cases like 'pkg_delete /var/db/pkg/m4-1.1//./..///' like the
old code did. :)
BTW, it appears pkg_info had a
"John W. DeBoskey" wrote:
>
> fyi...
>
> ===> Creating README.html for tkrat-1.2
> ===> mail/tkrat2
> ===> Creating README.html for tkrat-2.0b9
> ===> mail/wanderlust-emacs
> Error: Bad value of EMACS_PORT_NAME: emacs.
> Valid values are:
> Emacs family: emacs19 mule19 emacs20
>
> Mike Smith <[EMAIL PROTECTED]> wrote:
>
> > The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix
> > for disk devices.
>
> I'd like to see some backup for this assertion. Historically, BSD
> (up to 4.4) used to have
>
> mt block device, rewinding
>nmt block devic
Mike Smith <[EMAIL PROTECTED]> wrote:
> The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix
> for disk devices.
I'd like to see some backup for this assertion. Historically, BSD
(up to 4.4) used to have
mt block device, rewinding
nmt block device, non-rewinding
fyi...
===> Creating README.html for tkrat-1.2
===> mail/tkrat2
===> Creating README.html for tkrat-2.0b9
===> mail/wanderlust-emacs
Error: Bad value of EMACS_PORT_NAME: emacs.
Valid values are:
Emacs family: emacs19 mule19 emacs20
XEmacs family: xemacs19 xemacs20 xemacs21 x
Steve Price wrote:
>
> On Sun, 7 May 2000, Doug Barton wrote:
>
> # Ok, here are some silly questions. Did you create a private key for
> # this server, did you encrypt your cert with it, and is that .key file
> # pointed to in your httpd.conf config file? SSLCertificateKeyFile is what
> #
On Sun, 7 May 2000, Steve Price wrote:
> # Then:
> #
> # dumpasn1 file.der
>
> root@bonsai(/usr/local/etc/apache/ssl.key)# dumpasn1 server.key
Nope, this is the .pem-encoded version. You need to decode it to .der
using:
openssl asn1parse -in server.key -out server.der
before running dumpasn1
On Sun, 7 May 2000, Doug Barton wrote:
# Ok, here are some silly questions. Did you create a private key for
# this server, did you encrypt your cert with it, and is that .key file
# pointed to in your httpd.conf config file? SSLCertificateKeyFile is what
# you're looking for. http://www.mo
Is it only me that ever compiles LINT? The checksum changes went in a
few days ago.
Please, people, when you move code around or change a function that is
used in more than a fixed set of files, compile LINT. If unsure, compile
LINT. It's an extra five minutes, but well worth it.
linking kernel
> On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
> > OpenBSD only changed "rmt" to "rst" ("rsa" for us)
>
> Just "sa" for us -- "sa" is now a raw device and "rFOO" use is
> depreciated.
We had this argument the other day, and you clearly didn't understand.
We have three d
Will Andrews wrote:
>
> Hello,
>
> I've noticed an inconsistency among our ports. It seems that not every port
> that installs rc.d startup scripts includes methods to not only startup,
> but also shutdown and/or restart, where appropriate. (Sent to -ports for
> ports hackers' opinions.)
On Sun, 7 May 2000, Mike Smith wrote:
>
> Since there's a sysctl you can use to turn the former off, perhaps it
> would have been smart to take a few seconds to narrow it down?
Those changes wouldn't have affected ICMP, but we tried that anyway.
The problem was that the code changed the expres
> On Sun, May 07, 2000 at 04:15:57PM +0200, Jeroen Ruigrok van der Werven wrote:
> > -On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote:
> > >It is not dead card, it is broken TCP, see my similar report in -current, I
> > >notice it several hours ago
Steve Price wrote:
>
> On Fri, 5 May 2000, Kris Kennaway wrote:
>
> # I'm suspecting it might be something missing in the ASN.1 encoding of the
> # certificate, which netscape requires but IE permits. This would be
> # consistent with a missing openssl.cnf file at the time of certificate
> # gen
[CC culled, -stable removed]
David O'Brien wrote:
>
> On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote:
> > Can we settle this once and for all in a slightly sane manner?
> >
> > I committed the change so that MAKEDEV acd1 creates acd1 and not just
> > acd0.
>
> Thi
Le 2000-05-07, Mike Nowlin écrivait :
> stuff that sends SIGHUP to Apache. Gated got it right - add a simple
> program (gdc) that does the extra stuff. If we could get the ports
Bind has that as well with 'ndc', and apache with apachectl.
Such helper scripts are indeed very useful, and it owul
Oh, and in the updating of this, don't forget the FreeBSD usage of .ctl for
tape devices- as far as I know this is the only *BSD that has this.
On Sun, 7 May 2000, David O'Brien wrote:
> On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
> > OpenBSD only changed "rmt" to "rst
On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote:
> Can we settle this once and for all in a slightly sane manner?
>
> I committed the change so that MAKEDEV acd1 creates acd1 and not just
> acd0.
This is wrong. ``MAKEDEV acd2'' should either create only /dev/acd2*,
On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
> OpenBSD only changed "rmt" to "rst" ("rsa" for us)
Just "sa" for us -- "sa" is now a raw device and "rFOO" use is
depreciated.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
On Sat, 6 May 2000, Kris Kennaway wrote:
# I'm strongly suspecting something wrong with the encoding of the
# certificate. Can you grab dumpasn1.c and dumpasn1.cfg from
[snip]
# Then:
#
# dumpasn1 file.der
root@bonsai(/usr/local/etc/apache/ssl.key)# dumpasn1 server.key
0 2D 45: Unknown (
On Sun, May 07, 2000 at 08:19:23 -0700, Paul Saab wrote:
>
> I came up with this patch, which fixes my i386 machine.. I dont have an
> alpha to test.
>
> http://people.freebsd.org/~ps/cksum.diff
>
Fixes it for my machine (i386) too. Thanks Paul!
Regards
--
Udo Schweigert, Siemens AG | Voi
Andrey A. Chernov ([EMAIL PROTECTED]) wrote:
> Some of recent kernel TCP changes cause TCP completely not working,
> i.e. any network daemon (mountd, sendmail, cfsd) started from "rc" on
> dialup machine hangs with 3min "Can't connect' timeout and user level
> "ppp" started than hangs forever eve
-On [2506 21:55], Bruce Evans ([EMAIL PROTECTED]) wrote:
>On Sat, 6 May 2000, Maxim Sobolev wrote:
>
>> I've just noticed that "sh MAKEDEV acd1" doesn't produce node for acd1 due to
>> incorrect comparasion in the "while" loop. This affecting both 4.0-STABLE and
>> 5.0-CURRENT. With this messa
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Can someone explain to me why pax(1) has (undocumented) switches which
> select some tape devices, but apparently randomly numbered ones:
Note that these switches appear only in pax' tar compatibility
personality, which isn't used in FreeBSD. And the re
"Andrey A. Chernov" <[EMAIL PROTECTED]> écrivait (wrote) :
> Some of recent kernel TCP changes cause TCP completely not working,
> i.e. any network daemon (mountd, sendmail, cfsd) started from "rc" on
> dialup machine hangs with 3min "Can't connect' timeout and user level
> "ppp" started than ha
Jonathan Lemon <[EMAIL PROTECTED]> écrivait (wrote) :
> jlemon 2000/05/05 20:31:10 PDT
>
> Modified files:
> sys/netinet tcp.h tcp_input.c tcp_output.c
> tcp_timer.c tcp_var.h
> Log:
> Implement TCP NewReno, as documented in RFC 2582. This allo
On Sun, May 07, 2000 at 04:15:57PM +0200, Jeroen Ruigrok van der Werven wrote:
> -On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote:
> >It is not dead card, it is broken TCP, see my similar report in -current, I
> >notice it several hours ago right after TCP chang
-On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote:
>It is not dead card, it is broken TCP, see my similar report in -current, I
>notice it several hours ago right after TCP changes was commited.
I assume you mean the NewReno commit submitted by Jayanth?
--
Jeroen Ruigr
Eines schoenen Tages schrieb Oliver Schonefeld:
[snip]
> > It is not dead card, it is broken TCP, see my similar report in -current, I
> > notice it several hours ago right after TCP changes was commited.
>
> Same thing here, but the problems have gone to -stabe too. due to a probable
> tcp brea
Eines schoenen Tages schrieb Andrey A. Chernov:
> On Sun, May 07, 2000 at 06:44:39PM +0930, Greg Lehey wrote:
> > I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May,
> > and since then *some* Ethernet transactions don't work. I've checked
> > that it's not just a dead card: the p
On Sun, May 07, 2000 at 06:44:39PM +0930, Greg Lehey wrote:
> I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May,
> and since then *some* Ethernet transactions don't work. I've checked
> that it's not just a dead card: the previous kernel works fine. I
> have the funny situation
Can someone explain to me why pax(1) has (undocumented) switches which
select some tape devices, but apparently randomly numbered ones:
>From tar.h:
/*
* default device names
*/
#define DEV_0 "/dev/rmt0"
#define DEV_1 "/dev/rmt1"
#define DEV_4 "/dev/rmt4"
#define
I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May,
and since then *some* Ethernet transactions don't work. I've checked
that it's not just a dead card: the previous kernel works fine. I
have the funny situation that I can send fine, and I can traceroute to
the box, but I can't
> Fine, you can quote historical context to argue against doing something
> similar to SVR4 init. I, however, see nothing wrong with making it easier
> to manage the daemons. Of course, that does not necessarily need to go in
> the rc.d scripts.
This is as it should be.. "rc" files (and directo
45 matches
Mail list logo
