[Unstable Update] August 2024 Edition

Well, I do not know whether there already was an ongoing discussion regarding the codecs among the Team — I am neither a developer nor a packager, and the Manjaro developers have moved from Telegram to Matrix a while ago, so I have no idea.

However, a few weeks ago, after looking into the topic of the codecs — and mind you that I personally don’t have a dog in that fight because I am using Intel graphics — I chose to reopen the debate via a private exchange with the Team here at the forum, because as it turns out, those codecs are not copyrighted but patented, and the European Union does not recognize patents on software.

Manjaro being a European distribution, it is therefore not required to exclude those codecs from the official install media and repositories. After looking into this matter deeper, the Team agreed. :slight_smile:

14 Likes

Didn’t know that, thanks for clarification @Aragorn!

1 Like

i could not find a seperate thread for the mesa topic
just to make sure for slow people like me:
if i were to remove the mesa-nonfree repos would i now get essentially the same mesa build from manjaro repos?

1 Like

Manjaro as usual: communication sometimes totally non-existant.

You’d get the package built by Arch and they enable all codecs:

edit: forgot to mention you’d have to allow downgrading packages as mesa-nonfree used a higher epoch for its packages.

5 Likes

If you try and build mesa from the above package build the key 8D8E31AFC32428A6
for Eric Engestrom is missing.

First of all, one doesn’t need to build a package if it’s already in the repos. :wink:

Either way, before one attempts to build an Arch package, one needs the same prerequisites for using the AUR as well as acquiring a PGP public key if needed.

I only built it because the number is 1:24…1.5-2 but inxi shows 24.1.5-arch1.2. I just wondered if building it would show the different number it. it does not. it’s inxi that changes it.

Got a kernel null pointer dereference.

https://pst.innomi.net/paste/vzvx863fd835or3ngoh4x9fx/raw

$ uname -a
Linux kitsune 6.10.4-1-MANJARO #1 SMP PREEMPT_DYNAMIC Sun Aug 11 18:16:32 UTC 2024 x86_64 GNU/Linux

Given that its a tainted kernel, I presume upstream isnt going to be terribly interested. Is there any likelihood that this is the result of something in kwin, or a driver? It seems to happen intermittently, system becomes slowly unresponsive and then freezes totally.

heroic-games-launcher 2.15.1-1 is broken. did a rm -rf .config/heroic - same result.

prebuild tar/binary pkg from the dev website/github is working without issues

GUI ouput:

Error running command “LEGENDARY_CONFIG_PATH=/home/hans/.config/heroic/legendaryConfig/legendary /opt/heroic/resources/app.asar.unpacked/build/bin/x64/linux/legendary list --third-party”: Error: spawn ./legendary ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:286:19)
at onErrorNT (node:internal/child_process:484:16)
at processTicksAndRejections (node:internal/process/task_queues:82:21)

whole terminal session:

https://nopaste.net/QwqBOU5ROL

Fixed with 2.15.1-2 coming along shortly.

2 Likes

Can you tell me how i allow the downgrade?

For those who want to see the original instructions for removing the mesa-nonfree repo like I did, the page is available archived here. I successfully followed the “Remove” instruction, updated my system, and rebooted.

1 Like

Dang. I need that, but without opencl-clover-mesa (according to Arch Wiki page on Davinci Resolve at least).

confirmed working. ty

I can confirm what you already know.

The mesa-nonfree repo has been taken down - it has served it’s purpose.

The removal instruction is kept online at https://nonfree.eu.

To reflect this https://forum.manjaro.org/t/unstable-manjaro-community-mesa-nonfree-codecs/135012 has been updated and closed.

1 Like

I’m using pacman exclusivly, so:

$ pacman -Syuu

Don’t take this the wrong way but IMHO you should not be using unstable if you need to ask how to downgrade though.

2 Likes

You need to remove the mesa-nonfree repo → follow the instruction using the link above and you don’t need to downgrade.

That is not true.

Part of the reason why it is not shouted from a rooftop is all those negative responses that would immediately follow such message.

Well… after some digging into this, not quite. Yet, admittedly it did take me a while to find it, and it did first come as a surprise to me while running a pacman command today and seeing the following:

error: failed retrieving file 'mesa-nonfree.db' from nonfree.eu : The requested URL returned error: 404
error: failed to synchronize all databases (failed to retrieve some files)

Of course, then I checked the repo domain URL and saw this:

Community support has ended.

The mesa-nonfree repo hosted here served it’s purpose.

Maintenance of this repo has ended August 16. 2024.

Please update your system to remove the mesa-nonfree repo.

Remove

To remove mesa-nonfre repo and return to stock Manjaro
copy below lines and paste into a terminal and hit Enter

PKGS="$(pacman -Sl mesa-nonfree | grep 'installed' | awk '{print $2}')" \
  && sudo sed -i '/mesa-nonfree/d' /etc/pacman.conf \
  && sudo pacman -Sy $(echo ${PKGS//$'\n'/ })

At first, that made me think I’d probably have to start building my own mesa* packages with the right compile flags to enable codecs.

Searching the forum didn’t immediately turn up results until I checked this thread and also found this one had been updated with new information:

Finally, of course the mesa-freeworld/mesa-nonfree repo’s README was updated:

This is repository is now obsolete. Manjaro is back to the arch version of the mesa packages.

So, it turns out it’s case & problem solved!

“Good news everyone!” :point_up: :man_teacher:t3: [1] … Codecs are now re-enabled by using upstream packages!

:raised_hands: :clap: :tada:


  1. For best results, read in your finest Professor Farnsworth impression ↩︎

3 Likes

When I linked the internet archive link, nonfree.eu was completely offline and there was just a github page saying there was no website. I’m glad they decided to bring it back for the removal instructions. Thanks.

By the way, the new page has a typo. It says “mesa-nonfre” instead of “mesa-nonfree”.

Edit: I see another typo. It says “it’s purpose” instead of “its purpose”.

I noticed the nvidia 560 drivers dropped tonight so I had to try them before going to bed. After nearly 2 months of daily firefox crashes, 560 shows promise – albeit with limited testing. System refuses to sleep properly, but that’s still better behavior than simply segfaulting upon wake-up on 555. Here’s new reporting:

$ journalctl -b -p3
kernel: nvidia 0000:07:00.0: PM: pci_pm_suspend(): nv_pmops_suspend [nvidia] returns -5
kernel: nvidia 0000:07:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
kernel: nvidia 0000:07:00.0: PM: failed to suspend async: error -5
kernel: PM: Some devices failed to suspend, or early wake event detected
pulseaudio[x]: org.bluez.BatteryProviderManager1.UnregisterBatteryProvider() Failed: org.freedesktop.DBus.Error.UnknownObject:Method "UnregisterBatteryProvider" with signature "o" on interface "org.bluez.BatteryProviderManager1" doesn't exist
kernel: nvidia 0000:07:00.0: PM: pci_pm_suspend(): nv_pmops_suspend [nvidia] returns -5
kernel: nvidia 0000:07:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
kernel: nvidia 0000:07:00.0: PM: failed to suspend async: error -5
kernel: PM: Some devices failed to suspend, or early wake event detected
systemd-sleep[x]: Failed to put system to sleep. System resumed again: Input/output error
pulseaudio[x]: org.bluez.BatteryProviderManager1.UnregisterBatteryProvider() Failed: org.freedesktop.DBus.Error.UnknownObject:Method "UnregisterBatteryProvider" with signature "o" on interface "org.bluez.BatteryProviderManager1" doesn't exist
systemd[x]: Failed to start System Suspend.

I suggest push to testing.

2 Likes