bacula7

Build times (auto-updated)

• x86_64: 4m22s (2026-10-14 05:05 UTC, MAKEFLAGS=-j6)

---

• 2026-10-14/15: ARM build attempt (armv6h/armv7h/aarch64) failed on all three archs, real bugs not hangs – abandoned per explicit user instruction, not pursued further.
  • armv6h + armv7h: identical real compile error in src/findlib/fstype.c – error: narrowing conversion of '4283649346' from 'unsigned int' to 'int' [-Wnarrowing] (and four more similar literals, all filesystem magic numbers that don’t fit in a signed 32-bit int) when fstype.c gets compiled by g++ (bacula’s Makefiles compile .c files with the C++ compiler throughout, so C++11’s stricter brace-init narrowing rules apply even though this is plain C code). This kills libbacfind.la (the .lo for fstype.c never builds), which then cascades into make[1]: *** No rule to make target '../findlib/libbacfind.la' for bacula-fd, bacula-dir, bls, bregex, and finally package_bacula7-common() fails outright (cp: cannot stat 'usr/lib/libbacfind-7.4.7.so') – same failure shape as bacula7-sd’s documented real build bug #1 (a silently-unbuilt core lib surfacing later as a packaging-time cp error), different root cause. Did NOT reproduce on x86_64 earlier this session – likely a GCC-version/strictness difference between euronuc’s local chroot and these boards’ GCC 10.2.0, not an endianness/word-size issue (armv6h/armv7h are 32-bit, same int size as x86_64). Not investigated further (no patch attempted) – see below.
  • aarch64: unrelated dependency-availability gap, not the same bug – error: target not found: openssl-1.0 during the chroot’s own dependency install step, before the real build even started. openssl-1.0 may simply never have been built/published for aarch64 in this private repo. Would need checking separately from the fstype.c issue above even if retried.
  • Decision: abandoned, not fixed. User’s explicit instruction when queuing this ARM attempt: “if the ARM builds for bacula7 and bacula7-client fail, never mind … just continue with the plan and ignore bacula7 and bacula7-client.” These are real, reproducible build bugs (not a hang – no process needed killing, both builds ran to a clean error and exited on their own), so no abort/recovery action was needed, just no fix attempted. bacula7-client’s ARM build was not even attempted afterward, since it shares the same findlib/fstype.c code path and would almost certainly hit the identical armv6h/armv7h compile error (see memory/bacula7-client.md). If this is picked up again: the fstype.c fix is likely a small patch (explicit (int)/unsigned int cast or widening the literal’s type at those 5 call sites, lines ~216-246); the aarch64 openssl-1.0 gap is a separate, unrelated question of whether that dependency package is built for aarch64 at all.
  • i686 was already excluded from this attempt (unrelated, pre-existing chroot-hang issue, see below) – so this package now has no ARM or i686 coverage at all, x86_64-only, same as before this session’s attempt.
• Path: private/bacula7. Successor to private/bacula7-sd – same pkgbase=bacula7 split-package PKGBUILD (unchanged content, cp -a’d 2026-10-14), just living in a directory named after its actual pkgbase instead of after the one subpackage (-sd) that happened to be the only one ever published. private/bacula7-sd was removed from git entirely by the user right after (commit 311f134) – it no longer exists on disk. All build-bug and packaging notes for this codebase predating 2026-10-14 are in memory/bacula7-sd.md (openssl-1.0 flag handling, conio.c missing <termios.h>, the 01-basename.patch hunk #4 dead-code failure, per-subpackage depends, the i686 chroot hang) – still fully applicable here, not re-copied into this file.
• 2026-10-14: bumped pkgver 7.4.5 -> 7.4.7, pkgrel reset to 1. 7.4.7 is the final release of the 7.4.x branch (Mar 2017) – there is no 7.6/7.8; upstream jumped straight from 7.4 to 9.0 in Jul 2017. Also bumped private/bacula7-client to the same 7.4.7 in the same session, so the two packages’ versions are now aligned (previously 7.4.5 vs 7.4.3, inherited from two separately-ported upstream packages – see memory/bacula7-sd.md). All three patches (00-qmake4.patch, 01-basename.patch, 02-conio-termios.patch) re-verified to apply the same way against the 7.4.7 tarball as they did against 7.4.5 (same single real hunk-4 failure in 01-basename.patch, harmless/dead-code as already documented). This PKGBUILD only ever used bare sha1sums (no validpgpkeys, unlike bacula7-client) – kept that way, just updated the sha1 for the 7.4.7 tarball rather than widening scope to add PGP verification here too. Built +published x86_64 only (REPO_BUILD_ONLY_ARCH=x86_64); all 8 outputs (bacula7-common, -console, -debug, -dir, -dir-postgresql, -dir-sqlite3, -fd, -sd) published cleanly, old 7.4.5-3 entries auto-archived by repo_publish.sh. i686/other archs not attempted (matches prior session’s scope).
• Deliberately did not chase upstream past the 7.4 branch (current upstream is 15.0.3 stable / 17.0.0 beta) – the whole point of the bacula7-* naming is a frozen old major version (protocol/catalog format compatibility with other 7.x Bacula installs elsewhere), so a major-version jump would defeat the purpose and is a different, much larger undertaking (protocol + catalog schema changes) than a point-release bump.

2026-10-14: added armv6h/armv7h/aarch64 to arch=()

User asked to add the three ARM archs (now that the ARM build cluster eurobuild4/5/14 is back up) to this PKGBUILD’s arch=() and build+publish. No arch-specific logic in build()/prepare() for this package (unlike libarchive-static/pacman-static, which bundle+build their own openssl from source with per-CARCH target flags) – openssl-1.0 is a plain depends here, so nothing else needed changing. Built via REPO_BUILD_ONLY_ARCH="armv6h armv7h aarch64", deliberately not rebuilding i686 in the same pass: this package has an unresolved i686 chroot hang (see the entry below), and the user’s request here was specifically about the newly-available ARM cluster, not a general “build everything”: i686 stays deferred pending that separate investigation.