June 2011 - cabal-devel

[Hackage] #753: cabal executable chooses different versions of libraries than cabal library
by Hackage 09 Apr '12

09 Apr '12

#753: cabal executable chooses different versions of libraries than cabal library ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Hi, cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library This bug was originally reported by a Debian user. the `cabal' executable, when run on the attached sample library, chooses base 3.0.3.2: $ cabal -v configure [...] Configuring foobar-0.0... Dependency base ==3.0.3.2: using base-3.0.3.2 [...] whereas, the library (via Setup.hs) correctly gets base 4.2.0.0, probably due to ghc's hiding of the earlier version $ runhaskell Setup.hs -v configure Configuring foobar-0.0... Dependency base -any: using base-4.2.0.0 [...] cabal-install should probably perform the same hiding that ghc does. Cheers, Iain -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/753> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #762: cabal-install failed to resolve dependencies
by Hackage 07 Apr '12

07 Apr '12

#762: cabal-install failed to resolve dependencies ---------------------------------+------------------------------------------ Reporter: james_m_chapman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I tried to update my installation of the development version of Agda. I did a darcs pull from the repo (darcs get --lazy http://code.haskell.org/Agda) and then tried to build it: $ darcs pull $ cabal update $ cabal clean $ cabal install I get the following error: "Resolving dependencies... cabal: cannot configure haskeline-0.6.2.2. It requires mtl ==1.1.* For the dependency on mtl ==1.1.* there are these packages: mtl-1.1.0.0, mtl-1.1.0.1, mtl-1.1.0.2 and mtl-1.1.1.0. However none of them are available. mtl-1.1.0.0 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.1 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.2 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.1.0 was excluded because Agda-2.2.9 requires mtl ==2.0.*" Agda's .cabal file is here http://code.haskell.org/Agda/Agda.cabal and contains the build-depends line haskeline >= 0.3 && < 0.7 The solution is to upgrade haskeline to the latest version by running: $ cabal install haskeline Should cabal-install have been able to work this out itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/762> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #782: When building a plan, use installed package dependencies in preference to those from Hackage
by Hackage 07 Apr '12

07 Apr '12

#782: When building a plan, use installed package dependencies in preference to those from Hackage ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I was installing a package, let us call it foo. This package depended on a package foo', which in turn depended on bar, which in turn depended on baz < 0.3, but baz 0.3 was the default that came with the newer version of GHC I had just installed. Thus, I cabal-unpacked bar and bumped the baz dependency to < 0.4, **without changing the baz version number** since this was just a private change. This built and installed just fine with the new baz. I then went back to cabal install foo. I expected that cabal-install would just install foo' and then foo in that order. Instead, it tried to install baz 0.2, then bar, then foo', then foo. This seems stupid because I already had a perfectly acceptable bar installed. Why didn't Cabal just reuse that? It seems as if it is resolving dependencies by looking at the dependency information for bar **from the Hackage database** rather than the dependencies **from the installed bar**. The workaround is to go back to the unpacked bar and bump the version number, then reinstall it. Now when you install foo the installed baz is used as expected. It would be cool if this worked as expected without bumping the version number, because having to bump the version number even if not making a Hackage release is tiresome. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/782> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

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

29 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] #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] #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] #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

[Hackage] #799: ./dist/setup/setup without execute bit causes cabal to exit silently with code 127
by Hackage 05 Mar '12

05 Mar '12

#799: ./dist/setup/setup without execute bit causes cabal to exit silently with code 127 ---------------------------------+------------------------------------------ Reporter: rrnewton | 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 ran into this one thanks to Dropbox. All my cabal commands started to fail in the same way all of a sudden (no output, error code 127). A cabal clean -v3 revealed the problem and a chmod +x fixed it. $ cabal clean -v3; echo $? Using external setup method with build-type Custom Creating ./dist/setup (and its parents) Using Cabal library version 1.8.0.6 Using ./Setup.hs as setup script. ./dist/setup/setup clean --verbose=3 127 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/799> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3