code-server/4.108.1 package update

[octo-sts]

Commit: ba588b47099b31ad9734ef05534e9813bae22c64

Note: If you need to make manual changes to this PR, apply the skip:staging-update-bot label so the reconciler won't overwrite them.

[octo-sts]

🩹 Build Failed: Patch Application Failed

patch unexpectedly ends in middle of line
Hunk #1 FAILED at 32.
1 out of 1 hunk FAILED -- saving rejects to file lib/vscode/package.json.rej

Build Details

Category	Details
Build System	Wolfi Package Pipeline
Failure Point	patch command during step "patch" while applying node-memory.patch series

Root Cause Analysis 🔍

The patch file for lib/vscode/package.json is malformed or corrupted - it ends unexpectedly in the middle of a line, causing the patch application to fail. This prevents the build pipeline from continuing as the required modifications to package.json cannot be applied.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Suggested Changes

File: node-memory.patch

• fix_patch_format at line last line (end of file)
  Original:

The last line of the patch file ending abruptly without newline

Replacement:

Add a newline character at the end of the patch file to ensure proper patch format

Content:

Ensure the patch file ends with a proper newline character

Click to expand fix analysis

Analysis

Based on the three similar build failures, there's a clear pattern: all failures were caused by malformed patch files that ended unexpectedly in the middle of a line. The fixes consistently involved one of two approaches: 1) Fixing the malformed patch file by adding a proper newline at the end, or 2) Removing the problematic patch entirely from the build pipeline. In the first example, the vllm-remove-cmake.patch was fixed by adding a newline after the last line. In examples #1 and #2, the problematic patches (ingest-attachment.patch and bouncycastle.patch) were removed entirely from the pipeline along with corresponding YAML modifications.

Click to expand fix explanation

Explanation

The error indicates that the node-memory.patch file is malformed and ends unexpectedly in the middle of a line. This is a common issue with patch files that don't have proper line endings. The most likely fix is to ensure the patch file has a proper newline character at the end. This matches the pattern from Fix Example #0, where the vllm-remove-cmake.patch was corrected by adding a newline at the end. Patch files must end with a newline character for the patch command to process them correctly. Without this, the patch utility fails with the "unexpectedly ends in middle of line" error when it cannot parse the final line properly.

Click to expand alternative approaches

Alternative Approaches

• Remove the node-memory.patch from the pipeline entirely if the patch is no longer needed for the current version
• Regenerate the node-memory.patch file from scratch to ensure proper formatting
• Check if the patch content is still relevant for package version 4.108.1 and update accordingly

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[OddBloke]

OK, this one is going to be complicated to resolve. code-server has updated to use vscode 1.107.0 (coder/code-server@ea9a3a5) which includes a series of commits to the microsoft-authenticator extension which I don't fully understand, but which seem to remove the option of a Node-native authentication method in favour of msal-node: this pulls in msal-node-runtime (npm) which ships libmsalruntime.so: this is pre-compiled (that's a problem) and causes SCA to generate dependencies on several libraries we don't have packaged (including so:libwebkit2gtk-4.1.so.0, suggesting it includes a whole browser stack). Further complicating matters, I don't believe we could build this ourselves: https://www.npmjs.com/package/@azure/msal-node-runtime points at https://github.com/AzureAD/microsoft-authentication-library-for-cpp as its upstream, which no longer exists.

This problem does only surface on x86_64: it doesn't look like msal-node-runtime ships a .so for any architecture but x86_64, so it's possible that (a) aarch64 is simply broken due to this absence, or (b) aarch64 isn't broken and we could maybe hack at x86_64 to get it to behave the same as aarch64. microsoft/vscode#278689 looks like the relevant change we would need to potentially revert or modify.