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Ż
signature.asc
Description: PGP signature
