glib2.0 (2.64.4-1) [PTS] [DDPO]

NEW: VCS has unreleased changes: 2.64.4-2 > 2.64.4-1

Git: https://salsa.debian.org/gnome-team/glib.git
Enter a full Vcs-* header, supported schemes are: Vcs-Bzr, Vcs-Cvs, Vcs-Darcs, Vcs-Git, Vcs-Hg, Vcs-Mtn, Vcs-Svn.
For Vcs-Git append -b branch to select the branch name; append [subdir] if the debian/ directory is not in the repository root.
The next upload will reset the information from the source package headers.
Branch: debian/master
Path: debian/changelog
Browser: https://salsa.debian.org/gnome-team/glib
Last scan: 2020-07-30 15:50:10+00
Next scan: 2020-08-05 11:06:00+00
Merge requests: 1
CI pipeline status: success

Debian changelog in Git:

glib2.0 (2.64.4-2) UNRELEASED; urgency=medium

  * 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

 -- Sebastien Bacher <seb128@ubuntu.com>  Thu, 16 Jul 2020 12:34:32 +0200

This branch is 29 commits ahead of tag debian/2.64.3-2

Git log:

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