August 2009 - cabal-devel

[Hackage] #532: Can't find libraries on Windows (Cabal 1.6.0.2)
by Hackage 27 Mar '10

27 Mar '10

#532: Can't find libraries on Windows (Cabal 1.6.0.2) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- When trying to install the com-1.2.2 package from the Hackage tarball, configure reports that it cannot find the header file "include/WideStringSrc.h", which is part of the com-1.2.2 source, and is clearly there; and that it cannot find the libraries "kernel32", "user32", etc which are standard system libraries (the corresponding .lib files are part of the Platform SDK), even after giving it the library paths in every possible way (environment variable, command line option, modifying the "com.cabal" file). The former problem was mysteriously eliminated by some random modification of the .cabal file (namely, rearranging the order of the includes). The OS is Windows XP (servicepack 2). Everything works fine with Cabal 1.6.0.1. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/532> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #465: default global install on windows is a problem
by Hackage 21 Mar '10

21 Mar '10

#465: default global install on windows is a problem ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Windows | ----------------------------+----------------------------------------------- Lots of windows users have problems installing things globally. Some are using multi-user systems. More are using Vista where it seems that even when they are running as administrator they cannot install files in `C:\Program Files\`. We should revisit the decision to install globally and see if we cannot find a default that works better. Failing by default is bad. We may also want to try to improve the checking beforehand to check if we would have permissions to write into the target directories. If not we can fail at configure time rather than waiting until install time and failing ungracefully. This needs someone who knows and cares about windows. Particularly for the Vista aspects. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/465> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #251: link to the latest version of a package tar file
by Hackage 20 Mar '10

20 Mar '10

#251: link to the latest version of a package tar file ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Dan Corson suggests: it would be good to have links to latest versions of a package file available for download. for example: something like {{{ http://hackage.haskell.org/packages/archive/arrows/latest.tar.gz }}} would be a link to {{{ http://hackage.haskell.org/packages/archive/arrows/0.4/arrows-0.4.tar.gz }}} this would greatly simplify automating installs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/251> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

[Hackage] #520: Use nice Unicode characters for inequalities
by Hackage 20 Mar '10

20 Mar '10

#520: Use nice Unicode characters for inequalities ----------------------------------+----------------------------------------- Reporter: Porges | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- This is a terribly minor request, but it would make the display nicer :) In dependency restrictions, instead of displaying (>=), (<=), use (≥), (≤). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/520> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #570: Include distributions status on package page
by Hackage 19 Mar '10

19 Mar '10

#570: Include distributions status on package page --------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: patch Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Hi, I would find it very helpful if the package pages on hackage would include information as to which packages are available in distributions (Debian, arch, gentoo...). I have implemented a patch that reads this information from a simple formatted text and displays it. I have also implemented the generation of the list for Debian at http://people.debian.org/~nomeata/cabalDebianMap.txt, see README. A cronjob should fetch this regularly (maybe 4 times a day). To add distributions, you need to create the appropriate list (URLs are optional), add the distribution name to DistroMap.hs and put the lists in the right location. It would be great if this could be deployed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/570> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 23

[Hackage] #526: hugs-options aren't passed to ffihugs
by Hackage 19 Mar '10

19 Mar '10

#526: hugs-options aren't passed to ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Options in hugs-options aren't passed through to ffihugs, most importantly -98 and +o are the ones we'd like to pass. For enabling the +o flag Hugs-Sept06 does not honor: * pragma {-# LANGUAGE !OverlappingInstances #-} * pragma {-# OPTIONS_HUGS +o #-} * cabal extensions: !OverlappingInstances And the -98 flag has similar issues. Therefore this is a real problem. Immediate solution: The options set in hugs-options should be passed to ffihugs as well. As of Cabal 1.6 they are not passed (verified by Duncan Coutts). The two programs accept all the same options, so this is valid. Ideal solution: Based on the extensions field, Cabal should automatically determine whether -98 and +o need to be enabled (for both hugs and ffihugs). A simple example demonstrating this bug can be found in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/526> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #527: CPP not called before ffihugs
by Hackage 19 Mar '10

19 Mar '10

#527: CPP not called before ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When building for Hugs, if CPP is being used in conjunction with FFI, then cpp/cpphs is not called before ffihugs is called. Thus, users must pass an -F flag to ffihugs in order to declare a code filter (and must pass all cpp-options to -F manually). For example: {{{ --ffihugs-option=-F'cpp -P -traditional -D__HUGS__ -D__BLAH__' }}} This requires duplicating the build specifications, which defeats the point of Cabal. Also it leads to tricky issues about ensuring the proper level of quoting/escaping. (e.g. using the plural, --ffihugs-options=..., breaks it. Wrapping the -F'cpp...' in double quotes breaks it.) A simple example of this bug can be seen in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/527> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #284: Cannot upload packages that require specific cabal versions
by Hackage 19 Mar '10

19 Mar '10

#284: Cannot upload packages that require specific cabal versions --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- I have a package that requires a custom Setup.lhs.The package works for ghc 6.8.x and 6.6.x and, thus, the Setup.lhs script was designed to work with Cabal 1.2.x, the one that comes with ghc 6.8.x. This is clearly indicated in the cabal-version field. However, if I try to upload this package to hackage I get this error: {{{ hint-0.2.0.1/hint.cabal: This package requires Cabal version: >=1.2&&<1.3 }}} As a workaround I used cabal-version: >= 1.2 but now, although the description explicitly says that it works with ghc 6.8.x, hackage indicates that it fails to build. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/284> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #576: Show reverse dependencies
by Hackage 16 Mar '10

16 Mar '10

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide exmaples or documentation. It could be very helpful to look at packages which use the package on is interested in. This can be made easier if every package on http://hackage.haskell.org/ displays which other packages depend on it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11