<rekado>it comes with support for different format readers and handles annoying stuff like RSS.
<ng0>I came to like a push to publish thing I wrote before I temporarily retired what I used
<ng0>some minimalistic cms with markdown and dhtml
<rekado>the "shogun" package is broken since the upgrade from Octave 3.8 to 4.
<rekado>it's odd because it complains about an undefined "do_octave_atexit", but this procedure has not disappeared in Octave 4.
<ng0>ashort update on gnunet-svn: I pinned to a version I was told is usable (before the refactoring started), but I'll only sent the patches once I have a functional system service for it, which at the moment requires debugging and learning through my git-daemon-service
<ng0>I wished these 2 or 1 tests out of hundreds would not break, if enabled check/tests it hangs at the last check of tests round, 2 tests before that are skipped.
<ng0>as noted in the gnunet-fs integration thread, 0.10.2 of gnunet is "around the corner" so it will be release after this summer, with no specific date set - refactoring requires some rewrites
<rekado>personally, I find the name overlap unfortunate
<ng0>i would not know at this moment how much pure and guix service differ
<ng0>for gnunet it would be easier to write a guix system service, as it is config file based. git is not. and while I almost have it, I'll need to add back some values and try again.
<ng0>gnunet has more priority I'd say, but git is something which is smaller.
<ng0>what I definitely not understand and have not looked at so far is service expanding
<ng0>whydo some services export 'name'-service-type in addition to 'name'-service ? just because not everything is included in -service?
<ng0>most systems put the git user into /var/git for a home (for plain git, with access via git+ssh for the pubkeys). I have selected this directory as well, and will also use /var/gnunet for gnunet (the default iirc). is there anything against using /var/ for this? I assume it's okay
<ng0>I'd like to have a guix gnunet service first, but also expandable/refactoring to a generic shepherd service later. I assume at the moment guixsd is the only system using shepherd.
<ng0>generic service files can be included in gnunet upstream, specific ones not (and for guix it makes no sense to be included somewhere else when I aim for master tree)
<rekado>the service-type stuff is used so that a user can modify the service easily
<rekado>the service framework is very comprehensive and can be used for many neat things.
<rekado>if all you want is to have the equivalent of a systemd service (e.g. starting some daemon) then you need little more than a simple shepherd service definition.
<rekado>if that's what you want I suggest playing around with user-level shepherd.
<ng0>the (lirc lirc) in the lirc service refers to the user or package name? I renamed my service definitions from git-daemon-* to git-* once, but I'd like to prepend git services with git- in the future
<rekado>you can install shepherd into your profile, edit ~/.config/shepherd/init.scm and then start it as a user.
<rekado>I'll upload my service definitions to my server some day.
<ng0>for gnunet i need and want more than a simple service. for git is just taking some arguments and creating the user+group
<ng0>when in (define-record-type) I have among other lines: (git-daemon git-daemon-configuration-git (default git)) which i understand is for the output/package, (git git) in define git-daemon-service is wrong. would (git-daemon git) be accurate, or even (git-daemon git-daemon)? the rest I do understand as it is set and used before, but this I do not understand so far.. for every service there is a (name name) in
<ng0>the end. name or output? of service or package?
<rekado>ng0: could you give an example of a service like that?
<ng0>git daemon takes the argument --port=number (at least from what I remember with most systems, if it doesn't I'll find out soon enough). I let conf be a string-append where also "--port="(number->string port) is included. as the default is a number, 9418, I should not need this however I think I have seen a service where it number->string was used for this. I have yet to successfully run a VM when the service is
<ng0>ready, but there should be no need for number->string
<ng0>bitlbee does that, but it also writes this to a file, so it's different from what I do *I guess*
<ng0>woo :) I'm getting different errors now. once which are easier to fix.
<ng0>i have it almost working, but I think there are some last problems. the variable git-daemon does not get initialized, I'll compare to bitlbee again to see if I can solve it on my own, else I'll send an email with a patch
***marxistvegan is now known as marxistvegan_
<bavier>is substitute* an acceptable way to remove a line from a source file?