You are not logged in.

#1 2024-10-13 21:24:19

ectospasm
Member
Registered: 2015-08-28
Posts: 292

[SOLVED]nodejs-fast-cli error (puppeteer dependency not satisfied)

SOLVED:  adding a call to npm install -g --prefix "$pkgdir/usr" puppeteer to the package() function solved it, at least for non-root users.

Original post for posterity:
I'm the maintainer of the AUR package nodejs-fast-cli.  It is a CLI method to speed test against Netflix's https://fast.com, which is the only speedtest my ISP supports (according to the technicians who came by my home after I had complained to the FCC;  not even their own Ookla speedtest server is supported).  It's a really crappy package, depending on puppeteer and Chrome, since it uses Chrome to navigate all the Javascript nonsense to provide a decent-looking CLI output (it can even output to JSON which makes it easy to parse).

I had installed this on several Arch systems previously with no issues, but when I tried to install it today on my Arch Linux router, I get the following when trying to run fast -u (to test download and upload network speeds):

›Could not find Chrome (ver. 127.0.6533.88). This can occur if either
  1. you did not perform an installation before running the script (e.g. `npx puppeteer browsers install chrome`)
 or
  2. your cache path is incorrectly configured (which is: /root/.cache/puppeteer).
 For (2), check out our guide on configuring puppeteer at https://pptr.dev/guides/configuration.

I know very little about Node.js and npm, so I don't know how to modify my PKGBUILD to satisfy this apparent Node.js dependency.  I did see that chromium added the libjpeg-turbo dependency (which is how I built the depends=() array) so I added that to my PKGBUILD (creating pkgrel=2). 

On all the systems where it was installed previously, fast -u still works as intended, even after upgrading for pkgrel=2.  I do not recall installing anything with npx puppeteer..., except possibly when I was first trying to set up my PKGBUILD.

If I remember correctly, I did use nodejs-npm2arch to craft this PKGBUILD originally, do I need to do it again because perhaps the Node.js environment now requires it?  I guess I don't understand then why it isn't working on the other systems where this had already been installed and tested.

The goal of this is to move the regular speed tests I perform to my new router instead of my Arch Linux fileserver (my old Arch Linux router had too little RAM to run chromium comfortably).

Last edited by ectospasm (2024-10-20 03:51:54)

Offline

#2 2024-10-14 09:52:51

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 12,902

Re: [SOLVED]nodejs-fast-cli error (puppeteer dependency not satisfied)

foo-to-arch generators tend to miss many things specific to arch, look at https://wiki.archlinux.org/title/Node.j … guidelines .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#3 2024-10-20 03:47:57

ectospasm
Member
Registered: 2015-08-28
Posts: 292

Re: [SOLVED]nodejs-fast-cli error (puppeteer dependency not satisfied)

Lone_Wolf wrote:

foo-to-arch generators tend to miss many things specific to arch, look at https://wiki.archlinux.org/title/Node.j … guidelines .

I had read this before posting this topic;  but it wasn't obvious to me what I'm missing.  I can try to refactor my PKGBUILD, maybe rebuild it from scratch.  But this seems dependent upon the npm package puppeteer, which itself is depending on finding Chrome somewhere.

Following the actual error message, it looks like on at least one of the other systems I have ~/.cache/puppeteer/chrome/linux-127.0.6533.88.  It's been long enough I do not recall ever installing that, or using puppeteer to install it.

As I was typing this I found the puppeteer README.md in one of the systems that already had it installed.  Adding the following line to the package() function got it working:

   npm install -g --prefix "$pkgdir/usr" puppeteer

The fast -u command now works as a regular, non-root user.  But running it as root still gives the same error.  That's probably just as well, I shouldn't trust root to run this regularly.

Last edited by ectospasm (2024-10-20 03:48:24)

Offline

Board footer

Powered by FluxBB