Debian collaboration thread

[illwieckz]

This is a thread to discuss things to improve in the Debian package. To make it easy to collaborate with @twolife.

[illwieckz]

The current Debian rules files enables the build of examples:

override_dh_auto_configure:
	dh_auto_configure -- -DBUILD_EXAMPLES=ON

as seen on:

• https://tracker.debian.org/media/packages/c/crunch-dxtc/rules-0.56.2-1

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.

So those examples better be left disabled.

[illwieckz]

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)

as seen on:

• https://packages.debian.org/source/testing/crunch-dxtc

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.

[illwieckz]

Debian applies two patches:

• https://udd.debian.org/patches.cgi?src=crunch-dxtc&version=0.56.2-1

I rewrote or improved both of them here, so the upstream could be built by Debian without having to apply patches:

• Some patches to please Debian 💯️ #100 💯️

[illwieckz]

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 was wrong it runs it:

override_dh_auto_test:
	CRUNCH_BUILD_DIR=./$(wildcard obj-*) ./test/test.py || true

Though the || true makes it useless.

@twolife do you have some logs where the test fails?

[twolife]

Though the || true makes it useless.

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

[illwieckz]

I added this because I didn't want the failing tests to prevent the package to build, and I wanted the logs.

Ah I see.

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)

OK, good to know!

and surprisingly also on i386

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):

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. 🙂️

[illwieckz]

The current Debian rules files enables the build of examples:

override_dh_auto_configure:
	dh_auto_configure -- -DBUILD_EXAMPLES=ON

@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.

[illwieckz]

@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: