Build from source under Fedora 42
Describe the bug I am trying to build VSCodium under Fedora by following the Build documentation.
After installing the mentioned dependencies (except for libkrb5 because I cannot find it in Fedora repository), when I run ./dev/build.sh, I get the following error:
npm error code 1
npm error path /home/athena/vscodium/vscode/node_modules/@vscode/deviceid
npm error command failed
npm error command sh -c node-gyp rebuild
I see that as .spec file to build RPM package, you refer to code.spec.template.
Where can I find the values related to @@DEPENDENCIES@@? So I can try to build it in the same manner you do by a spec file with the right dependencies.
Desktop (please complete the following information):
- OS: Fedora 42
- Architecture: x64
Can you give more details of the error?
Sure. I explain you what I do in Fedora by following the documentation.
First install dependencies by:
sudo dnf install -y nodejs20 jq git python3 gcc gcc-c++ make pkgconf libX11-devel libxkbfile-devel libxkbfile-devel libsecret-devel fakeroot krb5-devel rpm rpmbuild
Then I run:
sudo ln -s /usr/bin/node-20 /usr/bin/node
sudo ln -s /usr/bin/npm-20 /usr/bin/npm
sudo ln -s /usr/bin/npx-20 /usr/bin/npx
to force the usage of Node 20 since on the build script I cannot specify the node binary to call.
Finally I run:
./dev/build.sh
UPDATE: after following the next comments, and updated the info above, it works.
~~And the output containing the error is the following:~~
OS_NAME="linux"
SKIP_SOURCE="no"
SKIP_BUILD="no"
SKIP_ASSETS="yes"
VSCODE_ARCH="x64"
VSCODE_LATEST="no"
VSCODE_QUALITY="stable"
Get version from stable.json
RELEASE_VERSION="1.99.32678"
MS_TAG="1.99.3"
MS_COMMIT="17baf841131aa23349f217ca7c570c76ee87b957"
remote: Enumerating objects: 10216, done.
remote: Counting objects: 100% (10216/10216), done.
remote: Compressing objects: 100% (8476/8476), done.
Receiving objects: 100% (10216/10216), 23.07 MiB | 15.48 MiB/s, done.
remote: Total 10216 (delta 1545), reused 4361 (delta 973), pack-reused 0 (from 0)
Resolving deltas: 100% (1545/1545), done.
From https://github.com/Microsoft/vscode
* branch 17baf841131aa23349f217ca7c570c76ee87b957 -> FETCH_HEAD
Note: switching to 'FETCH_HEAD'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 17baf84 bump version for recovery 3 (#246669)
BUILD_SOURCEVERSION="901d0fad8d73e850c69c330dcee92e6dac2c3b68"
++ . version.sh
+++ [[ -z 901d0fad8d73e850c69c330dcee92e6dac2c3b68 ]]
+++ export BUILD_SOURCEVERSION
++ [[ yes == \y\e\s ]]
++ echo 'MS_COMMIT="17baf841131aa23349f217ca7c570c76ee87b957"'
MS_COMMIT="17baf841131aa23349f217ca7c570c76ee87b957"
++ . prepare_vscode.sh
+++ set -e
+++ . ./utils.sh
++++ APP_NAME=VSCodium
+++++ echo VSCodium
+++++ awk '{print tolower($0)}'
++++ APP_NAME_LC=vscodium
++++ BINARY_NAME=codium
++++ GH_REPO_PATH=VSCodium/vscodium
++++ ORG_NAME=VSCodium
++++ exists gsed
++++ type -t gsed
++++ is_gnu_sed
++++ sed --version
+++ [[ stable == \i\n\s\i\d\e\r ]]
+++ cp -rp src/stable/resources src/stable/src vscode/
+++ cp -f LICENSE vscode/LICENSE.txt
+++ cd vscode
+++ ../update_settings.sh
APP_NAME="VSCodium"
APP_NAME_LC="vscodium"
BINARY_NAME="codium"
GH_REPO_PATH="VSCodium/vscodium"
ORG_NAME="VSCodium"
applying patch: ../patches/add-remote-url.patch
applying patch: ../patches/binary-name.patch
applying patch: ../patches/brand.patch
applying patch: ../patches/cli.patch
applying patch: ../patches/disable-cloud.patch
applying patch: ../patches/disable-signature-verification.patch
applying patch: ../patches/extensions-disable-mangler.patch
applying patch: ../patches/ext-from-gh.patch
applying patch: ../patches/feat-announcements.patch
applying patch: ../patches/fix-eol-banner.patch
applying patch: ../patches/fix-remote-libs.patch
applying patch: ../patches/merge-user-product.patch
applying patch: ../patches/optional-tree-sitter.patch
applying patch: ../patches/policies.patch
applying patch: ../patches/remove-mangle.patch
applying patch: ../patches/report-issue.patch
applying patch: ../patches/terminal-suggest.patch
applying patch: ../patches/update-cache-path.patch
applying patch: ../patches/use-github-pat.patch
applying patch: ../patches/version-0-release.patch
applying patch: ../patches/version-1-update.patch
applying patch: ../patches/linux/arch-0-support.patch
applying patch: ../patches/linux/arch-1-ppc64le.patch
applying patch: ../patches/linux/arch-2-riscv64.patch
applying patch: ../patches/linux/arch-3-loong64.patch
applying patch: ../patches/linux/arch-4-s390x.patch
applying patch: ../patches/linux/fix-build.patch
applying patch: ../patches/linux/fix-reh-bootstrap.patch
applying patch: ../patches/linux/rpm.patch
applying patch: ../patches/linux/update-xdg-path.patch
applying patch: ../patches/linux/yarn-dependencies.patch
+++ export ELECTRON_SKIP_BINARY_DOWNLOAD=1
+++ ELECTRON_SKIP_BINARY_DOWNLOAD=1
+++ export PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1
+++ PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1
+++ [[ linux == \l\i\n\u\x ]]
+++ export VSCODE_SKIP_NODE_VERSION_CHECK=1
+++ VSCODE_SKIP_NODE_VERSION_CHECK=1
+++ [[ '' == \a\r\m ]]
+++ mv .npmrc .npmrc.bak
+++ cp ../npmrc .npmrc
+++ for i in {1..5}
+++ [[ no != \n\o ]]
+++ npm ci
npm warn deprecated [email protected]: This package is no longer supported.
npm warn deprecated [email protected]: Please upgrade to v1.0.1
npm warn deprecated [email protected]: Please upgrade to v1.0.1
npm warn deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated [email protected]: Please upgrade to v0.1.5
npm warn deprecated [email protected]: Please upgrade to v0.1.7
npm warn deprecated [email protected]: Please upgrade to v0.1.5
npm warn deprecated [email protected]: Please upgrade to v0.1.7
npm warn deprecated [email protected]: Please upgrade to v0.1.5
npm warn deprecated [email protected]: Please upgrade to v0.1.7
npm warn deprecated [email protected]: Please upgrade to v0.1.5
npm warn deprecated [email protected]: Please upgrade to v0.1.7
npm warn deprecated [email protected]: Please upgrade to v0.1.5
npm warn deprecated [email protected]: Please upgrade to v0.1.7
npm warn deprecated [email protected]: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
npm warn deprecated [email protected]: Rimraf versions prior to v4 are no longer supported
npm warn deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm warn deprecated [email protected]: See https://github.com/lydell/source-map-resolve#deprecated
npm warn deprecated [email protected]: Since the coming of ESLint flat config file, you can specify local rules without the need of this package. For running ESLint rule unit tests, use eslint-rule-tester instead
npm warn deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: See https://github.com/lydell/source-map-resolve#deprecated
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm warn deprecated [email protected]: See https://github.com/lydell/source-map-url#deprecated
npm warn deprecated [email protected]: Please use @electron/asar moving forward. There is no API change, just a package name change
npm warn deprecated [email protected]: Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies
npm warn deprecated [email protected]: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm warn deprecated [email protected]: This package is no longer supported.
npm warn deprecated [email protected]: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.
npm warn deprecated [email protected]: 16.1.1
npm warn cleanup Failed to remove some directories [
npm warn cleanup [
npm warn cleanup '/home/athena/vscodium/vscode/node_modules/native-keymap',
npm warn cleanup [Error: ENOTEMPTY: directory not empty, rmdir '/home/athena/vscodium/vscode/node_modules/native-keymap'] {
npm warn cleanup errno: -39,
npm warn cleanup code: 'ENOTEMPTY',
npm warn cleanup syscall: 'rmdir',
npm warn cleanup path: '/home/athena/vscodium/vscode/node_modules/native-keymap'
npm warn cleanup }
npm warn cleanup ],
npm warn cleanup [
npm warn cleanup '/home/athena/vscodium/vscode/node_modules',
npm warn cleanup [Error: ENOTEMPTY: directory not empty, rmdir '/home/athena/vscodium/vscode/node_modules/native-keymap'] {
npm warn cleanup errno: -39,
npm warn cleanup code: 'ENOTEMPTY',
npm warn cleanup syscall: 'rmdir',
npm warn cleanup path: '/home/athena/vscodium/vscode/node_modules/native-keymap'
npm warn cleanup }
npm warn cleanup ]
npm warn cleanup ]
npm error code 1
npm error path /home/athena/vscodium/vscode/node_modules/kerberos
npm error command failed
npm error command sh -c prebuild-install --runtime napi || node-gyp rebuild
npm error make: Entering directory '/home/athena/vscodium/vscode/node_modules/kerberos/build'
npm error CXX(target) Release/obj.target/kerberos/src/kerberos.o
npm error make: Leaving directory '/home/athena/vscodium/vscode/node_modules/kerberos/build'
npm error gyp info it worked if it ends with ok
npm error gyp info using [email protected]
npm error gyp info using [email protected] | linux | x64
npm error gyp info find Python using Python version 3.13.3 found at "/usr/bin/python3"
npm error gyp info spawn /usr/bin/python3
npm error gyp info spawn args [
npm error gyp info spawn args '/usr/lib/node_modules_20/npm/node_modules/node-gyp/gyp/gyp_main.py',
npm error gyp info spawn args 'binding.gyp',
npm error gyp info spawn args '-f',
npm error gyp info spawn args 'make',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/home/athena/vscodium/vscode/node_modules/kerberos/build/config.gypi',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/usr/lib/node_modules_20/npm/node_modules/node-gyp/addon.gypi',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/home/athena/.cache/node-gyp/20.19.0/include/node/common.gypi',
npm error gyp info spawn args '-Dlibrary=shared_library',
npm error gyp info spawn args '-Dvisibility=default',
npm error gyp info spawn args '-Dnode_root_dir=/home/athena/.cache/node-gyp/20.19.0',
npm error gyp info spawn args '-Dnode_gyp_dir=/usr/lib/node_modules_20/npm/node_modules/node-gyp',
npm error gyp info spawn args '-Dnode_lib_file=/home/athena/.cache/node-gyp/20.19.0/<(target_arch)/node.lib',
npm error gyp info spawn args '-Dmodule_root_dir=/home/athena/vscodium/vscode/node_modules/kerberos',
npm error gyp info spawn args '-Dnode_engine=v8',
npm error gyp info spawn args '--depth=.',
npm error gyp info spawn args '--no-parallel',
npm error gyp info spawn args '--generator-output',
npm error gyp info spawn args 'build',
npm error gyp info spawn args '-Goutput_dir=.'
npm error gyp info spawn args ]
npm error gyp info spawn make
npm error gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
npm error In file included from ../src/kerberos_common.h:5,
npm error from ../src/kerberos.h:13,
npm error from ../src/kerberos.cc:1:
npm error ../src/unix/kerberos_gss.h:21:14: fatal error: gssapi/gssapi.h: No such file or directory
npm error 21 | #include <gssapi/gssapi.h>
npm error | ^~~~~~~~~~~~~~~~~
npm error compilation terminated.
npm error make: *** [kerberos.target.mk:110: Release/obj.target/kerberos/src/kerberos.o] Error 1
npm error gyp ERR! build error
npm error gyp ERR! stack Error: `make` failed with exit code: 2
npm error gyp ERR! stack at ChildProcess.<anonymous> (/usr/lib/node_modules_20/npm/node_modules/node-gyp/lib/build.js:209:23)
npm error gyp ERR! System Linux 6.14.2-300.fc42.x86_64
npm error gyp ERR! command "/usr/bin/node-20" "/usr/lib/node_modules_20/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
npm error gyp ERR! cwd /home/athena/vscodium/vscode/node_modules/kerberos
npm error gyp ERR! node -v v20.19.0
npm error gyp ERR! node-gyp -v v10.1.0
npm error gyp ERR! not ok
npm error A complete log of this run can be found in: /home/athena/.npm/_logs/2025-04-21T12_13_59_454Z-debug-0.log
+++ [[ 1 == 3 ]]
+++ echo 'Npm install failed 1, trying again...'
Npm install failed 1, trying again...
+++ sleep 30
Probably the issue is related to the missing of node-gyp command. In Fedora repository the package node-gyp does not exist, so, how can you create the RPM package without that dependency? Are you using third-party repositories to get node-gyp?
The main error is npm error ../src/unix/kerberos_gss.h:21:14: fatal error: gssapi/gssapi.h: No such file or directory.
It's libkrb5 , do sudo dnf install krb5-devel
It seems it is working, I am just waiting for the end of building process. At the end of this process, VSCodium will be automatically installed or it just create the rpm package and I need to install it manually?
Futhermore, since in Fedora the binary of nodejs20 is not node but node-20, is it possible to implement in build.sh a variable that can be override to specify the node binary? For example:
NODE=/usr/bin/node-20 ./dev/build.sh
?
It seems it is working, I am just waiting for the end of building process. At the end of this process, VSCodium will be automatically installed or it just create the rpm package and I need to install it manually?
By default, only the binary will be created.
Add the option -p to create the packages.
Futhermore, since in Fedora the binary of
nodejs20is notnodebutnode-20, is it possible to implement inbuild.sha variable that can be override to specify the node binary? For example:NODE=/usr/bin/node-20 ./dev/build.sh?
I would recommend you to use nvm to manage the node versions.
I am using COPR to build the package. I don't see nvm package in Fedora sadly.
I am using COPR to build the package. I don't see nvm package in Fedora sadly.
./dev/build.sh's purpose is to develop VSCodium (testing, updating patches), not for building the packages.
For CI build, you should look at either:
- https://github.com/VSCodium/vscodium/blob/master/.github/workflows/stable-linux.yml
- https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vscodium
Most node commands are executed with npm run ...
Not sure what you are doing with COPR...
By COPR I am trying to build a .spec file to create a binary RPM and host it in my RPM repository. I know that you provide RPM binaries, but I hate packaging directly binaries with no building from source (I think it is also a best practice on several Linux community about packaging maintenance).
By the way, I created this VSCodium spec file and, according to the COPR logs, it seems to work as intended. I am just waiting the end of building process to check if actually creates the right package.
I finished the building of VSCodium on COPR for x86_64 and aarch64 targets.
X86_64 builds correctly.
aarch64 (arm64) should have some missing one, probably should it be fixed upstream on the repository?
In particular, aarch64 building process produces the following output:
Reading /builddir/build/BUILD/vscodium-1.99.32562-build/SPECPARTS/rpm-debuginfo.specpart
Processing files: vscodium-1.99.32562-1.fc41.aarch64
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.m6kPJn
+ umask 022
+ cd /builddir/build/BUILD/vscodium-1.99.32562-build
+ cd vscodium-1.99.32562
+ DOCDIR=/builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/doc/vscodium
+ export LC_ALL=C.UTF-8
+ LC_ALL=C.UTF-8
+ export DOCDIR
+ /usr/bin/mkdir -p /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/doc/vscodium
+ cp -pr /builddir/build/BUILD/vscodium-1.99.32562-build/vscodium-1.99.32562/README.md /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/doc/vscodium
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.Fu5dKj
+ umask 022
+ cd /builddir/build/BUILD/vscodium-1.99.32562-build
+ cd vscodium-1.99.32562
+ LICENSEDIR=/builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/licenses/vscodium
+ export LC_ALL=C.UTF-8
+ LC_ALL=C.UTF-8
+ export LICENSEDIR
+ /usr/bin/mkdir -p /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/licenses/vscodium
+ cp -pr /builddir/build/BUILD/vscodium-1.99.32562-build/vscodium-1.99.32562/LICENSE /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/licenses/vscodium
+ RPM_EC=0
++ jobs -p
+ exit 0
error: Missing build-id in /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/vscodium/resources/app/node_modules/@vscode/ripgrep/bin/rg
error: Generating build-id links failed
Entire logs: https://download.copr.fedorainfracloud.org/results/@athenaos/athenaos/fedora-41-aarch64/08949532-vscodium/builder-live.log.gz
Probably it is caused from ripgrep that, for arm64 in VSCodium, is not suitable to run. It runs only for x86_64, or I don't know what could be another cause.
Can you please fix upstream for aarch64 case please @daiyam ?
By the way, I created this VSCodium spec file and, according to the COPR logs, it seems to work as intended. I am just waiting the end of building process to check if actually creates the right package.
I don't recommend the use of ./dev/build.sh (I will have to update the doc), you should use:
. get_repo.sh
. build.sh
as in the AUR
Probably it is caused from
ripgrepthat, for arm64 in VSCodium, is not suitable to run. It runs only for x86_64, or I don't know what could be another cause.Can you please fix upstream for aarch64 case please @daiyam ?
VSCodium ships with the correct rg:
[fedora@fedora bin]$ file rg
rg: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
I try to use the mentioned two bash scripts instead of ./dev/build.sh to check if it solves also the ARM scenario.
In environments using only sh instead of bash (for example minimal Linux environments, like COPR), the calls inside build.sh like . version.sh and . prepare_vscode.sh don't work. These statements work only for bash, not for sh.
For sh, it works if explicitely use . ./version.sh.
Could you please add upstream the needed ./ for all those script calls? Just to make it compatible for all building environments that use sh instead of bash?
Just finished to build. x86_64 works perfectly. On aarch64 (arm64) I still get the same issue:
error: Missing build-id in /builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/vscodium/resources/app/node_modules/@vscode/ripgrep/bin/rg
error: Generating build-id links failed
Entire logs: https://download.copr.fedorainfracloud.org/results/@athenaos/athenaos/fedora-42-aarch64/08949765-vscodium/builder-live.log.gz
@daiyam Can you please test the building on an ARM machine to check if you get the same issue?
Built on Ultramarine (FC40), rg is good.
❯ file VSCode-linux-arm64/resources/app/node_modules/@vscode/ripgrep/bin/rg
VSCode-linux-arm64/resources/app/node_modules/@vscode/ripgrep/bin/rg: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
Can you add a debug line like file VSCode-linux-arm64/resources/app/node_modules/@vscode/ripgrep/bin/rg to see if it's the issue?
About sh/bash, all scripts are bash and use features not available in sh.
About
sh/bash, all scripts arebashand use features not available insh.
Are you sure? I built on a sh environment and tested VSCodium successfully. Which bash feature that are not in sh are you referring to?
@daiyam I investigated more. The file command returns correctly:
/builddir/build/BUILD/vscodium-1.99.32562-build/BUILDROOT/usr/share/vscodium/resources/app/node_modules/@vscode/ripgrep/bin/rg: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
I had a discussion with Fedora team. They said me that the rg binary used by VSCodium during the building, despite it is for aarch64 (ARM), that binary doesn't include a build-id. So I think that I need to extract all the commands used in build.sh and use rg from Fedora package instead of getting it as node module. Is it viable in your opinion?
I had a discussion with Fedora team. They said me that the
rgbinary used by VSCodium during the building, despite it is foraarch64(ARM), that binary doesn't include a build-id. So I think that I need to extract all the commands used inbuild.shand usergfrom Fedora package instead of getting it as node module. Is it viable in your opinion?
For reference, Arch Linux already uses packaged ripgrep for the code package.
https://gitlab.archlinux.org/archlinux/packaging/packages/code/-/blob/main/PKGBUILD?ref_type=heads#L136
I had a discussion with Fedora team. They said me that the
rgbinary used by VSCodium during the building, despite it is foraarch64(ARM), that binary doesn't include a build-id. So I think that I need to extract all the commands used inbuild.shand usergfrom Fedora package instead of getting it as node module. Is it viable in your opinion?
Ok. I didn't know about the Fedora's build-id...
I would recommend you to do as @kxxt have suggested and we also replace that binary on some architectures (https://github.com/VSCodium/vscodium/blob/master/build/linux/riscv64/ripgrep.sh)
Thank you. It works now.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment, and we'll keep it open. If you have any new additional information, please include it with your comment!