Add Guix development stuff

[KarlJoad]

Adds in the necessary machinery for local checkout for development through guix shell and building with guix build.

This setup also allows Cuirass (Guix's CI, a reimplementation of Nix's Hydra) to build Mahogany continuously.

[KarlJoad]

This PR would also close out the final issue raised in #36, namely https://github.com/stumpwm/mahogany/issues/36#issuecomment-1763524208.

[KarlJoad]

This PR should be blocked until Guix pulls in the prerequisite patches for Mahogany's dependencies in https://issues.guix.gnu.org/66623.

[Tass0sm]

When I try this out, I get three errors. The first two are probably already known. Those are the following:

1. sbcl-wayland is an unbound variable. (replace with sbcl-cl-wayland)
2. cannot execute pkg-config (add pkg-config to native-inputs)

After fixing those the third is a LOAD-FOREIGN-LIBRARY-ERROR where it cannot find libxkbcommon. Just wanted to check if these are only issues on my end.

Thank you very much for writing the package definition!

[KarlJoad]

1. sbcl-wayland is an unbound variable. (replace with sbcl-cl-wayland)

I missed that, as I was testing in my personal channel before submitting upstream to Guix. You are right, sbcl-cl-wayland is the right one. I had to package that upstream in Guix. It is available after commit c065da01ff956d3c2bdfc45a33d910e509a211d9

2. cannot execute pkg-config (add pkg-config to native-inputs)

I had not gotten around to the heart stuff yet, so I had not yet added pkg-config. I built this package definition just by reading the README, the asd packages, and the build script.

After fixing those the third is a LOAD-FOREIGN-LIBRARY-ERROR where it cannot find libxkbcommon. Just wanted to check if these are only issues on my end.

This one is actually somewhat expected, as I had to add the xkbcommon Lisp FFI package to Guix. The commit with sbcl-xkbcommon is cbd1c983e1b7bc392287226e44437996cc2cf750. Loading foreign libraries is tricky in Guix, as certain asdf variables for package loading are unset/incorrect for the build environment.

This is still sitting as a draft because I need to work on the heart portion and fix the last few bugs in the definition. The first step was to get the vendored libraries into Guix itself (sbcl-cl-wayland and sbcl-xkbcommon). I'll get around to this again soon.

[Tass0sm]

I've just now made a package for the heart portion and finished up the main mahogany package using it. I may have made a few messy decisions along the way (deleting submodules in a phase which may not be necessary if not using the local source). After rebasing on the pull request #46, I was able to boot mahogany. I've made a fork with just the guix changes here.

[KarlJoad]

Thanks for your help @Tass0sm! I really appreciate it as school has gotten busier recently.

I pulled your changes in and made a few tweaks. The two largest being:

1. heart's version, source, and metadata follows Mahogany's. I felt this was the better option as heart is not a completely separate dependency right now (it is not a separate Git submodule or project, but just a directory inside mahogany).
2. heart uses a phase to change directory to the heart subdirectory inside of Mahogany. Your method of using the checkout will work, this way of writing the package will line up more closely with the package specification I will submit to upstream Guix.

I will rebase this on top of master tonight, so hopefully everything is ready to go once I do some quick tests on my system. Could you pastebin the system config you used to manually test Mahogany's functionality?

[Tass0sm]

And thank you for cleaning that up!

Here's an overview of my system: https://pastebin.com/yaYqWg9a Although maybe I'm misunderstanding the config you are referring to? I unfortunately didn't do any extra configuration for mahogany after just starting it.

[sdilts]

I unfortunately didn't do any extra configuration for mahogany after just starting it.

There's currently no way to apply configurations without recompiling. There really isn't anything to configure.

[KarlJoad]

Sorry @Tass0sm, I meant for the config you used to generate a system that ran Mahogany. Did you have an operating-system config that you used to create a VM to test with? Or did you reconfigure your currently-booted system.

I just need a minimal OS config that I can quickly test in a VM to make sure Mahogany does not just exit as soon as the display/seat manager drops you into your Wayland session.

[Tass0sm]

Oh I see. I'm using Guix on a foreign distro and only tested it there. I didn't make a separate VM. I think I can quickly look into writing that system configuration and testing it there too.

[KarlJoad]

I got a fairly minimal OS to boot in a VM, though I am not sure mahogany is working. I end up with a solid-colored background and seemingly no keyboard interaction (though I am probably wrong about that as I was testing in QEMU).

(define-module (test-system)
  #:use-module (guix gexp)
  #:use-module (gnu)
  #:use-module (gnu system)
  #:use-module (gnu tests)
  #:use-module (gnu services desktop)
  #:use-module (mahogany-package))

(operating-system
  (inherit %simple-os)
  (packages
   (list coreutils mahogany))
  (services
   (append
    (list
     (service elogind-service-type))
    %base-services)))

Just drop that config in mahogany/.guix/modules/test-system.scm and run the following command from mahogany's root.

mahogany$ $(guix system -L mahogany/.guix/modules vm ./.guix/modules/test-system.scm)

Note that you must have a version of Guix available in Guile's load-path that has the added necessary Common Lisp dependencies.

[Tass0sm]

Haha I just got to a similar point starting from the example config in the manual plus mahogany and seatd.

Indeed I only get the solid-colored background too and no apparent keyboard interaction both inside and outside of qemu. I thought that was all to expect.

[KarlJoad]

@sdilts Is this solid-colored background and inability to interact the current state of Mahogany?

[sdilts]

Pretty much. You should only be getting a cursor and a randomly colored background. Keybinding processing works too; run it under X11 or Wayland and watch the console, and see it echo your keyboard input. You can also close the program with C-t C-q. Keybindings are set in globals.lisp if you want to play around with it.

[Tass0sm]

It does seem that all the keyboard events are detected when using the guix-packaged mahogany and the keybind to quit works properly.

[KarlJoad]

@Tass0sm, I cannot seem to get a working test system that has a greeter/seatd/display manager using QEMU. But I can manually start mahogany on the command line, which brings a colored background and mouse cursor. Starting mahogany that way does not seem to respond to key events at all. Looking in ps when I manually start mahogany, I see only mahogany running, no Wayland (nor X), which might explain why there are no key events detected.

I have pushed a small operating-system in a separate file too, so others can try the system. @Tass0sm, could you take a look at it and diff it with the OS config you made? Perhaps I am just missing something small.

[KarlJoad]

@sdilts Does Mahogany (not Mahogany's heart) have a run-time dependency on libxkbcommon, since there is FFI to libxkbcommon through sbcl-xkbcommon?

[Tass0sm]

Hmm when I try that system it seems to work for me. The command to quit is actually C-t q instead of C-t C-q.

There are fewer logs about keyboard events in the vm than on my own system though. Not sure why.

[KarlJoad]

Apparently I just did not know what to expect out of Mahogany right now. The test system in a QEMU VM using sendkey ctrl-t then sendkey q did work to exit Mahogany.

I get some errors about EGL, but they do not seem to have stopped Mahogany or its heart. It seems to be working, but I would appreciate @sdilts looking over the inputs for the mahogany package definition to see if I missed anything or if things should move to native-inputs/propagated-inputs.

[sdilts]

There's a transitive dependency, yes. The front end uses a vendored version of cl-xkbcommon, which is found in the dependencies folder and is an ffi to that library.

There's another cl library called cl-xkb that we probably should be using instead, as although it doesn't have as nice of a lispy wrapper around the library, it's what is in quicklisp and is what the wayflan library uses.

Because of this, I'd hesitate to bundle cl-xkbcommon as a separate library and just treat it as a part of the greater system.

[KarlJoad]

The Guix package definition for Mahogany actually deletes the vendored version of cl-xkbcommon and replaces references from the vendored version to one that Guix understands (which is a separate package definition in Guix right now). If that will be very problematic for the future, then we can change that.

I meant if Mahogany depended on xkbcommon's .sos at runtime, but from your description, that seems to be the case, so I will make the package reflect that.

[KarlJoad]

@sdilts, how does this PR's contents look to you?

[sdilts]

Thanks!