<lispmacs[work]>I was wondering though if there was some trick to restart all the services after an upgrade, since guix doesn't tell you which ones need to be restarted after a reconfigure.
<dissoc>when developing packages i use --install-from-file and push it to a channel when done. what about testing services? it would get annoying pushing changes to a channel every time to test it out. is there a better way to try it locally?
<mbakke>dissoc: there is a handy './pre-inst-env' script in the guix source that you can prefix any guix command with to run it from the checkout, i.e. './pre-inst-env guix install foo'.
<mbakke>see "Running Guix before it is installed" in the manual
<mbakke>dissoc: for system services, the best way to test them is to write a "system test" though :-)
<mbakke>look into gnu/tests for examples, and you can run a test with "make check-system TESTS=my-test"
<dissoc>mbakke: thanks. i didnt know about the tests. i will give that a try
<dissoc>the tests are really cool. i didnt think it would be that easy
<jackhill>Can I have both an openssh-service and an lsh-service? I guess I need to rename one of them to avoid the guix system: error: service 'ssh-daemon' provided more than once error
<gnutec>viaken: For now! Back to the 5.4 until Hurd ready.
<gnutec>viaken: If 5.6 come to guix before Hurd, I say here. :)))
<gnutec>Just see right now in TV that AMLO, president of México, is incompetent and let corruption take over. But Argentina with Alberto is doing a great job. :)
<manzerbredes>Hi, I am facing to something strange. When I run guix from tty (out of a terminal emulator) as a regular user (not root) everything works fine. However, if a try to run guix from a terminal emulator (I am on ArchLinux) I have the following error: /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: error while loading shared libraries: libX11.so.6: cannot open shared object file:
<manzerbredes>gnutec: I search again, but actually it was working fine since today. I do not which mistake I since despite doing some guix pull. I just tried to add libX11 to the LD_LIBRARY_PATH and it work now, but I never had to do this before...
***tim is now known as Guest71065
<gnutec>manzerbredes: "I never had to do this before..." This is wear but something like this happed to me. When I upgraded my icecat, the numbers gone. Then I ask here and told me that I haved to install "font-gnu-freefont". I use Guix System, installed by ISO guix-1.0.1 and I had to add environment variable like I was a user of other distro. We just need to pay atention, but guix always solve ours problems.
<efraim>sneek: later tell civodul I'll test the JamVM patches on aarch64 but I don't want to be responsible for breaking other architectures :)
<htgoebel>janneke: The package builds find when using e.g. git-fetch (as the ones around).
<htgoebel>janneke: And the importer is model like the one for git, bzr or hg.
***sneek_ is now known as sneek
<janneke>htgoebel: hmm, and guix build --source erlang-getopt works?
<htgoebel>janneke: No "guix build --source erlang-getopt" does not even try the fetch the source - which is the curious point on this.
<htgoebel>janneke: "guix build --source erlang-getopt" will create a .drv file as expected, but this file starts with "Derive(,…" (which I assume means: no outputs are defined).
<htgoebel>janneke: Contrary some .drv file for a package using "git-fetch" start with "Derive(["out","/gnu/strore/…", …"
<kenogo>Hey, I just installed GuixSD for the first time, and I have to build GNU Icecat myself. This may take a couple hours on my underpowered laptop. If I understood it correctly, this means that probably the build process failed or isn't done yet on CI, so I have to build it myself, right?
<bonz060>zimoun: Yeah that's what I was looking for. It'd be my first hackathon though. I've been using GUIX for about 3 months now and I really like the ecosystem(I want to work my way to hacking around hurd in it) \o/.
<bonz060>I also want to get people in my community interested in it, so I reckon the hackathon would help a bit
<zimoun>civodul: since you restarted the web interface, then "guix weather" works again; it was raising 504.
<mothacehe>janneke: hey! I'd like to proceed with the Hurd CI serie civodul has reviewed recently. The next step is maybe to make a Hurd image available on the website. Not sure how to make the instructions available on how to run it though. I wonder if a standalone "run-vm.sh" would be more appropriate.
<NieDzejkob>Noisytoot: weird. What if you try to run it in a `guix environment --pure`? You'll need to provide the full path to the binary...
<Noisytoot>NieDzejkob: It still fails/does not find libgcc_s.so.1.
<lfam>It will be easiest to debug by inspecting the full results of `env`
<aadcg>I'm trying to run some python code blocks in org-mode. My issue is that in Guix python is actually python3. I have set an alias in bashrc, but it didn't work. I also tried (setq python-shell-interpreter "python3") and didn't work. Maybe someone who uses literate programming in org-mode can give me an hint? Thanks.
<lfam>aadcg: You can use the python-wrapper package instead
<nckx>Well, I'm obviously biased, but I think mine's a lot cleaner… 😳 wigust: Did you include binutils deliberately? It's almost certainly a mistake, and the STRIP trouble below might have been self-induced because of it. It seems like you had a lot more trouble with paths in general than I did; I think --with-path=$PATH doesn't do what it should if it does anything at all.
<nckx>#:validate-runpath? #f is right out. By the number of problems you had to solve (and I never encountered) it seems like you made a wrong turn early on and got some very unhelpful error messages thrown at you.
<nckx>It's probably safe if you think it can be useful. I'll take a look at the Nix expression, but their quality bar is lower than ours (I'm allowed to say that because they gave me commit access, which is proof).
<rekado_>janneke: I really wanted to review the changes and test this all, but magic smoke has been escaping my brain for some days now; hard to focus
<NieDzejkob>jackhill: I only skimmed the thread so far, but I'm confused as to why you're specifying (outputs '("out")) explicitly
<jackhill>NieDzejkob: I think that's a side effect of my suggesting that one part of the software might make sense as another output, and the original submitter of the patch thinking about that, but deciding not to do it right now.
<jackhill>I missed that in the updated patch, good catch.
<jsoo>NieDzejkob: hey there. Do you think the features argument in the new cargo build system can just be specified by the cargo-build-flags argument?
<NieDzejkob>jsoo: This was discussed on the guix-patches thread. No, it can't, as the features must also be passed to cargo install, which doesn't accept the --release flag.
<jsoo>NieDzejkob: Ah I see. I did get one compile error recently when compiling alacritty. It seems that the --features flag is not supported on projects with workspaces. Can the features be omitted entirely when not specified?
<jsoo>I'm sorry I cant get the exact error message
***sneek_ is now known as sneek
<NieDzejkob>jsoo: anyway, I think it is reasonable to omit the features argument when an empty list is passed, these should be equivalent. Do note that the patch to the build system will have to land on staging, though
<jsoo>Ok sounds good. What issue number is the patch set?