<cbaines>colemickens, I'm unsure, could you explain what purely evaluated means?
<colemickens>cbaines: in nix stable, NIX_PATH and environment variables and the exact state of ~/.config/nixpkgs/* affects the outcome of nix builds. in nixUnstable evaluations are pure by default and have none of those impurities leaking in affecting build outcomes
<cbaines>colemickens, OK, I don't think the concept exactly maps to Guix, but generally you have to be explicit about introducing changes (impurities), so I think the rough answer might be, yes
<leoprikler>There are a few environment variables, that can affect Guix, but they are rarely used.
<leoprikler>For instance, you can choose to prepend packages and extensions.
<leoprikler>If you are afraid of them leaking, simply set those variables to an empty value.
<leoprikler>And of course, the most important factor is the PATH variable, which defines which guix command to use :P
<meo>actually I probably need to update yubikey-piv-tool first
<leoprikler>there are already some yubikey tools packaged, perhaps you can use one of those?
<meo>leoprikler: ssh needs libykcs11 from yubico-piv-tool which is too old
<meo>leoprikler: so my fips authentication doesn't work out of the box, the yubico package in guix needs to be updated, I'll do it
<jlicht>sertified: what problem do you have? Is it with the ipykernel, by any chance?
<yuqio>Hello, I have a question about guix environment. Is it possible to automatically set environment variables when running `guix environment`? My current workflow is to run `guix environment -m manifest.scm` and then `source .env` (where the .env file contains the environment variables) and ideally I would like to skip the second command.
<leoprikler>yuqio: if you're using pure environments you can pass them on with -E, otherwise no
<pineapples>I read a short mailing thread regarding the bug that prevents Linux-libre from loading non-free firmware, and about the endorsement of Debian-based PureOS, by FSF. This got me thinking about GNU Guix System potentially adopting the Debian kernel, which can load those firmwares. Realistically-speaking, would this hurt any of the four freedoms of GNU Guix System users? I'm asking because I somewhat
<pineapples>disappointed after my yesterday's unsucessful attempt to use Linux-libre on my system :-(
<PurpleSym>sertified: My current intuition would be to patch jupyter-core, so it comes with etc/jupyter/migrated, which apparently prevents migration.
<PurpleSym>sertified: I pushed a fix as commit 16ad755f94597cc47725a030ef1a65f94d4155c8.
<jlicht>sertified: I always export JUPYTER_CONFIG_DIR=<some-dir> to do things with jupyter notebooks. Perhaps that might work for you as well
<irfus>hi #guix. I wrote an updated definition for mesa and added it to a local channel. Reconfiguring the system correctly builds and installs it too.
<irfus>But the version of mesa reported by `glxinfo` is still the older on e
<irfus>I checked the store and it seems to have both versions installed, but the new one is unused
<irfus>I had assumed that since it had a higher version, it would take precedence over the older one. What am I missing?
<roptat>irfus, that's because the precedence mechanism only works at the CLI level
<roptat>in code, it relies of the scheme object, so there's no ambiguity and no precedence
<roptat>iirc glxinfo is from mesa-util, which depends on mesa in that way: (input `(("mesa" ,mesa) ...)) the second mesa (with the comma) refers to the guile variable mesa, which is also defined in the same file, it's guix's own mesa variable
<roptat>similarly for the rest of the system, packages rely on the scheme variable, so they use the guix version instead of yours
<irfus>right, so I should modify the inputs of all such packages to pull 'mesa-21' instead?
<roptat>what you need is to rewrite their dependency graph, with something like --firstname.lastname@example.org=my-mesa
<irfus>I am aware of the above when using `guix package` on the command-line, but how to ensure that transformation applies to every package during a system reconfiguration?
<irfus>Also, assuming there's a programmatic way of applying that transformation, would that result in rebuilding them or will it use "grafting" (I've not entirely understood how that works but I believe this is the kind of scenario it was designed for?)
<roptat>to ensure grafting, you can for instance declare a new mesa package that inherits from guix package, but adds a replacement field
<roptat>the replacement field does not count for computing the guix store path, so it's the same package
<roptat>now, if you rewrite dependencies to use that package, all the dependents will be grafted with the package you put in the new replacement field
<roptat>and no rebuild, because it's the same dependency (store path)
<roptat>I don't know of an easy way to rewrite dependencies for guix system however
<roptat>you can do that for the packages field relatively easily, but not for the services
<irfus>yeah, services is where it gets hairy...I have a couple of package transforms in my config already, so I understand how that would work. But specifying the mesa for the xorg-server-configuration, I don't know how to do that
<roptat>I think you need to replace the display manager and your desktop manager if you have one
<irfus>so the only way aroun d this would be to update the scheme object 'mesa' in the original guix module where it is declared?
<apteryx>nckx: thanks for the info (httpd); no I hadn't found it for some reason
<irfus>since the updated package definition was relatively easy to define, I wonder why this hasn't already been added to guix. Is it simply low priority, which makes perfect sense, or is there another blocker that I am not aware of (that will painfully come to the fore if I attempt the rebuild :D)
<roptat>guix refresh -l mesa says there are 2368 dependents, so that's core-updates material
<roptat>although, it's not updated to mesa 21 on core-updates either
<irfus>core-updates is a branch on the source repo?
<roptat>usually this means nobody took the time to update it :)
<bone-baboon>If I get an error message that is prefix with "guix pull: error: Git error:" does that mean that guix pull is passing on a Git error it received from Git while it was trying to execute the guix pull command using libgit?
<tissevert>I hadn't yet matched your nick to the name I saw in the mailing list
<nckx>tissevert: Whence your nick actually comes, if you don't mind sharing?
<tissevert>not at all, I should've thought it was someone who at least partially understood french to translate the «-vert» ending (accurate translation as you'll see) it makes sense now
<tissevert>I needed a new nick four years ago, at the time I was very much into «Wynonna Earp» (a TV series about a family of Demon hunters very… a bit silly but I like it)
<djames>Is there a GNU Guix system available for powerpc64le? If not, is there a way to bootstrap such a system?
<tissevert>the character of the little sister, Waverly, had an interesting echo with my own life, and it was also the time when I started learning knitting and weaving
<tissevert>so a name centered around the idea of weaving became pretty obvious, and I thought «why not translate it into my native language, after all I love all languages and that includes frenche»
<tissevert>that got the «tisse-» part, and as for the «green», well it's always been my favourite color by far and I was indeed knitting and weaving a lot of green stuff (pretty much all of the yarn I bought at the time was green so… it was simply an objective description at the time «the one who weaves green stuff»)
<nckx>djames: I don't think you can boot Guix System on PPC64LE today, but nor have I tried. There's certainly no image. It might take some work, but doable work, and your help would be much appreciated. What we call the ‘bootstrap’ (with a working Guix package manager, toolchain, etc.) is done.
<tissevert>but for matters more relevant to this chan ^^' have you had a chance to look at my second patch ? I know I've been very long to answer and send my second version so I totally understand if you haven't, I just want to make sure you're not still waiting for something I'm unaware is missing
<tissevert>nckx: always my pleasure to spam honnest chans telling people about my uninteresting life :D
<mdevos>When running "guix import texlive babel-dutch": command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "51265" "svn://www.tug.org/texlive/tags/texlive-2019.3/Master/texmf-dist/source/latex/babel-dutch" "/tmp/guix-directory.8EghHU/svn" failed with signal 11. Can someone verify on their system?
<apteryx>linphone tells me it's delivering the messages: [13:48:11:827][Info]Core:linphone: Chat message 0x48bab20: moving from InProgress to Delivered
<davidl>nckx: to explain upstreams response reg. the xmllint patch (if I understand it correctly) - previously xmllint --xpath actually outputted multiple xpath results as a concatenated string which was totally useless, and at the time of the initial Pull Request by "Cyker Way" the default output separator would be changed to a newline and it was also modifying a very important function called xmlSaveTree(). This was later change by upstream so by now adding
<davidl>the --xpath0 option has no risk associated to it.
<raghavgururajan>apteryx: I got your messages as notofications, but not visible in the app.
<eriklovlie>n00b question: I want to invoke a program (from a build phase) and capture the standard output. Specifically it is "patchelf --print-interpreter". The "invoke" util returns a boolean. I didn't quite grok the "invoke/quiet" function but anyway it doesn't return the stdout. Do I need to resort to something like "open-output-pipe" or is there another
<cbaines>vagrantc, I guess that's sort of good it works in some situation, I wouldn't have expected armhf though
<vagrantc>i think the build path embedding issues were worked around in 1.3.0 (and a proper fix in core-updates), and you also have to build guix without parallelism ... i think those were the main blockers for reproducibility