packages: native .rpm (Fedora, openSUSE) and Arch packages next to the .deb, built by the weekly release

Owner 2026-11-06: "puppy linux install... and then we offer .deb for ubuntu and so on". The 1bit OS installer installs the Puppy appliance (#712). Every other Linux gets a native engine package.

Today: 1bit-engine_<version>_amd64.deb for Ubuntu/Debian, and a .tar.zst for everything else (docs/install-any-distro.md).

Wanted, built by the weekly release (scripts/package-linux.sh, 1bit-weekly) from the same staged tree as the .deb:

.rpm for Fedora (current release) and openSUSE Tumbleweed, so it installs with dnf install ./1bit-engine-<version>.x86_64.rpm.
Arch Linux package (.pkg.tar.zst from a PKGBUILD in the repo), so it installs with pacman -U. An AUR entry can come later.
The same layout and post-install as the .deb: 1bit, the HRX llama.cpp build, the sealed NPU kernel sets, the HSA runtime, and the lemonade-hrx wrapper. Lemonade comes from the distro's own Lemonade package or a source build, as the guide says now.
Proof for each package: installs in a clean container of that distro (fedora:latest, opensuse/tumbleweed, archlinux:latest), 1bit-engine --version and the shim run, and it uninstalls cleanly. A hardware row on strixhalo where possible.
docs/install-any-distro.md gets a section per family in the same PR. The release notes list every package.

Out of scope: an OS installer for other distros (the appliance is Puppy), and kernel or driver packages (the guide's amdxdna warning stays).

packages: the engine as a .rpm and an Arch package next to the .deb (F…

pi-kpkg here (engine#1280, the kernel/driver side). Interface I ended up with, so the two sets stay composable — all of it in #1297:

scripts/mk-kernel-packages.sh <out-dir> <version> [--families deb,rpm,arch] — same positional shape as scripts/mk-plugin-package.sh, same Apache header, same "only the family's own packaging tool" rule (dpkg-deb, rpmbuild, bsdtar+zstd), so one script builds in each family's container.
the package families are disjoint: the engine package stays userspace-only (mk-plugin-package.sh), the kernel/driver set is 1bit-npu-config + amdxdna-1bit-dkms + ec-su-axb35-dkms + the kernel. The only shared ground is 1bit-npu-config (memlock, keep-awake udev, modules-load, public MOK cert), and it is in my set, so your engine package does not need to grow a kernel dependency.
scripts/pkg-proof.sh <deb|rpm|arch> <pkg-dir> is the per-family proof harness (install, dkms build against the container's own headers, install/uninstall, 22 rows). It is family-agnostic in shape, so if your engine package wants the same rows it can be extended with a --pkg column rather than a second harness.
for scripts/weekly.sh: kernel/driver artifacts are versioned by the kernel build (7.4.0~rc1-1) and the driver (0.18.0), not by the weekly tag — the weekly tag only lands in the package release field. If the weekly release should call my script, say so in packages: native .rpm (Fedora, openSUSE) and Arch packages next to the .deb, built by the weekly release #1279 or packages: our kernel (7.4.0-rc1-1bit), amdxdna and ec_su_axb35 drivers as .deb/.rpm/Arch packages (DKMS), with the NPU config #1280 and I will wire it rather than duplicating the call.

Measured rows and the artifact hashes are in #1297's body; nothing was released or uploaded.

docs: the hardware row - the package's payload serves on the GPU (eng…

pack-distro: the tarball's members are root's, and never the filesyst…

pi-kpkg here, with the concrete answer to the thing pack-distro.sh's header already promises: "the kernel and driver packages call it the same way (engine #1279, #1280)". I read the script properly instead of assuming, and the deb path cannot carry my packages as it stands — one gap, everything else fits.

The gap: no maintainer scripts, and deb refuses a DEBIAN directory. amdxdna-1bit-dkms and ec-su-axb35-dkms are nothing but their scriptlets — dkms add + dkms autoinstall on install, dkms remove --all on removal — and pack-distro.sh's deb branch builds DEBIAN/control itself and exits if $root/DEBIAN exists ([ ! -e "$root/DEBIAN" ] || … exit 2). rpm and Arch are fine already: their scriptlets live in packaging/rpm/<name>.spec (%post/%preun) and packaging/arch/PKGBUILD (.INSTALL), which is exactly where your header says metadata belongs. So the split today is: rpm and Arch could move to pack-distro.sh now; deb cannot.

Smallest hook that closes it (your file, your call — I am not touching it):

# deb branch, before dpkg-deb
if [ -n "${PKG_DEB_SCRIPTS:-}" ]; then      # a directory holding postinst/prerm/preinst/postrm
    cp -a "$PKG_DEB_SCRIPTS"/. "$work/root/DEBIAN/"   # after control is written
    chmod 0755 "$work/root/DEBIAN"/postinst "$work/root/DEBIAN"/prerm 2>/dev/null || :
fi

with PKG_DEB_SCRIPTS documented next to PKG_NAME/PKG_SUMMARY/…; my caller would pass a two-file directory (it already generates exactly those files). If you prefer the symmetric form — one PKG_SCRIPTS=<dir> that the deb branch copies as DEBIAN/ and the rpm/Arch branches leave to their recipes — that is fine too; the point is that the scriptlet is metadata the caller owns, not something the emitter invents.

Two smaller things I hit that your script already solves, in case you want the credit recorded: normalize_modes is the same finding I had on fc45 (%dir on /usr/lib collides with filesystem), and your rpm branch building %files -f from the payload instead of a %dir list is what I ended up doing by hand.

What I am not doing: not refactoring my emitters to pack-distro.sh while the deb path cannot express the dkms scriptlets — that would silently drop the registration step, which is the whole package. The rpm/Arch halves are worth moving once you say the recipes should live in packaging/ for my three names (amdxdna-1bit-dkms, ec-su-axb35-dkms, 1bit-npu-config); say the word and I will write those two recipes and switch my script to call yours, so the weekly release has one shape for both sets.

Status of my side, for the record: #1280 merged (#1297, and the repair for its squash in #1324 — main was one revision behind what the PR proved). The kernel/driver set is scripts/mk-kernel-packages.sh, proven per family (deb 24/24, rpm 22/22, arch 22/22 rows) and the deb set's payload is byte-identical to this box's kernel. The one wiring nobody owns is the release call itself, because it needs the kernel debs and the public cert as inputs — that is the same question as this comment.

pack-version: a candidate's tag packs too, so the proof can find what…

release notes: list every package the release carries, read off the o…

pack-version: a candidate sorts above the previous release, which is …

pack-proof: the release installs every package it publishes, or it do…

pkg-proof: a coexist mode, because the engine package and this set ha…

pack-distro: the mode rule is the fleet's helper, not a fourth copy o…

docs(packaging): a weekly release tag upgrades in all three families,…

pkg-proof: a coexist mode, because the engine package and this set ha…

weekly: a package-only cut gets its HSA runtime, so its four packages…

docs: a package-only cut needs a workdir that has built, and what it …

weekly: a package-only cut gets its HSA runtime, so its four packages…

docs: the upgrade path and what each tool does with a downgrade, meas…

Navigation Menu

Repository navigation

packages: native .rpm (Fedora, openSUSE) and Arch packages next to the .deb, built by the weekly release #1279

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

packages: native .rpm (Fedora, openSUSE) and Arch packages next to the .deb, built by the weekly release #1279

Description

Activity

bong-water-water-bong commented on Nov 6, 2026

bong-water-water-bong commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions