***fxbjqywmr is now known as jje
<sturm>Any tips for having both Python 2.7 and 3.5 available at the same time? It seems my `python2.7` command has disappeared now I've locally installed 3.5. Or maybe I'm confused... <sturm>Or is this really where I need to look at `guix environment`? Do `python2.7` and `python3.5` symlinks not really coexist as they do in say Debian? <geemili>sturm: I have python2.7 and python3.5 both installed. <sturm>thanks geemili, I'll do some experimenting - if I install python@2.7 it does seem to remove `python2.7` from my path and vice versa. I could have sworn I had them both at one stage, like you. <sturm>sorry remove `python3.5` I mean <geemili>sturm: Have you tried installing `python` and `python2`? <sturm>geemili: ah clever! This worked: `guix package -i python@3.5 python@2.7`. Thanks! <geemili>sturm: Glad that worked for you, but you can just do this: `guix package -i python python2` <geemili>python2 is it's own package, without needing a version specifier <sturm>geemili: oh, I don't seem to have a `python2` package, maybe it's newish? <sturm>my packages list is probably a few weeks old <geemili>sturm: Oh. I thought it existed. Just ignore me then. <sturm> Do you know if it bothers Python having both 2.7 and 3.5 site-packages on the PYTHON_PATH? <sturm>Hmm just tested and it does seem to try to load 3.5 libraries into 2.7 if I have two `export PYTHONPATH=...`entries, one for each version. ***jim_ is now known as jje
<bavier>JamesRichardson: paroneayea has been trying to do such a thing recently <baconicsynergy>So, I'm still getting the hash mismatch for module-import-compiled on the live media. amz3 somehow got it to work earlier but never said how... <bavier>baconicsynergy: use the --fallback option <Apteryx>Hi Guix! Any idea how to inspect the effect of a substitute* rule on the source files? <jmd>Apteryx: diff the old and new versions? <Apteryx>I guess I could run the build command in the interpreter with a breakpoint at the right place? <Apteryx>jmd: But when is the altered source kept? In the built derivation, there is no more sources. <Apteryx>jmd: Will this work if my build doesn't fail? <jmd>What I do, in those circumstances is to force it to fail at the relevance phase. <civodul>or just Ctrl-C in the middle of the build <jmd>rekado: The image on bootstrappable.org is cropped on my browser. <Apteryx>The problem now is that I already successfully built it once, so I cannot interrupt the build process... it just quickly print the built derivation URL in the store. <Apteryx>Nevermind, I just tweeked the source enough to trigger a rebuild with make and then I was set. <rekado>civodul: I see that the update to 4.9 has been reverted and an update to 4.8.15 has been pushed. <rekado>civodul: should I rebase version-0.12.0 on top of master and revise the package addition/upgrade count? <civodul>rekado: you definitely need the linux-libre "downgrade", as well as a few other commits (translations & doc at least) <civodul>whether you rebase or cherry-pick is up to you :-) <jmd>Rebasing to a branch currently published will give problems if you ever push to that branch again. <civodul>rebase or merge, either way is fine with me <rekado>I was thinking: rebase on top of master, force push. “version-0.12.0” only becomes stable with tagging the release. <rekado>civodul: thanks for the documentation fixes! <jmd>rekado: Did you see my earlier comments about bootstrappable.org ? <rekado>jmd: about the image being cropped? <rekado>jmd: the big one or the small one (on the sub-pages)? <jmd>The window is wide, but it looks like the .css limits it somehow. <rekado>I see that it doesn’t behave well when the browser window is about 600px wide. <rekado>I don’t see this in Icecat or epiphany <jmd>I'm using torbrowser <jmd>On the main page I see "Bootstrappable Bui" <jmd>On the movation page I see "Bootstrappable Builc" <rekado>jmd: okay, thanks. I’ll investigate this after the release. Will also add the link. <rekado>v0.12.0 tagged, release branch created, jobset for release branch created on hydra <rekado>bleh, I get test failures during “make distcheck” <rekado>builders, derivations, packages, union, lint, containers <rekado>maybe that’s related to running inside of “guix envirnoment --container”…? <rekado>so I guess I’ll actually have to do this on my GuixSD laptop, adding an external drive to prevent running out of space. <rekado>copying over the store now, then bind-mount to /gnu and restart the daemon. Then I should have sufficient space for building the images. <jmd>rekado: I appreciate the hard work you're doing on this no-fun job. <rekado>I think a big part of the difficulty is because I’m doing this for the first time <jmd>Hmm. We'll have to make a rule that nobody should ever do anything for the first time. <jmd>(anyway I'm certainly glad it kept you away from the Weihnachtsmarkt) <geemili>jmd: Should I do a `sudo guix pull`? <rekado>geemili: “sudo guix pull” updates the guix command for the root user. <rekado>to update your packages do “guix package -u .” as the user whose packages you want to update. <rekado>for the system profile use “guix system reconfigure /path/to/config.scm” <rekado>civodul: distcheck failed with an error at the very end: <rekado>ERROR: files left in build directory after distclean: <rekado>Is this related to 5a5fc61f072eaa7fe9bfa65dbbd4c6215d88626c ? <jmd>rekado: It looks like the author forgot to add those to CLEANFILES <rekado>jmd: ah, I see. I’ll add them to CLEANFILES in nix/local.mk <civodul>rekado: i just pushed the fix to master, you can cherry-pick it <rekado>civodul: is it a problem that this happens after the tag for v0.12.0? <civodul>rekado: it's best if the tag really corresponds to the checkout used for 'make dist' <civodul>i think it's ok if you delete the remote tag, it hasn't been there for long <civodul>what i do is keep a local tag, and push it only once 'make dist' has succeeded <rekado>release.org says to first push the tag, then run distcheck. <rekado>(I ran “make check” before pushing the tag, though) <jmd>The Soyuz numbering system!! <rekado>while make distcheck is running I’ll work on the text of the announcement <djLeGit>I have a quick question about the nginx-service as described in the manual <djLeGit>does this imply that, if I only pass a config, I should have the default log and run dirs specified in my config file? <davexunit>djLeGit: correct, you will need to figure those appropriately <davexunit>the nginx service needs work, but I would recommend passing files in vhost-list instead <djLeGit>davexunit: Could you link to me a piece of the manual that describes this? <davexunit>guix will generate the right config for user/group, where the pid file goes, the default log and run dir, etc. <davexunit>if you don't want to do that by yourself, use vhost-list <djLeGit>davexunit: I found some pretty good pointers in the manual in the master branch. Thanks for the guidance <paroneayea>bavier: I am cwebber, depending on the context fwiw ;) <paroneayea>there's another "cwebber" in the free software area (also known as chris webber) who has the username cwebber here, unfortunately <civodul>djLeGit: but this is WIP, there are improvements to this submitted to the mailing list <paroneayea>I don't think 8sync will really be usable by anyone else until next release, but maybe it's time to package it for guix anyway <djLeGit>on a totally different note: are per-user services something that is somewhere on the guixSD roadmap? <civodul>there are no concrete plans but it's been discussed a few times <paroneayea>djLeGit: I think we've discussed it before, I don't think anyone has plans to work on it but it could maybe be possible if we can reduce assumptions that the services can control the user / have to be root iirc? I think probably first would be making "persistent profiles" work nicely <djLeGit>paroneayea: what would be the difference between persistent environments and profiles? <paroneayea>djLeGit: so here you'd want to be able to say, "hey, set up an environment here, and keep it at that directory" <paroneayea>one of those things that's generally wanted here, but nobody's gotten to <paroneayea>would make using guix for development environments a lot nicer <paroneayea>especially if your development environments happen to pull in texlive ;) <djLeGit>Can't live with texlive, can't live without it ;) <paroneayea>djLeGit: anyway, are you new here? if so, welcome! <djLeGit>paroneayea: I've lurked several times before, using different handles ;) <djLeGit>how many more-than-once contributors does guix have? <paroneayea>we're now over 40 contributers per month, impressive! <djLeGit>davexunit: The nginx vhost related stuff works like a dream :D <djLeGit>although I don't think ngingx call these things vhosts. Seems more apache like <djLeGit>I've been trying to run away from apache's config hell for ages ;) <jmd>Apache certainly has a knack of making jobs which should be rather simple into a very complicated affair. <davexunit>but what to change it to? that's the question I can't answer <djLeGit>meh, it is probably good enough. At least it's not confusing as to what it refers to <davexunit>I agree that it's too apache-like. nginx doesn't use the term "virtual host" anywhere in its documentation. <djLeGit>is it possible to configure guix (not guixSD) to use different paths instead of /var and /gnu/store? <davexunit>if you use something other than /gnu/store, you will not be able to use any of our pre-built binaries. <djLeGit>davexunit: that is to be expected :-) <djLeGit>the short of it is that I would like to try to get a guix running on top of Replicant <davexunit>but there are configure switches for all of these things <djLeGit>davexunit: I know! Abysmal build times, here I come :D <davexunit>if you could somehow do the builds on a more powerful arm machine first... <davexunit>but finding any ARM chip that do build software quickly is unlikely <rekado>guix package: error: build failed: while setting up the build environment: unable to make filesystem `/gnu/store' private: Invalid argument <rekado>background: I bind mount /mnt/gnu to /gnu (because there’s more space on the system at /mnt) <civodul>rekado: this has to do with clone(2) and MS_PRIVATE <rekado>looks like “mount(0, "/gnu/store", 0, MS_PRIVATE, 0)” fails <civodul>now i can't tell you why that happens :-/ <djLeGit>Is anyone using an ssd cache + large spinning rust with GuixSD? <djLeGit>civodul: All the more power to you :-) <civodul>i suppose someone willing to speed up builds could have /tmp on SSD and /gnu/store on a spinning disk <rekado>civodul: is it normal that after gnupload I can’t immediately download from alpha.gnu.org? <civodul>rekado: yes, it can take a few minutes <civodul>normally we receive a notification by email <civodul>i share the stress you experience ;-) <jmd>I'm having trouble getting guix system container to do anything sensible. <efraim>do we package libdns under a different name? <efraim>the gnupg-2.1.17 release notes say it removes support for adns and uses & bundles libdns <jmd>efraim: We have bind. Is that what you mean? <efraim>from the README: dns.c is intended to be dropped into existing project builds. The included Makefile is mostly for development and testing. <jmd>and what does it do? <efraim>it bills itself as "A non-blocking DNS resolver library in a single .c file" <jmd>suspect we don't have it. <ng0>I figured that "look, a work in progress package / please anyone finish this if you'd like to" doesn't work at our size yet, so expect some action on old threads/patches in the next hours/days/weeks :) <ng0>is there anything wrong about this: (add-before 'check 'fix-tests (lambda _ (with-directory-excursion "tests" (substitute* '("kakasi-1" "kakasi-4" "kakasi-5" "kakasi-6" "kakasi-7") (("/bin/echo") "echo"))))) nevermind any parens I might've forgotten, this is taken out of context .. this fails at kakasi-4, not -1 <rekado>civodul: after make distcheck I have quite a few po files that have changes. Should these be committed or should I ignore them? <ng0>i think I can take the shortcut and do it with find-files <ng0>no, find files doesn't work in this case. is there any mistake in the (add-before) I wrote? otherwise I have to look at the files more closely <rekado>argh! I didn’t notice (package-arguments guix-0.11.0) in guix-devel! <rekado>and the remote refuses my naughty attempt to rewrite the commit <civodul>or you can delete the branch and re-push it <rekado>but there’s already a hydra evaluation for the branch <ng0>the guile backtrace reads as if line 11 of tests/kakasi-4 is causing some error, line 11 does read: . ./env.sh , where env.sh in the folder is a simple file which includes two variables <ng0>if I leave kakasi-4 out, the substitute succeeds.. curious. <civodul>rekado: we can cancel it and restart it <ng0># (require: GNU echo, GNU od) <ng0>ah.. some basetool I suppose <ng0>how do I make it accessible to the build system? <ng0>this failed: ret=`cat tmp|od -t oC -w80|head -1|sed -e 's/^0* //'` <rekado>civodul: hmm, the tag is on a commit on that branch, and the uploaded release tarball uses it <rekado>but maybe this doesn’t matter because I won’t throw away my local commits. <civodul>rekado: if in doubt, just make an additional commit, that's fine <civodul>once you're done, we'll discuss the release process ;-) <ng0>what's with this weird kakasi-4 file that it defeats all rules of substituting <ng0>i'll try to fix this in the next weeks.. this is weird. ***roptat_ is now known as roptat
<davexunit>ACTION stomps floor and chants "guix re-lease! guix re-lease!" <jmd>ACTION serves davexunit with an antisocial behaviour order <newdan>Is there gonna be a release soon? :D <jmd>newdan: At Christmas ... if you're good. <civodul>cool, lemme know if you need something <efraim>way off topic, is there a compose + key combo for € ? <rekado>civodul: guix-binary.mips64el-linux.tar.xz cannot be built because it wants to build guix, but I don’t have a mips64el machine. Same problem for armhf, I think. <civodul>rekado: yes, we need to make them on hydra.gnu.org <civodul>rekado: is that with the tip of version-0-12-0? <civodul>c8e2219cfb914429b6409dbef1491652b910f70b, right? <rekado>(I deleted and recreated the branch with the fixed commit) <rekado>c8e2219cfb914429b6409dbef1491652b910f70b, right <civodul>rekado: tarballs for arm & mips are being built! <civodul>well, the mips box has a clock issue <civodul>mark_weaver: could you fix the clock on hydra-slave0? <rekado>civodul: when they are built on hydra, how does the signed upload work? <rekado>or are these just substitutes that I can download in the process of building the guix-binary tarballs? <civodul>rekado: yeah these are just substitutes <rekado>civodul: thanks for the clarification. <civodul>oh, funny there's 1 test failure on armhf <rekado>it was “tests/guix-register.sh” when creating the disk image for x86_64 <rekado>ACTION finds it hard to stay concentrated <lfam>I'd like to interject to say Thank you! rekado and civodul for working on the release! <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, albertoefg says: to pm to play hedgewars <civodul>rekado: do you manage to build one of the two images? <rekado>I’m still building the i686 image <rekado>it’s pretty slow here on my laptop <rekado>would have been great to do this on the office workstation in a container, but that led to test failures. <ng0>do we have chmod -R for our (chmod) function? <ng0>well, question for both <efraim>lfam: have you sent an email to the exim people about getting early access to the next release for CVE-2016-9963, or are we waiting for the 25th with the rest of the plebians? <rekado>civodul: the i686 image is ready now :) <lfam>efraim: Yes, we will have early access to the fix <civodul>rekado: awesome! the arm tarball is running tests again <ng0>so one problem I have: the gnunet-service needs to create files after it is started (bootstrap servers etc). I chmod and chown stuff in advance, but things like /var/lib/gnunet/hostlist/learned.txt get created by root, therefore they are rw only by root and no one else, preventing a bootstrap to ever happen <ng0>ialso suid, but I know I miss the two binaries for gnunetdns group <ng0>this is however very unrelated to bootstrap in my experience <civodul>by "root" or by some unprivileged "gnunet" user? <ng0>ah, harmut just wrote I should look at postgres service more closely <civodul>ng0: yeah, many services have similar requirements <davexunit>I have some thoughts about improving usability here, but this is a great start! thank you! <ng0>the reason for the system service is so that gnunet can be run as a system service (user gnunet, group gnunet; additionally one gnunetdns group fo <ng0>the reason for the system service is so that gnunet can be run as a system service (user gnunet, group gnunet; additionally one gnunetdns group) and users (people, accounts, etc) can just be added to the gnunet group and run the functions. the problem I'm facing is that somehow suid seems not to be enough, and I have to replicate what we did for gentoo in some other way, where I'm now positive postgres service <civodul>davexunit: yes that was just a low-hanging fruit, and i was tired of redownloading the stuff for my environment at work :-) <ng0>one way to speed this up: read the bugtracker and get involved fixing the cadet bugs <jmd> How do I set the default keymap? <nliadm>I'm trying to run weechat from guix (on top of fedora) and it can't do https. Setting SSL_CERT_{FILE,DIR} doesn't work, either <civodul>rekado: same test failure in tests/guix-system.sh on arm but i don't have access to test-suite.log <ng0>civodul: i don't see in gnu/services/cuirass where cuirass switches the user <civodul>ng0: the #:user argument to 'make-forkexec-constructor' <ng0>lfam: 0.2.5.x i don't see how this affects guix <civodul>lfam: thanks for the heads-up; it's low on details ;-) <lfam>I don't know Tor's release strategy, so I don't know what versions are vulnerable and which aren't. It's just a "heads up" :) <nliadm>it looks like weechat is built against openssl, so it should be honoring those environment vars. and the files they're pointing to exist <lfam>nliadm: And do the SSL_CERT variables point to something that exists? <lfam>We've had similar problems with other users of libcurl <lfam>nliadm: Can you file a bug? <ng0>civodul: hm.. aha! this is exactly what I did not set. so and setuid.. I need to setuid 2 binaries to gnunetdns, I suppose setuid is also documented somewhere <nliadm>okay, I'll send one when I get a chance <efraim>lfam: I pushed the update to tor without seeing that it had a CVE attached to it <efraim>their email to debian-security listed the 0.2.9.something as the "upgrade to" version for testing/sid <lfam>efraim: Okay, thanks for looking into this :) <ng0>WOO. i finaly get more output than before.. I hope i'm getting this done by 2016-12-31 <rekado>ERROR: In procedure copy-file: Success <rekado>oh… I think I *cannot* build the disk image for x86_64 at all on this laptop <rekado>the guest gets a kernel panic because I’m using Libreboot and the CPU feature for virtual extensions is broken <rekado>I’ll try again building this on my workstation in the office <civodul>rekado: that error suggests ENOSPC, no? <civodul>(an error-report bug i've become used to) <rekado>but I still have about 6GB left on / <civodul>if you managed to build the i686 image, i'd expect the x86_64 one to work as well? <rekado>I’m not thinking straight today, feeling sick <rekado>I just kicked off the build on the remote; let’s see how far it gets. <civodul>rekado: sorry that this is so tricky; it's usually a little less hard <civodul>lfam: thanks for the heads-up! i can't handle 'em right now :-/ <lfam>What do you think we should do given the comment in the package definition "Newer versions such as 4.2.3 bundle a copy of AngularJS."? <civodul>dunno, i don't think we could unbundle it in a meaningful way <civodul>we'd need the npm importer and all that--out of reach <civodul>rekado: the test failure on arm may be determinstic; entering debugging mode... <civodul>we should have caught it earlier, that sucks <rekado>then we can try this again once the arm error is fixed. <civodul>rekado: no, keep the tag, the tarball is out there already <rekado>I’ll try to finish this tomorrow morning. Even on the workstation space doesn’t seem to be onough <rekado>is it the --image-size argument? <rekado>I’m running ./pre-inst-env guix system disk-image --image-size=850MiB gnu/system/install.scm <civodul>i should have mentioned it earlier i guess :-) <civodul>re arm/mips, at worse the binary tarballs will be built from one commit later, no big deal <civodul>anyway, surely everything will be ready tomorrow! <rekado>I’m going to get some sleep now lest this headache gets any worse <rekado>…and the disk image just built :) ***jz is now known as Guest2791
<buenouanq>how can I deal with something that is looking for things via explicit paths? <buenouanq>an installer wants to run chmod, but it's actually doing /bin/chmod or something I think <civodul>buenouanq: patch out the absolute file names <civodul>there are examples of that in the packages <civodul>rekado: for tomorrow: 64b5e4137649be75c6f4ea37991be95a23844a95 fixes the issue <civodul>we could cherry-pick it in version-0.12.0, then change guix-devel to refer to that, then build the two missing tarballs from there