all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ng0 <ng0@pragmatique.xyz>
To: guix-devel@gnu.org
Subject: Re: how to create and test a new service definition
Date: Sun, 14 May 2017 11:48:17 +0000	[thread overview]
Message-ID: <nycvar.YAK.7.76.1705141147530.1140@ybpnyubfg> (raw)
In-Reply-To: <nycvar.YAK.7.76.1705140855500.846@ybpnyubfg>

On Sun, 14 May 2017, ng0 wrote:

> On Sun, 14 May 2017, Catonano wrote:
>
>>  2017-05-13 22:06 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>>
>>>  Vincent Legoll <vincent.legoll@gmail.com> skribis:
>>>
>>>>>  The best way to test your code is to write an ‘operating-system’
>>>>>  declaration that uses the new service and to instantiate it in a VM
>>>>>  with
>>>>>  ‘guix system vm’.
>>>>
>>>>  Should that be working properly (out-of-the-box) when you're already in
>>>>  a qemu VM (recursive virtualization) ?
>>>>
>>>>  I ask because I'm getting:
>>>>
>>>>  [...]
>>>>  ERROR: qemu failed "qemu-system-x86_64"
>>>
>>>  What were the lines above this one?  This tool tries to use KVM if it
>>>  seems available.  Maybe in your case it “seems” to be available (as in
>>>  /dev/kvm exists) but is actually unusable?
>>>
>>>>>  Once you’ve done that, you can also write an automated test for the new
>>>>>  service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
>>>>
>>>>  I'm far from there, I have a *really* hard time getting back to guixsd.
>>>  For
>>>>  instance it took me very long time to find back the GUIX_PACKAGE_PATH
>>>>  env var. This looks under-documented, or I don't understand how one is
>>>>  to
>>>>  work on custom or new packages, etc...
>>>
>>>  ‘GUIX_PACKAGE_PATH’ is documented at
>>>  <https://www.gnu.org/software/guix/manual/html_node/Package-
>>>  Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>>>
>>>  The workflow for defining packages is described at
>>>  <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
>>>>  ,
>>>  and that for contributing them is at
>>>  <https://www.gnu.org/software/guix/manual/html_node/
>>>  Submitting-Patches.html>.
>>>
>>>  There’s probably room for improvement though.  What changes/additions
>>>  would you suggest?
>>> 
>>
>>  Let me chime in here: I'd suggest to state the workflow or defining
>>  services, as the one or deining packages is stated
>>
>>  But I'm not thinking about how to define and use The scheme structures.
>>  The
>>  examples are enough for that.
>>
>>  I'm thinking about things like how to deal with qemu, if you want to test
>>  your services in a vm
>>
>>  Is there any other way to get your feet wet with services ?
>>
>>  George suggested me the trick to link a checked out master branch to
>>  .local/guix/profile (or maybe it's the other way around: it's liinking
>>  .local/guix/profile to a checked out master branch)
>>
>>  Is anyone using this to work on services ? How, exactly ?
>>
>>  Thanks
>> 
>
> My current way of testing services is usually on bare-metal.
> I had bad experiences with one network based service (gnunet)
> and it being terrible to debug, so I took the QEMU out of there.
> I test things this way which will not break my current generation like 
> darkhttpd or the gopherd I submitted as a question.
> Other, potential boot breaking, stuff I test on other systems.
>
> This is also because I never really figured out the best way
> to run network based services in qemu in Guix. I have no issues
> with qemu, but on Guix many months back it behaved unlike the
> qemu I knew from Gentoo.

I have to append to this: I tried debugging darkhttpd with a shared VM
now and it is much more useful to get a bourne-like shell than
a frozen system if you make a syntax error in the container description.

So that's definitely a plus for the VM.

> There is lots of room for services in the documentation.
> There should be a "contributing services" section in chapter 8,
> currently I learn this the way I learned to do packages, by
> repetition and failure until I see how to debug stuff.. which is already 
> helping since I am starting to see patterns for debugging with darkhttpd (it 
> helped that it simply worked and then randomly broke in further attempts).
>
>
>
>
>

  reply	other threads:[~2017-05-14 11:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13 10:06 how to create and test a new service definition Vincent Legoll
2017-05-13 14:40 ` Ludovic Courtès
2017-05-13 15:24   ` Vincent Legoll
2017-05-13 20:06     ` Ludovic Courtès
2017-05-14  7:56       ` Catonano
2017-05-14  9:04         ` ng0
2017-05-14 11:48           ` ng0 [this message]
2017-05-14  8:44       ` Vincent Legoll
2017-05-14  9:53         ` Catonano
2017-05-15 13:26         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.YAK.7.76.1705141147530.1140@ybpnyubfg \
    --to=ng0@pragmatique.xyz \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.