[esbuild] Trying to download "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.18.20.tgz" [esbuild] Failed to download "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.18.20.tgz": getaddrinfo EAI_AGAIN registry.npmjs.org /var/tmp/portage/net-misc/sunshine-0.23.1/work/Sunshine-0.23.1/node_modules/esbuild/install.js:275 throw new Error(`Failed to install package "${pkg}"`); ^ Error: Failed to install package "@esbuild/linux-x64" at checkAndPreparePackage (/var/tmp/portage/net-misc/sunshine-0.23.1/work/Sunshine-0.23.1/node_modules/esbuild/install.js:275:15) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome_systemd-20240419-093003 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 18.1.4 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/18 18.1.4 Python 3.11.9 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.77.1 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.10_p7 [openjdk-bin-17] 2) Eclipse Temurin JDK 21.0.2_p13 [openjdk-bin-21] *) Eclipse Temurin JDK 8.402_p06 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm [2] openjdk-bin-17 [3] openjdk-bin-21 The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): [1] php8.1 [2] php8.3 * go version go1.22.2 linux/amd64 HEAD of ::gentoo commit fcf4969c8c66627f7e49313b52a00434e79ab627 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Apr 22 03:19:07 2024 +0000 2024-04-22 03:19:06 UTC emerge -qpvO net-misc/sunshine [ebuild N ] net-misc/sunshine-0.23.1 USE="X libdrm svt-av1 vaapi wayland x265 -cuda -debug -filecaps -trayicon -x264" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext sse sse2 sse3 sse4_1 sse4_2 ssse3 -3dnow -3dnowext -fma4 -xop"
Created attachment 891342 [details] emerge-info.txt
Created attachment 891343 [details] emerge-history.txt
Created attachment 891344 [details] environment
Created attachment 891345 [details] etc.clang.tar.xz
Created attachment 891346 [details] etc.portage.tar.xz
Created attachment 891347 [details] logs.tar.xz
Created attachment 891348 [details] net-misc:sunshine-0.23.1:20240422-035513.log.xz
Created attachment 891349 [details] qlist-info.txt.xz
Created attachment 891350 [details] temp.tar.xz
The old version 0.22.2 on my machine has this problem too. (now, used to be working)
Arrgh. After struggling to find the right method to cache the NPM modules for offline use, it turns out this cache is sensitive to the NPM version being used. Fantastic. I'll see whether there's another way that doesn't involve pinning to specific NPM versions, but I'm not too optimistic.
I've got a plan. Expect a fix soon.
fwiw, I've filed https://github.com/npm/cli/issues/3764 in the past, maybe there is useful info in there.
After downgrading nodejs to `=net-libs/nodejs-20.11.0`, I can merge sunshine without errors.
Just a idea - besides npm there is at least yarn which may be more version-change tolerant in case offline installation.
Yeah, I thought of yarn too as I remembered it helping me with other issues in the past. I initially dismissed it because I didn't want to force upstream to change, but it looks like the syntax is the same, so maybe we could just swap it in. My other plan was to pre-compile the assets and nobble the build by giving npm as /bin/true. Either of those mean adjusting it to use CMake's find_program. This should work out one way or the other, just been short of time this week.
I tried hard to make yarn work, but it's a total pain in its handling of other platforms. Normally, it will insist on caching all 90MB to cover Windows, Android, all the BSDs, etc. You can manually strip out the other platforms from the lockfile and it won't complain, but only if you pass additional arguments, which can only be done via a wrapper in this case. It supports a .yarnrc file and a few environment variables, but these have nowhere near the amount of control required. All in all, it's just not worth the headache. I'll go back to the pre-compiled assets idea.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd44b9aa5c745304ea924fb12b8503bb8ecd9545 commit dd44b9aa5c745304ea924fb12b8503bb8ecd9545 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-05-11 17:44:51 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-05-11 17:44:51 +0000 net-misc/sunshine: Fix NPM issue by shipping pre-compiled assets It turns out the NPM cache is sensitive to the NPM version. Yarn is better in this regard, but it wanted to cache 90MB of files covering irrelevant operating systems and architectures. This is a lot more than 1.3MB of pre-compiled assets. Closes: https://bugs.gentoo.org/930441 Signed-off-by: James Le Cuirot <chewi@gentoo.org> net-misc/sunshine/Manifest | 2 +- net-misc/sunshine/files/sunshine-find-npm.patch | 100 ++++++++++++++++++++++++ net-misc/sunshine/sunshine-0.23.1.ebuild | 16 ++-- net-misc/sunshine/sunshine-9999.ebuild | 16 ++-- 4 files changed, 115 insertions(+), 19 deletions(-)
this error still exists in sunshine-9999 and the patch cannot be used anymore
(In reply to Yuhan Su from comment #19) > this error still exists in sunshine-9999 and the patch cannot be used anymore That's a different issue. 9999 fetches npm modules live, but we possibly need to change npm_config_optional to true. There's another unrelated issue that stops the build that I need to look into though.
