wl_proxy_marshal_flags
is provided by /usr/lib64/libwayland-client.so.0
which is part of libwayland-client0
(current version is-1.21.0-150500.1.1.x86_64). Is it installed?
Or is a wayland specific bug, because just startted to use wayland.
Yes, I have it installed and I am using plasma5 wayland.
At difference of my memories my recent test suggest discarting wayland specific bugs:
env -u WAYLAND_DISPLAY Blender_launcher
gives the same error
Well, your third-party blender may well come with own internal version of this library. Run it under strace
, look what libraries it tries to open, where they are located.
It is not blender, is blender launcher.
And my strace is this 5MiB file that I cannot upload because for some reason I gets detected as malicious
here is a one-time link https://file.io/ddYvH7lpZYl0 I managed to get
Too big to the x11/wayland copy function to work in it.
It is definitively too big to copy paste
We have https://susepaste.org/ for this. Anyway
stat("/tmp/_MEIZ7eauV/libwayland-client.so.0", 0x7ffcaa707950) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/tmp/_MEIZ7eauV/libwayland-client.so.0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
So, your program not only uses the private copy of libwayland_client.so.0
, but even creates it on the fly. It is not something to fix in openSUSE. You may consider using containers (like flatpak) here.
I mean it is too big to the x11/wayland clipbord.
Solved reinstalling OpenSUSE, problem maybe related to trying to run Virtio GPU with Vulkan support.
Problem persists I am getting this same error, but this time I have snapper setup and this is giving this message when check snapper of my last snapshot against my previous one it gives the following message:
sudo LANG=C snapper diff 43..42 /usr/lib64/libEGL_mesa.so
File '/usr/lib64/libEGL_mesa.so' not found.
with the snapshot 43 being the post snapshot of my last zypper install this being: zypper in -y ripgrep git find fd
according to my zypper-log
and the 42 being the pre of the same action. rolling back to 42 does not fix the problem, even rollback to 1 does not fix the problem.
Note that It worked after a fresh install of OpenSUSE.
Should it be a new problem?
The problem is in the third-party software you are using, so as long as you continue to use this software you will continue to get this problem. You are of course free to post on any random Internet forum, but only developers of this software can fix it.
Are you sure? Because it works in a fresh install.
Note that if I run from source the package (I have not runnied pyinstall) it works perfectly.