Matthieu Darbois

@julienmalik, If I understand correctly, there's no more build using cmake 2.8.x. `find . -name 'CMakeLists.txt' -exec grep 'cmake_minimum_required' {} +` outputs the following: ``` ./CMakeLists.txt:cmake_minimum_required(VERSION 2.8.2) ./tests/nonregression/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.7) ./thirdparty/libtiff/CMakeLists.txt:cmake_minimum_required(VERSION...

@slugan In order to keep a backward compatible behavior, could you add the inverse option instead. Something like `--no-rgb-conversion`

@slugan sorry I missed that the fix was only for those colorspaces. Anyway, @detonin shall say if consistent behavior shall be kept for those colorspaces (i.e. convert to RGB as...

It seems the difference is that the custom images are using a manifest list but manylinux images are not. The architecture is indeed present in manylinux images. You need the...

As @joerick said, it's likely just a waste of resources to change the default conditionally on the python version and, users can already do that if they want(/need) to using...

> I think we can already safely go to 2.26 as the new default. There are no images for 2.26. The next supported image is 2.28 hence the proposition in...

I just created pypa/manylinux#1671 to drop python 3.6 & 3.7 from the manylinux images (mostly in order to add 3.14 without image size growing or build times getting much longer)....

You're using a custom script (based on a pybind sample) which calls cmake with default option ending with an x86_64 build only. you'd probably be better off using [scikit-build-core](https://scikit-build-core.readthedocs.io/en/latest/index.html) maybe...

Another option would be for the `ninja` executable to be directly deployed as a distribution script. This should work as long as the ninja executable doesn't require to graft dependencies...

If we can rely on importlib.metadata (or importlib_metadata), the module can locate the script (that would mean no more support for python