<Demosthenex>ok, so the site's a bit light on detail. hurray that it isn't infected with systemd. i'm currently using ubuntu on my laptop, server edition with just a handful of X packages, no user crap. i'm seriously considering moving to freebsd because i'm sick of systemd and the duct taped together linux world. why might i consider guix?
<roelj>I'm running 'guix lint <my-package>' and it crashes with: 'ERROR: unsupported URL mirror kind alpha.gnu.org ...'
<davexunit>piyo: differentiate with a version number or naming the package differently
<piyo>davexunit: The changes: Filename is now my/packages/screen-piyo256.scm, (define-module (my packages screen-piyo256) ...) (define-public screen-piyo256 (package (name "screen-piyo256") ...) ...) and it compiles with guix package -i screen-piyo256
<rekado>referencing a variable explicitly in guile is (@@ (the module name) variable-name)
<rekado>but renaming the package variable/name is better anyway.
<rekado>Demosthenex: guix is a very nice package manager. GuixSD is a system built around the package manager (because thanks to functional package management guix knows about dependencies all the way down to kernel headers and bootstrap binaries).
<piyo>rekado: I don't understand those concepts yet.
<rekado>piyo: it's not important. As you can see from my handwaving: neither do I ;)
<piyo>my next question is using guix behind a http proxy... I found the workaround about injecting the http_proxy environment variable into guix-daemon. My question is, is there any downsides to using ~root/.guix-profile/bin/guix-daemon as the daemon to start? for example what happens when I do guix package -u guix as root?
<davexunit>that upgrades the guix package in the root user's profile
<piyo>I assume ~root/.guix-profile/bin/guix-daemon is updated as well?
<davexunit>you can verify for yourself by reading the links
<piyo>I am more concerned about the semantic change, is this a recommended upgrade procedure and at the same time a recommended guix-daemon running procedure?
<davexunit>it's a typical way to manage guix on a foreign distro
<davexunit>in guixsd, the global system config has the guix stuff.
<piyo>So piyo user has say guix-0.x, and root had guix-0.x but after the above, now has guix-0.y. I should now restart the guix-daemon so that ~root can call guix-0.y correctly. I should now also guix package -u guix as piyo so that piyo uses the "right" guix-daemon?
<davexunit>the guix daemon's API hasn't changed in all the time I've been using guix.
<piyo>So to sum up, when auto-starting guix-daemon via my own shell script which will define http_proxy, I don't have to worry about breaking changes (knock on wood). Therefore I can start the guix-daemon using the path "~root/.guix-profile/bin/guix-daemon".
<mark_weaver>piyo: everything guix-daemon needs and uses is in the immutable directories in /gnu/store. updating root's profile only changes one symlink, so it will not affect anything that the running daemon needs.
<mark_weaver>(the daemon doesn't care about that symlink; it will only be used when you launch it via the path you gave)
<piyo>yes mark_weaver but I was concerned about the situation where a newer .../bin/guix tool could not call a running guix-daemon because of a API change or otherwise.
<mark_weaver>ah, I see. no, the guix-daemon API is very stable, as davexunit said. it's never been an issue in the years I've been using guix.
<mark_weaver>I suspect a guix-daemon from two years ago would work with the current guix client
<keverets>rekado: ah. The guix manual seems to recommend doing "guix pull" to get the latest software versions available (which then need to be installed by "guix package -u"). Perhaps a git checkout is lighter weight, but similar outcome?
<dmcp>hi guys! I did't use guix nor guix sd yet, but I saw some infos on the webiste and I liked very much! I'll install guix on my machine soon just to see it in action and I intend to install guixsd at least on a v.m. some day :)
<lfam>It seems that nix is packaging the whole thing for python2, which screwed me up for a while (their python defaults to python2).
<lfam>My major issue now is figuring out why the test phase of lets-encrypt can't find python2-pythondialog. That is driving me nuts. And there are a few dependent libraries that aren't building properly.
<lfam>I rebased your big commit into a bunch of little commits. Lesson learned: I should have "duplicated" your big commit and then rebased the dupe. As it is, I broke history with you.
<lfam>So when pump.io says that it's only dependencies are node.js, npm, graphicsmagick, and a db (I'd use redis, probably), they are papering over a whole mess of dependencies that would come through npm?