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.

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

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

*** Bug 1622295 has been marked as a duplicate of this bug. ***

*** Bug 1624373 has been marked as a duplicate of this bug. ***

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

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.

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.

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.

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 .

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

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.

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 ~]#

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.

If you are interested in my custom installation, please have a look into the textfile i will upload in a moment.

Created attachment 1486914 [details]
Fedora-installation.txt

May be of interest for Adam Williamson.

To be honest, no, not really. What's basically going on here is pretty well understood already. But thanks.

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.

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?

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 ?

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.

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.

Is this also related to bug 1611664?

*** Bug 1611664 has been marked as a duplicate of this bug. ***

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

I have a good news, the problem was fixed in libsolve, therefore we are going to back-port it.

upgrading DNF `dnf update dnf` fixed this issue for me, thank you

The problem is fixed in libsolv-0.6.35-3 that should be available in F29+.

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

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

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.

I've had the same issues, fixed by upgrading to dnf-upstream (Comment #31)

Thanks for testing. The patch will be released in dnf-4.0

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.

*** Bug 1635694 has been marked as a duplicate of this bug. ***

*** Bug 1635910 has been marked as a duplicate of this bug. ***

*** Bug 1616042 has been marked as a duplicate of this bug. ***

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).

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.

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.

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

(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.

(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?

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.

*** Bug 1554820 has been marked as a duplicate of this bug. ***

"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.

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.

My issues described in bug 1635694 are not solved yet.

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.

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 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

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

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...

dnf-3.6.1-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3a17006b01

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!

The fact is that I had no modules installed, or at least I didn't install any module. And I was getting such messages.

Yes. We know.

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

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 ...

% 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.

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?

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.

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?

Different bug. That's a real dependency issue. Looks like https://bodhi.fedoraproject.org/updates/FEDORA-2018-7be27ff1d8 needs a libreswan build added.

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.

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!

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.