Various parts of the build (such as `objectmanager-rst-gen`) depend on
running `gdbus-codegen` after it’s been built, but they currently only
encode a dependency to the main codegen Python file and not the
supporting files. This can cause `gdbus-codegen` to fail with an
`ImportError` if the build races so that `objectmanager-rst-gen` is
built before the codegen supporting files.
Example failure here: https://gitlab.gnome.org/pwithnall/glib/-/jobs/3266471
```
FAILED: gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Animal.rst gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Cat.rst
/usr/bin/python3 gio/gdbus-2.0/codegen/gdbus-codegen --interface-prefix org.gtk.GDBus.Example.ObjectManager. --generate-rst objectmanager-rst-gen --output-directory gio/tests/gdbus-object-manager-example ../gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager.xml
Traceback (most recent call last):
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/gdbus-codegen", line 53, in <module>
from codegen import codegen_main
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in <module>
from . import dbustypes
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in <module>
from . import utils
ImportError: cannot import name 'utils' from 'codegen' (/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/__init__.py)
```
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
All the calls to `usage()` are immediately followed by a `return` from
`main()` which sets an appropriate exit status.
Calling `exit()` early means that running `gio --help` returns exit
status 1, which is incorrect — it should (by convention) return 0.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Depending on the operating system, /bin/sh might either be bash (for
example on Fedora or Arch) or dash (for example on Debian or Ubuntu)
or some other POSIX shell.
When bash is asked to run a simple command with no shell keywords or
metacharacters, like this one, it replaces itself with the program
via execve(), but dash does not have that optimization and treats it
like any other program invocation in a larger script: it will fork,
exec the program in the child, and wait for the child in the parent.
This seems like it conflicts with sleep_and_kill() assuming that it can
use the subprocess's process ID as the sleep(1) process ID. Specifically,
if it sends SIGKILL, it will go to the sh(1) process and not the sleep(1)
child, which could result in the sh(1) process being terminated and
its sleep(1) child being leaked.
To get the bash-like behaviour portably, explicitly use the exec builtin
to instruct the shell to replace itself with sleep(1), so that the
process ID previously used for the shell becomes the process ID of the
sleep process.
This appears to resolve an intermittent hang and test timeout on Debian
machines (especially slower ones), although I'm not 100% clear on the
mechanics of how it happens.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3157
Signed-off-by: Simon McVittie <smcv@collabora.com>
`test-generated.txt` is listed in `test.gresource.xml`, so it needs to
be specified as a dependency in the `custom_target()` which uses
`test.gresource.xml`.
Fixes intermittent build failures like:
```
FAILED: gio/tests/test.gresource
/builds/GNOME/glib/_build/gio/glib-compile-resources --compiler=gcc --target=gio/tests/test.gresource --sourcedir=/builds/GNOME/glib/gio/tests --sourcedir=/builds/GNOME/glib/_build/gio/tests --internal ../gio/tests/test.gresource.xml
../gio/tests/test.gresource.xml: Failed to locate test-generated.txt in any source directory.
```
See !3671 and #3163.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This reverts commit 0b9900e4e7.
The dependency was added in the wrong place: `test-generated.txt` is
needed when compiling `test.gresource`, not when compiling the test
which ultimately uses that gresource.
See !3671 and #3163.
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
On CHERI-enabled systems we use uintptr_t as the underlying storage for
GType and therefore casting to gsize strips the upper bits from a pointer.
Fix this by casting via uintptr_t instead and introduce a new set of
macros to convert between GType and pointers.
It needs to be in a separate page because there isn’t actually a
`GFileAttribute` type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Move it to the struct docs, although again this is a little suspect
because there is actually no `GDBusAddress` struct/type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
This might not work, as `GContentType` isn’t actually a defined type
(content types are just strings). It would be a bit weird to create a
separate page for content types, though, as the functions handling them
are very method-like and feel like they should be grouped together like
methods of a class.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
If `update-desktop-database` or `update-mime-database` are not
installed, there are a few `GAppInfo` methods for modifying file
associations which will print a `g_warning()` when called. Something
like:
```
GLib-GIO-FATAL-WARNING: Failed to execute child process ‘update-desktop-database’ (No such file or directory)
```
(Example: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053)
This will cause the appinfo/associations test to fail, as warnings are
fatal.
If that’s going to happen, skip the test. We can’t hard-depend on these
tools as they are external to GLib and only needed for a few operations.
Instead we have a soft runtime dependency on them; that should be
reflected in the tests.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Commit f6c40b1d fixed libelf detection on FreeBSD (where the library has
no pkg-config file and needs to be found via `find_library()`), but
broke `-Dlibelf=disabled` on Linux, as `get_option('libelf')` was no
longer checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3120
Add a default modification timestamp flag to g_file_copy so that it
doesn't copy the modification time from the source file as it does by
default. Similarly to G_FILE_COPY_TARGET_DEFAULT_PERMS, this flag
overrides the G_FILE_COPY_ALL_METADATA flag.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3140
There are some flavors of MIPS ABIs, such like r6 vs legacy,
nan2008 vs nan1985 etc.
The `cc -r` may not produce the correct elf binaries.
So let's skip this test for MIPS.
Many toolchain did not change the definition of NULL to avoid introducing
breaking changes in existing codebases. For example, on Windows NULL is
0 (int) regardless of the C++ standard in use.
Fixes the following warnings on CLang when compiling for Windows:
../glib/glib/tests/cxx.cpp:539:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
../glib/gio/tests/cxx.cpp:62:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
Fixes the following warnings on CLang:
../glib/gio/gregistrysettingsbackend.c:1503:32: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
child_item->readable = TRUE;
^ ~~~~
../glib/gio/gregistrysettingsbackend.c:1567:28: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
child_item->readable = TRUE;
^ ~~~~
The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.
A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).
This causes the following issue, if we have:
typedef enum
{
G_ZERO,
G_ONE,
G_TWO
} GFoo;
struct _GBar
{
GFoo foo : 2;
};
and then assign bar.foo = G_TWO and read it back, it will have the
expected value of 2 (aka G_TWO) on GCC, but a value of -2 (not matching
any of the enum variants) on MSVC.
There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.
This corresponds to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6467
in GTK.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This triggered a warning from the CHERI compiler since the struct contains
a `void *` but `__attribute__((aligned(8))` reduced alignment to less than
the `void *` alignment (which is 16 for Arm Morello).
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
This should not result in any functional changes, but will eventually
allow glib to be functional on CHERI-enabled systems such as Morello.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
It’s not actually needed on any platform, and causes compilation
problems on platforms where it’s not available.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3111
The Comment field provides a user-visible description of the app,
which usually contains generic words ("and", "or", "not", "is", ...)
that add noise when used for search.
It made some sense to match against the field as a fallback for
Keywords, before that key was well established. However that key
has been around for years now, so hopefully every app where additional
terms are helpful uses it by now.
With that, the downside of added noise outweighs the benefit, so
it's time to stop matching on comments.
When setting the file time using utimensat, don't ignore
microseconds for access/modify times. By doing that, they're preserved
when using g_file_info_set_modification_date_time and then setting the file's
attributes from it.
Fixes#3116
Commit 9e2ad88455 improved app search results by allowing to differentiate
their match_type: prefix match or substring match; while giving more priority
to prefix matches over substring matches, but only when they are in the same
match_category[1].
This was a step forward but, as outlined in #3082, still not enough to get
most relevant results first to the user, because apparently (and for the
specific case of desktop app searching) a prefix match in a lower category
is more relevant to the user than a substring match in a higher category.
So that's what this commit implements, i.e. it makes sure prefix matches
are still preferred over substring matches but this time not only when
in the same category but also across different categories.
[1] Match category is the Desktop file key where the match happened.
They are shown below from top to lesser priority.
DESKTOP_KEY_Name
DESKTOP_KEY_Exec
DESKTOP_KEY_Keywords
DESKTOP_KEY_GenericName
DESKTOP_KEY_X_GNOME_FullName
DESKTOP_KEY_Comment
Fixes#3082
· Add a usage output that is printed when called with no argument
or with '--help' argument. This is helpful as it avoids having
to read the source code to know how to run the different options.
· Adds new '--should-show-only' option to 'search' command, to
better mimick the gnome-shell app search, by not returning
apps with NoDisplay=true.
Example for running a desktop app search with the new option from
inside the GLib build dir:
$ gio/tests/apps search --should-show-only settings
Make sure to fail consistently in case people created a GPropertyAction
with g_object_new() without passing a property name.
Bindings that construct objects with g_object_new() have no idea if a
property is mandatory.
See: #3130
This avoids a critical warning from trying to disconnect a signal
handler from a `NULL` object if `paction->object` is `NULL` for whatever
reason (see: the following commit).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3130
The `GTK_USE_PORTAL` environment variable has started to be misused by
users, which is causing deployment issues (such as portal services
themselves ending up being forced to use portals, which is never going
to work).
Try and sidestep users’ broken configurations by renaming the
environment variable, and also separating it from the old GTK
environment variable, since the GLib one affects a lot more processes.
This environment variable is meant to be used for
debugging and development, and never in production.
GTK already renamed their environment variable in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829, so keeping the
`GTK_USE_PORTAL` name in GLib doesn’t make sense anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3107
I had thought that because `g_source_destroy()` was called for the two
sources (cancel and timeout) in the `GTask` finalize function for a
threaded resolver operation, that it would be fine to use a plain
pointer in the source callbacks to point to the `GTask`.
That turns out to not be true: because the source callbacks are executed
in the GLib worker thread, and the `GTask` can be finalized in another
thread, it’s possible for a source callback (e.g. `cancelled_cb()`) to
be scheduled in the worker thread, then for the `GTask` to be finalized,
and then the source callback to continue execution and find itself
doing a use-after-free.
Fix that by using a weak ref to the `GTask` in the source callbacks,
rather than a plain pointer.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3105
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
