<Apteryx>arg. I've got a test failure only in the Guix build environment. I've tried in a pure environment as well as container, and it passes. The error is: (file-error "Searching for program" "No such file or directory" "/bin/sh")
<pkill9>you could try just finding a bash package in the store and re-adding a symlink to that
<Apteryx>it's sorted out for my profile, but that failing I'm trying to understand happens on the build side. It's only for a specific package.
<ng0>efraim: how's the pine64 device? I'm thinking or ordering 2 later this year to replace 2 computers which are essentially just for music and videos. you haven't arrived at the point where a minimal desktop is building, right?
<efraim>ng0: I can't talk much now, the wifi isn't free, i currently have u-boot built and it boots grub, I think right now the boot process fails since it can't find the device tree for the board while booting, but I haven't been able to investigate it enough
<efraim>the odroid-c2 needs blobs for the flashing of the u-boot
<efraim>but overall i have a good feeling about the pine64
<lfam>I don't think anything has changed in the last hour or so that would affect this
<einarelen>Evening people, I'm trying to install guix on a fresh fedora 27 machine and I'm running into a bit of trouble. Particularly, the systemd daemon fails to exec every time. The error in the log simply says /var/guix/....../guix-daemon: permission denied
<einarelen>Running the daemon on its own as root goes fine
<lfam>einarelen: And you are sure it's the exact same path being executed?
<ng0>before GuixSD system init it should be enough precaution to copy the ssh pubkey to /mnt/root/.ssh/authorized_keys .. and set the password of root before running init? I'm installing SD right now from a rescue system. My experience tells me this should be enough, but maybe I'm missing something
<lfam>einarelen: I wonder if Fedora is using some extra security features like SELinux that need to be made aware of Guix?
<lfam>dieggsy: Based on the versions of the libraries it's using in the trace, it looks like the guix-daemon is kinda old. It's possible that it's old enough that there is some incompatibility between recent Guix clients (what you `guix pull`-ed) and the old guix-daemon. I would update the guix-daemon by doing `guix pull && guix package --upgrade .` as root. No need to pull again if you've pulled as root recently
<dieggsy>lfam: unrelatedly, is there any way to speed up the compilation step of guix pull? heh
<lfam>Sorry, not currently :) It makes us all want faster computers
<lfam>We know it's an issue and the Guile developers are slowly but surely improving things
<lfam>By the way, if multiple users do `guix pull` based on the same Git commit, then Guix should only need to do the expensive compilation once, reusing the build for the other users. You can specify a commit with `guix pull --commit=...`
<rekado>Ludo has a branch that splits up the work that’s done by guix pull, which should make this quite a bit faster.
<forester>Hi. Excuse me. I am interesting what GUIX abbreviation means? And if I would install guix on my linuxmint (if it possible to do) then what could it to do? And what is the GuixSD package postfix (.deb or .rpm)?
<ng0>yes, Guix can be installed on top of other systems. And the Guix package manager has no postfix for packages like .deb or .rpm per se. There's more, but I'll go to bed now. Others can answer the rest