Previously the len passed to g_socket_address_new_from_native() was only
for IPv4 addresses and the constructor would fail.
This was reported and discussed here:
fe0139ee98 (note_2581394)
Currently two of the tests from libffi 3.5.2 fail on macos-arm64, and
this is not something I have any chance of debugging:
```
481/1066 libffi:closures / closure_loc_fn0 -O0 FAIL 0.54s killed by signal 6 SIGABRT
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Check failed:
memcmp(pcl, FFI_CL(codeloc), sizeof(*pcl)) == 0
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
485/1066 libffi:closures / cls_1_1byte -O0 RUNNING
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_CHECK_=2 G_DEBUG=gc-friendly G_ENABLE_DIAGNOSTIC=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=147 LINT_WARNINGS_ARE_ERRORS=1 /Users/Shared/work/bgilbert/glib/_build/subprojects/libffi-3.5.2/testsuite/cls_1_1byte_O0
482/1066 libffi:closures / closure_loc_fn0 -O2 FAIL 0.55s killed by signal 6 SIGABRT
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Check failed:
memcmp(pcl, FFI_CL(codeloc), sizeof(*pcl)) == 0
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Version 3.5.2 emits some deprecation warnings on macOS, and those are
out of our control to fix, and also not relevant to the GLib build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is the same commit we were already pinning to, but now that there's
a release, we can switch to the WrapDB wrap so `meson wrap update` will
pick up future releases.
We have various APIs that return FDs (such as g_mkstemp) but we do not
have a generic way to get the file name from it.
As per this, provide a simple and cross-platform way to lookup the file
path for an open FD.
This is marked as an unix-only API, although it could be technically be
implemented for windows too
add implementations for these functions using st_{a,c,m}timespec when
__APPLE__ is defined. Also re-enable the g-file-info test for darwin.
Fixes#3070, #2608
`GDBusProxy` implements this interface but allows construction with a
`NULL` interface info and also marks its getter/setter for the interface
info accordingly.
Callers of `g_dbus_interface_get_info()` need to assume that it can
return `NULL` unless they constructed the `GDBusInterface` in a way that
guarantees that the interface info is available.
The connectivity is directly derived from the `is_available` variable,
so if that changes, we need to notify of a change in `connectivity` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3803
This step is no longer "hidden away in the infrastructure" but now in
the open.
Background: some GLib tests can fail with timeouts because of some
assumptions regarding the temporary directory that don't work out on
macOS. Until this is properly investigated and resolved, the
workaround is to redirect it to a ramdisk.
Also add ORKA_RUNNER variable as the macOS CI infrastructure evolves.
Future changes to the image can be controlled this way.
Fixes https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/2091
We have some (deprecated) methods that technically still return
transfer-full instances of GTypeClass's and GTypeInterface's.
The introspection scanner cannot generate bindings for them though since
it does not know how to manage their lifecycle, and we end up skipping
these symbols.
This is breaking some language bindings, and in particular gjs [1] and
lua-lgi, that were using the .ref methods.
While we should not use deprecated functions in the language bindings,
these symbols should still be introspected.
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/711
Partially reverts commit cad84d5e27.
When a snap is launched from its non-dbus-activable desktop file we may
still need to use the portal to pass the URIs to the program, so that it
can access to them even if confined.
In fact most snaps are not dbus-activable, but they rely on the classic
desktop file activation.
Seems scan-build is incorrectly assuming that `output != NULL` at the start
of the function (so `file` is opened), and then later assuming that
`output == NULL` (so `file` is not closed).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Keep the old error reporting FD around until duping it has worked,
otherwise we don’t have an FD to report errors on.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We were previously relying on it returning `EINVAL` so we could return
an error message, but scan-build doesn’t like that, so let’s just
explicitly return the same error anyway to shut scan-build up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The value of `errno` can apparently be undefined after a successful
function call (according to scan-build), so only check `errno` on
failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Snap applications like flatpak apps may need to use the portals to open
files, so use the same logic that we have for flatpaks but using the
snap ID that matches portal expectations
We were checking the results of opening an sandboxed application, but
never if the open was actually invoked.
So if another desktop file was used in tests, we were never getting any
failure, at least not related to the lack of a file being opened
