<bumble>I'm probably the right person to answer but essentially guix is only write files by default that are needed by guix... if guix home is writing files that is because your guix home configuration specifies, in some way, that those files should be written
<bumble>if you didn't specify any xdg or home configuration and did not specify any bash or profile vars or anything like that, guix home won't write anything in your home space
<bumble>the situation where, for example, it would write a ./config/emacs/init.el would occur because you have explicitly defined an init.el for your home config and have added the directives to your home config file that would explicitly copy that file into ~/.config/emacs/init.el
<oriansj>guix really should allow package name spaces and enable the users to decide on the names they wish to use
<oriansj>so that when one does: (cons (channel (name 'variant-packages) (url "https://example.org/variant-packages.git")) %default-channels); they would be able to use any names they want for any packages and they could be referenced like variant-packages:foo
<adanska>why does doing 'guix build --check=2 --no-substitutes --no-grafts icedove' do nothing but return a path to a build in the store?
<efraim>futurile: seeing that all of librespot is in github.com/librespot-org/librespot, and assumably developed together, would it make sense to just package "librespot" as one package and use the workspace as one package?
<adanska>it doesnt even look like its attempting anything
<rekado>adanska: because it has already been built
<futurile>efraim: hah - never thought of that - as the importer split them up. They are really 'one thing'. Do you care that some parts are buildable from source (e.g. core/connect), but due to the jack issue 'playback' won't be - as one package would all of it have to skip source building?
<futurile>efraim: also is there an example package that does this
<efraim>I only realized now when looking at why it may not build. You might have to choose a specific backend(s) for playback so we can test it out
<adanska>ok, i deleted my .thunderbird file and it seemed to fix things. it didnt get rid of the warnings about libpci though, but maybe that was a red herring
<efraim>20 hours to build rust-1.73 on aarch64-linux
<fnat>if i want to be able to guix pull from within the vm, i imagine i should simply build the image and launch it directly with qemu, instead of using the "guix system vm" script?
<fnat>i hoped there could be a way to make use of the host's store while being able to install additional packages (from the guest system) - but that's probably a naive expectation?
<efraim>fnat: perhaps something with the --volatile flag would help?
<efraim>futurile: I see what you mean about the conflicting demands on the jack library
<fnat>uh, that looks promising, let me try that - thanks efraim
<fnat>volatile seems to be the default for "guix system vm", or was it meant as an option for "guix system image" instead?
<fnat>i'd tried "guix system vm --persistent config.scm" already - which also complained about the store being on a read-only fs
<futurile>efraim: we don't have the option of ignoring optional crates with the cargo-build-system right? The only other 'mad' thing I could think of is does it work if we alter the Cargo.toml so Guix's build doesn't receive the optional dependency?
<efraim>futurile: Right now I'm playing with a snippet to have cpal-0.13 accept other versions of jack
<nmeum>I would like to upgrade unicorn to 2.0.1 and I noticed there is already an open issue from may which hasn't received any attention https://issues.guix.gnu.org/63442 the patch changes the unicorn package quite a bit and only ships the python files, is that why it hasn't received any attention? what would be my best course of action to get the package upgrade applied? should I send an
<nmeum>also: presently unicorn fails to build because the tests don't pass, with the patch referenced above it builds again
<futurile>nmeum: did you check whether a team looks after that package (using teams.scm) - and did you cc them onto the patch when you sent it?
<nmeum>it's not my patch, I was just looking for the issue tracker if someone else already send in an upgrade
<futurile>nmeum: if there's no replies or conversation on it - then it might be that no-one saw it. You could try building it, bumping the conversation and making sure that the Python team is aware of it etc
<futurile>nmeum: hmm it was probably in the middle of the massive thread about cognitive overhead for contribution. Anyway, I think the substance was that testing that a patch actually works (not just that it builds) is helpful. And there's kind of a checklist on the qa.guix.gnu.org
<stevenroose>IIRC last time I reconfigured I tried to restart the service, but I'm not sure I actually managed to do that (right now I can't find any services using shepherd for synthing anyway)
<jpoiret>phf: no, unless you also pass the source as an input
<phf>jpoiret: if the execution reaches a `lower' function in `(guix build-system mix)', then we have access to the `inputs' of the package being compiled. If `pkg' is an element of `input', then is it possible to get the source of `pkg' here?
<vivien>Splitting a commit is not very fun. How do you do it? What I do is consider the base commit, revert⁰. I revert it, then revert the revert. I then rebase the revert¹ and revert² on top of revert⁰. Then, I edit the revert¹, stage the changes of revert², discard some, continue; fix the conflict in revert², finish the rebase. Then, I reword revert². Then, I fixup revert¹ on top of revert⁰. Then, I reword revert⁰. Pfew.
<jpoiret>in the build expression or outside of it?
<phf>When execution reaches the `install-dependencies' phase of the build side procedure called `mix-build', I need to have access the the source of each Erlang and Elixir dependencies in order to convince `rebar3' to not access the network.
<jpoiret>yes, then there you don't have access to the sources of the inputs, you need to also pass them as inputs
<futurile>vivien: 'as a hobbyest' I find git very hard - been using StackedGit which deals with everything as patches on top of git. It's quite nice - and git is underneath so you can fallback to git if needed.
<phf>sneek: later tell jpoiret How to go from `#<gexp-input native #<origin "https://repo.hex.pm/tarballs/samovar-1.0.2.tar" #<content-hash sha256:1nfw5vbzcvqzpsahwxz7zjlshg31pa9f306g3hzm1kfx5rsyvry4> () 7f9c3ee0c900>:out>' to `/gnu/store/pgw9...-samovar-1.0.2.tar'
<phf>sneek: later tell civodul How to go from `#<gexp-input native #<origin "https://repo.hex.pm/tarballs/samovar-1.0.2.tar" #<content-hash sha256:1nfw5vbzcvqzpsahwxz7zjlshg31pa9f306g3hzm1kfx5rsyvry4> () 7f9c3ee0c900>:out>' to `/gnu/store/pgw9...-samovar-1.0.2.tar'
<phf>mirai: « Within a gexp it's just #$… ». `/gnu/store/pgw9...-samovar-1.0.2.tar' is needed just before the `build' phase. jpoiret suggested to pass the sources client side. So, in the client side rebar-build function in this case.
<VesselWave>Hey, Guix! Does anybody know how to make a system Shepherd service to auto-start something? Or maybe someone successfully made bitcoind a user-level Shepherd service?
<mirai>when you add a service to (services …) it already autostarts
<redacted>I've configured my nginx service in scheme. If I wanted to modify the nginx configuration file from another service (such as in a hook, or in a mcron script), how might I go about doing that?
<redacted>An nginx configuration is a data type, so perhaps it's possible to modify that data type and write it to disk?
<ohyllad>If i have two processes running in their respective guix shell --containers, is there a way to allow one to connect over http to the other?
<nckhexen>vivien: That is... 2 levels of metapatching? And I thought I was pushing git commit -p, 'e' to the limits of sanity (and diff validity) o_O
<lechner>Hi, as an eshell user i'm often startled to find myself in Bash after a 'guix shell'. Is there a way to select the shell (perhaps an 'emacs-client' with an shell?) What does 'guix environment' do? Thanks!
<lechner>sorry, i meant something like emacsclient -e "(eshell)"
<lilyp>lechner: guix shell respects your $SHELL environment variable – eshell just doesn't set it
<lilyp>imho guix-eshell might be a feature for emacs-guix
<vivien>nckhexen, I don’t want to add anything in the process, because I could forget to redo a change. With my technique, I only discard changes. The worst that could happen is a change ends up in the wrong side of the split.
<vivien>I’m sure it is possible to achieve the same thing with less steps though.
<nckhexen>Yeah, but yours has better checkpointing.
<vivien>lilyp, I can build webkitgtk and gstreamer on my end (x86_64) with the glib.scm updates. We will see if QA can too.