bug#56971: greeter user permissions are not enough to talk with seatd
Hi, As per discussion here: https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00020.html Above change reduced permissions of greeter user. While it is ok for greeters that do not talk to seatd, greeters talking to seatd lost access to seatd socket. As result, greeter (e.g. gtkgreet) requiring communication with seatd is failing to start, causing "black screen" behavior on active terminal (switching to the other non seatd related terminal is possible, for manual permissions adjustment as workaround). To address this issue, we need more flexible control over seatd user/group, which creates seatd.sock, and greeter user which connects to seatd.sock. Other distros (Arch for instance) introduced "seat" group. So user which wants to login on system controlled by seatd should be member of that group. However, not all greeters require that, so I decided to make more flexible. Propsed solutions consists of: * 56690 - gnu: seatd-service-type: Should use seat group. With this change, if seatd-service-type is present in the system configuration, "seat" group will be added, and seatd will run as root/seat. Group is configurable, but default is "seat". * 56699 - gnu: greetd-service-type: Add greeter-extra-groups config field. With this change, if user wants to use seatd-service-type with greeter requiring seatd.sock, he can add "seat" group to greeter-extra-groups field. Thanks in advance, muradm signature.asc Description: PGP signature
bug#56971: greeter user permissions are not enough to talk with seatd
Liliana Marie Prikler writes: block 56971 by 56690 56699 thanks Hi muradm, Hi Liliana, Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm: [...] greeter (e.g. gtkgreet) requiring communication with seatd is failing to start, causing "black screen" behavior on active terminal (switching to the other non seatd related terminal is possible, for manual permissions adjustment as workaround). To address this issue, we need more flexible control over seatd user/group, which creates seatd.sock, and greeter user which connects to seatd.sock. Okay. However, not all greeters require that, so I decided to make more flexible. Flexibility for its own sake is not always the right solution. On the other hand, looking at the two patches, it appears they are to be used in combination? No, technically they are not strongly dependent on each other, could be applied one after another in no particular order. After both are applied, in cooperation they address this issue. Propsed solutions consists of: * 56690 - gnu: seatd-service-type: Should use seat group. With this change, if seatd-service-type is present in the system configuration, "seat" group will be added, and seatd will run as root/seat. Group is configurable, but default is "seat". Why just the group and no user? Is it not possible to launch seatd as non-root? seatd provides a way for display servers to access input/output devices without having to be root. So seatd it self has to run as root. When seatd opening socket as root/seat, all members of seat would be able to communicate with it. Also socket could be opened with seat/seat for instance, but there is no specific point in doing so. Will be one more unused system user around. Arch seems to follow similar way, root/seat is ok for socket. Also will signal that seatd is running as root. * 56699 - gnu: greetd-service-type: Add greeter-extra-groups config field. With this change, if user wants to use seatd-service-type with greeter requiring seatd.sock, he can add "seat" group to greeter-extra-groups field. Note that you still have a TODO on that patch. That TODO is from the initial commit, it is about cgroup file system mounting, and totally out of scope of this issue. Cheers Thanks in advance signature.asc Description: PGP signature
bug#56971: greeter user permissions are not enough to talk with seatd
Liliana Marie Prikler writes: Am Donnerstag, dem 04.08.2022 um 15:52 +0300 schrieb muradm: Liliana Marie Prikler writes: > [...] [L]ooking at the two patches, it appears they are to > be used in combination? > No, technically they are not strongly dependent on each other, could be applied one after another in no particular order. After both are applied, in cooperation they address this issue. This is what I'm saying, albeit in different words. As far as I understand, neither of these patches really accomplishes anything if not put together. Thus, you more or less opened three issues to address one. Really I don't know what to comment here else. My analysis showed two independent issues, one is that seatd should have a declared group so that users of it could join it. This issues is not specific to greetd/greeter in any way. Any other greeting mechanism could fall short on this. And second, greeter today required conditional group to interact with seatd, or it could be any other group like input, usb, modem or else depending on user setup. Solutions are offered accordingly. Third issue, this bug I was asked to open. I don't understand, is it a sin to have multiple issues, or what is the problem here? > seatd it self has to run as root. Okay. That TODO is from the initial commit, it is about cgroup file system mounting, and totally out of scope of this issue. I didn't mean your code, I meant a suggestion from a reviewer that you haven't addressed yet (to my knowledge at least). done Cheers signature.asc Description: PGP signature
bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.
* gnu/packages/linux.scm (make-linux-libre*)[arguments]: Remove unnecessary let clause in 'configure phase. --- gnu/packages/linux.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index f4880f164c..ee6e592183 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -852,8 +852,7 @@ (define* (make-linux-libre* version gnu-revision source supported-systems #$(and extra-version (string-append "-" extra-version))) - (let ((build (assoc-ref %standard-phases 'build)) - (config (assoc-ref inputs "kconfig"))) + (let ((config (assoc-ref inputs "kconfig"))) ;; Use a custom kernel configuration file or a default ;; configuration file. -- 2.37.2
bug#57748: swaylock broken since last commit
Hi, swaylock needs wayland-protocols-next in native inputs to compile. wayland-protocols is 1.23, but new swaylock wants >= 1.25 Thanks in advance, muradm signature.asc Description: PGP signature
bug#49771: conflicting pam-limits-service and pam-mount-service-type
pam-limits-service and pam-mount-service-type are working when
used only one of them. When both are present in list of (services,
conflict hapens when guix system reconfigure is invoked. Digging
the problem led to use of etc-service-type.
pam-limits-service defines /etc/security/limits.conf in
gnu/services/base.scm:
(define pam-limits-service-type
(let ((security-limits
;; Create /etc/security containing the provided
"limits.conf" file.
(lambda (limits-file)
`(("security"
,(computed-file
"security"
#~(begin
(mkdir #$output)
(stat #$limits-file)
(symlink #$limits-file
(string-append #$output "/limits.conf"
(pam-extension
(lambda (pam)
Basically, it says to etc-service-type i need "security" under
"/etc" and uses mkdir to create it.
pam-mount-service-type asks "security/pam_mount.conf.xml" from
etc-service-type.
(define (pam-mount-etc-service config)
`(("security/pam_mount.conf.xml"
,(make-pam-mount-configuration-file config
When both pam-mount-service-type and pam-limits-service are
defined in (services ...), if pam-mount-service-type is before
pam-limits, guix system reconfigure fails with "Permission
denied", if pam-limits is before then it is "File exists".
I would suggest to fix gnu/services/base.scm so that
pam-limits-services-type ask for "security/limits.conf" just like
pam-mount-services-type does in order to avoid conflict.
Currently, both pam-limits-service and pam-mount-service-type are
not usable at the same time.
bug#50193: guix: shepherd pid 1 holds /dev/console
On IRC chat we identified an issue related to linux SAK, which is explained here https://www.kernel.org/doc/html/latest/security/sak.html Following the check what processes will be SAK'ed: ~# ls -l /proc/[0-9]*/fd/* | grep console lrwx-- 1 root root 64 Aug 24 21:22 /proc/1/fd/1 -> /dev/console lrwx-- 1 root root 64 Aug 24 21:22 /proc/1/fd/2 -> /dev/console l-wx-- 1 root root 64 Aug 24 21:22 /proc/578/fd/4 -> /dev/console lrwx-- 1 root root 64 Aug 24 21:22 /proc/593/fd/1 -> /dev/console lrwx-- 1 root root 64 Aug 24 21:22 /proc/593/fd/2 -> /dev/console lrwx-- 1 root root 64 Aug 24 20:03 /proc/705/fd/1 -> /dev/console lrwx-- 1 root root 64 Aug 24 20:03 /proc/705/fd/2 -> /dev/console lrwx-- 1 root root 64 Aug 24 21:22 /proc/909/fd/1 -> /dev/console lrwx-- 1 root root 64 Aug 24 21:22 /proc/909/fd/2 -> /dev/console As it is seen from above output, pid 1 which is shepherd holds /dev/console making linux SAK feature useless. When SAK command issued by shortcut keys, all above proceses gets killed including pid 1 which is shepherd, causing system to stall.
bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation
---
gnu/packages/java.scm | 3 +-
.../patches/classpath-instruction-order.patch | 35 +++
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/classpath-instruction-order.patch
diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 08ef7a8213..1e29cac401 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -230,7 +230,8 @@ only faster.")
(sha256
(base32
"0i99wf9xd3hw1sj2sazychb9prx8nadxh2clgvk3zlmb28v0jbfz"))
- (patches (search-patches "classpath-aarch64-support.patch"
+ (patches (search-patches "classpath-aarch64-support.patch"
+ "classpath-instruction-order.patch"
(build-system gnu-build-system)
(arguments
`(#:configure-flags
diff --git a/gnu/packages/patches/classpath-instruction-order.patch
b/gnu/packages/patches/classpath-instruction-order.patch
new file mode 100644
index 00..278ae912c7
--- /dev/null
+++ b/gnu/packages/patches/classpath-instruction-order.patch
@@ -0,0 +1,35 @@
+diff -ruN ../classpath/classpath-0.93/native/jni/java-io/java_io_VMFile.c
./native/jni/java-io/java_io_VMFile.c
+--- ../classpath/classpath-0.93/native/jni/java-io/java_io_VMFile.c
2006-09-23 08:17:45.0 +0300
./native/jni/java-io/java_io_VMFile.c 2021-09-03 01:08:17.073644627
+0300
+@@ -278,6 +278,7 @@
+ const char *filename;
+ int result;
+ jint entryType;
++ int fres;
+
+ /* Don't use the JCL convert function because it throws an exception
+ on failure */
+@@ -288,9 +289,22 @@
+ }
+
+ result = cpio_checkType (filename, &entryType);
++
++ fres = 1;
++
++ if (result != CPNATIVE_OK)
++{
++ fres = 0;
++}
++
++ if (entryType != CPFILE_FILE)
++{
++ fres = 0;
++}
++
+ (*env)->ReleaseStringUTFChars (env, name, filename);
+
+- return result == CPNATIVE_OK && entryType == CPFILE_FILE ? 1 : 0;
++ return fres;
+ #else /* not WITHOUT_FILESYSTEM */
+ return 0;
+ #endif /* not WITHOUT_FILESYSTEM */
--
2.33.0
bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation
This patch fixes issue in the way that it: a) calculates the result before call to (*env)->ReleaseStringUTFChars b) attempt to trick gcc optimizations by complicating path I suppose issue is with what (*env)->ReleaseStringUTFChars does and how. One should note that similar approach is not applicable to substitute in package definition. Why not just build ancient code with ancient gcc?
bug#44898: [wishlist] Make the GRUB installation procedure smarter
First I was using Guix on Lenovo Carbon X1 in parallel with Arch. Few times I experiences "NVRAM full" or similar problem, I don't recall now. Solution was to reset NVRAM by some procedure. Half a year now, I moved to System76 Lemur Pro, where I have only Guix alone. Here I have another problem, sometimes it simply does not boot, then I have to plug USB, and run grub-install manually to recover. As per discussion on IRC today, I would suggest the folowing regarding grub efi, I'm not using other bootloaders, but I suppose same logic may apply. There are two things about grub: 1) /boot/efi/EFI/Guix/grubx64.efi & NVRAM - these are changing very very rarely, only when grub version change, boot partition change. 2) /boot/grub/* - these are changing only when grub version change or new guix generation is created, then grub.cfg is getting updated. Currently, as far as I understand, both of them are getting installed with one script from this derivation: /gnu/store/...-install-bootloader.scm.drv It could be split into two, one which runs grub-install, i.e. #1 above, the other which covers #2 above, let's say bootloader-phase-1-install and bootloader-phase-2-install respectively. Then, each script can be executed only when derivation is changing. With the following exceptions: - must be executed anyway on "guix system init ..." - must be executed only if "guix system reconfigure --force-bootloader ..." Scripts them selves store grub version (via absolute path), thus if grub updated, derivations will change. If for some reason, grub and/or nvram getting broken on boot, user has to boot with some kind recovery media anyway.
bug#50604: [core-updates-frozen] make check-system tests broken
Hi, Currently execution of any system tests with "make check-system ..." seems to be broken. Tests are getting executed, and their status is "pass" in the log. But, some in some place around the test execution, below exception is fired. --8<---cut here---start->8--- This is the GNU system. Welcome. komputilo login: shepherd: changing HTTP/HTTPS proxy of 'guix-daemon' to "http://localhost:8118";... shepherd: Service guix-daemon has been stopped. shepherd: Service guix-daemon has been started. shepherd: clearing HTTP/HTTPS proxy of 'guix-daemon'... shepherd: Service guix-daemon has been stopped. shepherd: Service guix-daemon has been started. Backtrace: 4 (primitive-load "/gnu/store/638i01a9gj6zknrcyp78n9pc434?") In ice-9/eval.scm: 191:35 3 (_ #f) 196:35 2 (_ #f) 263:9 1 (_ #(#(#) #f)) 155:9 0 (_ _) ice-9/eval.scm:155:9: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f QEMU runs as PID 10 connected to QEMU's monitor read QEMU monitor prompt connected to guest REPL Starting test basic (Writing full log to "basic.log") marionette is ready ;;; (services (console-font-tty2 user-homes mcron term-tty4 udev term-tty2 syslogd console-font-tty5 user-processes console-font-tty6 file-system-/sys/firmware/efi/efivars loopback) # of expected passes 27 # of skipped tests1 note: keeping build directory `/tmp/guix-build-basic.drv-1' builder for `/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed with exit code 1 build of /gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv failed View build log at '/var/log/guix/drvs/2r/k2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv.bz2'. guix build: error: build of `/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed make: *** [Makefile:7039: check-system] Error 1 --8<---cut here---end--->8--- Thanks in advance, muradm
bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication
Could you please elaborate more on "loop on authenticating my user" from above and "prevents users from authenticating" from commit message? Does it mean that you could not authenticate as your user at all, or does it relates to authentication at http://localhost:631 for managing printers? signature.asc Description: PGP signature
bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication
This change broke cups for me like this: --8<---cut here---start->8--- I [13/May/2023:16:14:27 +0300] [Client 16] Started "/gnu/store/9kdm8k84j2xqlax4zaarchw00cfs62zz-cups-server-bin/lib/cups/daemon/cups-deviced" (pid=21409, file=14) E [13/May/2023:16:14:27 +0300] [CGI] cups-brf must be called as root E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21419 (cups-brf) stopped with status 1! E [13/May/2023:16:14:27 +0300] [CGI] Unable to execute ippfind utility: No such file or directory E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21421 (driverless-fax) stopped with status 127! --8<---cut here---end--->8--- cups-minimal does not include ippfind utility. Normally, user whishing to use cups, should be in lp group, isn't it? Maybe that was your original issue? muradm writes: [[PGP Signed Part:Undecided]] Could you please elaborate more on "loop on authenticating my user" from above and "prevents users from authenticating" from commit message? Does it mean that you could not authenticate as your user at all, or does it relates to authentication at http://localhost:631 for managing printers? [[End of PGP Signed Part]] signature.asc Description: PGP signature
bug#63198: [PATCH] services: cups: Add cups PAM service.
Fixes <https://issues.guix.gnu.org/63198>. Makes CUPS service to extend pam-root-service-type providing minimal configuration to authenticate users. Since PAM authentication is provided, cups package can be used as default. * gnu/services/cups.scm (cups-configuration) [cups]: Use cups. [allow-empty-password?]: PAM service configuration permitting empty passwords. (opaque-cups-configuration): Likewise. (cups-pam-service): cups PAM service. (cups-service-type): Extend pam-root-service-type with cups-pam-service. --- gnu/services/cups.scm | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/gnu/services/cups.scm b/gnu/services/cups.scm index c6099d77e7..d95c38b4d9 100644 --- a/gnu/services/cups.scm +++ b/gnu/services/cups.scm @@ -5,6 +5,7 @@ ;;; Copyright © 2019 Alex Griffin ;;; Copyright © 2019 Tobias Geerinckx-Rice ;;; Copyright © 2021 Maxime Devos +;;; Copyright © 2023 muradm ;;; ;;; This file is part of GNU Guix. ;;; @@ -25,6 +26,7 @@ (define-module (gnu services cups) #:use-module (gnu services) #:use-module (gnu services shepherd) #:use-module (gnu services configuration) + #:use-module (gnu system pam) #:use-module (gnu system shadow) #:use-module (gnu packages admin) #:use-module (gnu packages cups) @@ -500,8 +502,11 @@ (define (serialize-package-list field-name val) (define-configuration cups-configuration (cups - (file-like cups-minimal) + (file-like cups) "The CUPS package.") + (allow-empty-password? + (boolean #f) + "Specifies whether empty passwords will be allowed when authenticating via PAM.") (extensions (package-list (list brlaser cups-filters epson-inkjet-printer-escpr foomatic-filters hplip-minimal splix)) @@ -841,8 +846,11 @@ (define-configuration cups-configuration (define-configuration opaque-cups-configuration (cups - (package cups-minimal) + (package cups) "The CUPS package.") + (allow-empty-password? + (boolean #f) + "Specifies whether empty passwords will be allowed when authenticating via PAM.") (extensions (package-list '()) "Drivers and other extensions to the CUPS package.") @@ -1006,6 +1014,14 @@ (define (cups-shepherd-service config) "-f" "-c" #$cupsd.conf "-s" #$cups-files.conf))) (stop #~(make-kill-destructor)) +(define (cups-pam-service config) + (let ((allow-empty-password? + (if (opaque-cups-configuration? config) + (opaque-cups-configuration-allow-empty-password? config) + (cups-configuration-allow-empty-password? config +(list (unix-pam-service "cups" +#:allow-empty-passwords? allow-empty-password? + (define cups-service-type (service-type (name 'cups) (extensions @@ -1013,6 +1029,8 @@ (define cups-service-type cups-shepherd-service) (service-extension activation-service-type (const %cups-activation)) + (service-extension pam-root-service-type + cups-pam-service) (service-extension account-service-type (const %cups-accounts base-commit: ed1e7920393c9ae5b2ae31fc46bae88136239b13 -- 2.40.1
bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication
Hello, Maxim Cournoyer writes: Hi, muradm writes: Fixes <https://issues.guix.gnu.org/63198>. Makes CUPS service to extend pam-root-service-type providing minimal configuration to authenticate users. Since PAM authentication is provided, cups package can be used as default. * gnu/services/cups.scm (cups-configuration) [cups]: Use cups. I'd write 'Replace cups-minimal with cups'. Sure you may change this. [allow-empty-password?]: PAM service configuration permitting empty passwords. I'd write 'New field', but I think we'd want to add proper PAM support here not a 'bypass PAM authentication' hack. It should also be enabled out of the box, otherwise users won't be able to authenticate until they figure out they need to set that switch to #t. Who ever touches PAM configuration knows that by default PAM does not allow to authenticate users with empty passwords. This flag allows such users. Just grep guix for allow-empty-password?, you will see that it is all over the places. (opaque-cups-configuration): Likewise. (cups-pam-service): cups PAM service. Not descriptive :-) What is the change here? I used simlilar strategy as in your commit 6bc3e3f9ba :-) You are free to reword as you wish. Could you look into adding "regular" login PAM support instead of a bypass disabled by default? The user should still be prompted for its password, and it should go through the PAM auth module. I'm not very PAM-aware, but I believe there are examples spread in the code base. This patch provides necessary configuration for proper PAM support. I decided to take screen-locker-service-type's configuration as basis, since it is was most simpliest and adequate enough for this case. This patch does not disables, baypasses or cheats PAM in any way. User may navigate to CUPS portal. In the event of administrative actions taken by user, CUPS portal asks user to authenticate. With this configuration, it will attempt to authenticate as local system user. In the event of proper system user/password supplied and positively authenticated against PAM using "cups" service name, user allowed to take administrative action. In the event of invalid system user/password supplied, CUPS portal will keep looping begging for password (just as in your original case). If user decides to Cancel the authentication dialog, CUPS portal is navigated to Unauthorized access informing page. Why would I submit something that it is not working? signature.asc Description: PGP signature
bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication
Hi Maxim, Maxim Cournoyer writes: Hi muradm, muradm writes: [...] Could you look into adding "regular" login PAM support instead of a bypass disabled by default? The user should still be prompted for its password, and it should go through the PAM auth module. I'm not very PAM-aware, but I believe there are examples spread in the code base. This patch provides necessary configuration for proper PAM support. I decided to take screen-locker-service-type's configuration as basis, since it is was most simpliest and adequate enough for this case. This patch does not disables, baypasses or cheats PAM in any way. User may navigate to CUPS portal. In the event of administrative actions taken by user, CUPS portal asks user to authenticate. With this configuration, it will attempt to authenticate as local system user. In the event of proper system user/password supplied and positively authenticated against PAM using "cups" service name, user allowed to take administrative action. In the event of invalid system user/password supplied, CUPS portal will keep looping begging for password (just as in your original case). If user decides to Cancel the authentication dialog, CUPS portal is navigated to Unauthorized access informing page. Why would I submit something that it is not working? I didn't mean to imply that it didn't work; I just thought that it was somehow bypassing PAM (and the original problem it caused in the first place). As I wrote earlier, I know next to nothing about PAM, and misread your patch. I've now installed the change. Thanks for the fix, and thanks to Ricardo for the reminder. Cool, thanks! signature.asc Description: PGP signature
bug#75295: emacs-math-preview: add math-preview dependency?
Ah.. you also need to configure NPM. Mine is set as following: mkdir -p ~/.config/npm mkdir -p ~/.local/share/npm echo "prefix=/home/muradm/.local/share/npm" > ~/.config/npm/config Then you can use "npm install -g ...". Christopher Howard writes: muradm writes: guix shell node -- npm install -g git+https://gitlab.com/matsievskiysv/math-preview Does this command actually work for you? When I try, I get this error ``` 90 verbose stack Error: ENOENT: no such file or directory, mkdir '/gnu/store/lknvzfbwqffvvyflid5dpm53vbjg8kh4-node-18.19.0/lib/node_modules/math-preview' ``` Do you have some necessary node configuration set up which I don't? signature.asc Description: PGP signature
bug#75295: emacs-math-preview: add math-preview dependency?
Hi, normally nodejs packages are hard to import, since they have tons of dependencies, just like crates for rust, while crates are maintained in Guix and npm packages are not. When I need nodejs package to be available for emacs, I once install it globally: guix shell node -- npm install -g git+https://gitlab.com/matsievskiysv/math-preview Then next time I need an instance of emacs with it, I would run: guix shell node -- emacs Beware, that if you run emacs without node available, math-preview would not be available as well. If you normally don't have any thing complex to do with node (like having multiple nodejs versions, environments etc.), you may add it to your profile. Christopher Howard writes: Hi, the package emacs-math-preview requires nodejs package math-preview to be installed, in order to work. Would it be possible Somebody™ could create a package for that and add it as an explicit dependency for emacs-math-preview? I know nothing about nodejs and am having trouble figuring out how to install math-preview myself on Guix. The README.md instructions in emacs-math-preview state: It may be installed by issuing the command: ```bash > npm install -g > git+https://gitlab.com/matsievskiysv/math-preview ``` However, if I do this, I get this error: ``` christopher@theoden ~$ npm install -g git+https://gitlab.com/matsievskiysv/math-preview npm ERR! code ENOENT npm ERR! syscall mkdir npm ERR! path /gnu/store/lknvzfbwqffvvyflid5dpm53vbjg8kh4-node-18.19.0/lib/node_modules/math-preview npm ERR! errno -2 npm ERR! enoent ENOENT: no such file or directory, mkdir '/gnu/store/lknvzfbwqffvvyflid5dpm53vbjg8kh4-node-18.19.0/lib/node_modules/math-preview' npm ERR! enoent This is related to npm not being able to find a file. npm ERR! enoent npm ERR! A complete log of this run can be found in: /home/christopher/.npm/_logs/2025-01-02T18_16_26_364Z-debug-0.log ``` Evidently, I need to somehow pick a different path or something like that. If somebody could at least document the correct installation steps here, that would be helpful. signature.asc Description: PGP signature
