<lfam>And if you use the guix-install.sh script, then the key is authorized
<nckx>lfam: The current manual sez: ‘Note: Similarly, the 'berlin.guixsd.org.pub' file contains the public key for the project's new build farm, reachable at 'https://berlin.guixsd.org'.’
<nckx>‘As of this writing 'berlin.guixsd.org' is being upgraded so it can better scale up, but you might want to give it a try. It is backed by 20 x86_64/i686 build nodes and may be able to provide substitutes more quickly than 'mirror.hydra.gnu.org'.’
<nckx>So I guess it depends on how attentively you're reading.
<nckx>And if you understand the importance of good substitution at that point, which is often not the case.
<lfam>Yeah, I think the topic is obscure for beginners
<ecbrown>like me, i wonder if each commit triggers a re-build of all dependents, and how long to wait until they might be usable
*nckx looks forward to replacing their horrible shell-script based CI server with Cuirass.
<nckx>Probably in the back of some room during FOSDEM :-)
<lfam>It would be a cool workshop to present and explain a "turnkey" Cuirass CI based on a config.scm
<ecbrown>wonder why tap-to-click on macbook touchpad works under xfce, but not under gnome
<ecbrown>i had to blacklist usbmouse to get mouse to move other than up and down
<ecbrown>also i can't two-finger "right click" in gnome, but i can in xfce
<lfam>Amazingly, I often get the answer to complicated questions like that from Google
<nckx>ecbrown: I've never used a MacIntosh in my life, but I had to do some ‘xinput --set-prop’ hackery in my .xsession to get tap-to-click and sane (‘natural’?) scrolling to work on my Elantech PS/2 Touchpad.
<ecbrown>no such luck, to date. the usbmouse trick came from my attempt
<ecbrown>curious observation: install guixsd 0.15, then reboot. make a small change to config.scm, blacklisting a module, and guix system reconfigure /etc/config.scm, and it downloads all the pacakges again
<ecbrown>fine, then i reboot, and make another small change to the same place, and now it even has to download and recompile perl
<civodul>regarding the snippet, how do things break?
<civodul>well maybe i should just give it a try rather than bother you
<janneke>civodul: i hope we can drop a "level" of packages; either the "wrappers" i added to commencement.scm, or the bootstrap packages in mes.scm...
<janneke>civodul: ./pre-inst-env guix build --system=i686-linux glibc-boot00 or ./pre-inst-env guix build --system=i686-linux gcc-boot00 fail when adding the dependencies that are commented-out
<janneke>would be nice indeed if you could have a look -- i think (hope) that my work in make-bootstrap.scm and bootstrap.scm makes some sense -- very unsure about the extra packages added to in commencement.scm
<roptat>this issue means the build system of your package tries to find a library in /usr, but that doesn't exist in guix. The usual fix is to add a configure option, define an environment variable or fix the Makefile
<roptat>you'll have to run ./configure --help to find if you can set the path to the library
<roptat>or grep for "/usr/include" to try and find how it's used in the Makefile and how you can change that
<vagrantc>regarding the trust-path to the git repository ... i thought about writing a script that basically goes git pull, and iterates through the top commits until it finds one in a trusted keyring ...
<civodul>the upgrade-that-takes-forever issue is hard to fix "once and for all", though
<vagrantc>and then calls guix pull with that commit
<ecbrown>i have a luks disk, which is at /dev/mapper/my-root. on a guixsd 0.15 install, i was able to use (device (file-system-mapper "my-root")) and things work great. having used the system for a while, probably some guix pull's and whatnot, now i can not guix system reconfigure using the same file, as it complains about "file-system-label: unbound variable"
<ecbrown>(fwiw i am running a custom 4.17.x kernel)
<ecbrown>not sure which module i need to add: i tried (gnu system file-systems)
<lfam>ecbrown: In the context where you tried to reconfigure, what is `guix --version`? Make sure the context is the same regarding invocations of sudo or any other way you became root
<lfam>It's a bit opaque since the keys don't have any metadata like a name, but you can check which keys are authorized by viewing '/etc/guix/acl'. You'll have to look up which key corresponds to which server, however
<vagrantc>what installes /etc/guix/acl? my most recent 0.15.x install as of a few weeks ago still only included hydra's keys.
<ecbrown>lfam: will try that. i have %desktop-services, hopefully not a major problem
<lfam>Oh, interesting. I guess the code I read doesn't have the effect I thought
<ecbrown>i'd like to flesh out the openssh configuration... i started by adding whatever is needed for tunneling
<lfam>Here's a change that we should make sure doesn't break anything: * ssh(1): prefer the ssh binary pointed to via argv to $PATH when re-executing ssh for ProxyJump. bz#2831
<lfam>I guess since that's for `ssh` and not `sshd` it wouldn't be handled by the current GuixSD service code
<rekado>lfam: isn’t this change what we would want, though? Or do you mean it might break shell wrappers?
<lfam>rekado: Since Guix uses environment variables for so many things, I was concerned this could affect service restart or reloading if we implemented it for a related use-case
<lfam>But I don't think we use or handle `ssh` for anything, so we should be good
<lfam>But I can imagine a similar change breaking, for example, nginx reloading upon nginx updates
<OriansJ>hmmm, I wonder if there is a way to assign all guix packages a build cost in terms of memory and processor resources, that way all build servers could build packages in the order which corresponded to the build server's administrators preference. EG. build bulky desktop packages like webkit last and tiny applications like mescc-tools first
<samplet>rekado: It looks like the stage2 GHC is not using ld-wrapper because the “--with-ld” is not getting propagated all the way down.
<samplet>I have to go now, but I bet I can fix this later tonight.
<OriansJ>Or possibly a way to make repo servers fully independent from build servers and thus allow multiple build servers to get build instructions from the commonly shared repo server that provides the binaries to be used in builds.