[request] Backport manylinux_2_27/2_28 wheels for v0.1.4 (post1 release)

[sunway513]

Summary

Could the FlyDSL team please publish a v0.1.4.post1 (or similar post-release) wheel matrix with manylinux_2_27 / manylinux_2_28 platform tags, matching what v0.1.5+ already ships? The upstream PR #386 ("support glibc2.28") that landed for v0.1.5+ would just need to be backported as a maintenance patch onto the v0.1.4 line.

Why

amd-aiter v0.1.13.post1 ships with Requires-Dist: flydsl ==0.1.4 (build pin chosen at the time v0.1.13 was cut). Downstream consumers (vLLM, ATOM, SGLang) building or installing on systems with glibc < 2.35 cannot resolve flydsl==0.1.4 because the only PyPI artifact is manylinux_2_35:

$ pip install flydsl==0.1.4
ERROR: Could not find a version that satisfies the requirement flydsl==0.1.4
       (from versions: 0.1.6.dev529, 0.1.6, 0.1.7.dev551, 0.1.7)
ERROR: No matching distribution found for flydsl==0.1.4

The same error is what motivated #396 ("centos install failed"), which is still OPEN even though the fix (PR #386) has been merged for newer versions only.

This is currently blocking us in two places:

1. AITER's manylinux_2_28 build container (glibc 2.28) — pip install -r requirements.txt fails because flydsl==0.1.4 is not installable. We have to bump our pin to 0.1.6 to make builds pass, which then propagates as the Requires-Dist of every wheel we ship.

2. Partner deployments on RHEL 8 / Ubuntu 20.04 (glibc 2.31 / 2.27) — same install failure on the consumer side.

Specific ask

Either:

• Option A (preferred): Tag a v0.1.4.post1 from v0.1.4 plus the cherry-pick of support glibc2.28 #386 (and any minimal companion fixes), build the manylinux_2_27/2_28 wheel matrix with the same CI as v0.1.6 uses, publish to PyPI.

• Option B: Host the manylinux_2_27/2_28 v0.1.4.post1 wheels on a non-PyPI location (GitHub Release artifacts, internal Artifactory, S3) — we can wire --index-url / --find-links into our build and partner install instructions.

Option A is preferred because it keeps pip install flydsl==0.1.4 working out of the box for any downstream that has the version pinned.

Reference

• PR support glibc2.28 #386 (already merged for v0.1.5+) — support glibc2.28 #386
• Issue [Issue]: centos install failed #396 (still open, same root cause) — [Issue]: centos install failed #396
• amd-aiter v0.1.13 line uses flydsl==0.1.4 pin (https://github.com/ROCm/aiter/blob/v0.1.13/setup.py#L16)

Workaround we are taking now

Bumping our local amd-aiter pin to flydsl==0.1.6 so we can build wheels in our manylinux_2_28 container, but this changes what every consumer of amd-aiter v0.1.13.post1 sees. Reverting to the v0.1.4 line as soon as a manylinux_2_27/2_28 wheel is available.

cc @gbyu-amd @valarLip @sunway513