| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
fact that caddr_t is often misspelled as char *.
Sponsored by: DARPA, NAI Labs
|
|
|
|
|
|
|
| |
with variable numbers of arguments made this slightly harder than
it should be. Avoid the bug by not doing string concatenation within
the macros, and instead add a new function to syslog or print the
error messages.
|
|
|
|
| |
longer exist.
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
to (void *) to satisfy some stricter warning-level checks in the new
gcc (on sparc64).
Reviewed by: obrien
MFC after: 4 days
|
|
|
|
|
|
| |
Submitted by: Nicola Vitale <nivit@libero.it>
Reviewed by: hm
MFC after: 3 days
|
|
|
|
|
|
| |
Submitted by: morito@double-fault.net
Obtained from: KAME
MFC after: 3 days
|
|
|
|
|
|
| |
Submitted by: Yukiyo Akisada <Yukiyo.Akisada@jp.yokogawa.com>
Obtained from: KAME
MFC after: 3 days
|
|
|
|
|
|
|
| |
This is done since it contains much more than /bin, and also gets in the
way when making a combined install+fixit CD.
OK'ed by: jkh
|
|
|
|
|
|
|
| |
connect() to the socket for lpd. Tell them this error probably means that
the master 'lpd' process is not running.
MFC after: 4 days
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a boolean option, and if it is specified in a print queue
for a remote host, it causes lpd to resend the data file for each
copy the user requested on 'lpr -#n'. This is useful for network
printers which accept lpd-style jobs, but which ignore the control
file (and thus they ignore any request for multiple copies).
PR: 25635
Reviewed by: short review on freebsd-audit
MFC after: 6 days
|
|
|
|
|
|
| |
new gcc (on sparc64).
MFC after: 4 days
|
|
|
|
|
|
| |
new gcc (on sparc64).
MFC after: 4 days
|
|
|
|
|
| |
Also change one case of blatant __progname abuse (several more remain)
This commit does not touch anything in src/{contrib,crypto,gnu}/.
|
| |
|
| |
|
|
|
|
|
|
| |
default values are underlined (instead of using fake double-quotes).
MFC after: 4 days
|
|
|
|
|
|
|
|
| |
for `tf' (troff filter), and add a cross-reference to chkprintcap in some
lpr-related man pages.
Submitted by: dwmalone
MFC after: 4 days
|
|
|
|
|
|
| |
rendering of the man pages (turns some sequences of two blank lines
into a single blank line), and eliminates 306 errors generated while
formatting named.conf.5 .
|
|
|
|
|
|
|
| |
fails and on loss of carrier, the device doesn't become selectable with
0 bytes to read.
Problem reported by: ache
|
|
|
|
| |
Sponsored by: FreeBSD Mall, Inc.
|
| |
|
| |
|
|
|
|
|
|
|
| |
to Sweden standards.
Submitted by: Roger Olofsson <roger.olofsson@kommun.engelholm.se>
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
for what is currently the '-p' parameter. '-s' is what NetBSD
used (and they implemented it before I added -p in FreeBSD), and
it also matches the '-s' option in syslogd. Someone in OpenBSD
land had also talked about adding a '-s' option, but it hasn't
happened yet.
MFC after: 5 days
|
|
|
|
|
|
| |
line is using strlcpy instead of strncpy.
MFC after: 4 days
|
|
|
|
|
| |
Obtained from: NetBSD, OpenBSD
MFC after: 4 days
|
|
|
|
|
|
| |
execute a given filter.
MFC after: 4 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination.
(Currently lack of their specification does not lead to any problem, because
kernel does not check the consistency between actual address and its
address family / length on raw socket.
However kernel should always check their consistency and stop sending packets
if there is a contradiction. Considering backward compatibility of
programs, I just fixed rtsol now; I'd like to fix the kernel behavior later.)
Reviewed by: ume
MFC after: 3 days
|
|
|
|
|
|
|
| |
(based on freebsd4-snap-20020128)
Reviewed by: ume
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
Update copyright date.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
Extracted from: green
|
|
|
|
|
| |
IPPACKETSOUT, IPV6OCTETSIN, IPV6OCTETSOUT, IPV6PACKETSIN, IPV6PACKETSOUT,
OCTETSIN, OCTETSOUT, PACKETSIN, PACKETSOUT and SOCKNAME.
|
|
|
|
|
|
|
|
|
| |
them to point at static strings that contain the default paths. This
makes 'vipw -d' work again (I broke it in rev 1.21; apologies for taking
so long to fix it.)
Spotted by: Olivier Houchard <doginou@cognet.ci0.org>
Sponsored by: DARPA, NAI Labs
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
instead of u_char *.
The changes are cosmetic except:
RecvConfigAck() now displays the options that are being ACK'd
Huge (bogus) options sent from the peer won't cause an infinite loop
SendIdent and ReceiveIdent are displayed consistenlty with other FSM data
LCP AUTHPROTO options that aren't understood are NAK'd, not REJ'd
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
tun0.
Submitted by: qhwt@myrealbox.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).
Here's a description of the problem and my fix:
The problem with the old MTRR code is that it only expects
to find documented values in the bytes of MTRR registers.
To convert the MTRR byte into a FreeBSD "Memory Range Type"
(mrt) it uses the byte value and looks it up in an array.
If the value is not in range then the mrt value ends up
containing random junk.
This isn't an immediate problem. The mrt value is only used
later when rewriting the MTRR registers. When we finally
go to write a value back again, the function i686_mtrrtype()
searches for the junk value and returns -1 when it fails
to find it. This is converted to a byte (0xff) and written
back to the register, causing a GPF as 0xff is an illegal
value for a MTRR byte.
To work around this problem I've added a new mrt flag
MDF_UNKNOWN. We set this when we read a MTRR byte which
we do not understand. If we try to convert a MDF_UNKNOWN
back into a MTRR value, then the new function, i686_mrt2mtrr,
just returns the old value of the MTRR byte. This leaves
the memory range type unchanged.
I have seen one side effect of the fix, which is that ACPI calls
after X has been run seem to hang my machine. As running X would
previously panic the machine, this is still an improvement ;-)
I'd like to MFC this before the 4.6 code freeze - please let me
know if it causes any problems.
PR: 28418, 25958
Tested by: jkh, Christopher Masto <chris@netmonger.net>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
present, this field specifies the media volume that the disc is
contained on. If the volume of a given packages is different than the
current volume of mediaDevice, then the user is prompted --
"This is disc #%d. Package %s is on disc #%d\n"
"Would you like to switch discs now?\n"
If the user selects yes, then DEVICE_SHUTDOWN is called and the user
is then prompted --
"Please remove disc #%d from you drive, and add disc #%d"
This works well for a carefully crafted INDEX file, but more work
needs to be done to sort dependencies on a given package based on the
volume that they reside on, to minimize the amount of disc flipping
required of the user.
This commit is a no-op for normal INDEX files and FreeBSD CDs. These
additional features are only used if the INDEX and cdrom.inf file have
multi-volume support.
|
|
|
|
| |
initialize the volume ID for the media device in use.
|
|
|
|
|
| |
these values are different for a given package, then we must prompt
the user to insert another disc before the package can be installed.
|
| |
|
| |
|
|
|
|
|
|
| |
print out the correct transport it failed on rather than always
spitting out 'udp', also call nc_sperror() to give a more verbose
error message detailing the problem.
|
|
|
|
|
|
|
|
| |
I missed this as part of the fix to the PR below.
PR: 31265
Submitted by: Matthew D. Fuller <fullermd@over-yonder.net>
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
files are owned by the caller of newsyslog (usually root:wheel) even if
alternative ownerships were specified in newsyslog.conf.
Note that this is part of a wider problem which is fully addressed in
OpenBSD. Anyone with the time and inclination to incorporate the full
fix for the wider problem will receive no complaints from me and should
feel free to walk all over this delta.
PR: bin/36738
MFC after: 1 week
|
|
|
|
|
| |
PR: 36457
No objections from: ru
|
|
|
|
|
|
| |
PR: 36447
No objections from: ru
MFC after: 3 days
|