Description of problem: Version-Release number of selected component (if applicable): With libmodulemd-1.6.0-1.fc28 installed (from updates-testing), there is nothing shown when running "dnf module list" How reproducible: Steps to Reproduce: 1. install libmodulemd-1.6.0-1.fc28 from updates-testing Actual results: $> dnf module list Nothing to show. Expected results: $> dnf module list root@nb-georg:/usr/lib/python3.6/site-packages# dnf module list Letzte Prüfung auf abgelaufene Metadaten: vor 0:20:11 am Sa 21 Jul 2018 19:40:04 CEST. Fedora Modular 28 - x86_64 Name Stream Version Profiles [modules] Fedora Modular 28 - x86_64 - Updates Name Stream Version Profiles [lots of modules] Hint: [d]efault, [e]nabled, [i]nstalled, [l]ocked Additional info: Downgrading libmodulemd to libmodulemd-1.5.2-1.fc28 fixes the problem
Same problem with libmodulemd-1.6.1 The following upstream patch fixes the issue: https://github.com/rpm-software-management/dnf/commit/cd024ea9704612331a9d5deac1012c4fd052cdb6
A newer release of dnf was built in koji for Fedora 28 which fixes this for me (with libmodulemd-1.6.1-1.fc28): https://koji.fedoraproject.org/koji/buildinfo?buildID=1087098 Is there a particular reason why this hasn't been submitted as an update yet?
Ping?
I just found this also, having seen it reported by omajid on IRC. In that discussion at least, it was reported that various other module functions also do not work with the updated libmodulemd. This seems like a critical bug for modularity, nominating it as a prioritizedbug.
> In that discussion at least, it was reported that various other module functions also do not work with the updated libmodulemd. The problem is that libmodulemd 1.6 has an (accidental, I think) API break and Modulemd.Module.new_all_from_string_ext() started returning Modulemd.ModuleStream objects. The end result is that dnf is unable to load any module data from repositories - so yes, no module functionality will work correctly, until either dnf or libmodulemd is fixed. (dnf to use an alternate loading function, as the 2.7.5-15 update does, or libmodulemd to do the ModuleStream=>Module conversion for new_all_from_string_ext() that it does in other loading functions.)
Argh, yeah this is an accidental API break. I will get it fixed up by tomorrow and get a 1.6.3 release out to revert the breakage. Reassigning to libmodulemd.
I've got a scratch-build (x86_64 only) that I believe should resolve the issue, but as I'm at a conference and don't have the spare cycles to do proper testing, I'd appreciate it if someone else could take it and make sure it works before I push it to an official build: https://koji.fedoraproject.org/koji/taskinfo?taskID=28940467
I can't reproduce this issue with today's Rawhide using libmodulemd-1.6.1-2.fc29.x86_64 dnf-3.0.4-1.fc29.noarch libdnf-0.16.1-2.fc29.x86_64 libsolv-0.6.34-6.fc29.x86_64 Can you identify which versions of things you see this bug with? The code definitely needed to be fixed (the API-break was unintentional), but if I can't reproduce this specific error, I can't be certain I fixed it.
I am not using rawhide, the bug is filed aginst fedora 28. The problem occurs with: libmodulemd-1.6.1-1.fc28.x86_64 dnf-2.7.5-12.fc28.noarch python3-dnf-2.7.5-12.fc28.noarch libdnf-0.11.1-3.fc28.x86_64 libsolv-0.6.34-3.fc28.x86_64 As mentioned above in comment #1, newer upstream dnf-2-modularity already adopted the libmodulemd change, as did the master branch (multiple "use non-deprecated libmodulemd function" commits. But the dnf packages are still on an older commit. In the fedora dnf git repo, there are already commits referencing the newer version (dnf-2.7.5-15.fc28.noarch). I see builds for it in koji, but not in bodhi. And this is not in updates or updates-testing. Since these builds exist, I did not file the bug against libmodulemd, but against dnf.
I'd say that the fact that the newer dnf versions work is more coincidental than an intentional change to fix this particular issue - they are using a different module loading API which didn't have the issue. I've now tested both Stephen's scratch RPM and the equivalent patch in https://github.com/fedora-modularity/libmodulemd/pull/79 with the F28 dnf and they both work fine.
(In reply to Georg Müller from comment #9) > I am not using rawhide, the bug is filed aginst fedora 28. > > The problem occurs with: > libmodulemd-1.6.1-1.fc28.x86_64 > dnf-2.7.5-12.fc28.noarch > python3-dnf-2.7.5-12.fc28.noarch > libdnf-0.11.1-3.fc28.x86_64 > libsolv-0.6.34-3.fc28.x86_64 > > > As mentioned above in comment #1, newer upstream dnf-2-modularity already > adopted the libmodulemd change, as did the master branch (multiple "use > non-deprecated libmodulemd function" commits. But the dnf packages are still > on an older commit. > > In the fedora dnf git repo, there are already commits referencing the newer > version (dnf-2.7.5-15.fc28.noarch). I see builds for it in koji, but not in > bodhi. And this is not in updates or updates-testing. > > Since these builds exist, I did not file the bug against libmodulemd, but > against dnf. Thanks, I missed that you were reporting on F28. I can reproduce it there and I've verified that https://koji.fedoraproject.org/koji/taskinfo?taskID=28944087 (built for F28) resolves the issue. I'll get that in an update immediately.
libmodulemd-1.6.2-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3ff9de7496
libmodulemd-1.6.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-27078d921e
libmodulemd-1.6.2-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b5094f1689
libmodulemd-1.6.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-27078d921e
Thanks for the quick fix, sgallagh.
libmodulemd-1.6.2-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
libmodulemd-1.6.2-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b5094f1689
*** Bug 1612733 has been marked as a duplicate of this bug. ***
libmodulemd-1.6.2-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
libmodulemd-1.6.2-2.el7.1 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9b8c37c219
libmodulemd-1.6.2-2.el7.1 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9b8c37c219
libmodulemd-1.6.2-2.el7.1 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.