IRC channel logs

<civodul>Hello Guix!

<Sleep_Walker>:)

<jmd>Hydra is unresponsive again.

<civodul>hmm not sure why

<civodul>i can ssh into it and it doesn't seem to be particularly busy

<civodul>we definitely need to find another front-end

<jmd>Is it just a case of a machine with good io or does it need to be more than that?

<civodul>lots of memory and CPU power too

<civodul>well, ideally the front-end would not build things itself

<civodul>but currently there's one machine doing everything

<jmd>That's what I am hinting at. There could be a machine (with limited connectivity) doing the building and another (with limited CPU / memory) serving up requests.

<jmd>They don't even need to be in the same country.

<jmd>Oh now it goes!!

<civodul>just restarted the web server :-)

<jmd>Hydra is hosted at MIT?

<civodul>yes

<jmd>They should have good connectivity!

<civodul>they do

<civodul>but the machine is a VM, not very powerful, etc.

<jmd>How much CPU / Disk / Memory would be necessary for a build server?

<jmd>ie, A machine building packages and pushing them to hydra.

<jmd>How come this is failing:

<jmd>starting phase `patch-generated-file-shebangs'

<jmd>patch-makefile-SHELL: ./examples/Makefile: changing `SHELL' from `/bin/sh' to `/nix/store/97vnvqq5daji73b71v4cnmyaa7r3hzk2-bash-4.2/bin/sh'

<jmd>phase `patch-generated-file-shebangs' succeeded after 0 seconds

<jmd>starting phase `build'

<jmd>make: /bin/sh: Command not found

<jmd>Makefile:24: recipe for target 'all' failed

<jmd>make: *** [all] Error 127

<jmd>

<jmd>Is there a problem with the patch-shebangs or is it another issue?

<civodul>jmd: you'd have to find where that /bin/sh comes from

<civodul>from a Makefile it seems

<civodul>and perhaps it's in a place where it isn't patched

<civodul>because patch-makefile-SHELL only patches forms like "SHELL = /bin/sh"

<jmd>I found it. It was in an included makefile.

<civodul>ok

<civodul>so you'll probably have to patch it by hand

<jmd>Couldn't patch-makefile-SHELL be made to follow included files?

<civodul>well it would have to parse makefiles, so...

<civodul>dunno if you can find a simple and robust way to do it, that could be nice

<jmd>As I recall, include directives can only occur at the start of a line so that would be easier.

<civodul>but it's not clear to me that we can meet this criteria :-)

<civodul>*these

<jmd>Do we have a package for man ?

<civodul>not yet

<civodul>i started looking at it but it's annoying

<jmd>In what sense is it annoying?

<civodul>silly build system

<jmd>oh

<civodul>so feel free to give it a try :-)

<Sleep_Walker>zerwas: http://goo.gl/giyJbE <-- guix packages for openSUSE and Fedora

<civodul>Sleep_Walker: nice!

<civodul>so everything eventually worked?

<civodul>maybe you could email guix-devel

<civodul>the "New in this release" of the GNU Parallel announcements is always fun

<Sleep_Walker>civodul: yes, worked, but still it is experiment and have a lot of warnings from security audit, non FSH compliant file placement etc...

<Sleep_Walker>and I haven't tried it even once as I'm on gentoo now...

<atheia>Hi Guixers!

<sriharsha>Hi!

<atheia>Civodul: do you have a second to chat about the dmd manual?

<atheia>sriharsha: you've recently started adding packages/updates right?

<sriharsha>yes

<atheia>Congrats on those, nice to see newcomers :-)

<sriharsha>thanks :)

<civodul>hey atheia!

<civodul>atheia: tell me everything

<atheia>Ah, hello — caught me just before lunch:-)

<atheia>I was just wondering whether the project would be interested in a re-editing of the manual

<atheia>I submitted a patch this morning, which essentially systematically re-wrote the Introduction whilst keeping the meaning in tact.

<civodul>oh, neat

<civodul>to guix-devel?

*civodul hasn't checked email there yet

<atheia>And I can see myself going through the entire manual if that's desirable.

<atheia>Yep, should be there

<civodul>ok

<civodul>lemme see

<civodul>well, you can still have lunch in the meantime

<civodul>i'll let you know ;-)

<atheia>I used the fancy git-send-email command Cyrodil mentioned

<atheia>OK :-)

<civodul>cool

<atheia>Speak later!

<atheia>And when I said Cyrodil I meant Cyril of course — must reign in my Elder Scrolls gaming…

<civodul>:-)

<civodul>sriharsha: BTW, thanks for the patches!

<civodul>i hope it's not too hard to cope with the conventions & co. ;-)

<sriharsha>you're welcome; no problem.

<zerwas>civodul: Hm, shouldn't https://www.gnu.org/software/guix/manual/guix.html#Setting-Up-the-Daemon have updated commands for creating guix-builder users? (being system users)

<civodul>zerwas: no, i only update the HTML copy when a new release comes out

<zerwas>Ah, makes sense.

<zerwas>Sleep_Walker: looks great! :) Two more things that come to mind: Automatically creating the users would be nice. Also, do you think the initd script by sriharsha could be shipped? https://gnunet.org/content/gnu-guix-initd-script

<Sleep_Walker>zerwas: I'm just reading daemon configuration :)

<zerwas>I see :). Just a note: When you use the "useradd" command, add the parameter -r so the users don't show up at the login manager

<Sleep_Walker>we have probably some RPM macro for that

<zerwas>even better

<atheia>Civodul: quick question about your review about my patch:

<atheia>> +dmd is the @dfn{init system} of the GNU operating system---it is the

<atheia>> +first user process that gets started, typically with PID 1, and runs

<atheia>> +as @code{root}. Normally the purpose of init systems is to manage all

<atheia>> +system-wide services, but dmd can also be a useful tool assisting

<atheia>> +unprivileged users in the management of their own daemons.

<atheia>Currently the manual says “It is also a useful tool that assists

<atheia>unprivileged users in the management of their own daemons.” I think it

<atheia>would be nice to keep that information somewhere, though I agree it

<atheia>sort-of gets in the way currently. WDYT?

<atheia>mhmm... That didn't work quite as intended, sorry for the flood.

<atheia>The point about dmd being useful unprvileged users is still present in the final part of the re-written paragraph.

<atheia>Do you feel it get's lost where it is?

<atheia>Or do you feel the meaning has changed?

<civodul>atheia: aah no, sorry, i had overlooked it

<civodul>then it's perfect

<atheia>Great — I'll correct the other points you mention and will re-submit when I get a chance.

<atheia>Thanks

<Sleep_Walker>zerwas: new version is being baked - init script (and update logic) is in, users for build are generated

<civodul>atheia: cool, thanks!

<zerwas>Sleep_Walker: awesome!

<Sleep_Walker>not compatibile with systemd though

<Sleep_Walker>but it looks like distro bug, not init script issue

*sriharsha hi5v5 Sleep_Walker

<Sleep_Walker>:)

<Sleep_Walker>thanks for bringing me in, I'm reading guile tutorial and I'm quite amazed

<zerwas>thanks for helping with the project!

<Sleep_Walker>linking guile and C code - I wasn't aware of the posibilities... and I moved from ViM to Emacs some time ago but still hadn't time for programing with lisp

<mark_weaver>Sleep_Walker: If you're interested in Guile, I think you'll find #guile to be very helpful and friendly :)

<Sleep_Walker>thanks

<mark_weaver>jmd: fyi, RMS confirmed that the gnuplot license is free, so 'fsf-free' is appropriate.

<jmd>Ok. Thanks for taking the time to find out.

<jmd>BTW, I think we could do a lot more with (license) field...

<sriharsha>I update guix and now having *** No rule to make target `nix/libutil/affinity.cc', needed by `nix/libutil/libutil_a-affinity.o'. Stop.

<sriharsha>ok, its working now; had to clean nix and then syn-with-upstream

<Sleep_Walker>zerwas: it seems that there are some more problems with ownership of some paths

<Sleep_Walker>guix package: error: build failed: builder does not have write permission to `/nix/store'; try `chgrp 490 /nix/store; chmod 1775 /nix/store'

<Sleep_Walker>490 is GID of my guix-builders group

<zerwas>yeah, the store permisions need to be fixed, I forgot to mention that

<zerwas>I don't know if it's a bug in guix or supposed to be that way

<Sleep_Walker>I can add it to package

<Sleep_Walker>neither do I

<Sleep_Walker>the other path was missing /var/nix/profiles/per-user

<Sleep_Walker>I'd think this could be created by guix

<zerwas>Yeah, I hope this will be fixed soon :(

<Sleep_Walker>it's just detail

<mark_weaver>I think the idea is that /var/nix/profiles/per-user/* should be created when new users are created.

<mark_weaver>well, I think that's how it will work in the Guix standalone distro anyway.

<mark_weaver>but the guix command is normally run as non-root, so it can't do it.

<mark_weaver>guix-daemon could theoretically do it, but messing with user profiles is not part of what it does.

<Sleep_Walker>mark_weaver: missing dir was /var/nix/profiles/per-user/ itself

<Sleep_Walker>that needs to be created with proper rights and ownership

<Sleep_Walker>and than guix running as user could create user's profle

<Sleep_Walker>(but that is just wild guess)

<mark_weaver>well, I think /var/nix/profiles/per-user shouldn't be world-writable.

<Sleep_Walker>I can create this directory as part of package, but it's somehow weird as /var/nix/profiles/ was made automatically

<mark_weaver>hmm, I'm not sure why per-user is not created along with everything else. You'd have to ask civodul about that.

<mark_weaver>as far the directories in 'per-user', it may be that it should be left as a policy decision which users have those. e.g. not system users.

<Sleep_Walker>you mean like having group guix-users?

<Sleep_Walker>nevermind, it looks like it works

<mark_weaver>well, I didn't envision a group for it, but maybe based on whether --system is passed to useradd, or something.

<mark_weaver>or based on whether the UID is in the SYS_UID_MIN-SYS_UID_MAX range.

<mark_weaver>could be anything though. it just seems like you don't necessarily want 'nobody' to be able to run 'guix' and have a profile directory created automatically.

IRC channel logs

2014-01-23.log