If the GNetworkMonitorNetlink is finalised part-way through a dump
(after request_dump() is called, but before finish_dump() is called),
dump_networks was leaked. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
This should introduce no functional changes. Factor out some common
code, flip some arguments around to use the more conventional (data,
length) order, and move some memory management calls out of
if-blocks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
By using g_timeout_source_new_seconds(), we can let timer wakeups be
coalesced by the scheduler, and reduce power consumption a bit. This
shouldn’t really affect the accuracy of the network monitoring.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
Previously, the GSource would be attached to whatever GMainContext was
the thread default at the time; but that might no longer be the same as
the default at the time of constructing the GNetworkMonitor.
Save the default from construction time, so that source callbacks are
always invoked in the same GMainContext.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
If adding months or years to a date, the day of the month of the result
is supposed to be the same as in the input — but that doesn’t work if
that day doesn’t exist in the result month.
Clarify the documentation about what happens here (the day of the month
is clamped to the length of that month).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Some source code comments amended to avoid possible future confusion.
It has been explained that a month name is used in a genitive case
only if it is required by the language rules. Also it has been
explained that %OB is also supported by other platforms (e.g., BSD)
but for this test we are focused on glibc 2.27 vs. Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=749206
In doing so, ensure that g_option_context_set_ignore_unknown_options()
is always called if completion is being done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793597
In this situation:
$ gdbus emit --session --object-path /org/foo/bar --sig<tab><tab><tab>
We will currently insert --signal three times.
We should only do that once.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
Commit faf9440908 made the bash completion more
robust, but in doing so it made the optional --dest argument to `gdbus emit'
mandatory by mistake.
Remove the error case when --dest is not specified. To keep the completion
working, we shuffle the cases around. --dest should be offered up for
completion after --session/--system/--address have been supplied, so we can
complete its argument. Additionally, if --dest isn't specified then we can't
complete --object-path or --signal, so guard these completions accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
When completing, we parse the options that the user has typed so far. Up
until now we've been doing this without ignoring unknown options. This
leads to broken completions when the user has typed an incomplete
parameter.
For example, when doing the following:
$ gdbus emit --session --obj<tab>
We expect --object-path to be completed, but it is currently not. What
happens is that we fail to parse the options, therefore don't act on
--session and so don't connect to the session bus, then we early-exit
because we need to know which bus to operate on for later completions.
Instead we can ignore the half-completed --obj, parse --session, get
connected to the bus and then move on to the later completion code.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
The case was wrong, and ‘mayo’ had not been abbreviated to ‘may’. The
new translated strings here have all been copied from the abbreviated
month names (without days).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793645#c5
We're mostly interested into building and testing everything that gets
pushed to the repository — including merge requests.
When pushing tags, though, we should assume we're spinning a release, so
let's run the dist target, and store the tarball, and the generated
documentation while we're at it, as artifacts on GitLab.
The Dockerfile for the image used for the build is included in tree, and
published on Docker Hub. Using a custom image allows us to avoid the
costly "download and install build dependencies" phase, as well as
controlling the environment a little bit better.
https://bugzilla.gnome.org/show_bug.cgi?id=793635
