- cabal-devel - Haskell.org

darcs patch: Naive implementation of 'cabal check'
by Lennart Kolmodin 21 Feb '08

21 Feb '08

Thu Feb 21 21:48:20 CET 2008 Lennart Kolmodin <kolmodin(a)gentoo.org> * Naive implementation of 'cabal check' A naive implementation of 'cabal check'. It will list the errors and warnings as implemented by Cabal, yielding them in groups of severity. Currently ignores verbosity levels, no additional arguments are understood. This addresses ticket #211.

1 0

Re: [Hackage] #56: hackageDB should not accept a package if it is not installable
by Hackage 21 Feb '08

21 Feb '08

#56: hackageDB should not accept a package if it is not installable --------------------------------+------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux --------------------------------+------------------------------------------- Comment (by duncan): An example we could automatically discover: AutoForms-0.4 requires syb-with-class>=0.4 but the latest version of syb- with-class in hackage at the moment is 0.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/56#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): more import/qualified name hints to help nhc98
by Malcolm Wallace 21 Feb '08

21 Feb '08

Thu Feb 21 08:27:00 PST 2008 Malcolm.Wallace(a)cs.york.ac.uk * more import/qualified name hints to help nhc98 M ./Distribution/Simple/Configure.hs -1 +1 M ./Distribution/Simple/Haddock.hs -11 +11 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080221162700-6871e-ffa2c4a0…

1 0

Disable optimization
by Henning Thielemann 21 Feb '08

21 Feb '08

I have upgraded to Cabal 1.2 while still using GHC-6.4.1. In the Haskore project there is the module NewResolutions.lhs which let GHC run into extensive swapping (certainly due to excessive memory consumption) on compilation when compiled with optimization. One can say, it cannot be compiled this way. This is clearly a compiler bug, but upgrading the compiler is not an option here. Thus I used unoptimized compilation so far. Now, Cabal 1.2 seems to have optimization set by default. While it was easy to add optimization by using 'GHC-Options' field it is not obvious how to override Cabal defaults. I don't think it was a good idea to switch on optimization silently from one Cabal version to another one. It would have been better to let people configure Cabal globally and manually to use optimization.

5 7

[Hackage] #222: Hackage should be able to track which version of package is compatible with which version of GHC
by Hackage 20 Feb '08

20 Feb '08

#222: Hackage should be able to track which version of package is compatible with which version of GHC --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | --------------------------------+------------------------------------------- This is related to ticket #221 and #199. Cabal-install at this time always fetches the highest version of a package. But the highest version may not be compatible with the version of GHC. The example is the HXT package. http://www.fh-wedel.de/~si/HXmlToolbox/ As of this writing, version 7.4 is for GHC 6.8. But for those who have GHC 6.6, version 7.3 should be fetched. If there is a flag in Hackage to indicate this compatibility matrix, then cabal-install can make correct decision which version to fetch based on the GHC version the user has. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/222> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-install): Replace RepoIndex type with PackageIndex PkgInfo
by Duncan Coutts 20 Feb '08

20 Feb '08

Wed Feb 20 13:28:48 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Replace RepoIndex type with PackageIndex PkgInfo and adapt to the minor finalisePackageDescription change M ./Hackage/Dependency.hs -25 +30 M ./Hackage/Fetch.hs -2 +1 M ./Hackage/IndexUtils.hs -12 +63 M ./Hackage/Info.hs -2 +1 M ./Hackage/Install.hs -3 +2 M ./Hackage/List.hs -4 +5 R ./Hackage/RepoIndex.hs M ./Hackage/Types.hs +3 M ./Hackage/Upgrade.hs -2 +2 M ./cabal-install.cabal -1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080220212848-adfee-…

1 0

patch applied (cabal): Use PackageIndex in finalisePackageDescription
by Duncan Coutts 20 Feb '08

20 Feb '08

Wed Feb 20 13:27:41 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use PackageIndex in finalisePackageDescription rather than [PackageIdentifier] M ./Distribution/PackageDescription/Configuration.hs -16 +7 M ./Distribution/Simple/Configure.hs -12 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080220212741-adfee-47638e88…

1 0

patch applied (cabal): generalise remaining PackageIndex functions over class of pkgs with fixed deps
by Duncan Coutts 20 Feb '08

20 Feb '08

Wed Feb 20 11:51:43 PST 2008 Duncan Coutts <duncan(a)haskell.org> * generalise remaining PackageIndex functions over class of pkgs with fixed deps Add a class for packages with fixed deps, like InstalledPackageInfo and generalise the few functions that used PackageIndex InstalledPackageInfo specifically to use PackageFixedDeps pkg => PackageIndex pkg This will be helpful in cabal-install for configured but not-yet-installed packages. M ./Distribution/Simple/Configure.hs -7 +9 M ./Distribution/Simple/PackageIndex.hs -24 +32 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080220195143-adfee-af43b3db…

1 0

patch applied (cabal): Generalise InstalledPackageIndex over all Package instances
by Duncan Coutts 20 Feb '08

20 Feb '08

Wed Feb 20 11:10:31 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Generalise InstalledPackageIndex over all Package instances New Package class of things that can be identified by a PackageIdentifier so that covers at least PackageIdentifier, PackageDescription and InstalledPackageInfo. Most PackageIndex operations work for any package type. ./Distribution/Simple/InstalledPackageIndex.hs -> ./Distribution/Simple/PackageIndex.hs M ./Cabal.cabal -1 +1 M ./Distribution/Simple/Configure.hs -8 +10 M ./Distribution/Simple/GHC.hs -4 +4 M ./Distribution/Simple/Haddock.hs -2 +2 M ./Distribution/Simple/JHC.hs -5 +5 M ./Distribution/Simple/LocalBuildInfo.hs -2 +3 M ./Distribution/Simple/PackageIndex.hs -55 +81 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080220191031-adfee-5ba3b111…

1 0

[Hackage] #239: security hole: anyone can replace a package
by Hackage 20 Feb '08

20 Feb '08

#239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- It is possible for any registered user to upload a new version of a package without reference to the actual maintainer of the package. The new upload can even have the same name and version number as an existing package. Not only does this allow a malicious or misguided person to arbitrarily change or remove good code: there is also no notification on the webpage of the package about who uploaded it - only the author/maintainer fields of the cabal file. Needless to say, the latter may not be very happy that their name is associated with a corrupt package that they did not upload or authorise. Recently, a significant number of packages have been uploaded without their maintainers' knowledge, so this could be a real problem. A quick fix would be to list the uploader's name against every package, so that the paranoid user can make an informed decision about its status. Ultimately the decision about whether to trust a package is a social and community issue, but the lack of transparency in discovering relevant information is a technical problem that does have a solution. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/239> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 9