IRC channel logs


back to list of logs

***exio4 is now known as Exio4
***exio4 is now known as Exio4
***Exio4 is now known as exio4
<civodul>Hello Guix!
<mbuf>how do people run guix for testing?
<civodul>mbuf: you mean to try Guix out?
<mbuf>civodul: yes
<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
<civodul>mbuf: as efraim says; see
<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)
<mbuf>alezost: okay
<civodul>ACTION considers putting a new item on Savannah for the GNU/Hurd port, the ongoing mips GuixSD port, and the new ARM machines
<civodul>*news item
<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>but rebasing the code is a nightmare :P
<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>don't worry, I will manage it :-)
<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
<civodul>new news:
<davexunit>awesome :)
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, civodul says: see about systemd's startup notifications
<davexunit>civodul: what was the context of this note?
<civodul>you mentioned having problems with some daemon for which you wrote a service definition
<civodul>was it nginx?
<civodul>anyway, it seemed relevant
<civodul>you'll tell me if it really is ;-)
<davexunit>nginx pretty much has to be run as a daemon
<davexunit>the non-daemonized mode is very limited
<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?
<davexunit>sounds like the right approach.
<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>yeah, nix-daemon is systemd-aware
<civodul>it can receive an open file descriptor via an env.var
<civodul>oh but that's for socket activation
<davexunit>well that doesn't sound so bad
<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>submitted the news about porting to HN just for kicks:
<davexunit>upvote if you feel so kind
<davexunit>thanks! I meant to do that :)
<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
<davexunit>newuidmap and newgidmap being programs
<civodul>davexunit: could it be that the OP run the tests as root, which somehow lead to EPERM?
<civodul>'shadow' was updated recently
<civodul>it has these two programs
<cehteh> ... teheee :)
<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
<cehteh>thats what i meant
<davexunit>cehteh: :)
<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
<civodul>possibly useful deterministic build patches to borrow from