Arch Linux User Repository

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.

Actually when I first adopted the package I manually tested everything in a manually set up chroot and there was no problems. Probably because I was just being lucky at that time, files scattering in the working dir in a specific pattern that did not yield problems.

About "repository in this weird state": Now I am concerned. Yes, AUR git server was behaving strange yesterday when I made the update. When I git push as usual, the command line signals success all the way to "Writing objects...done", but then everything just hang on my side. I saw that on the webpage the "last updated" number indeed updated, while git was still hanging. I interrupted and tried several times, all the same. After I came back an hour later I saw that the changes are in place in "View Changes" so I be like "well...this means everything works in the end"?

I will look into this when I have the time (poor Computer Engineering student solving and plotting MOSFETs here).

Update: Oh I just tried git push origin master and my git did not hang this time. And cloning is successful.

@Richardn my "AUR helper" that is causing this is makechrootpkg, which is for building packages in a clean chroot (see the wiki). I've found this helpful for detecting issues in my (and sometimes other's) PKGBUILDs.

@ironveil this issue is because the current remote HEAD is a detached commit. Not sure what exactly happened to put the repository in this weird state, nor how to fix it. Maybe the maintainer can try pushing their master branch manually (git push origin master?).

The latest version doesn't build from yay, gives me this error:

:: (1/1) Downloaded PKGBUILD: vscodium-electron
 -> error merging /home/ironveil/.cache/yay/vscodium-electron: fatal: No current branch.