<marusich>is guix still usable after the error occurred? did it update the symlink at ~/.config/guix/latest? (you can check with 'stat ~/.config/guix/latest' and checking the mtime; if it isn't recent, it didn't flip the symlink)
<marusich>As for why it happened to you, I'm not sure. It is possible to run "guix pull" and wind up with a broken Guix installation, which is a huge bummer.
<marusich>There is no easy way to roll back when that happens, yet... The best you can do is record the original symlink and flip it back manually
<marusich>However, you might also be interested in knowing that "guix pull" allows you to specify arbitrary commits or URLs from which to pull, which makes it easier to get back to a working version if something bad happens.
<marusich>Apteryx, I feel like I'm missing something obvious with Magit. When I press "M-x magit-status", followed by "l", the popup screen makes it look like I can select arguments, such as --graph.
<marusich>But I can't figure out how to select them. Do you know how to do that?
<marusich>I didn't realize the switches were changing color when I was pressing them........
<marusich>CompanionCube, FWIW, I just ran "guix pull" as an unprivileged user, and successully switched to using Guix from commit e2d0cf033eb894fa8c786d0bf039fc54685d5559. I'm building GNU Hello as a test to make sure it works, and so far there are no errors like the one you mentioned. This is on an x86_64-linux GuixSD system.
<CompanionCube>marusich: maybe it's just down to me not updating user guix since january :p
<civodul>right, but global is the 2nd answer to "guix package -s code -s tagging"
<civodul>which is more important than having or not having "GNU" in its description i believe :-)
<snape>GNU Womb. "A collective repository for random code that isn't ready to become a seperate GNU project, or intends to be merged with an already existing GNU project." What's the point of GNU projects being there?
<snape>the problem being that if you change your drive, you need to update your config :-)
<wigust>Hello Guix, Could I cannot get a ‘gcc-lib’ PACKAGE in ‘guix environment’ with ‘(inputs `(… ("gcc" ,gcc-7 ("lib")) …))’. ‘guix package -p $GUIX_ENVIRONMENT -I’ doesn't show ‘gcc’ with output ‘lib’ (also no any other package output). I need a ‘/gnu/store/…-gcc-7.3.0-lib’ package in ‘guix environment’.
<wigust->civodul: Thank you, but in my case it's a workaround, because I use ‘--load=guix.scm’. Cannot I get a ‘gcc-lib’ in ‘guix.scm’?
<wigust->OK, ‘guix environment --no-grafts --load=guix.scm --ad-hoc gcc@7:lib’ works for me (the order of flags is matter, because ‘guix environment --ad-hoc gcc@7:lib --no-grafts --load=guix.scm’ doesn't work).
<rekado>g_bor: great! What does the change look like?
<rekado>unfortunately, I’ve already been building hundreds of packages with that change.
<g_bor>Actually it goes like that make the change in the importlib to also depend on 'DETERMINISTIC_BUILD'.
<g_bor>However it seems to me, that something is wrong here...
<g_bor>It seems that with the bytecode manipulation stuff it is actually possible to create modules not respecting 'DETERMINISTIC_BUILD'. Is it possible that for example numpy does something like that, and that's why it is not reproducible?
<civodul>i wonder why our GitHub updater is so often unhelpful
<civodul>for instance, "guix refresh arpack-ng" does nothing
<rekado>I think it is not correct to make validation behaviour dependent on the user environment.
<rekado>generating deterministic bytecode, however, is something that should be dependent on the environment, because people may build bytecode in projects that are not covered by Guix.
<rekado>when building with Guix we can trivially set this environment variable, so it’s not a problem.
<rekado>I feel that maybe we should leave the patch as is, although this entails disabling three tests.
<g_bor>rekado: In fact it seems that there is some mechanism in these tests, a module is created there on the fly, and thus failing the test. The module there is in fact created when we have 'DETERMINISTIC_BUILD' unset already.
<g_bor>I still feel that disabling the tests is safe.
<rekado>that’s why we’re recompiling all .py files at the end when DETERMINISTIC_BUILD is enabled again.
<rekado>for some reason this still leaves about 500 pyc files that are not deterministic. It’s possible that they were generated earlier (and maybe they should be removed before rebuilding all py files).
<rekado>civodul: IT just confirmed that they have no additional restrictions in the firewall that would affect SSH connections between overdrive1 and berlin.guixsd.org.
<ng0>speaking of which.. a friend brought up the lack of a field for "recommended runtime dependencies" and since my torbrowser requires a running tor (you will get to the testpage saying "you don't run tor!") with a control port, do we just point it out in the description like always or could we just extend the fields?
<ng0>not just for this package, but think of the many optional runtime dependencies of mc etc
<ng0>after a certain number of years you just know what you need, but newcomers won't figure it out that easy
<ng0>when I write "fields" I just mean what'S being returned by the package search
<ng0>technically incorrect, let's just pretend I wrote "more metadata"
<efraim>I like Debian's 'provides' field, 'oh, you need X? Take one of these 3'
<rekado>with Tor it’s different. You’d use the tor-service, not juts a package.
<mfiano>Is it as much of a pain to get a Common Lisp development working with Guix as it is with Nix?
<mfiano>Particularly a Common Lisp image being able to locate foreign libraries and such
<ng0>right.. but the simple statement "requires: tor" in a package search would tell people: Aha! I need tor for torbrowser. just as an example.
<thomassgn>Curious about something: I'm continuing on making a package inherit from another and want to change the arguments field. First I couldn't find any documentation for '(package-arguments package)' and now I see everywhere in the guix sources it is preceded by '(substitute-keyword-arguments ...)' which I also can not find in the docs for either guix or guile. I'm going to look through the guix sources for it, but
<thomassgn>is this simply missing documentation, or is something else going here?
<efraim>I don't think it's explicitly documented, I normally grep for substitute-keyword-arguments when I need to add another one
<fractal>and yes, those help pages allowed me to extract the iso. (i was doing it wrong, and assumed there wasn't specific documentation for it. derp!)
<thomassgn>fractal: Been there, I remember a period when I was changing distro approximately once a month.
<thomassgn>if you do want to try a commandline and config-files heavy distro I would recommend GuixSD (or maybe NixOS, samey but different - GuixSDs precursor). And remember that learning to be comfortable in a commandline can be time consuming but also incredibly rewarding in terms of understanding and suddenly so much more becomes accessible in this world of free software (and ironically I found, in nonfree also)... :)
<guile-guest3>Hi all, guile has mysteriously stopped working on my guixsd machine. When I run guile it says "guile: warning: failed to install locale" and then a variety of other stuff, which I'd be happy to paste here
<efraim>working on the enlightenment-service, #$enlightenment/lib/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.22/freqset is supposed to be setuid
<guile-guest3>I noticed this during a "sudo guix pull", but i'm not sure if it was broken before. It has persisted after the command finished and after I run "sudo guix package -u"
<rcm>civodul: Hello from guile. Sorry, I wasn't sure if it was a guile or a guix problem initially. So the general order of update commands you use is "sudo guix pull" then "guix pull" then "sudo guix system reconfigure "?
<rcm>Just given how long a "guix pull" command takes to execute I want to make sure I'm not being redundant by running the root command and the non-root command
<vagrantc>you don't actually need to update root's copy of guix
<vagrantc>unless you're installing programs just for the root user
<rcm>What exactly is happening when I run "guix pull"? It spends a lot of time compiling stuff. Is building a.) every program available to guixsd. b.) every program that the user has installed (not including those that are in the config.scm) c.) every program that is in config.scm or that the user has installed. or d.) something else entirely
<rcm>Sorry for beating a dead horse, but I still don't think I quite understand (but I think I'm getting close. This has been very helpful!). Does creating the symlink '~/.config/guix/latest' have any effect on the root user?
<vagrantc>ACTION admits it's all kind of confusing
<rcm>thorwil: So how will the root user be using the latest version of guix without running 'guix pull' as root?
<wigust->rcm: every user (including root) should have ‘~/.config/guix/latest’. Using ‘sudo’ mechanism you could preserve your Bash environment variables, for example to use your user's ‘~/.config/guix/latest’ instead of root's ‘~/.config/guix/latest’.
<thorwil>is it this way: no matter the user (including root), guix pull will fetch and build the latest available, if necessary, then set ~/.config/guix/latest?
<rcm>I have to run, but this has been incredibly illuminating. I know that guixsd is incredibly modular and applies to many many usecases, but perhaps the manual could use a 'best practices' section where things like basic system maintinence are outlined for a typical user
<rcm>thank you all so much for the valuable information
<wigust->rcm: best practice is to ‘pull’ for each user, but you asked for a specific case :-)
<wigust->thorwil: no matter the user, but it will pull and build even if not necessary as I know