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

[hendersj]

@feuervogel

I have good reasons to stay with openSUSE - this distribution is the best imho. But please acknowledge that users are not satisfied with the lack of codec and hwaccel support. This is my only gripe with openSUSE.

It’s not an openSUSE issue, it’s an IP licensing issue.

This has been discussed repeatedly in this very topic, as well as being well-documented for years. Ire at the openSUSE Project is misplaced - put it on those who decided that monetizing the IP was more important than making the technology widely available for all to use.

That is where the problem lies. It is absolutely reasonable that SUSE, as the openSUSE project’s main sponsor, doesn’t want to be the ‘deep pockets’ that some patent troll decides to sue because the project included patent-encumbered technology in the distribution.

Other distros made their own decisions, and SUSE made theirs. You want X, but there isn’t a legal way to do it beyond what has already been suggested.

It is unreasonable to expect SUSE to break the law so you can watch Youtube (or whatever you need the codecs for). If you want to take the risk (or if you live in a jurisdiction where this isn’t an issue), then that’s what the proposed solutions do.

As an open source community, how can we reasonably expect anyone to respect the GPL or other open source licenses if we’re not going to respect the licenses that this technology is provided under? We don’t have to like those license choices, but we do have to live with them until such time as the patents have expired.

[OrsoBruno]

Putting that another way…

@feuervogel

Users paid for their hardware and want to use those features - for decoding and encoding.

… but they didn’t pay for the SW needed by that HW to work and they cannot expect that others pay for them.
Cisco was kind enough to pay for everybody to use libopenh264.
Nvidia apparently paid for those using their proprietary drivers (but you need select players to directly take advantage of that, those using ffmpeg still need Packman or Videolan or Flatpak).
People cannot expect SUSE (or RedHat) expose themselves to legal action in the jurisdictions where they do the business that, by the way, support also openSUSE (and Fedora).
And openSUSE cannot risk losing their main sponsor… or do they?

[duncreg]

SUSE does not own or control OpenSUSE unless something has secretly changed. So no, OpenSUSE doing something does not hold SUSE liable. There’s an argument here, but it has to be about things SUSE has expressly done.

But the whole thing is kind of silly since no distro has ever been sued, Packman was around for 25 years with no legal trouble, and that nuclear weapon of patents large corporations have pooled together to defend Linux itself could very well be chosen to be employed against someone coming for a distro. If no one is defending the patents in question for all this time, there’s essentially zero danger of something happening now. And no one’s going to sue an entity that has no money in the first place. Let OpenSUSE host its own servers and then SUSE has nothing to worry about. I’m not at risk of being held financially or legally responsible for anything the Red Cross does because I sent them $20 last month.

[malcolmlewis]

Hi see https://en.opensuse.org/openSUSE:Packaging_guidelines#Banned_software

[hendersj]

You should look at (a) who the main packagers are for the openSUSE distributions, and (b) how openSUSE’s distributions fit into SUSE’s commercial products pipeline.

SUSE gets to decide the risk they’re willing to take. If you want to debate that, debate it with them.

And, of course, if you’re willing to take on the legal liability, be sure to let them know. I’m sure that’ll be a GREAT relief to them.

[knurpht]

@duncreg

Let OpenSUSE host its own servers and then SUSE has nothing to worry about

Well, then come up with € x00K / year. ( where x is a number > 3 ), that will be needed for:

• Infra a.o.
  – OBS + workers ( machines )
  – openQA + workers ( machines )
  – *.opensuse.org
  – Power, datacentre rental, mainenance
• Salaries of all the SUSE employees that are paid to ( partly ) work on openSUSE
• Marketing
• Funding for a legal entity and transfer the openSUSE Trade Mark
• The annual openSUSE Conference
• Travel expenses
• Part time jobs for financial and legal employees the Project will require.

@duncreg

But the whole thing is kind of silly since no distro has ever been sued

Search the web for “SCO linux court cases”. This was no different, software patents, and went for IBM, Novell ( at the time owner of SUSE ), RedHat.

@duncreg

I’m not at risk of being held financially or legally responsible for anything the Red Cross does because I sent them $20 last month

That is a totally crippled example. Give them 1000 fentanyl pills and see if no legal consequences will arise.

[akontsevich]

@ugjka

Also all Flatpak browsers like FF and Chromium derivatives will have HW accelerated video.

You can test your browser here: https://www.free-codecs.com/app/codec-checker/

Checked repo based browsers for now - everything are software accelerated (and H.265 - Not supported) in all the browsers (Chromium, Chromium-based, Firefox) in 2026 even with Packman!!! Terrible codecs/hardware acceleration support in Linux as for 2026!!! Do flatpak versions fixes this situation?!

Why flatpak can can support proprietary codecs and hardware acceleration while SUSE can’t?!

About packages to replace: I have nvidia card, so think Mesa from packman is not critical for me, right?!

How to replace following packages:

Critical for me:

Package	Replacement	Description
Mesa	???	Do I really need it with nvidia card?
libheif-HEIF	???	Can use PhotoQt from flatpak to preview, but also good to view/thumbnail/open them in Plasma apps from SUSE repo as well
ffmpeg	VideoLan repo	Not a big deal
vlc	VideoLan repo	Not a big deal
gstreamer-plugins-bad-codecs	???	Seems some browsers still use it? Some other apps? Migrate browsers to flatpak?
gstreamer-plugins-ugly-codecs	???	Seems some browsers still use it? Some other apps? Migrate browsers to flatpak?
handbrake	Flatpak	Any other solution?
chromium-ffmpeg-extra	???	How to replace? And do I need to replace?
avidemux	Flatpak

Not critical for me:

Package	Replacement	Description
obs-studio	Flatpak or original openSUSE repo?	openSUSE repo also has it: does it miss some codecs or features?
pipewire-aptx	???	Not sure I need it but nice to have
rar	???	unrar think enough

So summarizing - the most critical: nothing replaces full libheif with all the formats for now. Build it manually on every version update (which is not very convenient)? Or put it in my home OBS repo and enable some flags?

[deano_ferrari]

See this reply re libheif

HEVC decoding support for HEIF/HEIC images

@knurpht I think it’s because of the way the topic was originally presented. It didn’t really come across as a request for help with a specific problem, but more as a discussion/speculation about what will happen to HEIF/HEVC support when Packman is discontinued. However, as I explained already a viable alternative is using ffmpeg from the VLC repository which can facilitate HEVC decoding through libheif-ffmpeg.

[deano_ferrari]

Regarding GStreamer…

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

For a general desktop user, FFmpeg + the libav libraries are sufficient for most multimedia codec needs. For applications that do rely on the GStreamer framework, gstreamer-plugins-libav together with the FFmpeg libraries from the VLC repository can provide most of the codec support they might require. The gstreamer-plugins-libav plugin is essentially a bridge between GStreamer and FFmpeg’s/libav’s codec implementations.

[ugjka]

For hw acceleration you need patched mesa, if you use packman you need to do vendor switch to get it

[malcolmlewis]

Google Chrome seems happy…

[akontsevich]

@malcolmlewis could you provide more details please?! repo or flatpak, VideoLan or Packman? What packages installed, etc?! Seems no luck with hardware acceleration for nvidia users - only Intel or AMD? Everything is Software for me and h265 is absent at all!

[malcolmlewis]

I use the rpm (repo) version of google-chrome. I have my own build of some packages, but it’s using the intel media driver.

This is a development machine, so it has all sorts of stuff installed… but I only use the oss and openh264 repo, which from memory sufficed. I do use the flatpak versions of handbrake and vlc, plus the oss version of mpv.

[akontsevich]

@malcolmlewis

I use the rpm (repo) version of google-chrome.

Do You mean chromium from repo-oss?

[malcolmlewis]

No, the upstream version https://dl.google.com/linux/chrome/rpm/stable/x86_64 but if I use luakit browser, it doesn’t detect the gpu, but still shows hardware in use…

[dcurtisfra]

Also here – Firefox doesn’t seem to use the GPU silicon codecs but, Google Chrome seems to be using them:

…

[akontsevich]

chrome://gpu/ page shows nothing: need to verify it on the codec checker page and with

nvidia-smi dmon

utility whether dec column shows numbers (not zeros) while playing 4K video on Youtube, for example. Trying to use nvidia-vaapi-driver with chromium to enable Hardware acceleration - no luck for now, issue created.

[deano_ferrari]

@ugjka

For hw acceleration you need patched mesa, if you use packman you need to do vendor switch to get it

I made no mention of hw acceleration. My comments were made in respect of the codec decoding.

[malcolmlewis]

@akontsevich So as a test, I did a fresh Leap 16.0 GNOME install on a Dell 660 with an Intel ARC A310 gpu.

I removed Firefox and installed google chrome, also installed the intel-media-driver, intel and vulksn tools, openh264 was installed via updates…

Note I also add my user to the video and render groups.

inxi -GSaz

System:
  Kernel: 6.12.0-160000.38-default arch: x86_64 bits: 64 compiler: gcc
    v: 13.4.0 clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.12.0-160000.38-default
    root=UUID=099c2447-2756-44ee-86db-741f0d5ca5bd splash=silent
    mitigations=auto quiet security=selinux intel_iommu=on
    intel_pstate=passive loglevel=2 selinux=1
  Desktop: GNOME v: 48.4 tk: GTK v: 3.24.50 wm: gnome-shell
    tools: gsd-screensaver-proxy dm: GDM v: 48.0 Distro: openSUSE Leap 16.0
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics vendor: Dell
    driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports:
    active: none empty: DP-1,HDMI-A-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0152
    class-ID: 0380
  Device-2: Intel DG2 [Arc A310] vendor: Sparkle A380 ECO driver: i915
    v: kernel alternate: xe arch: Gen-12.7 code: Alchemist
    process: TSMC n6 (7nm) built: 2022+ pcie: gen: 1 speed: 2.5 GT/s lanes: 1
    ports: active: HDMI-A-4 empty: DP-2, DP-3, HDMI-A-2, HDMI-A-3
    bus-ID: 03:00.0 chip-ID: 8086:56a6 class-ID: 0300
  Display: wayland server: Xwayland v: 24.1.6 compositor: gnome-shell
    driver: N/A display-ID: 0
  Monitor-1: HDMI-4 res: 1920x1080 size: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: intel crocus drv: intel iris platforms: device: 0
    drv: crocus device: 1 drv: iris device: 2 drv: swrast gbm: drv: crocus
    surfaceless: drv: crocus wayland: drv: iris x11: drv: iris
  API: OpenGL v: 4.6 compat-v: 4.2 vendor: intel mesa v: 24.3.3 glx-v: 1.4
    direct-render: yes renderer: Mesa Intel Arc A310 Graphics (DG2)
    device-ID: 8086:56a6 memory: 3.86 GiB unified: no display-ID: :0.0
  API: Vulkan v: 1.4.309 layers: 1 device: 0 type: discrete-gpu name: Intel
    Arc A310 Graphics (DG2) driver: N/A device-ID: 8086:56a6
    surfaces: xcb,xlib,wayland device: 1 type: integrated-gpu name: Intel HD
    Graphics 2500 (IVB GT1) driver: N/A device-ID: 8086:0152
    surfaces: xcb,xlib,wayland

The internal GPU switched to a display controller, so used for prime render offload…

[malcolmlewis]

@akontsevich Also fired up nvtop and dropped a video into chrome to see the ARC GPU is decoding…