You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue happen in VS Code or GitHub Codespaces?
I cannot reproduce this in VS Code.
I cannot reproduce this in GitHub Codespaces.
Are you accessing code-server over HTTPS?
I am using HTTPS.
Notes
I couldn't dig properly, but I think node-rs adopted a new problem, perhaps? @yisibl would love to hear your insight on this!
My notes will be continued in comments later on. My first point is this:
This was supposed to be fixed in #4733, and so it was - I personally tested it via Node 14 on my 32-bit Raspbian install. This is back now, which makes it weird. I am going to need a bit of time on this - sorry, but I have a lot of things up next, like August 15, I have a job to do for that, as well as some other things.
@jsjoeio and @bpmct you are the people I know who have RPis set up. Can you install Node and check it? My install via nvm seems to be screwed up.
@yisibl you suggested @node-rs/argon2, have you noticed anything going haywire in the build logs? Maybe we could start on these things as I also try on my Zorin installation on my computer.
2022-08-09T16_30_58_095Z-debug-0.log
That was my debug log. It seems something other than node-rs/argon2, but this could be potentially NPM package-destructing.
So, my knowledge gain was - AMD64 has another issue.
Please test on your Pis and tell your ideas here. We can't switch node-rs/argon2, it has worked splendidly for the past releases.
First, thank you @im-coder-lg for testing and opening this! Looks semi-related to argon2. I will add this to high-priority list so we can take a look soon.
Let me know if I can help. Looking at the older issues, it seems that the system you guys are using ships an ancient version of glibc. node-argon2 currently builds for ubuntu20.04 which ships glibc 2.31, so anything older than that will fail to link/load.
So, it's mostly a problem in building the entire app, with an older glibc version? And all you have to do is make sure that npm packages are built on Ubuntu LTS with glibc 2.31, that's what you are saying? If this is the fix, I will personally test and code a nice workflow and PR it here.
@im-coder-lg yes, essentially that. In the past, we had this problem with a hosting provider that used Ubuntu 16.04 (after it's EOL, mind you) and there was no way to support that.
argon2 ships prebuilt binaries built against glibc 2.31, so a system shipping glibc in any version >=2.3.1, <3 will be compatible, otherwise crashing occurs. It can't provide a version linked with an older glibc version because GitHub Actions provides Ubuntu 20.04 as the oldest distro.
What you need to do is ensure that the system executing argon2 either ships with a compatible glibc version, or builds from source - this requires gcc, make, node-gyp and other bulld tools.
@jsjoeio indeed CentOS 8.5 ships glibc 2.28 which is already too old.
Closing since we updated to CentOS 8 some time ago, and other changes around this were made, and if it is still a problem I think we need new investigation.
Activity
lg-nineoneninethreenine commentedon Aug 9, 2022
2022-08-09T16_30_58_095Z-debug-0.log
That was my debug log. It seems something other than node-rs/argon2, but this could be potentially NPM package-destructing.
So, my knowledge gain was - AMD64 has another issue.
Please test on your Pis and tell your ideas here. We can't switch
node-rs/argon2, it has worked splendidly for the past releases.jsjoeio commentedon Aug 9, 2022
First, thank you @im-coder-lg for testing and opening this! Looks semi-related to argon2. I will add this to high-priority list so we can take a look soon.
code-asher commentedon Aug 19, 2022
I think we switched to
node-rs/argon2to fix this but then had an issue and had to switch back.Related/possibly a dupe: #4670
I have steps for resolution in there.
ranisalt commentedon Aug 22, 2022
Let me know if I can help. Looking at the older issues, it seems that the system you guys are using ships an ancient version of glibc.
node-argon2currently builds forubuntu20.04which ships glibc 2.31, so anything older than that will fail to link/load.lg-nineoneninethreenine commentedon Aug 23, 2022
So, it's mostly a problem in building the entire app, with an older glibc version? And all you have to do is make sure that npm packages are built on Ubuntu LTS with glibc 2.31, that's what you are saying? If this is the fix, I will personally test and code a nice workflow and PR it here.
jsjoeio commentedon Aug 23, 2022
Will do! Really appreciate that.
@code-asher do you remember why we use an ancient version of glibc? I want to say something-something CentOS but can't recall.
ranisalt commentedon Aug 23, 2022
@im-coder-lg yes, essentially that. In the past, we had this problem with a hosting provider that used Ubuntu 16.04 (after it's EOL, mind you) and there was no way to support that.
argon2ships prebuilt binaries built against glibc 2.31, so a system shipping glibc in any version >=2.3.1, <3 will be compatible, otherwise crashing occurs. It can't provide a version linked with an older glibc version because GitHub Actions provides Ubuntu 20.04 as the oldest distro.What you need to do is ensure that the system executing
argon2either ships with a compatible glibc version, or builds from source - this requires gcc, make, node-gyp and other bulld tools.@jsjoeio indeed CentOS 8.5 ships glibc 2.28 which is already too old.
code-asher commentedon Aug 24, 2022
Yeah we have been reluctant to up the minimum glibc requirement since I think we had people on the product side using code-server on CentOS 7.
code-asher commentedon Aug 24, 2022
IMO building from source sounds like it might be the best move for us at the moment.
ranisalt commentedon Aug 25, 2022
If you can confirm this data, I can try to build with an older distro, so it's compatible. There is no hard requirement to support newer distros :)
jsjoeio commentedon Aug 29, 2022
That is super nice of you! Let me ping some folks internally and find out.
code-asher commentedon Jul 11, 2024
Closing since we updated to CentOS 8 some time ago, and other changes around this were made, and if it is still a problem I think we need new investigation.
lg-nineoneninethreenine commentedon Jul 14, 2024
I thought this was done! Anyway this looks good