<jje>rekado: thanks for the help. civodul: thanks for posting that link. i am up and running again. <jin>Hello Guix, i've an issue when run `guix pull` <davexunit>I have two guixsd machines where a system reconfigure is failing with the latest master because the new guix package build hangs while running the test suite. <davexunit>oh, a core-updates merge. well let's rebuild the world and see if the problem persists. <davexunit>I'm realizing that we missed an opportunity to upgrade to mesa 12 <albertoefg1>export PATH="/var/guix/profiles/per-user/alberto/guix-profile/bin${PATH:+:}$PATH" <reepca>have you installed the programs per-user? that is, as non-root? <reepca>that's all good, the per-user installation just makes symlinks <reepca>just install the programs you want as your user and it should make the symlinks in ~/.guix-profile, IIRC <albertoefg1>reepca: do u know where in the documentation could i find that ? i don't know how to do that <albertoefg1>:( the problem is selinux then it doesn't let me use guix as non root <albertoefg1>i need to investigate how to authorize guix on selinux <reepca>guix has both a root and a user component, the daemon runs as root <albertoefg1>but when installing selinux won't let me add guix to systemd <reepca>does it fail at the copying step or at the systemctl part? <albertoefg1>Run the daemon, and set it to automatically start on boot.If your host distro uses the systemd init system, this can be achieved with these commands: <albertoefg1># cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \\ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon <albertoefg1>and tells me that guix wont run because selinux wont let it <albertoefg1>so i have to manually run # ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild <albertoefg1>give me a minute to restart and tell u exactly what is the selinux message <albertoefg1>SELinux is preventing (x-daemon) from execute access on the file guix-daemon. <albertoefg1>allow this access for now by executing: # ausearch -c '(x-daemon)' --raw | audit2allow -M my-xdaemon # semodule -X 300 -i my-xdaemon.pp <albertoefg1>but i am not sure if i should replace my-daemon whit guix-daemon and not sure if there is a guix-daemon.pp <reepca>sneek: later tell albertoefg1, hey, sorry it took me so long to get back. I'm not sure what those commands do (unfamiliar with selinux), but it looks like if you use those commands it might generate a guix-daemon.pp from guix-daemon? Not sure. I don't think it's a bug with guix, it's just a use case that isn't accounted for in the manual (which should still be fixed). <Apteryx>albertoefg: Did you try disabling SELinux for a moment to see if you can sort everything guix related at first, without it getting in the way for now? <sneek>albertoefg, you have 1 message. <sneek>albertoefg, reepca says: hey, sorry it took me so long to get back. I'm not sure what those commands do (unfamiliar with selinux), but it looks like if you use those commands it might generate a guix-daemon.pp from guix-daemon? Not sure. I don't think it's a bug with guix, it's just a use case that isn't accounted for in the manual (which should still be fixed). <albertoefg>but i am tired i will comeback tomorrow and tell u if it warked <albertoefg>reepca: so i was reading on what those commands do and how to disable selinux <Apteryx>albertoefg: sleeping does wonders. Good night! <Apteryx>My system is building for a looong time following a "guix system reconfigure --no-substitute"! Like... 3 hours now. I'm glad I don't use a full blown deskstop. <Apteryx>IceCat is surprisingly more stable since the last week. <efraim>libstdc++ in commencement, I wonder if i can --enable-static and --enable-shared, rather than --disable-shared <buenouanq>with the weird path magic guix does, do /home and ~/ permissions have to be something specific or can I freely change them to something sensible? <buenouanq>specifically, I would like to make /home 711 and each user"s ~/ 700 <buenouanq>is this going to mess anything guix needs up? <Apteryx>Just finished reconfiguring my system with the "--no-substitutes" option to get passed the cert verification issue, and the font issues I had due to fontconfig grafts bug went away! <janneke>sneek: later tell civodul, out of 4 builds of Guile on 2 different machines (guixsd vs ubuntu+guix), one build has a diff in command.go: http://paste.lisp.org/display/331245 (similar problems with http.go and fixnums.go earlier...I commented out the content of those files as a temporary hack) <Apteryx>Would that be because --no-substitutes doesn't use grafts? <cbaines>I'm having a bit of trouble with Guix and guile modules <cbaines>I've been trying to use a particular version of guix, so I'm running guix environment --pure --ad-hoc guix@... -- guix system container ... <cbaines>But, when I came to trying this on multiple machines, it seems that the contents of ~/.config/guix/latest changes the results I get from running guix system container within the guix environment <cbaines>I'm wondering if Guix is doing something to the GUILE_LOAD_PATH at runtime, as the value set by guix environment seems ok <efraim>so it seems to keep on stopping at gcc, but I'm not sure if its gcc-final or another one <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, janneke says: out of 4 builds of Guile on 2 different machines (guixsd vs ubuntu+guix), one build has a diff in command.go: http://paste.lisp.org/display/331245 (similar problems with http.go and fixnums.go earlier...I commented out the content of those files as a temporary hack) <alezost>buenouanq: you can set any permissions for ~/ dir you want, it doesn't matter for guix <efraim>gcc-final is having trouble finding -lstdc++ <efraim>(or however the link flag is called) <civodul>janneke[cm]: these are "transparent" differences, like differences of pointers at run time; it shouldn't matter <civodul>you can try 'guix build -e '(@@ (gnu packages commencement) gcc-boot0)' first <alezost>cbaines: yes, guix commands use the code from ~/.config/guix/latest (this dir is populated by "guix pull") <efraim>that one built after I readded libstdc++-boot0 that we had from when gcc-5.3.0 was our default gcc <efraim>maybe i'll try taking out --disable-shared from libstdc++ and add #:validate-runpath #f <efraim>I tried --enable-shared and --enable-static, but then libstdc++ didn't build <civodul>i guess the branch you're using is too different for me to say anything useful :-) <civodul>but if you don't find any obvious solution, don't hesitate to email details on guix-devel <efraim>it shouldn't be too bad once its done :) <cbaines>alezost, any idea how I prevent guix using ~/.config/guix/latest ? <cbaines>Its not a command that I am seeing leaking in, but a service type <cbaines>I was hoping that as the version of guix I want to use is on the GUILE_MODULE_PATH, it would take presedence, even if there is another gnu/... around? <cbaines>To recap, I'm running something like: guix environment --pure --ad-hoc guix@... -- guix system container ... <cbaines>and I want the system definition to use a specific version of guix (which I was trying to get by running guix system container within guix environment <civodul>except they didn't update the URL of our news feed <cbaines>a thought, could I define a different $HOME or $XDG_CONFIG_HOME to stop Guix from using .config/guix/latest ? <cbaines>I think changing $XDG_CONFIG_HOME might have done it :) <cbaines>I'm still getting a different output on different machines from guix system container, for what I think should be the same input, but both machines succeed in generating a script now :) <alezost>cbaines: well, guix always prefers "~/.config/guix/latest" if it exists (it is appended to the load path so the guix modules are always taken from this dir); look at the very short code of 'guix' script (`which guix`). <alezost>The only solution to avoid loading that dir I see is to run guix like this "GUIX_UNINSTALLED= guix ..." <alezost>oh, yes a different $HOME or $XDG_CONFIG_HOME should also work <janneke[cm]>civodul: what does that mean? How can I address such a transparent binary difference? <civodul>janneke[cm]: dunno, but what you pasted is a diff of the disassembly, not a diff of the .go files themselves <janneke>civodul: yes, the .go files differ. The paste is a diff of the disassembly of both go files. <janneke>ACTION had some network troubles...hope it's better now <Apteryx>Is someone using Gnus or mu4e inside emacs as their mail client? I'd be interested to know how well it works, especially with encrypted emails and a Gmail account? <xiug>Hi! Please help, i try to install test package (hello), but... - $ guix package -i hello warning: failed to install locale: Invalid argument guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist <xiug>No. Right now in terminal: # guix package -i glibc-locales warning: failed to install locale: Invalid argument guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist <janneke>Apteryx: i use gnus, but not with gmail <Apteryx>janneke: Are you a satisfied user? :) <janneke>it sucks less than other options i tried :) <efraim>xiug: did you create the builders <janneke>Apteryx: my problem is ... state. Mailers like gnus keep local state that some times corrupts and which always makes using different computers or another mail client a real pain. <jin>Hello Guix, i've an issue when run `guix pull` <efraim>the advice I got with setting up msmtp and mutt was to make each of the different parts work individually and then combine them all <Apteryx>efraim: I'm just at reading the manual of Gnus for now, haven't tried anything yet <civodul>basically you need to pull then reconfigure with --no-substitutes <Apteryx>I had that problem from last Friday and the "guix system reconfigure --no-substitutes /path/to/your/config.scm" did the trick, albeit it took a really long time since it must build your base system from sources. <Apteryx>civodul: It also happened to fix my graft related fontconfig issue, would you know why's that? <civodul>Apteryx: most likely you ended up downloading the fontconfig variant that was missing <Apteryx>civodul: Could it also be that there was a new release of fontconfig, and doing the reconfigure upgraded the problematic fontconfig package to a new one which was never grafted yet? <civodul>ah yes, there's also the core-updates merge <Apteryx>OK, thanks! Still a bit unclear about grafts and how they get deprecated in time, I guess I have to review that section of the manual! <rekado>our cluster sysadmin attended a conference where spack was presented as a solution for package management for HPC. <rekado>they wrote me an email saying that ‘this spack thing is like Guix, right’? <paroneayea>rekado: huh it does look like it has some similarities <stefanX2ovic>I I have a question about package font-google-noto. New version was released some time last month, Octobar 2016. Why is uri field of origin version independent? If I download uri specified archive, and run guix hash I get different hash, because the origin hash corresponds to the old version. Isn't this a big problem? <rekado>stefanX2ovic: we generally try to avoid this by using versioned URLs. Do you know if one exists? <stefanX2ovic>rekado: Maybe cloning git repo and than selecting font files from there, but I can not gues which commit represents released version. ***manjaro-kde5 is now known as f52sn
<efraim>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'. <civodul>it suggests that SSL_CERT_DIR points to something that contains invalid PEM files <efraim>Guix build jasper --with-source=https... <efraim>I'll check my SSL_CERT_DIR and make sure it actually points to something real <f52sn>from using the command 'guix system init' while installing guixsd <civodul>that is, 'guix system init config.scm --fallback' <civodul>at work a colleague talked about Spack the other day, and i talked about Guix later <rekado>‘make packaging great again!’ — haha! <rekado>the slides on spack list as cons for Guix: ‘virtual dependency’, ‘multi-compiler and version support’ <f52sn>probably my fault. it actually said to do that, but I thought I remembered trying that and it not working, so I didn't use it. <rekado>and: multiple versions are no problem with Guix, so what’s that about? <civodul>rekado: exactly, that was before he won, and i found the joke much less fun on the day after <forgetful>I can't run the executable I compile because it cannot find some shared library, it turns out $LD_LIBRARY_PATH is not set, if I set it, it works. I think $LD_LIBRARY_PATH is not set for a reason and I do not want to set it. What is the right way to do it? Can anybody help me? <civodul>rekado: i think i considered this was something we could make fun of because he was going to disappear from our lives <civodul>paroneayea: that any package manager implemented a half-baked, bug-riddled version of Guix? :-) <civodul>rekado: "virtual dependency" means that packages can depend on abstract specs, like "mpi", which then get filled in by a concrete dependency, like "openmpi" <lfam>I'll let others re-discover and re-evaluate the commits that don't pass `git verify-commit` :) <civodul>lfam: so this lists commits with invalid signatures, right? <lfam>Hopefully after 0.12.0, there will be none <lfam>It prints all commits that fail `git verify-commit`, which includes unsigned commits. <lfam>If I read the output correctly, all the "failing" commits are unsigned, from before we decided to sign everything <civodul>normally there are no unsigned commits since we installed the hook, no? <lfam>I believe so, but that's why I said I'll let others rediscover them :) <lfam>It should not require much attention after 0.12.0 <f52sn>It seems that I can't do anything without using the --fallback option... <f52sn>lfam: I tried 'guix package -i arc-theme' and after a while it failed with something like 'guix package: error: build failed: some substitutes for the outputs of derivation '/gnu/store/<hash>-module-import-compiled.drv' failed (usually happens due to networking issues); try '--fallback' to build derivation from source <lfam>f52sn: Ah, that's a known issue. Indeed, use --fallback. Only the failing substitutions will be rebuilt from source, and those modules are not too expensive to build. You should still get substitutes for the packages that we have built, which is most of them. Although a couple big ones like libreoffice and icecat don't seem to have substitutes ATM (soon) <lfam>sneek: Forget --fallback <lfam>sneek: Eat a moldy botsnack <lfam>f52sn: If you get a substitution failure for a package, please report it so we can remove it from the mirrors <lfam>It's hard for me to stay motivated to update our Jasper package, since only two things depend on it. But there is a steady stream of serious bug fix updates happening now, so it would be good if some motivated person could try to stay on top of it. Kodi and libicns users... <civodul>lfam: yeah, Jasper doesn't seem to be in a very good shape <civodul>a bit like all the image libraries, except it's probably younger <lfam>It was abandoned for many years. Recently someone started developing it again, and I think the fuzz testers are helping them find bugs <lfam>"Someone", I mean the original developer <lfam>They are releasing almost every day, but the releases don't always build successfully <lfam>It could be some Kodi user's pet project <lfam>What I meant is that some Kodi user could pay special attention to our Jasper package <lfam>Since Kodi is one of the two dependent packages we have, and probably the package with broader appeal and more exposure to untrusted JPEG2000 files