bug-guix
[Top][All Lists]
Advanced

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

bug#21829: guix import hackage failures


From: Federico Beffa
Subject: bug#21829: guix import hackage failures
Date: Tue, 10 Nov 2015 17:40:40 +0100

Hi,

I have checked the errors and have found the following:

* I do not get backtraces, but the following error:
------------------------------
$ ./pre-inst-env guix import hackage xmonad-contrib

Starting download of /tmp/guix-file.yf7Cor
>From http://hackage.haskell.org/package/xmonad-contrib/xmonad-contrib.cabal...
 xmonad-contrib.cabal                         761KiB/s 00:00 | 13KiB transferred
Syntax error: unexpected token : true (at line 75, column 7)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'xmonad-contrib'
------------------------------
  not sure what's different.

* The following packages fail because the file has DOS line endings:

  happy, base-compat, base-orphans, fast-logger, generic-deriving, ObjectName,
  SDL, setenv, split, StateVar, syb, transformers-base, wai, xmonad (+ 1 more
  problem), zlib (+ 1 more problem).

 Changing the encoding to UNIX line endings fixes the problem. This is
the number 1 problem. Is there a Guile way to easily fix this?

* nats gets imported correctly here?!

* The rest are genuine parsing errors. A brief summary of them and how
to fix them follows:
- xmonad-contrib, xmonad, xmonad-extras::
  + "if true" not handled.
  + "impl (ghc == 6.10.1) && arch (x86_64)" --> "impl(ghc == 6.10.1)
&& arch(x86_64)" OK
- clock, hscolour, QuickCheck::
  + "default   : Ture" --> "default: True" OK
  + "impl (ghc < 7.6)" --> "impl(ghc < 7.6)"
- fgl:: "description: {
         An ....
         }" ->
  No braces OK. Braces not handled outside of groups.
- old-locale:: "Cabal-Version:>=1.10" --> "Cabal-Version: >=1.10" OK
- streaming-common:: same group indentation level changes from 4 to 2 spaces!
  This file is buggy!
- tagged:: "if impl(ghc>=7.2 && <7.5)". Probably not handled correctly by parser
- zlib:: no final "\n" on last line

I will look into fixing them, but not immediately because of other
priorities. If somebody else is interested in diving into this, please
let me know, so that we don't duplicate efforts.

Regards,
Fede





reply via email to

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