GNOME Bugzilla – Bug 785963
Thumbnails aren't being generated with gnome-desktop 3.25.90
Last modified: 2017-09-20 12:18:11 UTC
I built and installed gnome-desktop 3.25.90 with libseccomp on Ubuntu 17.10 Alpha. I installed bubblewrap. I downloaded a sample .png and .svg to my Pictures/ folder and opened it with nautilus 3.24. No thumbnails are generated for either of the two pictures. I am using gdk-pixbuf 2.36.5.
Uncomment this: https://git.gnome.org//browse/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail-script.c#n764 and see what it's launching.
Enabling debug should also show some information about why the run failed, and there's a "test-desktop-thumbnail" test program in the gnome-desktop sources which you can run to avoid depending on, say, nautilus.
Thanks. $ jhbuild run ./test-desktop-thumbnail ~/Pictures/homer-simpson.svg GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. Segmentation fault (core dumped) Can you help me find more useful data about what's not working?
A backtrace of the crash would be nice.
I got this when I ran cheese from the command line and then took a picture ------- About to launch script: bwrap --ro-bind /usr /usr --proc /proc --dev /dev --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin --symlink usr/sbin /sbin --chdir / --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-ZQHV4Y /tmp --file 37 /tmp/gnome-desktop-file-to-thumbnail.jpg --seccomp 38 /usr/bin/gdk-pixbuf-thumbnailer -s 128 /tmp/gnome-desktop-file-to-thumbnail.jpg /tmp/gnome-desktop-thumbnailer.png ** (cheese:31266): WARNING **: could not generate thumbnail for /home/jeremy/Pictures/Webcam/2017-08-08-121913.jpg (image/jpeg) -------- Of course, Ubuntu and Debian don't use lib64.
(In reply to Jeremy Bicha from comment #3) > Thanks. > > $ jhbuild run ./test-desktop-thumbnail ~/Pictures/homer-simpson.svg It expects a URI, thumbnailing will simply fail if you pass it a filename. URIs is also what the API requires. I've made the error reporting better (enable it with G_MESSAGES_DEBUG=all). > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > not be saved or shared with other applications. > Segmentation fault (core dumped) I've fixed that crash. (In reply to Jeremy Bicha from comment #5) > Of course, Ubuntu and Debian don't use lib64. Which doesn't matter, as bwrap will happily ignore non-existent source directories. You'll wait to try again with the current git master.
Oh, the end of working days are rough. Let's try again. (In reply to Bastien Nocera from comment #6) > (In reply to Jeremy Bicha from comment #3) > > Thanks. > > > > $ jhbuild run ./test-desktop-thumbnail ~/Pictures/homer-simpson.svg > > It expects a URI, thumbnailing will simply fail if you pass it a filename. > URIs is also what the API requires. I've made the error reporting better > (enable it with G_MESSAGES_DEBUG=all). > > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > > not be saved or shared with other applications. > > Segmentation fault (core dumped) > > I've fixed that crash. Which was caused by the above change. So thanks for passing the wrong arguments! :) > (In reply to Jeremy Bicha from comment #5) > > Of course, Ubuntu and Debian don't use lib64. > > Which doesn't matter, as bwrap will happily ignore non-existent source > directories. > > You'll wait to try again with the current git master. You'll want to try again. Or you can wait, up to you ;) Subsidiary question, where does gdk-pixbuf's loaders.cache live on Debian/Ubuntu? Is it anywhere that's mapped by the bwrap command above?
related bug https://bugzilla.gnome.org/show_bug.cgi?id=785404 reverting 3b298f60 fixes showing folder icons and image thumbnails. external thumnailers such as totem are still broken. another issue is that /tmp filled up with 3.5GB of gnome* in a minute.
(In reply to Hussam Al-Tayeb from comment #8) > related bug https://bugzilla.gnome.org/show_bug.cgi?id=785404 > reverting 3b298f60 fixes showing folder icons and image thumbnails. I don't see why it would. > external > thumnailers such as totem are still broken. Works fine in my tests. > another issue is that /tmp > filled up with 3.5GB of gnome* in a minute. That's likely one of your third-party thumbnailers doing this.
Hi, sorry about the delay. Freeze week is a busy week for us all! I see you tagged 3.25.90.1 but you didn't publish the tarball. Those commits were a big help. I believe I was getting several different crashes with other apps with 3.25.90 that I don't get with 3.25.90.1. --------- $ G_MESSAGES_DEBUG=all ./test-desktop-thumbnail file:///home/jeremy/Pictures/homer-simpson.svg GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. (lt-test-desktop-thumbnail:4658): GnomeDesktop-DEBUG: Failed to launch script: execvp /usr/bin/gdk-pixbuf-thumbnailer: No such file or directory (lt-test-desktop-thumbnail:4658): GnomeDesktop-DEBUG: Thumbnail script ('/usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o') failed for 'file:///home/jeremy/Pictures/homer-simpson.svg': Child process exited with code 1 (lt-test-desktop-thumbnail:4658): GnomeDesktop-WARNING **: gnome_desktop_thumbnail_factory_generate_thumbnail() failed to generate a thumbnail for file:///home/jeremy/Pictures/homer-simpson.svg --------- …but I do have /usr/bin/gdk-pixbuf-thumbnailer installed. --------- (In reply to Bastien Nocera from comment #7) > Subsidiary question, where does gdk-pixbuf's loaders.cache live on > Debian/Ubuntu? Is it anywhere that's mapped by the bwrap command above? /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache libdir is passed during the gnome-desktop build so that you get the right multiarch directory. (It's set to /usr/lib/x86_64-linux-gnu/ for amd64).
(In reply to Jeremy Bicha from comment #10) > Hi, sorry about the delay. Freeze week is a busy week for us all! > > I see you tagged 3.25.90.1 but you didn't publish the tarball. I didn't. > Those commits were a big help. I believe I was getting several different > crashes with other apps with 3.25.90 that I don't get with 3.25.90.1. > > --------- > $ G_MESSAGES_DEBUG=all ./test-desktop-thumbnail > file:///home/jeremy/Pictures/homer-simpson.svg > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > not be saved or shared with other applications. > (lt-test-desktop-thumbnail:4658): GnomeDesktop-DEBUG: Failed to launch > script: execvp /usr/bin/gdk-pixbuf-thumbnailer: No such file or directory Again, run with the debug enabled so we can see what it's doing. > (lt-test-desktop-thumbnail:4658): GnomeDesktop-DEBUG: Thumbnail script > ('/usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o') failed for > 'file:///home/jeremy/Pictures/homer-simpson.svg': Child process exited with > code 1 > > (lt-test-desktop-thumbnail:4658): GnomeDesktop-WARNING **: > gnome_desktop_thumbnail_factory_generate_thumbnail() failed to generate a > thumbnail for file:///home/jeremy/Pictures/homer-simpson.svg > > --------- > > …but I do have /usr/bin/gdk-pixbuf-thumbnailer installed. But it's not available in the sandbox, or is a script which points to a shebang interpreter that's not available. > --------- > > (In reply to Bastien Nocera from comment #7) > > Subsidiary question, where does gdk-pixbuf's loaders.cache live on > > Debian/Ubuntu? Is it anywhere that's mapped by the bwrap command above? > > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache > > libdir is passed during the gnome-desktop build so that you get the right > multiarch directory. (It's set to /usr/lib/x86_64-linux-gnu/ for amd64). That's fine then.
The files staying in /tmp seems to come from evince and totem thumbnailers (gnome-desktop-thumbnailer-*/gnome-desktop-file-to-thumbnail.{pdf,mp4})
(In reply to Jeremy Bicha from comment #5) > About to launch script: bwrap --ro-bind /usr /usr --proc /proc --dev /dev > --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin > --symlink usr/sbin /sbin ... This is not going to work on a system where the /usr merge (<https://wiki.debian.org/UsrMerge>, <https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>) has not yet been carried out. Binaries tend to work poorly when they can't see /lib64/ld-linux-x86-64.so.2 or equivalent :-) Debian >= 9 has support for the /usr merge (unless one of a couple of still-broken packages are installed), but does not carry it out by default, either on existing installations or on upgraded systems. One way to handle this would be something like this pseudocode: for directory in lib lib64 bin sbin do if ! test -e /$directory then continue fi if test /$directory -ef /usr/$directory then append --symlink usr/$directory /$directory to bwrap command else append --ro-bind /$directory /$directory to bwrap command fi done where test -ef consists of stat()ing the two operands (stat() not lstat()!) and checking whether their device and inode numbers match. Another way would be to skip the use of bwrap if we detect that the /usr merge has not been carried out. > Of course, Ubuntu and Debian don't use lib64. They do not use lib64 for ordinary libraries, but on 64-bit platforms they still need to see the dynamic linker at /lib64/ld-linux-x86-64.so.2 or similar, because the cross-distribution ABIs for 64-bit architectures say that's the path that is required to be hard-coded into binaries.
(In reply to Simon McVittie from comment #13) > (In reply to Jeremy Bicha from comment #5) > > About to launch script: bwrap --ro-bind /usr /usr --proc /proc --dev /dev > > --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin > > --symlink usr/sbin /sbin ... > > This is not going to work on a system where the /usr merge > (<https://wiki.debian.org/UsrMerge>, > <https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>) > has not yet been carried out. Binaries tend to work poorly when they can't > see /lib64/ld-linux-x86-64.so.2 or equivalent :-) We still don't know whether that's Bigon's problem though, and given comment 12, it's likely that it isn't. Please file a separate bug, or even better, attach a patch for this, as I'm unlikely to get to it any time soon.
(In reply to Bastien Nocera from comment #14) > Please file a separate bug Bug #787072. Sorry, I'm not able to put together a patch for this at the moment either.
FTR I've usr-merge on all of my machines
Upgraded to gnome-desktop 3.26 and no more thumbnail for images+videos. 3.25.90 works great but with 3.25.90.1 can't see thumbnails.
(In reply to Maxim from comment #17) > Upgraded to gnome-desktop 3.26 and no more thumbnail for images+videos. > 3.25.90 works great but with 3.25.90.1 can't see thumbnails. Make sure bubblewrap is installed, and upgrade to gnome-desktop 3.26. File a new bug if the problem persists. Let's consider the original problem fixed, as there was no feedback on it in the past month.
>Make sure bubblewrap is installed Thanks. It's working now.
(In reply to Bastien Nocera from comment #18) > Let's consider the original problem fixed, as there was no feedback on it in > the past month. The patch from bug 787072 fixes my original issue. Thanks.