Description of problem: dnf complains about a conflict with dwm and stratis, which it can't even find, and libgit2, which is available but not installed on my system. Originally saw issue with 'dnf list updates', narrowed down to help debugging. glibc included in the query to demonstrate that dnf *is* able to list installed/available packages that are actually installed. 21:13:22 0 [~] dnf --disableexcludes=all list dwm libgit2 stratis glibc Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by libgit2:0.27:20180926125215:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by dwm:6.1:20180831122920:a5b0195c-0.x86_64 Installed Packages glibc.x86_64 2.28.9000-8.fc30 @rawhide Available Packages glibc.i686 2.28.9000-8.fc30 rawhide libgit2.i686 0.27.4-1.fc29 rawhide libgit2.x86_64 0.27.4-1.fc29 rawhide 21:16:21 0 [~] Version-Release number of selected component (if applicable): dnf-3.6.1-2.fc30.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please can you try reproduce the issue with upstream dnf? Please enable two copr repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly), and (dnf copr enable jmracek/dnf-upstream). From jmracek/dnf-upstream please install dnf-3.6.1-1.git.8585.35492e2.* and libsolv-0.6.35-6. Repo rpmsoftwaremanagement/dnf-nightly is required for dependencies. Thanks a lot for cooperation
I am sorry my comment was incorrect. The problems report issues about modules not rpms.
I create a patch that should improve error message https://github.com/rpm-software-management/libdnf/pull/605.
That fixes the lack of clarity. But it doesn't fix the underlying problem - stratis and dwm modules aren't installed *either*. # dnf module list stratis libgit2 dwm Fedora - Modular Rawhide - Developmental packages for the next Fedora release 12 kB/s | 14 kB 00:01 Fedora - Rawhide - Developmental packages for the next Fedora release 37 kB/s | 14 kB 00:00 google-chrome-beta 920 B/s | 951 B 00:01 google-chrome-unstable 27 kB/s | 951 B 00:00 google-chrome 27 kB/s | 951 B 00:00 google-earth 39 kB/s | 1.3 kB 00:00 google-talkplugin 23 kB/s | 951 B 00:00 RPM Fusion for Fedora 29 - Free - Test Updates 2.6 kB/s | 2.9 kB 00:01 RPM Fusion for Fedora 29 - Free 29 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 29 - Nonfree - Updates 1.8 kB/s | 3.0 kB 00:01 RPM Fusion for Fedora 29 - Nonfree 4.9 kB/s | 3.0 kB 00:00 skype (stable) 2.0 kB/s | 2.9 kB 00:01 skype (unstable) 15 kB/s | 2.9 kB 00:00 slack 393 B/s | 1.0 kB 00:02 Fedora 29 - x86_64 - VirtualBox 2.2 kB/s | 2.9 kB 00:01 Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by libgit2:0.27:20180926125215:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by dwm:6.1:20180831122920:a5b0195c-0.x86_64 Fedora - Modular Rawhide - Developmental packages for the next Fedora release Name Stream Profiles Summary dwm 6.0 user, default [d] Dynamic window manager for X dwm 6.1 [d] user, default [d] Dynamic window manager for X dwm latest user, default [d] Dynamic window manager for X libgit2 0.26 Library implementation of Git libgit2 0.27 [d] Library implementation of Git stratis 1 [d] default [d] Stratis Storage stratis master default Stratis Storage Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled You see an [i] anyplace there? I sure don't... There's both module and rpm flavors of libgit2, neither of which are on # dnf module list libgit2 Last metadata expiration check: 0:29:38 ago on Mon 08 Oct 2018 11:35:16 AM EDT. Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by libgit2:0.27:20180926125215:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by dwm:6.1:20180831122920:a5b0195c-0.x86_64 Fedora - Modular Rawhide - Developmental packages for the next Fedora release Name Stream Profiles Summary libgit2 0.26 Library implementation of Git libgit2 0.27 [d] Library implementation of Git Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled # dnf list libgit2 Last metadata expiration check: 0:29:47 ago on Mon 08 Oct 2018 11:35:16 AM EDT. Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by libgit2:0.27:20180926125215:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by dwm:6.1:20180831122920:a5b0195c-0.x86_64 Available Packages libgit2.i686 0.27.4-1.fc29 rawhide libgit2.x86_64 0.27.4-1.fc29 rawhid So these 3 objects aren't on my system in either RPM or module form. Or is this thing trying to tell me that dwm, libgit2, and stratis will be forcibly installed because of some prereq chain from Hell if 'module(platform:f30)' ever makes an appearance? If so, it would be nice to know why - no amount of 'repoquery --provides, --requires, --whatrequires' explains what's wanting to install these 3 packages/modules/whatever.
dnf-plugins-core-4.0.0-1.fc29 dnf-4.0.4-1.fc29 libdnf-0.22.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-1.fc29, libdnf-0.22.0-1.fc29 has been pushed to the Fedora 29 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-2789f6b6e7
dnf-4.0.4-1.fc29 dnf-plugins-core-4.0.0-2.fc29 libdnf-0.22.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libdnf-0.22.0-2.fc29 has been pushed to the Fedora 29 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-2789f6b6e7
anaconda-29.24.6-1.fc29 dnf-4.0.4-1.fc29 dnf-plugins-core-4.0.0-2.fc29 libblockdev-2.20-2.fc29 libdnf-0.22.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 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-2789f6b6e7
anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Still seeing it: dnf update Fedora - Modular Rawhide - Developmental packages for the next Fedora release 12 kB/s | 13 kB 00:01 Fedora - Rawhide - Developmental packages for the next Fedora release 94 kB/s | 14 kB 00:00 google-chrome-beta 26 kB/s | 951 B 00:00 google-chrome-unstable 29 kB/s | 951 B 00:00 google-chrome 28 kB/s | 951 B 00:00 google-earth 39 kB/s | 1.3 kB 00:00 google-talkplugin 25 kB/s | 951 B 00:00 RPM Fusion for Fedora 29 - Free - Test Updates 4.0 kB/s | 2.9 kB 00:00 RPM Fusion for Fedora 29 - Free 5.0 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 29 - Nonfree - Updates 1.9 kB/s | 3.0 kB 00:01 RPM Fusion for Fedora 29 - Nonfree 4.7 kB/s | 3.0 kB 00:00 skype (stable) 2.4 kB/s | 2.9 kB 00:01 skype (unstable) 15 kB/s | 2.9 kB 00:00 slack 394 B/s | 1.0 kB 00:02 Fedora 29 - x86_64 - VirtualBox 118 kB/s | 2.9 kB 00:00 Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:20181008044824:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:20181006095357:a5b0195c-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f30) needed by module dwm:6.1:20180831122920:a5b0195c-0.x86_64 Dependencies resolved. It's still complaining about these 4 modules which aren't even installed on my system: 14:16:23 0 [/etc]1 dnf module list installed Last metadata expiration check: 0:03:23 ago on Mon 22 Oct 2018 02:13:04 PM EDT. Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20180927214347:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:20181008044824:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:20181006095357:a5b0195c-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f30) needed by module dwm:6.1:20180831122920:a5b0195c-0.x86_64 Error: No matching Modules to list 14:16:28 1 [/etc]1
It sounds like that problem here is that you have rawhide metadata but platform module is not platform:f30. The content of "/etc/os-release" could help. Probably this a problem of infrastructure, but I think it requires investigation from modular people site. Please could you help here?
cat /etc/os-release NAME=Fedora VERSION="29 (Workstation Edition)" ID=fedora VERSION_ID=29 PLATFORM_ID="platform:f29" PRETTY_NAME="Fedora 29 (Workstation Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:29" HOME_URL="https://fedoraproject.org/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=rawhide PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation Probably due to fedora-release being stuck at 29 because rpmfusion-free-release is also still at 29. Aha. Found the actual problem - despite my thinking that there weren't any modules on my system, /etc/yum.repos.d/fedora-rawhide-modular.repo had enabled=1 for [rawhide-modular'. Disabled that and it shut right up.
Is this related or should I open a new bug? 4.19.10-300.fc29.x86_64 dnf module list libgit2 Last metadata expiration check: 0:02:36 ago on Thu 03 Jan 2019 02:39:39 PM EST. Modular dependency problem: Problem: module bat:latest:20181106000712:7fdbb362-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed - module libgit2:0.27:20180926125215:6c81f848-0.x86_64 conflicts with module(libgit2:0.26) provided by libgit2:0.26:20180928101841:6c81f848-0.x86_64 - module libgit2:0.26:20180928101841:6c81f848-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:20180926125215:6c81f848-0.x86_64 - module libgit2:0.26:20180928101841:6c81f848-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:20181028172505:6c81f848-0.x86_64 - module libgit2:0.27:20181028172505:6c81f848-0.x86_64 conflicts with module(libgit2:0.26) provided by libgit2:0.26:20180928101841:6c81f848-0.x86_64 - conflicting requests Fedora Modular 29 - x86_64 Name Stream Profiles Summary libgit2 0.26 [e] Library implementation of Git libgit2 0.27 Library implementation of Git Fedora Modular 29 - x86_64 - Updates Name Stream Profiles Summary libgit2 0.26 [e] Library implementation of Git libgit2 0.27 Library implementation of Git Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled cat /etc/os-release NAME=Fedora VERSION="29 (Server Edition)" ID=fedora VERSION_ID=29 VERSION_CODENAME="" PLATFORM_ID="platform:f29" PRETTY_NAME="Fedora 29 (Server Edition)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:29" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=29 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=29 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Server Edition" VARIANT_ID=server
(In reply to RobbieTheK from comment #16) > Is this related or should I open a new bug? > > 4.19.10-300.fc29.x86_64 > > dnf module list libgit2 > Last metadata expiration check: 0:02:36 ago on Thu 03 Jan 2019 02:39:39 PM > EST. > Modular dependency problem: > > Problem: module bat:latest:20181106000712:7fdbb362-0.x86_64 requires > module(libgit2:0.27), but none of the providers can be installed > - module libgit2:0.27:20180926125215:6c81f848-0.x86_64 conflicts with > module(libgit2:0.26) provided by > libgit2:0.26:20180928101841:6c81f848-0.x86_64 > - module libgit2:0.26:20180928101841:6c81f848-0.x86_64 conflicts with > module(libgit2:0.27) provided by > libgit2:0.27:20180926125215:6c81f848-0.x86_64 > - module libgit2:0.26:20180928101841:6c81f848-0.x86_64 conflicts with > module(libgit2:0.27) provided by > libgit2:0.27:20181028172505:6c81f848-0.x86_64 > - module libgit2:0.27:20181028172505:6c81f848-0.x86_64 conflicts with > module(libgit2:0.26) provided by > libgit2:0.26:20180928101841:6c81f848-0.x86_64 > - conflicting requests > Fedora Modular 29 - x86_64 > Name Stream > Profiles Summary > > libgit2 0.26 [e] > Library implementation of Git > libgit2 0.27 > Library implementation of Git > > Fedora Modular 29 - x86_64 - Updates > Name Stream > Profiles Summary > > libgit2 0.26 [e] > Library implementation of Git > libgit2 0.27 > Library implementation of Git > > Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled > > > cat /etc/os-release > NAME=Fedora > VERSION="29 (Server Edition)" > ID=fedora > VERSION_ID=29 > VERSION_CODENAME="" > PLATFORM_ID="platform:f29" > PRETTY_NAME="Fedora 29 (Server Edition)" > ANSI_COLOR="0;34" > LOGO=fedora-logo-icon > CPE_NAME="cpe:/o:fedoraproject:fedora:29" > HOME_URL="https://fedoraproject.org/" > DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f29/system- > administrators-guide/" > SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" > BUG_REPORT_URL="https://bugzilla.redhat.com/" > REDHAT_BUGZILLA_PRODUCT="Fedora" > REDHAT_BUGZILLA_PRODUCT_VERSION=29 > REDHAT_SUPPORT_PRODUCT="Fedora" > REDHAT_SUPPORT_PRODUCT_VERSION=29 > PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" > VARIANT="Server Edition" > VARIANT_ID=server This is a new bug. It's due to DNF not differentiating properly between "default" (meaning available without specifying a stream) and "enabled" (meaning that the stream has been selected). Closing this bug as the original issue should be resolved now.
this still occurs to me when attempting to upgrade fc29 to fc30: $ sudo -E dnf --releasever=30 distro-sync unitedrpms 30 - x86_64 92 B/s | 525 B 00:05 unitedrpms 30 - x86_64 1.7 MB/s | 1.8 kB 00:00 Importing GPG key 0x5250AEF3: Userid : "The UnitedRPMs Project (Key for UnitedRPMs infrastructure) <unitedrpms>" Fingerprint: 36EB EB08 D346 B0A8 5B58 E140 EE78 8F49 5250 AEF3 From : /etc/pki/rpm-gpg/URPMS-GPG-PUBLICKEY-Fedora-24 Is this ok [y/N]: y unitedrpms 30 - x86_64 136 kB/s | 1.1 MB 00:07 Copr repo for firefox-nightly owned by eclipseo 37 kB/s | 192 kB 00:05 Copr repo for Signal-Desktop owned by luminoso 8.5 kB/s | 15 kB 00:01 Copr repo for firefox-nightly owned by sramanujam 991 B/s | 3.3 kB 00:03 Copr repo for firefox-nightly owned by wanzenbug 1.3 kB/s | 2.9 kB 00:02 brave-browser-dev 17 kB/s | 1.4 kB 00:00 Failed to synchronize cache for repo 'brave-browser-dev' brave-browser 18 kB/s | 1.4 kB 00:00 Failed to synchronize cache for repo 'brave-browser' Fedora Modular 30 - x86_64 457 kB/s | 2.5 MB 00:05 Fedora Modular 30 - x86_64 - Updates 218 B/s | 257 B 00:01 Fedora 30 - x86_64 - Test Updates 2.6 MB/s | 6.8 MB 00:02 Fedora 30 - x86_64 - Updates 210 B/s | 257 B 00:01 Fedora 30 - x86_64 609 kB/s | 54 MB 01:30 Failed to synchronize cache for repo 'fedora' Error: Failed to synchronize cache for repo 'fedora' [asus@e403na ~]$ sudo -E dnf --releasever=30 distro-sync brave-browser-dev 16 kB/s | 1.4 kB 00:00 Failed to synchronize cache for repo 'brave-browser-dev' brave-browser 18 kB/s | 1.4 kB 00:00 Failed to synchronize cache for repo 'brave-browser' Fedora 30 - x86_64 756 kB/s | 54 MB 01:13 RPM Fusion for Fedora 30 - Free - Updates 38 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-free-updates' RPM Fusion for Fedora 30 - Free 223 kB/s | 71 kB 00:00 Failed to synchronize cache for repo 'rpmfusion-free' ZFS on Linux for Fedora 28 2.0 kB/s | 2.9 kB 00:01 ZFS on Linux for Fedora 28 - Testing 3.9 kB/s | 2.9 kB 00:00 Ignoring repositories: brave-browser-dev, brave-browser, rpmfusion-free-updates, rpmfusion-free Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190304181436:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:3020190305101905:a5b0195c-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f30) needed by module ninja:latest:3020190304180949:a5b0195c-0.x86_64 Problem 5: conflicting requests - nothing provides module(platform:f30) needed by module meson:latest:3020190304180854:36245242-0.x86_64 Problem 6: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 Problem 7: conflicting requests - nothing provides module(platform:f30) needed by module gimp:2.10:3020190304180601:a5b0195c-0.x86_64 Problem 8: conflicting requests - nothing provides module(platform:f30) needed by module fish:3:3020190301191132:602da195-0.x86_64 Problem 9: conflicting requests - nothing provides module(platform:f30) needed by module exa:latest:3020190305101925:e50d0d19-0.x86_64 Problem 10: conflicting requests - nothing provides module(platform:f30) needed by module dwm:6.1:3020190304180429:a5b0195c-0.x86_64 Problem 11: conflicting requests - nothing provides module(platform:f30) needed by module bat:latest:3020190305101836:e50d0d19-0.x86_64 Problem 12: conflicting requests - nothing provides module(platform:f30) needed by module avocado:stable:3020190304180315:a5b0195c-0.x86_64 Error: Problem 1: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 2: package blender-1:2.79b-10.fc30.x86_64 requires libboost_locale.so.1.66.0()(64bit), but none of the providers can be installed - problem with installed package blender-1:2.79b-9.fc29.x86_64 - boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository - blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade repository Problem 3: package openshot-2.4.3-3.gitb90557d.fc30.noarch requires pygoocanvas, but none of the providers can be installed - problem with installed package openshot-2.4.3-3.gitb90557d.fc29.noarch - pygoocanvas-0.14.1-24.fc29.x86_64 does not belong to a distupgrade repository - openshot-2.4.3-3.gitb90557d.fc29.noarch does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) $ cat /etc/os-release NAME=Fedora VERSION="29 (Workstation Edition)" ID=fedora VERSION_ID=29 VERSION_CODENAME="" PLATFORM_ID="platform:f29" PRETTY_NAME="Fedora 29 (Workstation Edition)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:29" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=29 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=29 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation
This is happening again: $ repoquery --repo=rawhide what Last metadata expiration check: 2:33:08 ago on Tue 13 Aug 2019 02:47:29 PM CEST. Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module exa:latest:3020190721165838:a23e773d-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module fd-find:rolling:3020190722174030:a23e773d-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:3020190803131619:a23e773d-0.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
I also get this when running reposync for a target Fedora version different from the one I'm running, e.g. syncing updates for f29 on my f30 machine: $ dnf reposync --repoid fedora-29-updates-i386 -p /srv/nb/distros/fc29 Fedora 29 - i386 - Updates 19 kB/s | 5.4 kB 00:00 Modular dependency problem: Problem: conflicting requests - nothing provides module(platform:f30) needed by module gimp:2.10:3020190614215426:a5b0195c-0.x86_64 ...
Could you please provide at least a workaround? $ repoquery --repo=rawhide{,-source} --whatrequires python2-scour Modular dependency problems: Problém 1: conflicting requests - nothing provides module(platform:f30) needed by module exa:latest:3020190721165838:a23e773d-0.x86_64 Problém 2: conflicting requests - nothing provides module(platform:f30) needed by module fd-find:rolling:3020190722174030:a23e773d-0.x86_64 Problém 3: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 Problém 4: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:3020190803131619:a23e773d-0.x86_64 inkscape-0:0.92.4-9.fc32.x86_64
(In reply to Miro Hrončok from comment #23) > Could you please provide at least a workaround? > > $ repoquery --repo=rawhide{,-source} --whatrequires python2-scour > Modular dependency problems: > > Problém 1: conflicting requests > - nothing provides module(platform:f30) needed by module > exa:latest:3020190721165838:a23e773d-0.x86_64 > Problém 2: conflicting requests > - nothing provides module(platform:f30) needed by module > fd-find:rolling:3020190722174030:a23e773d-0.x86_64 > Problém 3: conflicting requests > - nothing provides module(platform:f30) needed by module > libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 > Problém 4: conflicting requests > - nothing provides module(platform:f30) needed by module > ripgrep:latest:3020190803131619:a23e773d-0.x86_64 > inkscape-0:0.92.4-9.fc32.x86_64 This is a different and unrelated problem. The issue is that Rawhide's mass-rebuild of modules for the Branch point failed and most of those modules don't have an upgrade path in the Rawhide repo now. So those issues are actually legitimate failures that *should* be reported. See https://pagure.io/releng/issue/8664 for details about the Rawhide situation.
I'm querying ursine rawhide repositories. The problems are no concern of my query and I should not be bothered with them with this query. The title says: dnf complains about conflicts with non-installed and non-existent RPMs OTOH If I query the modular repos, I get nothing at all + similar problem: $ repoquery --repo=rawhide-modular -a Modular dependency problem: Problém: conflicting requests - nothing provides module(platform:f32) needed by module meson:latest:3220190826183302:737d6d13-0.x86_64 - nothing provides module(ninja) needed by module meson:latest:3220190826183302:737d6d13-0.x86_64 And that is indeed a different problem you are describing.
The issue is that available provider of module-platform in rawhide repository (probably fedora-release package) provides platform of rawhide. DNF according to specification from modularity team detect module-platform from the latest available provider of system release. The change was required for system upgrade. Workaround: set in rawhide.repo file: excludepkgs=<system-release providers> <system-release providers> = dnf repoquery --whatprovides system-release --repo=rawhide Because the issue will appear and appear and so on I would like to open discuss about the issue. What do you think?
I create an issue https://pagure.io/modularity/issue/150 to put the issue on Modularity team scope.
Lets ping modularity people. Any news?
I'm not sure I understand the problem here. If you've added Rawhide to your transaction, you literally *are* making it the "platform" for the modules. The only thing I can think to do here would be for DNF to consider all available providers of `base-module` in the transaction, but I realize that may be harder than it sounds.
> I'm not sure I understand the problem here. I'm querying nonmodular Rawhide. The output has some kind of conflicts that do not exist in nonmodular Rawhide and are not part of my query. When foo requires libbar in rawhide and libbar is not there, I don't see this when not querying libbar or foo: $ repoquery --repo=rawhide{,-source} --whatrequires spam Dependency problems: Problem 1: conflicting requests - nothing provides libbar needed by foo-1.2.3-1.fc32.noarch
I would suggest to reconsider decision about Platform Id. Platform ID is following releasever in 99% of user-case therefore dropping it will make no difference. It would decrease the complexity of the system and removes complains that it doesn't work. What do you think?
(In reply to Jaroslav Mracek from comment #31) > I would suggest to reconsider decision about Platform Id. Platform ID is > following releasever in 99% of user-case therefore dropping it will make no > difference. It would decrease the complexity of the system and removes > complains that it doesn't work. What do you think? Didn't we add it because upgrades didn't work without it? I'm trying to remember the history here.
There is a needinfo on me about reconsidering a decision about Platform Id. The decision is not my to reconsider.
This is not the first time when detection of platform failed. The problem is caused by using repositories from different distribution versions (F29/rawhide). I believe that we have to support this user-case, because the fail is a regression to a non-modular distribution. Simply users wants to do that and we are here to make them happy. telling users please don't do it is easy solution but it is not on the table. The problem cannot be resolved in DNF because platform_id requirement is in section of module requirement therefore dnf cannot ignore it. The detection of platform_id based on the pattern also cannot be applied because there is not known pattern for platform id. There are no restriction or even recommendations or naming policy for platform ID. How platform ID is detected. It is detected in first place from the latest available package that provides "system-release". Then the platform is taken from base-module(<Platform_ID>) provide. When it failed, it is taken from latest installed provider of "system-release". Then it is taken from os-release file on the system. Additional information see here: https://bugzilla.redhat.com/show_bug.cgi?id=1688462. The detection mechanism is very sensitive to presence of incorrect provider of the system-release and it does not allow to handle repositories from multiple releasevers. The comment 32 opened interesting question why platform_id is here and what it serves for? What we know that it produces problems. I can only suggest that platform id is important for the infrastructure. I believe that on distribution/customer side it is completely replaced by releasever variable in repository urls. What could be next steps: The first part would be to acknowledge the problem. I consider it as a problem that we have to resolve. But what about Modularity team? Petr Sabata - Please could you provide opinion and action plan? The second part gathering information. Probably we can start with answering some questions. Peter please could you answer the question from Comment 32? Why we need in distribution platform ID? I would like to know what is the additional value of platform Id in comparison with releasever. Modular repositories use releasever in urls therefore you cannot accidentally consume packages from incompatible release version. Because detection of platform id is primary taken from available metadata I do not see any additional protection value. Please can anyone verify my suggestions? The last part will be to find a solution. The solution must based on answers from questions like why we have platform ID.
To summarize the problem with platform ID I have to start from beginning. A. Platform ID detection fails in cases when (not only): 1. Modular repository is only used but the core system has a different platform - dnf download nodejs --releasever 31 - expected that modular version according to enabled module will be downloaded 2. Multiple providers of platform ID in available repositories - rawhide plus stable repositories are often used together (permanently, temporary for a single action) B. We know that platform ID produce a pain but we don't know why it is required for distribution (probably it is only required for a build system) - Stephen Gallagher a representative of Modularity team doesn't know and Petr Sabata is not responsive - we only see that platform platform:f32 is present with releasever 32, platform platform:f31 is present with releasever 31, platform platform:f30 is present with releasever 30. - Without knowing why it is so important we cannot provide the right solution. - In case that we know the role of platform ID in distribution we can - replace it by other mechanism - cannot specify because don't know the role - remove it completely and keep only releasever as a sufficient replacement
(In reply to Jaroslav Mracek from comment #37) > To summarize the problem with platform ID I have to start from beginning. > > A. Platform ID detection fails in cases when (not only): > 1. Modular repository is only used but the core system has a different > platform > - dnf download nodejs --releasever 31 > - expected that modular version according to enabled module will be > downloaded Can you rephrase this? I'm not sure what expectation you are describing. Are you saying that if I am running on F30 and pass `--releasever 31` I should get the `platform:30` version of whatever module I would have gotten if I was on F31? That... doesn't sound intuitive to me. I'd expect that this would download the same `nodejs` RPM that I would get if I was on F31, regardless of my current install. > 2. Multiple providers of platform ID in available repositories > - rawhide plus stable repositories are often used together (permanently, > temporary for a single action) > In this situation, shouldn't we just take whichever is the highest NEVRA as the official provider? We should also probably document that enabling Rawhide for Modules is likely never a good idea. (Maybe we should actually drop this from the fedora-repos RPMs on non-Rawhide releases.) Any module stream that is available for Rawhide should normally also be available for the stable release (possibly as a non-default stream). If it hasn't been built in a way that can be installed on the stable release, there's really no way that we should be trying to install it on that release. The more I consider this, the more I think that the fedora-repos package should drop the fedora-rawhide-Modular repos. Now, if we agree on the above constraint, I *think* we can say that DNF should just go with the releasever in order to determine which platform stream to have available if more than one is present. Can you think of a case where this wouldn't work? > B. We know that platform ID produce a pain but we don't know why it is > required for distribution (probably it is only required for a build system) > - Stephen Gallagher a representative of Modularity team doesn't know and > Petr Sabata is not responsive I don't recall being asked this question, but here's the answer: When we do the stream-expanded builds, we produce artifacts for each available platform, using that platform as the buildroot. This is because there may be significant build differences between the releases such that the resulting code may not run properly (or at all) if built in F30 and run on F31 (or vice-versa). We use the runtime dependency on the platform stream to ensure that we are running on the same system for which we were built. Some module streams can be built once and run anywhere, in which case they would specify a build-time dependency of `[ f30 ]` and a runtime dependency of `[ ]` (meaning: build on F30, install anywhere). Does that help? > - we only see that platform platform:f32 is present with releasever 32, > platform platform:f31 is present with releasever 31, platform platform:f30 > is present with releasever 30. > - Without knowing why it is so important we cannot provide the right > solution. > - In case that we know the role of platform ID in distribution we can > - replace it by other mechanism - cannot specify because don't know > the role > - remove it completely and keep only releasever as a sufficient > replacement
So I'm reading this: This is because there may be significant build differences between the releases such that the resulting code may not run properly (or at all) if built in F30 and run on F31 (or vice-versa). We use the runtime dependency on the platform stream to ensure that we are running on the same system for which we were built. and remain confused. Wouldn't the RPM dependencies on individual packages already stop that? Say barbaz-39.4 was built on F30, and depended on foobar-1.2.3.x86_64. Then any attempt to install the F31 version of foobar will fail because barbaz depends on the older version, and you can't get barbaz to install on F31. Of course, anybody who does a "rpm -Uvh --force --nodeps" is on their own already. So what situations require a runtime dependency that isn't already enforced at software update time?
(In reply to Valdis Kletnieks from comment #39) > So what situations require a runtime dependency that isn't already enforced > at software update time? I think it addresses issues like these (which all happened when curl was built against newer versions of libraries with the same soname as the ones the reporter had installed): https://bugzilla.redhat.com/show_bug.cgi?id=525002 https://bugzilla.redhat.com/show_bug.cgi?id=642796 https://bugzilla.redhat.com/show_bug.cgi?id=1462184 https://bugzilla.redhat.com/show_bug.cgi?id=1462211 https://bugzilla.redhat.com/show_bug.cgi?id=1631804 We have since added rpm-level dependencies to address these but I can see how a platform dependency could be useful to avoid this sort of issue.
I am sorry but the issue is not moving anywhere. The decision how to resolve the issue is on modularity team but there is no modularity component, therefore I have only the last option. Assignment of Petr Sabata and movement to the distribution component. What is known already we need a change.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I believe I'm seeing this issue when attempting to upgrade from Fedora 31 to 32. I see the following when attempting to download the upgrade: Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f31) needed by module exa:latest:3120190813195051:22d7e2a5-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64 However, removing gimp and exa has not allowed me to bypass this dependency problem message. I tried running the system-upgrade command with --refresh as well as dnf update --refresh but it has no cleared those messages.
You could try: # dnf module disable gimp # dnf module disable exa and see if that helps.
Not sure the trigger but I had a similar issue and this comment from Paul above helped. # dnf module disable eclipse meson ninja Last metadata expiration check: 0:00:54 ago on Thu 15 Oct 2020 09:20:36 AM EDT. Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f32) needed by module eclipse:latest:3220200402225102:7114797f-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f31) needed by module meson:latest:3120191009081836:dc56099c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f31) needed by module ninja:latest:3120190304180949:f636be4b-0.x86_64 Dependencies resolved. =========================================================================================================================================================================================================================================================================================== Package Architecture Version Repository Size =========================================================================================================================================================================================================================================================================================== Disabling modules: eclipse meson ninja Transaction Summary =========================================================================================================================================================================================================================================================================================== Is this ok [y/N]: y Complete! Not sure how I ended up in this state but it does appear to be fixed now as dnf check no longer reports the issue
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days