- cabal-devel - Haskell.org

[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

patch applied (cabal): Add auto-generated CPP macros for package version testing
by Simon Marlow 12 Aug '08

12 Aug '08

Mon Aug 11 10:30:16 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * Add auto-generated CPP macros for package version testing Now when using CPP you get MIN_VERSION_<package>(A,B,C) for each <package> in build-depends, which is true if the version of <package> in use is >= A.B.C, using the normal ordering on version numbers. This is done by auto-generating a header file dist/build/autogen/cabal_macros.h, and passing a -include flag when running CPP. M ./Distribution/Simple/Build.hs -2 +43 M ./Distribution/Simple/BuildPaths.hs +3 M ./Distribution/Simple/GHC.hs +2 M ./Distribution/Simple/PreProcess.hs -3 +9 M ./doc/Cabal.xml +41 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080811173016-12142-850c66ab…

1 0

patch applied (cabal): allow Cabal to use base-4
by Simon Marlow 12 Aug '08

12 Aug '08

Wed Aug 6 06:05:12 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * allow Cabal to use base-4 M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806130512-12142-d7e77cfa…

1 0

Re: [Hackage] #58: allow dev repo to be specified in cabal file
by Hackage 12 Aug '08

12 Aug '08

#58: allow dev repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:14 SamB]: > Would hackage then check that the contents of the tarball actually matches what's in the repository -- or simply make the tarball on its own? No, it would not check or generate tarballs. It'd be for other uses (manual or automatic) which wants the equivalent of a release in the source control system. What kind of uses? I'm sure there are several. How about looking at changes since a release, generating automatic changelogs. I'm sure other people can think of others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:15> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0