Fix incorrect argon2 target in arm builds #6453
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
code-asher
force-pushed
the
arm-again
branch
15 times, most recently
from
979a9f6 to
b327b2d
Compare
code-asher
changed the title
Not building from source causes argon2 to pull the wrong arch, so we have to build from source. But building from source is causing the new Kerberos module to fail on arm64 and keytar to fail on both. The latter has been very difficult to debug because the GitHub image provides a different result to containers based on Ubuntu 20.04. Because of this, use a container instead. Use debian:buster as the container because it is easier to set up the architecture sources (no need to modify the sources) and because it seems to come with glibc 2.28 rather than 2.31. Also use the exact version of Node (18.15.0) for reproducibility.
Otherwise you get IDs that can cause (benign) errors while extracting, which might be confusing. At the very least, I did not see these errors from previous tars (although they seem to use 1001). There is no guarantee what IDs might exist so 0 seems the most reasonable.
code-asher
force-pushed
the
arm-again
branch
from
b327b2d to
3e33eda
Compare
|
Hello @code-asher , |
|
I just published an RC with this commit. If you get a chance to try it please let me know if it fixes the issue! |
|
I updated it via |
|
Awesome thank you for the confirmation! |
yiliang114
pushed a commit
to yiliang114/code-server
that referenced
this pull request
Jan 23, 2025
* Fix building from source on arm Not building from source causes argon2 to pull the wrong arch, so we have to build from source. But building from source is causing the new Kerberos module to fail on arm64 and keytar to fail on both. The latter has been very difficult to debug because the GitHub image provides a different result to containers based on Ubuntu 20.04. Because of this, use a container instead. Use debian:buster as the container because it is easier to set up the architecture sources (no need to modify the sources) and because it seems to come with glibc 2.28 rather than 2.31. Also use the exact version of Node (18.15.0) for reproducibility. * Set owner and group during tar to zero Otherwise you get IDs that can cause (benign) errors while extracting, which might be confusing. At the very least, I did not see these errors from previous tars (although they seem to use 1001). There is no guarantee what IDs might exist so 0 seems the most reasonable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I removed building from source because the comment said it was due to CentOS 7, which we no longer use.
However, it seems that the real issue is that argon2 is pulling the wrong binary for cross-builds? So we need to force building from source instead. This should fix #6446 and fix #6448.
Unfortunately building from source is causing the new Kerberos module to fail on arm64. To fix that we will need to install the arm64 version of the library.
Additionally, building from source is causing keytar to fail (a longstanding issue that previously was accidentally ignored when it failed in CI). It seems unique to GitHub's VM; I cannot reproduce it in a Docker container. So, switch to a Docker container.