New versions not available on OpenVSX (platform-specific VSIXes)

[romainreignier]

EDIT: see #11080 (comment)

---

rust-analyzer version: "Rust Analyzer: Show RA Version" command does nor exist, extension install dir: matklad.rust-analyzer-0.2.867

rustc version: rustc 1.56.0 (09c42c458 2021-10-18)

OS Version: Ubuntu 18.04.6

VS Code version: I use VSCodium 1.63.2

Today, rust-analyzer updated itself and stop working with the error:

INFO [12/21/2021, 11:18:12 AM]: Using server binary at /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer
ERROR [12/21/2021, 11:18:12 AM]: Bootstrap error [Error: Failed to execute /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer --version
	at j0 (/home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/out/main.js:109:4032)
	at processTicksAndRejections (internal/process/task_queues.js:93:5)
	at async N0 (/home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/out/main.js:109:1881)
	at async I0 (/home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/out/main.js:108:3977)
	at async lC (/home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/out/main.js:108:3808)
	at async Promise.all (index 0)
	at async v.$activate (/usr/share/codium/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:100:20806)]

The file /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer but cannot be executed, even manually:

$ /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer --version
bash: /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer: No such file or directory

While the file exists.

But ldd on it shows the missing musl lib:

ldd /home/user/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer
        linux-vdso.so.1 (0x00007ffce3bfa000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5dc6a52000)
        libc.musl-x86_64.so.1 => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5dc6661000)
        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f5dc8490000)

I had a VSCodium update yesterday so it might be related.

I have tried to uninstall the extension but it installs the same version.

[samueltardieu]

A similar problem exists on ArchLinux.

[romainreignier]

Reverting to 0.2.853 works. So this seems specific to latest 0.2.867 version.

[lnicola]

@romainreignier what if you download https://github.com/rust-analyzer/rust-analyzer/releases/download/2021-12-20/rust-analyzer-linux-x64.vsix and install it using the Install from VSIX command?

[romainreignier]

@lnicola It works!

[samueltardieu]

Works for me too using the package provided by @lnicola which links musl statically the glibc.

[lnicola]

@samueltardieu are you sure it links to musl and not glibc?

[romainreignier]

I think it links to glibc:

 ldd ~/.vscode-oss/extensions/matklad.rust-analyzer-0.2.867/server/rust-analyzer
        linux-vdso.so.1 (0x00007ffd81e25000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec466cf000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec464b7000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec46298000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec45efa000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec45b09000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fec480ce000)

[samueltardieu]

Yes, indeed, it links to glibc.

[lnicola]

I think what happens is that:

• VS Code 1.61 added support for platform-specific dependencies
• downloading the server binaries from GitHub is a bit of a pain for us (sometimes the releases don't get published and updates fail, some users with proxies have problems, coordinating between the nightly and stable builds is a bit of a pain, it's a large surface for supply chain attacks and so on)
• we implemented VS Code: Platform-specific Extensions #10483 in feat: Publish platform-specific Code VSIXes #11053
• VSCodium uses Open VSX
• rust-analyzer gets published to Open VSX somehow (there's an open issue, but we don't have an account there and I don't know how it gets there)
• either Open VSX or the publishing process there doesn't support platform-specific extensions
• VSCodium users get a random version

I don't think we want to give up on this change, but I don't know any easy fix either.

[samueltardieu]

vscode on ArchLinux is also using open-vsx:

$ jq .extensionsGallery < product.json
{
  "serviceUrl": "https://open-vsx.org/vscode/gallery",
  "itemUrl": "https://open-vsx.org/vscode/item"
}

[bjorn3]

The vscode package registry is only allowed to be used by the vscode builds microsoft creates. These also contain a drm to make certain microsoft extensions work like the remote ssh, remote wsl and liveshare extensions. Any build from the source code in https://github.com/microsoft/vscode has to use an alternative package registry and isn't allowed to use these extensions.

[lnicola]

I think we need to finally make an account on OVSX, and find someone to ping about the ovsx tool and backend.

[lnicola]

eclipse/openvsx#336

[lnicola]

As a work-around, you can do one of these:

• disable updates and update manually from a GitHub release every once in a while
• use the non-free version of Code (on Arch, there's an AUR package for it, Ubuntu must have a snap)
• install the language server separately (on Arch there's a community package) and set rust-analyzer.server.path

I wouldn't recommend using the third solution, because the old Code extension might not work very well with a newer server binary.

[najtin]

thanks for these helpful comments! just wanted to add that v0.2.880 is also broken

[lnicola]

@najtin besides reverting #10483, there's not much we can do here. We could make a version with binaries for every platform, but currently we have no control over how things get published there.

I think this should be fixed on the Open VSX side. The maintainers there are aware of it.

[mrchip2k]

Quickest way to "fix" it for me was installing an older version from within VSCodium (also, disable auto updates)
(rightclick extension > Install Another Version... > 0.2.853 worked for me)

[lukasjuhrich]

(deleted, this information was completely redundant as I got confused and forgot the last half of the initial issue description)

[filiptronicek]

For a quick status update: over at OpenVSX we are trying to remove the non-working versions to make the extension work at least, but are running into some issues on our end (see EclipseFdn/open-vsx.org#814 & EclipseFdn/open-vsx.org#816). I removed this extension from auto-publishing to OpenVSX (because of EclipseFdn/publish-extensions#527) and hope to get the extension directly to OpenVSX back soon 🤞.

[lnicola]

Update: OpenVSX has now removed the newer versions. Now if you install it from there you will get an older, working version. I'll update the issue title accordingly.

[purkhusid]

Has there been any progress on this?

[bjorn3]

You might want to follow https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1483.

[lnicola]

I'm not convinced that https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1483 helps, since that change was online for a couple of days, but our nightly publish action still failed.

So this is more or less implemented on our side, but I don't know what's up with OpenVSX.

[filiptronicek]

Hey all! Good news, https://open-vsx.org/ has deployed the change with pre-releases and platform-specific releases, so this should be good to go 🎉

cc @lnicola

[coffeeispower]

YEEEEEESS

[lnicola]

The good news is it's no longer returning an error right from the start. The bad news is that publishing doesn't seem to finish either:

EDIT: 8:30 now.

[lnicola]

Still running, after almost 30 minutes.

@filiptronicek unrelated, but do you think it might be feasible to publish the extension "manually" (e.g. using curl) instead of going through the ovsx tool?

[lnicola]

Killed after 2h:

I'm tempted to disable publishing since we can't let it run like this 8 times a week.

[filiptronicek]

@lnicola sad to hear that the process is hanging 😕, @amvanbaren would you happen to know what might be causing this when only publishing a pre-baked extension file?

[filiptronicek]

@filiptronicek unrelated, but do you think it might be feasible to publish the extension "manually" (e.g. using curl) instead of going through the ovsx tool?

Yes! You can use /api/-/publish in the API - https://open-vsx.org/swagger-ui/#/registry-api/publishUsingPOST

[filiptronicek]

Just tried publishing some other extensions, seems the timeout is happening there as well, forwarding it to the team internally, will get back.

Edit: Eclipse has restarted Open VSX and I was able to publish an extension now

[lnicola]

@filiptronicek now it's back to returning 500: https://github.com/rust-lang/rust-analyzer/actions/runs/3253769967/jobs/5341462634.

[lnicola]

rust-analyzer is now available on OpenVSX: https://open-vsx.org/extension/rust-lang/rust-analyzer.

That's only a pre-release version, you get an error if you try to install it, but you can still use the "Install Pre-Release Version" option to get it.

Thanks @amvanbaren and kineticSquid for the help!