Debian Patches
Status for pygobject/3.50.0-6
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| async-Use-correct-T_BOOL-type-for-_asyncio_future_blockin.patch | async: Use correct T_BOOL type for _asyncio_future_blocking Declaring a PyMemberDef with type T_BOOL requires the corresponding C type to be char, with value 0 or 1: when the member is read, CPython will effectively be dereferencing `* (char *) &pygiasync._asyncio_future_blocking`. On little-endian architectures, in practice this worked, because the low-order bits of an int are in the first byte, which would take value 0 or 1 as desired, with all other bits zero. However, on big-endian architectures, the low-order bits of an int are in the last byte, so reading the _asyncio_future_blocking attribute from Python code would in practice always produce 0, even when the int field had been set to 1 from C code. |
Simon McVittie <smcv@debian.org> | yes | debian upstream | 2024-10-23 | |
| gi-overrides-Gio-Add-platform-specific-symbols.patch | gi/overrides/Gio: Add platform specific symbols In the past Gio provided platform-specific Gio symbols in the generic implementation, this changed as per girepository-2.0 and GLib 2.85.5, but not to break all the applications out there we need to provide a fallback. So, just continue exposing the platform-specific symbols as part of Gio, while notifying the users of the API with a deprecation warning |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | 2025-08-31 | ||
| tests-gio-Check-if-platform-specific-types-are-exposed-in.patch | tests/gio: Check if platform-specific types are exposed in Gio namespace | =?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | 2025-09-01 | ||
| importer-Excempt-GioPlatform-namespaces-from-require_vers.patch | importer: Excempt GioPlatform namespaces from require_version check They are as tied to the GLib/GObject versions as Gio (and even pygobject itself), so exempt them from the need to explicitly calling gi.require_version() on first use. Notably since commit 6a234a92b1b we import the platform namespace ourselves without specifying a version first, so this also fixes a warning when simply importing Gio. |
=?utf-8?q?Florian_M=C3=BCllner?= <fmuellner@gnome.org> | no | 2025-09-08 | ||
| gi-overrides-Gio-Use-Platform-prefix-for-platform-only-sy.patch | gi/overrides/Gio: Use Platform prefix for platform-only symbols In previous versions of GLib, platform-specific symbols such as GUnixMountMonitor were mapped in the Gio namespace as Gio.UnixMountMonitor, while since commit 6a234a92b1b614b7434340c4b15 we create wrappers such as Gio.MountMonitor. This is not correct, and does not serve the initial purpose of providing a backward compatible wrapper. So, use the same logic that we had before: if the GType of a symbol starts with G{Unix,Win32} we use the platform specific name as prefix of the wrapper type, so that it will be Gio.{Unix,Win32}TypeName |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | https://gitlab.gnome.org/GNOME/pygobject/-/merge_requests/451 | 2025-09-10 | |
| Revert-override-connection.register_object-to-prevent-an-.patch | Revert "override connection.register_object to prevent an invocation object from leaking" This reverts commit bf80d0f34af5062fd1201d71fbcd3a34bf1d1a80. It's causing issues with Anaconda (Fedora/RHEL installer). See https://gitlab.gnome.org/GNOME/pygobject/-/issues/658 Leave test case in place, but make it "xfail". |
Arjan Molenaar <gaphor@gmail.com> | no | 2025-02-10 |