Arch Linux User Repository

I know how rg is being depended, but not exactly why as the package adopter.

If you read the install() section, you will find that the rg being bundled with the package is replaced by and linked to the system rg. This is the dependency.

That said, I am not 100% sure why. If rg is the only binary other than the main code (and the now gone bundled electron) in the built package, then maybe it is a good idea to also use system rg due to the philosophy of this package. If there are multiple other bundled binaries, then it makes no sense to only pick rg and replace it. And I am not sure about which is the case.

FYI, before I adopt, the package creator replaced grep usage in the vscodium build script with rg, and now that I reverted the build process back to the original scripts, rg is no longer needed here.

Out of curiosity, why is ripgrep a dependency for this package? I checked the PKGBUILD and it seems like it's not needed at all. The main vscodium package doesn't depend on it.

Okay, now I am the maintainer of this package. On my local side, I have written a bash script for building vscodium with system electron and have been testing in a clean chroot environment. Major changes include:

• The script respect the original vscodium repo more, with as minimum mangling as possible. For example the download of vscode is now handled by the repo's get_repo.sh, instead of by the makepkg system.
• As nvm is used, the yarn used for building the package will be the yarn installed by the npm from the node installation by nvm for building the package. Dependency on system yarn is removed.

Now I have reached the step where the checksum failure is reproduced, and has determined the cause. During step

# previously vscode-linux-$TARGET-min, I really am not sure the differences, but I will respect the vscodium repo
yarn gulp vscode-linux-$TARGET-min-ci

A fresh electron copy is being downloaded for building purposes. As this package is targeting system electron, the version to download is mangled to be the system electron's version. However, this download is checksum'ed against checksums contained in vscode/build/checksums/electron.txt, which only includes checksums for the officially targeted electron version, thus resulting in a No checksum found error. I am currently determining a workaround.

--- EDIT ---

Done. Solution is to curl down the checksum of electron source of the system electron's version from GitHub. A similar move is done in the Arch official vscode package.

Is _nodejs="16.17.1" too outdated or something? makepkg yields 404 for https://artifacts.electronjs.org/headers/v16.17.1/node-v16.17.1-headers.tar.gz, thus failing. I switched to 18.16.1 in the PKGBUILD and started making.

The first thing I noticed is that if /usr/lib/$_electron/version does not present, an error will only be generated late in compilation, which is annoying. I suggest defaulting $_electron to none and hinting the user early in the build to set this variable if it is not set properly.

Then, I tried electron19-bin and electron22, both yielded

Error: No checksum found in checksum file for "electron-vXX.X.XX-linux-<arch>..zip"

, failing the build. Is this an upstream bug?

I do not manage a build till now.

--- EDIT ---

I found that if the "current" node.js is not v16.17.1, the build process will try to download v16.17.1 headers from electron.js, and will yield a 404, breaking the build. I nvm use 16.17.1 before makepkg and the making has been progressing. Still, stuck at the checksum issue.

--- EDIT ---

I managed a build with the 2023-08-04 version.

--- EDIT ---

From time to time I randomly encounter the checksum failure problem. A dirty solution is during the build, delete the checksum function call at <package-root>/src/vscode/node_modules/@vscode/gulp-electron/src/download.js:146. I did some prints of the pathnames used, and suspect that the failure is about switching directories when building. I do not have much experience in this, and just noting this down.

Is extensions marketplace even work on this package? Infinite loading for me. Nvm marketshare not work with exec electron21 for me. With 22 electron, vscodium don't wanna run with wayland flags. 23-24 electron works, but it load random cpu core to 100% always.

Vscode upstream does not support electron 22 yet, and is only planning on upgrading to it with version 78 for the mean time. Furthermore, on my system, vscodium.sh launches with wayland properly with the script. What kind of GPU are you using?

I had to make a modification to /usr/bin/codium to get this to work under wayland (mesa driver). I have to use the electron package instead of electron19 and:

--- ELECTRON_RUN_AS_NODE=1 exec electron19 /usr/lib/vscodium/out/cli.js /usr/lib/vscodium/vscodium.js --enable-features=UseOzonePlatform --ozone-platform=wayland "$@"

+++ ELECTRON_RUN_AS_NODE=1 exec electron /usr/lib/vscodium/out/cli.js /usr/lib/vscodium/vscodium.js --ozone-platform=wayland "$@"

@REmorin, done