bacula7-sd

Build times (auto-updated)

x86_64: 4m14s (2026-10-13 19:12 UTC, MAKEFLAGS=-j6)

2026-10-14: superseded by private/bacula7, now removed from git entirely (user’s commit 311f134). This directory no longer exists – private/bacula7 (same pkgbase=bacula7, now at 7.4.7) is its sole replacement. All build-bug/packaging history below is still accurate and still applies to that PKGBUILD’s content (an unmodified cp -a at the time of the rename); new work (the 7.4.5 -> 7.4.7 bump, version alignment with bacula7-client) is recorded in memory/bacula7.md instead. This file is kept only as the historical record of that build-bug investigation – do not expect private/bacula7-sd to exist on disk.
Path: private/bacula7-sd. Full Bacula 7.4.5 source bundle (split package: bacula7-common, bacula7-console, bacula7-fd, bacula7-sd, bacula7-dir, bacula7-dir-sqlite3, bacula7-dir-postgresql). Ported 2026-10-13 from an old local build found at /data/INSTALL/from_eurobuild3/bacula-sd (same host’s pre-existing bacula-client sits alongside it at private/bacula7-client). pkgbase/ pkgname renamed bacula -> bacula7 to match the project’s versioned-name convention for packages that would otherwise collide with a hypothetical newer bacula from the AUR (see private/README). Upstream project name/paths/binaries are kept as plain bacula throughout (own _pkgbase var) – only the Arch package names are namespaced. No filesystem-level coexistence with another bacula build (/etc/bacula, /usr/bin/bacula-fd etc. are unchanged) – this is about the private-repo package name, not running two bacula installs on one host at once.
Dropped bacula7-bat (management GUI, qt4-based): the inherited build() already passed --disable-bat, so usr/bin/bat was never actually produced and package_bacula7-bat() would fail at packaging time. Removed the subpackage and qt4 from makedepends to match; --disable-bat itself was left alone rather than re-enabling the GUI (out of scope for a straight port).
Real build bug #1: --with-openssl=/usr/openssl-1.0 silently failed. That path doesn’t exist on this host – openssl-1.0 here is laid out as /usr/include/openssl-1.0 + /usr/lib/openssl-1.0 (confirmed via pacman -Ql openssl-1.0), not as a single DIR with DIR/include + DIR/lib subdirs the way bacula’s configure expects for --with-openssl=DIR (checked the actual configure script: when that structure isn’t found it just drops back to OPENSSL_INC=""/default -lssl -lcrypto, no error). That silently compiled crypto.c against the system OpenSSL (modern, opaque structs) instead, failing with M_ASN1_*/SKM_sk_*/X509_KEYPAIR errors and leaving libbac-7.4.5.so never built – which only surfaced later, at packaging time, as cp: cannot stat 'usr/lib/libbac-7.4.5.so' in package_bacula7-common(). Fix: set CPPFLAGS=-I/usr/include/openssl-1.0 / LDFLAGS=-L/usr/lib/openssl-1.0 before ./configure and pass bare --with-openssl (no =DIR) – same paths bacula7-client’s PKGBUILD already used correctly. If this package is ever rebuilt on a different host, re-check pacman -Ql openssl-1.0 first rather than assuming this path.
Real build bug #2: src/console/conio.c never includes <termios.h>. Fails with “aggregate ‘termios …’ has incomplete type”/tcgetattr,VMIN, ECHO etc. “not declared”, even though configure correctly detects termios.h as present – the include just isn’t there in the file itself (relies on something upstream <curses.h>/<term.h> no longer pull in transitively on this ncurses/glibc). Non-fatal to make overall (tolerated), but fatal to usr/bin/bconsole actually linking, so package_bacula7-console() fails. Fix: 02-conio-termios.patch adds #include <termios.h> right after #include <term.h> in the HAVE_CONIO block. Same patch (same line numbers) applies cleanly to bacula 7.4.3 too – reused verbatim in private/bacula7-client.
Missing runtime depends (namcap E: findings, pkgrel 1 -> 2 -> 3): bacula7-common needs libcap + openssl-1.0 (the latter only showed up after fixing build bug #1 above, since libbac.so wasn’t even being built before then – caught in a pkgrel 3 follow-up, don’t assume one namcap pass catches everything if an earlier bug was hiding a library from ever linking); bacula7-fd/bacula7-sd need libcap + openssl-1.0 (+acl for -fd); bacula7-console needs openssl-1.0; bacula7-dir needs openssl-1.0 + libcap + zlib + perl (for make_catalog_backup.pl). Deliberately did not add glibc/bash/gcc-libs (providing libgcc_s.so.1/ libstdc++.so.6) anywhere – namcap only flags those as hard E: on a subpackage with no depends array of its own at all; every sibling subpackage that already declares some depends gets the same libs correctly downgraded to W: implicitly satisfied, matching normal Arch convention of never listing base-group packages explicitly.
pkgver mismatch with bacula7-client (7.4.5 vs 7.4.3) is inherited as-is from the original two separately-maintained packages – not reconciled, since this was a straight port, not a version-alignment effort.
01-basename.patch partially fails every build (-Np2, tolerated via || true, confirmed on every one of the three rebuilds this session): “Hunk #4 FAILED at 87” against src/dird/bacula-dir.conf.in, rejects saved to src/dird/bacula-dir.conf.in.rej. Checked the actual content – it’s the commented-out #Job { ... #Client = @basename@2-fd ... } example block (a second/alternate client example), so the __BASENAME__ substitution never applies there and it stays as the unexpanded @basename@2-fd placeholder in the installed bacula-dir.conf – but since the whole block is #-commented out, bacula never parses it and this has zero functional effect. Leaving the patch as-is (pre-existing fragility ported as-is, not worth chasing for dead example text).
Built+published clean for x86_64 only (2026-10-13); i686 not attempted this session (see below) – REPO_BUILD_ONLY_ARCH=x86_64 was used throughout.
i686 chroot hang, unresolved: the very first build attempt (pre any of the fixes above) hung for 3+ hours with 0% CPU inside archlinuxaba-i686’s makechrootpkg, stuck deep in pacman -S --asdeps openssl-1.0’s post-transaction hook (innermost pacman child talking to its parent over a unix socket, sleeping, not looping). Killing the systemd-nspawn process (sudo kill -TERM <pid>) tore down the whole container tree cleanly with no leftover mounts/locks. The very next x86_64 chroot build in the same session installed the same openssl-1.0 dependency without any issue, so this looks i686-chroot-specific (a pacman-sandbox/hook deadlock particular to that nested container?) rather than a general pacman 7.1.0 problem – not investigated further since the user only needed x86_64 this round. Before ever attempting i686 again: expect a possible repeat hang around dependency installation and have a kill plan ready (kill -TERM the systemd-nspawn pid, found via pgrep -af nspawn) rather than waiting it out.