Hiya, So having gotten around bug 653786 by installing bubblewrap, I've now found that whilst the gdk-pixbuf-thumbnailer works, the totem-video-thumbnailer does not. I wrote a little wrapper script to print out the parameters that bwrap is being passed, which are as follows: bwrap --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --proc /proc --dev /dev --symlink usr/bin /bin --symlink usr/sbin /sbin --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-J3QDIZ /tmp --ro-bind /home/mike/Downloads/video.mp4 /tmp/gnome-desktop-file-to-thumbnail.mp4 --seccomp 17 /usr/bin/totem-video-thumbnailer -s 256 file:///tmp/gnome-desktop-file-to-thumbnail.mp4 /tmp/gnome-desktop-thumbnailer.png Running bwrap manually without the --seccomp value (since there's no file descriptor present to provide those values), returns the following error: /usr/bin/totem-video-thumbnailer: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory I assume this is a sandboxing error in some form, but I can't figure it out. /lib, /lib64 and /usr are all mounted by parameters. I can see libstdc++.so.6 (under /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.so.6) if I run the same bwrap command but with /bin/bash (or, in fact, a slightly modified one because /bin is symlinked to /usr/bin, rather than a straight mount) however ldd tells me it can't find it (or libgcc_s.so.1). I guess it could be some environment variable getting not getting passed through to the shell, but I'm not sure why they'd do that or which one, so I can test it? So I can't figure out the problem. I tried installing gnome-desktop-3.28.1 just in case it had been fixed in a later version, but the same result. I'm not sure how to debug this further, but it's a hurdle that will need handling if gnome is adamant about the whole bubblewrap thing. Happy to run any tests that might help?
Created attachment 528686 [details, diff] Patch for the bwrap call gnome-desktop makes when thumbnailing to take ld.so.cache into account Ok, so I resolved the problem (and realized why no one else had run into it). The way that Gentoo stores its libstdc++.so libraries requires that ld.so.conf/ld.so.conf.d to have been processed. The bwrap command gnome-desktop uses doesn't include /etc/ld.so.cache, so any libraries outside of the standard /lib or /lib64 hierarchy fail (including totem-video-thumbnailer). The attached patch resolves this issue by including the ld.so.cache in the default bwrap parameters... The only thing left to do is get the patch applied in the ebuild. Upstream bugs.gnome.org number is 795602.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/gnome.git/commit/?id=8b53f1d94092e8fa279539f49222ea3ddd001177 commit 8b53f1d94092e8fa279539f49222ea3ddd001177 Author: Gilles Dartiguelongue <eva@gentoo.org> AuthorDate: 2018-11-16 17:24:22 +0000 Commit: Gilles Dartiguelongue <eva@gentoo.org> CommitDate: 2018-11-16 17:24:57 +0000 gnome-base/gnome-desktop: load ld.so.conf in sandbox Closes: https://bugs.gentoo.org/654096 Signed-off-by: Gilles Dartiguelongue <eva@gentoo.org> .../files/3.26.2-load-ld-so-cache.patch | 12 ++++ .../gnome-desktop/gnome-desktop-3.26.2-r1.ebuild | 64 ++++++++++++++++++++++ 2 files changed, 76 insertions(+)
The bug shouldn't be closed before we've taken it to upstream in some form.
But it was, they just haven't dealt with it. Going to file a MR for easier handling - maybe it'll progress then.
The MR got merged. I'll roll a patchset with more fixes in there and put it in main tree - like automatic usrmerge (/bin is symlink to /usr/bin, etc) support patch and whatever nice I find that isn't the ABI break. I did have some oddness in thumbnailing sometimes, but I think that might have been due to poking with strace or other things at it, combined with the sandbox. I believe gnome-directory-thumbnailer we'll lose for the moment, though.