October 2010 - cabal-devel

[Hackage] #673: cabal init: fail gracefully if bogus files are found during recursive search for source code
by Hackage 05 Mar '12

05 Mar '12

#673: cabal init: fail gracefully if bogus files are found during recursive search for source code ---------------------------------+------------------------------------------ Reporter: byorgey | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: init, search, file, crash Difficulty: easy (<4 hours) | Ghcversion: 6.12.1 Platform: Mac OS | ---------------------------------+------------------------------------------ cabal init does a recursive search looking for things that look like Haskell modules to be added to the exports list. The following error messages were reported by Ivan Miljenovic: {{{ cabal: /scratch/ghc-6.12.1/distrib/installer-scripts/MacOS: does not exist cabal: /tmp/pulse-a7kaqGHss6Yh/native: inappropriate type }}} Not sure exactly what causes these errors, but in any case cabal init should not crash. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/673> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #681: cabal-install init should not overwrite files without good reason
by Hackage 05 Mar '12

05 Mar '12

#681: cabal-install init should not overwrite files without good reason ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If you run "cabal init" in a directory with an already existing .cabal file, it will happily overwrite the old version without asking you. It should detect that a file exists and ask you before writing it out (or even prompting you for info). Alternatively, it could fill up it's defaults using the existing .cabal file. Furthermore, if you pass -n for non-interactive mode, cabal can't ask whether or not the user wanted to overwrite, so probably adding a --force flag is in order. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/681> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #682: 'cabal init' should try to set 'main-is' for executables
by Hackage 05 Mar '12

05 Mar '12

#682: 'cabal init' should try to set 'main-is' for executables ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently, `cabal init` will find modules and add them to the `exposed- modules` of a library. It should try to do something similar for executables. The `main-is` field is required for executables and any `other-modules` also need to be listed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/682> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #685: cabal install does not work in /tmp/
by Hackage 05 Mar '12

05 Mar '12

#685: cabal install does not work in /tmp/ ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Wanting to to build darcs 2.4.3, I downloaded the tarball ( http://wiki.darcs.net/Releases/2.4 ) and uncompressed it in /tmp/ to run cabal install. I got the following error : cabal: Error: some packages failed to install: darcs-2.4.3 failed during the configure step. The exception was: ExitFailure 127 See http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25412#a25412 for a full verbose log, but i think there is nothing informative to it. However, if I do "rm -fr dist" and try cabal install again, darcs build fine. Also, if I try in $HOME, cabal install works directly. Here are the versions of the software I'm using: cabal-install version 0.8.2 using version 1.8.0.4 of the Cabal library ghc 6.12.1 Linux distribution: Ubuntu 10.04 (Lucid Lynx). I hope this will help you! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/685> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #686: cabal install - Codec.Compression.Zlib: incorrect header check
by Hackage 05 Mar '12

05 Mar '12

#686: cabal install - Codec.Compression.Zlib: incorrect header check ---------------------------------+------------------------------------------ Reporter: Monsikos | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Zlib Difficulty: unknown | Ghcversion: 6.12.1 Platform: Windows | ---------------------------------+------------------------------------------ The command "cabal install packagename" fails with : "Codec.Compression.Zlib: incorret header check". The message appears while trying to extract the tar.gz file. I have manually updated Cabal (1.8.0.2), cabal-install(0.8.2) and zlib(0.5.2.0) but the error remains. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/686> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 12

[Hackage] #688: hard-coded path to configuration file
by Hackage 05 Mar '12

05 Mar '12

#688: hard-coded path to configuration file ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ I want to be able to tell {{{cabal}}} to read the configuration from a different place than {{{$HOME/.cabal/config}}}. The ultimate goal is to get rid of the non-standard {{{.cabal}}} directory altogether, so far careful {{{--package-db}}}/{{{--prefix}}} etc. juggling served me well; {{{config}}} is the last remaining file there. {{{ > cabal --version cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/688> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

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