August 2008 - cabal-devel

patch applied (cabal): Add data Platform = Platform Arch OS
by Duncan Coutts 12 Aug '08

12 Aug '08

Tue Aug 12 09:09:41 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add data Platform = Platform Arch OS Since we tend to pass them around together rather a lot. Also add a Text instance with a format like "i386-linux" M ./Distribution/System.hs +25 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080812160941-adfee-3690e2bd…

1 0

patch applied (cabal): Don't use tab characters in the generated Paths module
by Duncan Coutts 12 Aug '08

12 Aug '08

Tue Aug 12 09:07:31 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Don't use tab characters in the generated Paths module M ./Distribution/Simple/Build.hs -4 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080812160731-adfee-7508db2d…

1 0

Re: [Hackage] #133: sdist and clean should never be given Maybe LocalBuildInfo
by Hackage 12 Aug '08

12 Aug '08

#133: sdist and clean should never be given Maybe LocalBuildInfo ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: Cabal-2.0 Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * priority: high => normal -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/133#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #321: cabal in non-existant directory fails
by Hackage 12 Aug '08

12 Aug '08

#321: cabal in non-existant directory fails ----------------------------+----------------------------------------------- Reporter: larsv | 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: Linux | ----------------------------+----------------------------------------------- To reproduce: {{{ mkdir foo ; cd foo ; rmdir ../foo ; cabal install regex-pcre }}} Result: {{{ shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory Resolving dependencies... 'regex-base-0.93.1' is cached. cabal: Error: some packages failed to install: regex-base-0.93.1 failed during the configure step. The exception was: getCurrentDirectory: does not exist (No such file or directory) regex-pcre-0.94.1 depends on regex-base-0.93.1 which failed to install. }}} The first shell-init error occurs even if no package is chosen or any other cabal command is used such as "list" or "upgrade". -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/321> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #288: the package indexes are very slow
by Hackage 12 Aug '08

12 Aug '08

#288: the package indexes are very slow ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ In a large run, eg trying to make a plan to install 560 packages from hackage: {{{ $ cabal install --dry-run $(cat pkgs) }}} it turns out (according to the ghc profile), 91% of the time is spent reading the index of installed and available packages. The ghc package index is a couple of massive text files in `Read/Show` format so that takes for ever to read. The available package index is the tarball of .cabal files and our .cabal file parser is really slow. For smaller runs it's not so bad: {{{ $ cabal install --dry-run xmonad }}} since we only have to inspect the subset of the available package index that make up xmonad's transitive deps (any versions thereof), so that allows us to avoid forcing most of the index. http://hackage.haskell.org/trac/ghc/ticket/2089 might help us, but then again maybe not if we still have to parse the result of calling ghc-pkg since that will give us another text format. For our own package index, perhaps we should be generating a cache in some other format when we download the package index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/288> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #311: support ghc-pkg dump
by Hackage 12 Aug '08

12 Aug '08

#311: support ghc-pkg dump ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- http://hackage.haskell.org/trac/ghc/ticket/2201#comment:5 We need to do this to support ghc-6.10 properly. At the same time we should try the lazy parsing approach where we split on the records and extract the name and version but parse the remainder lazily. This could significantly speed up the parsing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/311> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #198: cabal install foo should upgrade foo if there's a newer version
by Hackage 12 Aug '08

12 Aug '08

#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/198> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

Re: [Hackage] #57: maybe: each new package uploaded to hackageDB should create a component in trac?
by Hackage 12 Aug '08

12 Aug '08

#57: maybe: each new package uploaded to hackageDB should create a component in trac? --------------------------------+------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: closed Priority: low | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: --------------------------------+------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: We should let packages link to their own bug reporting systems. It doesn't scale to use this trac for 600 packages and many use their own anyway. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/57#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
by Hackage 12 Aug '08

12 Aug '08

#175: cabal-install needs a new package dependency resolution algorithm ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/175> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #267: cabal upload has poor error messages (just an HTTP response code)
by Hackage 12 Aug '08

12 Aug '08

#267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Duncan says: Indeed. There is an error message available but I'm not sure how we get at it. Any ideas Ross? Another ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/267> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5