- 15 Jan, 2021 1 commit
-
-
Марко М. Костић (Marko M. Kostić) authored
-
- 13 Jan, 2021 1 commit
-
-
Matthias Clasen authored
ci: Use `only` clauses everywhere See merge request !100
-
- 12 Jan, 2021 1 commit
-
-
Emmanuele Bassi authored
Otherwise GitLab will detach jobs from the pipeline. To limit the amount of work done by the macOS job, we run the build only on branches on the project repository.
-
- 10 Jan, 2021 1 commit
-
-
Asier Sarasua Garmendia authored
-
- 09 Jan, 2021 1 commit
-
-
Hugo Carvalho authored
-
- 06 Jan, 2021 1 commit
-
-
Jordi Mas authored
-
- 05 Jan, 2021 1 commit
-
-
Emmanuele Bassi authored
gif: Honor "revert to previous" behaviour on the first frame. Closes #166 See merge request !99
-
- 04 Jan, 2021 8 commits
-
-
Fran Dieguez authored
-
Robert Ancell authored
The code originally failed to load GIFs that had this set (4607c8e9) and then changed to silently ignoring it (af71489c). Reverting to the background on the first frame seems completely reasonable and is the behaviour of Firefox/Chrome. The [current GIF spec](https://www.w3.org/Graphics/GIF/spec-gif89a.txt) doesn't indicate any issue doing this and it matches what Firefox/Chrome does. Fixes #166
-
Aurimas Černius authored
-
Emmanuele Bassi authored
Macos ci See merge request !98
-
Emmanuele Bassi authored
Only build on macOS for merge requests and the main development branch.
-
Emmanuele Bassi authored
Use `depth=1` to reduce the size of the clone when using subprojects.
-
Emmanuele Bassi authored
Since the gen-resources.py needs to call glib-compile-resources, we need to figure out where the binary is, and tell gen-resources.py to use that, instead of relying on it being in the PATH.
-
Emmanuele Bassi authored
The gen-resources.py script must be aware of the location of glib-compile-resources, in case it's not in the PATH.
-
- 03 Jan, 2021 4 commits
-
-
Matthias Clasen authored
It doesn't work.
-
Matthias Clasen authored
-
Matthias Clasen authored
-
Matthias Clasen authored
-
- 02 Jan, 2021 3 commits
-
-
Emmanuele Bassi authored
Include pixbuf loader API in the gir file Closes #167 See merge request !97
-
Paolo Borelli authored
-
Paolo Borelli authored
-
- 27 Dec, 2020 1 commit
-
-
Philipp Kiemle authored
-
- 22 Dec, 2020 1 commit
-
-
Jordi Mas authored
-
- 18 Dec, 2020 1 commit
-
-
Fabio Tomat authored
-
- 14 Dec, 2020 1 commit
-
-
Simon McVittie authored
Run GIF tests again, and fix regression for short reads See merge request !95
-
- 12 Dec, 2020 5 commits
-
-
Florentina Mușat authored
-
Emmanuele Bassi authored
tests: Fix some memory leaks See merge request !96
-
Simon McVittie authored
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. Signed-off-by:
Simon McVittie <smcv@debian.org>
-
Simon McVittie authored
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. Fixes: 7f0b214a "tests: Conditionally build and run tests" Signed-off-by:
Simon McVittie <smcv@debian.org>
-
Simon McVittie authored
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. Signed-off-by:
Simon McVittie <smcv@debian.org>
-
- 08 Dec, 2020 1 commit
-
-
Jan Tojnar authored
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)
-
- 07 Dec, 2020 6 commits
-
-
Emmanuele Bassi authored
Make enum GType registration thread safe See merge request !93
-
Emmanuele Bassi authored
-
Emmanuele Bassi authored
-
Emmanuele Bassi authored
Use g_once_init_enter/leave to ensure that enumeration types can be registered across threads.
-
Emmanuele Bassi authored
gif: Fix LZW decoder accepting invalid LZW code. Closes #164 See merge request !92
-
Robert Ancell authored
The code value after a reset wasn't being validated, which means we would accept invalid codes. This could cause an infinite loop in the decoder. Fixes CVE-2020-29385 Fixes #164
-
- 03 Dec, 2020 1 commit
-
-
Kjartan Maraas authored
(cherry picked from commit 9091fb98)
-
- 02 Dec, 2020 1 commit
-
-
Daniel Mustieles García authored
-