Package Details: vscodium-bin 1.95.3.24321-1

Git Clone URL: https://aur.archlinux.org/vscodium-bin.git (read-only, click to copy)
Package Base: vscodium-bin
Description: Binary releases of VS Code without MS branding/telemetry/licensing.
Upstream URL: https://github.com/VSCodium/vscodium
Licenses: MIT
Conflicts: vscodium
Provides: codium, vscode, vscodium
Submitter: ckatri
Maintainer: sperg512 (Icelk)
Last Packager: Icelk
Votes: 311
Popularity: 7.66
First Submitted: 2020-09-23 18:58 (UTC)
Last Updated: 2024-11-16 02:00 (UTC)

Pinned Comments

sperg512 commented on 2021-05-12 00:31 (UTC) (edited on 2024-06-04 15:14 (UTC) by sperg512)

@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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 24 Next › Last »

Icelk commented on 2023-06-15 07:46 (UTC)

@michaelskyf I'll revert that immediately! Thanks for reporting it.

Icelk commented on 2023-06-15 07:46 (UTC)

@jronald AUR packages can't be built on file system which do not support symbolic links (e.g. samba). Your issue should affect every package, not just this. Glad you resolved it!

jronald commented on 2023-06-14 17:35 (UTC) (edited on 2023-06-15 06:59 (UTC) by jronald)

EDIT works well for a normal path instead of samba


$ makepkg
...
==> Extracting sources...
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/vscodium-bin.desktop': Operation not supported
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/vscodium-bin-uri-handler.desktop': Operation not supported
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/vscodium-bin.install': Operation not supported
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/vscodium-bin.sh': Operation not supported
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/vscodium-bin-wayland.desktop': Operation not supported
ln: failed to create symbolic link '/home/abc/nuc_share/archlinux/aur/vscodium-bin/src/VSCodium-linux-x64-1.79.1.23164.tar.gz': Operation not supported

samba mounted on /home/abc/nuc_share

michaelskyf commented on 2023-06-14 07:59 (UTC) (edited on 2023-06-14 09:13 (UTC) by michaelskyf)

Hi! For some reason Codium wasn't launching for me under pure wayland session after an update. I had flags set in codium-flags.conf, but it looked like the program wasn't reading them. The solution was to remove "" around $CODE_USER_FLAGS from vscodium-bin.sh

...
# Launch
exec /opt/vscodium-bin/bin/codium "$@" "$CODE_USER_FLAGS"
...
# Launch
exec /opt/vscodium-bin/bin/codium "$@" $CODE_USER_FLAGS

The commit that introduced the bug: f89ac63d1886

Icelk commented on 2023-06-12 20:53 (UTC)

@manuth Thanks! The problem with changing the WMClass is that under xorg (and xwayland), it still has the VSCodium class. I'll create another .desktop entry with wayland options.

manuth commented on 2023-06-09 10:57 (UTC)

For whatever reason, when launching VSCodium with --ozone-platform-hint=wayland, the window class is codium-url-handler. I think it might make sense to reflect this in the StartupWMClass of codium.desktop.

manuth commented on 2023-06-09 10:49 (UTC) (edited on 2023-06-09 11:02 (UTC) by manuth)

The vscodium-bin.sh file currently does not work properly. The fact that "$@" is passed to vscodium after $CODE_USER_FLAGS seems to cause vscodium to ignore the specified directory/file to open.

This can be fixed by - much like in visual-studio-code-bin - by passing the "$@" first and $CODE_USER_FLAGS after.

LRitzdorf commented on 2023-05-13 13:20 (UTC)

Looks like the rendering issue is fixed in 1.78.2. Thanks for the quick update!

macwen commented on 2023-05-11 04:41 (UTC)

Rendering also seems to be broken for the edge devtools in version 1.78.1.23130-1. Rollback to version 1.77 seems to fix it.

LRitzdorf commented on 2023-05-10 23:48 (UTC)

As a heads-up, it looks like rendering is somehow broken in v1.78.1. I updated (1.77.3.23102-1 -> 1.78.1.23130-1) earlier today, and upon restarting, the Release Notes page and PDF previews from the LaTeX Workshop extension are simply blank.

The Interactive Editor Playground seems to work, and actual source code is also rendered successfully, so I'm not quite sure what's going on here.