January 2012 - cabal-devel

[Hackage] #690: document extra global options
by Hackage 05 Mar '12

05 Mar '12

#690: document extra global options ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ (split off from comment:1:ticket:688) > We don't list them all [such as --config-file] in the global --help so as not to clutter things, but then we need a way to let people know that there are extra global options and provide a way to get the help for them via some extended --help thing. Should go into a manual instead. You have already copied most of the good parts of the CPAN toolchain, installing man pages along binaries is one of the last things I am missing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/690> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #858: cabal-install needs a manpage
by Hackage 05 Mar '12

05 Mar '12

#858: cabal-install needs a manpage ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The cabal binary shipped by cabal-install ought to be documented with a manage. Ideally, cabal could generate one by itself from the Command declarations, similar to how darcs does it, this way there is no duplication of documentation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/858> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #691: cabal-install broken after update of cabal-install
by Hackage 05 Mar '12

05 Mar '12

#691: cabal-install broken after update of cabal-install ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.8.0.2 Severity: major | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Mac OS | ---------------------------------+------------------------------------------ After I upgraded to a newer cabal-install my cabal-install broke again: I get a Bus Error when doing "cabal update" or "cabal install something". The version that was bundled with the Haskell platform worked fine, but now it's broken again. I'm not sure what it was that went wrong or how to debug this. The previous time I had Bus Errors I upgraded to the newest available Haskell Platform release and started from scratch. I would prefer not to do that again. However, I don't really know how to solve the Bus Error. Does anyone have a clue where to start? Or is there a way to undo my cabal-install upgrade? Here is some info about my system (on OSX 10.6): <pre> ghc -v Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted by GHC version 6.10.4 </pre> <pre> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library </pre> I'm happy to help debugging and willing to test out possible solutions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/691> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #700: seemingly too liberal behaviour on overlapping dependency constraints across packages
by Hackage 05 Mar '12

05 Mar '12

#700: seemingly too liberal behaviour on overlapping dependency constraints across packages ---------------------------------+------------------------------------------ Reporter: kowey | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ There's a high chance this is not actually a bug, but I'm filing one anyway. In http://bugs.darcs.net/isuse1763 we have darcs-2.4 which depends on mmap >= 0.2 and on hashed-storage >= 0.4.7 && < 0.5 The hashed-storage 0.4.x line depends on mmap == 0.4.* The bug in darcs happened when darcs was linked against mmap-0.5 while hashed-storage against mmap-0.4. Is it reasonable to expect that if I depend on a package, that the package can indirectly impose at least soft constraints (on the cabal-install level) on our shared dependencies? Should cabal-install have been smart enough to work out that darcs should actually only pick up mmap 0.4? I think I could be quite happy with "no" -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/700> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #705: Non-deterministic behaviour when overlapping packages are installed
by Hackage 05 Mar '12

05 Mar '12

#705: Non-deterministic behaviour when overlapping packages are installed ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ See [http://stackoverflow.com/questions/3119782/mysterious-cabal-install- problems]. This user took a standard Haskell Platform install, installed a new version of the time package, and then installed random. The random package was rebuilt and installed against the new time package. However, re-running `cabal install random` installs random again; it doesn't reach a fixed point. The problem (I presume) is that when cabal-install merges the package databases it chooses which `random-1.0.0.2` to use non-deterministically. In fact it seems to depend on the exact package Ids, because I get different results with GHC 6.12.2 where the package Ids of the two `random-1.0.0.2` packages are ordered differently. I realise there are larger issues about how to do resolution here, but I think at least we should make cabal-install deterministic, and preferably idempotent. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/705> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #707: cabal-install config setting "documentation: True" ignores base library dependency
by Hackage 05 Mar '12

05 Mar '12

#707: cabal-install config setting "documentation: True" ignores base library dependency ---------------------------------+------------------------------------------ Reporter: KiYungAhn | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: cabal-install, link, dependency, documentation Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I use "documentation: True" setting in the cabal-install config file (in linux $HOME/.cabal/config) since I prefer to install documentation locally with the library, and recently found out that this ignores the base library version in the .cabal files. I am not sure about whether they ignore other libraries but for base it is for sure. Even though the package cabal file specifies base >= 4 the cabal-install seems to revert back to base version 3 when I use "documentation: True" in the config file. In particular, I found this bug when I was working with the RepLib package. I had a link error when I was using the "documentation: True" option in the config, but when I commented that out and worked with the default config file everything worked. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/707> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[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