Adds tarballs to PPG 17 - #1
Closed
rjd15372 wants to merge 42 commits into
Closed
Conversation
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…ball.sh Patch postgres.real (the wrapper shell script at bin/postgres cannot be patchelf'd, and postmaster is gone since PG 16) and drop the error swallowing so a failed patchelf aborts the build. RPATH the bundled libperl.so to $ORIGIN so it finds libcrypt in CORE/ (RUNPATH is not transitive). Replace the ldd-based library audit with a DT_NEEDED soname audit: inside the fully-populated buildroot ldd resolves everything from /usr/lib64 via ld.so.cache, so it could never catch a library that copy_deps failed to bundle. Each NEEDED soname must now be either in the system exclude list or present under /opt. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…iner Ran build-tarball.sh to completion inside a rockylinux:9 container provisioned with the staging:17 RockyLinux_9 RPMs (mirroring the OBS simpleimage buildroot: EPEL + CRB + staging repo) and structure-diffed the result against the official percona-postgresql-17.10-ssl3-linux-x86_64.tar.gz. Fixes found: - simpleimage: drop python3.12-idle BuildRequires — the package does not exist on EL9 (RHEL strips IDLE from python3.12), so the OBS build would be unresolvable. The official tarball ships no _tkinter either. - simpleimage: add percona-pgpool-II-pgNN-devel and -extensions — the official tarball ships the pgpool2 headers (include/pgpool2/) and the pgpool_adm/pgpool-recovery PostgreSQL extensions. - bundle_deps: accept extra directory trees walked recursively so python lib-dynload/ + site-packages C extensions (libsqlite3, libncursesw, libuuid, libgdbm, libpq via psycopg2) and perl XS module deps (libdb for DB_File, libsombok for Unicode::LineBreak) are bundled; perl XS .so get RPATH /opt/percona-perl/lib. These were the NEEDED-audit true positives; nothing was added to SYSTEM_LIBS_EXCLUDE. - site-packages copy list: add jmespath, s3transfer, psycopg2 (all shipped by the official tarball; psycopg2 is required by patroni). - license/doc staging: RPM %license files live under /usr/share/licenses, pgbouncer docs under unprefixed /usr/share/doc/pgbouncer; pgpool headers are flat in /usr/include and get nested under include/pgpool2/ per the reference layout; bundle the python man page under share/man. - section 15: precompute the bundled-soname list once instead of a full 'find /opt' per NEEDED entry (audit re-verified to fail on a synthetic missing soname and pass once bundled). Verification: NEEDED audit 0 unresolved; smoke commands pass (initdb, postgres.real, python+ssl+yaml, patroni import, perl, tcl); tarball top-level is exactly the percona-* component dirs. Accepted structure divergences vs the official tarball: - percona-haproxy/ absent (out of scope for this build, per spec). - percona-pgbadger/auto/ absent (perl .packlist install artifact of the official source build; RPM installs do not create it). - percona-tcl/share/ absent (official bundles man pages for tcl extensions itcl/tdbc/thread/sqlite built from source; EL9 does not package those extensions — our tcl man pages live under percona-tcl/man, which the official tarball also has). - percona-python3/lib64 extra (symlink to lib/pythonX.Y so the RPM python, compiled with platlibdir=lib64, resolves PYTHONHOME). - percona-postgresql17/lib/pgpool-regclass.so absent (obsolete extension for PG < 9.4; pgpool 4.7 RPMs no longer build it). - site-packages: psycopg (v3) absent (official pip-installs it; patroni works via the packaged psycopg2). Known blocker for the OBS build, out of scope here: the published python3.12-boto3 requires python3.12dist(jmespath) and python3.12dist(s3transfer), which no project in the RockyLinux_9 repo path provides — percona-patroni-aws is currently uninstallable in the buildroot. jmespath/s3transfer packages need to be added to ppg:common:deps (validated locally with stand-in RPMs built from the PyPI sdists). Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Review fixes on top of the container validation, re-validated in the
Rocky 9 harness (audit clean, all smoke commands pass, structure diff
unchanged):
- RPATH python C extensions (lib-dynload/ + site-packages) at
/opt/percona-python3/lib: the python3 wrapper sets LD_LIBRARY_PATH,
but embedded interpreters (plpython3 inside postgres.real) don't run
through the wrapper, and the executable's RUNPATH does not apply to
dlopened extensions' own dependencies.
- Section 15: build the bundled-soname list with -xtype f so dangling
symlinks never count as bundled. This immediately caught a real bug:
copy_deps only copied files matching the ${base}.so* glob, so when
the SONAME symlink resolves to a differently-named real file
(libldap.so.2 -> libldap_r.so.2.0.200, libopenblaso.so.0 ->
libopenblaso-r0.3.29.so on EL9) only a dangling symlink was bundled
and the library silently resolved from the buildroot. copy_deps now
copies the resolved real file explicitly.
- Perl XS RPATH loop: drop the 2>/dev/null || true swallow — every file
fed in is a real XS .so, so a patchelf failure is meaningful and must
fail the build. The new python loop keeps a file(1) ELF guard (the
tree contains non-ELF *.so* test fixtures) but also fails loudly on
patchelf errors.
Gate spot-check re-run: audit fails on a missing soname and on a
dangling symlink, passes once the real file (or a valid symlink to it)
is bundled.
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
python3.12-idle does not exist on EL9 (dropped from BuildRequires); the ldd-based verification audit was replaced by a DT_NEEDED soname audit, which detects unbundled libraries even inside the populated buildroot. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The published python3.12-boto3 RPM carries runtime requirements python3.12dist(jmespath) >= 0.7.1 < 2 and python3.12dist(s3transfer) >= 0.12 < 0.13, but no project in the OBS repository path chains provides them, leaving percona-patroni-aws (and the tarball packages that install it) unresolvable in build chroots. Package both, mirroring the python3-boto3/python3-botocore layout: obs_scm service pinned to the upstream tag (jmespath 1.0.1, s3transfer 0.12.0 - the only 0.12.x release), python3.12 stack on EL, noarch, Epoch 1. s3transfer requires botocore, matching upstream metadata; jmespath has no python dependencies. Add ppg:staging:17 _aggregate packages so the staging repositories stay self-contained, same as python3-boto3. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…nt repos User decision 2026-07-21: SSL variants become repositories (ssl1.1, ssl3, ssl3.5) of one ppg:staging:17:tarballs subproject instead of three subprojects. Per-repo differences move into %if "%_repository" conditionals (OBS defines _repository in every build config). The artifact is now written by the %build script directly to /usr/src/packages/OTHER with the exact official name, since the simpleimage recipe's raw-sed Name/Version extraction cannot vary per repository. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…t repos Replace the three per-SSL-variant subprojects (tarballs/ssl1.1, ssl3, ssl3.5) with a single ppg:staging:17:tarballs subproject that carries three repositories, one per variant, each stacked on its EL base (ssl1.1 -> RockyLinux 8, ssl3 -> RockyLinux 9, ssl3.5 -> RockyLinux 10). User decision: variants are repositories, not subprojects. Per-repository differences move to %if "%_repository" conditionals: the Python 3.12 vs default-python3 BuildRequires split in the simpleimage recipe, and the per-base resolution hints in the merged project config. The TARBALL_SSL_VARIANT / TARBALL_PYTHON_PKG macros and the per-variant macros.yaml files are gone. Artifact naming changes with it: the simpleimage recipe extracts Name:/Version: with a raw (unexpanded) sed, so the output name cannot vary per repository. The %build script now derives the full official name itself and writes the tarball directly into /usr/src/packages/OTHER (the OBS result dir), skipping /.simpleimage.tar.gz entirely (#!NoTarBall keeps the recipe's own tar step off). The SSL variant is derived from the buildroot's EL major version (os-release, with a glibc %dist-tag fallback) rather than the openssl-libs version, which can no longer tell EL9 from EL10 (EL 9.8+ and EL10 both ship OpenSSL 3.5.x). Unmapped EL majors fail the build loudly. The name now uses the official dash-arch form (percona-postgresql-<ver>-<variant>-linux-x86_64.tar.gz). Delete tests/test_tarball_variants.py: with a single package copy there is no byte-identity to guard. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The tarballs section still said the SSL variant is detected from the buildroot's openssl-libs version, which is the abandoned approach: EL 9.8+ and EL10 both ship OpenSSL 3.5.x, so the build script derives the variant from the buildroot's EL major version instead (/etc/os-release PLATFORM_ID, glibc %dist tag as fallback). Align the README with the committed script. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…et::SSLeay The ssl variant labels promise host compatibility (ssl1.1 = OpenSSL 1.1 hosts, ssl3 = any OpenSSL 3.0+ host, ssl3.5 = 3.5+ hosts), and what enforces that at the ELF level is each binary's versioned symbol references (version NEEDS) against the host-provided libssl/libcrypto. That property was unguarded: the buildroot may ship a newer OpenSSL than the promise (the EL9 buildroot has 3.5.x), so a staging rebuild could silently start referencing newer version nodes. Add an OpenSSL host-ABI audit to the section-15 verification gate: readelf -V version NEEDS (needs only, never version definitions) are parsed per needed soname, filtered to libssl.so.*/libcrypto.so.*, and checked against a per-variant allowed-node pattern (ssl1.1: OPENSSL_1_1_*, ssl3: OPENSSL_3.0.x only, ssl3.5: up to 3.5.x). The /opt/percona-python3 tree is excluded: it bundles its own OpenSSL copy, so its OpenSSL symbol needs are satisfied internally and are not part of the host promise. The SSL_VARIANT detection (EL-major mapping) moves from section 16 to the top of section 15 since the audit's policy selection depends on it; section 16 reuses the variable. Prune Net::SSLeay from the bundled perl (auto/Net/SSLeay XS dirs plus Net/SSLeay.pm/.pod), for parity with the official tarball, which does not ship it; its XS module links the host libssl/libcrypto with OPENSSL_3.2.0 needs that would violate the variant promises. NOTE: the gate now intentionally FAILS on the current EL9/Rocky 9.8 base — pgcrypto.so inherits an OPENSSL_3.4.0 reference from the staging build (verified: the official tarball's pgcrypto needs only OPENSSL_3.0.0). The ssl3 variant is being rebased onto Ubuntu 22.04 debs in a follow-up commit (its pgcrypto needs only OPENSSL_3.0.0); the strict OPENSSL_3.0.x policy is the documented reason for that rebase and stays as-is. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…-deb.sh) Section-by-section port of build-tarball.sh to Debian/Ubuntu paths and tools, sharing the same layout, helpers, SYSTEM_LIBS_EXCLUDE list and verification gate (DT_NEEDED soname audit, per-variant OpenSSL host-ABI audit, smoke commands). Key mappings: PostgreSQL under /usr/lib/postgresql/<major> (real binaries — /usr/bin/psql is a postgresql-common pg_wrapper symlink), ecpg + libecpg/libpgtypes from libecpg-dev, headers from /usr/include/postgresql with the <major>/server nesting flattened to include/server, pgbouncer/pgpool tools in /usr/sbin, config in /etc/pgpool2, python 3.10 with platlibdir=lib (no lib64 symlink hack) and third-party modules merged into the version-agnostic lib/python3/dist-packages that Debian's site.py resolves under a foreign PYTHONHOME, perl flattened from archlib/privlib/vendorarch/vendorlib, tcl stdlib from /usr/share/tcltk, multiarch libdir throughout, and version discovery via dpkg-query (epoch and revision stripped). Variant mapping is deliberate per deb base: ubuntu-22.04 -> ssl3, anything else is fatal. Validated end-to-end in an ubuntu:22.04 container against the published staging Ubuntu_22.04 debs: both audits clean under the strict ssl3 policy (only OPENSSL_3.0.x version nodes), all six smoke commands pass, artifact percona-postgresql-17.10-ssl3-linux-x86_64.tar.gz with the ten official percona-* component dirs. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The ssl3 variant promises to run on any OpenSSL 3.0 host, but its EL9 base can no longer deliver that: Rocky 9.8+ ships OpenSSL 3.5.x, so staging-built binaries (pgcrypto.so) reference OPENSSL_3.4.0 symbol version nodes and the gate added in commit cd4f043 correctly fails the build. Ubuntu 22.04 ships OpenSSL 3.0.2 (glibc 2.35), so its binaries can only reference OPENSSL_3.0.x nodes — verified against the published staging Ubuntu_22.04 debs. - simpleimage: wrap BuildRequires in %if "%_repository" == "ssl3" (deb binary package names, verified against the published Packages index) with the existing RPM list — including the nested ssl3.5 python3 split — in the %else branch; %build becomes a small os-release dispatcher running build-tarball-deb.sh on deb bases and build-tarball.sh elsewhere. - project.yaml: ssl3 repo paths now mirror staging's Ubuntu_22.04 chain (staging + common:deps + Ubuntu:22.04/universe); the EL9 hdf-libs Prefer block is dropped (no deb-side hints needed yet). - build-tarball.sh: EL9 is now an unmapped (fatal) tarball base; prune IO::Socket::SSL alongside Net::SSLeay (pure perl, but it can never load without the pruned XS module, and the official percona-perl tree ships neither); clarify the python-tree OpenSSL audit exclusion comment. - root/README.md: document the new ssl3 base, the two parallel builder scripts + dispatcher, and the deb-side python divergences (3.10, dist-packages). Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
RHEL 9.8 rebased to OpenSSL 3.5 and the EL9 staging pgcrypto.so references OPENSSL_3.4.0, breaking the ssl3 (OpenSSL 3.0 hosts) promise. ssl3 now consumes staging Ubuntu 22.04 debs via a second builder (build-tarball-deb.sh) selected by an os-release dispatcher; the verification gate enforces each variant's OpenSSL promise via a versioned-symbol-needs audit. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The OpenSSL host-ABI audit parses 'readelf -V' with stderr suppressed: if readelf were silently missing from the buildroot, awk would see empty input, emit zero violations, and the gate would pass vacuously — the exact failure mode it exists to prevent. Assert readelf up front in section 15 of both builder scripts, and add binutils to the RPM branch of the simpleimage BuildRequires (the deb branch already had it; the RPM buildroots only pulled it transitively). Also annotate the ssl3 arm of build-tarball.sh's OPENSSL_ALLOWED case as unreachable: EL9 now fails fatally before SSL_VARIANT can be ssl3 (the variant is deb-based, built by build-tarball-deb.sh); the arm is kept only to document the policy. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The first OBS sync of the PR project (pr-145) left the
percona-postgresql-tarball package unresolvable in all three repos:
- ssl1.1 (Rocky 8 base): "have choice for glibc-langpack = 2.28-...
needed by glibc: glibc-all-langpacks glibc-langpack-aa ...". The
simpleimage build resolves the full runtime closure and ignores the
base config's "Ignore: glibc:glibc-langpack" rule, so the virtual
glibc-langpack requirement surfaces as a choice. Fix: Prefer:
glibc-minimal-langpack (same fix as the ubi9 container project).
- ssl3 (Ubuntu 22.04 base): "preinstalls: conflict for providers of
perl-base >= 5.20.1-3 needed by init-system-helpers". The global
"Type: simpleimage" disables obs-build's recipe-type guessing that
staging relies on for its deb repos (Preinstall contains debianutils
-> Type dsc -> binarytype deb), and Build.pm does not re-derive the
binary format for simpleimage (only for kiwi/docker/...), so the repo
resolved with binarytype UNDEFINED, i.e. RPM dependency semantics
applied to deb metadata, breaking the preinstall expansion. Fix:
"Binarytype: deb" in the ssl3 block (plus explicit "Binarytype:
rpm" in the two RPM blocks for clarity).
- ssl3.5 (Rocky 10 base): "have choice" between our staging
python3.12-* packages and the EL10 python3-* packages (python3 is
3.12 on EL10, so the distro python3-foo packages also provide
python3.12-foo) for every percona-patroni dependency both sides
ship. Fix: Prefer: lines for our python3.12-{wcwidth,dateutil,six,
click,prettytable,psutil,boto3,dns} (the reported set) plus
python3.12-botocore (EPEL10's python3-botocore also provides it; the
choice surfaces once boto3 resolves) and python3.12-psycopg2
(defensive; currently shadowed by our python3-psycopg2 transition
package). No glibc-langpack Prefer needed here: the EL10 base
configs already carry "Prefer: glibc-langpack-en".
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…acing Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
boto3/botocore require python3.12dist(jmespath) and (s3transfer) via rich deps; EPEL10's python3-jmespath/python3-s3transfer provide those dist names too on EL10, so OBS reports have-choice against our staging python3.12-* packages. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…iginal names Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
OpenSSL 3.4 redefines the EVP_MD_CTX_size() compatibility macro to call EVP_MD_CTX_get_size_ex(), a function introduced in 3.4.0. Compiling contrib/pgcrypto/openssl.c against >= 3.4 headers (e.g. Rocky Linux 9.8, openssl 3.5.5) therefore silently adds a versioned runtime dependency on EVP_MD_CTX_get_size_ex@OPENSSL_3.4.0, which does not exist on OpenSSL 3.0-3.3 hosts and makes pgcrypto.so fail to load there. A readelf audit showed this is the only symbol in the whole EL9 artifact set above OPENSSL_3.0.0. Add pgcrypto-openssl34-md-ctx-size.patch, which restores the 3.0-era macro expansion (EVP_MD_get_size(EVP_MD_CTX_get0_md(ctx)) — identical behavior) when built against >= 3.4 headers, keeping the built module loadable on any OpenSSL 3.x host. Verified via PGXS build of contrib/pgcrypto (PG 17.10 source, Rocky 9, openssl 3.5.5): unpatched pgcrypto.so needs OPENSSL_3.4.0; patched needs only OPENSSL_3.0.0. This is a candidate for proposing upstream to PostgreSQL. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
….5 and deb builder
Revert the tarball variant matrix to two repositories, ssl1.1
(RockyLinux_8) and ssl3 (RockyLinux_9), dropping the interim Ubuntu
22.04 deb-based ssl3 and the RockyLinux_10 ssl3.5 repo:
- The Ubuntu deb detour is abandoned: the PGDG deb layout is
non-relocatable (multiarch lib dirs, split /usr/share/postgresql
trees, tools hardwired to /usr/lib/postgresql/<V> — verified against
PGDG's own packages), so it cannot reproduce the official
/opt/percona-* tarball layout. build-tarball-deb.sh and the %build
os-release dispatcher are removed; the deb branch survives in git
history and in the spec's rejected-alternatives section.
- ssl3 is honest on EL9 again because the OPENSSL_3.4.0 leak is now
fixed at the source: staging percona-postgresql patches pgcrypto to
avoid the EVP_MD_CTX_get_size_ex() OpenSSL-3.4 API, so EL9-built
binaries reference only OPENSSL_3.0.0 nodes and pass the gate's
strict OPENSSL_3\.0\.[0-9]* policy. Validated in a Rocky 9.8
container: PGXS-built patched pgcrypto.so installed over the staging
one, full build-tarball.sh run, both audits clean, artifact
percona-postgresql-17.10-ssl3-linux-x86_64.tar.gz produced.
- ssl3.5 is dropped as redundant: with the pgcrypto fix the ssl3
tarball already runs on every OpenSSL 3.x host, including 3.5 ones.
- The simpleimage recipe loses all %if branches (both remaining bases
are EL with identical package naming, python3.12 stack on each).
- The ssl3 prjconf block gains Binarytype: rpm and
Prefer: glibc-minimal-langpack (the EL9 base configs carry only
"Ignore: glibc:glibc-langpack", which image-type expansion ignores —
same "have choice" failure as Rocky 8).
Tighten the ssl1.1 gate: the allowed version nodes shrink from
OPENSSL_1_1_[0-9a-z]* to exactly OPENSSL_1_1_0/OPENSSL_1_1_1 (upstream
OpenSSL 1.1's only nodes), so Red-Hat-fork-only nodes such as
OPENSSL_1_1_1b (the krb5/libssh incident) fail at build time instead
of at load time on stock-OpenSSL hosts.
Apply the acceptance-derived script fixes:
- postgres wrapper exports PYTHONHOME=/opt/percona-python3: the
embedded plpython3 interpreter never runs the interactive python3
wrapper and crashed the backend without it (seen on every variant).
- psql wrapper searches Debian-multiarch host readline paths
(/lib/{x86_64,aarch64}-linux-gnu/libreadline.so.8) too.
- libunistring/libnghttp2/libidn2 leave SYSTEM_LIBS_EXCLUDE and are
bundled: their sonames drift across distro generations
(libunistring.so.2 vs .so.5) and minimal hosts lack them.
README and the design spec are updated to the two-variant matrix, with
host prerequisites (/run/postgresql, tzdata, krb5 libs) documented and
the deb approach recorded under rejected alternatives.
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
… (EL8) The EL8-built Percona PostgreSQL binary tarball (ssl1.1 variant) bundles krb5-libs. Red Hat builds krb5 with --with-crypto-impl=openssl against its OpenSSL 1.1.1 fork, so libk5crypto.so.3 needs symbol version nodes (EVP_KDF_ctrl@OPENSSL_1_1_1b) that exist only in RHEL-family libcrypto.so.1.1 — the bundled library fails to load on stock OpenSSL 1.1 hosts (proven on Debian 11). The official Percona tarball's krb5 has no libcrypto dependency at all. Rebuild the Rocky Linux 8 krb5 1.18.2-34 source package in ppg:common:deps, restricted to the RockyLinux_8 repository, keeping all binary package names identical to the distro's: - --with-crypto-impl=builtin: no libcrypto linkage in any krb5-libs shared object (libk5crypto now needs only krb5support/keyutils/ resolv/libc) - --with-tls-impl=no: k5tls.so becomes the upstream notls stub - --without-spake-openssl: spake.so supports only the native edwards25519 group (the default) — no OpenSSL-backed NIST groups - percona-builtin-crypto-portability.patch detaches the RH downstream FIPS/KDF hooks from OpenSSL in backend-independent code (configure hard-fail, prng.c, libkrad, spake, pkinit #error guard) - Release 34.percona.1 so this EVR wins over 1.18.2-34.el8_10 while yielding to a future distro -35 rebase - PKINIT still builds against the buildroot OpenSSL (krb5-pkinit is a separate subpackage, never bundled into the tarball) Verified in a rockylinux:8 container: every .so in krb5-libs has zero libcrypto/libssl NEEDED entries and zero OPENSSL_* version references; exported symbols and version definitions are identical to the distro build; percona-postgresql17 initdb/server/psql work with the rebuilt stack force-installed. ppg:common:deps has publish disabled, so these packages exist only inside build chroots and the tarball bundle. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…ty (EL8) The EL8-built Percona PostgreSQL binary tarball (ssl1.1 variant) bundles libssh.so.4 (a libcurl dependency for scp/sftp). Red Hat builds libssh against its OpenSSL 1.1.1 fork, so the library needs symbol version nodes (EVP_KDF_ctrl@OPENSSL_1_1_1b) that exist only in RHEL-family libcrypto.so.1.1 — it fails to load on stock OpenSSL 1.1 hosts (proven on Debian 11). Rebuild the Rocky Linux 8 libssh 0.9.6-16 source package in ppg:common:deps, restricted to the RockyLinux_8 repository, keeping all binary package names identical to the distro's: - -DWITH_GCRYPT=ON: libgcrypt crypto backend, no OpenSSL linkage at all (libgcrypt stays host-provided and is universally present) - BuildRequires libgcrypt-devel instead of openssl-devel - Release 16.percona.1 so this EVR wins over 0.9.6-16.el8_10 while yielding to a future distro -17 rebase Verified in a rockylinux:8 container: libssh.so.4.8.7 links libgcrypt.so.20/libgpg-error.so.0 with zero libcrypto/libssl NEEDED entries and zero OPENSSL_* version references; all 426 exported symbols and the LIBSSH_4_5_0..4_8_1 version definitions are identical to the distro build; the full upstream test suite (58/58, including client and server torture tests) passed at build time; curl scp:// and sftp:// transfers against a local sshd work end-to-end with the rebuilt library force-installed. ppg:common:deps has publish disabled, so the package exists only inside build chroots and the tarball bundle. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…ost notes - Move the libidn2/libunistring/libnghttp2 rationale comment out of the SYSTEM_LIBS_EXCLUDE string literal: every word between the quotes is a live glob-prefix token in is_system_lib, so a future comment word starting with "lib" would silently exclude real libraries from bundling and from both audits. Comment-only change (the list still holds exactly its 34 soname patterns); a warning note now marks the literal as a token list. - README tarball host notes: document that the postgres wrapper's PYTHONHOME export is inherited by server-spawned children, so host-python archive_command/restore_command/backup hooks must strip it (env -u PYTHONHOME); correct the krb5 prerequisite to host /etc/krb5.conf configuration (the krb5 libraries are bundled); add the EVR-race playbook line for ssl1.1 SSL-ABI audit failures on RH-fork nodes via krb5/libssh (bump the ppg:common:deps rebuilds). Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The ppg:common:deps RockyLinux_8 repository chain carries no TeX Live, making the package unresolvable in OBS (nothing provides /usr/bin/pdflatex, /usr/bin/makeindex). The prebuilt PDF manuals are already vendored as Source3 (krb5-1.18.2-pdfs.tar, extracted into build-pdf/ by %autosetup -a 3), so the LaTeX toolchain was never actually exercised — the distro spec only rebuilds PDFs when the tar is empty. - Drop the TeX BuildRequires: texlive-pdftex, latexmk, the tex(*.sty) block, texlive, texlive-latex, texlive-texmf-fonts and the /usr/bin/pdflatex + /usr/bin/makeindex file deps. python3-sphinx is kept: it builds the man pages and HTML docs (no LaTeX involved) and resolves fine in the repo chain. - %build: remove the latex sphinx-build pass, the pdflatex fallback loop and the pdfs.tar.new repack; assert the six vendored PDFs exist instead. Verified in a rockylinux:8 container without any TeX Live installed: build succeeds, all 7 binary subpackage file lists are byte-identical to the previous (texlive-present) build, the vendored PDFs are packaged with real content, and the readelf evidence for krb5-libs is unchanged (zero libcrypto/libssl NEEDED, zero OPENSSL_* version refs). Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The python3.12-devel BuildRequires was scoped to EL8 only, and no
PYTHON= wiring existed at all: configure's --with-python probes plain
python3, which on EL8 happens to resolve to 3.12 (the python3.12
package registers /usr/bin/python3 via alternatives when it is the
only python3 in the chroot) but on EL9 is always 3.9. The ssl3
tarball therefore shipped plpython3.so linked against libpython3.9
while bundling the python 3.12 stdlib, so the embedded interpreter
fatal'd at backend start ("No module named 'encodings'",
acceptance-proven on ubuntu 22.04/24.04 hosts).
Extend the python3.12-devel BuildRequires to EL9 (rhel >= 8 && < 10;
EL10's default python3 already IS 3.12) and add an explicit
'export PYTHON=%{_bindir}/python3.12' under the same bounds next to
configure, making the interpreter selection deterministic on EL8 too.
Verified by a targeted compile on rockylinux:9 against the PG 17.10
source (Percona-Lab/postgres release-17.10.1): with the PYTHON wiring
plpython3.so carries NEEDED libpython3.12.so.1.0; without it (negative
control) it carries NEEDED libpython3.9.so.1.0.
Release note: on EL9 the plpython3 procedural language now embeds
python 3.12 (previously 3.9), consistent with EL8 and the percona
python3.12-* runtime stack.
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…fallback The EL8-built (ssl1.1) psql.bin carries NEEDED libreadline.so.7, but current hosts ship only libreadline.so.8 — and LD_PRELOAD cannot satisfy a missing NEEDED soname, so the loader refused to start psql.bin at all. The original POC wrapper (like the official tarball's wrapper) handled this by symlinking libreadline.so.7 -> <host .so.8> inside the artifact's lib dir (reachable via psql.bin's RUNPATH $ORIGIN/../lib); the round-2 rewrite dropped that fallback. Restore it: when the wrapper finds only a host libreadline.so.8 (any of the searched paths), it best-effort creates the .so.7 symlink in $PG_LIB_PATH before exec'ing psql.bin. LD_PRELOAD behaviour for the .so.8-linked (EL9/ssl3) binary is unchanged, and the symlink write is guarded (|| true) so read-only installs still get the plain exec. Verified on debian:11 + libreadline8 with the fresh ssl1.1 artifact: the old wrapper fails with 'error while loading shared libraries: libreadline.so.7' (exit 127); with the new wrapper psql.bin starts and reports 'connection refused' as expected (no server running), and the libreadline.so.7 -> /lib/x86_64-linux-gnu/libreadline.so.8 symlink is created. shellcheck --severity=error and bash -n pass on both build-tarball.sh and the generated wrapper. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
… chroot On the EL8 parallel-python (python3.12-*) stack the python3.12dist(...) rich-require generators do not run, so python3.12-boto3 carries no dependency that would pull python3.12-jmespath/python3.12-s3transfer into the tarball build chroot transitively (buildinfo-verified: zero python3.12dist requires generated on EL8). build-tarball.sh section 8 then stages boto3/botocore without jmespath/s3transfer and patroni_aws imports fail at run time. Name both packages explicitly in the simpleimage BuildRequires. Binary names verified against the built pr-145 repository (isv:percona:PR:pr-145:ppg:common:deps, RockyLinux_8/x86_64): python3.12-jmespath-1.0.1 and python3.12-s3transfer-0.12.0. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…lter The obs-pr-check workflow builds --only-repos from PR labels (distro-base names like RockyLinux_9, Debian_13). SSL-variant tarball repos (ssl1.1, ssl3, ssl3.5) are named by OpenSSL variant, not distro base, so they never match a label-derived filter — any repo label on a PR stripped the simpleimage tarball project meta to zero repositories and the tarball silently never built. Extract the filter into _filter_meta_repos() and always retain ssl* repos regardless of the filter. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372
added
RockyLinux_9
no-dep-cascade
Collaborator
Author
|
Closing this PR, since actions will not run when opening PRs from a branch in a repo fork |
rjd15372
added a commit
that referenced
this pull request
Aug 31, 2026
The 2026-08 upstream minors (14.24 / 15.19 / 16.15 / 17.11) add a new GUC line to postgresql.conf.sample right after gin_fuzzy_search_limit: #output_plugin_libraries = 'pgoutput, test_decoding' # approved plugins for logical decoding That line sits inside the trailing context of the extension_destdir quilt patch's conf.sample hunk, and dpkg-source applies patches with fuzz 0, so the Debian/Ubuntu server builds failed with 'Hunk #1 FAILED at 726' on every major carrying the patch (staging/14, 15, 16, 17 and 17/extras; 18 does not carry it). Refresh the hunk context to include the new line. Each refreshed hunk verified to apply at fuzz 0 (patch -p1 -F 0 --dry-run) against the corresponding upstream tag's postgresql.conf.sample. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372
added a commit
that referenced
this pull request
Aug 31, 2026
Same refresh as bf52b62: the 16/tde server tree carries its own copy of the extension_destdir quilt patch, missed in that commit, and the Percona fork branch release-16.15.1 includes the new output_plugin_libraries line in postgresql.conf.sample just like upstream 16.15, so the conf.sample hunk failed at fuzz 0 ('Hunk #1 FAILED at 750'). This also unblocks percona-pg_tde in the same project: its Debian build failed with 'access/xlog_smgr.h: No such file or directory' because the tde server (which provides that header via its -dev package) never built, so the chroot resolved the stock staging:16 server headers instead. Hunk verified to apply at fuzz 0 against the fork's release-16.15.1 postgresql.conf.sample. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372
added a commit
that referenced
this pull request
Aug 31, 2026
The 2026-08 upstream minors (14.24 / 15.19 / 16.15 / 17.11) add a new GUC line to postgresql.conf.sample right after gin_fuzzy_search_limit: #output_plugin_libraries = 'pgoutput, test_decoding' # approved plugins for logical decoding That line sits inside the trailing context of the extension_destdir quilt patch's conf.sample hunk, and dpkg-source applies patches with fuzz 0, so the Debian/Ubuntu server builds failed with 'Hunk #1 FAILED at 726' on every major carrying the patch (staging/14, 15, 16, 17 and 17/extras; 18 does not carry it). Refresh the hunk context to include the new line. Each refreshed hunk verified to apply at fuzz 0 (patch -p1 -F 0 --dry-run) against the corresponding upstream tag's postgresql.conf.sample. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372
added a commit
that referenced
this pull request
Aug 31, 2026
Same refresh as bf52b62: the 16/tde server tree carries its own copy of the extension_destdir quilt patch, missed in that commit, and the Percona fork branch release-16.15.1 includes the new output_plugin_libraries line in postgresql.conf.sample just like upstream 16.15, so the conf.sample hunk failed at fuzz 0 ('Hunk #1 FAILED at 750'). This also unblocks percona-pg_tde in the same project: its Debian build failed with 'access/xlog_smgr.h: No such file or directory' because the tde server (which provides that header via its -dev package) never built, so the chroot resolved the stock staging:16 server headers instead. Hunk verified to apply at fuzz 0 against the fork's release-16.15.1 postgresql.conf.sample. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.