Failed to open module /usr/lib64/wireplumber-0.4/libwireplumber-module-route-settings-api: /usr/lib64/wireplumber-0.4/libwireplumber-module-route-settings-api.so: cannot open shared object file: No such file or directory
It's not actually missing a shared library. Instead you have an old config/script file somewhere on your system which references a module which is no longer present since WirePlumber 0.4.8. Most obvious places to look for the stale file are these two: * /etc/wireplumber (does not exist by default right now) * $HOME/.config/wireplumber (also does not exist by default) I'll talk to Sam later about having a way to have config_protect working for at least /etc/wireplumber, so that there's one less way for config/scripts to go stale. Finally thank you for bringing the issue to the forefront, so that it can finally be resolved. And ideally the same solution will be taken with PipeWire, too, which is at the risk of exactly the same general problem of /etc/pipewire not being config_protect'ed.
Yes, the problem was that I've copied `/usr/share/wireplumber` to `~/.config/wireplumber` (because it makes sense, `wireplumber` is started as user, so the config should be modifiable by user). `/usr/share/wireplumber` has been updated, while `~/.config/wireplumber` hasn't. After removing `~/.config/wireplumber` the problem has disappeared. Is there any chance portage can manage user configs?
Not right now and probably it would never be fully reliable - a user that's not logged in may have a missing or encrypted home directory but that's only the most obvious issue. Another one is that currently config_protect works by intercepting overwriting of config files, so a trivial implementation would duplicate those config files in every user's wireplumber config directory. With that said, Portage could probably be made capable of providing config_protect for <user_home>/.config/{piewire,wireplumber}, if someone wrote it. But it might not be as easy as it seems, because technically $HOME/.config is itself just a default location and there could be a user specific environment variable override that sets an entirely different path, and covering all the possible ways that could be set is probably unrealistic. Thankfully this may not be that big of a deal in the future, because upstream is working towards splitting scripts from configuration for the most common use cases. Overriding would still work as before and may be necessary for some things but at least the more typical things people want to adjust would be in files containing only config data and hopefully will be robust enough to not break if there's an outdated file somewhere.
I've got a crazy (but probably not too related to this bug) idea: "patch" FUSE filesystem, which contains all files from given source with given patch applied to them. I wonder if that's already implemented somewhere...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=786a2d71d3bd51fc39dc73c548b7c9d7fa45096e commit 786a2d71d3bd51fc39dc73c548b7c9d7fa45096e Author: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com> AuthorDate: 2022-02-11 19:41:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-02-12 05:16:52 +0000 media-video/wireplumber: backport a fix and enable config protection WirePlumber 0.4.8 contains a config/script change that, if not present in the user modified files, will cause startup failure. This commit backports an upstream fix to prevent a crash in addition to also implementing a solution to at least keep /etc/wireplumber up to date though the usual config_protect mechanism. This is needed because while the particular issue has been addressed, it does not solve the general problem with there potentially being outdated files in /etc/wireplumber directory. The same is true for $HOME/.config/wireplumber, too, however there's no reasonable way to help users who decide to copy config files to there and then never update them against newer versions. Closes: https://bugs.gentoo.org/832952 Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com> Signed-off-by: Sam James <sam@gentoo.org> ...eam-do-not-crash-if-config.properties-is-.patch | 27 ++++++++++++++++++++++ ...0.4.7-r1.ebuild => wireplumber-0.4.7-r2.ebuild} | 11 +++++++++ ...er-0.4.8.ebuild => wireplumber-0.4.8-r1.ebuild} | 15 ++++++++++++ media-video/wireplumber/wireplumber-9999.ebuild | 11 +++++++++ 4 files changed, 64 insertions(+)
commit fa40a68813842842cae00dac90450cf3e1b979ce Author: James Calligeros <jcalligeros99@gmail.com> Date: Sun Dec 10 10:59:53 2023 +1000 media-video/wireplumber: don't copy default configs to /etc/ Wireplumber does not tolerate having its default config split across /etc/ and /usr/share/. It has also recently acquired features which allow system integrators and other interested third parties to ship customised configuration packages to better integrate oddball hardware, such as Apple Silicon Macs. These configs naturally live in /usr/share/, since they are not user-created. As /etc/ takes precedence over /usr/share/, having the OOTB config there prevents these custom configs from being loaded properly. This commit removes the step which copies the OOTB config to /etc/, which matches the behaviour expected (and now arguably required) upstream. Users are responsible for adding their own overrides to /etc/ should they so choose. Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/34207 Signed-off-by: Sam James <sam@gentoo.org>
