There are a lot of links to the description of I/O priority in the GIO
docs, and they’re all currently broken since the docs build was ported
to gi-docgen.
Use a simple find and replace (see below) to fix them. This doesn’t port
any of the surrounding docs to gi-docgen format, but should still
improve things overall.
```sh
git search-replace --fix '\[I/O priority\]\[io-priority\]///[I/O priority](iface.AsyncResult.html#io-priority)'
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
g_file_copy_async() and g_file_move_async() are written in a way that is
not bindable with gobject-introspection. The progress callback data can
be freed once the async callback has been called, which is convenient
for C, but in language bindings the progress callback closure is
currently just leaked.
There is no scope annotation that fits how the progress callback should
be treated:
- (scope call) is correct for the sync versions of the functions, but
incorrect for the async functions; the progress callback is called
after the async functions return.
- (scope notified) is incorrect because there is no GDestroyNotify
parameter, meaning the callback will always leak.
- (scope async) is incorrect because the callback is called more than
once.
- (scope forever) is incorrect because the callback closure could be
freed after the async callback runs.
This adds g_file_copy_async_with_closures() and
g_file_move_async_with_closures() for the benefit of language bindings.
See: GNOME/gjs#590
This is an introspection-friendly version of g_settings_bind_with_mapping.
Having two callbacks that share the same user data is not supported by
girepository, so the existing function is not introspectable.
Closes: #564
These consistently fail on scheduled CI runs, which is not helping our
ability to catch Hurd regressions.
For example, https://gitlab.gnome.org/GNOME/glib/-/jobs/3709402
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3148
The gdbus-example-objectmanager visibility header was being re-created
on reconfigure, causing a needless rebuild of gdbus tests that were
using the visibility header.
All other invocations of gen_visibility_macros are via custom_target.
If we don't do this, the --help text is formatted as though the option
did not expect an argument.
IDENTIFIER is a new translated string, but it is developer-oriented,
so a missing translation is not particularly bad. COMMAND is already
present in translations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, the --help text is formatted as though the option
did not expect an argument.
This introduces a new translated string, but it is developer-oriented,
so a missing translation is not particularly bad.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The ref held by `data->task` may be the last one on the `GTask`. The
`GTask` stores `attempt->data` as its task data, and so when the `GTask`
is finalised, `attempt->data` is too. `connection_attempt_remove()`
needs to access `attempt->data`, so must be called before the
`g_object_unref()` in this situation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3266
Currently, the `stop_func` is executed on an extra thread, and the
`g_context_specific_group_remove` function returns before the `stop_func`
finishes. It may happen that the `stop_func` is never executed if the
program terminates soon after calling it. Let's wait until the `stop_func`
is done.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3258
This should clarify things a little for users of language bindings, who
don’t directly use `.pc` files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This creates `GioUnix`, `GioWin32`, `GLibUnix` and `GLibWin32`. These
bodies of documentation are in addition to the main, platform agnostic,
documentation for both libraries.
This commit necessarily includes various mechanical changes to update
the repository namespace used in various existing documentation links to
platform specific APIs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There was no obvious logical need to list the `GAppInfo` subclass
sources separately in the build. It makes more sense to add them to the
platform-specific source lists, since they are platform specific.
This will be used in an upcoming commit which generates
platform-specific GIR files, so needs the full platform-specific lists
of sources.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
`GFileDescriptorBased` is in `gio-unix-2.0` rather than `gio-2.0`, so
its types shouldn’t be declared in a header belonging to the latter.
This hasn’t been a problem previously because C is fine with that. But
upcoming commits are going to split the introspection scanning for
`gio-2.0` and `gio-unix-2.0`, and the introspection scanner is a little
more picky about declarations not being spread all over the place.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The symbols still have to be exported from the library (since they’re
called from unit tests), but there was never any reason for them to be
in a public header.
This means they now disappear from `Gio-2.0.gir`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
This property is supposed to be used by authors of applications that use GAppliaction to output the version by --version flag or otherwise if a version is needed.
Closes#3198
Signed-off-by: Maxim Moskalets <Maxim.Moskalets@kaspersky.com>
This is another way to get the file system type from `statvfs()`, newly
added in glibc 2.39
(https://lwn.net/ml/libc-alpha/38790850.J2Yia2DhmK@pinacolada/).
This hasn’t been tested with glibc 2.39 as I don’t have it, but the
change seems fairly straightforward.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not suitable to use to check if your own code has already called
`g_task_return_*()`, as it doesn’t directly correlate to that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If we're writing the body to standard output, we cannot know what the
filename of the corresponding header is going to be, but it seems
vanishingly unlikely that it will be either `stdout.h` (which we would
traditionally have generated) or `-.h` (which we would have generated
since !3886).
This makes some of the output snippets sufficiently short that black(1)
requires that they are folded into a single line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In command-line tools, ordinary filenames normally do not have
special-cased meanings, so commit 3ef742eb "Don't skip dbus-codegen tests
on Win32" was a command-line API break: in the unlikely event that a
user wanted to write to a file named exactly `stdout`, this would have
been an incompatible change.
There is a conventional pseudo-filename to represent standard output,
which is `-` (for example `cat -` is a no-op filter). Adding support
for this is technically also a command-line API break (in the very
unlikely event that a user wants to write to a file named exactly `-`,
they would now have to write it as `./-`), but filenames starting with
a dash often require special treatment anyway, so this probably will not
come as a surprise to anyone.
When the output filename is `-` we don't want to use `#ifdef _____` as
a header guard, so special-case it as `__STDOUT__` as before.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Memory was leaking when allocating it inside libelf and losing the pointer to it (it was an automatic variable) when returning NULL from the get_elf function in some cases
Closes#3242
Signed-off-by: Maxim Moskalets <Maxim.Moskalets@kaspersky.com>
This reverts commit fbdc9a2d03.
It was not submitted through a merge request and broke CI. Reverting it
immediately to unbreak CI and hence the rest of the development
pipeline. The changes can be re-submitted as a merge request so they’re
properly tested in CI before being merged.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3857#note_1994336
The previous commit enabled the `/run/mount/utab` monitoring. The problem
is that the `mount-changed` signal can be emitted twice for one mount. One
for the `/proc/mounts` file change and another one for the `/run/media/utab`
file change. This is still not ideal because e.g. the `GMount` objects for
mounts with the `x-gvfs-hide` option are added and immediately removed.
Let's enable the `mnt_monitor_veil_kernel` option to avoid this.
Related: https://github.com/util-linux/util-linux/pull/2725
The `GUnixMountMonitor` object implements monitoring on its own currently.
Only the `/proc/mounts` file changes are monitored. It is not aware of the
`/run/mount/utab` file changes. This file contains the userspace mount
options (e.g. `x-gvfs-notrash`, `x-gvfs-hide`) among others. There is a
problem when `/sbin/mount.<type>` (e.g. `mount.nfs`) helper programs are
used. In that case, the `/run/mount/utab` file is updated later than the
`/proc/mounts` file and thus the `GUnixMountMonitor` clients (e.g.
`gvfs-udisks2-volume-monitor`, `gvfsd-trash`) don't see the userspace
options until the next `mount-changed` signal. Let's use the `libmnt_monitor`
API for monitoring instead and emit the `mount-changed` signal also when the
`/run/mount/utab` file is changed.
Related: https://issues.redhat.com/browse/RHEL-14607
Related: https://github.com/util-linux/util-linux/pull/2607
This fixes a race condition which frequently caused the
`memory-monitor-dbus.py` test to fail.
The registration of the `LowMemoryMonitor` object on the bus, and the
`GMemoryMonitorDBus`’s connection to the warning signal raced, such that
it was possible for the mock `LowMemoryMonitor` to emit a warning signal
before the `GMemoryMonitorDBus` proxy was listening, and hence the proxy
would never see the signal.
Fix this by explicitly synchronising the two before proceeding to the
tests.
Make the same changes in the `memory-monitor-portal.py` test too, even
though that one was not failing. This should remove the need for a 2s
wait on every test run.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2887
Otherwise the test can go on to wait for a signal from the service
before it’s actually finished starting up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
