Version bump from outdated version 1.x to munin 2.0.49. Developed and imported
from WIP in cooperation with Sebastian Wiedenroth, Roland Illig, Filip Hajny and
Francois Tigeot.
Unsorted entries in PLIST files have generated a pkglint warning for at
least 12 years. Somewhat more recently, pkglint has learned to sort
PLIST files automatically. Since pkglint 5.4.23, the sorting is only
done in obvious, simple cases. These have been applied by running:
pkglint -Cnone,PLIST -Wnone,plist-sort -r -F
Problems found with existing digests:
Package memconf distfile memconf-2.16/memconf.gz
b6f4b736cac388dddc5070670351cf7262aba048 [recorded]
95748686a5ad8144232f4d4abc9bf052721a196f [calculated]
Problems found locating distfiles:
Package dc-tools: missing distfile dc-tools/abs0-dc-burn-netbsd-1.5-0-gae55ec9
Package ipw-firmware: missing distfile ipw2100-fw-1.2.tgz
Package iwi-firmware: missing distfile ipw2200-fw-2.3.tgz
Package nvnet: missing distfile nvnet-netbsd-src-20050620.tgz
Package syslog-ng: missing distfile syslog-ng-3.7.2.tar.gz
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
as root, so you need a ${SYSCONFDIR}/munin/plugin-conf.d/entropy file
with
[entropy]
user root
as contents to get any values. And... at the same time, I notice that
the postfix_mailqueue script also needs a postfix plugin-conf.d file with
[postfix_mailqueue]
user postfix
as contents to get any values.
Bump PKGREVISION.
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
+INSTALL script. This causes problems when you build the package on one
machine but install it on another not necessarily with the same
accounts configured.
XXX any real use for USERGROUP_PHASE=pre-install? IIUC pkg_install
installs USERGROUP during pre-install-script target by default, making it
explicit seems to cause more problems than it solves...
the owner of all installed files is a non-root user. This change
affects most packages that require special users or groups by making
them use the specified unprivileged user and group instead.
(1) Add two new variables PKG_GROUPS_VARS and PKG_USERS_VARS to
unprivileged.mk. These two variables are lists of other bmake
variables that define package-specific users and groups. Packages
that have user-settable variables for users and groups, e.g. apache
and APACHE_{USER,GROUP}, courier-mta and COURIER_{USER,GROUP},
etc., should list these variables in PKG_USERS_VARS and PKG_GROUPS_VARS
so that unprivileged.mk can know to set them to ${UNPRIVILEGED_USER}
and ${UNPRIVILEGED_GROUP}.
(2) Modify packages to use PKG_GROUPS_VARS and PKG_USERS_VARS.
process running at a certain PID is actually the process we wish to
stop. Just unconditionally send SIGTERM to the PID instead, like a
security/amavisd-new doing, fixed PR 35334.
