Clarify the licensing of the code generated by the two scripts in a
comment in the header of each generated file. The intention is that the
license of GLib does *not* apply to the generated files; but that they
are subject to the linking restrictions of the LGPL, since they link to
GLib and GLib is licensed under the LGPL. The generated files themselves
are under the license of whatever project they’re generated for.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
We should ensure a stable order when processing the files, regardless of
the order they were submitted on the command line, to increase the
chances of a reproducible build.
The old Perl-based version of glib-mkenums was fixed in commit 8686e430
to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=691436
The fallback code for providing a default comment template only worked
if a template file was provided. It didn’t work if individual templates
were provided on the command line (and --comment wasn’t).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
Putting them in the same section causes gtk-doc to mix their properties
together in a single listing, which is confusing.
Since having them in a single section doesn’t really add anything, split
them out to one class per section.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791334
New test to make sure we exercise the code paths in gdesktopappinfo.c
that get triggered when g_desktop_app_info_launch_uris_with_spawn()
is used (i.e. unknown app ID, no session bus), both for when either
a single URI or multiple ones are expected by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
If an application calls g_app_info_launch_uris() with a GList that includes
NULL values in some of its data members, and GIO ends up internally calling
g_desktop_app_info_launch_uris_with_spawn() for whatever reason (e.g. no
D-Bus session available), expand_macro() will crash due to the invalid data.
As this is considered a programmer error, use g_return_val_if_fail() in those
situations to prevent the crash from happening, but printing a warning anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
This list will be modified in-place when calling expand_macro(), so pass a copy
of it instead the original pointer, that is supposed to be an input parameter
only for g_desktop_app_info_launch_uris_with_spawn().
https://bugzilla.gnome.org/show_bug.cgi?id=791337
The thumbnail attributes would previously only be set if thumbnail::path
was included in the query — so querying for just thumbnail::is-valid
would return no results.
This fixes the behaviour of
gio info -a thumbnail::is-valid ./some-file.png
vs
gio info -a thumbnail ./some-file.png
The first command would previously list nothing. The second would
previously list a thumbnail::path and thumbnail::is-valid.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791325
When using python3 as interpreter, range only takes integer arguments or
it results in errors like:
File "/usr/bin/gtester-report", line 78, in html_indent_string
for i in range (0, (n + 1) / 2):
TypeError: 'float' object cannot be interpreted as an integer
https://bugzilla.gnome.org/show_bug.cgi?id=791296
This is happening since f591366eee, that
changed the way tests were skipped to use g_test_skip() instead of just
ignoring them. They are now reported to the log with G_TEST_RUN_SKIPPED
as result.
https://bugzilla.gnome.org/show_bug.cgi?id=790934
If we can’t convert the inotify event mask into a GFileMonitorEvent enum
value, don’t propagate it to GLocalFileMonitor, since it hits an
assertion failure in that case.
This should no longer be possible since the previous commit to ignore
IN_Q_OVERFLOW events, but we might as well change this just in case
other bugs crop up in event mask handling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
There’s not much we can do about them, and if they go unhandled, they
can propagate through to g_file_monitor_source_handle_event() and cause
assertion failures due to not mapping to a GFileMonitorEvent.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
It seems that when GLib is compiled without CFLAGS=-g, gdb can’t work
out the size of __glib_assert_msg, so assumes it’s 4 bytes — even on
64-bit systems. This causes it to not read the most significant 4 bytes
of the assertion message pointer, and hence it can’t print the stored
assertion message. This causes assert-msg-test to fail.
The upstream gdb bug is
https://sourceware.org/bugzilla/show_bug.cgi?id=22501.
Work around that by referencing and dereferencing __glib_assert_msg so
that gdb treats it as a pointer of sizeof(char*) rather than of the size
it incorrectly calculated from the library’s symbol table (or through
some other mystical process).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782057
Uris may be altered by the following code, which breaks xdg-open:
file = g_file_new_for_commandline_arg (arg[i])
uri = g_file_get_uri (file);
Examples of possible uri changes:
mailto:email -> mailto:///email
magnet:?xt=urn:hash -> magnet:///?xt=urn:hash
ssh://user@host -> sftp://user@host
This patch causes that uris aren't preprocessed for locations with
scheme, however absolute and relative paths are still preprocessed.
https://bugzilla.gnome.org/show_bug.cgi?id=779182
The initial MSVC 201x projects inadvertly disabled
RandomizedBaseAddress, which is normally enabled by default, so ensure
that is the case for all 201x builds. This feature is supported by
Visual Studio 2010 or later.
Also, for x64 builds on MSVC 2012 or later, use /HIGHENTROPYVA when
linking.
Pointed out by Ignacio Casal Quinteiro.
If gio open exits before the program it starts fully activates, then
the dbus-daemon may avoid doing the activating method call.
This commit works around the problem by pinging the activated application,
and waiting for a reply.
Same workaround is used in gtk-launch and was used in gvfs-open before
it was replaced by gio open.
https://bugzilla.gnome.org/show_bug.cgi?id=780296
Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...
https://bugzilla.gnome.org/show_bug.cgi?id=781867
Make config.h.win32.in reflect on the entries that are in the
autotools/Meson builds more closely.
Also declare that we have fd_set, declare SIZEOF_[SIZE|SSIZE]_T and
SIZEOF_LONG_LONG for 32-bit and x64 builds properly.
Note that since the Visual Studio 2015/2017 CRT's vsnprintf() and
snprintf() are not compliant enough (though they are much closer than
before) for GLib's purporses, we still use the gnulib's implementations
of them, as with the pre-Visual Studio 2015 builds.
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the Meson build files are not dist'ed by 'make dist', which are
reqired for things to work, and there was a missing '\' that cause some
of the meson.build files under tests/ not to be disted.
https://bugzilla.gnome.org/show_bug.cgi?id=783210
They are not supported by Visual Studio, so only define them in
glibconfig.h.in when not on Visual Studio. Fixes builds of GTK+-2.x
against Meson/MSVC builds of GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
This reverts commit 799f8dcd46.
This patch seems to break applications that use GTask specific
operations with GSocket. We will need to investigate a bit more
on this issue but for now we revert it and leave it for the
next major release.
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
