<zacts>I highly value the philosophy of 'the grandma test' and you get a new OS, plug it in, and it works for the next 10 years with almost no problems.
<zacts>the grandma test = if my grandma can use it, then it's stable / reliable / good clean software.
<mark_weaver>if you have trouble with the automake thing, another way is to start with the guix-0.5 tarball, and then use it to install automake and everything else you need, and then use that to bootstrap from git.
<mark_weaver>it needs to be able to find all the relevant .m4 files (typically in /usr/share/aclocal)
<mark_weaver>if, after running ./bootstrap, the ./configure script fails on a line that has an unexpanded m4 macro (i.e. all caps, and clearly not shell code), it probably means that you're missing a relevant .m4 file or that it couldn't be found.
<atheia>Does anyone know whether this is currently expected?
<rgrau>hi. I have a question regarding the recipes versionning. When a new version of a package comes out, if I update the recipe and you push it to the repo, what happens to packages that depend on the old version? do you keep every recipe for every version?
<rgrau>it's like a compressed step by step guide to superbasic package building and contributing. I'd like to write another tut for more complex packages, but first I have to succeed building more complex packages :)
<rgrau>civodul: regarding the versions, makes total sense. I'll send an update to the luajit package later
<mark_weaver>the thing is, going forward we'll be using /gnu/store, and those will probably be on hydra within a week, so it seems a bit silly to install a new guix with /nix/store, especially if you intend to contribute.