<rekado>sebboh: visudo probably won't work anyway.
<rekado>I think it's better to specify a sudoers file in the config.scm and reconfigure the system.
<rekado>Hmm. Since a couple of days I'm no longer able to abort "guix build" with C-c C-c in Emacs shell-mode. I have to use send a signal to the process with kill or M-x proced instead. Does anyone else have this problem?
<rekado>(could be my Emacs config doing weird things, of course)
<sebboh>oh? ... why is /etc/sudoers readonly? .. ok. fine. Ok, next question, I want a guile repl so I can see the value of these %some-default-stuff variables that are used in config.scm.. Where do I get that?
<sebboh>rekado: you could do a find / in shell-mode and then try to C-c C-c out of it. For testing.
<rekado>sebboh: /etc is populated from the store on boot. Changing it in the running system won't persist across reboots.
<sebboh>well... something could modify them. Checking them at runtime is a fine idea, in my opinion. Either way,
<rekado>How would something like %base-user-accounts be modified at runtime?
<rekado>the value exists only at system configuration time.
<rekado>once a system has been reconfigured the definition of the value no longer matters.
<sebboh>it's a global variable? My config.scm could set it to null in the first line...
<sebboh>these aren't exactly config files... they are code.
<sebboh>sorry, s/null/'()/ or F or whatever they do in guile land. :)
<fps>but then starting a new REPL and loading the modules and inspecting the values there won't give you any hint about possible modifications done when reconfiguring the system. you'd have to evaluate your system config in that new REPL
<rgrau>Hi guixers, I'm manually compiling openresty, and on the ./configure phase, I get: "ld-wrapper: error: attempt to use impure library "/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so" which is added by guix's ld-wrapper, but is kina cryptic to me. :/ Any tips or pointers?
<mark_weaver>to run a guile REPL with access to all the guix things, you need to first add "$HOME/.config/guix/latest:/gnu/store/...-guix-.../share/guile/site/2.0" to the front of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.
<mark_weaver>rgrau: when compiling software, you must ensure that either you are using ONLY toolchain/libraries from your host OS, or ONLY toolchain/libraries from Guix. You cannot mix them.
<mark_weaver>in this case, they are getting mixed. you seem to be using the toolchain from Guix and maybe also some libraries from Guix, but also some things from your host OS.
<mark_weaver>hmm, or maybe you're somehow using gcc from your host OS and ld from guix.
<mark_weaver>while hydra-evaluator is adding jobs to the postgresql database on hydra, all other attempts to perform postgresql transactions are prone to starvation. e.g. I asked to restart a job via the web interface, and it's been spinning for 15 minutes.
<fps>i'm using the gnu build-system with a deleted configure phase
<fps>and wonder if i can just set $CC to gcc in the gnu build system
<bavier>fps: you can probably use #:make-flags '("CC=gcc")
<sebboh>The docs for 'password' in 'user-account' say that I should put an encrypted string in there. But for the root account (gnu/system.scm) the string is "" and I log in without a password. What's up with that?
<fps>bavier: oh, ok right, there's #:make-flags. thanks :)
<sebboh>For context of my question, I intend to disable password-based login for the root account. I like the "sudo only" paradigm of ubuntu/debian land.
<sebboh>I believe setting the password hash for the root account to "*" or "bananas" will acheive this.
<sebboh>(assuming I also configure a proper user account in the wheel group or whatnot.)
<sebboh>oh, I've just read that maybe "" is different than "*"...
<civodul>sebboh: above all, the docs say you should put nothing in the 'password' field :-)
<sebboh>you folks know what "apt-file" does? It contains an index of installed files for all packages. it allows me to figure out which package provides some file like /usr/bin/some_utility. Is there something like that for guix?
<sebboh>"Passwords set with passwd are of course preserved across reboot and reconfiguration." oh. Fine.
<sebboh>does guix identify my CPU and such and tell gcc et al about it so those tools can ... take advantage of cpu instructions I have? Sorry if this question isn't well formed, I have been using binary distros for a while.. :)
<civodul>no it doesn't, because that would prefer redistribution of binaries
<civodul>sebboh: re apt-file, there's nothing like this, n
<sebboh>Prefer redistribution of binaries? I don't understand. Maybe I misunderstand. Let's say my CPU has SSE2 and yours does not. If I compile locally and use locally... I might as well employ those instructions. But my bins aren't useful to you... My understanding was that a distro (let's say debian) simply configures their compilers to include only the least-common-denominator of instructions. Did I get this wrong?
<fps>soo, thinking this one step further, if somewhere in this graph there would be a point for a user to "inject" extra compiler flags to make use of particular architecture features [i.e. a recipe itself]
<fps>then there's in principle no obstacle to prividing finer grained substitutes than the four major architectures
<sebboh>I don't suppose there is some sort of 'short' reconfigure. ...it takes a really long time to alter a single line in a single file in /etc...
<fps>this gets interesting only with a more powerful build server or a distributed build server/CAS where users provide their binaries..
<sebboh>fps, yeah but at that point I'd just use hydra. ;) If it's up! "unexpected end of file" message needs some work, by the way. Probably catch this in http.scm..? Or handle. Whatever guile calls it.