<pkill9>the error is: guix environment: error: build failed: some substitutes for the outputs of derivation `/gnu/store/7a3n0hkfm57jp53087n1akbabxj7yngs-fastboot-7.1.2_r6.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<pkill9>and more specifically: guix/ui.scm:1579:12: In procedure run-guix-command:
<rekado>if the admin web interface allowed the user to control whether a branch is built or not by simply clicking on the thing I would feel much more comfortable with it than running some sqlite command in an ssh session.
<snape>yes, but it's fundamentally the same. Also, the SQL request isn't complicated at all.
<snape>but you're right, an admin interface is preferable
<snape>FYI the request would be: update inputs set revision = '<revision>' and branch = NULL where specification = '<revision>' and name = '<input-name>';
<rekado>I’m confident I *will* do this wrong at some point :)
<rekado>this should show you that the source code is unpacked, patched, and repacked.
<rekado>civodul: building a statically linked subset of multipathd looks difficult.
<grafoo>rekado: yes the tarball exisits and is patched.
<rekado>I wonder if we could remount devices instead: mount /gnu/store from /dev/sdb1, then start multipathd, which creates /dev/mapper/foo from /dev/sdb1 and /dev/sdc1, and then remount /gnu/store from /dev/mapper/foo.
<rekado>grafoo: then there’s no problem, is there?
<snape>the Shepherd changes are awesome! Should we update our Shepherd package?
<civodul>snape: we need changes on the guix side to take advantage of them, and more testing
<civodul>after than we can make a Shepherd release
<civodul>janneke: also, that it behaves different on i686 and on x86_64 with "-s i686-linux" means that some package recipe must not be quite right, or the system conditional is not evaluated at the right time
<janneke>hmm, but that's (partly?) the idea right, we only want to modify the i686-linux bootstrap...
<civodul>yes but we should get the infinite recursion just as well when using "-s i686-linux" on x86_64
<ngz>Hello. In ".profile", I source "$GUIX_PROFILE/etc/profile". Unfortunately I have to unset "GI_TYPELIB_PATH" and "XDG_DATA_DIRS" in the same file or Gnome Shell crashes. Is it a known issue? Is there any workaround?
<sneek>ngz, wigust says: Try instead of unsetting - set them to what they were before sourcing ‘~/.guix-profile/etc/profile’ . For me setting XDG_CONFIG_DIRS and XDG_DATA_DIRS after sourcing  works.
<taylan>hmm, I can only log in to GNOME with root right now. if I log in with my normal user, GNOME or X11 seems to crash and I'm back in the login manager soon after. I moved away my GNOME autostart scripts but still have the same problem. what else might be causing this?..
<amz3>taylan: hey! good to see you around! sorry i can not help.
<taylan>sadly I only drop in sporadically these times. busy with lots of stuff :)
*taylan laments about software that won't say what its problem is
<roptat>rain1: you should use pre-inst-env from your git checkout
<rain1>thank you, i will make sure to do ./pref-inst-env for all this. but even after doing that my guix build command gives the same errors
<ngz>taylan: Do you source $GUIX_PROFILE/etc/profile in ".profile"?
<taylan>I have a very... "intricate" ~/.profile (in fact, it's located at ~/etc/profile)
<taylan>my obsessive tidiness keeps biting me in the behind
<ngz>taylan: It probably will not solve your issue. The problem is some environment variable is set, and Gnome doesn't like it. I had to unset GI_TYPELIB_PATH and XDG_DATA_DIRS to be able to go past GDM.