March 2012 - cabal-devel

[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

[Hackage] #732: Implement opt-in for anonymous build reporting
by Hackage 05 Mar '12

05 Mar '12

#732: Implement opt-in for anonymous build reporting ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ We want people to send in anonymous build reports. We also want to respect people's privacy. The suggestion is that we should use an opt-in system but make it very easy to opt in. Currently most users have a config file that contains no value set for the config file fields that control the build reporting feature. The suggestion is that when the build reporting config items are not set then we should interactively prompt users like so: {{{ $ cabal update Cabal can send build reports back to to the package server. Build reporting helps to improve package quality. The information sent back is minimal and it does not identify your computer. For more details see: http://haskell.org/cabal/reporting Enable automatic anonymous reporting of package builds? [y/n/?] Downloading the latest package list from hackage.haskell.org }}} We would then rewrite the config file with the updated setting, either on or off. That will require that we correctly preserve settings and comments in the config file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/732> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #745: cabal-install sometimes gives empty build-log and no build-summary
by Hackage 05 Mar '12

05 Mar '12

#745: cabal-install sometimes gives empty build-log and no build-summary ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Building `NaturalSort-0.2.1` with GHC 7.0.1 RC 1: {{{ $ cabal install --build-summary=log.bs --build-log=log.bl Resolving dependencies... Warning: NaturalSort.cabal: This package requires Cabal version: >=1.6 && <1.9 cabal: Error: some packages failed to install: NaturalSort-0.2.1 failed during the configure step. The exception was: user error (The package requires Cabal library version -any && >=1.6 && <1.9 but no suitable version is installed.) $ cat log.bs cat: log.bs: No such file or directory $ cat log.bl $ }}} I would like the build log to contain the error. I have {{{ $ cabal --version cabal-install version 0.9.2 using version 1.9.2 of the Cabal library }}} but this is not a released version; if nothing else, I have the #697 patch applied. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/745> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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 03 Mar '12

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

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

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

03 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

Re: [Hackage] #474: cabal-install needlessly reinstalls an existing package
by Hackage 03 Mar '12

03 Mar '12

#474: cabal-install needlessly reinstalls an existing package ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * milestone: cabal-install-0.8 => cabal-install-0.14 Comment: Probably hard to reproduce now, but if it's not already fixed in the topdown solver, I would at least expect the modular solver to be able to handle this properly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/474#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0