Zypper asks two questions about libheif-svtenc-1.17.6-1.1.x86_64 ? Best solutiion?

English Applications
1

Running zypper brings two questions . . . not sure how to answer . . . . Recently TW has been moving apps away from Packman and to oppenSUSE, but in this case it seems like #1 is moving it to Packman?? And #2 seems to be providing the opposite, moving it to openSUSE?? How to best answer these two important questions??

You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
2 Problems:
Problem: the to be installed libheif-svtenc-1.17.6-1.1.x86_64 requires 'libheif1 = 1.17.6-1.1', but this requirement cannot be provided
Problem: the to be installed libheif-rav1e-1.17.6-1.1.x86_64 requires 'libheif1 = 1.17.6-1.1', but this requirement cannot be provided

Problem: the to be installed libheif-svtenc-1.17.6-1.1.x86_64 requires 'libheif1 = 1.17.6-1.1', but this requirement cannot be provided
  not installable providers: libheif1-1.17.6-1.1.x86_64[download.opensuse.org-oss]
                   libheif1-1.17.6-1.1.x86_64[openSUSE-20220916-0]
 Solution 1: install libheif-svtenc-1.17.6-1699.4.pm.3.x86_64 from vendor http://packman.links2linux.de
  replacing libheif-svtenc-1.17.5-3.1.x86_64 from vendor openSUSE
 Solution 2: install libheif1-1.17.6-1.1.x86_64 from vendor openSUSE
  replacing libheif1-1.17.5-1699.6.pm.4.x86_64 from vendor http://packman.links2linux.de
 Solution 3: keep obsolete libheif-svtenc-1.17.5-3.1.x86_64
 Solution 4: break libheif-svtenc-1.17.6-1.1.x86_64 by ignoring some of its dependencies
2

@non_space No, it’s just maintained on openSUSE, when it hits factory it rebuilds on packman, but there is a delay for it to hit the Tumbleweed repos, you need to select Solution 1 to stay on the Packman ones…

2 Likes
3

See also:

1 Like
4

@malcolmlewis && @hui

So, choosing #1 moves it up to two more problems, which does seem to relate to @hui’s link, but that was a lot of data, in this new set, there doesn’t seem to be any options for Packman?? It just says, “do not install”??

2 Problems:
Problem: the to be installed gdk-pixbuf-loader-libheif-1.17.6-1.1.x86_64 requires 'libheif1 = 1.17.6-1.1', but this requirement cannot be provided
Problem: the to be installed libMagickCore-7_Q16HDRI10-7.1.1.25-2.1.x86_64 requires 'libheif.so.1()(64bit)', but this requirement cannot be provided

Problem: the to be installed gdk-pixbuf-loader-libheif-1.17.6-1.1.x86_64 requires 'libheif1 = 1.17.6-1.1', but this requirement cannot be provided
  not installable providers: libheif1-1.17.6-1.1.x86_64[download.opensuse.org-oss]
                   libheif1-1.17.6-1.1.x86_64[openSUSE-20220916-0]
 Solution 1: do not install gdk-pixbuf-loader-libheif-1.17.6-1.1.x86_64
 Solution 2: do not install libheif-svtenc-1.17.6-1699.4.pm.3.x86_64
 Solution 3: break gdk-pixbuf-loader-libheif-1.17.6-1.1.x86_64 by ignoring some of its dependencies
5

If you read the linked thread you would find the easy solution: simply do the update from packman again (vendor switch) and everything is solved without questions…

sudo zypper dist-upgrade --from packman --allow-vendor-change
6

Scanned through it, a bit jammed here for time, didn’t get to that simple command . . . but in running that command it brings:

Computing distribution upgrade...
Repository 'packman' not found by its alias, number, or URI.
Use 'zypper repos' to get the list of defined repositories.
7

@non_space If you run zypper lr -E and use the alias for your setup instead of packman.

8

I tried to run this “sudo zypper dist-upgrade --from Packman Repo --allow-vendor-change” and got :

sudo zypper dist-upgrade --from Packman Repo --allow-vendor-change
Loading repository data...
Reading installed packages...
Too many arguments.
9

If the alias is Packman Repo than you need to put it in quotes…blanks need to be put in quotation marks…
sudo zypper dist-upgrade --from "Packman Repo" --allow-vendor-change

1 Like
10

I’m not sure what you are saying “alias”?? You mean as I tried to do using “Packman Repo” which is what shows in the repo ref listing???

11

@non_space as @hui indicated, if you have spaces in names (consider using a - :wink: ) they have to be quoted…

1 Like
12

Gents, OK thanks for the precise details, that did go through with “17” packages changing vendor to Packman and “23” to upgrade . . . which was a lower number than the package updater applet had shown. After those packages ran through I again ran the regular “ref && dup -l” and got another “213” to upgrade, which was higher that the applet showed.

I thought that adding the “dup -l” was the “accept all changes” modifier?? Again, this, “we are changing everything from packman to openSUSE vendor” a few weeks ago . . . to now “we are changing a bunch of packages back to Packman vendor” thing is a bit “confusing” for the “daily driver” of TW???

13

See man zypper…
dup -l stands for:

-l, --auto-agree-with-licenses
Automatically say ‘yes’ to third party license confirmation prompt. By using this option, you choose to agree with licenses of all
third-party software this command will install. This option is particularly useful for administators installing the same set of
packages on multiple machines (by an automated process) and have the licenses confirmed before.

1 Like
14

Hmm . . . OK, must have come in at some point when I was using proprietary Nvidia driver?? Or, would that apply for nouveau as well??

15

Only Nvidia, not nouveau…

1 Like
16

If unsure don’t answer. Reconfigure zypper instead: Zypper dup priorities

Was annoyed answering recurring questions and fixed configuration.

17

If one is unsure to answer a zypper solver case, the best solution is to ask in the forum as the TO did.

Karls tip is not advised for normal users nor admins. Doing upgrades in the background without any control or possibility to interfere can be considered as a straight path to a compromised system…

1 Like
18

@karlmistelberger

OK, yes, the recurring questions were a pain . . . but I don’t know if one solution would cover all eventualities?? Seems like from a brief read of the link, your command would essentially change the “zypper dup” default of “no allow vendor change” to mean “allow vendor change”??? Which in an ideal world would be OK, but I do recall seeing TW changes that the answer was “don’t do it”???

The suggestions here did move my TW system through the zyppering gauntlet of questions . . . since it seems like the changes of vendors are “tidal” . . . moving back and forth, it might indeed be smoother to just “flow with them” as flotsam, letting the system flow along, or to coin a phrase, “tumble” along with the changes, by “allowing vendor change” to become the default setting??

Seems like in the open source world it is near impossible to prevent all system blow ups . . . total control seems a difficult goal to actually hold onto. : - )

19

Basically the suggestion is to allow anything:

erlangen:~ # zypper dist-upgrade --allow-
--allow-arch-change    --allow-downgrade      --allow-name-change    --allow-vendor-change  
erlangen:~ #

Users may try out and revert based on real life experience.

Priorities do matter. I current use three levels, default (99), low (100) and high (90):

erlangen:~ # repos
#  | Alias                               | Enabled | GPG Check | Refresh | Priority | URI
---+-------------------------------------+---------+-----------+---------+----------+-------------------------------------------------------------------------------------------------------
 7 | Packman                             | Yes     | (r ) Yes  | Yes     |   90     | http://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/
23 | non-oss                             | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/non-oss/
25 | oss                                 | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/oss/
32 | update                              | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/update/tumbleweed/
 4 | Geo                                 | Yes     | (r ) Yes  | Yes     |  100     | https://download.opensuse.org/repositories/Application:/Geo/openSUSE_Tumbleweed/
12 | google-chrome                       | Yes     | (r ) Yes  | Yes     |  100     | https://dl.google.com/linux/chrome/rpm/stable/x86_64
18 | home_eyecreate_branches_filesystems | Yes     | (r ) Yes  | Yes     |  100     | https://download.opensuse.org/repositories/home:/eyecreate:/branches:/filesystems/openSUSE_Tumbleweed/
19 | home_kukuk_qmapshack                | Yes     | (r ) Yes  | Yes     |  100     | https://download.opensuse.org/repositories/home:/kukuk:/qmapshack/openSUSE_Tumbleweed/
20 | jalbum                              | Yes     | (  ) No   | Yes     |  100     | https://jalbum.net/download/software/yumrepo/
22 | myrepo                              | Yes     | (  ) No   | Yes     |  100     | dir:/home/karl/Downloads/myrepo
erlangen:~ #

Using priorities dampens tidal effects.

Currently I am closely monitoring six Tumbleweed systems set up for daily dup. I am still waiting for support calls caused by the above configuration.

Sample operation:

root@freiburg: ~
# journalctl -q -u dupa -g Consumed
Nov 18 09:59:49 freiburg systemd[1]: dupa.service: Consumed 30.021s CPU time.
Nov 19 11:06:31 freiburg systemd[1]: dupa.service: Consumed 45.277s CPU time.
Nov 21 07:32:11 freiburg systemd[1]: dupa.service: Consumed 10.031s CPU time.
Nov 22 07:34:16 freiburg systemd[1]: dupa.service: Consumed 33.055s CPU time.
Nov 23 00:01:38 freiburg systemd[1]: dupa.service: Consumed 47.263s CPU time.
Nov 24 08:00:45 freiburg systemd[1]: dupa.service: Consumed 13.337s CPU time.
Nov 25 12:34:45 freiburg systemd[1]: dupa.service: Consumed 33.238s CPU time.
Nov 26 10:50:06 freiburg systemd[1]: dupa.service: Consumed 5.476s CPU time.
Nov 28 16:43:05 freiburg systemd[1]: dupa.service: Consumed 9.756s CPU time.
Nov 29 11:47:17 freiburg systemd[1]: dupa.service: Consumed 15.317s CPU time.
Dec 01 06:10:45 freiburg systemd[1]: dupa.service: Consumed 1min 15.726s CPU time.
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Consumed 3.669s CPU time.
Dec 02 09:52:56 freiburg systemd[1]: dupa.service: Consumed 1min 16.928s CPU time.
Dec 03 10:04:46 freiburg systemd[1]: dupa.service: Consumed 16.053s CPU time.
Dec 04 07:26:00 freiburg systemd[1]: dupa.service: Consumed 26.069s CPU time.
Dec 08 07:16:36 freiburg systemd[1]: dupa.service: Consumed 32.192s CPU time.
Dec 08 07:22:26 freiburg systemd[1]: dupa.service: Consumed 2.215s CPU time.
Dec 09 08:49:41 freiburg systemd[1]: dupa.service: Consumed 38.853s CPU time.
Dec 10 11:12:00 freiburg systemd[1]: dupa.service: Consumed 31.018s CPU time.
Dec 11 07:25:53 freiburg systemd[1]: dupa.service: Consumed 1min 7.269s CPU time.
Dec 12 07:08:47 freiburg systemd[1]: dupa.service: Consumed 8.498s CPU time.
Dec 13 07:17:01 freiburg systemd[1]: dupa.service: Consumed 13.047s CPU time.
Dec 14 07:20:26 freiburg systemd[1]: dupa.service: Consumed 51.928s CPU time.
Dec 16 09:20:58 freiburg systemd[1]: dupa.service: Consumed 21.752s CPU time.
Dec 17 11:09:01 freiburg systemd[1]: dupa.service: Consumed 1min 13.847s CPU time.
Dec 19 07:12:53 freiburg systemd[1]: dupa.service: Consumed 34.373s CPU time.
Dec 20 06:34:55 freiburg systemd[1]: dupa.service: Consumed 7.342s CPU time.
Dec 21 07:33:04 freiburg systemd[1]: dupa.service: Consumed 20.016s CPU time.
Dec 22 20:22:07 freiburg systemd[1]: dupa.service: Consumed 30.411s CPU time.
Dec 23 17:06:30 freiburg systemd[1]: dupa.service: Consumed 10.913s CPU time.
Dec 27 00:00:48 freiburg systemd[1]: dupa.service: Consumed 11.078s CPU time.
Dec 28 11:17:59 freiburg systemd[1]: dupa.service: Consumed 24.132s CPU time.
Jan 04 10:00:29 freiburg systemd[1]: dupa.service: Consumed 9.745s CPU time.
Jan 05 13:57:56 freiburg systemd[1]: dupa.service: Consumed 6.676s CPU time.
Jan 06 00:04:27 freiburg systemd[1]: dupa.service: Consumed 1min 29.221s CPU time.
Jan 07 10:24:22 freiburg systemd[1]: dupa.service: Consumed 29.823s CPU time.
Jan 08 07:33:37 freiburg systemd[1]: dupa.service: Consumed 5.806s CPU time.
Jan 09 07:19:12 freiburg systemd[1]: dupa.service: Consumed 9.676s CPU time.
Jan 10 00:00:37 freiburg systemd[1]: dupa.service: Consumed 10.055s CPU time.

root@freiburg: ~
#

Failures:

root@freiburg: ~
# journalctl -q -u dupa -p4
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Failed with result 'exit-code'.
Jan 04 09:40:38 freiburg systemd[1]: dupa.service: Failed with result 'exit-code'.

root@freiburg: ~
#

Enabling wake on lan affected NetworkManager-wait-online.service and caused this:

root@freiburg: ~
# journalctl  -b 70a89fb9dab24d579f0c0ff336cf5e10 -u dupa -g failed
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error message: Failed to connect to download.opensuse.org port 80 after 0 ms: Couldn't connect to server
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error message: Failed to connect to download.opensuse.org port 80 after 0 ms: Couldn't connect to server
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error message: Failed to connect to download.opensuse.org port 443 after 0 ms: Couldn't connect to server
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:37 freiburg zypper[32204]: Error code: Connection failed
Jan 04 09:40:38 freiburg systemd[1]: dupa.service: Failed with result 'exit-code'.

root@freiburg: ~
#

Got fixed by this local check:

root@freiburg: ~
# cat /usr/local/bin/check-opensuse.sh
#!/usr/bin/env bash 

while :; do
    curl -s -I download.opensuse.org | grep '200 OK' &>/dev/null && exit 0
    sleep 1
    echo sleep
done 

root@freiburg: ~
#

This was caused by selecting an improper repo:

Dec 02 08:52:59 freiburg systemd[1]: Starting dist upgrade...
Dec 02 08:53:05 freiburg check-opensuse.sh[26073]: sleep
Dec 02 08:53:06 freiburg systemd[1]: Started dist upgrade.
Dec 02 08:53:06 freiburg zypper[26541]: Retrieving repository 'Haupt-Repository (NON-OSS)' metadata [........done]
Dec 02 08:53:06 freiburg zypper[26541]: Building repository 'Haupt-Repository (NON-OSS)' cache [...done]
Dec 02 08:53:12 freiburg zypper[26541]: Retrieving repository 'Haupt-Repository (OSS)' metadata [...............................................................done]
Dec 02 08:53:14 freiburg zypper[26541]: Building repository 'Haupt-Repository (OSS)' cache [....done]
Dec 02 08:53:15 freiburg zypper[26541]: Retrieving repository 'Branch project for package btrbk (openSUSE_Tumbleweed)' metadata [......done]
Dec 02 08:53:15 freiburg zypper[26541]: Building repository 'Branch project for package btrbk (openSUSE_Tumbleweed)' cache [...done]
Dec 02 08:53:17 freiburg zypper[26541]: Retrieving repository 'Visual Studio Code' metadata [.....done]
Dec 02 08:53:17 freiburg zypper[26541]: Building repository 'Visual Studio Code' cache [...done]
Dec 02 08:53:17 freiburg zypper[26541]: Loading repository data...
Dec 02 08:53:17 freiburg zypper[26541]: Reading installed packages...
Dec 02 08:53:17 freiburg zypper[26541]: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about thi>
Dec 02 08:53:17 freiburg zypper[26541]: Computing distribution upgrade...
Dec 02 08:53:17 freiburg zypper[26541]: Problem: nothing provides 'perl(:MODULE_COMPAT_5.38.2)' needed by the to be installed btrbk-0.32.6-5.17.noarch
Dec 02 08:53:17 freiburg zypper[26541]:  Solution 1: deinstallation of btrbk-0.32.6-5.16.noarch
Dec 02 08:53:17 freiburg zypper[26541]:  Solution 2: keep obsolete btrbk-0.32.6-5.16.noarch
Dec 02 08:53:17 freiburg zypper[26541]:  Solution 3: break btrbk-0.32.6-5.17.noarch by ignoring some of its dependencies
Dec 02 08:53:17 freiburg zypper[26541]: Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Main process exited, code=exited, status=4/NOPERMISSION
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Failed with result 'exit-code'.
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Triggering OnFailure= dependencies.
Dec 02 08:53:17 freiburg systemd[1]: dupa.service: Consumed 3.669s CPU time.

Got fixed by changing the repo to a working one.

1 Like
20

@karlmistelberger

Very “permissive” of you . . . so, being of simple mind, I was looking for a simple command to do what you are suggesting. Today I’m in Leap 15.6, which has not been trouble free itself . . . I ran the “sudo zypper dup priorities” and it brought back a bunch of modifiers, including those you listed about “allowing X & Y” down in the “expert options” . . . so that would mean adding in your various “allow” modifiers manually?? I’m assuming the “–allow-” is a typo? I didn’t see any such plain, just “allow-” in that list?

I guess those commands could be reserved for when there are these similar questions asked about package changes, and if there are none then there would be no need for any of them, just the regular “zypper dup”?

As far as adjusting the priorities of the repos, other have mentioned doing that, I could try to edit those numbers or check them, but assuming it is something that would be “nano’d” . . . or would that be edited in YaSt “software repository” on a line item basis?