I've just noticed accidentally that the size of the setuptools wheel differs on ppc64le. To reproduce, you can scratch build python-setuptools like this: $ fedpkg build --nowait --fail-fast --scratch --arch ppc64le ... ++ du /builddir/build/BUILD/setuptools-65.5.1/pyproject-wheeldir/setuptools-65.5.1-py3-none-any.whl ++ cut -f1 + test 896 -lt 900 $ fedpkg build --nowait --fail-fast --scratch --arch x86_64 ... ++ du /builddir/build/BUILD/setuptools-65.5.1/pyproject-wheeldir/setuptools-65.5.1-py3-none-any.whl + test 860 -lt 900 This goes back at least to Fedora 36 where the (even stricter) `du` check actually fails the build on ppc64le. Since the wheel is required by Python (and hence dnf etc.), it's installed in containers and we want it to be as small as possible. We should really see if this is just different zip compression or something more serious. Running the build on other arches to see the difference is also a good next step.
Funnily enough, when I download the RPMs, the whl size is 860 and they appear identical. I'll verify this next week and reassign this to coreutils if I can verify du reports wrong size on ppc64le, but I cannot connect to ppc64le-test.fedorainfracloud.org now.
The `du` tool estimates disk usage, so I'd expect it to filesystem settings (block size, compression, holes, etc.) take into account. (And I wouldn't be surprised if the estimates change in different du versions even if the data is the same, as the tool tries to catch up to what filesystems do.) It would be better to look at file size rather than disk usage, e.g.: stat --format %s /builddir/build/BUILD/setuptools-65.5.1/pyproject-wheeldir/setuptools-65.5.1-py3-none-any.whl
stat --format %s is indeed arch-independent. I'll make the change, thanks.
https://src.fedoraproject.org/rpms/python-setuptools/pull-request/87
Fixed in dist-git. https://src.fedoraproject.org/rpms/python-setuptools/c/8d079510db88cca1891df9ccba23d0d916c63077?branch=rawhide