Hi again,

In the previous approach I tried to get the manifest and it failed to
get some source like the ath9k firmware.

Parsing the system definition approach:
---------------------------------------
I then tried to parse the system definition better and I could extract
it from the firmware field for instance and then I pass the resulting
package name to guix build --source=transitive:
> ;;; Copyright © 2024 Denis 'GNUtoo' Carikli
> ;;; <GNUtoo@cyberdimension.org>
> ;;; This file is free software; you can redistribute it and/or modify
> ;;; it under the terms of the GNU General Public License as
> ;;; published by the Free Software Foundation; either version 3 of
> ;;; the License, or (at your option) any later version.
> ;;;
> ;;; GNU Guix is distributed in the hope that it will be useful, but
> ;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;;; GNU General Public License for more details.
> (use-modules (gnu bootloader))
> (use-modules (gnu system))
> (use-modules (guix packages))
> (use-modules (minimal-system))
> 
> ;; List all the OS packages but not its dependencies. This can then be
> ;; fed to guix build --sources=transitive to provide the packages
> source code.
> 
> (let ((os minimal-operating-system))
>   (map
>    (lambda (p)
>      (display (string-append (package-name p) "\n")))
>    (append
>     (operating-system-packages os)
>     (list (operating-system-kernel os))
>     (operating-system-firmware os)
>     (operating-system-locale-libcs os)
>     (list
>      (bootloader-package
>       (bootloader-configuration-bootloader
>        (operating-system-bootloader os)))))))

But then in /gnu/store of the image I have
/gnu/store/sriajy9dya89gmfaix5n7ypc3li0lmcq-libx11-1.7.3.1

And the code above doesn't list that.

Reading the derivations and filtering the result approach:
----------------------------------------------------------

So I tried again another approach and it seems to print the right paths.

I can run it with:
> guix time-machine --commit=v1.4.0 -- repl read-derivations.scm \
> $(guix gc --derivers
> /gnu/store/5rhwm44nwvc4b3ww48b8w0i6f4l0bh1c-system/)

And it produces the ath9k source, and also
/gnu/[...]-libX11-1.7.3.1.tar.xz

Here's the code:
> ;;; Copyright © 2024 Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
> ;;;
> ;;; GNU Guix is free software; you can redistribute it and/or modify it
> ;;; under the terms of the GNU General Public License as published by
> ;;; the Free Software Foundation; either version 3 of the License, or (at
> ;;; your option) any later version.
> ;;;
> ;;; GNU Guix is distributed in the hope that it will be useful, but
> ;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;;; GNU General Public License for more details.
> (use-modules (guix derivations))
> 
> (let ((drv-from-file (read-derivation-from-file (list-ref (program-arguments) 1))))
>   (map
>    (lambda (drv-prerequisite)
>      (map
>       (lambda (drv-output)
> 	(if (derivation-output-hash (cdr drv-output))
> 	    ((lambda _
> 	       (display
> 		(string-append
> 		 (derivation-output-path (cdr drv-output))
> 		 "\n"))))))
>        (derivation-outputs (derivation-input-derivation drv-prerequisite))))
>    (derivation-prerequisites drv-from-file)))

But now I have another problem: some of the paths don't exist. For
instance the code above lists
/gnu/[...]-ath9k-htc-firmware-1.4.0-checkout which doesn't exist.

With the previous code that parsed the system definition, it produced a
different path for the system definition which existed. And running
'guix time-machine --commit=v1.4.0 -- build --system=i686-linux --source
ath9k-htc-firmware' with and without --system also produce the same
path than the code that parsed the system definition.

I'm unsure where the issue could come from. Does someone has some
hypothesis / ideas that I could look into?

Denis.