Help updating CLOG

[Roman Scherer]

G::DEBUGGER-DISABLED-HOOK # # :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #)
2: (INVOKE-DEBUGGER #)
3: (ERROR SB-INT:SIMPLE-FILE-ERROR :PATHNAME 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl"
 :MESSAGE "Permission denied" :FORMAT-CONTROL "Error opening ~S" 
:FORMAT-ARGUMENTS 
(#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl"))
4: (SB-IMPL::FILE-PERROR 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl"
 13 "Error opening ~S" 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl")
5: (SB-IMPL::%OPEN-ERROR 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl"
 13 NIL :CREATE)
6: (OPEN 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace-tmpCM21U60Z.fasl"
 :DIRECTION :IO :ELEMENT-TYPE :DEFAULT :IF-EXISTS NIL :IF-DOES-NOT-EXIST 
:CREATE :EXTERNAL-FORMAT :UTF-8 :CLASS SB-SYS:FD-STREAM)
7: (UIOP/STREAM:CALL-WITH-TEMPORARY-FILE # :WANT-STREAM-P NIL 
:WANT-PATHNAME-P T :DIRECTION :IO :KEEP T :AFTER NIL :DIRECTORY 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/"
 :TYPE "fasl" :PREFIX "clog-ace-tmp" :SUFFIX NIL :ELEMENT-TYPE NIL 
:EXTERNAL-FORMAT NIL)
8: (UIOP/LISP-BUILD:COMPILE-FILE* 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/share/common-lisp/sbcl/clog-ace/clog-ace.lisp"
 :OUTPUT-FILE 
#P"/gnu/store/5rhkkvvl5qc9yq9m72ypfrmq27hfq656-sbcl-clog-ace-0.1.0-0.61f3c2e/lib/common-lisp/sbcl/clog-ace/clog-ace.fasl"
 :EXTERNAL-FORMAT :UTF-8 :WARNINGS-FILE NIL)
9: (ASDF/LISP-ACTION:PERFORM-LISP-COMPILATION # 
#)
10: ((SB-PCL::EMF ASDF/ACTION:PERFORM) # # 
# #)
11: ((LAMBDA NIL :IN ASDF/ACTION:CALL-WHILE-VISITING-ACTION))
12: ((:METHOD ASDF/ACTION:PERFORM-WITH-RESTARTS :AROUND (T T)) 
# #) [fast-method]
13: ((:METHOD ASDF/PLAN:PERFORM-PLAN (T)) #) [fast-method]
14: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
15: ((:METHOD ASDF/PLAN:PERFORM-PLAN :AROUND (T)) #) [fast-method]
16: ((:METHOD ASDF/OPERATE:OPERATE (ASDF/OPERATION:OPERATION 
ASDF/COMPONENT:COMPONENT)) # # :PLAN-CLASS NIL :PLAN-OPTIONS NIL) [fast-method]
17: ((SB-PCL::EMF ASDF/OPERATE:OPERATE) # # 
# #)
18: ((LAMBDA NIL :IN ASDF/OPERATE:OPERATE))
19: ((:METHOD ASDF/OPERATE:OPERATE :AROUND (T T)) # 
#) [fast-method]
20: ((SB-PCL::EMF ASDF/OPERATE:OPERATE) # # 
ASDF/LISP-ACTION:LOAD-OP "clog/tools")
21: ((LAMBDA NIL :IN ASDF/OPERATE:OPERATE))
22: (ASDF/SESSION:CALL-WITH-ASDF-SESSION # :OVERRIDE NIL :KEY NIL :OVERRIDE-CACHE NIL 
:OVERRIDE-FORCING NIL)
23: ((:METHOD ASDF/OPERATE:OPERATE :AROUND (T T)) ASDF/LISP-ACTION:LOAD-OP 
"clog/tools") [fast-method]
24: (ASDF/OPERATE:LOAD-SYSTEM "clog/tools")
25: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF/OPERATE:LOAD-SYSTEM "clog/tools") 
#)
26: (EVAL (ASDF/OPERATE:LOAD-SYSTEM "clog/tools"))
27: (SB-IMPL::PROCESS-EVAL/LOAD-OPTIONS ((:EVAL . "(require :asdf)") (:EVAL . 
#<(SIMPLE-ARRAY CHARACTER (260)) (asdf:initialize-source-registry (list 
:source-registry (list :tree (uiop:ensure-pathname 
"/gnu/store/56kncl3nzl05wlk3ld8flkhl6p3lvb5q-sbcl-clog-tools-2.3-1.f736bfa/share/common-lisp/sbcl/clog-tools"
 ... {1001AB6DEF}>) (:EVAL . "(asdf:load-system \"clog/tools\")") (:QUIT)))
28: (SB-IMPL::TOPLEVEL-INIT)
29: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
30: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
31: (SB-IMPL::%START-LISP)

unhandled condition in --disable-debugger mode, quitting
;
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   printed 1 note
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: 
"/gnu/store/qhjivbf0fsgn62n4yy7xznwbzx7lf50l-sbcl-2.4.7/bin/sbcl" arguments: 
("--non-interactive" "--eval" "(require :asdf)" "--eval" 
"(asdf:initialize-source-registry (list :source-registry (list :tree 
(uiop:ensure-pathname 
\"/gnu/store/56kncl3nzl05wlk3ld8flkhl6p3lvb5q-sbcl-clog-tools-2.3-1.f736bfa/share/common-lisp/sbcl/clog-tools\"
 :truenamize t :ensure-directory t)) :inherit-configuration))" "--eval" 
"(asdf:load-system \"clog/tools\")") exit-status: 1 term-signal: #f 
stop-signal: #f>
phase `build' failed after 2.5 seconds
command "/gnu/store/qhjivbf0fsgn62n4yy7xznwbzx7lf50l-sbcl-2.4.7/bin/sbcl" 
"--non-inte

Re: Cuirass: Could not find repository

[Roman Scherer]

Richard Sent  writes:

Hi Richard,

thanks for taking a look and uncovering the issue about deleting
sddm-service-type on non-aarch64 systems. I'm now deleting it in a way
that does not fail.

https://github.com/asahi-guix/channel/blob/main/src/asahi/guix/system/desktop.scm#L102-L104

Unfortunatly, I still see the same error. But I think I'm a step
further. The /gnu/store/j3igwh17jvhvkr4839hdjlwvazwym3r4-guix-bfcac8c
directory now contains the version of my Guix channel that matches the
Cuirass specification.

But it still fails with the same error, complaining that this directory
is not a Git repository.

--8<---cut here---start->8---
Computing Guix derivation for 'aarch64-linux'...  
In thread:
uncaught throw to %exception: (#<&inferior-exception arguments: (git-error 
# code: -3 message: "could not find repository at 
'/gnu/store/j3igwh17jvhvkr4839hdjlwvazwym3r4-guix-bfcac8c'" class: 6>>) 
inferior: # stack: ((#f ("ice-9/boot-9.scm" 
1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) (raise-exception 
("ice-9/boot-9.scm" 1684 16)) (#f ("guix/git.scm" 438 13)) 
(update-cached-checkout ("guix/git.scm" 536 29)) (latest-channel-instance 
("guix/channels.scm" 416 18)) (latest-channel-instances ("guix/channels.scm" 
553 23)) (#f ("guix/store.scm" 2053 38)) (#f ("guix/build-system/channel.scm" 
42 2)) (#f ("guix/packages.scm" 2008 11)) (#f ("guix/store.scm" 2009 8)) (#f 
("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 2009 8)) (#f 
("./guix/monads.scm" 486 9)) (#f ("guix/gexp.scm" 1666 2)) (#f ("guix/gexp.scm" 
1866 6)) (#f ("guix/gexp.scm" 1982 2)) (#f ("guix/gexp.scm" 298 22)) (#f 
("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) (run-with-store 
("guix/store.scm" 2181 25)) (call-with-build-handler ("guix/store.scm" 1301 8)) 
(map/accumulate-builds ("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 
12)) (#f ("guix/gexp.scm" 912 4)) (#f ("guix/gexp.scm" 1071 2)) (#f 
("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 
2009 8)) (#f ("guix/gexp.scm" 917 13)) (run-with-store ("guix/store.scm" 2181 
25)) (call-with-build-handler ("guix/store.scm" 1301 8)) (map/accumulate-builds 
("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 12)) (#f 
("guix/gexp.scm" 912 4)) (#f ("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 
1204 2)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 2009 8)) (#f 
("guix/gexp.scm" 917 13)) (run-with-store ("guix/store.scm" 2181 25)) 
(call-with-build-handler ("guix/store.scm" 1301 8)) (map/accumulate-builds 
("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 12)) (#f 
("guix/gexp.scm" 912 4)) (#f ("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 
1204 2)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 2009 8)) (#f 
("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) (run-with-store 
("guix/store.scm" 2181 25)) (call-with-build-handler ("guix/store.scm" 1301 8)) 
(map/accumulate-builds ("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 
12)) (#f ("guix/gexp.scm" 912 4)) (#f ("guix/gexp.scm" 1071 2)) (#f 
("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 
2009 8)) (#f ("guix/gexp.scm" 917 13)) (run-with-store ("guix/store.scm" 2181 
25)) (call-with-build-handler ("guix/store.scm" 1301 8)) (map/accumulate-builds 
("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 12)) (#f 
("guix/gexp.scm" 912 4)) (#f ("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 
1204 2)) (#f ("gnu/services.scm" 463 2)) (run-with-store ("guix/store.scm" 2181 
25)) (call-with-build-handler ("guix/store.scm" 1301 8)) (map/accumulate-builds 
("guix/store.scm" 1383 11)) (#f ("guix/store.scm" 2066 12)) (#f 
("gnu/services.scm" 431 2)) (run-with-store ("guix/store.scm" 2181 25)) (#f 
("gnu/system.scm" 1661 9)) (#f ("guix/store.scm" 2053 38)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (run-with-store ("guix/store.scm" 2181 
25)) (#f ("gnu/ci.scm" 447 18)) (map1 ("srfi/srfi-1.scm" 585 17)) (map1 
("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1 
("srfi/srfi-1.scm" 585 1

Cuirass: Could not find repository

[Roman Scherer]

Hello Guix,

I'm trying to run a Cuirass server for my channels. I have setup
Cuirass and can build packages in my channels. So far so good.

What I would like to do next is to build a manifest with my channel
and my modified version of the Guix channel that contains patches that
aren't upstreamed.

When I do this, I see the following build error:

-
Computing Guix derivation for 'aarch64-linux'...
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/bzl05y4790frz38hv9mj1a0m91451akf-profile.drv
  /gnu/store/rwy6nr20rdc3krkpj45kbr4d3snsqkc0-asahi.drv
  /gnu/store/s8qlz8g581vvhdhh8qrmrpglmq7nndpv-inferior-script.scm.drv
  /gnu/store/wydr6pvfc0llx0d9hq41gn2cyzj8qwc1-profile.drv
The following profile hooks will be built:
   /gnu/store/2v1i8qwsxsin0ssgvjbghqq7hx81kqr4-ca-certificate-bundle.drv
   /gnu/store/8xgz94zkjayz5amxc4f16crxv7qgjda7-fonts-dir.drv
   /gnu/store/9akz81fhpkpz073mgxf5mnabwnpfg30g-info-dir.drv
   /gnu/store/k2f0m1qv0vvm4cz9f21yp1y3i23s513y-guix-package-cache.drv
   /gnu/store/s9nch31jiapln29c03an5sb4gk85yxzj-emacs-subdirs.drv
building path(s) `/gnu/store/ny6s2b4652xmqvjl44ban7ra3398zn7v-asahi'
(repl-version 0 1 1)
WARNING: (asahi guix system desktop): imported module (gnu services) overrides 
core binding `delete'
WARNING: (asahi guix system desktop): imported module (gnu services) overrides 
core binding `delete'
(values (value 
"/gnu/store/ny6s2b4652xmqvjl44ban7ra3398zn7v-asahi/share/guile/site/3.0"))
building path(s) 
`/gnu/store/hkk0778ql8ms9a0w5314s1r15qbvclpn-ca-certificate-bundle'
building path(s) `/gnu/store/29gz6ym8mgkb0qmvzlz5dmjyms4qlgss-emacs-subdirs'
building path(s) `/gnu/store/q6rs8i12gx68h3wcvx6f1pr4ndy5gxbs-fonts-dir'
building path(s) `/gnu/store/wk1hg6kfzgxqz5scimxkxsvv0ab05yyx-info-dir'
building path(s) `/gnu/store/dkb8539cx85833bpnils35shsvnv0bca-profile'
building path(s) 
`/gnu/store/c1wyvrxgwqgm6vsfv8xsgdsdzbq6a1w6-inferior-script.scm'
building path(s) 
`/gnu/store/b878q40rwkmi2b1fyd4aj4z14fpc914x-guix-package-cache'
(repl-version 0 1 1)
Generating package cache for 
'/gnu/store/dkb8539cx85833bpnils35shsvnv0bca-profile'...
(values (value 
"/gnu/store/b878q40rwkmi2b1fyd4aj4z14fpc914x-guix-package-cache/lib/guix/package.cache"))
building path(s) `/gnu/store/xvlilpg0pk9yqj1rhymc4jnh83clx3si-profile'
In thread:
uncaught throw to %exception: (#<&inferior-exception arguments: (git-error 
# code: -3 message: "could not find repository at 
'/gnu/store/xphccxyczx2706ikpz77iq10xjpcq9wc-guix-cf5f7a8'" class: 6>>) 
inferior: # stack: ((#f ("ice-9/boot-9.scm" 
1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) (raise-exception 
("ice-9/boot-9.scm" 1684 16)) (#f ("guix/git.scm" 438 13)) 
(update-cached-checkout ("guix/git.scm" 536 29)) (latest-channel-instance 
("guix/channels.scm" 416 18)) (latest-channel-instances ("guix/channels.scm" 
553 23)) (#f ("guix/store.scm" 2053 38)) (#f ("guix/build-system/channel.scm" 
42 2)) (#f ("guix/packages.scm" 2009 11)) (#f ("guix/store.scm" 2009 8)) (#f 
("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("guix/gexp.scm" 912 4)) (#f 
("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("guix/gexp.scm" 912 4)) (#f 
("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("gnu/services.scm" 724 2)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("gnu/services.scm" 431 2)) (run-with-store 
("guix/store.scm" 2181 25)) (#f ("gnu/system.scm" 1661 9)) (#f 
("guix/store.scm" 2053 38)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 
2009 8)) (run-with-store ("guix/store.scm" 2181 25)) (#f ("gnu/ci.scm" 447 18)) 
(map1 ("srfi/srfi-1.scm" 585 17)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1 
("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 505 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm"

Re: Cuirass instability on aarch64 systems

[Roman Scherer]

Hi,

thank you for your answer. I will try out your suggestion soon.

Roman

On Sun, Jan 21, 2024, 17:47  wrote:

> Hi,
>
> TL;DR: To mitigate this, add `GUILE_JIT_THRESHOLD=-1' as an environment
> variable for Cuirass. If you use the cuirass package from the guix
> channel you should be able to use `package-with-patches' and the
> attached patch.
>
> On 2024-01-21T16:16:57+0100, Roman Scherer wrote:
> >
> > Hi Guix,
> >
> > I'm running Cuirass for one of my channels on an aarch64 VM on the
> Hetzner
> > Cloud. When I visit the Cuirass web interface it sometimes serves the
> page,
> > but most of the time it just serves a blank page.
>
> I have been tracking down the exact same error last week.
>
> My debbuging showed that a related issue has been reported to
> guile-fibers in [0]. There, Andy Wingo suggested that it might be bad
> codegen for atomics[1]. I tried the test case in [0] for guile commits
> 33e07fc56c18d4f3ffbfd53c4a8300bb2b5e49ba which should be the first
> commit to be using the atomic instructions and it failed while it
> succeeded with the previous commit. I also tried applying only part of
> 33e07fc56c18d4f3ffbfd53c4a8300bb2b5e49ba and found that applying the
> changes for `compile_atomic_scm_swap_immediate' also makes the test
> fail. Unfortunately, I'm not proficient in assembly, atomics and JIT and
> don't see anything wrong with it. Even worse, I definitely should be
> doing other things right now :D and haven't had time to report my
> findings. Feel free to do so :). Else, I might find some time next week.
>
> > [...]
> > Recently I submitted this patch [2] to guile-fibers to get my system
> > updated. There were no substitutes available and I had to build the
> package on
> > my server. Unfortuntly that build never completed it just hang in the
> tests.
>
> I too had that problem and was able to work around it by building it on
> my x86_64 laptop using transparent emulation. I don't know if this is
> related and haven't tested it with `GUILE_JIT_THRESHOLD=-1'.
>
> I hope this helps
>
> vicvbcun
>
> [0]: https://github.com/wingo/fibers/issues/83
> [1]: https://github.com/wingo/fibers/issues/83#issuecomment-1538427808
>

Cuirass instability on aarch64 systems

[Roman Scherer]

Hi Guix,

I'm running Cuirass for one of my channels on an aarch64 VM on the Hetzner
Cloud. When I visit the Cuirass web interface it sometimes serves the page,
but most of the time it just serves a blank page.

When looking at the logs I see the following error messages:

```
2024-01-21 14:54:27 GET /
2024-01-21 14:54:27 In cuirass/http.scm:
2024-01-21 14:54:27   1008:33  1 (url-handler # 
#< me?> ?)
2024-01-21 14:54:27 In ice-9/boot-9.scm:
2024-01-21 14:54:27   1685:16  0 (raise-exception _ #:continuable? _)
2024-01-21 14:54:27 Throw to key `psql-query-error' with args `(#f #f "another 
command is already in2024-01-21 14:54:27 Uncaught exception in task:
2024-01-21 14:54:27 In fibers.scm:
2024-01-21 14:54:27 172:8  1 (_)
2024-01-21 14:54:27 In cuirass/http.scm:
2024-01-21 14:54:27 In ice-9/boot-9.scm:
2024-01-21 14:54:27   1685:16  0 (raise-exception _ #:continuable? _)
2024-01-21 14:54:27 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2024-01-21 14:54:27 In procedure port-auxiliary-write-buffer: Wrong type 
argument in position 1 (exp2024-01-21 14:54:27   1010:23  1 (url-handler _ 
#< method: GET uri: #< sc?> ?)
2024-01-21 14:54:27 In ice-9/boot-9.scm:
2024-01-21 14:54:27   1685:16  0 (raise-exception _ #:continuable? _)
2024-01-21 14:54:27 Throw to key `psql-query-error' with args `(#f #f "another 
command is already in
```

Does anyone have an idea what is going on here? It looks to me like there is
some deadlock with PostgreSQL, but I'm not sure how to further debug this.

Recently I submitted this patch [2] to guile-fibers to get my system
updated. There were no substitutes available and I had to build the package on
my server. Unfortuntly that build never completed it just hang in the tests.

Now I'm starting to wonder if this is related. Are there any known issues with
guile-fibers on aarch64 systems? Any ideas on how to fix/debug this issue?

My server configuration can be found here [1].

Thanks, Roman.

[1] 
https://github.com/asahi-guix/channel/blob/main/src/asahi/guix/system/server.scm
[2] https://lists.gnu.org/archive/html/guix-patches/2024-01/msg01116.html


signature.asc
Description: PGP signature

How to work on a bootloader in the REPL?

[Roman Scherer]

Hi Guix,

what is the best way to work on a bootloader in the REPL? Say, I make
changes to the grub-efi-bootloader and want to test if it is working. I
think I know how to do it with guix system on the command line, but I
wonder how I would do this in Scheme in the REPL, to have a faster
feedback cycle.

How would you do it?

Thanks, Roman.


signature.asc
Description: PGP signature

Re: Too many levels of symbolic links

[Roman Scherer]

Good to know about that unspoken rule. :) Should we do something about
that? I thought about adding a note to the manual. Or even not allowing
the user to re-configure in such a case?

WDYT?

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> On Tue, Mar 14, 2023 at 08:16:52PM +0100, Roman Scherer wrote:
>>
>> Felix, I'm back on track! I found what triggered this horrible problem :)
>>
>> At some point I added the qemu-binfmt-service-type to my system. I
>> copied a snipped from the manual and finally "adjusted" it to this:
>>
>> ```
>> (define %qemu-service
>>   (service qemu-binfmt-service-type
>>(qemu-binfmt-configuration
>> (platforms (lookup-qemu-platforms "aarch64" "x86_64")
>> ```
>>
>> I don't know much about quem and I thought, well let's choose the
>> "aarch64" and "x86_64" qemu platforms on which I run Guix, and maybe
>> re-use this service on multiple machines.
>>
>> My Guix system runs on the aarch64 architecture. It turns out that
>> having "aarch64" in lookup-qemu-platforms causes the "Too many levels of
>> symbolic links" error. As soon as I remove it, everything is good again.
>>
>> Now, maybe it does not even makes sense to add "aarch64" to that list,
>> but I think it should not fail that catastrophical. I still don't know
>> which symlink was causing this issue, though.
>>
>> That's where I am. Just happy that I survived my first serious Guix
>> crash. :)
>>
>> Thanks for your help so far,
>>
>> Roman
>
> I'm surprised that it worked for you. One of the unspoken rules of qemu
> binfmt emulation is you don't emulate your own hardware. I'm also
> surprised because in the past I tried to enable binfmt emulation on my
> pinebook pro and the qemu-binfmt-service-type was the difference between
> booting and not booting.


signature.asc
Description: PGP signature

Re: Too many levels of symbolic links

[Roman Scherer]

Felix, I'm back on track! I found what triggered this horrible problem :)

At some point I added the qemu-binfmt-service-type to my system. I
copied a snipped from the manual and finally "adjusted" it to this:

```
(define %qemu-service
  (service qemu-binfmt-service-type
   (qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "aarch64" "x86_64")
```

I don't know much about quem and I thought, well let's choose the
"aarch64" and "x86_64" qemu platforms on which I run Guix, and maybe
re-use this service on multiple machines.

My Guix system runs on the aarch64 architecture. It turns out that
having "aarch64" in lookup-qemu-platforms causes the "Too many levels of
symbolic links" error. As soon as I remove it, everything is good again.

Now, maybe it does not even makes sense to add "aarch64" to that list,
but I think it should not fail that catastrophical. I still don't know
which symlink was causing this issue, though.

That's where I am. Just happy that I survived my first serious Guix
crash. :)

Thanks for your help so far,

Roman

Felix Lechner  writes:

> Hi Roman,
>
> On Fri, Mar 10, 2023 at 7:32 AM Roman Scherer
>  wrote:
>>
>> Right now I rolled back to generation 53, which is still
>> working.
>
> Great!
>
>> Is it correct to look for the problematic files in the directory to
>> which system-54-link links to?
>
> Yes, probably. Unfortunately, profiles are large bundles of symbolic
> links, so finding the offending cycle may not be easy.
>
>> Generation 54 is the broken one, which does boot up, but
>> logging in fails with the too many levels of symbolic link issue.
>
> Since the issue occurs at login, there may also be a bad interaction
> with your user profile. What if you log in as another user?
>
>> I run the problematic commands from that directory and they seem to run
>> from the non-broken system
>
> My prime list of suspects include something like a system-wide Bash
> profile (or whichever shell you use).
>
>> I'm thinking of re-installing my system completely.
>
> Please don't do that. It is not necessary.
>
> Instead, you can delete generation 54 and try again. Make sure to
> 'guix pull' before reconfiguring again.
>
>> Do I have any other option, even an unsupported one?
>
> Please post the config.scm for your generation 53, plus a diff to
> generation 54. You find copies via 'guix system describe'. It may also
> be helpful to attach your home.scm, if you use Guix Home.
>
> Together with the changes in Guix since the commit on which generation
> 53 is based, we will find the issue. The process is more or less
> deterministic.
>
> Please keep up hope. All needed software is already installed. Guix
> has extraordinary ways to recover—even though they can be hard to
> figure out.
>
> Kind regards
> Felix


signature.asc
Description: PGP signature

Re: Too many levels of symbolic links

[Roman Scherer]

Hi Tobias and Felix,

the posix file was actually pointing to the correct parent directory (my bad)
and as Felix mentioned probably not the root of my issue.

The `guix gc --verify=contents,repair` unfortunatly did not help either.

I looked a bit around and found this in /var/guix/profiles

drwxr-xr-x 4 root root 4096 Jan 21 16:28 per-user/
lrwxrwxrwx 1 root root   14 Mar  8 16:20 system -> system-53-link
lrwxrwxrwx 1 root root   50 Feb 12 14:58 system-49-link -> 
/gnu/store/r048wnvv5wb792d0h29147j4q2m874d0-system
lrwxrwxrwx 1 root root   50 Mar  8 15:17 system-50-link -> 
/gnu/store/99kgb2jh7jdjcvqac81dj0gd2nkhanmw-system
lrwxrwxrwx 1 root root   50 Feb 20 12:30 system-51-link -> 
/gnu/store/cwk04xkh3zf7vb5bg3cpjr8jyviv5b2f-system
lrwxrwxrwx 1 root root   50 Feb 25 14:16 system-52-link -> 
/gnu/store/aqxlpw468wvnardbb8dmyxj1qghv68ah-system
lrwxrwxrwx 1 root root   50 Mar  3 16:33 system-53-link -> 
/gnu/store/1xdmrafzscrpi34rynag71my6nw3w8w2-system
lrwxrwxrwx 1 root root   50 Mar  8 15:53 system-54-link -> 
/gnu/store/cjdabnlk74irjh3xwqh9d31kza3c78a0-system

Right now I rolled back to generation 53, which is still
working. Generation 54 is the broken one, which does boot up, but
logging in fails with the too many levels of symbolic link issue.

Is it correct to look for the problematic files in the directory to
which system-54-link links to?

I run the problematic commands from that directory and they seem to run
from the non-broken system

I'm thinking of re-installing my system completely. Do I have any other
option, even an unsupported one?

Thanks again for your help,

Roman.

Tobias Geerinckx-Rice  writes:

> [[PGP Signed Part:Undecided]]
> Hi Roman,
>
> Roman Scherer 写道：
>>   
>> /gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo/posix
>>
>> links to itself.
>
> FYI, it should link to its parent:
>
>  /gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo
>
> (So, yes, you could …/posix/posix/posix/posix/… all night long.)
>
>> Since I read I should not mess with the store, any
>> ideas how to get rid of that file system loop in a safe way?
>
> You could try
>
>  # guix gc --verify=contents,repair
>
> and Guix should detect the mismatch and refresh tzdata from a
> substitute server.
>
> The unsupported alternative would be to bind-mount /gnu/store
> somewhere and manually relink the file.
>
>> I already tried re-installing it, but that had no effect.
>
> It wouldn't.
>
> Kind regards,
>
> T G-R
>
> [[End of PGP Signed Part]]


signature.asc
Description: PGP signature

Re: Too many levels of symbolic links

[Roman Scherer]

Hi Felix,

thanks for your help! Running

  find /run/current-system/ -follow -printf ""

on my current system does not find anything. When inside the broken
system, find fails with the same error message.

However, running

  find /gnu/store/ -follow -printf ""
  find: File system loop detected; 
‘/gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo/posix’ 
is part of the same file system loop as 
‘/gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo’.

detects that the file

  /gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo/posix

links to itself. Since I read I should not mess with the store, any
ideas how to get rid of that file system loop in a safe way?

I already tried re-installing it, but that had no effect.

Roman.

Felix Lechner  writes:

> Hi Roman,
>
> On Sun, Mar 5, 2023 at 8:34 AM Roman Scherer
>  wrote:
>>
>> "Too many levels of symbolic links" error.
>
> I think you have circular symbolic links (or possibly just a
> poorly-placed link to a folder). [1] Unfortunately, I am not sure how
> to examine the issue unless you have basic tools like 'find'
> available.
>
> Perhaps you can run the absolute path from the store.
>
> find /run/current-system/ -follow -printf ""
>
> Kind regards
> Felix Lechner
>
> [1] 
> https://serverfault.com/questions/265598/how-do-i-find-circular-symbolic-links/265614#265614


signature.asc
Description: PGP signature

Too many levels of symbolic links

[Roman Scherer]

Hi Guix,

after upgrading my system it becomes unusable. The guix system
reconfigure completes, but after that, running any command fails with an
"Too many levels of symbolic links" error.

Here are some examples:

```
bash: /root/.config/guix/current/bin/guix:
/gnu/store/dlivmgf8xikvfi6422dggra77lay9g8y-guile-wrapper/bin/guile: bad
interpreter: Too many levels of symbolic links
bash: /run/current-system/profile/bin/sh: Too many levels of symbolic links
bash: /run/current-system/profile/bin/ls: Too many levels of symbolic links
bash: /run/current-system/profile/bin/whoami: Too many levels of symbolic links
bash: /run/current-system/profile/bin/hostname: Too many levels of symbolic 
links
```

I'm not sure what's going on with the files in
/run/current-system/profile/bin (I can't run ls on them), but after
booting a previous working system, running the guile interpreter in
/gnu/store/dlivmgf8xikvfi6422dggra77lay9g8y-guile-wrapper/bin/guile
seems to be working fine.

I first thought I have too many symlinks on my system. I cleaned up old
generations and collected the garbage, but the problem still
persists. So I think this is not the issue.

Any ideas?

Thanks, Roman.


signature.asc
Description: PGP signature

Re: installation on LVM on LUKS

[Roman Scherer]

Hi Emmanuel,

did you add the cryptsetup-static and lvm2-static packages to the
packages field of your operating system?

Apart from that, I think you also need to add the dm-crypt module to the
initrd-modules field of the of the operating system.

I'm not sure about your other question, but from what I understand the
reason why the kernel and the initrd live in the store and not in the
EFI partition might be that you actually would need to put the kernel
and the initrd for *each* system generation onto the EFI partition, so
you can boot different system generations. And that would fill up the
EFI partition pretty quickly.

I hope that helps.

Roman

Emmanuel Beffara  writes:

> Hello,
>
> I am currently trying to install Guix System on my laptop and I am facing an
> issue with the bootloader configuration.
>
> I use full-disk encryption with a single encrypted partition, split into
> several logical volumes using LVM, plus an extra non-encrypted partition for
> EFI boot material:
>
>   nvme0n1  259:00 953,9G  0 disk
>   ├─nvme0n1p1  259:10 953,4G  0 part
>   │ └─manivelle254:00 953,4G  0 crypt
>   │   ├─storage-swap   254:1032G  0 lvm   [SWAP]
>   │   │ [...]
>   │   └─storage-guix   254:5064G  0 lvm   /
>   └─nvme0n1p2  259:20   487M  0 part  /boot
>
> I attach the system configuration, which I derived from the desktop template.
>
> Everything installed fine EXCEPT that Grub fails to load its LVM volume, hence
> the root partition is not found. Indeed, the produced grub.cfg has no mention
> of lvm anywhere. If I adjust it by inserting "insmod lvm" somewhere, either at
> the start or in a menuentry, or if I do that by hand in the Grub shell, then
> the system starts and works fine.
>
> Did I miss something in the configuration ?
>
>
> As a related point, this setup requires entering the decryption password
> twice: once so that Grub can load the kernel from the store, and once so that
> the kernel can open the volume itself. I understand the situation is known,
> but it could be avoided, for instance, by copying the kernel and initrd
> somewhere in the EFI partition so that they could be loaded directly. Besides,
> for some reason, Grub is extremely slow at opening the partition: it takes
> around 30 seconds to start after I correctly enter the password, whereas the
> kernel boots in just a few seconds after I enter the password for it.
>
> Any thoughts on this ?


signature.asc
Description: PGP signature

Re: GNU Guix 1.4.0rc2 available for testing!

[Roman Scherer]

Hi Ludo,

I tested the foreign distro installation of 
guix-binary-1.4.0rc2.aarch64-linux.tar.xz
on Asahi Linux. I went through the installation without any problems.

After that I reconfigured my Guix home. I had to remove the inkscape, pandoc,
emacs-ox-pandoc and qgis packages because they were not supported on aarch64,
but apart from that everything seems to work.

Great job of everyone involved!

Roman.

Ludovic Courtès  writes:

> [[PGP Signed Part:Undecided]]
> Hello Guix!
>
> The second release candidate of the upcoming 1.4.0 release is now
> available for testing, fixing issues that were reported for rc1:
>
>   source:
> https://alpha.gnu.org/gnu/guix/guix-1.4.0rc2.tar.gz
>
>   binary tarball (to install on a “foreign distro”):
> https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.aarch64-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.armhf-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.i686-linux.tar.xz
> 
> https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.x86_64-linux.tar.xz
>
>   system installation:
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.i686-linux.iso
> 
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso
>
>   virtual machine image:
> 
> https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2
>
> SHA256 hashes:
>
>   3b6c676615ce0b9de7c66ead528a91bb8520b74d2c391edac8d4c76d2d52  
> guix-1.4.0rc2.tar.gz
>   3566bfe5f0615f9b2167db7d1a2f1c88c02e8cc5013563b3e1eb95636a58f850  
> guix-binary-1.4.0rc2.aarch64-linux.tar.xz
>   18741b6780e9d0f8985d2514e5dff32110091cdf4da106062d1a2cf5cd6ed6a4  
> guix-binary-1.4.0rc2.armhf-linux.tar.xz
>   3d8348c2dbed8f9c6ab90f2ddc0df8c10d45c042612aed1fe7dcc7eabbc18b70  
> guix-binary-1.4.0rc2.i686-linux.tar.xz
>   4731126cc4f3f22265ae430e2acc3f67489ec311e42de346b634656740258033  
> guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
>   542e53a09fddedbddd75dfc745509ad9365cb7a76750d9bf8575b589c97dc286  
> guix-binary-1.4.0rc2.x86_64-linux.tar.xz
>   b35f94609942b9715acefa978166189c5505934c9576b1c3e14417beb5c48d6d  
> guix-system-install-1.4.0rc2.i686-linux.iso
>   880a1ee977f6999f63535d5667930d1d859a607c723573c86bd9f6c2ae69  
> guix-system-install-1.4.0rc2.x86_64-linux.iso
>   8bc98e42ba9370f49cfc2b051083121d8682c760ac3dac614b3f478d174c8756  
> guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2
>
> All these files have an associated ‘.sig’, an OpenPGP signature that you
> can verify as explained at
>  [0].
>
> You can help by:
>
>   1. Testing the binary tarball on the distro of your choice.  You can
>  download  and uncomment the
>  ‘GNU_URL’ variable assignment that refers to alpha.gnu.org.  It
>  should pick up 1.4.0rc2 automatically.
>
>   2. Testing the graphical installer of Guix System (the ISO images).
>
>   3. Testing the VM image, along the lines of
>  
> .
>
> Please report success to guix-de...@gnu.org, and report bugs and
> annoyances to bug-g...@gnu.org.
>
> If not serious problems are reported, we may release 1.4.0 on Dec. 19th.
>
> Thanks in advance!
>
> Ludo’.
>
> [0] Replacing https://sv.gnu.org/people/viewgpg.php?user_id=127547 by
> https://sv.gnu.org/people/viewgpg.php?user_id=15145 in the
> instructions.  This will only be reflected on the website after the
> release is made.
>
> [[End of PGP Signed Part]]


signature.asc
Description: PGP signature