IRC channel logs

<thomassgn>sneek: later tell quiliro I wrote up a tiny thing about adding fpm to guix at https://browniehive.net/2017/07/Adding-FPM2-to-GuixSD/

<sneek>Will do.

<thomassgn>sneek: botsnack and thanks

<sneek>:)

<jellyeyedjim>hi, just wondering how guix handles xorg configurations

<jellyeyedjim>my tear free options at /etc/X11/xorg.conf.d/20-intel.conf seem to do nothing

<jellyeyedjim>i am running guixsd

<reepca>sneek: later tell jellyeyedjim: see 6.2.7.5 of the manual ("X Window"). In general, the xorg configuration is automatically generated by guix, but you can append arbitrary text to it (see xorg-configuration-file, especially #:extra-config) in your system configuration. Just replace the default slim service with one that uses an xorg-start-command that uses an xorg-configuration-file with what you want appended (see "modify-services" in

<reepca>6.2.15.3 "Service Reference" for how to do that).

<sneek>Will do.

<reepca>sneek: later tell jellyeyedjim: 6.2.15.3 "Service Reference" for how to do that).

<sneek>Will do.

<blt>ACTION waves

<reepca>o/

<blt>i'm verifying my guix download, about to burn on a usb. wish me luck

<blt>(first timer)

<reepca>ah, good luck!

<blt>i686 netbook ftw

<blt>well, we'll see

<blt>migrating from arch :D

<jellyeyedjim>i checked the log, thanks reepca

<sneek>jellyeyedjim, you have 2 messages.

<sneek>jellyeyedjim, reepca says: see 6.2.7.5 of the manual ("X Window"). In general, the xorg configuration is automatically generated by guix, but you can append arbitrary text to it (see xorg-configuration-file, especially #:extra-config) in your system configuration. Just replace the default slim service with one that uses an xorg-start-command that uses an xorg-configuration-file with what you want appended (see "modify-services" in

<sneek>jellyeyedjim, reepca says: 6.2.15.3 "Service Reference" for how to do that).

<jellyeyedjim>thank you sneek

<reepca>Since adding a discrete graphics card, my ethernet interface has been renamed from enp2s0 to enp3s0 and now I have to manually run "ifconfig enp3s0 up" and "dhclient enp3s0" after each boot. Any idea why that might be?

<reepca>sneek: botsnack

<sneek>:)

<mekeor>how would you package a go-library like https://github.com/mattn/go-sqlite3 which on usual distros is installed with "go get github.com/mattn/go-sqlite3" ?

<jellyeyedjim>so is guix entirely compile based like gentoo or does it use prebuilt packages as well?

<mekeor>jellyeyedjim: it uses "prebuilt packages" as well. they are called "subtitutes", AFAICS

<mekeor>i meant "substitutes"

<jellyeyedjim>day 1 with guixsd, such an interesting distro

<mekeor>but personally i actually don't exactly know when substitutes are used and when not

<jellyeyedjim>so much to learn though

<reepca>mekeor: they're used whenever they're available unless --no-substitutes is passed to whichever command is being used.

<blt>reepca: alright, made it thru the hairy parens and have a config.scm running

<blt>got lost in the jungle of mapped-devices so we'll see if it boots soon. muhaha

<blt>one thing i'm wondering, how can i install packages right away on the livecd

<blt>would like to ssh somewhere and install acpi for battery status

<reepca>as long as you have an internet connection, you should be able to install stuff on the live usb image using the usual methods. For example, "guix package -i gcc"

<blt>thank you reepca, that works :)

<blt>reepca: the acpi thing can be sidestepped by me getting up to get the charger :D

<reepca>when you say you "have a config.scm running", do you mean you've successfully guix system init'ed?

<blt>reepca: it's initing currently

<reepca>ah, alright

<blt>my hardware is about 10 years old so it takes its time

<reepca>on the bright side, that means you shouldn't have too much trouble with stuff working with linux-libre.

<blt>when will guix be ported to emacs?

<blt>:p

<blt>honestly, i didn't even try wifi but it's atheros so i guess it will just work tm

<blt>if i have to plug an adapter in so be it. i'll just look l33t at the coffee shops with my 10" adapter

<reepca>I went through 5 graphics cards seeking support for multiple displays, though many of those were my fault - 2 of them I already owned, 2 of them were inaccurately reported on h-node (or spontaneously lost support in recent releases), and one of them I thought had a problem but actually was an issue with the vga->hdmi adapter.

<blt>reepca: is it a bad idea to install packages from the livecd i tried to install acpi but it seemed to want to download lots of dependencies

<blt>and then it took quite a long time building said packages. so i just canceled

<reepca>Building packages can take quite awhile, and I just remembered the issues I had trying to do stuff with guix on my i686 laptop. The state of substitutes for i686 at that time (about a month ago) wasn't very good. So you may end up having to build quite a bit of stuff.

<blt>reepca: got it. appreciate the experience report

<blt>i really went into this blind; install is going way longer than i anticipated.

<reepca>I keep getting 504 gateway timeout whenever I try getting status information from hydra - can anything be done about that?

<blt>oh well, gives me more time to read the little schemer :p

<rekado>blt: our build farm isn’t very powerful

<rekado>blt: I also have two i686 machines and it’s been tough to keep them up to date without help from the build farm.

<rekado>blt: we’ll soon get more servers for the build farm.

<blt>rekado: okay, interesting. always be buildin'

<blt>i wonder how long this could go on for; been about 4 hours so far :D

<rekado>depends on what you build

<rekado>on my i686 netbook I had to build the kernel and took a day

<blt>right right, i'm doing the guixsd install -- the lightweight-desktop.scm build

<janneke>o/

<janneke>ACTION goes to try exwmx-1.6 again, brb

<bytes83>i am getting an error while doing "guix system reconfigure".

<bytes83>here is the pastebin link

<bytes83>pastebin.com/XBdY887b

<bytes83>i did a guix pull before the reconfigure

<bytes83>after reading through the logs i don't feel to bad about needed to build quite a lot of packages. :p

<blt>made it through eh bytes83

<bytes83>yeah! stuck at a weird error that i dont quite understand fully.

<bytes83>i *think* that his error might be due to a patch (https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00091.html). But the fact that this patch is old makes me wonder why i did not get this error before.

<bytes83>this*

<bytes83>okay. update. fixed the error by using an empty (grub-theme) in config

<civodul>Hello Guix!

<janneke>hey civodul!

<jlicht>hello Guix

<rain1>hi :)

<rain1>I wanted to try making a minimal chroot i can boot in qemu, with guix

<rain1>I tried mkroot but I think I need to copy some stuff in like gcc

<civodul>rain1: did you try "guix system build" or "guix system vm"?

<jlicht>Where does guix get its bash-completion files from? I am trying to work on getting the vpnc package fixed so it works with eduroam, but some completion looking in /etc/vpnc is making things more difficult than they have to be.

<civodul>jlicht: the bash completion file is in etc/completion/bash in the source tree

<civodul>but yeah, sometimes there are annoying corner cases that are badly handled

<jlicht>civodul: good to know, but I am talking about the specific vpnc bash completion stuff ;-)

<civodul>oh, sorry

<civodul>maybe that comes from the 'bash-completion' package?

<jlicht>civodul: ah of course! thanks!

<jlicht>how would one go about patching one of the completion scripts in there to refer to the correct store path? It seems inadvisable to have vpnc be an input to the bash-completion package

<civodul>jlicht: good question

<civodul>perhaps it could take it from $PATH?

<jlicht>civodul: ah, that could work. I'll see if the nice people at nixpkgs already have a solution for this :-)

<civodul>:-)

<jlicht>civodul: ah, that could work. I'll see if the nice people at nixpkgs already have a solution for this :-)

<jlicht>oops, wrong keybind in rcirc :#

<jlicht>What is the naming convention for packages that are checked out from a subversion repo? I currently am going for `<latest-released-version>-<revision-number>'

<civodul>yeah, see https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html

<civodul>it doesn't mention svn explicitly but you can extrapolate :-)

<jlicht>thanks civodul. It just so happens that the word `revision' has a double meaning when talking about svn ;-)

<civodul>true

<jamesrichardson>Hello guix!

<jamesrichardson>lately after I do a guix pull and guix package -u, libreoffice wants to be recompiled. It this normal at the moment? I have mirror.hydra.gnu.org in my substitute list.

<jamesrichardson>oh, I'm running guixsd x86_64.

<jlicht>is there any specific reason mcron is still built using guile-2.0?

<ng0__>i haven't finished my other system yet, so I can't send a mail, but: it becomes increasignly frustrating working with the master. can we at least get a way to ensure that the system builds? at the moment I'm tracking guix one pace slower than master and it's the only failsafe I have. someone pushed something without reconfiguring their branch or testing it on a live system and like so often in the last months

<ng0__>this prevents a successful reconfigure.

<ng0__>master is just that, a master which has the tendency to accept things which do not ensure a build. so could we please look into a way to ensure the most basic functionalities are still working? like run a guix system test, etc..

<jlicht>ng0__: I use a hackish workaround where I pull the current master, and try to build and boot my system config in qemu

<ng0__>every QA is wothless if the end result is pushed and makes the cardboard house collapse for a moment until someone fixes it. yeah, we can't test everything so we need scenarios and guidelines.

<ng0__>jlicht: yeah, but this shouldn't be necessary in the first place

<ng0__>i mean a hack. it hsould be part of an official guideline

<ng0__>like right now it's caused by an rsvg related commit

<ng0__>if you just push that, we should not have to wait for hydra to pick it up

<ng0__>we should be aware of this moments after it was pushed

<ng0__>or push to a branch, and once it builds sucessfully it is integrated into master

<ng0__>anything but not what we have now

<jlicht>ng0__: I agree that it is currently unworkable for anyone who would not be comfortable working from a git checkout

<ng0__>and it shouldn't be a human thing. i haven't put any thought other than a short chat in our hackerspace to this, but the optimal way would be a machine deciding that it builds, or at least involved in the process plus some signed feedback of people saying 'yes this builds' or 'no, this did not builkd" etc

<ng0__>good that this time it's an obvious break and nothing which happens in the initrd, because right now i only have seabios ;D

<ng0__>what I learned yesterdy; it's definitely not recommended to not update debian for 4 years. I ran into a problem with flashing yesterday and only finished at midnight because I switched to compiling on a not 4 years old debian with limited support

<cehteh>um scheme noob question: when i want to split my config.scm into multiple files, whats the closest to C #include in scheme (users (cons* (#include "users.scm") alike

<jlicht>cehteh: you can create a Scheme module

<jlicht>but depending on how you choose to interact with these modules, they need to be located in GUIX_PACKAGE_PATH and/or GUILE_LOAD_PATH

<cehteh>no dead simple include like thing?

<rain1>yes there is (include file-name) it must be used at the top level

<jlicht>cehteh: https://www.gnu.org/software/guile/manual/html_node/Local-Inclusion.html might be what you are looking for :-)

<rain1>your file could (define my:users '(...)) then do (users (cons* my:users

<cehteh>rain1: still that 'file' needs to be loaded somehow, module may work, but include (things are only used in one place, less clutter, no defines) sounds easier to me

<jlicht>RE: my mcron + guile2.2 question, what are the show-stoppers for `shepherd' using guile2.2 as well?

<ng0__>a case where error messages could be improved: I just had to figure out by hand which file referenced in my config no longer exists/moved. even with full verbosity the most verbose I got from guix system build was "no such file" :)

<rain1> https://www.gnu.org/software/guix/download/

<rain1>whats the username and password for the image?

<cehteh>huh?

<ng0>there's none

<cehteh>there shouldnt be user/passwords

<sneek>Welcome back ng0, you have 2 messages.

<sneek>ng0, catonano says: ok I replied on #gnunet as I think it's more appropriate. Good luck with your university arrangements

<sneek>ng0, efraim says: tell me more about enlightenment and screenlock, check git.enlightenment.org and the substitutions in enlightenment, I didn't substitute suspend

<rain1>cehteh: how do I log in

<cehteh>login where?

<cehteh>doesnt ask me for login

<ng0>you have to set a password after install with 'passwd' as root (whic his passwordless) if that's what you mean

<cehteh>ah after installing

<cehteh>yes just 'root' no password

<ng0>efraim1: could be that you broke the keyboardlayout I fixed or that the computer I'm using does not include it. I'll let you know.

<ng0>sneek: later tell catonano: sneek is not in #gnunet, but I got your message. will respond later

<sneek>Will do.

<cehteh>is there a 'dont run tests after building' option when guix builds something?

<ng0>depends on the build system used

<ng0>#:tests? #f in gnu-build-system

<ng0>well others as well, some just don't haev a test

<cehteh>ii meant as option to guix package -i --fallback

<ng0>but usually the tests should be fixed unless they can't be fixed

<ng0>same

<cehteh>how do i pass that then?

<ng0>by caputuring it, debugging it, sending a fix or reporting a bug

<cehteh>i dont speak about failing tests

<ng0>but?

<ng0>what do you mean then

<cehteh>i just want to pretend "dont runs tests at all, assume the software works"

<cehteh>aka .. install the damn thing, now!

<cehteh>not waiting hours for some testsuites to complete

<ng0>not possible without local overrides of the packages

<cehteh>thought so

<ng0>ie you could simply create a package in your GUIX_PACKAGE_PATH named "openssl" which then runs without tests and use that

<cehteh>would be nice to have a --dont-run-tests option to guix

<cehteh>yes

<ng0>well with openssl it is not so easy as I described, but that's it

<cehteh>well thats not my intention, i just want to speed up things which --fallback

<cehteh>editing the package definitons contradicts these idea

<cehteh>and i am aware that not testing can be problematic, but i only shoot in my own foot this way

<ng0>in that case, no idea. thin kabout something and propose it as a discussion to the list

<cehteh>well whats your opinion about that? .. and maybe others here

<cehteh>making a futile proposal to the list wastes everyones time

<ng0>at the moment I don't want to think about this

<cehteh>ok

<ng0>nothing to do with you, I prefer to focus on something and currently this wouldn't get my full attention

<cehteh>yes, go on

<oriansj>cehteh: if you want something added to guix, patches work much better

<cehteh>oriansj: thats why i am hesistant to make a propoal, i am not fluent in scheme

<cehteh>generally i prefer to contribute patches than just sugesting things

<oriansj>cehteh: we have literally thousands of things we are working on right now and developer time and attention is rare

<cehteh>i know

<oriansj>I wanted a lower level bootstrap for guix (all the way down to the bare metal) and I am making it and we have pieces available but until it is fully ready its discussions are not going to be on here any more and they are all going to be on #bootstrappable

<cehteh>i had a dim hope someone here would just say "good idea, i know how to do that in 2 lines", but making a proposal without knowing by myself how much this involves isnt what i want to do

<oriansj>cehteh: we can add it as a wishlist bug but honestly I have no idea when anyone would pick it up

<cehteh>the problem for me is that working with guix is still tenacious to me, everything i do takes too much time, mostly because i dont know better but also because guix is slow

<oriansj>cehteh: if you want faster installs use binary substitutes

<paroneayea>hi

<cehteh>when i am at least at a state where i can work more fluently with guix i could try to contribute as well

<cehteh>binary substitutes still fail to often, not available on hydra, overloaded or whatever reasons

<cehteh>my 2 vm's hang since hours on the subversion testsuite

<oriansj>cehteh: you can make your own build server, then simply pull the binary builds from that

<cehteh>one of the vms is the build server

<cehteh>still it takes a lot time to do anything, i just want to try something in guix, turns out i have to install something else, baam needs hours because hydra doesnt have it

<cehteh>happens frequently

<cehteh>(including mirrors. ..)

<rain1>shadow-4.4-su-snprintf-fix.patch patch not found

<oriansj>cehteh: I can see why you want that feature, personally I prefer having good tests to make sure I'm not about to install hot garbage and I hope you can find someone willing to do that work but I've got a lisp interpreter written in assembly I need to enhance to support a C compiler written in lisp to attend to. Best of luck

<ZombieChicken>Does the kernel used by Guix have twofish installed in the kernel? I'm not seeing it in /proc/crypto

<rain1>unable to guix system reconfigure

<cehteh>rain1: what error?

<jlicht>hey all, is #guix also the place to chat about GNU Shepherd related shenanigans?

<lfam>jlicht: Yup!

<divansantana>is there a way to force guix to not compile, like ever? Like only use substitutes. If no substitutes available, then don't update to that version.

<cehteh>isnt that the default behaviour when you dont give --fallback?

<paroneayea>anyone else find that when they ssh into machines running guix their .bashrc isn't sourced?

<paroneayea>same with when logging in via a tty

<paroneayea>however opening in gnome-terminal and friends, it's fine!

<fps>.bash_profile not checking for the existance of .bashrc?

<paroneayea>:o

<paroneayea>is it supposed to do that?

<fps>actually no, i'm wrong :)

<fps>just checked the manpage

<cehteh>$ git clone https://git.savannah.gnu.org/git/guix.git

<cehteh>Klone nach 'guix' ...

<cehteh>fatal: unable to access 'https://git.savannah.gnu.org/git/guix.git/': Problem with the SSL CA cert (path? access rights?)

<cehteh>grrr

<cehteh>git -c http.sslVerify=false clone https://git.savannah.gnu.org/git/guix.git works .. but thats not really the idea

<lfam>cehteh: Is the environment variable GIT_SSL_CAINFO set correctly?

<lfam>divansantana: No, not currently

<fps>paroneayea: if you login via ssh to a guix box, then .bash_profile is read and commands in it executed

<lfam>divansantana: It's been discussed previously, and people have floated some ideas around, but I don't think anyone has worked on it.

<fps>paroneayea: see man bash and / for bash_profile

<fps>paroneayea: put something like this in your .bash_profile:

<fps>if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

<paroneayea>fps: nice thanx

<paroneayea>way better :)

<cehteh>lfam: $ echo $GIT_SSL_CAINFO

<cehteh>/etc/ssl/certs/ca-certificates.crt

<cehteh>is that correct?

<cehteh>no its not,

<cehteh>no such file

<cehteh>lfam: thanks .. fixed

<divansantana>lfam:cool. One day I suppose - thanks.

<divansantana>another, can one do a guix system reconfigure /etc/config.scm when offline?

<lfam>My personal opinion is that since Guix is basically a build from source distro, the better approach is to improve the build farm.

<lfam>But it's not a universal opinion

<divansantana>I'm just trying to update my openssh setting and would expect guix to read the file, check the option changed, reconfigure openssh and restart it. Instead it tries to build things and breaks.

<lfam>divansantana: Yes, but not if you need to download anything...

<rain1>yeah i had the same problem

<rain1>recompiling gtk and a million other things when I just wanted to add sshd

<divansantana>lfam:I think it's nice to have the option to force no compiles. Options are always good. For some circumstances.

<lfam>I think there is a bug related to grafting and the build cache, maybe you are hitting it too: https://lists.gnu.org/archive/html/guix-devel/2017-06/msg00348.html

<lfam>divansantana: Well, there are some packages that we don't build on the build farm at all. Users have to build them locally.

<lfam>So... it's complicated :)

<divansantana>rain1: lfam: is there a way to tell guixsd to just read the config.scm and reconfigure the system, without telling it to update?

<lfam>By default, it doesn't update anything. The "update" comes from having run `guix pull`

<divansantana>I wouldn't expect it to look expect it to download and build things. Just see my openssh option changed and restarted the service. Surely there's a way to do that?

<divansantana>lfam: will check thanks

<lfam>If you didn't run `guix pull`, then you might be experiencing the bug (?) I reported

<rain1>im thinking about using guix inside a mininal linux distro instead

<fps>guix pull fails here after compiling many a things: https://pastebin.com/SvnEJbKp

<lfam>Err... "fatal: could not read Username for 'https://gitlab.com': No such device or address"

<lfam>That's quite strange

<fps>yep ;)

<lfam>Can you investigate?

<fps>i'm not really qualified.. just logged into my guix box again after a couple of months ;)

<divansantana>lfam:ah, ok I understand! So why don't all packages build on farm and forced locally? Due to limited resources on build farm?

<fps>trying guix pull --verbose

<lfam>divansantana: Some "packages" are really just huge downloads. So, there's no point in us providing them when you could download them from the upstream source.

<lfam>fps: Can you send a bug report?

<fps>lfam: sure..

<fps>actually no.. i need to run. i'll hope to remember at a later time [and manage to figure out how to report a bug ;)]

<lfam>I'll do it

<lfam>Well, if I can reproduce it.

<lfam>fps: It's a problem with the upstream repo

<lfam>amz3: We noticed that the Git repo of guile-git can not be cloned: http://paste.lisp.org/+7HXT

<lfam>amz3: I see, the repo moved

<lfam>sneek: later tell fps: The upstream repo URL changed, so you won't be able to build guile-git without providing the source code "manually". You'll need to get the right Git checkout, check that it has the correct hash with `guix hash --recursive --exclude-vcs`, and then use `guix download` to put it in your store

<sneek>Got it.

<lfam>amz3: Is it possible to redirect from the old URL to the new URL? We still have users trying to access the guile-git source code at the old URL.

<divansantana>so after install, guix pull and system reconfigure it fails http://paste.lisp.org/+7HXV

<divansantana>any ideas?

<jlicht>When using shepherd as my non-root user (jelle), my services are not properly killed using `herd stop <service>'

<divansantana>"Failed to autoload rsvg-handle-new-from-file in (rsvg)" is the first error

<jlicht>The relevant part of my init.scm: http://paste.lisp.org/display/349842

<lfam>divansantana: I reported it here: <https://bugs.gnu.org/27551>

<divansantana>lfam:thanks

<divansantana>lfam:any workaround for now?

<lfam>divansantana: As a temporary workaround, you can pull from a commit before the bug was introduced:

<divansantana>lfam: that sounds useful to no how to do

<jlicht>And the following paste shows the issues I have with defunct processes still showing up: http://paste.lisp.org/display/349844

<lfam>`guix pull --url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/f48a9d4a462041a8cf31cdf0249508a43e7b8c3c.tar.gz`

<lfam>divansantana: It's in the manual, too, section Invoking guix pull

<lfam>It's strictly a temporary workaround

<divansantana>lfam:was just looking it up. That helps though, thanks! Sure.

<lfam>I might revert the problematic changes, not sure

<lfam>Mostly cause I'm not sure if that would cause problems for Guix users

<lfam>I guess I'll try it on myself to find out

<cehteh>guile compiling is really unbelieveable slow nowadays :/

<jlicht>anyone using per-user shepherd?

<lfam>Yeah, it got a lot slower :(

<lfam>jlicht: Yeah, I use it

<efraim1>more ram makes it better

<lfam>It's a bit rough compared to systemd

<lfam>Help wanted!

<cehteh>i gave 2GB to that mv .. i'll up that next time

<lfam>cehteh: Try 3 GB

<cehteh>heh thought about 4

<lfam>If you are doing `guix pull` 2 GB is probably not enough

<cehteh>but its only the 'playground' vm

<efraim1>2 takes me about 7 hours, 4 takes 45 minutes on my aarch64 board

<lfam>Basically, the (gnu packages python) module requires between 2 and 3 GB to build

<cehteh>i wish i had more in my server (16GB currently)

<lfam>This is the upstream discussion: https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html

<cehteh>yes

<cehteh>seen something like that

<lfam>Honestly, I think it's a pretty dire bug :(

<jlicht>lfam: Would you be so kind as to share some shepherd-configuration snippets ;-)? I am having issues with my processes not being killed.

<lfam>jlicht: It's ugly: http://paste.lisp.org/display/349846

<lfam>I log in to that machine remotely after it boots and start my shepherd like this: [ -z $(pgrep -U $(id --user) shepherd) ] && shepherd

<lfam>I'd prefer something like `loginctl --enable-linger`

<cehteh>it eventually completed .. now reconfigure and then reboot with more ram

<lfam>Or, `loginctl enable-linger`

<jlicht>lfam: if it's ugly, you know it is actually used ;-). Thanks!

<lfam>Doing it like that, the stop, start, and restart actions work as expected

<lfam>But, I think there are some bugs that can cause it to lose track of processes depending on how shepherd starts

<lfam>Like, when I started it on a local TTY, that stuff didn't work

<lfam>Since this machine is primarily a remote machine, it's fine for me to do the SSH start

<lfam>But annoying

<jlicht>lfam: ah! I did start my shepherd via local tty

<catonano>hello guixers !

<sneek>Welcome back catonano, you have 1 message.

<sneek>catonano, ng0 says: sneek is not in #gnunet, but I got your message. will respond later

<catonano>ahh

<catonano>sneekk later tell ng0 I apologize

<sneek>Got it.

<cehteh>yay guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused

<cehteh># guix system roll-back ... ^^ :D

<lfam>cehteh: That usually means the guix-daemon is not running

<cehteh>yes but i cant start it, made a bug in config.scm

<cehteh>well reboot to older config now

<cehteh>what are errors like: ;;; WARNING: loading compiled file /gnu/store/1jp9i5w7jsisgm0sjv1qycfxsjn643lf-module-import-compiled/gnu/build/activation.go failed:

<cehteh>;;; ERROR: In procedure load-thunk-from-memory: not an ELF file

<lfam>cehteh: Are you working from a Git checkout?

<cehteh>of course these should not be elf or?

<cehteh>no

<lfam>Did you recently run `guix pull` for the first time in a long time?

<cehteh>yes

<cehteh>as you mentioned above with the `guix pull --url=https:// .. option

<lfam>Okay, they are harmless. Guile switched to using the ELF format in Guile 2.2, and you just crossed from Guile 2.0 to 2.2. Run `guix pull` again to silence the warnings

<cehteh>ah

<lfam>There are still Guile 2.0 objects lying around somewhere

<cehteh>on the other VM i added a regular guix pull to the crontab :D

<jlicht>lfam: both mcron and shepherd seem to still be using guile 2.0. Not sure if that is relevant, but I keep seeing the error message from time to time as well

<lfam>That shouldn't affect this issue

<lfam>Those warnings were internal to Guix

<lfam>They say "ERROR" but in practice they are really "WARNING"

<cehteh>i had plenty of them, move .config/guix/latest out of the way and pulled again

<efraim>for font-google-noto, wouldn't it be easier to extract only the ttf and otf files and pipe them directly into the install dir?

<cehteh>that fixed them but now that one reappeared

<lfam>"that one" ?

<lfam>Please try to be more specific

<cehteh>the one i pasted above

<lfam>You pasted more than one thing. Please be specific

<cehteh>] <cehteh> what are errors like: ;;; WARNING: l

<cehteh>...

<cehteh>well forget it

<lfam>That comes from Guile 2.2 when it finds Guile 2.0 objects. But in practice, it's harmless, since Guile 2.2 will see the bad object, warn you that it can't read it, and then recompile for 2.2, as an ELF. But to permanently get rid of the warnings, you'll need to make sure everything is updated to use the latest Guile. So on GuixSD, you should update per-user and the full system (reconfigure).

<lfam>I wasn't trying to be rude, but I didn't know if you were referring to the version mismatch warnings, the missing daemon socket, etc

<cehteh>no worried, i meant with 'forget it' i dont wanted to waste your time, works for me now

<cehteh>where do i configure '--fallback' globaly?

<efraim>I don't believe its possible currently

<efraim>But I would think to add it as a guix-daemon flag

<cehteh>just tried that and failed :D

<paroneayea>Can't locate Time/ParseDate.pm in @INC (you may need to install the Time::ParseDate module) (@INC contains: /home/cwebber/.guix-profile/lib/perl5/site_perl/5.24.0/x86_64-linux-thread-multi /home/cwebber/.guix-profile/lib/perl5/site_perl/5.24.0 /home/cwebber/.guix-profile/lib/perl5/site_perl /gnu/store/cw7lyi58d9z36hlhl1xawdnjvnm9pbjq-perl-5.24.0/lib/perl5/site_perl/5.24.0/x86_64-linux-thread-multi

<paroneayea>/gnu/store/cw7lyi58d9z36hlhl1xawdnjvnm9pbjq-perl-5.24.0/lib/perl5/site_perl/5.24.0 /gnu/store/cw7lyi58d9z36hlhl1xawdnjvnm9pbjq-perl-5.24.0/lib/perl5/5.24.0/x86_64-linux-thread-multi /gnu/store/cw7lyi58d9z36hlhl1xawdnjvnm9pbjq-perl-5.24.0/lib/perl5/5.24.0 .) at /gnu/store/fgvh4sayhazsrvkc0hv2rahzmy6ihdlc-profile/bin/dirvish.pl line 55.

<paroneayea>oops

<paroneayea>sorry, didn't mean to make such a big paste

<paroneayea>anyway, I've theoretically packaged this module and installed it as a dependency but I guess it's not being found...

IRC channel logs

2017-07-01.log