It might not be immediately obvious that this is the case. Let's record
it in the description of `GTimeVal` itself and also in
`g_time_val_from_iso8601`.
We also drop an incorrect statement in the documentation for
`g_time_val_from_iso8601` stating that years up to 3000 were supported;
this is also not true for the same reason.
Related: #1509
(cherry picked from commit 68a4e273b443ad79a3cd392d464390ab6a3fed2e)
On 32 bit systems, the size of a long might be the same as the size of
an int. In that case, we won't be able to get an overflow when
converting from a GTimeVal to a time_t. Skip the test for this in that
case.
Closes#1509
(cherry picked from commit f697f6aa08dc5499ae1c5c9177976cc62d19a998)
The ::network-changed signal is documented to indicate any change in
network configuration, which doesn't necessarily imply a property
change - additional services becoming available after connecting to
a VPN comes to mind for instance.
In order to match the "native" network monitor's behavior, always
emit the signal when it's in response to the 'changed' D-Bus signal.
Also emit the signal unconditionally when loading the initial property
values, to allow clients to differentiate between "offline" meaning
"offline" and "offline" meaning "uninitialized".
The behavior of "which" is not standardized by POSIX. Some old
implementations print their error messages to stdout instead of stderr,
and don't return a nonzero exit code when they fail to find the given
program. "command -v" on the other hand is in POSIX (optional in 2004
and required as of 2008).
Remove otherwise-unused variables AUTORECONF and GTKDOCIZE.
It fails because dist-job (correctly) doesn’t build with the code
coverage CFLAGS enabled.
Leave coverage to be generated on master and development branches.
See this pipeline for an example of when it fails:
https://gitlab.gnome.org/GNOME/glib/pipelines/26349
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is what Autotools does, and it's what all consumers of the
GModule API expect. Without this change, people on macOS upgrading to
a GLib built with Meson will find that their plugins no longer load.
Projects that use Meson and the `g_module_build_path()` API such as
glib-networking should pass `name_suffix:` to `shared_module()` to
ensure that plugins continue to be called libfoo.so on macOS.
New GModule API will eventually be added to address this.
See also:
https://gitlab.gnome.org/GNOME/glib/issues/1413a3d81719fe/meson.build (L108)
This reverts commit 3c1902fcf9ff9d0fb162d6ea71ec94c253687f84.
This was accidentally re-added from an old version of the branch before
!265 was merged. It should not have been re-added.
Rearrange the code so we try version 3 first,
falling back to version 2 and then version 1.
We still do a construct-time check to ensure
that we work with unsupported versions.
Note that this also takes care of setting the
initial property values in the version 1 case.
Version 3 of the network monitor portal interface adds
a CanReach method. Use it to implement can_reach.
The docs state that can_reach will either return TRUE
or set an error. So, set an error of G_IO_ERROR_HOST_UNREACHABLE
when the portal returns FALSE for CanReach.
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
