October 2008 - cabal-devel

Cabal is not working now
by Ahn, Ki Yung 21 Oct '08

21 Oct '08

kyagrd@kyagrd:~/cscs/EugeneSumSch/distr$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library kyagrd@kyagrd:~$ cabal update Downloading package list from server 'http://hackage.haskell.org/packages/archive' kyagrd@kyagrd:~$ cabal upgrade Resolving dependencies... cabal: cannot configure HUnit-1.2.0.2. It requires base ==4.* There is no available version of base that satisfies ==4.* I am using the current stable release of ghc 6.8.3 on linux i386, which as base version 3.x.x. As you can see, I am using the most recent version of cabal that I can get by doing "cabal upgrade cabal-install". Thanks, Ahn, Ki Yung

1 0

Re: cabal
by Simon Marlow 21 Oct '08

21 Oct '08

Claus Reinke wrote: >> The basic problem here is that the version number of the network package >> has not been bumped. .. >> .. Of course that's not true here because the package has >> changed without the version being bumped. >> .. >> Indeed the only reason it's trying to rebuild it at all is because the >> installed version has different deps from the available version, again >> due to the fact that it changed without changing version number. >> >> So the solution is for the updated network package to have its version >> bumped and for it to be released. > > For ghc at least, couldn't cabal grep the hashes from the output of > > find dist/ -name '*.hi' | xargs ghc --show-iface > > and associate the collection of hashes for the exposed-modules and > cross-package imports with the version number, keeping a history of > these associations? > > cabal tag-current > would try to add the current version number with the current hashes, > complaining if the number already exists with different hashes > > cabal sdist (and other distribution channels) > would check that the current version number is in the history with > the current hashes, and complain otherwise > > Distributing packages without version number checks could result in > in "unverified" packages, so users would know that the dependencies > and version number haven't been checked (successful checks could > create a package signature based on .cabal+.history, or on the whole > package contents). > Or are Ghc's new hashes non-portable/too specific? GHC's hashes aren't suitable for this (yet). We do not hash the API, but rather the ABI, and the ABI is often not stable - re-compiling can give you a different ABI, as internal names change and things move around in unpredictable ways. However I do think we should have a way to get a dump of the API. We've talked in the past about having some kind of API tool that would compare APIs and show you the differences (built on the GHC API of course). This would make a nice little project for someone... Cheers, Simon

1 0

Re: cabal
by Duncan Coutts 20 Oct '08

20 Oct '08

On Mon, 2008-10-20 at 20:20 +0100, Claus Reinke wrote: > > The basic problem here is that the version number of the network package > > has not been bumped. .. > > .. Of course that's not true here because the package has > > changed without the version being bumped. > > .. > > Indeed the only reason it's trying to rebuild it at all is because the > > installed version has different deps from the available version, again > > due to the fact that it changed without changing version number. > > > > So the solution is for the updated network package to have its version > > bumped and for it to be released. > > For ghc at least, couldn't cabal grep the hashes from the output of > > find dist/ -name '*.hi' | xargs ghc --show-iface > > and associate the collection of hashes for the exposed-modules and > cross-package imports with the version number, keeping a history of > these associations? Unfortunately the interface can change depending on the way the package is built, in particular the versions of the dependencies it is built with. This is because packages are really functors, parameterised by their dependencies. For this reason we can only associate hashes with built/installed packages, not with source packages on hackage. However for installed packages we certainly should track the package ABI hash. This will help in verifying the dependencies of built packages. It's also the starting point for a nix-style persistent built-package store. Duncan

1 0

Re: cabal
by Duncan Coutts 20 Oct '08

20 Oct '08

On Mon, 2008-10-20 at 16:28 +0200, Christian Maeder wrote: > Hi, > > currently I've got a problem installing from hackage. > using: > GHC (package manager) version 6.10.0.20081019 > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library > > I get: > > Building network-2.2.0.0... > > Network/URI.hs:128:7: > Could not find module `Data.Generics': > it is a member of package base-3.0.3.0, which is hidden The basic problem here is that the version number of the network package has not been bumped. You probably installed from a ghc bindist that has network-2.2.0.0 already, however it's not the same as network-2.2.0.0 from hackage. The pre-installed one is built against base-4, so when cabal-install tries to rebuild it then it tries to build it against base 4 which does not work because the one on hackage has not been updated. Normally cabal-install would use base-3 but in this case it's picking 4 because the version that is already installed used 4 so the assumption is that since the same version is already installed then it does indeed work with base 4. Of course that's not true here because the package has changed without the version being bumped. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number. So the solution is for the updated network package to have its version bumped and for it to be released. Duncan

1 0

patch applied (cabal-branches/cabal-1.6): Add GHC 6.10.1's extensions to the list in Language.Haskell.Extension
by Ian Lynagh 19 Oct '08

19 Oct '08

Sun Oct 19 07:14:08 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Add GHC 6.10.1's extensions to the list in Language.Haskell.Extension M ./Language/Haskell/Extension.hs -3 +16 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2008101914…

1 0

patch applied (cabal): Add GHC 6.10.1's extensions to the list in Language.Haskell.Extension
by Ian Lynagh 19 Oct '08

19 Oct '08

Sun Oct 19 07:14:08 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Add GHC 6.10.1's extensions to the list in Language.Haskell.Extension M ./Language/Haskell/Extension.hs -3 +16 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081019141408-3fd76-342e1efc…

1 0

[Hackage] #374: Hs-Source-Dirs in nested If must be respected by 'sdist'
by Hackage 18 Oct '08

18 Oct '08

#374: Hs-Source-Dirs in nested If must be respected by 'sdist' ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I have the following part in a Cabal file: {{{ If flag(executePipe) Hs-Source-Dirs: execute/pipe Else If flag(executeShell) Hs-Source-Dirs: execute/shell Else Hs-Source-Dirs: execute/tmp }}} However, when I run './Setup.lhs sdist' I get only the files from execute/pipe into the archive, but not execute/shell and execute/tmp. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/374> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal): Ensure that the lib target directory is present when installing
by Duncan Coutts 17 Oct '08

17 Oct '08

Thu Oct 16 17:44:37 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Ensure that the lib target directory is present when installing Variant on a patch from Bryan O'Sullivan M ./Distribution/Simple/GHC.hs -1 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081017004437-adfee-9cbba089…

1 0

darcs patch: Ensure that the target directory is present
by Bryan O'Sullivan 17 Oct '08

17 Oct '08

Thu Oct 16 19:56:15 EDT 2008 Bryan O'Sullivan <bos(a)serpentine.com> * Ensure that the target directory is present

1 0

[Hackage] #308: provide hierarchical haddock for each package
by Hackage 14 Oct '08

14 Oct '08

#308: provide hierarchical haddock for each package --------------------------------+------------------------------------------- Reporter: EricKow | Owner: Type: task | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- The primary haddock documentation for some packages seems to be on hackage. But on hackage, you see separate links for each module within the package, not a nice hiearchical listing like the one on http://www.haskell.org/ghc/docs/latest/html/libraries/ It would be nice if each package had its own mini-hierarchy -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/308> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2