[bug#55231,v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

This patch allows copying of out-of-tree kernel modules to the Linux
initrd.

For out-of-tree modules to found, an extra slot has been added to
‘operating-system’: ‘initrd-extra-module-paths’, which contains a list
containing items of either FILE-LIKE or (FILE-LIKE OUTPUT) which will be
searched for modules in addition to the standard Linux module path. The
required modules can then be added to ‘initrd-modules’ as normal and all paths
will be searched for it, including for any modules depended on.

* gnu/build/linux-modules.scm (find-module-file): change DIRECTORY argument to
DIRECTORIES. Now takes a list of directories to search, rather than a single
one.
* gnu/system.scm <operating-system>: Add INITRD-EXTRA-MODULE-PATHS
field and accessor. Takes a list of file-like objects.
* gnu/system/linux-initrd.scm (flat-linux-module-directory): change LINUX
argument to PACKAGES. Now contains a list of file-likes to search for modules.
(raw-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it
to (flat-linux-extra-module-paths) along with the selected LINUX package.
(base-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it
to (raw-initrd).
---
 gnu/build/linux-modules.scm | 19 ++++++++------
 gnu/system.scm              |  5 ++++
 gnu/system/linux-initrd.scm | 52 +++++++++++++++++++++++++------------
 3 files changed, 51 insertions(+), 25 deletions(-)


base-commit: 0a64b629ae8512790d532158a72a4a25698e8157
prerequisite-patch-id: 213ce2b9743f11d45836fe0794f117f3bb84063d
  

Brian Cully via Guix-patches via schreef op ma 02-05-2022 om 15:11 [-
0400]:
> This patch allows copying of out-of-tree kernel modules to the Linux
> initrd.

This needs some information in the manual -- when does the field need
to be set?  For what kernel modules?  Is this required by v4l2loopback-
linux-module and librem-ec-acpi-linux-module?  Things like that.
As-is, this functionality is hard to discover.

Greetings,
Maxime.
  

I've read through the original patch and the doc patch, and based on my own tinkering with guix initrd generation, the patches look good to me. I'm also happy to see the functionality being added, and already have plans for using it with zfs (to further the goal of an encrypted multi-disk zfs root).

Cheers,
Kaelyn
  

(for whatever reason, looks like this didn't end up in my inbox)
> +@item @code{initrd-extra-module-paths} (default: @code{'()})
> [...]
> The items in this may be either file-like objects (usually 
> packages), or
> +a list where the first element is a package and the second is an
> +output--e.g. @code{(list (list zfs "module"))}.


As-is, I don't think this is a good example, because
'expression->initrd' does not set #:substitutable? #false,
the 'zfs' package has the comment (*)

     `(;; The ZFS kernel module should not be downloaded since the
license
       ;; terms don't allow for distributing it, only building it
locally.
       #:substitutable? #f [...])

and IIUC, the code inside expression->initrd copies the kernel module
into
the new store item, so it looks like this accidentally suggest people
to
commit copyvios, and copyvios are currently against the law.

Greetings,
Maxime.

(*) Though I don't understand that comment: Guix is a distribution, so
by definition
it's distributing zfs -- unless it's only talking about the binaries
and not the
source code ...
  

As the earlier patch discussion seemed to have focused on ZFS licensing issues that are largely orothogonal to the functionality being added, I'd like to again voice my support for the proposed patch. While ZFS is indeed a bad example due to open questions about module licensing and redistribution, it isn't the only out-of-tree module currently packaged in Guix which could be used with the extra initrd support (not counting future packages or external channels). Within the guix repo, the packages using the `linux-module-build-system` aside from zfs are:
- acpi-call-linux-module
- bbswitch-module
- ddcci-driver-linux
- rtl8812au-aircrack-ng-linux-module
- rtl8821ce-linux-module
- ttyebus-linux-module
- v4l2loopback-linux-module
- vhba-module
- wiregard-linux-compat

Of those nine, at least four look to be for specific hardware, and I can come up with theoretical use cases for why someone might want those or wiregard-linux-compat (though the cases are definitely contrived straw-men that may or may not be implementable in practice or actually useful in an initrd context, such as network booting with an older kernel and the root filesystem can only be accessed over a wireguard connection).

Cheers,
Kaelyn
  

Hi,

My $0.02 on 'initrd-extra-module-paths' vs 'kernel-loadable-modules': if the initrd code is smart enough to not include the entire packages and only includes the requested modules from the packages (which I think is already true based on behavior observed some time ago), then not having to duplicate the list would be preferable.

I found this issue in the tracker after being surprised that the initrd builder ignored 'kernel-loadable-modules' with 'initrd-modules' only working for modules that are included in the primary linux kernel package. That surprise over the incompatibility between 'initrd-modules' and 'kernel-loadable-modules' is also why I've been relatively vocal about the patch. ;)

Cheers,
Kaelyn
  

Hi again,

Regarding the documentation example, one (contrived) alternative is:

"""
For example, if you need the driver for a Realtek RTL8821CE wireless network adapter for mounting the root filesystem over NFS, your configuration might include the following:

@lisp
(operating-system
  ;; @dots{}
  (initrd-modules (cons "8821ce" %base-initrd-modules))
  (kernel-loadable-modules (list (list rtl8821ce-linux-module "module"))))
@end lisp
"""

While I don't have the hardware, I did verify the kernel module name by building the rtl8821ce-linux-module package.

Cheers,
Kaelyn
  

Hi,

I just want to say that the latest v4 of the patches look good to me, and has removed the example with the questionable licensing situation. I have also been using this patch quite successfully, in a slightly modified version (mostly module name changes) imported into a local channel, for almost 2 years now.

Also, if needed, I would be happy to rebase the patches against the current master.

Cheers,
Kaelyn
  

I've made a (hopefully acceptable) attempt to rebase the patches on the newest master of the Guix repo. If there's anything preventing these patches from being merged, please let me know.

Best,

Morgan
  

Hi all,

As a bit of an aside, I'm wondering if it wouldn't be possible to eliminate the possibility of even potential copyviols by a change to the `derivation` function? It currently sets environment variable for the builder daemon by setting `allowSubstitutes = 0` if `(not substitutable?)`. If non-substitutability were propagated by doing something like instead setting `allowSubstitutes = 0` if `(not substitutable?)` or if `(not (every substitutable-derivation? inputs))`, wouldn't this suffice to ensure that an initrd which contains non-substitutable inputs is properly marked non-substitutable?

It might be more correct to allow derivations built with non-substitutable native inputs to be substitutable nonetheless. The alternative seems like it could cause issues, in particular with the non-substitutable texlive package being used as a native input to build documentation.

Best,

Morgan
  

On 9/02/2025 23:42, Morgan Arnold wrote:

> Hi all,
>
> As a bit of an aside, I'm wondering if it wouldn't be possible to eliminate the possibility of even potential copyviols by a change to the `derivation` function? It currently sets environment variable for the builder daemon by setting `allowSubstitutes = 0` if `(not substitutable?)`. If non-substitutability were propagated by doing something like instead setting `allowSubstitutes = 0` if `(not substitutable?)` or if `(not (every substitutable-derivation? inputs))`, wouldn't this suffice to ensure that an initrd which contains non-substitutable inputs is properly marked non-substitutable? [...]

This has effectively already been answered.

Best regards,
Maxime Devos
  

Hello,

Am Sun, Feb 09, 2025 at 10:42:26PM +0000 schrieb Morgan Arnold via Development of GNU Guix and the GNU System distribution.:
> It might be more correct to allow derivations built with non-substitutable native inputs to be substitutable nonetheless. The alternative seems like it could cause issues, in particular with the non-substitutable texlive package being used as a native input to build documentation.

just to clarify, texlive (or more precisely, texlivetexmf) is marked as
non substitutable not because it would not be allowed, but because it is
huge and essentially just an unpacked big tarball. So people had better
build the package by themselves.

And it should not be used as a (native-)input to other packages: We have
the much smaller modular texlive packages for this, which make it
possible to depend precisely on what is needed to build the
documentation.

Andreas
  

Hi Andreas,

Thanks for the clarification. If this is the case, and texlive is unlikely to be used as a native input, it seems reasonable to me that setting `allowSubstitutes = 0` if `(not (and substitutable? (every substitutable-derivation? inputs)))` would entirely eliminate the possibility of ZFS-based copyviols, as any derivation depending on it could not be substituted, and so neither Guix nor anyone using Guix could commit a copyviol. A user who wishes to use ZFS will then download the source code, compile the kernel module, and include it in their initrd, and this initrd will not accidentally be distributed. To the best of my non-lawyer understanding, this would not constitute any kind of copyviol.

This seems to me to implement a maximally conservative (in terms of avoiding possible copyviols) approach to incorporating ZFS into Guix. If this makes sense, I would be happy to include that change to `derivation` in this patch set.

Best,

Morgan

On Monday, February 10th, 2025 at 14:42, Andreas Enge <andreas@enge.fr> wrote:

> 
> 
> Hello,
> 
> Am Sun, Feb 09, 2025 at 10:42:26PM +0000 schrieb Morgan Arnold via Development of GNU Guix and the GNU System distribution.:
> 
> > It might be more correct to allow derivations built with non-substitutable native inputs to be substitutable nonetheless. The alternative seems like it could cause issues, in particular with the non-substitutable texlive package being used as a native input to build documentation.
> 
> 
> just to clarify, texlive (or more precisely, texlivetexmf) is marked as
> non substitutable not because it would not be allowed, but because it is
> huge and essentially just an unpacked big tarball. So people had better
> build the package by themselves.
> 
> And it should not be used as a (native-)input to other packages: We have
> the much smaller modular texlive packages for this, which make it
> possible to depend precisely on what is needed to build the
> documentation.
> 
> Andreas
  

Hi,

Morgan Arnold <morgan.arnold@proton.me> writes:

> Hi Andreas,
>
> Thanks for the clarification. If this is the case, and texlive is
> unlikely to be used as a native input, it seems reasonable to me that
> setting `allowSubstitutes = 0` if `(not (and substitutable? (every
> substitutable-derivation? inputs)))` would entirely eliminate the
> possibility of ZFS-based copyviols, as any derivation depending on it
> could not be substituted, and so neither Guix nor anyone using Guix
> could commit a copyviol. A user who wishes to use ZFS will then
> download the source code, compile the kernel module, and include it in
> their initrd, and this initrd will not accidentally be distributed. To
> the best of my non-lawyer understanding, this would not constitute any
> kind of copyviol.

I'm not sure exactly where in the daemon code this would be implemented?
Would you have a pseudo-code draft of where it'd be done?  Few of us are
knowledgeable about the daemon code base.

> This seems to me to implement a maximally conservative (in terms of
> avoiding possible copyviols) approach to incorporating ZFS into
> Guix. If this makes sense, I would be happy to include that change to
> `derivation` in this patch set.

The idea is logical to me, but the implementation, if it touches how a
derivation is computed/changes its result, IIUC, would invalidate all
past derivations ever computed by Nix/Guix, which would be highly
undesirable/disruptive.
  

Hi Maxim,

Thanks for the input. I think that I communicated the idea that I'm proposing poorly, although I'm not sure if what I'm proposing would actually work. I sent a new version of the patchset with the change that I'm proposing implemented, which should hopefully clarify what I mean. Of course, it's very possible that what I'm suggesting here is unacceptable for some reason that I haven't noticed.

Let me know if this doesn't adequately clarify things!

Best,

Morgan

On Tuesday, February 11th, 2025 at 14:09, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> 
> 
> Hi,
> 
> Morgan Arnold morgan.arnold@proton.me writes:
> 
> > Hi Andreas,
> > 
> > Thanks for the clarification. If this is the case, and texlive is
> > unlikely to be used as a native input, it seems reasonable to me that
> > setting `allowSubstitutes = 0` if `(not (and substitutable? (every substitutable-derivation? inputs)))` would entirely eliminate the
> > possibility of ZFS-based copyviols, as any derivation depending on it
> > could not be substituted, and so neither Guix nor anyone using Guix
> > could commit a copyviol. A user who wishes to use ZFS will then
> > download the source code, compile the kernel module, and include it in
> > their initrd, and this initrd will not accidentally be distributed. To
> > the best of my non-lawyer understanding, this would not constitute any
> > kind of copyviol.
> 
> 
> I'm not sure exactly where in the daemon code this would be implemented?
> Would you have a pseudo-code draft of where it'd be done? Few of us are
> knowledgeable about the daemon code base.
> 
> > This seems to me to implement a maximally conservative (in terms of
> > avoiding possible copyviols) approach to incorporating ZFS into
> > Guix. If this makes sense, I would be happy to include that change to
> > `derivation` in this patch set.
> 
> 
> The idea is logical to me, but the implementation, if it touches how a
> derivation is computed/changes its result, IIUC, would invalidate all
> past derivations ever computed by Nix/Guix, which would be highly
> undesirable/disruptive.
> 
> --
> Thanks,
> Maxim
  

Hi all,

> I'm not sure if what I'm proposing would actually work.

How prophetic.

I did some more testing with the proposed change to `derivation`, and it seems to be causing a weird issue. I didn't think that propagating non-substitutability would be much of a problem, since there are very few non-substitutable packages, but I was surprised to find that this change makes almost all packages non-substitutable! I did some REPL-ing to find the culprit, and it when I traced it back, I found that all of my non-substitutable derivations appeared to be so because their dependency graph included a derivation called `#<derivation /gnu/store/qbrwrmdgnfx3p9gl499f5pyhv0fcnw0a-gcc-11.4.0.drv => /gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib 7fc7c9bb99b0>`.

Unfortunately, I cannot for the life of me figure out what this derivation is, or why it isn't substitutable (all of its inputs are substitutable, and I can't find any relevant package explicitly marked as non-substitutable). I wonder if maybe it has something to do with the `gnu-build-system`? It appears to be an input of `bash-minimal`, which is what leads me to that suspicion. If I could figure out what this derivation is and why it's non-substitutable, I think that the change that the proposed change to `derivation` would work (and, in some sense, implement what ought intuitively to be the default behaviour, as Brian noted).

Any and all relevant thoughts would be much appreciated.

Best,

Morgan
  

Hi Morgan,

Morgan Arnold <morgan.arnold@proton.me> writes:

> Hi all,
>
>> I'm not sure if what I'm proposing would actually work.
>
> How prophetic.
>
> I did some more testing with the proposed change to `derivation`, and
> it seems to be causing a weird issue. I didn't think that propagating
> non-substitutability would be much of a problem, since there are very
> few non-substitutable packages, but I was surprised to find that this
> change makes almost all packages non-substitutable! I did some
> REPL-ing to find the culprit, and it when I traced it back, I found
> that all of my non-substitutable derivations appeared to be so because
> their dependency graph included a derivation called `#<derivation
> /gnu/store/qbrwrmdgnfx3p9gl499f5pyhv0fcnw0a-gcc-11.4.0.drv =>
> /gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib
> 7fc7c9bb99b0>`.

That's probably the GCC implicitly added by gnu-build-system, which is
listed in the %final-inputs variable.

> Unfortunately, I cannot for the life of me figure out what this
> derivation is, or why it isn't substitutable (all of its inputs are
> substitutable, and I can't find any relevant package explicitly marked
> as non-substitutable). I wonder if maybe it has something to do with
> the `gnu-build-system`? It appears to be an input of `bash-minimal`,
> which is what leads me to that suspicion. If I could figure out what
> this derivation is and why it's non-substitutable, I think that the
> change that the proposed change to `derivation` would work (and, in
> some sense, implement what ought intuitively to be the default
> behaviour, as Brian noted).

I'm not sure what's wrong, but I think we could start by investigating
why this changes causes 29 new failures when running:

--8<---------------cut here---------------start------------->8---
export SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1
make check TESTS=tests/derivations.scm
$ make check TESTS=tests/derivations.scm 
make  check-recursive
make[1] : on entre dans le répertoire « /home/maxim/src/guix-spare »
Making check in po/guix
make[2] : on entre dans le répertoire « /home/maxim/src/guix-spare/po/guix »
make[2]: Rien à faire pour « check ».
make[2] : on quitte le répertoire « /home/maxim/src/guix-spare/po/guix »
Making check in po/packages
make[2] : on entre dans le répertoire « /home/maxim/src/guix-spare/po/packages »
make[2]: Rien à faire pour « check ».
make[2] : on quitte le répertoire « /home/maxim/src/guix-spare/po/packages »
make[2] : on entre dans le répertoire « /home/maxim/src/guix-spare »
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
make  check-TESTS check-local
make[3] : on entre dans le répertoire « /home/maxim/src/guix-spare »
make[4] : on entre dans le répertoire « /home/maxim/src/guix-spare »
PASS: tests/derivations.scm - parse & export 
PASS: tests/derivations.scm - add-to-store, flat 
PASS: tests/derivations.scm - add-to-store, recursive 
PASS: tests/derivations.scm - derivation with no inputs 
PASS: tests/derivations.scm - build derivation with 1 source 
FAIL: tests/derivations.scm - derivation fails but keep going 
PASS: tests/derivations.scm - identical files are deduplicated 
PASS: tests/derivations.scm - built-in-builders 
PASS: tests/derivations.scm - unknown built-in builder 
PASS: tests/derivations.scm - 'download' built-in builder 
PASS: tests/derivations.scm - 'download' built-in builder, invalid hash 
PASS: tests/derivations.scm - 'download' built-in builder, not found 
PASS: tests/derivations.scm - 'download' built-in builder, not fixed-output 
PASS: tests/derivations.scm - 'download' built-in builder, no fixed-output hash 
PASS: tests/derivations.scm - 'download' built-in builder, check mode 
PASS: tests/derivations.scm - 'git-download' built-in builder 
PASS: tests/derivations.scm - 'git-download' built-in builder, invalid hash 
PASS: tests/derivations.scm - 'git-download' built-in builder, invalid commit 
PASS: tests/derivations.scm - 'git-download' built-in builder, not found 
PASS: tests/derivations.scm - derivation-name 
PASS: tests/derivations.scm - derivation-output-names 
PASS: tests/derivations.scm - offloadable-derivation? 
PASS: tests/derivations.scm - substitutable-derivation? 
PASS: tests/derivations.scm - fixed-output-derivation? 
PASS: tests/derivations.scm - fixed-output-derivation?, no hash 
PASS: tests/derivations.scm - fixed-output derivation 
PASS: tests/derivations.scm - fixed-output derivation: output paths are equal 
PASS: tests/derivations.scm - fixed-output derivation, recursive 
PASS: tests/derivations.scm - fixed-output derivation, invalid hash size 
PASS: tests/derivations.scm - derivation with a fixed-output input 
PASS: tests/derivations.scm - derivation with duplicate fixed-output inputs 
PASS: tests/derivations.scm - derivation with equivalent fixed-output inputs 
PASS: tests/derivations.scm - multiple-output derivation 
PASS: tests/derivations.scm - multiple-output derivation, non-alphabetic order 
PASS: tests/derivations.scm - read-derivation vs. derivation 
PASS: tests/derivations.scm - read-derivation with hash = #f 
PASS: tests/derivations.scm - multiple-output derivation, derivation-path->output-path 
PASS: tests/derivations.scm - user of multiple-output derivation 
PASS: tests/derivations.scm - derivation with #:references-graphs 
PASS: tests/derivations.scm - derivation #:allowed-references, ok 
PASS: tests/derivations.scm - derivation #:allowed-references, not allowed 
PASS: tests/derivations.scm - derivation #:allowed-references, self allowed 
PASS: tests/derivations.scm - derivation #:allowed-references, self not allowed 
PASS: tests/derivations.scm - derivation #:disallowed-references, ok 
PASS: tests/derivations.scm - derivation #:disallowed-references, not ok 
PASS: tests/derivations.scm - derivation #:leaked-env-vars 
PASS: tests/derivations.scm - build derivation with coreutils 
PASS: tests/derivations.scm - build-expression->derivation and invalid module name 
FAIL: tests/derivations.scm - build-expression->derivation and builder encoding 
FAIL: tests/derivations.scm - build-expression->derivation and derivation-prerequisites 
FAIL: tests/derivations.scm - derivation-prerequisites and valid-derivation-input? 
FAIL: tests/derivations.scm - build-expression->derivation without inputs 
FAIL: tests/derivations.scm - build-expression->derivation and max-silent-time 
FAIL: tests/derivations.scm - build-expression->derivation and timeout 
FAIL: tests/derivations.scm - build-derivations with specific output 
FAIL: tests/derivations.scm - build-expression->derivation and derivation-build-plan 
FAIL: tests/derivations.scm - derivation-build-plan when outputs already present 
FAIL: tests/derivations.scm - derivation-build-plan and substitutes 
FAIL: tests/derivations.scm - derivation-build-plan and substitutes, non-substitutable build 
FAIL: tests/derivations.scm - derivation-build-plan and substitutes, non-substitutable dep 
FAIL: tests/derivations.scm - derivation-build-plan and substitutes, local build 
FAIL: tests/derivations.scm - derivation-build-plan in 'check' mode 
FAIL: tests/derivations.scm - derivation-build-plan, topological ordering 
FAIL: tests/derivations.scm - derivation-input-fold 
FAIL: tests/derivations.scm - substitution-oracle and #:substitute? #f 
FAIL: tests/derivations.scm - build-expression->derivation with expression returning #f 
FAIL: tests/derivations.scm - build-expression->derivation with two outputs 
FAIL: tests/derivations.scm - build-expression->derivation with one input 
FAIL: tests/derivations.scm - build-expression->derivation with modules 
FAIL: tests/derivations.scm - build-expression->derivation: same fixed-output path 
FAIL: tests/derivations.scm - build-expression->derivation with a fixed-output input 
FAIL: tests/derivations.scm - build-expression->derivation produces recursive fixed-output 
FAIL: tests/derivations.scm - build-expression->derivation uses recursive fixed-output 
FAIL: tests/derivations.scm - build-expression->derivation with #:references-graphs 
FAIL: tests/derivations.scm - derivation-properties 
FAIL: tests/derivations.scm - map-derivation 
PASS: tests/derivations.scm - map-derivation, sources
===================================================
   GNU Guix 1.3.0.77462-364394: ./test-suite.log
===================================================

# TOTAL: 77
# PASS:  48
# SKIP:  0
# XFAIL: 0
# FAIL:  29
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2
--8<---------------cut here---------------end--------------->8---
  

Hi Maxim,

> That's probably the GCC implicitly added by gnu-build-system, which is
> listed in the %final-inputs variable.

I did figure out that this was the GCC implicitly added by `gnu-build-system`, although unfortunately examining this more carefully didn't help me a whole lot with understanding why it seemed to be non-substitutable. 

> I'm not sure what's wrong, but I think we could start by investigating
> why this changes causes 29 new failures when running:

I accidentally added an extra closing parenthesis to the changed line in `derivation`, but didn't bother submitting an updated patch set because even with that typo fixed, the change still didn't seem to work. You may have noticed and fixed this yourself. I had trouble running the test suite while working on the changes, as I was away from home and my laptop seemed to be somewhat underpowered for the purpose. I'm back at home with access to my PC now, so I'll try to have a look at why the tests are failing.

Best,

Morgan
  

Hi Maxim,

I found the cause of these failed tests, although unfortunately it doesn't seem to resolve the problem with implicit inputs from `gnu-build-system` being non-substitutable. The failing tests pass a `derivation` as input to the derivations that they construct, rather than a `derivation-input`. My added code then fails upon attempting to apply `derivation-input-derivation` to something which is not `derivation-input?`. I think that this might arguably be a flaw in the tests, but it can be resolved by simply checking that an input is `derivation-input?` before attempting to apply `derivation-input-derivation`. I'll send over the patch in a moment.

Best,

Morgan
  

Hi Morgan,

I needed to do some changes and adjust one test, but in v6 the
derivations tests now pass, and the regular operation of
Guix appears otherwise unaffected, which is good (I don't need to
rebuild say, Libreoffice).

Could you test?
  

Hi Maxim,

Your help is much appreciated! The changes all look good, but there is one thing which is alarming me somewhat. Perhaps I am misunderstanding how the `substitutable-derivation?` function actually operates, but if I apply these patches and then run, say:

```
(use-modules (guix) (gnu) (gnu packages bash))
(define store (open-connection))
(display (substitutable-derivation? (package-derivation store bash-minimal)))
```

it prints `#f`, which seems quite contrary to what I would expect. Oddly enough, despite this, Guix still seems to fetch a substitute for `bash-minimal` from Cuirass. In this sense it doesn't cause a problem, but I don't understand why the above script prints `#f` despite Guix fetching a substitute.

Hopefully this is just a misunderstanding on my part and the changes are actually completely fine.

Best,

Morgan
  

it's been some months since the last update, and seemingly no progress
has been made by maxim.

is there any reason to still hold this up?

to call the delay on this excessive is an extreme understatement.

can we please merge this, and if maxim ever figures out the
substitutable flag it can be handled separately,

-bjc
  

Hi Brian,

> it's been some months since the last update, and seemingly no progress
> has been made by maxim.

I've primarily been the one working on this, so the onus for the lack of progress is on me, not on Maxim. I'm currently working on resolving issue 41602 (see pull request #127 on the new Codeberg repo: https://codeberg.org/guix/guix/pulls/127). My hope is that it will be merged soon, and then a version of this which ensures that initrds which take ZFS as an input are marked non-substitutable should be totally acceptable for inclusion.

> to call the delay on this excessive is an extreme understatement.

Any delay is my fault entirely. I just haven't found the time to work on it. I've been aware for months that resolving 41602 was necessary for this issue to be resolved, and haven't found the time to solve 41602. I'm working on it now, and my hope is that pull request #127 will be merged soon and I can get a version of these patches written up and merged.

> can we please merge this, and if maxim ever figures out the
> substitutable flag it can be handled separately,

I'm as eager as anyone for these changes to be merged, but I understand the desire to ensure that the changes that we make respect copyright rigorously, and I'm doing my best to ensure that we can have these changes while still carefully respecting the licensing issues surrounding ZFS.

Best,

Morgan
  

Morgan Arnold <morgan.arnold@proton.me> writes:

> I've primarily been the one working on this, so the onus for the lack
> of progress is on me, not on Maxim. I'm currently working on resolving
> issue 41602 (see pull request #127 on the new Codeberg repo:
> https://codeberg.org/guix/guix/pulls/127). My hope is that it will be
> merged soon, and then a version of this which ensures that initrds
> which take ZFS as an input are marked non-substitutable should be
> totally acceptable for inclusion.

my mistake. i was working off what i saw on the old website. i'll keep
an eye on the new patch.

> Any delay is my fault entirely.

you only just got here. this ticket is three years old. i wait at least
one before i start to get peeved ;)

thanks for your work on this.

-bjc