Files
unraid-podman/packages
maggesandClaude Sonnet 5 e912180e8d
Build Packages / Build .txz packages (push) Failing after 5m5s
Lint / ShellCheck (push) Successful in 13s
Lint / Validate .plg XML (push) Successful in 9s
Lint / EditorConfig (push) Successful in 4s
Fix two real bugs in the package build scripts, found via a live CI run
The toolchain bootstrap fixes finally got build-packages.sh far enough
to attempt actual package builds, surfacing two genuine bugs (not
environment/toolchain issues) in task 80's log:

1. sb_fetch_and_verify() echoed its "Fetching..."/"SHA256 verified..."
   progress messages to stdout, same stream its return value (the
   tarball path) is returned on. Every caller captures that return value
   via `tarball=$(sb_fetch_and_verify ...)`, so command substitution
   swallowed the progress lines into $tarball too, and the resulting
   multi-line garbage got handed to `tar -xf` as a single bogus
   filename. Fixed by sending the progress echoes to stderr.

2. unraid-podman.SlackBuild read plugin/podman.plg's version via
   `grep -oP` with a variable-length lookbehind ({1,10} to match
   flexible whitespace). PCRE requires fixed-length lookbehind; this
   works on a PCRE2 grep (e.g. most dev machines) but fails outright
   ("lookbehind assertion is not fixed length") on Slackware's PCRE1
   grep. Replaced with a portable sed capture group.

Both verified directly against vbatts/slackware:15.0 on the runner host
before this commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-11 15:14:45 +00:00
..

packages/

One subdirectory per Slackware .txz package required by the plugin, built against Unraid's Slackware base. See docs/ARCHITECTURE.md, section 5 for the full rationale (why these components, static linking preference, version pinning, build strategy).

Packages

Directory Upstream project Purpose
podman/ containers/podman Core container engine binary
conmon/ containers/conmon Container monitor process
crun/ containers/crun OCI runtime (preferred over runc)
netavark/ containers/netavark Network backend
aardvark-dns/ containers/aardvark-dns DNS for container-to-container name resolution
containers-common/ containers/common Default config/seccomp/registries templates
fuse-overlayfs/ containers/fuse-overlayfs Fallback storage driver (rootless, Phase 2)
passt/ passt.top (no GitHub mirror) Rootless networking (Phase 2), successor to slirp4netns
unraid-podman/ this repository (not an upstream project) Plugin's own scaffolding — rc.podman, sbin/ scripts, event/ hooks, config templates (see its README)

podman, conmon, crun, netavark, aardvark-dns, passt, fuse-overlayfs, and unraid-podman are built and released automatically by .github/workflows/build-packages.yml. containers-common currently only supplies reference config (see config/) and is not yet wired into the automated build.

Standard layout per package

Each package directory follows the same skeleton:

packages/<name>/
├── <name>.SlackBuild   # Slackware build script (source download, build, packaging)
├── slack-desc            # Slackware package description (max 70 cols / 11 lines)
├── patches/               # Optional patches applied during the build
└── README.md              # Upstream version pinned, build notes, patch rationale

Build pipeline

Packages are built via scripts/build-packages.sh, which runs each package's <name>.SlackBuild in turn (see scripts/lib/slackbuild-common.sh for the shared fetch/verify/package helpers they all use). This must run inside a Slackware-compatible build environment — never on an arbitrary host distro, to avoid glibc/ABI drift against Unraid's base. .github/workflows/build-packages.yml is the CI entry point: it runs the same script inside a pinned Slackware container (scripts/ci/setup-slackware-buildenv.sh bootstraps any build-time dependency the base image doesn't already ship) and uploads the results as a workflow artifact — nothing built is ever committed to this repository.

Exact upstream versions and source checksums are pinned centrally in versions.env (update via scripts/update-versions.sh, never by hand) and, at release time, mirrored into the top-level plugin/podman.plg manifest together with MD5 checksums by scripts/release.sh, so installs are reproducible and rollback-able — see docs/ARCHITECTURE.md, section 14 (Rollback).