Re: 02/36: gnu: guix: Use gnutls-3.6.13 when cross-compiling.

Re: 02/36: gnu: guix: Use gnutls-3.6.13 when cross-compiling.

[Ludovic Courtès]

Hello!

Time for random review comments on ‘wip-hurd-vm’.  :-)

guix-commits@gnu.org skribis:

> commit af9b4d0ba3d55ef89e956f408853548451243e95
> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Fri Apr 10 09:54:02 2020 +0200
>
>     gnu: guix: Use gnutls-3.6.13 when cross-compiling.
>     
>     * gnu/packages/package-management.scm (guix)[propagated-inputs]: When
>     cross-compiling, use patched gnutls-3.6.13.

[...]

>        (propagated-inputs
> -       `(("gnutls" ,guile3.0-gnutls)
> +       `(("gnutls" ,(if (%current-target-system)
> +                        (@@ (gnu packages tls) gnutls-3.6.13)

Please avoid @@ by making ‘gnutls-3.6.13’ public (and making the package
itself hidden if necessary).

Otherwise LGTM!

Ludo’.

Forgive brevity, sent from my Emacs under lockdown.
:-)

Re: 02/36: gnu: guix: Use gnutls-3.6.13 when cross-compiling.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello Ludo'!

> Time for random review comments on ‘wip-hurd-vm’.  :-)

\o/

> guix-commits@gnu.org skribis:
>
>> commit af9b4d0ba3d55ef89e956f408853548451243e95
>> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
>> AuthorDate: Fri Apr 10 09:54:02 2020 +0200
>>
>>     gnu: guix: Use gnutls-3.6.13 when cross-compiling.
>>     
>>     * gnu/packages/package-management.scm (guix)[propagated-inputs]: When
>>     cross-compiling, use patched gnutls-3.6.13.
>
> [...]
>
>>        (propagated-inputs
>> -       `(("gnutls" ,guile3.0-gnutls)
>> +       `(("gnutls" ,(if (%current-target-system)
>> +                        (@@ (gnu packages tls) gnutls-3.6.13)
>
> Please avoid @@ by making ‘gnutls-3.6.13’ public

Oh..."gnutls-3.6.13" is already public; I simply removed (@@ ..)

Hmm, I don't know how this happened...I either didn't look well before,
maybe I was using then non-exported "gnutls", changed to gnutls-3.6.13
and kept the @@), or possibly it got exported later.  I'll try to
remember to avoid @@ in such cases.

> (and making the package > itself hidden if necessary).

> Otherwise LGTM!

Great, pushed.

> Forgive brevity, sent from my Emacs under lockdown.
> :-)

*lol*

Reading in my GNU Emacs under lockdown, thanks for your brevity.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 05/36: vm: Make the device node procedure a parameter.

[Ludovic Courtès]

Hi,

guix-commits@gnu.org skribis:

> commit ddb44df650592a29528ef3f4a913336230b1d3a1
> Author: Ludovic Courtès <ludo@gnu.org>
> AuthorDate: Tue Apr 7 10:21:48 2020 +0200
>
>     vm: Make the device node procedure a parameter.
>     
>     * gnu/build/vm.scm (root-partition-initializer): Add #:make-device-nodes
>     parameter and use it.
>     * gnu/system/vm.scm (qemu-image): Add #:device-node parameter.  Pass
>      #:make-device-nodes to 'root-partition-initializer'.
>     * gnu/system/hurd.scm (cross-hurd-image): Pass #:device-nodes 'hurd to
>     'qemu-image'.
> ---
>  gnu/system/hurd.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/system/hurd.scm b/gnu/system/hurd.scm
> index 2583ff0..059bfaf 100644
> --- a/gnu/system/hurd.scm
> +++ b/gnu/system/hurd.scm
> @@ -209,6 +209,7 @@ fi\n"))
>                #:bootcfg-drv grub.cfg
>                #:bootloader grub-bootloader
>                #:register-closures? #f
> +              #:device-nodes 'hurd
>                #:extra-directives hurd-directives))

On ‘core-updates’, there’s already #:device-nodes 'hurd, though not on
the same line.

I think we can drop this patch, no?

Ludo’.

Re: 05/36: vm: Make the device node procedure a parameter.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>     vm: Make the device node procedure a parameter.
>>                #:bootcfg-drv grub.cfg
>>                #:bootloader grub-bootloader
>>                #:register-closures? #f
>> +              #:device-nodes 'hurd
>>                #:extra-directives hurd-directives))
>
> On ‘core-updates’, there’s already #:device-nodes 'hurd, though not on
> the same line.
>
> I think we can drop this patch, no?

Oops, sure; dropped.

We may even want to move this (and "friends") into the qemu-image
declaration itself; in a much later patch on wip-hurd-vm I have

 (define* qemu-image #:key
[...]
-                     (file-system-type "ext4")
-                     (file-system-options '())
-                     (device-nodes 'linux)
+                     (file-system-type (if (hurd-target?) "ext2" "ext4"))
+                     (file-system-options
+                      (if (hurd-target?) '("-o" "hurd") '()))
+                     (device-nodes (if (hurd-target?) 'hurd 'linux))

Having linux-specific defaults in a generic function is kind of awkward;
we would need to change all callers, or ...

Well, that's for later to be sure!

Greetings,
janeke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 05/36: vm: Make the device node procedure a parameter.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> We may even want to move this (and "friends") into the qemu-image
> declaration itself; in a much later patch on wip-hurd-vm I have
>
>  (define* qemu-image #:key
> [...]
> -                     (file-system-type "ext4")
> -                     (file-system-options '())
> -                     (device-nodes 'linux)
> +                     (file-system-type (if (hurd-target?) "ext2" "ext4"))
> +                     (file-system-options
> +                      (if (hurd-target?) '("-o" "hurd") '()))
> +                     (device-nodes (if (hurd-target?) 'hurd 'linux))
>
> Having linux-specific defaults in a generic function is kind of awkward;
> we would need to change all callers, or ...

Ah yes, we should do something like that.

Ludo’.

Re: 06/36: gnu: hurd: Fix references to /bin/w.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> janneke pushed a commit to branch wip-hurd-vm
> in repository guix.
>
> commit f3b1d64cecdd964699a4e22a2b4b5b7fccccc53c
> Author: Rene Saavedra <pacoon@protonmail.com>
> AuthorDate: Sun Apr 12 22:33:08 2020 -0500
>
>     gnu: hurd: Fix references to /bin/w.
>     
>     * gnu/packages/hurd.scm (hurd): Use '/bin/w' from hurd package.

OK!

Re: 06/36: gnu: hurd: Fix references to /bin/w.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> commit f3b1d64cecdd964699a4e22a2b4b5b7fccccc53c
>> Author: Rene Saavedra <pacoon@protonmail.com>
>> AuthorDate: Sun Apr 12 22:33:08 2020 -0500
>>
>>     gnu: hurd: Fix references to /bin/w.
>>     
>>     * gnu/packages/hurd.scm (hurd): Use '/bin/w' from hurd package.
>
> OK!

Thanks; Pushed to core-updates.
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 07/36: gnu: hurd: Use default Qemu guest ip: 10.0.2.15.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit 695e2b4b5691910e6c82c56ec3fd31e6acdb9373
> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Sun Apr 12 13:53:04 2020 +0200
>
>     gnu: hurd: Use default Qemu guest ip: 10.0.2.15.
>     
>     Specifying 10.0.2.77 also works
>     
>         -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2228-10.0.2.77:22
>     
>     but using this default allows us to use the widely advertised
>     
>         -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2228-:22

Oh!

>     * gnu/packages/hurd.scm (hurd-rc-script): Use 10.0.2.15.
                                              ^
You can also mention [hurd-directives] here.

> -                            "--address" "10.0.2.77"
> +                            "--address" "10.0.2.15"

Perhaps add a margin comment saying this is the default QEMU guest IP.

LGTM!

Ludo’.

Re: 07/36: gnu: hurd: Use default Qemu guest ip: 10.0.2.15.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>     but using this default allows us to use the widely advertised
>>     
>>         -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2228-:22
>
> Oh!
>
>>     * gnu/packages/hurd.scm (hurd-rc-script): Use 10.0.2.15.
>                                               ^
> You can also mention [hurd-directives] here.

Eh, this is in the RC script; I have changed it to

* gnu/packages/hurd.scm (hurd-rc-script): Used by (hurd)[inputs]: Use
10.0.2.15; the default QEMU guest IP.

>> -                            "--address" "10.0.2.77"
>> +                            "--address" "10.0.2.15"
>
> Perhaps add a margin comment saying this is the default QEMU guest IP.

Good idea; done.

> LGTM!

Thanks, pushed to core-updates with these changes.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 08/36: gnu: hurd: Add NFS support.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit 2f5d2dc8240c22ea109c52c8ca957be9b155ff36
> Author: Ricardo Wurmus <rekado@elephly.net>
> AuthorDate: Sun Apr 12 23:06:30 2020 +0200
>
>     gnu: hurd: Add NFS support.
>     
>     * gnu/packages/hurd.scm (hurd)[inputs]: Add libtirpc/hurd.
>     [arguments]: Add configure flags to use libtirpc; add phase "find-tirpc" to
>     find the RPC headers; add phase "fix-rpc-headers" to include missing headers.

LGTM!

Re: 08/36: gnu: hurd: Add NFS support.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> guix-commits@gnu.org skribis:
>
>> commit 2f5d2dc8240c22ea109c52c8ca957be9b155ff36
>> Author: Ricardo Wurmus <rekado@elephly.net>
>> AuthorDate: Sun Apr 12 23:06:30 2020 +0200
>>
>>     gnu: hurd: Add NFS support.
>>     
>>     * gnu/packages/hurd.scm (hurd)[inputs]: Add libtirpc/hurd.
>>     [arguments]: Add configure flags to use libtirpc; add phase "find-tirpc" to
>>     find the RPC headers; add phase "fix-rpc-headers" to include missing headers.
>
> LGTM!

Pushed to core-updates; thanks Ricardo!

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 09/36: gnu: Add libtirpc/hurd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit 29ea4dc2c1df0d4562f1add01501726a3f963b91
> Author: Ricardo Wurmus <rekado@elephly.net>
> AuthorDate: Sun Apr 12 23:04:49 2020 +0200
>
>     gnu: Add libtirpc/hurd.
>     
>     * gnu/packages/onc-rpc.scm (libtirpc/hurd): New variable.
>     * gnu/packages/patches/libtirpc-hurd-client.patch,
>     gnu/packages/patches/libtirpc-hurd.patch: New files.
>     * gnu/local.mk (dist_patch_DATA): Add them.

LGTM!

On the next ‘staging’ cycle, we should merge the two libtirpc’s.

Ludo’.

Re: 09/36: gnu: Add libtirpc/hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> guix-commits@gnu.org skribis:
>
>> commit 29ea4dc2c1df0d4562f1add01501726a3f963b91
>> Author: Ricardo Wurmus <rekado@elephly.net>
>> AuthorDate: Sun Apr 12 23:04:49 2020 +0200
>>
>>     gnu: Add libtirpc/hurd.
>>     
>>     * gnu/packages/onc-rpc.scm (libtirpc/hurd): New variable.
>>     * gnu/packages/patches/libtirpc-hurd-client.patch,
>>     gnu/packages/patches/libtirpc-hurd.patch: New files.
>>     * gnu/local.mk (dist_patch_DATA): Add them.
>
> LGTM!

Pushed to core-updates; thanks Ricardo!

> On the next ‘staging’ cycle, we should merge the two libtirpc’s.

I'll try to help remember; can we add helpful comment somewhere?

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: branch wip-hurd-vm created (now fdb35e3)

[Ludovic Courtès]

guix-commits@gnu.org skribis:

>      new 330f3ab  gnu: guix: Cross-build fixup for wrap-program.
>      new af9b4d0  gnu: guix: Use gnutls-3.6.13 when cross-compiling.
>      new de41617  gnu: guix: Apply courage for the Hurd.
>      new 309963e  gnu: guix: Update to de41617661.
>      new ddb44df  vm: Make the device node procedure a parameter.
>      new f3b1d64  gnu: hurd: Fix references to /bin/w.
>      new 695e2b4  gnu: hurd: Use default Qemu guest ip: 10.0.2.15.
>      new 2f5d2dc  gnu: hurd: Add NFS support.
>      new 29ea4dc  gnu: Add libtirpc/hurd.
>      new d01f38a  system: hurd: Add less, which to %base-packages/hurd.
>      new df00a4a  system: hurd: Add /etc/group.

With the feedback I gave, these 11 patches can go to ‘core-updates’ IMO!

Thank you!

Ludo’.

Re: branch wip-hurd-vm created (now fdb35e3)

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>      new 330f3ab  gnu: guix: Cross-build fixup for wrap-program.
>>      new af9b4d0  gnu: guix: Use gnutls-3.6.13 when cross-compiling.

removed (@@ ...)

>>      new de41617  gnu: guix: Apply courage for the Hurd.
>>      new 309963e  gnu: guix: Update to de41617661.

re-created

>>      new ddb44df  vm: Make the device node procedure a parameter.

dropped

>>      new f3b1d64  gnu: hurd: Fix references to /bin/w.
>>      new 695e2b4  gnu: hurd: Use default Qemu guest ip: 10.0.2.15.

added comments

>>      new 2f5d2dc  gnu: hurd: Add NFS support.
>>      new 29ea4dc  gnu: Add libtirpc/hurd.
>>      new d01f38a  system: hurd: Add less, which to %base-packages/hurd.
>>      new df00a4a  system: hurd: Add /etc/group.

added

> With the feedback I gave, these 11 patches can go to ‘core-updates’
> IMO!

Great!  All pushed to core-updates.  Lovely progress by 4 committers:
Rene, Ricardo, Efraim, Janneke!

...No commits by Ludovic this round! (the silence before the storm?)...
and of course I'm joking here, thanks a lot for this review party
Ludovic!

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 13/36: services: Add hurd-console-service-type.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit d7a217e67dcd3b14402d746f4428db8545ce83f2
> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Mon Apr 13 10:13:05 2020 +0200
>
>     services: Add hurd-console-service-type.
>     
>     * gnu/services/hurd.scm (<hurd-console-configuration>): New variable.
>     (hurd-console-shepherd-service, hurd-console-service-type): New function.
>     (hurd-service->shepherd-service): Add entry.

Now for the exciting stuff, neat!

> -  #:export (hurd-service->shepherd-service))
> +  #:export (hurd-console-service-type
> +            hurd-service->shepherd-service))
>  
>  ;;; Commentary:
>  ;;;
> @@ -38,9 +39,51 @@
>  (define (hurd-service->shepherd-service service)
>    (let ((config (service-value service)))
>      (match config
> +      (($ <hurd-console-configuration>) (hurd-console-shepherd-service config))
>        (_ '()))))

Hmm do we really need this ‘hurd-service->shepherd-service’ procedure?
I haven’t read the rest, but it seems surprising at first sight.

> +  (list (shepherd-service
> +         (documentation "Hurd console.")

“Run the Hurd’s VGA console client.”

> +         (provision '(console))
> +         (requirement '())

Should be '(user-processes) I think.

> +         (start #~(lambda _ (fork+exec-command #$console-command) #t))

Rather #~(make-forkexec-constructor #$console-command).

> +(define hurd-console-service-type
> +  (service-type
> +   (name 'console)
> +   (description
> +    "Run a hurd console, @command{console}.")

Maybe “Run the Hurd console client.”

> +   (compose concatenate)
> +   (extend first-of-two)

I don’t think we need these two fields since this service is not meant
to be extensible.

> +   (default-value (hurd-console-configuration))))

Please add a ‘description’ too!

Also, normally we document every new service type in the manual, but
maybe we can delay it here so that you can unleash your hack powers in
the meantime.  :-)

Thanks,
Ludo’.

Re: 13/36: services: Add hurd-console-service-type.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> guix-commits@gnu.org skribis:
>
>> commit d7a217e67dcd3b14402d746f4428db8545ce83f2
>> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
>> AuthorDate: Mon Apr 13 10:13:05 2020 +0200
>>
>>     services: Add hurd-console-service-type.
>>     
>>     * gnu/services/hurd.scm (<hurd-console-configuration>): New variable.
>>     (hurd-console-shepherd-service, hurd-console-service-type): New function.
>>     (hurd-service->shepherd-service): Add entry.
>
> Now for the exciting stuff, neat!

\o/

>> -  #:export (hurd-service->shepherd-service))
>> +  #:export (hurd-console-service-type
>> +            hurd-service->shepherd-service))
>>  
>>  ;;; Commentary:
>>  ;;;
>> @@ -38,9 +39,51 @@
>>  (define (hurd-service->shepherd-service service)
>>    (let ((config (service-value service)))
>>      (match config
>> +      (($ <hurd-console-configuration>) (hurd-console-shepherd-service config))
>>        (_ '()))))
>
> Hmm do we really need this ‘hurd-service->shepherd-service’ procedure?
> I haven’t read the rest, but it seems surprising at first sight.

We certainly don't need it.  The patch/hunk above is being cut very
unfortunately; it loses the one interesting comment just one line
earlier, which was introduced by the privous (mosttly empty) commit:

    +;; XXX Gradually bootstrap (gnu services) framework.
    +(define (hurd-service->shepherd-service service)

The "XXX" comment is my attempt at implicitly communicating a question
that I had trouble formulating, two weeks ago.  The code that I could
not imagine how to write now looks something like this:

  (define shepherd.conf
    (with-parameters ((%current-target-system "i586-pc-gnu"))
      (shepherd-configuration-file
       (append-map list
                   (service-value
               (fold-services (operating-system-services os)
                              #:target-type
                              shepherd-root-service-type))))))

...but this does not work.  The problem here is that I currestly faked
"file-systems", "syslogd", "user-processes".  Those are needed to "get
past" the missing dependency checks for "openssh" and "guix-daemon".  I
have no idea how to write those yet, so would like to postpone them for
a bit.

However

  (define shepherd.conf
    (with-parameters ((%current-target-system "i586-pc-gnu"))
      (shepherd-configuration-file
       (filter
        (lambda (value)
          ;; XXX Remove file-systems, loopback, syslogd, user-processes
          ;; those are fake/don't work yet on the Hurd
          (pk "prov" (memq (car (shepherd-service-provision value))
                           '(console guix-daemon ssh-daemon ttys
                                     user-processes))))
        (service-value
         (fold-services (operating-system-services os)
                        #:target-type
                        shepherd-root-service-type))))))

this also does not work, because again, I get

    guix build: error: service 'user-processes' requires 'user-homes', which is not provided by any service

So...I just can't manage to bootstrap shepherd services into
"system/hurd.scm cross-hurd-image" without this intermediate
hurd-service->shepherd-service procedure.  Once we have working
implementations for all these services, hurd-service->shepherd-service
has become obsolete.

Now this

    guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

has some cross-build problems, though.  Yesterday I finally managed to
pin-point the problem.  It lives between
expression->derivation-in-linux-vm

(define* (expression->derivation-in-linux-vm name exp
                                             #:key
                                             (system (%current-system)) target
                                             (linux linux-libre)
...

that is called by qemu-image.  So I have been playing with this hack

(define* (qemu-image #:key
                     (name "qemu-image")
                     (system (%current-system))
-                    (target (%current-target-system))
+                    (target (if (hurd-target?) #f (%current-target-system)))

Because when qemu-image has "target" set, then expression->derivation-in-linux-vm
will attempt to create a QEMU vm for that target and start in in
QEMU...but it needs a LINUX for that target and starts to cross-build
linux for i586-pc-gnu.  That build fails.

In our "guix build -f gnu/system/hurd.scm" setup ("hack"?) we call
qemu-image with target #f, build and run a VM-image using x86_64-linux
and manually cross-compile all packages that go inside.

I'll be trying to rewrite these services harder and use more of the
regular "guix system" way of handling services to plug that into
gnu/system/hurd.scm.

Meanwhile there is the vm-image question: can we somehow use
expression->derivation-in-linux-vm when running "guix system
... --target=i586-pc-gnu"?  Or do we want to create a
expression->derivation-in-hurd-vm?  Or do we leap onto the "explosive
mixture of wip-disk-image and wip-hurd-vm?  Once any of these solutions
work we can drop the gnu/system/hurd.scm cross-hurd-image workaround.

>> +  (list (shepherd-service
>> +         (documentation "Hurd console.")
>
> “Run the Hurd’s VGA console client.”

Ah, ok...that's what it is.

>> +         (provision '(console))
>> +         (requirement '())
>
> Should be '(user-processes) I think.

Ah yes, good catch.

>> +         (start #~(lambda _ (fork+exec-command #$console-command) #t))
>
> Rather #~(make-forkexec-constructor #$console-command).

Great, thanks!

>> +(define hurd-console-service-type
>> +  (service-type
>> +   (name 'console)
>> +   (description
>> +    "Run a hurd console, @command{console}.")
>
> Maybe “Run the Hurd console client.”

Thanks.

>> +   (compose concatenate)
>> +   (extend first-of-two)
>
> I don’t think we need these two fields since this service is not meant
> to be extensible.
>
>> +   (default-value (hurd-console-configuration))))
>
> Please add a ‘description’ too!

For the default value?  Isn't that added above...maybe i'm using a weird
layout for the fields?

I will be testing these changes and updating the other services
similarly.

> Also, normally we document every new service type in the manual, but
> maybe we can delay it here so that you can unleash your hack powers in
> the meantime.  :-)

I'm marking this as DRAFT and add a TODO in the message so that we don't
forget.  Let's not waste my hacking powers on documenting stuff too long
before it's merged...but also not forget the documentation.

Phew...

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 13/36: services: Add hurd-console-service-type.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

> Now this
>
>     guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

Oops the above works, I should have said:

Now this

     guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

... etc

We can now, actually cross build using guix system build; but the
problem is in creating a VM with a cross-built system in it, as
described in that message.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 13/36: services: Add hurd-console-service-type.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:


[...]

> Now this
>
>     guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl
>
> has some cross-build problems, though.  Yesterday I finally managed to
> pin-point the problem.  It lives between
> expression->derivation-in-linux-vm
>
> (define* (expression->derivation-in-linux-vm name exp
>                                              #:key
>                                              (system (%current-system)) target
>                                              (linux linux-libre)
> ...
>
> that is called by qemu-image.  So I have been playing with this hack

Ah, so there was a #$ vs. #+ issue we discussed on IRC.  Did that help?

> Meanwhile there is the vm-image question: can we somehow use
> expression->derivation-in-linux-vm when running "guix system
> ... --target=i586-pc-gnu"?  Or do we want to create a
> expression->derivation-in-hurd-vm?

The VM is used just to create the image (it will no longer be necessary
once Mathieu’s work on image creation has landed).  The fact that it
runs Linux doesn’t matter.

>>> +   (default-value (hurd-console-configuration))))
>>
>> Please add a ‘description’ too!
>
> For the default value?

No, I meant a ‘description’ field.

Thanks!

Ludo’.

Re: 13/36: services: Add hurd-console-service-type.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> (define* (expression->derivation-in-linux-vm name exp
>>                                              #:key
>>                                              (system (%current-system)) target
>>                                              (linux linux-libre)
>> ...
>>
>> that is called by qemu-image.  So I have been playing with this hack
>
> Ah, so there was a #$ vs. #+ issue we discussed on IRC.  Did that
> help?

Yes; that fixed this aspect.  In fact, fixing this allows me to
introduce guix system build --target=i586-pc-gnu / guix system vm-image
--target=i586-pc-gnu much earlier, and have those working.

So I have reversed some bits, and now don't need to introduce the
hurd-service->shepherd-service intermediate anymore!

I'll reset wip-hurd-vm with those improvements.

> The VM is used just to create the image (it will no longer be necessary
> once Mathieu’s work on image creation has landed).  The fact that it
> runs Linux doesn’t matter.

Yes...

>>>> +   (default-value (hurd-console-configuration))))
>>>
>>> Please add a ‘description’ too!
>>
>> For the default value?
>
> No, I meant a ‘description’ field.

Ah, I believe, I think it's there.  Someone may have overlooked
something.

Thanks!

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> +(define (hurd-loopback-shepherd-service _)
> +  "Return the 'loopback' Shepherd service."
> +
> +  (list (shepherd-service
> +         (documentation "Dummy for bootstrapping (gnu services) on the Hurd.")
> +         (provision '(loopback))
> +         (requirement '())
> +         (start #~(const #t))
> +         (stop #~(const #t))
> +         (respawn? #f))))
> +
> +(define hurd-loopback-service-type
> +  (service-type
> +   (name 'loopback)
> +   (extensions (list (service-extension shepherd-root-service-type
> +                                        hurd-loopback-shepherd-service)))
> +   (compose concatenate)
> +   (extend first-of-two)
> +   (default-value '(loopback)) ;canary for hurd-service->shepherd-service
> +   (description "Dummy service to bootstrap (gnu services) on the
> +Hurd.")))

I believe the code currently used in ‘static-networking-service’ to
setup the loopback device on GNU/Linux should also work on GNU/Hurd: it
uses the “traditional” ioctls provided by (guix build syscalls).

So hopefully we don’t need a Hurd-specific variant.

Ludo’.

Re: 18/36: services: hurd: Add dummy loopback.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> guix-commits@gnu.org skribis:
>
>> +(define (hurd-loopback-shepherd-service _)
>> +  "Return the 'loopback' Shepherd service."
>> +
>> +  (list (shepherd-service
>> +         (documentation "Dummy for bootstrapping (gnu services) on the Hurd.")
>> +         (provision '(loopback))
>> +         (requirement '())
>> +         (start #~(const #t))
>> +         (stop #~(const #t))
>> +         (respawn? #f))))
>> +
>> +(define hurd-loopback-service-type
>> +  (service-type
>> +   (name 'loopback)
>> +   (extensions (list (service-extension shepherd-root-service-type
>> +                                        hurd-loopback-shepherd-service)))
>> +   (compose concatenate)
>> +   (extend first-of-two)
>> +   (default-value '(loopback)) ;canary for hurd-service->shepherd-service
>> +   (description "Dummy service to bootstrap (gnu services) on the
>> +Hurd.")))
>
> I believe the code currently used in ‘static-networking-service’ to
> setup the loopback device on GNU/Linux should also work on GNU/Hurd: it
> uses the “traditional” ioctls provided by (guix build syscalls).
>
> So hopefully we don’t need a Hurd-specific variant.

Ah, great!  I rewrote this to use <static-networking>...and it almost
works already.  I have added

        (service static-networking-service-type
                 (list (static-networking (interface "lo")
                                          (ip "127.0.0.1")
                                          (requirement '())
                                          (provision '(loopback)))))

and the VM builds, only it doesn't start

    herd: exeception caught while executing 'start' on service 'loopback':
    Value out of range 0 to 4294967295: -1

I have added new code for this as a squash! commit, that I then also
revert for now, until it works. :-(

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ah, great!  I rewrote this to use <static-networking>...and it almost
> works already.  I have added
>
>         (service static-networking-service-type
>                  (list (static-networking (interface "lo")
>                                           (ip "127.0.0.1")
>                                           (requirement '())
>                                           (provision '(loopback)))))
>
> and the VM builds, only it doesn't start
>
>     herd: exeception caught while executing 'start' on service 'loopback':
>     Value out of range 0 to 4294967295: -1

Ah see, it’s out of range.

Could you run Guile, load (guix build syscalls), and try to run the code
of the ‘start’ method that appears in
‘static-networking-shepherd-service’ to see which syscall is giving us
that error?

Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its
friends?

Ludo’.

Re: 18/36: services: hurd: Add dummy loopback.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>     herd: exeception caught while executing 'start' on service 'loopback':
>>     Value out of range 0 to 4294967295: -1
>
> Ah see, it’s out of range.
>
> Could you run Guile, load (guix build syscalls), and try to run the code
> of the ‘start’ method that appears in
> ‘static-networking-shepherd-service’ to see which syscall is giving us
> that error?

Yes, that reproduces!

> Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its
> friends?

Something like that: sizeof-ifconf is set to 16 (like on x86_64), but
it's size should be 8.

Not sure how that works!?

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>> Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its
>> friends?
>
> Something like that: sizeof-ifconf is set to 16 (like on x86_64), but
> it's size should be 8.

Oh, that’s because ‘define-c-struct’ does all the work at
macro-expansion time, with the host types and alignment constraints.  I
wonder how we didn’t notice it earlier.  Cross-compiling from x86_64 to
ARMv7 has the same problem, but maybe the networking ioctls work by
chance.

The patch below appears to fix it:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guild compile --target=i686-pc-linux-gnu guix/build/syscalls.scm -o guix/build/syscalls.go
wrote `guix/build/syscalls.go'
$ guix environment -s i686-linux -C --ad-hoc guile-next -- guile -L . -C .
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> ,m(guix build syscalls)
scheme@(guix build syscalls)> sizeof-ifconf
$1 = 8
scheme@(guix build syscalls)> %host-type
$2 = "i686-unknown-linux-gnu"
--8<---------------cut here---------------end--------------->8---

Thank you!

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1923 bytes --]

diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 73b439fb7d..00d8ceb480 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -23,6 +23,7 @@
 
 (define-module (guix build syscalls)
   #:use-module (system foreign)
+  #:use-module (system base target)
   #:use-module (rnrs bytevectors)
   #:autoload   (ice-9 binary-ports) (get-bytevector-n)
   #:use-module (srfi srfi-1)
@@ -194,9 +195,14 @@
      (* (sizeof* type) n))
     ((_ type)
      (let-syntax ((v (lambda (s)
-                       (let ((val (sizeof type)))
-                         (syntax-case s ()
-                           (_ val))))))
+                       ;; When compiling natively, call 'sizeof' at expansion
+                       ;; time; otherwise, emit code to call it at run time.
+                       (syntax-case s ()
+                         (_
+                          (if (= (target-word-size)
+                                 (with-target %host-type target-word-size))
+                              (sizeof type)
+                              #'(sizeof type)))))))
        v))))
 
 (define-syntax alignof*
@@ -208,9 +214,14 @@
      (alignof* type))
     ((_ type)
      (let-syntax ((v (lambda (s)
-                       (let ((val (alignof type)))
-                         (syntax-case s ()
-                           (_ val))))))
+                       ;; When compiling natively, call 'sizeof' at expansion
+                       ;; time; otherwise, emit code to call it at run time.
+                       (syntax-case s ()
+                         (_
+                          (if (= (target-word-size)
+                                 (with-target %host-type target-word-size))
+                              (alignof type)
+                              #'(alignof type)))))))
        v))))
 
 (define-syntax align                             ;as found in (system foreign)

Re: 18/36: services: hurd: Add dummy loopback.

[Vincent Legoll]

Hello,

On Tue, May 5, 2020 at 11:23 AM Ludovic Courtès <ludo@gnu.org> wrote:
> The patch below appears to fix it:

Is target-word-size checking always equivalent to cross-compiling ?

Aren't there cross-compilation host/target combos where this will
be true, but still there will be other differences (endianness maybe) ?

I don't know if the question really makes sense, though, so please
forgive my ignorance...

-- 
Vincent Legoll

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

Hi,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> On Tue, May 5, 2020 at 11:23 AM Ludovic Courtès <ludo@gnu.org> wrote:
>> The patch below appears to fix it:
>
> Is target-word-size checking always equivalent to cross-compiling ?

In this case it’s sufficient: it’s just about ‘sizeof’ and ‘alignof’, so
the word size is all that matters.

Ludo’.

Re: 18/36: services: hurd: Add dummy loopback.

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]

Ludovic Courtès writes:

Hi,

>> Something like that: sizeof-ifconf is set to 16 (like on x86_64), but
>> it's size should be 8.
>
> Oh, that’s because ‘define-c-struct’ does all the work at
> macro-expansion time, with the host types and alignment constraints.  I
> wonder how we didn’t notice it earlier.  Cross-compiling from x86_64 to
> ARMv7 has the same problem, but maybe the networking ioctls work by
> chance.
>
> The patch below appears to fix it:

Yes, it fixes the struct sizes in the cross-compiled .go file.  Thanks!
I have added it as the attached patch to "wip-hurd-vm" for now.  I did

    ./pre-inst-env guild compile --target=i586-pc-gnu -o syscalls.go guix/build/syscalls.scm 

and copied that to the Hurd.

When running this (changed #$... to UPPERCASE)

--8<---------------cut here---------------start------------->8---
(use-modules (guix build syscalls))

(define LOOPBACK? #t)
(define IP "127.0.0.1" )
(define INTERFACE "lo")
(define NETMASK #f)
(define GATEWAY #f)

(format #t "ifreq-struct-size: ~a\n" (@@ (guix build syscalls) ifreq-struct-size))
(format #t "sizeof-ifconf: ~s\n" (@@ (guix build syscalls) sizeof-ifconf))
(define (test)
  (let* ((addr     (inet-pton AF_INET IP))
         (sockaddr (make-socket-address AF_INET addr 0))
         (mask     (and NETMASK
                        (inet-pton AF_INET NETMASK)))
         (maskaddr (and mask
                        (make-socket-address AF_INET
                                             mask 0)))
         (gateway  (and GATEWAY
                        (inet-pton AF_INET GATEWAY)))
         (gatewayaddr (and gateway
                           (make-socket-address AF_INET
                                                gateway 0))))
    (configure-network-interface INTERFACE sockaddr
                                 (logior IFF_UP
                                         (if LOOPBACK?
                                             IFF_LOOPBACK
                                             0))
                                 #:netmask maskaddr)
    (when gateway
      (let ((sock (socket AF_INET SOCK_DGRAM 0)))
        (add-network-route/gateway sock gatewayaddr)
        (close-port sock)))))

(test)
--8<---------------cut here---------------end--------------->8---

Now I see the correct sizes...

root@guixygnu# guile -L . -C . static.scm 
;;; note: source file /root/static.scm
;;;       newer than compiled /root/.cache/guile/ccache/3.0-LE-4-4.2/root/static.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /root/static.scm
;;; compiled /root/.cache/guile/ccache/3.0-LE-4-4.2/root/static.scm.go
ifreq-struct-size: 32
sizeof-ifconf: 8
Backtrace:
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           8 (apply-smob/0 #<thunk 2e6430>)
In ice-9/boot-9.scm:
    718:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle?>)
In ice-9/eval.scm:
    619:8  6 (_ #(#(#<directory (guile-user) 2dd820>)))
In ice-9/boot-9.scm:
   2806:4  5 (save-module-excursion _)
  4351:12  4 (_)
In static.scm:
     24:4  3 (test)
In guix/build/syscalls.scm:
   1529:8  2 (configure-network-interface "lo" #(2 2130706433 0) 9 # _)
  1464:18  1 (_ _ "lo" _)
In unknown file:
Exception thrown while printing backtrace:
In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 8f8560 (_ _ _)>

ERROR: Value out of range 0 to 4294967295: -1

...but still/again a similar range error; Ideas?

Greetings,
janneke


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-syscalls-Cross-build-fix-for-alignof-sizeof.patch --]
[-- Type: text/x-patch, Size: 2509 bytes --]

From 33fbfcd7f46cf675cc24db92b1110d38afa51ae5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Tue, 5 May 2020 11:53:39 +0200
Subject: [PATCH] syscalls: Cross-build fix for alignof*, sizeof*.

See <https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00008.html>.
Reported by Jan (janneke) Nieuwenhuizen <janneke@gnu.org>.

* guix/build/syscalls.scm (sizeof*, alignof*): When cross-compiling, emit code
to call at runtime.
---
 guix/build/syscalls.scm | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 73b439fb7d..00d8ceb480 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -23,6 +23,7 @@
 
 (define-module (guix build syscalls)
   #:use-module (system foreign)
+  #:use-module (system base target)
   #:use-module (rnrs bytevectors)
   #:autoload   (ice-9 binary-ports) (get-bytevector-n)
   #:use-module (srfi srfi-1)
@@ -194,9 +195,14 @@
      (* (sizeof* type) n))
     ((_ type)
      (let-syntax ((v (lambda (s)
-                       (let ((val (sizeof type)))
-                         (syntax-case s ()
-                           (_ val))))))
+                       ;; When compiling natively, call 'sizeof' at expansion
+                       ;; time; otherwise, emit code to call it at run time.
+                       (syntax-case s ()
+                         (_
+                          (if (= (target-word-size)
+                                 (with-target %host-type target-word-size))
+                              (sizeof type)
+                              #'(sizeof type)))))))
        v))))
 
 (define-syntax alignof*
@@ -208,9 +214,14 @@
      (alignof* type))
     ((_ type)
      (let-syntax ((v (lambda (s)
-                       (let ((val (alignof type)))
-                         (syntax-case s ()
-                           (_ val))))))
+                       ;; When compiling natively, call 'sizeof' at expansion
+                       ;; time; otherwise, emit code to call it at run time.
+                       (syntax-case s ()
+                         (_
+                          (if (= (target-word-size)
+                                 (with-target %host-type target-word-size))
+                              (alignof type)
+                              #'(alignof type)))))))
        v))))
 
 (define-syntax align                             ;as found in (system foreign)
-- 
2.26.0


[-- Attachment #3: Type: text/plain, Size: 152 bytes --]


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> (use-modules (guix build syscalls))
>
> (define LOOPBACK? #t)
> (define IP "127.0.0.1" )
> (define INTERFACE "lo")
> (define NETMASK #f)
> (define GATEWAY #f)
>
> (format #t "ifreq-struct-size: ~a\n" (@@ (guix build syscalls) ifreq-struct-size))
> (format #t "sizeof-ifconf: ~s\n" (@@ (guix build syscalls) sizeof-ifconf))
> (define (test)
>   (let* ((addr     (inet-pton AF_INET IP))
>          (sockaddr (make-socket-address AF_INET addr 0))
>          (mask     (and NETMASK
>                         (inet-pton AF_INET NETMASK)))
>          (maskaddr (and mask
>                         (make-socket-address AF_INET
>                                              mask 0)))
>          (gateway  (and GATEWAY
>                         (inet-pton AF_INET GATEWAY)))
>          (gatewayaddr (and gateway
>                            (make-socket-address AF_INET
>                                                 gateway 0))))
>     (configure-network-interface INTERFACE sockaddr
>                                  (logior IFF_UP
>                                          (if LOOPBACK?
>                                              IFF_LOOPBACK
>                                              0))
>                                  #:netmask maskaddr)
>     (when gateway
>       (let ((sock (socket AF_INET SOCK_DGRAM 0)))
>         (add-network-route/gateway sock gatewayaddr)
>         (close-port sock)))))
>
> (test)

Could you change that last line to:

  (catch 'system-error
    test
    (lambda args
      (let ((errno (system-error-errno args)))
        (pk errno (strerror errno)))))

?

The out-of-range exception presumably is an unrelated error in Guile’s
debugger and it’s shadowing the one we’re interested in.

TIA!

Ludo’.

Re: 20/36: system: hurd: Add the Shepherd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit bb17242a511014e1691d494b17152865db0580e0
> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Tue Apr 7 08:03:03 2020 +0200
>
>     system: hurd: Add the Shepherd.
>     
>     This starts console and ttys using the Shepherd.  Shepherd is not running as
>     PID 1 yet, its started from `rc'.
>     
>     * gnu/system/hurd.scm (%base-packages/hurd): Add "shepherd".
>     (%base-services/hurd): New variable.
>     (%hurd-os): New variable.
>     (hurd-shepherd-services): New function.
>     (cross-hurd-image): Use them to generate an (unused and incomplete) ...
>     (shepherd.conf): Generate from services defined in
>     %hurd-os.
>     * gnu/packages/hurd.scm (hurd-rc-script): Do not start console, start the
>     shepherd instead.
>     (hurd)[arguments]: Create pty devices.
>     * gnu/system/hurd.scm (shepherd.conf): New file.

[...]

> +;; XXX: We will replace this by addding (gnu services shepherd).
> +(define shepherd-configuration-file
> +  (@@ (gnu services shepherd) shepherd-configuration-file))
> +
>  (define %base-packages/hurd
>    (list hurd bash coreutils file findutils grep sed
>          guile-3.0 guile-colorized guile-readline
> -        net-base inetutils less which))
> +        net-base inetutils less shepherd which))
> +
> +(define %base-services/hurd
> +  (list (service user-processes-service-type)
> +        (service hurd-console-service-type
> +                 (hurd-console-configuration (hurd hurd)))
> +        (service hurd-ttys-service-type
> +                 (hurd-ttys-configuration (hurd hurd)))))
> +
> +(define %hurd-os
> +  (operating-system
> +    (host-name "guixygnu")
> +    (bootloader #f)
> +    (file-systems '())
> +    (timezone "GNUrope")
> +    (services %base-services/hurd)))
> +
> +(define (hurd-shepherd-services os)
> +  (append-map hurd-service->shepherd-service (operating-system-services os)))
>  
>  (define* (cross-hurd-image #:key (hurd hurd) (gnumach gnumach))
>    "Return a cross-built GNU/Hurd image."
> @@ -136,6 +163,10 @@ if [ -f \"$GUIX_PROFILE/etc/profile\" ]; then
>    . \"$GUIX_PROFILE/etc/profile\"
>  fi\n"))
>  
> +  (define shepherd.conf
> +    (with-parameters ((%current-target-system "i586-pc-gnu"))
> +      (shepherd-configuration-file (hurd-shepherd-services %hurd-os))))

This looks like an intermediate before fully using the service/OS
framework, but I wonder how much it helps.

The way I see it, now that you’ve defined services for Hurd-specific
things like the console client, you could very much write:

  (operating-system
    ;; …
    (kernel gnumach)
    (hurd hurd)  ;<- we probably need this new field
    (essential-services (hurd-essential-services this-operating-system))
    (services %base-hurd-services))

(Eventually we can even arrange for ‘essential-services’ and ‘services’
to pick the right default as a function of the chosen kernel.)

and then do:

  guix system build --target=i586-pc-gnu the-config-above.scm

Assuming system cross-compilation works as advertised :-), it should
cross-compile the whole system.

At that stage, you don’t need ‘cross-hurd-image’ any longer and you can
instead run:

  guix system vm-image --target=i586-pc-gnu the-config-above.scm

to achieve the same result.

But!  There’s one missing bit: a Hurdish grub.cfg.  I think that can be
hacked in (gnu bootloader grub), by inheriting from ‘grub-bootloader’
and providing a custom ‘configuration-file-generator’ field and maybe
‘installer’ as well.

Thus, (gnu system hurd) would be left with nothing but the definitions
of ‘%base-services/hurd’, ‘%base-packages/hurd’, and so on.
‘hurd-essential-services’ could maybe go to (gnu services hurd).

But I wonder if I’m missing something, WDYT?

Thanks for the exciting developments again!  :-)

Ludo’.

Re: 20/36: system: hurd: Add the Shepherd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi Ludo'!

>> commit bb17242a511014e1691d494b17152865db0580e0
>> Author: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
>> AuthorDate: Tue Apr 7 08:03:03 2020 +0200
>>
>>     system: hurd: Add the Shepherd.

>> +  (define shepherd.conf
>> +    (with-parameters ((%current-target-system "i586-pc-gnu"))
>> +      (shepherd-configuration-file (hurd-shepherd-services %hurd-os))))
>
> This looks like an intermediate before fully using the service/OS
> framework

TL;DR: Thanks a lot for your review and questions!  I will be using this
to rewrite the Shepherd/services introduction in a proper way, until
it can be merged.

> , but I wonder how much it helps.

Yes, that's exactly it!  This intermediate, is curerently the only way I
found that can produce a fully functional VM-image; i.e., one that
starts guix-daemon and openssh.  So it helps by being an intermediate.

> The way I see it, now that you’ve defined services for Hurd-specific
> things like the console client, you could very much write:
>
>   (operating-system
>     ;; …
>     (kernel gnumach)
>     (hurd hurd)  ;<- we probably need this new field

(oh...prolly better than the (if hurd-target?) I've been sprinkling and
implicit adding of gnumach.  I'll have a go at this.

>     (essential-services (hurd-essential-services this-operating-system))
>     (services %base-hurd-services))
>
> (Eventually we can even arrange for ‘essential-services’ and ‘services’
> to pick the right default as a function of the chosen kernel.)
>
> and then do:
>
>   guix system build --target=i586-pc-gnu the-config-above.scm

> Assuming system cross-compilation works as advertised :-), it should
> cross-compile the whole system.

Yeah...is seems that the marketing department may have sold us something
that has yet to be delivered.  Either that, or I failed to read some
bits of the instruction manual ;-)

To get something to run, we need (near the top of wip-hurd-vm)

    6302837257 HACK Don't fail on running host's localedef.
    443e1b2176 gnu: hurd: Cross-build hack: Set target i586-pc-gnu if unset.
    87b50146ee gnu: glibc/hurd-headers: Cross-build fix for the Hurd.

So, on a well-chosen version of wip-hurd-vm (for example: wip-hurd-vm24
on my gitlab), I can now finally run this

    ./pre-inst-env guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

...but (most of) the OS is not cross-compiled; <profile>/bin/bash is the
build host's bash.  Some things, like Grub, Gnumach, the Hurd are cross
compiled, so ...

> At that stage, you don’t need ‘cross-hurd-image’ any longer and you can
> instead run:
>
>   guix system vm-image --target=i586-pc-gnu the-config-above.scm
>
> to achieve the same result.

... indeed, running:

    ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

creates a bootable VM-image that drops into a bash-minimal shell,
because <profile>/bin/bash cannot be executed.

> But!  There’s one missing bit: a Hurdish grub.cfg.  I think that can be
> hacked in (gnu bootloader grub), by inheriting from ‘grub-bootloader’
> and providing a custom ‘configuration-file-generator’ field and maybe
> ‘installer’ as well.

I think I have that covered here

    d6ec2c2543 * system: hurd: Add hurd-grub-configuration-file.
    a9a6b716d9 * system: hurd: Add hurd-grub-minimal-bootloader.

possibly depending on these

    4fd4296325 * system: Add hurd-operating-system-directory-base-entries.
    f4f872a440 * services: hurd: Move hurd-default-essential-services.
    5f7c73d83a * services: Add hurd-file-systems-service-type.
    d7cd2f122d * services: hurd: Move hurd-etc-sevcices.

> Thus, (gnu system hurd) would be left with nothing but the definitions
> of ‘%base-services/hurd’, ‘%base-packages/hurd’, and so on.
> ‘hurd-essential-services’ could maybe go to (gnu services hurd).

Yes!

> But I wonder if I’m missing something, WDYT?

You're right...and this is what I am trying to work towards.  The reason
for me to introduce these intermediate steps is that they enable to run
intermediate tests.

Currently, "guix build -f gnu/system/hurd.scm" is the only way I have
that produces a functional VM.  We are pretty close t creating such a
thing with "guix system ...", but to do so we need a cross build that
works and a shepherd config generated...and that all needs to come
together.  So instead of attempting a giant leap, I'm trying to throw
some intermediate stepping stones in the pond :-)

We don't need to merge, or keep this history; but I don't see how to
walk this path without going round these extra curves; let alone getting
feedback or asking questions.  So I can imagine that these commits keep
being rewritten/removed on wip-hurd-vm until everything works.

> Thanks for the exciting developments again!  :-)

Thanks for your insights, we're getting there...  I have some more
specific, related questions/puzzles in response to your other mail about
services.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com