IRC channel logs

<SomeoneS[m]><civodul> "not clear to me why they..." <- I didn't watch the talk yet (I should), but I'd guess they rely on mount namespaces bind `/nix/store` from a custom location/from a prebuilt image? At least in my uni the "IT team" won't bother with either of Nix or Guix, and they also won't enable user namespaces either (all we have is setuid singularity), so the location of the store is a bit of an issue...

<SomeoneS[m]>By the way, does Guix support relocatable builds (thinking Spack-like, maybe) or would one also have to rebuild the closure if they were to change the store path?

<flypaper-ultimat>SomeoneS[m]: yes! try guix pack -RR nano for example! See also the example on the bottom of https://hpc.guix.info

<flypaper-ultimat>They're great! I use them a lot on our HPC where we don't have guix and i dont have root.

<flypaper-ultimat>For more details see https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-pack.html or run "info '(guix) Invoking guix pack'"

<flypaper-ultimat>SomeoneS[m]: ah, did you mean of the guix executable itself?

<SomeoneS[m]>No-no, I mean the artifacts

<flypaper-ultimat>So does the section 'Sending Packages to Guix-less Machines' on the bottom of https://hpc.guix.info do what you want?

<SomeoneS[m]>Yes, it seems so! I'm just trying to understand the costs, bc I'm not so familiar with Guix.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/93f213b9b1c2a0538cd3a995e85d0a730c2ce704>)

<flypaper-ultimat>SomeoneS[m]: With public binary cache you mean "prebuilt binaries" so that you don't have to build everything from source? yes there is and it enabled by default, these are called "binary subtitutes", and are enabled by default, provided by buildfarms such as ci.guix.gnu.org. if you want to force building everything from source you can use the --no-substitutes flags. see also

<flypaper-ultimat> https://guix.gnu.org/en/manual/devel/en/html_node/Substitutes.html#Substitutes

<SomeoneS[m]>Say I hope to use the public cache even when using guix pack --relocatable

<SomeoneS[m]>Motivation: I could, in principle and with some effort, build this kind of relocatable software using `$ORIGIN` with nix(pkgs) as well, but that would take "rebuilding the world", at least the way things are today. That is expensive, so I wonder if Guix implements a more feasible solution?

<flypaper-ultimat>so in guix it doesnt rebuilt the world, it just wraps the programs in either usernamesaces, proot or fakechroot

<SomeoneS[m]>But what about pack --relocatable?

<SomeoneS[m]>It says it uses $ORIGIN and relative symlinks instead of absolute paths

<SomeoneS[m]>Which to me sounds very appealing, because I can't use any of these three on our cluster

<flypaper-ultimat>< in the `in the -RR case`

<rekado>I’ve often used “guix pack -RR”, works very well

<rekado>it’s a little heavy because you can’t share existing store items

<rekado>but it’s great when you don’t have a full Guix installation

<SomeoneS[m]>Oh, I misread the post, it doesn't claim anything about using $ORIGIN

<rekado>the wrapper used by “pack -RR” uses a number of different strategies to run the binary

<rekado>with GUIX_EXECUTION_ENGINE you can select the stategy, e.g.: default, performance, userns, proot, or fakechroot

<SomeoneS[m]>Thanks! I'm definitely going to check out Guix some time soon, it definitely seems like it went further than Nix in certain aspects

<civodul>SomeoneS[m]: check out https://guix.gnu.org/blog/2018/tarballs-the-ultimate-container-image-format/ on relocatable packs through user namespaces

<civodul>and https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/ for the other strategies, when user namespaces aren't available

<SomeoneS[m]>(no user namespaces on aalto's cluster :-()

<SomeoneS[m]>* aalto's cluster) :-(

<civodul>heh, see? :-)

<civodul>aalto?

<SomeoneS[m]>the uni whose cluster I'm using

<civodul>ok

<civodul>the fakechroot strategy above was born precisely because colleagues of mine regularly had to run code on clusters without unprivileged user namespaces

<SomeoneS[m]>How does it work? Is it not a setuid solution?

<civodul>nope, not at all

<civodul>it works unprivileged

<civodul>the blog post has all the technical details

<civodul>main takeaway is: no overhead

<SomeoneS[m]>But how?

<SomeoneS[m]>Hmm, looking at the man page, it seems to substitute some glibc functions using LD_PRELOAD?

<civodul>which man page?

<civodul>see https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/ :-)

<SomeoneS[m]>man 1 fakechroot

<civodul>fakechroot is just part of the solution; the rest is handled using an ld.so audit module

<civodul>but yes, it's LD_PRELOAD-style interposition

<SomeoneS[m]>civodul: Awesome! I like the writing, nixpkgs definitely could benefit from maintaining a similar blog:)

<civodul>so it's not as robust as syscall interception (PRoot) or user namespaces, but in practice it works well for most cases

<civodul>SomeoneS[m]: heh thanks :-)

<flypaper-ultimat>talking about blog-posts, wouldn't a blog post or a cookbook entry about how you can make your git repo a channel like shepherd's and guile's be pretty cool?

<flypaper-ultimat>i've been using it recently and its pretty rad.

<flypaper-ultimat>But i had to figure it out by looking at those examples, about e.g. `(source (local-file "." "skribilo-checkout" #:select? (git-predicate (current-source-directory))))`

<civodul>flypaper-ultimat: i started writing that just yesterday :-)

<civodul>i got distracted, but hopefully i'll have something by the end of the week

<flypaper-ultimat>civodul: awesome!

IRC channel logs

2023-05-24.log