Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update the manylinux wheel glibc version to 2.28 #21650

Merged
merged 2 commits into from
Nov 16, 2024

Conversation

cburroughs
Copy link
Contributor

@cburroughs cburroughs commented Nov 15, 2024

While trying to land #21528 to was observed that the wheel building jobs were failing during git checkout with wonderful errors like /__e/node20/bin/node: /lib64/libm.so.6: version GLIBC_2.27' not found (required by /__e/node20/bin/node). This appears to be the same symptoms as https://github.com/actions/checkout/issues/1809 which pointed the the deprecation notice at <https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/>. If this all sounds familiar that is because we *mostly* cleaned this up in #21133, but kept a fewer uses of the older actions for manylinux2014` compatibility. However, from the notice:

"To opt out of this and continue using Node16 while it is still available in the runner, you can choose to set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
as an ‘env’ in their workflow or as an environment variable on your runner machine. This will only work until we upgrade the runner removing Node16 later in the spring. (emphasis added)"

From the wheel job failures during #21528 and my attempts to fiddle with all of ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION, ACTIONS_RUNNER_FORCED_INTERNAL_NODE_VERSION, ACTIONS_RUNNER_FORCE_ACTIONS_NODE_VERSION I think the removal time promised for the Spring has finally come, but I'm not that familiar with GitHub Actions and could be missing something.

As a consequence the version of both actions/upload-artifacts and actions/checkout is bumped to v4. To make this testable now and in the future, wheels are now build on ci config changes.

Why is bumping to manylinux_2_28 (the next oldest manylinux) not a big deal? The "2.28" refers to glibc 2.28 in 2018. That is older than Debian stable and if you need to use software that old you are presumably paying someone for an enterprise distribution.

NOTE: I think we should bump the manylinux version in main regardless, but if my read if the situation is correct we may need to backport this any active release line. Without this or a more complex change we would also be unable to release after December 5th per #21616.

ref #21195 #21616

@cburroughs cburroughs changed the title manylinux wip update the manylinux wheel glibc version to 2.28 Nov 15, 2024
@cburroughs cburroughs marked this pull request as ready for review November 15, 2024 03:12
@cburroughs cburroughs self-assigned this Nov 15, 2024
Copy link

@copart-jafloyd copart-jafloyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me

Copy link
Member

@cognifloyd cognifloyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. I approved in the wrong window with the wrong account 🤦. Trying again...

Copy link
Contributor

@benjyw benjyw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking this on!

@cburroughs
Copy link
Contributor Author

@benjyw Are you the one who can poke at the macos runners?

image

@benjyw
Copy link
Contributor

benjyw commented Nov 16, 2024

I rebooted the machine and the job is picked up now

@cburroughs cburroughs merged commit d55290d into pantsbuild:main Nov 16, 2024
24 checks passed
benjyw pushed a commit to benjyw/pants that referenced this pull request Nov 18, 2024
While trying to land pantsbuild#21528 to was observed that the wheel building jobs
were failing during git checkout with wonderful errors like
`/__e/node20/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found
(required by /__e/node20/bin/node)`. This appears to be the same
symptoms as actions/checkout#1809 which
pointed the the deprecation notice at
<https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/>.
If this all sounds familiar that is because we *mostly* cleaned this up
in pantsbuild#21133, but kept a fewer uses of the older actions for
`manylinux2014` compatibility. However, from the notice:

"To opt out of this and continue using Node16 while it is still
available in the runner, you can choose to set
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
as an ‘env’ in their workflow or as an environment variable on your
runner machine. This will *only work until we upgrade the runner
removing Node16 later in the spring*. (emphasis added)"

From the wheel job failures during pantsbuild#21528 and my attempts to fiddle with
all of `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION`,
`ACTIONS_RUNNER_FORCED_INTERNAL_NODE_VERSION`,
`ACTIONS_RUNNER_FORCE_ACTIONS_NODE_VERSION` I think the removal time
promised for the Spring has finally come, but I'm not that familiar with
GitHub Actions and could be missing something.

As a consequence the version of both `actions/upload-artifacts` and
`actions/checkout` is bumped to `v4`. To make this testable now and in
the future, wheels are now build on ci config changes.

Why is bumping to `manylinux_2_28` (the next oldest manylinux) not a big
deal? The "2.28" refers to glibc
[2.28](https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html)
in 2018. That is older than Debian stable and if you need to use
software that old you are presumably paying someone for an enterprise
distribution.

NOTE: I think we should bump the manylinux version in `main` regardless,
but if my read if the situation is correct we may need to backport this
any active release line. Without this or a more complex change we would
also be unable to release after December 5th per pantsbuild#21616.

ref pantsbuild#21195 pantsbuild#21616
benjyw added a commit that referenced this pull request Nov 19, 2024
While trying to land #21528 to was observed that the wheel building jobs
were failing during git checkout with wonderful errors like
``/__e/node20/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found
(required by /__e/node20/bin/node)``. This appears to be the same
symptoms as actions/checkout#1809 which
pointed the the deprecation notice at

<https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/>.
If this all sounds familiar that is because we *mostly* cleaned this up
in #21133, but kept a fewer uses of the older actions for
`manylinux2014` compatibility. However, from the notice:

"To opt out of this and continue using Node16 while it is still
available in the runner, you can choose to set
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
as an ‘env’ in their workflow or as an environment variable on your
runner machine. This will *only work until we upgrade the runner
removing Node16 later in the spring*. (emphasis added)"

From the wheel job failures during #21528 and my attempts to fiddle with
all of `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION`,
`ACTIONS_RUNNER_FORCED_INTERNAL_NODE_VERSION`,
`ACTIONS_RUNNER_FORCE_ACTIONS_NODE_VERSION` I think the removal time
promised for the Spring has finally come, but I'm not that familiar with
GitHub Actions and could be missing something.

As a consequence the version of both `actions/upload-artifacts` and
`actions/checkout` is bumped to `v4`. To make this testable now and in
the future, wheels are now build on ci config changes.

Why is bumping to `manylinux_2_28` (the next oldest manylinux) not a big
deal? The "2.28" refers to glibc

[2.28](https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html)
in 2018. That is older than Debian stable and if you need to use
software that old you are presumably paying someone for an enterprise
distribution.

NOTE: I think we should bump the manylinux version in `main` regardless,
but if my read if the situation is correct we may need to backport this
any active release line. Without this or a more complex change we would
also be unable to release after December 5th per #21616.

ref #21195 #21616

Co-authored-by: cburroughs <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants