Cabal mismatch in ghc-lucid; long-term archiving Haskell?

Cabal mismatch in ghc-lucid; long-term archiving Haskell?

[zimoun]

Hi,

Let try to build the Haskell package ghc-lucid.

--8<---------------cut here---------------start------------->8---
$ guix build ghc-lucid
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv
  /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv
building /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv...

Starting download of /gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal
From https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal...
downloading from https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal ...
 1.cabal                                                                            345KiB/s 00:00 | 3KiB transferred
sha256 hash mismatch for /gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal:
  expected hash: 1f0whk5ncanxfjjanrf6rqyncig2xgc5mh2j0sqy3nrlyjr9aqq9
  actual hash:   1xllyf26ypk37k807g5v6fl1449mhpvk18dljmqgwj723n0v8rpj
hash mismatch for store item '/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal'
build of /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv failed
View build log at '/var/log/guix/drvs/i6/2zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv.gz'.
cannot build derivation `/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv' failed
--8<---------------cut here---------------end--------------->8---

and indeed, ci.guix.gnu.org is also failing (since May) with the same
message.  See <https://ci.guix.gnu.org/build/750925/details>.

The reason is because,

--8<---------------cut here---------------start------------->8---
    (arguments
     `(#:cabal-revision
       ("1"
        "1f0whk5ncanxfjjanrf6rqyncig2xgc5mh2j0sqy3nrlyjr9aqq9")))
--8<---------------cut here---------------end--------------->8---

Hopefully, we have an old substitute for this Cabal file on
bordeaux.guix.gnu.org.

Therefore, we can compare both:

--8<---------------cut here---------------start------------->8---
$ diff error.cabal pass.cabal
2,3c2,3
< version:             2.9.12.1
< x-revision: 1
---
> version:             2.9.12
> x-revision:          1
23c23
< cabal-version:       >=1.10
---
> cabal-version:       >=1.8
25c25
< tested-with:         GHC==7.10.3,GHC==8.0.2,GHC==8.2.2,GHC==8.4.4,GHC==8.6.5,GHC==8.8.4,GHC==8.10.4,GHC==9.0.1
---
> tested-with:         GHC==7.10.3,GHC==8.0.2,GHC==8.2.2,GHC==8.4.4,GHC==8.6.5,GHC==8.8.3,GHC==8.10.1
28d27
<   default-language:  Haskell2010
37c36
<   build-depends:     base                   >=4.8      && <4.16
---
>   build-depends:     base                   >=4.8      && <4.15
43c42
<   build-depends:     mtl                    >=2.2 && < 2.3
---
>   build-depends:     mtl                    >=2.2
56,59d54
< source-repository head
<   type:     git
<   location: https://github.com/chrisdone/lucid.git
< 
61d55
<     default-language: Haskell2010
76d69
<   default-language: Haskell2010
91d83
<   default-language: Haskell2010
--8<---------------cut here---------------end--------------->8---


And it is where I am confused. :-)  The Hackage entry of the Haskell
package Lucid says:

     https://hackage.haskell.org/package/lucid-2.9.12.1/revisions/

which corresponds to only one line in the diff.  All the other means
that the time-machine could break.


Is it a manual in-place replacement?  Or is it an automatic in-place
update by Hackage infrastructure?  Or do I miss a point?

In all cases, these revised Cabal files are not archived elsewhere than
in Hackage, right?  The question is thus, where could we archive them?

Note that the both items have the same store-address hash
(/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal)
but not the same content hash.


Any idea?


Cheers,
simon

Re: Cabal mismatch in ghc-lucid; long-term archiving Haskell?

[Lars-Dominik Braun]

Hi zimoun,

> Is it a manual in-place replacement?  Or is it an automatic in-place
> update by Hackage infrastructure?  Or do I miss a point?
> 
> In all cases, these revised Cabal files are not archived elsewhere than
> in Hackage, right?  The question is thus, where could we archive them?
> 
> Note that the both items have the same store-address hash
> (/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal)
> but not the same content hash.
fear not, this is a mistake on our side – mine in particular. `git
blame` indicates the package was updated in my last big Haskell bump as
commit b97f549b14402421fcfb360ddd4cff7de93b9af0. And while I updated the
version number, I did not touch #:cabal-revision, which is obviously a
mistake. Unfortunately we chose to encode this information into arguments
and not the version and so this happens (alot), because – alas –
`guix refresh` touches the version only, but not #:cabal-revision.

As for Haskell/Hackage/Stackage: All of their .cabal files are versioned
and never overwritten. I think they also keep them permanently.

Cheers,
Lars

Re: Cabal mismatch in ghc-lucid; long-term archiving Haskell?

[zimoun]

Hi Lars,

On sam., 20 août 2022 at 18:47, Lars-Dominik Braun <lars@6xq.net> wrote:

>> In all cases, these revised Cabal files are not archived elsewhere than
>> in Hackage, right?  The question is thus, where could we archive them?

>                                                  And while I updated the
> version number, I did not touch #:cabal-revision, which is obviously a
> mistake. Unfortunately we chose to encode this information into arguments
> and not the version and so this happens (alot), because – alas –
> `guix refresh` touches the version only, but not #:cabal-revision.

Well, it means it is not part of the ’source’ and thus not considered by
any of the archiving mechanism.  IIUC.

Using Guix 65cabb0, 719 packages are using ’haskell-build-system’ and
considering these, 108 packages have a ’cabal-revision’ argument.  See
below the snippet of “guix repl”.

Considering that the Haskell build-system is creating an ’origin’ under
the hood, from (guix build-system haskell):

--8<---------------cut here---------------start------------->8---
  (define (cabal-revision->origin cabal-revision)
    (match cabal-revision
      ((revision hash)
       (origin
         (method url-fetch)
         (uri (source-url->revision-url (origin-uri source) revision))
         (sha256 (base32 hash))
         (file-name (string-append name "-" revision ".cabal"))))
      (#f #f)))
--8<---------------cut here---------------end--------------->8---

Maybe it could be better to move the ’cabal-revision’ from the
’arguments’ field to the ’origin’ field.

Perhaps, we could have a ’cabal-revision’ procedure returning a G-exp
and put it under the ’snippet’ field.

WDYT?

Having all as ’origin’ would ease 1. to teach “guix refresh” about this
Cabal revision and 2. to only consider ’origin’ for archiving.

Note that ’computed-origin-method’ from (guix packages) could be used
too; although it seems a bad idea, IMHO.  However, maybe a package using
multiple upstream sources could be revisited.


That’s said, it is a core-updates change because it requires to modify
the Haskell build-system and, a rough estimate about the number of
impacted packages:

--8<---------------cut here---------------start------------->8---
$ guix refresh ghc -l | cut -d':' -f1
Building the following 450 packages would ensure 1468 dependent packages are rebuilt
--8<---------------cut here---------------end--------------->8---


Cheers,
simon


--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (use-modules (guix)
             (guix build-system haskell)
             (gnu)
             (ice-9 match))

scheme@(guix-user)> (define haskell-packages
  (fold-packages
   (lambda (package result)
     (if (eq? (package-build-system package) haskell-build-system)
         (cons package result)
         result))
   '()))

scheme@(guix-user)> (define (cabal-revision? package)
  (apply (lambda* (#:key cabal-revision #:allow-other-keys)
           (match cabal-revision
             ((revision hash) #t)
             (_ #f)))
         (package-arguments package)))

scheme@(guix-user)> (define cabal-revision-packages
  (filter cabal-revision? haskell-packages))

scheme@(guix-user)> (length haskell-packages)
$1 = 719
scheme@(guix-user)> (length cabal-revision-packages)
$2 = 108
--8<---------------cut here---------------end--------------->8---

Re: Cabal mismatch in ghc-lucid; long-term archiving Haskell?

[Lars-Dominik Braun]

Hi zimoun,

> Maybe it could be better to move the ’cabal-revision’ from the
> ’arguments’ field to the ’origin’ field.
> Perhaps, we could have a ’cabal-revision’ procedure returning a G-exp
> and put it under the ’snippet’ field.
> WDYT?
it would be awesome to have that functionality and I agree that a
“combining” origin putting the .cabal file in the right spot would
be ideal. Not sure how to build that though, any ideas?

> That’s said, it is a core-updates change because it requires to modify
> the Haskell build-system and, a rough estimate about the number of
> impacted packages:
There’s a branch wip-haskell waiting to be worked on.

Lars