On Sat, 17 Aug 2019 at 00:46:34 -0700, James Lu wrote:
> It would appear that this affects exe-thumbnailer[1] too
Please could you report a separate bug for this? I believe the original
issue reported in #902288 was fixed during the buster freeze, and even
if it wasn't, it's a lot easier to merge two bugs (if they turn out to
have the same root cause) than to disentangle two root causes that share
a bug number.
Report the new bug against libgnome-desktop-3-17 or exe-thumbnailer,
whichever one seems more likely to be at fault. If you assign it to
exe-thumbnailer, please cc gnome-desktop3 tracker.debian.org to
keep the maintainers of that library in the loop, and similarly if you
assign it to libgnome-desktop-3-17, it's probably a good idea to cc
exe-thumbnailer tracker.debian.org. We can always reassign the bug
if it turns out that the initial guess was wrong.
> the default bwrap settings cause thumbnails to be missing
To be clear about this, bwrap (bubblewrap) does not really have defaults
or settings in the way that applications do: what it exposes or protects
in the sandbox is entirely determined by the command-line options it
is given. If the sandbox is not exposing enough from the main system,
then the solution is for the library or program that is calling bwrap
to run it with different command-line options.
In the case of GNOME thumbnailers, these are set up by libgnome-desktop
(and, temporarily, also Nautilus using forked code from libgnome-desktop -
but a bug report against libgnome-desktop is just as good as a bug report
against nautilus, because if a fix is needed in either libgnome-desktop
or nautilus, we'll want to copy it into the other one anyway).
Other packages that use bwrap for non-thumbnailing purposes (like flatpak
and webkit2gtk) provide their own command-line options, which need to
be set differently to be appropriate for those packages' requirements.
smcv
