1. 30 Jan, 2019 8 commits
  2. 09 Jan, 2019 1 commit
  3. 08 Jan, 2019 1 commit
  4. 27 Dec, 2018 1 commit
  5. 25 Dec, 2018 2 commits
  6. 16 Dec, 2018 2 commits
  7. 14 Dec, 2018 1 commit
  8. 13 Dec, 2018 1 commit
    • Mart Raudsepp's avatar
      thumbnail: bind mount /etc/ld.so.cache to the sandbox · f4dcb2f2
      Mart Raudsepp authored
      This is especially important for libstdc++ on distributions that
      don't have it directly in a libdir and the runtime linker doesn't
      look where needed without /etc/ld.so.cache (e.g. if libstdc++ is
      in a GCC per-version subdirectory handled via /etc/ld.so.conf.d/).
      
      If /etc/ld.so.cache is not available, the runtime linker will look
      only at a set of predetermined paths - as seen with LD_DEBUG=libs
      added to the bwrap call with "--setenv LD_DEBUG libs":
      
      find library=libstdc++.so.6 [0]; searching
       search cache=/etc/ld.so.cache
       search path=/lib64:/usr/lib64		(system search path)
        trying file=/lib64/libstdc++.so.6
        trying file=/usr/lib64/libstdc++.so.6
      
      followed by:
      
      /usr/bin/totem-video-thumbnailer: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
      
      If /etc/ld.so.cache is available, it will use that for the paths:
      
      find library=libstdc++.so.6 [0]; searching
       search cache=/etc/ld.so.cache
        trying file=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.so.6
      
      By bind mounting just that file out of /etc, we get it to work on
      such a system.
      
      Closes: #81
      f4dcb2f2
  9. 12 Dec, 2018 1 commit
  10. 11 Dec, 2018 3 commits
    • Matthias Clasen's avatar
      3.31.3 · 2452584f
      Matthias Clasen authored
      2452584f
    • Bastien Nocera's avatar
      thumbnail: Fix use-after-free when getting a preview icon · e629e46a
      Bastien Nocera authored
      g_file_info_get_attribute_object() is transfer none, so when getting a
      preview GIcon from a gvfs-backed file that supports it, we need to
      reference the preview otherwise we might crash.
      
      ==19044== Invalid read of size 8
      ==19044==    at 0x48607E7: get_preview_thumbnail (gnome-desktop-thumbnail.c:978)
      ==19044==    by 0x48607E7: gnome_desktop_thumbnail_factory_generate_thumbnail (gnome-desktop-thumbnail.c:1058)
      ==19044==    by 0x401181: main (test-desktop-thumbnail.c:51)
      ==19044==  Address 0x700f750 is 0 bytes inside a block of size 40 free'd
      ==19044==    at 0x4839A0C: free (vg_replace_malloc.c:530)
      ==19044==    by 0x48DFCD0: g_type_free_instance (gtype.c:1943)
      ==19044==    by 0x4E7F7B5: _g_file_attribute_value_clear (gfileattribute.c:176)
      ==19044==    by 0x4E83D46: g_file_info_finalize (gfileinfo.c:327)
      ==19044==    by 0x48C1C61: g_object_unref (gobject.c:3346)
      ==19044==    by 0x48607D5: get_preview_thumbnail (gnome-desktop-thumbnail.c:974)
      ==19044==    by 0x48607D5: gnome_desktop_thumbnail_factory_generate_thumbnail (gnome-desktop-thumbnail.c:1058)
      ==19044==    by 0x401181: main (test-desktop-thumbnail.c:51)
      ==19044==  Block was alloc'd at
      ==19044==    at 0x483880B: malloc (vg_replace_malloc.c:299)
      ==19044==    by 0x4B54F20: g_malloc (gmem.c:99)
      ==19044==    by 0x4B6C3C2: g_slice_alloc (gslice.c:1024)
      ==19044==    by 0x4B6C9F8: g_slice_alloc0 (gslice.c:1050)
      ==19044==    by 0x48DFA33: g_type_create_instance (gtype.c:1846)
      ==19044==    by 0x48C2397: g_object_new_internal (gobject.c:1805)
      ==19044==    by 0x48C4113: g_object_new_valist (gobject.c:2128)
      ==19044==    by 0x48C443B: g_object_new (gobject.c:1648)
      ==19044==    by 0x7451CF7: g_vfs_icon_new (gvfsicon.c:178)
      ==19044==    by 0x7451D47: g_vfs_icon_from_tokens (gvfsicon.c:268)
      ==19044==    by 0x4E8BA45: g_icon_new_from_tokens (gicon.c:381)
      ==19044==    by 0x4E8BA45: g_icon_new_for_string (gicon.c:462)
      ==19044==    by 0x7450C5F: _g_dbus_get_file_attribute (gvfsdaemonprotocol.c:300)
      ==19044==    by 0x7450D26: _g_dbus_get_file_info (gvfsdaemonprotocol.c:340)
      ==19044==    by 0x867A74C: g_daemon_file_query_info (gdaemonfile.c:830)
      ==19044==    by 0x486078D: get_preview_thumbnail (gnome-desktop-thumbnail.c:960)
      ==19044==    by 0x486078D: gnome_desktop_thumbnail_factory_generate_thumbnail (gnome-desktop-thumbnail.c:1058)
      ==19044==    by 0x401181: main (test-desktop-thumbnail.c:51)
      ==19044==
      ==19044== Invalid read of size 8
      ==19044==    at 0x48607F0: get_preview_thumbnail (gnome-desktop-thumbnail.c:978)
      ==19044==    by 0x48607F0: gnome_desktop_thumbnail_factory_generate_thumbnail (gnome-desktop-thumbnail.c:1058)
      ==19044==    by 0x401181: main (test-desktop-thumbnail.c:51)
      ==19044==  Address 0xaaaaaaaaaaaaaaaa is not stack'd, malloc'd or (recently) free'd
      
      Root-caused by "Just Me"
      
      Closes: #87
      e629e46a
    • Bastien Nocera's avatar
      README: Mention bwrap non-optional requirement · c244f43b
      Bastien Nocera authored
      Closes: #82
      c244f43b
  11. 10 Dec, 2018 1 commit
  12. 15 Nov, 2018 4 commits
    • Florian Müllner's avatar
      wall-clock: Use LC_TIME for strftime format string translations · 0f3de28f
      Florian Müllner authored
      In order to handle the clock's various display setting correctly for
      different locales, we mark strftime format strings for translation.
      However those translations are looked up according to the locale
      defined by LC_MESSAGES, while the conversion characters themselves
      are resolved according to LC_TIME, with rather odd results when
      mixing locales.
      The correct solution would be to install translations for format
      strings in the LC_TIME catalogue and look them up with dcgettext(),
      but we don't have the infrastructure to do that easily. Work around
      this by adding a helper method that looks up a string in LC_MESSAGES
      using the locale defined by LC_TIME and use that to translate the
      format strings, which has the same result.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=789205
      0f3de28f
    • Michael Catanzaro's avatar
      Prepare release 3.31.2 · 3358b964
      Michael Catanzaro authored
      Also, update the totally-incorrect comment above the libversion string.
      Clearly this isn't libtool versioning as the numbers we use here will be
      literally used for the installed library.
      3358b964
    • Michael Catanzaro's avatar
      Revert "Make myself the maintainer temporarily" · 93188713
      Michael Catanzaro authored
      This reverts commit 7c46216f.
      
      Just kidding!
      93188713
    • Michael Catanzaro's avatar
      Make myself the maintainer temporarily · 7c46216f
      Michael Catanzaro authored
      I want to edit the settings for this repo....
      7c46216f
  13. 04 Nov, 2018 1 commit
  14. 03 Nov, 2018 1 commit
  15. 24 Oct, 2018 1 commit
  16. 16 Oct, 2018 1 commit
  17. 09 Oct, 2018 1 commit
  18. 29 Sep, 2018 1 commit
  19. 24 Sep, 2018 1 commit
  20. 18 Sep, 2018 1 commit
  21. 13 Sep, 2018 1 commit
  22. 12 Sep, 2018 1 commit
    • Niels De Graef's avatar
      Meson: fix preprocessor directives. · d3e8c455
      Niels De Graef authored
      When using `#ifdef` in your code (vs `#if`), the C preprocessor doesn't
      check the value of the macro, only whether it is defined at all.
      
      By using `conf.set10()`, the macros were defined, whether the
      boolean values in the meson build file were false or not. So, to fix
      this, you either have to start using `#if`, or you make sure you use
      `conf.set()` instead.
      
      This fixes the flatpak build of GNOME Contacts (which turns off udev
      support).
      d3e8c455
  23. 08 Sep, 2018 1 commit
    • Emmanuele Bassi's avatar
      Fix the soname versioning for libgnome-desktop · 854cfe77
      Emmanuele Bassi authored
      With Meson, using the `soversion` argument of a library() target means
      setting the explicit soname, e.g.:
      
          soversion: 17.0.2
      
      will be used to generate:
      
          libgnome-desktop-3.so.17.0.2
      
      Unlike libtool, though, Meson will not generate the symbolic links for
      the first component of the soversion:
      
          libgnome-desktop-3.so.17
      
      Which is what the dynamic linker will actually use to resolve the
      library dependency at link time.
      
      In order to get a symbolic link, we need to use the `version` field for
      the soname, and the `soversion` field for the first component:
      
          version: '17.0.2'
          soversion: '17'
      
      To avoid having to manually set two fields, we can generate the
      `soversion` value from the `version` one, so that they will always be in
      sync.
      
      This fixes the build of gnome-shell on Continuous, which has been
      failing since gnome-desktop has been moved to Meson with the error:
      
          ld: warning: libgnome-desktop-3.so.17, needed by /usr/lib/libmutter-3.so,
          not found (try using -rpath or -rpath-link)
      Signed-off-by: 's avatarEmmanuele Bassi <ebassi@gnome.org>
      854cfe77
  24. 07 Sep, 2018 3 commits