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 <[email protected]>:
Vincent Legoll <[email protected]> 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).
