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
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?
Ah
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?
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
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
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
n 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 (gu
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
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
>>
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:
Fixed by https://issues.guix.gnu.org/49199
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, whil
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"
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
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 imp
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
>
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
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
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
Hi John Kehayias,
The patch seems to work! What will it take for us to get it merged?
Best,
Philip
This issue has been fixed by #48943 and should be closed.
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
> > th
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.
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
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.
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
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
27 matches
Mail list logo
