Hi, On Tue, 25 Oct 2022 at 12:50, Vagrant Cascadian <vagr...@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
