IRC channel logs


back to list of logs

<civodul>Hello Guix!
<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?
<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>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>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>not yet
<civodul>i started looking at it but it's annoying
<jmd>In what sense is it annoying?
<civodul>silly build system
<civodul>so feel free to give it a try :-)
<Sleep_Walker>zerwas: <-- 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!
<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 :-)
<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>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 :-)
<atheia>Speak later!
<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. ;-)
<sriharsha>you're welcome; no problem.
<zerwas>civodul: Hm, shouldn't 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?
<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.
<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>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/', 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.