Arch Linux User Repository

Another day without electron29 update, so you will still be needing the dirty fix mentioned above if you want to build with electron29.

By the way, as a followup to this convo, as now I completely understand the packaging process, I can answer: ripgrep is being depended on because in the usual vscodium package, electron and ripgrep are the only two binary executables present in the compiled files. It is then reasonable for this package to remove both of them and link the system versions of them instead.

I am working on the major v1.90 update, which upgrades to electron 29 and node 20.9.0. However a confusing situation is found: The latest electron 29 version is 29.4.2, however the electron29 in the Arch repo is 29.4.3. This breaks build as the process can't find the source on GitHub for the system electron installed. I have alerted several Arch community managers about this and we are investigating.

--- Update ---

Issue for the electron problem is here

I already updated this repo anyways. By design, you can choose whatever version of system electron to use by modifying the PKGBUILD (of course no one can guarantee that things will run fine).

But, if you choose electron29, due to the issue mentioned above, build will fail. A nasty solution is, modify /usr/lib/electron29/version to be 29.4.2. This can trick the build system into getting electron v29.4.2 source files instead. I did this and the editor appears fine with me so far.

A note from maintainer me: I am still alive and will check and update this package soon. Just that these two weeks I am graduating, moving out from my apartment, preparing US departure, etc., TLDR too busy to do anything else. Sorry for the delay, I will definitely come back to this soon.

Is there any reason why the compiled VSCodium has a different release number than the package indicates? Mine has version 24124, while this package is currently 24102.

As of Python 3.12, distutils is no longer included by default, which is needed by the compile script. It would make sense to make this package depend on python-setuptools as this provides distutils.

I had an issue where on wayland, vscodium would start by opening the vscodium.js file rather than the welcome tab, while it would launch normally on X11. Changing process.argv.splice(0, 1); to process.argv.splice(0, process.argv.findIndex(arg => arg.endsWith('/vscodium.js'))); in vscodium.js fixed the problem and resulted in it opening to the welcome screen as expected.

@fredricocalamari yeah it looks like the branch issue has been fixed. I wasn't having issues with this build, though (other than noticing the strange git situation).

@ironveil can you confirm it has been fixed for you as well? You might have to delete this package from yay's PKGBUILD cache (if it even has one? I don't use yay), since the cloned repo might be in a weird state.

@MithicSpirit I just successfully rebuilt the latest submit this time using yay to automate the entire process. I selected cleanbuild and it now works as intended, at least on my computer.

@fredricocalamari I think that the only current issue is that the remote has a detached HEAD. The latest PKGBUILD seems to be working fine.

@Richardn huh that's weird. Good luck, both with git and with your studies.

I guess I am lucky that I was able to get the package to build on 4/9 right after @Richardn merged the xwayland fix to the repo. If you can roll back to that date and work from there I think you will have more luck fixing the issues others are having considering it worked for me. I had to clone the source and run makepkg. I didn't use yay. I have the fully functioning no-xwayland patched vscodium-electron installed already so I know there is a working configuration. We just need to track it down.