enchant hash, fail to upgrade

enchant hash, fail to upgrade

[Catriel]

Hi!

after a minor nuisanse (*) with guix pull, I stumble upon an error:

$guix upgrade --fallback
guix upgrade: aviso: paquete 'libstdc++' ya no existe
guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
construyendo /gnu/store/g6srxnikawk7snkzxk6vxmms1aldidww-libgnomekbd-3.26.1.tar.xz.drv...
/gnu/store/g6srxnikawk7snkzxk6vxmms1aldidww-libgnomekbd-3.26.1.tar.xz.drv construido satisfactoriamente
construyendo /gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv...
la construcción de /gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv falló
Muestra el registro de construcción en '/var/log/guix/drvs/3d/fjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv.bz2'.
construyendo /gnu/store/7gsxkb7qivmw6kw4aizfxnx5r6m6i2lh-gnupg-2.2.17.tar.bz2.drv...
-guix upgrade: error: build of `/gnu/store/9xsx8j5b5j3khlicg91nrv6v84c3nssa-arc-theme-20181022.drv' failed

(sorry about the language)

it's saying that
/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
failed.

the log doesn't output anything usefull, it just shows that the file was
downloaded.

So I try to build it from the derivation for more info:

guix build /gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv 
Se construirá la siguiente derivación:
   /gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
construyendo
/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv...
...
sha256 hash mismatch for output path `/gnu/store/wsyfm5avik0wvh82gyxw9acbixp0ygbp-enchant-2.2.5.tar.gz'
  expected: 0iqwzs11i9fvqdxv5kn0svcn2mzymn657qf3j66lg8dx1nh4xkpz
  actual:   0r41qjz3104h5raiwlw5ywwybafbxdjz12j1bnq3kq60jlr6d2pf


And there it goes, the sha256 it's wrong, either in the .scm definition
or upstream.

I choose to trust upstream and try to define a package with the same
name and version but different sha256.

After

guix download --no-check-certificate https://github.com/AbiWord/enchant/releases/download/v2.2.5/enchant-2.2.5.tar.gz

to get the hash (**) and file

and defining enchant.scm with:

(use-modules (guix packages)
             (guix download)
             (gnu packages enchant)
             (gnu packages wm))

(package
 (inherit enchant)
 (name "enchant")
 (version "2.2.5")
 (source (origin
          (method url-fetch)
          (uri (string-append "https://github.com/AbiWord/enchant/releases"
                              "/download/v" version "/enchant-"
                              version ".tar.gz"))
          (sha256
           (base32
            "0r41qjz3104h5raiwlw5ywwybafbxdjz12j1bnq3kq60jlr6d2pf")))))

and then

guix package -f enchant.scm

I succefully install enchant, with the same version and name.

Then happily enjoying my wit to circumvent this issue until more proper
fixing takes place, I try to do a package upgrade again 'guix package -u'

but as a knowingly reader might predict, it just tries to build again
the enchant definition on guix repos. No matter that the package have
the same version and name, the package has another hash, another place
on the store, it's just a different input for the packages that use
enchant. So my hacky solution it's a no-solution that poped up in my
mind because habits from a non functional world die hard... but they
will... eventually.

So the questions are:

* How do I patch a package definition when I find a bug?

* Do I have to use guixsd or guix from source? (I'm currently using a
  guix binary installation on a foreign distro)

* I know that I can define a package with modifications. Say, modify
  emacs to display mario bros on background.. cuz... that would be
  really usefull.  But how to modify a package definition that it's not
  a leaf in the dependency graph? I never installed enchant, it's just a
  dependency. Say I find a bug or want to mess around with some lib and
  break things for fun. Just to break it, travel back in time with guix,
  and break it again in just another way. Do I have to redefine all the
  packages that use that dependency or there is an automatic way to do
  it?

(*) I was suffering from the same problem in this thread
    https://www.mail-archive.com/help-guix@gnu.org/msg04879.html
    and tried Ludovic suggestion. Maybe I remove more links that Ludovic
    suggests, but after some manual tinkering it just works.

(**) How does guix download calculates the hash? if I do a
     $sha256sum tarball.tar.gz it outputs other hash.

Thanks in advance!
COD.

Re: enchant hash, fail to upgrade

[Julien Lepiller]

Le 22 septembre 2019 21:22:45 GMT+02:00, Catriel <cdelia@dc.uba.ar> a écrit :
>
>Hi!
>
>after a minor nuisanse (*) with guix pull, I stumble upon an error:
>
>$guix upgrade --fallback
>guix upgrade: aviso: paquete 'libstdc++' ya no existe
>guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
>substitute: updating substitutes from 'https://mirror.hydra.gnu.org'...
>100.0%
>substitute: updating substitutes from 'https://mirror.hydra.gnu.org'...
>100.0%
>construyendo
>/gnu/store/g6srxnikawk7snkzxk6vxmms1aldidww-libgnomekbd-3.26.1.tar.xz.drv...
>/gnu/store/g6srxnikawk7snkzxk6vxmms1aldidww-libgnomekbd-3.26.1.tar.xz.drv
>construido satisfactoriamente
>construyendo
>/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv...
>la construcción de
>/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
>falló
>Muestra el registro de construcción en
>'/var/log/guix/drvs/3d/fjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv.bz2'.
>construyendo
>/gnu/store/7gsxkb7qivmw6kw4aizfxnx5r6m6i2lh-gnupg-2.2.17.tar.bz2.drv...
>-guix upgrade: error: build of
>`/gnu/store/9xsx8j5b5j3khlicg91nrv6v84c3nssa-arc-theme-20181022.drv'
>failed
>
>(sorry about the language)
>
>it's saying that
>/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
>failed.
>
>the log doesn't output anything usefull, it just shows that the file
>was
>downloaded.
>
>So I try to build it from the derivation for more info:
>
>guix build
>/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv 
>Se construirá la siguiente derivación:
>   /gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
>construyendo
>/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv...
>...
>sha256 hash mismatch for output path
>`/gnu/store/wsyfm5avik0wvh82gyxw9acbixp0ygbp-enchant-2.2.5.tar.gz'
>  expected: 0iqwzs11i9fvqdxv5kn0svcn2mzymn657qf3j66lg8dx1nh4xkpz
>  actual:   0r41qjz3104h5raiwlw5ywwybafbxdjz12j1bnq3kq60jlr6d2pf
>
>
>And there it goes, the sha256 it's wrong, either in the .scm definition
>or upstream.
>
>I choose to trust upstream and try to define a package with the same
>name and version but different sha256.
>
>After
>
>guix download --no-check-certificate
>https://github.com/AbiWord/enchant/releases/download/v2.2.5/enchant-2.2.5.tar.gz
>
>to get the hash (**) and file
>
>and defining enchant.scm with:
>
>(use-modules (guix packages)
>             (guix download)
>             (gnu packages enchant)
>             (gnu packages wm))
>
>(package
> (inherit enchant)
> (name "enchant")
> (version "2.2.5")
> (source (origin
>          (method url-fetch)
>      (uri (string-append "https://github.com/AbiWord/enchant/releases"
>                              "/download/v" version "/enchant-"
>                              version ".tar.gz"))
>          (sha256
>           (base32
>            "0r41qjz3104h5raiwlw5ywwybafbxdjz12j1bnq3kq60jlr6d2pf")))))
>
>and then
>
>guix package -f enchant.scm
>
>I succefully install enchant, with the same version and name.
>
>Then happily enjoying my wit to circumvent this issue until more proper
>fixing takes place, I try to do a package upgrade again 'guix package
>-u'
>
>but as a knowingly reader might predict, it just tries to build again
>the enchant definition on guix repos. No matter that the package have
>the same version and name, the package has another hash, another place
>on the store, it's just a different input for the packages that use
>enchant. So my hacky solution it's a no-solution that poped up in my
>mind because habits from a non functional world die hard... but they
>will... eventually.
>
>So the questions are:
>
>* How do I patch a package definition when I find a bug?
>
>* Do I have to use guixsd or guix from source? (I'm currently using a
>  guix binary installation on a foreign distro)
>
>* I know that I can define a package with modifications. Say, modify
>  emacs to display mario bros on background.. cuz... that would be
>  really usefull.  But how to modify a package definition that it's not
> a leaf in the dependency graph? I never installed enchant, it's just a
>  dependency. Say I find a bug or want to mess around with some lib and
> break things for fun. Just to break it, travel back in time with guix,
>  and break it again in just another way. Do I have to redefine all the
>  packages that use that dependency or there is an automatic way to do
>  it?
>
>(*) I was suffering from the same problem in this thread
>    https://www.mail-archive.com/help-guix@gnu.org/msg04879.html
>   and tried Ludovic suggestion. Maybe I remove more links that Ludovic
>    suggests, but after some manual tinkering it just works.
>
>(**) How does guix download calculates the hash? if I do a
>     $sha256sum tarball.tar.gz it outputs other hash.
>
>Thanks in advance!
>COD.

Sorry I'm too tired to answer properly. Their is a section about contributing in the manual. Have you read that?

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 recursively.

Good night, and good luck :)

Re: enchant hash, fail to upgrade

[Catriel]

Julien Lepiller <julien@lepiller.eu> 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.

> 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 recursively.
>

mmm the problem remaings the same. The source is accesible and downloads
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
upstream).

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.

> Good night, and good luck :)

Have a good sleep!
and really thank you for answering!

Re: enchant hash, fail to upgrade

[Julien Lepiller]

Le 23 septembre 2019 00:38:39 GMT+02:00, Catriel <cdelia@dc.uba.ar> a écrit :
>Julien Lepiller <julien@lepiller.eu> 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.

>
>> 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
>recursively.
>>
>
>mmm the problem remaings the same. The source is accesible and
>downloads
>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
>upstream).
>
>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 https://ci.guix.gnu.org/nar/wsyfm5avik0wvh82gyxw9acbixp0ygbp-enchant-2.2.5.tar.gz

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 https://github.com/AbiWord/enchant/pull/221 fos details.

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

Re: enchant hash, fail to upgrade

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Catriel, Julien,

Julien Lepiller 写道：
> 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 
> https://github.com/AbiWord/enchant/pull/221 fos details.

I'd noticed this too, and probably retraced your steps above.

Enchant upstream[0] 写道：
>> The original tarball is still available on 
>> https://src.fedoraproject.org/repo/pkgs/enchant2/enchant-2.2.5.tar.gz/.
>
> Thanks, but I'd rather not publish something I haven't 
> generated. What's the problem you're trying to solve here?

…which doesn't make any sense to me (it's their own tarball), but 
oh well.  I've pushed enchant@2.2.7 to master with commit 
bfe194b5331fe9a60ed9e1d373fe1de9e2606d34.

Thanks!

T G-R

[0]: 
https://github.com/AbiWord/enchant/pull/221#issuecomment-528858811

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: enchant hash, fail to upgrade

[Catriel Omar D'Elía]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Catriel, Julien,
>
> Julien Lepiller 写道：
>> 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
>> https://github.com/AbiWord/enchant/pull/221 fos details.
>
> I'd noticed this too, and probably retraced your steps above.
>
> Enchant upstream[0] 写道：
>>> The original tarball is still available on
>>> https://src.fedoraproject.org/repo/pkgs/enchant2/enchant-2.2.5.tar.gz/.
>>
>> Thanks, but I'd rather not publish something I haven't
>> generated. What's the problem you're trying to solve here?
>
> …which doesn't make any sense to me (it's their own tarball), but oh
> well.  I've pushed enchant@2.2.7 to master with commit
> bfe194b5331fe9a60ed9e1d373fe1de9e2606d34.
>

vOv not shure I follow, that was Thomas? ... anyway your commit fixed the
issue!

> Thanks!

To you!

>
> T G-R
>
> [0]:
> https://github.com/AbiWord/enchant/pull/221#issuecomment-528858811

Re: enchant hash, fail to upgrade

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Catriel,

Catriel Omar D'Elía 写道：
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>> Enchant upstream[0] 写道：
>>>> The original tarball is still available on
>>>> https://src.fedoraproject.org/repo/pkgs/enchant2/enchant-2.2.5.tar.gz/.
>>>
>>> Thanks, but I'd rather not publish something I haven't
>>> generated. What's the problem you're trying to solve here?
>
> vOv not shure I follow, that was Thomas?

Yes?  Describing @rrthomas as ‘enchant upstream’ seems correct 
based on recent commit history[1].

The ‘original tarball’ that @lantw44 mentions *was* generated by 
@rrthomas [2], so the latter's refusal to restore it makes no 
sense to me.  But the point is moot now :-)

> ... anyway your commit fixed the issue!

Huzzah!  Thanks also to roptat, who discussed this issue in more 
depth on IRC whenever I wasn't looking…

Kind regards,

T G-R

[0]: 
https://github.com/AbiWord/enchant/pull/221#issuecomment-528858811
[1]: https://github.com/AbiWord/enchant/commits
[2]: Same hash 
0iqwzs11i9fvqdxv5kn0svcn2mzymn657qf3j66lg8dx1nh4xkpz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: enchant hash, fail to upgrade

[Catriel Omar D'Elía]

Julien Lepiller <julien@lepiller.eu> writes:

> Le 23 septembre 2019 00:38:39 GMT+02:00, Catriel <cdelia@dc.uba.ar> a écrit :
>>Julien Lepiller <julien@lepiller.eu> 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
>>recursively.
>>>
>>
>>mmm the problem remaings the same. The source is accesible and
>>downloads
>>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
>>upstream).
>>
>>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
> https://ci.guix.gnu.org/nar/wsyfm5avik0wvh82gyxw9acbixp0ygbp-enchant-2.2.5.tar.gz
>

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

$guix upgrade
--with-source=enchant=/gnu/store/wsyfm5avik0wvh82gyxw9acbixp0ygbp-enchant-2.2.5.tar.gz
guix upgrade: aviso: paquete 'libstdc++' ya no existe
guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
substitute: updating substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
construyendo
/gnu/store/qmld15kzh9azm1mpbbs21wsz3x4ibab7-libwacom-0.33.drv...
/gnu/store/qmld15kzh9azm1mpbbs21wsz3x4ibab7-libwacom-0.33.drv construido
satisfactoriamente
construyendo
/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv...
la construcción de
/gnu/store/3dfjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv
falló
Muestra el registro de construcción en
'/var/log/guix/drvs/3d/fjsc9nm0bjcv4p0gidgi61n3yk3ps3-enchant-2.2.5.tar.gz.drv.bz2'.
construyendo
/gnu/store/7gsxkb7qivmw6kw4aizfxnx5r6m6i2lh-gnupg-2.2.17.tar.bz2.drv...
/guix upgrade: error: build of
`/gnu/store/9xsx8j5b5j3khlicg91nrv6v84c3nssa-arc-theme-20181022.drv'
failed

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
> https://github.com/AbiWord/enchant/pull/221 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!

Thanks!
Chau che.

Re: enchant hash, fail to upgrade

[Ludovic Courtès]

¡Hola!

"Catriel" <cdelia@dc.uba.ar> skribis:

> $guix upgrade --fallback
> guix upgrade: aviso: paquete 'libstdc++' ya no existe
> guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
> substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%

Este servidor de substituciones está invalido ahora; deberías usar
https://ci.guix.gnu.org en lugar de esta dirección:

  https://lists.gnu.org/archive/html/info-guix/2019-06/msg00001.html

Ludo'.

Re: enchant hash, fail to upgrade

[Catriel Omar D'Elía]

Ludovic Courtès <ludo@gnu.org> writes:

> ¡Hola!
>
> "Catriel" <cdelia@dc.uba.ar> skribis:
>
>> $guix upgrade --fallback
>> guix upgrade: aviso: paquete 'libstdc++' ya no existe
>> guix upgrade: el paquete 'sbcl-next' ha sido reemplazado por 'next'
>> substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
>
> Este servidor de substituciones está invalido ahora; deberías usar
> https://ci.guix.gnu.org en lugar de esta dirección:
>
>   https://lists.gnu.org/archive/html/info-guix/2019-06/msg00001.html
>
> Ludo'.

Ah I was not aware of this...

porque casi nunca uso --fallback y no recordaba que si no hay server de
substitución --fallback es por defecto. Estaba comenzando a pensar que
siempre se construyen las derivaciones y entonces guix elige substituir
el paquete o compilarlo (build it). No, lo que siempre hace es calcular
el hash, las derivaciones solo cuando debe compilar (lógico, era un paso
innecesario). El link que me pasaste me aclaró la mente. Gracias!

maybe a command like:

guix news

could prove helpful for this kind of scenarios?

Chau!

PD: buen español Ludo'!

COD.

Re: enchant hash, fail to upgrade

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

Catriel Omar D'Elía 写道：
> maybe a command like:
>
> guix news
>
> could prove helpful for this kind of scenarios?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37413 :-D

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: enchant hash, fail to upgrade

[Catriel Omar D'Elía]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Catriel Omar D'Elía 写道：
>> maybe a command like:
>>
>> guix news
>>
>> could prove helpful for this kind of scenarios?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37413 :-D
>

really nice! I never used --news, 'cuz I thought that it only told you
the new packages, as in debian: apt --upgradable. Really cool upgrade!
Thanks Ludo'!

> Kind regards,
>
> T G-R

Chau!
COD.