IRC channel logs


back to list of logs

<ray__>Sorry, I got distracted. If you're still here, here's the diff from the git repo:
<ray__>It's kind of a MWE
<pmikkelsen>hi guix
<ray__>When I make some changes in my clone of the git repo and run ./pre-inst-env guix ... it starts compiling gcc. Why? How can I avoid this? It'll take too long.
<pkill9>where is pre-inst-env?
<ray__>at the root of the cloned git repo
<pkill9>i don't see it here
<ray__>It's created once I run ./bootstrap; ./configure; make
<ray__>I guess I'll let it go. It should only happen once, anyway
<very>I have a GuixSD machine without an internet connection. My other machines don't have Guix.
<very>What's the recommended way to download a package and install it in a setup like this?
<apteryx`>very: it should be possible to download the binary archives from an official server, say,, and install them using guix archive --import some-package.nar
<very>I'll try that. I appreciate your help, apteryx`.
<apteryx`>I've never attempted this and I doubt it'll be fun to hunt manually all the dependency; I'd recommend installing guix on one of your network enabled machine and do a 'guix archive --export some-package'
<apteryx`>(and pipe the output to some .nar file)
<very>I would, but my other machines are very outdated and can't install anything right now.
<apteryx`>OK :/
<apteryx`>would be cool to have an fdroidserver service in GuixSD :)
<very>I don't think the package I was looking for is actually part of Guix yet.
<very>I'll need to try later; thanks again, apteryx`.
<EuAndreh[m]>Other than increased disk space usage, what are the downsides of including different versions of the same package as Guix does?
<efraim>Haven't touched it im forever though
<snape>EuAndreh[m]: a downside is: more maintainance to do
<janneke>yay, i finally found who's adding a qt-dependency: it's alsa-service-type and colord
<jahb>Hi guix. this happens when trying to upgrade duplicity on a foreign distro is it a bug?
<brendyn>jahb: I haven't been able to build it for ages either. It's been broken
<brendyn>I'll have a look at fixing it
<jahb>brendyn: thank you and good luck! it seems like a very complicated problem to me :|
<brendyn>I'm trying to build it now, hopefully my error message isn't any different
<jahb>yes that would be annoying
<brendyn>jahb: oh right, my error is about GPG
<jahb>oh. is it a similar "failed to map segment from shared object" error?
<brendyn>Completely different
<ng0>is this sneek's source?
<jahb>yes, you seem to get all the way to the testing phase.
<ng0>actually, no this is a bobot++ in C++
<brendyn>jahb: Yeah, my rsync bit built fine
<jahb>brendyn: you're seeing something that's been reported already:
<ng0>aha, found it
<jahb>brendyn: i'd like to try removing and installing duplicity to see if that makes a difference, but I need my presently-working install. I suppose I could roll-back the removal could I?
<jahb>ng0: where did you find sneek's source?
<brendyn>jahb: It shouldn't make any difference since packages are build in an isolated environment
<brendyn>is your guix up to date?
<jahb>brendyn: yup
<brendyn>the guix-daemon also?
<brendyn>welp i haven't the slightest clue then
<jahb>brendyn: oh now i feel silly. /tmp was mounted noexec. the build is in the testing phase now...
<jahb>ng0: nice. no commits for 8 years. can that be right?
<ng0>it's an irc bot
<brendyn>jahb: let me know if it breaks at GPG
<ng0>there's an actively developed irc bot in C from around 199whatever which only gets updates due to being in C and getting new features I think
<ng0>(talking about a different bot)
<jahb>brendyn: will do.
<jahb>ng0: sneek must be very stable then!
<ng0>but maybe the current sneek runs from a different source
<jahb>brendyn: yes it fails at the same place test_sigchain_fileobj
<brendyn>jahb: I don't know how to fix it :(
<jahb>brendyn: it looks like an issue upstream and when using GnuPG >= 2.2.8
<jahb>brendyn: i'm not sure how to find out what version of gpg is actually being used though
<jahb>brendyn: Ah good find. Bug reported at
<jahb>brendyn: we don't yet have a way to say --ignore-failed-tests do we?
<brendyn>perhaps there is already a patch in the repo we can steal
<jahb>brendyn: i don't see a patch
<brendyn>jahb: So is it something unimportant that can be ignored?
<jahb>brendyn: i think it can be ignored by virtue of it being a change in gpg - being more strict - and not a bug per se. but clearly the upstream test does need to fixed at some point.
<brendyn>jahb: I just want to be careful messing with GPG related things, since peoples security depend on it.
<jahb>brendyn: understood. i don't think we need worry about "test breaks because gpg is more strict".
<brendyn>It'd be good if we can patch just this one test, rather than disabling all of them
<jahb>brendyn: it's not clear to me how these tests work though. perhaps not running that test is an option.
<brendyn>python packages have a that handles it all
<brendyn>hmm it uses tox
<jahb>brendyn: what about annotating the test method with @pytest.mark.skip(reason="see bug ...")
<taylan>is there a way to list the authorized substitute urls? (i.e. what was added with 'guix archive --authorize < foo')
<brendyn>or add --ignore-mdc-error somewhere
<taylan>hmm, the urls aren't part of the key file so I guess the information is not available
<james-d-lisper>Hi guys, probably a rookie mistake but I have just done a "guix pull" on my machine, and now "guix system" does not seem to work, when I run "guix system <command>", I get told that "guix: system: command not found". Does anyone know where I went wrong?
<james-d-lisper>for example "guix system reconfigure" gives the same output: "guix: system: command not found"
<brendyn>james-d-lisper: This is a common problem. I forget the solution, I think you may have to run guix pull again
<james-d-lisper>Ok thanks! I have done so once already, but i'll try again.
<brendyn>james-d-lisper: I think since there are significant changes that have been made do guix pull, it needs to be run twice to work fully just this once
<james-d-lisper>Ok no worries, thanks for the quick reply :)
<james-d-lisper>Unfortunatly the problem persists. "guix pull" is now telling me that there is "nothing to be done" after multiple runs and multiple reboots. I am at a loss. should I reinstall from live-usb?
<rekado_>james-d-lisper: are you using the new Guix that has been placed in ~/.config/guix/current/bin?
<rekado_>reinstall is rarely ever a good idea.
<brendyn>james-d-lisper: make sure you dont have guix installed in your profile
<james-d-lisper>Ok thanks! using guix from ~/.config/guix/current/bin looks like it's working!
<znavko>Hello! How to see list of started services in shepherd?
<rekado_>znavko: sudo herd status
<rekado_>james-d-lisper: excellent! “guix pull” does end with a note that asks you to add that directory to the beginning of PATH, but it’s easy to miss this as it prints so many other things that are not of interest.
<james-d-lisper>Yes, and i thought i had done what it said there, but i probably messed that up. any way all is well now, Thankyou :D
<znavko>thanks. I aim to disable NetworkManager and use wpa_supplicant. But have problems. I do not know how disable nmtui that I have connected with.
<wigust->znavko: nmtui is not a service to disable it
<wigust->znavko: if you want to disable network-manager then you probably want to do it by changing %desktop-services in your system configuration ‘config.scm’. Otherwise network-manager will spawn after reboot. Also nmtui will not be available after removing network-manager from services in config.scm
<pkill9>i'm not sure, but you may just be able to run `sudo herd disable network-manager` to disable it
<EuAndreh[m]>snape: more maintenance for packages? Why is that?
<brendyn>EuAndreh[m]: it means you have to keep multiple package definitions in guix and make sure they all work.
<EuAndreh[m]>brendyn: makes sense, thx
<brendyn>EuAndreh[m]: It's perfectly possible though. I hope it will become more commonplace once guix channels exist
<pkill9>brendyn, EuAndreh[m]: what is more maintenance for packages?
<brendyn>pkill9: EuAndreh[m] asked about including multiple versions of packages in guix
<pkill9>what are guix channels?
<pkill9>like stable/testing/development?
<znavko>How disable networkmanager changing %desktop-services ?
<brendyn>pkill9: I use it to talk about some kind of repository feauture that I hope guix will get. the term channel comes from
<pkill9>atleast guix pull has rollbacks now
<EuAndreh[m]>Why do package managers (like Maven, Gradle, etc.) try to choose a dependency version instead of picking both and not choosing anything?
<ray__>I've been working on this same damn issue for a few days now. Here's a paste of the diff of the code I'm trying:
<ray__>The error I get is ERROR: In procedure %resolve-variable:
<ray__>Unbound variable: test
<ray__>builder for `/gnu/store/y53grsnh3bm0n9jpyqx3xh9wx5hii01r-xmonad-0.13.drv' failed with exit code 1
<ray__>Thank you very much for your help
<ray__>the command I'm running is ./pre-inst-env guix build xmonad
<brendyn>ray__: + (test '())
<brendyn>seems there that is not defined?
<ray__>Yeah that's the line I expect to work
<ray__>I use-module guix build profiles at the top
<ray__>so I thought it'd import that procedure?
<brendyn>I don't see any procedure defined test in there
<snape>the problem is that you're using 'test' in the build environment
<brendyn>and importing modules at the top will not make modules available inside the build environment
<snape>in that environment, the modules exporting 'test' isn't used
<ray__>oh so how can I get it into the build environment?
<snape>I'm trying to find an example
<brendyn>ray__: if you scroll down to evilwm you will see an example
<ray__>ah I just import it right there
<snape>usually people need (guix build utils)
<ray__>I added ERROR: In procedure %resolve-variable:
<ray__>Unbound variable: test
<ray__>builder for `/gnu/store/y53grsnh3bm0n9jpyqx3xh9wx5hii01r-xmonad-0.13.drv' failed with exit code 1
<ray__>I added #:modules ((guix build profiles))
<ray__>to arguments
<ray__>but now I get as an error
<ray__>ERROR: In procedure scm-error:
<ray__>no code for module (guix build profiles)
<snape>is it in the top of the file as well?
<snape>well it's not necessary
<ray__>I thought not, but I kept it in just to be safe
<brendyn>does it require another use-modules?
<ray__>Does what?
<brendyn>like if you look at fatfsck/static
<brendyn>it has :modules ((guix build utils))
<brendyn>but after it also has (use-modules (guix build utils))
<ray__>Yeah I might end up needing that, but I think this error comes before it even parses my added phase
<ray__>the error triggers just by trying to add guix build profiles to the list of modules
<snape>I think it's because (guix build utils) is imported by the gnu build system
<snape>but guix build profiles isn't
<ray__>ok... is it a good idea to get guix build profiles imported by the build system?
<ray__>or should I try another approach?
<ray__>The full story here is that I'd like to have a procedure wrap-program-in-profile which takes a program and a profile and wraps the program a la wrap-program, but instead of specifying the paths manually, wraps the program in the profile
<ray__>So I wanted that procedure to go in guix build profiles
<ray__>Since that's where all of the profile information lives. It can't live in guix build utils I think, since guix build profiles imports guix build utils
<ray__>So there'd be a circular import issue
<snape>ray__: I don't really understand what you want to achieve
<ray__>Ok, the use case is that when I install xmonad, I can't run xmonad --recompile, since the environment isn't right
<ray__>But I can do guix environment xmonad; xmonad --recompile
<ray__>I'd like to have that happen automatically, by having the build system wrap the xmonad binary in a shell script which auto-loads the correct profile
<ray__>Maybe I should ask first: is this even a good idea? Is there a better way?
<snape>what is the environment issue?
<ray__>ghc, gcc, as, and XMonad itself are not in the environment
<ray__>I need ghc in the path, XMonad in the GHC_PACKAGES_PATH, and also LIBRARY_PATH set up to be whatever complicated mess it needs to be
<snape>hmm indeed they are not inputs of the xmonad package
<ray__>Yeah but even if they were, the xmonad binary wouldn't set up all the paths correctly
<ray__>I could certainly make it work via wrap-program, but I'd have to figure out all the paths to set up manually
<snape>but a wrap-program could help setup the environment well
<ray__>But I know that if I make a profile (like with guix enviroment xmonad), it sets up all the paths for me
<snape>yes, because it includes the native-inputs
<snape>the problem, if I understand well, is that you want some of the native inputs to be normal inputs as well
<ray__>But there aren't any native-inputs to xmonad?
<snape>they are implicit
<snape>because of the haskell build system
<ray__>ah yes. I don't think just adding them to inputs will fix anything, though, since the environment variables will be wrong when the xmonad binary is calle
<snape>I think you can fix them
<ray__>Via wrap-program?
<ray__>How can I know which ones I need to set up?
<snape>you analyse the error :)
<snape>I mean, it's a matter of understanding how xmonad works, you probably know better than me about it
<ray__>That seems doable I suppose. One other comment on guix while I'm here: right now if a user installs a compiler, e.g. gcc, although ghc has the same problem, it's unusable since the paths aren't set up
<ray__>so is it worthwhile to wrap gcc in a similar way to have LIBRARY_PATH automatically set up when it's run?
<ray__>Or is it a deliberate decision to have it not work out of the box?
<ray__>Actually, this is directly related, since I'm wondering whether it's better to wrap ghc, or to wrap xmonad
<snape>the package to install is gcc-toolchain
<snape>if you want to use gcc
<ray__>oh! Cool, that sounds like exactly what I was looking for
<snape>I don't know about ghc though
<ray__>I'll poke around and see if something like ghc-toolchain would be a good fit or not
<ray__>Thanks for your help
<ray__>Another problem :) I want GHC_PACKAGE_PATH to contain <xmonad>/lib/<ghc package name>-<ghc package version>/xmonad-0.13.conf.d
<ray__>And I'm having trouble getting access to ghc package name
<ray__>I'm trying (package-name ghc), but package-name is defined in guix packages
<ray__>and guix packages again gives me no code for module (guix packages)
<ray__>probably because it's "not in the build system"?
<ray__>So how can I fix this?
<snape>ray__: should xmonad-0.13.conf.d contain user config?
<ray__>No, it contains ghc package data (like /lib for C programs)
<ray__>or maybe a better analogy is how sometimes libraries are found in /lib/x86_64-gnu-linux-gcc-5.5.0 or something (I'm remembering the path off the top of my head, it might be wrong
<ray__>So the path to the library contains the compiler version, because it's compiled for a particular compiler version
<jahb>brendyn: a fix was committed upstream and will be in 0.7.18
<brendyn>jahb: did you talk to someone to get it in?
<jahb>brendyn: no just filed the report!
<brendyn>jahb: That's fantastic
<brendyn>very rapid response
<jahb>brendyn: isn't it!
<brendyn>although it was already mentioned on the mailing list, i guess you made someone notice it
<brendyn>I wonder how long it will be until the next release, should we steal the patch for now?
<jahb>brendyn: there's 5 out of 10 bugs outstanding for the release, four of which are in progress. I don't think it will be very long, but we could still steal the patch:
***jonsger1 is now known as jonsger