<fschl>I am thinking about getting starten with guix for my homeserver. The current setup is a debian machine running docker containers. At the moment I have some basic idea about system+home configuration with guix on a test laptop but struggle to figure out how to run nginx and several php-based web services on GuixSD. Could anybody be so kind and direct me towards a guide/documentation or even an example repo? tyvm :)
<next4th>fschl: there are nginx and php service example in gnu/tests/web.scm, which should be a good start
<ngz>sneek later tell mirai I'm not familiar with this part of the code (maybe rekado knows), but I think 1) you need to indeed add `texlive-bin' outside of `texlive-updmap.cfg' assuming dblatex tries to run binaries and need them in $PATH 2) GUIX_TEXMF should probably be exported in the wrapper so the local texmf tree is used instead of the one in the profile, if any.
<renngar>Shortish answer to my question: guix build the failed derivation, examine the log output. In my case the top frame was a primitive-load, the partial hash pointed to a builder and I discovered .ko.gz kernel modules are explicitly handled, but my custom build was using zstd, which is not.
<Altadil>lnnk: I think it depends on what desktop environment you are using.
<lilyp>is anyone knowledgable about low-level guix stuff here? I think I broke guix itself over at gnome-team; whenever I try building something, it starts pretty much from the bottom with gdk-pixbuf, even if earlier builds succeeded
<next4th>lilyp: eh, how could that happend.. if gdk-pixbuf was build succeeded, it won't build again unless its inputs/reciple changed (drv and output path will change)
<lilyp>that's exactly the thing i don't understand either
<next4th>did run 'guix build gdk-pixbuf; guix build gdk-pixbuf' will build it twice with different output paths?
<mirai>does anyone have any idea what package provides 'xkbregistry'?
<sneek>mirai, ngz says: I'm not familiar with this part of the code (maybe rekado knows), but I think 1) you need to indeed add `texlive-bin' outside of `texlive-updmap.cfg' assuming dblatex tries to run binaries and need them in $PATH 2) GUIX_TEXMF should probably be exported in the wrapper so the local texmf tree is used instead of the one in the profile, if any.
<nckx>The problem with packages like libxkbcommon is that there are ‘legitimate’ reasons to have them installed, so propagation is actually noticable by users. They'd suddenly get libxml2 installed along with it.
<nckx>‘Legitimate’ because they provide binaries, not just libraries.
<ngz>mirai: Maybe one way to avoid the (getenv "GUIX_TEXMF") would be to loop over the inputs and add all /whatever/share/texmf-dist to GUIX_TEXMF. However, I didn't change the part about GUIX_TEXMF, so rekado may have a better idea.
<ngz>I don't know how to provide, in a simple way, an isolated and fixed texmf tree.
<ngz>But I think GUIX_TEXMF was introduced for that purpose.
<mirai>mktexfmt is gone from texlive-bin (I was doing guix build on an older checkout and it was still present back then)
<ngz>mirai: "kpathsea: Running mktexfmt pdflatex.fmt" means it cannot locate contents of texlive-latex-bin package. Are you sure you're using the definition I pasted? (note that the package name is dblatex-test)
<amjoseph>hi, i'm trying to get an understanding of how guix does certain things, coming from a background with (quite a lot of) nix experience but almost no scheme exposure. in nix we have an eval/build separataion: the packaging language evaluates to a derivation, and derivations do not have access to the packaging language evaluator (well, they do, but that mechanism is called "IFD" and is forbidden in nixpkgs).
<amjoseph>it looks like guix does not have this restriction: search-input-file is an example of something that you can't do in nix without IFD.
<amjoseph>does guix's derivation language allow arbitrary guile expressions?
<amjoseph>nix's derivation language is basically not executable. it's just a list of environment variables and a list with argv.
<amjoseph>can i do something like (search-input-file ...) and then, say, branch on whether the length of the resulting string is odd or even?
<andreas-e>Hello, amjoseph! I think the answer is that a Guix derivation is an arbitrary Scheme file.
<amjoseph>oh! i get it. the derivation language is still "just argv and envp", but since the "builder" (argv) is often the guile interpreter rather than scheme, it's easy to defer chunks of the packaging language into the derivation. i totally get it now.
<amjoseph>so i guess the fundamental difference that makes this possible in guix is the fact that scheme programs are easy to serialize, and nix programs are basically impossible to serialize.
<andreas-e>You probably understand it better than I do ;-)
<amjoseph>i think we each understand different parts of it; thank you so much for sharing your part
<andreas-e>Your explanation sounds good to me. Since we still use the Nix daemon, the "derivation language" must probably be the same one.
<amjoseph>i thought you folks had rewritten nix-daemon? are you using some fork of the C++-language nix 2.3.16?
<andreas-e>In our git repo, there is a subdirectory nix/nix-daemon with a file guix-daemon.cc, and Copyright Eelco Dolstra between 2006 and 2014 (and then Ludovic)...
<amjoseph>ah c2033df432af87d0176347858c7d11acfe2ed89f build: Include a copy of Nix's libstore and daemon
<andreas-e>When you speak of "serialising scheme", this is probably quoting: Considering code as just a list. There is a quoting/unquoting dance (or nowadays, gexping and ungexping) in the package recipes, that distinguishes between Scheme that is compiled into the package object and Scheme that is passed on to the builder.
<mirai>ngz: indeed, with getenv it builds the test file