<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 <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/libc.so.6: version `GLIBC_2.28' not found" <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 <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) <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. <mange>Are you on GuixSD, or a foreign distro? <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. <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>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>bzip.org 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 bzip.org? 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 bzip.org domain was allowed to expire.". <mange>Which then uses web.archive.org. 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 bzip.org 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>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. <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! <thorwil>hi! suddenly, `guix pull` fails with "no code for module (git)" 0.o <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 <thorwil>ok, but how? apparently, it's not `guix pull --commit 3763e7716cc319dadb3adfbcbbc668aea96fec09` <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" <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>at least we have a very fast feedback loop :-) <jonsger>and room for improvements in the post-pushing QA :P <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)" <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 <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? <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? <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>who would like to take charge of reviewing some other lonely patches today? <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 <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 <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) <montxero>rekado: funny thing I tested and had it working on 2 computers before deciding to put it on my primary. <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. <montxero>Can't remember the details. Something about not having a profile in /var/guix/profiles/per-user or something along those lines <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: pastebin.com/FxjmwBEH <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: 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. *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>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? <lfam>I think the manual goes into some detail <dustyweb>also has anyone tried running libreoffice from a container? <dustyweb>/gnu/store/2mw4m28w189l5nx7lygqbl18zmphjaic-profile/bin/oosplash: No such file or directory <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>yeah I just meant the security properties of X11 <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>something about libreoffice finding its binaries I think *dustyweb having to open some .docx emailed to them <lfam>You could treat it as a zip file... oh wait, all the unzippers are also terrible ;) <dustyweb>davexunit: yeah it's not there, but even weirder <dustyweb>I wonder if thss is some corruption issue <davexunit>not in the store within the container, right? <lfam>dustyweb: Is there any path with that hash? <dustyweb>I should try launching it outside teh container in a normal environment <lfam>It could be that a valid store path was concatenated with '/bin/oosplash' <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>soffice is a shell script, I never noticed! <dustyweb>davexunit: is this what I need to do? --expose=/tmp/.X11-unix=/tmp/.X11-unix <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>well now it has new errors, and the old one :) <dustyweb>foo@jasmine /tmp/eligibility [env]# DISPLAY=":0.0" libreoffice <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 <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>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>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. <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>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. <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/test_util.py" (("python-coverage") ("coverage")))) ? <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/test_util.py" (("python-coverage") "coverage")) <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>e.g. tests are running instead of a backtrace :) <vagrantc>of course, one of the thousands of tests fails. heh.