missing at least 3.12+ arm wheels

[altendky]

looking at pypi https://pypi.org/project/zstd/1.5.7.2/#files it appears that at least for linux arm there are only wheels up to 3.11. i figured i'd take a look at the workflows to see why those weren't covered in the matrix but instead found per-case it seems workflows. can this not be handled by a matrix? a matrix does end up with various exceptions due to ragged edges of the matrix, but can drastically reduce repetition (and missing wheel builds).

tl;dr

1. it would be helpful to have wheels for all versions built and published
2. i would be happy to help with that depending on an explanation for the present ci setup.

thanks!

[emlowe]

Is there anything we can do to help this along? Kyle is available to assist with cleaning up the Github workflows. Preferably, CNI can help with upstream fixes rather than managing a fork to obtain the required binary wheels.

[sergey-dryabzhinsky]

@emlowe test some arm/64 actions that builds any wheels

[altendky]

i see both build-wheels.yml with a matrix and also lots of other repeated workflows for specific combinations. which are used for what?

[altendky]

@emlowe test some arm/64 actions that builds any wheels

are you referring to this failure?

https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16992438286/job/48174913562?pr=260#step:7:77

ValueError: 'armhf' is not a valid Architecture

[altendky]

or maybe this one.

https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16993620003/job/48178860631#step:7:378

Error:   '/opt/python/cp312-cp312/bin/python' executable doesn't exist in image 'quay.io/pypa/manylinux_2_24_x86_64:2022-12-26-0d38463' to build 'cp312-manylinux_x86_64'.

[altendky]

i would suggest we start by reverting the addition of armhf. that will allow more green ci and also avoid hiding any issues in other PRs i make.

• Revert "Merge pull request #258 from sergey-dryabzhinsky/sergey-dryabzhinsky-patch-1" #263 armhf is not a valid arch here. https://cibuildwheel.pypa.io/en/stable/options/#archs aarch64 is the 'common' meaning of arm here with linux, as i understand it.

[altendky]

@sergey-dryabzhinsky, would you be willing to cancel and rerun the failures on this job? https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16995481612/job/48185051662 for me it shows a lot of the linux stuff as not having run and it would be helpful to have a reference on the latest master to compare my pr runs against.

[sergey-dryabzhinsky]

@altendky done

[altendky]

do we need to be running the linux builds on both 24.04 and 20.04? it looks like 22.04 is the oldest listed ubuntu https://github.com/actions/runner-images. the builds occur inside docker via cibuildwheel. if we want testing of the wheels across various platforms then we could have a followup job that uses the already built wheels. if we want 20.04 we could work in a docker image instead of trying to get that from a github actions host.

i bring this up because it looks like all the not-running jobs are 20.04.

i would tend towards just dropping the 'older ubuntu' jobs but we could also update that to 22.04. let me know if you are comfortable having this changed and i'll make a pr.

[altendky]

meh, i try not to be pushy, but it's probably easier to just have a pr ready in case you agree. #265

[sergey-dryabzhinsky]

@altendky 20.04 was having lowest libc at a time . If it deprecated now then it unneeded now.

[altendky]

that was specifically the runner. we control the libc used to build by using the manylinux docker image via cibuildwheel. so for building, the runner host doesn't matter a whole lot.

[altendky]

it looks like #262 fixed the 3.12/3.13 linux jobs without introducing new failures. after that i'll keep looking at other failures.

[altendky]

i've been fixing the build wheels workflow with the matrix. are the other workflows still used? just making wheels with 'specialized' compilation settings?

[sergey-dryabzhinsky]

Yes, they are used. Yes they are