aurupdater

thruk

Build times (auto-updated)

2026-08-30: fully fixed – built and published (x86_64, any)

By this date, Arch’s own repos had absorbed perl-plack and perl-log-dispatch (both now official extra packages), so the 2026-08-02 vendored copies were no longer in the tree at all – of thruk’s 18 declared dependencies, only mod_fcgid and perl-crypt-rijndael still needed AUR vendoring this time (re-added via scripts/add_maintained.sh). mod_fcgid’s PGP-key blocker resolved on this attempt too – see memory/mod_fcgid.md for that investigation. perl-crypt-rijndael had no issues at all (plain CPAN-style module, no PGP source).

thruk itself (arch=('any')) then built and published cleanly on the first try – repo_release.sh, no PKGBUILD changes needed. namcap flagged (all pre-existing, not build failures): the usual GPL2 is not a valid SPDX license identifier nag, plus E: File (...) is owned by http:http for etc/thruk/panorama, var/lib/thruk, var/lib/thruk/reports, var/log/thruk – thruk’s own package() hardcodes ownership to the http user for these paths rather than leaving them root-owned for thruk.install/tmpfiles to fix up, a pre-existing upstream packaging choice, not something introduced here. Confirmed published via repo_arch_status.sh: any euronuc published (3.28-1).

2026-10-23: perl-plack dependency chain rebuild (runtime bug on a deployed armv7h host)

User reported a live runtime failure on a deployed armv7h thruk/mod_perl host, after a system Perl update there: Can't locate WWW/Form/UrlEncoded.pm in @INC, raised from HTTP::Entity::Parser::UrlEncoded – i.e. somewhere in thruk’s perl-plack dependency chain. Not this project’s own build machine or ARM boards – a separate deployed service host.

Traced the chain: thruk -> perl-plack -> perl-http-entity-parser -> perl-www-form-urlencoded. All four already existed at correct versions in the archlinuxaba repo db (pacman -Si confirmed each), so this wasn’t a “never built” gap – rebuilt+republished all four anyway, in dependency order, at the user’s explicit choice (clarified first: since every package in this chain is arch=(any), there’s no real per-arch build distinction to make – a single any build fans out to every arch’s repo via symlink automatically, including the deployed host’s armv7h repo).

None needed a PKGBUILD change or version bump – just a clean rebuild, confirmed building against the whole dependency chain correctly the second time around (see below for a recurring, unrelated pacman-cache quirk hit along the way). After this, the deployed armv7h host should pick up corrected files on its next pacman -Syu.

Recurring build hiccup, not a real bug: rebuilding each of the four packages at the SAME version (no bump) caused the VERY NEXT build in the chain that depended on it to fail once with a false “corrupted package (checksum)” pacman error, self-resolving on an immediate retry after clearing the stale /var/cache/pacman/pkg/<pkg> file. Hit this identically for all three inter-package handoffs (www-form-urlencoded->http-entity-parser, http-entity-parser->plack, plack->thruk) – see memory/TOOLING_NOTES.md’s 2026-10-23 entry for the full investigation (ruled out a CDN/proxy cache; root cause still unconfirmed, but the workaround is reliable).

2026-10-25: routine version bump 3.28 -> 3.30

Flagged UPD by check_for_updates_maintained.sh. Plain upstream pkgver/md5sum bump, no PKGBUILD logic changes – new tarball (http://download.thruk.org/pkg/v3.30/src/thruk-3.30.tar.gz, md5 443436725fc9ea4611cd60739c425ab9) downloaded and verified before editing. Built and published cleanly on the first try, pkgrel reset to

  1. AUR feedback checked: the two existing comments (inetutils dependency note, root-uid config note) are both old (2019/2021) and already ANSWERED – nothing new to fold in this pass.