<ng0>ok :) it's an interesting idea nevertheless. but I don't have the energy to do it. what would be cool is guile bindings to neomutt to the extent that the config can be written in guile… just "because".
<Apteryx>civodul: Do you think guix could help in building a package that aims to targets multiple systems such as GNU/Linux (RPMs, Debs, Guix Packs), Windows, Android, iOS, macOS (pretty much every mainstream platform in existence). I see value for GNU/Linux with some work (we already have packs and docker, would need to come up with .deb and .rpm, maybe others), with Windows with more (a lot?) work, with Android with
<Apteryx>a lot of work, and the last two appear nearly impossible given lack of free dev tools there.
<civodul>Apteryx: a Guix pack can work on any GNU/Linux distro, as well as Android i suppose (given that it's the same kernel), and Windows (with its compatibility shim)
<civodul>marusich: beware: 'guix pack -f docker' currently ignores --localstatedir
<marusich>I realize I might be able to take an entire GuixSD disk image and just stuff all of its files into a docker image and then tell docker to run the init process...perhaps that is a saner way to do this, rather than trying to only put Guix itself into a docker container?
<civodul>so i guess 'guix pack' would be the thing
<civodul>the only limitation is the lack of --localstatedir for docker images currently
<marusich>Later, I can share files between the container and my host system - I know Docker makes it possible to do that - and I will look into ways to get graphical stuff (using Xorg, I guess) working, but for now I just want to get something simple running.
<marusich>OK, so --localstatedir doesn't actually do anything, like you said. That means that even if I get guix-daemon running in the Docker container, it won't really do anything useful?
<marusich>How are we producing binary installation tarballs for release, if --localstatedir does not work? The manual says that's how the binary installation tarball gets made ((guix) Binary Installation).
<marusich>So, after starting guix-daemon in container ('docker run dcb7750333e6 /gnu/store/...-profile/bin/guix-daemon ...'), I can run the "guix" command like this: docker exec e0d99951da06 /gnu/store/1q4s83nzlrxbxdphn0v1kq8npclmlh8s-profile/bin/guix package -i hello
<marusich>I can see the guix-daemon's stdout tellin me "accepted connection from pid 14, user 0", which is great, but the "guix" fails, saying: "guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist"
<civodul>TaoHansen[m]: i suspect "noauto" is not a valid option
<marusich>This brings me back to my original question: how do I 'add' the required users and groups to the container?
<marusich>Does docker have its own notion of users and groups that exist in the container, or does it expect to find the right files/services running in the container (like you would on a regular OS)?
<civodul>i suppose you could somehow run adduser in there?
<marusich>That's what I'm thinking, and that's what various posts on the Internet seem to suggest. My guess is that if /etc/passwd etc. exists, things will "just work"
<marusich>So...it seems like probably the path of least resistance might be to just take the files that make up a GuixSD system, and put that into a Docker container.... That way, I wouldn't have to hand craft all the details.
<marusich>Suppose you had that. So you can run GuixSD in a docker container. Then what? I would run "guix" commands to install stuff and upgrade things, in the container, I guess. What if I want or need (for security reasons?) to upgrade the GuixSD system in that docker container. I'd have to do another guix system pack, right?
<marusich>So I'd lose the state I accumulated by installing things via guix in the container. That seems to be undesirable.
<two>hello, every time I try to install guixsd to my laptop using the documentation I get to "guix system init /mnt/etc/config.scm /mnt" it fills up the USB drive from wich we are booted and not onto the /dev/sda1 which is mounted to /mnt
<marusich>If I have to do that, it seems good enough to just "guix pack" the specific things I need, and deploy that to my mac for running in docker.
<marusich>However, I suppose there might be other reasons to want to pack up a GuixSD system for deployment via Docker. If you intend to build a GuixSD system so you can deploy and run a stateless service, for example (maybe a web proxy or something), then it might make a lot of sense to take advantage of existing deployment tools that use Docker containers. It could be nice to have a "guix system pack -f docker" for that.
<marusich>But for my situtaion, where I really want to use guix to manage installed packages, it seems not that great, since I would wind up modifying the 'system pack' that gets deployed, which is gross.
<cbaines>two, did you run herd start cow-store /mnt ?
<marusich>Maybe it would make sense to have a "guix system pack" feature, after all. It's not much different in spirit from making a VM image or a disk image, I guess.
<marusich>And I suppose that if I can produce a docker container that I can use as a "virtual GuixSD system" to run on my Mac, that would be better than nothing.
<cbaines>marusich, when you say you want to use guix to manage installed packages, why not specify them at the time you run guix pack?
<marusich>Yeah, I could do that - it's just more inconvenient.
<marusich>I was hoping to be able to run "guix" commands on my Mac using Docker, to make it look like I am using Guix on my Mac. Docker is just one way to maybe do that. Certainly, making 'guix packs' and copying them over from time to time, and running them in docker, is one possible solution. It just means I couldn't manage those packages from my mac.
<marusich>civodul, rekado, I read more about GNU libc, and I see what you mean about it being probably infeasible to use on macOS :/ I didn't know.
<marusich>I didn't know that it was designed to only really run with linux or hurd, although I suppose in retrospect they do explicitly say that in their documentation and stuff.