bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
Hi, "buma2...@outlook.fr" skribis: > I am using happily shepherd since a few years as my init system on > Debian: amd64 (desktop and notebook), armhf (Cubox). Interesting! I didn’t know of such uses. > I was using 0.9.1 with guile-3.0.5 and fibers-1.1.1. > > I recently tried 0.10.1 with guile-3.0.9 and fibers 1.3.1 and > encountered a problem with using system and system* in my services: > the simple fact to have the symbol system or system* in > /etc/shepherd.scm or included files (even if the command is not > executed) leads to a misbehaving shepherd, more specifically the > shepherd socket disappears; the system boots but with multiple > instances of the launched daemons. > > If a system/system* command is executed while booting, shepherd > blocks at the point of its execution. > > Example of service causing the failure: > > (register-services > (make >#:provides '(mytest) >#:start (lambda args > (system "touch /tmp/somefile") > #t) >)) > > The service is not started at boot, I have to do it manually afterwards, > but I never can go there, as the shepherd socket is missing. I can reproduce it like this: --8<---cut here---start->8--- $ cat /tmp/t.conf (register-services (make #:provides '(mytest) #:start (lambda args (system "touch /tmp/somefile") #t))) (start 'mytest) $ shepherd -I -c/tmp/t.conf -s /tmp/sock Starting service root... Service root started. Service root running with value #t. Service root has been started. Starting service mytest... C-c C-z [1]+ Stopped shepherd -I -c/tmp/t.conf -s /tmp/sock $ bg [1]+ shepherd -I -c/tmp/t.conf -s /tmp/sock & $ herd -s /tmp/sock status herd: error: /tmp/sock: Connection refused --8<---cut here---end--->8--- This is both with 0.10.1 and with d5ed516e736ce473902cc86b5cf4f61f27ebb642. To be continued… Ludo’.
bug#64302: Guix derivation cannot be computed during pull
Hi, Andreas Enge skribis: > Am Fri, Jul 07, 2023 at 04:09:13PM +0200 schrieb Ludovic Courtès: >> Is it reproducible for you? Could it be a transient failure? > > It is not transient, it happens consistently. > Can I do anything myself to trick it into working? Is there any more data you can grab? Perhaps in /var/log/guix-daemon.log or similar if that’s on a foreign distro? And as a last resort, ‘strace -f -o /tmp/log -s 500 guix pull’, so we can get an idea of what happens. TIA! Ludo’.
bug#64014: guix pack regression
André A. Gomes skribis: > Ludovic Courtès writes: > >> Yes, that’d be great. If you still have that older pack that didn’t >> have the problem, you could also run it under ‘strace -f -o >> /tmp/log.strace’ to see what happens before the failure. > > Ludovic, I didn't reach any meaningful conclusion. Please close this > issue. Thanks. Done!
bug#64309: Python dlopen()s musl libc
> The nvr package in ~/.local seems to be used instead of a Guix > package. That locally installed nvr package expects to use the > host's libc, but since the python interpreter being used has a > fixed RPATH and system search path it won't find it. I've just checked and temporarily removing .local/lib/python3.10 makes Guix's nvr work, and takes the .local site-packages off sys.path. pgpz6JI82iCYQ.pgp Description: OpenPGP digital signature
bug#64309: Python dlopen()s musl libc
> So it's not the LD_DEBUG output that hold a clue, but rather the
> Python traceback.
> The nvr package in ~/.local seems to be used instead of a Guix
> package. That locally installed nvr package expects to use the host's
> libc, but since the python interpreter being used has a fixed RPATH
> and system search path it won't find it.
Ah, I see.
> .nvr-real should definitely be using the Python code inside the
> store, I wonder why that isn't being done. Maybe our
> sitecustomize.py is misbehaving? Can you do `guix shell
> python-neovim-remote python -- python3` then type `import sys.path;
> sys.path`?
$ guix shell python-neovim-remote python -- python3
>>> sys.path
['',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python310.zip',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/lib-dynload',
'/home/alm/.local/lib/python3.10/site-packages',
'/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/site-packages']
(It's not from the environment:)
$ guix shell python-neovim-remote python --pure -- python3
>>> sys.path
['',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python310.zip',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/lib-dynload',
'/home/alm/.local/lib/python3.10/site-packages',
'/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
'/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/site-packages']
>>> os.environ
environ({'HOME': '/home/alm', 'LOGNAME': 'alm', 'PAGER': 'less', 'DISPLAY':
':0', 'USER': 'alm', 'TERM': 'xterm-256color', 'PATH':
'/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/bin', 'GUIX_PYTHONPATH':
'/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
'GUIX_ENVIRONMENT': '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile'})
pgpM2JLV3bskc.pgp
Description: OpenPGP digital signature
bug#64562: Rotated logs have different permissions from logs that have not yet been rotated
I noticed this inconsistency: -- $ ls -l /var/log/messages* -rw-r- 1 root root 112994 Jul 10 14:29 /var/log/messages -rw-r--r-- 1 root root 8883 Jul 5 12:00 /var/log/messages.1.gz -- This seems like a mistake.
bug#64557: (no subject)
guix substitute: warning: while fetching
https://ci.guix.gnu.org/nar/zstd/vmq70gpqzdrd4ljbr1l9ap9pjvwn8dv0-perl-term-readkey-2.38:
server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
Backtrace:
In ice-9/boot-9.scm:
1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
18 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 17 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 16 (_ #(#(#)))
In guix/ui.scm:
2279:7 15 (run-guix . _)
2242:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
858:15 11 (_)
650:2 10 (process-substitution _ _ _ #:cache-urls _ #:acl _ # _ # ?)
In ice-9/boot-9.scm:
1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
467:7 8 (download-nar #< path: "/gnu/store/vmq70gpqzd?> ?)
In ice-9/boot-9.scm:
1747:15 7 (with-exception-handler # ?)
1685:16 6 (raise-exception _ #:continuable? _)
1683:16 5 (raise-exception _ #:continuable? _)
1685:16 4 (raise-exception _ #:continuable? _)
1780:13 3 (_ #< components: (#<> #)
Backtrace:
14 (primitive-load
"/gnu/store/m43d9r0zn4q4ifwd1bgfdm6pgdji4yrg-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
2168:24 9 (run-with-store #
# ?)
1996:8 8 (_ #)
In ./guix/gexp.scm:
299:22 7 (_ #)
1180:2 6 (_ #)
1046:2 5 (_ #)
892:4 4 (_ #)
In ./guix/store.scm:
2053:12 3 (_ #)
1401:5 2 (map/accumulate-builds #7efc228da0a0> # ?)
1417:15 1 (_ #
("/gnu/store/mrxlmmr782nl5z3j2lcapzr2ifr2ln33-guile-ssh-?" ?) ?)
1417:15 0 (loop #f)
./guix/store.scm:1417:15: In procedure loop:
ERROR:
1. :
message: "some substitutes for the outputs of derivation
`/gnu/store/f74aip8bzq6axicf1ws1v8qcjivhw789-po4a-0.68.drv' failed
(usually happens due to networking issues); try `--fallback' to build
derivation from source "
status: 1
guix pull: error: You found a bug: the program
'/gnu/store/m43d9r0zn4q4ifwd1bgfdm6pgdji4yrg-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"ef0a45c6413a35e0e7ee375cab2c6f7bc468ab5a"; system: "x86_64-linux";
host version: "fcfdb8f05ed0228ede47e9d2a0de5b05b09dd7be"; pull-version: 1).
bug#64309: Python dlopen()s musl libc
Hi Athena, So it's not the LD_DEBUG output that hold a clue, but rather the Python traceback. Athena Martin writes: > File > "/gnu/store/dsgxdqs620pp284bfm1drbsjqpb36i4n-python-neovim-remote-2.5.1/bin/.nvr-real", > line 4, in > import nvr.nvr as mod > File "/home/alm/.local/lib/python3.10/site-packages/nvr/__init__.py", line > 1, in > from .nvr import main > File "/home/alm/.local/lib/python3.10/site-packages/nvr/nvr.py", line 34, > in > import psutil > File "/home/alm/.local/lib/python3.10/site-packages/psutil/__init__.py", > line 102, in > from . import _pslinux as _psplatform > File "/home/alm/.local/lib/python3.10/site-packages/psutil/_pslinux.py", > line 26, in > from . import _psutil_linux as cext > ImportError: libc.musl-x86_64.so.1: cannot open shared object file: No such > file or directory The nvr package in ~/.local seems to be used instead of a Guix package. That locally installed nvr package expects to use the host's libc, but since the python interpreter being used has a fixed RPATH and system search path it won't find it. .nvr-real should definitely be using the Python code inside the store, I wonder why that isn't being done. Maybe our sitecustomize.py is misbehaving? Can you do `guix shell python-neovim-remote python -- python3` then type `import sys.path; sys.path`? Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#64505: bug report
Hi Jean-Christophe, Jean-Christophe Haessig writes: > In ./guix/platform.scm: > 139:6 2 (lookup-platform-by-target-or-system "x86_64-linux") > In ice-9/boot-9.scm: > 829:9 1 (catch srfi-34 # ./guix/platform.scm:139:6 ()> # ?) > In ./guix/platform.scm: > 129:2 0 (lookup-platform-by-target "x86_64-linux") > > ./guix/platform.scm:129:2: In procedure lookup-platform-by-target: > error: raise-exception: unbound variable > guix pull: error: You found a bug: the program > '/gnu/store/cb56v1p47byd2ars5xbgkw26f3iq41sj-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "961ffca1c75141cbb351d143b22b673638e9659d"; system: "x86_64-linux"; > host version: "1.1.0"; pull-version: 1). > Please report the COMPLETE output above by email to . You seem to have a quite old version of Guix, along with Guile 2.x, and there raise-exception doesn't exist, but it is indirectly being used when building Guix. You can either try to pull in small increments (I think 1.1 -> 1.2 -> 1.3 -> master should do it) for now, but we should also fix this use of raise-exception: it should be `raise` from srfi-34/35 instead. Best, -- Josselin Poiret signature.asc Description: PGP signature
