bug#56137: [PATCH 2/2] gnu: openssl-1.1: Run the test suite through datefudge.

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Fixes .
>
> * gnu/packages/tls.scm (openssl-1.1): Bind a RELEASE-DATE variable.
> [arguments]: Invoke the test suite through datefudge, to avoid certificates
> from expiring as time passes.
> [native-inputs]: Add datefudge.

Hmm, sorry for the noise, I got tricked into building the graft, which
is openssl-1.1.1t, not openssl-1.1.1l.

The patch doesn't fix the issue :-(.

-- 
Thanks,
Maxim

bug#56137: [PATCH 2/2] gnu: openssl-1.1: Run the test suite through datefudge.

[Maxim Cournoyer]

Fixes .

* gnu/packages/tls.scm (openssl-1.1): Bind a RELEASE-DATE variable.
[arguments]: Invoke the test suite through datefudge, to avoid certificates
from expiring as time passes.
[native-inputs]: Add datefudge.

---

 gnu/packages/tls.scm | 266 +++
 1 file changed, 144 insertions(+), 122 deletions(-)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 524b801443..c20548e89a 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -492,130 +492,152 @@ (define (target->openssl-target target)
 (string-append kernel "-" arch
 
 (define-public openssl-1.1
-  (package
-(name "openssl")
-(version "1.1.1l")
-(replacement openssl/fixed)
-(source (origin
-  (method url-fetch)
-  (uri (list (string-append 
"https://www.openssl.org/source/openssl-";
-version ".tar.gz")
- (string-append "ftp://ftp.openssl.org/source/";
-"openssl-" version ".tar.gz")
- (string-append "ftp://ftp.openssl.org/source/old/";
-(string-trim-right version 
char-set:letter)
-"/openssl-" version ".tar.gz")))
-  (patches (search-patches "openssl-1.1-c-rehash-in.patch"))
-  (sha256
-   (base32
-"1lbblxps2fhmz7bqh058iywh5wxfignbfx1s1kz2fj63b5g3wyhb"
-(build-system gnu-build-system)
-(outputs '("out"
-   "doc";6.8 MiB of man3 pages and full HTML documentation
-   "static"))   ;6.4 MiB of .a files
-(native-inputs (list perl))
-(arguments
- (list
-  #:parallel-tests? #f
-  #:test-target "test"
-
-  ;; Changes to OpenSSL sometimes cause Perl to "sneak in" to the closure,
-  ;; so we explicitly disallow it here.
-  #:disallowed-references (list (canonical-package perl))
-  #:phases
-  #~(modify-phases %standard-phases
-  #$@(if (%current-target-system)
- #~((add-before 'configure 'set-cross-compile
-  (lambda* (#:key target #:allow-other-keys)
-(setenv "CROSS_COMPILE" (string-append target "-"))
-(setenv "CONFIGURE_TARGET_ARCH"
-#$(target->openssl-target
-   (%current-target-system))
- #~())
-  ;; This test seems to be dependant on kernel features.
-  ;; https://github.com/openssl/openssl/issues/12242
-  #$@(if (or (target-arm?)
- (target-riscv64?))
- #~((replace 'check
-  (lambda* (#:key tests? test-target #:allow-other-keys)
-(when tests?
-  (invoke "make" "TESTS=-test_afalg" test-target)
- #~())
-  (replace 'configure
-(lambda* (#:key configure-flags #:allow-other-keys)
-  (let* ((out #$output)
- (lib (string-append out "/lib")))
-;; It's not a shebang so patch-source-shebangs misses it.
-(substitute* "config"
-  (("/usr/bin/env")
-   (string-append (assoc-ref %build-inputs "coreutils")
-  "/bin/env")))
-(apply
- invoke #$@(if (%current-target-system)
-   #~("./Configure")
-   #~("./config"))
- "shared"   ;build shared libraries
- "--libdir=lib"
+  ;; Note to maintainers: when updating this package, make sure to update the
+  ;; RELEASE-DATE variable below.  It is used by datefudge to avoid time bombs
+  ;; in the test suite.
+  (let ((release-date "2021-12-14 00:00"))
+(package
+  (name "openssl")
+  (version "1.1.1l")
+  (replacement openssl/fixed)
+  (source (origin
+(method url-fetch)
+(uri (list (string-append 
"https://www.openssl.org/source/openssl-";
+  version ".tar.gz")
+   (string-append "ftp://ftp.openssl.org/source/";
+  "openssl-" version ".tar.gz")
+   (string-append "ftp://ftp.openssl.org/source/old/";
+  (string-trim-right version 
char-set:letter)
+  "/openssl-" version ".tar.gz")))
+(patches (search-patches "openssl-1.1-c-rehash-in.patch"))
+(sha256
+ (base32
+  "1lbblxps2fhmz7bqh058iywh5wxfignbfx1s1kz2fj63b5g3wyhb"
+  (build-system gnu-build-system)
+  (outputs '("out"
+ "doc"  ;6.8 MiB of man3 pages and f

bug#56137: [PATCH 1/2] gnu: openssl-1.1: Do not quasiquote arguments.

[Maxim Cournoyer]

* gnu/packages/tls.scm (openssl-1.1): Do not quasiquote arguments.
---

 gnu/packages/tls.scm | 190 +--
 1 file changed, 94 insertions(+), 96 deletions(-)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 59e0e28feb..524b801443 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -15,7 +15,7 @@
 ;;; Copyright © 2018 Clément Lassieur 
 ;;; Copyright © 2019 Mathieu Othacehe 
 ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
-;;; Copyright © 2020, 2021 Maxim Cournoyer 
+;;; Copyright © 2020, 2021, 2023 Maxim Cournoyer 
 ;;; Copyright © 2021 Solene Rapenne 
 ;;; Copyright © 2021 Brice Waegeneire 
 ;;; Copyright © 2021 Maxime Devos 
@@ -515,107 +515,105 @@ (define-public openssl-1.1
"static"))   ;6.4 MiB of .a files
 (native-inputs (list perl))
 (arguments
- `(#:parallel-tests? #f
-   #:test-target "test"
+ (list
+  #:parallel-tests? #f
+  #:test-target "test"
 
-   ;; Changes to OpenSSL sometimes cause Perl to "sneak in" to the closure,
-   ;; so we explicitly disallow it here.
-   #:disallowed-references ,(list (canonical-package perl))
-   #:phases
-   ,#~
-   (modify-phases %standard-phases
- #$@(if (%current-target-system)
-#~((add-before
-   'configure 'set-cross-compile
- (lambda* (#:key target #:allow-other-keys)
-   (setenv "CROSS_COMPILE" (string-append target "-"))
-   (setenv "CONFIGURE_TARGET_ARCH"
-   #$(target->openssl-target
-  (%current-target-system))
-#~())
- ;; This test seems to be dependant on kernel features.
- ;; https://github.com/openssl/openssl/issues/12242
- #$@(if (or (target-arm?)
-(target-riscv64?))
-#~((replace 'check
- (lambda* (#:key tests? test-target #:allow-other-keys)
-   (when tests?
- (invoke "make" "TESTS=-test_afalg" test-target)
-#~())
- (replace 'configure
-   (lambda* (#:key configure-flags #:allow-other-keys)
- (let* ((out #$output)
-(lib (string-append out "/lib")))
-   ;; It's not a shebang so patch-source-shebangs misses it.
-   (substitute* "config"
- (("/usr/bin/env")
-  (string-append (assoc-ref %build-inputs "coreutils")
- "/bin/env")))
-   (apply
-invoke #$@(if (%current-target-system)
-  #~("./Configure")
-  #~("./config"))
-"shared";build shared libraries
-"--libdir=lib"
+  ;; Changes to OpenSSL sometimes cause Perl to "sneak in" to the closure,
+  ;; so we explicitly disallow it here.
+  #:disallowed-references (list (canonical-package perl))
+  #:phases
+  #~(modify-phases %standard-phases
+  #$@(if (%current-target-system)
+ #~((add-before 'configure 'set-cross-compile
+  (lambda* (#:key target #:allow-other-keys)
+(setenv "CROSS_COMPILE" (string-append target "-"))
+(setenv "CONFIGURE_TARGET_ARCH"
+#$(target->openssl-target
+   (%current-target-system))
+ #~())
+  ;; This test seems to be dependant on kernel features.
+  ;; https://github.com/openssl/openssl/issues/12242
+  #$@(if (or (target-arm?)
+ (target-riscv64?))
+ #~((replace 'check
+  (lambda* (#:key tests? test-target #:allow-other-keys)
+(when tests?
+  (invoke "make" "TESTS=-test_afalg" test-target)
+ #~())
+  (replace 'configure
+(lambda* (#:key configure-flags #:allow-other-keys)
+  (let* ((out #$output)
+ (lib (string-append out "/lib")))
+;; It's not a shebang so patch-source-shebangs misses it.
+(substitute* "config"
+  (("/usr/bin/env")
+   (string-append (assoc-ref %build-inputs "coreutils")
+  "/bin/env")))
+(apply
+ invoke #$@(if (%current-target-system)
+   #~("./Configure")
+   #~("./config"))
+ "shared"   ;build shared libraries
+ "--libdir=lib"
 
-;; The default for this catch-all directory is
-;; PREFIX/ssl.  Change that to something more
-;; conventional.
-(string-append "--openssldir="

bug#61798: infodoc patch doesn't apply to linux 6.2

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> On Wed, Nov 16, 2022 at 11:55:51AM -0500, Maxim Cournoyer wrote:
>>  .../patches/linux-libre-infodocs-target.patch |  88 ++
>
> This patch doesn't apply to linux-libre 6.2.1, as shown below. If I
> understand correctly, it's been applied upstream, but I don't understand
> how to adjust things on our end.

It's indeed been applied upstream.  Can't we just drop our local version
of it?

-- 
Thanks,
Maxim

bug#58813: [PATCH] doc: Document how to use Patman for patches submission.

[Maxim Cournoyer]

Fixes .

* doc/contributing.texi (Sending a Patch Series): Mention Patman.  Adjust the
examples to no longer showcase broken command substitutions.  Add a section
about how to use Patman, with examples.

---

 doc/contributing.texi | 119 ++
 doc/guix.texi |   2 +-
 2 files changed, 110 insertions(+), 11 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index c436bc4a31..2a12dffefe 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1416,12 +1416,19 @@ git config --local sendemail.thread no
 @cindex @code{git format-patch}
 
 @unnumberedsubsubsec Single Patches
-@anchor{Single Patches}
-The @command{git send-email} command is the best way to send both single
-patches and patch series (@pxref{Multiple Patches}) to the Guix mailing
-list.  Sending patches as email attachments may make them difficult to
-review in some mail clients, and @command{git diff} does not store commit
-metadata.
+@cindex patman patch manager
+@cindex patch management, via patman
+@anchor{Single Patches} The @command{git send-email} command is the best
+way to send both single patches and patch series (@pxref{Multiple
+Patches}) to the Guix mailing list.  Sending patches as email
+attachments may make them difficult to review in some mail clients, and
+@command{git diff} does not store commit metadata.  If you want
+something a bit higher level than @command{git send-email} to organize
+your patch submissions and take care of its various options for you, you
+may want to try the @command{patman} command, from the eponymous
+package.  Patman's help can be accessed via @samp{patman -H} or as an
+Info manual after installing the @code{u-boot-documentation} package
+(@pxref{Patman patch manager,,,u-boot,The U-Boot Documentation}).
 
 @quotation Note
 The @command{git send-email} command is provided by the @code{send-email}
@@ -1521,7 +1528,7 @@ that we can send the rest of the patches to.
 @example
 $ git send-email outgoing/-cover-letter.patch -a \
   --to=guix-patches@@gnu.org \
-  $(etc/teams.scm cc-members ...)
+  --cc=team-member1@@example.org --cc=team-member2@@example.org ...
 $ rm outgoing/-cover-letter.patch # we don't want to resend it!
 @end example
 
@@ -1535,7 +1542,7 @@ can send the actual patches to the newly-created issue 
address.
 @example
 $ git send-email outgoing/*.patch \
   --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org \
-  $(etc/teams.scm cc-members ...)
+  --cc=team-member1@@example.org --cc=team-member2@@example.org ...
 $ rm -rf outgoing # we don't need these anymore
 @end example
 
@@ -1578,18 +1585,110 @@ You can run the following command to have the 
@code{Mentors} team put in
 CC of a patch series:
 
 @example
-$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org $(./etc/teams.scm cc 
mentors) *.patch
+$ ./etc/teams.scm cc mentors
 @end example
 
+then note the @var{output} of the script.
+
+@example
+$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org @var{output} *.patch
+@end example
+
+Taking care to manually splice the @var{output} of the
+@file{etc/teams.scm} script into the command.
+
 The appropriate team or teams can also be inferred from the modified
 files.  For instance, if you want to send the two latest commits of the
 current Git repository to review, you can run:
 
 @example
 $ guix shell -D guix
-[env]$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org 
$(./etc/teams.scm cc-members HEAD~2 HEAD) *.patch
+[env]$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org @var{output} 
*.patch
 @end example
 
+@cindex patman, usage example
+As manually stitching the output of the @file{etc/teams.scm} script in
+the @command{git send-email} command can get tedious; you may prefer to
+use Patman to automate this for you.  Its necessary basic configuration
+is already found at the root of the Guix repository, in the
+@file{.patman} file.  Another useful bit to have is a default
+destination for the @command{git send-email} command.  You can specify
+it in your repository-local Guix @file{.git/config} file with:
+
+@example
+[sendemail]
+to = guix-patches@@gnu.org
+@end example
+
+To send a long series to Debbugs, the patches can be written to the
+current directory with:
+
+@example
+patman -n
+@end example
+
+The first patch should then be sent using @samp{git send-email
+-cover-letter.patch}, as explained earlier (@pxref{Multiple
+Patches}).
+
+After Debbugs has issued a unique bug email in reply to that initial
+patch submission, e.g. @email{N@@debbugs.gnu.org}, you can save this
+information into the top commit of your patch series (it doesn't matter
+which, but it's more convenient to amend it later when it's at the top)
+like so, via the Patman-specific @code{Series-to} git message tag:
+
+@example
+gnu: Add foo.
+
+* gnu/packages/dummy.scm: Add foo.
+
+Series-to: N@@debbugs.gnu.org
+@end example
+
+You can then se

bug#61798: infodoc patch doesn't apply to linux 6.2

[Leo Famulari]

On Wed, Nov 16, 2022 at 11:55:51AM -0500, Maxim Cournoyer wrote:
>  .../patches/linux-libre-infodocs-target.patch |  88 ++

This patch doesn't apply to linux-libre 6.2.1, as shown below. If I
understand correctly, it's been applied upstream, but I don't understand
how to adjust things on our end.

Can you take a look and send a patch that applies on top of #61770?

https://issues.guix.gnu.org/issue/61770

https://ci.guix.gnu.org/build/469982/details
--
applying 
'/gnu/store/b9kc2xs6407hmpzcvx44g1mi88ls0509-linux-libre-infodocs-target.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/6hr5qlvj92idkp2hmnwk7f16ah4?")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "lin?") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # ?)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # _)
In guix/build/utils.scm:
762:6  0 (invoke "/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-p?" ?)

guix/build/utils.scm:762:6: In procedure invoke:
ERROR:
  1. &invoke-error:
  program: 
"/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
"/gnu/store/b9kc2xs6407hmpzcvx44g1mi88ls0509-linux-libre-infodocs-target.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
builder for
`/gnu/store/qvhbmfmsjryxs0mwmv0apl2110vdmaz2-linux-libre-6.2.1-guix.tar.xz.drv' 
failed with exit code 1
--

bug#58428: [PATCH 1/2] gnu: ddcutil: Update to 1.3.2.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Closing this stale bug which was accidentally filed against ‘debbugs’ 
itself, not ‘guix’!


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#61795: “guix deploy” doesn’t build all derivations remotely

[Ricardo Wurmus]

I’m running “guix deploy deploy.scm” on a x86_64 host.  The deploy.scm
file looks like this:



deploy.scm
Description: Binary data

The target machine architecture is aarch64-linux, and the x86_64 host
cannot offload to any aarch64-linux machines.  The machine declaration
has the “build-locally?” property set to #false.  The manual says:

 ‘build-locally?’ (default: ‘#t’)
  If false, system derivations will be built on the machine
  being deployed to.

Not all derivations are built on the target machine, though:

--8<---cut here---start->8---
$ guix deploy deploy.scm
The following 1 machine will be deployed:
  elephly

guix deploy: deploying to elephly...
guix deploy: sending 0 store items (0 MiB) to '192.168.178.20'...
guix deploy: sending 0 store items (0 MiB) to '192.168.178.20'...
guix deploy: warning: the following accounts appear more than once: mpd
guix deploy: warning: the following accounts appear more than once: mpd
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation will be built:
  
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv

8.1 MB will be downloaded
 guile-static-stripped-3.0.9  6.7MiB
   2.3MiB/s 00:03 ▕██▏ 100.0%
 e2fsprogs-1.46.4  1.1MiB   
   2.3MiB/s 00:00 ▕██▏ 100.0%
building 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv...
|builder for 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv'
 failed with exit code 1
build of 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv
 failed
View build log at 
'/var/log/guix/drvs/4c/py9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv.gz'.
guix deploy: error: build of 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv'
 failed
--8<---cut here---end--->8---

These are the contents of the build log:

--8<---cut here---start->8---
@ unsupported-platform 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv
 aarch64-linux
while setting up the build environment: a `aarch64-linux' is required to build 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv',
 but I am a `x86_64-linux'
--8<---cut here---end--->8---

It is also of note that a build of this derivation is attempted even
though it has successfully been built on the target machine.

-- 
Ricardo

bug#61557: vdirsyncer fails to verify certificates

[Leo Famulari]

Thanks for the report!

Did you follow the instructions about X.509 Certificates in the manual
section Application Setup? That section is about using Guix on other
distros.

I use vdirsyncer from Guix on Debian and it works fine when validating
X.509 / TLS / HTTPS certificates.

bug#61722: (guix cpio) produces corrupted archives when there are non-ASCII filenames

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Fixes .
>
> * guix/cpio.scm (file->cpio-header): Compute the file name length in bytes 
> rather than in
> characters.
> (file->cpio-header*, special-file->cpio-header*): Likewise.
> (write-cpio-archive): Likewise, and write the file name as UTF-8 bytes, not
> textually, to avoid encoding it as ISO-8859-1.

Pushed to master.

Closing.

-- 
Thanks,
Maxim

bug#61570: [PATCH] services: mpd: Use proper records.

[Maxim Cournoyer]

Hi,

Bruno Victal  writes:

> Hi Maxim, Liliana
>
> On 2023-02-18 17:42, Liliana Marie Prikler wrote:> This patch fixes the issue 
> of not being able to insert actual users and
>> groups into MPD service.  Sadly, as define-configuration lacks proper
>> support for sanitizers, it's a backwards-incompatible change.
>> Perhaps it makes sense to extend define-configuration to support this
>> case?
>
> I'd like to ask to hold merging this patch yet. I've got a few additional 
> patches that addresses
> some usability issues and IMO we can get a nicer patch by fixing 
> define-configuration directly (whilst preserving API compatibility).
> My intention is to patch define-configuration to accept a custom-sanitizer if 
> specified.

Sounds good!  Thanks for working toward that.

-- 
Thanks,
Maxim

bug#56584: vala build uses bundled bootstrap binaries

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Samstag, dem 16.07.2022 um 10:18 +0200 schrieb Liliana Marie
> Prikler:
>> The code in vala-bootstrap does not appear helpful, it in fact reads
>> exactly like Vala-compiled Vala.
> I've now hosted my own vala-bootstrap [1], which has valacompiler.c and
> gee translated to more readable C already.  I'd be happy to take in
> patches or transfer it to the bootstrappable project.
>
> Cheers
>
> [1] https://gitlab.gnome.org/lilyp/vala-bootstrap

Neat!  Will you send patches to use it to bootstrap our vala in Guix?

-- 
Thanks,
Maxim

bug#61684: can't compose 'with-patch' with 'with-source'

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi Maxim,
>
> On Fri, 24 Feb 2023 at 08:52, Maxim Cournoyer  
> wrote:
>
>> if the API was consistent it'd be much easier for everyone
>
> Indeed.  However, when it is currently not, the implicit rule is to not
> break backward compatibility.  That’s the whole point. :-)
>
> We need to be very cautious when we change the API; even when it is for
> fixing an inconsistency.

Agreed; if the current behavior really provides well outlined benefits,
we could always introduce a "--order-sensitive" option for its users.

-- 
Thanks,
Maxim

bug#60657: Rethinking how service extensions work

[Ludovic Courtès]

Hi Bruno,

Bruno Victal  skribis:

> The current situation with services in Guix is that service extensions do not 
> care about dependencies.

This is the result of “services” being unrelated to “Shepherd services”,
as noted in the manual (info "(guix) Services").

> This can result in cryptic errors as seen in [1].
>
> [1] https://issues.guix.gnu.org/57589#12
>
> In [1], the issue arises from using activation-service-type to create 
> files/directories for services
> when these should be either (1) shepherd one-shot services or moved into the 
> 'start' procedure of the service.
> 'activation-service-type' should only be used for doing things "listed on its 
> label", that is, performing
> actions at boot-time or after a system reconfigure.

Right.

As we once discussed on IRC, the conclusion to me is that some of the
code currently implemented as activation snippets should rather be
implemented either as part of the ‘start’ method of the corresponding
Shepherd service, or as a one-shot Shepherd service that the main
service would depend on.

> But both solutions (1) and (2) are still not enough as the directories 
> themselves might not yet
> be available and the services must be aware of this fact and wait for them to 
> be ready. One example
> would be a network dependent mount or a simple service that mounts a volume 
> such as:
>
> (simple-service 'mount-overlayfs shepherd-root-service-type
> (list (shepherd-service (requirement '(foo-mount))
> (provision '(overlayfs-foo))
> (documentation "Mount OverlayFS.")
> (one-shot? #t)
> (start (let ((util-linux (@ (gnu 
> packages linux) util-linux)))
>  #~(lambda _
>  (system* #$(file-append 
> util-linux "/bin/mount")
>   "-t" "overlay"
>   "-o" 
> (string-append "noatime,nodev,noexec,ro,"
>   
> "lowerdir="
>   
> (string-join '("/srv/foo/overlays/top-layer"
>   
>"/srv/foo/overlays/layer2"
>   
>"/srv/foo/overlays/layer1"
>   
>"/media/foo-base") ":"))
>   "none" 
> "/media/foo" )))

Note that this should prolly be declared as a ‘file-system’ rather than
as a custom service.  That way, it would get a “standard” Shepherd
service.

There are cases where we add explicit dependencies on
‘file-system-/media/foo’ or similar.   has a ‘dependencies’
field specifically for this purpose (info "(guix) File Systems").

Would that work for you?

HTH,
Ludo’.

bug#61684: can't compose 'with-patch' with 'with-source'

[Simon Tournier]

Hi Maxim,

On Fri, 24 Feb 2023 at 08:52, Maxim Cournoyer  wrote:

> if the API was consistent it'd be much easier for everyone

Indeed.  However, when it is currently not, the implicit rule is to not
break backward compatibility.  That’s the whole point. :-)

We need to be very cautious when we change the API; even when it is for
fixing an inconsistency.

Cheers,
simon