Submitted by: ishisone@sra.co.jp
Make touch handle years 2000-2038 in the obsoleted format, rather
than 1902-1969 as was previously the case with two digit year spec.
note of this in the updating file. Put it under the 19981224 date
rather than today's date, since that was when the change was.
Submitted by: Gregory Bond <gnb@itga.com.au>
Also added note about floppy tape driver. Didn't add note about
voxware or pcvt as they have been restored to the kernel.
day when the elves sail accross the sea to a new home, which happens
to be in your computer. They will sing glorious songs for the Eldar
days. You machine will shun the darkness that is upon the world.
Errrm, well actually you won't even notice...
Submitted by: peter
Appologies to: tokien
is enough to satisfy things like StarOffice. This is a hack, but doing
it properly would be a LOT of work, and would require extensive grovelling
around in the user address space to find the argv[].
Obtained from: Mostly from Andrzej Bialecki <abial@nask.pl>.
isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.
(I was never able to personally trip the bug on this chip rev, but today
one of the guys in the lab did it with the software they're working on
for their cellular IP project, which uses BPF and promiscuous mode
extensively.)
This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
The char that the random letters and numbers are being pulled from is
ended with a '\0'. Using sizeof() includes this '\0' in the 'pool' of
possible characters. This patch decrements by one the size so we don't
accidently end the new password prematurly.
so it can't be completely fixed here. Putting -I paths to the current
headers in CFLAGS is more likely to break things than fix them, since
there is no reason why current headers should work with old libraries.
Other Makefiles that do this may only work because they are not used early
in the bootstrap. However, the usual problem with errno being defined in
terms of a nonexistent library doesn't seem to occur here, since we don't
reference errno.
probably other versions by spamming ${DESTDIR}/usr/include in much
the same way as `make includes'.
Details for 2.2.7: the bootstrap target has always done a weak spam
of ${DESTDIR}/usr/include; we depend on it not installing any
significant anachronisms (it probably shouldn't touch the headers
at all; however, we may be depending on it for things like the
renaming of ts_nsec to ts_sec in <sys/time.h>). Rev.1.49 strengthens
the spam to everything in src/include. For 2.2.7, this is not
immediately fatal. However, the `make all' step in src/includes
is not followed by a `make clean' step, so new rpc headers are not
generated after we've bootstrapped rpcgen. This causes a fatal
error much later when the old (generated) rpc headers are used with
the current headers (sys/types.h and/or the non-generated rpc
headers).
Details for 2.1.x: the bug is immediately fatal. It gives definition
of errno that is not supported by 2.1.x's libc. The weak spam in the
restored version avoids this problem by not installing errno.h.
(Bootstrapping from 2.1.5 actually breaks much earlier.)
I think the header problems supposedly fixed by rev.1.49 were caused
by using NOCLEAN and having the build fall over when the weakly
spammed headers are active. Minor differences in the layout will
then cause the .depend files to point to nonexistent headers. It
is a feature for symlinks like errno.h -> sys/errno.h to not exist
early.
The other change in rev.1.49 breaks building obj directories if NOCLEAN
is set. It is only safe for _re_building with NOCLEAN set.
a circular dependency problem, wherein rpcgen depends on the latest
includes, but those same includes depend on rpcgen to build
include/rpcsvc. This was causing the build or librpcsvc to fail
(like I said, only on upgrades of 9 month old sources).
If there's stylistic problems, tell me, I'll learn and fix them.
I did a buildworld with this, it should be safe.
CAPACITY fail for a non-removable media device. There's a race
condition where the device entry is removed and then
xpt_release_ccb is called which attempts to give back the ccb
to a device that's now gone. In this bandaid release the ccb
early and then remember to not call xpt_release_ccb later.
- Special registers of IO-DATA device's RSA series are defined in
ic/rsa.h (new file).
Pointed out by: Bruce Evans <bde@zeta.org.au>
Submitted by: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.ac.jp>
