- Apr 12, 2022
-
-
Jeremy Bicha authored
-
Jeremy Bicha authored
-
- Mar 23, 2022
-
-
Jeremy Bicha authored
-
- Mar 22, 2022
-
-
Johannes Schauer Marin Rodrigues authored
debian/libglib2.0-0.postinst.in: only run clean-up-unmanaged-libraries on upgrades and not on new installations Closes: #1008096
-
- Mar 18, 2022
-
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
-
- Mar 17, 2022
-
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
Update to upstream version '2.72.0' with Debian dir a41fad36aad216218ce25baf677fb192d976ce58
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
Update to upstream version '2.70.5' with Debian dir c72015f056365226cd9911e386ba3f83d398c110
-
Simon McVittie authored
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Charles Monzat authored
-
Milo Casagrande authored
-
Мирослав Николић authored
-
- Mar 16, 2022
-
-
Simon McVittie authored
Backport !2554 “gtimezone: Fix assertion failure when called with a huge offset” to glib-2-70 See merge request GNOME/glib!2555
-
Philip Withnall authored
This looks like a regression from commit 3356934d, but prior to that commit there was always an assertion failure when calling `g_time_zone_new_offset()` with an offset which is too large (such as 44 hours), ever since the function was added in commit cf24867b. It would be ideal if we could return a `NULL` timezone to indicate the error, but that’s not part of the API for `g_time_zone_new_offset()`, so we have to go with the dated and not-ideal approach of returning the UTC timezone and letting the caller figure it out. Another potential approach would be to reduce the `offset` modulo 24 hours. This makes the error less easily detectable than if returning UTC, though, and still returns an invalid result: `+44:00` is not the same timezone as `+20:00` (it’s one day further ahead). Add a unit test. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2620
-
Simon McVittie authored
gtimezone: Fix assertion failure when called with a huge offset Closes #2620 See merge request GNOME/glib!2554
-
Philip Withnall authored
This looks like a regression from commit 3356934d, but prior to that commit there was always an assertion failure when calling `g_time_zone_new_offset()` with an offset which is too large (such as 44 hours), ever since the function was added in commit cf24867b. It would be ideal if we could return a `NULL` timezone to indicate the error, but that’s not part of the API for `g_time_zone_new_offset()`, so we have to go with the dated and not-ideal approach of returning the UTC timezone and letting the caller figure it out. Another potential approach would be to reduce the `offset` modulo 24 hours. This makes the error less easily detectable than if returning UTC, though, and still returns an invalid result: `+44:00` is not the same timezone as `+20:00` (it’s one day further ahead). Add a unit test. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2620
-
Philip Withnall authored
gtlsconnection: fix typo in docs See merge request GNOME/glib!2552
-
Michael Catanzaro authored
Grrr, copy/paste error detected.
-
Philip Withnall authored
tests: More flaky test fixes to converter-stream and test-printf See merge request GNOME/glib!2551
-
- Mar 14, 2022
-
-
Philip Withnall authored
When the test has finished writing all the expanded content into the socket, explicitly close the output stream, which should make the input stream readable and non-blocking. The code intended to do this before, but only as a side-effect of dropping its last reference to `right`. If another reference was being held to `right` somewhere else, it wouldn’t end up being closed, which would lead to failures like https://gitlab.gnome.org/GNOME/glib/-/jobs/1890000 : ``` (/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/converter-stream:56570): GLib-GIO-DEBUG: 12:56:23.280: GSocketClient: Connection successful! Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1042:test_converter_pollable: assertion failed (error == NULL): Resource temporarily unavailable (g-io-error-quark, 27) stderr: ``` This is a bit of a guess (I’m not sure it’ll fix the intermittent test error, as I haven’t been able to reproduce that locally), but it’s worth a try. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
The `vasprintf()` version on those platforms seems to do less rigorous checking of format placeholders. See https://gitlab.gnome.org/GNOME/glib/-/jobs/1890001 and https://gitlab.gnome.org/GNOME/glib/-/jobs/1890000 . Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
tests: Various fixes to gdbus-auth, gdbus-non-socket, gdbus-connection-flush, spawn-multithreaded tests See merge request GNOME/glib!2548
-
Simon McVittie authored
fuzzing: Fix test failure with G_DISABLE_ASSERT See merge request GNOME/glib!2542
-
- Mar 12, 2022
-
-
Baurzhan Muftakhidinov authored
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Otherwise the `start_thread()` threads and the main thread are competing to iterate the global default context, which is probably not what was intended. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Otherwise the test takes forever, for no discernible benefit. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Philip Withnall authored
They make everything a lot harder to reason about, and easily allow for state to leak between tests. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-