IRC channel logs


back to list of logs

<ecbrown>rekado: yes
<ecbrown>i have this working on another laptop with another build server, so i'm (somewhat) familiar with the process
<ecbrown>sort of hoping someone recognizes it as "oh that's the missing guile-ssh error" or something
<ecbrown>lfam: i've done guix package -i guix guile guile-ssh on root/user on laptop/server (all four)
<ecbrown>now i will try to get this new system working with an already functioning build server
<ecbrown>maybe i can triangulate
<lfam>ecbrown: You might also search on help-guix and the guix-devel archives. It seems like offloading is a little finicky; maybe someone else had the same issue
<emacsomancer>I'm having trouble installing a package via quicklisp. it's associating with a glibc-2.7 but wants glibc-2.8
<emacsomancer>"/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/ version `GLIBC_2.28' not found"
<emacsomancer>I have glibc-2.28 installed though
<mange>Which package are you installing from quicklisp? And are you using SBCL?
<emacsomancer>mange: yes, sbcl, and I'm trying (ultimately) to install shuffletron, but I'm getting stuck on osicat
<emacsomancer>(read glibc-2.27 and 2.28 above for 2.7, 2.8)
<mange>Okay, well, shuffletron didn't work for me, but osicat worked without issues (then it died loading audio-related libraries).
<mange>I start my SBCL in a pretty hacky way, with LD_LIBRARY_PATH=$HOME/.guix-profile/lib:/run/current-system/profile/lib.
<emacsomancer>mange: hmm, for some reason it's grabbing glibc-2.27 rather than 2.28 (though it sounds like it may or may not matter)
<emacsomancer>let me try that to see what happens
<emacsomancer>I get a segmentation fault when i try that....
<mange>Hmm, my SBCL is linked with libc from glibc 2.27, so I would have expected if osicat required 2.28 it would have failed.
<emacsomancer>ah, so that's probably why it's grabbing 2.27 rather than 2.28 though, no?
<mange>It still works when I remove my LD_LIBRARY_PATH hack, so that's probably not it.
<emacsomancer>hmm, that's odd.
<mange>Are you on GuixSD, or a foreign distro?
<emacsomancer>mange: on GuixSD
<mange>Okay, that could also be relevant. I'm on Ubuntu, and while I didn't see glibc 2.28 anywhere, it's hard to say for sure that it's not there.
<emacsomancer>mange: it's funny because I do have glibc 2.28 installed directly and glibc 2.27 is installed as a dependency of other packages (presumably)
<mange>I'd like to do some investigating to work out why it's not working, but I don't really have time to do it now, sorry.
<emacsomancer>mange: no worries.
<jpnc>hi, anyone ever have issues with guix erroring out on pull or package commands due to hash mismatch where the "actual" hash is different each time the command is run?
<mange>No, I haven't. Have you verified that the file it's trying to download isn't changing between downloads?
<jpnc>yeah actually just realized after i asked the question that i've been ignoring the obvious.. curled which it is trying to pull and i get an html page saying it can't be found instead of a tarball
<jpnc>is there a cache i need to blow out somehow if it is trying to pull from an invalid url?
<mange>I don't think so. It will only cache it based on its hash, so if the hash in the package definition doesn't match any store entries then you'll be fine.
<jpnc> appears to just be a parked domain, so pulling anything from that domain won't work
<mange>Actually, I think it caches based on filename and hash, or something. I can't remember the precise details.
<jpnc>any clues what is telling it to try to pull from this is apparently an issue not affecting everyone, i'm not certain how it could be gentoo specific but that's the foreign distro it is living in
<mange>There's a note in the Guix source: "XXX The domain was allowed to expire.".
<mange>Which then uses See the bzip2 package in compression.scm.
<jpnc>i don't find that file under /gnu or /var/guix, am i missing a location?
<jpnc>the only reference i found to the url with grep was in /gnu/store/59pqd1d0ihqxx0i64yxk335vjmw78wmh-bzip2-1.0.6.tar.gz.drv
<jpnc>found it: /usr/share/guile/site/2.2/gnu/packages/compression.scm
<mange>If you run "guix edit bzip2" it should open it up in $EDITOR. It looks like the change was made a month ago.
<jpnc>mine doesn't have the new url it seems, maybe the gentoo package needs updating
<mange>Okay, one sec.
<mange>If you run "guix download" guix should download it and put it in the store for you. Check that the hash it outputs is 1kfrc7f0ja9fdn6j1y6yir6li818npy6217hvr3wzmnmzhs8z152. If it is, then try your guix pull/package command again.
<jpnc>ok i changed the url to what i found in and the pull is actually doing stuff now so i think we've probably got it :)
<mange>Oh okay, that's a different way to do it. :)
<jpnc>well i did the guix edit bzip2 and figured that's what you meant heh
<mange>Yeah. Once "guix pull" finishes, the source that "guix edit" opens will be in the store, so will be read-only. I'm used to not being able to directly change things with "guix edit", so I just gave you instructions as if you couldn't.
<jpnc>so the stuff in /usr/share/guile is basically just used for bootstrapping the guix environment from my host os?
<mange>I don't know how the Gentoo package is set up, but I assume so, yeah.
<jpnc>cool, makes sense
<mange>If you install using the guix binary install instructions I'm fairly sure it's all just in the store..
<jpnc>well, hopefully there will be a more reliable source for bzip2 at some point, but this has been super helpful
<mange>No worries! I hope you enjoy guix!
<civodul>Hello Guix!
<janneke>hello civodul!
<thorwil>hi! suddenly, `guix pull` fails with "no code for module (git)" 0.o
<thorwil>how do i recover from that?
<civodul>it may be my fault, lemme see
<civodul>thorwil: you could pull an older commit in the meantime
***rekado_ is now known as rekado
<rekado>got the same problem on my i686 machine, thought it was my problem
<rekado>it might be commit aed0a594058a59bc3bb1d2686391dc0e8a181b1f
<rekado>pulling 3763e7716cc319dadb3adfbcbbc668aea96fec09 should work
<Sleep_Walker>I met this too
<thorwil>ok, but how? apparently, it's not `guix pull --commit 3763e7716cc319dadb3adfbcbbc668aea96fec09`
<roptat>hi guix!
<roptat>yesterday I was able to download a few pieces of my torrent and save them to file \o/
<roptat>but at some point my program was killed with no error message
<roptat>and that's not supposed to happen since my main thread executes (let loop (...) ... (loop ...))
<roptat>(it's not supposed to end unless I Ctrl+C it)
<roptat>could it be that I made to many recursive calls?
<civodul>hey roptat! that's rather good news!
<civodul>thorwil: "guix pull --commit=3763e7716cc319dadb3adfbcbbc668aea96fec09"
<civodul>(notice the equal sign)
<thorwil>of course, i should _read_ when reading! ;)
<Sleep_Walker>it seems that pulling that particular commit workarounds the problem
<civodul>thorwil, rekado: i've pushed a fixed in the meantime
<civodul>sorry for the breakage!
<civodul>at least we have a very fast feedback loop :-)
<jonsger>and room for improvements in the post-pushing QA :P
<jonsger>eh, pre-pushing
<civodul>that too :-)
<civodul>it's been hard to keep up with patches and everything lately
<thorwil>glibc-utf8-locales is in my manifest and GUIX_LOCPATH is /home/thorwil/.guix-profile/lib/locale. still get "guile: warning: failed to install locale"
<thorwil>plus still running into "no code for module (gcrypt pk-crypto)"
<ekket>hello, i've been trying to install guixSD on a VM and keep getting this error with guix pull: "ERROR: In procedure scm-error: no code for module (git)"
<ekket>full error log: config.scm:
<roptat>thorwil: that message could also be from guix-daemon
<roptat>are you running on a foreign distro?
<roptat>make sure GUIX_LOCPATH is defined is the context of the daemon
<roptat>typically in /etc/systemd/system/guix-daemon.service
<roptat>ekket: try again, it's supposed to have been fixed less than an hour ago :)
<ekket>tried again and it works, thanks
<roptat>ekket: cool :)
<thorwil> /etc/systemd/system/guix-daemon.service
<thorwil> /etc/systemd/system/guix-daemon.service has "Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale"
<thorwil>which points to /gnu/store/xa391b23r5lbwxb9q26sq5rq1fkd1xi3-glibc-utf8-locales-2.25/lib/locale
<roptat>that's a bit old (should be 2.27 I think)
<roptat>could you try updating root's profile?
<roptat>(guix package -u as root)
<thorwil>however, `sudo env` does not print anything with "LOC"
<roptat>that's OK, it's defined by systemd for the guix-daemon service
<thorwil>well, the first attempt `guix package -u` as root failed: error: directory `/var/guix/profiles/per-user/root' is not owned by you. chown root ... 2nd attempt ongoing
<tune>any news on qutebrowser getting fixed?
<ekket>same question here
<rekado>this is the last I know about qutebrowser:
<rekado>we already have qtwebkit now (though the build seems to be very resource hungry)
<rekado>I don’t know if there are other problems.
<rekado>if somebody knows more about this please comment on that issue.
<rekado>Today is Patch Review Thursday!
<rekado>I’ll take care of all of these today:
<rekado>who would like to take charge of reviewing some other lonely patches today?
<civodul>rekado: i'm happy to help!
<civodul>(going to a meeting now though)
<tune>ah, I think I had seen that issue before
<tune>it seemed like no one wanted to touch qtwebengine
<tune>because it's big and possibly not completely free
<tune>so then we've set a far-off goal and just left qutebrowser broken
<rekado>I also claim this one:
<montxero>Hey guys
<montxero>Quick question, how do I add new user profiles to /var/guix/profiles/per-user on a foriegn distro?
<montxero>is it handled automatically or do I need to create it manually?
<rekado>montxero: it’s done automatically.
<montxero>Quick question, how do I add new user profiles to /var/guix/profiles/per-user on a foriegn distro?
<montxero>rekado: okay, I thought so... semms like I am missing a step
<roptat>montxero: I think you only have to run "guix package -i ..." as that user
<bavier>tune: fixing qutebrowser is on my list of things to do
<tune>oh, okay. good to know
<montxero>roptat: Yeah, tried that a couple of times.. restated computer now running guix pull as said user
<rekado>montxero: do you get an error with “guix package -i”?
<Sleep_Walker>if you are looking for some webkit-based browser, there is also eolie
<Sleep_Walker>(I discovered this today when I was looking for qutebrowser alternative)
<Sleep_Walker>it's using webkit-gtk though
<montxero>rekado: yes I did earlier
<montxero>rekado: funny thing I tested and had it working on 2 computers before deciding to put it on my primary.
<rekado>what error do you get?
<rekado>Sleep_Walker: eolie should be updated. I haven’t gotten around to that yet.
<rekado>I added it in a time when it was pretty early in its development.
<Sleep_Walker>it looks in better shape than qutebrowser :)
<montxero>Can't remember the details. Something about not having a profile in /var/guix/profiles/per-user or something along those lines
<Sleep_Walker>and more user-friendly than surf
<montxero>rekado: in the middle of guix pull now
<montxero>rekado: roptat: Yay!, thanks guys it finally worked
<montxero>I removed guix, rebooted, reinstalled, rebooted, guix pulled, spoke to you guys, and it works! yay
<rekado>oh… reinstallation is a rather drastic measure to take.
<montxero>rekado: yeah, I went nuclear... removed the directories, build group and build users, cleaned systemd... nuked that sucker
<montxero>I made a .guixrc for my other systems. How common is this practice? is there a better way of handling the settings that have to do with guix and its environment variables in a foreign distro? here's my .guixrc:
<Sleep_Walker>is anyone using bluetooth headphones with GuixSD?
<Sleep_Walker>it seems that my bluez module of pulseaudio can't connect bluetooth daemon
<Sleep_Walker>and I'm not sure what is the idea how this should work...
<grafoo>has someone tried to create a package for bcc from the iovisor project?
<lfam>grafoo: I started a package for bcc ~2 years ago, but never finished it or got it to build properly. I can share it with you if you want, but it's possible that so much has changed upstream that the patch is not relevant. Let me know if you'd like a copy
<lfam>Looking at my old work-in-progress patch, I think it would be a lot easier to start from scratch. That's what I would do if I was going to try again
<grafoo>lfam: ok thx for the info. do you know if at least all of the dependencies are already available in guix?
<lfam>grafoo: Do you have a list of bcc's current dependencies?
<grafoo>lfam: there's a listing on
<grafoo>lfam: couldn't we leverage the work from the nix project?
<lfam>grafoo: Yes, it would probably be useful to look at what they did
*bavier` thought people were talking about a compiler for the B programming language, haha
<lfam>We won't be able to offer netperf in GNU Guix if the license is not free
<lfam>If the tests really get run as part of the build process and can't be disabled, it will block bcc from being part of Guix
<lfam>But, it's software, so we can probably skip that part somehow
<grafoo>just tried a build with a ubuntu:18.04 docker image without arping, netperf or iperf.
<grafoo>seems fine so far.
*civodul joins rekado in applying a bunch of patches from the queue
<lfam>We do have an iperf package
<grafoo>i know. already using that one :)
<dustyweb>so I'm using guix environment --container
<dustyweb>how do I get it to *not* expose my homedir to the thing in the container...?
<dustyweb>$ guix environment --container --expose=/tmp/eligibility=/tmp/eligibility --user=foo --ad-hoc libreoffice coreutils bash -- bash
<dustyweb>when I do ls
<dustyweb>I still see my home directory, but as /home/foo
<dustyweb>I wanted to not link in my home directory at all
<lfam>dustyweb: IIUC it exposes the current working directory by default
<bavier`>dustyweb: could you use the `--user' option?
<dustyweb>it exposes the current directory, right
<lfam>I think the manual goes into some detail
<dustyweb>I misunderstood that bit
<dustyweb>got it ty
<dustyweb>also has anyone tried running libreoffice from a container?
<dustyweb>I'm trying now and
<dustyweb>/gnu/store/2mw4m28w189l5nx7lygqbl18zmphjaic-profile/bin/oosplash: No such file or directory
<dustyweb>no idea why it's saying that
<davexunit>dustyweb: I haven't done that but I have done icecat. you'll need to link in the /tmp file that has the X server socket
<lfam>I've tried running a few graphical applications from within a container and it's always really tedious to figure out *all* the paths it needs shared or exposed
<dustyweb>davexunit: oh really? yeah I guess so :(
<dustyweb>sad times, xorg
<davexunit>it was pretty easy
<dustyweb>yeah I just meant the security properties of X11
<davexunit>yeah there's no real way around that
<lfam>Is pre-inst-env working for anyone else from the HEAD of the master branch?
<lfam>I'm getting 'Unbound variable: git-fetch' for what I guess is every package module that uses git-fetch
<dustyweb>still getting the error
<dustyweb>something about libreoffice finding its binaries I think
<dustyweb>I guess I can also do this in a vm
*dustyweb having to open some .docx emailed to them
<davexunit>dustyweb: veryify if that file is there?
<lfam>You could treat it as a zip file... oh wait, all the unzippers are also terrible ;)
<davexunit>you may be missing a package outout?
<davexunit>nvm, there's only 1 output
<dustyweb>davexunit: yeah it's not there, but even weirder
<dustyweb>it's not in my /gnu/store at all
<dustyweb>I wonder if thss is some corruption issue
<davexunit>not in the store within the container, right?
<dustyweb>not in the store outside either!
<lfam>dustyweb: Is there any path with that hash?
<dustyweb>wait, if I'm going to be sane
<dustyweb>I should try launching it outside teh container in a normal environment
<davexunit>yeah give that a shot
<lfam>It could be that a valid store path was concatenated with '/bin/oosplash'
<dustyweb>ok that works
<davexunit>but there is still no oosplash file anywhere on your system? there must be
<civodul>lfam: re git-fetch, that's on current master? from 'guix pull'?
<lfam>civodul: On master with pre-inst-env. I'm building a fresh checkout now
<lfam>Could be related to the git-predicate change
<lfam>Hm, I need to install guile-git and set GUILE_LOAD_PAT
<dustyweb>libreoffice needs sed and grep to launch
<lfam>I am so curious why :)
<dustyweb>I think it's the launch script
<lfam>soffice is a shell script, I never noticed!
<dustyweb>davexunit: is this what I need to do? --expose=/tmp/.X11-unix=/tmp/.X11-unix
<davexunit>dustyweb: yeah!
<dustyweb>it's saying "Failed to open display" still
<lfam>You also have to export the DISPLAY variable correctly (no idea how to learn the right value)
<dustyweb>lfam: oh!
<davexunit>that too
<davexunit>pass along $DISPLAY
<dustyweb>well now it has new errors, and the old one :)
<dustyweb>foo@jasmine /tmp/eligibility [env]# DISPLAY=":0.0" libreoffice
<dustyweb>No protocol specified
<dustyweb>Failed to open display
<dustyweb>No protocol specified
<davexunit>I think you need --share
<davexunit>instead of --expose
<davexunit>since libreoffice needs to write to the socket
<lfam>I also don't have '/tmp/.X11-unix' but instead '/tmp/serverauth.IlFjMUHlxX' with that random component
<davexunit>it's always /tmp/.X11-unix on my machine. I assume dustyweb verified that part
<efraim>my eyes were getting tired and I took off my glasses, forgot I set the scaling based on wearing my glasses :/
<dustyweb>/tmp/.X11-unix is a directory I have, I assumed it must be the one
<lfam>Yeah, I think there is some diversity in how X is started. Unfortunately googling doesn't enlighten me :/
<dustyweb>still not working with --share for whatever reason
<dustyweb>maybe I should start up a VM instead at this point!
<efraim>'find /gnu/store -type -f -name oosplash' gives me /gnu/store/...-libreoffice/lib/libreoffice/program/oosplash
<bavier`>might be nice to have something like "firejail" for guix, where a user could start a container for a specific application and some sort of rules could dictate the configuration
<efraim>the ever elusive 'guix run'
<davexunit>yeah would be cool
<davexunit>unfortunately no one has taken up the container torch since I stopped being a regular contributor
<rekado>davexunit: it just works too well as is ;)
*rekado just pushed a commit with a bad commit message :(
<lfam>rekado: It happens, oh well! We can't do anything about it now
<rekado>misses two characters!
<rekado>imagine a “* ” at the beginning of the line for me.
<mbakke>lfam: libinput-minimal has a lot of dependent packages.
<lfam>mbakke: Ah, I didn't realize that. I'll revert now
<lfam>mbakke: Well, at least I can say that this new libinput seems to work with a GNOME desktop
<mbakke>lfam: Perhaps you can merge and re-add it on core-updates? We really should start that soon..
<mbakke>It also works with a GNOME desktop ;-)
<dustyweb>ok I got it launching
<dustyweb>now I'm missing fonts :)
<dustyweb>slowly making it there..
<mbakke>dustyweb: Wohoo :-)
<lfam>mbakke: Done
<dustyweb>not really sure what's missing about getting the fonts to work
<dustyweb>I see a thread with Mike Gerwitz about getting icecat to run some time ago
<dustyweb>which also talks about font difficulties
<mbakke>dustyweb: Try exposing ~/.cache/fontconfig, or running `fc-cache -f` in the container.
<dustyweb>mbakke: aha, I will try that, thanks
<rekado>mbakke: speaking of GNOME — do you think we can merge the GNOME updates into core-updates-next?
<rekado>I fear the updates might go stale
<dustyweb>still was having trouble, so in the interest of time I used "guix system vm" instead
<dustyweb>so close though!
<dustyweb>it was still nice to try out the container things
*janneke tries to upgrade to a version of guix that has profile-search-paths
<janneke>running guix pull now...i would have liked to have the default stay at 0.15.0, but have latest master in emacs' M-x guix repl
<mbakke>rekado: I thought they were for the current core-updates.
<rekado>mbakke: they are not in the current core-updates, though, are they?
<rekado>once core-updates is merged I’d like us to test the GNOME update on actual systems and then merge it pretty quickly after that.
<mbakke>rekado: Sounds good.
<vagrantc>upgrading u-boot to 2018.09 fails building u-boot-tools ... because it's calling "python-coverage" in some of the tests, and the python-coverage package only provides the "coverage" binary ... how did this ever work? nothing's changed in the u-boot side...
<vagrantc>and apparently, the python-coverage package hasn't changed since late 2017
<vagrantc>maybe those tests were skipped in older versions of u-boot...
<vagrantc>guess i could just patch the source on the fly?
<vagrantc>guess ... something along the lines of (substitute* "tools/patman/" (("python-coverage") ("coverage")))) ?
<bavier`>vagrantc: that looks right
<vagrantc>hmmm. it already replaces the check target... so i guess i can just stick it in the check target itself?
<rekado>vagrantc: yes, that would be okay.
<vagrantc>the above fails with: Wrong type to apply:
<rekado>(substitute* "tools/patman/" (("python-coverage") "coverage"))
*vagrantc tries again
<rekado>the substitute* body is a list of transforms; each consists of a match expression in parens followed by the replacement text.
<rekado>(the match expression can bind groups, that’s why it’s in parens)
<vagrantc>looks promising
<vagrantc>e.g. tests are running instead of a backtrace :)
<vagrantc>of course, one of the thousands of tests fails. heh.