Arch Linux User Repository

@Icelk set up a script that checks for new releases and pushes updates if there are any new ones. I believe it runs every hour so there's no need to flag OOD, unless there's something that needs changed with the PKGBUILD.

Vscodium now uses Electron version 39 internally, which should automatically default to Wayland. Not sure that the vscodium-bin-wayland.desktop is still needed, on my system Vscodium runs on Wayland whether I launch with vscodium-bin-wayland.desktop or vscodium-bin.desktop

many warnings, full logs for makepkg are too long to paste here, see https://bbs.archlinux.org/viewtopic.php?pid=2279997#p2279997

Here are some logs:

Error while writing index for `/usr/lib/debug/opt/vscodium-bin/chrome-sandbox.debug': No debugging symbols
Error while writing index for `/home/u/Downloads/vscodium-bin/pkg/vscodium-bin/opt/vscodium-bin/chrome-sandbox': No debugging symbols
gdb-add-index: No index was created for ./opt/vscodium-bin/chrome-sandbox
gdb-add-index: [Was there no debuginfo? Was there already an index?]
debugedit: ./opt/vscodium-bin/resources/app/node_modules/node-pty/build/Release/pty.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/node-pty/build/Release/pty.node: Unknown debugging section .debug_gnu_pubtypes
Error while writing index for `/usr/lib/debug/opt/vscodium-bin/resources/app/node_modules/@vscodium/native-keymap/build/Release/keymapping.node.debug': No debugging symbols
Error while writing index for `/home/u/Downloads/vscodium-bin/pkg/vscodium-bin/opt/vscodium-bin/resources/app/node_modules/@vscodium/native-keymap/build/Release/keymapping.node': No debugging symbols
gdb-add-index: No index was created for ./opt/vscodium-bin/resources/app/node_modules/@vscodium/native-keymap/build/Release/keymapping.node
gdb-add-index: [Was there no debuginfo? Was there already an index?]
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@vscodium/policy-watcher/build/Release/vscodium-policy-watcher.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@vscodium/policy-watcher/build/Release/vscodium-policy-watcher.node: Unknown debugging section .debug_gnu_pubtypes
debugedit: ./opt/vscodium-bin/resources/app/node_modules/kerberos/build/Release/obj.target/kerberos.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/kerberos/build/Release/obj.target/kerberos.node: Unknown debugging section .debug_gnu_pubtypes
debugedit: ./opt/vscodium-bin/resources/app/node_modules/kerberos/build/Release/kerberos.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/kerberos/build/Release/kerberos.node: Unknown debugging section .debug_gnu_pubtypes
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@parcel/watcher/build/Release/watcher.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@parcel/watcher/build/Release/watcher.node: Unknown debugging section .debug_gnu_pubtypes
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@vscode/sqlite3/build/Release/vscode-sqlite3.node: Unknown debugging section .debug_gnu_pubnames
debugedit: ./opt/vscodium-bin/resources/app/node_modules/@vscode/sqlite3/build/Release/vscode-sqlite3.node: Unknown debugging section .debug_gnu_pubtypes
Error while writing index for `/usr/lib/debug/opt/vscodium-bin/resources/app/node_modules/@vscode/ripgrep/bin/rg.debug': No debugging symbols
Error while writing index for `/home/u/Downloads/vscodium-bin/pkg/vscodium-bin/opt/vscodium-bin/resources/app/node_modules/@vscode/ripgrep/bin/rg': No debugging symbols

Coexistence of vscdoium(x11) and vscdoium(wayland) is a little annoying. Is there anyway to make it wayland only, for desktop entries, file manager context menu, etc?

Strangely this package doesn't provide Plasma 6 global menu while AUR package 'vscodium' does.

@Nemris @tyrheimdal

Thanks for the suggestions! They should be implemented now.

Seconding what @nemris said, apart from the "Optional" part. Using rm on find with unknown output is DANGEROUS.

Additionally there's no reason to do manually chown and chmod on the SUID chrome-sandbox binary. Just use install -Dm4755 SRC DEST instead.

LICENSE handling is missing, see: https://wiki.archlinux.org/title/PKGBUILD#license

You don't have to specify ${srcdir} as you are already in the directory when using the package() function. It's generally a bad idea to switch directory in the function. See https://man.archlinux.org/man/PKGBUILD.5#PACKAGING_FUNCTIONS for more details.

If you are unsure, consider taking inspiration from other official chrome-based packages like: https://gitlab.archlinux.org/archlinux/packaging/packages/chromium/-/blob/main/PKGBUILD?ref_type=heads#L277-346

Optionally, you can do away with both the cding and rm by having find do all the work:

diff --git a/PKGBUILD b/PKGBUILD
index 09f0e98..e12ae9c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -51,9 +51,7 @@ package() {
   install -d -m755 "${pkgdir}/usr/share/"{applications,pixmaps}
   cp -r "${srcdir}"/* "${pkgdir}/opt/${pkgname}"
   # remove source files links
-  cd "${pkgdir}/opt/${pkgname}"
-  rm $(find "${pkgdir}/opt/${pkgname}" -maxdepth 1 -type l)
-  cd -
+  find "${pkgdir}/opt/${pkgname}" -maxdepth 1 -type l -delete
   ln -s "/opt/${pkgname}/bin/codium" "${pkgdir}/usr/bin/codium"
   ln -s "/opt/${pkgname}/bin/codium" "${pkgdir}/usr/bin/vscodium"
   install -D -m644 "${srcdir}/vscodium-bin.desktop" "${pkgdir}/usr/share/applications/codium.desktop"

@wackbyte

Thanks! That should be fixed now.

The PKGBUILD seems to install files that are symlinks into the build directory, which are easily broken, particularly when building in a clean chroot.

In /opt/vscodium-bin/ I have:

code.svg -> /startdir/code.svg
vscodium-bin.install -> /startdir/vscodium-bin.install
vscodium-bin.sh -> /startdir/vscodium-bin.sh
vscodium-bin-wayland.desktop -> /startdir/vscodium-bin-wayland.desktop

@hiruocha

I didn't find a way to do it without using bash's eval which opens users up to shell injection vulnerabilities. If you find one please send a diff :)