<reepca>sneek: later tell jellyeyedjim: see 220.127.116.11 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>18.104.22.168 "Service Reference" for how to do that).
<sneek>jellyeyedjim, reepca says: see 22.214.171.124 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: 126.96.36.199 "Service Reference" for how to do that).
<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?
<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
<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 ;-)
<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__>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
<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
<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" :)
<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
<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
<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...
<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
<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?
<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.