September 2009 - cabal-devel

[Hackage] #485: preference on base version should only be applied for open constraints
by Hackage 19 Dec '09

19 Dec '09

#485: preference on base version should only be applied for open constraints ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently we apply the preference on the base version. That means that if you have base 3 and 4 available then for dependencies like: {{{ build-depends: base >= 2 }}} or {{{ build-depends: base >= 3 && < 5 }}} Then we end up picking base 3. That makes perfect sense in the first case. In the first case the developer clearly did not think about base 4. However in the second case they clearly have thought about it and yet we end up picking base 3. On balance it is probably better to pick base 4 in the second case even though both are allowed. One suggestion for how to handle soft constraints on the version of base is to say that we only apply the preference if the version is not bounded above. If it is bounded above then we use no preference and end up picking the highest version available. This policy cannot be expressed in the simple preferred versions syntax. It's probably ok to hard code it for base for now. This will require generalising the interface to the constraint solver to supply preferences in a slightly different form. It may need to be as a function from a list of possible versions to the selected version. The function would also be supplied with the package it's for, the dependency and the list of installed versions since it may want to take any of these into account and it is needed to express the above policy. This is related to the splitting of preferences into real preferences and hacks (see #483). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/485> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #385: emgm package incorrectly shown as "program" but is "library and program"
by Hackage 01 Dec '09

01 Dec '09

#385: emgm package incorrectly shown as "program" but is "library and program" --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- The summary says it all. In the HackageDB package overview, it is shown whether packages contain libraries and/or programs, but this does not seem to work correctly in all cases, as emgm demonstrates. kosmikus -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/385> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #423: add option to fetch a single package without dependencies
by Hackage 28 Nov '09

28 Nov '09

#423: add option to fetch a single package without dependencies ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Right now, {{{cabal fetch}}} fetches all missing dependencies of a package along with its source. In some cases, in particular when studying code, those dependencies are not useful. It would be nice to have an option, say {{{--no-deps}}} to fetch just the specified packages. (This is related to {{{cabal unpack}}} -- see #390.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/423> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #562: cabal-install update fails going through a HTTP proxy (but not consistently)
by Hackage 14 Nov '09

14 Nov '09

#562: cabal-install update fails going through a HTTP proxy (but not consistently) ----------------------------+----------------------------------------------- Reporter: acid2 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have installed Cabal, cabal-install and HTTP all from source on my Arch Linux machine, which has GHC 6.10.3 installed. When running {{{cabal update}}} this will occasionally work, but most often fails with the error: {{{cabal: user error (Codec.Compression.Zlib: premature end of compressed stream)}}} In this case, inspecting ~/.cabal/packages/hackage.haskell.org/00-index.tar.gz shows a file size that varies around 1-15K, rather than the expected ~900K. Attached are logs of `cabal-update` failing, and working: {{{ Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/0.6.2 Host: hackage.haskell.org proxy uri host: wwwcache.lancs.ac.uk, port: :8080 Creating new connection to wwwcache.lancs.ac.uk:8080 Received: HTTP/1.0 200 OK Date: Tue, 09 Jun 2009 13:50:46 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Tue, 09 Jun 2009 09:53:44 GMT ETag: "3890c4-f8d7c-55909a00" Accept-Ranges: bytes Content-Length: 1019260 Content-Type: application/x-tar Content-Encoding: x-gzip Age: 854 X-Cache: HIT from wwwcache.lancs.ac.uk X-Cache-Lookup: HIT from wwwcache.lancs.ac.uk:8080 X-Cache: MISS from wwwcache.lancs.ac.uk X-Cache-Lookup: MISS from wwwcache.lancs.ac.uk:8080 Via: 1.0 wwwcache3.lancs.ac.uk:8080 (squid/2.6.STABLE22), 1.0 wwwcache1.lancs.ac.uk:8080 (squid/2.7.STABLE4) Connection: close Downloaded to /home/ollie/.cabal/packages/hackage.haskell.org/00-index.tar.gz }}} {{{ Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/0.6.2 Host: hackage.haskell.org proxy uri host: wwwcache.lancs.ac.uk, port: :8080 Creating new connection to wwwcache.lancs.ac.uk:8080 Received: HTTP/1.0 200 OK Date: Tue, 09 Jun 2009 13:50:46 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Tue, 09 Jun 2009 09:53:44 GMT ETag: "3890c4-f8d7c-55909a00" Accept-Ranges: bytes Content-Length: 1019260 Content-Type: application/x-tar Content-Encoding: x-gzip Age: 875 X-Cache: HIT from wwwcache.lancs.ac.uk X-Cache-Lookup: HIT from wwwcache.lancs.ac.uk:8080 Via: 1.0 wwwcache3.lancs.ac.uk:8080 (squid/2.6.STABLE22) Proxy-Connection: close Downloaded to /home/ollie/.cabal/packages/hackage.haskell.org/00-index.tar.gz Reading available packages... }}} I was also asked to try running wget in verbose mode, this is the output: {{{ --2009-06-09 16:17:00-- http://hackage.haskell.org/packages/archive/00-index.tar.gz Resolving wwwcache.lancs.ac.uk... 194.80.32.11, 194.80.32.8, 194.80.32.9, ... Connecting to wwwcache.lancs.ac.uk|194.80.32.11|:8080... connected. Proxy request sent, awaiting response... HTTP/1.0 200 OK Date: Tue, 09 Jun 2009 13:50:46 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Tue, 09 Jun 2009 09:53:44 GMT ETag: "3890c4-f8d7c-55909a00" Accept-Ranges: bytes Content-Length: 1019260 Content-Type: application/x-tar Content-Encoding: x-gzip Age: 1558 X-Cache: HIT from wwwcache.lancs.ac.uk X-Cache-Lookup: HIT from wwwcache.lancs.ac.uk:8080 Via: 1.0 wwwcache3.lancs.ac.uk:8080 (squid/2.6.STABLE22) Proxy-Connection: close Length: 1019260 (995K) [application/x-tar] Saving to: `00-index.tar.gz.2' 100%[===================================================================================================>] 1,019,260 --.-K/s in 0.09s 2009-06-09 16:17:00 (11.1 MB/s) - `00-index.tar.gz.2' saved [1019260/1019260] }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/562> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 15

[Hackage] #403: Bad error message when running ./configure fails to find sh
by Hackage 10 Nov '09

10 Nov '09

#403: Bad error message when running ./configure fails to find sh ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.1 Platform: Windows | ----------------------------------+----------------------------------------- For `build-type: Configure` we have to run `./configure`. On windows this will very often fail of course because they usually lack the `sh` program. Currently the error message users get is not great: {{{ sh: runGenProcess: does not exist (No such file or directory) }}} It would be nicer if they got a better message. Perhaps the way to do that is to catch the `DoesNotExist IOException` and re-throw a better message. Alternatively we could explicitly check for `sh` before invoking it. If it's not found on Windows then we could report that the package needs a unix-style command shell program eg from `mingw` to build. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/403> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #261: Marking packages deprecated
by Hackage 06 Nov '09

06 Nov '09

#261: Marking packages deprecated ----------------------------+----------------------------------------------- Reporter: nibro | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- There should be a way to mark a package as '''deprecated''' so it doesn't show up on the main Hackage listing. If a newer package, with the same name, is uploaded then the older packages will in effect be defunct. But if you don't have a newer package with the same name, there is currently no way to "get rid of" packages that are no longer valid. There may be several reasons for why you would want to do this, likely most often because the contents of the package are superceded by functionality in some other package, with a different name. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/261> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #382: 'cabal ghci' mode
by Hackage 22 Oct '09

22 Oct '09

#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ See http://www.haskell.org/pipermail/haskell-cafe/2008-October/049830.html and http://www.haskell.org/pipermail/haskell- cafe/2008-October/049913.html. Two things would be nice: "cabal ghci" loads the main-is file in ghci; and "cabal ghci Data.My.Module" loads the listed modules in ghci. Reiner -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 11

[Hackage] #591: Dynamic libraries don't receive a proper install-name on Mac OS/X
by Hackage 02 Oct '09

02 Oct '09

#591: Dynamic libraries don't receive a proper install-name on Mac OS/X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: dynamic mac osx Difficulty: unknown | Ghcversion: Platform: Mac OS | ----------------------------+----------------------------------------------- Mac OS/X stores the install location of dynamic library into the library itself. GHC bug #3550 adds a new -install-name option to GHC, to allow this to be done at build time. This patch modifies Cabal to pass the -install-name option when building dynamic libraries on Mac OS/X so they're created with the correct install location. This change is needed for the GHC #3550 fix to work correctly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/591> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #282: profiling versions of libraries not managed well
by Hackage 30 Sep '09

30 Sep '09

#282: profiling versions of libraries not managed well ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: profiling Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ At the moment, if you want profiling builds of libraries which you have already installed, the only way to get them is to unregister and rebuild with profiling turned on. This is especially inconvenient when you have a program that depends on many different libraries... Ideally, I could just add a flag to rebuild a program with profiling, regardless of whether I'd installed profiling versions or not... Any ideas on how this should be managed? What configurations should be allowed? How do we make sure the same library version is used for the profiling build as was used for the normal build? When do we just give up and make the user figure it out? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/282> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

Re: [Hackage] #593: Rebuild for library profiling without reinstalling
by Hackage 30 Sep '09

30 Sep '09

#593: Rebuild for library profiling without reinstalling -------------------------------------------------+-------------------------- Reporter: Tim <chevalier(a)alum.wellesley.edu> | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: minor | Resolution: duplicate Keywords: | Difficulty: unknown Ghcversion: | Platform: -------------------------------------------------+-------------------------- Changes (by duncan): * status: new => closed * resolution: => duplicate Comment: I think the better solution is for {{{ cabal install mtl --enable-library-profiling }}} To just do the right thing. That is the subject of ticket #282. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/593#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0