The modification time test creates a file, gets the modification time in
seconds, then gets the modification time in microseconds and assumes
that the difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
This is necessary when building glib with icecc. Icecc splits the build
process into two parts. The file is locally preprocessed with
-fdirectives-only to resolve any includes. This adds linemarkers to the
intermediate file. Without the new-line at the end of the file this:
#include "gconstructor_as_data.h"
#include "glib/glib-private.h"
Is turned into this:
const char gconstructor_code[] = "...";# 1 "glib/glib-private.h"
...
The result is a compile error:
In file included from ../glib/gio/glib-compile-resources.c:45:
gio/gconstructor_as_data.h:1: error: stray '#' in program
gio/gconstructor_as_data.h:1: error: expected identifier or '(' before numeric constant
In file included from ../glib/glib/glib-private.h:22,
from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/gwakeup.h:27:1: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:28:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:30:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:32:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:33:42: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:98:3: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:99:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h💯58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:102:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:103:58: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:164:53: warning: file "../glib/gio/glib-compile-resources.c" linemarker ignored due to incorrect nesting
To avoid this, generate gconstructor_as_data.h with a new-line at the end
of the file.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This helps to void deadlocks when two processes call interfaces on each
other one of them being org.freedesktop.DBus.ObjectManager.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
The current code is unsafe to use from multiple threads at once.
GIOStream functions like this are supposed to be semi-threadsafe. It's
allowed for them to be called on both a reader thread and a writer
thread at the same time. Of course, it's still tricky and dangerous,
because it's only *really* threadsafe if the handshake has finished,
and API users have no plausible way to know that because the API
does not require performing an explicit handshake operation. But that's
a glib-networking problem. We can at least avoid the most obvious
threadsafety issue here in the API layer.
Note that we'll need to implement the new vfunc in glib-networking for
this to actually work.
Fixes#2393
The documentation for `g_bus_watch_name()` implies that the
`GDestroyNotify` for the user data will be called in the current thread
default `GMainContext`. Currently, it could be called in any thread, as
`client_unref()` can be called in any thread.
Fix that by deferring it to an idle source if `client_unref()` finalises
the `Client` object in a different thread.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These were missing from the test before the previous commit ported from
`GMainLoop` to `GMainContext`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It makes combination exit conditions a lot easier than when using
`g_main_loop_quit()` from different callbacks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Work around a bug in Meson versions < 0.50.0 where
`--wrap-mode=nodownload` would disable the use of fallback subprojects,
even if they’d already been downloaded, with the message:
```
Cross dependency libpcre found: NO (tried pkgconfig and cmake)
Cross dependency libpcre found: NO (tried pkgconfig)
Not looking for a fallback subproject for the dependency libpcre because:
Use of fallbackdependencies is disabled.
meson.build:1998:2: ERROR: Dependency "libpcre" not found, tried pkgconfig
```
This workaround can be dropped in the near future when we bump our Meson
dependency to something less ancient. We have a self-imposed requirement
to be buildable using what’s packaged in Debian Stable, which is
currently Meson 0.49.2 — but the new Debian Stable release is coming
soon, with an updated Meson.
Using `--force-fallback-for=libpcre` would have been a more constrained
workaround, but unfortunately that argument didn’t exist in Meson 0.49.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
No behavior changes. Just reindent the existing code to avoid a GCC
warning spam.
I considered changing the code to not run fflush() on every iteration of
the loop, but I doubt it matters much, so I left it be.
This should maintain equivalent functionality, apart from that now you
have to pass `--force-fallback-for libpcre` to `meson configure` in
order to use the subproject; rather than specifying
`-Dinternal_pcre=true` to use the internal copy.
This also fixes#642, as the wrapdb copy of libpcre is version 8.37.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962Fixes: #642
Fedora 29 is no longer available, and I need to rebuild these images so
libpcre is pre-downloaded as a subproject.
Update them to Fedora 31, which is what we use in `fedora.Dockerfile`.
This should allow some blobs to be shared in the container repository.
This isn’t the latest Fedora release, but I don’t want to go through the
hassle of updating all the CI images to F33 right now in addition to
updating the subproject caches.
`python-unversioned-command` is needed because the Android NDK calls
`python` without a version number. F29 must have installed this already.
The Android NDK setup appears to be OK with Python 3.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
This is basically a contrived test to trigger the `bytes->user_data !=
bytes->data` condition (and none of the earlier short-circuiting
conditions in that statement) in `try_steal_and_unref()`. This gives
100% line and branch coverage for `gbytes.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The first sentence incorrectly said that it checked the type of the
value, and then the second sentence explicitly said it was a programmer
error to give a value of the wrong type.
According to the code, the second sentence is correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2425
WebKit wants these private key properties to be readable in order to
implement a deserialization function. Currently they are read-only
because at the time GTlsCertificate was originally designed, the plan
was to support PKCS#11-backed private keys: private keys that are stored
on a smartcard, where the private key is completely unreadable. The
design goal was to support both memory-backed and smartcard-backed
private keys with the same GTlsCertificate API, abstracting away the
implementation differences such that code using GTlsCertificate doesn't
need to know the difference.
The original PKCS#11 implementation was never fully baked and at some
point in the past I deleted it all. It has since been replaced with a
new implementation, including a GTlsCertificate:private-key-pkcs11-uri
property, which is readable. So our current API already exposes the
differences between normal private keys and PKCS#11-backed private keys.
The point of making the private-key and private-key-pem properties
write-only was to avoid exposing this difference.
Do we have to make this API function readable? No, because WebKit could
be just as well served if we were to expose serialize and deserialize
functions instead. But WebKit needs to support serializing and
deserializing the non-private portion of GTlsCertificate with older
versions of GLib anyway, so we can do whatever is nicest for GLib. And I
think making this property readable is nicest, since the original design
reason for it to not be readable is now obsolete. The disadvantage to
this approach is that it's now possible for an application to read the
private-key or private-key-pem property, receive NULL, and think "this
certificate must not have a private key," which would be incorrect if
the private-key-pkcs11-uri property is set. That seems like a minor
risk, but it should be documented.
