bug#71211: %guile-static-stripped crashes with a sigsegv (i.e. the guile used in the initrd (?))
root symptom: - i think this is the guile binary that is used in initrd. it's been a while i noted this bug. but if it's so, then if error happens early in the boot, then it just dies with a sigsegv; i.e. it's a major hindrance to debuggability. reproducer: --- guix shell -e '(begin (use-modules (gnu packages make-bootstrap)) %guile-static-stripped)' and then start guile. or alternatively: guile -c '(use-modules (ice-9 readline))' analysis: - make-guile-static-stripped calls (remove-store-references guile2) without checking the return code. if i remove that call, then building fails with: "... is not allowed to refer to path `/gnu/store/3zl03prdg07ax4dny78hrzykillr6vcy-glibc-2.35'" i.e. there's some reference in the binary to glibc, which is corrupted by remove-store-references. i'm not sure this is the cause, but i suspect. note that the `guile --version` test in make-guile-static-stripped runs fine; i.e. it's an insufficient test. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “How much truth can a spirit bear, how much truth can a spirit dare? […] that became for me more and more the real measure of value.” — Friedrich Nietzsche (1844–1900)
bug#67565: shepherd: FAIL: tests/close-on-exec.sh
> > this log file is with my shepherd branch, i.e. it contains much more log. > > > Could you check whether it happens with current ‘main’? i ran a `make check` recently on main, and it ran clean. it doesn't mean much, though, because it only failed sporadically. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The worst enemy of clear thinking is the propensity to hypostatize, i.e. to ascribe substance or real existence to mental constructs or concepts.” — Ludwig von Mises (1881–1973), 'The Ultimate Foundations of Economic Science' (1962)
bug#70125: `guix home import` doesn't quote aliases properly
as reported on #guix on 2024-04-01: https://logs.guix.gnu.org/guix/2024-04-01.log#121908 the following alias (a default in ubuntu) is not quoted properly: notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')" which leads to an error when opening a new terminal after a `guix home reconfigure`. a discussion of this alias: https://askubuntu.com/questions/423646/use-of-default-alias-alert -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “What you do speaks so loud I cannot hear what you say.” — Ralph Waldo Emerson (1803–1882)
bug#67565: (No Subject)
> hrm, i tried to reproduce it just now on the same machine, and i couldn't. it has happened again, i'm attaching another log file. this log file is with my shepherd branch, i.e. it contains much more log. the error: + test 4 -eq 6 HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “I don't trust a man who talks about ethics when he is picking my pocket. But if he is acting in his own self-interest and says so, I have usually been able to work out some way to do business with him.” — Robert Heinlein (1907–1988), 'Time Enough For Love' (1973) + shepherd --version shepherd (GNU Shepherd) 0.10.3 Copyright (C) 2024 the Shepherd authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. + herd --version herd (GNU Shepherd) 0.10.3 Copyright (C) 2024 the Shepherd authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. + socket=t-socket-11858 + conf=t-conf-11858 + log=t-log-11858 + pid=t-pid-11858 + c_file=t-count-file-descriptors-11858.c + exe=/home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-11858 + fd_count=/home/alendvai/workspace/guix/shepherd/t-fd-count-11858 + herd='herd -s t-socket-11858' + trap 'cat t-log-11858 || true; rm -f t-socket-11858 t-conf-11858 t-log-11858 /home/alendvai/workspace/guix/shepherd/t-fd-count-11858 t-count-file-descriptors-11858.c /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-11858; test -f t-pid-11858 && kill `cat t-pid-11858` || true; rm -f t-pid-11858' EXIT + '[' -d /proc/self/fd ']' + cat + gcc -Wall t-count-file-descriptors-11858.c -o /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-11858 + /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-11858 0 -> /dev/pts/0 1 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log 2 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log 3 -> /proc/11890/fd 15 -> /gnu/store/l0y8jkmip7qpa7x33972mn0dsfy8ac01-libffi-3.4.4/lib/libffi.so.8.1.2 + cat ++ type -P sleep + rm -f t-pid-11858 /home/alendvai/workspace/guix/shepherd/t-fd-count-11858 + test -f t-pid-11858 + sleep 0.3 + shepherd -I -s t-socket-11858 -c t-conf-11858 -l t-log-11858 --pid=t-pid-11858 Starting service root... Service root started. Service root running with value #t. Service root has been started. Configuration successfully loaded from 't-conf-11858'. + test -f t-pid-11858 ++ cat t-pid-11858 + shepherd_pid=11894 + kill -0 11894 + herd -s t-socket-11858 start inetd-ctor Starting service inetd-ctor... Service inetd-ctor started. Service inetd-ctor running with value (#). Service inetd-ctor has been started. + ls -l /proc/11894/fd total 0 lr-x-- 1 alendvai users 64 Jan 19 00:06 0 -> /dev/null l-wx-- 1 alendvai users 64 Jan 19 00:06 1 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log lrwx-- 1 alendvai users 64 Jan 19 00:06 10 -> anon_inode:[signalfd] lr-x-- 1 alendvai users 64 Jan 19 00:06 11 -> pipe:[7007304] l-wx-- 1 alendvai users 64 Jan 19 00:06 12 -> pipe:[7007304] lr-x-- 1 alendvai users 64 Jan 19 00:06 13 -> pipe:[7005516] l-wx-- 1 alendvai users 64 Jan 19 00:06 14 -> pipe:[7005516] lr-x-- 1 alendvai users 64 Jan 19 00:06 15 -> /gnu/store/l0y8jkmip7qpa7x33972mn0dsfy8ac01-libffi-3.4.4/lib/libffi.so.8.1.2 lr-x-- 1 alendvai users 64 Jan 19 00:06 16 -> pipe:[7005517] l-wx-- 1 alendvai users 64 Jan 19 00:06 17 -> pipe:[7005517] lr-x-- 1 alendvai users 64 Jan 19 00:06 18 -> pipe:[7003504] l-wx-- 1 alendvai users 64 Jan 19 00:06 19 -> pipe:[7003504] l-wx-- 1 alendvai users 64 Jan 19 00:06 2 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log lrwx-- 1 alendvai users 64 Jan 19 00:06 20 -> socket:[7007305] lrwx-- 1 alendvai users 64 Jan 19 00:06 22 -> socket:[7007310] lr-x-- 1 alendvai users 64 Jan 19 00:06 3 -> pipe:[7007301] l-wx-- 1 alendvai users 64 Jan 19 00:06 4 -> pipe:[7007301] lr-x-- 1 alendvai users 64 Jan 19 00:06 5 -> /home/alendvai/workspace/guix/shepherd/shepherd l-wx-- 1 alendvai users 64 Jan 19 00:06 6 -> /home/alendvai/workspace/guix/shepherd/t-log-11858 lr-x-- 1 alendvai users 64 Jan 19 00:06 7 -> pipe:[7007303] l-wx-- 1 alendvai users 64 Jan 19 00:06 8 -> pipe:[7007303] lrwx-- 1 alendvai users 64 Jan 19 00:06 9 -> anon_inode:[eventpoll] + herd -s t-socket-11858 start system-ctor Starting service system-ctor... Service system-ctor has been started. + herd -s t-socket-11858 status system-ctor Status of system-ctor: It is stopped (one-shot). It is enabled. Provides (system-ctor). Requires (). Will not be respawned. + test -f /home/al
bug#67839: [PATCH v2 1/2] shepherd: Make sure with-process-monitor covers everything needed.
* modules/shepherd.scm (main): Switch with-service-registry and with-process-monitor. This way the parameterize of the process monitor covers everything else. This fixes the bug that caused `guix system reconfigure` to hang in certain situations. Fix proposed by @emixa-d at: https://github.com/wingo/fibers/issues/29#issuecomment-1858922276. --- modules/shepherd.scm | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/modules/shepherd.scm b/modules/shepherd.scm index efc5517..3303de3 100644 --- a/modules/shepherd.scm +++ b/modules/shepherd.scm @@ -450,13 +450,13 @@ fork in the child process." ;; because POSIX threads and 'fork' cannot be used together. (run-fibers (lambda () - (with-service-registry + (with-process-monitor + (with-service-registry - ;; Register and start the 'root' service. - (register-services (list root-service)) - (start-service root-service) + ;; Register and start the 'root' service. + (register-services (list root-service)) + (start-service root-service) - (with-process-monitor ;; Replace the default 'system*' binding with one that ;; cooperates instead of blocking on 'waitpid'. Replace ;; 'primitive-load' (in C as of 3.0.9) with one that does -- 2.41.0
bug#67839: [PATCH v2 2/2] service: Add asserts that used to make tests/replacement.sh fail.
* modules/shepherd/service.scm (spawn-service-controller): Add two asserts.
This is the bug that causes `guix system reconfigure ...` to sometimes hang,
and subsequently all shepherd commands, because a match-error flies out from
the service-controller of a replaced service, and thus its fiber dies. These
asserts get triggered without the previous commit that fixes the issue.
---
modules/shepherd/service.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index c3bdf44..0ee6929 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -382,9 +382,11 @@ denoting what the service provides."
(define (spawn-service-controller service)
"Return a channel over which @var{service} may be controlled."
+ (assert (current-process-monitor))
(let ((channel (make-channel)))
(spawn-fiber
(lambda ()
+ (assert (current-process-monitor))
;; The controller writes to its current output port via 'local-output'.
;; Make sure that goes to the right port. If the controller got a
;; wrong output port, it could crash and stop responding just because a
--
2.41.0
bug#67839: [PATCH 3/2] shepherd: Fix tests/replacement.sh
* modules/shepherd.scm (main): Switch with-service-registry and with-process-monitor. Fix proposed by @emixa-d at https://github.com/wingo/fibers/issues/29#issuecomment-1858922276. This way the parameterize of the process monitor covers everything else. --- modules/shepherd.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/shepherd.scm b/modules/shepherd.scm index 77c6d18..3303de3 100644 --- a/modules/shepherd.scm +++ b/modules/shepherd.scm @@ -450,8 +450,8 @@ fork in the child process." ;; because POSIX threads and 'fork' cannot be used together. (run-fibers (lambda () - (with-service-registry - (with-process-monitor + (with-process-monitor + (with-service-registry ;; Register and start the 'root' service. (register-services (list root-service)) -- 2.41.0
bug#67538: Shepherd stops responding during "guix system reconfigure"
> Thank you very much for this, Attila! you're welcome! :) > Are the patch in 67839 and/or your branch "attila" linked from there in a > state that I could test them locally? Would it be valuable to you if I ran a > patched Shepherd and sent logs and/or backtraces as I encountered them? it's nice of you, but not really. now that we have a failing test case in shepherd's unit tests that can reproduce it much easier. with #67839 you would only get you an extra "Assertion failed" message over master, without much useful output. as for my branch, it would emit a lot of useful log, including backtraces, but i keep force-pushing into it. i'm running my servers with it, though, so if you feel really adventurous, and want to join the debugging, then you can try... otherwise it's too much in flux. what we need to focus on now is making shepherd's test suite run clean again, one way or another. then i can test it in a real life environment, and report back with any possible findings. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Ignorance might be bliss for the ignorant, but for the rest of us it's a fucking pain in the ass.” — Ricky Gervais
bug#65178: Shepherd stops responding during "guix system reconfigure"
i think i have found the root cause of this, as documented here: https://issues.guix.gnu.org/67839 that issue contains patches for shepherd to reproduce it in its test suite. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “What divides libertarians from everybody else is not a belief about rights or what rights people have, because the judgments libertarians make about the state are the same as the judgments almost everyone makes about private agents. So it's not that we believe in rights that other people don't believe in, or that other people believe in rights that we don't believe in. It's that other people think the state is exempt from the moral principles that apply to non-government agents.” — Michael Huemer
bug#67839: [PATCH 2/2] service: Add two asserts that will make tests/replacement.sh fail.
* modules/shepherd/service.scm (spawn-service-controller): Add two asserts.
This is the bug that causes `guix system reconfigure ...` to sometimes hang,
and subsequently all shepherd commands, because a match-error flies out from
the service-controller of a replaced service, and thus its fiber dies.
---
modules/shepherd/service.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index c3bdf44..0ee6929 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -382,9 +382,11 @@ denoting what the service provides."
(define (spawn-service-controller service)
"Return a channel over which @var{service} may be controlled."
+ (assert (current-process-monitor))
(let ((channel (make-channel)))
(spawn-fiber
(lambda ()
+ (assert (current-process-monitor))
;; The controller writes to its current output port via 'local-output'.
;; Make sure that goes to the right port. If the controller got a
;; wrong output port, it could crash and stop responding just because a
--
2.41.0
bug#67839: [PATCH 1/2] shepherd: Move root-service start under with-process-monitor.
* modules/shepherd.scm (main): move the (start-service root-service) under the dynamic extent of with-process-monitor, so that (current-process-monitor) is valid for the root-service, too. --- modules/shepherd.scm | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/modules/shepherd.scm b/modules/shepherd.scm index efc5517..77c6d18 100644 --- a/modules/shepherd.scm +++ b/modules/shepherd.scm @@ -451,12 +451,12 @@ fork in the child process." (run-fibers (lambda () (with-service-registry + (with-process-monitor - ;; Register and start the 'root' service. - (register-services (list root-service)) - (start-service root-service) + ;; Register and start the 'root' service. + (register-services (list root-service)) + (start-service root-service) - (with-process-monitor ;; Replace the default 'system*' binding with one that ;; cooperates instead of blocking on 'waitpid'. Replace ;; 'primitive-load' (in C as of 3.0.9) with one that does -- 2.41.0
bug#67839: shepherd: sometimes hangs on `guix system reconfigure`
my fellow hackers, i'm going to attach two patches that is essentially just adding a couple of asserts that trigger a test failure (tests/replacement.sh). my current codebase (https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila) logs a whole lot more information, and has a more sophisticated error handling. triggering the same error on that codebase shows that the first assert is already failing (the one that is before spawning the new fiber for the controller of the replacement). maybe the root cause is this: https://github.com/wingo/fibers/issues/29 HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Angry people want you to see how powerful they are… loving people want you to see how powerful You are.” — Chief Red Eagle
bug#67649: shepherd: (shepherd support) is visible for start GEXP
the facts: -- start GEXP's of services are loaded into unnamed modules. the definitions from (shepherd support) are visible in these unnamed modules. see the attached rerpoducer. it can be run with: $(guix system --no-graphic vm reproducer.scm) and in the VM (must use fold, because it's a dumb terminal): cat /var/log/messages | fold -150 and observe that (shepherd support) is listed. questions: -- is this indended? i.e. part of the shepherd API? if not, then this is probably a bug. looking at the public definitions in (shepherd support), it's not obvious that those are meant to be available for the users of shepherd. either way, this should probably be documented with at least a comment at the top of the file. if this is intended, then where is this module imported? i looked all around, and i can't seem to find what mechanism imports this support module into the unnamed module that are used for the GEXPs. my ultimate issue: -- my service code has conflicting definitions with (shepherd support), and i need to know the intent in the shepherd API to decide on the proper fix. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Tact is a skill that can turn brutal honesty into just honesty. It's a skill that develops with practice, and one that's harder to use when emotions are running high. But you can't go towards someone with a verbal fist and expect a hug in return. When method matches intention, outcomes are much more peaceful.” — Doe Zantamata ;; Run with something like this: ;; $(guix system --no-graphic vm reproducer.scm) (define-module (reproducer) #:use-module (gnu system) #:use-module (gnu system shadow) #:use-module (gnu system nss) #:use-module (gnu system vm) #:use-module (gnu tests) #:use-module (gnu services) #:use-module (gnu services base) #:use-module (gnu services dbus) #:use-module (gnu services shepherd) #:use-module (gnu packages admin) #:use-module (gnu packages base) #:use-module (gnu packages bash) #:use-module (gnu packages certs) #:use-module (gnu packages package-management) #:use-module (gnu packages linux) #:use-module (guix gexp) #:use-module (guix git) #:use-module (guix git-download) #:use-module (guix store) #:use-module (guix modules) #:use-module (guix packages) #:use-module (srfi srfi-1) #:use-module (ice-9 match)) (operating-system (inherit %simple-os) (services (cons* (simple-service 'reproducer shepherd-root-service-type (list (shepherd-service (requirement '(file-systems)) (provision '(reproducer)) (documentation "") (start #~(begin (lambda _ (format #t "*** reproducer gexp speaking, \ current module: ~A, \ module-uses: ~A, \ ringbuffer: ~A~%" (current-module) (module-uses (current-module)) (and=> (module-variable (current-module) 'ring-buffer) variable-ref)) 0)) %base-services)))
bug#67565: (No Subject)
hrm, i tried to reproduce it just now on the same machine, and i couldn't. not sure it's relevant, but my router is overloaded, and sometimes DNS resolution, and other things break. looking at the test it shouldn't matter as it deals with the loopback device. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If one rejects laissez faire on account of man's fallibility and moral weakness, one must for the same reason also reject every kind of government action.” — Ludwig von Mises (1881–1973), 'Planning for Freedom' (1952)
bug#67565: shepherd: FAIL: tests/close-on-exec.sh
make check TESTS="tests/close-on-exec.sh" fails for me in shepherd. it's the same with master, with v0.10.2, and with v0.10.1. i didn't check other revisions. the log file is attached. HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- You cannot enslave a mind that knows itself, that values itself, that understands itself. + shepherd --version shepherd (GNU Shepherd) 0.10.2 Copyright (C) 2023 the Shepherd authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. + herd --version herd (GNU Shepherd) 0.10.2 Copyright (C) 2023 the Shepherd authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. + socket=t-socket-12913 + conf=t-conf-12913 + log=t-log-12913 + pid=t-pid-12913 + c_file=t-count-file-descriptors-12913.c + exe=/home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-12913 + fd_count=/home/alendvai/workspace/guix/shepherd/t-fd-count-12913 + herd='herd -s t-socket-12913' + trap 'cat t-log-12913 || true; rm -f t-socket-12913 t-conf-12913 t-log-12913 /home/alendvai/workspace/guix/shepherd/t-fd-count-12913 t-count-file-descriptors-12913.c /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-12913; test -f t-pid-12913 && kill `cat t-pid-12913` || true; rm -f t-pid-12913' EXIT + '[' -d /proc/self/fd ']' + cat + gcc -Wall t-count-file-descriptors-12913.c -o /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-12913 + /home/alendvai/workspace/guix/shepherd/t-count-file-descriptors-12913 0 -> /dev/pts/1 1 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log 2 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log 3 -> /proc/12945/fd + cat ++ type -P sleep + rm -f t-pid-12913 /home/alendvai/workspace/guix/shepherd/t-fd-count-12913 + test -f t-pid-12913 + sleep 0.3 + shepherd -I -s t-socket-12913 -c t-conf-12913 -l t-log-12913 --pid=t-pid-12913 Starting service root... Service root started. Service root running with value #t. Service root has been started. Configuration successfully loaded from 't-conf-12913'. + test -f t-pid-12913 ++ cat t-pid-12913 + shepherd_pid=12949 + kill -0 12949 + herd -s t-socket-12913 start inetd-ctor Starting service inetd-ctor... Service inetd-ctor started. Service inetd-ctor running with value (#). Service inetd-ctor has been started. + ls -l /proc/12949/fd total 0 lr-x-- 1 alendvai users 64 Nov 17 21:46 0 -> /dev/null l-wx-- 1 alendvai users 64 Nov 17 21:46 1 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log lrwx-- 1 alendvai users 64 Nov 17 21:46 10 -> anon_inode:[signalfd] l-wx-- 1 alendvai users 64 Nov 17 21:46 11 -> pipe:[16921055] lr-x-- 1 alendvai users 64 Nov 17 21:46 12 -> pipe:[16920173] l-wx-- 1 alendvai users 64 Nov 17 21:46 13 -> pipe:[16920173] lrwx-- 1 alendvai users 64 Nov 17 21:46 14 -> anon_inode:[eventpoll] lrwx-- 1 alendvai users 64 Nov 17 21:46 15 -> socket:[16920174] lrwx-- 1 alendvai users 64 Nov 17 21:46 17 -> socket:[16920178] l-wx-- 1 alendvai users 64 Nov 17 21:46 2 -> /home/alendvai/workspace/guix/shepherd/tests/close-on-exec.log lr-x-- 1 alendvai users 64 Nov 17 21:46 3 -> pipe:[16918174] l-wx-- 1 alendvai users 64 Nov 17 21:46 4 -> pipe:[16918174] lr-x-- 1 alendvai users 64 Nov 17 21:46 5 -> /home/alendvai/workspace/guix/shepherd/shepherd l-wx-- 1 alendvai users 64 Nov 17 21:46 6 -> /home/alendvai/workspace/guix/shepherd/t-log-12913 lr-x-- 1 alendvai users 64 Nov 17 21:46 7 -> pipe:[16920172] l-wx-- 1 alendvai users 64 Nov 17 21:46 8 -> pipe:[16920172] lr-x-- 1 alendvai users 64 Nov 17 21:46 9 -> pipe:[16921055] + herd -s t-socket-12913 start system-ctor Starting service system-ctor... Service system-ctor has been started. + herd -s t-socket-12913 status system-ctor Status of system-ctor: It is stopped (one-shot). It is enabled. Provides (system-ctor). Requires (). Will not be respawned. + test -f /home/alendvai/workspace/guix/shepherd/t-fd-count-12913 ++ cat /home/alendvai/workspace/guix/shepherd/t-fd-count-12913 + test 4 -eq 4 + herd -s t-socket-12913 start forkexec-ctor Starting service forkexec-ctor... Service forkexec-ctor started. Service forkexec-ctor running with value 13000. Service forkexec-ctor has been started. + herd -s t-socket-12913 status forkexec-ctor Status of forkexec-ctor: It is running since 21:46:15 (0 seconds ago). Running value is 13000. It is enabled. Provides (forkexec-ctor). Requires (). Will not be respawned. ++ herd -s t-socket-12913 status forkexec-ctor ++ grep 'Running value' ++ sed '-es/^.* \([0-9]\+\)\.$/\1/g' + pid=13000 + kill -0 13000 + ls -l /
bug#67538: Shepherd stops responding during "guix system reconfigure"
> > my suspicion is that it's due to some error coming from a start > > GEXP that somehow derails shepherd's event loop. [...] > iirc I once managed to get a debugger out when it happened and it's > stuck waiting in one of the epoll/select/alike calls, ...or one of the start/stop GEXP's calls something that (sometimes?) blocks indefinitely (which violates the API of shepherd). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- Child labor was not abolished, it was changed from productive work to counter-productive brainwashing, and made universal: compulsory public schooling.
bug#67538: Shepherd stops responding during "guix system reconfigure"
i've also experienced this, and someone else on IRC also described the same behavior. that makes three of us. i don't think it's relevant, but i'm also using syncthing. my suspicion is that it's due to some error coming from a start GEXP that somehow derails shepherd's event loop. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- The use of power is only needed when you want to do something harmful, otherwise love is enough to get everything done.
bug#64665: [Shepherd] Introduce a configurable respawn delay
> > The conclusion of the thread at > > https://lists.gnu.org/archive/html/guix-devel/2023-07/msg5.html > > seems to be that we should introduce a configurable respawn delay > > (systemd makes that 100ms). > > > Implemented in commit 1d3643f2576aff1869bba084c92684c81689a0a1. > > Let me know if you have any comments! damn, i already had this in the queue for sending: https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=1d3643f2576aff1869bba084c92684c81689a0a1 to help synchronize our efforts, here are the commits i'm working on, and planning to send them once they have been polished and properly tested: https://github.com/attila-lendvai-patches/shepherd/commits/attila -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Whosoever is delighted in solitude, is either a wild beast or a god.” — Aristotle (BC 384–322), paraphrased by Francis Bacon in 'Of Friendship'
bug#62491: [berlin] certbot renewal appears to be broken
hi Giovanni, it's been a long time, i don't remember much anymore. but let's run a quick assert: my server is serving multiple virtual domains (dwim.hu and lendvai.name) from completely different webroot directories. that's why i assumed that certbot needs to generate two different certificates for the two domains, and then be able to download them by accessing the same ip address through two separate domain names, and nginx serving the certificates corresponding to the domain name in the request. did you write your answer with this in mind? if yes, then i'll need to get back in context to answer properly. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Not to discuss with a man worthy of conversation is to waste the man. To discuss with a man not worthy of conversation is to waste words. The wise waste neither men nor words.” — Confucius (551–479 BC), 'The Analects'
bug#61292: fontconfig -> fontconfig-minimal
close 61292 stop i started doing the rename of the variable, but the change quickly grew extensive, so i gave up. it's probably not worth the trouble. there are 332 grep matches, and the majority requries a change. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Beware the stories you read or tell; subtly, at night, beneath the waters of consciousness, they are altering your world.” — Ben Okri (1959–)
bug#64008: shepherd respawns a service even when it's disabled
i forgot to mention that the service is in the stopped state while this is happening, at least according to `herd status`. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Most of our lives, most of us live in realities determined by others, imprinted in our brains by education, by religion, by politics, by the authorities.” — Timothy Leary (1920–1996)
bug#64008: shepherd respawns a service even when it's disabled
the issue: i'm in a situation where my service quits after a few seconds of CPU usage (i.e. the default-respawn-limit is not triggered). therefore shepherd keeps restarting it, practically in a busy loop. suggested solution: maybe respawn-service should check for the disabled state, so that the admin can intervene by `herd disable myservice`. a longer term solution could be to add a respawn-delay field for , and default it to something non-zero. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- The mind: an excellent servant, but a dangerous master.
bug#63979: SHEPHERD-SERVICE-CANONICAL-NAME assumes a non-empty PROVISION, but such instantiation is allowed
it's possible to instantiate a SHEPHERD-SERVICE with an empty list as PROVISION, but then much later in time and space SHEPHERD-SERVICE-CANONICAL-NAME dies on it. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You live within a framework of perception that's determined by your values. […] We never think of the world as something that reveals itself through our values, but of course it does! Because you look at what you want. […] Whatever you're focusing on is directed by what you value.” — Jordan Peterson (1962–)
bug#63972: specifying a substitute server without adding its PGP key silently ignores it
i've installed a new guix, and at the first `guix system reconfigure` i specified a substitute server using --substitute-urls for That Other Channel. i had to do this, because the config.scm that contains the substitute specification is yet to be applied. it didn't work. it prints everything as usual, including the 100% message for that substitute server, but it starts to build packages locally for which substitutes are available. i haven't noticed any indication that there's a problem with any of the substitute servers. once i've downloaded the .pub and i finally did the right incantation (sudo guix archive --authorize < signing-key.pub), then it started to download the substitutes as i expected. i would much prefer a behavior where a "cryptyc" exception and backtrace is printed by a toplevel error handler. it has cost me about an hour of my life. i'd suggest the following general strategy for the entire codebase in general: throw exceptions, and let them fly all the way up to the toplevel error handler that should print it with a backtrace. this should be the baseline, and only then start adding very specific exception handlers to print friendly and localizable error messages for various situations, and only ever swallow exceptions when it's really justified. e.g. a file-not-found error in an ensure-file-deleted function. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Civilization is in a race between education and catastrophe. Let us learn the truth and spread it as far and wide as our circumstances allow. For the truth is the greatest weapon we have.” — H.G. Wells (1866–1946)
bug#53580: shepherd's architecture
> Sorry to be direct: is there a concrete bug you’re reporting here? i didn't pay careful enough attention to report something specific, but one thing that pops to mind: when i'm working on my service code, which is `guix pull`ed in from my channel, then after a reconfigure i seem to have to reboot for my new code to get activated. a simple `herd restart` on the service didn't seem to be enough. i.e. the guile modules that my service code is using did not get reloaded into the PID 1 guile. keep in mind that this is a non-trivial service that e.g. spawns a long-lived fiber to talk to the daemon through its stdio while the daemon is running. IOW, its start GEXP is not just a simple forkexec, but something more complex that uses functions from guile modules that should be reloaded into PID 1 when the new version of the service is to be started. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The unexamined life is not worth living for a human being.” — Socrates (c. 470–399 BC, tried and executed), 'Apology' (399 BC)
bug#63868: [reconfigure, shepherd] error: remove: unbound variable
close 63868 stop TL;DR HEAD of master doesn't exhibit this anymore, it works fine. > Weird. Are there any hints in /var/log/messages? nothing sticks out to me. i saw it on another machine since then, similar config. i had more opportunity to experiment there, and the first commit where the error shows up is this one: services: Error in MODIFY-SERVICES when services don't exist https://git.savannah.gnu.org/cgit/guix.git/commit/?id=dbbc7e946131ba257728f1d05b96c4339b7ee88b one commit prior in the history works fine: ae707b62e71b1fae054eb422412384bcc8d39fa9 i've tried to play around with different commits, and also reverting this one on top of other commits, but it took too long to recompile stuff locally... and meanwhile some changes in master eliminated this issue, so this is all kinda moot now. but i have double checked, and the above commit is the one that consistently leads to this error for me. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “To every man is given the key to the gates of heaven; the same key opens the gates of hell. And so it is with science.” — Richard Feynman (1918–1988)
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
i turn off some services using `herd disable`. then i do a `guix system reconfigure`, and these services get enabled and started. i would expect the enabled/disabled state to be preserved across reconfigures. if it's not easily feasible in the current architecture, then feel free to close this. it's not a crucial feature. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Those who do not weep, do not see.” — Victor Hugo (1802–1885)
bug#63868: [reconfigure, shepherd] error: remove: unbound variable
$ sudo guix system reconfigure ... [...] building /gnu/store/8by5a6wqlxm3fw27xh3a6zzzwfczjpcm-install-bootloader.scm.drv... guix system: bootloader successfully installed on '(/boot/efi)' guix system: warning: exception caught while executing 'eval' on service 'root': error: remove: unbound variable guix system: warning: some services could not be upgraded hint: To allow changes to all the system services to take effect, you will need to reboot. $ (notice the empty line before the prompt; may or may not be relevant) this is all foggy. the only certain part is that i get the above printed with a recent commit, but when i rolled back the guix channel to: (commit "f9af75b2c34aab564c821b5bacebd8570777a535") then it finished without the above error. when it happens it also seems to break booting. it hang rather early, not long after grub. it's happening on a server where i'd like to keep downtime low, so i didn't do double checks. i just rolled back, reconfigured, and it worked afterwards. HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Choice implies consciousness - a high degree of consciousness. Without it, you have no choice. Choice begins the moment you disidentify from the mind and its conditioned patterns, the moment you become presentNobody chooses dysfunction, conflict, pain. Nobody chooses insanity. They happen because there is not enough presence in you to dissolve the past, not enough light to dispel the darkness. You are not fully here. You have not quite woken up yet. In the meantime, the conditioned mind is running your life.” — Eckhart Tolle (1948–)
bug#53580: shepherd's architecture
[resending to include the guix-devel list. apologies for everyone who receives this mail twice!] -- [forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system] > So I think we’re mostly okay now. The one thing we could do is load > the whole config file in a separate fiber, and maybe it’s fine to keep > going even when there’s an error during config file evaluation? > > WDYT? i think there's a fundamental issue to be resolved here, and addressing that would implicitly resolve the entire class of issues that this one belongs to. guile (shepherd) is run as the init process, and because of that it may not exit or be respawn. but at the same time when we reconfigure a guix system, then shepherd's config should not only be reloaded, but its internal state merged with the new config, and potentially even with an evolved shepherd codebase. i still lack a proper mental model of all this to succesfully predict what will happen when i `guix system reconfigure` after i `guix pull`-ed my service code, and/or changed the config of my services. this problem of migration is pretty much a CS research topic... ideally, there should be a non-shepherd-specific protocol defined for such migrations, and the new shpeherd codebase could migrate its state from the old to the new, with most of the migration code being automatic. some of it must be hand written as rquired by some semantic changes. even more ideally, we should reflexive systems; admit that source code is a graph, and store it as one (as opposed to a string of characters); and our systems should have orthogonal persistency, etc, etc... a far cry from what we have now. Fare's excellent blog has some visionary thoughts on this, especially in: https://ngnghm.github.io/blog/2015/09/08/chapter-5-non-stop-change/ but given that we will not have these any time soon... what can we do now? note: what follows are wild ideas, and i'm not sure i have the necessary understanding of the involved subsystems to properly judge their feasibility... so take them with a pinch of salt. idea 1 it doesn't seem to be an insurmontable task to make sure that guile can safely unlink a module from its heap, check if there are any references into the module to be dropped, and then reload this module from disk. the already runing fibers would keep the required code in the heap until after they are stopped/restarted. then the module would get GC'd eventually. this would help solve the problem that a reconfigured service may have a completely different start/stop code. and by taking some careful shortcuts we may be able to make reloading work without having to stop the service process in question. idea 2 another, probably better idea: split up shepherd's codebase into isolated parts: 1) the init process 2) the service runners, which are spawned by 1). let's call this part 'the runner'. 3) the CLI scripts that implement stuff like `reboot` by sending a message to 1). the runner would spawn and manage the actual daemon binaries/processes. the init process would communicate with the runners through a channel/pipe that is created when the runner are spawn. i.e. here we wouldn't need an IPC socket file like we need for the communication between the scripts and the init process. AFAIU the internal structure of shepherd is already turning into something like this with the use of fibers and channels. i suspect Ludo has something like this on his mind already. in this setup most of the complexity and the evolution of the shepherd codebase would happen in the runner, and the other two parts could be kept minimal and would rarely need to change (and thus require a reboot). the need for a reboot could be detected by noticing that the compiled binary of the init process has changed compared to what is currently running as PID 1. the driver process of a service could be reloaded/respawned the next time when the daemon is stopped or it quits unexpectedly. recently i've succesfully wrote a shepherd service that spawns a daemon, and from a fiber it does two way communication with the daemon using a pipe connected to the daemon's stdio. i guess that counts as a proof of concept for the second idea, but i'm not sure about its stability. a stuck/failing service is a different issue than a stuck/failing init process. for reference, the spawning of the daemon: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/services/swarm.scm#L315 the fiber's code that talks to it: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/swarm-utils.scm#L133 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Dying societies accumulate laws like dying men accumulate remedies.” — Nicolás Gómez Dávila (1913–1994), 'Escolios a un texto implicito: Seleccion'
bug#53580: shepherd's architecture
[forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system] > So I think we’re mostly okay now. The one thing we could do is load > the whole config file in a separate fiber, and maybe it’s fine to keep > going even when there’s an error during config file evaluation? > > WDYT? i think there's a fundamental issue to be resolved here, and addressing that would implicitly resolve the entire class of issues that this one belongs to. guile (shepherd) is run as the init process, and because of that it may not exit or be respawn. but at the same time when we reconfigure a guix system, then shepherd's config should not only be reloaded, but its internal state merged with the new config, and potentially even with an evolved shepherd codebase. i still lack a proper mental model of all this to succesfully predict what will happen when i `guix system reconfigure` after i `guix pull`-ed my service code, and/or changed the config of my services. this problem of migration is pretty much a CS research topic... ideally, there should be a non-shepherd-specific protocol defined for such migrations, and the new shpeherd codebase could migrate its state from the old to the new, with most of the migration code being automatic. some of it must be hand written as rquired by some semantic changes. even more ideally, we should reflexive systems; admit that source code is a graph, and store it as one (as opposed to a string of characters); and our systems should have orthogonal persistency, etc, etc... a far cry from what we have now. Fare's excellent blog has some visionary thoughts on this, especially in: https://ngnghm.github.io/blog/2015/09/08/chapter-5-non-stop-change/ but given that we will not have these any time soon... what can we do now? note: what follows are wild ideas, and i'm not sure i have the necessary understanding of the involved subsystems to properly judge their feasibility... so take them with a pinch of salt. idea 1 it doesn't seem to be an insurmontable task to make sure that guile can safely unlink a module from its heap, check if there are any references into the module to be dropped, and then reload this module from disk. the already runing fibers would keep the required code in the heap until after they are stopped/restarted. then the module would get GC'd eventually. this would help solve the problem that a reconfigured service may have a completely different start/stop code. and by taking some careful shortcuts we may be able to make reloading work without having to stop the service process in question. idea 2 another, probably better idea: split up shepherd's codebase into isolated parts: 1) the init process 2) the service runners, which are spawned by 1). let's call this part 'the runner'. 3) the CLI scripts that implement stuff like `reboot` by sending a message to 1). the runner would spawn and manage the actual daemon binaries/processes. the init process would communicate with the runners through a channel/pipe that is created when the runner are spawn. i.e. here we wouldn't need an IPC socket file like we need for the communication between the scripts and the init process. AFAIU the internal structure of shepherd is already turning into something like this with the use of fibers and channels. i suspect Ludo has something like this on his mind already. in this setup most of the complexity and the evolution of the shepherd codebase would happen in the runner, and the other two parts could be kept minimal and would rarely need to change (and thus require a reboot). the need for a reboot could be detected by noticing that the compiled binary of the init process has changed compared to what is currently running as PID 1. the driver process of a service could be reloaded/respawned the next time when the daemon is stopped or it quits unexpectedly. recently i've succesfully wrote a shepherd service that spawns a daemon, and from a fiber it does two way communication with the daemon using a pipe connected to the daemon's stdio. i guess that counts as a proof of concept for the second idea, but i'm not sure about its stability. a stuck/failing service is a different issue than a stuck/failing init process. for reference, the spawning of the daemon: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/services/swarm.scm#L315 the fiber's code that talks to it: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/swarm-utils.scm#L133 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We reject: kings, presidents and voting. We believe in: rough consensus and running code.” — David Clark for the IETF
bug#63443: download retry bug; mkdir: File exists
maybe this commit has a bug? https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8bd4126917f59f4af9a4323c3d5699201862dca2 i get a "mkdir: File exists" error: 1,198.1 MB will be downloaded substitute: updating substitutes from 'https://substitutes.nonguix.org'... 100.0% substitute: updating substitutes from 'https://substitutes.nonguix.org'... 100.0% locale-2.33 1.9MiB 567KiB/s 00:04 ▕██▏ 100.0% dtc-1.6.1 96KiB 106KiB/s 00:01 ▕██▏ 100.0% linux-firmware-20230404 267.8MiB 119KiB/s 04:57 ▕██▎ ▏ 12.8%retrying download of '/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404' with other substitute URLs... linux-firmware-20230404 267.8MiB 226KiB/s 00:01 ▕ ▏ 0.0%guix substitute: error: mkdir: File exists: "/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404" substitution of /gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404 failed guix system: error: corrupt input while restoring archive from # -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The world is not to be narrowed till it will go into the understanding… but the understanding to be expanded and opened till it can take in the image of the world as it is in fact.” — Sir Francis Bacon (1561–1626)
bug#62491: (No Subject)
i don't think this is the same issue as #56678. or at least what i'm seeing on my server is that the wrong certbot cmd line is generated, which then results in saving the challenge at the wrong path. this is the mcron that gets generated: [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/ --cert-name dwim.hu -d dwim.hu --email att...@lendvai.name and this what worked when i fixed the -w arg: [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/dwim.hu --cert-name dwim.hu -d dwim.hu --email att...@lendvai.name i.e. the -w parameter should point to the webroot of the virtual domain, but the guix config structure does not allow setting the webroot for each , only at their parent, i.e. in the . this all seems to me as if the certbot service code was assuming that the certbot script will append the domain names (specified with -d) to the webroot path, but it does not. from the certbot log (i.e. challenge is saved at the wrong path): "Removing /srv/http/.well-known/acme-challenge/[hash]" the relevant code is from 2018, so certbot's behavior may very well have changed since then: https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/services/certbot.scm?id=c3215d2f9d8fa4b890e3a41ceb4404b76a7c5c49 it seems to me that the webroot field should be moved down into . am i right? if so i may try to patch this up. -- - attila PGP: 5D5F 45C7 DFCD 0A39 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “State is the name of the coldest of all cold monsters. Coldly it lies; and this lie slips from its mouth: "I, the state, am the people."” — Friedrich Nietzsche (1844–1900), 'Thus Spoke Zarathustra' (1885), http://j.mp/1k6pbwS
bug#36069: (No Subject)
open 36069 -- 3 years later i was also hindered by this (see #60002). in my case it was "fixed" (read: avoided) by my VPS provider specifying a different vga argument for my VM. maybe this patch should be applied? 'cirrus' was the default before QEMU 2.2 (~2017), and 'std' is the default since QEMU 2.2. "-vga cirrus - Simple graphics card. Every guest OS has a built-in driver." https://www.qemu.org/docs/master/system/qemu-manpage.html -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You don't need another human being to make your life complete, but let's be honest. Having your wounds kissed by someone who doesn't see them as disasters in your soul, but cracks to put their love into, is the most calming thing in this world.” — Emery Allen
bug#61292: define-public fontconfig vs. fontconfig-minimal as its name
(define-public fontconfig [...] (name "fontconfig-minimal") this tripped me up. is this a mistake? if not, then please add a comment that explains this anomaly. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We're all going to die, all of us, what a circus! That alone should make us love each other but it doesn't. We are terrorized and flattened by trivialities, we are eaten up by nothing.” — Charles Bukowski (1920–1994)
bug#56709: (No Subject)
> > i'm also seeing this, and the solution was to comment > > out the (identity ...) field of my machine-ssh-configuration. > > > i spoke too soon. today it's again broken for me the same way, even > though identity is commented out. lechner on IRC also reported that > it's broken for him. since then it's working again. this seems to be some transient issue. possibly related to network state? note that normal SSH always works. it's only a late phase of `guix deploy` where this error sometimes shows up. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The most urgent necessity is, not that the State should teach, but that it should allow education. All monopolies are detestable, but the worst of all is the monopoly of education.” — Frédéric Bastiat (1801–1850), 'What Is Money?'
bug#60265: (No Subject)
do you have other channels added, or did this happen on a vanilla Guix install? it's a duplicate of https://issues.guix.gnu.org/57838 if this happened on a vanilla Guix install, then we should reopen that issue, and merge this into that one. -- - attila PGP: 5D5F 45C7 DFCD 0A39
bug#56709: (No Subject)
> i'm also seeing this, and the solution was to comment > out the (identity ...) field of my machine-ssh-configuration. i spoke too soon. today it's again broken for me the same way, even though identity is commented out. lechner on IRC also reported that it's broken for him. random hint, maybe not relevant: i may have pulled in the short time since i wrote my previous mail, and there may have been a guile-ssh update in that pull. - attila
bug#56709: (No Subject)
i'm also seeing this, and the solution was to comment out the (identity ...)
field of my machine-ssh-configuration.
maybe my id_ed25519 key is not supported?
it seems to be able to talk to the target and even installed some stuff into
its store, and only dies when it's already deep into the process.
BTW, the configuration field names and doc are somewhat confusing. e.g. the
identity field expects a file path as a string; i.e. a file-like GEXP object
doesn't work, and neither does a copy-pasted public key as a scheme string.
also, should it be the .pub part, or the private part?
maybe a pitfall pointer could be added to the manual until the error message is
made more edifying?
- attila
PS: my output when it failed for me:
$ guix deploy lendvai.scm
The following 1 machine will be deployed:
lendvai
guix deploy: deploying to lendvai...
guix deploy: sending 0 store items (0 MiB) to 'lendvai.name'...
guix deploy: sending 0 store items (0 MiB) to 'lendvai.name'...
guix deploy: sending 0 store items (0 MiB) to 'lendvai.name'...
guix deploy: sending 0 store items (0 MiB) to 'lendvai.name'...
;;; [2022/12/21 22:16:19.061054, 0] [GSSH ERROR] Channel opening failure:
channel 63 error (2) open failed: #
Backtrace:
In guix/store.scm:
1382:11 19 (map/accumulate-builds # …)
1300:8 18 (call-with-build-handler # …)
In ice-9/boot-9.scm:
1752:10 17 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/scripts/deploy.scm:
167:6 16 (_)
In guix/store.scm:
2170:25 15 (run-with-store # _ # _ # …)
In gnu/machine/ssh.scm:
538:12 14 (_ _)
539:41 13 (_ _)
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In gnu/machine/ssh.scm:
539:41 11 (_)
In guix/store.scm:
2170:25 10 (run-with-store # # …)
In guix/remote.scm:
138:10 9 (_ _)
In guix/store.scm:
2042:38 8 (_ #)
In guix/ssh.scm:
376:2 7 (send-files # _ # …)
222:5 6 (remote-run (begin (use-modules (guix) (srfi srfi-34) (…) …) …) …)
In ssh/popen.scm:
64:4 5 (open-remote-pipe* _ "r+" _ . _)
In unknown file:
4 (channel-open-session #)
In ice-9/boot-9.scm:
1685:16 3 (raise-exception _ #:continuable? _)
1683:16 2 (raise-exception _ #:continuable? _)
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel
opening failure: channel 63 error (2) open failed" # #f)'.
bug#60002: installer console garbled on 1984.is VPS
> I guess you could have selected shell-based installation in the > graphical installer, it just wasn’t visible. once you chose menu based install at the beginning, it's not possible to change your mind and get a shell (without switching virtual consoles, or rebooting). shell based install works fine (when the console text is not garbled). as for DHCP: the VPS provider itself doesn't run a DHCP server on their network. the network must be configured manually.
bug#57838:
close 57838 -- i just found out that this is a bug in that codebase that we don't talk about here. sorry about the noise! https://gitlab.com/nonguix/nonguix/-/issues/111 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- In the end, we only regret the chances we didn’t take, relationships we were afraid to have, and the decisions we waited too long to make.
bug#60160: installer: installing on a VPS
the menu based installer (1.4.0 RC2) cannot be used on some VPS-es (e.g. https://1984.is) when: 1) there is no DHCP on the network, and therefore the network must be configured manually, and 2) they provide only a WEB based console, where it is not possible to send CTRL+ALT+Fn to switch virtual consoles. what happens with the workflow is that it gets stuck in a deadend where it checks for network upstream, fails, and the only option is to press retry, i.e. a dead-end. a suggested solution: when the network check fails, then it should get back to a toplevel menu where there's an option to start a shell, which when exited goes back to the menu. another option in the menu is to try to continue to checking network upstream again. HTH, - attila
bug#60002: installer console garbled on 1984.is VPS
close done > So the admins are using a Web interface to QEMU. Which one? What -vga > > option is it using? their response: "I changed the video mode in libvirt to virtio instead of the default cirrus." this has fixed both the garbling of text, and the resizing of the console to accommodate for the window based installer. maybe it's worth mentioning in the/a troubleshooting section of the doc. i couldn't find anything about it using websearch. my only remaining issue with the installer is that the menu based installation workflow is not possible when 1) i cannot switch virtual consoles, and 2) there's no DHCP on the network, i.e. it requires manual configuration using a shell. but i'll report that as a different issue. thank you, - attila
bug#60002: installer console garbled on 1984.is VPS
> So the admins are using a Web interface to QEMU. Which one? What -vga > option is it using? i'll ask them and report back. > Perhaps when in GRUB, press E to edit the linux boot command-line and > append to it: nomodeset this didn't help. the behavior appears to be the exact same. > IIRC there had been discussions about QEMU Bochs graphics and such, but > I can’t find them. > > > maybe the installer could be extended with something to start a > > temporary shell to configure te network, without the need to switch > > virtual consoles? > > > I don’t understand this. Can others help? let me put this another way: assume that 1) it's not possible to press CTRL+ALT+Fn to switch virtual consoles, and 2) there is no DHCP configured on the machine's network. this means that the installation is not possible, becuse it's stuck at checking for a functional network upstream. if there was a menu entry to start a temporary shell, then i could configure the network in that shell, exit the shell, and press retry in the installer's menu. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Do not be dismayed by the brokenness of the world. All things break. And all things can be mended. Not with time, as they say, but with intention. So go. Love intentionally, extravagantly, unconditionally. The broken world waits in darkness for the light that is you.” — L. R. Knost
bug#58191: (No Subject)
the fix is in https://issues.guix.gnu.org/59863 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Chaos should be seen as a teacher that teaches us, through the negative, what not to do.” — Mark Passio, http://youtu.be/atjdCbayxYM?t=46m33s
bug#58859: profile contents depends on package order
this is also somewhat related to: https://issues.guix.gnu.org/50878 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “In your journey to healing, you will learn to appreciate the many faceted qualities of others. Your early impressions will grow more accurate and you will use your trust more wisely. As your boundaries become more clearly defined, you will detect more quickly when others violate them. When the wounds are healed, the sharks will no longer circle.” — Richard Moskovitz, 'Lost in the Mirror'
bug#55802: (No Subject)
58437 updates the package and fixes this issue: https://issues.guix.gnu.org/58437 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.” — Edsger W. Dijkstra (1930–2002)
bug#58221: confirmation
i can confirm this. and thanks for including a bandaid! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “There is no single effort more radical in its potential for saving the world than a transformation of the way we raise our children.” — Marianne Williamson (1952–)
bug#58191: missing substitute for @gschemasCompiled@ ?
i'm attaching my current WIP diff while i was trying to debug this.
note that in my original submission there was a substitute for
@gschemasCompiled@ (https://issues.guix.gnu.org/53072), but it did not reach
master when it got pushed
(https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/gnome-xyz.scm?id=a485e1e663060e8c62103d81dfffec591f624360).
i'm not sure whether it's important. it shouldn't be, because gpaste used to
work for me right until a recent reconfigure... but i thought that i point it
out. if that substitute was intentionally left out, then it may warrant a
comment on why, because the package's .patch file (inherited from NixOS) adds
the marker
(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gpaste-fix-paths.patch).
i tried to reinstate the substitute, as you can see below, but it does not fix
the new crash. i added some asserts, even sure-to-fail ones, and that code path
seems not yet reached when the sigsegv already happens.
i'm out of ideas, and certainly out of my glib knowledge.
2 files changed, 11 insertions(+), 5 deletions(-)
gnu/packages/gnome-xyz.scm | 12
gnu/packages/patches/gpaste-fix-paths.patch | 4 +++-
modified gnu/packages/gnome-xyz.scm
@@ -819,7 +819,7 @@ (define-public gnome-shell-extension-paperwm
(define-public gpaste
(package
(name "gpaste")
-(version "42.1")
+(version "42.2")
(source (origin
(method git-fetch)
(uri (git-reference
@@ -828,12 +828,13 @@ (define-public gpaste
(file-name (git-file-name name version))
(sha256
(base32
-"1dlqa69zvzzdxyh21qfrx2nhpfy0fbihxpgkxqmramcgv3h5k4q3"))
+"0qq2p19p3r3lz8yfynpnf36cipv54bzdbmq1x5zgwhyl4yl41g28"))
(patches
(search-patches "gpaste-fix-paths.patch"
(build-system meson-build-system)
(native-inputs
- (list gettext-minimal
+ (list gcr
+ gettext-minimal
gobject-introspection
(list glib "bin"); for glib-compile-resources
pkg-config
@@ -862,7 +863,10 @@ (define-public gpaste
(substitute* '("src/gnome-shell/extension.js"
"src/gnome-shell/prefs.js")
(("@typelibPath@")
- (string-append #$output "/lib/girepository-1.0/"
+ (string-append #$output "/lib/girepository-1.0/")))
+ (substitute* '("src/libgpaste/gpaste/gpaste-settings.c")
+ (("@gschemasCompiled@")
+ (string-append #$output
"/share/glib-2.0/schemas/"
(home-page "https://github.com/Keruspe/GPaste;)
(synopsis "Clipboard management system for GNOME Shell")
(description "GPaste is a clipboard manager, a tool which allows you to
modified gnu/packages/patches/gpaste-fix-paths.patch
@@ -30,14 +30,16 @@ diff --git a/src/libgpaste/gpaste/gpaste-settings.c
b/src/libgpaste/gpaste/gpast
index 7e53eb64..57c399fc 100644
--- a/src/libgpaste/gpaste/gpaste-settings.c
+++ b/src/libgpaste/gpaste/gpaste-settings.c
-@@ -1013,7 +1013,11 @@ create_g_settings (void)
+@@ -1013,7 +1013,13 @@ create_g_settings (void)
}
else
{
-return g_settings_new (G_PASTE_SETTINGS_NAME);
+// library used by introspection requires schemas but we cannot set
XDG_DATA_DIRS for the library
+GSettingsSchemaSource *schema_source =
g_settings_schema_source_new_from_directory ("@gschemasCompiled@", NULL, FALSE,
NULL);
++g_assert (schema_source);
+g_autoptr (GSettingsSchema) schema = g_settings_schema_source_lookup
(schema_source, G_PASTE_SETTINGS_NAME, FALSE);
++g_assert (schema);
+g_settings_schema_source_unref (schema_source);
+return g_settings_new_full (schema, NULL, NULL);
}
bug#58191: gpaste-client --version dies with a sigsegv
this pretty much tells it all: $ guix shell gpaste $ gpaste-client --version (/gnu/store/7xj6mjvd00f83bmscn6ya1zwd0wi67gf-profile/bin/gpaste-client:27755): GPaste-CRITICAL **: 10:49:21.373: Error calling StartServiceByName for org.gnome.GPaste: Process org.gnome.GPaste received signal 11 i tried to debug it, but it happens in a new thread, and i failed to obtain a backtrace by simply starting it in gdb. the actual symptom is that the gpaste shell extension crashes the gnome shell while logging in, and upon the next login all gnome shell extensions are disabled. enabling them immediately crashes the entire gnome shell. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Being true to yourself means living in truth with each person in your life. It means refusing to say or do something that you don’t believe is right. Living in truth with other people means that you refuse to stay in any situation where you are unhappy with the behavior of another person. You refuse to tolerate it. You refuse to compromise.” — Brian Tracy (1944–)
bug#57838: failing to boot, probably due to guix gc
> > on one of my installs i ran the following two commands as root: > > > > guix gc --delete-generations=60d > > guix system delete-generations 60d > > > > i think i ran a reboot pretty soon after this, and the machine is failing > > to boot with the error "no code for module (ice-9 popen)". > > > How did you reboot? Maybe whatever rebooting mechanism you use doesn't > do 'sync' first or doesn't wait for 'sync' to complete. i'm pretty sure i have issued a `reboot` in an ssh session. > To test the hypothesis that there is store corruption, could you do > "guix gc --verify=contents" (assuming there are some old system > generations you can boot from)? as i have explained in an earlier mail, all my old generations (3 remained after the GC) got broken, but they all got repaired by a subsequent reconfigure from a chroot. it has probably installed some files that were missing. # guix gc --verify=contents reading the store... checking path existence... checking hashes... # -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Self knowledge is always bad news.” — John Barth (1930–)
bug#57978: the fallback machanism for substitute servers doesn't work?
ci.guix.gnu.org is down right now. if i add --substitute-urls=http://bordeaux.guix.gnu.org then things work, but sans that it fails: $ ./pre-inst-env guix system --no-graphic vm ~/workspace/guix/guix-crypto/tests/swarm-tests.scm guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet substitute: updating substitutes from 'https://substitutes.nonguix.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute: warning: ci.guix.gnu.org: connection failed: No route to host substitute: substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/fkdmiwmvb6ar6n04hr470r3f5frgcbnc-bee-binary-1.8.1.drv /gnu/store/ksqiqmdijfy34g9qmqhkn3r5kww7v644-bee-linux-amd64.drv /gnu/store/lgc6jnar1qha8dydhi5p9ni2jawp5wmd-module-import-compiled.drv /gnu/store/kjza0q20vy6jywfrzr4l5df5va8d5ia9-geth-binary-1.10.25.drv /gnu/store/f090qzxym89vp3r13fbqlh4ghbnfc7ls-geth-alltools-linux-amd64-1.10.25-69568c55.tar.gz.drv /gnu/store/kxjd60sx5hxygkz8vfj670f2c70xdjxd-module-import-compiled.drv /gnu/store/jkp7wrakjv4gqjn475kszaa425zgm62a-openethereum-binary-3.3.5.drv /gnu/store/d1cl9x0gy0bns9frqwgliq0z7604vian-openethereum-linux-v3.3.5.zip.drv 71.2 MB will be downloaded substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0% guix substitute: warning: ci.guix.gnu.org: connection failed: No route to host qemu-minimal-7.1.0-doc 3.4MiB 876.6MiB/s 00:00 [##] 100.0% guix substitute: error: connect*: No route to host substitution of /gnu/store/7czrnkybr466v69wdj6i2sn6vpsg0ks3-cdrkit-libre-1.1.11 failed guix system: error: corrupt input while restoring archive from # the second time fails with another package: $ ./pre-inst-env guix system --no-graphic vm ~/workspace/guix/guix-crypto/tests/swarm-tests.scm guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet guix system: warning: the following groups appear more than once: swarm-mainnet substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute: warning: ci.guix.gnu.org: connection failed: No route to host substitute: The following derivations will be built:
bug#57838: (No Subject)
i have fixed it by running a reconfigure in a chroot. surprisingly, this has also fixed the old, previously broken system generations, not only the newly created one. maybe some boot related references are not traversed while GC'ing? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- If you expect the world to be fair with you because you are fair, you're fooling yourself. Stop bitching about the lion, and get busy learning how not to get eaten.
bug#57838: failing to boot, probably due to guix gc
dear Guixers, on one of my installs i ran the following two commands as root: guix gc --delete-generations=60d guix system delete-generations 60d i think i ran a reboot pretty soon after this, and the machine is failing to boot with the error "no code for module (ice-9 popen)". i'm attaching a photo of the kernel panic screen. the delete-generations left 3 generations, but all the three fail the same way. i'll keep the machine as-is for a while if some inspection would help by providing logs/data. i also want to fix it and have it running soonish, so let me know if there's anything valuable i should extract from it before attempting to fix it. i hope a chroot and a reconfigure will fix it. i think i ran the commands multiple times with different time ranges, and in different order. i did something similar on another install, but IIRC i also ran a `guix system reconfigure` prior to the reboot, and that install didn't break. HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Politicians never accuse you of 'greed' for wanting other people's money - only for wanting to keep your own money.” — Joseph Sobran (1946–2010)
bug#41390: still doesn't work
i just got here while i wanted to test my new hunspell-dict-hu package using libreoffice. i briefly looked at the issue, and there's no mention of ASPELL_DICT_DIR in libreoffice.scm, nor in the wrapper files that i have checked. this might be an invalid expectation, though. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If a person seems wicked, do not cast him away. Awaken him with your words, elevate him with your deeds, repay his injury with your kindness. Do not cast him away; cast away his wickedness.” — Lao Tzu (sixth century BC)
bug#56799: [PATCH 4/5] services: Use the new maybe/unset API.
* gnu/home/services/ssh.scm (serialize-address-family): Use the public API of
the maybe infrastructure.
* gnu/services/file-sharing.scm (serialize-maybe-string): Use maybe-value.
(serialize-maybe-file-object): Use maybe-value-set?.
* gnu/services/getmail.scm (getmail-retriever-configuration): Don't use
internals in unset field declarations.
(getmail-destination-configuration): Ditto.
* gnu/services/messaging.scm (raw-content?): Use maybe-value-set?.
(prosody-configuration): Use %unset-value.
* gnu/services/telephony.scm (jami-shepherd-services): Use maybe-value-set?.
(archive-name->username): Use maybe-value-set?.
* tests/services/configuration.scm ("maybe type, no default"): Use
%unset-value.
---
gnu/home/services/ssh.scm| 12 +++-
gnu/services/file-sharing.scm| 11 ---
gnu/services/getmail.scm | 6 +++---
gnu/services/kerberos.scm| 1 +
gnu/services/messaging.scm | 15 ++-
gnu/services/networking.scm | 2 +-
gnu/services/telephony.scm | 6 +++---
tests/services/configuration.scm | 2 +-
8 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/gnu/home/services/ssh.scm b/gnu/home/services/ssh.scm
index f0987aee23..d15f5ee912 100644
--- a/gnu/home/services/ssh.scm
+++ b/gnu/home/services/ssh.scm
@@ -69,17 +69,19 @@ (define (serialize-string field value)
" " value "\n"))
(define (address-family? obj)
- (memv obj (list 'unset AF_INET AF_INET6)))
+ (memv obj (list AF_INET AF_INET6)))
+
+(define-maybe address-family)
(define (serialize-address-family field family)
- (if (eq? 'unset family)
- ""
+ (if (maybe-value-set? family)
(string-append " " (serialize-field-name field) " "
(cond ((= family AF_INET) "inet")
((= family AF_INET6) "inet6")
;; The 'else' branch is unreachable.
(else (raise (condition ()
- "\n")))
+ "\n")
+ ""))
(define (natural-number? obj)
(and (integer? obj) (exact? obj) (> obj 0)))
@@ -115,7 +117,7 @@ (define-configuration openssh-host
maybe-string
"Host name---e.g., @code{\"foo.example.org\"} or @code{\"192.168.1.2\"}.")
(address-family
- address-family
+ maybe-address-family
"Address family to use when connecting to this host: one of
@code{AF_INET} (for IPv4 only), @code{AF_INET6} (for IPv6 only).
Additionally, the field can be left unset to allow any address family.")
diff --git a/gnu/services/file-sharing.scm b/gnu/services/file-sharing.scm
index 5df8b0d597..75e99f20b7 100644
--- a/gnu/services/file-sharing.scm
+++ b/gnu/services/file-sharing.scm
@@ -114,10 +114,7 @@ (define-maybe string)
;; name-value pair for the JSON builder.
(set! serialize-maybe-string
(lambda (field-name val)
-(serialize-string field-name
- (if (eq? val 'unset)
- ""
- val
+(serialize-string field-name (maybe-value val ""
(define (string-list? val)
(and (list? val)
@@ -180,9 +177,9 @@ (define (serialize-file-object field-name val)
(define-maybe file-object)
(set! serialize-maybe-file-object
(lambda (field-name val)
-(if (eq? val 'unset)
-(serialize-string field-name "")
-(serialize-file-object field-name val
+(if (maybe-value-set? val)
+(serialize-file-object field-name val)
+(serialize-string field-name ""
(define (file-object-list? val)
(and (list? val)
diff --git a/gnu/services/getmail.scm b/gnu/services/getmail.scm
index ce124f6b11..0a1c34cfd3 100644
--- a/gnu/services/getmail.scm
+++ b/gnu/services/getmail.scm
@@ -111,10 +111,10 @@ (define-configuration getmail-retriever-configuration
"The type of mail retriever to use. Valid values include
@samp{passwd} and @samp{static}.")
(server
- (string 'unset)
+ string
"Name or IP address of the server to retrieve mail from.")
(username
- (string 'unset)
+ string
"Username to login to the mail server with.")
(port
(non-negative-integer #f)
@@ -143,7 +143,7 @@ (define (serialize-getmail-destination-configuration
field-name val)
(define-configuration getmail-destination-configuration
(type
- (string 'unset)
+ string
"The type of mail destination. Valid values include @samp{Maildir},
@samp{Mboxrd} and @samp{MDA_external}.")
(path
diff --git a/gnu/services/kerberos.scm b/gnu/services/kerberos.scm
index f845c1bd89..c3c7872734 100644
--- a/gnu/services/kerberos.scm
+++ b/gnu/services/kerberos.scm
@@ -39,6 +39,7 @@ (define-module (gnu services kerberos)
+;; TODO Use %unset-value and the define-maybe infrastructure.
(define unset-field (list 'unset-field))
(define (predicate/unset pred)
diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm
index 00a1c80a14..59cb486778 100644
--- a/gnu/services/messaging.scm
+++ b/gnu/services/messaging.scm
bug#56799: [PATCH 1/5] services: configuration: Add a 'maybe-value-set?' procedure.
From: Maxim Cournoyer
* gnu/services/configuration.scm (maybe-value-set?): New procedure.
* doc/guix.texi (Complex Configurations): Document it. Remove comment showing
usage of 'maybe-string' with a default value, which doesn't make sense.
Co-authored-by: Attila Lendvai
---
doc/guix.texi | 7 ++-
gnu/services/configuration.scm | 15 ++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 86cfe7d49c..039df29ebc 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -38999,7 +38999,7 @@ to be a string, or left unspecified.
(name
;; If set to a string, the `serialize-string' procedure will be used
;; to serialize the string. Otherwise this field is not serialized.
- maybe-string; equivalent to (maybe-string *unspecified*)
+ maybe-string
"The name of this module."))
@end lisp
@@ -39030,6 +39030,11 @@ whether its value is set or not.
@end lisp
@end deffn
+@deffn (Scheme Procedure) maybe-value-set? @var{value}
+Predicate to check whether a user explicitly specified the value of a
+maybe field.
+@end deffn
+
@deffn {Scheme Procedure} serialize-configuration @var{configuration} @
@var{fields}
Return a G-expression that contains the values corresponding to the
diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
index 3007e8de35..e2c4fe9998 100644
--- a/gnu/services/configuration.scm
+++ b/gnu/services/configuration.scm
@@ -57,6 +57,7 @@ (define-module (gnu services configuration)
serialize-configuration
define-maybe
define-maybe/no-serialization
+maybe-value-set?
generate-documentation
configuration->documentation
empty-serializer
@@ -142,7 +143,8 @@ (define (define-maybe-helper serialize? prefix syn)
(id #'stem #'serialize-maybe- #'stem
#`(begin
(define (maybe-stem? val)
- (or (eq? val 'unset) (stem? val)))
+ (or (not (maybe-value-set? val))
+ (stem? val)))
#,@(if serialize?
(list #'(define (serialize-maybe-stem field-name val)
(if (stem? val)
@@ -260,11 +262,10 @@ (define #,(id #'stem #'stem #'-fields)
(default-value-thunk
(lambda ()
(display '#,(id #'stem #'% #'stem))
- (if (eq? (syntax->datum field-default)
- 'unset)
+ (if (maybe-value-set? (syntax->datum field-default))
+ field-default
(configuration-missing-default-value
- '#,(id #'stem #'% #'stem) 'field)
- field-default)))
+ '#,(id #'stem #'% #'stem) 'field
(documentation doc))
...
@@ -300,6 +301,10 @@ (define-configuration stem (field field-type+def
(define (empty-serializer field-name val) "")
(define serialize-package empty-serializer)
+(define (maybe-value-set? value)
+ "Predicate to check whether a 'maybe' value was explicitly provided."
+ (not (eq? 'unset value)))
+
;; A little helper to make it easier to document all those fields.
(define (generate-documentation documentation documentation-name)
(define (str x) (object->string x))
--
2.35.1
bug#56799: [PATCH 3/5] services: configuration: Add maybe-value exported procedure.
* gnu/services/configuration.scm (maybe-value): New procedure. --- gnu/services/configuration.scm | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index a9426066b9..60965486a7 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -58,6 +58,7 @@ (define-module (gnu services configuration) define-maybe define-maybe/no-serialization %unset-value +maybe-value maybe-value-set? generate-documentation configuration->documentation @@ -315,6 +316,15 @@ (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." (not (eq? %unset-value value))) +;; Ideally there should be a compiler macro for this predicate, that expands +;; to a conditional that only instantiates the default value when needed. +(define* (maybe-value value #:optional (default #f)) + "Returns VALUE, unless it is the unset value, in which case it returns +DEFAULT." + (if (maybe-value-set? value) + value + default)) + ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) (define (str x) (object->string x)) -- 2.35.1
bug#56799: [PATCH 5/5] services: configuration: Change the value of the unset marker.
The new value of %unset-value sticks out more when something goes wrong, and is also more unique; i.e. easier to search for. --- gnu/services/configuration.scm | 5 +++-- gnu/services/messaging.scm | 2 +- tests/services/configuration.scm | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index 60965486a7..83da63c1b3 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -305,12 +305,13 @@ (define serialize-package empty-serializer) ;; Ideally this should be an implementation detail, but we export it ;; to provide a simpler API that enables unsetting a configuration -;; field that has a maybe type, but also a default value. +;; field that has a maybe type, but also a default value. We give it +;; a value that sticks out to the reader when something goes wrong. ;; ;; An example use-case would be something like a network application ;; that uses a default port, but the field can explicitly be unset to ;; request a random port at startup. -(define %unset-value 'unset) +(define %unset-value '%unset-marker%) (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm index 59cb486778..02712ede7c 100644 --- a/gnu/services/messaging.scm +++ b/gnu/services/messaging.scm @@ -95,7 +95,7 @@ (define (make-pred arg) ;; doesn't interfere with ;; define-configuration and define-maybe ;; internals. - #''unset def)) + #''%unset-marker% def)) #'(def ...) #'(target ...))) ((new-doc ...) (map (lambda (doc target) diff --git a/tests/services/configuration.scm b/tests/services/configuration.scm index 8ed4ed4b66..4f8a74dc8a 100644 --- a/tests/services/configuration.scm +++ b/tests/services/configuration.scm @@ -150,7 +150,7 @@ (define-configuration config-with-maybe-symbol (protocol maybe-symbol "")) ;;; Maybe symbol values are currently seen as serializable, because the -;;; unspecified value is 'unset, which is a symbol itself. +;;; unspecified value is '%unset-marker%, which is a symbol itself. ;;; TODO: Remove expected fail marker after resolution. (test-expect-fail 1) (test-equal "symbol maybe value serialization, unspecified" -- 2.35.1
bug#56799: [PATCH 2/5] services: configuration: Add %unset-value exported variable.
* gnu/services/configuration.scm (%unset-value): New variable. (normalize-field-type+def): Use it. (maybe-value-unset?): Use it. --- gnu/services/configuration.scm | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index e2c4fe9998..a9426066b9 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -57,6 +57,7 @@ (define-module (gnu services configuration) serialize-configuration define-maybe define-maybe/no-serialization +%unset-value maybe-value-set? generate-documentation configuration->documentation @@ -172,10 +173,10 @@ (define (normalize-field-type+def s) (values #'(field-type def))) ((field-type) (identifier? #'field-type) - (values #'(field-type 'unset))) + (values #'(field-type %unset-value))) (field-type (identifier? #'field-type) - (values #'(field-type 'unset) + (values #'(field-type %unset-value) (define (define-configuration-helper serialize? serializer-prefix syn) (syntax-case syn () @@ -301,9 +302,18 @@ (define-configuration stem (field field-type+def (define (empty-serializer field-name val) "") (define serialize-package empty-serializer) +;; Ideally this should be an implementation detail, but we export it +;; to provide a simpler API that enables unsetting a configuration +;; field that has a maybe type, but also a default value. +;; +;; An example use-case would be something like a network application +;; that uses a default port, but the field can explicitly be unset to +;; request a random port at startup. +(define %unset-value 'unset) + (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." - (not (eq? 'unset value))) + (not (eq? %unset-value value))) ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) -- 2.35.1
bug#57159: rust-gmp-mpfr-sys bundles gmp, mpc and mpfr
> unless some new rust packages were added that depend on rust-gmp-mpfr-sys, > there's probably no dependant of it, and in that case it can be safely > removed. i can't deal with this, lacking time and rust knowledge. i suggest the removal of this package. $ ./pre-inst-env guix refresh --list-dependent rust-gmp-mpfr-sys No dependents other than itself: rust-gmp-mpfr-sys@1.4.7 apologies for the inconvenience, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Desire is a contract you make with yourself to be unhappy until you get what you want.” — Naval Ravikant
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
> > would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? > > > unset-value? sounds like an action; so I'd name it 'maybe-value-unset?'; > but as I wrote above I don't really see the benefit/like the idea. it's always funny when two non-native speakers (?) argue about english... :) maybe we should invite one into the conversation? with that in mind: UNSET-VALUE? certainly doesn't look like an action to me due to the question mark at the end. if we want to clearly disambiguate this, then we should insert 'is' somewhere, e.g. IS-UNSET-VALUE? which is a short version of IS-IT-THE-UNSET-VALUE?, i.e. it is not a shorthand for IS-THIS-VALUE-UNSET?, because only places can be in the state of not set. does this clarify my perspective? it's not crucial, though. i can work my way through the changes without renaming this, but it'll be public API, so it's better to have something intuitive and non-misleading published at the earliest possible iteration. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “I sincerely believe that banking establishments are more dangerous than standing armies, and that the principle of spending money to be paid by posterity, under the name of funding, is but swindling futurity on a large scale.” — Thomas Jefferson (1743–1826)
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
> I had used maybe-value-set? because the maybe values are define via the > 'define-maybe' syntax; they are not really part of > 'define-configuration' and are sometimes used outside of it, such as in > (guix home ssh). oh! i wasn't aware of that. > An exported variable seems simplest and perhaps less awkward to use, > e.g. %unset or similar, although it's a bit ugly that we need to reify > an unspecified value :-). yeah, i started work on implementing an UNSET! function, and its API would be unnecessarily complex with a (type, field-name, instance) signature, and going through generic slot access in its implementation. > prepare a patch for the other things mentionned here (an exported > symbol). i started implementing your suggestions, including the replacement of the scattered usage of (eq? 'unset ...) pattern. what i found is that the code is not very readable using MAYBE-VALUE-SET?, or at least not for me. first, it negates the boolean logic everywhere in the current code (i.e. larger diff, and/or the use of (if (not ...) a b)). and an example wrt readability: (if (maybe-value-set? field-default) field-default (configuration-missing-default-value ...) a value is never set, only places can be set to some value. would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? then the boolean logic would remain the same, and the above example would look like: (if (unset-value? field-default) (configuration-missing-default-value ...) field-default) short of a response i'll continue working towards this in the following days and send a proposal eventually, but if you're very much unhappy about it, then let me know! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- That, which is not falsifiable, can never be true.
bug#57159: rust-gmp-mpfr-sys bundles gmp, mpc and mpfr
sorry about that! some update on its background: meanwhile development on openethereum has been abandoned in favor of nethermind. unless some new rust packages were added that depend on rust-gmp-mpfr-sys, there's probably no dependant of it, and in that case it can be safely removed. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The ultimate, hidden truth of the world is that it is something that we make, and could just as easily make differently.” — David Graeber (1961–2020)
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
> OK, I've reread this, and it is indeed a risk, that 'unset could leak in > the case of a serializable configuration making use of a maybe-value > field of type maybe-symbol. I've added the unit test suggested as > 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected > to fail'). Luckily no current service uses that. thank you for that Maxim! and sorry for my initial, somewhat reactive, and emotionally driven response earlier! maintaining a channel with complex services, and finally getting the changes i needed merged into Guix proper was a source of frustration for me. i've looked at the current state of the code, and it looks good to me. the only issues i have left are the following: 1) the (eq 'unset ...) scattered around the code; it should be hidden behind an explicit abstraction, but you yourself mentioned this already in an earlier mail. i'd call it CONFIGURATION-FIELD-SET? (instead of MAYBE-SET?). it's longer, but we have completion in emacs, and it won't be used a gazillion times all around the code either. 2) the lack of an abstraction for the unset/unspecified value. whatever we use as the marker should be hidden behind either an exported global variable, or a function called UNSET-CONFIGURATION-FIELD! (or something alike). i should have introduced these myself, and then your fix would have been as simple as replacing *UNSPECIFIED* with 'UNSET in the abstraction. 3) the SYMBOL? corner case that your test captures, but it's not a burning issue for me (it doesn't affect the user facing API, once the above leakages are fixed). do you agree? if yes, will you implement it, or shall i prepare a patch? one more note: sometimes it's useful to have a field with a maybe type that also has a default, together with the ability to explicitly unset this field. an example would be a port specification for a torrent client: it has some default port, but it's possible to explicitly unset the port value to request the allocation of a random port at startup. to better accommodate for this use case, 2) should probably be implemented not as an UNSET-FOO! function, but as a global variable holding the unset value marker. or maybe both? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “There is only one thing more harmful to society than an elected official forgetting the promises he made in order to get elected; that's when he doesn't forget them.” — John McCarthy (1927–2011), father of Lisp
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
> i'm obviously not aware of the entire complexity here, othrwise > there wouldn't have remained a bug... but regardless of the actual > API/value used, i don't see how any of this could work without the > service code explicitly checking for the unspecified value for > fields that have a maybe type (i.e. whose type allows the value to > be unspecified). i think using a symbol instead of unspecified only > pushes the appearance of the symptoms farther away both in time and > space (otherwise there should have been a trivial fix to this > without changing unspecified back to 'unset). sorry, i was wrong/slow here^. i think i finally understand what the original issue was that triggered the rollback: the *UNSPECIFIED* value cannot get through the GExp serialize/deserialize operation between the host/builder (or how do we call it?) and Shepherd. the checks in the service code that handle the unspecified field values only happen when Shepeherd is executing the deserialized GExp's. the fix i would propose is to smarten up GExp serialization to handle whichever value we use as the marker, be it 1) *UNSPECIFIED*, or 2) Nothing from srfi-189, or 3) a record instance that we define/instantiate ourselves. i don't recommend 3). we should rather use srfi-189 then, because it sandardizes widely known concepts. so, would you accept a patch that implements 1) or 2) ? 2) has non-trivial uncertainties/complexities in making srfi-189 available in all the required contexts, and not introducing any bootstrap related issues in the process. because of that i would recommend getting to 2) by first implementing 1) and then working towards 2) -- if we want to use srfi-189 at all, that is. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “What's done to children, they will do to society.” — Karl A. Menninger (http://psychohistory.com/)
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
i got back online... > That said, whether it’s ‘unspecified?’ or something else, you have to > have a check in place, right? With the new interface it becomes: > > (if (eq? port 'unset) #f port) > > Or you can provide an actual default value (an integer in this case), > but that’s possible whether or not unspecified is the default value. i agree. > With the xvnc example, I better understand the kind of situation where > a field value might end up directly in a gexp, though I’m still unsure > whether use of unspecified really makes things worse. At least, > because it lacks a read syntax, the problem is caught early on; whereas > with 'unset, you might end up stuffing 'unset in your config file > without noticing. i agree with this, too. also, seems like it didn't register in this discussion, so i press it once again: if the default/unspecified value is a symbol (any symbol), then those configuration fields, whose type is set to be of symbol, will not error when they are left unspecified. (see the FIELD-SANITIZER: it simply does a (IF (PRED VALUE) ...) check, which doesn't fail because 'UNSET satisfies SYMBOL?). i should have added a unit test for this... i think moving back from *UNSPECIFIED* to using 'UNSET only has drawbacks. and if it works (read: it doesn't error out while guix is deploying the config), then it probably produces illegal config files by serializing the unspecified value into an "unset" string in the config files. i'm obviously not aware of the entire complexity here, othrwise there wouldn't have remained a bug... but regardless of the actual API/value used, i don't see how any of this could work without the service code explicitly checking for the unspecified value for fields that have a maybe type (i.e. whose type allows the value to be unspecified). i think using a symbol instead of *unspecified* only pushes the appearance of the symptoms farther away both in time and space (otherwise there should have been a trivial fix to this without changing *unspecified* back to 'unset). either way, if there was a failing test case that i could run locally, then i would have been more than happy to fix it... now i'm only dismayed that all my service code, and my entire channel got broken. seems like i went offline in the worst two weeks. sidenote: what srfi-189 does is basically introduce such a special value that we are trying to hone in on here (i.e. Nothing, which is implemented as a record instance) in a standardized way, and also an API to deal with this special value in various different contexts (i.e. it exports stuff like MAYBE-IF, MAYBE-FOLD, MAYBE-AND, etc). https://srfi.schemers.org/srfi-189/srfi-189.html -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Although teachers do care and do work very, very hard, the institution is psychopathic-it has no conscience. It rings a bell and the young man in the middle of writing a poem must close his notebook and move to a different cell where he must memorize that humans and monkeys derive from a common ancestor.” — John Taylor Gatto (1935–), 'Dumbing Us Down: The Hidden Curriculum of Compulsory Education' (1992)
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
hi, sorry for the headaches! the original discussion is here (well, i think. site is down right now): https://issues.guix.gnu.org/54674 'UNSPECIFIED would satisfy SYMBOL?, i.e. a source of headaches/confusion. it used to be 'DISABLED, which was even worse as it can be confused/conflated with a user specified value. i suggested the use of srfi-189, but it was rejected as unwelcome complexity. https://srfi.schemers.org/srfi-189/srfi-189.html i think it makes sense to change Guile to make *unspecified* self-evaluating, but looking back, maybe the use of srfi-189 would have been better. i need to run now, and i'll be offline for a week or two. i can't look the example in depth now, but my gut instinct says that it's a bug if *unspecified* reaches any GExp machinery. more later, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If you are neutral in situations of injustice, you have chosen the side of the oppressor.” — Desmond Tutu (1931–)
bug#56780: rottlog ignores the subdir structure
my service puts its log files into subdirs under /var/log/myservice/some-config/logfile. i set up some rottlog-service-type and rottlog-configuration to rotate these log files, and to my surprise rottlog puts them under /var/log (ignoring the subdir structure). is this a feature or a bug? if the former, could we change the default to put the rotated files into the same directory as the files being rotated? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “A political situation is the manifestation of a parallel psychological problem in millions of individuals. This problem is largely unconscious (which makes it a particularly dangerous one!)” — Carl Jung (1875–1961), Letters, vol.1 pg. 535
bug#56005: In procedure write_wait_fd: unimplemented
i'm also seeing this every once in a while. some speculation: my router has QoS set up that limits the upstream, so that i avoid triggering my ISP's rate limiter, because it sends ping into the ballpark of seconds. maybe because of this config i'm seeing this more regularly than others? - attila
bug#55949: installing HP printer using Gnome Settings fails
i have a HP printer connected on USB, and hplip-minimal is installed. the printer is detected in Gnome Settings, but installing it fails. i see the following in the cups log afterwards: [cups-driverd] Unable to open driver directory \"/gnu/store/rwrmqxklbdq85lwjgjl56r9zh54066ra-cups-server-bin/lib/cups/driver\": No such file or directory installing the printer using the CUPS web interface works, and afterwards printing works, too. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “All wars are civil wars, because all men are brothers […] Each one owes infinitely more to the human race than to the particular country in which he was born.” — Francois Fenelon
bug#55464: (current-filename) is #f when guix pull'ing
> > (define-public foo
> > (let ((hashes
> > (with-input-from-file
> > (string-append (dirname (current-filename))
> > "/foo.hashes")
> > read)))
> > (package ...)))
>
>
> Not fully answering your question, but if “foo.hashes” contains hashes
> for origins and similar, you could make “foo.hashes” contain something
> like:
>
> (list (base32 …) …)
>
> and, in the .scm, write:
>
> (include "foo.hashes")
>
> The ‘include’ directive includes the file at macro-expansion time,
> similar to #include in C.
i did find guile's INCLUDE and tried to use it, but it also didn't work when
guix pull'ing it. see the attached, now abandoned commit.
IIRC the issue is that the implementation of INCLUDE tries to load the file
relative to the cwd, but cwd is not changed by the code that is driving the
compilation when guix pull'ing the code. (does each thread has its own cwd at
all...?)
it works when i build it using `./pre-inst-env guix build foo`. i briefly tried
to analyse what's the difference between the two situations, but i ran out of
steam.
it is the same reason i need to call READ like below in my current
implementation:
(define (%read-module-relative-file module filename)
(with-input-from-file
(or (search-path
%load-path
(string-append (dirname (module-filename module))
"/" filename))
(error "%read-module-relative-file failed for" filename))
read))
...which is not beautiful.
> Back to the original issue, I suppose ‘current-filename’ return #f when
> this .scm is first loaded, before it’s compiled. Anyway, it’s probably
> best to load it at macro-expansion time as you suggested.
is my analysis is correct, namely that cwd is not (always?) changed at
macroexpand time, and thus the implementation of INCLUDE is broken for relative
paths? is this a bug to be fixed in guile? if so, shall i try to add a test
case for this somewhere?
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The saddest aspect of life right now is that science gathers knowledge faster
than society gathers wisdom.”
— Isaac Asimov (1920–1992)
From 20f815592708862a336f1937aa792e5dc356b1b4 Mon Sep 17 00:00:00 2001
From: Attila Lendvai
Date: Tue, 17 May 2022 14:35:01 +0200
Subject: use guile's INCLUDE instead of our own way to read a file
diff --git a/bin/release-update-helper.scm b/bin/release-update-helper.scm
index 6545630..3c8eddb 100755
--- a/bin/release-update-helper.scm
+++ b/bin/release-update-helper.scm
@@ -129,7 +129,7 @@
(false-if-exception (delete-file db-file))
(with-output-to-file db-file
(lambda ()
- (format #t ";; This file was generated by the ~A script~%"
+ (format #t ";; This file was generated by the ~A script~%'"
(basename (current-filename)))
(write db)
(format #t "Finished successfully~%")))
diff --git a/src/guix-crypto/package-utils.scm b/src/guix-crypto/package-utils.scm
index 1877890..680d591 100644
--- a/src/guix-crypto/package-utils.scm
+++ b/src/guix-crypto/package-utils.scm
@@ -21,26 +21,7 @@
#:use-module (guix diagnostics)
#:use-module (guix packages)
#:use-module (guix ui)
- #:use-module (ice-9 match)
- #:export (read-module-relative-file))
-
-(define (%read-module-relative-file module filename)
- (with-input-from-file
- (or (search-path %load-path
- (string-append (dirname (module-filename module))
- "/" filename))
- (error "%read-module-relative-file failed for" filename))
-read))
-
-(define-syntax read-module-relative-file
- (lambda (syn)
-(syntax-case syn ()
- ((_ filename)
- (with-syntax
- ;; Read the file at compile time and macroexpand to the first form.
- ((form (%read-module-relative-file (current-module)
- (syntax->datum #'filename
- #''form)
+ #:use-module (ice-9 match))
(define-public (unsupported-arch package-name system)
(raise (formatted-message
diff --git a/src/guix-crypto/packages/bee-binary.hashes b/src/guix-crypto/packages/bee-binary.hashes
index 6ddc1c0..382d2c9 100644
--- a/src/guix-crypto/packages/bee-binary.hashes
+++ b/src/guix-crypto/packages/bee-binary.hashes
@@ -1,2 +1,2 @@
;; This file was generated by the release-update-helper.scm script
-(("aarch64-linux" . "1fjx9hw23dg20k4iz0imd33wsnlwxkjs9z39b4kakzpf4h89wrnl") ("x86_64-linux" . "18hs1mx50hdgqy1xzppfl0mcf7y2h23qs8qr74jzk5f34ixqhg4d") ("i686-linux" . "0fs5wqjh7qvdcmbbnl34m1j4ja7rl831dixaz3bznb4ys7lmlsjr"))
\ No newline at end of fil
bug#55464: alternative way
as Ludovic kindly pointed out on IRC, i can use this instead: (module-filename (current-module)) unfortunately, this returns a relative path, which is only useful using (search-path %load-path ...), which introduces some uncertainty about what actually gets loaded depending on the runtime value of %load-path... :| therefore, i decided to read the file at macroexpand-time. after some struggle with hygienic macros: (define-syntax read-module-relative-file (lambda (syn) (syntax-case syn () ((_ filename) (with-syntax ;; Read the file at compile time and macroexpand to the first form. ((form (%read-module-relative-file (current-module) (syntax->datum #'filename #''form) (define (%read-module-relative-file module filename) (with-input-from-file (or (search-path %load-path (string-append (dirname (module-filename module)) "/" filename)) (error "%read-module-relative-file failed for" filename)) read)) not beautiful, but works. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “It is just as difficult and dangerous to try to free a people that wants to remain servile as it is to enslave a people that wants to remain free.” — Niccolò Machiavelli (1469–1527)
bug#55464: (current-filename) is #f when guix pull'ing
the actual context where i'm encountering this is a package definition where i want to load some hashes from a file relative the to the .scm file: (define-public foo (let ((hashes (with-input-from-file (string-append (dirname (current-filename)) "/foo.hashes") read))) (package ...))) this works fine in a `./pre-inst-env build foo`, but i think there's something special in how `guix pull` compiles the scm files, and (c-f) expands to #f. guix pull works, but afterwards: $ guix system --on-error=backtrace reconfigure --allow-downgrades /etc/guix/config.scm guix system: error: failed to load '/etc/guix/config.scm': guix-crypto/packages/ethereum.scm:47:36: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f In ice-9/boot-9.scm: 222:29 19 (map1 (((gnu)) ((gnu system)) ((gnu system #)) ((# …)) …)) 222:29 18 (map1 (((gnu system)) ((gnu system file-systems)) (#) …)) 222:29 17 (map1 (((gnu system file-systems)) ((oop goops)) ((…)) …)) 222:29 16 (map1 (((oop goops)) ((shepherd service)) ((nongnu …)) …)) 222:29 15 (map1 (((shepherd service)) ((nongnu packages linux)) …)) 222:29 14 (map1 (((nongnu packages linux)) ((guix-crypto # #)) # …)) 222:17 13 (map1 (((guix-crypto packages ethereum)) ((# # #)) (#) …)) 3936:31 12 (_ ((guix-crypto packages ethereum))) 3327:17 11 (resolve-interface (guix-crypto packages ethereum) # _ # …) In ice-9/threads.scm: 390:8 10 (_ _) In ice-9/boot-9.scm: 3253:13 9 (_) In ice-9/threads.scm: 390:8 8 (_ _) In ice-9/boot-9.scm: 3544:20 7 (_) 2836:4 6 (save-module-excursion #) 3564:26 5 (_) In unknown file: 4 (primitive-load-path "guix-crypto/packages/ethereum" #<…>) In guix-crypto/packages/ethereum.scm: 47:36 3 (_) In unknown file: 2 (dirname #f) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1780:13 0 (_ #< components: (#<…>) i would be happy to avoid using (c-f), but i failed to find a way in Guile's module reflection API. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “People who have never gone to school have never developed negative attitudes toward exploring their world.” — Grace Llewellyn
bug#55337: display-download-progress: wrong type error
while running a `make check-system` on a flaky network (unstable ipv4 tunnel on a native ipv6 connection). the linu number points to: (unless (zero? transferred) ...) Backtrace: 19 (apply-smob/0 #) In ice-9/boot-9.scm: 724:2 18 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 17 (_ #(#(#))) In guix/ui.scm: 2230:7 16 (run-guix . _) 2193:10 15 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/status.scm: 809:4 13 (call-with-status-report _ _) In ice-9/boot-9.scm: 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 658:37 11 (thunk) 1320:8 10 (call-with-build-handler _ _) 1320:8 9 (call-with-build-handler # _) In guix/scripts/build.scm: 717:27 8 (_) In guix/store.scm: 1421:15 7 (_ # _ _) 759:14 6 (process-stderr _ _) In unknown file: 5 (display "@ substituter-succeeded /gnu/store/skdygnanqswb92sgzi7gbgc1smy8i5rq-docker-pack.tar.gz\n" #) In guix/status.scm: 732:16 4 (write! _ _ _) 646:6 3 (_ (download-progress "/gnu/store/skdygnanqswb92sgzi7gbgc1smy8i5rq-docker-pack.tar.gz" "https://ci.guix.gnu.org/nar/skdygnanqswb92sgzi7gbgc1s@; "substit…" …) …) In guix/progress.scm: 223:17 2 (display-download-progress "skdygnanqswb92sgzi7gbgc1s@" _ #:tty? _ #:start-time _ #:transferred _ #:log-port _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure =: Wrong type argument in position 1: #f (random sidenote: i have also experienced "In procedure write_wait_fd: unimplemented" in other runs) -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Discipline is helping a child solve a problem. Punishment is making a child suffer for having a problem. To raise problem solvers, focus on solution not retribution.” — L. R. Knost
bug#55270: unpack phase randomly changes the cwd
> It takes the first result 'scandir' -- i.e., the 'smallest' file name
> according to string-locale reproducibility problems)
fair enough. what i meant to communicate is that it's arbitrary, not random.
another potential issue:
if the root of the archive contains a file called 'environment-variables', then
this way it would overwrite the one generated by Guix. this may not necessarily
be an issue, though, if that file is never used after the unpack phase.
maybe the cleanest would be to:
1) mkdir a directory ('extracted/'?) and chdir into it prior to
unpacking, and
2) only do the DWIM chdir if the toplevel of the archive was a single
dir.
but i lack the necessary perspective to see all the implications.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There is always a philosophy for lack of courage.”
— Albert Camus (1913–1960)
bug#55270: unpack phase randomly changes the cwd
at the end of the unpack phase, the working directory is changed to a random directory. https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm#n178 this is fine *when* the archive contains a single dir... but this DWIM'ness has just burned 15 mintues of my life, and i recommend removing it. if it is to stay, then at least it should be patched that it only happens when the dir after extraction only contains a single subdir, and no files otherwise. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “When men hire themselves out to shoot other men to order, asking nothing about the justice of their cause, I don’t care if they are shot themselves.” — Herbert Spencer (1820–1903), during Britain's second Afghan war
bug#54893: [PATCH] guix: git-download: Set locale to deal with Unicode in git metadata.
Without this the git-fetch GEXP is run in an environment that uses ASCII character encoding when strings are crossing the Guile - C boundary. It means that e.g. tag names that have Unicode chars in them will cause problems, e.g. when walking and deleting the .git directory. An example in the wild: https://github.com/klauspost/pgzip/tags For more details see: https://issues.guix.gnu.org/54893 * guix/git-download.scm (git-fetch): Call setlocale to set it to en_US.utf8. --- thanks Maxime, this indeed seems to work! and i have successfully guix pull'ed it, too. guix/git-download.scm | 10 ++ 1 file changed, 10 insertions(+) diff --git a/guix/git-download.scm b/guix/git-download.scm index 5e624b9ae9..2fc5a06490 100644 --- a/guix/git-download.scm +++ b/guix/git-download.scm @@ -104,6 +104,9 @@ (define guile-zlib (define gnutls (module-ref (resolve-interface '(gnu packages tls)) 'gnutls)) + (define glibc-locales +(module-ref (resolve-interface '(gnu packages base)) 'glibc-locales)) + (define modules (delete '(guix config) (source-module-closure '((guix build git) @@ -121,6 +124,13 @@ (define build (guix build download-nar) (guix swh) (ice-9 match)) +;; We must set the locale to something/anything that will make the +;; Guile FFI use a character encoding that is idempotent through a +;; bytes->string string->bytes roundtrip. Otherwise e.g. git tags +;; with Unicode characters would break things. For more details +;; and an example see https://issues.guix.gnu.org/54893 +(setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale")) +(setlocale LC_ALL "en_US.utf8") (define recursive? (call-with-input-string (getenv "git recursive?") read)) -- 2.35.1
bug#54893: guix-daemon, locale, LANG, and unicode in git tag names
> thank you, this works indeed as a band aid: > > (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale")) > (setlocale LC_ALL "en_US.utf8") i spoke too early. this works in a git checkout of guix, but it fails to compile when i try to guix pull it. even if i declare the dependency like this: #:autoload (gnu packages base) (glibc-locales) IIUC, this is due to a circular dependency: glibc-locales (and its variants) depend on git-fetch, therefore i cannot refer to them from the implementation of git-fetch. i tried to set the locale to "C" or "POSIX", but it results in ASCII encoding. i tried to set the locale to "en_US.iso-8859-1", hoping that it's available, but it isn't. all that is needed here is an encoding that is idempotent wrt a cycle through bytes->string, string->bytes. i think the iso-8859-n encodings are like that. to verify that hypothesis: $ mkdir -p /tmp/delme/v½.2.0 $ LANG=C guix repl scheme@(guix-user)> (use-modules (guix build utils)) scheme@(guix-user)> (delete-file-recursively "/tmp/delme") warning: failed to delete /tmp/delme/v??.2.0: No such file or directory warning: failed to delete /tmp/delme: Directory not empty $1 = #t $2 = # scheme@(guix-user)> $ LANG=en_US.iso-8859-1 guix repl scheme@(guix-user)> (use-modules (guix build utils)) scheme@(guix-user)> (delete-file-recursively "/tmp/delme") $1 = # scheme@(guix-user)> so, is such an idempotent locale available/embedded in glibc without any external dependencies? searching the web suggests that there isn't. if not, then what would be a bird's eye view plan to make one available for git-fetch? should we create a new, ASCII-only git-fetch variant used in the bootstrap process? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The world is changed by your example, not by your opinion.” — Paulo Coelho (1947–)
bug#52362: another patchset
FYI, i have extensive fixes to the go importer that i'm preparing for submission: https://github.com/attila-lendvai-patches/guix/tree/import it fixes this issue, and it can also recursively import rclone (and go-ethereum for that matter): ./pre-inst-env guix import go --recursive github.com/rclone/rclone emits 100+ packages. unfortunately, it fails on/skips: guix import go github.com/billziss-gh/cgofuse i suspect that it's probably because that module is not adhering to the git tag name rules. -- - attila PGP: 5D5F 45C7 DFCD 0A39
bug#54893: guix-daemon, locale, LANG, and unicode in git tag names
> I don't expect /run/current-system/locale to exist inside the build > container. Maybe try > > (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale")) > ;; for testing > ((@ (guix build utils) invoke) > #+(file-append coreutils "/bin/ls") (getenv "GUIX_LOCPATH")) > > instead? thank you, this works indeed as a band aid: (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale")) (setlocale LC_ALL "en_US.utf8") -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.” — Thomas Jefferson (1743–1826)
bug#54893: guix-daemon, locale, LANG, and unicode in git tag names
> * LANG should be set, because it is in #:leaked-env-vars (see > guix/git-download.scm). I don't know whose LANG it is though > -- the user's, or the daemon's? if i add this to the gexp: (simple-format (current-error-port) "LANG is '~A'~%" (getenv "LANG")) (setenv "LANG" "en_US.utf8") (setenv "GUIX_LOCPATH" "/run/current-system/locale") (setlocale LC_ALL (getenv "LANG")) i see: LANG is '' Backtrace: 2 (primitive-load "/gnu/store/z4bis94jg0s0y0xj1xbmliv7xs8?") In ice-9/eval.scm: 619:8 1 (_ #f) In unknown file: 0 (setlocale 6 "en_US.utf8") ERROR: In procedure setlocale: In procedure setlocale: Invalid argument > * GUIX_LOCPATH is not leaked. it's the same if i add GUIX_LOCPATH to the #:leaked-env-vars and don't setenv it explicitly. > * Even if it was, I don't think that /gnu/store/...glibc-locales > would be accessible from the build container (though you could give > it a try?). i didn't check this specifically, but i'm afraid you are right, and this is why my kludge doesn't work. > * So perhaps GUIX_LOCPATH needs to be set in the gexp in > guix/git-download.scm, + some setlocale as done by > gnu-build-system. i don't understand why the setlocale call in gnu-build-system's install-locale works, but my setlocale kludge in git-download doesn't. i even tried to add glibc-locale as native-inputs to the package in question, but it didn't help. > * Long-term, it could be interesting to remove the > ‘file name = string encoded in current locale's encoding’ > assumption from Guile. i'm not sure why the wrong locale breaks file-system walking and deleting, though. i assume if every function in guile uses/assumes the same locale (character encoding), then both directions through the guile FFI should be idempotent, no? and i think both ASCII and UTF-8 are idempotent wrt C bytes <-> scheme string conversions. IOW, it's only the displaying of the chars that should be broken, not file operations. or am i wrong to assume this? or maybe the character encoding algo used in guile's FFI silently emits actual question marks in place of bytes that are outside the valid range of the encoding used? if so, that's not a very defensive way of coding, and it's eating up hours of my life... hrm... this is not relevant here, only a related thought: things can go wrong in the GEXP serialization, too: if the writing side and the reading side doesn't use the same character encoding. locale should be set explicitly at the relevant entry points. i'd appreciate if someone could help me come up with at least a kludge, so that i could make progress until it's fixed properly. thanks for your insights Maxime, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- If you never heal from what hurt you, you'll bleed on people who didn't cut you.
bug#54893: guix-daemon, locale, LANG, and unicode in git tag names
i'm trying to build a golang package that i have just imported. its repo has a
tag with unicode in it, namely v½.2.0, as observable at
https://github.com/klauspost/pgzip/tags
(define-public the-pkg
(package
(name "go-github-com-klauspost-pgzip")
(version "1.0.2-0.20170402124221-0bf5dcad4ada")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/klauspost/pgzip;)
(commit "0bf5dcad4ada")))
(file-name (git-file-name name version))
(sha256
(base32 "0dgp2iljvhibzxia1g3lsfg4bjmfh4kf0bfrmfi7sd49hwhrvk7s"
(build-system go-build-system)
(arguments '(#:skip-build? #t #:import-path "github.com/klauspost/pgzip"))
(home-page "https://github.com/klauspost/pgzip;)
(synopsis "pgzip")
(description
"Package pgzip implements reading and writing of gzip format compressed
files, as
specified in @url{https://rfc-editor.org/rfc/rfc1952.html,RFC 1952}.")
(license license:expat)))
i have attached the build log, but the essence is this:
guile: warning: failed to install locale
and i can't get rid of this^ warning. i installed glibc-locales to root and my
user, reconfigured, restarted the guix-daemon.
which is probably the cause of the ultimate error:
warning: failed to delete .git/refs/tags/v??.2.0: No such file or directory
r:sha256 hash mismatch for...
the daemon starts from an empty env:
https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n1590
and then copies the env from the derivation, but it doesn't seem to contain any
LANG value. i assume guile is also launched then without a LANG env. BTW, guile
could be more informative in its warning, too.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The unexamined life is not worth living for a human being.”
— Socrates (c. 470–399 BC, tried and executed), 'Apology' (399 BC)
build-log
Description: Binary data
bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system
FTR, the issue is that when Shepherd is booting up, i.e. starting from its config file, it calls the start forms without guarding for any possible exceptions. any error propagates up beyond the loop and up until an unwind protect that deletes the socket. the reason my system seemed fully functional is that my service was pretty much the last one to be started. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind.” — Alan Kay, OOPSLA '97
bug#53047: (No Subject)
closing it because i don't see this anymore, and i have no idea what triggered this error, and what has resolved it. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Governments don’t want a population capable of critical thinking. They want obedient workers, people just smart enough to run the machines and just dumb enough to passively accept their situation.” — George Carlin (1937–2008), paraphrased
bug#41791: [Shepherd] loses track of Tor
i'm not sure this is related, but it's certainly a bug in MAKE-KILL-DESTRUCTOR that it doesn't wait for the process to quit after sending it a signal, and thus may restart the service while the previous instance is still running. it's also not sending it a kill -9 after a timeout if the process is not responsive. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “[Design] Patterns mean "I have run out of language."” — Rich Hickey
bug#53657: inconsistent parsing of the channel sexp's
pull.scm does this with channel files, e.g. with /etc/guix/channels.scm: (load* file (make-user-module '((guix channels i.e. this way field values are EVAL'd. beside the big can of worms that this opens up, it also means that e.g. the name field must be quoted: (name 'guix). then at other occurrences of channels, an sexp parser is used to read them, e.g. in the 'dependencies field of a .guix-channel entry. see READ-CHANNEL-METADATA in guix/channels.scm. here the name field is not EVAL'd, and thus it must be specified without quotes: (name guix). this leads to an actual issue that channel dependencies don't match up, unless the name is without quotes in the dependencies list specification. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Awareness isn’t something we own; awareness isn’t something we possess. Awareness is actually what we are.” — Adyashanti (1962–)
bug#53580: (No Subject)
i forgot to add that i'm working on a shepherd service, and this may be due to errors in the service's user code, like the start gexp.
bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system
the systems seems to work fine. Gnome is up, i can log in with my user, and everything seems to work, except herd. i encounter this broken state every once in a while. IRC logs also mention this multiple times, but without many insights: https://logs.guix.gnu.org/guix/search?query=%2Fvar%2Frun%2Fshepherd%2Fsocket ``` # herd status error: connect: /var/run/shepherd/socket: No such file or directory # ps afxu | grep shepherd root 1 0.0 0.3 160788 43684 ?Sl 11:51 0:00 /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile --no-auto-compile /gnu/store/vza48khbaq0fdmcsrn27xj5y5yy76z6l-shepherd-0.8.1/bin/shepherd --config /gnu/store/q4nd803lxrlkr60s8sx88gvpb6c7lxyd-shepherd.conf # uptime 12:26:44 up 0:34, 2 users, load average: 0.00, 0.01, 0.00 ``` looking at shepherd's code: ``` (define (call-with-server-socket file-name proc) "Call PROC, passing it a listening socket at FILE-NAME and deleting the socket file at FILE-NAME upon exit of PROC. Return the values of PROC." (let ((sock (open-server-socket file-name))) (dynamic-wind noop (lambda () (proc sock)) (lambda () (close sock) (catch-system-error (delete-file file-name)) ``` maybe this is caused by some call/cc magic that causes an unwind that deletes the file, but then continues? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Above all, do not lose your desire to walk: Every day I walk myself into a state of well-being and walk away from every illness; I have walked myself into my best thoughts, and I know of no thought so burdensome that one cannot walk away from it.” — Søren Kierkegaard (1813–1855)
bug#53047: (No Subject)
i have updated my local checkout to: ``` commit 7b5f7810a7461970e03bbc7bd25259589c63394a (HEAD -> master, origin/master, origin/HEAD) Author: Mathieu Othacehe Date: Wed Jan 19 10:58:47 2022 +0100 gnu: cuirass: Update to 1.1.0-11.9f08035. * gnu/packages/ci.scm (cuirass): Update to 1.1.0-11.9f08035. ``` then i have issued: ``` $ ./pre-inst-env guix package -u qbittorrent ``` and now qbitorrent seems to work fine. may be relevant that the command resulted in a local rebuild: ``` The following package will be upgraded: qbittorrent (dependencies or package changed) substitute: updating substitutes from 'https://substitutes.nonguix.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/hl19l4i2llf3z2h794i9p27amb0xn8vg-profile.drv /gnu/store/z40jlbqv4s2wfz3jp072dsf0mvg3nd41-qbittorrent-4.2.5.drv ``` i'm not sure whether this has been fixed in master, or by the fact that it got rebuilt locally. - attila PGP: 5D5F 45C7 DFCD 0A39
bug#36667: (No Subject)
Empty Message
bug#53334: (No Subject)
i may be misunderstanding something here... but when i add python to my user's profile, then for me search does work in vanilla qBittorrent. i think the entire point of this is to keep the python dependency optional at runtime. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If you have 10,000 regulations, you destroy all respect for the law.” — Winston Churchill (1874–1965)
bug#53047: qBittorrent or libtorrent-rasterbar doesn't connect post c-u-f merge
dear Guixers, qBittorrent stopped working around the time when i reconfigured after the core-updates-frozen merge. the new behavior is that it can connect to trackers, it gets the peer list, but when i switch to the peer list tab of a specific torrent, what i see is that peers keeps showing up and then immediately disappear. the number of DHT connections also remain at zero. on my router i can see UPNP opening the relevant tcp and udp ports, and there's no firewall on the computer itself. nothing else seems to have changed in the environment, and qBittorrent on a windows machine works on the same network. - attila PGP: 5D5F 45C7 DFCD 0A39
bug#51170: tlp fullcharge
> > as of latest master, tlp fails for me with this error message: > > > > tlp fullcharge > > == > > > > /gnu/store/68mpiffl51mcrss7zy26dnqfx3d5v2vv-tlp-1.4.0/share/tlp/tlp-func-base: > > line 528: /usr/share/tlp/bat.d/[0-9][0-9]*[a-z]: No such file or directory > > > > this used to work not so long ago. > > This was fixed in commit e7b899008c34c3d420b2017b8d41e13b33d5a93c > applied on October, 8th. I cannot reproduce it. > > You may not be running a recent enough guix. Could you double-check the > output of "guix describe"? indeed, i wasn't fully pulled. sorry for the noise, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The condition upon which God hath given liberty to man is eternal vigilance; which condition if he break, servitude is at once the consequence of his crime and the punishment of his guilt.” — John Philpot Curran (1750–1817)
bug#51170: tlp fullcharge
dear Guixers, as of latest master, tlp fails for me with this error message: # tlp fullcharge /gnu/store/68mpiffl51mcrss7zy26dnqfx3d5v2vv-tlp-1.4.0/share/tlp/tlp-func-base: line 528: /usr/share/tlp/bat.d/[0-9][0-9]*[a-z]: No such file or directory this used to work not so long ago. - attila PGP: 5D5F 45C7 DFCD 0A39
bug#40039: (No Subject)
any ETA on this fix? i think i need it. i tried to add a `wrap-script-or-program` to `python-build-system`: attempt to use `wrap-scipt`, and in case of a `no-interpreter-found` error fall back to `wrap-program`. (motivated by trezor-agent relying on sys.argv[0], which is ruined by `wrap-program`) the result of my change was that building `serf` dies, and i suspect that because of this bug. the output: command "scons" "-j" "8" "APR=/gnu/store/gxq63qb00yn11vv875n7l9fffs2gmgxp-apr-1.6.5" "APU=/gnu/store/gl2wzkld26ry7xainbbbwgrz493925xn-apr-util-1.6.1" "OPENSSL=/gnu/store/ixm51m1jcfw4rhvwnd690szfv2w3pcsm-openssl-1.1.1j" "ZLIB=/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11" "PREFIX=/gnu/store/pgs8b7410lap9ax68wbq2j5kyhhb3kwf-serf-1.3.9" failed with status 127 note that after my change `scons` is wrapped as a script, not as a program. i tried to apply this fix, and retry, but it seems to cause the rebuilding of the entire world -- and i'm on a laptop... :) so, i think i'll just wait until this fix reaches main, and i'll retry after that. - attila PGP: 5D5F 45C7 DFCD 0A39
bug#33189: (No Subject)
feedback from a newcomer to Guix: i suggest a higher priority for this bug, because it affects just about anyone who installs Guix on a laptop, and whose neurons are used to natural scrolling, and/or tap to click. i have spent a couple of days annoyed until i got to resolve this issue finally (thank you Alex Griffin!). - attila PGP: 5D5F 45C7 DFCD 0A39
