<ulfvonbelow>Well that was a proper confusing debugging session. Apparently guix will assume that any string starting with "/gnu/store" in any expression is a reference to... something... in the store. That's confusing enough behavior, but it does it inconsistently: only when you splice a non-gexp expression containing said string into a gexp.
<ulfvonbelow>so if you're like me and happened to have an old local package around that uses plain old quoted forms and that contains `(format #t "/gnu/store top: ~%~a~%" (scandir "/gnu/store"))' in a phase, and now you're trying to apply a transformation to that that modifies the phases by wrapping them in a gexp, you'll get weird stuff like: guix build: error: path `/gnu/store top: ~%~a~%' is not in the store
<ulfvonbelow>are there any cases where we actually substitute an expanded gexp into another gexp?
<ngraves>Hi Guix ! Does someone know if there's a way to reload a guile load-path from within a guile script ?
<ngraves>Let's say the first half of a script changes the symlink to the load-path, how can I ensure the second half will use the right reloaded code ?
<rekado>ngraves: is there shared state between the two halves of the script?
<ngraves>rekado: I don't really use any state in this script. The symlinks I talk about point to the store though, but since we want to reload them, it isn't state.
<andreas-e>ngraves: Since you are around, what is your stance on moving to a more recent scilab? Would you still need the 5 version, or would switching to 6 be okay?
<sneek>Welcome back andreas-e, you have 1 message!
<sneek>andreas-e, rekado says: email@example.com is used by the old java-cisd-jhdf5, which is an input to fastqc. I don’t know if it’s possible to upgrade it, because there’s no newer version of java-cisd-jhdf5.
<jpoiret>ngraves: not sure how that would work esp. if you have things that depend on definitions in the module you're trying to replace
<ngraves>andreas-e: I can always freeze a manifest, so I don't really care. The program I use with scilab is not really easy to move to scilab 6 though. And there might be substantial compilation / package definition changes with scilab 6. Go ahead if you want ;)
<andreas-e>rekado: This is unfortunate, but thanks for the analysis! There is a newer version of fastqc, but I suppose it will also need the older Java library. I did not find anything to convince me of the contrary in the changelog.
<ngraves>jpoiret: What about delayed evaluation? Is there any chance it might work?
<andreas-e>ngraves: Okay, this does not provide a lot of motivation! I am indeed afraid it would be a major hassle to upgrade the package definition. Some of my motivation is that it is one of the few dependents of firstname.lastname@example.org.
<ngraves>andreas-e: IIRC, the major change for compilation is that they moved away from fortran and included more CPP. I remember having tried quickly but unsucessfully, don't remember where I got stuck. But that was a long time ago.
<dan>So, guys hi. guix hangs for me a lot at system at "guix system reconfigure" towards the last phases after updatng grub, and at "shutdown" where shepher prolly hangs and no shutdown ever happens
<dan>are there any videos showing how to debug issues in guix and how to set up some introspection into the system ?
<dan>and maybe videos showing the data flow in a system from package spec to derivation to build artefacts ?
<dcunit3d>how do i uninstall a package in the ~/.guix-profile ?
<dcunit3d>on arch, it's also installed guix/guile to this profile, so my load path is not quite correct inside emacs. i don't actually load this profile on arch, but i think something it /etc/profile.d from the guix-installer package on arch is doing it.
<apteryx>lechner: looks like it could be related, yes!
<apteryx>are the system tests broken the same way for others?
<dcunit3d>working across both arch and guix system has been very confusing, esp since the geiser/guile repl requires different set up for each system. i took doom emacs out of the mix (which uses straight to download guix.el, which causes issues with where your guile deps come from)
<dcunit3d>woops. let me try that. i've been focusing on a lot of other things recently, but i'm trying to resolve this geiser/guile load path stuff once and for all, so i can build packages/systems/profiles in the repl.
<dcunit3d>i just worry about lib64 problems. i looked into those as well, trying to get an appimage to run. it's close. the easiest ways around the lib64 issues are docker/vm's
<apteryx>dcunit3d: Geiser load-path should be preconfigured out of the box if you accept the .dir-locals.el content
<dcunit3d>i just occasionally need to run software like that. that's the only major issue. also, i have a great AMD gpu and i worry about not being able to run machine learning.
<dcunit3d>apteryx: i've been looking into that, but i source other channels as well (sorry if this is bordering on discussion of non-free software)
<apteryx>it's fine to source many channels; we need not know what's in them
<dcunit3d>my ~/.config/guix/current/etc/profile doesn't modify GUILE_LOAD_PATH/etc, which contains the *.go files for my channel list
<dcunit3d>i have a git-repo XML that allows me to grab all the channels at once, so I could modify the .dir-locals.el to add them to the load path. AFAIK, after building my guix checkout, then running code in geiser would simply build them when needed.
<dcunit3d>i was considering that as an alternative workflow, esp since I would like to contribute where I can. I enjoy learning about new build systems.
<dcunit3d>that set of paths for the git-repo would maybe be the easiest way to have consistent paths across all my systems. one potential issue is that the guix checkout build isn't necessarily updated when I update my system.
<apteryx>nckx: hello! had you had any luck in fixing the system test failures? did you dump the state of things of your investigation somewhere I could read?
<dcunit3d>i also may have customized the arch /etc/profile.d because it doesn't have the content in guix-install.sh
<lechner>Hi, would someone please run guix shell -f guix.scm on this file and tell me if your $GUIX_ENVIRONMENT/share/guile/site/3.0/bespoke/make.scm refers to b3sum by an absolute path? This command will tell grep b3sum $GUIX_ENVIRONMENT/share/guile/site/3.0/bespoke/make.scm
<andreas-e>lechner: I thought of "guix gc --verify=repair", but maybe this has nothing to do with your problem. I just wondered because of the missing file.
<lechner>how can removing a stale build artifact break my store?
<andreas-e>I do not use guix home and am afraid I will not be of much further help.
<lechner>actually, i just want to tell ludo about bespoke. could you please run that guix shell command one more time, and then cd examples/hello as well as ./make -d 3 ? Please note the ./ before make
<andreas-e>lechner: Actually it could be that your setup breaks "guix shell". I think these links (there are many actually) from/var/guix/gcroots/auto to $HOME/.cache/guix/profiles/... may be cached "guix shell"s. This is what makes the command fast the second time.
<lechner>andreas-e / thanks, i was just looking at that. you explained a lot!
<lechner>not sure why this crowd would think it would be reasonable to grant root read permissions to $HOME :)
<andreas-e>lechner: So I think your "guix gc" removed items in /gnu/store to which your profiles in $HOME/.cache/guix/profiles/ point, making them invalid.
<graywolf>attila_lendvai: Hm, so if I want to have the ability to "clean up" after a one shot service, I need to *not* use one-shot, and instead have regular service who's command will basically be one-shot + sleep inf?
<lechner>graywolf / that does not sound like a one-shot
<attila_lendvai>graywolf, why don't you put the cleanup at the end of the start gexp?