ubuntu-latest is 26.04 now. Its rpm 6 runs %__gpg_sign_cmd without
taking the word after %{__gpg} for argv[0], as rpm 4 does, so the
command of our own broke there; rpm's own is given the passphrase file
and the digest through %_gpg_sign_cmd_extra_args and %_gpg_digest_algo
instead, which both read. Each rpm is then checked by the rpm of the EL
release it is for, against 3proxy-release-key.asc.
The OpenWrt SDK refuses an install which is not GNU's. 26.04 has the
Rust coreutils, and GNU's as gnuinstall and the like: gnuinstall is
linked as install ahead in PATH. ipk also reads DEVEL when there is no
RELEASE, so it can be run on the development branch.
workflow_dispatch takes a sign input, to sign the packages as a release
does without uploading anything.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A release whose tree has DEVEL and no RELEASE is one of the development
branch (release-kind.yml, called by the workflows below). For it only
the Windows x64 zip, the x86_64 and arm64 deb packages and the rpm for
EL 9 and 10 (x86_64 and arm64) are built and added to the release: no
Docker images, no source tarball, no ipk, armhf, watcom, win32 or
Windows arm64 builds. docker.yml makes it a prerelease, not "Latest",
which also keeps it out of the package repository 3proxy.github.io
builds from releases.
The packaging reads the version from RELEASE or DEVEL. rpm names the
source archive and its directory after the spec's Version, which for
2.0.0-devel is 2.0.0~devel, so that %setup finds it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release carried nothing installable on a router. Build the OpenWrt package
in the SDK for the four architectures that cover most consumer hardware:
mipsel_24kc ramips, MediaTek MT7620/MT7621
mips_24kc ath79, Atheros/QCA
arm_cortex-a7_neon-vfpv4 ipq40xx
aarch64_cortex-a53 mediatek filogic and similar
Linking against the distribution's libraries rather than building static keeps
the package near 100kB and gives it TLS and PCRE support.
The SDK file name carries the toolchain flavour and differs between targets -
ipq40xx is musl_eabi where the others are musl - so it is taken from the
directory listing instead of being assembled from the target name.
The package is built from the checked out tree rather than the published
release archive: the workflow runs when a release is created, and depending on
GitHub having generated that archive already would be a race.
opkg verifies the signature of a feed index and never of a package file, so
the packages are published with checksums and a signature over them, in the
same shape as the other artifacts, and are not signed in any opkg specific
way.
