<radio>I am dealing with some problems with the fish shell in guix. The first one is that files on the /gnu/store/<hash-here>-fish-foreign-env/share/fish/functions aren't being sourced by fish by default (IDK if it should, tho, in either case, it's not working) and was asking myselt the proper way to make fenv always avaiable within fish in a declarative way (I'm using guix home)
<radio>It's also possibly related to fish: When I open emacs outside a guix shell, I'm currently unable to execute any command, even M-x gives me the same error message: "Symbol value as variable is void: /bin/sh"
<dcunit3d>hey i'm getting an error about license:arphic-1999 for quite a few guix commands on my system. i've checked the code used for `guix pull` in both system/user current profiles, but it has that declared in there.
<andreas-e>janneke: Recently I learnt about the observer effect (in the Guix context, a package test failure) when doing floating point in C. Just printing a double variable can change its value, because it may be moved from a register to main memory, and since they have different size, may be round in the process.
<andreas-e>A Heisenbug, nice term. It could be considered a compiler bug, because it is not compatible with a programming language semantics (assuming C has one). But it is difficult to fix, since one also wants to be efficient and use CPU registers with their available instructions :)
<nikolar>Well the value depends on if it was observed or not, so definitely an appropriate term :)
<mirai>in essence, a XML catalog helper within guix search (or perhaps it can be made even more useful by providing something like (inputs (list … (catalog-resolution #:publicId "-//OASIS//DTD DocBook XML V4.2//EN")))
<ulfvonbe`>and copy said file from the store to there before the check phase
<Guest96>Now thats the clever hacky hack I like to see!!
<Guest96>Oh wow, that's a large file. Getting checks to work has involved a lot of downloading models files which don't end up in the final build. Is there a point at which it is "not worth it"? I don't know if these inline origin references will end up in the substitute server or not.
<ulfvonbe`>if xfig has documentation links built in to the program itself, maybe it should just be one output... how big is the doc output?
<Guest96>You could probably do something sneaky like "export GUIX_LOCPATH=$(guix build glibc-locales)/lib/locale", but probably it would be fixed by adding glibc-locales to the packages list in your guix system config
<nikolar>i am kind of on a shitty wifi at the moment so i'll just use the hack until i can reconfigure :)
<nikolar>well guess i should read through the whole thing
<Guest96>looking at it now, it does seem a little opaque. That section is for installing the package manager on a foreign distro, and your situation is a genuine guix system install. In general, if you want things to "just work", you should use %desktop-services over %base-services.
<aarcov>Does anyone know how to tell guix to build a cmake project where the source is in a subfolder in a git repo? aka, to build from within a `build` folder, I use `cmake ../src` instead of `cmake ..`
<aarcov>(this is for the cmake-build-system in a package definition)
<mwette>ekaitz: thanks -- I ordered a VisionFive2 starter boxv
<efraim>vagrantc, mwette: there's a system definition for the hifive unmatched which I'm running on my machine. I have a visionfive and visionfive2 but no image for either yet
<Guest96>I have a module with checks that succeed on everything BUT the tests related to exporting. The exporting tests utilize several backends, each of which is orders of magnitude larger/more complex than the module itself. The module is still very useful without those export backends (I personally don't use any of them).
<Guest96>Is it ok to package the module without the backends for now? If so, should I disable tests, or try to patch the tests to exclude testing those backends?
<Guest96>Alright, I know I've seen some instance where the source code for a package needed to be modified for guix. Where can I find documentation on how to do this?
<Guest96>Groumf Haha, that sounds like the right move as far as personal development goes, but docs are important to new users, so probably something about source patches should be added in the future.
<Groumf>Guest96 I would be willing to help on that front. I am not sure how. But I am pretty sure there are some teachings to be shared from my little guix journey in packaging the stuff I need. Sadly I'm not a lisper. I mostly chose guix bc it comes from GNU and is not implemented in C++. But I wouldn't call that a positive choice.
<Groumf>Guest96 Honnestly I have rarely seen a codebase that is so clean (build tools are usually very complex and obtuse). Paradoxicaly, it may be partly because it's in lisp.
<nikolar>well scheme macros let you do a bunch of neat things
<Groumf>I would go as far as saying that the code is the doc is not a joke for guix. Well, non-coder won't like it. Tbh, I don't think there are many people who don't code using guix. Using guix *is* coding.
<nikolar>can you have /gnu on a different partition/fs
<Guest96>Groumf, for now, using guix is coding, but I think that once it matures, that it will be able to support computer novices. I think it genuinely has such a superior design philosophy that it will win out.
<Groumf>Well, building a comunity is hard. nix is full of haskellers. I am sure the average guix user is your typical emacs user who love lisp.
<Groumf>I feel a bit like an oddball in here. OCaml/Erlang dev using vim :D
<Groumf>At the end of the day, I think GNU provides some sort of *comprehensive user experience*. It's fine. It's great actually. But it doesn't necessarily promote diversity.