| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| Make-enum-GType-registration-thread-safe.patch | Make enum GType registration thread safe Use g_once_init_enter/leave to ensure that enumeration types can be registered across threads. |
Emmanuele Bassi <ebassi@gnome.org> | no | upstream, 2.43.0, commit:7e168dca2438f73cfb8534bb126e799a2185aa5d | 2020-11-18 | |
| tests-Fix-some-memory-leaks.patch | tests: Fix some memory leaks This is enough to make many of the tests pass under gcc's AddressSanitizer. pixbuf-randomly-modified still fails when it cannot allocate more memory, and pixbuf-fail fails with memory allocation errors unless run with ASAN_OPTIONS=allocator_may_return_null=1. |
Simon McVittie <smcv@debian.org> | yes | 2020-12-12 | ||
| Update-Romanian-translation.patch | Update Romanian translation | =?utf-8?q?Florentina_Mu=C8=99at?= <florentina.musat.28@gmail.com> | no | upstream, 2.43.0, commit:89a4cedc0d00fdea6f6c792baafe4cfc8e485fe0 | 2020-12-12 | |
| build-Do-not-install-.test-files-when-test-is-skipped.patch | build: Do not install .test files when test is skipped The skipping prevented the executable from being installed but not the .test file that referenced it. This caused installed tests to fail: Running test: gdk-pixbuf/pixbuf-pixdata.test Caught exception during testing: Failed to execute child process ?/nix/store/kqmj2776mw24qxyswfbqlmybpws4g4yn-gdk-pixbuf-2.42.0-installedTests/libexec/installed-tests/gdk-pixbuf/pixbuf-pixdata? (No such file or directory) |
Jan Tojnar <jtojnar@gmail.com> | yes | 2020-12-08 | ||
| gif-Do-all-of-gif_init-with-a-single-read.patch | gif: Do all of gif_init() with a single read As documented in the introductory comment, the interface of the various functions in the GIF loader is that they read all the bytes they need, or return -1 if not enough are available. Since commit 5212d69f "gif: Replace old buffer management code with GByteArray", the incremental loader strictly depends on that assumption. Unfortunately, gif_init() didn't conform to that interface. If there were enough bytes available for the GIF signature (GIF87a or GIF89a) but not enough bytes for the screen descriptor, it would return -1 having already consumed the first 6 bytes of the stream. A subsequent retry with more data available would start from the beginning of the screen descriptor, and immediately raise an error because the screen descriptor is extremely unlikely to start with another copy of the "GIF8" magic number. The regression test tests/pixbuf-short-gif-write.c would have detected this, but was accidentally disabled by commit 7f0b214a "tests: Conditionally build and run tests". This seems most easily fixed by reading the whole of the 13-byte fixed-length header in one go. Adjust the offsets into the buffer used to parse the screen descriptor accordingly. |
Simon McVittie <smcv@debian.org> | yes | 2020-12-12 | ||
| tests-Don-t-check-whether-bmp-and-gif-loaders-are-enabled.patch | tests: Don't check whether bmp and gif loaders are enabled This is conceptually similar to commit 2fd7d21f "tests: Fix GIF tests being permanently disabled". One way or another, gdk-pixbuf always supports these two formats: on Windows with the native gdiplus loader enabled, it covers these two formats; otherwise, format-specific loaders are used. This means we will run the GIF tests, as intended. |
Simon McVittie <smcv@debian.org> | yes | 2020-12-12 | ||
| Skip-test-for-GNOME-753605.patch | Skip test for GNOME#753605 It relies on a non-free JPEG that happens to exhibit the bug, which is excluded from the Debian source package. |
Simon McVittie <smcv@debian.org> | not-needed | 2018-07-26 | ||
| tests-Mark-pixbuf-randomly-modified-as-flaky.patch | tests: Mark pixbuf-randomly-modified as flaky This is basically a crude fuzzer. It isn't really suitable for build-time acceptance testing, since it frequently produces images for which gdk-pixbuf will try to allocate more memory than is available, but if it does, it isn't straightforward to capture the failing image from an autobuilder that only records build logs. |
Simon McVittie <smcv@debian.org> | yes | debian upstream | 2020-11-16 | |
| gif-Check-for-overflow-when-compositing-or-clearing-.patch | gif: Check for overflow when compositing or clearing frames. Similar to fix in 086e8adf4cc352cd11572f96066b001b545f354e |
Robert Ancell <robert.ancell@canonical.com> | yes | upstream | https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/6976bdc8ee9dd2c2954f91066f7b0f643769a379 | 2021-06-03 |
| Add-an-assertion-that-checks-for-maximum-LZW-code-si.patch | Add an assertion that checks for maximum LZW code size | Robert Ancell <robert.ancell@canonical.com> | no | https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/0cf97225c9c227d11fc4ddf9cba8e8480672ee1b | 2022-02-02 | |
| Fix-the-check-for-maximum-value-of-LZW-initial-code-.patch | Fix the check for maximum value of LZW initial code size. This value is the number of bits for each symbol (i.e. colour index) decoded via LZW. The maximum LZW code is specified as 12 bits, so the value here can only be 11 as two additional code words are required (clear and end of information) that immediately uses an additional bit. This implementation has always been wrong, and the Firefox implementation has the same issue so it seems a common misinterpretation of the spec. This has been changed here to avoid an assertion later in the LZW decoder. Note that there is never any reason for a GIF to be encoded with more than 8 bits of colour information, as the colour tables only support up to 8 bits. |
Robert Ancell <robert.ancell@canonical.com> | yes | debian upstream | https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/19ebba03117aefc9d0312f675f3a210ffdcc4907 | 2022-02-02 |