Ludovic Courtès writes:
> Jan Nieuwenhuizen skribis:
>
>> So, after digesting your message here I took the next step: grep for
>> _HURD_STARTUP and change it there, like so
>>
>> diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
>> index 421783eb80..8c73ea8430 100644
>> --- a/gnu/package
Hi,
Jan Nieuwenhuizen skribis:
> So, after digesting your message here I took the next step: grep for
> _HURD_STARTUP and change it there, like so
>
> diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
> index 421783eb80..8c73ea8430 100644
> --- a/gnu/packages/hurd.scm
> +++ b/gnu/packag
Ludovic Courtès writes:
Hello!
> Jan Nieuwenhuizen skribis:
>
>> --- a/gnu/packages/hurd.scm
>> +++ b/gnu/packages/hurd.scm
[...]
>> + (substitute* "hurd/paths.h"
>> + (("_HURD_STARTUP\t")
>> + (string-append "_HURD_STARTUP\t\"" out "\" "))
>> +
Hi!
Jan Nieuwenhuizen skribis:
> --- a/gnu/packages/hurd.scm
> +++ b/gnu/packages/hurd.scm
> @@ -390,6 +390,8 @@ PATH=@PATH@
>
> fsck --yes --force /
> fsysopts / --writable
> +
> +# Note: this /hurd/ gets substituted
> settrans -c /servers/socket/1 /hurd/pflocal
>
> # parse multiboot ar
Mathieu Othacehe writes:
Hi!
>> Legend (in order of merge'ability / is there a convention for this?):
>>
>> [M] Mathieu
>> [L] Ludo
>>g good to go LGTM'd
>>t trivial (self-LGTM :-)
>>. direct dependency of/partially superseded by a LGTM
>>
>> ack or review needed
>>!
Hey!
> Legend (in order of merge'ability / is there a convention for this?):
>
> [M] Mathieu
> [L] Ludo
>g good to go LGTM'd
>t trivial (self-LGTM :-)
>. direct dependency of/partially superseded by a LGTM
>
> ack or review needed
>! troublesome
Hehe, nice one :)
Ludovic Courtès writes:
>> From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001
>> From: "Jan (janneke) Nieuwenhuizen"
>> Date: Thu, 30 Apr 2020 15:40:07 +0200
>> Subject: [PATCH v2] gnu: services: Add %hurd-startup-service.
>>
>> This decouples startup of the Hurd from the "hur
Hi,
Jan Nieuwenhuizen skribis:
> From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001
> From: "Jan (janneke) Nieuwenhuizen"
> Date: Thu, 30 Apr 2020 15:40:07 +0200
> Subject: [PATCH v2] gnu: services: Add %hurd-startup-service.
>
> This decouples startup of the Hurd from the "
Ludovic Courtès writes:
Hello!
> Jan Nieuwenhuizen skribis:
>
>>> Having an RC argument passed directly by the bootloader seems like a
>>> good way to proceed for me. This is somehow remotely similar to what we
>>> are doing with the "initrd" on Linux (pointing to some piece of code
>>> that nee
Hi,
Jan Nieuwenhuizen skribis:
>> Having an RC argument passed directly by the bootloader seems like a
>> good way to proceed for me. This is somehow remotely similar to what we
>> are doing with the "initrd" on Linux (pointing to some piece of code
>> that needs to be loaded before starting the
Mathieu Othacehe writes:
Hi Mathieu,
> Having an RC argument passed directly by the bootloader seems like a
> good way to proceed for me. This is somehow remotely similar to what we
> are doing with the "initrd" on Linux (pointing to some piece of code
> that needs to be loaded before starting th
> Now, how could we have runsystem run another RC? Hmm, runsystem is
> being called with --load and --system arguments too; we could even
> give it an --rc=RC-FILE if that's more convenient.
>
> Then, we would only need to add this RC-FILE to the system, maybe add a
> %hurd-"something" service?
Mathieu Othacehe writes:
Hello Mathieu,
>> I have managed to completely boot-activation. Still using the same
>> patch for hurd-directives, but I've got a feeling we're getting real
>> close now.
>
> Just discovered your (gnu build hurd-boot), that's awesome!
Thanks...yeah I was just attempting
Hello Jan,
> I have managed to completely boot-activation. Still using the same
> patch for hurd-directives, but I've got a feeling we're getting real
> close now.
Just discovered your (gnu build hurd-boot), that's awesome! I wonder if
we could go one step further and move the "rc" script outs
Mathieu Othacehe writes:
Hello!
> About that, I'd like to limit at maximum the (if hurd ...) conditionals
> in (gnu system image).
>
> So for the "make-device-node", I would propose to "link" it to the
> image definition, as proposed in the attached patch.
>
> I'll see if we can do something simi
Mathieu Othacehe writes:
Hello Mathieu,
> That's a good summary of the (complex) situation, thank you!
Yeah...well sorry for helping create such a mess :-)
>> Mattieu is looking into cleaning up of
>>
>> b605a36031 * origin/wip-hurd-vm WIP hurd-directives
>
> About that, I'd like to limit at ma
Hello Jan,
That's a good summary of the (complex) situation, thank you!
> Mattieu is looking into cleaning up of
>
> b605a36031 * origin/wip-hurd-vm WIP hurd-directives
About that, I'd like to limit at maximum the (if hurd ...) conditionals
in (gnu system image).
So for the "make-device-node",
Hello!
TL; DR: I propose to rebase on master, squash the squash!es, collapse
the Reverts, hard reset and => review+finish the rest, merge!
So...
After about two months in the working, current wip-hurd-vm
commit 6a284069188f59553f27760614ffb604b49ec62b
squash! linux-boot: Update 'make-hu
18 matches
Mail list logo
