This seems to be a libspdlog packaging problem, since the mangohud package is affected too:
Problem: 1: the to be installed mangohud-0.7.2-1.2.x86_64 requires 'libspdlog.so.1.14(FMT_v11)(64bit)', but this requirement cannot be provided
not installable providers: libspdlog1_14-1.14.1-3.1.x86_64[openSUSE:repo-oss]
Solution 1: Following actions will be done:
remove lock to allow removal of libspdlog1_14-1.14.1-2.1.x86_64
deinstallation of patterns-sway-sway-20200619-6.3.x86_64
deinstallation of sway-branding-openSUSE-0.16.2-1.1.noarch
deinstallation of openSUSEway-0.16.2-1.1.noarch
deinstallation of patterns-openSUSEway-0.16.2-1.1.noarch
Solution 2: Following actions will be done:
deinstallation of mangohud-0.7.2-1.1.x86_64
deinstallation of goverlay-1.1.1-1.1.x86_64
Solution 3: keep obsolete mangohud-0.7.2-1.1.x86_64
Solution 4: break mangohud-0.7.2-1.2.x86_64 by ignoring some of its dependencies
No, the other thread is not relevant. The problem there was an improperly configured repo (missing auto refresh flag). The problem of the other thread is solved and not related at all with the one from this thread.
I agree that it was probably a bit careless of me to jump the gun there, since the thread is definitely about VSCode, and technically this particular issue was not being discussed there. However, the improperly configured repo was not the only issue present in that post:
Problem: 1: nothing provides 'libspdlog.so.1.14(FMT_v10)(64bit)' needed by the to be installed code-1.90.2-1.1.x86_64
Solution 1: do not install code-1.90.2-1.1.x86_64
Solution 2: break code-1.90.2-1.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
From the OP.
I do apologize though, since that would not have been the best place to continue this discussion.
Did you actually read the terminal output? You created the problem yourself by locking libspdlog. Remove the lock and the installation will succeed.
tumblevb@test:~> LAMG=C sudo zypper in mangohud
[sudo] password for root:
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is suggested, but will not be installed:
goverlay
The following 3 NEW packages are going to be installed:
libfmt11 libspdlog1_14 mangohud
3 new packages to install.
Package download size: 1,6 MiB
Package install size change:
| 6,7 MiB required by to be installed packages
6,7 MiB | - 0 B released by to be removed packages
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y):
Retrieving: libfmt11-11.0.2-1.1.x86_64 (repo-oss) (1/3), 77,2 KiB
Retrieving: libfmt11-11.0.2-1.1.x86_64.rpm .............................................................................................................................................................................................................................[done]
Retrieving: libspdlog1_14-1.14.1-3.1.x86_64 (repo-oss) (2/3), 119,7 KiB
Retrieving: libspdlog1_14-1.14.1-3.1.x86_64.rpm ........................................................................................................................................................................................................................[done]
Retrieving: mangohud-0.7.2-1.2.x86_64 (repo-oss) (3/3), 1,4 MiB
Retrieving: mangohud-0.7.2-1.2.x86_64.rpm ..................................................................................................................................................................................................................[done (3,8 MiB/s)]
Checking for file conflicts: ...........................................................................................................................................................................................................................................[done]
(1/3) Installing: libfmt11-11.0.2-1.1.x86_64 ...........................................................................................................................................................................................................................[done]
(2/3) Installing: libspdlog1_14-1.14.1-3.1.x86_64 ......................................................................................................................................................................................................................[done]
(3/3) Installing: mangohud-0.7.2-1.2.x86_64 ............................................................................................................................................................................................................................[done]
Running post-transaction scripts .......................................................................................................................................................................................................................................[done]
tumblevb@test:~>
Really? Did you actually test it yourself (VMs are great for such stuff!)? The issue from the other thread was caused because the refresh was disabled and zypper was not able to find the outdated code package in the cache on the server anymore. The libspdlog was a red herring in this case. This can easily be seen by checking the different code package versions.
I am trying to understand the problem.
When I run sudo zypper dup (even after sudo zypper ref),
I get the same block as OP here, in regards to waybar. No mention of a locked package. The lock only happens as a result of “keep obsolete libspdlog . . .”
If I choose Solution 3 (break waybar, ignore dependency), then:
Problem: 2: the installed waybar-0.10.3-1.1.x86_64 requires 'libspdlog.so.1.14(FMT_v10)(64bit)', but this requirement cannot be provided
deleted providers: libspdlog1_14-1.14.1-2.1.x86_64
Solution 1: Following actions will be done:
deinstallation of patterns-sway-sway-20200619-6.3.x86_64
deinstallation of openSUSEway-0.16.2-1.1.noarch
deinstallation of patterns-openSUSEway-0.16.2-1.1.noarch
Solution 2: deinstallation of mangoapp-0.7.2-1.1.x86_64
Solution 3: keep obsolete mangoapp-0.7.2-1.1.x86_64
Solution 4: break waybar-0.10.3-1.1.x86_64 by ignoring some of its dependencies
Now the issue with mangohud is not with a locked libspdlog package, though it is interesting that solution 4 involves waybar.
Please tell me what I am missing here. I am not familiar with zypper, so I am probably making misguided assumptions.
(I realize the block mentions mangoapp, but mangohud is affected too)
The mangohud problem on your system is caused when you choose to keep the obsolete libspdlog1_14-1.14.1-2.1. package. Therefore libspdlog1_14 cannot be updated on your system and that leads to the error that mangohud wants to be removed as it already depends on the newer libspdlog1_14-1.14.1-3.1. version. Keeping obsolete packages can cause much more issues than removing a temporarely broken package.
I really do not mean to argue, but I am confused how it can be locked, even if I do not instruct it to keep the obsolete package. See running sudo zypper in mangohud:
Problem: 1: the to be installed mangohud-0.7.2-1.2.x86_64 requires 'libspdlog.so.1.14(FMT_v11)(64bit)', but this requirement cannot be provided
not installable providers: libspdlog1_14-1.14.1-3.1.x86_64[openSUSE:repo-oss]
Solution 1: Following actions will be done:
deinstallation of waybar-0.10.3-1.1.x86_64
deinstallation of patterns-sway-sway-20200619-6.3.x86_64
deinstallation of sway-branding-openSUSE-0.16.2-1.1.noarch
deinstallation of openSUSEway-0.16.2-1.1.noarch
deinstallation of patterns-openSUSEway-0.16.2-1.1.noarch
Solution 2: do not install mangohud-0.7.2-1.2.x86_64
Solution 3: break mangohud-0.7.2-1.2.x86_64 by ignoring some of its dependencies
Same issue, different package. Now if there was a lock on a package providing the library, I would like to know how I can remove it, given that I do not know what package name to specify for zypper rl.
Now, are you saying that particular bug is a conflict involving only waybar package, and, the newer libspd version cannot be updated because of that, and since mangohud depends on the new version (but is not part of the problem itself), it cannot use the obsolete package?
Aditionally, please always post the full terminal output including the initial command. By ommiting terminal output nobody knows what you are doing.
As example your output from this, this and this post differ. So it seems you are using different commands, but nobody knows as you are hiding some informations.
dgrif12@localhost:~> zypper ll
There are no package locks defined.
Something I missed:
Problem: 1: the installed waybar-0.10.3-1.1.x86_64 requires 'libspdlog.so.1.14(FMT_v10)(64bit)', but this requirement cannot be provided
deleted providers: libspdlog1_14-1.14.1-2.1.x86_64
Problem: 1: the to be installed mangohud-0.7.2-1.2.x86_64 requires 'libspdlog.so.1.14(FMT_v11)(64bit)', but this requirement cannot be provided
not installable providers: libspdlog1_14-1.14.1-3.1.x86_64[openSUSE:repo-oss]
So my misunderstanding is that mangohud was affected by the deleted (older) provider libspdlog1_14-1.14.1-2.1.x86_64, but it just depended on the newer provider that could not be installed because waybar depends on the older version?
Yep. Thats it. The new libspdlog is compatible with mangohud. So mangohud could be installed if you wont have waybar installed which needs the no longer available old libspdlog package.
Is there an ETA on when this will be fixed?
I see that currently waybar succeeds building with libspdlog.so.1.14(FMT_v11) in Factory, however and no matter how many times I refresh the repos zypper notifies about waybar depending on libspdlog.so.1.14(FMT_v10) (which is no longer provided by libspdlog1_14 package)
By checking the relevant communication channels, the next sway QA test is scheduled for Build 20240728.
The sway QA test for Build 20240726 still failed.