Mpv Appimage doesn't start on Debian - mesa-loader errors cannot find vmwgfx, swrast & co.

[cg-cri-gl]

This is the first time i have downloaded your appimage'd mpv, however i couldn't get it to start (even with fiddling with ld.so & symlinks.

The error is:

mpv-Media-Player_0.37.0-2-archimage3.4-x86_64.AppImage  
MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

Relevant excerpt from running LD_DEBUG=libs ./AppRun :

          [...]
     13069: 
     13069: initialize program: mpv
     13069: 
     13069: 
     13069: transferring control: mpv
     13069: 
     13069: find library=libglapi.so.0 [0]; searching
     13069:  search cache=/etc/ld.so.cache
     13069:   trying file=/usr/lib/libglapi.so.0
     13069: 
     13069: 
     13069: calling init: /usr/lib/libglapi.so.0
     13069: 
MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
     13068: 
     13068: calling fini:  [0]
     13068: 
     13068: 
     13068: calling fini: /tmp/squashfs-root/.junest/usr/lib/libcap.so.2 [0]
     13068: 
     13068: 
     13068: calling fini: /tmp/squashfs-root/.junest/usr/lib/libgcc_s.so.1 [0]
     13068: 
     13068: 
     13068: calling fini: /tmp/squashfs-root/.junest/usr/lib/libc.so.6 [0]
     13068: 
     13068: 
     13068: calling fini: /tmp/squashfs-root/.junest/lib64/ld-linux-x86-64.so.2 [0]
     13068: 
     13080: find library=libselinux.so.1 [0]; searching
     13080:  search cache=/etc/ld.so.cache
     13080:   trying file=/lib/x86_64-linux-gnu/libselinux.so.1
     13080: 
     13080: find library=libc.so.6 [0]; searching
     13080:  search cache=/etc/ld.so.cache
     13080:   trying file=/lib/x86_64-linux-gnu/libc.so.6
     13080: 
     13080: find library=libpcre2-8.so.0 [0]; searching
     13080:  search cache=/etc/ld.so.cache
     13080:   trying file=/lib/x86_64-linux-gnu/libpcre2-8.so.0
     13080: 
     13080: 
     13080: calling init: /lib64/ld-linux-x86-64.so.2
     13080: 
     13080: 
     13080: calling init: /lib/x86_64-linux-gnu/libc.so.6
     13080: 
     13080: 
     13080: calling init: /lib/x86_64-linux-gnu/libpcre2-8.so.0
     13080: 
     13080: 
     13080: calling init: /lib/x86_64-linux-gnu/libselinux.so.1
     13080: 
      [...]

The 'missing' libs are actually in /usr/lib/x86_64-linux-gnu/dri/ instead

Details:

• my o.s. is in a virtual machine (on top of virtualbox), running MX-linux - a bookworm debian based version, no 'fancy' stuff added on top of Bookworm, so the problem shouldn't be here (?)
• i've been using ungoogled chromium as an appimage for while now - no issues
• remember having seen a while ago the same error but for another (appimage??) software
• regular mpv (via apt works)

---

LE:

1. This is 'funny' , line 13406: calling init: /usr/lib/libglapi.so.0 . This file isn't present on my system (it is in /usr/lib/x86_64-linux-gnu/libglapi.so.0 instead) but, according the the AppRun debug log , this didn't throw any visible error (?). Tried the 'symlink' dance -> no result.

2. This seems related

Thanks for looking into this

[ivan-hc]

What if you add only "swrast_dri.so" from https://archlinux.org/packages/extra/x86_64/mesa/download/ ?

Extract the tar archive, find the file /usr/lib/dri/swrast_dri.so and place it where it should be.

If it still does not work, add also the other two it is looking for.

I normally test video playing and YouTube/streaming videos to see if it works, and if starts also without "swrast_dri.so" I don't need to include it.

Let me know.

[cg-cri-gl]

To copy the file from the mesa archive in the squashfs-root/.junest/usr/lib/**dri** you mean ? The folder dri is missing from your appimage completely, so i copied the whole folder dri from the archive to squashfs-root/.junest/usr/lib , but still no success (as a side note:

% file  ./squashfs-root/.junest/usr/lib/d3d/*
./squashfs-root/.junest/usr/lib/d3d/d3dadapter9.so: **broken** symbolic link to d3dadapter9.so.1

To clear it up for me: The initial errors about : MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so , are relative to the squash-root (is it proot ?) - and not the host filesystem?

[cg-cri-gl]

...also , shouldn't your .junest/lib/libc.so look like such , since it is for 64 bit ?

[ivan-hc]

it uses bubblewrap (no more proot). If /usr/lib/dri does not exists, you should create it and place only that file I said.

Also, I think you should add LLVM into it.

You should build the AppImage by yourself using the script on your system (or VM) with the following changes:

• uncomment line 297 (the one related to the function _include_swrast_dri)
• comment line 341 (to prevent LLVM to be removed)

they both work about MESA implementation into the container (because Archimage is an Arch Linux container into an AppImage, not a normal Appimage like ungoogled-chromium)

EDIT: I've rebuilt it using the same script on my PC right now, without changes... and I can't reproduce your issue. I use Debian Testing

[cg-cri-gl]

it uses bubblewrap (no more proot). If /usr/lib/dri does not exists, you should create it and place only that file I said.

ok.. Also, I think you should add LLVM into it.

where ? in same squash-root ? You should build the AppImage by yourself using the script on your system (or VM) with the following changes:

which script do you mean?

• uncomment line 297 (the one related to the function _include_swrast_dri)
• comment line 341 (to prevent LLVM to be removed)

they both work about MESA implementation into the container (because Archimage is an Arch Linux container into an AppImage, sot a normal Appimage like ungoogled-chromium)

q: any advantage of using 'archimage' over a normal Appimage like ungoogled-chromium for example ? To my limited understanding, it looks like it adds some complexities / complications ' :D

[cg-cri-gl]

EDIT: I've rebuilt it using the same script on my PC right now, without changes... and I can't reproduce your issue. I use Debian Testing

Can you please share the (relevant part) from LD_DEBUG={files,libs} ./AppRun if that sheds some light ...

The answer to similar questions around the net (some) point out tolibstdc++ / libcmismatches

[ivan-hc]

which script do you mean?

I'm sorry, this one https://github.com/ivan-hc/MPV-appimage/blob/main/mpv-junest.sh

q: any advantage of using 'archimage' over a normal Appimage like ungoogled-chromium for example ? To my limited understanding, it looks like it adds some complexities / complications ' :D

I can say the disvantage on wich I'm still working on: hardware accelleration is missing

About advantages, you can bundle everything without having to care about some strange environment variables to add and find (in particular when upstream developers does not want to spend time on AppImages and want to rely on an easyer environment, for example flatpak). Anyone can create Archimages, while Appimages are not so easy to create.

[cg-cri-gl]

To reiterate my question (you have probably missed it since i added it / edited my question afterwards):

• do the errors from Mesa actually refer to missing libs from inside the "bubble-root / squash-root" and not from my host system, is iT?

[ivan-hc]

EDIT: I've rebuilt it using the same script on my PC right now, without changes... and I can't reproduce your issue. I use Debian Testing

Can you please share the (relevant part) from LD_DEBUG={files,libs} ./AppRun if that sheds some light ...

The answer to similar questions around the net (some) point out tolibstdc++ / libcmismatches

OK

[...]
     55157: find library=libvdpau_nvidia.so [0]; searching
     55157:  search cache=/etc/ld.so.cache
     55157:  search path=/usr/lib/glibc-hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-v2:/usr/lib       (system search path)
     55157:   trying file=/usr/lib/glibc-hwcaps/x86-64-v3/libvdpau_nvidia.so
     55157:   trying file=/usr/lib/glibc-hwcaps/x86-64-v2/libvdpau_nvidia.so
     55157:   trying file=/usr/lib/libvdpau_nvidia.so
     55157: 
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[...]

it can see that I'm using an Nvidia, but can't use the driver.

[ivan-hc]

To reiterate my question (you have probably missed it since i added it / edited my question afterwards):

* do the errors from Mesa actually refer to missing libs from inside the "bubble-root / squash-root" and not from my host system, is iT?

normally the containers rely only on internal libraries. JuNest is not much different from Docker/Podman, the only thing is that it can share only some essential parts to made a minilal Arch Linux installation work. See https://github.com/fsquillace/junest

Normally, when I create these packages, I first check if it requires libraries. If so, I add them using keywords ($BIN/SHARE/LIBSAVED) or by adding the package into the $DEPENDENCES variable.

[ivan-hc]

Another advantage of Archimages is that they can work also on systems with Linux kernel 2.6... not just "the old and still supported Ubuntu LTS" as the official guide of AppImages suggests.

[cg-cri-gl]

Also, I think you should add LLVM into it.

This seems indeed the case now, the error is different after copying mesa libs:

% ./AppRun 
MESA-LOADER: failed to open vmwgfx: libLLVM-17.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

previous it was

MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

can you please help me by pointing out from where to download the LLVM libs ? am not an arch user .... Thanks

[ivan-hc]

Are you able tu run the script I provided above?

https://github.com/ivan-hc/MPV-appimage/blob/main/mpv-junest.sh

if yes:

• uncomment line 297 (the one related to the function _include_swrast_dri)
• comment line 341 (to prevent LLVM to be removed)

if not: download and extract the content of /usr/lib from this archive https://archlinux.org/packages/extra/x86_64/llvm-libs/download/ to the same path in the extracted Appimage

[cg-cri-gl]

Tomorrow will hopefully get a change to test out your modifications (need to install some stuff first)
Tip : appending /download at the end of the page with the arch package downloads it - nice !

[ivan-hc]

The AppImage will be bigger. From the actual 135 MB to 200 MB.

After your test, try to run the AppRun without /usr/lib/dri, maybe it is a LLVM issue only (because I've not included it... I know that MX Linux has not systemd, and I don't really know (and care) if they have correlations.

[ivan-hc]

can you please help me by pointing out from where to download the LLVM libs ? am not an arch user .... Thanks

You're wellcome, I'm not an Arch Linux user too... Isearched on Google "libLLVM archlinux" and found as first result:

https://archlinux.org/packages/extra/x86_64/llvm-libs/files/

that lists the content of the package "llvm-libs"

The main difference in directories structure for libraries between Arch Linux and Debian is that Arch puts all libraries directly in /usr/lib, while we use both /usr/lib and /usr/lib/x86_64-linux-gnu on Debian and derivatives... they Keep It Simple (KISS)

[ivan-hc]

I repeat, when you have time, do also a test only with /usr/lib/libLLVM.so* libraries and without /usr/lib/dri, so we can try to save some disk space ("swrast_dri.so" is 34 MB if uncompressed).

[ivan-hc]

@cg-cri-gl I just started a workflow https://github.com/ivan-hc/MPV-appimage/actions/runs/8475628417

The next release will include only libLLVM and it is 177 MB. At the end of the workflow, download and test it from https://github.com/ivan-hc/MPV-appimage/releases/tag/continuous and if it still does not work, exstract it and include /usr/lib/dri/swrast_dri.so, then test the AppRun. I'm pretty sure that it should work this time.

[cg-cri-gl]

Tried the build you prepared, but it shows same error as initially:

% ./MPV-Media-Player_0.37.0-2-with-LLVM-archimage3.4-x86_64.AppImage
MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

.... however , after copying mesa libs , mpv kind-of works:

$ ./AppRun  ./AppRun movie.mp4 
 (+) Video --vid=1 (*) (h264 720x576 24.566fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
[vo/gpu/drm] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/drm] Failed to set up VT switcher. Terminal switching will be unavailable.
VMware: No 3D enabled (0, Success).
[vo/gpu] Failed to create GBM surface.
[vo/gpu] Failed to setup GBM.
[vo/gpu] Failed to commit atomic request: Function not implemented
[vo/gpu-next/drm] Can't handle VT release - signal already used
[vo/gpu-next/drm] Failed to set up VT switcher. Terminal switching will be unavailable.
VMware: No 3D enabled (0, Success).
[vo/gpu-next] Failed to create GBM surface.
[vo/gpu-next] Failed to setup GBM.
[vo/gpu-next] Failed to commit atomic request: Function not implemented
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[vo/vdpau] Error when calling vdp_device_create_x11: 1
[vo/xv] No Xvideo support found.
[vaapi] libva: vaGetDriverNames() failed with unknown libva error
[vaapi] Failed to initialize VAAPI: unknown libva error
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the x11 VO.
[E] pw.loop [loop.c:67 pw_loop_new()] 0x55bc5c3a7230: can't make support.system handle: No such file or directory
AO: [pulse] 44100Hz stereo 2ch float
VO: [x11] 720x576 => 1026x576 yuv420p
Exiting... (Quit)

There is no sound, however, wonder if this is related to this line

[E] pw.loop [loop.c:67 pw_loop_new()] 0x55bc5c3a7230: can't make support.system handle: No such file or directory

which smells like it references pipewire :(

Thank you

LE;

1. The sound issue is solved , was probably due to me messing up my system when looking to solve mesa libs issue...
2. There is, indeed no 3d acceleration :( , which would be so good esp. for a such like mpv... This limitation comes from bubblewrap or from junest ?

[ivan-hc]

There is, indeed no 3d acceleration :( , which would be so good esp. for a such like mpv... This limitation comes from bubblewrap or from junest ?

both, but JuNest may be extended with environment variables if libselinux is built in. See my experiments at https://github.com/ivan-hc/ArchImage/issues/20

That said, should i add just swrast_dri.so in the package?

[cg-cri-gl]

There is, indeed no 3d acceleration :( , which would be so good esp. for a such like mpv... This limitation comes from bubblewrap or from junest ?

both, but JuNest may be extended with environment variables if libselinux is built in. See my experiments at ivan-hc/ArchImage#20

what if libselinux is not present on the system (... or come to think of it, if apparmor instead ) ? This line looks weird to me

if test -f $JUNEST_HOME/usr/lib/libselinux.so; then
        export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"${LD_LIBRARY_PATH}"
fi

so iiuc. if and only if selinux is present (regardless of which mode it is in - enforcing or not) , then we put some libs to have precedence over the 'standard' ones in junest (?)

_LE: after reading more through the experiments you posted the link for, i think the LD_LIBRARY_PATH line actually exposes lib locations from the host system, no ? This means, that if selinux is available _inside_ junest then use some libs from host system instead ?_

(but you have more knowledge about why it is is so, from reading your link with your experiments - can you explain why selinux is / if needed ? Thanks

That said, should i add just swrast_dri.so in the package?

in my specific case, i need the kms_swrast_dri.so lib also ( + vmwgfx_dri.so lib also since i am in a VM.)

[ivan-hc]

what if libselinux is not present on the system (... or come to think of it, if apparmor instead ) ? This line looks weird to me

if test -f $JUNEST_HOME/usr/lib/libselinux.so; then
        export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"${LD_LIBRARY_PATH}"
fi

so iiuc. if and only if selinux is present (regardless of which mode it is in - enforcing or not) , then we put some libs to have precedence over the 'standard' ones in junest (?) LE: or we do actually want to bypass selinux-mixed libs ?

I've discovered this using LD_DEBUG=libs when trying to force bubblewrab using various libraries from the host (including libc.so), an I ended to have errors about JuNest looking for libselinux.

So I removed all my previous "bindings" (when you want let the container use a path from the host, you need to use "--bind") and tried to install libselinux in JuNest... and then I exported LD_LIBRARY_PATH:

• without libselinux, I had errors with Bubblewrab, being host libraries overwriting the guest's ones;
• with libselinux, JuNest was able to run and had less errors than before, being more old libraries available among the builtin ones.

From here I started looking for a concrete solution to let some JuNest apps use OpenGL (for example, Torcs game was not working before these tests, now it is available as AppImage).

(but you have more knowledge about why it is is so, from reading your link with your experiments - can you explain why selinux is / if needed ? Thanks

nope, I just was lucky. I'm not an expert, not a developer... I'm here just for fun (and to convince real developers join and save AppImage packaging format from the extintion). I also don't know how selinux works. In brief I'm a total ignorant.

That said, should i add just swrast_dri.so in the package?

in my specific case, i need the kms_swrast_dri.so lib also ( + vmwgfx_dri.so lib also since i am in a VM.)

:fearful:

this means that the final appimage would be about 250-270 MB in total. I'd prefer not to made my Archimages look like Flatpaks.

Can you try to build MPV on your PC or VM using the script linked above and by including libselinux in dependences? Its not much but is just an attempt.

[cg-cri-gl]

this means that the final appimage would be about 250-270 MB in total. I'd prefer not to made my Archimages look like Flatpaks.

Totally agree to steer away from flatpaks - but just want to point out that in this mpv archimage (i would avoid using appimage since that's a totally different approach now that i understand it , based on ldd 'tricks' ) - it's missing libselinux:

ll squashfs-root/.junest/lib/libselinux*
ls: cannot access 'squashfs-root/.junest/lib/libselinux*': No such file or directory

so the LD_LIBRARY_PATH actually doesn't get called...

Can you try to build MPV on your PC or VM using the script linked above and by including libselinux in dependences? Its not much but is just an attempt.

would that include it in the junest root ? if so, wouldn't this be like a horrible workaround , i mean the purpose would only be to call LD_LIBRARY_PATH and as such use some host os libs instead of junest ones ... or am i missing smth here ?

[ivan-hc]

Re-download the new Archimage when this workflow ends https://github.com/ivan-hc/MPV-appimage/actions/runs/8483477102

I've included libselinux, however this feature is still experimental. I can't guarantee that would work.

[cg-cri-gl]

ok, will want to test your new version. in the meantime, it seems to me the the LD_LIBRARY_PATH is getting ignored ... saying this because i have tweaked AppRun like so:

if ! test -f $JUNEST_HOME/usr/lib/libselinux.so; then
    export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/dri/:/usr/lib/:"${LD_LIBRARY_PATH}"

This should've made it to include my host os libs, if libselinux is missing from junest root ...which is the case for the 'old' version of mpv archimage - but it didn't work either, same error message about missing mesa libs:

$ ./AppRun
LD_LIBRARY_PATH is: /lib/:/lib64/:**/lib/x86_64-linux-gnu/dri/**:/usr/lib/:
MESA-LOADER: failed to open vmwgfx........ _and so on_

but the missing mesa libs are present in the bolded folder in my host os :(

[ivan-hc]

what should we do to let JuNest use host's /dri directory instead of its own?

EDIT: I think that this is a topic we should discuss at https://github.com/ivan-hc/ArchImage/issues/20

[cg-cri-gl]

Indeed that's a separate Topic , and i saw your comment in that topic:

alternativelly we have to "export" the correct variables. For example, we here have already exported "LD_LIBRARY_PATH" from the host to the AppImage

so i presumed that is what export LD_LIBRARY_PATH is accomplishing , but it turns out it is not :( - even with selinux present (your latest build)

$ ./MPV-Media-Player_0.37.0-2-1-archimage3.4-x86_64.AppImage
MESA-LOADER: failed to open vmwgfx: ................
..........

and OTOH, even if the export LD_LIBRARY_PATH mechanism would function (which is a junest bug if it is not but it's supposed to work) then we would mix OS libs and libs from junest which i have doubts would function... maybe only for same (or very close versions) + lib[std]c[++] headaches... (debian vs arch vs .... )

LE and if actually there is a completely different intended behaviour for the export LD_LIBRARY_PATH mechanism of junest, then i am all ears :)

[ivan-hc]

I had an issue like this in Bottles, I've solved by creating a Debian Stable base and only import compiled packages from AUR, since the python3 version is the same (3.11), however I cannot made it work on older distros because python3.11 is not available for them.

https://github.com/ivan-hc/Bottles-appimage

But this is another story. In this case we have not to compile stuff from AUR or git, due to GLIBC compatibility.

[ivan-hc]

Also, if I had to compile from git, I need to build "on the old and still supported Ubuntu LTS" -_- ant this sucks

[ivan-hc]

@cg-cri-gl about Virtualbox, have you enabled 3D hardware accelleration? Are guest additions installed?

[cg-cri-gl]

They're not enabled, but that doesn't affect that it cannot find the mesa libs :-/

[ivan-hc]

They're not enabled, but that doesn't affect that it cannot find the mesa libs :-/

are you sure?

I ask this because I'm a Virtualbox user too and MPV worked out of the box on my VMs. Regardless it uses MESA or not (that ist another topic, as I said above), the AppImage runs and plays video/audio/streams...

[ivan-hc]

I need to know this, because if so, I can revert the script, keep the Appimage small again and switch this issue to the one related to hardware accelleration in JuNest/Archimages, that is another topic (and this become a duplicate).

[ivan-hc]

I've reverted MPV to the original status, try running it on the VM with 3D accelleration enabled

[ivan-hc]

I started creating it again on the VM trying to reproduce your issue

[ivan-hc]

I think I've finally solved, I've created the same environment and the Appimage is about 179 MB. I'm going update the script.

[ivan-hc]

In this case I included all libraries containing "swrast" in the name, in /usr/lib/dri... and surprisingly the AppImage didn't grow too much.

However, I would like to underline the importance of my research, in which I am encouraging more people to participate consistently, until this problem is resolved. It will be version 4 of the Archimage project, but for now, if the app continues to have these problems, we will be forced to suffer from container restrictions.

In the meantime, enjoy this new release.

https://github.com/ivan-hc/MPV-appimage/releases/tag/continuous

[cg-cri-gl]

They're not enabled, but that doesn't affect that it cannot find the mesa libs :-/

are you sure?

yes, it is so, unfortunately :( - remeber that we tested to include the mesa libs in the junest root (mpv appimage) and it works then (but without 3d , ofc)

I ask this because I'm a Virtualbox user too and MPV worked out of the box on my VMs. Regardless it uses MESA or not (that ist another topic, as I said above), the AppImage runs and plays video/audio/streams...

This is don't understand: how come it works for you, even without the mesa libs in the junest root ... it must be that in your case it is using the host OS (Arch, in your case ... no?) libs

Thanks for your time on this

[ivan-hc]

@cg-cri-gl I was wrong, sorry. I did other tests until this release I published. Let me know if it works for you too.

it must be that in your case it is using the host OS (Arch, in your case ... no?) libs

BTW I use Debian (Testing) ;)

[cg-cri-gl]

The latest release , works :100: - still complaints about vmwgfx driver but that is a separate issue:

$ ./MPV-Media-Player_0.37.0-2-vm-archimage3.4-x86_64.AppImage
MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open vmwgfx: /usr/lib/dri/vmwgfx_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory

... however i am still puzzled how come it worked for you in the first place without swrast-* libs !?

[cg-cri-gl]

also, when i run manually using launch command from AppRun: $ env LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/dri/ /tmp/squashfs-root/.local/share/junest/bin/junest -n -b --bind /media /media --bind /etc/resolv.conf /etc/resolv.conf -- mpv --player-operation-mode=pseudo-gui --

it's stuck at: Error: The image is still not installed in /home/demo/.junest. Run this first: junest setup (i know i can run junest setup , but i don't want to spread files in my home folder) => question: why it doesn't show same error , when running % ./AppRun ?

[cg-cri-gl]

In this case I included all libraries containing "swrast" in the name, in /usr/lib/dri... and surprisingly the AppImage didn't grow too much.

However, I would like to underline the importance of my research, in which I am encouraging more people to participate consistently, until this problem is resolved. It will be version 4 of the Archimage project, but for now, if the app continues to have these problems, we will be forced to suffer from container restrictions.

In the meantime, enjoy this new release.

https://github.com/ivan-hc/MPV-appimage/releases/tag/continuous

Thanks, as said it works , but could you please add also the 'vmwgfx' libs , since the release is called 'MPV-Media-Player_0.37.0-2-vm-archimage3.4-x86_64.AppImage' :P ? at least temporary so i can download it and test it after enabling 3d acceleration on my vm.

[ivan-hc]

... however i am still puzzled how come it worked for you in the first place without swrast-* libs !?

I repeat, I was wrong, I was confused with another app (I have 60+ AppImages in my repos, for me them seems all the same)

also, when i run manually using launch command from AppRun: $ env LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/dri/ /tmp/squashfs-root/.local/share/junest/bin/junest -n -b --bind /media /media --bind /etc/resolv.conf /etc/resolv.conf -- mpv --player-operation-mode=pseudo-gui --

it's stuck at: Error: The image is still not installed in /home/demo/.junest. Run this first: junest setup (i know i can run junest setup , but i don't want to spread files in my home folder) => question: why it doesn't show same error , when running % ./AppRun ?

because the JuNest installation is incomplete.

When I build an Archimage, I include only what would made it work, so I have to remove a lot of things.

If I had to bundle the whole JuNest for MPV, I think it would be 700+ MB.

About the environment, just create a new folder

mkdir tmp

and put the script into it and run it, all files will not be scatteres arond, sinche the script uses that directory as a fake $HOME

Also, Archimage 3.4 has the advantage of being reusable. You can add dependences, keyword and other, but you don't need to rebuilt everything again.

[cg-cri-gl]

another weird stuff, maybe you could check it out :-} 1.

$ /tmp/squashfs-root/.local/share/junest/bin/junest --help
JuNest (v7.4.8): The Arch Linux based distro that runs upon any Linux distros without root access

Usage: junest [action] [options] [--] [command]
[...]
            -b, --backend-args <args>      Arguments for bwrap backend program
                                           **(junest ns -b "--help" to check out the bwrap options)**

but it doesn't work:

mx1:/tmp/squashfs-root $ /tmp/squashfs-root/.local/share/junest/bin/junest ns b "--help"
/bin/sh: line 1: b: command not found

only when running with ...bwrap it displays help:

mx1:/tmp/squashfs-root $ /tmp/squashfs-root/.local/share/junest/bin/junest bwrap "--help"
usage: bwrap [OPTIONS...] [--] COMMAND [ARGS...]

    --help                       Print this help
    --version                    Print version
    --args FD                    Parse NUL-separated args from FD

      [....] 
_now it displays help_

i wonder if no.1 impacts next no. 2 which could affect proper operation....

2. 
   mx1:/tmp/squashfs-root $ export JUNEST_HOME=$(pwd)/.junest ;  /tmp/squashfs-root/.local/share/junest/bin/junest -n -b   --bind /media /media   --bind /etc/resolv.conf /etc/resolv.conf   -- mpv --player-operation-mode=pseudo-gui --
   **** DEBUG ****: will run command:  run_env_as_bwrap_user  --bind true /media /media --bind /etc/resolv.conf /etc/resolv.conf -- mpv --player-operation-mode=pseudo-gui --
   _bwrap: Unknown option -c_

....There is however, no `-c` explicitly being passed - it comes from line 156 in  `function run_env_as_bwrap_user()`  in file `.local/share/junest/lib/core/namespace.sh`:

132 function run_env_as_bwrap_user() { [...] 156 [[ "$1" != "" ]] && args=("-c" "$(insert_quotes_on_spaces "${@}")")

[ivan-hc]

Its not b, its -b

also, JuNest is like a "frontend" for "bubblewrap". All the scripts are wrote to work in three modes: the best one is the normal one (using bubblewrap), then proot and chroot. My packages were based on proot before I found how to made them work without it (before Archimage v3).

There is a lot to study on that project, @fsquillace did an amazing job, in my opinion. If only we find a way to use hardware accelleration, it would be perfect. We can bundle every program out there as AppImages, better than Flatpak.

[cg-cri-gl]

About the environment, just create a new folder

mkdir tmp

and put the script into it and run it, all files will not be scatteres arond, sinche the script uses that directory as a fake $HOME

for me to do this means installing few packages + archimage Tgz bundle + .... just to add one single file , the vmwgfx.so .... or maybe you could add a new branch, for VMs?

[cg-cri-gl]

Its not b, its -b

.. but more important is point no. 2 ... @ivan-hc : can you run the command on your system and show output ?

There is a lot to study on that project, @fsquillace did an amazing job, in my opinion. If only we find a way to use hardware accelleration, it would be perfect. We can bundle every program out there as AppImages, better than Flatpak.

meToo :) don't like flatpak at all

[ivan-hc]

???

You have nothing to do but:

mkdir tmp
cd tmp
wget https://raw.githubusercontent.com/ivan-hc/MPV-appimage/main/mpv-junest.sh
chmod a+x ./mpv-junest.sh
./mpv-junest.sh

all you need as dependences are wget, rsync, tar, unzip, git and imagemagick on your host system. If your pc has an ssd and is quite recent and have good performances (and good internet speed) you will build the Appimage in about 2 minutes or less.

[ivan-hc]

This is Firefox (from the README of my project https://github.com/ivan-hc/ArchImage , Archimage 3.3)

https://private-user-images.githubusercontent.com/88724353/313565898-06c91ddf-b9c8-41aa-a68c-325250925fd7.mp4?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTE4MDAwMTMsIm5iZiI6MTcxMTc5OTcxMywicGF0aCI6Ii84ODcyNDM1My8zMTM1NjU4OTgtMDZjOTFkZGYtYjljOC00MWFhLWE2OGMtMzI1MjUwOTI1ZmQ3Lm1wND9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAzMzAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMzMwVDExNTUxM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTk4ODcyOTk2YTFlNmU5M2FjMjU4MjY1ZDk0MzU0ZmI5OWFjZTVkMmI5ZmE5ZGFkNDQyZTYzYzM1YzhlYWYyMWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.QjvhYnZN2tVL_Wzwq6a6HjRVFPKE2Z7FtPyPgDjPPGs

[cg-cri-gl]

Also, Archimage 3.4 has the advantage of being reusable. You can add dependences, keyword and other, but you don't need to rebuilt everything again.

That sound very cool ... This means one could add (also) libs to an existing archimage app - like my usecase here, e.g. to add the vmwgfx.so for example ?

Thanks and am eager to check out your progress here :)