<xentrac>wgreenhouse: I'm glad it's helpful! but you should *test your backups* also so that you aren't left relying on the correctness of random snippets of irc :)
<wgreenhouse>xentrac: yeah, I do :) but I had been (separately) making btrfs snapshots and rdiff-backup'ing that entire filesystem in its "live" unsnapshotted state
<wgreenhouse>I realized that that was probably a bit riskier than taking the snapshot and copying that, especially if e.g. mail is arriving and getting indexed meanwhile
<xentrac>hmm, I guess it's hard to make sure your backup procedure is stress-tested
<xentrac>unless you're using a system that allows you to reproduce the system configuration on another machine (maybe a virtual one) and load-test it without fear of wasting a lot of time trying to get the configurations to match
<mark_weaver>my guess is that your build failed because your kernel lacks a needed feature that caused coreutils' test suite to fail
<mark_weaver>so you'll need to clear the cache entry that remembered that the build failed
<mark_weaver>sneek: later ask civodul: lfam needs to know how to clear the cache of failed builds. he enabled the caching of failed builds in his guix-daemon, and then had a build fail and doesn't know how to recover.
<lfam>mark_weaver: I'm not sure how the caching works, obviously. But I ran guix gc and now I am downloading substitutes. So maybe it will build now that that test is disabled. I'm sick of this stupid vendor kernel, though.
<mark_weaver>lfam: it looks like the failure cache is stored in the sqlite database
<rekado>haven't upgraded anything on the cluster yet, but I'm a little worried about this.
<rekado>Here's another thing that repeatedly annoyed me whenever I upgrade my profile: "python-2" and "python" both provide packages named "python", making it difficult to upgrade "python-2" to the latest 2.x.
<rekado>I forgot to exclude "python-2" from the updates, so now I have two entries of "python 3.x" in my profile.
<rekado>since we provide separate modules for python 2 and python 3, would it not be a good idea to let "python-2" provide a package named "python2", so that users could easily upgrade to the latest 2.x release?
<Steap>oh yeah, I can't easily install both Python 2 and 3 iirc
<rekado>you can do "guix package -i python-2.x python", but upgrades are a little more difficult.
<mark_weaver>rekado: regarding "python-2", this is not just a problem for python but for _any_ package where users deliberately want an older version. I have this problem for many other packages, including gcc, clang, gnupg, and texinfo.
<mark_weaver>this is really just a limitation in our "upgrade" command. I don't think we should move the version number into the package name to work around that limitation.
<mark_weaver>rather, I think we should remember when you ask for e.g. "python-2" or "gcc-4.9" and record that information in the manifest so that upgrades will take that into account
<rekado>I think that python is a little special, because we cater for both major versions, providing modules for both.
<rekado>but sure, if the upgrade command could be made to perform a conservative upgrade, that would be nice too.
<mark_weaver>I should also mention that we have a superior approach already available which avoids this problem entirely: "guix package --manifest"
<mark_weaver>although it would be very helpful to have a way to create a file suitable for use with that command, given an existing profile.
<mark_weaver>I recently converted to that approach, but creating the file was rather tedious, mainly because of having to look up all of the module names that I needed to import.
<sneek>civodul, mark_weaver says: lfam needs to know how to clear the cache of failed builds. he enabled the caching of failed builds in his guix-daemon, and then had a build fail and doesn't know how to recover.
<sneek>civodul, mark_weaver says: the failed build was coreutils on armhf, and I think it failed because he was missing a needed feature in his kernel
<mark_weaver>it's probably not a great idea for ordinary users to enable the build failure cache anyway, given the number of non-deterministic test failures we have currently. also, I wonder if download failures by the substituter would be cached as failures. if so, that would be a problem
<mark_weaver>codemac: probably you just want to add "CC=gcc" to #:make-flags
<mark_weaver>and remove that custom phase, as well as 'gcc' from inputs which is already included implicitly
<mark_weaver>so, in the arguments list, #:make-flags (list "CC=gcc")
<mark_weaver>but surely you'll need to tell it where to install things. normally that's done by passing --prefix= to configure, but without a configure phase that can't happen.
<mark_weaver>codemac: the reason 'match' didn't work is because you didn't arrange to import (ice-9 match) in the build environment, but anyway this is not a good way to set CC anyway.
<mark_weaver>when 'match' is not imported, it is assumed to be a normal procedure, and so (((_ . dir) ...) dir) is one of its arguments, which is itself a procedure call, and ultimately (_ . dir) is an expression that is not valid scheme code, hence the error.
<mark_weaver>well, (_ . dir) is a position where an expression is expected, but it's not a valid scheme expression, is what I meant to write.
<codemac>mark_weaver: Ahh yes, I forget that importing a module at the top of a package != available in build rules. It makes sense but I keep forgetting. And thanks for the pointer on the #:make-flags :)
<paroneayea>davexunit: counteracting that kind of direction for application packaging means we're going to have to get gnome nicely working to prove it's an alternative... at least there seems to be progress there
<paroneayea>anyway, I'm sold on GUIs because I think network freedom will require serving users who aren't programmers (but maybe eventually will become so)
<paroneayea>I'd like to have GUIs as a programming funnel :)
<davexunit>Eben Moglen describes GUIs as things that lower the dialogue with the computer to "point and grunt"
<davexunit>I wrote guix-web, so obviously I think a GUI has a purpose, but a GUI will always be limiting.
<paroneayea>still, there's a good reason to not be condescending towards GUI users
<mark_weaver>yeah, he compared using a mouse as "pointing and grunting" and said that when the way we communicate with computers is reduced to pointing and grunting, neither they nor we will grow as we should
<paroneayea>Mairin Duffy drew a nice comic where she showed some users wanting to get involved, and they were basically snarked out for not being "technical enough", and so they walk over to the Apple store where sales clerks welcome them with open arms
<paroneayea>and I think that's true, GUIs might not be optimal, but if you make GUI users feel unwelcome
<paroneayea>you can't be surprised when they go somewhere else