Package Details: vscodium-bin 1.68.1-1

Git Clone URL: (read-only, click to copy)
Package Base: vscodium-bin
Description: Binary releases of VS Code without MS branding/telemetry/licensing.
Upstream URL:
Licenses: MIT
Conflicts: vscodium, vscodium-git
Provides: codium, vscodium
Submitter: ckatri
Maintainer: sperg512 (Icelk)
Last Packager: Icelk
Votes: 155
Popularity: 11.91
First Submitted: 2020-09-23 18:58 (UTC)
Last Updated: 2022-06-16 01:00 (UTC)

Pinned Comments

sperg512 commented on 2021-05-12 00:31 (UTC)

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

Latest Comments

Ashark commented on 2022-07-05 23:23 (UTC)

Can you please add vscode to provides array? See

jplatte commented on 2022-04-01 12:20 (UTC)

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?

sperg512 commented on 2022-02-10 23:12 (UTC)

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

Icelk commented on 2022-02-01 10:27 (UTC)

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.

ajgringo619 commented on 2022-01-31 22:51 (UTC) (edited on 2022-01-31 22:52 (UTC) by ajgringo619)

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)

Icelk commented on 2022-01-31 20:51 (UTC)

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

Gigas002 commented on 2022-01-31 20:32 (UTC)

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.

ZorinArch commented on 2021-12-22 13:53 (UTC)

@Icelk Thanks,

Icelk commented on 2021-12-22 13:29 (UTC)

@ZorinArch Done!

ZorinArch commented on 2021-12-22 13:25 (UTC)

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

KDN_Observer commented on 2021-12-21 21:27 (UTC)

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

Icelk commented on 2021-12-21 17:59 (UTC)

@macxcool Is it working now?

macxcool commented on 2021-12-21 16:31 (UTC)

(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

Icelk commented on 2021-12-21 07:28 (UTC)

@KDN_Observer Can you confirm it works as expected now?

Icelk commented on 2021-12-21 07:21 (UTC)

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

KDN_Observer commented on 2021-12-21 01:26 (UTC)

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

Icelk commented on 2021-12-18 10:21 (UTC)


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

Ashark commented on 2021-12-17 13:37 (UTC)

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.

Icelk commented on 2021-12-17 10:14 (UTC)


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

KDN_Observer commented on 2021-12-10 07:27 (UTC)

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

Icelk commented on 2021-11-27 12:37 (UTC)

@animo Are the checksums good now?

Icelk commented on 2021-11-27 12:37 (UTC)

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

livem commented on 2021-11-26 21:27 (UTC)

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

indicozy commented on 2021-11-26 20:47 (UTC) (edited on 2021-11-26 20:47 (UTC) by indicozy)

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?

animo commented on 2021-11-15 20:39 (UTC)

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

Icelk commented on 2021-11-07 12:25 (UTC)

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.

3y3p4tch commented on 2021-11-06 05:32 (UTC)

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)

Icelk commented on 2021-10-27 17:48 (UTC)

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

sperg512 commented on 2021-10-27 16:16 (UTC)

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

willemw commented on 2021-10-26 19:38 (UTC) (edited on 2021-10-27 06:40 (UTC) by willemw)

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

Icelk commented on 2021-10-26 19:18 (UTC)

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


willemw commented on 2021-10-26 19:07 (UTC)

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

Icelk commented on 2021-10-26 19:04 (UTC)

@willemw So what do you propose we do?

willemw commented on 2021-10-26 19:02 (UTC) (edited on 2021-10-26 20:28 (UTC) by willemw)

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]:

Icelk commented on 2021-10-26 18:56 (UTC)

@willemw Thanks. It should now be fixed.

willemw commented on 2021-10-26 18:48 (UTC)


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.

Icelk commented on 2021-10-26 17:30 (UTC)

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.

Ashark commented on 2021-10-26 17:15 (UTC)

Edit pkgbuild as follows:




gameslayer commented on 2021-10-26 17:03 (UTC)

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().

galvez_65 commented on 2021-10-26 16:49 (UTC)

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

willemw commented on 2021-10-26 16:45 (UTC)

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

Ashark commented on 2021-10-26 16:39 (UTC) (edited on 2021-10-26 16:40 (UTC) by Ashark)

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

wooque commented on 2021-10-26 16:28 (UTC)

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().
 -> error making: vscodium-bin

Icelk commented on 2021-10-26 16:24 (UTC)

@Ashark The desktop file is now included.

Icelk commented on 2021-10-26 16:22 (UTC)

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

willemw commented on 2021-10-26 12:43 (UTC)

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

Icelk commented on 2021-10-20 06:36 (UTC)

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

Ashark commented on 2021-10-16 17:24 (UTC)

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

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 Click green clone button, and at the end of the list you will see "Open in your IDE" Visual Studio Code SSH and HTTPS.

zoorat commented on 2021-10-16 02:08 (UTC)

@sperg512 ok.

sperg512 commented on 2021-10-15 01:05 (UTC)

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

zoorat commented on 2021-10-15 00:35 (UTC)

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

sperg512 commented on 2021-10-11 13:24 (UTC)

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

ludvigHz commented on 2021-10-11 11:50 (UTC)

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.

Icelk commented on 2021-09-27 06:14 (UTC)

@lunaryorn The update is pushed.

Icelk commented on 2021-09-27 06:12 (UTC)

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

lunaryorn commented on 2021-09-24 08:57 (UTC)

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 :)

pgray commented on 2021-09-20 04:07 (UTC) (edited on 2021-09-20 04:08 (UTC) by pgray)

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

It built cleanly after.

gameslayer commented on 2021-09-17 14:13 (UTC) (edited on 2021-09-17 14:13 (UTC) by gameslayer)

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

gameslayer commented on 2021-09-17 14:12 (UTC)

Glad to help @Icelk!

Icelk commented on 2021-09-17 05:13 (UTC)

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

chovy commented on 2021-09-17 05:04 (UTC)

@gameslayer how did you clean the cache?

chovy commented on 2021-09-17 05:03 (UTC)

==> 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

Icelk commented on 2021-09-17 03:50 (UTC)

@ganeslayer Thank for letting us know.

gameslayer commented on 2021-09-17 01:09 (UTC)

Yep clearing the cache fixed it, thanks

Icelk commented on 2021-09-16 07:35 (UTC)

The hash in the PKGBUILD is the same as, the hash validating the download. It's a problem with VS Codium's build process. Try clearing the package cache.

gameslayer commented on 2021-09-16 07:26 (UTC)

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

wooque commented on 2021-09-16 07:20 (UTC) (edited on 2021-09-16 07:22 (UTC) by wooque)

==> 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!

Icelk commented on 2021-09-16 05:58 (UTC)

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

GNQG commented on 2021-09-15 23:16 (UTC)

The checksum for x86_64 seems incorrect too.

gurustave commented on 2021-09-14 19:12 (UTC)

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

Icelk commented on 2021-09-14 18:55 (UTC)

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

gurustave commented on 2021-09-14 13:38 (UTC) (edited on 2021-09-14 13:38 (UTC) by gurustave)

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

Icelk commented on 2021-09-14 04:55 (UTC)

@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

gurustave commented on 2021-09-13 15:29 (UTC)

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.

sperg512 commented on 2021-05-12 00:31 (UTC)

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

macxcool commented on 2021-04-02 17:21 (UTC)

Better. Thanks.

sperg512 commented on 2021-04-02 16:52 (UTC)

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

macxcool commented on 2021-04-02 14:50 (UTC)

I tried it again after Marketplace upgraded. Same problem.

macxcool commented on 2021-04-02 14:45 (UTC) (edited on 2021-04-02 14:50 (UTC) by macxcool)

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

sperg512 commented on 2021-04-02 01:40 (UTC)

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

macxcool commented on 2021-04-02 01:39 (UTC) (edited on 2021-04-02 01:41 (UTC) by macxcool)

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

sperg512 commented on 2021-03-13 14:22 (UTC)

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

nimaipatel commented on 2021-03-07 13:46 (UTC)

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

sperg512 commented on 2020-12-20 01:33 (UTC)

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

zaandoff commented on 2020-12-20 01:17 (UTC)

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


zaandoff commented on 2020-12-19 22:45 (UTC)

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.

cradcore commented on 2020-12-19 22:33 (UTC) (edited on 2020-12-19 22:34 (UTC) by cradcore)

@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 :)

teras commented on 2020-12-19 12:17 (UTC)

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

lkrms commented on 2020-12-19 10:52 (UTC)

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

teras commented on 2020-12-19 08:36 (UTC)

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

lkrms commented on 2020-12-19 04:05 (UTC)

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 :)

sperg512 commented on 2020-12-17 18:27 (UTC)

@cradcore removed, thanks

sperg512 commented on 2020-12-17 18:22 (UTC)

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

pryme-svg commented on 2020-12-17 18:18 (UTC)

1.52.1 has been released upstream

cradcore commented on 2020-12-16 15:44 (UTC) (edited on 2020-12-16 15:46 (UTC) by cradcore)

@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

sperg512 commented on 2020-12-14 19:01 (UTC)

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

cradcore commented on 2020-12-14 19:00 (UTC) (edited on 2020-12-16 15:44 (UTC) by cradcore)

@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

sperg512 commented on 2020-12-14 18:58 (UTC)


sperg512 commented on 2020-11-29 23:50 (UTC)

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

teras commented on 2020-11-29 23:04 (UTC)

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

sperg512 commented on 2020-11-29 22:25 (UTC)

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

teras commented on 2020-11-29 10:33 (UTC)

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?

sperg512 commented on 2020-11-14 16:01 (UTC)

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

ckatri commented on 2020-11-14 12:44 (UTC)

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

sperg512 commented on 2020-11-14 09:27 (UTC)

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.

caliberspoon commented on 2020-11-11 22:28 (UTC) (edited on 2020-11-11 22:29 (UTC) by caliberspoon)

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.

pryme-svg commented on 2020-11-08 22:58 (UTC)

Please update to 1.51

jwtiyar commented on 2020-11-08 09:54 (UTC)

can you please update it to 1.51?

sinon commented on 2020-11-06 20:09 (UTC)

@pryme-svg Thank you!

pryme-svg commented on 2020-11-06 16:01 (UTC)

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

xdg-mime default nemo.desktop inode/directory

sinon commented on 2020-10-17 08:44 (UTC)

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.

Riptor commented on 2020-10-10 19:28 (UTC) (edited on 2020-10-10 19:34 (UTC) by Riptor)

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}'
shopt -s extglob in line 34 does not work correctly?

ZhangHua commented on 2020-10-08 05:14 (UTC)

There have been aarch64 version in upstream (, please fix arm64 support, thanks.

cradcore commented on 2020-10-07 13:11 (UTC) (edited on 2020-10-07 13:13 (UTC) by cradcore)

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)

jakedacatman commented on 2020-10-03 17:02 (UTC)

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

Tharbad commented on 2020-09-23 19:30 (UTC)


ckatri commented on 2020-09-23 19:28 (UTC)

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.

Tharbad commented on 2020-09-23 19:25 (UTC)

Can you tell us what happend?