<lfam>Whether packages get upgraded quickly or not really depends on whether or not anyone is paying attention to those particular packages.
<taken>and 2: is it easy to get a newer version of just a couple of packages within Guix, eg. by tweaking the recipe to get the sources for the newest version rather than whatever is in the main catalog?
<lfam>It's easy to create a package variant with a different version, and use that privately. Also very easy to send an update patch to firstname.lastname@example.org and let us merge it :)
<taken>lfam: I noted a couple things, but hopefully after I start using Guix I'll learn how to modify the recipes and I'll just patch them myself. Do you generally try to stay as current as possible on packages?
<taken>For instance, I install something like ssh-server. It needs a key pair to authenticate, so most package systems will run a script to generate a key pair on first installation. Do you count on the user to generate keys before running it?
<lfam>Building and installing sshd is handling separately from initiliazing the use of it. We do that sort of thing in the "service" layer. Our init system / service manager Shepherd does that stuff. We have a service for the Lsh SSH implementation, but not yet for OpenSSH (help wanted!)
<lfam>The other thing is that what counts as "installation" is different here. We install software into /gnu/store when it is built. What users consider installation (making it available for use) is a further step, which usually consists of making a bunch of symlinks to put the software in the user's profile.
<lfam>I guess that lsh is not meant to be capitalized
<taken>lfam: Ok. Also, another annoying thing most package managers use scripts for is silly databases that several programs want to update, like man-db or icon caches or things like that. What is the guix approach to those sorts of things?
<lfam>When built, every package is installed into a unique directory in /gnu/store. Man pages are typically put in /gnu/store/...-foo/share/man/man1, where ... is the unique hash. When a user puts a package in their profile, all the man pages are symlinked into ~/.guix-profile/share/man/man1
<lfam>We provide a file you should source in your login shell that makes that path available, among other things
<lfam>Hmm, reading that file, I don't see any mention of the man pages. I don't remember what I did to make them available
<lfam>Hm, I thought I sourced that file, but it seems that I don't!
<lfam>I do on my home server, but not on my workstation
<bavier>there's a MANPATH native-search-path declared
<bavier>so on a foreign distro that will get set in the user's profile
<bavier>I was confused for a moment, because I'm on GuixSD, and that env var is set in the system profile
<lfam>I have no idea how it works on this Debian system. This is another point for GuixSD ;)
<taken>lfam: man-db was probably a bad example, because man uses MANPATH, and I'm really not sure why man-db even exists (I guess it's faster if it's in man-db?), but some groups of programs have databases that need to be updated via mutation.
<lfam>Yeah, nothing ever gets mutated in the store
<lfam>Those programs typically let you configure the location of the mutable state at build-time, so you just make sure to configure the program to look elsewhere
<taken>lfam: so far it sounds like guix just avoids them, which is what I assumed, but I wondered if there were some sort of solution on top of that. Like maybe the database was copied and modified in some way. But, yeah, the real solution is for developers to stop doing that...
<lfam>In practice it's not a problem. Not much software requires the state to be in the same directory as the executable.
<taken>lfam: yeah. Frankly I don't use much of that software anyway, but occasionally I see my package manager updating weird gnome databases or something. Anyway, thanks for all your answers.
<lfam>Huh, when I inspect the environment of `man foo`, MANPATH isn't set. The only references to my ~/.guix-profile are in PATH and GUIX_LOCPATH
<taken>lfam: Why do you have /bin/sh but not /usr/bin/env? /usr/bin/env is the one thing I really care about so I can write portable scripts that end up just getting the right interpreter as set by the environment.
<taken>lfam: to me it makes more sense to have /usr/bin/env and not /bin/sh...
<lfam>My opinion is that if a script is important, I care what interpreter it uses, so I want to use a shebang that points to a unique store path, rather than some random version of the interpreter
<lfam>But like I said, if you don't care what interpreter is used, you can make the symlink. `env` is in the coreutils packages.
<lfam>Check out 'patch-source-shebangs' in the manual for a potential improvement over `env`
<taken>lfam: Well, I really think there should be a default /usr/bin/env always there for convenience, (eg so people can clone their dotfiles repo that includes a bunch of scripts that they use on all OSes), but I guess we can just disagree :) Thanks for all your answers.
<lfam>Yes, /usr/bin/env has been discussed many times before. It's really easy to make the symlink.
<lfam>But I hope you'll consider my point. You lose most of the advantages of Guix for whatever script you run against `env`
<taken>lfam: patch-source-shebangs seems like the wrong thing to me, because then I am mutating the source of my scripts. I see that it's losing the rock-solid linking and whatnot, but there is also something to be said for being able to conveniently use scripts that are already written for maximum portability.
<lfam>Okay, as long as you see the drawback, which I think you do :)
<taken>How does shepherd compare with systemd? Since both Arch and Debian switched to systemd I've been happy to finally have all my systems (except my phone...) on the same init system. Knowing now that a switch to GuixSD means a switch of init systems again makes me want to use it less...
<lfam>Shepherd is implemented in Guile Scheme (like the rest of Guix) and services are also Scheme.
<lfam>As a happy systemd user, I would say that Shepherd has considerably fewer features
<lfam>But the potential for system integration is much greater, since it's all in Scheme
<lfam>I was totally new to Scheme when I started using Guix. I miss the ease with which you can create systemd services, but eventually I realized that you can also do simple per-user services with Shepherd, so I'm happy again.
<lfam>I'm currently struggling to write a system service, and I've had to reach out for help.
<taken>Hmm... well I am semi-obsessed with lisp machines, so all scheme is very appealing...
<lfam>We need more. Hopefully when I complete the one I am working on now, I will experience a revelation and add a bunch :)
<lfam>There are also people using Shepherd on foreign distros. It's quite flexible
<taken>If I run the guix packaging commands with nice, will the daemon build things with a nice value, or should I put nice in the service file for the build daemon? [I've been building stuff and seeing my system less responsive, which I'm not used to since I have make aliased with nice...]
<lfam>Eventually, the protocol could be implemented by 3rd parties who have the resources to spend on very polished interfaces
<taken>after a quick trial of syncthing-gtk, I think it is probably good enough to get my family to start using syncthing if I can get them through installing it. Really manually getting to the interface I always saw as the biggest blocker.
<lfam>You have to decide if you want to become remote (SSH) tech support for your entire family ;)
<taken>Aha! I would actually not mind being ssh tech support for my entire family if that meant I could get my entire family to switch away from Windows!
<taken>Then I'll set them all up with duplicity running regularly and putting the backups in a shared syncthing repo that we all keep on a large hard drive, then we can all have encrypted, versioned, off-site backups, and do it all with free software and all within the family [no large soulless corporations included].
<uncanny>Any idea what config.scm was used to create the USB Stick installation ? If I find it I intend on running `guix system reconfigure that_config.scm` and hope guix gets updated this way, before proceeding with `guix system init /mnt/etc/config.scm /mnt`
<cbaines>uncanny, I believe what you are looking for is in gnu/system/install.scm
<uncanny>looks like reconfigure is doing some grafting and I see guix in that list, when it's done it should be build 8062...
<uncanny>Confirmed. So, apparently, unless I'm missing something, a `guix system reconfigure a_config.scm` is needed after a `guix pull` or else guix won't get updated (tested on qemu booted USB stick installation)
<uncanny>That being said, grub will fail right at the end; I guess it's not part of the transaction, since it failing still gets guix(and all others?) updated
<uncanny>`guix gc` just freed 1.1G and I've realized that the free space that `df` reports in /gnu/store/ is the sum of 75% of my RAM + the free space on /mnt (that explains what `herd cow-store start /mnt` does) and the 1.1G freed is freed from both /mnt and /gnu/store (unionfs?). Cool!
<alezost>halteaugrabuge: I guess you used several file systems. It's a scheme question: cons is used to construct an element and a list (cons 1 '(2 3)); cons* is used to construct multiple elements and a list: (cons* 1 2 3 '(4 5))
<joshuaBPMan>hello, I'm trying to get my /dev/sda4 to mount into /home. I've change by configure.scm. But `guix system reconfigure /etc/config.scm` is reporting: /etc/config.scm:8:0: error: source expression failed to match any pattern.
<mark_weaver>the relevant error message is probably earlier in the output
<mark_weaver>halteaugrabuge: oh, also, I should mention that there's a lot of output *after* the login prompt, so you might have missed the login prompt. maybe try hitting "return" to see if another one is printed?
<habs>Hi, I have this problem where if I view videos in VLC at the default (small) window size, I can see everything, but if I try to resize the window the video gets cropped, like this: http://imgur.com/a/UN3AB What can I do to debug / fix this?
<habs>I'm using GuixSD / GNOME on a Thinkpad X200. glxgears seems to work fine (runs at the max of ~60fps full screen), here is the output of glxgears -info: http://sprunge.us/RLPV
<mark_weaver>habs: hmm, I don't use vlc on Guix, so I don't know off-hand, but in the meantime I can recommend the 'mpv' movie player
<joshuaBPman>habs: are you experiencing any other issues with Gnome? about 10 minutes after I log in, Gnome won't let me open any new programs.
<mark_weaver>joshuaBPman: that's a problem I've not heard about before
<joshuaBPman>mark_weaver: Well I installed with /dev/sda1 (root) at /mnt and /dev/sda4 at /home. But I ran `guix system init` when my config file DID NOT specify that it needed to mount home. I'm wondering if that has anything to do with it.
<joshuaBPman>also I did not run guix pull before running 'guix system init'
<mark_weaver>joshuaBPman: have you run "guix pull" and "guix system reconfigure" since then? if not, you've got a lot of unpatched security flaws.
<petter>habs, i had those problems as well. I fixed it in the settings. Pretty sure it was unselecting "Resize interface to video size" that fixed it for me.
<joshuaBPman>yeah. I've run guix pull a lot. But I'm think that guix system reconfigure is failing. I'll try both again now and let you know what happens.
<mark_weaver>joshuaBPman: note that "guix pull" only updates guix for the user that runs it. since "guix system reconfigure" is run as root, you need to run "guix pull" as root or else you'll get old stuff.
<mark_weaver>you'll also need to run "guix pull" as your normal user, for when you run "guix" as your normal user, e.g. to install packages in your user profile.
<joshuaBPman>hello, I tried a `sudo guix system reconfigure /etc/config.scm` Right now it is saying "shepherd: Evaluating user expression (register-services (primitive-load "/gnu/s.."))" and it's been saying that for the last half hour.