January 2012 - cabal-devel

[Hackage] #731: Custom Build-type with --package-db and --global encounters runtime error
by Hackage 28 Mar '12

28 Mar '12

#731: Custom Build-type with --package-db and --global encounters runtime error ---------------------------------+------------------------------------------ Reporter: cygnus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.2 Platform: Linux | ---------------------------------+------------------------------------------ To reproduce: * Run `cabal init`, change `Build-type` to `Custom` (`Setup.hs` already provided by `cabal init`) * Run `ghc-pkg init db` * Run `cabal configure --package-db=./db --global` * Output: {{{ Resolving dependencies... cabal: internal error: unexpected package db stack }}} In `cabal-install-0.8.2`, this appears to be caused by the code on lines 112-114 of `Distribution.Client.Configure`: {{{ usePackageDB = if UserPackageDB `elem` packageDBs then packageDBs else packageDBs ++ [UserPackageDB] }}} in combination with the code on lines 297-306 of `Distribution.Client.SetupWrapper`: {{{ ghcPackageDbOptions :: PackageDBStack -> [String] ghcPackageDbOptions dbstack = case dbstack of (GlobalPackageDB:UserPackageDB:dbs) -> concatMap specific dbs (GlobalPackageDB:dbs) -> "-no-user-package-conf" : concatMap specific dbs _ -> ierror where specific (SpecificPackageDB db) = [ "-package-conf", db ] specific _ = ierror ierror = error "internal error: unexpected package db stack" }}} Essentially, the order of the package databases in the stack is not as expected since the list already contains a `SpecificPackageDB` when the `UserPackageDB` is appended. (Note: this applies to GHC 6.12.3 and Cabal 1.8.0.6 on my system, but I could not select those versions in the ticket properties.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/731> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #807: inplace is shadowed by package
by Hackage 15 Mar '12

15 Mar '12

#807: inplace is shadowed by package ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: test Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a library, persistent, that builds. When I try to build the test suite, I get: {{{ Preprocessing library persistent-0.4.0.1... Preprocessing test suites for persistent-0.4.0.1... Building persistent-0.4.0.1... Registering persistent-0.4.0.1... <command line>: cannot satisfy -package-id persistent-0.4.0.1-inplace: persistent-0.4.0.1-inplace is shadowed by package persistent-0.4.0.1-f5ffa1e952f5d8b58608c8d1f9f69825 (use -v for more information) }}} The test-suite build-depends has: {{{ persistent >= 0.4.0.1, persistent-mongoDB, persistent-postgresql, persistent-sqlite, }}} persistent-mongoDB (and postgresql and sqlite) depends on persistent to build. I have tried this twice now from a fairly clean install- immediately after upgrading to a new version of ghc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/807> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #896: cabal install cabal-install fails if gcc not in /Developer/usr/bin/gcc
by Hackage 11 Mar '12

11 Mar '12

#896: cabal install cabal-install fails if gcc not in /Developer/usr/bin/gcc ---------------------------------+------------------------------------------ Reporter: jeremyw.sherman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ Under Mac OS X, `cabal` assumes `gcc` is at `/Developer/usr/bin/gcc`. This fails when Xcode is installed to another directory. Xcode has supported installing to an arbitrary folder since at least Xcode 3.x. This is particularly common among iOS developers, as they frequently require multiple parallel Xcode installs. Since Xcode installs gcc to both `$DEVELOPER/usr/bin/gcc` and `/usr/bin/gcc`, this could be fixed by using `/usr/bin/gcc` directly or the result of a search in `$PATH` for `gcc`. The user workaround for now is to symlink `/Xcode_4_2` (or whatever the user's latest Xcode install directory is) to `/Developer`. (Apple is moving from `gcc` to `clang`, anyway. Apple's `gcc` has been frozen at an ancient version for some time now.) Sample session exhibiting this bug: {{{ $ cabal install cabal-install Resolving dependencies... Configuring cabal-install-0.10.2... ghc: could not execute: /Developer/usr/bin/gcc cabal: Error: some packages failed to install: cabal-install-0.10.2 failed during the configure step. The exception was: ExitFailure 1 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library $ which gcc /usr/bin/gcc $ which clang /usr/bin/clang $ ls -l `which gcc` lrwxr-xr-x 1 root wheel 12 13 Okt 15:37 /usr/bin/gcc@ -> llvm-gcc-4.2 $ ls -l `which clang` -rwxrwxr-x 1 root admin 41251344 27 Aug 03:53 /usr/bin/clang* $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.3 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/896> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #842: cabal appears to complain about relative paths
by Hackage 10 Mar '12

10 Mar '12

#842: cabal appears to complain about relative paths ---------------------------------+------------------------------------------ Reporter: jeffz | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ With `cabal configure --extra-lib-dirs=foo` $ cabal build Preprocessing library HENet-0.0.1... Building HENet-0.0.1... Registering HENet-0.0.1... cabal.exe: HENet-0.0.1: library-dirs: .libs is a relative path (use --force to override) Originally reported on irc: <dcoutts> jeffz: the right solution here would be for cabal to make the paths absolute before passing them on to ghc-pkg -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/842> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #908: Error installing base
by Hackage 08 Mar '12

08 Mar '12

#908: Error installing base ----------------------------+----------------------------------------------- Reporter: mcandre | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Specs: {{{ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 10.04.3 LTS Release: 10.04 Codename: lucid $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} Trace: {{{ $ sudo cabal install base Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:169:37-73: Non-exhaustive patterns in lambda }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/908> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #910: per-package configuration
by Hackage 06 Mar '12

06 Mar '12

#910: per-package configuration ---------------------------------+------------------------------------------ Reporter: kowey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ This may be related to #223 but I don't particularly want it in my global config. I'm sick of running "cabal build" and not noticing until much later that my test had a compile error because I'd neglected to reconfigure with "--enable-test". A similar issue happens with packages with custom flags, say sometimes I lose the "-f-library" flag I sometimes use for faster compilation. I wish I had a mechanism to remember the command line flags passed in for a particular package. Editing my global config doesn't seem quite like what I'm looking for; it has to be something that works, eg. with different branches of the same package. What might be better for me is something like the Darcs prefs system, where I could edit a file in the current working directory like ".cabal" that says something like {{{ configure --enable-test -f-library install -fgui }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/910> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #675: template-haskell cannot be upgraded (broken data-accessor-template)
by Hackage 05 Mar '12

05 Mar '12

#675: template-haskell cannot be upgraded (broken data-accessor-template) ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: | ---------------------------------+------------------------------------------ data-accessor-template-0.2.1.3 has flags in the cabal file on template- haskell versions, which makes it broken for cabal-install on ghc-6.12: cabal-install tries to install template-haskell-2.3, which fails (and it can't be expected to succeed because TH is integrated into ghc due to quotes) You can work around the build failure with: {{{ cabal install data-accessor-template --constraint='template-haskell >= 2.4' }}} cabal-install ought to know that template-haskell isn't something it should install (as it does with base). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/675> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #822: world-file does not support $arch, $os, $compiler
by Hackage 05 Mar '12

05 Mar '12

#822: world-file does not support $arch, $os, $compiler ---------------------------------+------------------------------------------ Reporter: josh | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ In my ~/.cabal/config, I have: install-dirs user prefix: /home/josh/.cabal/install/$arch-$os-$compiler This allows packages for multiple architectures (such as 32-bit and 64-bit) or multiple compilers (such as ghc6 and ghc7) to coexist. It also ensures that after upgrading the compiler, old libraries that won't work automatically disappear. Recent cabal added a "world" file, under ~/.cabal/world. I tried to move this to the same directory, by adding: world-file: /home/josh/.cabal/install/$arch-$os-$compiler/world However, this generated the following error: Error while Error while updating world-file. : /home/josh/.cabal/install/$arch-$os-$compiler/: openNewBinaryFile: does not exist (No such file or directory) From this, I'd guess that cabal doesn't support those variables in world- file like it does in prefix. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/822> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #889: Add option to list recursive dependencies of a package along with their licenses
by Hackage 05 Mar '12

05 Mar '12

#889: Add option to list recursive dependencies of a package along with their licenses ---------------------------------+------------------------------------------ Reporter: joeyadams | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ It should be possible to list all of the dependencies of a package, including their licenses. This would be useful for: * Developers writing proprietary applications. * Developers who don't want their liberally-licensed libraries to be "upgraded" to the GPL or similar by subtle dependencies. Attached is a simple patch that makes cabal-install list this information when the verbosity level is 2 or higher. Sample usage: {{{ $ cabal install --verbose=2 --dry-run gnutls Reading available packages... Resolving dependencies... base BSD3 bytestring BSD3 ffi BSD3 ghc-prim BSD3 gnutls GPL (Just (Version {versionBranch = [3], versionTags = []})) integer-gmp BSD3 monads-tf BSD3 rts BSD3 transformers BSD3 In order, the following would be installed: monads-tf-0.1.0.0 (new package) gnutls-0.1 (new package) }}} This is a quick hack, as I am not familiar with the Cabal codebase. This should probably be wrapped as a {{{--list-licenses}}} command line switch. Pretty-printing licenses would be a plus. I am already finding this feature useful, and hope others will too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/889> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #665: Confusion situation when linking ./dist/setup/setup is interrupted
by Hackage 05 Mar '12

05 Mar '12

#665: Confusion situation when linking ./dist/setup/setup is interrupted ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If one accidentally interrupts cabal when it's linking `./dist/setup/setup` then you can end up with the file existing it not being executable. This leads to a confusing situation for the user. Running `cabal install` or `cabal configure` will fail silently. Running with -v indicates that something returns exit code 127. This corresponds to a permission error when trying to execute `./dist/setup/setup` Two improvements could be made: * Report the failure to execute `./dist/setup/setup` * If ghc is interrupted when creating `./dist/setup/setup`, cabal should delete the file, if it exists. That way, cabal will recompile on the next invocation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/665> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2