bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hi again, On Thu, 2 Jun 2022, at 13:57, Lars-Dominik Braun wrote: > Hey, > >> Indeed, that seems to work for those packages, but it still doesn't seem to >> work for OneTuple, as mentioned here: > I’m attaching a patch for that, please have a look. I’ll merge these > into master, since they don’t change any builds. That works, thanks! >> Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many >> other packages could be broken as well. > I didn’t actually upgrade any packages on wip-haskell yet, so it’s > likely they fail with a newer GHC than 8.10. Aha. Let me know if there's anything I can do to help.
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
On Thu, 2 Jun 2022, at 11:59, Philip Munksgaard wrote: > On Thu, 2 Jun 2022, at 11:53, Philip Munksgaard wrote: >> Also, attoparsec still won't build with result of the import, but for >> different reasons. > > Actually, that's weird. Didn't attoparsec used to build? Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many other packages could be broken as well.
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
On Thu, 2 Jun 2022, at 11:53, Philip Munksgaard wrote: > Also, attoparsec still won't build with result of the import, but for > different reasons. Actually, that's weird. Didn't attoparsec used to build?
bug#54752: import: hackage: `elif` conditionals not supported
On Sun, 22 May 2022, at 11:55, Lars-Dominik Braun wrote: > Hi Philip, > > thank you! > >> Unfortunately, building raaz still fails (first because of the description, >> then because some internal libraries are added as external dependencies, and >> then for... other reasons I haven't figured out. But all of those are >> separate issues. > > You’re right, it fails with this error for me, which indicates > haskell-build-system has a bug _somewhere_. > Yes, I don't think that should hold back these patches from going into wip-haskell.
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hi Lars, On Sun, 22 May 2022, at 11:37, Lars-Dominik Braun wrote: >> The attoparsec package on hackage defines multiple internal libraries inside >> one package, named "attoparsec" and "attoparsec-internal", with the first >> depending on the latter. Importing attoparsec using `guix import hackage >> attoparsec` therefore yields the following erroneous package definition: […] > > attached patches should fix this. I tried them with both, attoparsec and > raaz, and internal libraries appear neither in inputs nor native inputs > any more. > Indeed, that seems to work for those packages, but it still doesn't seem to work for OneTuple, as mentioned here: https://issues.guix.gnu.org/52152#3 Also, attoparsec still won't build with result of the import, but for different reasons.
bug#54752: import: hackage: `elif` conditionals not supported
Hi Lars On Sat, 14 May 2022, at 15:53, Lars-Dominik Braun wrote: > attached patch series fixes the import for `raaz` by adding support for > elif and other minor adjustments. There still is syntax we do not support, > most importantly mixed indentation, which is already documented as xfail > via a testcase. I’m adding a few more. > > Could you have a look please if these make sense? > Looks like it works! Unfortunately, building raaz still fails (first because of the description, then because some internal libraries are added as external dependencies, and then for... other reasons I haven't figured out. But all of those are separate issues.
bug#53655: haskell build system cannot build attoparsec
A patch has been submitted for the second part of this issue [0] and a new
issue has been created for the first part [1]. I'm therefore closing this issue.
0: https://issues.guix.gnu.org/54729
1: https://issues.guix.gnu.org/54760
On Wed, 6 Apr 2022, at 21:27, zimoun wrote:
> Hi,
>
> On Mon, 31 Jan 2022 at 11:33, "Philip Munksgaard"
> wrote:
>
>> ```
>> (define-module (gnu packages futhark)
>> #:use-module (guix packages)
>> #:use-module (guix download)
>> #:use-module (guix build-system haskell)
>> #:use-module (guix licenses)
>> #:use-module (guix git-download)
>> #:use-module ((guix licenses) #:prefix license:)
>> #:use-module (gnu packages)
>> #:use-module (gnu packages haskell)
>> #:use-module (gnu packages haskell)
>> #:use-module (gnu packages haskell-web)
>> #:use-module (gnu packages haskell-xyz)
>> #:use-module (gnu packages haskell-check)
>> #:use-module (gnu packages haskell-crypto))
>>
>> (package
>> (name "ghc-attoparsec")
>> (version "0.14.4")
>> (source
>> (origin
>> (method url-fetch)
>> (uri (hackage-uri "attoparsec" version))
>> (sha256
>> (base32 "0v4yjz4qi8bwhbyavqxlhsfb1iv07v10gxi64khmsmi4hvjpycrz"
>> (build-system haskell-build-system)
>> (inputs (list ghc-scientific))
>> (native-inputs
>> (list ghc-quickcheck
>> ghc-quickcheck-unicode
>> ghc-tasty
>> ghc-tasty-quickcheck
>> ghc-vector))
>> (arguments
>> `(#:cabal-revision
>> ("1" "149ihklmwnl13mmixq6iq5gzggkgqwsqrjlg2fshqwwbvbd4nn3r")))
>> (home-page "https://github.com/bgamari/attoparsec";)
>> (synopsis "Fast combinator parsing for bytestrings and text")
>> (description
>> "This package provides a fast parser combinator library, aimed
>> particularly at
>> dealing efficiently with network protocols and complicated text/binary file
>> formats.")
>> (license license:bsd-3))
>> ```
>>
>> When trying to build this file however, I get the following error:
>
> This part is now fixed by <https://issues.guix.gnu.org/54729#2>. But it
> is a core-updates change so the fix will land master at the next
> cycle... who knows when. ;-)
>
> For the other issue about the importer, I suggest to close this one and
> reopen an issue.
>
>
> Cheers,
> simon
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
The attoparsec package on hackage defines multiple internal libraries inside
one package, named "attoparsec" and "attoparsec-internal", with the first
depending on the latter. Importing attoparsec using `guix import hackage
attoparsec` therefore yields the following erroneous package definition:
(define-public ghc-attoparsec
(package
(name "ghc-attoparsec")
(version "0.14.4")
(source
(origin
(method url-fetch)
(uri (hackage-uri "attoparsec" version))
(sha256
(base32 "0v4yjz4qi8bwhbyavqxlhsfb1iv07v10gxi64khmsmi4hvjpycrz"
(build-system haskell-build-system)
(inputs (list ghc-scientific ghc-attoparsec-internal))
(native-inputs
(list ghc-quickcheck
ghc-quickcheck-unicode
ghc-tasty
ghc-tasty-quickcheck
ghc-vector))
(arguments
`(#:cabal-revision
("1" "149ihklmwnl13mmixq6iq5gzggkgqwsqrjlg2fshqwwbvbd4nn3r")))
(home-page "https://github.com/bgamari/attoparsec";)
(synopsis "Fast combinator parsing for bytestrings and text")
(description
"This package provides a fast parser combinator library, aimed
particularly at
dealing efficiently with network protocols and complicated text/binary file
formats.")
(license license:bsd-3)))
Note that `ghc-attoparsec-internal` is listed as a dependency of
`ghc-attoparsec`. I believe that is incorrect, and that we should filter out
the internal dependencies from `inputs`, just like we filter out
`ghc-attoparsec` from the list of `native-inputs`.
bug#52152: Haskell Hackage importer can create dependency cycles
Hi On Thu, 7 Apr 2022, at 09:45, zimoun wrote: > On Tue, 08 Mar 2022 at 11:04, zimoun wrote: >> And the "cycle" seems expected from OneTuple.cabal: >> >> $ cat OneTuple-0.3.1/OneTuple.cabal >> cabal-version: >=1.10 >> >> [...] >> >> test-suite th >> type: exitcode-stdio-1.0 >> default-language: Haskell98 >> hs-source-dirs: test >> main-is: th.hs >> build-depends: >> base >> , OneTuple >> , template-haskell >> >> >> Well, for what they are worth, based on this remark, two points: >> >> 1. I do not know what could be done on Guix side. An idea? >> 2. Usually, it is recommended to follow LTS and so Stackage. > > I do not think it is a bug from Guix but a bug from OneTuple upstream, > not in their version 0.2.2.1, and introduce by their version 0.3.1. I don't think that's correct. My understanding is that it is common (perhaps even necessary) to include the library itself in the test-suite dependencies. For instance, the same thing appears in attoparsec. However, when importing attoparsec, they are filtered out, and indeed we even have functionality to filter out the package name [0], but for some reason that doesn't work for OneTuple. 0: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/hackage.scm#n225
bug#54752: import: hackage: `elif` conditionals not supported
Since Cabal 2.2 conditional blocks support the `elif` construct [0], but our hackage importer does not currently support such expressions. This causes importing packages like `raaz` [1] to fail. 0: https://cabal.readthedocs.io/en/latest/cabal-package.html?highlight=elif#conditional-blocks 1: https://hackage.haskell.org/package/raaz
bug#48944:
Fixed by https://issues.guix.gnu.org/49199
bug#53655: haskell build system cannot build attoparsec
On Wed, 23 Feb 2022, at 12:06, Philip Munksgaard wrote: > And yes, this is indeed the issue I'm mostly concerned about. It seems > like > `/gnu/store/25ql0xsjqf0alrvy6hmpw6gzirzbqfmv-ghc-attoparsec-0.14.4/ghc-attoparsec-0.14.4.conf` > > is expected to be a file, while it is in fact a directory. I'm not sure > what that means or why it is important though. Upon further investigation, it seems like the `register` function in `guix/build/haskell-build-system.scm` assumes that running `runhaskell Setup.hs register --gen-pkg-config=...` will at most result in a single configuration file, while the documentation for `--gen-pkg-config` clearly states that it is also possible that it results in a directory[0]. The relevant section states: > This option outputs a directory if the package requires multiple > registrations: this can occur if internal/convenience libraries are used. > These configuration file names are sorted so that they can be registered in > order. I think we need to amend `haskell-build-system.scm` to be able to handle such cases. 0: https://downloads.haskell.org/cabal/Cabal-3.0.0.0/doc/users-guide/installing-packages.html#cmdoption-setup-register-gen-pkg-config
bug#53655: haskell build system cannot build attoparsec
On Wed, 23 Feb 2022, at 11:02, zimoun wrote:
> It is 2 different issues; therefore I propose to keep them separated.
Yes, I agree, sorry for the confusion.
> Let focus on this one…
>
>> When trying to build this file however, I get the following error:
>>
>> ```
>> running "runhaskell Setup.hs" with command "register" and parameters
>> ("--gen-pkg-config=/gnu/store/25ql0xsjqf0alrvy6hmpw6gzirzbqfmv-ghc-attoparsec-0.14.4/ghc-attoparsec-0.14.4.conf")
>> error: in phase 'register': uncaught exception:
>> ```
>
> …for this bug report. Hum, I do not know how where the error comes
> from.
>
And yes, this is indeed the issue I'm mostly concerned about. It seems like
`/gnu/store/25ql0xsjqf0alrvy6hmpw6gzirzbqfmv-ghc-attoparsec-0.14.4/ghc-attoparsec-0.14.4.conf`
is expected to be a file, while it is in fact a directory. I'm not sure what
that means or why it is important though.
bug#53655: haskell build system cannot build attoparsec
I'm trying to build a newer version of attoparsec than the one included in
guix, namely version 0.14.4.
First of all, `guix import hackage -r attoparsec` fails, as far as I can tell
because of the requirement to attoparsec-internal, with the following error:
```
$ guix import hackage -r attoparsec
Starting download of /tmp/guix-file.szLCRk
>From https://hackage.haskell.org/package/attoparsec/attoparsec-0.14.4.tar.gz...
….14.4.tar.gz 157KiB5.1MiB/s 00:00 [##] 100.0%
Backtrace:
7 (primitive-load "/home/munksgaard/.config/guix/current/…")
In guix/ui.scm:
2209:7 6 (run-guix . _)
2172:10 5 (run-guix-command _ . _)
In guix/scripts/import.scm:
124:11 4 (guix-import . _)
In guix/scripts/import/hackage.scm:
129:26 3 (guix-import-hackage . _)
In guix/import/utils.scm:
504:23 2 (recursive-import _ #:repo->guix-package _ #:guix-name _ …)
In srfi/srfi-1.scm:
586:17 1 (map1 (("attoparsec-internal" #f)))
In guix/import/utils.scm:
492:33 0 (lookup-node "attoparsec-internal" #f)
guix/import/utils.scm:492:33: In procedure lookup-node:
Wrong number of values returned to continuation (expected 2)
```
`guix import hackage attoparsec` succeeds, but I have to manually remove the
dependency on attoparsec-internal, resulting in this file:
```
(define-module (gnu packages futhark)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system haskell)
#:use-module (guix licenses)
#:use-module (guix git-download)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (gnu packages)
#:use-module (gnu packages haskell)
#:use-module (gnu packages haskell)
#:use-module (gnu packages haskell-web)
#:use-module (gnu packages haskell-xyz)
#:use-module (gnu packages haskell-check)
#:use-module (gnu packages haskell-crypto))
(package
(name "ghc-attoparsec")
(version "0.14.4")
(source
(origin
(method url-fetch)
(uri (hackage-uri "attoparsec" version))
(sha256
(base32 "0v4yjz4qi8bwhbyavqxlhsfb1iv07v10gxi64khmsmi4hvjpycrz"
(build-system haskell-build-system)
(inputs (list ghc-scientific))
(native-inputs
(list ghc-quickcheck
ghc-quickcheck-unicode
ghc-tasty
ghc-tasty-quickcheck
ghc-vector))
(arguments
`(#:cabal-revision
("1" "149ihklmwnl13mmixq6iq5gzggkgqwsqrjlg2fshqwwbvbd4nn3r")))
(home-page "https://github.com/bgamari/attoparsec";)
(synopsis "Fast combinator parsing for bytestrings and text")
(description
"This package provides a fast parser combinator library, aimed particularly
at
dealing efficiently with network protocols and complicated text/binary file
formats.")
(license license:bsd-3))
```
When trying to build this file however, I get the following error:
```
running "runhaskell Setup.hs" with command "register" and parameters
("--gen-pkg-config=/gnu/store/25ql0xsjqf0alrvy6hmpw6gzirzbqfmv-ghc-attoparsec-0.14.4/ghc-attoparsec-0.14.4.conf")
error: in phase 'register': uncaught exception:
system-error "fport_read" "~A" ("Is a directory") (21)
phase `register' failed after 0.5 seconds
Backtrace:
11 (primitive-load "/gnu/store/01ry4yp98silvy0mfwgn8c77fxz…")
In guix/build/gnu-build-system.scm:
906:2 10 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 8 (for-each # …)
In ice-9/boot-9.scm:
1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
927:23 6 (_)
In guix/build/haskell-build-system.scm:
244:23 5 (register #:name _ #:system _ #:inputs _ #:outputs _)
In ice-9/ports.scm:
433:17 4 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In ice-9/rdelim.scm:
160:18 3 (read-string _)
In unknown file:
2 (read-char #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
```
I've attached the entire build log.
q4j1fa750jn3jks5xpf5lqd4pnxkk9-ghc-attoparsec-0.14.4.drv.gz
Description: application/gzip
bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions
On Wed, 7 Jul 2021, at 07:58, Philip Munksgaard wrote:
> On Wed, 7 Jul 2021, at 05:26, John Kehayias via Bug reports for GNU Guix
> wrote:
> > Actually, this does exist in the Haskell build system in Guix, but
> > seems to be undocumented and not used by the importer. You can add the
> > following to the arguments (in the bootstrap package in this case) to
> > use a metadata revision:
> >
> > #:cabal-revision ("2"
> > "0a6j3313vz7n7dn8abddyib4jggblaq89f87ib4imdwjxjajbm33")
> >
> > The hash is from running guix hash file (where file = 2.cabal in this
> > case, downloaded from Hackage). This should be part of the importer, to
> > specify a revision or by default grab the latest, I would say.
> >
> > (and I'm guessing you know this is packaged in guix as
> > integer-logarithms, without the "ghc-" prefix for some reason; not the
> > only package like that I've noticed)
> >
>
> Ah yes, good catch! I agree that the fix should be to amend the
> importer, such that it finds out about these revisions and
> automatically uses the latest one.
Actually, upon closer inspection, that's exactly what it does! Instead of
actually using the importer in my original example (as I claimed), I had
actually just modified the code from gnu/packages/haskell-xyz.scm. Doing a
fresh import correctly picks up that there is a new revision of the cabal file
and produces the right derivation. I'll close this issue.
bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions
On Wed, 7 Jul 2021, at 05:26, John Kehayias via Bug reports for GNU Guix wrote:
> Actually, this does exist in the Haskell build system in Guix, but
> seems to be undocumented and not used by the importer. You can add the
> following to the arguments (in the bootstrap package in this case) to
> use a metadata revision:
>
> #:cabal-revision ("2" "0a6j3313vz7n7dn8abddyib4jggblaq89f87ib4imdwjxjajbm33")
>
> The hash is from running guix hash file (where file = 2.cabal in this
> case, downloaded from Hackage). This should be part of the importer, to
> specify a revision or by default grab the latest, I would say.
>
> (and I'm guessing you know this is packaged in guix as
> integer-logarithms, without the "ghc-" prefix for some reason; not the
> only package like that I've noticed)
>
Ah yes, good catch! I agree that the fix should be to amend the importer, such
that it finds out about these revisions and automatically uses the latest one.
bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions
The hackage store of haskell packages allows maintainers to update package
metadata directly on hackage without updating the associated archive of a
package. For instance, the cabal file of the integer-logarithms package version
1.0.3 [0] has been updated since 1.0.3 was published, relaxing the constraints
on some dependencies[1]. This means that, if I try to build the attached
integer-logarithms.scm (created from guix import hackage integer-logarithms and
modified to use ghc-8.8) I get the following error:
```
Setup.hs: Encountered missing or private dependencies:
base >=4.3 && <4.13
command "runhaskell" "Setup.hs" "configure"
"--prefix=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3"
"--libdir=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/lib"
"--docdir=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/share/doc/ghc-integer-logarithms-bootstrap-1.0.3"
"--libsubdir=$compiler/$pkg-$version"
"--package-db=/tmp/guix-build-ghc-integer-logarithms-bootstrap-1.0.3.drv-0/package.conf.d"
"--global" "--enable-shared" "--enable-executable-dynamic"
"--ghc-option=-fPIC"
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/lib/$compiler/$pkg-$version"
failed with status 1
builder for
`/gnu/store/pwdhhwp6d6b5g5pgik9y6ml5g1d8fxf5-ghc-integer-logarithms-bootstrap-1.0.3.drv'
failed with exit code 1
build of
/gnu/store/pwdhhwp6d6b5g5pgik9y6ml5g1d8fxf5-ghc-integer-logarithms-bootstrap-1.0.3.drv
failed
```
In ghc 8.8 the base version is 4.13, and the updated cabal file for
integer-logarithms amends the constrants to allow that version.
The solution might be to use `cabal get` to download the archive instead of
downloading the .tar.gz directly, or manually amending the cabal file after
downloading.
0: https://hackage.haskell.org/package/integer-logarithms-1.0.3
1: https://hackage.haskell.org/package/integer-logarithms-1.0.3/revisions/(define-module (gnu packages futhark)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system haskell)
#:use-module (guix licenses)
#:use-module (guix git-download)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (gnu packages)
#:use-module (gnu packages haskell)
#:use-module (gnu packages haskell)
#:use-module (gnu packages haskell-web)
#:use-module (gnu packages haskell-xyz)
#:use-module (gnu packages haskell-check)
#:use-module (gnu packages haskell-crypto))
(define-public ghc-integer-logarithms
(package
(name "ghc-integer-logarithms")
(version "1.0.3")
(source
(origin
(method url-fetch)
(uri (string-append "https://hackage.haskell.org/package/";
"integer-logarithms/integer-logarithms-"
version ".tar.gz"))
(sha256
(base32
"05pc5hws66csvcvfswlwcr2fplwn1lbssvwifjxkbbwqhq0n5qjs"
(build-system haskell-build-system)
(arguments
`(#:phases
(modify-phases %standard-phases
(add-before 'configure 'update-constraints
(lambda _
(substitute* "integer-logarithms.cabal"
(("tasty >= 0\\.10 && < 1\\.1")
"tasty >= 0.10 && < 1.2")))
(native-inputs
`(("ghc-quickcheck" ,ghc-quickcheck)
("ghc-smallcheck" ,ghc-smallcheck)
("ghc-tasty" ,ghc-tasty)
("ghc-tasty-hunit" ,ghc-tasty-hunit)
("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)
("ghc-tasty-smallcheck" ,ghc-tasty-smallcheck)))
(home-page "https://github.com/Bodigrim/integer-logarithms";)
(synopsis "Integer logarithms")
(description
"This package provides the following modules:
@code{Math.NumberTheory.Logarithms} and
@code{Math.NumberTheory.Powers.Integer} from the @code{arithmoi} package,
@code{GHC.Integer.Logarithms.Compat} and
@code{Math.NumberTheory.Power.Natural}, as well as some additional functions
in migrated modules.")
(license license:expat)))
(define-public ghc-integer-logarithms-bootstrap
(package
(inherit ghc-integer-logarithms)
(name "ghc-integer-logarithms-bootstrap")
(arguments `(#:tests? #f
#:haskell ,ghc-8.8))
(native-inputs '())
(properties '((hidden? #t)
ghc-integer-logarithms-bootstrap
bug#49326: haskell-build-tool: specifying a haskell version breaks some builds
The attached versions.scm has been generated using `guix import hackage
versions` and specifying that I want to build it with `#:haskell ,ghc-8.8`.
Upon building, I get the error posted here: http://paste.debian.net/1203119/
I'm not entirely sure what the problem is, but it seems like when another
version of ghc has been specified, dependencies built with another version of
ghc no longer work.(use-modules (guix packages))
(use-modules (guix download))
(use-modules (guix build-system haskell))
(use-modules (guix licenses))
(use-modules (gnu packages))
(use-modules (gnu packages haskell))
(use-modules (gnu packages haskell-xyz))
(use-modules (gnu packages haskell-crypto))
(use-modules (gnu packages haskell-check))
(define-public ghc-versions
(package
(name "ghc-versions")
(version "5.0.0")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/versions/versions-";
version
".tar.gz"))
(sha256
(base32
"1rfxjivdsaqc6w7dfqdycy3a81rsajvpfyi5si9ssc0w3ljfsbzr"
(build-system haskell-build-system)
(arguments `(#:haskell ,ghc-8.8))
(inputs
`(("ghc-megaparsec" ,ghc-megaparsec)
("ghc-hashable" ,ghc-hashable)
("ghc-parser-combinators"
,ghc-parser-combinators)))
(native-inputs
`(("ghc-microlens" ,ghc-microlens)
("ghc-quickcheck" ,ghc-quickcheck)
("ghc-tasty" ,ghc-tasty)
("ghc-tasty-hunit" ,ghc-tasty-hunit)
("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)))
(home-page
"https://github.com/fosskers/versions";)
(synopsis
"Types and parsers for software version numbers.")
(description
"A library for parsing and comparing software version numbers. We like to give version numbers to our software in a myriad of ways. Some ways follow strict guidelines for incrementing and comparison. Some follow conventional wisdom and are generally self-consistent. Some are just plain asinine. This library provides a means of parsing and comparing /any/ style of versioning, be it a nice Semantic Version like this: . > 1.2.3-r1+git123 . ...or a monstrosity like this: . > 2:10.2+0.0093r3+1-1 . Please switch to if you aren't currently using it. It provides consistency in version incrementing and has the best constraints on comparisons. . This library implements version @2.0.0@ of the SemVer spec.")
(license bsd-3)))
ghc-versions
bug#49320: guix import hackage does not support build-tools and build-tool-depends stanzas
The two stanzas build-tools[0] and build-tool-depends[1] are not supported by
the cabal importer[2], which means that the generated build files for a package
such as language-c-quote[3] doesn't work.
For instance, the attached language-c-quote.scm was generated by amending the
result of running `guix cabal import -r language-c-quote`. Building it with
`guix build -f language-c-quote.scm` yields the following error:
```
Setup.hs: The program 'alex' version >=3 is required but it could not be
found.
command "runhaskell" "Setup.hs" "configure"
"--prefix=/gnu/store/javas0gpngal7lcmc77srpcc9z4891ni-ghc-language-c-quote-0.13"
"--libdir=/gnu/store/javas0gpngal7lcmc77srpcc9z4891ni-ghc-language-c-quote-0.13/lib"
"--docdir=/gnu/store/javas0gpngal7lcmc77srpcc9z4891ni-ghc-language-c-quote-0.13/share/doc/ghc-language-c-quote-0.13"
"--libsubdir=$compiler/$pkg-$version"
"--package-db=/tmp/guix-build-ghc-language-c-quote-0.13.drv-0/package.conf.d"
"--global" "--enable-tests" "--enable-shared" "--enable-executable-dynamic"
"--ghc-option=-fPIC"
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/javas0gpngal7lcmc77srpcc9z4891ni-ghc-language-c-quote-0.13/lib/$compiler/$pkg-$version"
failed with status 1
builder for
`/gnu/store/4l01sv6w7a7y8sikka48pd14rvw1wvj6-ghc-language-c-quote-0.13.drv'
failed with exit code 1
build of
/gnu/store/4l01sv6w7a7y8sikka48pd14rvw1wvj6-ghc-language-c-quote-0.13.drv failed
View build log at
'/var/log/guix/drvs/4l/01sv6w7a7y8sikka48pd14rvw1wvj6-ghc-language-c-quote-0.13.drv.bz2'.
guix build: error: build of
`/gnu/store/4l01sv6w7a7y8sikka48pd14rvw1wvj6-ghc-language-c-quote-0.13.drv'
failed
```
The attached language-c-quote-fixed.scm adds the `ghc-happy` and `ghc-alex`
packages to native-inputs, as required by the build-tools stanzas in the
original cabal file.
However, build-tools has actually been deprecated in favor of
build-tool-depends, as noted in the documentation, so I guess we should
actually implement support for it in addition to build-tools.
0: https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-build-tools
1:
https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-build-tool-depends
2: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/cabal.scm
3: https://hackage.haskell.org/package/language-c-quote(define-module (gnu packages futhark)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system haskell)
#:use-module (guix licenses)
#:use-module (guix git-download)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (gnu packages)
#:use-module (gnu packages haskell)
#:use-module (gnu packages haskell-web)
#:use-module (gnu packages haskell-xyz)
#:use-module (gnu packages haskell-check)
#:use-module (gnu packages haskell-crypto))
(define-public ghc-srcloc
(package
(name "ghc-srcloc")
(version "0.6")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/srcloc/srcloc-";
version
".tar.gz"))
(sha256
(base32
"1vcp9vgfi5rscy09l4qaq0pp426b6qcdpzs6kpbzg0k5x81kcsbb"
(build-system haskell-build-system)
(home-page "https://github.com/mainland/srcloc";)
(synopsis
"Data types for managing source code locations.")
(description
"Data types for tracking, combining, and printing source code locations.")
(license bsd-3)))
(define-public ghc-mainland-pretty
(package
(name "ghc-mainland-pretty")
(version "0.7.1")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/mainland-pretty/mainland-pretty-";
version
".tar.gz"))
(sha256
(base32
"19z2769rik6kwvsil2if2bfq2v59jmwv74jy3fy4q3q3zy4239p1"
(build-system haskell-build-system)
(inputs `(("ghc-srcloc" ,ghc-srcloc)))
(home-page
"https://github.com/mainland/mainland-pretty";)
(synopsis
"Pretty printing designed for printing source code.")
(description
"Pretty printing designed for printing source code based on Wadler's paper /A Prettier Printer/. The main advantage of this library is its ability to automatically track the source locations associated with pretty printed values and output appropriate #line pragmas and its ability to produce output in the form of lazy text using a builder.")
(license bsd-3)))
(define-public ghc-exception-transformers
(package
(name "ghc-exception-transformers")
(version "0.4.0.9")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/exception-transformers/exception-transformers-";
version
".tar.gz"))
(sha256
(base32
"033z8mhczwf59lh59q3z546gkcsy0bzg98r1qhm3fiq7j11hgd95"
(build-system h
bug#48944: haskell build-system cannot build pcg-random
Hi John Kehayias, The patch seems to work! What will it take for us to get it merged? Best, Philip
bug#48701: Closed by 48943
This issue has been fixed by #48943 and should be closed.
bug#48700: guix import fails with unexpected token
On Thu, 10 Jun 2021, at 15:02, zimoun wrote: > On Thu, 10 Jun 2021 at 14:22, Philip Munksgaard wrote: > > > If I understand you correctly, you're saying that this issue is an instance > > of bug#44115 because we get a backtrace instead of a nice error. I agree > > that the backtrace is ugly, but in this case the error shouldn't happen at > > all because all the recursively imported packages exist. > > Your point is that parsing the Cabal file of the package "versions" > fails. Mine is, somehow, instead of an ugly backtrace (whatever the > reason), the error for "guix import hackage futhark -r" should be: > > Syntax error: unexpected token : common (at line 36, column 0) > Syntax error: unexpected end of input > guix import: error: échec du téléchargement du fichier cabal du > paquet « versions » > > as it is for "guix import hackage versions". > Good point, I agree that would be nicer. The backtrace was not my concern when submitting this bug, but it doesn't really matter as long as both issues are fixed :-)
bug#48700: guix import fails with unexpected token
Hi zimoun, If I understand you correctly, you're saying that this issue is an instance of bug#44115 because we get a backtrace instead of a nice error. I agree that the backtrace is ugly, but in this case the error shouldn't happen at all because all the recursively imported packages exist. The reason why the backtrace occurs is that the cabal-file for one of the recursively imported dependencies (versions) cannot be parsed using the current version of guix/import/cabal.scm. You'll find that `guix import hackage -r futhark` works as expected with the submitted patch#48943. Furthermore, I actually think that a backtrace _is_ desirable in this case, because it is an error in the script, and not in the users input or some third-party repository. As you say, your example works, but you've forgotten the "versions" dependency. If you add that to your list it will not work. Best regards, Philip
bug#48944: haskell build-system cannot build pcg-random
I've used `guix import hackage pcg-random` to create the attached
pcg-random.scm. When trying to build it using `guix build -f pcg-random.scm`, I
get the following error:
starting phase `configure'
running "runhaskell Setup.hs" with command "configure" and parameters
("--prefix=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7"
"--libdir=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/lib"
"--docdir=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/share/doc/ghc-pcg-random-0.1.3.7"
"--libsubdir=$compiler/$pkg-$version"
"--package-db=/tmp/guix-build-ghc-pcg-random-0.1.3.7.drv-0/package.conf.d"
"--global" "--enable-tests" "--enable-shared" "--enable-executable-dynamic"
"--ghc-option=-fPIC"
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/lib/$compiler/$pkg-$version")
Setup.hs:3:1: error:
Could not find module ‘Distribution.Extra.Doctest’
Perhaps you meant Distribution.Simple.Doctest (from Cabal-2.4.0.1)
Use -v to see a list of the files searched for.
|
3 | import Distribution.Extra.Doctest (defaultMainWithDoctests)
| ^^^
command "runhaskell" "Setup.hs" "configure"
"--prefix=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7"
"--libdir=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/lib"
"--docdir=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/share/doc/ghc-pcg-random-0.1.3.7"
"--libsubdir=$compiler/$pkg-$version"
"--package-db=/tmp/guix-build-ghc-pcg-random-0.1.3.7.drv-0/package.conf.d"
"--global" "--enable-tests" "--enable-shared" "--enable-executable-dynamic"
"--ghc-option=-fPIC"
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/s5fjjd04x0n5f5dr9rgaf963nfqwf3dz-ghc-pcg-random-0.1.3.7/lib/$compiler/$pkg-$version"
failed with status 1
builder for
`/gnu/store/7jkcigan6ygy42c3ivy9spfqh5pfx4qx-ghc-pcg-random-0.1.3.7.drv' failed
with exit code 1
build of /gnu/store/7jkcigan6ygy42c3ivy9spfqh5pfx4qx-ghc-pcg-random-0.1.3.7.drv
failed
View build log at
'/var/log/guix/drvs/7j/kcigan6ygy42c3ivy9spfqh5pfx4qx-ghc-pcg-random-0.1.3.7.drv.bz2'.
guix build: error: build of
`/gnu/store/7jkcigan6ygy42c3ivy9spfqh5pfx4qx-ghc-pcg-random-0.1.3.7.drv' failed
(use-modules (guix packages))
(use-modules (guix download))
(use-modules (guix build-system haskell))
(use-modules (guix licenses))
(use-modules (gnu packages))
(use-modules (gnu packages haskell))
(use-modules (gnu packages haskell-xyz))
(use-modules (gnu packages haskell-crypto))
(define-public ghc-cabal-doctest
(package
(name "ghc-cabal-doctest")
(version "1.0.8")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/cabal-doctest/cabal-doctest-";
version
".tar.gz"))
(sha256
(base32
"03if74imlhhk7m56nci5f1wclniwqdmwl4hl177040j1gnlac9i0"
(build-system haskell-build-system)
(arguments
`(#:cabal-revision
("2"
"05v1awad3d1wvc763xcgvxm4n6n7bs7byc6s14kdbw35zcaddlcb")))
(home-page
"https://github.com/phadej/cabal-doctest";)
(synopsis
"A Setup.hs helper for doctests running")
(description
"Currently (beginning of 2017), there isn't @cabal doctest@ command. Yet, to properly work doctest needs plenty of configuration. This library provides the common bits for writing custom Setup.hs See for the progress of @cabal doctest@, i.e. whether this library is obsolete.")
(license bsd-3)))
(define-public ghc-pcg-random
(package
(name "ghc-pcg-random")
(version "0.1.3.7")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/pcg-random/pcg-random-";
version
".tar.gz"))
(sha256
(base32
"1l6jq5nvmg1ygk7i7g50s47p6qkh74p9avl1wbcxdl5m85lc5j76"
(build-system haskell-build-system)
(inputs
`(("ghc-primitive" ,ghc-primitive)
("ghc-random" ,ghc-random)
("ghc-entropy" ,ghc-entropy)
("ghc-doctest" ,ghc-doctest)
("ghc-cabal-doctest" ,ghc-cabal-doctest)))
(native-inputs
`(("ghc-doctest" ,ghc-doctest)
("ghc-cabal-doctest" ,ghc-cabal-doctest)))
(home-page
"http://github.com/cchalmers/pcg-random";)
(synopsis
"Haskell bindings to the PCG random number generator.")
(description
"PCG is a family of simple fast space-efficient statistically good algorithms for random number generation. Unlike many general-purpose RNGs, they are also hard to predict. . This library implements bindings to the standard C implementation. This includes the standard, unique, fast and single variants in the pcg family. There is a pure implementation that can be used as a generat
bug#48700: guix import fails with unexpected token
As far as I can tell, this is actually an instance of https://issues.guix.gnu.org/48701. You can close this issue in favor of that one.
bug#48700: guix import fails with unexpected token
Trying to to import futhark from hackage fails, when using the -r flag.
$ guix import hackage -r futhark
user with UID 497492280 not found
Starting download of /tmp/guix-file.MqWnPq
>From https://hackage.haskell.org/package/futhark/futhark-0.19.5.tar.gz...
…19.5.tar.gz 959KiB 6.6MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.ZPWyOq
>From
>https://hackage.haskell.org/package/bytestring-to-vector/bytestring-to-vector-0.3.0.1.tar.gz...
…tor-0.3.0.1.tar.gz 4KiB9.4MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.bjbYYp
>From https://hackage.haskell.org/package/bmp/bmp-1.2.6.3.tar.gz...
….3.tar.gz 10KiB 23.7MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.uhGsUr
>From
>https://hackage.haskell.org/package/directory-tree/directory-tree-0.12.1.tar.gz...
…-0.12.1.tar.gz 12KiB 15.1MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.SUjZRr
>From
>https://hackage.haskell.org/package/language-c-quote/language-c-quote-0.13.tar.gz...
…te-0.13.tar.gz 74KiB 4.2MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.W3CjMq
>From
>https://hackage.haskell.org/package/mainland-pretty/mainland-pretty-0.7.1.tar.gz...
…y-0.7.1.tar.gz 10KiB 11.8MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.K7aEUp
>From
>https://hackage.haskell.org/package/neat-interpolation/neat-interpolation-0.5.1.2.tar.gz...
…on-0.5.1.2.tar.gz 6KiB 9.7MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.ovhTIs
>From
>https://hackage.haskell.org/package/pcg-random/pcg-random-0.1.3.7.tar.gz...
….1.3.7.tar.gz 25KiB3.5MiB/s 00:00 [##] 100.0%
user with UID 497492280 not found
Starting download of /tmp/guix-file.nj5C8q
>From https://hackage.haskell.org/package/srcloc/srcloc-0.6.tar.gz...
….6.tar.gz 4KiB 9.9MiB/s 00:00 [##] 100.0%
Syntax error: unexpected token : common (at line 36, column 0)
Syntax error: unexpected end of input
Backtrace:
In ice-9/boot-9.scm:
1736:10 17 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
16 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2 15 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 14 (_ #(#(#)))
In guix/ui.scm:
2166:12 13 (run-guix-command _ . _)
In guix/scripts/import.scm:
120:11 12 (guix-import . _)
In guix/scripts/import/hackage.scm:
132:26 11 (guix-import-hackage . _)
In guix/import/utils.scm:
477:27 10 (recursive-import _ #:repo->guix-package _ #:guix-name _ …)
In srfi/srfi-1.scm:
586:29 9 (map1 _)
586:29 8 (map1 _)
586:29 7 (map1 _)
586:29 6 (map1 _)
586:29 5 (map1 _)
586:29 4 (map1 (("neat-interpolation" #f) ("pcg-random" #f) (…) …))
586:29 3 (map1 (("pcg-random" #f) ("srcloc" #f) ("versions" #f)))
586:29 2 (map1 (("srcloc" #f) ("versions" #f)))
586:17 1 (map1 (("versions" #f)))
In guix/import/utils.scm:
466:33 0 (lookup-node "versions" #f)
guix/import/utils.scm:466:33: In procedure lookup-node:
Wrong number of values returned to continuation (expected 2)
bug#48701: cabal import parser doesn't support common stanzas
As far as I can tell, the cabal parser for the `guix import` command (https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/cabal.scm) does not support common stanzas, as specified in the cabal specification (https://cabal.readthedocs.io/en/3.4/cabal-package.html#common-stanzas). This means that some packages, like "versions" (https://hackage.haskell.org/package/versions-5.0.0/src/versions.cabal) and all depending packages cannot be imported using `guix import hackage versions`: ``` $ guix import hackage versions Syntax error: unexpected token : common (at line 36, column 0) Syntax error: unexpected end of input guix import: error: failed to download cabal file for package 'versions' ```
