| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
places.
Comment out crc32 related definitions in zlib.h, we don't seem to have the
corresponding code in our kernel.
|
| | |
|
| |
|
|
|
|
| |
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
|
| | |
|
| |
|
|
| |
kernel compile
|
| |
|
|
| |
that the deflate components use zlib 1.0.4 instead of zlib 0.95.
|
| |
|
|
|
|
|
|
|
|
| |
2.3.0 -> 2.3.1 changes, but I seem to recall that there are certain
"issues" with 2.3.1 (I'm not sure if it's just pppd or the whole lot, I
am not quite that far). The present pppd seems to work with it just fine
for the time being.
Among the changes are that zlib (aka LZ77 aka deflate aka gzip) compression
is implemented as well as the original compress(1) LZW style.
|
| |
|
|
|
|
|
|
|
|
|
| |
1: cvs and cvsup don't really support vendor branches other than 1.1.1.x,
this is on 1.1.2.x and causing problems in cvsup 'checkout mode', just the
same as cvs has problems interpreting dates. (cvs has "1.1.1" hard coded)
2: cvs 'rm'ing them takes them off the vendor branch and should hide the
above problems.
3: it's just clutter until the merge is done.
4: if the problem isn't sufficiently resolved by taking these off the
vendor branch, the files will have to be nuked and re-imported.
|
| |
|
