[Top][All Lists]

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

Re: enchant hash, fail to upgrade

From: Catriel Omar D'Elía
Subject: Re: enchant hash, fail to upgrade
Date: Tue, 24 Sep 2019 12:32:32 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Julien Lepiller <address@hidden> writes:

> Le 23 septembre 2019 00:38:39 GMT+02:00, Catriel <address@hidden> a écrit :
>>Julien Lepiller <address@hidden> writes:
>>> Sorry I'm too tired to answer properly. Their is a section about
>>contributing in the manual. Have you read that?
>>yes, but I was asking a way or methodology to modify packages from guix
>>and using them even when they are dependencies. Because just defining a
>>package doesn't seem to handle that situation very well. As opose to
>>inheriting emacs package definition, calling it
>>awesome-mario-bros-emacs, patching it, and installing it. I was not
>>interested so much on the details of contributing.
> I see, sorry for the misunderstanding. Honestly, I'm not sure how to do it. 
> My best answer is: get the repository, make your change, build it and use 
> ./pre-inst-env.

No problem! Honestly, me neither XD. Your idea is not bad, but then is
the problem to replacing the package in the system. I think that all the
family of --with-source/--with-graft... should be the answer, but my
recent failure to replace enchant with a downloaded tar.gz cast a dark
shadow on that thought.

>>> As a workaround, you can try guix package -u
>>> --with-source=enchant=`guix download …` where … is the url of the
>>> sources you want to use. Iirc, it applies to dependencies
>>mmm the problem remaings the same. The source is accesible and
>>just fine, the issue here is with the package definition: it have a
>>wrong sha256 (asuming that is the case and not a sec. vulnerability in
>>So even if I download it manually and write:
>>$guix upgrade --fallback --with-source=enchant=path-to-downloaded-file
>>it's equivalent to let guix download the package by itself. When it
>>tries to build the derivation the sha256 mismatch aborts the upgrade.
> That's weird: enchant should be replaced everywhere and build with the
> new source, it shouldn't even look for a hash. The file is available
> at the ci server though, so maybe check your substitute servers? You
> can download it directly at

I don't know, I download it from the github source, and then try to upgrade it:

$guix upgrade
guix upgrade: aviso: paquete 'libstdc++' ya no existe
guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
substitute: updating substitutes from
''... 100.0%
substitute: updating substitutes from
''... 100.0%
/gnu/store/qmld15kzh9azm1mpbbs21wsz3x4ibab7-libwacom-0.33.drv construido
la construcción de
Muestra el registro de construcción en
/guix upgrade: error: build of

What I can guess is that it only change the url/fetch method in the
(package (source (...))) record, instead of replacing all the (source
...) with the file. So you provide the file but hash validations, as
well any other definition on it's .scm, still holds. But I should read
the code to really be shure.

> I'll update to 2.2.7 when I have access to my gpg key, so the problem
> should be fixed after that. The 2.2.5 release was made twice by
> accident, which overwrote the old tarball. The new 2.2.5 tarball
> actually is the 2.2.6 release. See
> fos details.

Nice!.. well it seems to be only a minor mistake from Thomas on
upstream. No harm done.

>>> Good night, and good luck :)
>>Have a good sleep!
>>and really thank you for answering!

Chau che.

reply via email to

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