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

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

[Roel Janssen]

Dear Guix,

I'm running into the following problem:

----
$ guix pull
Updating channel 'guix-science' from Git repository at 
'https://github.com/guix-science/guix-science.git'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from these channels:
   guix      https://git.savannah.gnu.org/git/guix.git   5763eba
   guix-sciencehttps://github.com/guix-science/guix-science.git 5a2e3d5
Computing Guix derivation for 'x86_64-linux'... |
The following derivation will be built:
    /gnu/store/xy2q5rk35sxn07xjq89l3ga95igjmmsi-profile.drv

building package cache...
/builder for 
`/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv' 
failed to produce output path 
`/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
build of 
/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv failed
Could not find build log for 
'/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv'.
cannot build derivation 
`/gnu/store/xy2q5rk35sxn07xjq89l3ga95igjmmsi-profile.drv': 1 
dependencies couldn't be built
guix pull: error: build of 
`/gnu/store/xy2q5rk35sxn07xjq89l3ga95igjmmsi-profile.drv' failed
----

Is this a known problem? I assume this may be a problem with the 
"guix-science" channel (which would be my own fault of course).
If it is, then perhaps the UI could be improved to show why the package 
cache couldn't be built.
Perhaps, as a matter of diagnostics, it could build package caches 
separately for each channel to pinpoint which channel is causing the 
problem.

Thanks.

Kind regards,
Roel Janssen

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

[Ludovic Courtès]

Hi Roel,

Roel Janssen <roel@gnu.org> skribis:

> /builder for
> `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv' 
> failed to produce output path
> `/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
> build of
> /gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv
> failed
> Could not find build log for
> '/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv'.

Could you find the log of this derivation?  :-)

It’ll tell us what’s wrong.

> Perhaps, as a matter of diagnostics, it could build package caches
> separately for each channel to pinpoint which channel is causing the 
> problem.

Yeah, we’ll have to see what’s doable, but I agree there’s room for
improvement here.

Ludo’.

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

[Roel Janssen]

On Wed, 2021-04-28 at 23:38 +0200, Ludovic Courtès wrote:
> Hi Roel,
> 
> Roel Janssen <roel@gnu.org> skribis:
> 
> > /builder for
> > `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
> > cache.drv'
> > failed to produce output path
> > `/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
> > build of
> > /gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv
> > failed
> > Could not find build log for
> > '/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
> > cache.drv'.
> 
> Could you find the log of this derivation?  :-)
> 
> It’ll tell us what’s wrong.
> 

I'm confused.. The message says "Could not find build log for ...". Is
there any other place I can look?

Thank you!

Kind regards,
Roel Janssen

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

[Ludovic Courtès]

Hi,

Roel Janssen <roel@gnu.org> skribis:

> On Wed, 2021-04-28 at 23:38 +0200, Ludovic Courtès wrote:
>> Hi Roel,
>> 
>> Roel Janssen <roel@gnu.org> skribis:
>> 
>> > /builder for
>> > `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>> > cache.drv'
>> > failed to produce output path
>> > `/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
>> > build of
>> > /gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv
>> > failed
>> > Could not find build log for
>> > '/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>> > cache.drv'.
>> 
>> Could you find the log of this derivation?  :-)
>> 
>> It’ll tell us what’s wrong.
>> 
>
> I'm confused.. The message says "Could not find build log for ...". Is
> there any other place I can look?

“Could not find build log” typically happens if you’re talking to a
remote daemon, via GUIX_DAEMON_SOCKET.  In that case, the build log is
in /var/log/guix/drvs (or similar) on the machine where the daemon is
running.

HTH!

Ludo’.

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

[Vagrant Cascadian]

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

On 2021-04-29, Ludovic Courtès wrote:
> Roel Janssen <roel@gnu.org> skribis:
>> On Wed, 2021-04-28 at 23:38 +0200, Ludovic Courtès wrote:
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>> > /builder for
>>> > `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>>> > cache.drv'
>>> > failed to produce output path
>>> > `/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
>>> > build of
>>> > /gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv
>>> > failed
>>> > Could not find build log for
>>> > '/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>>> > cache.drv'.
>>>
>>> Could you find the log of this derivation?  :-)
>>>
>>> It’ll tell us what’s wrong.
>>>
>>
>> I'm confused.. The message says "Could not find build log for ...". Is
>> there any other place I can look?
>
> “Could not find build log” typically happens if you’re talking to a
> remote daemon, via GUIX_DAEMON_SOCKET.  In that case, the build log is
> in /var/log/guix/drvs (or similar) on the machine where the daemon is
> running.

I just started getting hit by what appears to be the same issue on a
Debian system running guix whenever i guix pull...

originally stared for
me with guix successfully pulled to
bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull
to anything newer would trigger the issue...

I managed to workaround it by using an older guix pull at commit
e61660c78f1190c578dd6f202bc5529cbdcff84e, and then guix pull to
8663be6da7f13a8eeea71dc1f493f7adc5b7672a was successful ... but now with
8663be6da7f13a8eeea71dc1f493f7adc5b7672a it appears to be happening
again. Wow, that's confusing...


  builder for `/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv' failed to produce output path `/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache'
  build of /gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv failed
  View build log at '/var/log/guix/drvs/r3/y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv.bz2'.
  cannot build derivation `/gnu/store/z2859cbabpsdz7wcy7iq5fmgkwjphhqk-profile.drv': 1 dependencies couldn't be built
  guix pull: error: build of `/gnu/store/z2859cbabpsdz7wcy7iq5fmgkwjphhqk-profile.drv' failed

/var/log/guix/drvs/r3/y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv.bz2 says:

(repl-version 0 1 1)
Generating package cache for '/gnu/store/fwjz2hfj9kizx1xpimq1a13p2rinfzvh-profile'...

Backtrace:
In guix/repl.scm:
    141:4 19 (machine-repl _ _)
    126:7 18 (_)
In ice-9/boot-9.scm:
  1747:15 17 (with-exception-handler #<procedure 7ffff050f540 at ic?> ?)
  1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/repl.scm:
    99:21 15 (_)
In unknown file:
          14 (_ #<procedure 7ffff052d240 at guix/repl.scm:100:25 ()> ?)
          13 (primitive-load "/gnu/store/ia3qygs61fk0zg18x4il6lb28vx?")
In ice-9/boot-9.scm:
  1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In gnu/packages.scm:
   438:11 11 (generate-package-cache _)
In srfi/srfi-1.scm:
   460:18 10 (fold #<procedure expand-cache expr> _ _)
In guix/packages.scm:
   570:21  9 (expand-cache . _)
  1317:17  8 (supported-package? #<package wicd@1.7.4 gnu/packages/?> ?)
In guix/memoization.scm:
    101:0  7 (_ #<hash-table 7fffeef54ee0 23100/28099> #<package wi?> ?)
In guix/packages.scm:
  1295:37  6 (_)
  1555:16  5 (package->bag _ _ _ #:graft? _)
  1656:48  4 (thunk)
In gnu/packages/wicd.scm:
    59:32  3 (inputs #<package wicd@1.7.4 gnu/packages/wicd.scm:39 7?>)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
In unknown file:
           0 (backtrace #<undefined>)

(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python2-pygtk)) (value #f))

If it helps,
/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv
contains:

Derive([("out","/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache","","")],[("/gnu/store/1s1izmdn2xnznrj5mrfil6ibmcb7ishh-guile-3.0.7.drv",["out"]),("/gnu/store/nc5yrjbj78f490mjc8s622g2v0v516gb-inferior-script.scm.drv",["out"]),("/gnu/store/zjnd5hvfr2b4q299if7g508r1ilnwyp5-profile.drv",["out"])],["/gnu/store/ck9dnn4n5ljhbswydf23aaymanm8xsa2-guix-package-cache-builder"],"x86_64-linux","/gnu/store/1kws5vkl0glvpxg7arabsv6q9vazp0hx-guile-3.0.7/bin/guile",["--no-auto-compile","/gnu/store/ck9dnn4n5ljhbswydf23aaymanm8xsa2-guix-package-cache-builder"],[("guix properties","((type . profile-hook) (hook . package-cache))"),("out","/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache"),("preferLocalBuild","1")])


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[zimoun]

Hi,

On Tue, 25 Oct 2022 at 12:50, Vagrant Cascadian <vagrant@debian.org> wrote:

> originally stared for
> me with guix successfully pulled to
> bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull
> to anything newer would trigger the issue...
>
> I managed to workaround it by using an older guix pull at commit
> e61660c78f1190c578dd6f202bc5529cbdcff84e, and then guix pull to
> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a was successful ... but now with
> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a it appears to be happening
> again. Wow, that's confusing...

These commits are from:

bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f Sat Oct 22 18:37:02 2022 +0200
e61660c78f1190c578dd6f202bc5529cbdcff84e Sun Oct 16 02:00:43 2022 +0200
8663be6da7f13a8eeea71dc1f493f7adc5b7672a Mon Oct 24 20:31:34 2022 +0200

when Guix complains about

> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python2-pygtk)) (value #f))

removed by

1c09ed37211d983d04e626d736df8f69f504630d Tue May 31 14:53:45 2022 -0400


Is the ’guix pull’ failure consistent?  Is it always because this or
does it vary?


Cheers,
simon

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

[Vagrant Cascadian]

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

On 2022-10-26, zimoun wrote:
> On Tue, 25 Oct 2022 at 12:50, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> originally stared for
>> me with guix successfully pulled to
>> bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull
>> to anything newer would trigger the issue...
>>
>> I managed to workaround it by using an older guix pull at commit
>> e61660c78f1190c578dd6f202bc5529cbdcff84e, and then guix pull to
>> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a was successful ... but now with
>> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a it appears to be happening
>> again. Wow, that's confusing...
>
> These commits are from:
>
> bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f Sat Oct 22 18:37:02 2022 +0200
> e61660c78f1190c578dd6f202bc5529cbdcff84e Sun Oct 16 02:00:43 2022 +0200
> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a Mon Oct 24 20:31:34 2022 +0200
>
> when Guix complains about
>
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python2-pygtk)) (value #f))
>
> removed by
>
> 1c09ed37211d983d04e626d736df8f69f504630d Tue May 31 14:53:45 2022 -0400
>
>
> Is the ’guix pull’ failure consistent?  Is it always because this or
> does it vary?

It is consistently the same errors in the log, though on further looking
i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow
related. I did remove all the evidence, so so if stale checkouts is
somehow the issue, it will be hard to reproduce again... oops.

I did manage again to use an old commit to pull up to a more recent
master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new
commits now so will try again. Will see.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[zimoun]

Hi Vagrant,

On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian <vagrant@debian.org> wrote:

> It is consistently the same errors in the log, though on further looking
> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow
> related. I did remove all the evidence, so so if stale checkouts is
> somehow the issue, it will be hard to reproduce again... oops.

Hum, what does “guix describe” say?


> I did manage again to use an old commit to pull up to a more recent
> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new
> commits now so will try again. Will see.

What is your hackish workflow?  You do,

    guix pull --commit=<old> && guix pull

right?  From your recent pull, does this

    guix time-machine --commit=<new> -- help

work?  where <new> is newer than your current revision.


Cheers,
simon

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

[Vagrant Cascadian]

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

On 2022-10-26, zimoun wrote:
> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> It is consistently the same errors in the log, though on further looking
>> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
>> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow
>> related. I did remove all the evidence, so so if stale checkouts is
>> somehow the issue, it will be hard to reproduce again... oops.
>
> Hum, what does “guix describe” say?

I'll try this instead, with some annotation:

$ guix pull -l 1w
# Version used when 139 failed:
Generation 138       Oct 19 2022 19:04:26
  guix e61660c
    repository URL: /home/vagrant/src/guix
    branch: master
    commit: e61660c78f1190c578dd6f202bc5529cbdcff84e

# First version where I noticed failures:
Generation 139       Oct 22 2022 13:07:08
  guix bb2701b
    repository URL: /home/vagrant/src/guix
    branch: master
    commit: bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f

# Failed to pull from 139, successfully pulled from 138:
Generation 140       Oct 24 2022 13:19:21
  guix 8663be6
    repository URL: /home/vagrant/src/guix-master
    branch: master
    commit: 8663be6da7f13a8eeea71dc1f493f7adc5b7672a

# failed to pull from 139, successfully pulled from 138:
Generation 141       Oct 25 2022 13:08:12
  guix a0751e3
    repository URL: /home/vagrant/src/guix-master
    branch: master
    commit: a0751e3250dfea7e52468c8090e18c3118d93a60

# Finally noticed the ~/.cache/guix/... leftover cruft and removed
# cached checkouts, successfully pulled from 141:
Generation 142       Oct 26 2022 10:03:18 (current)
  guix c07b55e
    repository URL: /home/vagrant/src/guix-master
    branch: master
    commit: c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652

Apparently I sometimes used:

  guix pull --url=/home/vagrant/src/guix --branch=master

and sometimes:

  guix pull --url=/home/vagrant/src/guix-master --branch=master

Which end up using different directories in ~/.cache/guix/checkouts/
... and one of the directories has some cruft leftover in it.

After cleaning out the cruft, so far so good...


>> I did manage again to use an old commit to pull up to a more recent
>> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new
>> commits now so will try again. Will see.
>
> What is your hackish workflow?  You do,
>
>     guix pull --commit=<old> && guix pull

To use the older generations I used:

  /var/guix/profiles/per-user/vagrant/current-guix-138-link/bin/guix pull ...


> right?  From your recent pull, does this
>
>     guix time-machine --commit=<new> -- help
>
> work?  where <new> is newer than your current revision.

Oh yeah, that reminds me to add to the confusion, "guix time-machine
--commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
successfully work with guix pull.

Maybe that's a clue pointing to the crufty .cache directories?


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Vagrant Cascadian]

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

On 2022-10-26, Vagrant Cascadian wrote:
> On 2022-10-26, zimoun wrote:
>> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian <vagrant@debian.org> wrote:
>>
>>> It is consistently the same errors in the log, though on further looking
>>> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
>>> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow
>>> related. I did remove all the evidence, so so if stale checkouts is
>>> somehow the issue, it will be hard to reproduce again... oops.
...
>>> I did manage again to use an old commit to pull up to a more recent
>>> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new
>>> commits now so will try again. Will see.
>>
>> What is your hackish workflow?  You do,
>>
>>     guix pull --commit=<old> && guix pull
>
> To use the older generations I used:
>
>   /var/guix/profiles/per-user/vagrant/current-guix-138-link/bin/guix pull ...
>
>
>> right?  From your recent pull, does this
>>
>>     guix time-machine --commit=<new> -- help
>>
>> work?  where <new> is newer than your current revision.
>
> Oh yeah, that reminds me to add to the confusion, "guix time-machine
> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
> successfully work with guix pull.
>
> Maybe that's a clue pointing to the crufty .cache directories?

Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem
again, with several successful pulls.

This suggests to me that guix should make sure to not use a dirty
checkout to prevent this in the future ... either exporting the guix
tree it's working with to a temporary location, or something like
running "git clean -dfx" before using the checkout...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 772 bytes --]



On 28-10-2022 22:23, Vagrant Cascadian wrote:
>[...]
>> Maybe that's a clue pointing to the crufty .cache directories?
> 
> Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem
> again, with several successful pulls.
> 
> This suggests to me that guix should make sure to not use a dirty
> checkout to prevent this in the future ... either exporting the guix
> tree it's working with to a temporary location, or something like
> running "git clean -dfx" before using the checkout...
>

A (similar) problem was reported previously but I couldn't find it 
anymore.  A proposed solution was to use temporary git worktrees ("git 
clean -dfx" wouldn't be sufficient in context of concurrent "guix 
time-machine").

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[zimoun]

Hi Vagrant,

On ven., 28 oct. 2022 at 13:23, Vagrant Cascadian <vagrant@debian.org> wrote:

>> Oh yeah, that reminds me to add to the confusion, "guix time-machine
>> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
>> successfully work with guix pull.
>>
>> Maybe that's a clue pointing to the crufty .cache directories?
>
> Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem
> again, with several successful pulls.

Well, “guix time-machine --commit=<some-commit>” uses,

--8<---------------cut here---------------start------------->8---
(define %default-channel-url
  ;; URL of the default 'guix' channel.
  "https://git.savannah.gnu.org/git/guix.git")

(define %default-guix-channel
  (channel
   (name 'guix)
   (branch "master")
   (url %default-channel-url)
   (introduction %guix-channel-introduction)))

(define %default-channels
  ;; Default list of channels.
  (list %default-guix-channel))
--8<---------------cut here---------------end--------------->8---

which is another directory checkout under ~/.cache/guix/checkouts. :-)


> This suggests to me that guix should make sure to not use a dirty
> checkout to prevent this in the future ... either exporting the guix
> tree it's working with to a temporary location, or something like
> running "git clean -dfx" before using the checkout...

From my understanding, you have 3 similar checkouts of Guix; the default one:

--8<---------------cut here---------------start------------->8---
$ cat  ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/config
[core]
	bare = false
	repositoryformatversion = 0
	filemode = true
	logallrefupdates = true
[remote "origin"]
	url = https://git.savannah.gnu.org/git/guix.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
--8<---------------cut here---------------end--------------->8---

and then 2 others, probably located at these hash names:

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(guix git)
scheme@(guix-user)> ,pp (map url-cache-directory (list
"https://git.savannah.gnu.org/git/guix.git"
"file:///home/vagrant/src/guix"
"file:///home/vagrant/src/guix-master"))
$1 = (
 "/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq"
 "/home/simon/.cache/guix/checkouts/cbek2jy4zeoea2wj4xppwabceeayfzzuap6iw6uk7kylh4hdolfa"
 "/home/simon/.cache/guix/checkouts/duxgcjge5pc2tzexf4qwjra3uzu3t4htsxojtxralegek3bqkisa"
)
--8<---------------cut here---------------end--------------->8---

then you pulled,

  guix pull --url=/home/vagrant/src/guix --branch=master

and sometimes:

  guix pull --url=/home/vagrant/src/guix-master --branch=master

How clean are these 2 local repositories?

I do not know if “git clean -dfx” would help because here the error is
probably between the repositories src/guix and src/guix-master and Guix
manages them under 2 unrelated directory checkouts.

When you cleaned ~/.cache/guix/checkouts and pulled again, you created a
new directory checkout.  Based on which origin?  Default?  Or src/guix?
Or src/guix-master?

Cheers,
simon

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

[Vagrant Cascadian]

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

On 2022-11-02, zimoun wrote:
> On ven., 28 oct. 2022 at 13:23, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>>> Oh yeah, that reminds me to add to the confusion, "guix time-machine
>>> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
>>> successfully work with guix pull.
>>>
>>> Maybe that's a clue pointing to the crufty .cache directories?
>>
>> Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem
>> again, with several successful pulls.
>
> Well, “guix time-machine --commit=<some-commit>” uses,
>
> --8<---------------cut here---------------start------------->8---
> (define %default-channel-url
>   ;; URL of the default 'guix' channel.
>   "https://git.savannah.gnu.org/git/guix.git")
>
> (define %default-guix-channel
>   (channel
>    (name 'guix)
>    (branch "master")
>    (url %default-channel-url)
>    (introduction %guix-channel-introduction)))
>
> (define %default-channels
>   ;; Default list of channels.
>   (list %default-guix-channel))
> --8<---------------cut here---------------end--------------->8---
>
> which is another directory checkout under ~/.cache/guix/checkouts. :-)

Ok, that's promising. :)


>> This suggests to me that guix should make sure to not use a dirty
>> checkout to prevent this in the future ... either exporting the guix
>> tree it's working with to a temporary location, or something like
>> running "git clean -dfx" before using the checkout...
>
> From my understanding, you have 3 similar checkouts of Guix; the default one:
>
> --8<---------------cut here---------------start------------->8---
> $ cat  ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/config
> [core]
> 	bare = false
> 	repositoryformatversion = 0
> 	filemode = true
> 	logallrefupdates = true
> [remote "origin"]
> 	url = https://git.savannah.gnu.org/git/guix.git
> 	fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> 	remote = origin
> 	merge = refs/heads/master
> --8<---------------cut here---------------end--------------->8---
>
> and then 2 others, probably located at these hash names:
>
> --8<---------------cut here---------------start------------->8---
> $ guix repl
> GNU Guile 3.0.8
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> ,use(guix git)
> scheme@(guix-user)> ,pp (map url-cache-directory (list
> "https://git.savannah.gnu.org/git/guix.git"
> "file:///home/vagrant/src/guix"
> "file:///home/vagrant/src/guix-master"))
> $1 = (
>  "/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq"
>  "/home/simon/.cache/guix/checkouts/cbek2jy4zeoea2wj4xppwabceeayfzzuap6iw6uk7kylh4hdolfa"
>  "/home/simon/.cache/guix/checkouts/duxgcjge5pc2tzexf4qwjra3uzu3t4htsxojtxralegek3bqkisa"
> )
> --8<---------------cut here---------------end--------------->8---

Hashes are coming out different, maybe without the file:// prefix?


> then you pulled,
>
>   guix pull --url=/home/vagrant/src/guix --branch=master
>
> and sometimes:
>
>   guix pull --url=/home/vagrant/src/guix-master --branch=master
>
> How clean are these 2 local repositories?

src/guix tends to have cruft laying around, but src/guix-master I tend
to keep clean, barring accidents. I *usually* just pull from
src/guix-master, which is essentially a local mirror of upstream
guix.git. Though I suspect the state of the local branch does not or at
least should not matter, since it's pulling from --branch=master.


> I do not know if “git clean -dfx” would help because here the error is
> probably between the repositories src/guix and src/guix-master and Guix
> manages them under 2 unrelated directory checkouts.

I had the impression that it uses git to copy the branches (rather than
cp -r or something), otherwise the --branch=master argument would be
meaningless (e.g. --branch=master does not mean whatever happens to be
in the working directory), so I would assume the state of the local
working directory wouldn't matter, only what's in the specified branch
as git sees it.

So My suspicion here is somehow guix is working off of dirty checkouts
in ~/.cache/guix/checkouts ... which, maybe would not be so hard to
reproduce ... just drop some files from an ancient checkout or
something. Not sure what the conditions are necessary to make it
actually leave behind cruft in a way that triggers the issue. It
definitely seemed related to an old copy of wicd.scm that has since been
removed.


FWIW, I use my git checkout to avoid re-downloading the git history
multiple times... since I already typically have a full copy of the git
history.


> When you cleaned ~/.cache/guix/checkouts and pulled again, you created a
> new directory checkout.  Based on which origin?  Default?  Or src/guix?
> Or src/guix-master?

I think so far only src/guix-master.

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[zimoun]

Hi Vagrant,

On Wed, 02 Nov 2022 at 11:40, Vagrant Cascadian <vagrant@debian.org> wrote:

>> I do not know if “git clean -dfx” would help because here the error is
>> probably between the repositories src/guix and src/guix-master and Guix
>> manages them under 2 unrelated directory checkouts.
>
> I had the impression that it uses git to copy the branches (rather than
> cp -r or something), otherwise the --branch=master argument would be
> meaningless (e.g. --branch=master does not mean whatever happens to be
> in the working directory), so I would assume the state of the local
> working directory wouldn't matter, only what's in the specified branch
> as git sees it.

From my understanding, this

  guix pull --url=/home/vagrant/src/guix --branch=master

creates one directory under ~/.cache/guix/checkouts/ and then this,

  guix pull --url=/home/vagrant/src/guix-master --branch=master

creates another directory under ~/.cache/guix/checkouts/ and these both
directory does not have the same name because their url is different.

IIUC, you were at generation 139 (using a clone of
/home/vagrant/src/guix living under say
~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa)

--8<---------------cut here---------------start------------->8---
# First version where I noticed failures:
Generation 139       Oct 22 2022 13:07:08
  guix bb2701b
    repository URL: /home/vagrant/src/guix
    branch: master
    commit: bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f

# Failed to pull from 139, successfully pulled from 138:
Generation 140       Oct 24 2022 13:19:21
  guix 8663be6
    repository URL: /home/vagrant/src/guix-master
    branch: master
    commit: 8663be6da7f13a8eeea71dc1f493f7adc5b7672a
--8<---------------cut here---------------end--------------->8---

and then you had difficulties, but note that “guix pull” generating 140
created another clone from /home/vagrant/src/guix-master living under
~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq.

Generation 140 did not updated the checkout used by generation 139.

Somehow, the state of
~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa
and the state of
~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq
require some compatibility, no?


Well, I have lost the topic of the initial bug report. :-)

BTW, I agree that “guix pull” and “guix time-machine” are requiring too
much resource (especially bandwidth) when we could imagine more resource
shares between various accounts and root.  Well, I do no know if
guile-git provides the git-worktree feature.  Or we could also imagine a
more automated workflow using only one local clone as you are doing.


Cheers,
simon

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

[Vagrant Cascadian]

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

On 2022-11-03, zimoun wrote:
> On Wed, 02 Nov 2022 at 11:40, Vagrant Cascadian <vagrant@debian.org> wrote:
>>> I do not know if “git clean -dfx” would help because here the error is
>>> probably between the repositories src/guix and src/guix-master and Guix
>>> manages them under 2 unrelated directory checkouts.
>>
>> I had the impression that it uses git to copy the branches (rather than
>> cp -r or something), otherwise the --branch=master argument would be
>> meaningless (e.g. --branch=master does not mean whatever happens to be
>> in the working directory), so I would assume the state of the local
>> working directory wouldn't matter, only what's in the specified branch
>> as git sees it.
>
> From my understanding, this
>
>   guix pull --url=/home/vagrant/src/guix --branch=master
>
> creates one directory under ~/.cache/guix/checkouts/ and then this,
>
>   guix pull --url=/home/vagrant/src/guix-master --branch=master
>
> creates another directory under ~/.cache/guix/checkouts/ and these both
> directory does not have the same name because their url is different.

Yes, this seems consistent with my understanding too.

I should also add that src/guix and src/guix-master are using the same
git repository, src/guix-master is just another worktree.


> IIUC, you were at generation 139 (using a clone of
> /home/vagrant/src/guix living under say
> ~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa)
>
> --8<---------------cut here---------------start------------->8---
> # First version where I noticed failures:
> Generation 139       Oct 22 2022 13:07:08
>   guix bb2701b
>     repository URL: /home/vagrant/src/guix
>     branch: master
>     commit: bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f
>
> # Failed to pull from 139, successfully pulled from 138:
> Generation 140       Oct 24 2022 13:19:21
>   guix 8663be6
>     repository URL: /home/vagrant/src/guix-master
>     branch: master
>     commit: 8663be6da7f13a8eeea71dc1f493f7adc5b7672a
> --8<---------------cut here---------------end--------------->8---
>
> and then you had difficulties, but note that “guix pull” generating 140
> created another clone from /home/vagrant/src/guix-master living under
> ~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq.
>
> Generation 140 did not updated the checkout used by generation 139.
>
> Somehow, the state of
> ~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa
> and the state of
> ~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq
> require some compatibility, no?

Well, with the same inputs, they ought to produce the same outputs... :)


> Well, I have lost the topic of the initial bug report. :-)

While I think somewhat of a digression, it explained the confusing
situation where "guix pull" appeared to behave differently (as I was
calling it with diffrent --url), as one of the ~/.cache/guix/checkouts/
was dirty and that mattered (as there were old removed files present in
the tree) ... which I suspect is the crux of the bug report, though I
don't know with absolutely certainty.

I'm guessing one could dirty the tree I'm guessing reverting:

  edac21bfc78ffea85f4dac7206e5e7cd621bba19 gnu: Remove wicd.

Something like this, maybe?

  cd ~/.cache/guix/checkouts/SOMECHECKOUT
  git revert edac21bfc78ffea85f4dac7206e5e7cd621bba19
  git reset origin/master
  cd ~
  guix pull ...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Maxim Cournoyer]

Hello,

I think I may have experienced this issue; the symptoms:

--8<---------------cut here---------------start------------->8---
$ guix pull
[...]
\builder for `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed to produce output path `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
la compilation de /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
conseil : This usually indicates a bug in one of the channels you are pulling from, or some incompatibility
among them.  You can check the build log and report the issue to the channel developers.

The channels you are pulling from are: guix sfl-packages.

Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
cannot build derivation `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies couldn't be built
guix pull: erreur : build of `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed

$ tail /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
  1694:48  4 (thunk)
In sfl/packages/sflvault.scm:
    75:29  3 (propagated-inputs #<package python-sflvault-common@0.9?>)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
In unknown file:
           0 (backtrace #<undefined>)

(exception unbound-variable (value #f) (value "Unbound variable: ~S")
(value (python-pycrypto)) (value #f))

$ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 -- show python-pycrypto
name: python-pycrypto
version: 2.6.1
[...]
--8<---------------cut here---------------end--------------->8---

The problematic channel is pinned via an inferior at the above commit,
so I'm surprised the error mentions python-pyrypto is unbound (it exists
at least, according to the above time-machine invocation).

I'll keep a backup of ~/.cache/guix/checkouts/ around for forensics.

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello,
>
> I think I may have experienced this issue; the symptoms:
>
> $ guix pull
> [...]
> \builder for `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed to produce output path `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
> la compilation de /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
> conseil : This usually indicates a bug in one of the channels you are pulling from, or some incompatibility
> among them.  You can check the build log and report the issue to the channel developers.
>
> The channels you are pulling from are: guix sfl-packages.
>
> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
> cannot build derivation `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies couldn't be built
> guix pull: erreur : build of `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>
> $ tail /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>   1694:48  4 (thunk)
> In sfl/packages/sflvault.scm:
>     75:29  3 (propagated-inputs #<package python-sflvault-common@0.9?>)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
> In unknown file:
>            0 (backtrace #<undefined>)
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (python-pycrypto)) (value #f))
>
> $ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 -- show python-pycrypto
> name: python-pycrypto
> version: 2.6.1
> [...]
>
> I'll keep a backup of ~/.cache/guix/checkouts/ around for forensics.

Perhaps not the same issue after all, as 'sudo rm -rf
~/.cache/guix/checkouts' didn't resolve the issue.

-- 
Thanks,
Maxim

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

[Simon Tournier]

Hi Maxim,

On Fri, 28 Apr 2023 at 12:47, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> I think I may have experienced this issue

Well, I think it’s different from the issue reported by Vagrant; IIUC,
something related to mixed branches and/or locations of repository from
where Vagrant pulled.

Instead, your issue seems related to channels.

>                                            the symptoms:
>
> --8<---------------cut here---------------start------------->8---
> $ guix pull
> [...]
> \builder for `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed to produce output path `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
> la compilation de /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
> conseil : This usually indicates a bug in one of the channels you are pulling from, or some incompatibility
> among them.  You can check the build log and report the issue to the channel developers.
>
> The channels you are pulling from are: guix sfl-packages.
>
> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
> cannot build derivation `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies couldn't be built
> guix pull: erreur : build of `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>
> $ tail /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>   1694:48  4 (thunk)
> In sfl/packages/sflvault.scm:
>     75:29  3 (propagated-inputs #<package python-sflvault-common@0.9?>)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
> In unknown file:
>            0 (backtrace #<undefined>)
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (python-pycrypto)) (value #f))
>
> $ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 -- show python-pycrypto
> name: python-pycrypto
> version: 2.6.1
> [...]
> --8<---------------cut here---------------end--------------->8---
>
> The problematic channel is pinned via an inferior at the above commit,
> so I'm surprised the error mentions python-pyrypto is unbound (it exists
> at least, according to the above time-machine invocation).

Could you share the link of the other channel, if it’s public?


Cheers,
simon

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

[Maxim Cournoyer]

Hi Simon,

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

> Hi Maxim,
>
> On Fri, 28 Apr 2023 at 12:47, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> I think I may have experienced this issue
>
> Well, I think it’s different from the issue reported by Vagrant; IIUC,
> something related to mixed branches and/or locations of repository from
> where Vagrant pulled.
>
> Instead, your issue seems related to channels.

Right.  I thought the package I used from the channel should be frozen
because I specify it in my manifest via an old guix inferior, but that
only applies at 'guix package -m' profile generation time, not at the
time 'guix pull' fetches the channel.  The channel is public and
contains free software only [0].

Thanks for pointing that!

[0]  https://gitlab.com/Apteryks/sfl-guix-channel

-- 
Thanks,
Maxim

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

[Simon Tournier]

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:

--8<---------------cut here---------------start------------->8---
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:
--8<---------------cut here---------------end--------------->8---

then that works:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---


However, then this,

    guix build -L sfl-guix-channel python-sflvault-common

fails with:

--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---

Bah I do not know.  Somehow, it would be the strategy I would try to follow.

Last, I get an error:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

which reads,

--8<---------------cut here---------------start------------->8---
(repl-version 0 1 1)
(exception %exception (non-self-quoting 140737182622144 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>"))
--8<---------------cut here---------------end--------------->8---

Hum?!

Cheers,
simon


1: https://gitlab.com/Apteryks/sfl-guix-channel/-/blob/master/sfl/packages/sflvault.scm#L75
2: https://gitlab.com/Apteryks/sfl-guix-channel/-/blob/master/sfl/packages/sflvault.scm#L99


PS: Please note that the example from the manual [#] fails with Guix
fa685c8:

--8<---------------cut here---------------start------------->8---
$ cat manifest.scm
(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;for 'first'

(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
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; An inferior representing the above revision.
  (inferior-for-channels channels))

;; Now create a manifest with the current "guile" package
;; and the old "guile-json" package.
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

$ guix build -m manifest.scm
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
The following derivations will be built:
  /gnu/store/01d4kdfqx0hq2lj0ir9yk7fl3kmpanyh-compute-guix-derivation.drv
  /gnu/store/1dgn5q7q8gm5y9dssaws2bbcdvwznvj9-module-import-compiled.drv
  /gnu/store/xxrxdi543lcfmw43svp8nxpbp3d3d4rd-module-import-compiled.drv
building path(s) `/gnu/store/hrvp38jfh5gvdhd2rh4v2rxk39vvgzi9-module-import-compiled'
[ 1/78] Loading './gnu/packages/bootstrap.scm'...
Backtrace:
In ice-9/boot-9.scm:
  2887:24 19 (_)
   222:17 18 (map1 (((guix config)) ((srfi srfi-1)) ((srfi #)) (#) ?))
  2800:17 17 (resolve-interface (guix config) #:select _ #:hide _ # _ ?)
In ice-9/threads.scm:
    390:8 16 (_ _)
In ice-9/boot-9.scm:
  2726:13 15 (_)
In ice-9/threads.scm:
    390:8 14 (_ _)
In ice-9/boot-9.scm:
  2994:20 13 (_)
   2312:4 12 (save-module-excursion #<procedure 7ffff7818090 at ice-?>)
  3014:26 11 (_)
In unknown file:
          10 (primitive-load-path "guix/config" #<procedure 7ffff77e?>)
In ice-9/eval.scm:
   721:20  9 (primitive-eval (begin (define-module (guix #) # (?)) #))
In ice-9/psyntax.scm:
  1235:36  8 (expand-top-sequence ((begin (define-module (# ?) ?) ?)) ?)
  1182:24  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
  1182:24  6 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
  1182:24  5 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   285:10  4 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)
In ice-9/eval.scm:
   626:19  3 (_ #<directory (guix config) 7fffeebd45a0>)
   182:19  2 (proc #<directory (guix config) 7fffeebd45a0>)
   142:16  1 (compile-top-call _ (7 . repository) ((10 (13 . #) #) ?))
In unknown file:
           0 (%resolve-variable (7 . repository) #<directory (guix c?>)

ERROR: In procedure %resolve-variable:
Unbound variable: repository
builder for `/gnu/store/1dgn5q7q8gm5y9dssaws2bbcdvwznvj9-module-import-compiled.drv' failed with exit code 1
cannot build derivation `/gnu/store/01d4kdfqx0hq2lj0ir9yk7fl3kmpanyh-compute-guix-derivation.drv': 1 dependencies couldn't be built
guix build: error: exception thrown: #<&store-protocol-error message: "build of `/gnu/store/01d4kdfqx0hq2lj0ir9yk7fl3kmpanyh-compute-guix-derivation.drv' failed" status: 100>
--8<---------------cut here---------------end--------------->8---

#: https://guix.gnu.org/manual/devel/en/guix.html#Inferiors

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

[Maxim Cournoyer]

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

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

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> $ guix pull
> [...]
> \builder for `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed to produce output path `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
> la compilation de /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
> conseil : This usually indicates a bug in one of the channels you are pulling from, or some incompatibility
> among them.  You can check the build log and report the issue to the channel developers.
>
> The channels you are pulling from are: guix sfl-packages.
>
> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
> cannot build derivation `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies couldn't be built
> guix pull: erreur : build of `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>
> $ tail /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>   1694:48  4 (thunk)
> In sfl/packages/sflvault.scm:
>     75:29  3 (propagated-inputs #<package python-sflvault-common@0.9?>)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
> In unknown file:
>            0 (backtrace #<undefined>)
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (python-pycrypto)) (value #f))

Isn’t the advice above correct?  The unbound-variable error appears to
come from sfl/packages/sflvault.scm, not from the ‘guix’ channel.

HTH,
Ludo’.

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

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> $ guix pull
>> [...]
>> \builder for `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed to produce output path `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
>> la compilation de /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
>> conseil : This usually indicates a bug in one of the channels you are pulling from, or some incompatibility
>> among them.  You can check the build log and report the issue to the channel developers.
>>
>> The channels you are pulling from are: guix sfl-packages.
>>
>> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
>> cannot build derivation `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies couldn't be built
>> guix pull: erreur : build of `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>>
>> $ tail /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>>   1694:48  4 (thunk)
>> In sfl/packages/sflvault.scm:
>>     75:29  3 (propagated-inputs #<package python-sflvault-common@0.9?>)
>> In ice-9/boot-9.scm:
>>   1685:16  2 (raise-exception _ #:continuable? _)
>>   1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari?>)
>> In unknown file:
>>            0 (backtrace #<undefined>)
>>
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
>> (value (python-pycrypto)) (value #f))
>
> Isn’t the advice above correct?  The unbound-variable error appears to
> come from sfl/packages/sflvault.scm, not from the ‘guix’ channel.

I think so :-).  My confusion stemmed from using a Guix inferior for the
package 'sflvault-client' from that channel... but that only holds at
the time of building the package, not at the time of 'guix pull'.

I'll see if I can fix the channel, thanks.

For the record, a stripped down version of my user manifest reads:

--8<---------------cut here---------------start------------->8---
(use-modules (gnu packages)
             (guix channels)
             (guix inferior)
             (guix profiles)
             (srfi srfi-1))

;;; An inferior for a working sflvault-client package.
(define sflvault-inferior
  (inferior-for-channels
   (list (channel
          (name 'guix)
          (url "https://git.savannah.gnu.org/git/guix.git")
          (commit "9ed65e6af77893b658a7159b091b5002892c2f95"))
         (channel
          (name 'sfl-guix-channels)
          (url "https://gitlab.com/Apteryks/sfl-guix-channel")
          (commit "9b9ba3f72d939bfc796b7457eafe0ef8b2ace81f")))))

(concatenate-manifests
 (list (specifications->manifest
        '("hello"))
       ;; FIXME: sflvault-client doesn't build anymore on latest Guix.
       (packages->manifest
        (list (first (lookup-inferior-packages sflvault-inferior
                                               "sflvault-client"))))))
--8<---------------cut here---------------end--------------->8---

While my channel definitions at ~/.config/guix/channels.scm reads:

--8<---------------cut here---------------start------------->8---
(cons (channel
       (name 'sfl-packages)
       (url "https://gitlab.com/Apteryks/sfl-guix-channel"))
      %default-channels)
--8<---------------cut here---------------end--------------->8---

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hello again,

To add more to my previous replies; what seems problematic here is that

1. The use of package inferior should allow using packages from a
distant past yet...

2. They can't refer to packages that no longer exist in current Guix!

Should I create a separate issue for that?

-- 
Thanks,
Maxim