Bug 1616118 - DNF update fails with "cannot install the best update candidate for package"
Summary: DNF update fails with "cannot install the best update candidate for package"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://fedoraproject...
: 1554820 1611664 1616042 1622295 1624373 1635694 1635910 (view as bug list)
Depends On: 1616180
Blocks: F29FinalBlocker 1599413
TreeView+ depends on / blocked
 
Reported: 2018-08-15 00:25 UTC by Stephen Gallagher
Modified: 2018-12-24 18:06 UTC (History)
49 users (show)

Fixed In Version: dnf-3.6.1-2.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-10 17:40:46 UTC
Type: Bug


Attachments (Terms of Use)
Fedora-installation.txt (5.35 KB, text/plain)
2018-09-25 19:31 UTC, Sebastian
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1616180 1 None None None 2021-03-01 13:41:13 UTC

Internal Links: 1616180

Description Stephen Gallagher 2018-08-15 00:25:39 UTC
Description of problem:
Attempting to do a full update results in numerous error messages about "cannot install the best update candidate for package" where it appears that DNF is attempting (and failing) to install packages from non-installed modules.

Version-Release number of selected component (if applicable):
dnf-3.2.0-2.fc29.noarch
python3-dnf-3.2.0-2.fc29.noarch
libdnf-0.17.0-2.fc29.x86_64
libsolv-0.6.35-1.fc29.x86_64
librepo-1.9.0-4.fc29.x86_64
libmodulemd-1.6.2-2.fc29.x86_64


How reproducible:
Every time

Steps to Reproduce:
1. `sudo buildah pull registry.fedoraproject.org/fedora:29`
2. `sudo buildah from --name dnfcandidatebug registry.fedoraproject.org/fedora:29`
3. `sudo buildah run -t dnfcandidatebug /usr/bin/bash`
[ Steps from here onwards are inside the container ]
4. `dnf install meson`
5. `dnf update dnf fedora-repos`
6. `dnf update`
7. `dnf update` (Again)

Actual results:
```
Last metadata expiration check: 0:00:51 ago on Wed Aug 15 00:22:59 2018.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package meson-0.47.1-5.fc29.noarch
  - package meson-0.47.1-5.module_1993+7c0a4d1e.noarch is disabled
 Problem 2: cannot install the best update candidate for package ninja-build-1.8.2-4.fc29.x86_64
  - package ninja-build-1.8.2-4.module_1991+4e5efe2f.x86_64 is disabled
Nothing to do.
Complete!
Warning: ssh still initialized; probably ssh_init() was called more than once (init count: 1)

```

Expected results:
No updates are expected at this point, since a full update just completed.

Additional info:
Ignore the ssh_init() message, that's bug #1615975

Comment 1 Fedora Blocker Bugs Application 2018-08-15 00:34:22 UTC
Proposed as a Blocker and Freeze Exception for 29-beta by Fedora user sgallagh using the blocker tracking app because:

 "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). "

I'm on the fence about whether this is a real blocker, since it *appears* to be cosmetic... it doesn't seem to stop real updates of the affected packages from occurring when they become available. However, it certainly *looks* alarming and would lead users to assume something was broken.

Comment 2 Geoffrey Marr 2018-08-20 19:59:04 UTC
Discussed during the 2018-08-20 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" (Final) was made as it violates the following criteria:

"The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type"

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-08-20/f29-blocker-review.2018-08-20-16.00.txt

Comment 3 Geoffrey Marr 2018-08-20 20:13:03 UTC
Discussed during the 2018-08-20 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedFreezeException" was made as, while this is also a blocker, we would like to have this fixed and if it can be done safely, we are all for this.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-08-20/f29-blocker-review.2018-08-20-16.00.txt

Comment 4 Stephen Gallagher 2018-08-27 12:10:42 UTC
*** Bug 1622295 has been marked as a duplicate of this bug. ***

Comment 5 Stephen Gallagher 2018-08-31 11:55:46 UTC
*** Bug 1624373 has been marked as a duplicate of this bug. ***

Comment 6 Daniel Mach 2018-09-17 09:24:24 UTC
I ran following:
docker run -it fedora:29 /bin/bash
(instead of steps 1-3)
and then followed steps 4-7

I couldn't reproduce the problem.
Could also someone else confirm that?

I tested it with the latest dnf-3.5.1

Comment 7 Michael Young 2018-09-17 09:44:14 UTC
You need a package with a module version more recent than the version in F29 and it looks like meson and ninja-build have had recent updates which stop that being the case

Instead try with
dnf install perl-HTTP-Tiny
which is currently showing the problem for me.

Comment 8 Adam Williamson 2018-09-20 15:41:18 UTC
teuf notes in https://pagure.io/releng/issue/7827#comment-532084 that this is particularly unfortunate in conjunction with the problem described there - modules that are intended to be used for server-side flatpak generation only being exposed to users. This bug results in those modules being shown to users who just run 'dnf update', in a confusing error message that makes it look a lot like they're being told to enable those modules.

Comment 9 Adam Williamson 2018-09-21 00:18:22 UTC
BTW, dunno if it has been mentioned yet, but note this:

===

[root@adam libdnf (master)]# dnf update
Last metadata expiration check: 0:00:55 ago on Thu 20 Sep 2018 04:59:45 PM PDT.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
...

[root@adam libdnf (master)]# dnf update bubblewrap
Dependencies resolved.
Nothing to do.
Complete!
[root@adam libdnf (master)]# 

===

i.e. the bug doesn't occur if you do 'dnf update foo', where 'foo' is a package that has the problem when you do 'dnf update'. There's some difference between the 'dnf update' and 'dnf update foo' paths which is significant here.

Comment 10 Adam Williamson 2018-09-21 00:36:59 UTC
Here's an interesting patch which "fixes" the problem:

diff --git a/dnf/base.py b/dnf/base.py
index 96c1aab7..172a084a 100644
--- a/dnf/base.py
+++ b/dnf/base.py
@@ -1937,7 +1937,7 @@ class Base(object):
 
     def upgrade_all(self, reponame=None):
         # :api
-        if reponame is None and not self._update_security_filters:
+        if reponame is None and not self._update_security_filters and 1 == 0:
             self._goal.upgrade_all()
         else:
             # provide only available packages to solver otherwise selection of available

i.e. we basically disable the 'shortcut' branch in base.upgrade_all , which just calls `self._goal.upgrade_all()`, and instead force even a 'simple' `dnf update` through the 'complicated' branch of that method, which creates a query for 'available' packages, does a couple other things to it, creates a selector from the query, then passes the selector to `self._goal.upgrade()`.

If you look at this from the libdnf end, I think it's ultimately the difference between winding up in the 'no arguments' form of Goal::upgrade(), which does this:

void
Goal::upgrade()
{
    pImpl->actions = static_cast<DnfGoalActions>(pImpl->actions | DNF_UPGRADE_ALL);
    queue_push2(&pImpl->staging, SOLVER_UPDATE|SOLVER_SOLVABLE_ALL, 0);
}

and winding up passing a selector to Goal::upgrade(), which does this:

void
Goal::upgrade(HySelector sltr)
{
    pImpl->actions = static_cast<DnfGoalActions>(pImpl->actions | DNF_UPGRADE);
    sltrToJob(sltr, &pImpl->staging, SOLVER_UPDATE);
}

which in turn I think ultimately affects what libsolv solver_solve() does - because its behaviour is influenced by SOLVER_SOLVABLE_ALL .

Comment 11 Adam Williamson 2018-09-21 00:40:53 UTC
Note, though, that my 'fix' isn't without its own interesting consequences. I have a couple of packages installed which I installed direct from Koji (because I needed them before they hit the repos). When I apply my patch and run 'dnf update', dnf actually wants to reinstall those packages from the repos:

Reinstalling:
 abrt                                x86_64          2.10.10-5.fc29                    updates-testing          511 k
 abrt-addon-ccpp                     x86_64          2.10.10-5.fc29                    updates-testing          120 k
 abrt-addon-coredump-helper          x86_64          2.10.10-5.fc29                    updates-testing           32 k
 abrt-addon-kerneloops               x86_64          2.10.10-5.fc29                    updates-testing           44 k
 abrt-addon-pstoreoops               x86_64          2.10.10-5.fc29                    updates-testing           25 k
 abrt-addon-vmcore                   x86_64          2.10.10-5.fc29                    updates-testing           37 k
 abrt-addon-xorg                     x86_64          2.10.10-5.fc29                    updates-testing           36 k
 abrt-cli                            x86_64          2.10.10-5.fc29                    updates-testing           16 k
 abrt-dbus                           x86_64          2.10.10-5.fc29                    updates-testing           79 k
 abrt-desktop                        x86_64          2.10.10-5.fc29                    updates-testing           16 k
 abrt-gui                            x86_64          2.10.10-5.fc29                    updates-testing          113 k
 abrt-gui-libs                       x86_64          2.10.10-5.fc29                    updates-testing           25 k
 abrt-libs                           x86_64          2.10.10-5.fc29                    updates-testing           44 k
 abrt-plugin-bodhi                   x86_64          2.10.10-5.fc29                    updates-testing           29 k
 abrt-retrace-client                 x86_64          2.10.10-5.fc29                    updates-testing           51 k
 abrt-tui                            x86_64          2.10.10-5.fc29                    updates-testing           28 k
 gnome-shell                         x86_64          3.30.0-7.fc29                     updates-testing          1.4 M
 python3-abrt                        x86_64          2.10.10-5.fc29                    updates-testing           40 k
 python3-abrt-addon                  x86_64          2.10.10-5.fc29                    updates-testing           25 k

Comment 12 Miroslav Suchý 2018-09-24 10:42:31 UTC
I can confirm that this happens with dnf-3.5.1-1.fc29.noarch

@dmach I can reproduce it on my machine. Feel free to stop by.

Comment 13 Sebastian 2018-09-25 03:21:28 UTC
I have it since i upgraded F28 to F29. My other fresh install of F29 did not have all those problems.

[root@f29 ~]# dnf update
Letzte Prüfung auf abgelaufene Metadaten: vor 2:36:56 am Di 25 Sep 2018 02:24:56 CEST.
Abhängigkeiten sind aufgelöst.

 Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled

 Problem 2: cannot install the best update candidate for package
 eog-3.28.3-1.fc29.x86_64
  - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled

 Problem 3: cannot install the best update candidate for package
 exempi-2.4.5-3.fc29.x86_64
  - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled

 Problem 4: cannot install the best update candidate for package
 gimp-2:2.10.6-2.fc29.x86_64
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled

 Problem 5: cannot install the best update candidate for package
 gimp-libs-2:2.10.6-2.fc29.x86_64
  - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled

 Problem 6: cannot install the best update candidate for package
 libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled

 Problem 7: cannot install the best update candidate for package
 libpeas-1.22.0-9.fc29.x86_64
  - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled

 Problem 8: cannot install the best update candidate for package
 libpeas-gtk-1.22.0-9.fc29.x86_64
  - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled

 Problem 9: cannot install the best update candidate for package
 libpeas-loader-python3-1.22.0-9.fc29.x86_64
  - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled

 Problem 10: cannot install the best update candidate for package
 perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled

 Problem 11: cannot install the best update candidate for package
 perl-Thread-Queue-3.13-1.fc29.noarch
  - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
Nichts zu tun.
Fertig.
[root@f29 ~]#

Comment 14 Adam Williamson 2018-09-25 05:15:47 UTC
Sebastian: it doesn't matter really whether you upgraded; what matters is what packages you have installed, and the state of the modular repos at the time. Many of the packages showing as 'updates' have only appeared in the modular repos relatively recently, so you wouldn't have seen the message for those packages if you were testing earlier in the cycle.

Comment 15 Sebastian 2018-09-25 19:04:57 UTC
If you are interested in my custom installation, please have a look into the textfile i will upload in a moment.

Comment 16 Sebastian 2018-09-25 19:31:10 UTC
Created attachment 1486914 [details]
Fedora-installation.txt

May be of interest for Adam Williamson.

Comment 17 Adam Williamson 2018-09-25 19:51:01 UTC
To be honest, no, not really. What's basically going on here is pretty well understood already. But thanks.

Comment 18 Yaniv Kaul 2018-09-27 05:52:40 UTC
After upgrade from a perfectly working F28 to F29 beta (+ update after), I'm stuck with:
 Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
 Problem 2: cannot install the best update candidate for package eog-3.28.3-1.fc29.x86_64
  - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
 Problem 3: cannot install the best update candidate for package exempi-2.4.5-3.fc29.x86_64
  - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
 Problem 4: cannot install the best update candidate for package gimp-2:2.10.6-2.fc29.x86_64
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
 Problem 5: cannot install the best update candidate for package gimp-libs-2:2.10.6-2.fc29.x86_64
  - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
 Problem 6: cannot install the best update candidate for package kubernetes-client-1.10.3-1.fc29.x86_64
  - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is disabled
 Problem 7: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 8: cannot install the best update candidate for package libpeas-1.22.0-9.fc29.x86_64
  - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 9: cannot install the best update candidate for package libpeas-gtk-1.22.0-9.fc29.x86_64
  - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 10: cannot install the best update candidate for package libpeas-loader-python3-1.22.0-9.fc29.x86_64
  - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 11: cannot install the best update candidate for package libuv-1:1.23.0-1.fc29.x86_64
  - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 12: cannot install the best update candidate for package perl-DB_File-1.842-1.fc29.x86_64
  - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
 Problem 13: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
 Problem 14: cannot install the best update candidate for package perl-Thread-Queue-3.13-1.fc29.noarch
  - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
Nothing to do.


Unsure how to even proceed.

Comment 19 Adam Williamson 2018-09-27 05:56:57 UTC
As the bug says, this doesn't indicate any actual problem. If that's all you get when you run 'dnf update', or something, it means your system is fully up to date.

Is there a reason you say you're "stuck"? Is something that should work not working?

Comment 20 Edouard Bourguignon 2018-09-27 06:26:30 UTC
Same bug here. I think I'm stuck because dnf says there are a lot of problem. And doesn't give more clue to how to fix them. I've got a couple of PC running F29, and the one that have this bug seems stuck. I mean by that, that it didn't get any more updates. But maybe that is just because beta is being released, so updates are quiet ? At least those messages are misleading. Why is it written "problem #" if everything is fine ?

I also have to disable repo "*cisco*". don't know where they are from. It's an other problem I guess. And a kind of crash with fastestmirror.

$ LANG=C dnfu                 
Last metadata expiration check: 0:01:37 ago on Thu Sep 27 08:19:10 2018.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
 Problem 2: cannot install the best update candidate for package eog-3.28.3-1.fc29.x86_64
  - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
 Problem 3: cannot install the best update candidate for package exempi-2.4.5-3.fc29.x86_64
  - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
 Problem 4: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 5: cannot install the best update candidate for package libpeas-1.22.0-9.fc29.x86_64
  - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 6: cannot install the best update candidate for package libpeas-gtk-1.22.0-9.fc29.x86_64
  - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 7: cannot install the best update candidate for package libpeas-loader-python3-1.22.0-9.fc29.x86_64
  - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 8: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
Nothing to do.
Complete!

How to fix that ?

Comment 21 Adam Williamson 2018-09-27 06:53:15 UTC
There isn't anything to fix. There isn't any problem. It's just a bug that dnf is telling you there is one, that's all.

It's seeing that you have bubblewrap and eog and exempi and so on installed, and noticing that 'newer' versions of them are available in some disabled modules, and telling you about that. It shouldn't do that. But nothing is really wrong.

Comment 22 Jaroslav Mracek 2018-09-27 11:09:54 UTC
This bug is relevant to https://bugzilla.redhat.com/show_bug.cgi?id=1616180 and we try to solve it as soon as it is possible.

Comment 23 Pekka Korkki 2018-09-27 13:35:21 UTC
Is this also related to bug 1611664?

Comment 24 Jaroslav Mracek 2018-09-27 13:38:05 UTC
*** Bug 1611664 has been marked as a duplicate of this bug. ***

Comment 25 Yann Droneaud 2018-10-02 09:11:08 UTC
I've noticed the issue on rawhide too:

 Problem 1: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc30.x86_64
  - package libnghttp2-1.33.0-1.module_2177+076c917f.x86_64 is excluded
 Problem 2: cannot install the best update candidate for package libuv-1:1.23.0-1.fc30.x86_64
  - package libuv-1:1.23.0-1.module_2177+076c917f.x86_64 is excluded

Comment 26 Jaroslav Mracek 2018-10-02 11:27:13 UTC
I have a good news, the problem was fixed in libsolve, therefore we are going to back-port it.

Comment 27 jibecfed 2018-10-05 07:44:50 UTC
upgrading DNF `dnf update dnf` fixed this issue for me, thank you

Comment 28 Jaroslav Mracek 2018-10-05 07:58:21 UTC
The problem is fixed in libsolv-0.6.35-3 that should be available in F29+.

Comment 29 Michael Young 2018-10-05 08:07:45 UTC
I am still seeing the problem with
dnf-3.6.1-1.fc29.noarch
libsolv-0.6.35-3.fc29.x86_64
eg.
 Problem 1: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is excluded
 Problem 2: cannot install the best update candidate for package libpeas-1.22.0-9.fc29.x86_64
  - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
 Problem 3: cannot install the best update candidate for package libpeas-gtk-1.22.0-9.fc29.x86_64
  - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
 Problem 4: cannot install the best update candidate for package libpeas-loader-python3-1.22.0-9.fc29.x86_64
  - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
 Problem 5: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is excluded

Comment 30 Jaroslav Mracek 2018-10-05 08:53:38 UTC
to Comment 29 : This is a problem of modularity and hybrid repository where non-modular package depends on modular content that is not available(not in default stream). Probably this could help http://miroslav.suchy.cz/blog/archives/2018/10/03/fedora_29_will_enable_you_modules/index.html

Comment 31 Jaroslav Mracek 2018-10-05 09:30:04 UTC
I am sorry, the problem is fixed with libsolv-0.6.35-3 and upstream dnf (commit https://github.com/rpm-software-management/dnf/commit/55ea10083506f58b0eb2d9e302df235414a140c1 and one after). Here is a copr repository for testing https://copr.fedorainfracloud.org/coprs/jmracek/dnf-upstream. Hope that it helps.

Comment 32 Mike Gerber 2018-10-05 14:56:16 UTC
I've had the same issues, fixed by upgrading to dnf-upstream (Comment #31)

Comment 33 Jaroslav Mracek 2018-10-05 18:28:18 UTC
Thanks for testing. The patch will be released in dnf-4.0

Comment 34 Adam Williamson 2018-10-05 18:30:17 UTC
That's a very scary version number, given that we're between Beta and Final right now.

Please do not close distro bugs as NEXTRELEASE in this way. It is misleading and confusing as the bug is not fixed in the distribution yet. The bug should only be closed when the code to fix it is actually in the distribution release in question, that is, Fedora 29.

Comment 35 Jaroslav Mracek 2018-10-05 18:38:36 UTC
*** Bug 1635694 has been marked as a duplicate of this bug. ***

Comment 36 Jaroslav Mracek 2018-10-05 19:41:29 UTC
*** Bug 1635910 has been marked as a duplicate of this bug. ***

Comment 37 Jaroslav Mracek 2018-10-05 20:24:12 UTC
*** Bug 1616042 has been marked as a duplicate of this bug. ***

Comment 38 Luigi Cantoni 2018-10-06 00:49:08 UTC
As my problem (similar to above but for kernel modules) is with F28 I do not expect a fix at the moment.
F29 official release is:
2018-10-30 	Fedora 29 Final Release (GA) (Target #1)
I will wait until the start of Nov and upgrade to F29.
If fixed/not fixed I will report then (or open new bug if this is closed).
I expect it should be fixed based on what I have read above (and in other bug reports).

Comment 39 Adam Williamson 2018-10-06 00:51:27 UTC
Luigi: anything you are seeing on F28 is extremely unlikely to be the same thing. It is more likely to be a genuine dependency issue. Please file a separate bug for it.

Comment 40 Luigi Cantoni 2018-10-06 01:08:53 UTC
Bug 1628103 show the same types of issues and I believe it has been addressed so all should be good.
I agree looking in detail above my problem is probably not exactly the same.
Sorry for adding the item I guess its a fork in an earlier bug and I am the other side of the fork.
 Problem: cannot install both kernel-4.18.11-200.fc28.x86_64 and kernel-4.18.11-200.fc28.x86_64
dnf is confused, hopefully will sort itself with F29. Just inconvenient not a real problem.

Comment 41 Alessio 2018-10-06 21:26:54 UTC
Fedora-Server-netinst-x86_64-29-20181005.n.0.iso fresh install.

dnf update return this message

 Problem: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is excluded

Installing dnf from jmracek/dnf-upstream copr and issuing dnf update works without any problem

Comment 42 Piruthiviraj Natarajan 2018-10-07 01:41:45 UTC
(In reply to Alessio from comment #41)
> Fedora-Server-netinst-x86_64-29-20181005.n.0.iso fresh install.
> 
> dnf update return this message
> 
>  Problem: cannot install the best update candidate for package
> libnghttp2-1.33.0-1.fc29.x86_64
>   - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is excluded
> 
> Installing dnf from jmracek/dnf-upstream copr and issuing dnf update works
> without any problem

I do not understand why you would try to use copr repo for dnf.

Comment 43 Alessio 2018-10-07 06:01:33 UTC
(In reply to Piruthiviraj Natarajan from comment #42)
> 
> I do not understand why you would try to use copr repo for dnf.

I don't know. Just to try. After all in such copr repo, there is an updated dnf version, isn't it?

Comment 44 Marcin Juszkiewicz 2018-10-08 09:12:58 UTC
So dnf generating misleading messages is considered to be not an issue nowadays?

On my F29 system I have 25 packages which dnf treats as problematic ones despite being installed in latest available versions:

[root@puchatek dnf]# dnf update 
Ostatnio sprawdzono ważność metadanych: 0:06:48 temu w dniu pon, 8 paź 2018, 11:00:58.
Rozwiązano zależności.

 Problem 1: cannot install the best update candidate for package ghc-array-0.5.2.0-69.fc29.x86_64
  - package ghc-array-0.5.2.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 2: cannot install the best update candidate for package ghc-base-4.10.1.0-69.fc29.x86_64
  - package ghc-base-4.11.1.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 3: cannot install the best update candidate for package ghc-binary-0.8.5.1-69.fc29.x86_64
  - package ghc-binary-0.8.5.1-71.module_2248+0d799374.x86_64 is excluded
 Problem 4: cannot install the best update candidate for package ghc-bytestring-0.10.8.2-69.fc29.x86_64
  - package ghc-bytestring-0.10.8.2-71.module_2248+0d799374.x86_64 is excluded
 Problem 5: cannot install the best update candidate for package ghc-containers-0.5.10.2-69.fc29.x86_64
  - package ghc-containers-0.5.11.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 6: cannot install the best update candidate for package ghc-deepseq-1.4.3.0-69.fc29.x86_64
  - package ghc-deepseq-1.4.3.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 7: cannot install the best update candidate for package ghc-directory-1.3.0.2-69.fc29.x86_64
  - package ghc-directory-1.3.1.5-71.module_2248+0d799374.x86_64 is excluded
 Problem 8: cannot install the best update candidate for package ghc-filepath-1.4.1.2-69.fc29.x86_64
  - package ghc-filepath-1.4.2-71.module_2248+0d799374.x86_64 is excluded
 Problem 9: cannot install the best update candidate for package ghc-ghc-boot-th-8.2.2-69.fc29.x86_64
  - package ghc-ghc-boot-th-8.4.3-71.module_2248+0d799374.x86_64 is excluded
 Problem 10: cannot install the best update candidate for package ghc-mtl-2.2.2-1.fc29.x86_64
  - package ghc-mtl-2.2.2-71.module_2248+0d799374.x86_64 is excluded
 Problem 11: cannot install the best update candidate for package ghc-parsec-3.1.13.0-1.fc29.x86_64
  - package ghc-parsec-3.1.13.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 12: cannot install the best update candidate for package ghc-pretty-1.1.3.3-69.fc29.x86_64
  - package ghc-pretty-1.1.3.6-71.module_2248+0d799374.x86_64 is excluded
 Problem 13: cannot install the best update candidate for package ghc-process-1.6.1.0-69.fc29.x86_64
  - package ghc-process-1.6.3.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 14: cannot install the best update candidate for package ghc-stm-2.4.5.0-1.fc29.x86_64
  - package ghc-stm-2.4.5.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 15: cannot install the best update candidate for package ghc-template-haskell-2.12.0.0-69.fc29.x86_64
  - package ghc-template-haskell-2.13.0.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 16: cannot install the best update candidate for package ghc-text-1.2.3.0-1.fc29.x86_64
  - package ghc-text-1.2.3.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 17: cannot install the best update candidate for package ghc-time-1.8.0.2-69.fc29.x86_64
  - package ghc-time-1.8.0.2-71.module_2248+0d799374.x86_64 is excluded
 Problem 18: cannot install the best update candidate for package ghc-transformers-0.5.2.0-69.fc29.x86_64
  - package ghc-transformers-0.5.5.0-71.module_2248+0d799374.x86_64 is excluded
 Problem 19: cannot install the best update candidate for package ghc-unix-2.7.2.2-69.fc29.x86_64
  - package ghc-unix-2.7.2.2-71.module_2248+0d799374.x86_64 is excluded
 Problem 20: cannot install the best update candidate for package gimp-2:2.10.6-2.fc29.x86_64
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is excluded
 Problem 21: cannot install the best update candidate for package gimp-libs-2:2.10.6-2.fc29.x86_64
  - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is excluded
 Problem 22: cannot install the best update candidate for package libuv-1:1.23.0-1.fc29.x86_64
  - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is excluded
 Problem 23: cannot install the best update candidate for package perl-DB_File-1.842-1.fc29.x86_64
  - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is excluded
 Problem 24: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is excluded
 Problem 25: cannot install the best update candidate for package perl-Thread-Queue-3.13-1.fc29.noarch
  - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is excluded
Nie ma nic do zrobienia.
Ukończono.

Good thing is that disabling all 'fedora modular' repos resulted in dnf doing it's job without spitting messy messages like above.

Comment 45 Jaroslav Mracek 2018-10-08 14:40:35 UTC
*** Bug 1554820 has been marked as a duplicate of this bug. ***

Comment 46 Adam Williamson 2018-10-08 15:26:50 UTC
"So dnf generating misleading messages is considered to be not an issue nowadays?"

Um. No. Nobody said that. That's why this bug report exists and the developers fixed it.

Comment 47 Adam Williamson 2018-10-09 05:48:16 UTC
So the libsolv update and DNF 3.6.1 update are now both stable. Can folks please check they have both libsolv-0.6.35-3.fc29 or later and dnf-3.6.1-1.fc29 or later, and confirm whether they still see the bug? Thanks.

Comment 48 Vít Ondruch 2018-10-09 06:21:43 UTC
My issues described in bug 1635694 are not solved yet.

Comment 49 Michael Young 2018-10-09 07:35:55 UTC
As I wrote in comment #29
I am still seeing the problem with
dnf-3.6.1-1.fc29.noarch
libsolv-0.6.35-3.fc29.x86_64

However my testing in a container suggests that the fixes in dnf from jmracek/dnf-upstream will solve the problem when they reach Fedora.

Comment 50 Alessio 2018-10-09 11:04:10 UTC
Using 

dnf-3.6.1-1.fc29
libsolv-0.6.35-3.fc29

Today "dnf update" works without any issue. Is it plausible that another (now updated) package was involved?
Because with the same version of dnf and libsolv, some days ago I was facing the described issue.

- package foo.module_xxxx+xxxxx.x86_64 is excluded
 Problem 1: cannot install the best update candidate for package foo.module_xxxx+xxxxx.x86_64 is excluded
...

Comment 51 Michael Young 2018-10-09 11:43:56 UTC
(In reply to Alessio from comment #50)
> Using 
> 
> dnf-3.6.1-1.fc29
> libsolv-0.6.35-3.fc29
> 
> Today "dnf update" works without any issue. Is it plausible that another
> (now updated) package was involved?
> Because with the same version of dnf and libsolv, some days ago I was facing
> the described issue.
> 
> - package foo.module_xxxx+xxxxx.x86_64 is excluded
>  Problem 1: cannot install the best update candidate for package
> foo.module_xxxx+xxxxx.x86_64 is excluded
> ...

In your example it might be that package foo has been updated, so the condition triggering the warning has gone away ie. the F29 package has a later version (under rpm sorting) than any module builds.
For example one of the warnings I was seeing
 Problem 1: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is excluded
has gone now I have libnghttp2-1.34.0-1.fc29.x86_64 but I would expect the warning to come back when the nodejs-10 module is rebuilt giving an updated libnghttp2 dependant module package

Comment 52 Pekka Korkki 2018-10-09 14:30:11 UTC
I have libsolv-0.6.35-3.fc29 and dnf-3.6.1-1.fc29 installed. "sudo dnf update" prints:

 Problem 1: cannot install the best update candidate for package gimp-2:2.10.6-2.fc29.x86_64
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is excluded
 Problem 2: cannot install the best update candidate for package gimp-libs-2:2.10.6-2.fc29.x86_64
  - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is excluded
 Problem 3: cannot install the best update candidate for package libuv-1:1.23.0-1.fc29.x86_64
  - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is excluded
 Problem 4: cannot install the best update candidate for package nodejs-1:10.11.0-1.fc29.x86_64
  - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is excluded
 Problem 5: cannot install the best update candidate for package npm-1:6.4.1-1.10.11.0.1.fc29.x86_64
  - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is excluded
 Problem 6: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is excluded
 Problem 7: package vlc-3.0.5-1.fc29.x86_64 requires libplacebo.so.5()(64bit), but none of the providers can be installed
  - cannot install both libplacebo-0.6.0-2.fc29.x86_64 and libplacebo-0.5.0-1.fc29.x86_64
  - cannot install both libplacebo-0.5.0-1.fc29.x86_64 and libplacebo-0.6.0-2.fc29.x86_64
  - cannot install the best update candidate for package vlc-3.0.5-1.fc29.x86_64
  - cannot install the best update candidate for package libplacebo-0.5.0-1.fc29.x86_64

Comment 53 Adam Williamson 2018-10-09 14:47:22 UTC
OK, so, that confirms we need a DNF later than 3.6.1 to see the fix for this.

I think I will backport the fix and do a build; we are frozen for Final now and I don't think it'd be a good idea to pull in a new major DNF release just to fix this...

Comment 54 Fedora Update System 2018-10-09 15:17:37 UTC
dnf-3.6.1-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3a17006b01

Comment 55 Michael Young 2018-10-09 15:35:26 UTC
Quick test in a container with perl-HTTP-Tiny package added
dnf-3.6.1-1.fc29.noarch
libsolv-0.6.35-3.fc29.x86_64

dnf update
Last metadata expiration check: 0:07:26 ago on Tue 09 Oct 2018 03:21:57 PM UTC.
Dependencies resolved.

 Problem: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is excluded
Nothing to do.
Complete!

Get and install dnf, dnf-data, python3-dnf, dnf-yum 
from https://koji.fedoraproject.org/koji/buildinfo?buildID=1151824

dnf-3.6.1-2.fc29.noarch
libsolv-0.6.35-3.fc29.x86_64

dnf update
Last metadata expiration check: 0:08:55 ago on Tue 09 Oct 2018 03:21:57 PM UTC.
Dependencies resolved.
Nothing to do.
Complete!

Comment 56 Alessio 2018-10-09 15:46:26 UTC
The fact is that I had no modules installed, or at least I didn't install any module. And I was getting such messages.

Comment 57 Adam Williamson 2018-10-09 17:36:30 UTC
Yes. We know.

Comment 58 Fedora Update System 2018-10-09 20:03:58 UTC
dnf-3.6.1-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-3a17006b01

Comment 59 Vít Ondruch 2018-10-10 08:24:44 UTC
Testing with:

~~~
$ rpm -q dnf
dnf-3.6.1-3.fc30.noarch
~~~

It fixes most of the issues I observed, but there is still one:

~~~
$ sudo dnf update --disablerepo=* --enablerepo=rawhide -x kernel
Last metadata expiration check: 0:03:04 ago on Wed Oct 10 10:15:27 2018.
Error: 
 Problem: package kernel-4.18.10-300.fc29.x86_64 requires kernel-core-uname-r = 4.18.10-300.fc29.x86_64, but none of the providers can be installed
  - conflicting requests
  - problem with installed package kernel-4.18.10-300.fc29.x86_64
~~~

The command above should not quit but install the other available updates. I might report is separately ...

Comment 60 Mike Gerber 2018-10-10 08:31:59 UTC
% rpm -q dnf libsolv
dnf-3.6.1-2.fc29.noarch
libsolv-0.6.35-3.fc29.x86_64

The latest update from updates-testing fixes the modules-related issues for me.

Comment 61 Adam Williamson 2018-10-10 15:04:14 UTC
Vit: yeah, that seems slightly different to me. It would be interesting if it was a *regression* caused by the fix for this, though. Can you check that - did it work with the previous libsolv?

Comment 62 Fedora Update System 2018-10-10 17:40:46 UTC
dnf-3.6.1-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 63 Pekka Korkki 2018-10-11 05:39:42 UTC
dnf-3.6.1-2.fc29 and libsolv-0.6.35-3.fc29 installed. "sudo dnf upgrade" says:

 Problem: package libreswan-3.25-3.fc29.1.x86_64 requires libunbound.so.2()(64bit), but none of the providers can be installed
  - cannot install both unbound-libs-1.8.1-1.fc29.x86_64 and unbound-libs-1.7.3-9.fc29.x86_64
  - cannot install both unbound-libs-1.7.3-9.fc29.x86_64 and unbound-libs-1.8.1-1.fc29.x86_64
  - cannot install the best update candidate for package unbound-libs-1.7.3-9.fc29.x86_64
  - cannot install the best update candidate for package libreswan-3.25-3.fc29.1.x86_64

Is this a different bug/problem or still the same issue?

Comment 64 Adam Williamson 2018-10-11 06:46:01 UTC
Different bug. That's a real dependency issue. Looks like https://bodhi.fedoraproject.org/updates/FEDORA-2018-7be27ff1d8 needs a libreswan build added.

Comment 65 Thomas W 2018-10-25 11:29:10 UTC
This was/is in fact blocking additional updates via "sudo dnf update" and/or "sudo dnf upgrade" from going forward.

After finding this thread and running "sudo dnf update dnf" (which resulted in "nothing to do") "sudo dnf update" suddenly had 30 updates to do.

Comment 66 thommy.m.malmstrom 2018-12-20 09:37:34 UTC
I updated to F29 last night (2018-12-19) and I guess the "bug" is still there.


$ uname -a
Linux han 4.19.9-300.fc29.x86_64 #1 SMP Thu Dec 13 17:25:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q dnf libsolv
dnf-4.0.9-2.fc29.noarch
libsolv-0.7.2-1.fc29.x86_64

$ sudo dnf upgrade --refresh
[sudo] password for thommym: 
Copr repo for qgis owned by dani                2.3 kB/s | 3.9 kB     00:01    
etcher-rpm                                      955  B/s | 1.3 kB     00:01    
Fedora Modular 29 - x86_64                       15 kB/s |  28 kB     00:01    
Fedora Modular 29 - x86_64 - Updates             16 kB/s |  26 kB     00:01    
Fedora 29 - x86_64 - Updates                     13 kB/s |  28 kB     00:02    
Fedora 29 - x86_64                               16 kB/s |  28 kB     00:01    
google-chrome                                   1.2 kB/s | 1.3 kB     00:01    
insync repo                                     2.5 kB/s | 2.9 kB     00:01    
MySQL Connectors Community                      2.3 kB/s | 2.4 kB     00:01    
MySQL Tools Community                           2.3 kB/s | 2.5 kB     00:01    
MySQL 8.0 Community Server                      2.3 kB/s | 2.5 kB     00:01    
RPM Fusion for Fedora 29 - Free - Updates       6.8 kB/s | 9.8 kB     00:01    
RPM Fusion for Fedora 29 - Free                 9.0 kB/s |  10 kB     00:01    
RPM Fusion for Fedora 29 - Nonfree - NVIDIA Dri 6.7 kB/s | 9.5 kB     00:01    
RPM Fusion for Fedora 29 - Nonfree - Steam      8.0 kB/s | 9.2 kB     00:01    
RPM Fusion for Fedora 29 - Nonfree - Updates    8.7 kB/s | 9.9 kB     00:01    
RPM Fusion for Fedora 29 - Nonfree              9.1 kB/s |  10 kB     00:01    
Fedora 29 - x86_64 - VirtualBox                  55  B/s | 181  B     00:03    
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package gimp-2:2.10.6-2.module_2129+8576126a.x86_64
  - nothing provides /usr/bin/python22 needed by gimp-2:2.10.8-3.module_2456+e107f95c.x86_64
 Problem 2: package ufraw-gimp-0.22-14.fc29.x86_64 requires gimp(x86-64), but none of the providers can be installed
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 requires gimp-libs(x86-64) = 2:2.10.6-2.module_2129+8576126a, but none of the providers can be installed
  - cannot install both gimp-libs-2:2.10.8-3.module_2456+e107f95c.x86_64 and gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64
  - cannot install the best update candidate for package ufraw-gimp-0.22-14.fc29.x86_64
  - cannot install the best update candidate for package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64
  - nothing provides /usr/bin/python22 needed by gimp-2:2.10.8-3.module_2456+e107f95c.x86_64
  - package gimp-2:2.10.8-5.fc29.x86_64 is excluded
  - package gimp-2:2.10.6-2.fc29.x86_64 is excluded
================================================================================
 Package     Arch     Version                           Repository         Size
================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 gimp-libs   x86_64   2:2.10.8-3.module_2456+e107f95c   updates-modular   2.4 M
Skipping packages with broken dependencies:
 gimp        x86_64   2:2.10.8-3.module_2456+e107f95c   updates-modular    23 M

Transaction Summary
================================================================================
Skip  2 Packages

Nothing to do.
Complete!

$ sudo dnf update dnf
Last metadata expiration check: 0:06:34 ago on Thu 20 Dec 2018 10:15:42 AM CET.
Dependencies resolved.
Nothing to do.
Complete!

Comment 67 Adam Williamson 2018-12-20 15:46:49 UTC
That...doesn't really look like the same bug, it looks more like an actual dependency bug in an enabled module. Note there are no "is disabled" messages in your output.


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