September 2010 - cabal-devel

[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

[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] #725: Distinguish speculative and required build-depends upper bound
by Hackage 03 Mar '12

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

05 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 05 Jan '12

05 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 05 Jan '12

05 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

[Hackage] #671: better error message for broken build tools
by Hackage 05 Jan '12

05 Jan '12

#671: better error message for broken build tools ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Consider: {{{ Configuring haskell-src-exts-1.9.0... setup: happy version >=1.17 is required but the version of /usr/local/bin/happy could not be determined. }}} The actual problem is: {{{ /usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/671> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2