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