- 8-stream (EOL): switch from single vault.centos.org to 3 verified vault mirrors
https://mirrors.aliyun.com/centos-vault/8-stream/https://ftp.iij.ad.jp/pub/linux/centos-vault/8-stream/https://ftp.yandex.ru/centos/centos/8-stream/ (dual-path validated)
via multi-baseurl sed in Dockerfile.centos-stream EL8 branch
- 9-stream: update modify_dnf_source.pl @mirrors to 4 verified stream mirrors
(mirrors.aliyun, mirrors.ustc, ftp.iij, ftp.yandex /centos-stream)
drop vault.centos.org (404 for active 9-stream, verified via HEAD)
- verified repodata (BaseOS/$basearch/os/repodata/repomd.xml) on both arches
RPM does not allow '-' in the Release field (it is the Version/Release
delimiter). The 'uos20-' prefix produced Release values like 'uos20-b1.el8'
which rpmbuild rejects with 'Illegal char '-' (0x2d)'. Switch to 'uos20.'.
The standard EL 8 build does not include the do_dup2() kernel-panic
workaround needed on UOS 20 kernels. Point UOS 20 users at the UOS20
variant instead, matching the dedicated 'Build for uniontech UOS 20'
section in Other Notes.
Replace the hardcoded 'el7' / 'x86_64' filter with ARCH and EL
variables, populated from `uname -m` and `./compile.sh GETEL`
respectively. UOS 20 still requires manually setting EL=uos20
since it's not auto-detectable from the running system.
PKGREL=1 + 'uos20' prefix concatenated to 'uos201', which reads as
'uos two hundred one' rather than 'uos20 version 1'. Add a hyphen
('uos20-') so the resulting release tag is 'uos20-1' / 'uos20-b12' etc.
Update compile.sh logic and the three doc references (README,
AGENTS.md, docker/README.md) to match.
Add an 'Other Notes' subsection describing the UOS 20 kernel
do_dup2() panic, the openssh-uos20-kernel-panic-fix.patch workaround,
and how to opt in via UOS20=1 (which also prefixes PKGREL with uos20).
Note that ordinary EL7/8/9 builds are unaffected, and link to the
Docker build instructions for the same variant.
The upload-artifact template hardcoded 'el' as a prefix
(rpm-el${el}-${arch}), which glued 'el' to non-numeric el values
like 'uos20' and produced ugly artifact names such as
'rpm-eluos20-x86_64'.
Add an explicit 'artifact' field to each matrix entry carrying the
full artifact name, and reference it directly in the upload step.
This keeps naming fully self-describing per entry and lets future
variants pick their own label without touching the template.
Add a UOS 20 matrix entry to both build-arm64 and build-amd64 jobs,
reusing the existing el8 / aarch64_el8 base images and passing
-e UOS20=1 to the container. Artifact names use 'uos20' (rpm-uos20-x86_64,
rpm-uos20-aarch64) so they are distinguishable from the standard el8
builds in releases.
The release job already downloads everything under artifacts/, so no
changes there.
Add a UOS 20 Variant subsection in the EL7 build area and a row in the
Build Arguments table, showing how to reuse the elssh:el7 image with
-e UOS20=1 to produce UOS 20 RPMs.
The UOS 20 build was previously a near-duplicate spec (openssh.uos20.spec)
with only the kernel-panic patch as an intentional difference. The
kerberos5 and gssapi drift was unintentional and caused maintenance pain
upstream changes had to be applied in two places.
Now there is one spec. The kernel-panic patch is gated on a uos20 macro
that compile.sh sets only when UOS20=1 is in the environment, so non-UOS
builds cannot accidentally pick it up. When UOS20=1, PKGREL is prefixed
with 'uos20' so the resulting RPMs are distinguishable from the standard
build (e.g. PKGREL=1 -> uos201).
Delete openssh.uos20.spec, document UOS20=1 in AGENTS.md.
The do_dup2() NULL pointer dereference panic affects all UOS 20 systems,
not just aarch64, so the patch name is generalized. Move the patch slot
from Patch100 (which collides with 10.4-fix-gssapi.patch in other specs)
to Patch999. Add an inline comment documenting the panic call trace and
fix mechanism.
