November 2010 - cabal-devel

[Hackage] #748: cabal update fails
by Hackage 05 Mar '12

05 Mar '12

#748: cabal update fails ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: HEAD Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- I've installed Haskell Platform 2010.2.0.0 and I cannot make any use of cabal since "cabal update" results in: Config file path source is default config file. Config file C:\Users\suszynsk\AppData\Roaming\cabal\config not found. Writing default configuration to C:\Users\suszynsk\AppData\Roaming\cabal\config Downloading the latest package list from hackage.haskell.org cabal: failed cabal -V returns: cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library I'm using Windows Vista Enterprise GHC ver. 6.12.3 [I was unable to select correct versions of cabal and ghc in this "create new ticket" form] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/748> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #754: cabal should pass extra lib/include dirs to configure scripts
by Hackage 04 Mar '12

04 Mar '12

#754: cabal should pass extra lib/include dirs to configure scripts ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: | ---------------------------------+------------------------------------------ cabal install SDL-gfx with macports has always failed for me, because that package's configure script doesn't know about the required extra lib dir /opt/local/lib. This made it work: LDFLAGS=-L/opt/local/lib cabal install SDL-gfx . cabal-install should probably use this or some other method to tell configure scripts about extra lib and include dirs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/754> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #759: please clarify/document --remote-repo
by Hackage 04 Mar '12

04 Mar '12

#759: please clarify/document --remote-repo ---------------------------------+------------------------------------------ Reporter: claus | 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 often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages. The source code has an undocumented(?) option `--remote-repo` that seems to serve that purpose, but there is little documentation, sometimes conflicting info, about how to put this to use. Mailing list threads: http://www.haskell.org/pipermail/haskell-cafe/2010-November/085860.html http://www.haskell.org/pipermail/haskell-cafe/2010-November/085900.html Repo layout descriptions (differs between hackage 1.0 and 2.0, which is hardcoded in `cabal-install`): http://hackage.haskell.org/trac/hackage/wiki/HackageDB http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0/URIs Related tickets: #758, comment:6:ticket:428 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/759> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #761: could use more options for framework linking on mac
by Hackage 04 Mar '12

04 Mar '12

#761: could use more options for framework linking on mac ---------------------------------+------------------------------------------ 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: Mac OS | ---------------------------------+------------------------------------------ It seems you can list apple frameworks in a .cabal file like other libs, but I'm not sure how to influence where cabal looks for those frameworks. When trying to link with some in a non-standard place, I wished for an --extra-framework-dirs option. There is a rumoured -framework option, I haven't found much info in --help or online about all this. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/761> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #755: high verbosity should make configure verbose as well ?
by Hackage 04 Mar '12

04 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 04 Mar '12

04 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 04 Mar '12

04 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] #667: Improve tools to manage ad-hoc package releases
by Hackage 06 Jan '12

06 Jan '12

#667: Improve tools to manage ad-hoc package releases ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases. For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality. It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks. One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run: {{{ cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix- blah-1.0.1.tar.gz }}} This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks. In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers. Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package "search path" promoted by the searchpath project (http://searchpath.org/) Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/667> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #724: Add getDataDirectory function to Paths_pkgname
by Hackage 06 Jan '12

06 Jan '12

#724: Add getDataDirectory function to Paths_pkgname ----------------------------+----------------------------------------------- Reporter: tommd | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Some libraries and programs have a large number of files. Instead of having explicit knowledge of each file (and instead of using a mutation on the result of getDataFilename) there should be a "getDataDirectory" or a "getDataDirectoryContents": getDataDirectoryContents = getDataDirectory >>= getDirectoryContents -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/724> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #739: cabal install regression with GHC HEAD - ghc-paths
by Hackage 06 Jan '12

06 Jan '12

#739: cabal install regression with GHC HEAD - ghc-paths ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- with the Cabal library installed with GHC 6.13.20100911 I can no longer install the package ghc-paths-0.1.0.6 In 'ghci Setup.hs' I get the error: Setup.hs:41:25: Ambiguous occurrence `None' It could refer to either `Distribution.Simple.Setup.None', imported from Distribution.Simple.Setup at Setup.hs:2:1-32 or `Pkg.None', imported from Distribution.Simple.PackageIndex at Setup.hs:7:1-46 It looks like the 'None' constructor didn't exist in Distribution.Simple.Setup in Cabal 1.8.x. While we can't guarantee that an added constructor doesn't conflict with data declarations used in every Setup.hs, it seems in poor form to export the same constructor in two types in the same library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/739> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4