November 2011 - cabal-devel

[Hackage] #714: cabal: Couldn't read cabal file ".\\HaTeX\\1.0.0\\HaTeX.cabal"
by Hackage 05 Mar '12

05 Mar '12

#714: cabal: Couldn't read cabal file ".\\HaTeX\\1.0.0\\HaTeX.cabal" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ---------------------------------+------------------------------------------ I have a similar error than exposed in Ticket#677. This error appears when I try to install the HaTeX package: cabal: Couldn't read cabal file ".\\HaTeX\\1.0.0\\HaTeX.cabal" Even when I'm installing version 1.0.1. A link to the package in Hackage: http://hackage.haskell.org/package/HaTeX Note that the same error appears in Hackage. I'm the author of the package, and I want a fix for him. But I don't know how to attack the problem, because error appears before reading a new version of the package (When "Resolving dependencies..."). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/714> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #716: Inconsistent behavior between custom and simple build types
by Hackage 05 Mar '12

05 Mar '12

#716: Inconsistent behavior between custom and simple build types ---------------------------------+------------------------------------------ Reporter: j3h | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If a Custom build-type is used, Setup.hs may be built with a different version of Cabal than the one that cabal-install was built with. This can cause hard-to-find (seemingly random) build failures. Perhaps cabal-install should warn when it runs Setup.hs with a different version of Cabal than the one that it was built with. Alternatively, it could fail if the version of Cabal that cabal-install was built with is not available when compiling the Setup script. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/716> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #719: tool support for checking if a package works with a range of versions
by Hackage 05 Mar '12

05 Mar '12

#719: tool support for checking if a package works with a range of versions ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ [http://www.haskell.org/pipermail/libraries/2010-July/013970.html Doaitse reports] that he would like: {{{ since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too) }}} Others responded that they would also like to do the same thing locally, even though the range of versions they have locally may be limited. So one simple approach would be a flag to indicate a preference that the earliest version of a package (or all packages?) be used rather than the latest version. This might be integrated into a "cabal disttest" feature that makes a tarball and builds from the tarball. The same approach could be taken for hackage build bots. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/719> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #723: Strip path error under Cygwin
by Hackage 05 Mar '12

05 Mar '12

#723: Strip path error under Cygwin ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: strip cygwin windows Difficulty: unknown | Ghcversion: Platform: Windows | ---------------------------------+------------------------------------------ I am using a new Windows 7 box using cygwin and the Haskell Platform 2010.2.0.0. I am working with cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library. Cabal config is default located here: \\fs1\grad\users\pkeir\Application Data\cabal\config Installing packages with cabal-install ends with an error relating to the path argument provided to strip (strip is present on cygwin): cabal install cpphs ... Linking dist\build\cpphs\cpphs.exe ... Installing library in \\fs1\grad\users\pkeir\Application Data\cabal\cpphs-1.11\ghc-6.123 Installing executable(s) in \\fs1\grad\users\pkeir\Application Data\cabal\bin /usr/bin/strip: '\fs1\grad\users\pkeir\Application Data\cabal\bin\cpphs.exe': No such file cabal.exe: Error: some packages failed to install: cpphs-1.11 failed during the final install step. The exception was: ExitFailure 1 It looks like strip is being given one less backslash than it needs at the start. The exe is however installed, and so this command does work: strip '\\fs1\grad\users\pkeir\Application Data\cabal\bin\cpphs.exe' Though of course the package remains formally uninstalled. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/723> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #732: Implement opt-in for anonymous build reporting
by Hackage 05 Mar '12

05 Mar '12

#732: Implement opt-in for anonymous build reporting ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ We want people to send in anonymous build reports. We also want to respect people's privacy. The suggestion is that we should use an opt-in system but make it very easy to opt in. Currently most users have a config file that contains no value set for the config file fields that control the build reporting feature. The suggestion is that when the build reporting config items are not set then we should interactively prompt users like so: {{{ $ cabal update Cabal can send build reports back to to the package server. Build reporting helps to improve package quality. The information sent back is minimal and it does not identify your computer. For more details see: http://haskell.org/cabal/reporting Enable automatic anonymous reporting of package builds? [y/n/?] Downloading the latest package list from hackage.haskell.org }}} We would then rewrite the config file with the updated setting, either on or off. That will require that we correctly preserve settings and comments in the config file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/732> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #745: cabal-install sometimes gives empty build-log and no build-summary
by Hackage 05 Mar '12

05 Mar '12

#745: cabal-install sometimes gives empty build-log and no build-summary ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Building `NaturalSort-0.2.1` with GHC 7.0.1 RC 1: {{{ $ cabal install --build-summary=log.bs --build-log=log.bl Resolving dependencies... Warning: NaturalSort.cabal: This package requires Cabal version: >=1.6 && <1.9 cabal: Error: some packages failed to install: NaturalSort-0.2.1 failed during the configure step. The exception was: user error (The package requires Cabal library version -any && >=1.6 && <1.9 but no suitable version is installed.) $ cat log.bs cat: log.bs: No such file or directory $ cat log.bl $ }}} I would like the build log to contain the error. I have {{{ $ cabal --version cabal-install version 0.9.2 using version 1.9.2 of the Cabal library }}} but this is not a released version; if nothing else, I have the #697 patch applied. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/745> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #748: cabal update fails
by Hackage 05 Mar '12

05 Mar '12

#748: cabal update fails ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: HEAD Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- I've installed Haskell Platform 2010.2.0.0 and I cannot make any use of cabal since "cabal update" results in: Config file path source is default config file. Config file C:\Users\suszynsk\AppData\Roaming\cabal\config not found. Writing default configuration to C:\Users\suszynsk\AppData\Roaming\cabal\config Downloading the latest package list from hackage.haskell.org cabal: failed cabal -V returns: cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library I'm using Windows Vista Enterprise GHC ver. 6.12.3 [I was unable to select correct versions of cabal and ghc in this "create new ticket" form] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/748> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #754: cabal should pass extra lib/include dirs to configure scripts
by Hackage 03 Mar '12

03 Mar '12

#754: cabal should pass extra lib/include dirs to configure scripts ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: | ---------------------------------+------------------------------------------ cabal install SDL-gfx with macports has always failed for me, because that package's configure script doesn't know about the required extra lib dir /opt/local/lib. This made it work: LDFLAGS=-L/opt/local/lib cabal install SDL-gfx . cabal-install should probably use this or some other method to tell configure scripts about extra lib and include dirs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/754> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #759: please clarify/document --remote-repo
by Hackage 03 Mar '12

03 Mar '12

#759: please clarify/document --remote-repo ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages. The source code has an undocumented(?) option `--remote-repo` that seems to serve that purpose, but there is little documentation, sometimes conflicting info, about how to put this to use. Mailing list threads: http://www.haskell.org/pipermail/haskell-cafe/2010-November/085860.html http://www.haskell.org/pipermail/haskell-cafe/2010-November/085900.html Repo layout descriptions (differs between hackage 1.0 and 2.0, which is hardcoded in `cabal-install`): http://hackage.haskell.org/trac/hackage/wiki/HackageDB http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0/URIs Related tickets: #758, comment:6:ticket:428 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/759> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #761: could use more options for framework linking on mac
by Hackage 03 Mar '12

03 Mar '12

#761: could use more options for framework linking on mac ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ It seems you can list apple frameworks in a .cabal file like other libs, but I'm not sure how to influence where cabal looks for those frameworks. When trying to link with some in a non-standard place, I wished for an --extra-framework-dirs option. There is a rumoured -framework option, I haven't found much info in --help or online about all this. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/761> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4