bacula7

Build times (auto-updated)

• x86_64: 4m22s (2026-10-14 05:05 UTC, MAKEFLAGS=-j6)
• armv7h: 21m49s (2026-11-06 08:06 UTC, remote, MAKEFLAGS=-j4)

---

• 2026-11-06: armv7h fstype.c narrowing bug FIXED, armv7h now published. User asked to retry the armv6h/armv7h/aarch64 attempt below for real this time (wanted bacula-dir/bacula-sd/bacula-fd + postgresql on armv7h). Root cause confirmed: switch (st.f_type) in src/findlib/fstype.c switches on a 32-bit-wide type, and several filesystem magic-number case labels (0xFF534D42 cifs, 0xf995e849 hpfs, 0x958458f6/0x858458f6(x3) hugetlbfs/ramfs/rootfs/tmpfs, 0xa501FCF5 vxfs, 0x9123683e btrfs, 0xaee71ee7 gadgetfs, 0xb00000ee hppfs, 0xa0b4d889 pfmfs – 9 distinct literals, 11 case lines) exceed INT_MAX. On x86_64 this is silently fine because long/the promoted switch type is 64-bit there; on 32-bit ARM (armv6h/armv7h) it’s actually 32-bit, so C++11’s converted-constant-expression rule for case labels (narrowing conversions ill-formed) fires for real. Fix: 03-fstype-narrowing.patch – one-line, casts the switch controlling expression itself (switch ((unsigned int)st.f_type)) rather than touching each of the 9 literals individually; since all case values already sit in the unsigned int range, this makes every case conversion trivial (no narrowing). Applied in prepare() after 02-conio-termios.patch (-Np1, applies cleanly). pkgrel bumped 1 -> 2 (packaging-only fix, see [[feedback_pkgrel_vs_pkgver]]). Built+published REPO_BUILD_ONLY_ARCH=armv7h only (eurobuild5, -j4 per the standing REMOTE_BUILD_MAKEFLAGS_eurobuild5 config) – all 7 subpackages (-common, -console, -dir, -dir-postgresql, -dir-sqlite3, -fd, -sd) built and published cleanly for armv7h. Did NOT retry armv6h/aarch64 in this pass (user’s ask was specifically armv7h); the same fix should apply equally to armv6h (same 32-bit-int switch issue) if that’s ever revisited, but aarch64 still has its own separate, unrelated gap (openssl-1.0 dependency missing for aarch64, see below) that this patch does nothing for. bacula7-client was NOT touched/rebuilt this session – user’s request was scoped to private/bacula7 only. It shares the same fstype.c code path, so the identical patch would very likely fix its armv6h/armv7h build too if ever asked for.

• 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.