<vldn>python doesn't have enough permission to create the bash completion things
<Noisytoot>Do you get substitutes from bordeaux by default?
<lfam>vldn: The only directory that the build process can write to in the store is the directory created by the build. This /gnu/store/...-bash-completion directory is already "done", and cannot be changed
<lfam>You'll need to adjust the build scripts of your package to put the completions in its own output directory
<lfam>Or maybe you'll have to patch the meson scripts
<lfam>Also, almost every other distro will have the same issue. So you could try googling your error message to see if anyone else reported it. Or check other distros package recipes if they have packaged 1.6.1
<futurile>Hi - I'm just getting started with guix. I'm trying to build a package locally from the source package defined in the guix repos. I did `guix build ed` and rather than build the package it used a substitution from the CI system. I need to remove the package from the store so I can retry building it. But, I can't figure out how to remove the package from the package store: if I try `guix remove ed` it
<futurile>correctly says I haven't installed it, I tried it with the path `guix remove /gnu/store/ah51j7kj9xk5r3xqp77n2d7hhmy82ms3-ed-1.16` but that errors. Is there a way to do this, or have I got a bad mental model?
<atuin>futurile: did you try with `--no-substitutes`?
<futurile>no - I figured I had to remove it before I tried again - I'll try that now
<futurile>--no-substitutes doesn't work - guess it's a 'complted build' so doesn't think it has to do it again. Ah --check ed works.
<futurile>OK, so how should I remove that 'derivation'? from the store? is 'guix gc' the only way?
<slyfox>you can also 'guix gc' the unused local fetched substitutions (might delete A Lot)
<slyfox>'guix gc' help says 'guix gc /store/path' might be a way to exict one entry safely
<moshy>thing with doing 'guix gc' alone, can break the system in some ways. ended up losing all my icecat addons, needing to delete .mozilla to fix
<atuin>is there a way to get the output from a derivation? I really would like to see what's doing the guix-translated-texinfo one
<atuin>What's the difference between `guix pull --commit=XXXX` and using time-machine?
<slyfox>looking at raw process tree might show it as well. for me perl uses 100% CPU on the following command: /bin/sh '/tmp/portage-tmpdir/portage/sys-apps/guix-9999/work/guix-9999/build-aux/missing' po4a-translate -M UTF-8 -L UTF-8 -k 0 -f texinfo -m "doc/guix.texi" -p "po/doc/guix-manual.es.po" -l "doc/guix.es.texi.tmp"
<atuin>I guess time-machine does not install the guix profile
<atuin>slyfox, yeah i have same (4 processes though)
<atuin>but it has been running for 40 mins :D Is not too much that?
<slyfox>i think that script is supposed to run for seconds, not hours
<ft>Though, gcc doesn't enable any warnings as errors by default. Not sure what linux-module-build-system enables.
<bost>Hi. Is there any `partial` function in Guile? For partial function application?
<ft>Functions in scheme aren't curried by default. Guile has the (ice-9 curried-definitions) module additionally, though.
<ft>That allows things like (define ((add a) b) (+ a b)).
<excalamus>How do I clean up a build? I'm trying to upgrade a package definition. I made the changes and ran guix build -K --file=myfile.scm. It completed and made an entry in the store. I've tried guix gc -D /gnu/store/snthntshsnth... but it says its not in the store. Is guix gc appropriate here? If so, how do I refernce the store item to remove?
<excalamus>Okay, looks like guix gc is what I need. My build won't delete because it's "live" (shows up in --list-live). Things in the store are live when they are reachable from a root. How do I find which root my build is under?
<excalamus>guix gc --list-roots just gives 134 symlinks
<excalamus>I see that the roots correspond to generations. I'm currently on gen 80. My build doesn't appear to be part of the generation; at least it doesn't appear in guix package --list-generations
<excalamus>Yeah checking out the link, to the generation, the bin doesn't contain my build
<slyfox>Yeah. i'm a bit worried that it does not translate well to 'guix environment' and './pre-inst-env ...' calls of the same. nix has '/etc/nix/nix.conf' and '~/.config/nix/nix.conf' for some of these.
<excalamus>roptat, there's a emacs command guix-store-item which can give information about store items. For better or worse, it has a button to delete. Even though it calls gc under the hood...it actually deleted the file I specified. I didn't expect it to work. I expect that it will cause me problems...
<leoprikler>well, if it just deleted the file, then it was probably fine to do so, no?
<excalamus>The info page says, "removing files or directories manually may break it beyond repair!"
<excalamus>I've saved all my shell output so I have a list of all the returns fro guix gc --references and guix gc --recursive. One way forward might be to use the guix-store-item command to remove each of these manually.
<excalamus>All this feels obtuse. But it's all I can find in the documentation
<excalamus>I assume there's some bookkeeping going on. So, yeah, since the guix-store-item-delete command (which the button) calls gc, that should be taken care of.
<apteryx>excalamus: why would you micro-manage your store items instead of letting 'guix gc' taking care of removing the cruft? that's what it's made for.
<excalamus>apteryx, great question. Because running guix gc --delete, the only option in the documentation I could find to remove items from the store, returned an error. I don't have the log output for the error
<excalamus>I deduced it was because the file was live. The file appeared in guix gc --list-live and the docs said --delete wouldn't work for those.
<excalamus>Really? The file I just deleted had appeared in the --list-live output. Wouldn't that mean it's live and wouldn't be gc'd? (assuming I hadn't deleted it)
<apteryx>so if you want to retrieve as much disk space as possible, what is recommended is to first delete the generations of both your user and system profiles (e.g. 'guix package --delete-generations' and 'sudo guix system delete-generations' and then run 'guix gc'
<apteryx>guix gc -d or --delete shouldn't delete live things; if it did, that's a bug
<apteryx>are you sure it was live? are you sure it's gone?
<excalamus>For posterity, it looks like I was able to clean up my store by clearing out previous system profiles and package generations. I think it was apteryx who suggested this. Thanks!
<GNUtoo>btw, I've things like that: "Unbound variable: %current-target-system", when trying to disable tests of a package with #:tests? (let ((system (or (%current-target-system) (%current-system)))) (string-prefix? "x86_64-linux" system))
<GNUtoo>I've asked here the other day and I was told that I needed to do something special to those variables