vcswatch reports that
this package seems to have a new changelog entry (version
2.64.4-2, distribution
UNRELEASED) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit 509653be2e240345f2e986f571717e2fb802fc31
Author: Sebastien Bacher <seb128@ubuntu.com>
Date: Thu Jul 16 12:35:53 2020 +0200
* debian/control.in:
- let libglib2.0-tests Depends on libglib2.0-0 (= ${binary:Version}),
otherwise we can end up with failures due to out of sync versions
commit a30c498a21d6619c3b1edfe372a1e89c9e64d925
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:33:13 2020 +0100
Release to unstable
commit 9c328fdc521f67bf077baccf0c16a66becad9a88
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:32:56 2020 +0100
Update changelog
commit c4e7bc6640a735b9f0072ace3537953eb307473a
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:31:06 2020 +0100
Add post-release bugfixes from upstream
commit b2f7f42c742f48af72c92a7e69b0fe5dc454f807
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:28:28 2020 +0100
Remove stray [PATCH] prefix from a patch
commit 7faeff58e14d7011bc08437ce1b497ef3942174a
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:28:06 2020 +0100
Split a combined patch into its two component upstream commits
commit ffd43e85fef299a5d82366ef7791722087ac4a3a
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:18:54 2020 +0100
New upstream release
commit 415c51da7637f966500c07798b9453bd6fd60dce
Merge: 1dba85b01 d82757c22
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:18:54 2020 +0100
Update upstream source from tag 'upstream/2.64.4'
Update to upstream version '2.64.4'
with Debian dir e736de8f12c43f00830c6ac1aa176a275b919313
commit d82757c229f96d78c00b0011ec989224b8064ec9
Merge: 5f1a848ac 551bd5c1d
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:18:40 2020 +0100
New upstream version 2.64.4
commit 1dba85b01e5e47e911b44cf019bdbe224d621977
Author: Simon McVittie <smcv@debian.org>
Date: Tue Jul 7 13:18:06 2020 +0100
Update changelog
commit b86a7017c0f09f63bf31d73dae83feebd7fb0457
Author: Simon McVittie <smcv@debian.org>
Date: Mon Jul 6 23:37:05 2020 +0100
Re-enable libmount support
libmount no longer depends on libcryptsetup, avoiding the various
crashes that we are working around. Future versions will dlopen it
on-demand, which should also avoid those crashes. Bump the
build-dependency to a suitable version.
This reverts commit 3e07efd165cdbe570fae8b3691c5779283a44cda.
commit 5d5d4e5405b6a5e32c7c0133df2d984bd25a83b2
Author: Simon McVittie <smcv@debian.org>
Date: Mon Jul 6 23:34:44 2020 +0100
d/tests/build: Don't exercise static linking for GIO
libmount will no longer support being linked statically from 2.35.2-8
onwards. For now I'm continuing to test that the other libraries can
still be statically linked, but please consider them to be "at risk".
Closes: #963933
commit 551bd5c1d1db1aa10d71acb9cde6a088a374d8bb
Author: Philip Withnall <withnall@endlessm.com>
Date: Thu Jul 2 13:58:20 2020 +0100
2.64.4
Signed-off-by: Philip Withnall <withnall@endlessm.com>
commit 8e7a483a7360c4ef83f165853a63af462d2db8c4
Author: Baurzhan Muftakhidinov <baurthefirst@gmail.com>
Date: Thu Jun 25 07:40:07 2020 +0000
Update Kazakh translation
commit d0e54ef794a0d74229c10dbcc64d4adadcb53773
Merge: 4abdd10e4 f99f0c2fa
Author: Sebastian Dröge <slomo@coaxion.net>
Date: Wed Jun 24 11:58:49 2020 +0000
Merge branch 'backport-1544-spawn-async-signal-safety-glib-2-64' into 'glib-2-64'
Backport !1544 “Resolve "calling malloc in fork child is undefined-behaviour"” to glib-2-64
See merge request GNOME/glib!1547
commit f99f0c2fabafcf33bc7df6d8f4171c6d6b9220b3
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 14:33:12 2020 +0100
gspawn: Don’t use malloc() when running a binary under /bin/sh
Allocate a working buffer before calling `fork()` to avoid calling
`malloc()` in the async-signal-safe context between `fork()` and
`exec()`, where it’s not safe to use.
In this case, the buffer is used to assemble a wrapper around `argv` so
it can be run under `/bin/sh`.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #2140
commit cc8715c3b740bdac16d71ae110319c2a25a7d1d6
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 14:15:42 2020 +0100
gspawn: Don’t use malloc() when searching for a binary
Allocate a working buffer before calling `fork()` to avoid calling
`malloc()` in the async-signal-safe context between `fork()` and
`exec()`, where it’s not safe to use.
In this case, the buffer is used to assemble elements from `PATH` with
the binary from `argv[0]` to try executing them.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit 3548996c0ee6de35ac630dc7eb4f2e2b47bb2224
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 13:59:48 2020 +0100
gspawn: Don’t use getenv() in async-signal-safe context
Query the environment before calling `fork()` so that it doesn’t have to
be called in the async-signal-safe context between `fork()` and
`exec()`.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit 45b8e60ac4f8cf9f38699cc9d4f81d5cb4afd00e
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 13:40:27 2020 +0100
gspawn: Don’t use getrlimit() or sysconf() in async-signal-safe context
They’re not safe to call in an async-signal-safe context on Linux.
`sysconf()` is safe to call on FreeBSD and OpenBSD (at least), so
continue doing that.
This will reduce performance in the (already low performance) fallback
case where `/proc` is inaccessible to a forked process on Linux, while
spawning a subprocess.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit 923315ef823bafbce2bce98cc599d7c39798efcf
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 13:11:32 2020 +0100
gspawn: Don’t use g_assert() in async-signal-safe context
Use the error handling infrastructure which already exists for other
failures in the async-signal-safe context.
`g_assert()` is unlikely to have caused problems in practice because it
is only async-signal-unsafe when the assertion condition fails.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit d24acc7ea5e6445a84c43b811ff2ebcd160c3264
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 13:10:35 2020 +0100
gspawn: Don’t use g_ascii_isdigit() in async-signal-safe context
While `g_ascii_isdigit()` *is* currently async-signal-safe, it’s going
to be hard to remember to keep it that way if the implementation changes
in future.
It seems more robust to just reimplement it here, given that it’s not
much code.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit 539d51836a279affcce50f3c0b6598ee507a71b7
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 13:09:56 2020 +0100
gspawn: Don’t use g_close() in async-signal-safe context
Use normal `close()` instead, which is guaranteed to be
async-signal-safe.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit 92eac2f4247c3d1a3c5aa57a44f46a346c2bd3aa
Author: Philip Withnall <withnall@endlessm.com>
Date: Mon Jun 22 12:36:32 2020 +0100
gspawn: Audit for async-signal-safety
Functions called between `fork()` and `exec()` have to be
async-signal-safe.
Add a comment to each function which is called in that context, and
`FIXME` comments to the non-async-signal-safe functions which end up
being called as leaves of the call graph.
The following commits will fix those `FIXME`s.
See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #2140
commit aae98ce774e4c22e80474e0a6f1d231792f47849
Author: Philip Withnall <withnall@endlessm.com>
Date: Tue Jun 23 10:49:44 2020 +0100
tree: Fix various ableist language
In almost all cases, rewording the documentation/comments made things
more specific and a little clearer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1544#note_846645
commit 4abdd10e48de286f2000b649465d1d8c96722680
Author: Matej Urbančič <mateju@svn.gnome.org>
Date: Mon Jun 22 21:00:31 2020 +0200
Updated Slovenian translation
commit 175b7e2727b48251fe2dd0e8dd5b0ab8bbba83b1
Merge: 2068a6c48 d8d5664ba
Author: Nirbheek Chauhan <nirbheek.chauhan@gmail.com>
Date: Tue Jun 9 04:00:23 2020 +0000
Merge branch 'backport-1522-meson-printf-checks-glib-2-64' into 'glib-2-64'
Backport !1522 “meson: Fix gnulib printf checks” to glib-2-64
See merge request GNOME/glib!1523
commit d8d5664ba966cdb06de611018a3f8cbc59c68d80
Author: Nirbheek Chauhan <nirbheek@centricular.com>
Date: Mon Jun 8 18:43:04 2020 +0530
meson: Fix gnulib printf checks
Some typos, and accidental usage of the strings `'true'` / `'false'`
instead of the booleans `true` / `false`.
commit 2068a6c484b0378f668637cfc9561f31744893c3
Merge: af1edc1c3 66b56ee9d
Author: Sebastian Dröge <slomo@coaxion.net>
Date: Fri May 22 10:32:16 2020 +0000
Merge branch 'backport-1504-win32-poll-glib-2-64' into 'glib-2-64'
Backport !1504 “win32 gpoll: Fix wait for at least one thread to return” to glib-2-64
See merge request GNOME/glib!1507
commit 66b56ee9d8cb58d70b2e4708487bef1ff7e50faf
Author: majordaw <major.david@balasys.hu>
Date: Wed May 20 15:30:57 2020 +0200
win32 gpoll: Fix wait for at least one thread to return
When timeout grater than 0 in g_poll function, the WaitForMultipleObjects
call will wait for all the threads to return, but when only one thread
got an event the others will sleep until the timeout elapses, and causes
a stall. Triggering the stop event in g_poll in this case is useless as
it is triggered when all the threads where already signaled or timed-out.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/2107
![[bug history graph]](https://qa.debian.org/data/bts/graphs/g/glib2.0.png){kind=link}