August 2009 - cabal-devel

[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 21 Oct '09

21 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] #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

[Hackage] #578: Allow installation of distro packages
by Hackage 23 Sep '09

23 Sep '09

#578: Allow installation of distro packages ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ It would be very nice indeed if {{{cabal-install}}} could be taught how to install a distro's version of a package. This could amount to simply asking a shell script if the package is available and can be installed, before proceeding with the usual Cabal installation machinery. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/578> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 10

[Hackage] #320: cooperation with Windows Vista's User Access Control
by Hackage 20 Sep '09

20 Sep '09

#320: cooperation with Windows Vista's User Access Control ----------------------------+----------------------------------------------- Reporter: Toxaris | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Windows | ----------------------------+----------------------------------------------- Installation of a cabal package under Windows Vista with UAC activated may fail even when working as administrator, because cabal doesn't request the necessary rights to write to, e.g., "c:\Program Files\Haskell\<whatever>". A workaround is to start an "Administrator console" to start Cabal from a process which already acquired admin privileges. Cabal should request the necessary rights instead of failing. cabal-install should check in advance whether the target destination is writeable and fail early or request the necessary rights. (currently, cabal-install fails after compiling all dependencies. After starting cabal-install again from an Administrator console, everything has to be build again). {{{ C:\Downloads\Haskell\typeof-0.1.1>runhaskell Setup install Setup: C:\Program Files\Haskell\doc\typeof-0.1.1: copyFile: permission denied (P ermission denied) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/320> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #572: cabal update download too short when through privoxy
by Hackage 18 Sep '09

18 Sep '09

#572: cabal update download too short when through privoxy ---------------------------------+------------------------------------------ Reporter: wolverian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ I have a Privoxy proxy running on localhost, set in the $http_proxy env var. Running cabal update gets a partial 00-index.tar.gz file: {{{ wolverian@pupupu:~ (master)$ cabal update -v3 Downloading the latest package list from hackage.haskell.org Sending: GET /packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/0.6.2 Host: hackage.haskell.org proxy uri host: 127.0.0.1, port: :8118 Creating new connection to 127.0.0.1:8118 Received: HTTP/1.1 200 OK Date: Mon, 03 Aug 2009 14:10:46 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Mon, 03 Aug 2009 13:56:03 GMT ETag: "595494-111c43-216dc2c0" Accept-Ranges: bytes Content-Length: 1121347 Connection: close Content-Type: application/x-tar Content-Encoding: x-gzip Downloaded to /home/wolverian/.cabal/packages/hackage.haskell.org/00-index.tar.gz cabal: user error (Codec.Compression.Zlib: premature end of compressed stream) }}} The resulting file is 1078 bytes. Running wget on the file gives: {{{ wolverian@pupupu:~ (master)$ LANG=C wget --server-response hackage.haskell.org/packages/archive/00-index.tar.gz --2009-08-03 17:12:26-- http://hackage.haskell.org/packages/archive/00-index.tar.gz Connecting to 127.0.0.1:8118... connected. Proxy request sent, awaiting response... HTTP/1.1 200 OK Date: Mon, 03 Aug 2009 14:12:26 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Mon, 03 Aug 2009 13:56:03 GMT ETag: "595494-111c43-216dc2c0" Accept-Ranges: bytes Content-Length: 1121347 Connection: close Content-Type: application/x-tar Content-Encoding: x-gzip Length: 1121347 (1.1M) [application/x-tar] Saving to: `00-index.tar.gz.3' 100%[===================================>] 1,121,347 84.8K/s in 12s 2009-08-03 17:12:38 (90.4 KB/s) - `00-index.tar.gz.3' saved [1121347/1121347] }}} The file is downloaded correctly. Versions: cabal-install is 0.6.2, Cabal is 1.6.0.2, and I have HTTP version 4000.0.7 installed, though I am not sure if that is the one cabal- install is compiled against. GHC is 6.10.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/572> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #240: setup install does not preserve MacOS X resource forks
by Hackage 11 Sep '09

11 Sep '09

#240: setup install does not preserve MacOS X resource forks ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I use the attached Setup.lhs file to do some Mac-related magic (which I unfortunately do not understand) on files built with wxhaskell on MacOS X. The key point about this magic is that it allows me to run a GUI from the command line. Without doing the magic, the GUI will open, but it will not react to any user interaction. I think the problem is that whatever mechanism we use to copy the binary over (say to /usr/local/bin) does not preserve the magic. That is, if I run it directly after a runhaskell Setup install, I get the non-reactive GUI. If I do a cp geni /usr/local/bin by hand, then the GUI reacts, presumably because on MacOS X cp also copies the magic over. Sorry for being so vague. Let me know if I can help in any way. -- Eric Kow -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/240> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

How to change -optc-O2 when compiling C files
by Roel van Dijk 31 Aug '09

31 Aug '09

Hello, I have cabal file which specifies some c-sources to compile together with the usual Haskell stuff. I noticed that cabal automatically passes -optc-O2 to GHC when compiling C files. If I specify some additional cc-options in my cabal file they just get prepended to the list of options passed to ghc. How do I get rid of the -optc-O2? With my current cc-options "-D_OPENMP -O3 -funroll-loops" GHC is invoked like this during a "cabal build": /usr/bin/ghc -Ilevmar-2.4 -package base-3.0.3.1 -optc-D_OPENMP -optc-O3 -optc-funroll-loops -optc-O2 -odir dist/build -c levmar-2.4/lm.c I don't know which -optc-O? will be picked by the C compiler. Normally -O2 is ok, but in this case I really want -O3. Thanks in advance, Roel van Dijk

1 0

[Hackage] #579: Wrong content type for web documentation
by Hackage 29 Aug '09

29 Aug '09

#579: Wrong content type for web documentation ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The http headers for http://www.haskell.org/cabal/release/cabal-latest/doc /users-guide/index.html return "Content-Type: text/html; charset=utf-8" however the documentation is in ISO-8859-1 format. The documentation source even has <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> but this doesn't override the content-type given by the HTTP headers in Firefox. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/579> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0