Fedora 28 dnf update dependency issue with salt and python-tornado

[mvermaes]

Qubes OS version:

R3.2

Affected component(s):

Fedora packaging, Salt

---

Steps to reproduce the behavior:

Install qubes-template-fedora-28, then run dnf update in the template

Expected behavior:

All packages updated, no dependency issues.

Actual behavior:

[user@fedora-28 ~]$ sudo dnf clean all
49 files removed
[user@fedora-28 ~]$ sudo dnf update
Fedora 28 - x86_64 - Updates                    4.3 MB/s |  16 MB     00:03    
Fedora 28 - x86_64                               11 MB/s |  60 MB     00:05    
Qubes OS Repository for VM (updates)             41 kB/s |  58 kB     00:01    
Last metadata expiration check: 0:00:00 ago on Thu 14 Jun 2018 12:51:16 AWST.
Dependencies resolved.

 Problem: package salt-2018.3.0-1.fc28.noarch requires python-tornado < 5.0, but none of the providers can be installed
  - cannot install both python2-tornado-5.0.2-2.fc28.x86_64 and python2-tornado-4.5.2-2.fc28.x86_64
  - cannot install both python2-tornado-4.5.2-2.fc28.x86_64 and python2-tornado-5.0.2-2.fc28.x86_64
  - cannot install the best update candidate for package salt-2018.3.0-1.fc28.noarch
  - cannot install the best update candidate for package python2-tornado-4.5.2-2.fc28.x86_64
================================================================================
 Package                Arch          Version              Repository      Size
================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 python2-tornado        x86_64        5.0.2-2.fc28         updates        746 k

Transaction Summary
================================================================================
Skip  1 Package

Nothing to do.
Complete!

General notes:

Using --best --allowerasing as suggested allows python2-tornado to be upgraded, but removes qubes-mgmt-salt-vm-connector, qubes-vm-recommended, salt and salt-ssh.

I think this only started happening in the last week or so. At least when I initially downloaded the template around May 23, updates were completing without issue.

---

Related issues:

#3593 (although this is about uninstalling a qubes-vm-recommended package)

[andrewdavidwong]

Several users affected. Thread:
https://groups.google.com/d/topic/qubes-users/oQhZgbObado/discussion

[andrewdavidwong]

Several users affected. Thread:
https://groups.google.com/d/topic/qubes-users/oQhZgbObado/discussion

[marmarek]

Looks like Fedora dependency issue, but breakage correctly avoided by dnf.
Salt require (according to package deps) python2-tornado older than 5.0, so dnf blocks update to python2-tornado-5.0.2-2.fc28. Not sure if "python2-tornado < 5.0" is still applicable, but probably is - was introduced in Feb 2018, in salt-2017.7.4-1. According to salt 2018.3.1 release notes, it should be compatible with python2-tornado version 5 (but not python3-tornado 5). But salt 2018.3.1 isn't packaged for Fedora yet. It may be also that salt 2018.3.0 is also compatible with python2-tornado 5 and salt package dependencies are wrong, but can't confirm it yet.

[marmarek]

Looks like Fedora dependency issue, but breakage correctly avoided by dnf.
Salt require (according to package deps) python2-tornado older than 5.0, so dnf blocks update to python2-tornado-5.0.2-2.fc28. Not sure if "python2-tornado < 5.0" is still applicable, but probably is - was introduced in Feb 2018, in salt-2017.7.4-1. According to salt 2018.3.1 release notes, it should be compatible with python2-tornado version 5 (but not python3-tornado 5). But salt 2018.3.1 isn't packaged for Fedora yet. It may be also that salt 2018.3.0 is also compatible with python2-tornado 5 and salt package dependencies are wrong, but can't confirm it yet.

[lunarthegrey]

Can confirm the issue, noticed it the other day when running updates.

[lunarthegrey]

Can confirm the issue, noticed it the other day when running updates.

[andrewdavidwong]

So, what should we do? Just let dnf skip python2-tornado?

[andrewdavidwong]

So, what should we do? Just let dnf skip python2-tornado?

[marmarek]

Just let dnf skip python2-tornado?

Yes.

[marmarek]

Just let dnf skip python2-tornado?

Yes.

[mathrack]

Beware that when upgrading from fedora-27 to fedora-28, the options recommended in the documentation (--best --allowerasing) lead to the deletion of qubes-mgmt-salt-vm-connector, qubes-vm-recommended, salt and salt-ssh if -x python2-tornado is not used.

[mathrack]

Beware that when upgrading from fedora-27 to fedora-28, the options recommended in the documentation (--best --allowerasing) lead to the deletion of qubes-mgmt-salt-vm-connector, qubes-vm-recommended, salt and salt-ssh if -x python2-tornado is not used.

[tasket]

Anyone know why Fedora would upgrade packages by a whole integer when their OS upgrade cycles are so short? It seems capricious.

[tasket]

Anyone know why Fedora would upgrade packages by a whole integer when their OS upgrade cycles are so short? It seems capricious.

[coeusite]

Can confirm the issue on R4.0. It is an upstream error.

[coeusite]

Can confirm the issue on R4.0. It is an upstream error.

[andrewdavidwong]

@marmarek, should this be closed as notourbug?

[andrewdavidwong]

@marmarek, should this be closed as notourbug?

[marmarek]

@marmarek, should this be closed as notourbug?

I'd say so.

[marmarek]

@marmarek, should this be closed as notourbug?

I'd say so.

[mvermaes]

This issue still exists with salt-2018.3.2-1.fc28.

While I understand this is a Fedora packaging issue, at least for me it does have the Qubes-specific effect that template VMs always remain in the state 'Updates pending!' according to Qubes Manager. I'm working around this by checking for updates daily, but maybe it's worth putting this in the docs somewhere, as it seems like it would be confusing for new users?

[mvermaes]

This issue still exists with salt-2018.3.2-1.fc28.

While I understand this is a Fedora packaging issue, at least for me it does have the Qubes-specific effect that template VMs always remain in the state 'Updates pending!' according to Qubes Manager. I'm working around this by checking for updates daily, but maybe it's worth putting this in the docs somewhere, as it seems like it would be confusing for new users?

[andrewdavidwong]

I don't think it needs to be documented, since it's only temporary. Also, there's a separate bug that causes the "updates pending" notification to persist incorrectly (#2009).

[andrewdavidwong]

I don't think it needs to be documented, since it's only temporary. Also, there's a separate bug that causes the "updates pending" notification to persist incorrectly (#2009).

[mvermaes]

In this case I had thought the notification was correct, since the python2-tornado package could not be updated. I was not seeing the 'updates pending' notification previously, unless there actually were updates available. So I think this is different from #2009.

Fair enough about the documentation, it seems like not many people are affected by this.

[mvermaes]

In this case I had thought the notification was correct, since the python2-tornado package could not be updated. I was not seeing the 'updates pending' notification previously, unless there actually were updates available. So I think this is different from #2009.

Fair enough about the documentation, it seems like not many people are affected by this.

[andrewdavidwong]

In this case I had thought the notification was correct, since the python2-tornado package could not be updated. I was not seeing the 'updates pending' notification previously, unless there actually were updates available. So I think this is different from #2009.

I wasn't saying that this is the same as #2009. Rather, I was just pointing out that there is a separate bug (#2009) that causes the same effect (persistence of the "updates pending" notification when it should not persist). You are correct that the notification is "correct" insofar as there is technically a package update available, but it the notification is "incorrect" in the sense that the persistence is unwanted and unuseful after a user updates in this situation. From the user's perspective, the notification persists when it shouldn't in both situations. So, if we were to document this general phenomenon of the notification persisting when it shouldn't, we would probably have to document both potential causes (or else risk providing the wrong explanation in cases in which the user is actually experiencing #2009).

[andrewdavidwong]

In this case I had thought the notification was correct, since the python2-tornado package could not be updated. I was not seeing the 'updates pending' notification previously, unless there actually were updates available. So I think this is different from #2009.

I wasn't saying that this is the same as #2009. Rather, I was just pointing out that there is a separate bug (#2009) that causes the same effect (persistence of the "updates pending" notification when it should not persist). You are correct that the notification is "correct" insofar as there is technically a package update available, but it the notification is "incorrect" in the sense that the persistence is unwanted and unuseful after a user updates in this situation. From the user's perspective, the notification persists when it shouldn't in both situations. So, if we were to document this general phenomenon of the notification persisting when it shouldn't, we would probably have to document both potential causes (or else risk providing the wrong explanation in cases in which the user is actually experiencing #2009).

[mathrack]

Something similar is happening with pulseaudio in all my fedora-28 based templates (R3.2). See below. Is it related or should I open another issue?

 Problem 1: package qubes-gui-vm-3.2.22-1.fc28.x86_64 requires pulseaudio = 11.1, but none of the providers can be installed
  - cannot install both pulseaudio-12.0-3.fc28.x86_64 and pulseaudio-11.1-18.fc28.1.x86_64
  - cannot install both pulseaudio-11.1-18.fc28.x86_64 and pulseaudio-12.0-3.fc28.x86_64
  - cannot install the best update candidate for package qubes-gui-vm-3.2.22-1.fc28.x86_64
  - cannot install the best update candidate for package pulseaudio-11.1-18.fc28.1.x86_64
 Problem 2: package salt-2018.3.2-1.fc28.noarch requires python-tornado < 5.0, but none of the providers can be installed
  - cannot install both python2-tornado-5.0.2-2.fc28.x86_64 and python2-tornado-4.5.2-2.fc28.x86_64
  - cannot install both python2-tornado-4.5.2-2.fc28.x86_64 and python2-tornado-5.0.2-2.fc28.x86_64
  - cannot install the best update candidate for package salt-2018.3.2-1.fc28.noarch
  - cannot install the best update candidate for package python2-tornado-4.5.2-2.fc28.x86_64
 Problem 3: problem with installed package qubes-gui-vm-3.2.22-1.fc28.x86_64
  - package qubes-gui-vm-3.2.22-1.fc28.x86_64 requires pulseaudio = 11.1, but none of the providers can be installed
  - package pulseaudio-11.1-18.fc28.1.x86_64 requires pulseaudio-libs(x86-64) = 11.1-18.fc28.1, but none of the providers can be installed
  - package pulseaudio-11.1-18.fc28.x86_64 requires pulseaudio-libs(x86-64) = 11.1-18.fc28, but none of the providers can be installed
  - cannot install both pulseaudio-libs-12.0-3.fc28.x86_64 and pulseaudio-libs-11.1-18.fc28.1.x86_64
  - cannot install both pulseaudio-libs-11.1-18.fc28.x86_64 and pulseaudio-libs-12.0-3.fc28.x86_64
  - cannot install the best update candidate for package pulseaudio-libs-11.1-18.fc28.1.x86_64

And

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 pulseaudio                                       x86_64                            11.1-18.fc28                                      fedora                              1.0 M
 pulseaudio                                       x86_64                            12.0-3.fc28                                       updates                             1.0 M
 pulseaudio-libs                                  x86_64                            11.1-18.fc28                                      fedora                              674 k
 pulseaudio-libs                                  x86_64                            12.0-3.fc28                                       updates                             685 k
 python2-tornado                                  x86_64                            5.0.2-2.fc28                                      updates                             746 k

[mathrack]

Something similar is happening with pulseaudio in all my fedora-28 based templates (R3.2). See below. Is it related or should I open another issue?

 Problem 1: package qubes-gui-vm-3.2.22-1.fc28.x86_64 requires pulseaudio = 11.1, but none of the providers can be installed
  - cannot install both pulseaudio-12.0-3.fc28.x86_64 and pulseaudio-11.1-18.fc28.1.x86_64
  - cannot install both pulseaudio-11.1-18.fc28.x86_64 and pulseaudio-12.0-3.fc28.x86_64
  - cannot install the best update candidate for package qubes-gui-vm-3.2.22-1.fc28.x86_64
  - cannot install the best update candidate for package pulseaudio-11.1-18.fc28.1.x86_64
 Problem 2: package salt-2018.3.2-1.fc28.noarch requires python-tornado < 5.0, but none of the providers can be installed
  - cannot install both python2-tornado-5.0.2-2.fc28.x86_64 and python2-tornado-4.5.2-2.fc28.x86_64
  - cannot install both python2-tornado-4.5.2-2.fc28.x86_64 and python2-tornado-5.0.2-2.fc28.x86_64
  - cannot install the best update candidate for package salt-2018.3.2-1.fc28.noarch
  - cannot install the best update candidate for package python2-tornado-4.5.2-2.fc28.x86_64
 Problem 3: problem with installed package qubes-gui-vm-3.2.22-1.fc28.x86_64
  - package qubes-gui-vm-3.2.22-1.fc28.x86_64 requires pulseaudio = 11.1, but none of the providers can be installed
  - package pulseaudio-11.1-18.fc28.1.x86_64 requires pulseaudio-libs(x86-64) = 11.1-18.fc28.1, but none of the providers can be installed
  - package pulseaudio-11.1-18.fc28.x86_64 requires pulseaudio-libs(x86-64) = 11.1-18.fc28, but none of the providers can be installed
  - cannot install both pulseaudio-libs-12.0-3.fc28.x86_64 and pulseaudio-libs-11.1-18.fc28.1.x86_64
  - cannot install both pulseaudio-libs-11.1-18.fc28.x86_64 and pulseaudio-libs-12.0-3.fc28.x86_64
  - cannot install the best update candidate for package pulseaudio-libs-11.1-18.fc28.1.x86_64

And

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 pulseaudio                                       x86_64                            11.1-18.fc28                                      fedora                              1.0 M
 pulseaudio                                       x86_64                            12.0-3.fc28                                       updates                             1.0 M
 pulseaudio-libs                                  x86_64                            11.1-18.fc28                                      fedora                              674 k
 pulseaudio-libs                                  x86_64                            12.0-3.fc28                                       updates                             685 k
 python2-tornado                                  x86_64                            5.0.2-2.fc28                                      updates                             746 k

[marmarek]

Something similar is happening with pulseaudio in all my fedora-28 based templates (R3.2).

This is #4072 , updated package already in current-testing repository (QubesOS/updates-status#589)

[marmarek]

Something similar is happening with pulseaudio in all my fedora-28 based templates (R3.2).

This is #4072 , updated package already in current-testing repository (QubesOS/updates-status#589)