StumpWM fails to start - Read only file system

  • Done
  • quality assurance status badge
Details
3 participants
  • Guillaume Le Vaillant
  • Kjartan Óli Águstsson
  • Richard Sent
Owner
unassigned
Submitted by
Kjartan Óli Águstsson
Severity
normal
K
K
Kjartan Óli Águstsson wrote on 17 Apr 2023 00:32
(address . bug-guix@gnu.org)
GV1P193MB23106F1D18FD3516594772CBDF9F9@GV1P193MB2310.EURP193.PROD.OUTLOOK.COM
I just started experiencing an issue with stumpwm where it fails to
start, complaining about a read only file system. A web search for the
error message leads me to
which sounds exactly like the problem I'm experiencing. I'm unsure how
to get the backtrace shared in that thread, or in general how to proceed
with debugging this.

guix describe shows:
guix 9a5e1dc
branch: master
commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
but I tried rolling back to an earlier system generation:
guix:
branch: master
commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
to no success so I doubt it is a new change in Guix.

Unless I'm missing something in the help-guix thread there is no
solution discussed there, so any help in debugging this would be greatly
appreciated.

--
Kjartan Oli Agustsson
GPG Key fingerprint: 4801 0D71 49C0 1DD6 E5FD 6AC9 D757 2FE3 605E E6B0
-----BEGIN PGP SIGNATURE-----

iQHLBAEBCAA1FiEESAENcUnAHdbl/WrJ11cv42Be5rAFAmQ8e5UXHGtqYXJ0YW5v
bGlAb3V0bG9vay5jb20ACgkQ11cv42Be5rBssgv+MZWF74qgxhIe3tm5ALAWNdQB
9+B+neLCrO6yiujo343lthpPM6FgeSVJ0vpMZnE1gDCX9pg45iWU/d3MIHNSIeEC
cIKPXIZHbwQWPQBqPA0lEGshOa9PGBCGrs7XuqyvPmRaEvKcTnNx/Vs+qRNOdR6T
f4dPDgb6Y7CpPIcC84DiV9eg4I+W3XlS2xePnnqgSBgbvAU86yYpbjMSVE2O/InI
8PNRKnp5XPvsNuDHVzi/79g2FXMEfTQKGlyeWZqdsv4KMj+3Xze/3LCHihl67gEd
9kzFaAKxFlNQTn0aK9fBthEC0eK3HGu5vCf+QjoBayAFAXhYBBcWSue/cRlVUohY
xk1knjXFLUZbkWZ4l7Oa+6e3DWEcYmMdJmM2kC/NIyO9fxVmLK6uWyU2X/l1HVCh
CRYPXSU7bgdVC9iDEbBkmrLIqE342vjvOj6gANTt7r4w6tEXvS2G9j6qCgVQdlW/
sF7TrNCulIoLqaixaFYbESAi2mPGOH22CpAjAO+r
=7+6W
-----END PGP SIGNATURE-----


G
G
Guillaume Le Vaillant wrote on 24 Apr 2023 14:57
(name . Kjartan Óli Águstsson)(address . kjartanoli@outlook.com)(address . 62890@debbugs.gnu.org)
878rehifo4.fsf@kitej
Kjartan Óli Águstsson <kjartanoli@outlook.com> skribis:

Toggle quote (24 lines)
> I just started experiencing an issue with stumpwm where it fails to
> start, complaining about a read only file system. A web search for the
> error message leads me to
> https://lists.gnu.org/archive/html/help-guix/2021-02/msg00080.html,
> which sounds exactly like the problem I'm experiencing. I'm unsure how
> to get the backtrace shared in that thread, or in general how to proceed
> with debugging this.
>
> guix describe shows:
> guix 9a5e1dc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
> but I tried rolling back to an earlier system generation:
> guix:
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
> to no success so I doubt it is a new change in Guix.
>
> Unless I'm missing something in the help-guix thread there is no
> solution discussed there, so any help in debugging this would be greatly
> appreciated.

Hi,

I just got the same problem after reconfiguring a machine (using
guix-home, but I'm not sure if it is relevant). It only happens when
I try to load extra modules from the ".stumpwm/init.lisp" file.

It looks like the configuration indicating where to search for the
compiled Common Lisp files (ASDF's source-registry and
output-translations) is not taken into consideration by Stumpwm
anymore... so it tries to recompile them in the wrong place.

As a workaround, replacing:
exec stumpwm
by:
exec sbcl --no-userinit --non-interactive --eval '(require :asdf)' --eval '(asdf:load-system "stumpwm")' --eval '(stumpwm:stumpwm)'
in my ".xsession" file seems to work...
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZEaBKw8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j9SdgD9G+NN54TQ5dXqN+Qu+vT2amTOGrLziC5gmsJJ
m7w45WgA/jfK4NFpi+lJPvcJfeF84hdiE94Zd0XCwZDYJCKwL3oM
=EDnO
-----END PGP SIGNATURE-----

G
G
Guillaume Le Vaillant wrote on 25 Apr 2023 11:35
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
877cu05ltz.fsf@kitej
I think the issue comes from grafts.

Without grafts, the ASDF configuration is coherent; the path for
stumpwm's sources and libraries is the same everywhere (here in
stumpwm:lib and sbcl-stumpwm-cpu):

Toggle snippet (22 lines)
$ cat $(guix build --no-grafts stumpwm | grep 'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build --no-grafts sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")


With grafts, we get different paths, which probably explains why ASDF
fails to find the compiled Lisp files it is looking for:

Toggle snippet (20 lines)
$ cat $(guix build stumpwm | grep 'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZEejOA8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j8JWAD/XbO6V2+ZOWww6M1/AJJ3meeCnG0lSZFIJspj
72/m7lAA/RSLVnm64CbDerB5H65zC2INTyOHO3vnEEtcbvDUZe7A
=Uiaz
-----END PGP SIGNATURE-----

R
R
Richard Sent wrote on 12 Jan 22:02 +0100
StumpWM with --no-grafts and System/Home mismatches
(address . 62890@debbugs.gnu.org)
1e0e77cc4d8f9b49c181d8eff6ee2bdd@freakingpenguin.com
I've noticed the same behavior and was able to resolve it by adding
--no-grafts whenever I reconfigure my system and home profiles. Likely
just the former is necessary, but I haven't tested it.

I've also noticed this behavior (SBCL trying to place .fasl in
/gnu/store) once when I pulled, reconfigured system, and didn't
reconfigure home. I have my setup configured such that StumpWM is
installed at the system level, while contrib packages are installed via
guix home.

I ran a git bisect and continually reconfigured my system to try and
narrow down what commit it was, and was able to isolate it to either an
xorgproto or Mesa update. Home was built before (49a7a95ba4) the commit,
System after (d55a4431f3). The offending commit in this particular case
lies somewhere between d55a4431f3 and 17c3a3bfff. (This probably isn't
actually a bug, but I'm posting it in case anyone else runs into a
similar issue in the future.)

If anyone else has a similar setup, encounters this issue, and already
uses --no-grafts, be sure both the system and home profiles are built
with the same version of Guix.

Richard Sent
R
R
Richard Sent wrote on 3 May 04:30 +0200
Specific graft that's at fault
(address . 62890@debbugs.gnu.org)
8734qzr5jr.fsf@freakingpenguin.com
Hi Guix!

The issue is likely caused by the glibc/fixed graft in (gnu packages
base). When this graft is removed, the the path discussed earlier is
coherent. Other grafts do not appear relevant.

Toggle snippet (21 lines)
Building stumpwm
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

Building sbcl-stumpwm-cpu
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))

(:tree "/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

Unfortunately stumpwm currently doesn't build on core-updates so I can't
check if the discrepency would occur there where glibc isn't grafted.

How exactly does that graft causes the problem? No clue.

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
R
R
Richard Sent wrote on 27 May 08:54 +0200
Likely cause found, excess library grafting
(address . 62890@debbugs.gnu.org)
87plt7kano.fsf@freakingpenguin.com
Hi Guix!

Once again I sunk more time into this issue when I should have been
sleeping. Here's what I found:

Building a grafted stumpwm directly creates one stumpwm:lib output.
Building it /indirectly/ as a dependency of, say, sbcl-stumpwm-cpu,
creates another, distinct stumpwm:lib output. This difference in
stumpwm:lib outputs is reflected in 50-stumpwm.conf being incoherent.

Packages that depend on say, A:lib graft their own copies of A:lib that
is distinct from grafting A:out and A:lib together. This behavior
confuses asdf-build-system and leads to breakage.

Here's a link to an issue discussing excess library grafts:

The simplest way to resolve this I feel is to either:

1. Remove stumpwm:lib entirely and just have stumpwm:out
1. Realistically is anyone out there using stumpwm:lib but NOT
stumpwm:out? What would the point of that be?
2. Add stumpwm as an input to to any package that just uses stumpwm:lib.

Between the two, I strongly prefer 1.

Below is a bunch of debug output to show how I reached the conclusion
that I did.

Toggle snippet (30 lines)
richard@gibraltar ~/code/cloned/guix [env]$ ./pre-inst-env guix build stumpwm --check
The following graft will be made:
/gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
applying 9 grafts for stumpwm-22.11 ...
grafting '/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib' -> '/gnu/store/r4sc5ylh2g30zgr10q35phd80cb3llqy-stumpwm-22.11-lib'...
grafting '/gnu/store/2rd3r0m8q11icwhhbwfl20ali3w5mwf4-stumpwm-22.11' -> '/gnu/store/azj1nchh8b9h9bssyzs15qbpd9p1zf7h-stumpwm-22.11'...
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
/gnu/store/r4sc5ylh2g30zgr10q35phd80cb3llqy-stumpwm-22.11-lib
/gnu/store/azj1nchh8b9h9bssyzs15qbpd9p1zf7h-stumpwm-22.11

# ^ here 50-stumpwm.conf refers to r4sc5ylh..., as it should
# whereas
# below 50-stumpwm.conf refers to y8fd8yirq. Notice how stumpwm is
# grafted differently

richard@gibraltar ~/code/cloned/guix [env]$ ./pre-inst-env guix build sbcl-stumpwm-cpu
The following grafts will be made:
/gnu/store/w8fbnjz3a8rzigldazhqn75v1ncrwnmr-sbcl-stumpwm-cpu-0.0.1-5.4613a95.drv
/gnu/store/w5027r2xlf88pfafw9dsx38cya01la83-stumpwm-22.11.drv
applying 5 grafts for stumpwm-22.11 ...
grafting '/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib' -> '/gnu/store/y8fd8yirq8n87sl7pv2wliwihrrbv820-stumpwm-22.11-lib'...
successfully built /gnu/store/w5027r2xlf88pfafw9dsx38cya01la83-stumpwm-22.11.drv
applying 2 grafts for sbcl-stumpwm-cpu-0.0.1-5.4613a95 ...
grafting '/gnu/store/r3l0dxxlcdh73092q9fmjj629klayxhq-sbcl-stumpwm-cpu-0.0.1-5.4613a95' -> '/gnu/store/nvp9y9qgpv4w22dqbjmdyc0l41gymims-sbcl-stumpwm-cpu-0.0.1-5.4613a95'...
successfully built /gnu/store/w8fbnjz3a8rzigldazhqn75v1ncrwnmr-sbcl-stumpwm-cpu-0.0.1-5.4613a95.drv
/gnu/store/nvp9y9qgpv4w22dqbjmdyc0l41gymims-sbcl-stumpwm-cpu-0.0.1-5.4613a95

Now that there are two distinct derivations for two distinct stumpwm:lib
outputs, we can look at the builders.

Toggle snippet (41 lines)
;; guix build stumpwm, stumpwm graft builder
(begin (use-modules (guix build graft) (guix build utils) (ice-9 match))
(define %outputs (list (cons "lib" ((@ (guile) getenv) "lib")) (cons "out" ((@ (guile) getenv) "out"))))
(begin (setenv "GUIX_LOCPATH" "/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib/locale")
(setlocale LC_ALL "en_US.utf8"))
(let* ((old-outputs (quote (("lib" . "/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib")
("out" . "/gnu/store/2rd3r0m8q11icwhhbwfl20ali3w5mwf4-stumpwm-22.11"))))
(mapping (append (quote (("/gnu/store/hqxzgbbbnxl8l9q8bcsvzvmyw1mjws4r-zstd-1.5.2-lib" . "/gnu/store/x35wy730jwwmwwypvzy2nmqvcb3hc3ba-zstd-1.5.2-lib")
("/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib" . "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib")
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35" . "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35")
("/gnu/store/hbzlh3zjss4w80jscwfkivpyqc2sqbm3-sbcl-alexandria-1.4-0.009b7e5" . "/gnu/store/p8iagp15zzj5ivh3j8443jjpq6wmmzpw-sbcl-alexandria-1.4-0.009b7e5")
("/gnu/store/jd34ay8cyyl2dag62n94m15gg1b4s1sw-sbcl-2.4.0" . "/gnu/store/vj5jdgz6dajq25f6arjw976h6awwblgh-sbcl-2.4.0")
("/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16" . "/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16")
("/gnu/store/kf04j56xzh2pglwz3d8ybiz7wxwrs4df-sbcl-clx-0.7.5-1.3840045" . "/gnu/store/3sbrd8gj3ddq3cya2fygj0q788wp0kbr-sbcl-clx-0.7.5-1.3840045")
("/gnu/store/1xpjw51n2alaszrvwwm2f78k3nnnlrk1-sbcl-fiasco-0.0.1-2.bb47d2f" . "/gnu/store/z4l73b6b1a6ijfd5chpijjbi37mbq5wl-sbcl-fiasco-0.0.1-2.bb47d2f")
("/gnu/store/7xiwhrv7x4isj2860par69xas9lrk4av-sbcl-cl-ppcre-2.1.1" . "/gnu/store/h7r9c6wxm7d3yk803jyw86c0pr86rxcj-sbcl-cl-ppcre-2.1.1")))
(map (match-lambda ((name . file) (cons (assoc-ref old-outputs name) file))) %outputs)))) (graft old-outputs %outputs mapping)))



;; guix build sbcl-stumpwm-cpu, stumpwm-graft builder
(begin (use-modules (guix build graft) (guix build utils) (ice-9 match))
(define %outputs (list (cons "lib" ((@ (guile) getenv) "lib"))))
(begin (setenv "GUIX_LOCPATH" "/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib/locale")
(setlocale LC_ALL "en_US.utf8"))
(let* ((old-outputs (quote (("lib" . "/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib"))))
(mapping (append (quote (("/gnu/store/kf04j56xzh2pglwz3d8ybiz7wxwrs4df-sbcl-clx-0.7.5-1.3840045" . "/gnu/store/3sbrd8gj3ddq3cya2fygj0q788wp0kbr-sbcl-clx-0.7.5-1.3840045")
("/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16" . "/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16")
("/gnu/store/1xpjw51n2alaszrvwwm2f78k3nnnlrk1-sbcl-fiasco-0.0.1-2.bb47d2f" . "/gnu/store/z4l73b6b1a6ijfd5chpijjbi37mbq5wl-sbcl-fiasco-0.0.1-2.bb47d2f")
("/gnu/store/jd34ay8cyyl2dag62n94m15gg1b4s1sw-sbcl-2.4.0" . "/gnu/store/vj5jdgz6dajq25f6arjw976h6awwblgh-sbcl-2.4.0")
("/gnu/store/7xiwhrv7x4isj2860par69xas9lrk4av-sbcl-cl-ppcre-2.1.1" . "/gnu/store/h7r9c6wxm7d3yk803jyw86c0pr86rxcj-sbcl-cl-ppcre-2.1.1")))
(map (match-lambda ((name . file) (cons (assoc-ref old-outputs name) file))) %outputs)))) (graft old-outputs %outputs mapping)))--8<---------------cut here---------------end--------------->8---

Different builders? Different outputs. Different outputs? Different
50-stumpwm.conf files. Different 50-stumpwm.conf files? Sadness.

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
R
R
Richard Sent wrote on 27 May 09:05 +0200
Re: bug#62890: StumpWM fails to start - Read only file system
(address . 62890@debbugs.gnu.org)
87bk4rvinf.fsf_-_@freakingpenguin.com
Richard Sent <richard@freakingpenguin.com> writes:

Toggle quote (4 lines)
> Packages that depend on say, A:lib graft their own copies of A:lib that
> is distinct from grafting A:out and A:lib together. This behavior
> confuses asdf-build-system and leads to breakage.

I should rephase this. asdf-build-system is doing its job just fine. I
don't think it's the build-system that's broken. It's that splitting
outputs like this simply leads to incompatibility with asdf itself.

That being said, I've never actually /used/ asdf. I welcome thoughts
from my betters! :)

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
G
G
Guillaume Le Vaillant wrote on 24 Jun 13:50 +0200
(name . Richard Sent)(address . richard@freakingpenguin.com)(address . 62890@debbugs.gnu.org)
877ceewodw.fsf@kitej
Hi.
Here's a patch for using a single output for stumpwm instead of having
a separate lib output. Could you check if it works for you?
Attachment: 0001-gnu-stumpwm-Use-a-single-output.patch
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZnldiw8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j/DHgD+Musqw16p09NRnDcmlZVwsVEt2HwExfKg4Z/f
zjtQAF8A/3CG3VZpzhrBEAZ3+4wN6i8mt7KztYdaEE2MzJHrRRR8
=9d3E
-----END PGP SIGNATURE-----

R
R
Richard Sent wrote on 29 Jun 03:03 +0200
(name . Guillaume Le Vaillant)(address . glv@posteo.net)(address . 62890@debbugs.gnu.org)
87ed8gv9u0.fsf@freakingpenguin.com
Hi Guillaume,

Thanks, your patch works for me! I don't expect many use cases to break
from this (how many people want to install stumpwm lib but not stumpwm
proper), but there's probably a fair amount of configs that'll break.
Maybe it deserves a NEWS entry.

I dream of the day https://issues.guix.gnu.org/48907is fixed.

While testing this I noticed that the error message can be even less
descriptive than reported previously. With my current StumpWM config,
without your patch, and with grafts enabled I get the following error:

Toggle quote (2 lines)
> Memory fault in 0x<some_random_hex_address>.

Yeah, that's a fun one to debug. Very informative ?. I spent far too
long bisecting a big Guix commit list before realizing this was ALSO a
grafting issue.

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
G
G
Guillaume Le Vaillant wrote on 29 Jun 11:03 +0200
(name . Richard Sent)(address . richard@freakingpenguin.com)(address . 62890-done@debbugs.gnu.org)
87cyo09l37.fsf@kitej
Thanks for testing. Patch applied as
a46908620fac09bd8ccd0f587a27e86035d3b1d7.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZn/N/A8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j8BMwD/WVRr4sEuJw1etMKfCyUBtvO1xr+rlvySp15M
6ff2wFwA/0QVNYtLJXXGA5F92dFoCBuabwJEv+1XLGICMzlI16lZ
=6RnR
-----END PGP SIGNATURE-----

Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 62890@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62890
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch