<az`>guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/ij9ccdz9igw2j2x2n18allscc6zakwk0-slim-1.3.6.tar.xz.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<ngz>Hmmm there is a problem with the Scribus package I updated recently. With "guix environment --pure --ad-hoc scribus -- scribus" the software runs flawlessly. However in a "regular" environment (foreign distribution), the software spits out an error about Python. It sounds like it picks up the wrong Python.
<ngz>I tried to wrap PYTHONPATH around the program, without success.
<ngz>civodul: For example, I get lines similar to stat("/gnu/store/snk1lslg3ykmxmf2qjf13x59d6krpkv1-python-2.7.13/lib/python2.7/site-packages/_sysconfigdata_nd", 0x7fff10fb42d0) = -1 ENOENT (No such file or directory). Then it seems to fallback to "/usr/lib/python2.7/..."
<Steap>civodul: yeah, it may not be included in our Python package for some reason
<Apteryx_>civodul: I invested some time (more than I'm willing to admit ;) in customizing that debbugs-gnu-apply-patch function. The only reason the original function fails is because it tries to expand a lisp subdirectory in the compile command... So at first I made an advice to disable compile for that function. It works but I wasn't entirely satisfied so I customized it.
<Apteryx_>It automates some things such as: 1) apply any patch(es) from a message, whether they come as attachments or in the body. 2) Clean up the debbugs metadata from the subject line. 3) run make in a ./pre-inst-guix guix environment. 4) Shows the compilation buffer & magit.
<lfam>Assuming it was not previously referenced...
<lfam>This could protect us from accidentally introducing a reference later on
<bavier>oh right, duh, in 'guix environment --container' the test links against our firstname.lastname@example.org, but outside it links to the system's email@example.com, and IIRC one of the issues is with firstname.lastname@example.org's rw lock algorithm
<lfam>I'm still digging into it, but doing a simple test case with a file that exports FOO=bar shows that it seems to be accurate
<lfam>I realized that on a foreign distro machine where everything works, I was not using the example from the manual, but instead doing GUIX_PROFILE=$HOME/.guix-profile . $HOME/.guix-profile/etc/profile
<lfam>So, perhaps I noticed this long ago and worked around it
<lfam>I like the reporter's suggestion to simply not define $GUIX_PROFILE
<civodul>lfam: if we don't define it, then we get /gnu/store/...-profile
<civodul>that's no good, because when you change your profile, then all your env vars become outdated
<ng0>bavier: yeah :) my realistic correction for Guix through GNUnet is 'somewhere between now and post-master studies depending on the sun, moon and advanced witchcraft and it takes just time and reading and lots of debugging and learning'
<civodul>rekado_, ng0: great stuff here! (re mumi.png)
<lfam>In 'Invoking guix package' we offer a different command that does work
<ng0>I'm not so sure what's good about debbugs. The code doesn't seem that big. Is it still maintained, even if just a few minor corrections and features updates once in a while, or legacy maintenance? Maybe rewriting it in some other language and adding features if we really rely on it longterm would be good. Okay, we use the GNU hosted one, but just wild associations..
<ng0>even the installation on debian is not that complicated or feature-complete
<ng0>"here, have some files, now configure the stuff in /etc/debbugs/ and configure again"
<rekado_>what’s good about debbugs is that it works
<reed_>Hi all, I wasn't sure if I should ask this in #guix or #guile, but when I install a guile module on guixsd with "guix package -i ..." how do I tell guile where to look for that module when I want to use it?
<jlicht>reed_: "guix package -i" should (on foreign distro's at least) print some GUILE_LOAD_PATH or something similar on completion
<reed_>jlicht: even if I'm using GuixSD and not a foreign distro?
<jlicht>reed_: I am not sure in that case. It all depends on if your "guix package -i"-invocation mentioned anything about the GUILE_LOAD_PATH (or GUILE_LOAD_COMPILED_PATH).
<reed_>jlicht: I think I may have figured out the problem. The module I'm trying to use is in the guile-2.0 folder in the profile but I have both guile 2.2 and 2.0 installed. When I run guile, do you know how to tell it which version to use?
<jlicht>afaik, if you just run `guile' from your PATH, it should be one or the other
<jlicht>if you want to change this, you could do something like `guix environment --ad-hoc email@example.com' or with 2.0 replaced by 2.2
<jlicht>guix environment does not alter your profile though, so if you want to work with a specific version most of the time it makes sense to just `guix package -i guile@<your-version>' that instead