Arch Linux: stumpwm, sbcl installed from distros repo, error in stumpwm ("cannot create directory /build")

[yusi1]

I installed StumpWM and SBCL from my distros repository and when I try to restart StumpWM it has this error:
Error loading /home/yaslam/.stumpwm.d/init.lisp: Can't create directory /build.

I'll try and build StumpWM andd SBCL from source and see if the error goes away.

[adlai]

Thank you for reporting this problem; I have encountered similar error messages, when attempting to load swank.

I have contacted the maintainer, although my hopes are low, due to the wide variety of packages for which he is also responsible.

[adlai]

[...] when I try to restart StumpWM it has this error: Error loading /home/yaslam/.stumpwm.d/init.lisp: Can't create directory /build.

How were you restarting the window manager?

[adlai]

I'm not gonna blame anyone, because they all move quickly and the world is so fucking fragile.

What I discovered, so far:

• Common Lisp afictionados still don't give two shits about Linux distributions;
• The breakage may have occurred when stumpwm-contrib got cut away;
• If you do not want to cause notifications, stop using the Internet.

[dmb2]

I think a lot of us who are actively developing compile and run stumpwm directly, rather than through the packages in whatever linux distro we're running.

Any help with reproducing the issue would be very helpful.

@adlai I appreciate your frustration. We're all doing this in our spare time as a passion project. We might make mistakes, but everyone contributing is acting with good intent.

[adlai]

[...]
@adlai I appreciate your frustration. We're all doing this in our spare time as a passion project. We might make mistakes, but everyone contributing is acting with good intent.

One of my favorite tricks is making projects fail automated distribution; obviously, that would be overkill for this one.

[adlai]

https://bugs.archlinux.org/task/76866

[grawlinson]

Yo, downstream maintainer here. I've just added stumpwm-contrib as an optional dependency to the stumpwm package on Arch.

Any issues, let me know via the bug tracker (link above), or this issue.

[yusi1]

I think a lot of us who are actively developing compile and run stumpwm directly, rather than through the packages in whatever linux distro we're running.

Any help with reproducing the issue would be very helpful.

@adlai I appreciate your frustration. We're all doing this in our spare time as a passion project. We might make mistakes, but everyone contributing is acting with good intent.

This is what I ended up doing.
Sorry for not replying everyone, I must've forgotten about this issue.

[adlai]

Yo, downstream maintainer here. I've just added stumpwm-contrib as an optional dependency to the stumpwm package on Arch.

Thank you for making the new package.

Any issues, let me know via the bug tracker (link above), or this issue.

Looking at the current situation, it seems to me that all the optional dependencies of stumpwm (with the possible exception of emacs) ought actually be optional dependencies of stumpwm-contrib; thoughts?

[grawlinson]

That’s a really good point, actually. I dare say that the current optional dependencies of stumpwm were added prior to the -contrib split. I’ll create a bug issue on our tracker and look into this after the new year.

edit: downstream report.

[dmb2]

stumpwm-contrib is a wild west mish-mash of all kinds of things. Its dependencies will be greater than stumpwm dependencies.

Forgive my ignorance of how distro package dependencies are managed, but doesn't our stumpwm.asd file define our dependencies?

[adlai]

Forgive my ignorance of how distro package dependencies are managed, but

Forgiven! The tip of the iceberg is plain-text files containing configuration variables and script snippets, although naturally, the devil is in the details. If you wish help choosing which link is relevant: the latter link is mainly relevant for folks working towards making packages that can be adopted by the official distributors, while the former covers what is relevant for independant management of personal systems and lone wolf packs.

doesn't our stumpwm.asd file define our dependencies?

Thank you for not including a link to the moving target; it currently includes not much about the contribs, although I imagine that the mechanics for defining and loading them are still referenced from the main system. There does not appear to be any separate definition file for the broken-out stumpwm-contrib sister repo, and I am no ASDF wizard.

I hope the above information is more helpful than verbose.

[greg-minshall]

i installed both stumpwm and stumpwm-contrib today, and got the
same "Can't create directory /build" as the OP.

after a large amount of flailing around, i cloned the stumpwm
repository and checked out the commit (fff2508...) that the current
PKGBUILD seems to have. then, following the PKGBUILD, i did

• autoconf
• ./configure ...
• make

which all ran fine. i then put the path to the stumpwm binary that
was produced into my .xinitrc, and re-booted.

when i came back up, i was able to (load-module "battery-portable")
with no error.

i then quit stumpwm which, the way my .xinitrc is written, caused
/usr/bin/stumpwm to run. here, i was not able to do (load-module "battery-portable").

i noticed something: when the load-module fails, there is a
backtrace printed out by sbcl (the common lisp), and on the 18th
frame of this backtrace, it says

((lambda nil :in "/build/stumpwm/src/stumpwm/make-image.lisp"))

which makes me wonder if somehow the location at which the binary is
being built is somehow "leaking" into the binary. (certainly,
strings(1) shows lots of occurrences of /build/stumpwm/src/stumpwm
in /usr/bin/stumpwm; the version i built has lots of
/var/tmp/foo/stumpwm in the binary.)

hth.

[greg-minshall]

and, i did another test, though the results are negative.

i sudo mkdir /baddirectory, and then downloaded the current PKGBUILD into a subdirectory of that, and did a makepkg(1) there (using no options -- i wasn't sure what options one might give to makepkg(1)).

that completed, then i sudo mv /baddirectory /worsedirectory (i.e., something like running without /build, but with different naming).

then i pointed my .xinitrc at the /worsedirectory/.../stumpwm, re-booted. and, the /worsedirectory/.../stumpww does load-module just fine. fwiw.

[dmb2]

@greg-minshall Any way you could post the whole backtrace?

Lisp puts weird stuff in weird places and breaks when the assumptions are invalidated. This is probably a problem with how sbcl creates binaries but the fix may not be straightforward.

[greg-minshall]

@dmb2 apologies, but now when i run /usr/bin/stumpwm (the one straight out of the package), even after re-booting, i have no problem with load-module. so, i can't show the backtrace.

and, i can't explain the behaivor i described above. one possibility is -- well, okay, one is that i was totally confused (possible). another is that some bit of my configuration has changed over the past several days, allowing load-module to work.

a third possibility is that between loading the two packages (stumpwm and stumpwm-contrib) and seeing the failures i did not reboot (i don't remember), and that re-booting kicked something in the system, and now load-module works. (but, i seem to have re-booted times the day i loaded the packages.)

[greg-minshall]

ok. i re-created the error. something like this (from a system with stumpwm and stumpwm-contrib installed via pacman).

• pacman -R stumpwm-contrib stumpwm
• pacman -S stumpwm
• reboot
• pacman -S stumpwm-contrib
• reboot
• "load-module mpd" fails. no load-path
• eval module-dir shows /usr/share/stumpwm/contrib/
• eval (init-load-path module-dir)
• load-path now packed
• "load-module mpd" fails
• eval (load-module "mpd") gives stack trace

bash archlinux (master): {23} /usr/share/stumpwm/contrib/util/stumpish/stumpish
Welcome to the STUMPwm Interactive SHell.
Type commands for a list of commands.
...
> lload-module mpd
Error In Command 'load-module mpd': Can't create directory /build
> eeval (load-module "mpd")
Can't create directory /buildBacktrace for: #<SB-THREAD:THREAD tid=1058 "main thread" RUNNING {1005030093}>
0: (STUMPWM::BACKTRACE-STRING)
1: (ERR "~A" #<SB-INT:SIMPLE-FILE-ERROR "Can't create directory ~A~:[~;,~%a file with ~
                          the same name already exists.~]" {10025B4EB3}>)
2: (EVAL-LINE "(load-module \"mpd\")")
3: (STUMPWM::CALL-INTERACTIVELY "eval" #S(STUMPWM::ARGUMENT-LINE :STRING "eval (load-module \"mpd\")" :START 24))
4: (STUMPWM::EVAL-COMMAND "eval (load-module \"mpd\")" NIL)
5: (STUMPWM::HANDLE-STUMPWM-COMMANDS #<XLIB:WINDOW :0 522>)
6: (STUMPWM::HANDLE-EVENT :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)> :EVENT-KEY :PROPERTY-NOTIFY :EVENT-CODE 28 :SEND-EVENT-P NIL :SEQUENCE 14610 :WINDOW #<XLIB:WINDOW :0 522> :EVENT-WINDOW #<XLIB:WINDOW :0 522> :ATOM :STUMPWM_COMMAND :TIME 948399 :STATE :NEW-VALUE)
7: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT))
8: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
9: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<FUNCTION (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT) {7F162F7BF18B}> #<SB-THREAD:MUTEX "CLX Event Lock" taken owner=main thread> T 0)
10: (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)> :HANDLER #<FUNCTION STUMPWM::HANDLE-EVENT> :TIMEOUT 0 :PEEK-P NIL :DISCARD-P NIL :FORCE-OUTPUT-P T)
11: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
12: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<FUNCTION (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN STUMPWM::DISPATCH-ALL) {7F162F7BF43B}> #<SB-THREAD:MUTEX "CLX Event Lock" taken owner=main thread> T NIL)
13: ((FLET STUMPWM::DISPATCH-ALL :IN "/build/stumpwm/src/stumpwm/stumpwm.lisp") #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)>)
14: ((:METHOD IO-LOOP (STUMPWM::SBCL-IO-LOOP)) #<STUMPWM::SBCL-IO-LOOP {1003A6D0B3}> :DESCRIPTION "StumpWM") [fast-method]
15: (STUMPWM::STUMPWM-INTERNAL-LOOP)
16: (STUMPWM::STUMPWM-INTERNAL ":0")
17: (STUMPWM ":0")
18: ((LAMBDA NIL :IN "/build/stumpwm/src/stumpwm/make-image.lisp"))
19: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
20: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
21: (SB-IMPL::%START-LISP)

[greg-minshall]

note line 18 of the backtrace

18: ((LAMBDA NIL :IN "/build/stumpwm/src/stumpwm/make-image.lisp"))

after the above was not working, then, i

• =pacman -R stumpwm-contrib stumpwm=
• then went to the package i had built with the arch package in
  worsedirectory/make-a-pkg/stumpwm/stumpwm/,
• did a pacman -U stumpwm-22.11-5-x86_64.pkg.tar.zst.

then i rebooted.

then, when the system came up, stumpwm worked just fine.

[KonstantinDjairo]

i've got the same error

[dmb2]

Exact steps to reproduce? Is it in arch?    DavidOn Dec 10, 2023, at 9:33 PM, Konstantin ***@***.***> wrote: i've got the same error —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[KonstantinDjairo]

yes, it's on a arch-based distro, artix.
i got stumpwm from the aur, and also stumpwm-contrib.
i've tried to follow the steps from @greg-minshall but didnt worked here, still broken and somehow it still tries to build stuff on that directory:
~/.stumpwm/modules/
and then it says that the build failed.
even tho i already modified the module-path to (set-module-dir "/usr/share/stupmwm/contrib/")

[KonstantinDjairo]

ok. i re-created the error. something like this (from a system with stumpwm and stumpwm-contrib installed via pacman).

* pacman -R stumpwm-contrib stumpwm

* pacman -S stumpwm

* reboot

* pacman -S stumpwm-contrib

* reboot

* "load-module mpd" fails.  no _load-path_

* eval _module-dir_ shows /usr/share/stumpwm/contrib/

* eval (init-load-path _module-dir_)

* _load-path_ now packed

* "load-module mpd" fails

* eval (load-module "mpd") gives stack trace

bash archlinux (master): {23} /usr/share/stumpwm/contrib/util/stumpish/stumpish
Welcome to the STUMPwm Interactive SHell.
Type commands for a list of commands.
...
> lload-module mpd
Error In Command 'load-module mpd': Can't create directory /build
> eeval (load-module "mpd")
Can't create directory /buildBacktrace for: #<SB-THREAD:THREAD tid=1058 "main thread" RUNNING {1005030093}>
0: (STUMPWM::BACKTRACE-STRING)
1: (ERR "~A" #<SB-INT:SIMPLE-FILE-ERROR "Can't create directory ~A~:[~;,~%a file with ~
                          the same name already exists.~]" {10025B4EB3}>)
2: (EVAL-LINE "(load-module \"mpd\")")
3: (STUMPWM::CALL-INTERACTIVELY "eval" #S(STUMPWM::ARGUMENT-LINE :STRING "eval (load-module \"mpd\")" :START 24))
4: (STUMPWM::EVAL-COMMAND "eval (load-module \"mpd\")" NIL)
5: (STUMPWM::HANDLE-STUMPWM-COMMANDS #<XLIB:WINDOW :0 522>)
6: (STUMPWM::HANDLE-EVENT :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)> :EVENT-KEY :PROPERTY-NOTIFY :EVENT-CODE 28 :SEND-EVENT-P NIL :SEQUENCE 14610 :WINDOW #<XLIB:WINDOW :0 522> :EVENT-WINDOW #<XLIB:WINDOW :0 522> :ATOM :STUMPWM_COMMAND :TIME 948399 :STATE :NEW-VALUE)
7: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT))
8: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
9: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<FUNCTION (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT) {7F162F7BF18B}> #<SB-THREAD:MUTEX "CLX Event Lock" taken owner=main thread> T 0)
10: (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)> :HANDLER #<FUNCTION STUMPWM::HANDLE-EVENT> :TIMEOUT 0 :PEEK-P NIL :DISCARD-P NIL :FORCE-OUTPUT-P T)
11: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
12: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<FUNCTION (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN STUMPWM::DISPATCH-ALL) {7F162F7BF43B}> #<SB-THREAD:MUTEX "CLX Event Lock" taken owner=main thread> T NIL)
13: ((FLET STUMPWM::DISPATCH-ALL :IN "/build/stumpwm/src/stumpwm/stumpwm.lisp") #<XLIB:DISPLAY :0 (The X.Org Foundation R12101009)>)
14: ((:METHOD IO-LOOP (STUMPWM::SBCL-IO-LOOP)) #<STUMPWM::SBCL-IO-LOOP {1003A6D0B3}> :DESCRIPTION "StumpWM") [fast-method]
15: (STUMPWM::STUMPWM-INTERNAL-LOOP)
16: (STUMPWM::STUMPWM-INTERNAL ":0")
17: (STUMPWM ":0")
18: ((LAMBDA NIL :IN "/build/stumpwm/src/stumpwm/make-image.lisp"))
19: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
20: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
21: (SB-IMPL::%START-LISP)

see? this is exactly the same what happens here, even if you explicitly state that the module folder is located at " /usr/share/stumpwm/contrib/" it stills fails to load any module, and here rebooting didnt solved anything.

[greg-minshall]

@KonstantinDjairo could you run stumpish (/usr/share/stumpwm/contrib/util/stumpish/stumpish), then enter these two commands

• eval module-dir
• eval (load-module 'mpd)

and then post the output?

[KonstantinDjairo]

of course
here's the full log:

https://pastebin.com/n9BTxf92

[greg-minshall]

@KonstantinDjairo thanks. sorry i didn't say *module-dir*.

but, the

Can't create directory /build

certainly seems the same problem.

are you certain that the version of stumpwm you are running that gave that error is the one you built from AUR? (i was hoping only the pre-built official Arch stumpwm package would give that result.)

maybe, in stumpish, enter version, and report what it says?

[KonstantinDjairo]

it's the binary version

https://archlinux.org/packages/extra/x86_64/stumpwm/

the git version doesn't compile at all.

the output of stumpish is as follows:

[hashirama@omnia ~]$ /usr/share/stumpwm/contrib/util/stumpish/stumpish 
WARN: rlwrap not found, command completion won't work
Welcome to the STUMPwm Interactive SHell.
Type commands for a list of commands.
> version
22.11 Compiled On Fri Nov 17 2023 17:28:08
> 

edit: im now compiling sbcl from source, to see if it fixes this weird behavior.
i'm following this tutorial

https://web.archive.org/web/20201001145752/https://carlo-hamalainen.net/2011/03/05/sbcl-stand-alone-packages-copy-n-paste-instructions/

but since i have to delete the old version of sbcl from my machine, im using clisp to compile sbcl.

sh make.sh /usr/bin/clisp

[KonstantinDjairo]

without much sucess, stumpwm itself doesn't compiled

https://pastebin.com/i1V6wqLY

i clone stumpwm from git, and compiled sbcl as i said above

edit: also found that patch in the AUR

https://aur.archlinux.org/cgit/aur.git/commit/load-ql-systems.patch?h=stumpwm-ql&id=f6b2eac04e05ea53b21a914b371377fbc9157f67

[greg-minshall]

thanks. btw, using the PKGBUILD from the Arch package (not AUR), i was able to compile, etc. ymmv, obviously.

[KonstantinDjairo]

the error was caused by the quicklisp from the package manager.
it seems that it's better to install everything out of the package manager (at least in arch-based distros)

i could compile stumpwm from scratch (directly from git) after uninstalling all clisp-related tools that I've installed with pacman, including quicklisp.

this is to say: a clean install from scratch without a package manager.

then everything worked.

edit: for anyone who wants to compile stumpwm in arch linux, remember to uninstall quicklisp and all packages related to lisp, let only sbcl, and then do as follows:

% fetch http://beta.quicklisp.org/quicklisp.lisp
% sbcl --load quicklisp.lisp
* (quicklisp-quickstart:install :path ".quicklisp/")
* (ql:add-to-init-file)
* (ql:quickload "alexandria")
* (ql:quickload "clx")
* (ql:quickload "cl-ppcre")
* (ql:quickload "quicklisp-slime-helper") ;; optional to hack StumpWM while it's running
* (quit)

then you can compile stumpwm as it's stated in the readme

[dmb2]

Please report this downstream to Arch's package maintainers.