search

#packaging for guix

#packaging for guix

I recently took a more serious look at guile scheme and guix. I didn’t really knew what I did it, but that’s what I did.

In that action I went through the guix manual (I read in Emacs’ info, so probably I started in a moment of no-internetness and have to read info for entertainment; nice to see SICP in there too.) and clarified a few things I was confused about with guix and guile, namely

1. what is record and what that (package (inherit xx)) syntax supposed to mean. short answer; struct/oop and guix’s own defined syntax.
2. the GEXP as I didn’t knew what #~ and #$ meant, as well as those symbols that weren’t defined such as emacs in them. It is good to know that they just expand to /gnu/store/xxxxxxx-emacs strings.

I also familiarized myself just with the entirety of the stuff under guile/3.0/site/{guix|gnu} and apprantly some of srfi-n and ice-9, by not knowing what open-pipe* was and trying to find where it is defiend. Also, geiser just worked, (which I remember that it used to not,) which is helpful

Knowing what mkdir-p, substitute*, invoke, symlink each meant and supposed to do also helped; and in no time I can actually read all those packages.

And that is when I remembered my hack on using sbcl in guix. If you didn’t know, common lisp on Guix System had this problem that unless you use guix packaged ASDF systems, no ASDF system using cffi:foreign-library like libsqlite.so can find those libs. And the traditional work around I’ve been using is to prepend those individual /gnu/store/xxxxx-sqlite3/lib paths in LD_LIBRARY_PATH; Another workaround is to prepend ~/.guix-profile/lib, but that is not proper and gives you random segfaults.

My sbcl command was a script with a very long list of LD_LIBARY_PATH; and I’ve got to do it again for every .so I needed, I even build tooling just for that, a guix_path

echo $(guix package -I |grep $1 | sed -E 's/.*\t+([^[:space:]]+-[0-9]+\.[0-9]+\.[0-9]+).*/\1/')

guix_path sqlite

that returns the path of a package so I can write LD_LIBRARY_PATH=$(guix_path sqlite)/lib:$(guix_path mesa)/lib:...

I was kind of lisp package manager shopping a while back; I was using quicklisp, then vendoring with local-project, and then unknowningly lem’s .qlot and nyxt’s build for some reason (they were in the asdf registry apparantly). I moved on to vend for a bit, drawn to the concept of vendoring systems from watching the primagen about Odin as the controll and mess were pleasing the soul then; and then it didn’t; then qlot since, after I made sure I understood how it worked. Even that I had problem with about local systems.

Knowing what I knew now and examples I can usually just copy from gnu/pacakge/lisp-xyz.scm, I made my own channel and packaged clog, which I’m using for a project now, and finally living in peace with just CL_SOURCE_REGISTRY=[projectpath] sbcl.

Then I packaged cl-completions, an llm-api system I was using, and added it to the inputs of the package I’m developing.

(This is the channel)

And that’s probably when how easy and proper this is dawned on me really. Before I just vaguely thought that this should be the proper way to do thing in Guix System. And at the time I knew I also enjoyed it.

So quite naturally I went on to package ewm and the skia emacs (pwayl patch EZ was working on, made scrolling through lots of images snapping fast).

Primary road block of ewm is that it is in rust and rust is a bit difficult in guix. Luckily I had built ewm myself with this guix shell workaround and have been using it (Why have I been avoiding going the guix way for everything for so long), so the more difficult parts of wrapping the executable, fixing rpath I have already done; (even if I hadn’t, just rgrep fix-rpath and wrap in gnu/packages, there are PLENTY examples, it’s like the standard practice); with the rust crates, I imported everything in Cargo.lock with a bit of emacs magic (read the guix import result with emacs and did a mapcar cadr on them to get all the symbles). And it was done.

For emacs there are 3:

1. guix’s skia (version 122) is too old, it’s from 2016 or something, specifically EZ’s patch uses some Sk…freetype.h that it didn’t have.
   • I got the version 144 from nixpkgs which I think EZ’s using as that’s in nixpkgs and there isn’t changes in his nix definition.
   • And it didn’t compile, missing some google zlib extension. I removed the part building it in a BUILD.gn file. And it compiled.
   • And test didn’t pass. so I removed the test phase as well. I was a bit worried, but I see there’s a lot in gnu/packages, so that’s that.
2. EZ’s patch include skia with #include "core/Sk..." , where in my skia headers there’s #include "include/core/Sk...".
   • So I susbtitute* the skia includes in EZ’s patch as it is downstream and have less of them.

3. the third is quite minor, emacs didn’t use g++ so never set it, and EZ added a rule in configure.ac that uses g++ (CXX) but when failing just ask you to use a compiler with -fno-rtti support. I bypassed it and found out that I don’t have CXX set when compiling emacs_skia.cpp failed and I can see in the Makefile

   CXX =
   ....
   $CXX -o ....
   

   So (setenv "CXX" "g++") in a phase before configure fixed it.

That’s about 4 days worth of adventure, one of which is bit stressful as the skia/emacs bit is kind of difficult for me. Got through it tho.