libsoup3: first autopatch config — package translations when %check is skipped, skip the 2 GiB logger test on 32-bit #1

Merged

eabdullin merged 1 commit from triage/fix-libsoup3-78 into a10s

2026-10-19 14:34:25 +00:00

almalinux-automation commented

2026-10-19 14:32:21 +00:00

Member

Automatically opened by releng-monitoring: the AlmaLinux build of libsoup3 failed, and the fix below changes what autopatch-tool applies to the upstream import.

Diagnosis

libsoup3-3.8.0-1.el10 fails in two separate, reproducible ways. Both build attempts of build 92345 failed the same way, so this is not a flaky failure. x86_64/aarch64 are not in the failed set.

riscv64 (task 469676): %install runs cleanly, and meson installs the po/*/LC_MESSAGES/libsoup-3.0.mo catalogs. The spec, however, puts %find_lang libsoup-3.0 inside %check, right after %meson_test. On riscv64 the %check scriptlet runs with an empty body (in the log, Executing(%check) is followed directly by Processing files). So %find_lang never runs and rpmbuild aborts with Could not open %files file .../libsoup-3.0.lang. This is a spec placement bug: %find_lang belongs in %install, so the build works whenever tests are skipped.
i686 (task 469611): %check fails 1 of 38 meson tests. logger-test case /logger/long-invalid-body-length hits GLib-FATAL-ERROR: ../glib/gmem.c:106: failed to allocate 2147483648 bytes and is killed by SIGTRAP. A 2 GiB allocation cannot succeed in a 32-bit address space, so on i686 this test case in 3.8.0 fails every time and does not point to a library bug. It needs to be skipped on 32-bit.

libsoup3 is not autopatch-managed, and it has no earlier triage history (this is the first failure, after the 3.6.6 to 3.8.0 update). The fix is a small downstream spec change.

What this changes

Files: config.yaml, files/1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch

This is the first autopatch config of libsoup3. Merging it puts the package under autopatch on a10s: every later upstream import gets this config applied and an .alma.N release, until the config is changed or the branch is deprecated.

The libsoup3 3.8.0 build fails in two ways. This first autopatch config fixes both.

riscv64: libsoup-3.0.lang is missing. The spec ran %find_lang libsoup-3.0 inside %check, after %meson_test. When %check is skipped, as it is on the riscv64 builders, %find_lang never runs. %files -f libsoup-3.0.lang then fails with "Could not open %files file". The config moves %find_lang libsoup-3.0 to the end of %install, after the libsoup.supp install line. It uses two replace actions, each with count: 1.

i686: logger-test aborts. 3.8.0 adds the test case /logger/long-invalid-body-length. Its server handler allocates G_MAXINT32 + 1 bytes (2 GiB), which a 32-bit process cannot do. GLib aborts with failed to allocate 2147483648 bytes and SIGTRAP. The new patch 1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch makes that one test case call g_test_skip() when sizeof (gsize) < 8. The other logger tests and the whole suite still run on every architecture, and 64-bit builds behave exactly as before.

The config also adds the .alma.1 release suffix and a changelog entry.

Patch-author notes: I checked the config with autopatch_validate_config, applied it to a fresh copy of rpms/ with autopatch, and read the spec diff. %find_lang is now in %install, and Patch 1000 is added and applied by %autosetup. rpmbuild -bp exited 0. I did not compile or run the test itself; the patch only adds an early g_test_skip/return when sizeof(gsize) < 8. The Release suffix was handled by autopatch-tool's %autorelease path: the log says it added the suffix, but the spec diff shows no change to the Release line.

How it was verified

In a fresh offline container, autopatch-tool validated the config and applied it to the upstream import, and rpmbuild -bp (%prep) passed on the result — independently of the agent that wrote it.

The spec after autopatch-tool applies the config

--- a/libsoup3.spec
+++ b/libsoup3.spec
@@ -14,6 +14,9 @@
 
 # https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/448 (simplified and corrected)
 Patch:   CVE-2025-4035.patch
+
+# AlmaLinux Patch
+Patch: 1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch
 
 BuildRequires: ca-certificates
 BuildRequires: gcc
@@ -79,10 +82,10 @@
 %meson_install
 install -m 644 -D tests/libsoup.supp %{buildroot}%{_datadir}/libsoup-3.0/libsoup.supp
 
+%find_lang libsoup-3.0
+
 %check
 %meson_test
-
-%find_lang libsoup-3.0
 
 %files -f libsoup-3.0.lang
 %license COPYING

What happens after you merge

Merging pushes this to a10s, which makes autopatch-tool re-run and tag changed/a10s/<nvr>.alma.N. releng-monitoring then rebuilds libsoup3 from that tag by itself — nothing else is needed from you.

Failed build: https://build.almalinux.org/build/92345
Upstream import: imports/c10s/libsoup3-3.8.0-1.el10

Automatically opened by releng-monitoring: the AlmaLinux build of `libsoup3` failed, and the fix below changes what autopatch-tool applies to the upstream import. ### Diagnosis libsoup3-3.8.0-1.el10 fails in two separate, reproducible ways. Both build attempts of build 92345 failed the same way, so this is not a flaky failure. x86_64/aarch64 are not in the failed set. 1) riscv64 (task 469676): %install runs cleanly, and meson installs the po/*/LC_MESSAGES/libsoup-3.0.mo catalogs. The spec, however, puts `%find_lang libsoup-3.0` inside %check, right after `%meson_test`. On riscv64 the %check scriptlet runs with an empty body (in the log, `Executing(%check)` is followed directly by `Processing files`). So %find_lang never runs and rpmbuild aborts with `Could not open %files file .../libsoup-3.0.lang`. This is a spec placement bug: %find_lang belongs in %install, so the build works whenever tests are skipped. 2) i686 (task 469611): %check fails 1 of 38 meson tests. logger-test case /logger/long-invalid-body-length hits `GLib-FATAL-ERROR: ../glib/gmem.c:106: failed to allocate 2147483648 bytes` and is killed by SIGTRAP. A 2 GiB allocation cannot succeed in a 32-bit address space, so on i686 this test case in 3.8.0 fails every time and does not point to a library bug. It needs to be skipped on 32-bit. libsoup3 is not autopatch-managed, and it has no earlier triage history (this is the first failure, after the 3.6.6 to 3.8.0 update). The fix is a small downstream spec change. ### What this changes Files: `config.yaml`, `files/1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch` **This is the first autopatch config of `libsoup3`.** Merging it puts the package under autopatch on `a10s`: every later upstream import gets this config applied and an `.alma.N` release, until the config is changed or the branch is deprecated. The libsoup3 3.8.0 build fails in two ways. This first autopatch config fixes both. **riscv64: `libsoup-3.0.lang` is missing.** The spec ran `%find_lang libsoup-3.0` inside `%check`, after `%meson_test`. When `%check` is skipped, as it is on the riscv64 builders, `%find_lang` never runs. `%files -f libsoup-3.0.lang` then fails with "Could not open %files file". The config moves `%find_lang libsoup-3.0` to the end of `%install`, after the `libsoup.supp` install line. It uses two `replace` actions, each with `count: 1`. **i686: logger-test aborts.** 3.8.0 adds the test case `/logger/long-invalid-body-length`. Its server handler allocates `G_MAXINT32 + 1` bytes (2 GiB), which a 32-bit process cannot do. GLib aborts with `failed to allocate 2147483648 bytes` and SIGTRAP. The new patch `1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch` makes that one test case call `g_test_skip()` when `sizeof (gsize) < 8`. The other logger tests and the whole suite still run on every architecture, and 64-bit builds behave exactly as before. The config also adds the `.alma.1` release suffix and a changelog entry. Patch-author notes: I checked the config with autopatch_validate_config, applied it to a fresh copy of rpms/ with autopatch, and read the spec diff. %find_lang is now in %install, and Patch 1000 is added and applied by %autosetup. `rpmbuild -bp` exited 0. I did not compile or run the test itself; the patch only adds an early `g_test_skip`/return when sizeof(gsize) < 8. The Release suffix was handled by autopatch-tool's %autorelease path: the log says it added the suffix, but the spec diff shows no change to the Release line. ### How it was verified In a fresh offline container, autopatch-tool validated the config and applied it to the upstream import, and `rpmbuild -bp` (`%prep`) passed on the result — independently of the agent that wrote it. <details><summary>The spec after autopatch-tool applies the config</summary> ```diff --- a/libsoup3.spec +++ b/libsoup3.spec @@ -14,6 +14,9 @@ # https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/448 (simplified and corrected) Patch: CVE-2025-4035.patch + +# AlmaLinux Patch +Patch: 1000-logger-test-skip-long-invalid-body-length-on-32-bit.patch BuildRequires: ca-certificates BuildRequires: gcc @@ -79,10 +82,10 @@ %meson_install install -m 644 -D tests/libsoup.supp %{buildroot}%{_datadir}/libsoup-3.0/libsoup.supp +%find_lang libsoup-3.0 + %check %meson_test - -%find_lang libsoup-3.0 %files -f libsoup-3.0.lang %license COPYING ``` </details> ### What happens after you merge Merging pushes this to `a10s`, which makes autopatch-tool re-run and tag `changed/a10s/<nvr>.alma.N`. releng-monitoring then rebuilds `libsoup3` from that tag by itself — nothing else is needed from you. Failed build: https://build.almalinux.org/build/92345 Upstream import: `imports/c10s/libsoup3-3.8.0-1.el10`

almalinux-automation added 1 commit

2026-10-19 14:32:21 +00:00

libsoup3: first autopatch config — package translations when %check is skipped, skip the 2 GiB logger test on 32-bit 3aaf3eb9b5