default broken flags. groff 1.19 defaulted to this value off, whereas
groff 1.18.1 and earlier defaulted to this being on. Setting this value
fixes postscript printing to my HP LJ4m.
Note: BROKEN_SPOOLER_FLAGS was previously `7', so we were already enabling
workarounds for other issues...
from GENTOO LINUX SECURITY ANNOUNCEMENT 200312-08
"Stable CVS 1.11.11 has been released. Stable releases contain only
bug fixes from previous versions of CVS. This release adds code to
the CVS server to prevent it from continuing as root after a user
login, as an extra failsafe against a compromise of the
CVSROOT/passwd file. Previously, any user with the ability to write
the CVSROOT/passwd file could execute arbitrary code as the root
user on systems with CVS pserver access enabled. We recommend this
upgrade for all CVS servers!"
date: 2003/07/09 01:27:30; author: cgd; state: Exp; lines: +3 -2
2003-07-08 Chris Demetriou <cgd@broadcom.com>
* config/tc-mips.c (mips_validate_fix): Do not warn about branch
target being a global symbol if not compiling SVR4 PIC code.
Fixes warnings compiling MIPS kernels. Problem noticed by Izumi Tsutsui
on the port-pmax list.
PR optimization/13037
* loop.c (update_giv_derive): Ignore redundant sets of a biv
when calculating how to derive a giv from a biv.
This fixes the underlying problem in toolchain/23002.
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)