<lfam>lumidragon: Check out the desired commit and then delete the .git directory. Then do `guix hash -r` on the Git repo directory
<lfam>Better to mv the .git directory, or work on a copy of the Git directory, so you don't have to clone again
<lfam>We have to do this because the .git directory might be different every time you clone, as people commit to it. It would be nice if `guix hash` could exclude things, so you didn't have to delete the .git metadata
<kete>my eyes hurt, and I can't dim the screen. I'll just start over in the morning.
<kete>thanks defanor I think so, too. I'll try that tomorrow.
<lfam>Do we package a tool to check a disk's SMART status?
<defanor>does `guix system init` proceed from where it failed, or is it doing everything from the beginning each time?
<lfam>My question appears to be answered by the smartmontools package
<lfam>defanor: I _think_ that if you just stop `guix system init` and restart it, whatever you downloaded or built should still be in the store. But, I'm not sure what happens if you reboot, or anything like that.
<defanor>hrm. how much disk space the "bare-bones" system installation may require?
<lfam>defanor: Depending on what packages your OS configuration requires, you will probably get more substitutes and have to build less if you `guix pull` to get the latest package definitions. If you don't do it from the installer image, you should do it after you reboot into the system, because that is how you get security updates (there are many).
<lfam>I don't know off the top of my head, but I built a QEMU image of a very slightly modified bare-bones config yesterday, and the image is 1.2G. I don't know how that compares to a bare-metal installation.
<defanor>strange. i've tried to install on a 20G disk, also using qemu (qemu-kvm, a qcow2 disk)
<lfam>Guix will work on pretty much any GNU / Linux system, and is very unintrusive (it only creates /gnu, /var/guix, some new users (the builders), and a symlink forest at ~/.guix-profile)
<lfam>To be clear, Guix is the standalone package manager. GuixSD is the operating system built around Guix.
<lfam>You wouldn't have to install it on a desktop. You could install it on a server, build the VM there, and then copy the image to any machine with QEMU (and ideally with KVM)
<lfam>But I can understand not wanting to install Guix just to build a VM in order to try a new OS
<defanor>got it. and regarding substitutes – "guix system init" can also use them, right?
<lfam>Yes, as long as it can reach the substitutes server. You would see the messages about downloading them from mirror.hydra.gnu.org
<lfam>However, if there are no substitutes available for what you want, it won't help you much :) You might try `guix pull` so that you request the latest packages. It might increase the number of packages you can substitute.
<defanor>my primary concern with installing it on another machine is that it'll shadow some installed packages somehow/somewhere. got that with nixos, was quite confused with paths
<lfam>Well, if you have 'foo' at ~/.guix-profile/bin/foo and also at /usr/bin/foo, you need to set up your PATH so that it chooses the one you desire.
<defanor>yup, same with nix (and ouch, s/nixos/nix/). though i knew it, somehow things got messy
<lfam>It's been said in this channel that environment variables are one of the great problems of computer science ;)
<defanor>though sorted it out then, but three package managers would be a bit too much
<defanor>does the hydra public key come with guixsd? failing to find it
<lfam>Yes, I think it's authorized by default in GuixSD, but not for standalone Guix.
<lfam>If you don't seem to be getting any substitutes, then you either can't reach the substitutes server, or you are requesting things for which we have no substitute. That could mean that our build farm hasn't built your thing yet, or we have already garbage collected the thing you are requested, because too much time has passed and we need to make space for new substitutes.
<mark_weaver>inkscape is used to render our SVG graphics for things like the GRUB background image, which is why that's needed even for the barebones config.
<mark_weaver>reconfigure doesn't work from the installer. reconfigure is only used from within the system that you wish you update.
<mark_weaver>you'll probably need to erase the installed system and start the installation from scratch, I'm afraid. once you have a working system installed, future mistakes are easily dealt with by choosing an older (working) system from the GRUB menu, but mistakes in the initial install are rather painful, I'm sorry to say.
<mark_weaver>it would be good to find ways to improve this, but I'm not yet sure how to do it.
<defanor>of course, and it's not a big deal – i didn't configure much. just trying to install the basic system. thanks for the answers
<notadrop>No output and command ran successfully. I guess that means there are no updates currently availiable for my system.
<mark_weaver>notadrop: bugs for Guix and GuixSD are not distinguished. both should be sent to email@example.com
<mark_weaver>notadrop: note that "guix package -u" is similar to "apt-get upgrade" (except it only upgrades packages in the profile of the user who runs it), and "guix pull" is similar to "apt-get update" (except it only updates guix packages for the user who runs it)
<mark_weaver>notadrop: if you haven't run "guix pull" or equivalent, then you'll never get updates.
<mark_weaver>notadrop: also note that you'll need to run "guix pull" for each user who runs guix, which normally includes at least two users: your normal user, and root. if you don't run it as root also, then "guix system reconfigure", which is run as root, will not have updated packages.
<Kooda>guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/mgnqhcmzc76jxanfp5g6i60ycxnf874n-gzip-1.6.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<defanor>what's the proper way to set the default keyboard layout (for both console and X) in GuixSD? seems like one shouldn't touch anything in /etc, so should i edit local configs, or can it be set in the system config somehow?
<davexunit>civodul: remembering back to when I wrote the bindings, I found that I needed to make guesses at how much memory the decompressed data would take up, and if decompression failed I would expand the buffer and try again. I never did know if there was a better way :)
<mark_weaver>defanor: we don't have any way to configure the default X keymap. I'm not sure off-hand how to do that, so if you want to investigate that would be welcome. for now, we just configure it in our desktop environment, or if all else fails to you do it via the ~/.xsession script if necessary using 'setxkbmap'.
<mark_weaver>if ~/.xsession exists and is executable (shebang and chmod +x), then it will be run *instead* of the default action for launching the chosen desktop environment. so, the last thing it should do is to run something like 'startxfce4' in the foreground, preferably using 'exec'.
<defanor>mark_weaver: yup, i'm about to do that (setxkbmap, in a user config). thanks
<mark_weaver>there's nothing particularly special about our releases, except that we create new installers
<defanor>looks like the guix emacs mode requires magit, which isn't shipped with it. and the default i3-wm configuration uses dmenu and i3status, which aren't in its dependencies. are those deemed as bugs?
<taylan>how do I wrap an executable with a custom script again? akin to wrap-program, but providing hand-written code. I think there was a way to do it.
<taylan>maybe I'm dreaming. wrap-program doesn't seem to use any lower-level public procedure to do the actual wrapping.
<janneke>yup...i lack some understanding still of the build system, it seems
<defanor>can `guix system disk-image` use an alternative (gnu system install) module (e.g., in order to put alternative sample configurations there)? or can it just init/install the current system (same as the one used as installer), without writing a new configuration?
<defanor>and is there a way to put files into a user home directory, during installation? and/or to install packages into a user store?
<mark_weaver>and then add (console-keymap-service keymap) to the 'services' field of the OS config.
<mark_weaver>where the contents of that large string literal are what should be fed into 'loadkeys'
<kete>thanks, that's more involved than what I was asking. I just want to load en-latin9. I was putting it in the OS config and 'en-latin9' in /etc/console_keymap, but it's probably better to make it limited to my user even though there won't be any other users.