Same pattern already used for container update checking (P.openLogModal)
— these can take a while (storage checks, container stop grace periods,
...) and are exactly the actions someone reaches for when something's
actually wrong, so a button that just sits there disabled with no
feedback until it's done isn't good enough. "Refresh Status" stays inline
(quick, read-only, no modal needed).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rounds out the Podman Service card to the full start/stop/restart trio.
Stop and Restart both get a confirm() first — both actually stop every
running container (with its own configured grace period) before touching
the API service itself, not just the service process; worth surfacing
that explicitly rather than letting it be a surprise.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
softprops/action-gh-release talks to GitHub's REST API — it cannot
publish anywhere else, so this workflow could never have actually
published a release on this Gitea-hosted repo, reproducibility bug aside.
Replaced the publish step with plain curl against Gitea's own
/api/v1/repos/.../releases endpoints, using the repo-scoped token Gitea
Actions already injects as secrets.GITHUB_TOKEN (same env var name as
GitHub Actions, for exactly this kind of drop-in compatibility).
Idempotent: deletes and recreates the release if one already exists for
the tag, so a re-run after a transient failure doesn't just error on a
duplicate tag.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause of a fresh-install "cannot reach the Podman API socket" report
(a friend's Unraid box, cache pool present and mounted): unlike
Docker-for-Unraid's docker.img path, this plugin never auto-created
STORAGE_PATH itself — only podman.img inside it. A perfectly normal,
already-mounted cache pool still failed preflight/storage-create with
"does not exist", just because its own .../system/podman subdirectory
had never been created. Fixed by walking up to the nearest existing
ancestor and checking whether it's on a different device than / (real
mount vs. nothing mounted at all) — see podman-common.sh's new
podman_path_has_real_mount_ancestor(), used by both podman-preflight.sh
and podman-storage.sh.
Settings gets a "Podman Service" card (status chip + Start/Restart,
backed by new ajax/settings.php service_status/start/restart actions
that just shell out to rc.podman) so a fresh install that failed to start
can be diagnosed and retried without SSH/terminal access at all — exactly
what was missing when this was first needed live.
Also adds "Format a Disk for Podman Storage" (new ajax/disks.php) for a
single-disk system with no cache pool at all. Only ever lists disks with
literally no existing partition/filesystem/RAID-or-ZFS-membership
signature and that aren't Unraid's boot flash — found live, twice, during
development: the boot USB (FAT, labeled "UNRAID") passed the initial
mounted-only check because this host's /boot is backed by a ZFS dataset
rather than a direct partition mount, and active RAID-member cache disks
passed a data-vs-blank *warning* rather than a hard exclusion. Both are
now excluded outright, not just flagged — see disks.php's
device_or_children_labeled_unraid() and the hasData exclusion in
list_candidate_disks(). A disk formatted this way is remounted by UUID on
every boot via a new plugin/sbin/podman-mount-managed-disk.sh, called
from plugin/event/disks_mounted before rc.podman start.
Unrelated fix bundled in: scripts/lib/slackbuild-common.sh now sets
SOURCE_DATE_EPOCH (derived from the repo's last commit) before calling
makepkg, so two separate builds of the same commit produce byte-identical
.txz files — makepkg already supports this (`--clamp-mtime` when
$SOURCE_DATE_EPOCH is set, confirmed by reading a real host's
/sbin/makepkg) but nothing was setting the variable, so release.yml's
"rebuild in CI and verify it matches the committed checksums" step was
guaranteed to fail on the first package it checked alphabetically
(observed live: aardvark-dns).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
v0.1.0's <URL>/<MD5> entity values were split across their own lines
inside the tags. Unraid's plugin manager (scripts/plugin, see download())
passes that raw text straight into a `wget ... -O $name $url` shell
command without trimming whitespace, so the leading newline split the
command in two: wget got no URL argument ("wget: missing URL") and the
URL text itself ran as a separate, failing shell command
("sh: line 2: https://...: No such file or directory") — which the
installer then reported as "download failure: zero-length file",
looking like a network problem when it was a formatting bug.
Confirmed live: v0.1.0 fails to install on a real Unraid host (reproduced
via the plugin manager's own CLI, scripts/plugin install, not just the
webGUI). Every real Unraid plugin keeps <URL>...</URL> on one line
(verified against unassigned.devices.plg on the same host) — this fix
matches that convention. Package contents are unchanged from v0.1.0; only
podman.plg's XML formatting and the version/baseURL entities are bumped.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First cut release, built and verified via Gitea Actions (build-packages.yml
run against commit 18b414d, all 11 packages succeeded). Repo lives on
Gitea (git.mp-mueller.de), not GitHub — scripts/release.sh and
plugin/podman.plg's github/gitURL/supportURL/baseURL entities are updated
to point there instead of the GitHub placeholders they had before (this
project has never actually had a GitHub remote).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
editorconfig-checker correctly flagged this in CI (Lint workflow, run
107) — every other tracked file already ends with one per .editorconfig.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every other packages/*/*.SlackBuild is 755 — this one was created at 644
(likely from how it was originally written to disk), so
scripts/build-packages.sh's own executability check correctly refused to
run it ("No SlackBuild found/executable for 'podman-compose'"), failing
the whole build — confirmed from a real Gitea Actions run's log
(build-packages.yml run 110).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Terminal panel now opens a genuinely interactive shell (ttyd bound to a
unix socket, proxied through Unraid's own /logterminal/ nginx location —
the same mechanism Unraid's own Docker "Console" button uses) instead of
one-shot exec calls, shown inline with a Disconnect action; bash is the
default shell. Container/shell selectors and action buttons are now
correctly bottom-aligned (root cause: Unraid's theme puts a 10px margin
on every <button>, never reset before).
Destructive actions (Disconnect, Compose/Template Delete, Volumes/Images/
Networks Remove) get a consistent, solid red treatment at rest instead of
only tinting on hover, via new --bad-strong/--bad-contrast tokens.
Settings panel restructured: a real save toolbar instead of a button
buried in an empty-label row, card subtitles, a toggle switch instead of
a bare checkbox, and installed-package versions shown as chips.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The YAML view was read-only with no way to create a new project at
all. Add save/remove AJAX actions (validated via a real `podman
compose ... config` dry-run, written to a .new sibling and only
renamed into place on success) and a New Project/Save/Delete UI
backed by an editable textarea instead of a <pre>. Also strip ANSI
escape codes from compose command output so podman's own provider
banner doesn't show as literal garbage in error alerts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
podman-compose and docker-compose aren't discovered the same way by
`podman compose` - verified live (a fake-binary test reading podman's own
provider-search error output) that docker-compose is searched for by
exact path across a fixed list of CLI-plugin directories, while
podman-compose is instead looked up as a plain command on $PATH. This
package installs to /usr/local/bin/podman-compose accordingly, not under
any cli-plugins/ directory.
Unlike docker-compose (a single static Go binary), podman-compose is a
Python script with two runtime dependencies neither of which ship with
Unraid's own Python3 - PyYAML and python-dotenv, vendored here as plain
pure-Python source (no C extension build; PyYAML's own fallback handles
its optional C accelerator being absent).
Verified end-to-end on a real host: with the previous docker-compose
binary temporarily moved aside to confirm podman-compose was actually the
one invoked, `podman compose up/ps/down` ran a real compose project
correctly, including a live HTTP check against the started service.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Create Container form:
- GPU passthrough dropdown (AMD/Intel via /dev/dri detection, NVIDIA
excluded since it needs a different runtime) - device paths strictly
validated server-side against the host's own detected list.
- Macvlan network support: selecting a macvlan network reveals a static
IP field and hides port mappings (meaningless once the container has
its own LAN address), matching Unraid Docker Manager's "Custom: br0"
behavior. Networks panel gained a matching macvlan network-creation
flow, with the parent-interface dropdown read from Unraid's own
network.cfg so it lists exactly what Docker Manager itself offers.
Containers panel:
- Edit: reopens the create form pre-filled from the container's current
config (image/ports/volumes/env/network/restart policy/GPU/static IP);
saving stops+removes the old container and recreates it under the same
settings, since podman/Docker have no in-place "modify" API for most of
this.
- Update: same stop/remove/recreate flow, but pulls the current image
first. "Check for Updates" compares each in-use image's local digest
against its origin registry (Docker Hub/GHCR/self-hosted registries all
verified live) with no podman-side feature backing it - implemented via
the registry's own HTTP API. A small log-modal shows progress for both
actions instead of a silent wait.
- Fixed a real bug hit live: PodmanClient's flat 15s HTTP timeout aborted
real image pulls/container creates mid-request; bumped to 600s (nginx
already allows up to 640s for this plugin's requests).
Images panel:
- "Prune unused" (removes every image with zero containers referencing
it, not just dangling ones - confirmation copy says so explicitly since
this is more aggressive than it sounds) and per-image "Tag".
Also several real UI bugs found via live screenshots: unused-image prune
having no visible effect until reloaded, table action-button columns
drifting row to row (a bare "display:flex" on a <td> was fighting the
table layout algorithm), Templates category badges dumping raw multi-tag
strings from real Unraid templates, and low-contrast search/filter
controls that were nearly invisible against the card background.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pods panel could previously only list pods - there was no way to create
one, start/stop/restart it, or attach a container to it from the UI.
Adds a "New Pod" modal (name + port mappings), a per-pod lifecycle menu
(start/stop/restart/remove), and an optional "Pod" field on the Create
Container modal to join an existing pod's network namespace. Backend
verified live against the real podman socket (/pods/create, /pods/{name}/
restart, container "pod" field).
Also fixes three real bugs found via live testing:
- Podman.page used Menu="Podman" instead of Menu="Tasks:<rank>", so the
plugin never actually appeared in Unraid's top navigation (traced through
PageBuilder.php/DefaultPageLayout.php/Navigation/Main.php - only pages
registered under "Tasks" become top-level tabs).
- app.js's shared context-menu component mis-mapped every item positioned
after a 'separator' entry to the wrong DOM element (an off-by-one against
menu.children, which includes the separator <div>s) - so "Remove", which
always sits after a separator, silently did nothing when clicked. Fixed
by indexing into querySelectorAll('button') instead.
- That same menu was positioned via "position: absolute" math that assumed
a viewport-relative containing block, but Unraid's own page wrapper
(webGui/styles/default-base.css's ".content") sets position:relative,
so the menu rendered far from its anchor button. Switched to
"position: fixed" with viewport-relative coordinates.
Incidentally, pods add a hidden "infra" container that was leaking into
the plain Containers list with no working lifecycle of its own (always
"running", so its own Remove was permanently disabled) - now filtered out
via libpod's IsInfra flag. And every action-buttons table cell used
"display: flex" directly on the <td>, which browsers can size
inconsistently row to row - moved onto an inner wrapper div instead, and
bumped .podman-btn-icon's touch target size.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Lets users create containers from the WebUI (image/name/ports/volumes/
env/network mode/restart policy/privileged) instead of only managing
existing ones, and adds a Templates panel to save/reuse those configs
as Unraid-Docker-compatible template XML, including browsing and
importing the host's own existing Docker Manager templates directly.
Also fixes bugs found via live testing along the way: container names
with spaces/invalid characters now get a clear client- and server-side
error with a suggested fix instead of podman's raw API error, the New
Container modal's backdrop no longer renders transparent (was being
appended outside the .podman-plugin CSS scope), and modal buttons now
have real visual hierarchy (ghost/primary/danger) after Unraid's own
site-wide button theme was found to override plain single-class rules.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Clicking a container's name now opens a tabbed detail modal, fed entirely
by the existing inspect action's raw libpod data — no new backend needed.
Field names (Config.Env, Config.Labels, Mounts[].Source/Destination/RW,
NetworkSettings.Networks{}.IPAddress/Gateway/MacAddress, HostConfig.
RestartPolicy) verified against a real inspect response before building
the tabs around them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First increment of the big WebUI feature-parity spec (see task list) —
row-level actions were about to run out of icon-button space, so this adds
a small anchored dropdown menu (app.js openContextMenu) for secondary
per-container actions instead of cramming more buttons into every row.
All four new actions verified live against the real podman API before
wiring up the UI (same discipline as the CSRF/pull/compose bugs found
earlier — field names and response shapes checked against the running
socket, not assumed from docs).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Package #9-11: catatonit (pod infra init), nftables (netavark firewall
backend), docker-compose (external compose provider for `podman compose`)
— all vendored prebuilt binaries, versions.env pinned, propagated through
build-packages.sh/release.sh/podman.plg/verify+update-packages.sh.
- Fix WebUI: every POST action was silently failing (empty response body)
because Unraid's own CSRF protection was never satisfied — app.js now
sends the page's csrf_token as X-CSRF-Token.
- Fix WebUI: PodmanClient::pullImage() assumed a single JSON response, but
/images/pull actually streams newline-delimited JSON — every successful
pull was throwing "Expected a JSON object/array response".
- Fix WebUI: compose.php's up/down status detection had the same
single-JSON-vs-NDJSON bug for `podman compose ps`, plus stderr was
corrupting the parse.
- Add cache-busting (?v=<mtime>) to Podman.page's script/style tags so a
redeployed JS/CSS fix isn't served stale from browser cache.
- Add a reusable modal dialog (app.js openFormModal) replacing
prompt()/alert() for New Volume/Network/Pull Image.
- Add host-path (bind-mount) support when creating a named volume.
- Add Create Container (image, name, network mode incl. custom networks,
ports, volumes, env, restart policy, privileged, start-after-create),
auto-pulling the image on first use since /containers/create doesn't.
All fixes verified live against a real podman system service and, where
reachable, via the actual WebUI over the real socket — not just unit-level.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found by exercising the AJAX endpoints directly against a real running
podman service (php -d display_errors=1 -r '...containers.php...') —
containers.php's list action crashed with an uncaught TypeError the
moment a real container existed. podman's libpod API is inconsistent
about container/volume timestamp encoding: inspect-style endpoints
return RFC3339 strings, but list-style endpoints (containers/json,
volumes/json) return raw Unix-epoch integers for the same logical
field. podman_parse_time() only accepted ?string, so any list call
with a real container blew up outright rather than merely
mis-rendering. Widened it to string|int|null and handle both.
Verified: containers.php's list action now returns correct JSON for
real running/exited containers, including their createdAt timestamps.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First live end-to-end install on real Unraid hardware (all 8 built
packages installed via upgradepkg, rc.podman started, containers
pulled/run/networked/port-mapped) — surfaced five genuine bugs no
amount of container-based CI testing could have caught, since none of
them exist inside the vbatts/slackware:15.0 build container:
1. rc.podman never created $PODMAN_LOG_DIR before redirecting the
podman system service's output into it, so the service failed to
even start ("No such file or directory"). Added it alongside the
existing PODMAN_RUN_DIR mkdir.
2. config/storage.conf hardcoded a [storage] table, and
podman-config.sh's `sync` step appended a second one at boot with
the real graphroot/runroot — TOML forbids defining the same table
twice. Removed the template's [storage] entirely; sync already
generates the whole thing.
3. config/policy.json had a "_comment" pseudo-field for
documentation, but containers/image's policy parser rejects any
unknown top-level key outright. JSON has no comment syntax; moved
the rationale into docs/ARCHITECTURE.md instead.
4. netavark >= 2.0 dropped its iptables firewall driver entirely
(verified: passing "iptables" is flatly rejected) — nftables or
firewalld are the only remaining options, and firewalld needs
systemd/dbus, which Unraid has neither of. Set firewall_driver =
"nftables" explicitly and documented that Unraid OS doesn't ship
the `nft` binary this needs (a slackware64 nftables package works;
not yet wired into the build/install pipeline — see follow-up).
5. Every container failed with "crun: pivot_root: Invalid argument".
Root cause: Unraid's / is permanently the kernel's initial "rootfs"
pseudo-filesystem (Unraid never pivots to a real one at boot — the
whole OS runs from RAM), and pivot_root(2) unconditionally rejects
that as the old root. This is not new: Docker/runc hits the exact
same kernel restriction on this exact host and silently falls back
to an MS_MOVE-based chroot; crun has no such fallback, only a
--no-pivot flag with no config-file equivalent. Added
plugin/sbin/crun-no-pivot.sh, a thin wrapper that scans crun's full
argument list (podman puts global flags before the subcommand, so
the subcommand isn't reliably $1) and injects --no-pivot right
after create/run, and pointed containers.conf's crun runtime at it.
Also fixed the podman.plg postinstall's chmod glob
(`podman-*.sh` -> `*.sh`), which would have skipped this new
non-podman-prefixed sbin script.
Verified end-to-end on the real host: pull, run, real network
connectivity (wget through the container's bridge), and a published
port actually serving HTTP (curl through -p 8099:80 to nginx) all
work. --no-pivot's security tradeoff (disabling one particular
container-escape mitigation) was explicitly discussed with and
approved by the user before committing, given it must be the default
for any container to start at all on this platform.
Follow-up not yet done: nftables (needed for #4) is not yet a
packages/ component in the reproducible build pipeline — it was only
installed manually on the test host for this verification run.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
All 8 packages built and verified successfully in task 96 — the only
remaining failure was the very last step: actions/upload-artifact@v4
errored with GHESNotSupportedError. Gitea Actions' built-in artifact
storage doesn't implement the newer v2 upload/download API that
upload-artifact@v4/download-artifact@v4 require. Downgraded both (they
must match — v3 and v4 artifacts aren't cross-compatible) to v3, which
uses the older protocol Gitea does support.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verified end-to-end with a full local build of all 8 packages on the
actual runner host (docker exec against vbatts/slackware:15.0, bind-
mounted repo on the cache pool) instead of round-tripping through
Gitea Actions for each fix — much faster for a chain of issues this
deep. All 8 packages now build successfully from a clean checkout.
Three fixes, all in crun (the last package still failing):
1. "Package requirements (json-c >= 0.14) were not met" — added
json-c to the toolchain bootstrap.
2. crun depends on the libocispec git submodule, which in turn depends
on the image-spec and runtime-spec git submodules. GitHub's source
archive tarball never includes submodule content (no .git directory
for `git submodule update` to work against — the existing `|| true`
masked this failing silently). Fetched all three as their own
pinned tarballs instead, at the exact commits crun 1.28 references
(cross-checked via the GitHub contents API), matching how every
other dependency in this project is already pinned.
3. crun.c unconditionally #includes git-version.h, which crun's own
Makefile only generates via `git describe` (again, no .git) or from
a pre-existing .tarball-git-version.h — the file crun's own `make
dist` would have written, which we never run. Write that file
ourselves in the exact format the Makefile already expects; this is
the documented fallback path bundled release tarballs rely on, not
a workaround around it.
Also includes the podman go-md2man pre-seed fix and setup-slackware-
buildenv.sh python3 addition from the previous commit's follow-up
testing (both already verified working in this same local build run).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GO_SRC_SHA256 was wrong since it was first pinned in Task 1 — this
path had never actually been exercised in any prior CI run or local
test because every earlier failure happened before reaching the Go
install step, or (once it did run) nothing had checked the pinned
value against go.dev's own published checksum yet. Task 88's log
caught it: the real go1.26.5 linux-amd64 tarball hashes to
5c2c3b16caefa1d968a94c1daca04a7ca301a496d9b086e17ad77bb81393f053
(cross-checked against https://go.dev/dl/?mode=json directly), not
the previously pinned value. Also independently re-verified
LIBSECCOMP_SRC_SHA256 against the real v2.6.1 tarball while looking at
this — that one was already correct.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task 84's log got further than any run so far — 4 of 8 packages
(aardvark-dns, passt, fuse-overlayfs, unraid-podman) built successfully
— and surfaced four distinct, genuine build-time issues for the rest:
1. podman: go.mod parsing failed with "invalid go version '1.25.6':
must match format 1.23". Root cause: slackpkg's batch-mode
`install gcc` (verified directly) pulls in every gcc-<lang> sibling
package Slackware's gcc SlackBuild produces — including gcc-go, an
ancient bundled go1.16.5. Our Go bootstrap only installed the pinned
$GO_VERSION when `command -v go` found nothing, so gcc-go's go1.16.5
silently won. Fixed by always installing/overwriting the pinned Go
and prepending it to PATH, regardless of what else provides `go`.
2. crun: "no suitable Python interpreter found" — added python3.
3. netavark: build.rs (via prost-build) needs a `protoc` binary;
Slackware packages no protobuf/protoc at all. Added the official
prebuilt release binary, pinned + checksummed (no `unzip` on this
image either, so extracted with `python3 -m zipfile` instead of
adding yet another package).
4. conmon: `make install`'s docs target needs go-md2man, not packaged
by Slackware and no prebuilt release exists upstream. `go install`
it, pinned to a tagged release, now that our own Go is reliably on
PATH.
All four verified directly against vbatts/slackware:15.0 on the actual
runner host before this commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
yajl (needed by conmon, bootstrapped from source since Slackware ships
no package for it) builds via CMake, not the cmake-free autoconf script
its ./configure wrapper name suggests. Tracing the failure through the
actual vbatts/slackware:15.0 image on the runner host surfaced a chain
of packages slackpkg does not auto-resolve (Slackware packages carry no
dependency metadata at all): cmake needs libarchive, which needs lz4 and
libxml2; the patched make/gmake this mirror serves needs guile, which
needs gc; compiling anything needs kernel-headers for <linux/errno.h>;
and this build's binutils (ar/ranlib) needs flex, while objdump needs
elfutils. All added to the same slackpkg install list as the rest of
the toolchain, keeping everything on one mutually consistent version
set. Verified end-to-end against vbatts/slackware:15.0 on the actual
runner host at each step of this dependency chain.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The git fix alone got further, but actions/checkout@v4 (and later,
actions/upload-artifact@v4) are Node-based actions — Gitea Actions
execs their JS bundle with the "node" binary from inside the job's
own container rather than injecting a runtime of its own, and
vbatts/slackware:15.0 has no nodejs package anywhere on the official
Slackware mirror. Install a pinned, checksum-verified Node.js release
straight from nodejs.org in the same "Install git" step, matching the
existing Go/Rust bootstrap style in setup-slackware-buildenv.sh.
Verified end-to-end (node --version succeeds after a fresh install) in
vbatts/slackware:15.0 on the actual runner host.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The build-packages.yml run was failing for two compounding reasons,
found by testing directly against vbatts/slackware:15.0 on the actual
runner host:
1. The image ships neither git nor its HTTPS runtime libs, so
actions/checkout failed immediately.
2. It's a minimal rootfs with none of the 'D' (development) series —
no gcc, make, autoconf, pkg-config, curl, glib2, libcap, or fuse3 —
contrary to setup-slackware-buildenv.sh's assumption that a "full"
Slackware install already provides these.
An earlier fix attempt hand-pinned git + its deps (nghttp2, brotli,
cyrus-sasl) by exact file + SHA256 from the base 15.0 release
directory. That drifted out of sync with the newer, patched curl
slackpkg installs later in the same container — same shared library,
two different builds, causing a runtime symbol lookup error. Both
steps now resolve every package through slackpkg's own prioritized
mirror instead, keeping the whole toolchain on one mutually consistent
version set. Verified end-to-end (git ls-remote and curl both succeed
over HTTPS against the real Gitea instance, full toolchain present)
in a fresh vbatts/slackware:15.0 container.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vbatts/slackware:15.0 ships neither git nor its runtime shared libs
(nghttp2, brotli, cyrus-sasl) or ca-certificates, so actions/checkout
was failing immediately with "base image is missing git/tar". Install
git and its dependencies from Slackware's own official mirror, pinned
by exact filename and verified SHA256, and build the CA bundle so git
can trust HTTPS remotes. Verified end-to-end against the real Gitea
instance (git ls-remote succeeds) in a fresh vbatts/slackware:15.0
container.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- podman-common.sh: file-wide shellcheck disable=SC2034 for its
constants, which are intentionally defined for other scripts to
source, not used within the file itself (ShellCheck can't see
cross-file usage in that direction). Confirmed as the actual cause
of the failing ShellCheck job via the real Gitea Actions log.
- podman-storage.sh: use the retry counter in cmd_unmount's log
message instead of leaving it genuinely unused (real SC2034 hit,
not a false positive).
- lint.yml: replace the editorconfig-checker/action-* marketplace
action with a pinned, checksum-verified direct binary download —
more robust than relying on third-party action resolution on
self-hosted Gitea Actions runners — and disable its IndentSize
check, which false-positives on Markdown's nested-list indentation
and shell heredoc bodies. scripts/dev/lint.sh mirrors the same check
for local use. All three lint.yml jobs verified passing locally.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- versions.env pins podman, conmon, crun, netavark, aardvark-dns, passt,
and fuse-overlayfs to verified upstream source checksums; SlackBuild
recipes, scripts/build-packages.sh, checksums.sh, release.sh, and
update-versions.sh implement the reproducible pipeline; GitHub Actions
workflows build in a Slackware container and publish releases without
committing any binaries.
- plugin/podman.plg installs/updates/removes all eight packages (the
seven components plus the plugin's own unraid-podman scaffolding
package) via upgradepkg, using the official Unraid array-event hook
mechanism (event/disks_mounted, event/stopping) instead of editing
/boot/config/go. rc.podman and the sbin/ helper scripts implement
storage creation, config seeding/sync, preflight checks, autostart
with per-container Safe-Mode, and package verify/update/rollback.
- webui/plugins/podman implements the Dashboard, Containers, Pods,
Images, Volumes, Networks, Logs, Terminal, Compose, and Settings
panels against the approved mockup (webui/mockups/prototype.html),
talking to podman system service exclusively via PodmanClient.php
(libpod REST API over the Unix socket), with two documented
exceptions: Terminal's one-shot exec model and Compose's use of the
podman compose CLI, since libpod has no REST equivalent for either.
- docs/ARCHITECTURE.md and docs/ROADMAP.md record the design decisions
and honest current status (syntax-checked, unit- and
integration-tested against fake sockets/servers; not yet run against
a real Unraid/Podman/Slackware system).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
maggesandClaude Sonnet 5