Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1636285 - dnf complains about conflicts with non-installed and non-existent RPMs
Summary: dnf complains about conflicts with non-installed and non-existent RPMs
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 30
Hardware: x86_64
OS: Linux
high
unspecified
Target Milestone: ---
Assignee: Petr Šabata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-05 01:18 UTC by Valdis Kletnieks
Modified: 2023-09-12 01:33 UTC (History)
23 users (show)

Fixed In Version: dnf-4.0.4-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 14:32:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Valdis Kletnieks 2018-10-05 01:18:48 UTC
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:

Comment 1 Jaroslav Mracek 2018-10-05 12:56:05 UTC
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

Comment 2 Jaroslav Mracek 2018-10-05 18:35:15 UTC
I am sorry my comment was incorrect. The problems report issues about modules not rpms.

Comment 4 Jaroslav Mracek 2018-10-08 14:33:26 UTC
I create a patch that should improve error message https://github.com/rpm-software-management/libdnf/pull/605.

Comment 5 Valdis Kletnieks 2018-10-08 16:17:07 UTC
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.

Comment 6 Fedora Update System 2018-10-15 12:27:56 UTC
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

Comment 7 Fedora Update System 2018-10-15 18:22:29 UTC
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

Comment 8 Fedora Update System 2018-10-17 13:00:56 UTC
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

Comment 9 Fedora Update System 2018-10-17 23:30:02 UTC
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

Comment 10 Fedora Update System 2018-10-18 14:05:44 UTC
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

Comment 11 Fedora Update System 2018-10-20 19:21:31 UTC
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

Comment 12 Fedora Update System 2018-10-22 16:12:26 UTC
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.

Comment 13 Valdis Kletnieks 2018-10-22 18:17:25 UTC
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

Comment 14 Jaroslav Mracek 2018-10-22 18:28:11 UTC
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?

Comment 15 Valdis Kletnieks 2018-10-22 19:07:38 UTC
 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.

Comment 16 RobbieTheK 2019-01-03 19:45:43 UTC
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

Comment 17 Stephen Gallagher 2019-01-15 19:00:35 UTC
(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.

Comment 18 Mai Ling 2019-03-18 22:27:36 UTC
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

Comment 19 Miro Hrončok 2019-08-13 15:20:51 UTC
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

Comment 20 Ben Cotton 2019-08-13 16:54:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 21 Ben Cotton 2019-08-13 17:02:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 22 Paul Howarth 2019-08-14 07:46:42 UTC
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
...

Comment 23 Miro Hrončok 2019-08-28 10:25:18 UTC
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

Comment 24 Stephen Gallagher 2019-08-28 11:29:15 UTC
(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.

Comment 25 Miro Hrončok 2019-08-28 11:31:49 UTC
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.

Comment 26 Jaroslav Mracek 2019-09-06 16:14:57 UTC
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?

Comment 27 Jaroslav Mracek 2019-09-06 16:22:20 UTC
I create an issue https://pagure.io/modularity/issue/150 to put the issue on Modularity team scope.

Comment 28 Jaroslav Mracek 2019-11-01 13:56:47 UTC
Lets ping modularity people. Any news?

Comment 29 Stephen Gallagher 2019-11-08 12:42:50 UTC
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.

Comment 30 Miro Hrončok 2019-11-08 12:48:57 UTC
> 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

Comment 31 Jaroslav Mracek 2019-11-08 13:42:09 UTC
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?

Comment 32 Stephen Gallagher 2019-11-11 13:54:01 UTC
(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.

Comment 33 Miro Hrončok 2019-11-12 09:48:35 UTC
There is a needinfo on me about reconsidering a decision about Platform Id. The decision is not my to reconsider.

Comment 34 Jaroslav Mracek 2019-11-15 13:16:19 UTC
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.

Comment 37 Jaroslav Mracek 2019-11-29 07:47:04 UTC
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

Comment 38 Stephen Gallagher 2019-12-03 13:32:59 UTC
(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

Comment 39 Valdis Kletnieks 2019-12-03 22:36:44 UTC
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?

Comment 40 Paul Howarth 2019-12-04 10:01:08 UTC
(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.

Comment 41 Jaroslav Mracek 2019-12-12 13:07:30 UTC
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.

Comment 42 Ben Cotton 2020-04-30 20:14:55 UTC
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.

Comment 43 Ben Cotton 2020-05-26 14:32:33 UTC
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.

Comment 44 David Millar 2020-06-08 15:12:39 UTC
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.

Comment 45 Paul Howarth 2020-06-08 16:28:05 UTC
You could try:
# dnf module disable gimp
# dnf module disable exa

and see if that helps.

Comment 46 jared mauch 2020-10-15 13:27:29 UTC
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

Comment 47 Red Hat Bugzilla 2023-09-12 01:33:34 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.