nrpe

Build times (auto-updated)

• x86_64: 59s (2026-10-26 18:57 UTC, MAKEFLAGS=-j6)

---

• Category: adapted/ (plain local-tracked directory, not a submodule). Forked from the official Arch packaging repo (gitlab.archlinux.org/archlinux/packaging/packages/nrpe, maintainer Jonathan Steel) – not currently synced to the live [extra] mirror this host uses (pacman -Si nrpe finds nothing), fetched via pkgctl/its raw GitLab URLs directly. There’s also an unrelated AUR nrpe (maintainer gijsdebeer, not us) – deliberately NOT used as the base, since the user specifically wanted the official packaging repo’s version.
• Deviation from upstream, explicitly requested: --enable-command-args added to build()’s ./configure call, plus a sed in package() flipping the shipped /etc/nrpe/nrpe.cfg’s dont_blame_nrpe=0 -> dont_blame_nrpe=1. Per NRPE’s own SECURITY.md, BOTH are required together for clients to be able to supply command arguments to checks – the compile-time flag alone does nothing without the runtime directive, and vice versa. NRPE’s own docs call this a real security risk (clients can execute arbitrary command arguments on this host) – enabled anyway because it was asked for explicitly by name (dont_blame_nrpe), not discovered or defaulted to.
• Verified end-to-end after publish by downloading the actual built package from the repo and checking the real binary/config, not just trusting the build log: nrpe --help prints NRPE’s own “POSSIBLE SECURITY RISK - COMMAND ARGUMENTS ARE SUPPORTED!” banner (gated behind #ifdef ENABLE_COMMAND_ARGUMENTS in src/nrpe.c, so this is a reliable compile-time signal), and the packaged nrpe.cfg has dont_blame_nrpe=1.
• Bash command substitution (--enable-bash-command-substitution, an even higher-risk option per the same SECURITY.md) was NOT enabled – only asked for dont_blame_nrpe/command-args specifically.
• 2026-10-12: first build+publish, clean, x86_64 only (matches upstream’s own arch=(x86_64)). pkgrel 1 (fresh local fork, not a resign of an existing build – plain integer, not the local-install/-style X.Y scheme, since this is a real PKGBUILD fork we maintain, not someone else’s exact binary).
• 2026-10-26: upstream GitHub release 4.2.0 built, published, then REVERTED back to 4.1.2 same day. User asked to check for an upstream update; confirmed 4.2.0 exists on GitHub (--enable-command-args and the dont_blame_nrpe config directive both unchanged there, so the existing deviation ported cleanly with no PKGBUILD logic change, just the version bump). Build+sign+publish ran to completion before the user’s follow-up – “is this the version upstream Arch has adopted?” – landed (a genuine race: the question was meant to gate the build, not review it after the fact). GitLab’s archlinux/packaging/packages/nrpe PKGBUILD (the actual base this fork tracks, per the top note on this page) could NOT be checked programmatically – it’s behind Anubis bot-protection, even a browser-UA curl gets refused. archlinux.org’s package-search JSON API confirms nrpe isn’t in any live official binary repo at all right now (zero results), consistent with this page’s existing note that it’s not synced to the live mirror. Given no way to confirm what version the actual upstream-tracked PKGBUILD carries, user chose to revert: restored the archived 4.1.2 package files to the repo host’s live os/x86_64/ dir (copied from archive/x86_64/, archive itself untouched/append-only), archived the built 4.2.0 files instead, and rebuilt the repo-add database entry against 4.1.2. Local arch/adapted/nrpe/PKGBUILD/.SRCINFO reverted to 4.1.2 to match. Before attempting this again: find a way to actually read the GitLab packaging PKGBUILD (a real browser, or ask the user) rather than assuming raw upstream’s latest tag is automatically the right version to ship for this fork. (Side effect of this session, unrelated to nrpe’s own version: the publish attempt surfaced that /data/tmp was missing on the repo host, breaking repo-add silently – see TOOLING_NOTES.md’s 2026-10-26 entry. Fixed on the host; not yet made self-healing in repo_lib.sh.)