On Thu, Jan 14, 2021 at 10:48:35AM +0100, zimoun wrote:

> I guess it will not change your problem at hand: the missing tarball.

A tarball is there, just a different one. I would like to make guix
accept it.

> About the hash mismatch, game over with time-machine.

Are you sure? I remember a situation where a package was defined in my
private channel. Then, someone committed a definition for the same
package to guix, but the definition in the private channel was still
given a priority while performing `guix package` operations.

Isn’t it possible to obtain analogous behavior with time-machine and
have a definition with a current hash defined in a private channel
replace the original one? Isn’t it the purpose of inferiors? Not a long
time ago, there was this [1] thread discussed here, which looks related
to my problem — a need for package definition shuffling. An inferior
gave me the substitutes error, so I’m hoping to make some progress once
I remove this obstacle.

[1]: https://lists.gnu.org/archive/html/help-guix/2020-11/msg00230.html

If I don’t manage to make the different channels “communicate with each
other”, I can try substituting the input r-foreign definition from the
guix channel with one with another version, which is even closer to the
theme of the cited thread. I don’t care much about the r-foreign
version, but I care about the version (and the binary) of r and the R
package stack that I use in that environment, and r happens to depend on
r-foreign as an input.

> Well, you have to do the “time-machine” by hand where the simplest
> IMHO is what I proposed.

If the above fails, I will.

> The substitutes error seems transient.  Rebuild locally all you need
> vs wait the fix: I do not know what would be the fastest. :-)

For testing a solution to the hash mismatch problem, it suffices to
build r, which uses r-foreign as an input. I will decide later about
what to do next.

Thank you for your support,

WŻ