help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guix time-machine, broken hash in an old package definition, a worka


From: Wiktor Żelazny
Subject: Re: guix time-machine, broken hash in an old package definition, a workaround?
Date: Thu, 14 Jan 2021 20:00:30 +0100

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Ż

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]