<reepca-laptop>The order in which imported modules get compiled is depth-first based on a scandir, meaning we compile leaves first in ascending alphabetical order. If I understand correctly, we need to compile higher-level modules before the stuff they depend on. Since we try to make it so that modules in subdirectories never depend on stuff at a higher level, would it work to just switch to breadth-first compiling (first compile all the leaves of
<apteryx>I had not touched an importer yet, so it was interesting to discover how things were wired
<apteryx>regarding the circular dependency with python-urllib3, seems to be a problem on my side (maybe one of the patches I have on my stack, adding some Python dependencies), as I can't reproduce using my 'guix pull'd' guix.
<apteryx>OK, figured out the circular deps caused by adding python-urllib3 to python-requests: urllib3 -> cffi -> sphinx -> requests // requests -> urllib3
<apteryx>it's unfortunate, since sphinx is only used as a native dependency of cffi (build time only). I'm not sure how to fix this.
<apteryx>I could make a 2nd requests package derive from the original requests, but that seems a ugly hack
<mbakke>apteryx: The requests<->urllib3 cycle is solved on the staging branch.
<Blackbeard[m]>(define (equivalent-narinfo? narinfo1 narinfo2) "Return true if NARINFO1 and NARINFO2 are equivalent--i.e., if they describe the same store item. This ignores unnecessary metadata such as the Nar URL." (and (string=? (narinfo-hash narinfo1) (narinfo-hash narinfo2))
<Blackbeard[m]>I am sorry I haven't done my proposal earlier I had a few family issues
<Blackbeard[m]>Longer-term, binaries could very well be downloaded from a content-addressed store such as IPFS orGNUnet without having to forego our existing infrastructure. Peer-to-peer distribution of binaries has been on our mind for a while, but we hadn’t quite realized this decoupling and how it would allow us to support a smooth transition.
<wednesday>civodul: for me the operating-system keyboard-layout gives errors, bootleader keyboard-layout leaves me with no keyboard, and I think the whole update broke sddm because it starts with no x config now, that's what I've found out about the whole keyboard thing heh
<shcv>also, I was wondering about how to package the caddy server (https://caddyserver.com/), which supports plugins by importing go modules. What's the right way to make a modular package, instead of requiring everyone who wants to install it to repackage it themselves with a different set of plugins?
<shcv>(importing them before building the server, that is)
<roptat>usually, that is done with environment variables
<roptat>does it use a PATH-like variable to find its plugins?
<roptat>shcv, you can find an example in gnu/packages/ocaml.scm for instance : the ocaml package defines native-search-paths to have users define OCAMLPATH in their environment
<jlicht>I think this might not be possible at this time, but does anyone know how to build arm software using x86_64 binary guix on top of a different distro? I seem to recall this working really well using the binfmt service, but don't really know how to have my current guix-daemon do something similar
<jlicht>(as in, I already had this working some time ago on a Guix System machine, but I want to do the same thing on a non-Guix System system)
<jlicht>I figured it out; simply adding the right directories to guix-daemon via --chroot-directory=/usr/arm-linux-gnueabi and adding qemu-arm-static to the chroot seems to allow me to build armhf stuff using guix on a foreign distro :D