Add support for xdg-terminal-exec for handling desktop applications using 'Terminal=true'

See merge request GNOME/glib!2839

ci: Fix check for missing install tag

See merge request GNOME/glib!3019

Max Gautier authored Jul 23, 2022 and Marco Trevisan committed Oct 26, 2022

Allow users to select their terminal of choice by using the
xdg-terminal-exec wrapper.

It is a temporary temporary solution while waiting for the
xdg-default-apps specification
(https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54), in
accordance with this comment:
GNOME/glib#338 (comment 1076172)

Max Gautier authored Jul 23, 2022 and Marco Trevisan committed Oct 26, 2022

Introduce support for terminals executing commands without an option,
i.e., the command is passed directly as argument to the terminal emulator.
This is needed for xdg-terminal-exec.

Max Gautier authored Jul 23, 2022 and Marco Trevisan committed Oct 26, 2022

Get rid of multiple conditionals branch by using a loop and storing the
options needed by particular terminal emulators directly in an array.
Remove intermediate variable term_argv as we don't need it.

Advantages:
- simpler logic, less branching
- the terminal emulator list is more readable, by virtue of being
  condensed in one array. Launch options to execute a terminal program
  are also more explicitly specified
- the logic become independent from the order
- one less allocation

Better check the installation plan json file instead of parsing logs.

Install gversionmacros.h in the right place

See merge request GNOME/glib!3018

The gversionmacros.h header is referenced from glib/, so it needs to go
into glib's include directory, not in the top-level alongside glib.h,
glib-object.h, gmodule.h, and glib-unix.h.

Handle plugable g_modules through RTLD_DEFAULT for NetBSD

Closes #19

See merge request GNOME/glib!3014

gio/gdesktopappinfo: Free the wrapped argv array on launch failure

See merge request GNOME/glib!3008

Fix function name typo in comment of gtype.c

Closes #2791

See merge request GNOME/glib!3016

The function adjusting private struct size to private struct offset
should be `g_type_class_adjust_private_offset`, instead of the
previously misspelled `g_type_class_add_instance_private` in comment.

Fixes #2791

tests: Fix few new clang warnings

See merge request GNOME/glib!3013

fix issue #19

We create an array that we never free, ensure this is the case.
The previous commit gives CI a chance to check this with valgrind job.

Found as part of another review:
 - GNOME/glib!2839 (comment 1524922)

Trying to use invalid Fd's numbers so that this would fail early.

Add a custom launch context implementation so that we can test the
startup notification code better.

gtimezone: Fix symlink checks on relative link targets

See merge request GNOME/glib!3009

Fabio Tomat authored Oct 25, 2022 and Administrator committed Oct 25, 2022

(cherry picked from commit 142f1712d22eb459d919bd0f4fe7cba573a58791)

meson: Cleanup and fix include files paths, using base path without repetitions

See merge request GNOME/glib!3011

docs: Stop claiming that gsize is wide enough to hold a pointer

See merge request GNOME/glib!3000

ghash: Correctly retrieve low 32 bits of 64-bit values

Closes #2787

See merge request GNOME/glib!2994

Always ref-sink variants in g_object_set

Closes #2774

See merge request GNOME/glib!2934

docs: Soft-deprecate G_STRUCT_OFFSET in favour of offsetof

See merge request GNOME/glib!3002

Otherwise clang would complain:

  ../glib/tests/strfuncs.c:2603:32: warning: result of comparison
    against a string literal is unspecified (use an explicit string
    comparison function instead) [-Wstring-compare]
    g_assert_true ((gpointer)str != (gpointer)"");
                                 ^  ~~~~~~~~~~~~
  ../glib/gtestutils.h:187:59: note: expanded from macro 'g_assert_true'
                                               if G_LIKELY (expr) ; else \
                                                            ^~~~
  ../glib/gmacros.h:1186:59: note: expanded from macro 'G_LIKELY'
  #define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
                                                            ^~~~
  ../glib/gmacros.h:1180:8: note: expanded from macro '_G_BOOLEAN_EXPR'
     if (expr)

Clang was complaining:

  ../glib/tests/sequence.c:125:7: warning: variable 'i' set but not used
    int i;
        ^
  1 warning generated.

Meson is able to handle this automatically when we're installing in the
include-dir prefix.

Avoid setting the subdir all the times, just use the global definition
plus the specific module subdir

glib, gmodule, gobject: Add generated headers to the lib dependency

See merge request GNOME/glib!2991

It’s entirely possible that `g_file_read_link()` will return a relative
path. Mention that in the documentation, and include a short example of
how to make the path absolute for further computation.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

The changes in 6265b2e6

 to reject weird
`/etc/localtime` configurations where `/etc/localtime` links to another
symlink did not consider the case where the target of `/etc/localtime`
is a *relative* path. They only considered the case where the target is
absolute.

Relative paths are permissible in all symlinks. On my Fedora 36 system,
`/etc/localtime`’s target is `../usr/share/zoneinfo/Europe/London`.

Fix the check for toolbx by resolving relative paths before calling
`g_lstat()` on them.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Standard C specifically does not guarantee this, and it's untrue on
CHERI architectures (which have 128-bit pointers into a 64-bit
address space, with the remaining bits used for a capability-like
mechanism).

Signed-off-by: Simon McVittie <smcv@collabora.com>

Matthias Clasen authored Oct 05, 2022 and Philip Withnall committed Oct 24, 2022

When collecting varargs, ignore the NOCOPY_CONTENTS
flag for variants. That is what our docs advice for
refcounted types, and it fixes a regression that
was inadvertendly introduced when we stopped doing
some extra GValue copies.

Includes a test case by Philip Withnall.

Fixes: #2774

Simon McVittie authored Oct 21, 2022 and Philip Withnall committed Oct 24, 2022

Dereferencing a pointer to a 64-bit object as though it was a 32-bit
object is the same as taking the least significant 32 bits on a
little-endian machine, but on a big-endian machine it is the same as
taking the *most* significant 32 bits, which would result in these hash
functions always hashing to zero. The /hash/int64/collisions and
/hash/double/collisions test-cases in glib/tests/hash.c detect this
and fail.

Instead, fetch the whole 64-bit quantity and do the bit-manipulation
to xor the more significant half with the less significant half in an
architecture-neutral way.

Fixes: dd1f4f70 "Optimize g_double_hash implementation"
Fixes: c1af4b2b "Optional optimization for `g_int64_hash`"
Resolves: GNOME/glib#2787


Signed-off-by: Simon McVittie <smcv@collabora.com>