Odd issue with packman and a fresh slowroll installation

marjoryTrashHeap · July 20, 2025, 5:20pm

I’ve got a fresh installation of Slowroll, that I would like to use with Packman, as I’d like to get hardware video decoding going.

However, the copy of libavcodec61 in Packman seems to be dependent on librav1e0_7. However, it looks to me as if slowroll moved on from librav1e0_7 and is now on librav1e0_8 ?

I’ve double-checked that I am using the correct packman repos for slowroll, and I have tried a couple different mirrors. I realize Packman is unsupported, but assistance would be appreciated.

Zypper output:

24 Problems:
Problem: 1: nothing provides 'librav1e.so.0.7' needed by the to be installed libavcodec61-32bit-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 2: nothing provides 'librav1e.so.0.7' needed by the to be installed libheif-rav1e-1.19.8-1699.4.pm.4.i586
Problem: 3: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.i586
Problem: 4: nothing provides 'librav1e.so.0.7' needed by the to be installed libavcodec58_134-4.4.6-1699.4.0.7.pm.1.i586
Problem: 5: nothing provides 'librav1e.so.0.7' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.i586
Problem: 6: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 7: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec58_134-4.4.6-1699.4.0.7.pm.1.x86_64
Problem: 8: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 9: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0()(64bit)' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.x86_64
Problem: 10: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 11: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0()(64bit)' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.x86_64
Problem: 12: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 13: the installed Mesa-32bit-25.1.5-419.1.x86_64 requires 'Mesa = 25.1.5', but this requirement cannot be provided
Problem: 14: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0()(64bit)' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.x86_64
Problem: 15: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec58_134-4.4.6-1699.4.0.7.pm.1.x86_64
Problem: 16: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 17: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 18: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 19: nothing provides 'librav1e.so.0.7()(64bit)' needed by the to be installed libavcodec61-7.1.1-1699.6.0.6.pm.1.x86_64
Problem: 20: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0()(64bit)' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.x86_64
Problem: 21: nothing provides 'libabsl_log_internal_check_op.so.2501.0.0()(64bit)' needed by the to be installed vlc-noX-3.0.21-1699.7.0.5.pm.1.x86_64
Problem: 22: the installed Mesa-25.1.5-419.1.x86_64 requires 'Mesa-dri = 25.1.5', but this requirement cannot be provided
Problem: 23: the to be installed libpostproc55_9-4.4.6-1699.4.0.7.pm.1.x86_64 requires 'libavutil.so.56.70()(64bit)', but this requirement cannot be provided
not installable providers: libavutil56_70-4.4.6-1699.4.0.7.pm.1.x86_64[packman]
                   libavutil56_70-4.4.6-3.0.2.2.sr20250601.x86_64[repo-update]

Problem: 24: the to be installed Mesa-32bit-25.1.3-417.1.x86_64 requires 'Mesa-dri-32bit = 25.1.3', but this requirement cannot be provided
not installable providers: Mesa-dri-32bit-25.1.3-417.1.x86_64[repo-update]


Problem: 1: nothing provides 'librav1e.so.0.7' needed by the to be installed libavcodec61-32bit-7.1.1-1699.6.0.6.pm.1.x86_64
 Solution 1: Following actions will be done:
  deinstallation of libavcodec61-32bit-7.1.1-7.1.x86_64
  deinstallation of pipewire-modules-0_3-32bit-1.4.6-1.1.x86_64
 Solution 2: keep obsolete libavcodec61-32bit-7.1.1-7.1.x86_64
 Solution 3: break libavcodec61-32bit-7.1.1-1699.6.0.6.pm.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c):

marjoryTrashHeap · July 20, 2025, 5:42pm

My Repositories:

Repository priorities in effect:                                                                                                                                                                                        (See 'zypper lr -P' for details)
      70 (raised priority)  :  1 repository
      80 (raised priority)  :  1 repository
      99 (default priority) :  3 repositories

# | Alias               | Name                                   | Enabled | GPG Check | Refresh
--+---------------------+----------------------------------------+---------+-----------+--------
1 | openSUSE-20250701-0 | openSUSE-20250701-0                    | No      | ----      | ----
2 | packman             | Packman                                | Yes     | (r ) Yes  | Yes
3 | repo-debug          | openSUSE-Slowroll-Debug                | No      | ----      | ----
4 | repo-non-oss        | openSUSE-Slowroll-Non-Oss              | Yes     | (r ) Yes  | Yes
5 | repo-openh264       | Open H.264 Codec (openSUSE Tumbleweed) | Yes     | (r ) Yes  | Yes
6 | repo-oss            | openSUSE-Slowroll-Oss                  | Yes     | (r ) Yes  | Yes
7 | repo-source         | openSUSE-Slowroll-Source               | No      | ----      | ----
8 | repo-update         | openSUSE-Slowroll-Update               | Yes     | (r ) Yes  | Yes

Contents of: /etc/zypp/repos.d/packman.repo

[packman]
name=Packman
baseurl=https://ftp.fau.de/packman/suse/openSUSE_Slowroll/
enabled=1
type=rpm-md
gpgcheck=1
gpgkey=https://ftp.fau.de/packman/suse/openSUSE_Slowroll/repodata/repomd.xml.key
autorefresh=1
priority=70

hui · July 20, 2025, 5:45pm

In this case the packman repo for Slowroll lags behind the main openSUSE repos. So you can only wait (or don’t use packman temporarly).

hcvv · July 20, 2025, 5:53pm

We can not see what you did (that is why we ask to include the line with the prompt and the command in your copy/paste, it is only oneline more), but you used a command that does not show the most important column: the URL.

You tried to remedy this by showing the contents of the Packman repo file (again without command, but with some story telling instead). But there is not need when you use e.g.

zypper lr -d

Just for next time.

marjoryTrashHeap · July 20, 2025, 6:09pm

In this case the packman repo for Slowroll lags behind the main openSUSE repos. So you can only wait (or don’t use packman temporarly).

Gotcha, do you know how long the lag is? As this has already been going on for about a day?

hui · July 20, 2025, 6:13pm

It is a third party repo which is not controlled by openSUSE. You may contact Packman…
https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

They have some problems atm with publishing actual versions to the mirrors.

Metakw · July 21, 2025, 9:44pm

I too have the same problem.

marjoryTrashHeap · July 22, 2025, 1:15am

From what I gather from the mailing list archives, it looks like Packman has been broken since July 6th, and the team is aware. The relevant thread is “[Packman] Publishing Fails”

https://lists.links2linux.de/pipermail/packman/2025-July/thread.html

Presumably, when it is fixed, the dates for the past twenty updated packages on the home page will begin looking a bit fresher. http://packman.links2linux.org

oldcpu · August 14, 2025, 5:31am

I am tempted to install ‘slowroll’ … probably in December, after first updating to LEAP-16.0 in December.

My view is that this ‘odd issue’ is actually a good thing in that it illustrates the Packman packagers are doing a good job in ensuring their rpm spec files appropriately flag the dependencies of the Packman packaged apps.

What would be worse in my view, would be for the rpm spec files (created by Packman for Packman packaged apps) to not have the correct dependencies flagged, and hence a ‘slowroll’ update could break the not-mentioned dependencies of the Packman packaged apps, and such apps could stop working.

I am curious to learn how this will play with LEAP-16.0 with its different underlying ALP coming. Might it reduce the dependency many of us have on Packman packaged apps?

Edit: Typo fixed.