<lfam>When I am installing GuixSD (which doesn't happen often except for testing), I usually install rsync and ssh in the installer and pull the OS config from a remote machine. It's not designed to persist in the situation you describe
<lfam>I thought you didn't finish installing it yet?
<lime_>I think I'll do the rtfm thing, in the morning
<lfam>When I said that it's not expected for your OS configuration to persist on disk, I thought that you were still using the installer image, not an installed system. Of course your files should persist once the system is installed.
<ng0>is GuixSD-logo.png the logo we want to have linked when the option is given at applications which list the systems with graphics, or is there another one for just the package manager? My choice would be GuixSD-logo from the artwork repo
<efraim>i don't have the artwork repo cloned on this machine, is that the one with the 3 pieces into a circle?
<ng0>it's the logo which can be seen on the first page of our web site
<ng0>on gnunet, I've spent some time reading gnunet papers to understand the intention and direction of secushare, where my main interest in gnunet is. this, and discussions with the other developers involved helped
<Petter>I have only barely looked at gnunet. Don't know much about it at all.
<ng0>the strategy with secushare changed as perfectionism was too slow, so my intention to package psyced for guix will be of use there too :) psyced will soon be able to federate native over gnunet
<ng0>and i'm looking into guixsd and nixos for "liveusb" systems for secushare.
<ng0>i tried nixos before, but this time i have to say guix is easier.. i have not managed to boot into X11 with thei documenttion
<ng0>it's a sandboxed chatserver, providing xmpp, irc, psyc, telnet, etc. almost 20 years old and still running. used to be a big network. PSYC0.99 (1) is not like PSYC2. there's a wiki on it, although a bit messy.
<wgreenhouse>mark_weaver: since you were discussing the guix build environment, is it reasonably possible to [ab]use "guix environment --container" as a sandbox for processes interacting with untrusted data?
<lfam>Re: mosh: I use it with GuixSD and with Guix on foreign distros. If there are issues with PATH when connecting to the remote, you can pass something like '--server=~/.guix-profile/bin/mosh-server' to your local invocation of mosh
<lfam>And, I do have issues with things like PATH and remote locales with mosh. I didn't figure out how to make it start the remote with my "login" environment. I actually rebuilt a GuixSD system with a modified glibc to make it work again since the glibc we released 0.11.0 with has some locale issues
<bavier1>any recommendations for a harddisk clone tool?
<lfam>I didn't have PATH issues with mosh. I only had issues with locales. Mosh will not run if it can't find a UTF-8 locale. Our glibc is supposed to hard-code the location of these locales, but the variable name was changed upstream in glibc-2.23 and we didn't notice until we'd already rebuilt everything.
<lfam>I could not make mosh read my login shell startup files and honor GUIX_LOCPATH
<lfam>So, I rebuilt the world ;) The patch I used is on the core-updates branch
<lfam>While I was rebuilding, I made a wrapper script for mosh that exports the variables, and passed that to '--server='
<lfam>There must be a better way than what I did, but we needed to fix the glibc thing anyways
<ng0>gcc -o $@ $(M32) -O $^ -lm there's a lone above that in a Makefile, but what doeshappen after $@ ? $(M32) is something like -m32?
<Petter>lfam: I like your attitude; if it doesn't work like you want, make it :)
<lfam>Lol! Like I said, the glibc issue was an oversight that needed to be fixed anyways.
<davexunit>I just wish I could use only Guile and compile to JS
<ng0>i think i will reply something like pointing out how unstable other systems are at times, but that feedback is good and we'll improve on it and we'll ping them when it's no longer beta if that's what scares them off.. i mean curl has guix listed, but everybody has their standards and views
<lfam>With time, one of the Tor devs will probably learn about Guix / Nix on their own, and that person can convince the rest of them that it's okay to link to us
<ng0>my personal experience sometimes leads me to not diplomatic answers based on facts i experienced. thanks for the feedback
<davexunit>rekado: the other thing I really wanted for 'guix web' was a login page that works like the CUPS web UI where you login as your system user
<rekado>davexunit: I found a bug a while ago; if you go to, say, page 9 and then restrict the number of packages (e.g. by typing “blender”) you won’t see any packages, probably because you’re stuck on a non-existing page 9.
<catern>(so... if I'm on a system that doesn't even have guile installed, is there a particularly easy way to bootstrap my way up to guix? ofc I can just compile guile and other guix deps but just curious)
<davexunit>I'm not super persuaded by the anti-user namespace arguments
<bavier1>the best I've come up with in an unpriveleged env is to set up 'guix publish' on a machine I do control, which serves substitutes for a storedir that I have write perms for on the unpriveleged system
<davexunit>bavier1: yeah but the store would *have* to be /gnu/store
<davexunit>which usually requires root access to create :)
<catern>oh? I remember from when I tried nix that you couldn't use their precompiled packages if you didn't put them in the well-known path /nix/store (or whatever)
<rekado>I thought we had some undocumented environment variable that affected the store prefix at runtime…?
<bavier1>I ran into difficulties running two guix-daemon on the same GuixSD machine
<bavier1>rekado: I think our daemon officially doesn't support that since some time
<catern>I had a further great idea. my company (I just started) is pretty paranoid about security (that's why I don't have root on my own machine and need to use guix to get packages) and they might not even be willing to give me a VM with root and no network or anything. But! There are tons of job-running services that give programmers an isolated environment. Maybe I could use one of those to do the builds!
<bavier1>rekado: I might be wrong, our test-env uses a NIX_STORE_DIR
<lfam>Holy crap, there are so many patches on guix-devel!
<lfam>mark_weaver: It looks like many of the "Newly failing jobs" on the latest wip-python evaluation are caused by failures in guile-2.0 and subversion. But, I just downloaded substitutes for those packages from wip-python, so I guess that those issues have resolved themselves.
<lfam>mark_weaver: Is it possible to start another evaluation? Or do you think I am missing something?
<lfam>Also, shepherd failed on x86_64 and i686, but I just got a substitute for it. Another thing that appears to have been fixed
<lfam>I mean, I just built it from source. No substitute.