app-editors/vscode: line 3156: ulimit: open files: cannot modify limit: Operation not permitted

[F3llFr0mTh3Sky]

I was trying to emerge app-editors/vscode-1.93.1::pf4public but it stalled for a long time, when I took a look at the logs, I noticed there was an error related to ulimit. So I then tried to build by using the ebuild command and it seems to have failed because the ulimit wasn't set correctly, here's the full logs:

ebuild_logs.txt

I'm using gentoo with openrc, I'm not using systemd.

p.s.:
I was also wondering if you planned to update the vscode ebuild to 1.94.2 and 1.95.1

[F3llFr0mTh3Sky]

I rebooted my PC, opened the terminal, set manually ulimit -n $((8192*2)), and then I tried to build vscode from source again, but it's stuck on that since two hours:
ebuild_logs2.txt

[PF4Public]

the ulimit wasn't set correctly

Correct, that is an issue I have no idea how to fix didn't fix. The simplest solutions is indeed to manually alter the ulimit.

I was also wondering if you planned to update the vscode ebuild to 1.94.2 and 1.95.1

If you were monitoring this repo, you might've noticed me mentioning my limited internet access and computing power available, which makes some activities really difficult. No time estimates for now, sorry. You could've also noticed #377. Fortunately @Kawanaao took the initiative and working on it here: #384

but it's stuck on that since two hours

Is your hardware OK? Any OOMs in dmesg? That step shouldn't take that long. Have you tried restarting the build?

[F3llFr0mTh3Sky]

Sorry for the late answer, I didn't notice you replied to me.

If you were monitoring this repo [...]

I wasn't monitoring it, but I did have been using other of your ebuilds that did work perfectly (element-web-1.11.83, element-desktop-1.11.83, ungoogled-chromium. All of those even did build correctly on an old computer from 2012

but it's stuck on that since two hours

Is your hardware OK? Any OOMs in dmesg? That step shouldn't take that long. Have you tried restarting the build?

My hardware is fine. No OOMs in dmesg, everything else build perfectly. I tried to restart the build three times afterwards, and I always got stuck at the same step. I was building vscode on an ASUS laptop that has 16 Gb of DDR4 as well as a 16 cores AMD Ryzen 7 4800H CPU. I was using -j8.

[PF4Public]

Which version of electron are you using for the build?

[F3llFr0mTh3Sky]

electron-31, I chose that one since it was the one used by all of my other electron based packages.

edit:
I don't think it should have any impact on the installation of yarn packages.

[PF4Public]

You'll have to provide more information than that without me requesting it from you bit by bit. I won't be able to help you otherwise. If you really want to find the culprit, you'll have to provide everything you have without me trying to guess it.

Good candidates were: your USE flags for vscode and electron, full build.log as it is generated by portage in temp folder, emerge --info might be valuable, are you building electron from this overlay or are you using something else. Anything could help, I just cannot guess what exactly.

[F3llFr0mTh3Sky]

Ok, sorry.
There you go:
vscode use flags (all I changed is the electron version):

tux ~ # 
emerge --verbose --pretend =app-editors/vscode-1.93.1::pf4public

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.22 s (backtrack: 0/20).

[ebuild  N     ] sys-apps/ripgrep-14.1.1::gentoo  USE="pcre -debug" 0 KiB
[ebuild  N    #] app-editors/vscode-1.93.1::pf4public  USE="electron-31 -api-proposals -badge-providers -build-online -electron-27 -electron-28 -electron-29 -electron-32 -openvsx -reh -reh-web -substitute-urls -temp-fix" 0 KiB

Total: 2 packages (2 new), Size of downloads: 0 KiB

 * IMPORTANT: 1 news items need reading for repository 'src_prepare-overlay'.
 * IMPORTANT: 8 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

electron use flags:

tux ~ # 
emerge --verbose --pretend --oneshot =dev-util/electron-31.7.3::pf4public

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.81 s (backtrack: 0/20).

[ebuild   R   #] dev-util/electron-31.7.3:31/7.3::pf4public  USE="X bluetooth clang cups hevc proprietary-codecs pulseaudio system-crc32c system-double-conversion system-ffmpeg system-harfbuzz system-icu system-jsoncpp system-libevent system-libusb system-openh264 system-openjpeg system-png system-snappy system-woff2 system-zstd ungoogled -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -kerberos -libcxx -nvidia -optimize-thinlto -optimize-webui -pax-kernel -pgo -screencast (-selinux) -system-abseil-cpp -system-av1 -system-brotli -system-libvpx -system-re2 -thinlto -vaapi -wayland" L10N="fr -af -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -ur -vi -zh-CN -zh-TW" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

 * IMPORTANT: 1 news items need reading for repository 'src_prepare-overlay'.
 * IMPORTANT: 8 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

So I enabled a lot of system- USE flags. For making electron work with system-ffmpeg, I did applied a patch I found in another bug report of this overlay.
#309
that one: https://github.com/bashonly/ffmpeg-bashonly/raw/refs/heads/master/01-add-av_stream_get_first_dts-for-chromium.patch
The only system- USE flags that I let disabled where the ones that caused me trouble.

full build.log as it is generated by portage in temp folder

Here's the one (colored) for app-editors/vscode-1.93.1::pf4public up to the moment it get stuck:
build.log

emerge --info:
emerge_info.txt

Also, all my system packages are up to date.

are you building electron from this overlay [...]

Yes I am.

[PF4Public]

Hmm, I just don't see anything suspicious. Try building with temp-fix.

[F3llFr0mTh3Sky]

I guess temp-fix did the trick, that or less probably using ulimit -n $((8192*4)).
The logs:
build.log

[PF4Public]

Does it work though? :D If it does, I'd be tending to mark this issue as resolved

[F3llFr0mTh3Sky]

Yes it worked. The compilation and installation phase worked.

[PF4Public]

I meant if vscode itself works

[F3llFr0mTh3Sky]

I didn't try it yet.

[F3llFr0mTh3Sky]

Ok, so when I launch code-oss, the windows open, with the grey background, and then it instantly crashes.

[PF4Public]

I'm still not in the mood of playing the guessing game :-/

#372

[F3llFr0mTh3Sky]

Here's the output of code-oss --wait --verbose > /home/calico/Bureau/failure.txt:
failure.txt

No messages in dmesg.

[F3llFr0mTh3Sky]

I'll try to rebuild electron with the same glibcxx-assertions as he used.

[F3llFr0mTh3Sky]

Ok, so disabling "glibcxx-assertions" for electron did work.
Now, you could close the issue.
Thanks a lot for the help.

p.s.:
Do you think it would be doable to remove the telemetry code of Code-OSS completely through a patch instead of just disabling it by default?

[PF4Public]

Do you think it would be doable to remove the telemetry code of Code-OSS completely through a patch instead of just disabling it by default?

gentoo-overlay/app-editors/vscode/metadata.xml

Line 36 in 02bb24f

<flag name="substitute-urls">Even though telemetry is disabled by default in this ebuild, one might want to replace telemetry reporting urls with 0.0.0.0</flag>