Arch Linux User Repository

hey guys, @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

Can you please add vscode to provides array? See https://wiki.archlinux.org/title/Talk:Visual_Studio_Code#Provides_array_for_flavor_packages

1.66.0-1 seems to have broken wayland support via --ozone-platform=wayland (not sure whether --enable-features=UseOzonePlatform was still required for this one). Does somebody know what broke it?

Another reminder that unless the package isn't updated for several hours, or something needs fixed in the PKGBUILD, then you do not need to flag this OOD

That's a weird issue. I think GitHub for some reason reported the wrong version, causing my bot to revert the version. It's however fixed now.

Based on my pacman history, it looks like v1.63.2-2 was installed, then removed (by me), then reinstalled later:

[2022-01-01] [ALPM] installed vscodium-bin (1.63.2-2)

[2022-01-19] [ALPM] removed vscodium-bin (1.63.2-2)

[2022-01-21] [ALPM] installed vscodium-bin (1.63.2-2)

yay -Ss vscodium-bin shows aur/vscodium-bin 1.63.2-1 (+122 8.97) (Installed: 1.63.2-2)

@GIgas002 I don’t see any 1.63.2-2 version?

What was the problem with 1.63.2-2 version? It's now displayed, as "newer, than in AUR (1.63.2-1)"? I don't see the sense in two latest commits.

@Icelk Thanks,

@ZorinArch Done!

Hi @Icelk, please update checksum of vscodium-bin-marketplace from md5 to sha256.

@Icelk I tested on both my main machine and a clean Arch VM and everything works as expected. I don't use those downstream packages (such as vscodium-bin-features or vscodium-bin-marketplace) but I guess they need to be patched as well.

@macxcool Is it working now?

(1/3) Arming ConditionNeedsUpdate... (2/3) Updating the desktop file MIME type cache... (3/3) [vscodium-bin-marketplace] Patching product.json... sed: can't read /usr/share/vscodium-bin/resources/app/product.json: No such file or directory error: command failed to execute correctly

@KDN_Observer Can you confirm it works as expected now?

@KDN_Observer Thanks a lot! I'll implement this today.

@Icelk Here you go. Basically I changed all the occurrences of /usr/share/${pkgname} to /opt/${pkgname}

@Ashark

Since we're only redistributing the binary, we can't change this.

I agree, removing own electron will be good, if possible. I was confused when investigating which version of electron the app uses, before I understand that it uses its own.

@KDN_Observer

It seems like no other distribution of VSCode does this. Could you provide the diff of the PKGBUILD to change this?

As per Electron package guidelines, packages that contain a prebuilt copy of electron shall be installed in /opt/appname rather in /usr/share. Please change your PKGBUILD to either 1) remove the bundled electron and use the system one instead or 2) install inside the /opt/vscodium-bin directory

@animo Are the checksums good now?

@indicozy Try reinstalling electron. Don't think any electron app should throw a Segmentation fault, ever.

@indicozy, Which version you meant update to?

In order to try to reproduce, I re-installed the package. I got the same version as was a week ago already. I see no any issue for me after that reinstallation.

~/Desktop ❯ vscodium
~/Desktop ❯ 

vscodium about window:

Version: 1.62.3
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-19T00:20:00.672Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.15.5-1-MANJARO

Probably some dependency issue. Try to go fix them (you see them in above). May be to refresh kernel is also a possible solution.

Also I am a bit "alien" to Arch Linux (so possibly have a bit different environment):

Operating System: Manjaro Linux
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.5-1-MANJARO (64-bit)
Graphics Platform: X11

after update I got a bug:

$ vscodium
/usr/bin/vscodium: line 53: 38749 Segmentation fault      ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"

Did anyone get the same issue?

The 1.62.2 sha256 sum for the ARM64 architecture is wrong in PKGBUILD, here's the correct one: 3a7b9931ab1bc3432ba6e4323c7f0caf280e236d95fc6b30c6cb24e9af925f02 .

Hi @3y3p4tch! I believe it is to allow all features like reading workspaces and other content in the .vscode directory.

Check the vscode docs (or something), since it's just an argument to vscode.

Hi maintainers, I noticed that vscodium-bin.desktop contains 'no-sandbox'. Any particular reason for it being there? If not, then could it be removed? (My build works perfectly without no-sandbox)

@willemw @sperg512 This is now implemented and will be added in the next release by the auto-updater, so we don't push an unneeded change to all using this package.

@willemw yeah, that's what he means, we can just add "vscodium" to provides and it'll pop up that same menu when you yay -S vscodium.

@Icelk: I would just add 'vscodium' to 'provides' now to this package (and all the other packages you maintain). It is optional to do so and there is no downside.

By "Do all the options appear with a default?" do you mean similar to this:

$ paru -S paru
:: Resolving dependencies...
:: There are 3 providers available for paru:
:: Repository AUR:
    1) paru  2) paru-bin  3) paru-git
Enter a number (default=1):

Answer is yes.

@willemw That probably won't happen as I only have influence on this. If you get any of the others to add that to the "provides", I'll add it here.

How will it work when you try to $ paru -S vscodium when the package with an exact name exists? Do all the options appear with a default?

Thanks!

@Icelk: Have all related 'vscodium' packages change from 'provide ... codium' to 'provide ... vscodium'.

@willemw So what do you propose we do?

A specific 'provide' name in several packages will give you all the provide choices:

$ paru -S codium
:: Resolving dependencies...
:: There are 3 providers available for codium:
:: Repository AUR:
    1) vscodium-git  2) vscodium  3) vscodium-bin
Enter a number (default=1):

Normally, you would search on 'vscodium' instead of (the unknown) 'codium' (name), but that will now not give you all the 'provide' choices:

paru -S vscodium
:: Resolving dependencies...
:: Calculating conflicts...
:: Calculating inner conflicts...

Repo Make (3) gulp-4.0.2-3  yarn-1.22.17-1  git-lfs-3.0.1-1
Aur (2) nvm-0.39.0-1  vscodium-1.61.2-1

:: Proceed to review? [Y/n]:

@willemw Thanks. It should now be fixed.

@Icelk:

...
looking for conflicting packages...

Packages (1) vscodium-bin-1.61.2-3

Total Installed Size:  268.72 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                                                      [#####################################################################] 100%
(1/1) checking package integrity                                                                                    [#####################################################################] 100%
(1/1) loading package files                                                                                         [#####################################################################] 100%
(1/1) checking for file conflicts                                                                                   [#####################################################################] 100%
error: failed to commit transaction (conflicting files)
vscodium-bin: /usr/bin/codium exists in filesystem (owned by vscodium)
vscodium-bin: /usr/bin/vscodium exists in filesystem (owned by vscodium)
vscodium-bin: /usr/share/pixmaps/vscodium.png exists in filesystem (owned by vscodium)
Errors occurred, no packages were upgraded.

The issue should now be resolved.

Regarding the conflict, the wiki states that we don't need to specify a conflict when we have a provides in common.

Edit pkgbuild as follows:

pkgrel=3

sha256sums=('65e6b053e6d8be61763801312ded64a82cf835d77a6eabe1b9d7eb9e87b2e49b'
            'f26703924abca3738f2e1f84e5a1e27e8cc7dae4364bb53dbff03c2de5fe0898')

source=('vscodium-bin.desktop'
        'vscodium-bin-uri-handler.desktop')

Yeah having the same issue

Building vscodium-bin...
==> Making package: vscodium-bin 1.61.2-2 (Wed 27 Oct 2021 03:01:32)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found vscodium-bin.desktop
  -> Found VSCodium-linux-x64-1.61.2.tar.gz
==> Validating source files with sha256sums...
    vscodium-bin.desktop ... Passed
==> Validating source_x86_64 files with sha256sums...
    VSCodium-linux-x64-1.61.2.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting VSCodium-linux-x64-1.61.2.tar.gz with bsdtar
==> Entering fakeroot environment...
==> Starting package()...
install: cannot stat '/var/tmp/pamac-build-corey/vscodium-bin/src/vscodium-bin-uri-handler.desktop': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting..

FYI vscodium-bin-uri-handler.desktop needs to be added to the source section section in pkgbuild

@Icelk: OK. I thought that 'codium' was maybe an old package name. Normally, the name to provide and conflict with would be 'vscodium', i.e. without introducing a new name.

It still think that a 'conflict' name is missing. See the "VCS package guidelines". There you have to define a name that is both in 'provides' and in 'conflicts'. For *-bin packages, I think, the same rule applies.

@Icelk Thanks for url handler.
It is strange why in code-oss they do not use vscode scheme.

Latest version fails

==> Starting package()...
install: cannot stat '/home/vuk/.cache/yay/vscodium-bin/src/vscodium-bin-uri-handler.desktop': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
 -> error making: vscodium-bin

@Ashark The desktop file is now included.

@willemw This is not needed as it provides "codium", which automatically conflicts with the other packages.

provides=('vscodium') and conflicts=('vscodium') are missing.

@Ashark That sounds like a good idea. I'll add it when I come home today.

This can't be part of the main .desktop file as that has the flag --no-sandbox, which is unsafe for handling URIs, correct?

Should not this package also include codium-url-handler.desktop, just like code-oss?

I have created a file codium-url-handler.desktop (based on code-oss's file) with this content:

[Desktop Entry]
Name=VSCodium - URL Handler
Comment=Code Editing. Redefined.
GenericName=Text Editor
Exec=/usr/share/vscodium-bin/bin/codium --open-url %U
Icon=vscodium
Type=Application
NoDisplay=true
StartupNotify=true
Categories=Utility;TextEditor;Development;IDE;
MimeType=x-scheme-handler/vscode;
Keywords=vscode;

and placed it in ~/.local/share/applications/codium-url-handler.desktop. Then run update-desktop-database. And then I could open url with vscode:// scheme. Such link can be seen for example here https://invent.kde.org/pim/zanshin. Click green clone button, and at the end of the list you will see "Open in your IDE" Visual Studio Code SSH and HTTPS.

@sperg512 ok.

@zoorat Disable it, this does it every hour--and updates it. No need to, we only need OODs if there's a problem with the build process in the new version.

@sperg512 hi, as i use this package, i have a out-of-date checking script too. i run it every morning and report if needed... should i continue ??

Probably because it directly supports opening directories, though I'm not sure about removing it because some users likely need to open directories with vscodium

Is there a reason the .desktop file contains inode/directory? Personally, I find it really annoying that every directory opens in vscodium instead of the file manager. I would suggest removing it from the mimetypes.

@lunaryorn The update is pushed.

@lunaryorn Sure. The desktop file is named after a variable with the name of the package. @sperg512 if this is not what you want, send me a message and I'll revert it.

Would you mind to install the desktop file as codium.desktop instead of VSCodium.desktop? The former seems to be the standard for VSCodium packages for other distributions, so it'd make it a bit easier to write cross-distribution scripts :)

Even after running pamac clean --keep 0, I had to run rm -rf /var/tmp/pamac-build-$USER/vscodium-bin

It built cleanly after.

Well I'm on Manjaro so I do so in the pamac GUI settings.

Glad to help @Icelk!

@chovy I think clearing the .cache/paru (or yay if you’re using it). Also try paru -Scc.

@gameslayer how did you clean the cache?

==> Validating source_x86_64 files with sha256sums...
    VSCodium-linux-x64-1.60.1.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
error downloading sources: vscodium-bin

@ganeslayer Thank for letting us know.

Yep clearing the cache fixed it, thanks

The hash in the PKGBUILD is the same as https://github.com/VSCodium/vscodium/releases/download/1.60.1/VSCodium-linux-x64-1.60.1.tar.gz.sha256, the hash validating the download. It's a problem with VS Codium's build process. Try clearing the package cache.

Still having issues with the checksum

Building vscodium-bin...
==> Making package: vscodium-bin 1.60.1-3 (Thu 16 Sep 2021 16:19:56)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found vscodium-bin.desktop
  -> Found VSCodium-linux-x64-1.60.1.tar.gz
==> Validating source files with sha256sums...
    vscodium-bin.desktop ... Passed
==> Validating source_x86_64 files with sha256sums...
    VSCodium-linux-x64-1.60.1.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
Failed to build vscodium-bin

==> Validating source_x86_64 files with sha256sums...
VSCodium-linux-x64-1.60.1.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!

@GNQG The hashes should be correct now. The same weird thing happened now as my previous comment.

The checksum for x86_64 seems incorrect too.

@Icelk Installed just fine on my Pinebook Pro now! Thanks.

@gurustave The newest version should have the correct hashes. I just reran the script, which worked! It seems the hashes the script gets from GitHub have changed, or some niche network error occurred while fetching them. What is weirder is that only the arm hashes were wrong. Hope it's fixed now.

@Icelk Thanks! That is indeed the hash I was getting. 255365c524d17aa71550b2c49d08590b17d8783612920c9cb28f4eafe0ef1930 VSCodium-linux-arm64-1.60.0.tar.gz

@gurustave I will correct this one I come back home today. Thanks for the notice.

Does this hash work? 255365c524d17aa71550b2c49d08590b17d8783612920c9cb28f4eafe0ef1930 VSCodium-linux-arm64-1.60.0.tar.gz

The Checksum for the aarch64/arm64 artifact appears to be incorrect. I downloaded the tar a four times between three computers, all had the same, different, checksum.

hey guys, @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

Better. Thanks.

@macxcool alright, should be fixed, try updating now.

I tried it again after Marketplace upgraded. Same problem.

@sperg512 Yes. I tried to upgrade them both at the same time. Should I upgrade Marketplace first? Would you like to see the .rej file?

@macxcool did you also install the update for vscodium-bin-marketplace?

I get this when installing the update

patching file /usr/share/vscodium-bin/resources/app/product.json
Unreversed patch detected!  Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file /usr/share/vscodium-

bin/resources/app/product.json.rej error: command failed to execute correctly

@nimainimaii I'm not actually sure. That's just kind of how it's always been so I've never felt the need to change it.

Is there any reason the package also creates a link to /usr/bin/codium along with /usr/bin/vscodium?

yeah i have absolutely no idea what the fuck is happening rn, i just finished my exams and came back to this lol

anyways, @lkrms you can just create a symlink on your own. it'll stay there for each release, as it's just pointing to /usr/bin/codium which is, ofc, updated each release.

@zaandoff will do, internet is spazzing out atm so I don't know when it'll update.

thanks for everyone's feedback, by the way. i think we should just keep it the way it is right now lol

Also @sperg512, the PKGBUILD still has conflicts with vscode. Line 22 needs be changed to provides=('codium')

Thanks!

I agree as well, that they are separate projects. The names themselves make it clear, and we shouldn't be linking binaries to names that don't match. Especially when there is an AUR package that is for vscode, of which the binary file provided is named code. I would expect that running ln -s /usr/local/bin/codium /usr/local/bin/code is a whole lot easier for anyone who would want that link than manually compiling and installing vscodium every time there is a new release. It makes no sense to link vscodium to code, because it isn't code. Its codium.

@lkrms This project is VS Codium, not VS Code. Yes, they come from the same code base, but they are not the same project. They are compiled differently and their binaries are different. Therefore, linking /usr/local/bin/code to the codium binary doesn't make sense. Its not the same thing.

If your workflows were broken from the removal of this symlink, can you not just add it yourself to get the same result? Inversely, if the symlink is kept in the PKGBUILD, we can not have VS Code and VS Codium installed at the same time. If you truly have a problem with VS Code not being open source, and that being at odds with the spirit of Arch Linux, then a better place to reach out would be either Microsoft, or the maintaner for the VS Code AUR package, would it not?

Again, this is all said respectfully :)

@lkrms Respectfully from my part as well, they are projects with the same root (like OpenOffice and LibreOffice) but with different names and functionality. Yes, indeed they are intended to be as close as possible, but they are not the same, in many aspects.

@teras Respectfully, they're not separate projects. They're distinct builds of the same project, following identical release schedules and versioning. From the VSCodium home page: "The VSCodium project exists so that you don’t have to download+build from source. This project includes special build scripts that clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries for you to GitHub releases."

It's supposed to work as a drop-in replacement for VS Code. Removing this symlink disrupts that (IMHO).

@ikrms IMHO the one project is called "code", the other "codium". If someone requires "codium" to point to "code", just do so. And as a general Unix user, I feel more comfortable to just create this symlink instead of having to use a platform specific and not everyday used "overwrite" or "nodeps" option instead.

The removal of /usr/local/bin/code has broken several of my workflows, and the fact that it's only been done to facilitate installation of proprietary extensions that depend on the proprietary build of VS Code seems at odds with the open-source spirit of both VSCodium and Arch Linux, in my opinion. I would have thought users who require such extensions, and are willing to install multiple variants of VS Code to use them (including manually resolving the conflicts that arise from doing so) would receive little benefit from using VSCodium over VS Code and/or be comfortable using pacman's --overwrite and --nodeps options.

But that's just one user's opinion! Thanks for your consistent and responsive efforts maintaining this package :)

@cradcore removed, thanks

@pryme-svg no need to make a comment, as I already get notifications for new releases + flags out of date. Thanks though

1.52.1 has been released upstream

https://github.com/VSCodium/vscodium/releases/download/1.52.1/VSCodium-linux-x64-1.52.1.tar.gz

@sperg512 I tried to edit it and accidentally deleted it. But thank you! The only other thing is line 39 of the PKGBUILD, that needs to be removed as well. That will fail if code is installed on the system

@cradcore already did, why'd you delete the last comment?

@sperg512 please remove the code and vscode conflicts. There are several proprietary extensions that only work with Microsoft's build of VSCode, and it is a big pain to have to uninstall VSCodium every time we need to use one of these extensions

ok

It's probably some weird issue with yaourt. Submit a bug report to yaourt's repo.

Though it might actually be archived, i dont remember. I'd recommend switching to yay personally

@sperg512 this really worked. I'll have it in my mind the next time. Still, I can't understand why I couldn't install it the usual way...

@teras builds fine for me, try directly cloning and running makepkg -si.

When I try to install this package, I get this error

/tmp/yaourt-tmp-teras/aur-vscodium-bin/./tmp.zpJC22uMc4: line 40: syntax error near unexpected token `('
/tmp/yaourt-tmp-teras/aur-vscodium-bin/./tmp.zpJC22uMc4: line 40: `  cp -r ${srcdir}/!(vscodium-bin.desktop|${pkgname}-${pkgver}.tar.gz) ${pkgdir}/usr/share/${pkgname}'
==> ERROR: Failed to source /tmp/yaourt-tmp-teras/aur-vscodium-bin/./tmp.zpJC22uMc4
Unable to read PKGBUILD

any idea?

Okay, I see. Thanks for letting me know and have a good time with FreeBSD!

I disowned cause I no longer use Arch, I just switched to FreeBSD, before that I was using void so I've been a bit slow before but now I don't even have pacman to test

Does anyone know why @ckatri just updated it to 1.51.0 then disowned? I haven't found a way to contact him about it and ask.

For impatient folk, 1.51.0 builds fine by changing pkgver to 1.51.0, and updating the relevant sha256sum to the upstream one for your architecture.

Please update to 1.51 https://github.com/VSCodium/vscodium/releases/tag/1.51.0

can you please update it to 1.51?

@pryme-svg Thank you!

To set the default file browser back to your original one, run

xdg-mime default nemo.desktop inode/directory

Description: In Manjaro Cinnamon I use Win+E (Super+E) to start Nemo file manager (default). After installing vscodium-bin behaviour changes. Win+E now opens VSCodium. Also click on desktop icon "Home" opens VSCodium. Keyboard settings still say that Win+E shall open file manager application, but it doesn't.

Version: 1.50.1-1, but has also occured earlier

Steps to reproduce: Install vscodium-bin Press Win+E or click desktop icon "Home" -> VSCodium opens

Uninstall vscodium-bin Press Win+E or click desktop icon "Home" -> Nemo file manager opens (default)

With visual-studio-code-bin and visual-studio-code-insiders instead all is fine.

I have an error during installation:

/home/riptor/vscodium-bin/PKGBUILD: line 39: syntax error near unexpected token `('
/home/riptor/vscodium-bin/PKGBUILD: line 39: `  cp -r ${srcdir}/!(vscodium-bin.desktop|${pkgname}-${pkgver}.tar.gz) ${pkgdir}/usr/share/${pkgname}'

There have been aarch64 version in upstream (https://github.com/VSCodium/vscodium/releases/download/1.49.3/VSCodium-linux-arm64-1.49.3.tar.gz), please fix arm64 support, thanks.

Is there any way you can get rid of the visual studio code conflicts? It is sometimes useful to have that downloaded, for example downloading an extension that isn't available for VSCodium (so that I can manually copy over the extension files to VSCodium). The PKGBUILD just needs to be updated to remove the the symlinks for code and then remove the conflicts line (remove lines 23, 36 and 37)

New version out (1.49.3) and you can grab the checksum from the releases page.

Thanks

To be honest, I do not know. I seems that the previous maintainer has abandoned it, so I have taken it over. If they would like it back I'll gladly let them.

Can you tell us what happend?