Bump upper boundary of allowed version of Shpinx to 1.7 in new,
non-stabilized boto3 ebuilds.
Dependency on Sphinx has versions range. Declaration of this range comes
from requirements-docs.txt in boto3 sources, but that file hasn't been
updated since 2015. Latest Sphinx, version 1.6.5, builds boto3 docs
successfully.
Sphinx versions range bump has been suggested to boto3 maintainers, but
there's nothing preventing newer Sphinx from working on already released
versions.
Link: https://github.com/boto/boto3/pull/1337
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
Copied from 1.4.4 ebuild with such changes:
* stable keywords downgraded to testing
* dev-python/botocore dependency versions range updated to require 1.7.*
in accordance with upstream setup.{cfg,py}
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
This version is not the latest one, but it is the only one expecting
botocore of version 1.6.*.
Copied from 1.4.4 ebuild with such changes:
* stable keywords downgraded to testing
* dev-python/botocore dependency versions range updated to require 1.6.*
in accordance with upstream setup.{cfg,py}
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
Bump upper boundary of allowed version of Shpinx to 1.7 in new,
non-stabilized botocore ebuilds.
Dependency on Sphinx has versions range. Declaration of this range comes
from requirements-docs.txt in botocore sources, but that file hasn't
been updated since 2015. Latest Sphinx, version 1.6.5, builds botocore
docs successfully.
Sphinx versions range bump has been suggested to botocore maintainers,
but there's nothing preventing newer Sphinx from working on already
released botocore versions.
Link: https://github.com/boto/botocore/pull/1306
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
This is currently the latest upstream release.
Ebuild copied from 1.5.90 with stable keywords downgraded to testing.
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
This is the last release in 1.6.x series.
Ebuild copied from 1.5.90 with stable keywords downgraded to testing.
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
This is the last release in 1.5.x series.
Ebuild copied from 1.5.90 with stable keywords downgraded to testing.
Acked-by: Alex Brandt <alunduil@gentoo.org>
Package-Manager: Portage-2.3.12, Repoman-2.3.3
Version bump to 2.12.6, we use now a fixed copy of the tar ball.
Had to migrate from 'fdo-mime' to 'xdg-utils' to make repoman happy.
Bug: https://bugs.gentoo.org/627062
Closes: https://bugs.gentoo.org/626130
Package-Manager: Portage-2.3.13, Repoman-2.3.4
The past few revisions have made some directories owned by the "nagios
user" so that the nagios/icinga daemon can write stuff there. Instead
of giving ownership of those directories to the nagios user, it's a
little bit more secure to give group-rwx permissions to the "nagios
group." This new revision does that instead.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
Now that pnp4nagios doesn't rely on the localstatedir of Nagios or
Icinga, the two implementations of Icinga are actually suitable for an
"or" dependency. We therefore do away with USE=icinga2, and let
USE=icinga mean "either icinga or icinga2."
Package-Manager: Portage-2.3.8, Repoman-2.3.3
With USE=apache2, we used to set the group of process_perfdata.cfg to
"apache2", but that appears unnecessary. This revision doesn't do it.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
The process_perfdata.cfg file refers to a STATS_DIR that is set to
"@localstatedir@/stats" at build-time. However, the build system
doesn't create that directory nor ensure that it is writable. This
latest revision passes --localstatedir to econf, and then creates the
associated directory with the desired permissions. The "bulk mode"
without NPCD now works out-of-the-box!
Package-Manager: Portage-2.3.8, Repoman-2.3.3
Past revisions have stored the RRDtool data and the process_perdata.pl
logs in (for example) /var/nagios or /var/icinga, depending on whether
or you had Nagios or Icinga installed. That's silly: the data format
doesn't change, so it makes more sense to choose one location (now:
/var/lib/pnp) and stick with it.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
The last few revisions have done,
insinto "${APACHE_MODULES_CONFDIR}"
but the depend.apache eclass was removed in pnp4nagios-0.6.25-r3,
which means that the conf file wound up installed to ${ROOT}. The
new revision specifies the path explicitly without using the eclass
variable.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
The apache "define" changed a while ago from "PHP5" to simply "PHP".
This commit fixes the latest revision, in place, to output the correct
instructions.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
Previous revisions of pnp4nagios install /etc/pnp owned by the "nagios
user," and the npcd daemon also runs as that user. That configuration
is insecure: the unprivileged user can edit /etc/pnp/npcd.cfg, and
escalate his own privileges by setting "user = root". To avoid the
problem, we set INSTALL_OPTS="" while running "emake install". That
leaves all of /etc/pnp with the default (root:root) ownership.
Bug: https://github.com/lingej/pnp4nagios/issues/140
Package-Manager: Portage-2.3.8, Repoman-2.3.3
In CVE-2012-3457, it was reported that one particular file should not
be world-readable. To fix that, our ebuild made all of /etc/pnp
unreadable; that made other permissions issues difficult to work
around. This r2 sets o-rwx only on /etc/pnp/process_perfdata.cfg.
Bug: https://bugs.gentoo.org/430358
Package-Manager: Portage-2.3.8, Repoman-2.3.3
Previous revisions of pnp4nagios have an "or" dependency on either
Nagios or Icinga,
|| ( net-analyzer/nagios-core net-analyzer/icinga ...
The way "or" dependencies work is that they are considered satisfied
if any elements of the associated group are installed. Thus the above
stanza allows Nagios and Icinga to be swapped out without rebuilding
pnp4nagios. That is incorrect, since later in the ebuild, nagios-
or icinga-specific paths are compiled into pnp4nagios.
The usual solution to that problem is to choose a default package that
satisfies the "one of these" dependency, but to allow the user to
specify one with a USE flag. This new revision adds three USE flags:
icinga, icinga2, and nagios. The "nagios" flag is enabled by default,
and builds pnp4nagios against net-analyzer/nagios. The other flags
build against the associated package.
In the process, the dependency on nagios-3.x was loosened to accept
nagios-4.x as well. The nagios-3.x series has been end-of-life'd, and
has multiple open security bugs.
Bug: https://bugs.gentoo.org/628086
Bug: https://bugs.gentoo.org/629380
Bug: https://bugs.gentoo.org/636234
Closes: https://bugs.gentoo.org/600424
Package-Manager: Portage-2.3.8, Repoman-2.3.3
Hans de Graaff
NP-Hardass
Matthew Thode
Andrey Utkin
Jonas Stein
Jonathan Vasquez
Andreas K. Hüttel
Marty E. Plummer
Michael Orlitzky
Justin Bronder
Patrice Clement
Mike Gilbert
Sergei Trofimovich