bug#47949: Failed to produce output path for guix-package-cache

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> On jeu., 04 mai 2023 at 08:53, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> [0]  https://gitlab.com/Apteryks/sfl-guix-channel
>
> From a Guile point of view, where the symbol ’python-pycrypto’ [1,2] is
> it defined?  And it’s defined nowhere.
>
> I would suggest to bind the symbol ’python-pycrypto’ to a package from
> an inferior.  Hum, but that’s not working as expected…
>
> Applying this patch:
>
> diff --git a/sfl/packages/sflvault.scm b/sfl/packages/sflvault.scm
> index 74a975f..eb04a5b 100644
> --- a/sfl/packages/sflvault.scm
> +++ b/sfl/packages/sflvault.scm
> @@ -8,7 +8,28 @@
>    #:use-module (guix download)
>    #:use-module (guix git-download)
>    #:use-module (guix packages)
> -  #:use-module (guix build-system python))
> +  #:use-module (guix build-system python)
> +
> +  #:use-module (guix inferior)
> +  #:use-module (guix channels)
> +  #:use-module (srfi srfi-1))
> +
> +(define channels
> +  ;; This is the old revision from which we want to
> +  ;; extract guile-json.
> +  (list (channel
> +         (name 'guix)
> +         (url "https://git.savannah.gnu.org/git/guix.git")
> +         (commit
> +          "9ed65e6af77893b658a7159b091b5002892c2f95"))))
> +
> +(define inferior
> +  ;; An inferior representing the above revision.
> +  (inferior-for-channels channels))
> +
> +(define python-pycrypto
> +  (first (lookup-inferior-packages inferior "python-pycrypto")))
> +
>  
>  ;;; python-keyring > 1.6.1 API has changed, which breaks 'sflvault
>  ;;; wallet' (see:
>
>
> then that works:
>
> $ guix show -L sfl-guix-channel python-sflvault-common
> name: python-sflvault-common
> version: 0.9.2-2.120617c
> outputs:
> + out: everything
> systems: x86_64-linux i686-linux
> dependencies: python-wheel@0.40.0
> location: sfl-guix-channel/sfl/packages/sflvault.scm:84:2
> homepage: https://www.sflvault.org
> license: GPL 3+
> synopsis: Network credentials store and authentication manager library  
> description: This package is a Python library that contains code common to the
> + SFLvault server and its clients.
>
> $ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 \
>        -- build python-pycrypto --no-grafts --check -K -q
> /gnu/store/3kbr3lnwajc16a7w2jq3knxsphlrqkrz-python-pycrypto-2.6.1
>
> $ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 \
>        -- build python-pycrypto --check -K -q
> /gnu/store/yrpcsjjb3b5wr2jahp5rbr8vbbg1n3yg-python-pycrypto-2.6.1
>
> $ guix build -L sfl-guix-channel -e '(@@ (sfl packages sflvault) python-pycrypto)'
> /gnu/store/yrpcsjjb3b5wr2jahp5rbr8vbbg1n3yg-python-pycrypto-2.6.1
>
>
>
> However, then this,
>
>     guix build -L sfl-guix-channel python-sflvault-common
>
> fails with:
>
> starting phase `sanity-check'
> validating 'SFLvault-common' /gnu/store/r3kfygxwzpnsia687bf0d1xsval5cid7-python-sflvault-common-0.9.2-2.120617c/lib/python3.10/site-packages
> ...checking requirements: ERROR: SFLvault-common==0.9.2 DistributionNotFound(Requirement.parse('pycrypto'), {'SFLvault-common'})
> error: in phase 'sanity-check': uncaught exception:
> %exception #<&invoke-error program: "python" arguments: ("/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py" "/gnu/store/r3kfygxwzpnsia687bf0d1xsval5cid7-python-sflvault-common-0.9.2-2.120617c/lib/python3.10/site-packages") exit-status: 1 term-signal: #f stop-signal: #f> 
> phase `sanity-check' failed after 0.1 seconds
> command "python" "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py" "/gnu/store/r3kfygxwzpnsia687bf0d1xsval5cid7-python-sflvault-common-0.9.2-2.120617c/lib/python3.10/site-packages" failed with status 1
> builder for `/gnu/store/6i075y53h83rasrw898n6qnsn673hnll-python-sflvault-common-0.9.2-2.120617c.drv' failed with exit code 1
> build of /gnu/store/6i075y53h83rasrw898n6qnsn673hnll-python-sflvault-common-0.9.2-2.120617c.drv failed
> View build log at '/var/log/guix/drvs/6i/075y53h83rasrw898n6qnsn673hnll-python-sflvault-common-0.9.2-2.120617c.drv.gz'.
> guix build: error: build of `/gnu/store/6i075y53h83rasrw898n6qnsn673hnll-python-sflvault-common-0.9.2-2.120617c.drv' failed
>
>
> Bah I do not know.  Somehow, it would be the strategy I would try to follow.

Hm.  Interesting to try to use the inferior in the package definition.
I was using a Guix inferior encapsulating the whole 'sflvault-client'
package's world view in a manifest, but this does not change the
behavior of Guix pull, which validates that all package exists at this
earlier time, at least for its package cache derivation.

> Last, I get an error:
>
> $ cat channels.scm
> (list (channel
>         (name 'guix)
>         (url "https://git.savannah.gnu.org/git/guix.git")
>         (branch "master")
>         (commit
>           "fa685c87eaa9888a4278f39bb2b815673589dced"))
>       (channel
>         (name 'sfl)
>         (url "file:///tmp/sfl-guix-channel")
>         (branch "master")
>         (commit
>          "11bbb36e28ee80ce17785f09b33ed20af18d4832"
>          ;"bc6b32b116d3e62b5f41cb73df63a6024f1324ba"
>          )))
>          
> $ guix time-machine -C /tmp/channels.scm -- help
> [...]
>
> building /gnu/store/56ilhij5y51xg5znaspwk2zl731bq8za-sfl.drv...
> |builder for `/gnu/store/56ilhij5y51xg5znaspwk2zl731bq8za-sfl.drv' failed to produce output path `/gnu/store/nlpvr38p83jwrwcsj1czwhi8r2jpa2ic-sfl'
> build of /gnu/store/56ilhij5y51xg5znaspwk2zl731bq8za-sfl.drv failed
> View build log at '/var/log/guix/drvs/56/ilhij5y51xg5znaspwk2zl731bq8za-sfl.drv.gz'.
> cannot build derivation `/gnu/store/spikfdg9lhxy98z33dqiv6clmjm2kwv6-profile.drv': 1 dependencies couldn't be built
> guix time-machine: error: build of `/gnu/store/spikfdg9lhxy98z33dqiv6clmjm2kwv6-profile.drv' failed
>
>
> which reads,
>
> (repl-version 0 1 1)
> (exception %exception (non-self-quoting 140737182622144 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>"))
>
>
> Hum?!

I guess the use of an inferior in package code is not a very well
supported use case (or invalid?).

Thanks for experimenting and sharing the results!  I'll continue the
investigation/discussion in #63276, an issue I created for this very
purpose.

-- 
Thanks,
Maxim