Skip to content

ppg:staging: next release train — PG 14.24 / 15.19 / 16.15 / 17.11 / 18.6 and component bumps per QA fixtures - #16

Open
rjd15372 wants to merge 5 commits into
mainfrom
next-train-bumps
Open

ppg:staging: next release train — PG 14.24 / 15.19 / 16.15 / 17.11 / 18.6 and component bumps per QA fixtures#16
rjd15372 wants to merge 5 commits into
mainfrom
next-train-bumps

Conversation

@rjd15372

@rjd15372 rjd15372 commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Moves ppg:staging to the next release train as expected by the Percona-QA/ppg-testing fixtures (versions/*.py + settings.py, PG-2628 / PG-2544): 14.24 / 15.19 / 16.15 / 17.11 / 18.6.

Server minors

  • PG_MINOR_VERSION / PG_PREV_MINOR_VERSION bumped in staging/14–18. Upstream REL_14_24 … REL_18_6 tags exist.
  • Percona fork (17, 18): PERCONA_PG_PATCH_VERSION 2 → 1, matching QA's percona-version 17.11.1 / 18.6.1. The fork currently has only the release-17.11.1 / release-18.6.1 branches; the same-named tags are expected shortly and will pin the revision without any further change here.
  • staging/16/tde: the fork has no release-16.15 branch (only release-16.15.1), so the server _service now uses the same release-%!{PG_VERSION}.%!{PERCONA_PG_PATCH_VERSION} form as 17/18 (PERCONA_PG_PATCH_VERSION: 1 added to staging/16, QA psp-16.15 percona-version 16.15.1) and points at percona/postgres.
  • extras upgrade containers: OLD_SERVER_VERSION → 15.19 / 16.15 / 17.11.

Components (all upstream tags verified)

Component From → To Notes
haproxy 2.8.23 → 2.8.27 our 4 patches' targets untouched upstream (only doc/ changed)
patroni 4.1.3 → 4.1.5 only version.py in the packaging-relevant set
pgbackrest 2.58.0 → 2.59.0 new optional libsystemd meson feature left at auto; staging/18 literal Version: 2.58.0 → 1.0.0 placeholder like 14–17
pgvector 0.8.3 → 0.8.6 %files globs the SQL upgrade scripts
postgresql-common 290 → 293 ported the two debian/ changes into our overlays: pg_lsclusters guard in try_upgrade, new -dev.docs
etcd (ppg:common:deps) 3.5.30 → 3.5.33 literal revision + hand-written deb/rpm changelog entries
pg_oidc_validator (18) 1.0 → 1.1.0 revision was the release-1.0 branch; now the bare 1.1.0 tag. Makefile change adds only a non-default test target

pg_tde 2.2.1 → 2.2.2 (17, 18, 16/tde)

Upstream tagged plain 2.2.2 (not release-2.2.2), so the _service revision is the bare %!{PG_TDE_VERSION} and the release-(.*) versionrewrite is dropped. 2.2.2 brings the C++ KMIP client (libkmip git submodule, cmake). The fixes already proven on ppg:devel:18 (4e6353d, 074f56d) are carried into the three staging trees: submodules=enable, cmake build-dep, the meson-cpp-std-c2a quilt patch for bullseye's meson 0.56 (dry-run applied cleanly against the 2.2.2 meson.build), and gcc-c++ on SUSE. staging/18's control/control.in/dsc/spec are now byte-identical to devel/18.

Verification

Every touched _service resolved through percona_obs.common.load_macros():
REL_14_24, REL_15_19, REL_16_15, release-17.11.1, release-18.6.1, release-16.15.1, 2.2.2 ×3, v2.8.27, v4.1.5, release/2.59.0, v0.8.6, debian/293, v3.5.33, 1.1.0. tests/: 124 passed. No Python changes.

Not in this PR

  • devel/* macros (deliberately left alone).
  • QA's psp-16.15 entry expects pgbackrest 2.59.1 for the psp-16 repo line; our 16/tde links to staging/16's 2.59.0.

@rjd15372
ppg:staging: PG 14.24 / 15.19 / 16.15 / 17.11.1 / 18.6.1
1c4f14e 
Move every staging project to the PostgreSQL minors the QA fixtures
(Percona-QA/ppg-testing versions/ppg.py + settings.py) expect for the
next release train: 14.24, 15.19, 16.15, 17.11 and 18.6.

- PG_MINOR_VERSION / PG_PREV_MINOR_VERSION bumped in staging/14-18.
- Percona fork servers: PERCONA_PG_PATCH_VERSION 2 -> 1 in staging/17
  and 18 (QA percona-version 17.11.1 / 18.6.1). The fork has only the
  release-17.11.1 / release-18.6.1 *branches* so far; the tags of the
  same name are expected shortly, at which point the revision pins
  automatically without further change here.
- staging/16/tde: the fork has no release-16.15 branch (only
  release-16.15.1), so the server _service now uses the same
  release-%!{PG_VERSION}.%!{PERCONA_PG_PATCH_VERSION} form as 17/18
  (new PERCONA_PG_PATCH_VERSION: 1 in staging/16/macros.yaml, QA
  psp-16.15 percona-version 16.15.1) and points at percona/postgres
  instead of the Percona-Lab redirect.
- extras/containers upgrade pipeline: OLD_SERVER_VERSION follows the
  previous major's new minor (15.19 / 16.15 / 17.11).

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
@rjd15372
ppg:staging: haproxy 2.8.27, patroni 4.1.5, pgbackrest 2.59.0, pgvect…
de9deca 
…or 0.8.6, postgresql-common 293

Shared component versions the QA fixtures expect for the next train
(14.24 / 15.19 / 16.15 / 17.11 / 18.6). All are single macro bumps in
staging/macros.yaml; upstream tags verified to exist.

- haproxy 2.8.23 -> 2.8.27: our four debian patches target
  admin/systemd, contrib/halog and debian/dconv, none of which changed
  between the two tags (only doc/).
- patroni 4.1.3 -> 4.1.5: only patroni/version.py changed in the
  packaging-relevant set; no new Python dependencies.
- pgbackrest 2.58.0 -> 2.59.0: meson build unchanged for us; upstream
  adds an optional libsystemd feature (auto), left at its default.
  staging/18 still carried the literal 2.58.0 in the spec and dsc
  Version fields; set_version rewrites them at build time, so use the
  1.0.0 placeholder like staging/14-17.
- pgvector 0.8.3 -> 0.8.6: %files globs the SQL upgrade scripts.
- postgresql-common 290 -> 293: port the two debian/ changes from the
  Debian tags into our renamed overlay: the pg_lsclusters guard in
  try_upgrade (percona-postgresql.config) and the new
  postgresql-common-dev.docs (doc/postgresql-debian-packaging.md).

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
@rjd15372
ppg:common:deps: etcd 3.5.30 -> 3.5.33
ec3e25d 
QA fixtures expect etcd 3.5.33 for the next release train. The etcd
package pins its revision literally (no macro) and keeps hand-written
changelog entries in debian/changelog and the spec, so all three are
updated here. Aggregated into every ppg:staging:<N> project.

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
@rjd15372
ppg:staging: pg_tde 2.2.1 -> 2.2.2 (17, 18, 16/tde) with C++ KMIP bui…
ea0a98f 
…ld fixes

QA fixtures expect pg_tde 2.2.2 for 17.11 / 18.6 / psp-16.15. Upstream
tagged it as plain '2.2.2' (2.2.1 was 'release-2.2.1'), so the _service
revision is now the bare %!{PG_TDE_VERSION} tag and the
release-(.*) versionrewrite is dropped.

2.2.2 switches the KMIP client to the C++ libkmip library, pulled in as
a git submodule (subprojects/libkmip) and built with cmake. Carry the
fixes already proven on ppg:devel:18 (percona/main 4e6353d, 074f56d)
into the three staging trees:

- obs_scm: submodules=enable (staging/18 already had it).
- Debian: cmake in Build-Depends (control, control.in, debian.dsc) and
  the meson-cpp-std-c2a quilt patch — bullseye's meson 0.56.2 rejects
  cpp_std=c++20 (added in 0.57); c++2a is the same standard. Hunk
  context verified against the 2.2.2 meson.build (lines 142/171) with
  a dry-run apply.
- RPM: cmake BuildRequires; gcc-c++ on SUSE so meson does not pair
  clang++ (from the llvm BuildRequires) with gcc under -flto=auto.

staging/18's control/control.in/debian.dsc/spec are now byte-identical
to devel/18's; 17 and 16/tde received the equivalent edits in their own
spec/control layout.

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
@rjd15372
ppg:staging:18: pg_oidc_validator 1.0 -> 1.1.0
cd8dc03 
QA fixtures expect pg_oidc_validator 1.1.0 for 18.6. The _service
revision was release-%!{PG_OIDC_VALIDATOR_VERSION}, i.e. the
'release-1.0' *branch*; upstream tags are plain versions (1.0.0,
1.1.0), so the revision is now the bare %!{PG_OIDC_VALIDATOR_VERSION}
tag. The 1.0.0 -> 1.1.0 Makefile change only adds a non-default
oauth_conn_test target; the module build and %files are unaffected.
Spec Version literal replaced with the 1.0.0 placeholder that
set_version rewrites.

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
@rjd15372 rjd15372 added Ubuntu_24.04 RockyLinux_9 Debian_13 no-dep-cascade If used with `obs-sync*` labels, it prevents from packages that were not changed from being built obs-sync Trigger OBS sync push labels Aug 28, 2026
@github-actions

github-actions Bot commented Aug 28, 2026 •
edited
Loading

Copy link
Copy Markdown

OBS Build Check — ❌ Sync failed

The OBS sync step failed. See the workflow run for details.

Updated: 2026-08-28 14:24 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Debian_13 no-dep-cascade If used with `obs-sync*` labels, it prevents from packages that were not changed from being built obs-sync Trigger OBS sync push RockyLinux_9 Ubuntu_24.04

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@rjd15372