By encoding the path to the appinfo-test binary in the .desktop files,
we can avoid a chdir() call in the tests, which was a bit ugly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
This partially reverts commit 27b5fb5892.
The infrastructure for disabling a test is kept, but the appinfo and
desktop-app-info tests no longer need to be run serially.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1601
gtk-doc is unhappy that skeleton documentation comments had been written
for these functions (for the introspection annotations) but that the
documentation content was actually missing.
Add that content. I like a happy gtk-doc.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This partially reverts commit 799f8dcd46.
This patch seems to break the writability status of the server socket: once
somebody writes to it with success, then it reports it is not writable
anymore. Also, when the client socket has the flag FD_CONNECT set once,
it is never cleared and then it reports it is always writable, also when
it is not.
This checks if the stream is writable before writing
to it. If the write succeeded with no error, then the
stream has to be also writable after the write
Currently a new connection will not be attempted until the previous
one has timed out and as the current API only exposes a single
timeout value in practice it often means that it will wait 30 seconds
(or forever with 0 (the default)) on each connection.
This is unacceptable so we are now trying to follow the behavior
RFC 8305 recommends by making multiple connection attempts if
the connection takes longer than 250ms. The first connection
to make it to completion then wins.
As RFC 8305 recommends we can start multiple DNS queries in parallel
to more quickly make an initial response, especially when one is
particularly slow/broken.
This allows higher levels to have more control over resolving
(ipv4 or ipv6 for now) which allows for optimizations such
as requesting both in parallel as RFC 8305 recommends.
This means the output (including lists of filenames) does not depend on
the order of the input files, which may matter if this tool is invoked
with a glob or some other mechanism that doesn't guarantee an order.
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
Previously, method and signal arguments were sorted by name, which
(assuming you don't happen to give your arguments
lexicographically-ordered names) means the generated signatures were
incorrect when there is more than 1 argument.
While sorting the methods and signals themselves (and properties, and
annotations on all these) is fine, it's easiest to not sort anything.
Since 1217b1bc4f, LICENSE_STR has taken two
parameters, not one. Without this change, running either mode fails
with a traceback like:
Traceback (most recent call last):
File "../gdbus-codegen", line 55, in <module>
sys.exit(codegen_main.codegen_main())
File ".../codegen_main.py", line 294, in codegen_main
gen.generate()
File ".../codegen.py", line 896, in generate
self.generate_body_preamble()
File ".../codegen.py", line 682, in generate_body_preamble
self.outfile.write(LICENSE_STR.format(config.VERSION))
IndexError: tuple index out of range
8916874ee6, which introduced these flags,
was actually merged after that commit, but I assume it was written
beforehand.
This is to ensure that the generated code is still compilable by the
running compiler, and see whether we can read the things in there
properly.
See issue #1580.
glib-compile-resources was updated to generate octal byte
representation in a string, but unfortunately this breaks the build
on Visual Studio when the generated string sequence exceeds 65535
characters, which is the imposed limit on Visual Studio compilers.
To make things work on Visual Studio builds and to not slow down things
on other compilers, generate a code path for Visual Studio an array of
octal byte representations, as well as a code path for other compilers
that use the new string representation of octal values, and let the
compiler take the appropriate code path when compiling the
generated code.
Fixes issue #1580.
While uniqueness is great, sometimes you want to restart
a newer version of the same app. These two flags make that
possible.
We also add a ::name-lost signal, that is emitted when it
happens. The default handler for this signal just calls
g_application_quit(), but applications may want to connect
and do cleanup or state-saving here.
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
Putting the raw URIs in the documentation comments would not link them,
and the ‘%20’s in the URIs were being parsed by gtk-doc as symbol
references. Fix that by using Markdown to format them correctly as
links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Due to the line wrapping, gtk-doc was interpreting this second line as
redefining the @dbus_register documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Otherwise they fill your real ~/.config/mimeapps.list with rubbish and
race for access to it. This is arguably not good.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1514
If a D-Bus interface was annotated with o.fd.DBus.Deprecated, then the
corresponding GObject property, in the common GInterface implemented
by the generated GDBusObjectProxies and GDBusObjectSkeletons, to
access the generated code for the D-Bus interface was not being marked
with G_PARAM_DEPRECATED, even though the gtk-doc snippet had the
'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
If a D-Bus interface has a property that's annotated with
o.fd.DBus.Deprecated, then the corresponding GObject property was not
being marked with G_PARAM_DEPRECATED, even though the gtk-doc snippet
had the 'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
Allowing unsafe rehandshakes used to be required for web compatibility,
but this is no longer a concern in 2018. So there should no longer be
compatibility benefits to calling this function. All it does is make
your TLS connection insecure.
Also, rehandshaking no longer exists at all in TLS 1.3.
At some point (maybe soon!) glib-networking will begin ignoring the
rehandshake mode, so let's deprecate it now.
Let's entirely deprecate calling this function for rehandshaking. The
current documentation is OK, but guarantees defined behavior (to attempt
a rehandshake) when TLS 1.2 is in use. But there's no way to force TLS
1.2, and also no way to check which version of TLS is in use. I really
should have deprecated use of this function for rehandshaking entirely
last time I updated it.
Fortunately, there should be no compatibility risk for existing code,
because rehandshaking has no visible effects at the API level.
With the changes to limit GVariant type nesting (commit 7c4e6e9fbe),
it’s now possible to have a valid type signature which is not a valid
GVariant type when enclosed in parentheses (to make it a tuple).
Check for that when parsing the signature field in a D-Bus message.
Includes a unit test.
oss-fuzz#11120
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This test is intended to verify the fix for
https://bugzilla.gnome.org/show_bug.cgi?id=787731, which was that
g_file_query_filesystem_info() would return stale information for the
mount. After replacing a read-only mount with a read-write mount, this
test used to only fail if G_FILE_ATTRIBUTE_FILESYSTEM_READONLY was TRUE
and yet the file could be opened for writing. In particular, if (due to
a test bug) the file really was still on a read-only filesystem, the
test would pass.
Now that we have fixed that bug in the test, we can make a stronger
assertion.
fusermount -z behaves like umount --lazy, which is documented thus:
> Detach the filesystem from the file hierarchy now, and clean up all
> references to this filesystem as soon as it is not busy anymore.
Without this, the call to `fusermount -u` often fails with:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent call to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
It's not clear what is causing the mount to be busy. Inserting a
g_usleep (100 * 1000) before the calls to `fusermount -u` also works to
make the problem go away, but for the purposes of this test the
important point is that the mount is detached from the directory, for
which a lazy unmount is fine.
Fixes#1590.
In practice, fusermount -u often fails:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent calls to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
This may or may not cause the current test run to fail, but it reliably
causes a repeat run of the test to fail. This change causes the current
run to fail instead.
I made a mistake when last updating the documentation in 94a99ae9. I
wrote that, with TLS 1.3, this would perform a rekey instead of a
rehandshake. In fact, that's only true for client connections. For
server connections, it's a no-op.
I was a bit nervous about how to document the behavior anyway, because
we really don't know what behavior will be reasonable with non-GnuTLS
crypto backends. This behavior is reasonable for the GnuTLS backend, but
might not necessarily make sense for OpenSSL. Ideally, we would
discourage API users from doing things which could have unexpected
effects, so instead of documenting what the GnuTLS backend does, I think
it'd be better to document that this is "undefined but not dangerous,"
since of course we want to make sure that existing code that doesn't
know about TLS 1.3 is not broken.
The docs sound like settings list is a thing, and
a ::children-changed signal exists. That is not the
case, and will never be the case at this point, so
stop pretending.
Closes: #1362
Currently, GDBusProxy:g-name-owner only notifies changes to the unique
name owner of the remote object in case the proxy was constructed for a
well-known name.
That sounds like an artificial restriction, and it's convenient to
connect to notify::g-name-owner if a proxy instance has already been
created for an unique name, instead of additionally using
g_bus_watch_name() to track the owner.
To fix this, always connect to NameOwnerChanged after the proxy is
initialized, instead of only doing so when the proxy was constructed for
a well-known name.
https://bugzilla.gnome.org/show_bug.cgi?id=791316https://gitlab.gnome.org/GNOME/glib/issues/1310
test_c_args is defined in the root meson.build with unfiltered list of
compiler flags, then redefined in gio/tests/meson.build after the
subdir() call. Move it before.
The length of the stolen data from a memory output stream is given by
get_data_size() — get_size() can be larger, and hence cause unnecessary
overallocation.
Similarly to g_source_set_name(), this sets a name on a GTask for
debugging and profiling. Importantly, this name is propagated to the
GSource for idle callbacks for the GTask, ending the glorious reign of
`[gio] complete_in_idle_cb`.
The name can be queried using g_task_get_name(). Locking is avoided by
only allowing the name to be set before the GTask is used from another
thread.
Includes tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is the most degenerate possible test but it does exercise this code
path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to also add the flag
to the autotools build.)
The executable depends only on the generated header file at compile
time, and on the library at link time. So meson can decide to compile
gdbus-peer.c before compiling the library and thus won't have generated
the header yet, causing the build error.
So declare_dependency() should only have the header file in its sources,
to force generating files before compiling gdbus-peer.c without
including objectmanager-gen.c into gdbus-peer's sources.
We use libgdbus_example_objectmanager_dep as dependency for various
tests, but this implies only a link dependency while it doesn't ensure
that the sources are generated.
Make this explicit
mntent-based implementation filter out mounts with device path that was
repeated. Consequently, it is not possible to show such mounts in UI even
with x-gvfs-show, because they are not returned from g_unix_mounts_get.
libmount-based implementation currently doesn't filter out any mounts
which causes issues to our volume monitors. Let's rather mark mounts
which don't point into fs root as system_internal. This approach won't be
affected by mount order as is mntent-based implementation. It will mark
more mounts as system_internal than it is filtered out with mntend-based
implementation, but there will be always possibility to show them in UI
over x-gvfs-show, which was not possible with mntend-based. We can
probably introduce some improvements later to not mark unique mounts as
system internal even if they don't point into fs root...
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, there isn't API to determine root path for mounts created
over bind operation (or btrfs subvolumes). This causes issues to our
volume monitors if there is multiple mounts for one device, which can
happen with libmount-based implementation currently. Let's propagate
root path from libmount over g_unix_mount_get_root_path, so we can
handle this somehow in our volume monitors.
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, readlink() is used only 12 times when expanding symlinks.
However, kernel uses 40 for this purpose and it is defined as MAXSYMLINKS.
Use that constant if available, or 40. See:
https://github.com/torvalds/linux/include/linux/namei.h.
find_mountpoint_for() uses current file in case of error, because
get_parent() returns NULL for error, but also if parent doesn't exist.
Return "." from get_parent() if parent doesn't exist in order to
differentiate the error state.
Test symlink expansion in find_mountpoint_for() function over
_g_local_file_find_topdir_for(). find_mount_for() is crucial for many
of glocalfile.c functionality (e.g. to determine correct trash location)
and symlink expansion has to work properly.
https://gitlab.gnome.org/GNOME/glib/issues/1522
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was checking whether the signature provided by the blob was a
valid D-Bus signature — but that’s a superset of a valid GVariant type
string, since a D-Bus signature is zero or more complete types. A
GVariant type string is exactly one complete type.
This meant that a D-Bus message with a header field containing a variant
with an empty type signature (for example) could cause a critical
warning in the code parsing it.
Fix that by checking whether the string is a valid type string too.
Unit test included.
oss-fuzz#9810
Signed-off-by: Philip Withnall <withnall@endlessm.com>
