Skip to content

Conversation

@travier
Copy link
Member

@travier travier commented Sep 26, 2025

See: https://bugzilla.redhat.com/show_bug.cgi?id=2372978
See: rpm-software-management/libdnf@8eadf44
Should fix: #5494


I have not tested this change yet.

It looks like dependabot stopped updating this submodule around July (edit: last year). I don't know why.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the libdnf submodule to commit 8eadf44 to resolve an issue with modular dependency handling. The change is a simple dependency bump. However, as noted in the description, this change has not yet been tested. Given that libdnf is a core dependency, it is critical to perform thorough testing to confirm that it resolves the intended issue and does not introduce any regressions before merging.

@travier
Copy link
Member Author

travier commented Sep 26, 2025

C9S failure is due to an older librepo:

-- Checking for module 'librepo>=1.18.0'
  --   Package dependency requirement 'librepo >= 1.18.0' could not be satisfied.
  Package 'librepo' has version '1.14.5', required version is '>= 1.18.0'
  -- Configuring incomplete, errors occurred!

From rpm-software-management/libdnf@5449211

@travier
Copy link
Member Author

travier commented Sep 26, 2025

Code style issue is:

16:36:21  error: Commit message for 3313d51d774a81b490060dca83e49a6444127c7c changes a submodule, but does not match regex Update submodule: libdnf

Will be fixed in the next push.

@travier
Copy link
Member Author

travier commented Sep 26, 2025

C9S failure is due to an older librepo:

-- Checking for module 'librepo>=1.18.0'
  --   Package dependency requirement 'librepo >= 1.18.0' could not be satisfied.
  Package 'librepo' has version '1.14.5', required version is '>= 1.18.0'
  -- Configuring incomplete, errors occurred!

From rpm-software-management/libdnf@5449211

That probably means that we need to branch rpm-ostree for C9S with a libdnf bumped to the commit prior to this one.

@travier
Copy link
Member Author

travier commented Sep 26, 2025

FCOS E2E failure looks weird:

Importing rpm-md...done
rpm-md repo 'fedora-coreos-pool'; generated: 2025-09-26T16:26:35Z solvables: 57868
rpm-md repo 'fedora'; generated: 2025-04-09T11:06:59Z solvables: 76879
rpm-md repo 'fedora-updates'; generated: 2025-09-26T01:02:13Z solvables: 24241
error: Installing packages: Packages not found: /usr/share/makedumpfile
failed to execute cmd-fetch: exit status 1

@cgwalters
Copy link
Member

Yes this came up previously in #5140 (comment)

I'm OK to branch for rhel9.

@cgwalters cgwalters mentioned this pull request Sep 26, 2025
@cgwalters
Copy link
Member

#5500 will track the branching.

@travier
Copy link
Member Author

travier commented Oct 20, 2025

/retest

1 similar comment
@travier
Copy link
Member Author

travier commented Oct 20, 2025

/retest

@travier
Copy link
Member Author

travier commented Oct 20, 2025

🤔

Importing rpm-md...done
rpm-md repo 'fedora-coreos-pool'; generated: 2025-10-19T20:39:08Z solvables: 60869
rpm-md repo 'fedora'; generated: 2025-04-09T11:06:59Z solvables: 76879
rpm-md repo 'fedora-updates'; generated: 2025-10-20T00:59:12Z solvables: 25415
error: Installing packages: Packages not found: /usr/share/makedumpfile

@travier
Copy link
Member Author

travier commented Oct 21, 2025

Build-chunked-oci failed on:

+ podman run --rm --privileged --security-opt=label=disable -v /var/lib/containers:/var/lib/containers -v /var/tmp:/var/tmp -v /home/runner/work/rpm-ostree/rpm-ostree/tests/build-chunked-oci:/output localhost/builder rpm-ostree compose build-chunked-oci --bootc --from quay.io/centos-bootc/centos-bootc:stream9 --output containers-storage:localhost/chunked-ppc64le --label foo=bar
rpm-ostree: error while loading shared libraries: librpm.so.10: cannot open shared object file: No such file or directory

@castrojo
Copy link

We're shipping this in Aurora, Bazzite, and Bluefin as of 15 hours ago: ublue-os/main#1600

We've had multiple confirmed users with locally layered packages that this fixes the issue. We'll have at least a few more thousand users over the course of the next few days to bang on it.

@cgwalters
Copy link
Member

Thanks, we'll get this reviewed and merged soon!

@cgwalters

This comment was marked as off-topic.

@cgwalters
Copy link
Member

OK so filelists. Holy cow. As linked from #5522 this pulls in https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists

Except that actually because we had an old libdnf at the time, we basically implemented that behavior in a different way via 340f2aa which has its own knobs and configuration.

The complexity here comes in that basically I think what we want is to always enable filelists on the build side, and not the client side, and we need to work through how the libdnf change affects all the code paths invoking it.

@cgwalters
Copy link
Member

Hummm....I think some of this is actually just quay.io/fedora/fedora-coreos:testing-devel revving to Fedora 43 just as of ~yesterday

@cgwalters
Copy link
Member

OK first we need to land #5523

travier and others added 2 commits October 30, 2025 21:02
As of libdnf 0.73.0 (commit f1ffeed5a75e902adf356c6cdfd926d6653b00ce),
filelists metadata is disabled by default to optimize package resolution
performance. However, this breaks file dependency resolution when packages
specify file paths (e.g., /usr/share/makedumpfile) as dependencies.

The previous code only explicitly disabled filelists when the
SKIP_FILELISTS flag was set, relying on the old default of filelists
being enabled. With the new libdnf default, we need to explicitly enable
filelists when NOT skipping them.

Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters
Copy link
Member

OK now down to just one failure

 Oct 31 02:07:10 qemu0 kola-runext-layering-useradd[2210]: + grep testdaemon /etc/passwd /usr/lib/passwd
Oct 31 02:07:10 qemu0 kola-runext-layering-useradd[2210]: + rpm-ostree install /var/opt/kola/extdata/rpm-repos/0/packages/x86_64/rpmostree-openvpn-1.0-1.x86_64.rpm
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]: Checking out tree 7cb290a...done
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]: No enabled rpm-md repositories.
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]: Importing rpm-md...done
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]: Resolving dependencies...done
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]: error: Could not depsolve transaction; 1 problem detected:
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]:  Problem: conflicting requests
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]:   - nothing provides group(rpmostree-openvpn) needed by rpmostree-openvpn-1.0-1.x86_64 from @commandline
Oct 31 02:07:11 qemu0 kola-runext-layering-useradd[2491]:   - nothing provides user(rpmostree-openvpn) needed by rpmostree-openvpn-1.0-1.x86_64 from @commandline 

Yet what has me baffled is this same test passes in Jenkins. There must be some environmental difference leaking in? I wonder if this is skew in the RPM version used at build time?

@cgwalters
Copy link
Member

For now
/override ci/prow/fcos-e2e

@openshift-ci
Copy link

openshift-ci bot commented Oct 31, 2025

@cgwalters: Overrode contexts on behalf of cgwalters: ci/prow/fcos-e2e

Details

In response to this:

For now
/override ci/prow/fcos-e2e

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@cgwalters cgwalters enabled auto-merge October 31, 2025 15:20
Copy link
Member

@jmarrero jmarrero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cgwalters cgwalters merged commit d90f633 into coreos:main Oct 31, 2025
20 checks passed
@travier
Copy link
Member Author

travier commented Nov 13, 2025

Thanks for all the work fixing this one.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fedora 43 Kinoite Beta failed to add subkeys for google-chrome

4 participants