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
Yo, listen up, here’s a story
About a little guy that lives in a UTF-8 world
And all day and all night and everything he sees
Is just UTF-8 like him inside and outside
UTF-8 his house with a UTF-8 little window
And a UTF-8 corvette
And everything is UTF-8 for him and himself
And everybody around
’Cause he ain’t got nobody to listen
https://bugzilla.gnome.org/show_bug.cgi?id=791221
Clarify that the return value may be floating, or may not be (depends
on whether the input @value was in normal form).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=741167
Divide first, *then* cast. Otherwise a very long "now", which is
64-bit, gets truncated into a 32-bit time_t, which can't hold the
value, and turns negative more often than not.
https://bugzilla.gnome.org/show_bug.cgi?id=791128
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than unreffing them _after_ finalising the GSource and freeing
its struct. This fixes the case where the GSourceCallbackFuncs data
contains a pointer to the GSource, and the unref() function operates on
that pointer, e.g. by calling g_source_destroy(). This happens when
using g_source_set_dummy_callback() on a GSource, as the generated
GClosure needs to destroy the GSource when it is invalidated, which
could happen (at latest) when the GSourceCallbackFuncs.unref() function
is called during finalisation of the GSource.
By moving the GSourceCallbackFuncs.unref() invocation higher up in
g_source_unref_internal(), it becomes re-entrancy-safe for GSource
methods.
https://bugzilla.gnome.org/show_bug.cgi?id=692034
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
g_variant_get_normal_form() doesn’t necessarily return a floating
GVariant, so we have to take, rather than sink, the ref.
This fixes a lot of leaks with gdbus-codegen-generated code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=741167
When using gdbus-codegen to produce generated code for a method with
an out parameter with a signature like 'as', make sure to include
an "(array)" annotation for that parameter.
(Reworked by Philip Withnall to improve code formatting.)
https://bugzilla.gnome.org/show_bug.cgi?id=741167
If nl_langinfo() doesn’t support a particular item, it returns the empty
string. We should check for that and return NULL from
g_date_time_format() accordingly, otherwise the user could unwittingly
end up with a formatted date/time which is missing some or all of its
components.
This arose with %r in de_DE, which is unsupported by nl_langinfo()
because Germans almost never write time in 12-hour format.
Add a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790416
Apparently Solaris defines statbuf fields as long when Linux doesn’t, in
some cases. Cast down to the type expected by the printf() format
placeholder.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749652
When doing a level traverse of a GNode with depth of -1, the depth was
implicitly being converted to an unsigned integer. This worked (making
the depth limit G_MAXUINT), but was a bit mystical.
Change g_node_depth_traverse_level() to explicitly take a signed depth
and handle it appropriately.
Coverity issue: #1159465https://bugzilla.gnome.org/show_bug.cgi?id=732003
Two of the vfuncs in GMountOperation need some annotations for their
element types and array sizes, otherwise g-ir-scanner comes up with
nonsense output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773980
Bug #786580 triggered this warning to show up in the appinfo tests if
run on a machine where no terminal except xterm is installed (for
example, a build machine). Since we didn’t warn before if xterm but no
other terminals were installed, it seems reasonable to downgrade the
warning to a debug message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790914
Otherwise there is a race in finalising the GSourceCallback if one
thread is finishing off a g_main_dispatch() while another thread is
destroying the GSource which owns the GSourceCallback.
A helgrind log:
==21707== Possible data race during write of size 4 at 0x54EACB0 by
thread #12
==21707== Locks held: none
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECD953: g_main_dispatch (gmain.c:3081)
==21707== by 0x4ECE667: g_main_context_dispatch (gmain.c:3673)
==21707== by 0x4ECE859: g_main_context_iterate (gmain.c:3744)
==21707== by 0x4ECEC7F: g_main_loop_run (gmain.c:3938)
==21707== by 0x41C197: some_thread (some-code.c:224)
==21707==
==21707== This conflicts with a previous write of size 4 by thread #5
==21707== Locks held: 1, at address 0x54CF320
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECB86F: g_source_destroy_internal (gmain.c:1178)
==21707== by 0x4ECB9D4: g_source_destroy (gmain.c:1227)
==21707== by 0x41CF09: some_other_thread (some-other-code.c:410)
https://bugzilla.gnome.org/show_bug.cgi?id=737677
SystemTap tapsets are architecture-specific, as they include the full
path to the .so file for each probe they reference. Hence, we should
install them in an architecture-specific path, or multiarch systems will
suffer from collisions between them.
A better long-term solution, using $libdir rather than the
non-architecture-specific $datadir, is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264; but this will do
for now.
https://bugzilla.gnome.org/show_bug.cgi?id=662802
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
While gio module extension is loaded a new GProxyResolverPortal is
created to query whether it's supported. We always return FALSE when not
aunder flatpak, so we don't need to connect to the session bus in that
case. Add a helper ensure_resolver_proxy() that returns TRUE when the
proxy is created and use it in is_supported() instead of creating the
proxy unconditionally in the instance initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=790894
This removes the use of defined() in a macro expansion, which may not be
portable to some pre-processors. Instead, we hoist the defined check
outside the macro expansion.
https://bugzilla.gnome.org/show_bug.cgi?id=790877
The example code defines an interface with three methods. The preceding text
reads 'This interface defines two methods'. This appears to be because the
example code was changed without updating the surrounding text.
https://bugzilla.gnome.org/show_bug.cgi?id=790830
We can’t guarantee that the builddir we’re generating in actually exists
— if doing a clean build with builddir ≠ srcdir, and there are no other
rules which generate build products in builddir, the .test generation
rule can fail. This happens for flatpak-builder.git for me.
Try to avoid that by explicitly creating the builddir.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790785
Since automake 1.11.2, it’s recommended to use the prefixed version and
leave the unprefixed version for users to override. Since we depend on
automake 1.13.3, we should be doing this.
Based on a patch by Sam Spilsbury <smspillaz@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
