<cbaines>As there is not an ISO available currently, I though I would give installing Guix in a VM (hosted on BigV) though using the self contained binary, running on a Debian Live ISO a go... I'm making it up as I go, but has anyone attempted something similar?
<rekado>Does anyone else have problems connecting to git.sv.gnu.org?
<rekado>On "git fetch origin" I get this error: "Connection to 188.8.131.52 timed out while waiting to read"
<efraim>i fetch from git.savannah.gnu.org and only push to git.sv.gnu.org
<efraim>i don't remember if it was a timeout issue or because I set up a password on my ssh key for savannah
<rekado>same with git.savannah.gnu.org. Cannot fetch.
<rekado>I'm using a password-protected ssh key as well.
<rekado>maybe the firewall settings have been changed here.
<rekado>but before talking to IT about this (which is going to take a long time), I'd be happy if someone could test this on their own machine.
<joshuaBPman>Hello, I just installed gnu guix yesterday via the usb installer image! I've since run guix pull. I'm having issues with my mouse. When I launch gnome or xfce, my mouse only moves up and down. NOT left to right. To fix this, I've just been rebooting. Anyone else encounter an issue like this?
<rekado>joshuaBPman: I haven't seen anything like this before. Is this a touchpad or a regular mouse? USB?
<joshuaBPman>rekado: it's a regular touchpad. I've got a macbook 7,1. So it's pretty old.
<cbaines>rekado, followed the binary installation procedure (moving it in to place, setting up the build service, ...)
<cbaines>I have mounted the disk I'm trying to install on to as /mnt
<cbaines>I then copied the store to /mnt/gnu/store, and bind mounted it back to /gnu/store
<rekado>cbaines: this doesn't sound bad. What do you do to install the system then? Just "guix system init..."?
<rekado>joshuaBPman: there are some people here who use GuixSD on a macbook. I don't know the specifics, though.
<rekado>could be that you need to install an additional package for the touchpad.
<cbaines>rekado, Yep, and that is when I get the error
<rekado>ACTION is unhappy that git fetch isn't working on this network. Patches need to be pushed.
<rekado>cbaines: the base-initrd is not in my store either (on the Guix+Fedora machine).
<rekado>what does your operating system configuration file look like?
<lumidragon>Hi everyone is the search-paths in package definitions only meant to used with path related variables? Or can that option be used to define any type of environment variable related to the package?
<bavier>lumidragon: it can be used to define any related env var
<lumidragon>okay cool, my next question where can I get more info on that topic? The manual seems a bit lacking.
<ajgrf>lumidragon: digging through the source is your best bet at the moment, unfortunately. it's not as intimidating as it seems though
<cbaines>I ran guix gc, and guix gc --verfiy=repair a few times, and that fixed the warnings, but the issue with the base-initrd has just come back again...
<lfam>Did you read gnu/system/install.scm? That's what we pass to `guix system disk-image` to generate the USB installer. I read the log and understand you aren't using the installer, but reading that file may help you.
<lfam>I'm struggling to write my first Shepherd service. The service is intended to save entropy to seed /dev/urandom on reboot. So, it needs to run after the file-systems are mounted, ensure a seed file exists, send the contents of the file to /dev/urandom, and then, at shutdown, write some data from /dev/urandom into the seed file.
<cbaines>lfam, I have read that file, but I don't understand all of it fully. There may be something in there which does explain why things are not working for me though. I just tried with a different version of Guix, and I get the same problem (thing in the store does not exist, and building the derivation does nothing).
<cbaines>This time though, its the grub-image.resized.png
<lfam>cbaines: Yeah, suggesting you read that was a shot in the dark ;) I wish I had an answer for you
<lfam>Oh, did you change anything, or do you get a different "missing file" for seemingly no reason?
<cbaines>Yeah, instead of using guix as is in the root profile, I picked a different guix from the store
<lfam>And you have to use this particular VM host? You can't use QEMU? I can tell you how to do it in QEMU ;)
<cbaines>All I am really looking for is to setup a server running GuixSD, which is actually on the internet (and not in my house behind a NAT).
<lfam>Yeah, I just looked up BigV. I didn't realize it was remote.
<cbaines>I'm open to any suggestions of how to do that
<lfam>This is a bit of a u-turn, but I remember hearing here that serveraptor.com was asking for a GuixSD VM image they could offer to their VPS customers
<lfam>They don't seem to be offering GuixSD yet, however
<lfam>Sorry if you've already answered this, but can you say how you are mounting the target? It's remote, right?
<cbaines>I have mounted the disk /dev/vda1 on /mnt, the store is at /mnt/gnu/store and is bind mounted to /gnu/store
<cbaines>Not sure what you mean by remote, but I am working from a Debian Jessie live CD
<lfam>By remote I mean: Are you working on your physically local machine, with the target mounted over the network?
<lfam>Or are you installing to some local volume that you will send to the remote host later on?
<cbaines>No, I'm working on the target machine (just over SSH, with no network filesystem stuff)
<cbaines>As in, for both of the missing paths I have encountered, I can see the derivation to create it, and build it, and guix build output's the path I am expecting, but there is still nothing there in the store...
<davexunit>this applies to both user profiles and full system configurations
<davexunit>for example, when our gnome support was really really new I upgraded to it only to find that closing my laptop lid and opening it caused an infinite suspend loop. it would immediately re-suspend as soon as I opened the lid, rendering it unusable.
<taken>Hi. I just tried installing the guix 0.10.0 binary, but at the end of the install instructions where it finally says to run the guix command, it segfaults for me. I'm using Arch Linux. Any suggestions?
<lfam>There are some helper variables you can set (described in the installation instructions), but you shouldn't get segfaults if they are unset
<lfam>taken: Can you prefix the command with 'strace -f -o /tmp/guix.log' and put the log (or at least the end of it) on paste.lisp.org?
<lfam>Btw, you didn't try to change any files in /gnu/store, right?
<lfam>I wonder, is the daemon running normally? (Segfaults are not a consequence of the daemon not running, just curious)
<taken>Well I ran with strace, but a glance at the output made me remember that I have LD_LIBRARY_PATH set to an extended search path. If I unset LD_LIBRARY_PATH then it seems to work. But it shouldn't be hitting anything in the path previous to the default locations.
<taken>the daemon seems to be running fine according to systemd.
<taken>Maybe I'm missing something from the default search path that is assumed when LD_LIBRARY_PATH is empty. Do you know offhand if the default includes anything more than `/usr/local/lib:/usr/lib:/lib`?
<lfam>Right, Guix should *never* use executables that are not in /usr
<lfam>Guix is excellent at letting you install user-facing programs that depend on different versions of library foo
<taken>Speaking of which, is it easy to install guix as a normal user? IE, let's say I work at a company that doesn't give me root access to my workstation (which runs an old RHEL type OS), but lets me run anything I want to put in my home directory. Does guix work well for single-user home directory based package management as well as being a system package manager?
<lfam>It becomes very easy to inspect and change the dependency graph of any package
<lfam>Unfortunately, you need privileges to run the daemon. It's possible to run it without root, but then it won't build packages in isolation, which is a crucial part of treating package-building as a pure function, which is the why Guix (and Nix) are so good.
<lfam>But, if you can get root to run the daemon, then Guix *is* a per-user package manager. It's only on GuixSD that you are able to do system-level package management.
<bavier>taken: I'm in a similar position at $dayjob. theoretically it's possible to run an unprivileged daemon, but things may break
<taken>In practice if you run all builds as the same user do they muck with each other? I mean, I know in theory they can, but it seems like the build scripts would have to be adversarially written to do so.
<lfam>taken: You'd end up with issues like you just had, where Guix looks in /usr
<bavier>you lose the build isolation, and the builds might behave unexpectedly
<lfam>Consider that most upstream build systems look in /usr by default, and then you realize that pretty much everything will look for dependencies in the wrong place
<taken>lfam: [about looknig in /usr] Why is that? Wouldn't a home directory install have something like a $PREFIX/gnu/store or something?
<lfam>The linux kernel features that enforce the isolation require privileges
<lfam>Specifically, I think the issue is that unprivileged users cannot create chroots
<taken>Ok, well I'll read up on the proposed solution. I actually don't work at that job anymore, but it got me thinking a lot more about package management, since I basically hand a whole distribution built from source in my home dir since all of the OS packages were ancient.
<lfam>The proposed solution is more like an inspiration for a solution. Also, I believe that person has significantly changed how they do things since that article was posted.
<taken>lfam: but chroots are only for the build itself, right? Aside from doing the build in a chroot or not, the final executable should be set up to look in where ever the store is rather than just searching through /usr, right?
<lfam>Right, but if the build process is not in a chroot, the wrong library (from /usr) may be linked at build time
<lfam>The chroots contain *only* the dependencies you specify in the package definition.
<lfam>Nix: A Safe and Policy-Free System for Software Deployment
<roelj>I've created a patch to run guix-daemon without super-user privileges. It involved disabling chrooting, because we cannot do that as a user, and disabling chowning the store directory, which you cannot do either as a user.
<lfam>roelj: Does it address the issue of maintaining a pure build environment?
<roelj>So, not only in theory can you do that, in practice you can too. But indeed, it isn't what we want to achieve with Guix -- fully isolated environments.
<taken>lfam: One of my constant gripes with Unix (which I love, though I want something better) is that there is no way to have something like sub-users to arbitrary depths. So we either get coarse permissions at a user level or we go a full Android and have a single-user OS again... [disclaimer: I know Android has multiple users, but I see them as somewhat of a hack]
<lfam>So, your user ('taken') could have sub-roles that are isolated from each other?
<roelj>lfam: Do you have any idea to get a pure build environment as a user without su privileges? I am willing to try and implement it..
<taken>lfam: I've worked on some experiments about how to do stuff like that, but the closest thing in industrial strength to the sort of always being able to further isolate child processes is the various sandboxing features of Racket.
<lfam>taken: This isn't really what you described, but Qubes OS does some interesting things regarding isolation. Of course, virtualization is basically made of holes, but the idea is still interesting.
<lfam>Do you have a link to the Racket features? I would be interested to read about them
<bavier>roelj: does the guix-daemon option --disable-chroot not do what you want already?
<roelj>bavier: No, you have to disable chown calls as well, otherwise the daemon stops when it cannot chown the build directory in /tmp.
<roelj>bavier: But for disabling chrooting, --disable-chroot will do the job :)
<bavier>roelj: ok, I haven't tried unprivileged builds in a while, so something might have changed in the meantime
<roelj>bavier: Have you succeeded in bootstrapping Guix with a daemon running as a normal user?
<taken>lfam: offhand I can recommend the paper "Revenge of the Son of the Lisp Machine" by Flatt, Findler, and Felleisen to describe some of it, but basically Racket has a bunch of security stuff at the language level so that you can parameterize different security-related things for any given function. Eg. you can nest different programs and each one can limit access that its children have to resources like the network, the filesystem, memory
<taken>One of my motivations for doing crap like having a modified LD_LIBRARY_PATH and building things in my home directory is that sometimes I want to use the very bleeding edge of some packages. Is that easy to do with guix? From what I've seen of available packages things are pretty old. Is there anything in guix like a stability channel [unstable, stable, etc] or some such, or any plans for that? Is it easy to use the latest version of