<Apteryx>srfi-19 records are super slow to evaluate in Geiser. I wonder if this could be one of the reason compiling guix is so slow? <brendyn>Is there a project to libre-fy chromium or a webpage somewhere detailing what needs to be done? <efraim>There's a patch on guix-patches that's being worked on iirc <lfam>Anyone else getting 403 errors for mirror.hydra.gnu.org? Could be related to this hotel network, but not sure <Apteryx>s/srfi-19/srfi-9 (yesterday's question) <efraim>There's berlin.guixsd.org and bayfront.guixsd.org, or if you're looking for aarch64 substitutes git.flashner.co.il:8181 <Apteryx>they're already trusted by the guix-daemon, so all you need to do is pass them to the substitute-urls field of the guix-service configuration. <Apteryx>(if you intend to use them in your operating-system declaration) <happy_gnu[m]>guix archive --authorize < ~root/.guix-profile/share/guix/berlin.guixsd.org <Apteryx>As I wrote earlier, they are already trusted by the guix-daemon, so you don't need to authorize them manually :) <ng0>slighly OT: at which folder size (message per folder) would Gnus become usable? or do I remember it correctly that unless I use a cache, Gnus would scan every folder given anyway? <ng0>civodul: I found dusty pieces of a past a couple of weeks ago: mutt-guile. I supposed you don't have any of the now no longer available files beyond the sourcecode? <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) <ng0>hrm.. ant-bootstrap is failing <ng0>bootstrap.sh: line 155: 26 Segmentation fault "${JAVACMD}" -classpath "${CLASSPATH}" -Dant.home=. $ANT_OPTS org.apache.tools.ant.Main -emacs "$@" bootstrap <Apteryx>Oh, I hadn't thought about guix packs on Windows or Android. On Android you would need root, and on Windows, I guess the compatibility shim would allow files to live under /gnu/store? <Apteryx>I was thinking also in terms of native packaging, for smaller downloads and convenience (no need to be root on android for example). <jlicht>Apteryx: I can confirm that at least some simple cli-based applications in a pack work on Windows 10 (/w the linux subsystem, at least) <jlicht>and of course there is option of cross-compiling using MinGW target, which might work for other pieces of software <ng0>I'm trying again, maybe I had a bad commit <Apteryx>Wondering how cross-compiling for a different OS such as Windows work; does it still use /gnu/store? If so I guess it would need something like Cygwin to run? <ng0>and now icedtea compiles, after I had encountered the error I had 3 times ***OneBigMes is now known as NullConstant
<jlicht>Apteryx: I only compiled the `hello' program once, was amazed it worked on Windows, and moved on with life, so I do not know how complete/useful the produced binaries are <marusich>Is anyone here familiar with docker? I'm trying to use it to run Guix, and I'm a little confused... <civodul>Apteryx: for native packaging, you could always write a derivation that spawns a (say) Debian VM, and runs db_whatever in there <marusich>Specifically, I'm thinking: it would be nice to be able to take the output of 'guix pack -f docker -s x86_64-linux --localstatedir guix' and run it somehow using Docker. <marusich>However, I know guix-daemon requires things like build users...and I have little idea about how that meshes with Docker's paradigm. <Apteryx>marusich: I think that's exactly what it's made for. <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>marusich: dunno, it depends on what you want to do :-) <civodul>guix-daemon just sits there printing nothing by default <marusich>Huh, then maybe I misinterpreted what I saw. That is what I saw. <marusich>I want to "run guix" using Docker. On a Mac, specifically, but that's a detail that isn't really relevant. <marusich>So, I want to be able to fire up a terminal, and eventually just type things like "guix package -i hello" and have it install stuff (in the 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). <ng0>guix pack is involved there <TaoHansen[m]>so i'm trying to get an external drive with a (file-system) entry mounted and well it's not mounting. here's the error: <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? <civodul>marusich: good question, i have no idea <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. <civodul>perhaps we need 'guix system pack'... <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 would not be able to manage my installed packages from the mac on which I am working. <marusich>But...maybe it is actually more convenient than trying to run GuixSD in Docker? I suppose I could try. Maybe I spoke too soon. <cbaines>marusich, Are you thinking of building new images using Dockerfiles, or something else to manage installed packages? <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.