Github messages for voidlinux
 help / color / mirror / Atom feed
From: mobinmob <mobinmob@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: s6/66 integration (previously boot-66serv )
Date: Sat, 17 Feb 2024 16:40:08 +0100	[thread overview]
Message-ID: <20240217154008.EC1D529C5D@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-45578@inbox.vuxu.org>

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

New comment by mobinmob on void-packages repository

https://github.com/void-linux/void-packages/pull/45578#issuecomment-1950238891

Comment:
> Oh good to know. Am I assuming correct that the values in the `[]` of each line in the [configuration file](https://git.obarun.org/obmods/boot-66serv/-/blob/master/configure?ref_type=heads) are showing the default value for the argument? If so, could we remove the `KEYMAP` argument in the template? Are the `TTY` and `TZ` arguments necessary for the building process?

The configuration file for the boot@ service contains by default all possible keys. 
That may change in the future but the upstream logic is to be explicit in configuration. In order to prevent anything missing that may result in weird behaviour, I have created a way to test the configuration ([see here](https://git.obarun.org/obmods/boot-66serv/-/merge_requests/1)) and missing keys is an error.  
The configure arguments in the template are just the default values that the void configuration has, nothing more. They are there only to ensure that the default configuration mathes the voidlinux default one.
`66boot-rc.conf` can populate the configuration with the values from the void `/etc/rc.conf` file and `66boot-starage-autoconf` finds the correct values for ZFS,BTRFS etc.

  parent reply	other threads:[~2024-02-17 15:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-13 14:23 [PR PATCH] s6/66 integration (previously boot-66) mobinmob
2023-08-13 14:34 ` mobinmob
2023-10-01 17:12 ` s6/66 integration (previously boot-66serv ) mobinmob
2023-12-31  1:47 ` github-actions
2024-01-01 10:30 ` mobinmob
2024-02-07 16:52 ` dataCobra
2024-02-07 17:01 ` mobinmob
2024-02-07 17:05 ` mobinmob
2024-02-07 17:11 ` dataCobra
2024-02-07 17:37 ` mobinmob
2024-02-07 17:38 ` mobinmob
2024-02-17 14:42 ` dataCobra
2024-02-17 14:44 ` dataCobra
2024-02-17 14:50 ` dataCobra
2024-02-17 14:51 ` dataCobra
2024-02-17 14:51 ` dataCobra
2024-02-17 14:52 ` dataCobra
2024-02-17 15:14 ` mobinmob
2024-02-17 15:15 ` mobinmob
2024-02-17 15:28 ` dataCobra
2024-02-17 15:30 ` dataCobra
2024-02-17 15:40 ` mobinmob [this message]
2024-02-17 15:48 ` mobinmob
2024-02-17 15:50 ` mobinmob
2024-02-17 15:51 ` mobinmob
2024-05-18  1:46 ` github-actions
2024-05-18 20:49 ` mobinmob

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=20240217154008.EC1D529C5D@inbox.vuxu.org \
    --to=mobinmob@users.noreply.github.com \
    --cc=ml@inbox.vuxu.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).