GitLab

ci: Use `only` clauses everywhere

See merge request !100

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.

gif: Honor "revert to previous" behaviour on the first frame.

Closes #166

See merge request !99

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

Macos ci

See merge request !98

Only build on macOS for merge requests and the main development branch.

Use `depth=1` to reduce the size of the clone when using subprojects.

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.

The gen-resources.py script must be aware of the location of
glib-compile-resources, in case it's not in the PATH.

It doesn't work.

Include pixbuf loader API in the gir file

Closes #167

See merge request !97

Run GIF tests again, and fix regression for short reads

See merge request !95

tests: Fix some memory leaks

See merge request !96

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>

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>

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>

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)

Make enum GType registration thread safe

See merge request !93

Use g_once_init_enter/leave to ensure that enumeration types can be
registered across threads.

gif: Fix LZW decoder accepting invalid LZW code.

Closes #164

See merge request !92

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

(cherry picked from commit 9091fb98)