October 2011 - cabal-devel

[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

[Hackage] #818: cabal sdist warns about optimization levels
by Hackage 03 Mar '12

03 Mar '12

#818: cabal sdist warns about optimization levels ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ For some reason 'cabal sdist' dislikes fast code so much that it tells me not to use -O2. What does it know about my needs and my project? See below for an example: {{{ $ cabal sdist Distribution quality warnings: 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. }}} Is there a way to disable this warning in my .cabal file? If not, can the warning please be removed? It doesn't seems appropriate for sdist to tell me which compiler flags I should use to optimize my code. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/818> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #820: cabal-install clobbers itself on multi-arch platforms
by Hackage 03 Mar '12

03 Mar '12

#820: cabal-install clobbers itself on multi-arch platforms ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ On my Mac, I have 32-bit and 64-bit versions of GHC 7.0.2 installed, and cabal installs the object and interface files into the same directory. The {{{$arch}}} variable looks like it should do the right thing, but in fact it's expanded to whatever architecture cabal-install was built for, not the architecture that's supported by GHC itself. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/820> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #804: support remote .cabal files in cabal info
by Hackage 03 Mar '12

03 Mar '12

#804: support remote .cabal files in cabal info ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently, `cabal info` supports local .cabal files and remote tarballs, but not remote .cabal files. The [http://hackage.haskell.org/package/lscabal lscabal] program supports remote .cabal file target like: {{{ $ lscabal http://code.haskell.org/xmonad/xmonad.cabal XMonad XMonad.Main }}} Is this useful? Presumably it would also need a more general query language to pull out the fields that the user is interested in. Note that `lscabal` only lists exposed modules and only unconditional ones (e.g. not ones that are platform dependent). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/804> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #834: cabal should detect case errors in build-depends:
by Hackage 03 Mar '12

03 Mar '12

#834: cabal should detect case errors in build-depends: ---------------------------------+------------------------------------------ Reporter: cmh | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ for example, with a foo.cabal file containing: build depends: http >= 4000 Resolving dependencies... cabal: cannot configure foo-0.0.1. It requires http >=4000 There is no available version of http that satisfies >=4000 The solution is of course to specify HTTP, but the user may be led to believe that there is a version problem, which is confusing. Perhaps a message such as - "Did you mean package HTTP" - Would be appropriate. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/834> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #849: [PATCH] Store licenses in text files instead of code.
by Hackage 03 Mar '12

03 Mar '12

#849: [PATCH] Store licenses in text files instead of code. ----------------------------+----------------------------------------------- Reporter: refold | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- This shaves 300 KiB off the final executable size and makes it slightly easier to add new license types (just drop the text file under %SRCDIR%/licenses and modify the 'licenseFile' function in Distribution.Client.Init.hs). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/849> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9