Compared to the file in the Translation Project, I still had to apply
a few fixes that were needed with the previous (5.7.1-dev1) version too:
- Remove two extra '<' characters that break the build with po4a.
- Don't translate XZ_DEFAULTS and XZ_OPT environment variable names.
It was (probably) intentionally without the null terminator, but the test
works with null terminator too (the test still fails with xz <= 5.0.3),
so simply omit one character to silence the warning.
tests/test_bcj_exact_size.c:30:32: error: initializer-string for array of ‘unsigned char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (17 chars into 16 available) [-Werror=unterminated-string-initialization]
30 | const uint8_t in[16] = "0123456789ABCDEF";
| ^~~~~~~~~~~~~~~~~~
Fixes: d8db706acb83 ("liblzma: Fix possibility of incorrect LZMA_BUF_ERROR.")
Fixes: https://github.com/tukaani-project/xz/issues/176
cap_rights_clear() with no additional arguments acts as a no-op, so
instead of removing all capability rights from STDIN_FILENO, the same
rights were allowed for STDIN_FILENO as were allowed for src_fd.
Fixes: a0eecc235d3b ("xz: Make Capsicum sandbox more strict with stdin and stdout.")
(The commit message says "stdout". It should have said "stderr".)
Use --trace-children-skip instead of --trace-children-skip-by-arg
so that the skipping is only done based on the executable names.
(--trace-children-skip-by-arg can match other args than argv[0].)
Update the list of executables to skip to match what the scripts run.
Do not skip bash or sh. If Valgrind didn't trace the shell, then the
xz and xzdec programs run by the shell wouldn't be analyzed either.
Fixes: 7e99856f66c0 ("CI: Speed up Valgrind job by using --trace-children-skip-by-arg=...")
If shared liblzma is built, tests/test_* and src/xz/xz are wrapper
scripts created by Libtool. The wrappers set library search path
so that the freshly-built shared library is found.
With a static liblzma, no wrapper scripts are needed, and Libtool
places the real executables to the aforementioned locations. This
speeds up the tests under Valgrind dramatically.
Fixes: 6c095a98fbec ("ci: test Valgrind")
Debian and Ubuntu have a patch that changes the upstream default to
HAVE_DOT = YES. Undo it to have more consistent results across distros.
This was noticed in Ubuntu CI runner where "doxygen" tried to run "dot"
but that failed due to "dot" not being installed. "doxygen" still
finished with exit status 0 until the commit that turned warnings to
errors with WARN_AS_ERROR = FAIL_ON_WARNINGS.
Re-enable CLANG64 environment. Add CLANGARM64. Don't add MINGW64
to slightly reduce the number of runner VMs needed.
Install the required packages using the setup-msys2 action instead
of running the commands separately.
Test Autotools and CMake in the same job to reduce the number of VMs.
This doesn't slow it down too much because the msys2-setup step is
needed by both. However, do only the full builds on ARM64 because
those runners seem to be slower.
Test fewer build configurations. The point of testing on MSYS2 is to
catch Windows-related issues. It should be enough that the more unusual
build configurations are tested in ci.yml.
Run the build commands directly instead of using ci_build.bash. This
makes it easier to see what commands are run even if it is a little
more verbose now.
Run the workflow automatically when commit are pushed to master.
With the fewer build variants it's not too slow.
Don't say that the .lz format allows trailing data. According to the
lzip 1.25 manual, trailing data isn't part of the file format at all.
However, tools are still expected to behave as usefully as possible
when there is trailing data.
Fix the description of lzip >= 1.20 behavior when some of the first
bytes of trailing data match the magic bytes. While the lzip 1.25 manual
recommends that none of the first four bytes in trailing data should
match the magic bytes, the default behavior of lzip 1.25 treats
trailing data as a corrupt member header only if two or three bytes
match the magic bytes; one matching byte isn't enough.
Reported-by: Antonio Diaz Diaz
Link: https://www.mail-archive.com/xz-devel@tukaani.org/msg00702.html
If <getopt.h> had optreset but not getopt_long, xz used optreset while
the replacement getopt_long doesn't support optreset. I'm not aware of
any relevant system where bug is possible. Autotools build didn't have
this bug.
Fixes: af66cd585902 ("CMake: Add support for replacement getopt_long (lib/getopt*).")
Using eight runners seems wasteful. Using only two runners isn't
much slower due to the runner startup overhead.
Also add a comment about the test that fails without b5a5d9e3f702.
On GitHub runners, VS 2019 16.11 (MSVC 19.29.30158) results in
test failures. VS 2022 17.13 (MSVC 19.43.34808) works.
In xz 5.6.x there was a #pragma-based workaround for MSVC builds for
32-bit x86. Another method was thought to work with the new rewritten
CLMUL CRC. Apparently it doesn't. Keep it simple and disable CLMUL CRC
with any non-recent MSVC when building for 32-bit x86.
Fixes: 54eaea5ea49b ("liblzma: x86 CLMUL CRC: Rewrite")
Fixes: https://github.com/tukaani-project/xz/issues/171
Reported-by: Andrew Murray
