[Max-42]

Sorry everyone! I'm still relatively new to contributing to nixpkgs, and I got some branches mixed up while working on PR #580502. I also overlooked the upstream commit 08a2d5fff737. Sorry for the confusion!

I've tried to address this properly in this follow-up PR. It brings in the relevant changes from:

• 08a2d5fff737, which introduced support for @vscode/ripgrep-universal.
• 0c2094806c9e, which fixed the macOS ripgrep path for VS Code >= 1.129.

Testing:

I reproduced the original build failure and verified that this change fixes it. I successfully built the package on x86_64-linux using:

NIXPKGS_ALLOW_UNFREE=1 nix build --impure \
  .#legacyPackages.x86_64-linux.vscode \
  -o result

I also rebased the change onto the latest release-26.05 and repeated the build successfully.

Thanks for your patience, and sorry again for the branch confusion!

Things done

• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.
• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • aarch64-darwin
• Tested, as applicable:
  • Basic functionality of all binary files, usually in ./result/bin/.
  • Ran nixpkgs-review on this PR. See nixpkgs-review usage.
  • Package tests at passthru.tests.
  • NixOS tests in nixos/tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.

[nixpkgs-commit-check]

This report is automatically generated by the PR / Check / cherry-pick CI workflow.

Some of the commits in this PR require the author's and reviewer's attention.

Sometimes it is not possible to cherry-pick exactly the same patch.
This most frequently happens when resolving merge conflicts.
The range-diff will help to review the resolution of conflicts.

If you need to merge this PR despite the warnings, please dismiss this review shortly before merging.

Warning

Difference between 1e96977 and original 08a2d5f may warrant inspection.

Show diff

@@ Metadata
  ## Commit message ##
     vscode: 1.119.0 -> 1.122.1
 
+    (cherry picked from commit 08a2d5fff737305a13c39a47a49cf8590567220d)
+
  ## pkgs/applications/editors/vscode/generic.nix ##
 @@ pkgs/applications/editors/vscode/generic.nix: stdenv.mkDerivation (
          # Remove native encryption code, as it derives the key from the executable path which does not work for us.
@@ pkgs/applications/editors/vscode/generic.nix: stdenv.mkDerivation (
          in
          if !useVSCodeRipgrep then
            ''
-
- ## pkgs/applications/editors/vscode/vscode.nix ##
-@@ pkgs/applications/editors/vscode/vscode.nix: let
- 
-   hash =
-     {
--      x86_64-linux = "sha256-HcZIRGB0y8U5huxXN9jNrhMD0Jjmn+QNUU60EHGduXo=";
--      x86_64-darwin = "sha256-mMDxEAt/Lst4ifeczcL+QT8mVVXNk8fDNTM1YHGZ8tY=";
--      aarch64-linux = "sha256-o0JV1Vc6utTmJkH9uTSylBsYM3mAfiDIgwg3LUOBWb0=";
--      aarch64-darwin = "sha256-8ixVOUe4EcNX/z0jnux1hXOhnG1JuhbssH2BARqU80o=";
--      armv7l-linux = "sha256-KxrSOVCdfa4L9RlnHybwGLRciMFwC/COsctX+5nqR/c=";
-+      x86_64-linux = "sha256-t26YN3E5XaSJ7gki8nm06hVh4ZvXDEU77M749ZrqfAo=";
-+      x86_64-darwin = "sha256-jOnwhiDJmU+EqU30wg1+frqDDxJgfngETx414i2YTIg=";
-+      aarch64-linux = "sha256-8sYanI12qDMPgVG7S0QKLEkU0i/SICkJ5wz/OwhP+i4=";
-+      aarch64-darwin = "sha256-oXeZZWAvpUn5KItEOR8yX9iQ0Fp6EzXGux0jvYbZqtU=";
-+      armv7l-linux = "sha256-16cUu1C389edf0aHxXxTLJwjxmpHxM8mv1YFnPDLgP4=";
-     }
-     .${system} or throwSystem;
- 
-   # Please backport all compatible updates to the stable release.
-   # This is important for the extension ecosystem.
--  version = "1.119.0";
-+  version = "1.122.1";
- 
-   # The update server (update.code.visualstudio.com) expects the version path
-   # segment in X.Y.Z form, so we normalize X.Y to X.Y.0 (e.g. "1.110" → "1.110.0").
-@@ pkgs/applications/editors/vscode/vscode.nix: let
-   downloadVersion = lib.versions.pad 3 version;
- 
-   # This is used for VS Code - Remote SSH test
--  rev = "8b640eef5a6c6089c029249d48efa5c99adf7d51";
-+  rev = "8761a5560cfd65fdd19ce7e2bd18dab5c0a4d84e";
- in
- buildVscode {
-   pname = "vscode" + lib.optionalString isInsiders "-insiders";
-@@ pkgs/applications/editors/vscode/vscode.nix: buildVscode {
-     src = fetchurl {
-       name = "vscode-server-${rev}.tar.gz";
-       url = "https://update.code.visualstudio.com/commit:${rev}/server-linux-x64/stable";
--      hash = "sha256-FyRpbjxY8PWr8z+ttn1H93ud4raFAJz704Vn38+LYCM=";
-+      hash = "sha256-7n8KvIYEDYO8qqJjfbuUsgUwCxq9FJ6i/EuDBd1HQDk=";
-     };
-     stdenv = stdenvNoCC;
-   };

Hint: The full diffs are also available in the runner logs with slightly better highlighting.

[Max-42]

In reply to #585147 (review):

The original commit also updates vscode.nix from 1.119.0 to 1.122.1. Since release-26.05 already ships VS Code 1.144.0, applying those changes would unnecessarily downgrade the package and replace its source hashes.

Edit: This is not longer true since #585279 .

[qweered]

Fixes #584492

[Max-42]

I just saw that #585279 got merged so please do not merge this now.

I'll fix the missing version later today

[Max-42]

It looks like we now have two reports of the same VS Code build failure: #585142, which was closed as a duplicate of #584492.

Both issues are caused by the changed location of the bundled ripgrep binary in newer VS Code versions.

This should be addressed by this PR, #585147.

However, #585279 has now been merged, reverting my previous backport in #580502 because VS Code 1.144.0 failed to build.

Since this PR now contains the necessary ripgrep path fixes, I would like to reintroduce the VS Code update alongside those fixes, effectively restoring 1.144.0 with the build failure addressed.

My proposal is to undo the revert in this PR, test the combined changes again with nixpkgs-review and verify the build.

In parallel, I would also like to update VS Code on unstable to a newer version and, once that update has landed, backport the newer version to release-26.05.

This way, we can get the existing build failure fixed and restore the VS Code update without having to wait for the next upstream update.

Would you prefer this approach, or would you rather keep the ripgrep fix and the VS Code version update in separate PRs?

[sarahec]

Would you prefer this approach, or would you rather keep the ripgrep fix and the VS Code version update in separate PRs?

The two should not be combined as they're so different.

First, understand why your previous change broke the build. Then carefully construct a new PR to apply the ripgrep fix.

[Max-42]

@sarahec I think you may have missed the linked issue: #584492.

To summarize: Starting with VS Code 1.122, Microsoft changed the location of the bundled ripgrep binary. This is documented in the upstream issue: microsoft/vscode#318691.

This was already fixed on unstable, where everything was working fine. I simply didn't realize that the corresponding workaround was still missing from 26.05. That's why I didn't include it in #580502. This was clearly my mistake, although it also went unnoticed during the package review.

That is precisely what this PR was intended to address.

However, before this additional fix could be merged, @dotlambda reverted my previous PR (which did not yet include the workaround) in #585279. As a result, we are now left with this PR, which on its own no longer really makes sense.

Versions prior to 1.122 did not require this workaround, which is probably why it was never backported to 26.05 and only existed on unstable.

I completely understand why my previous PR was reverted.

Given how much has changed in the meantime, I think the cleanest approach is to wait until #585343 reaches unstable and then prepare a completely new backport containing both the workaround and the update to VS Code 1.145.2.

Therefore, I propose closing this PR for now and starting over in a few days, once #585343 has been merged.

To be honest, I don't have the energy to keep updating and rebasing this PR every time something changes. I'd rather come back with a clean, complete backport that addresses everything properly.

Thanks for your understanding.