You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But those examples are not installed and then not shipped in the .deb file.
It's not needed to ship them to begin with, so it's not needed to build them.
Actually one of them is a CRN-to-DDS (or the reverse, I don't remember) transformer that doesn't convert (same data in different container), and that can be useful. But if needed we better do this in Crunch.
The Debian package seems to depend on Python as a dependency:
adep: debhelper-compat (= 13)
Package not available
adep: [cmake](https://packages.debian.org/forky/cmake)
cross-platform, open-source make system
adep: [python3](https://packages.debian.org/forky/python3)
interactive high-level object-oriented language (default python3 version)
Python is only used to run the test/test.py script to validate the build (used in CI). The Debian rules file currently doesn't run it, so it better be removed.
If Debian wants to run it as part of the package validation, then Python should be kept as a dependency, but it's either everything or nothing. I'm actually curious to see if some architectures Debian support produces different files.
Python is only used to run the test/test.py script to validate the build (used in CI). The Debian rules file currently doesn't run it, so it better be removed.
I added this because I didn't want the failing tests to prevent the package to build, and I wanted the logs.
@twolife do you have some logs where the test fails?
Logs are available at https://buildd.debian.org/status/package.php?p=crunch-dxtc (just click on the "Installed" link in the green boxes)
Tests fails for s390x, powerpc, ppc64, hppa (all big endian archs) and surprisingly also on i386
We know about it. In fact I already wrote the documentation for it but it looks like I forgot to merge it the last time I updated the readme. Here is the missing part of the readme (that will be pushed one day):
It is recommended for those looking for generating reproducible CRN files to keep disabled the use of fast math. It is also recommended to disable x87 floats on i686 and to rely on SSE instead with the -mfpmath=sse -msse compiler flags.
The thing is that x87 has more precision than the standard, so there are minor floating point variations. SSE follows the standard, so SSE should be preferred over x87. 🙂️
@twolife now I see why the rules file builds the examples… because the tests run them! 😁️
The examples may rely on code paths not used by the crunch tool, and then it can be useful to test them. But if only the crunch tool is shipped, testing them adds nothing more. When a .so or a .a or some headers are distributed, then it becomes useful. maybe we can make these examples optional in test.
@twolife While the i386 build failed the test because of precision difference of x87, the produced files are supposed to work, they should be properly produced, just with different checksums.
But with big endian architectures, it's probably just not working at all. I just tested in a s390x chroot, and DDS and KTX files are unreadable (malformed), and CRN files have broken colors:
Activity
illwieckz commentedon Aug 8, 2026
The current Debian rules files enables the build of examples:
as seen on:
But those examples are not installed and then not shipped in the
.debfile.It's not needed to ship them to begin with, so it's not needed to build them.
Actually one of them is a CRN-to-DDS (or the reverse, I don't remember) transformer that doesn't convert (same data in different container), and that can be useful. But if needed we better do this in Crunch.
So those examples better be left disabled.
illwieckz commentedon Aug 8, 2026
The Debian package seems to depend on Python as a dependency:
as seen on:
Python is only used to run the
test/test.pyscript to validate the build (used in CI). The Debian rules file currently doesn't run it, so it better be removed.If Debian wants to run it as part of the package validation, then Python should be kept as a dependency, but it's either everything or nothing. I'm actually curious to see if some architectures Debian support produces different files.
illwieckz commentedon Aug 8, 2026
Debian applies two patches:
I rewrote or improved both of them here, so the upstream could be built by Debian without having to apply patches:
illwieckz commentedon Aug 8, 2026
I was wrong it runs it:
Though the
|| truemakes it useless.@twolife do you have some logs where the test fails?
twolife commentedon Aug 8, 2026
I added this because I didn't want the failing tests to prevent the package to build, and I wanted the logs.
Logs are available at https://buildd.debian.org/status/package.php?p=crunch-dxtc (just click on the "Installed" link in the green boxes)
Tests fails for s390x, powerpc, ppc64, hppa (all big endian archs) and surprisingly also on i386
illwieckz commentedon Aug 8, 2026
Ah I see.
OK, good to know!
Not surprising at all. 😉️
We know about it. In fact I already wrote the documentation for it but it looks like I forgot to merge it the last time I updated the readme. Here is the missing part of the readme (that will be pushed one day):
The thing is that x87 has more precision than the standard, so there are minor floating point variations. SSE follows the standard, so SSE should be preferred over x87. 🙂️
illwieckz commentedon Aug 8, 2026
@twolife now I see why the rules file builds the examples… because the tests run them! 😁️
The examples may rely on code paths not used by the
crunchtool, and then it can be useful to test them. But if only thecrunchtool is shipped, testing them adds nothing more. When a.soor a.aor some headers are distributed, then it becomes useful. maybe we can make these examples optional in test.illwieckz commentedon Aug 8, 2026
@twolife While the i386 build failed the test because of precision difference of x87, the produced files are supposed to work, they should be properly produced, just with different checksums.
But with big endian architectures, it's probably just not working at all. I just tested in a s390x chroot, and DDS and KTX files are unreadable (malformed), and CRN files have broken colors:
illwieckz commentedon Aug 9, 2026
This fixes endianness issues: