IRC channel logs
2014-01-23.log
back to list of logs
<jmd>Hydra is unresponsive again. <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>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>Hydra is hosted at MIT? <jmd>They should have good connectivity! <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>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>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>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 :-) <jmd>Do we have a package for man ? <civodul>i started looking at it but it's annoying <jmd>In what sense is it annoying? <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>Civodul: do you have a second to chat about the dmd manual? <atheia>sriharsha: you've recently started adding packages/updates right? <atheia>Congrats on those, nice to see newcomers :-) <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 hasn't checked email there yet <atheia>And I can see myself going through the entire manual if that's desirable. <civodul>well, you can still have lunch in the meantime <atheia>I used the fancy git-send-email command Cyrodil mentioned <atheia>And when I said Cyrodil I meant Cyril of course — must reign in my Elder Scrolls gaming… <civodul>sriharsha: BTW, thanks for the patches! <civodul>i hope it's not too hard to cope with the conventions & co. ;-) <civodul>zerwas: no, i only update the HTML copy when a new release comes out <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 <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 <atheia>Great — I'll correct the other points you mention and will re-submit when I get a chance. <Sleep_Walker>zerwas: new version is being baked - init script (and update logic) is in, users for build are generated *sriharsha hi5v5 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 :) <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' <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 <zerwas>Yeah, I hope this will be fixed soon :( <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 <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. <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.