December 2011 - cabal-devel

[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

[Hackage] #755: high verbosity should make configure verbose as well ?
by Hackage 03 Mar '12

03 Mar '12

#755: high verbosity should make configure verbose as well ? ---------------------------------+------------------------------------------ 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: | ---------------------------------+------------------------------------------ Even with -v 3, configure scripts run at normal verbosity which is often not enough to debug the problem. AFAIK you have to unpack the package, install/configure again and inspect config.log. If possible it would be convenient to have -v2 or -v3 tell configure to print the full log on stdout. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/755> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #725: Distinguish speculative and required build-depends upper bound
by Hackage 03 Mar '12

03 Mar '12

#725: Distinguish speculative and required build-depends upper bound ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ When a package adds a build-dependency on another package, it's good form to follow the Package Versioning Policy and add a speculative upper bound that is x.(y+1), if the current version is x.y. This is great, but in many cases the next version will /not/ break compatibility with your package. In that case, once you have tested that the dependency is fine, you can bump the upper bound. As the list of dependencies for any respectable Cabal package can be quite long, it may be useful to have some sort of 'cabal whatsnew' command which checks the upper bounds of your build dependencies and notifies you when there are newer versions than your upper bounds availble. Furthermore, there should be a mechanism for telling Cabal that the upper bound is required, and that the package will break if you try to bump it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/725> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #768: Cabal cannot find GHC when using relative path in -w flag
by Hackage 03 Mar '12

03 Mar '12

#768: Cabal cannot find GHC when using relative path in -w flag ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Trying to build the network package while standing at the root of a GHC build tree fails to find GHC: {{{ $ cabal install -w inplace/bin/ghc-stage2 network -v2 inplace/bin/ghc-stage2 --numeric-version looking for package tool: ghc-pkg near compiler in inplace/bin found package tool in inplace/bin/ghc-pkg inplace/bin/ghc-pkg --version inplace/bin/ghc-stage2 --supported-languages Reading installed packages... inplace/bin/ghc-pkg dump --global inplace/bin/ghc-pkg dump --user inplace/bin/ghc-stage2 --print-libdir Reading available packages... Resolving dependencies... selecting network-2.3 (hackage) and discarding network-2.0, 2.1.0.0, 2.2.0.0, 2.2.0.1, 2.2.1, 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7, 2.2.1.8, 2.2.1.9, 2.2.1.10, 2.2.3 and 2.2.3.1 selecting base-4.3.0.0 (installed) selecting ffi-1.0 (installed) selecting ghc-prim-0.2.0.0 (installed) selecting integer-gmp-0.2.0.2 (installed) selecting rts-1.0 (installed) selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0 selecting unix-2.4.1.0 (installed) and discarding unix-2.0, 2.2.0.0, 2.3.0.0, 2.3.1.0, 2.3.2.0, 2.4.0.0, 2.4.0.1 and 2.4.0.2 selecting bytestring-0.9.1.8 (installed) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3, 0.9.1.4, 0.9.1.5, 0.9.1.6 and 0.9.1.7 In order, the following would be installed: parsec-2.1.0.1 (new package) network-2.3 (new package) parsec-2.1.0.1 has already been downloaded. Extracting /home/tibell/.cabal/packages/hackage.haskell.org/parsec/2.1.0.1/parsec-2.1.0.1.tar.gz to /tmp/parsec-2.1.0.117969... Configuring parsec-2.1.0.1... cabal: Cannot find the program 'ghc' at 'inplace/bin/ghc-stage2' or on the path cabal: Error: some packages failed to install: network-2.3 depends on parsec-2.1.0.1 which failed to install. parsec-2.1.0.1 failed during the configure step. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/768> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #781: cabal list should have --with-compiler, --user, --global and --package-db flags
by Hackage 03 Mar '12

03 Mar '12

#781: cabal list should have --with-compiler, --user, --global and --package-db flags ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal list` is lacking a way to control which compiler and package databases are queried. See also ticket #457 about enhanced filtering for `cabal list` -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/781> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #809: Improve update performance
by Hackage 03 Mar '12

03 Mar '12

#809: Improve update performance ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I have an automated package build set up using Hudson, and it tries to build my code as often as once every 5 minutes. Right now, that means running cabal update before every build, which takes at least 30 seconds. It would be great if cabal update used the ETag and If-Modified-Since HTTP headers to do conditional fetches of the metadata, so that there would be far less of a performance hit to both the Hackage server and my client. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/809> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2