***exio4 is now known as Exio4
***exio4 is now known as Exio4
***Exio4 is now known as exio4
<mbuf>how do people run guix for testing? <mbuf>civodul: sorry, was away <efraim>You can install guix on top of an existing GNU/Linux system by installing using the tarball and that works pretty well. Or you could build it from the git repository if you want to hack on it <mbuf>efraim: is there a VM that I should use? <mbuf>I don't want to disturb my host system <mbuf>civodul: I shall go through the manual; thanks! <mbuf>this line is incorrect? "# ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix" <mbuf>there should be a space before /bin/guix <alezost>mbuf: no, there is no typo in that line. It creates a symlink to …/bin/guix in the current directory (which is /usr/local/bin) <civodul>ACTION considers putting a new item on Savannah for the GNU/Hurd port, the ongoing mips GuixSD port, and the new ARM machines <iyzsong>yes, I think the progress of hurd port and container support is very exciting. <civodul>i was planning to save container support for a future news entry :-) <phant0mas>thank god I don't have lesson to worry about <civodul>phant0mas: sorry for not really helping with the nightmare ;-) <civodul>i thought squashing some of the commits was better <civodul>but i understand it makes things more difficult on your side <phant0mas>civodul: btw how and when will we upload the bootstrap-tarballs for hurd? <civodul>phant0mas: i'll upload them when we merge the corresponding bits <sneek>Welcome back davexunit, you have 1 message. <civodul>you mentioned having problems with some daemon for which you wrote a service definition <davexunit>in systemd terms, according to this article, it would be "forking" <davexunit>civodul: nginx worked fine for me, btw. I had trouble with elogind. <davexunit>civodul: what do you think of this article in regards to future development of dmd? <civodul>well, i had the same impression as this article <civodul>namely that, unless the daemon has special integration with dmd, startups have to be handled on a case-by-case basis <civodul>our dhclient and udev services do that polling, which is inelegant but presumably about the only way to make things reliable <civodul>probably dmd should provide helper functions for these things <civodul>basically providing modes akin to "daemon" and "forking", but also support for PID file polling and the likes <civodul>then of course, socket activation would help a lot for those daemon that support it <davexunit>so all of these things *without* requiring daemons to have knowledge of the init system that manages them? <civodul>yes, we have to assume that most daemons cannot be modified <davexunit>I didn't realize that people were making them daemons systemd-aware. <davexunit>sounds like a serious break in encapsulation. <civodul>it can receive an open file descriptor via an env.var <civodul>the systemd client lib is another story, indeed <civodul>yeah the activation code looks reasonable to me <davexunit>that sounds like a generic hook for any init system <civodul>we could probably implement it quite easily <davexunit>linking against a client library sounds like the terrible encapsulation violation. <davexunit>cool, so we have a daemon that we know pretty well to play around with for socket activation. <davexunit>and we can live hack on a userspace dmd process to get it to work ;) <davexunit>civodul: ohhh I just remembered! the services I was talking about before were my userspace dmd processes for starting an ssh tunnel and proxy <davexunit>when starting them at the same time, there's a race condition for the tunnel to start quick enough for the proxy service to start successfully <davexunit>civodul: this clone issue is confusing, but at least we know its not a Guix issue. not sure what further action to take. <davexunit>I think that Debian has done something to cripple the use of unprivileged user namespaces <davexunit>also, I think we need an updated 'shadow', as the newuidmap and newgidmap aren't available AFAICT <civodul>davexunit: could it be that the OP run the tests as root, which somehow lead to EPERM? <taylanub>I thought that's old news by now. great work though. <davexunit>now if only people realized it that we have a much better framework for reproducibility <Steap>I wonder how they can do reproducible builds while keeping the whole Debian thing ***wgreenho` is now known as wgreenhouse`
***wgreenhouse` is now known as wgreenhouse