Packman discontinued from Jan 1st 2027, but here's your chance!

ugjka · September 4, 2026, 7:43pm

Oh I dont need patched mesa and vlc repo, vivaldi and vlc from flatpak are hw accelerated already neat

notsoran.domuser · September 4, 2026, 10:20pm

Thanks to the messenger, despite the message.

I will miss it…

notsoran.domuser · September 4, 2026, 11:02pm

just reencode your videos to av1/opus and you will never have a problem anymore with codecs, and in the process you will free a lot of storage…

ugjka · September 5, 2026, 3:33pm

I believe If you get Handbrake from flatpak you get all codec support

fstue · September 5, 2026, 3:59pm

This is the typical problem with absolute statements in a larger group - they are wrong more often than not. (No hard feelings here, and no bad intentions assumed. =)

I’m using an AMD GCN Gen1 GPU (R9 270X), and it’s still perfectly suitable for everything I intend to do with my box. But, to the best of my knowledge, I wouldn’t have hardware acceleration available if Packman wasn’t providing customised versions of Mesa. And thankworthily, they still do:

zypper se -si mesa
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                      | Type  | Version           | Arch   | Repository
---+---------------------------+-------+-------------------+--------+----------------
i+ | Mesa                      | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i  | Mesa-demo-egl             | Paket | 9.0.0-160000.2.2  | x86_64 | repo-oss (16.0)
i+ | Mesa-demo-x               | Paket | 9.0.0-160000.2.2  | x86_64 | repo-oss (16.0)
i+ | Mesa-dri                  | Paket | 24.3.3-160000.3.6 | x86_64 | Packman
i+ | Mesa-gallium              | Paket | 24.3.3-160000.3.6 | x86_64 | Packman
i+ | Mesa-KHR-devel            | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libEGL-devel         | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libEGL1              | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libGL-devel          | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libGL1               | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libglapi0            | Paket | 24.3.3-160000.3.2 | x86_64 | Packman
i+ | Mesa-libva                | Paket | 24.3.3-160000.3.6 | x86_64 | Packman
i+ | Mesa-vulkan-device-select | Paket | 24.3.3-160000.3.6 | x86_64 | Packman

I could probably replace most other Packman-built packages in use here with versions from the VLC repos, but does someone know an alternative for the acceleration enabled Mesa libs, other than trying to build oneself?

Don’t know if they follow this discussion, but I’d also like to give a big fat THANK YOU!!! to the people behind Packman for doing what they did during the last 25 years.

I’d certainly not have considered (open)SuSE for 10 ms if Packman hadn’t existed, and while I did a full zypper dup from Packman right after my last clean install (15.3, if I remember correctly) and left the repo enabled during all subsequent upgrades (15.3>15.4>15.5>15.6>16.0), I never had a single problem with dependencies that could not be resolved by one or two a/b choices during a dup.

malcolmlewis · September 5, 2026, 4:26pm

It is early days and a suitable provider may be found between now and the end of the year…

The _constraints file for Mesa shows 20GB of ram required for building…

OrsoBruno · September 5, 2026, 5:44pm

Launched in 2013, wonder how many are still in active service today and long abandoned by the Win world I guess.
No offence, I still have a working box from 2007 but it is “collecting dust in the basement” and writing this from a 2015 box whose Nvidia Maxwell is going to be unsupported in a year or so. 10 years of active support is an “epoch” by today’s standards in electronics and when that is no more practical let’s move on.

fstue · September 5, 2026, 6:05pm

I’m using the card under Win as well.
You’re right of course, the driver support stopped long ago, but under Win10, my driver from ~2016 (or 2018?) still offers the full functionality the card has to offer, and it even does on a test install of Windows 11.
If there’s no alternative and self-building does not work (my box is far away from 20GB RAM…) I might keep the last Packman-built version, but I’m not sure for how long that’ll work, since driver interfaces seem to change in incompatible ways much faster on Linux than on Windows.

Kalyr · September 6, 2026, 2:10am

correct me if im wrong but… once packman goes away, no more hardware video decoding on firefox right ? it feels like a forced migration to flatpaks, the firefox RPM would become unusable on AMD GPUs, and i assume many other things, OBS Studio, and others

flatpaks aren’t perfect, for example password managers can’t communicate with a flatpak firefox (such as keepassxc), and you have to tinker a lot just to get it to work, which should NOT even be a problem to begin with.

why are those packman mesa packages required to begin with ? why can’t we just do hardware video enc/decoding with the OSS packages ? i know that there’s a licensing issue with codecs which is why openSUSE can’t deliver them easily, but i don’t see how that could have anything to do with mesa

is there any hope for a mesa-only repo maybe ?
to me, losing packman sounds like a disaster for the distro

deano_ferrari · September 6, 2026, 2:15am

I wouldn’t get ahead of yourself here. I think it’s too early to assume the worst. If Packman does go away, I’d expect there to be a succession plan for the functionality it currently provides. What that ultimately looks like remains to be seen.

I suggest following the mailing list discussion.

hendersj · September 6, 2026, 2:22am

Video codec libraries aren’t the only pieces of software that are patent-encumbered. There may be (and I don’t know the specifics) other elements, such as how the Mesa libraries connect to closed-source drivers, that are potentially a legal grey area.

But the VLC repo’s codecs may suffice for your needs. As Dean notes, it’s worth looking at the full discussion (not just here, but on the Packman ML). There are several options for continuing the repo (or parts of it) that are still being discussed, so it’s not time to panic.

dcurtisfra · September 6, 2026, 12:02pm

Almost but, not quite, correct – you may wish to inspect this GitHub entry: <Enabling Hardware Acceleration in Firefox>

On this machine with Mozilla Firefox 154.0 (64-Bit):

 > kinfo
Operating System: openSUSE Tumbleweed 20260902
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.2
Kernel Version: 7.2.2-1-default (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 8600G w/ Radeon 760M Graphics
Memory: 34 GB of RAM (32.8 GB usable)
Graphics Processor: AMD Radeon 760M Graphics
 >

The “about:support” values →

Window Protocol:	wayland
Compositing:		WebRender
HW_COMPOSITING:		default		available
OPENGL_COMPOSITING:	default		available
Compositing:		WebRender
HARDWARE_VIDEO_DECODING:		default		available		
HARDWARE_VIDEO_DECODING_VULKAN:	default		available		
								user		disabled	User disabled via media.hardware-video-decoding-vulkan.enabled 	Blocklisted; failure code FEATURE_HARDWARE_VIDEO_DECODING_VULKAN_PREF_DISABLED
HARDWARE_VIDEO_ENCODING:		default		available		
HW_DECODED_VIDEO_ZERO_COPY:		default		available

<https://webglsamples.org/aquarium/aquarium.html> functions wonderfully without any errors.

The Firefox Codec Support information is as follows:

In “about:config” –

media.hardware-video-decoding.enabled:			true
media.hardware-video-decoding-vulkan.enabled:	false

If I set “vulkan.enabled” to “true”, the Firefox thread with “libvulkan_radeon.so” crashes when a video stream is started. The video stream continues with a good quality and without any further issues or events.
Therefore I’ve left the setting at it’s default value: “false”.

Bottom line, as Martin Vysny has written in his GitHub Blog –

As of 2025, Firefox finally supports hardware acceleration, both for layouting, webgl, and for hardware video decoding. On AMD Radeon and Intel GPUs, things just work out-of-the-box.

I would tend to agree with him, despite my (recent) Radeon graphics not currently supporting hardware H.264 video decoding completely with the current openSUSE OpenH264 codecs – <https://en.opensuse.org/OpenH264>

Maybe, something will change, eventually, with respect to the Cisco Codecs supporting hardware H.264 decoding.

hendersj · September 6, 2026, 2:40pm

Videos that are encoded in this way may not be compatible with other devices, so using the formats they use are because those devices don’t support the av1/opus format.

Not everyone chooses the formats they choose for playback on PC alone.

dcurtisfra · September 7, 2026, 1:43pm

Yet another hardware video decode information: <Hardware video acceleration>

BTW, AFAICS my Vulkan can’t handle H.264 and H.265 –

 > vulkaninfo | grep VK_KHR_video_
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPlanePropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_decode_vp9                       : extension revision 1
        VK_KHR_video_encode_av1                       : extension revision 1
        VK_KHR_video_encode_intra_refresh             : extension revision 1
        VK_KHR_video_encode_quantization_map          : extension revision 2
        VK_KHR_video_encode_queue                     : extension revision 12
        VK_KHR_video_maintenance1                     : extension revision 1
        VK_KHR_video_maintenance2                     : extension revision 1
        VK_KHR_video_queue                            : extension revision 8
 >

swannema · September 7, 2026, 5:50pm

Is this with the packman Mesa packages or without?
My RX9060XT and IGPU (Ryzen 7) are the same.
Without Mesa from packman:

xxx@tumbleweed:~> vulkaninfo | grep VK_KHR_video_
WARNING: radv is not a conformant Vulkan implementation, testing use only.
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPlanePropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_decode_vp9                       : extension revision 1
        VK_KHR_video_encode_av1                       : extension revision 1
        VK_KHR_video_encode_intra_refresh             : extension revision 1
        VK_KHR_video_encode_quantization_map          : extension revision 2
        VK_KHR_video_encode_queue                     : extension revision 12
        VK_KHR_video_maintenance1                     : extension revision 1
        VK_KHR_video_maintenance2                     : extension revision 1
        VK_KHR_video_queue                            : extension revision 8
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_decode_vp9                       : extension revision 1
        VK_KHR_video_encode_intra_refresh             : extension revision 1
        VK_KHR_video_encode_quantization_map          : extension revision 2
        VK_KHR_video_encode_queue                     : extension revision 12
        VK_KHR_video_maintenance1                     : extension revision 1
        VK_KHR_video_maintenance2                     : extension revision 1
        VK_KHR_video_queue                            : extension revision 8

With Mesa from packman:

xxx@tumbleweed:~> vulkaninfo | grep VK_KHR_video_
WARNING: radv is not a conformant Vulkan implementation, testing use only.
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPlanePropertiesKHR!
WARNING: [Loader Message] Code 0 : ICD for selected physical device does not export vkGetPhysicalDeviceDisplayPropertiesKHR!
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_h264                      : extension revision 9
        VK_KHR_video_decode_h265                      : extension revision 8
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_decode_vp9                       : extension revision 1
        VK_KHR_video_encode_av1                       : extension revision 1
        VK_KHR_video_encode_h264                      : extension revision 14
        VK_KHR_video_encode_h265                      : extension revision 14
        VK_KHR_video_encode_intra_refresh             : extension revision 1
        VK_KHR_video_encode_quantization_map          : extension revision 2
        VK_KHR_video_encode_queue                     : extension revision 12
        VK_KHR_video_maintenance1                     : extension revision 1
        VK_KHR_video_maintenance2                     : extension revision 1
        VK_KHR_video_queue                            : extension revision 8
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_h264                      : extension revision 9
        VK_KHR_video_decode_h265                      : extension revision 8
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_decode_vp9                       : extension revision 1
        VK_KHR_video_encode_h264                      : extension revision 14
        VK_KHR_video_encode_h265                      : extension revision 14
        VK_KHR_video_encode_intra_refresh             : extension revision 1

malcolmlewis · September 7, 2026, 10:35pm

@swannema @dcurtisfra have you tried the following?

AMD: Vulkan Video support in vulkan-radeon is enabled by default for VCN 2+ since Mesa 25. To force-enable experimental support on older cards, set the RADV_EXPERIMENTAL environment variable to video_decode,video_encode.

swannema · September 8, 2026, 5:29am

This is a brand new card and not an older vulkan card and it is crippled by the Mesa build from openSUSE.

deano_ferrari · September 8, 2026, 6:21am

A post was split to a new topic: Changing from Packman to VLC repo question

malcolmlewis · September 8, 2026, 11:29am

Then you likely need to create a bug report.

Edit: As I see WARNING: radv is not a conformant Vulkan implementation, testing use only.

dcurtisfra · September 8, 2026, 1:59pm

I have only Packman Essentials enabled on this Tumbleweed system – there are no Mesa packages available with that Packman version.