IRC channel logs


back to list of logs

<apteryx>I just installed Guix on a Debian 9 machine with the latest Bash installer script... nifty!
<rk4>there's a bash installer script?
<lsl881>verisimilitude: i will try, thank you :)
<apteryx>rk4: yes! see the link under section 2.1 here:
<apteryx>can't guile-ssh resolve DNS? My host is configured to use a (DynDNS) domain name, and it times out trying to reach it.
<apteryx>(while doing `guix copy')
<apteryx>seems it doesn't honor the port setting in ~/.ssh/config, and uses a hardcoded 22
<apteryx>will report this bug after I verify it some more
<rk4>nice :)
<apteryx>has someone ever seen this: in `guix copy': guix copy: error: failed to connect to `#<input-output: channel (open) 2466ac0>': Protocol error
<apteryx>cbaines had answered lfam about the same question with: does running guile directly over SSH work, e.g. ssh guile
<apteryx>so apparently Guile needs to be in the path of the remote
<mfzap>hi all, has anyone installed gnucash? It's failing tests for me, a bunch of timezone and date manipulation tests that use the boost library (according to a C++ comment) fail... not sure how to poke it to install
<g_bor>hello guix!
<Gamayun>hello g_bor
<g_bor>What is the status of core-updates?
<g_bor>I believe that we should push the python-minimal fix there before the merge.
<XexonixXexillion>Is it possible to get guix working on something which isn't linux? (obviously they can't share substitutes). But is there anything major stopping me from running it on BSD?
<g_bor>The breaking change is already present somewhere in the 4.18 kernel series, did not look at eariler version.
<janneke>XexonixXexillion: guix runs on the Hurd, I guess porting to BSD should be easier?
***LucidDreamZzZz is now known as luciddreamz
<Laalf>the python on core-updates still leaks...
<amz3>I successfully install guile-next
<amz3>What I did, is checkout the guix git when guile-gcrypt was added, and install guile-crypt from there and then checkout master to install guile-next
<amz3>this way guix did not complain about missing guile-gcrypt
<amz3>well, now 'guile' command gives me: ;;; In procedure load-thunk-from-memory: incompatible bytecode kind
<amz3>ERROR: In procedure load-extension:
<amz3>In procedure dynamic-link: file: "/gnu/store/i0nqs30zn0bdij5zwagqx1chcdk460ai-guile-readline-2.2.3/lib/guile/3.0/extensions/guile-readline", message: "file not found"
<amz3>I am uninstall guile-next fix the issue
<efraim>there are a number of places where 2.2 is hardcoded in the package definition
<g_bor>hello guix, some more information about the python-minimal thing:
<g_bor>it builds for me on core-updates guixsd. That is good news.
<Laalf>the python on core-updates still leaks. is what i wrote 1 hour 10 ago
<g_bor>I think it would worth to mark the substitue for python-minimal as gc-root on berlin, so that we don't accidentally lose it until we have a proper fix if we have to gc. WDYT?
<g_bor>Laalf, yes, I know that.
<g_bor>What kernel are you on?
<Laalf>4.18.15 mainline
<g_bor>Ok, then this is a problem.
<g_bor>Could you tell me the exact command you use? For me it builds /gnu/store/qws8zsa0mm1d7jwlcrg4rr9rmhip30av-python-minimal-3.7.0/
<g_bor>Also, is this on a foreing distro?
<Laalf> guix pull --branch=core-updates -k --substitute-urls="" -c 8
<Laalf>no. guixsd
<g_bor>ok I will try to reproduce.
<Laalf>even with roptats help. i have the .nars still here but i cant import them. i did not gc so i dont know wtf is going on
<roptat>Laalf: you shouldn't use mirror.hydra until the maintenance is over
<roptat>Laalf: what happened when you tried to import them?
<roptat>did it work but then guix went on compiling python anyway?
<Laalf>roptat: it warned me about openssl not being able to be imported. that now works. with guix pull it still compiles python
<g_bor>roptat: It would be really important to know if it is safe to upgrade berlin, so I will have a look at this.
<g_bor>If the build does not work on the latest core-updates kernel, that is a big problem.
<g_bor>roptat: Do you know what is the current status of core-updates?
<Laalf>i use mainline. not libre. but they are not that different iirc
<g_bor>If they are similar enough in this respect, then we already have a problem, as the core-updates kernel is later than the one you mentioned :)
<roptat>g_bor: I think we are waiting for hydra to come back, but it is ready to be merged
<Laalf>roptat: guix archive: error: build failed: path ‘/gnu/store/4n6v2zp5mslq2784j878dmfzzj4vvmza-openssl-1.0.2o’ is not valid
<roptat>ah, that's bad
<g_bor>this python problem is definitely a core-updates category one. I wonder if this is severe enough to delay the merge or not...
<Laalf>i can go through everything but the last test
<Laalf>it leaks earlier but i dont have enough ram
<g_bor>Currently we do have a substitute, but I believe we should do precautions to keep it that way, until we have a proper fix.
<roptat>Laalf: take this:
<roptat>hopefully that will solve that "not valid" issue
<g_bor>Or do we? Oops, I am bit confused...
<roptat>g_bor: yes, we have
<roptat>Laalf: are you sure you authorized berlin?
<Laalf>roptat: where can i get the key again?
<rekado>Hi Guix
<rekado>g_bor: I really don’t want to delay the core-updates merge any longer.
<rekado>can’t we graft thisL
<rekado>core-updates is a requirement for the gnome-updates branch, which has been collecting dust for … two months(?) now.
<rekado>more than that! The last commit on wip-gnome-upgrades was August 10.
<g_bor>rekado: civodul said that grafting here does not really work. See it in last night's log.
<rekado>oh, that’s bad :(
<rekado><civodul> [23:21:42] grafting wouldn't help though, because you'd still need
<rekado> to build the actual thing
<g_bor>yes, that's it.
<g_bor>I am tring to have a look at this, and see if this fail for me or not.
<Laalf>roptat: its building stuff but not python -n outputs nothing
<Laalf>i am confused
<g_bor>I am on guixsd, and I use the linux-libre kernel. Reconfiguring to latest core-updates just now.
<roptat>Laalf: let's hope it works
<Laalf>roptat: it compiles binutils now.
<hulten>Is a garbage collector necessarily needed for any functional, reproducible package manager?
<hulten>Or: what property of Guix is the reason for the creation of "garbage" (obsolete packages)?
<roptat>hulten: we ensure that packages that make up profiles and their history (actually gc roots) are never removed
<kmicu>Hi hulten, GC is not necessarily. We can decide to remove packages right away (or set a cron job) or let the user decide when to do it.
<roptat>we could collect garbage after every guix operation too without any ill effect
<kmicu>Leaving packages in the store is playing safe.
<roptat>also, the result of guix build (mostly used by developpers of guix) doesn't register gc roots, so the result is garbage, but we don't want it to be collected right away
<nly>Hi, how can I see info manuals for guile-* (say guile-chickadee) in emacs?
<nly>M-x info doesn't list guile-* modules though i can do 'info chickadee' to view (guile-chickadee) info page for example
<nly>in terminal
<janneke>nly: have emacs see the same INFOPATH that you feed `info'
<emacsen>I'm a new Guix user (as in 10 minutes ago). Is the build server down? I get a 504 Gateway Time-out
<Laalf>emacsen: yes. hydra is down.
<emacsen>Laalf, okay. Since this is litterally minute 15 of me using the software, I couldn't be sure if this was it, or me.
<Laalf>emacsen: you can use import the key from here
<emacsen>Laalf, dumb question but search isn't helping. Where do I tell it to import this?
<jlicht>emacsen: it is a known problem already. If I am not mistaken, *some* maintenance will take place by the 6th of November, so I hope to see things change by the end of this week again at least
<Laalf>emacsen: wget && sudo guix archive --authorize <
<Laalf>then use --substitute-urls=""
<nly>Thanks janneke
<emacsen>Laalf, thanks. :)
<ng0>don't just wget it. you can git clone it and have the signature on the commit which added it..
<davidl>unable to build mozjs and gvfs
<hulten>Thanks to roptat and kmicu for the explanation on garbage collection.
<hulten>My /gnu/store has a filesystem of 100 GB, and it was filled up.
<hulten>So I did some cleaning with guix gc -F 50G, which probably did most that it could; now it is 68 GB in size, which I still find a lot.
<Laalf>hulten: sudo guix gc --delete --optimize --clear-failures -C wipes everything that is not needed
<roptat>hulten: you also have history of profiles that are gc roots, so they are not removed (so you can switch to another generation of any profile)
<roptat>you can remove old generations and re-run guix gc to free more space
<hulten>roptat, does removing the symlinks /var/guix/profiles/system-*-link and /var/guix/profile/per-user/*/guix-profile-*-link do this?
<roptat>hulten: yes, but you can use guix package for that too
<hulten>Ah, yes, I see if that, --delete-generations, does indeed remove the symlink (nothing else?).
<roptat>nothing else
<roptat>that's why you need to run guix gc after that to actually remove packages
<kmicu>hulten: how many entries do you see during boot process? 2 or more? Did you update your system and user packages at once? Maybe they are on different guix revisions.
<kmicu>You could also inspect /gnu/store/ for your favorite package. It should be only one instance of it after complete garbage collecting. If not then something holds other versions.
<Laalf>can we rename guix pull to guix compile python?
<janneke>ah, great -- i finally found why tar/compress don't work with bootstrap-guile
<janneke>(search-patch "guile-2.2-default-utf8.patch")
<janneke>grrr -- so that means bootstrap-guile behaves differently from regular guile wrt binary ports
<janneke>wondering where to sprinkle set-port-encoding!s in gash...
<nlyy>I still didn't figure out how to get emacs to list guile-* manuals in info mode
<nlyy>I have exported the INFOPATH in ~/.profile and in ~/.bashrc, apparently to no effect
<nlyy>any ideas?
<cbaines>nlyy, are you sure those environment variables are actually taking effect? Perhaps try checking them in a shell, and then starting Emacs from that shell.
<cbaines>also, generally, if you source ~/.guix-profile/etc/profile then you shouldn't have to set the environment variables manually
<nlyy>should i give you a paste?
<nlyy>cbaines i tried launching emacs from a terminal, 'info chickadee' works in a terminal but not in emacs launched from the same terminal weird
<nlyy>I haven't sourced ~/.guix-profile/etc/profile, that might be the issue
<nlyy>nah didn't
<janneke>nlyy: in emacs *scratch*, try (getenv "INFOPATH") and see if the directory you need is present
<nlyy>looks ok
<janneke>nlyy: where does live?
<nlyy>maybe it's this? .guix-profile/share/info/
<nlyy>ah, the address in info -w chickadee is different from .guix-profile/share/info/
<janas>Is anyone else getting a 504 Bad Gateway message from the Guix Substitutes server?
<nlyy>in the store
<nlyy>yes, hydra is down i think
<janas>okay, thanks!
<nlyy>I did an 'info -w chickadee' which gave $1, ls -al .guix-profile/ -R | grep $1 didn't find anything. where $1 is a store path.
<verisimilitude>Oh hey, did that X11 Emacs issue with Guix ever get fixed?
<verisimilitude>I've been using Ncurses Emacs for several months now.
<verisimilitude>X11 Emacs always segfaults.
<g_bor> verisimilitude: Doy you have a bug number for this issue?
<verisimilitude>I reported it to the mailing list a few months back, I believe.
<verisimilitude>I suppose I should check that, actually.
<pkill9_>verisimilitude: i've been using X11 Emacs for a while
<verisimilitude>It's my understanding it hit some and not others.
<verisimilitude>Also, I now recall that mailing list issue involved Clozure, not Emacs.
<verisimilitude>There was, however, a fellow collecting some information regarding this a ways back.
<munen>Hello everyone. After reading up and looking at a lot of videos, I'm intrigued by Guix! I'm a long time Debian user, but face constantly 'mutable state' issues when doing DevOps that I solved in my own programs long ago by employing functional programming (Clojure and such). That's why I finally installed Guix (on a foreign platform, my Debian notebook). It took about 16h to compile everything to get to the point where I can use the
<munen>command prompt which makes me quite happy(; From this point on, I'd like to go with substitutes to increase the feedback loop while I'm still learning. However, I'm getting "substitute: guix substitute: warning: while fetching '': 504 ("Gateway Time-out")" and all the mirros I'm looking at show the same. Is that a real nginx issue the servers are currently facing or am I missing configuration
<munen>somewhere? Thanks a lot for your help in advance and for working/using Guix!
<Laalf>munen: hydra is down at the moment. do wget && sudo guix archive --authorize < and then use --substitute-urls="" at every build that you are doing
<munen>Laalf: Thank you very much for providing me with an alternate mirror and the super fast response!
<lsl88>hi! I am still having trouble with makeinfo and guix.texi
<lsl88>I downloaded the files in all the formats available from guix gnu site, but they are organized different to the ones in guix/doc. I ony added some cindex
<verisimilitude>Were you able to install texlive-tiny more easily than what you were trying to install, lsl88?
<hulten>munen: It's good to hear such recognisable stories. I also come from Debian (mostly), and two pc's at home are now running GuixSD, smoothly.
<hulten>Only recently I thought of installing Guix on my work's Ubuntu laptop; for some packages it is more easy to get the newest through Guix.
<hulten>kmicu: Thanks for the tips on gc. I removed a couple of entries, and should now be reducing disk usage with gc.
<lsl88>verisimilitude: I believe it has to do with my locales. Here goes the error I get explanined:
<pkill9_>is there a way to silence the messages that say "source file ____ newer than compiled _____"?
<verisimilitude>Alright; that's more magic than I'm currently trained in, lsl88; so, I can't really give any advice on where to go from here.
<civodul>pkill9_: when do you see them?
<pkill9_>i have GUIX_PACKAGE_PATH set, and if the package deifnitions there are newer than the compiled versions from that path, then it shows that message everytime you run the guix command
<marusich>I'm not sure where to ask this question, so I'll ask here. I've noticed that a lot of email lists out there have archives like this:
<pkill9_>the compiled version are stored in ~/.cache/guile
<marusich>I can view threads by month etc., but it's hard to search them. Is there an easy way to search these sorts of archives that I'm not aware of?
<reed_>hi all, I've tried to install GuixSD a few times on a thinkpad x220 and It keeps failing to build bzip2, python-3, python2-2 and curl
<marusich>reed_, as general advice, you might consider trying to "guix pull" from some older commits.
<reed_>before I run guix system init?
<marusich>Oh, hm. I misunderstood.
<marusich>I see you're installing it for the first time.
<marusich>If you're using a release image, it shouldn't be failing... But since it is, there are probably a few things you can try. 1) Try running "guix pull" to get the latest version of Guix, before running "guix system init". This might take a long time, depending on how fast your system is and whether or not substitutes are available. I'd expect it to take hours.
<reed_>If it's relevant, I'm using the config for the minimal desktop environment (the one with i3). I've only made the minimal modifications to make it compatible with my system (i.e. changed /dev/sdX to /dev/sda, etc..)
<marusich>2) Share the build failures here or on the mailing list, so maybe somebody can help diagnose the issue.
<marusich>Did you add software like packages or services?
<reed_>Okay, I will try to run "guix pull" and then try again, and report back.