__color__ __group__ ticket summary type severity created _changetime _description _reporter
3 Cabal library 24 Cabal shouldn't try to build GHCI libs on platforms without GHCI defect normal 2005-11-28T11:54:51-0800 2012-01-05T08:28:31-0800 "Cabal should not attempt to do anything relating to GHCI on archs that don't support it. It shouldn't try to build ghci libs, and it shouldn't pass --auto-ghci-libs to ghc-pkg.
More information here:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1364839&group_id=8032" jgoerzen@…
3 Cabal library 43 for Hugs executable install, dependencies need to be taken into account for the generated script defect normal 2006-01-08T21:37:52-0800 2010-10-18T16:28:54-0700 "See the TODO in Hugs.hs:installHugs around line 209.
When we generate the runhugs command, we should not only use the options and language extensions for this package but also all those of packages that this executable depends on. This is because hugs has no notion of package, so we have to use the union of all flags/extensions and just prey that they are compatible." ijones
3 Cabal library 93 Incorrect permissions on library install defect normal 2006-09-22T16:05:34-0700 2012-01-05T07:59:52-0800 "My user umask is 0007 and my root umask is 0022. When I build a library with cabal and then install with:
# sudo runghc Setup.hs install
The library which is installed doesn't have the correct permissions for cabal to be able to reference it later when I build other things.
My work around is to follow the install with the following command:
# sudo chmod -R a+rX /path/to/new/library
This happens on all versions of cabal that I have tried." guest
4 Cabal library 124 *.cpphs files aren’t preprocessed with -D__HADDOCK__ when needed defect normal 2007-04-24T09:48:43-0700 2010-04-13T14:52:51-0700 If using {{{Distribution.Simple}}} together with {{{*.cpphs}}} files, Haddock doesn’t receive input files preprocessed with {{{-D__HADDOCK__}}} but probably those files preprocessed for compilation. This removes the ability to include and exclude code depending on whether Haddock is run or not. g9ks157k@…
3 Cabal library 128 cabal building broken libraries when module list is not complete defect major 2007-05-04T02:33:06-0700 2012-01-05T08:06:01-0800 "to reproduce:
- write a *.cabal file for a library, but omit a module in extra-modules list
- install that library
- use the library, and you will get linking errors, pointing out that the left out modules
functions are missing (undefined reference)
to workaround:
- make shure that all modules are noticed in *.cabal
to fix (suggestion):
- don't build a library when some of its modules are not in *.cabal" m@…
3 cabal-install tool 131 cabal-install should rebuild dependants when a package is upgraded defect normal 2007-05-23T05:08:06-0700 2012-03-08T01:04:39-0800 "Currently, when cabal-install upgrades a package, other packages that depend on it are not rebuilt.
Scenario: You have package A-1.0 and A-2.0, and B-1.0 which depends on A. B-1.0 is compiled against A-1.0. C then depends on A and B, and GHC picks A-2.0 and B-1.0. This breaks, because C now uses A-2.0 and B-1.0 uses A-1.0.
This could be made less of a problem if cabal-install would be able to reinstall all packages which depend on the new package. This might not always be what you want, so there should be a flag to turn it off.
Logic: When installing a new package Foo-X.Y, then each installed package which depends on Foo with a version range that includes X.Y should be reinstalled." bringert
3 Cabal library 137 setup sdist places implementation-dependent preprocessor output in the source bundle defect normal 2007-06-02T02:00:26-0700 2012-04-12T12:40:54-0700 "e.g. happy -agc output in the haskell-src package.
Suggested new scheme: [http://www.haskell.org/pipermail/cabal-devel/2007-May/000529.html]." ross@…
3 Cabal library 146 cabal should support CPP and haskell string gaps in the same file defect normal 2007-08-13T09:25:39-0700 2008-03-19T05:27:46-0700 "Haskell string gaps are not completely compatible with cpp preprocessing. cpphs works fine as a preprocessor, but ghc -cpp needs trailing whitespace so that the C preprocessor only emits warnings but accepts the file.
Using ""extensions: CPP"" in a .cabal file results in a call to ""ghc -cpp"", even if cpphs is installed. Removing ""extensions: CPP"" breaks haddock generation." guest
3 Cabal library 170 pkg-config uses a more general version scheme defect normal 2007-11-05T14:35:56-0800 2012-01-05T08:04:48-0800 "From {{{HsOpenSSL.cabal}}}
{{{
--PkgConfig-Depends: openssl >= 0.9.7l
-- We really should use this instead of the configure
-- script but Cabal 1.2.2.0 can't handle the weird version
-- scheme of OpenSSL.
}}}
For example:
{{{
$ pkg-config --modversion openssl
0.9.8f
}}}
Currently Cabal tries to map pkg-config versions to the standard {{{Version}}} type which only allows for a sequence of numbers.
pkg-config uses just strings to represent package versions. It uses code lifted from rpm to compare version strings. See the {{{compare_versions}}} function in {{{pkg-gconfig-0.22/pkg.c}}} from http://pkgconfig.freedesktop.org/releases/pkg-config-0.22.tar.gz" duncan
4 Cabal library 177 Check Include-dirs, extra-lib-dirs etc exist at configure time. defect normal 2007-11-12T14:13:43-0800 2012-01-05T08:04:07-0800 "Trying to build the HDBC-PostGreSQL database driver[1] revealed some poor handling of pathames under Windows.
The package requires that the paths to postgre header and libraries files be added to the .cabal file. My initial attempt was the obvious:
{{{
include-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program Files\PostgreSQL\8.2\include\server, .
extra-lib-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program Files\PostgreSQL\8.2\include\server
}}}
However, the package would not build. The include files ""pg_config.h"" and some others were not found. Using single or double quotes did not help. Finally, I moved the installation to ""C:\pgsql"" and updated the .cabal file:
{{{
include-dirs: C:\pgsql\include, C:\pgsql\include\server, .
extra-lib-dirs: C:\pgsql\lib
}}}
And the package built. It seems the spaces in the first path caused the problem.
For reference, this it the configure output on my machine:
{{{
Configuring HDBC-postgresql-1.0.1.0...
configure: Dependency base-any: using base-2.1.1
configure: Dependency mtl-any: using mtl-1.0.1
configure: Dependency HDBC>=1.0.0: using HDBC-1.0.1
configure: Dependency parsec-any: using parsec-2.0
configure: Using install prefix: C:\Program Files
configure: Binaries installed in: C:\Program Files\Haskell\bin
configure: Libraries installed in: C:\Program Files\Haskell\HDBC-postgresql-1.0.1.0\ghc-6.6.1
configure: Private binaries installed in: C:\Program Files\HDBC-postgresql-1.0.1.0
configure: Data files installed in: C:\Program Files\Common Files\HDBC-postgresql-1.0.1.0
configure: Using compiler: c:\ghc\ghc-6.6.1\bin\ghc.exe
configure: Compiler flavor: GHC
configure: Compiler version: 6.6.1
configure: Using package tool: c:\ghc\ghc-6.6.1\bin\ghc-pkg.exe
configure: Using ar found on system at: c:\ghc\ghc-6.6.1\bin\ar.exe
configure: Using haddock found on system at: C:\haddock\haddock-0.8\haddock.exe
configure: No pfesetup found
configure: Using ranlib found on system at: c:\MinGW\bin\ranlib.exe
configure: Using runghc found on system at: c:\ghc\ghc-6.6.1\bin\runghc.exe
configure: Using runhugs found on system at: C:\Program Files\WinHugs\runhugs.exe
configure: No happy found
configure: No alex found
configure: Using hsc2hs: c:\ghc\ghc-6.6.1\bin\hsc2hs.exe
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
}}}
Feel free to email me at jgbailey AT gmail DOT com for more info.
[1] Version 1.0.1.0 available at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-postgresql-1.0.1.0. HDBC is also required. I used 1.0.1, available at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-1.0.1." guest
4 Cabal library 219 JHC's generated .ho files should go under dist/ defect minor 2008-01-26T14:58:48-0800 2008-01-30T12:58:28-0800 "Apparently JHC puts `.ho` files into the src dirs.
That will not work any more since we only clean the `dist/` directory. It's really much simpler that way.
The fix is probably to pass some extra flag to jhc when compiling in `Distribution/Simple/JHC.hs`. Should be easy to fix for anyone who has a working jhc installed." duncan
3 cabal-install tool 227 cabal-install doesn't consider build-tools as dependencies defect normal 2008-01-31T17:23:54-0800 2012-03-02T09:46:54-0800 "On #haskell, nelhage mentioned that one of the bugs he ran into while trying to install Yi-0.3 through cabal-install was an error which looked like this:
Installing: /home/gwern/.cabal/lib/regex-posix-0.72.0.2/ghc-6.8.2/regex-posix-0.72.0.2/ghc-6.8.2
Registering regex-posix-0.72.0.2...
Reading package info from ""dist/installed-pkg-config"" ... done.
Saving old package config file... done.
Writing new package config file... done.
'yi-0.3' is cached.
[1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o )
Linking dist/setup/setup ...
Configuring yi-0.3...
setup: alex version >=2.0.1&&<3 is required but it could not be found.
That is, the dependency on Alex (a version which satisfied >=2.0.1&&<3) was not met. Perfectly sensible as he did not have Alex installed. Puzzled, he did a 'cabal install alex', which worked, and then re-started. (I guess he had his GHC installed locally?).
He and I were puzzled, because cabal-install is supposed/usually does track down dependencies. Is build-tools excluded for a reason, or was it just accidentally omitted from dependency-tracking? If the latter, I think this is a bit of a bug.
(I use Cabal-1.2.3.0, btw, and the error message above was my reproduction of Nelhage's problem. I had to uninstall Alex from my system, but that did the trick, and reinstalling bypassed the issue just fine - which is why I hadn't seen it before.)
--
gwern
" guest
3 Cabal library 230 setup haddock ignores LANGUAGE CPP pragma defect normal 2008-02-04T09:42:56-0800 2012-01-05T08:07:45-0800 "`setup haddock` preprocesses sources with cpp if `CPP` is included in the `extensions` field, but not if a source file starts with
{{{
{-# LANGUAGE CPP #-}
}}}
This is confusing, because that works with `setup build`." ross@…
3 Cabal library 231 """buildable: False"" should fail the current configuration" defect normal 2008-02-04T17:15:22-0800 2009-04-27T02:02:54-0700 "Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non-existant`, though with a different error message.
If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards).
At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step.
One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error." duncan
3 Cabal library 236 Installed package config refers to nonexisting haddock interface and html files defect normal 2008-02-11T13:48:51-0800 2009-02-04T04:37:04-0800 "Cabal generates the {{{haddock-interfaces}}} and {{{haddock-html}}} package fields even if the haddock documentation is not built nor installed.
Instead of assuming haddock is used, it should add the fields iff needed upon register (install = copy + register), where enough information should be available to make a more clever installation.
Example {{{ghc-pkg describe binary}}} built without haddock:
{{{
name: binary
version: 0.4.1
license: BSD3
copyright:
maintainer: Lennart Kolmodin, Don Stewart
stability: provisional
homepage: http://www.cse.unsw.edu.au/~dons/binary.html
package-url:
description: Efficient, pure binary serialisation using lazy ByteStrings.
Haskell values may be encoded to and form binary formats,
written to disk as binary, or sent over the network.
Serialisation speeds of over 1 G\/sec have been observed,
so this library should be suitable for high performance
scenarios.
category: Data, Parsing
author: Lennart Kolmodin
exposed: True
exposed-modules: Data.Binary Data.Binary.Put Data.Binary.Get
Data.Binary.Builder
hidden-modules:
import-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2
library-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2
hs-libraries: HSbinary-0.4.1
extra-libraries:
extra-ghci-libraries:
include-dirs:
includes:
depends: base-3.0.1.0 bytestring-0.9.0.4 base-3.0.1.0
containers-0.1.0.1 array-0.1.0.0
hugs-options:
cc-options:
ld-options:
framework-dirs:
frameworks:
haddock-interfaces: /usr/share/doc/binary-0.4.1/html/binary.haddock
haddock-html: /usr/share/doc/binary-0.4.1/html
}}}
Both {{{/usr/share/doc/binary-0.4.1/html/binary.haddock}}} and {{{/usr/share/doc/binary-0.4.1/html}}} are (rightfully) missing in the installation." kolmodin
3 Cabal library 241 The Make build-type doesn't pass haddock options to make defect normal 2008-02-16T05:37:18-0800 2012-01-05T08:03:57-0800 "The Simple build-type works out the correct options for haddock, including the extra options for haddock2 and --read-interface options taking into account the --html-location option. For example this is used by hackageDB to generate correct inter-package links. There is no way for the makefile to figure out where those links should point. (e.g. the wxcore package.)
The Make build-type ought to put these options in a HADDOCKOPTS setting on the make command line, so that the makefile can pass these to haddock." ross@…
4 Cabal library 245 Cabal should support hsc2hs's stub .c feature defect normal 2008-02-21T11:37:23-0800 2012-01-05T08:03:28-0800 "The Pugs project recently uncovered a bit of a problem with GHC 6.8.x.
To quote:
- {-# INCLUDE -} seems to require either a very relative or an absolute path. That is, you have to make the path listed inside an INCLUDE ('dist/build/Pugs/Embed/Parrot_hsc.h') in the file dist/build/Pugs/Embed/Parrot.hs absolute or completely relative - that is, the first line needs to look like either '{-# INCLUDE ""Parrot_hsc.h"" #-}' or '{-# INCLUDE
""/home/gwern/bin/pugs/dist/build/Pugs/Embed/Parrot_hsc.h"" #-}'.
The particular problem is that 'dist/build/Pugs/Embed/Parrot_hsc.c:#include ""Parrot_hsc.h""' is being translated to the (broken) 'dist/build/Pugs/Embed/Parrot.hs:{-# INCLUDE ""dist/build/Pugs/Embed/Parrot_hsc.h"" #-}'.
The relevant files and notes can be found in the Pugs SVN repo, in src/Pugs/Embed/, and the files of interest are Haskell.hs Parrot.hsc Parrot_hsc.c Parrot_hsc.h Perl5.hs Pugs.hs
--
gwern
" guest
3 Cabal library 263 Multiple compilers of the same version confuse Cabal defect normal 2008-03-25T05:31:20-0700 2010-06-22T07:30:26-0700 "It often happens that two or more copies of the same version of the same
compiler are installed on a system. For example, the compiler can be installed
with an installation package, or be built from the source tarball, or from darcs,
or using MacPorts.
If a package is installed for each of these copies of the compiler
while allowing Cabal to use the default installation location each time,
Cabal will always use the exact same folder. This leads to mayhem and
anarchy.
Proposed solution:
Cabal should also use the base path of the compiler when it constructs
the directory name for the package, not just the compiler name and version.
For example: If I install a package foo-1.2.3.4 --with-compiler=/opt/local/bin/ghc-6.8.2
and the installation base path is /usr/local, then Cabal should install the
package into /usr/local/lib/foo-1.2.3.4/opt_local_ghc-6.8.2
" guest
4 Cabal library 265 Cabal field stability not useful defect minor 2008-04-08T16:02:57-0700 2012-01-05T08:02:37-0800 "As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string.
I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing.
Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml.
But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas.
Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release.
--
gwern" guest
3 Cabal library 266 cabal haddock plus cpp preprocessing with relative #include files defect normal 2008-04-09T14:49:16-0700 2012-01-05T08:03:40-0800 "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
Bug 2: cabal haddock fails
$ cabal haddock
Preprocessing library homeomorphic-0.1...
Running Haddock for homeomorphic-0.1...
Warning: The documentation for the following packages are not installed.
No links will be generated to these packages: base-3.0.1.0,
QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1
dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0:
Include/Hash.hs: No such file or directory
This one may well be my fault, if some extra magic is required for the
haddock with CPP, but not the building - but that seems weird, if
there is enough info to build the file, surely there is enough info to
haddock it
Duncan says:
Right, there is no such guarantee at the moment. That's because ghc
--make can find things by import chasing where Cabal needs more stuff
specified explicitly. One day when Cabal does the import chasing they'll
be consistent.
In this case though it doesn't look like on of those problems. It seems
to be because for haddock we're copying files to dist/ and then running
cpp on them. That means of course that relative #includes do not work.
It's not entirely clear to me why we are copying them before running cpp
and not just running cpp on the files from their original locations.
Please file a ticket for this one.
" guest
3 cabal-install tool 282 profiling versions of libraries not managed well defect normal 2008-05-24T09:26:48-0700 2012-05-23T08:50:12-0700 "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?" SamB
3 Cabal library 283 install command doesn't install dist/doc/users-guide/ defect normal 2008-05-26T17:55:33-0700 2008-08-20T09:41:10-0700 When doing install on cabal itself, only the contents of dist/doc/html are copied to their install location. The users guide doesn't get installed. Misha Aizatulin
3 Cabal library 290 Cabal does some work behind the back of hooks defect normal 2008-06-08T04:06:50-0700 2009-03-07T06:47:38-0800 "Cabal does some work behind the back of hooks, e.g. with `q.cabal`:
{{{
name: q
version: 1
exposed-modules: Bar
build-type: Custom
}}}
and `Setup.hs`:
{{{
module Main (main) where
import Distribution.Simple
import Distribution.Simple.Setup
import System.Cmd
main :: IO ()
main = defaultMainWithHooks myHooks
myHooks :: UserHooks
myHooks = simpleUserHooks {
confHook = \x flags -> do
let flags' = flags { configDistPref = Flag ""foo"" }
lbi <- (confHook simpleUserHooks) x flags'
system ""ls""
return lbi,
postConf = \args flags pd lbi -> do
system ""ls""
let flags' = flags { configDistPref = Flag ""foo"" }
(postConf simpleUserHooks) args flags' pd lbi
return ()
}
}}}
a `dist` directory magically appears between the configure hook and the postconf hook:
{{{
$ ./Setup configure
Configuring q-1...
Setup Setup.hi Setup.hs Setup.o foo q.cabal
Setup Setup.hi Setup.hs Setup.o dist foo q.cabal
$ ls -l dist
-rw-r--r-- 1 ian ian 6411 Jun 8 12:02 setup-config
}}}
The reason I want to do this is so that `Setup.hs` can take care of building itself in multiple ways, using different dist directories.
" igloo
3 Cabal library 303 cabal clean: Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty) defect normal 2008-06-23T04:02:26-0700 2011-08-08T11:03:49-0700 "cabal clean has a problem on Windows and Unix with NFS that causes it to fail when using a custom `Setup.hs`. The problem is that we compile `Setup.hs` to `dist/setup/setup`, and then invoke `dist/setup/setup clean` which is supposed to remove the whole of the `dist` tree, including the running binary. This causes problems on Windows where running binaries can't be deleted, and also on NFS where deleting the running binary leaves a `.nfs` file behind, preventing the parent directory from being deleted.
{{{
> cabal clean -v
Creating dist/setup (and its parents)
dist/setup/setup clean --verbose=2 --distpref=dist
cleaning...
Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty)
> ls -lr dist
total 36
-rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/
~/darcs/ghc-paths > ls -lra dist
total 52
-rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ./
~/darcs/ghc-paths > ls -lRa dist
dist:
total 52
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ./
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/
-rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config
dist/build:
total 52
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ./
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ../
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 autogen/
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 GHC/
-rw-rw-r-- 1 simonmar GHC 3657 2008-06-23 11:32 HSghc-paths-0.1.o
-rw-rw-r-- 1 simonmar GHC 4404 2008-06-23 11:32 libHSghc-paths-0.1.a
dist/build/autogen:
total 24
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 ./
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../
-rw------- 1 simonmar GHC 990 2008-06-23 11:32 Paths_ghc_paths.hs
dist/build/GHC:
total 32
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 ./
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../
-rw-rw-r-- 1 simonmar GHC 895 2008-06-23 11:32 Paths.hi
-rw-rw-r-- 1 simonmar GHC 3824 2008-06-23 11:32 Paths.o
dist/setup:
total 16
drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 ./
drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ../
}}}" simonmar
3 cabal-install tool 309 cabal install should recognize if package was already configured defect normal 2008-07-05T07:53:09-0700 2012-03-08T01:14:33-0800 "If I first configure an unpacked package inside its source directory
cabal configure --prefix=/my/path --flags=whatever
and then afterwards do
cabal install
then the configure options I gave before are not recognized by the 'cabal install'.
Instead, 'cabal install' without a package name argument should inspect whether the package is already configured and use whatever options have been set." bfr
4 Cabal library 321 cabal in non-existant directory fails defect minor 2008-08-09T02:56:10-0700 2012-01-05T08:06:59-0800 "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"".
However, that seems to be intrinsic to ghc as it shows when running just the ghc binary as well." larsv
3 Cabal library 325 SHGetFolderPath requiered to configure cabal on windows defect normal 2008-08-16T04:23:39-0700 2012-01-05T08:27:50-0800 "i try to install cabal with ghc 6.8.3 on XP.
i get the error message
GHCi could not find the following symbols
SHGetFolderPath
i saw some old bugs mentioning this problem - what is a current fix?" guest
3 Cabal library 331 pkg-config error messages could be better defect normal 2008-08-20T09:38:22-0700 2012-01-05T08:27:59-0800 "Currently if you `cabal install X11-xft` but don't have the xft development package installed you get this during configure:
{{{
cabal: The pkg-config package xft is required but it could not be found.
}}}
What is not immediately clear is that this is a native package and thus not something that `cabal-install` could have gone and fetched. So the wording of this message could be improved. Perhaps mentioning both in general terms and then specifically. For example saying that the development files for xft are not installed and that the user probably can and should install a native package that provides it. Specifically it's looking for a xft.pc file that pkg-config uses to tell is what compiler flags to use to use xft.
A related problem is that the message is somewhat lost in the noise because we print the error to stdout rather than throwing it as an exception that we could print in the final summary. This problem is particulary bad when we have to have error message cross process boundaries, ie when cabal-install invokes a setup program." duncan
3 Cabal library 337 --disable-split-objs has wrong help string defect minor 2008-08-22T15:14:01-0700 2012-01-05T08:07:26-0800 "I did:
$ ./Setup.lhs configure --help
...
--enable-split-objs split library into smaller objects to
reduce binary sizes (GHC 6.6+)
--disable-split-objs split library into smaller objects to
reduce binary sizes (GHC 6.6+)
...
It should read:
--disable-split-objs retain library as one object file
(GHC 6.6+)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.3
" guest
3 Cabal library 346 Add a warning for synopsis being a prefix of the description defect normal 2008-08-27T07:56:54-0700 2012-01-05T08:30:40-0800 "Many packages provide useless descriptions, just repeating the synopsis. Three (all from different authors, and only looking at those with ""string"" as a substring of the name!) include stringtable-atom, bytestring-csv and packedstring.
Suggestion: Give a warning when the synposis is a prefix of the description." guest
3 Cabal library 362 Disallow uploads of libraries that provide binaries called 'test' and similar defect normal 2008-09-28T22:04:59-0700 2009-01-22T07:43:12-0800 "Some libraries (example, haskore), provide an executable called 'test' or 'Test' or other similarly named private test programs. These are however installed onto the users system, or prevented from doing so, as they conflict with /usr/bin/test
uploading should prevent and warn if people use unix builtin names as executables, particularly 'test'.
-- don stewart" guest
3 Cabal library 370 Check that packages declare language extensions accurately defect normal 2008-10-13T12:36:26-0700 2008-10-13T13:36:10-0700 "We'd like to make it possible to ensure all code on hackage lists precisely the -X extensions it uses.
This kind of thing
-XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable
Now, these should be listed in both the .cabal file, and in individual modules that require the extensions. We can check this by loading the modules in ghci.
The end result: we'd be able to filter on extensions. Researchers would be able to see precisely which extensions are used, and in what packages.
A simple 'is this type correct' script:
{{{
#!/bin/sh
echo ""Checking type correctness ... ""
f=`mktemp`
for i in *.hs ; do
ghci -cpp -Iinclude -v0 $i < /dev/null
done > $f 2>&1
if cmp -s $f /dev/null ; then
echo ""Passed""
true
else
echo ""Failed""
cat $f
false
fi
}}}" guest
3 cabal-install tool 371 cabal-install can break installed packages by rebuilding dependents defect normal 2008-10-14T20:55:18-0700 2012-03-08T01:05:11-0800 "Install plans sometime involve rebuilding a package. This is not a safe operation however. Rebuilding a package can and does change its ABI.
The ideal solution is to use a persistent package store like nix. That would mean we do not replace any installed package, just add new instances.
In the mean time however one solution would be to extend an install plan the re-installs a package such that it rebuilds all reverse dependencies too." duncan
3 Cabal library 374 Hs-Source-Dirs in nested If must be respected by 'sdist' defect normal 2008-10-17T07:09:09-0700 2012-01-05T08:31:03-0800 "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.
" guest
3 hackageDB website 385 "some packages incorrectly shown as ""program"" but are actually ""library and program""" defect minor 2008-10-31T08:03:28-0700 2009-12-01T04:29:11-0800 "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" guest
3 User guide 386 Cabal changelog is not in user's guide defect normal 2008-10-31T09:47:16-0700 2012-01-05T08:30:12-0800 "The Cabal user's guide doesn't contain the changelog. This means, for instance, that one can't view it in the offline documentation distributed with GHC.
It's also not directly linked from http://www.haskell.org/cabal/, making it altogether a bit better hidden than it should be." Deewiant
4 cabal-install tool 405 cabal-install finds non-existent conflict due to picking base 3 defect normal 2008-11-13T05:56:09-0800 2012-04-05T00:02:31-0700 "While creating a new package syb-0.2 (which supersedes syb-0.1), we have in the .cabal file:
{{{
build-depends: base >= 4.0
}}}
'cabal configure -v' outputs:
{{{
(...)
Configuring syb-0.2...
Dependency base >=4.0: using base-4.0.0.0
Dependency mtl >=1.1.0.2: using mtl-1.1.0.2
Using Cabal-1.6.0.1 compiled by ghc-6.10
(...)
}}}
'cabal install -v' outputs:
{{{
(...)
Reading available packages...
Resolving dependencies...
selecting syb-0.2 (hackage) and discarding mtl-1.0, 1.1.0.0 and 1.1.0.1
selecting mtl-1.1.0.2 (installed or hackage)
selecting
cabal: dependencies conflict: base-3.0.3.0 requires syb ==0.1.0.0 however
syb-0.1.0.0 was excluded because syb-0.2 was selected instead
syb-0.1.0.0 was excluded because of the top level dependency syb ==0.2
}}}
However, 'runghc Setup.hs install' proceeds without problems." dreixel
3 cabal-install tool 410 cabal sdist does not call the sdist build hook in custom Setup.hs defect normal 2008-11-20T10:14:15-0800 2012-04-07T13:13:27-0700 "The `cabal sdist` command only runs the default actions, it does not call the sdist hook that gets called if you `runghc Setup sdist`.
The problem is there is no external method for invoking the sdist hook. Calling `./setup sdist` performs the whole action, but we only want to prepare the tree and not tar it up, since `cabal sdist` uses internal tar code rather than calling an external tar program (which typically does not exist on windows)." duncan
3 cabal-install tool 412 build-reports: option is invalid in a config file defect normal 2008-11-21T18:24:06-0800 2012-04-16T05:37:48-0700 "With darcs (tonight) cabal and cabal-install, I see the generated .cabal/config includes the line '-- build-reports:', suggesting that this is a valid configuration option.
However, it is not. If one uncomments it to 'build-reports: True', then Cabal warns and apparently ignores one's configuration as corrupt:
gwern@craft:29302~>cabal update
Warning: Error parsing config file /home/gwern/.cabal/config:9: ""True""
Warning: Using default configuration.
Downloading package list from server
'http://hackage.haskell.org/packages/archive'
The syntax is valid, the True is correct, it's not listed as being part of a section. further, --build-reports is a valid CLI option:
gwern@craft:29304~>rm .cabal/config && mv config .cabal && cabal install --build-reports ztail [ 9:21PM]
Resolving dependencies...
Downloading hinotify-0.2...
[1 of 1] Compiling Main ( /tmp/TMPhinotify-0.2/hinotify-0.2/Setup.lhs, /tmp/TMPhinotify-0.2/hinotify-0.2/dist/setup/Main.o )
Linking /tmp/TMPhinotify-0.2/hinotify-0.2/dist/setup/setup ...
Downloading ztail-1.0...
........
Either the default config is lying/wrong, or the build-reports: option is busted." guest
3 cabal-install tool 419 cabal-install should handle packages that need a later Cabal version better defect normal 2008-12-01T06:57:40-0800 2012-03-06T10:56:20-0800 "I am using cabal-install 0.5.2. I have previously installed cgi (and other packages) locally. Now when I try to upgrade them all:
Resolving dependencies...
cabal: Couldn't read cabal file ""./cgi/3001.1.7.1/cgi.cabal""
I presumed that the starting point in that path was ~/.cabal/packages/hackage.haskell.org. In cgi/3001.1.7.1 there is just the tarball for the package but opening it and putting the .cabal file in the right place didn't help." jimburton
4 Cabal library 421 Cabal shouldn't try to build split-objs when ghc reports it does not support it defect normal 2008-12-01T09:57:26-0800 2012-01-05T08:10:40-0800 "It is possible to build ghc without support for object splitting. In such a case Cabal should refuse to work if the user enables split objs.
All one has to do is to parse the output of `ghc --info` (which is in a `Read/Show` format).
See also #24." duncan
3 Cabal library 422 Cabal should warn if using a version of ghc that is newer than Cabal knows about defect normal 2008-12-01T09:59:18-0800 2008-12-01T09:59:18-0800 "It seems to often happen that newer versions of ghc make changes that break old versions of Cabal. This is particularly a problem for `cabal-install` since that need not necessarily be upgraded when ghc is upgraded.
Probably it should warn if the major version is bigger than the known version at the time." duncan
3 Cabal library 424 build-depends in global section in new-style .cabal files are ignored defect normal 2008-12-03T09:22:10-0800 2010-08-26T00:31:26-0700 "http://hpaste.org/12669
In a .cabal file like:
{{{
name: music
version: 0.0
cabal-version: >= 1.2
build-type: Simple
build-depends: base == 4
library
exposed-modules:
Music
}}}
which uses new-style syntax but puts the build-depends in the global section, the build-depends get ignored.
It should either warn or reject this, or it should automatically propagate such global options into each buildable component." duncan
3 cabal-install tool 428 cabal update uses too much bandwidth defect normal 2008-12-05T04:49:07-0800 2012-03-06T10:50:59-0800 "`cabal update` appears to download a compressed tarball (>600k and growing), which is larger than most packages, takes a while over a slow line, and doesn't provide much info (`-v` just adds low-level details).
using `rsync` over the relevant parts of the directory tree ought to be faster (increasingly so as hackage keeps growing), use less bandwith, and be able to tell me which package descriptions have changed (although it would be nice to limit the latter info to new packages and changes to installed packages)." claus
3 cabal-install tool 429 Strange error that seems related to repos field in config defect normal 2008-12-06T14:33:45-0800 2010-08-21T14:14:53-0700 "I'm reporting this although I don't really know what the problem is.
I installed cabal-install using GHC 6.10.1. When I tried to use it, it complained that the it couldn't open the file 'Ê', or some other strange, seemingly random, one-character long file name. An strace revealed that just before trying to open the file it reads the repos: field from the config file in ~/.cabal. That field was set to ""hackage.haskell.org:http://hackage.haskell.org/packages/archive"". I tried removing the initial ""hackage.haskell.org:"", and them cabal-install works.
Not sure what this is, but I couldn't find something about it in the bug tracker after a quick search.
" waern
3 Cabal library 431 Distribution.Make requires to use sudo and --global defect normal 2008-12-12T18:50:11-0800 2012-01-05T08:12:09-0800 "wxHaskell is heavily depends on self generated file. So, wxHaskell uses Distribution.Make to cabalize wxcore package now. But it causes trouble when using cabal command to install wxHaskell (wx and wxcore) from Hackage.
Distribution.Make and cabal don't path any package databases options to configure script. So, we can't install wxHaskell (wx package) straightforward way. We must use following horrible command.
{{{
sudo cabal install wxcore --global
cabal install wx
}}}
See [http://sourceforge.net/tracker/index.php?func=detail&aid=2407551&group_id=73133&atid=536845 wxHaskell's bug tracker #2407551] and [http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00319.html wxhaskell-devel's thread].
Note: I tried to fix this problem by Custom Setup.lhs and Distribution.Make.WX. Attached file is that. But I can't get any package database information from Cabal and cabal. I checked configPackageDB flag's value by using unsafePerformIO.
{{{
optPackageDB = unsafePerformIO (print (configPackageDB flag) >> return [])
}}}
It always shows just NoFlag. Neither supplying package database option and cabal command affect that." shelarcy
4 Cabal library 438 Cabal should warn or fail if user specifies a bad configuration flag defect normal 2008-12-23T20:29:30-0800 2012-01-05T08:11:51-0800 "Let us take the example of Yi.
Yi specifies a flag:
{{{
flag ghcAPI
Description: Enable linking with GHC API for advanced features.
Default: False
}}}
The advanced features are nice indeed, and I wish to use them. So I configure thusly:
{{{
gwern@craft:33763~/bin/yi>runhaskell Setup configure --user -fghc-api
Configuring yi-0.5.3...
}}}
(Or perhaps I specify -fghcapi, or -fghc-API. There are a lot of quite reasonable permutations, and I suspect I have made every one of them over the past few months.)
The point is, the flag is *wrong*. Completely wrong. If we turn on --verbose, we notice that
{{{
Flags chosen: testing=True, hacking=False, cocoa=False, pango=False,
gtk=False, vty=True, ghcapi=False
}}}
The user is not going to get what she requested. Worse, the user has no idea! Everything looks dandy! There is not the slightest indication that something bad has happened. Half an hour later when Yi has compiled and installed, any user trying to use the Shim.* modules in their yi.hs is in for an unpleasant surprise.
So the basic point here is: if the user specifies a flag, and the flag doesn't match any flags in the cabal file, *something* is wrong. Either the cabal file is damaged in someway, or the user mistyped. I think an error would be perfectly reasonable here, in the same way that missing fields is a reasonable reason for erroring out; but at a minimum a warning is warranted." guest
3 cabal-install tool 446 Can't set path to tools in ~/.cabal/config defect normal 2009-01-07T11:27:06-0800 2012-03-03T08:18:36-0800 "The config file for cabal-install lets me set all sorts of useful paths, except for the non-compiler tools. In other words, there's no config file mapping for the --with-PROG or --PROG-options flags, which would be really convenient.
(At least, when I tried the obvious versions, it didn't work. Maybe missing docs somewhere?)" awick
3 Cabal library 454 file permissions of installed files on windows defect normal 2009-01-12T17:12:50-0800 2012-01-05T08:05:41-0800 "When installing a binary on Windows Vista using ghc 6.10.1 and Cabal 1.6.0.1, it is not accessible for ordinary users. Old binaries installed with ghc 6.8.2 and Cabal 1.4 had ""read"" and ""execute"" permissions set for ""all users"", while new binaries have only permissions set for ""administrators"".
Cabal should set ""read"" and ""execute"" permissions for ""all users"" for binaries.
A workaround is to manually set these permissions using the executable's properties dialog." Toxaris
2 Cabal library 458 inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure defect normal 2009-01-16T07:56:12-0800 2012-01-05T08:28:56-0800 "We have a mismatch between the cabal Setup scripts which ignore `LDFLAGS` etc and provide `--extra-lib-dirs` instead, and some `./configure` scripts which grab the `CCFLAGS` etc and bung them into a `.buildinfo` file.
This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface.
We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file.
Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages.
We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system.
A case in point is the curl package. It has a .buildinfo file like:
{{{
cc-options: @CPPFLAGS@
ld-options: @LDFLAGS@
}}}
The `./configure` script checks:
{{{
AC_TRY_CPP([#include ],,[no_curl=yes])
}}}
Which uses the `CPPFLAGS`.
So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the `--extra-lib-dirs=` and `--extra-include-dirs=` Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to `build-type: Simple` and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful.
See also #262 which should make these checks redundant." duncan
4 cabal-install tool 460 find the http proxy on windows more reliably defect normal 2009-01-16T16:22:28-0800 2012-01-05T08:05:35-0800 "Some network setups (particularly corporate ones) do not use a static proxy set in the windows registry but use [http://msdn.microsoft.com/en-us/library/aa384240%28VS.85%29.aspx ""AutoProxy""]. This is a rather complex protocol involving DHCP, dns and requires a !JavaScript interpreter.
However the [http://msdn.microsoft.com/en-us/library/aa384273%28VS.85%29.aspx WinHTTP] library comes with Windows as of Win2k SP3, WinXP SP1, Win2k3 and Vista.
It's got a bunch of functions for dealing with this AutoProxy stuff, [http://msdn.microsoft.com/en-us/library/aa384122(VS.85).aspx including sample code]. In particular the main function we want is [http://msdn.microsoft.com/en-us/library/aa384097(VS.85).aspx WinHttpGetProxyForUrl]
So we could try either statically linking to this, or perhaps doing some dynamic !GetProcAddress funky stuff.
Reading more closely, it seems that this only works if the setup is using an !AutoProxy setup. This documentation may be more relevant:
* [http://msdn.microsoft.com/en-us/library/aa383660(VS.85).aspx Discovery Without an Auto-Config File]
* [http://msdn.microsoft.com/en-us/library/aa384096(VS.85).aspx WinHttpGetIEProxyConfigForCurrentUser]
* [http://msdn.microsoft.com/en-us/library/aa384095(VS.85).aspx WinHttpGetDefaultProxyConfiguration]
It seems that there are some performance issues with !AutoProxy but any caching has to be fairly careful since the proxy information can change." duncan
3 Cabal library 465 default global install on windows is a problem defect normal 2009-01-19T10:26:53-0800 2010-03-21T04:41:26-0700 "Lots of windows users have problems installing things globally. Some are using multi-user systems. More are using Vista where it seems that even when they are running as administrator they cannot install files in `C:\Program Files\`.
We should revisit the decision to install globally and see if we cannot find a default that works better. Failing by default is bad.
We may also want to try to improve the checking beforehand to check if we would have permissions to write into the target directories. If not we can fail at configure time rather than waiting until install time and failing ungracefully.
This needs someone who knows and cares about windows. Particularly for the Vista aspects." duncan
3 Cabal library 466 datadir does not follow prefix on windows (for libs) defect normal 2009-01-19T10:27:00-0800 2010-03-31T12:34:00-0700 "On Windows the `--datadir` is set independently of the `--prefix` (at least for libraries). This is actually quite annoying because it's not discoverable and when you do discover it you've got to set the datadir along with the prefix on the command line or in the config file.
The problem is to do with relocatable packages and data files.
Suppose you have a library that has data files. For a hypothetical example how about some Unicode library that uses data files of character traits. Now we want to use that library in a program and we want to have that program be relocatable. That means that at runtime the library needs to be able to locate its data files. But the place where the library was installed is completely independent of where the .exe is being run from.
One way to make this appear to work is for the library data directory to not really be relocatable, then it looks like we can relocate the .exe and have it still work. Of course the .exe is not very re-locatable, in particular it cannot be relocated to another machine. This is often the use case for relocatable packages on Windows.
Perhaps another solution would be to place the burden of finding the data files on the executable, or at least on the process of preparing the relocatable executable. If we made the process of generating a relocatable package more explicit we could include in that process checking for dependent library packages that use data files. We could then inform the packager and/or copy/link the necessary data files into a place where the library code will be able to find them relative to the executable. See #469." duncan
3 cabal-install tool 471 check for ambigious module names defect normal 2009-01-20T15:51:36-0800 2012-03-06T04:04:08-0800 "Consider a example:
{{{
build-depends:
base, bytestring
}}}
The package `base-2.1.x` and `bytestring-0.9.x` both provide the module `Data.ByteString`. This means it is impossible to pick both packages as direct dependencies of any single package.
We should check for this situation at configure time and/or in cabal-install when planning an installation plan.
Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420)." duncan
2 cabal-install tool 474 cabal-install needlessly reinstalls an existing package defect normal 2009-01-23T11:18:03-0800 2012-04-09T04:27:56-0700 "With ghc-6.10.1, Cabal-1.6.0.1 and cabal-install-0.6 (or HEAD):
{{{
$ cabal install cabal-install --dry-run -v
[..]
Reading available packages...
Resolving dependencies...
[..]
selecting Cabal-1.6.0.1 (installed or hackage)
[..]
selecting process-1.0.1.1 (installed or hackage) and discarding filepath-1.0,
process-1.0.0.0 and 1.0.1.0
[..]
In order, the following would be installed:
Cabal-1.6.0.1 (reinstall) changes: process-1.0.1.0 -> 1.0.1.1
cabal-install-0.6.0 (new package)
}}}
The `ghc` package depends on `Cabal-1.6.0.1` and `process-1.0.1.0`, so rebuilding `Cabal` to depend on `process-1.0.1.1` causes `ghc` to have inconsistent dependencies. In particular:
{{{
$ cabal install cabal-install
[succeeds, but reinstalls Cabal-1.6.0.1]
$ cabal install ghci-haskeline
Resolving dependencies...
cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however
process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1
}}}
It seems like the right thing to do would be to use `process-1.0.1.0` when building `cabal-install`." judah
3 hackageDB website 498 package downloads confuse IE6 and webkit-gtk browsers defect normal 2009-02-13T02:53:42-0800 2011-01-23T04:01:30-0800 "In IE6 the `.tar.gz` packages from the Hackage website get downloaded and saved by the browser with the wrong name. For example `foo-1.0.tar.gz` gets saved as `foo-1.0.tar.tar`.
Currently the apache config for the hackage website is such that it send these headers for `.tar.gz` files:
{{{
Content-Type: application/x-tar
Content-Encoding: x-gzip
}}}
This apparently confuses IE6. This has been [http://mail-archives.apache.org/mod_mbox/httpd-dev/200302.mbox/%3c5.2.0.9.2.20030204125407.02768620@pop3.rowe-clan.net%3e. reported elsewhere previously].
So we are looking for help in finding a workaround. We want to adjust our apache config so that for the IE6 user agent it reports a mime time and encoding that will make IE6 save the file properly. For example we guess that sending `Content-Type: application/x-gzip` and no `Content-Encoding` would make IE6 do the right thing.
So how do we actually configure apache to do this? Can we get some help testing it?" duncan
4 cabal-install tool 511 requiring consistent package dependencies can give surprising results defect normal 2009-02-27T01:58:58-0800 2012-04-07T07:33:25-0700 "I tried running this command:
{{{
sudo cabal install test-framework test-framework-hunit test-framework-quickcheck test-framework-quickcheck2
}}}
However, Cabal barfed with:
{{{
Resolving dependencies...
cabal: cannot configure test-framework-quickcheck-0.2.1. It requires
QuickCheck >=1.1 && <2
For the dependency on QuickCheck >=1.1 && <2 there are these packages:
QuickCheck-1.1.0.0 and QuickCheck-1.2.0.0. However none of them are available.
QuickCheck-1.1.0.0 was excluded because QuickCheck-2.1.0.1 was selected
instead
QuickCheck-1.1.0.0 was excluded because test-framework-quickcheck2-0.2.1
requires QuickCheck >=2.1.0.0
QuickCheck-1.2.0.0 was excluded because QuickCheck-2.1.0.1 was selected
instead
QuickCheck-1.2.0.0 was excluded because test-framework-quickcheck2-0.2.1
requires QuickCheck >=2.1.0.0
}}}
This seems to be because the quickcheck and quickcheck2 providers for test-framework by design depend on disjoint versions of QuickCheck. This should not confuse cabal install, since installing the packages sequentially in any order works fine:
{{{
sudo cabal install test-framework test-framework-hunit test-framework-quickcheck
sudo cabal install test-framework-quickcheck2
}}}" guest
4 Cabal library 513 Version of Cabal lib used to build Setup.hs is not tracked. defect normal 2009-02-27T10:02:11-0800 2009-02-27T10:02:11-0800 "Neil ran into these symptoms:
{{{
Cabal documents itself as having a --builddir command to
change the placement of dist stuff, which is fantastic.
However, running with GHC 6.8.3, Cabal 1.6.0.2, I get:
cabal build --builddir=../../../_make/Tools/ext/haddock-0.9/dist
setup.exe: Unrecognised flags:
--builddir=../../../_make/Tools/ext/haddock-0.9/dist
i.e. cabal accepts the --builddir command, but the setup
that cabal builds doesn't. Why?
}}}
Turns out it was because the `Setup` executable had been compiled previously using an older Cabal lib that did not understand the `--builddir` flag.
Two things are needed to fix this, one is a proper checked specification of the command line interface so that cabal-install always knows what flags the `Setup` supports. The other is to track the version of the Cabal lib used to build the `Setup` and to recompile it if that changes.
Note that this should happen automagically if we use a proper dependency tracking framework. In the mean time it'd require keeping an extra state file in `dist/setup`." duncan
3 Cabal library 521 Check that module names match file names case-sensitively on Windows defect normal 2009-03-13T07:06:47-0700 2009-03-13T07:06:47-0700 It's possible to specify a module name like `Foo.Bar` but have ghc actually find `foo/Bar.hs` or something. This is ok for local use but we should warn or reject it for distributed packages. duncan
3 Cabal library 526 hugs-options aren't passed to ffihugs defect normal 2009-03-17T23:34:29-0700 2012-01-05T08:10:56-0800 "Options in hugs-options aren't passed through to ffihugs, most
importantly -98 and +o are the ones we'd like to pass. For enabling
the +o flag Hugs-Sept06 does not honor:
* pragma {-# LANGUAGE !OverlappingInstances #-}
* pragma {-# OPTIONS_HUGS +o #-}
* cabal extensions: !OverlappingInstances
And the -98 flag has similar issues. Therefore this is a real
problem.
Immediate solution: The options set in hugs-options should be passed
to ffihugs as well. As of Cabal 1.6 they are not passed (verified
by Duncan Coutts). The two programs accept all the same options,
so this is valid.
Ideal solution: Based on the extensions field, Cabal should
automatically determine whether -98 and +o need to be enabled (for
both hugs and ffihugs).
A simple example demonstrating this bug can be found in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest" guest
3 Cabal library 527 CPP not called before ffihugs defect normal 2009-03-17T23:36:42-0700 2010-03-18T20:45:21-0700 "When building for Hugs, if CPP is being used in conjunction with FFI, then cpp/cpphs
is not called before ffihugs is called. Thus, users must pass an
-F flag to ffihugs in order to declare a code filter (and must pass
all cpp-options to -F manually). For example:
{{{ --ffihugs-option=-F'cpp -P -traditional -D__HUGS__ -D__BLAH__' }}}
This requires duplicating the build specifications, which defeats
the point of Cabal. Also it leads to tricky issues about ensuring
the proper level of quoting/escaping. (e.g. using the plural,
--ffihugs-options=..., breaks it. Wrapping the -F'cpp...' in double
quotes breaks it.)
A simple example of this bug can be seen in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest" guest
3 Cabal library 535 Mac OS X 10.4 can't locate gmp defect normal 2009-03-31T22:52:16-0700 2012-01-05T07:57:40-0800 "Linking Setup ...
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp
collect2: ld returned 1 exit status
Error during cabal-install bootstrap:
Compiling the Setup script failed
I'm _sure_ that this has something to do with my binary ghc installation, since I found I could not compile with ghc either for the same reason. I set LD_LIBRARY_PATH to point to /sw/lib to point to the location of gmp (fink). This fixed my ghc compilation problem, but the bootstrap script still fails." guest
4 cabal-install tool 538 --constraint= is not respected for base defect normal 2009-04-02T18:02:36-0700 2012-04-08T10:32:23-0700 "the --constraint= flag apparently does nothing when the constraint involves base.
e.g. to install directory-1.0.0.3, that imports Control.Exception.Base and only lists ""base"" in build-depends, you need to add ""base >= 4"", but cabal install directory --constraint=""base >= 4"" picks base-3.0.3.0 anyway.
{{{
saizan@astarte:~/trash/directory-1.0.0.3$ cabal configure --constraint=""base >= 4""
Resolving dependencies...
Configuring directory-1.0.0.3...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/stat.h... (cached) yes
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h
config.status: include/HsDirectoryConfig.h is unchanged
saizan@astarte:~/trash/directory-1.0.0.3$ cabal build -v
Creating dist/build (and its parents)
Creating dist/build/autogen (and its parents)
Preprocessing library directory-1.0.0.3...
Building directory-1.0.0.3...
Building library...
Creating dist/build (and its parents)
/usr/local/bin/ghc -package-name directory-1.0.0.3 --make -hide-all-packages -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-include -optPdist/build/autogen/cabal_macros.h -#include ""HsDirectory.h"" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.3.0 -package filepath-1.1.0.1 -package old-time-1.0.0.1 -package unix-2.3.1.0 -O -XCPP -XForeignFunctionInterface System.Directory
System/Directory.hs:81:7:
Could not find module `Control.Exception.Base':
it is a member of package base, which is hidden
}}}" Saizan
4 cabal-install tool 542 installing cabal-install refers to editing nonexistent file $HOME/.cabal/config defect minor 2009-04-19T14:26:23-0700 2012-03-06T02:40:17-0800 "{{{cabal --help}}} invites me to edit a file that doesn't exist, and I can't easily find documentation for the file:
{{{
: nr@homedog 5520 ; cabal --help
This program is the command line interface to the Haskell Cabal infrastructure.
...
You can edit the cabal configuration file to set defaults:
/home/nr/.cabal/config
: nr@homedog 5521 ; ls -l /home/nr/.cabal/config
ls: cannot access /home/nr/.cabal/config: No such file or directory
}}}
" nr
3 Cabal library 543 ghc global package db should live in /var not /usr defect normal 2009-04-19T14:50:43-0700 2012-01-05T08:08:02-0800 "cabal requires root privileges in order to modify files in /usr/lib/ghc-6.8.2. I'm reporting this as a defect in the tool, since it was told to install in /usr/local/cabal, and it seems unreasonable that cabal should require root privileges when these are not required for installing into its target directory.
I am less well informed about the Linux Filesystem Standard, but I believe that files in /usr/lib are supposed to be immutable. If I'm correct, cabal is violating that standard in a major way. If you must have a mutable {{{package.conf}}}, put it in {{{/var/lib/ghc-6.8.2}}}, and make it group writable by a suitable group (which you may need to create). I'm cc-ing ghc-devel on this one because the two groups will probably have to cooperate.
{{{
: nr@homedog 5548 ; cabal install graphmod
Resolving dependencies...
Downloading dotgen-0.2...
Configuring dotgen-0.2...
Preprocessing library dotgen-0.2...
Building dotgen-0.2...
[1 of 1] Compiling Text.Dot ( Text/Dot.hs, dist/build/Text/Dot.o )
/usr/bin/ar: creating dist/build/libHSdotgen-0.2.a
Installing library in /usr/local/cabal/lib/dotgen-0.2/ghc-6.8.2
Registering dotgen-0.2...
Reading package info from ""dist/installed-pkg-config"" ... done.
Unable to rename ""/usr/lib/ghc-6.8.2/package.conf"" to ""/usr/lib/ghc-6.8.2/package.conf.old""
Saving old package config file... ghc-pkg.bin: /usr/lib/ghc-6.8.2/package.conf: renameFile: permission denied (Permission denied)
Downloading haskell-lexer-1.0...
Configuring haskell-lexer-1.0...
Preprocessing library haskell-lexer-1.0...
Building haskell-lexer-1.0...
[1 of 6] Compiling Language.Haskell.Lexer.Position ( Language/Haskell/Lexer/Position.hs, dist/build/Language/Haskell/Lexer/Position.o )
Language/Haskell/Lexer/Position.hs:25:4:
Warning: Pattern match(es) are overlapped
In a case alternative: '\n' -> ...
[2 of 6] Compiling Language.Haskell.Lexer.Tokens ( Language/Haskell/Lexer/Tokens.hs, dist/build/Language/Haskell/Lexer/Tokens.o )
[3 of 6] Compiling Language.Haskell.Lexer.Utils ( Language/Haskell/Lexer/Utils.hs, dist/build/Language/Haskell/Lexer/Utils.o )
[4 of 6] Compiling Language.Haskell.Lexer.Lex ( Language/Haskell/Lexer/Lex.hs, dist/build/Language/Haskell/Lexer/Lex.o )
[5 of 6] Compiling Language.Haskell.Lexer.Layout ( Language/Haskell/Lexer/Layout.hs, dist/build/Language/Haskell/Lexer/Layout.o )
[6 of 6] Compiling Language.Haskell.Lexer ( Language/Haskell/Lexer.hs, dist/build/Language/Haskell/Lexer.o )
/usr/bin/ar: creating dist/build/libHShaskell-lexer-1.0.a
Installing library in /usr/local/cabal/lib/haskell-lexer-1.0/ghc-6.8.2
Registering haskell-lexer-1.0...
Reading package info from ""dist/installed-pkg-config"" ... done.
Unable to rename ""/usr/lib/ghc-6.8.2/package.conf"" to ""/usr/lib/ghc-6.8.2/package.conf.old""
Saving old package config file... ghc-pkg.bin: /usr/lib/ghc-6.8.2/package.conf: renameFile: permission denied (Permission denied)
cabal: Error: some packages failed to install:
dotgen-0.2 failed during the final install step. The exception was:
exit: ExitFailure 1
graphmod-1.1.3 depends on haskell-lexer-1.0 which failed to install.
haskell-lexer-1.0 failed during the final install step. The exception was:
exit: ExitFailure 1
: nr@homedog 5549 ;
}}}
" nr
3 Cabal library 546 look for haddock in ghc's bin dir before using findExecutable defect normal 2009-04-22T09:35:36-0700 2009-04-22T09:35:36-0700 "With current versions of haddock it's important to pick a version that's consistent with the ghc in use. Normally we use `System.Directory.findExecutable` to find tools like `haddock`. However on Windows, the Win32 `SearchPath` function looks not just in the `%PATH%`. It looks first in the directory where the .exe of the current process lives (which might either be `runghc.exe` or it might be `cabal.exe`) and only secondarily in the `%PATH%`.
So, for ghc, Cabal should look for haddock first in ghc's bin dir and then if it's not there, use `findExecutable` to look in various other places.
Reported originally on the [http://haskell.org/pipermail/cabal-devel/2009-April/005161.html mailing list] and as a [http://hackage.haskell.org/trac/ghc/ticket/3186 ghc ticket]." duncan
4 cabal-install tool 550 bad error message when proxy cannot be resolved defect minor 2009-04-29T07:50:24-0700 2012-03-06T02:48:14-0800 "As reported by a user:
{{{
when I run cabal update I get some strange error:
% cabal update
Downloading the latest package list from hackage.haskell.org
cabal: user error (openTCPConnection: host lookup failure for """")
}}}
Turns out the problem was that `http_proxy` environment variable was set to """" (ie the empty string).
The problem with the error of course is that we've no idea what it is it thinks is """", there's no indication that it's the proxy. If it said that it encountered the problem while contacting the proxy that'd be an improvement." duncan
3 Cabal specification 557 Spec does not define the installed package info fields defect normal 2009-05-31T15:29:42-0700 2009-05-31T15:29:42-0700 "http://haskell.org/cabal/proposal/x272.html#IPD
Section 3.4 of the spec ""Syntax of installed package description"" is empty. It should define all the fields and their contents." duncan
2 Cabal library 564 Cabal doesn't use LD options when testing linking defect normal 2009-06-24T09:00:47-0700 2012-01-05T08:32:55-0800 "
When checking to see if the C libraries are available, Cabal isn't using the LD options that it has been given.
This example is using GHC's `ghc-cabal` program, but that's just a thin wrapper around the Cabal library. It looks like it's in `checkForeignDeps` in `Distribution.Simple.Configure` that it goes wrong. Note that `--ld-options=""-L/usr/local/lib ""` is passed, but not used in the `gcc` commands that do the linking.
{{{
$ ""inplace/bin/ghc-cabal"" configure --with-ghc=""/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc"" --with-ghc-pkg=""/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg"" --with-gcc=""gcc"" --configure-option=--with-cc=""gcc"" --with-hscolour=""/usr/local/bin/HsColour"" --configure-option=CFLAGS=""-O -I/usr/local/include "" --configure-option=LDFLAGS=""-L/usr/local/lib "" --gcc-options=""-O -I/usr/local/include "" --ld-options=""-L/usr/local/lib "" -v3 -- dist-install libraries/integer-gmp
[boring stuff skipped]
(""sh"",[""configure"",""--with-compiler=ghc"",""--with-cc=gcc"",""CFLAGS=-O -I/usr/local/include "",""LDFLAGS=-L/usr/local/lib ""])
checking build system type... x86_64-unknown-openbsd4.5
checking host system type... x86_64-unknown-openbsd4.5
checking target system type... x86_64-unknown-openbsd4.5
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for __gmpz_fdiv_qr in -lgmp... yes
configure: creating ./config.status
config.status: creating integer-gmp.buildinfo
config.status: creating gmp/config.mk
Reading parameters from ./integer-gmp.buildinfo
(""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-O"",""-I/usr/local/include"",""-D__GLASGOW_HASKELL__=611"",""-I."",""-I/home/kili/src/ghc/ghc-head/includes"",""-I/home/kili/src/ghc/ghc-head/libffi/build/include"",""-lgmp""])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
(""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-lgmp""])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
(""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-lgmp""])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
(""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-c"",""-O"",""-I/usr/local/include"",""-D__GLASGOW_HASKELL__=611"",""-I."",""-I/home/kili/src/ghc/ghc-head/includes"",""-I/home/kili/src/ghc/ghc-head/libffi/build/include""])
ghc-cabal: Missing dependency on a foreign library:
* Missing C library: gmp
This problem can usually be solved by installing the system package that
provides this library (you may need the ""-dev"" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
}}}
" igloo
4 cabal-install tool 565 sdist is broken on Windows defect normal 2009-06-29T13:32:13-0700 2012-03-06T02:26:53-0800 "Read it and weep:
{{{
E:\Orphi\Haskell\_Hackage\AOC-HalfInteger>cabal configure
Resolving dependencies...
Configuring AOC-HalfInteger-1.0...
E:\Orphi\Haskell\_Hackage\AOC-HalfInteger>cabal -v3 sdist
Creating dist\src (and its parents)
Building source dist for AOC-HalfInteger-1.0...
Creating dist\src\sdist.1876\AOC-HalfInteger-1.0 (and its parents)
Creating dist\src\sdist.1876\AOC-HalfInteger-1.0\.\Data (and its parents)
copy .\Data\HalfInteger.hs to
dist\src\sdist.1876\AOC-HalfInteger-1.0\.\Data\HalfInteger.hs
Creating dist\src\sdist.1876\AOC-HalfInteger-1.0 (and its parents)
copy Licence.txt to dist\src\sdist.1876\AOC-HalfInteger-1.0\Licence.txt
Preprocessing library AOC-HalfInteger-1.0...
Creating dist\src\sdist.1876\AOC-HalfInteger-1.0 (and its parents)
copy Setup.hs to dist\src\sdist.1876\AOC-HalfInteger-1.0\Setup.hs
copy .\AOC-HalfInteger.cabal to
dist\src\sdist.1876\AOC-HalfInteger-1.0\.\AOC-HalfInteger.cabal
Source tarball created: dist\AOC-HalfInteger-1.0.tar.gz
cabal: dist\src\sdist.1876\AOC-HalfInteger-1.0\Data\HalfInteger.hs: removeFile: permission denied (Permission denied)
}}}" Orphi
3 Cabal library 566 Don't try and resolve dependencies for packages that are not buildable defect normal 2009-07-03T05:55:29-0700 2012-01-05T07:56:13-0800 "I had a component like this:
{{{
Executable edit-distance-benchmark
Main-Is: Text/EditDistance/Benchmark.hs
if flag(splitBase)
Build-Depends: base >= 3 && < 5, array >= 0.1, random >= 1.0, old-time >= 1.0, process >= 1.0,
parallel >= 1.0, unix >= 2.3
else
Build-Depends: base < 3,
parallel >= 1.0, unix >= 2.3
if !flag(benchmark)
Buildable: False
Ghc-Options: -O2 -fvia-C -Wall
}}}
However, I've only just found out that this meant that you couldn't install any parts of my package on Windows, because Cabal tried to resolve the ""unix"" dependency even if ""benchmark"" was False (the default)!
I've solved this like so:
{{{
Executable edit-distance-benchmark
Main-Is: Text/EditDistance/Benchmark.hs
if !flag(benchmark)
Buildable: False
else
if flag(splitBase)
Build-Depends: base >= 3 && < 5, array >= 0.1, random >= 1.0, old-time >= 1.0, process >= 1.0,
parallel >= 1.0, unix >= 2.3
else
Build-Depends: base < 3,
parallel >= 1.0, unix >= 2.3
Ghc-Options: -O2 -fvia-C -Wall
}}}
But really Cabal should not need to resolve dependencies for things that are not buildable." batterseapower
3 Cabal library 575 Cabal configure leaves behind temporary files on Windows defect normal 2009-08-18T17:13:28-0700 2009-08-18T17:13:28-0700 "Every time 'configure' is run on Windows, a single .exe is left behind in the user's %TEMP% directory and is never removed.
The problem is in checkForeignDeps in Distribution.Simple.Configure, specifically when GCC is run in builds. A temporary filename is created to hold the output, but it has no extension. When GCC is given this filename for output it appends .exe extension automatically. Since this is a different filename it never gets removed.
Fix is to specify an extension for the output, like "".tmp"", so GCC will actually put it there." guest
3 Cabal library 577 an executable and library differing in capitalization use the same build dir on case-insensitive filesystems defect normal 2009-08-26T18:15:38-0700 2009-08-27T08:29:48-0700 "Discussion from #darcs:
{{{
[5:56pm]
While compiling the Darcs library, the build process creates a directory called $BUILDDIR/build/Darcs. While compiling the Darcs executable, it creates $BUILDDIR/build/darcs. On Mac OS X, these pathnames both name a common directory.
[5:57pm]
yeah, that's mildly irritating
[5:57pm]
I have to run dist/build/Darcs/darcs (tab-completion)
[5:57pm]
Does this affect the output of the build?
[5:57pm]
no apparent problems here
[5:58pm]
OK.
[5:58pm]
(You could, of course, create the directory with a lowercase name to begin with and then build.)
[5:58pm]
(Also, some shells, such as zsh, will do case-insensitive completion.)
[5:58pm]
I guess no other cabal package out there simultaneously has a library starting with Foo as a top level bit of namespace and an executable named foo
[5:58pm]
Riastradh: bash of course can do case-insenistive completion if figured
[5:58pm]
*configured
[5:59pm]
kowey: xmonad?
[5:59pm]
oh yeah!
[5:59pm]
import XMonad.*... 'exec xmonad'
[5:59pm]
and xmonad ain't the only example either
[6:00pm]
yi, autoproc... anything doing the executable-library thing is likely to have that
}}}
" simonmic
4 Cabal library 589 FreeBSD compiles should automatically add --extra-lib-dirs=/usr/local/lib defect normal 2009-09-21T12:12:34-0700 2012-01-05T08:09:21-0800 "FreeBSD stores a number of standard things in /usr/local/lib, such as the 'curl' libraries that darcs needs to compile against. Cabal should detect that FreeBSD is the platform and look in this lib directory automatically.
Reference my experience trying to install darcs on FreeBSD:
http://www.mail-archive.com/darcs-users@darcs.net/msg12611.html
" markstos
3 Cabal library 592 cabal test does not detect that cabal build needs to be re-run defect normal 2009-09-28T23:32:27-0700 2012-04-24T20:09:46-0700 "This is a frequently recurring source of confusion in the Darcs team.
A: Such and such test fails
B: Have you re-run cabal build?
A: Oh, no I haven't
First seen on http://bugs.darcs.net/issue1299
" kowey
3 cabal-install tool 597 non-exhaustive patterns when trying to install base defect minor 2009-10-02T17:03:06-0700 2012-04-09T07:44:50-0700 "I was trying to install regex-dfa. I should mention that I have library profiling enabled in my cabal-install config. So when a dependency claims to be hidden I usually just reinstall it and everything works.
Here, I tried that and base showed up as a dependency (shouldn't I have the profiled version of base already?), and when I tried to cabal install base, I get a funny error.
Transcript below (note that I've selected 1.6.0.2 from the version drop down, but my version is actually 1.6.0.3, but isn't in the list). My GHC version is also not in the lits. I have 6.10.4.
{{{
$ cabal --version
cabal-install version 0.6.2
using version 1.6.0.3 of the Cabal library
$ cabal install regex-dfa
Resolving dependencies...
[1 of 1] Compiling Main ( /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-base-0.93.18737/regex-base-0.93.1/Setup.hs, /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-base-0.93.18737/regex-base-0.93.1/dist/setup/Main.o )
Linking /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-base-0.93.18737/regex-base-0.93.1/dist/setup/setup ...
Configuring regex-base-0.93.1...
Warning: No 'build-type' specified. If you do not need a custom Setup.hs or
./configure script then use 'build-type: Simple'.
Preprocessing library regex-base-0.93.1...
Building regex-base-0.93.1...
[1 of 4] Compiling Text.Regex.Base.RegexLike ( Text/Regex/Base/RegexLike.hs, dist/build/Text/Regex/Base/RegexLike.o )
[2 of 4] Compiling Text.Regex.Base.Context ( Text/Regex/Base/Context.hs, dist/build/Text/Regex/Base/Context.o )
[3 of 4] Compiling Text.Regex.Base ( Text/Regex/Base.hs, dist/build/Text/Regex/Base.o )
[4 of 4] Compiling Text.Regex.Base.Impl ( Text/Regex/Base/Impl.hs, dist/build/Text/Regex/Base/Impl.o )
[1 of 4] Compiling Text.Regex.Base.RegexLike ( Text/Regex/Base/RegexLike.hs, dist/build/Text/Regex/Base/RegexLike.p_o )
[2 of 4] Compiling Text.Regex.Base.Context ( Text/Regex/Base/Context.hs, dist/build/Text/Regex/Base/Context.p_o )
[3 of 4] Compiling Text.Regex.Base ( Text/Regex/Base.hs, dist/build/Text/Regex/Base.p_o )
[4 of 4] Compiling Text.Regex.Base.Impl ( Text/Regex/Base/Impl.hs, dist/build/Text/Regex/Base/Impl.p_o )
ar: creating archive dist/build/libHSregex-base-0.93.1.a
ar: creating archive dist/build/libHSregex-base-0.93.1_p.a
Installing library in /Users/dagit/.cabal/lib/regex-base-0.93.1/ghc-6.10.4
Registering regex-base-0.93.1...
Reading package info from ""dist/installed-pkg-config"" ... done.
Writing new package config file... done.
Downloading regex-dfa-0.91...
[1 of 1] Compiling Main ( /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-dfa-0.918737/regex-dfa-0.91/Setup.hs, /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-dfa-0.918737/regex-dfa-0.91/dist/setup/Main.o )
Linking /var/folders/s-/s-WdqsnuGFyUGEeXB-+sZk+++TI/-Tmp-/regex-dfa-0.918737/regex-dfa-0.91/dist/setup/setup ...
Configuring regex-dfa-0.91...
Warning: No 'build-type' specified. If you do not need a custom Setup.hs or
./configure script then use 'build-type: Simple'.
Preprocessing library regex-dfa-0.91...
Building regex-dfa-0.91...
Text/Regex/DFA/Common.hs:6:7:
Could not find module `Data.IntMap':
it is a member of the hidden package `containers-0.2.0.1'
Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
regex-dfa-0.91 failed during the building phase. The exception was:
exit: ExitFailure 1
[04:55 PM][dagit@apricot~/local-data/regex-tests/darcs.net-regex-base]
$ cabal install containers-0.2.0.1
Resolving dependencies...
No packages to be installed. All the requested packages are already installed.
If you want to reinstall anyway then use the --reinstall flag.
[04:55 PM][dagit@apricot~/local-data/regex-tests/darcs.net-regex-base]
$ cabal install containers-0.2.0.1 --reinstall
Resolving dependencies...
Downloading containers-0.2.0.1...
Configuring containers-0.2.0.1...
Preprocessing library containers-0.2.0.1...
Building containers-0.2.0.1...
Data/IntMap.hs:182:7:
Could not find module `Data.Data':
it is a member of the hidden package `base'
Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
containers-0.2.0.1 failed during the building phase. The exception was:
exit: ExitFailure 1
[04:55 PM][dagit@apricot~/local-data/regex-tests/darcs.net-regex-base]
$ cabal install base
Resolving dependencies...
cabal: Distribution/Client/Dependency/TopDown.hs:170:37-73: Non-exhaustive patterns in lambda
[04:55 PM][dagit@apricot~/local-data/regex-tests/darcs.net-regex-base]
$ cabal install base
Resolving dependencies...
cabal: Distribution/Client/Dependency/TopDown.hs:170:37-73: Non-exhaustive patterns in lambda
}}}" guest
3 Cabal library 603 --with-PROG=prog option unclear in --help defect normal 2009-11-03T08:25:23-0800 2009-11-03T08:25:23-0800 "I expected the following to work on Cygwin:
{{{cabal install --with-cpp=`which cpp-3.exe` hgeometric}}}
, but apparently --with-cpp means cpphs.
The same issue probably also occurs on Windows. " fasta
4 cabal-install tool 608 Files that are only used by cabal setup are not recompiled when they change between runs of 'cabal build' defect normal 2009-11-14T16:17:34-0800 2012-03-06T02:08:01-0800 "Files that are only used by cabal setup are not recompiled when they change between runs of 'cabal build'.
Reproduction steps for the included cabal package:
- Run 'cabal configure && cabal build && cabal test'
- The test output should be ""I helped with lots of stuff!""
- Change the string in Distribution/Helper.hs to ""I didn't help with ""
- Rerun 'cabal configure && cabal build && cabal test' -- the output should change to ""I didn't help with lots of stuff!"", but nothing recompiles and the output doesn't change.
Although the attached cabal package is minimal, I've observed this behavior with darcs's Distribution/ShellHarness." guest
3 cabal-install tool 610 wxcore install fail on Vista defect normal 2009-11-22T05:41:25-0800 2012-03-06T01:59:49-0800 "Hi,
I'm trying to install the wx package onto my Windows Vista machine
using the command: ""cabal install wx"" and I am having a problem. The
problem is with the wxcore package. The error I get is the following:
setup.exe: wx-config: runGenProcess: does not exist (No such file or directory)
cabal: Error: some packages failed to install:
wx-0.12.1.2 depends on wxcore-0.12.1.2 which failed to install.
wxcore-0.12.1.2 failed during the configure step. The exception was:
exit: ExitFailure 1
I have downloaded CYGWIN and run the command from there, but I get the
exact same error. Any ideas as to what is going on?
Thanks,
Colm" guest
3 miscellaneous 617 bootstap.sh: post-install message doesn't make sense when using --global defect normal 2009-12-14T06:53:04-0800 2009-12-14T06:53:04-0800 "When using the bootstrap.sh script with --global then the message displayed after a successful installation will look like this:
{{{
The 'cabal' program has been installed in /usr/local/bin/
You should either add /usr/local/bin to your PATH
or copy the cabal program to a directory that is on your PATH.
}}}
This is probably redundant since most users will have /usr/local/bin on their path." taavi
3 Cabal library 626 Package build error due to unicode defect normal 2010-01-26T07:21:31-0800 2011-10-18T14:40:04-0700 "The following packages don't build on hackage due to the same error:
* http://hackage.haskell.org/package/regions-0.3
* http://hackage.haskell.org/package/ftdi-0.1
The [http://hackage.haskell.org/packages/archive/regions/0.3/logs/failure/ghc-6.12 log] contains the following error:
{{{haddock: internal Haddock or GHC error: dist/doc/html/regions/regions.txt: commitAndReleaseBuffer: invalid argument (Invalid or incomplete multibyte or wide character)}}}
I think the .txt file is generated because of the haddock {{{--hoogle}}} flag.
'''Note that these package make heavy use of Unicode syntax and symbols.'''
Note that {{{cabal haddock}}} works perferctly on my local system (tested with ghc-6.10.4 + haddock-2.5 + cabal-install-0.6.2 and ghc-6.12.1 + haddock-2.6.0 + cabal-install-0.8.0)
" basvandijk
3 Cabal library 628 Greencard files are processed incorrectly defect normal 2010-02-01T06:50:36-0800 2010-02-01T06:50:36-0800 "If I use greencard file (.gc):
1. stub files are created in source directory instead of dist
2. stub files are not compiled
PS. Version is 1.8.0.2" mpiechotka
3 Cabal library 631 readline-1.0.1.0 not linking with GNU macports readline on darwin defect normal 2010-02-09T02:41:15-0800 2012-01-05T08:27:37-0800 "I had some problems installing readline-1.0.1.0 on Darwin. I don't
think it was looking for GNU readline among my Macports.
In the end I did this and it worked:
{{{
sudo cabal unpack readline
cd readline-1.0.1.0/
chmod +x configure
sudo ./configure --with-readline-includes=/opt/local/include/readline
--with-readline-libraries=/opt/local/lib
sudo runhaskell Setup build
sudo runhaskell Setup install
}}}" osaunders
3 Cabal library 633 Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs defect normal 2010-02-11T12:28:26-0800 2012-01-05T07:58:33-0800 "For the Debian packages, we use Cabal to build packages for ghc6 and for hugs. Unfortunately, with Cabal-1.8, the hugs support is broken:
{{{
debian/hlibrary.setup configure --hugs --prefix=/usr -v2 --builddir=dist-hugs
Configuring binary-0.5.0.2...
Flags chosen: applicative-in-base=True, split-base=True,
bytestring-in-base=True
Dependency array -any: using array
Dependency base >1 && <1: using base
Dependency containers -any: using containers
Using Cabal-1.8.0.2 compiled by ghc-6.12
Using compiler: hugs
Using install prefix: /usr
Binaries installed in: /usr/bin
Libraries installed in: /usr/lib/hugs/packages/binary
Private binaries installed in: /usr/libexec
Data files installed in: /usr/share/binary-0.5.0.2
Documentation installed in: /usr/share/doc/binary-0.5.0.2
No alex found
Using ar found on system at: /usr/bin/ar
No c2hs found
Using cpphs version 1.9 found on system at: /usr/bin/cpphs
Using ffihugs found on system at: /usr/bin/ffihugs
Using gcc version 4.4.3 found on system at: /usr/bin/gcc
Using ghc version 6.12.1 found on system at: /usr/bin/ghc
Using ghc-pkg version 6.12.1 found on system at: /usr/bin/ghc-pkg
No greencard found
Using haddock version 2.6.0 found on system at: /usr/bin/haddock
No happy found
No hmake found
Using hsc2hs version 0.67 found on system at: /usr/bin/hsc2hs
Using hscolour version 1.15 found on system at: /usr/bin/HsColour
Using hugs found on system at: /usr/bin/hugs
No jhc found
Using ld found on system at: /usr/bin/ld
No lhc found
No lhc-pkg found
No nhc98 found
No pkg-config found
Using ranlib found on system at: /usr/bin/ranlib
Using strip found on system at: /usr/bin/strip
Using tar found on system at: /bin/tar
debian/hlibrary.setup build --builddir=dist-hugs
Preprocessing library binary-0.5.0.2...
Building binary-0.5.0.2...
Registering binary-0.5.0.2...
hlibrary.setup: --inplace is not supported with Hugs
}}}
The reason seems to be the build function in ./Distribution/Simple/Build.hs:
{{{
build pkg_descr lbi flags suffixes = do
let distPref = fromFlag (buildDistPref flags)
verbosity = fromFlag (buildVerbosity flags)
initialBuildSteps distPref pkg_descr lbi verbosity suffixes
setupMessage verbosity ""Building"" (packageId pkg_descr)
internalPackageDB <- createInternalPackageDB distPref
withLibLBI pkg_descr lbi $ \lib clbi -> do
info verbosity ""Building library...""
buildLib verbosity pkg_descr lbi lib clbi
installedPkgInfo <- generateRegistrationInfo verbosity pkg_descr lib
lbi clbi True{-inplace-} distPref
-- Register the library in-place, so exes can depend
-- on internally defined libraries.
registerPackage verbosity
installedPkgInfo pkg_descr lbi True{-inplace-} internalPackageDB
-- Use the internal package db for the exes.
let lbi' = lbi { withPackageDB = withPackageDB lbi ++ [internalPackageDB] }
withExeLBI pkg_descr lbi' $ \exe clbi -> do
info verbosity $ ""Building executable "" ++ exeName exe ++ ""...""
buildExe verbosity pkg_descr lbi' exe clbi
}}}
Here, the inplace flag is unconditionally set to true. But in ./Distribution/Simple/Register.hs, we have
{{{
registerPackageHugs verbosity installedPkgInfo pkg lbi inplace _packageDb = do
when inplace $ die ""--inplace is not supported with Hugs""
let installDirs = absoluteInstallDirs pkg lbi NoCopyDest
createDirectoryIfMissingVerbose verbosity True (libdir installDirs)
writeUTF8File (libdir installDirs ""package.conf"")
(showInstalledPackageInfo installedPkgInfo)
}}}
I’d be grateful for a quick work-around or patch, as this is holding up the transition to ghc 6.12 in Debian." nomeata
3 Cabal library 641 Cabal-1.8 install of darcs installs manpage with permission 0600 defect normal 2010-03-05T02:00:53-0800 2010-03-06T16:15:35-0800 "With ghc-6.12.1 (ie Cabal-1.8.0.2) cabal installing darcs-2.4
creates a manpage with permission 0600. This doesn't happen
with ghc-6.10.4 (Cabal-1.6) so looks like a regression.
I starting looking at the code but didn't track down the cause yet." juhp
3 cabal-install tool 645 "confusing interface: cabal ""install"" subcommand has two clashing meanings" defect normal 2010-03-19T02:53:26-0700 2012-03-05T06:14:18-0800 "This is not a duplicate of #601. Installing a package with
{{{
rm -rf ~/.ghc ~/.cabal
cabal clean
cabal configure --user --prefix=""${HOME}/opt""
cabal build
cabal install
}}}
will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'.
I'll attach a toy project demonstrating this.
System:
{{{
sk@watarrka:~> ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
sk@watarrka:~> cabal --version
cabal-install version 0.8.0
using version 1.8.0.2 of the Cabal library
}}}
" StefanK
3 Cabal library 648 Cabal C lib check error message is occasionally misleading defect normal 2010-03-26T13:51:40-0700 2012-01-05T07:58:44-0800 "This problem occurs with Cabal version 1.8.0.2 on Arch Linux
(this version number does not appear in the Version selector, so I have left it at 1.6.0.1) and ghc version 6.12.1.
Trying to install Codec-Image-DevIL, either version 0.1 or 0.2.0, 'runghc Setup configure' produces a misleading error message:
$ runghc Setup configure
Configuring Codec-Image-DevIL-0.2.0...
Setup: Missing dependency on a foreign library:
* Missing C library: IL
This problem can usually be solved by installing the system package that
provides this library (you may need the ""-dev"" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
The error message ""Missing C library: IL"" is incorrect:
the Arch 'devil' package
is installed, and the include and library files are present in
the normal locations:
$ pacman -Q devil
devil 1.7.8-6
$ ls /usr/include/IL
devil_cpp_wrapper.hpp il.h ilu.h ilu_region.h ilut.h
$ ls /usr/lib/*IL*
/usr/lib/libIL.a /usr/lib/libILU.a /usr/lib/libILUT.a
/usr/lib/libIL.so@ /usr/lib/libILU.so@ /usr/lib/libILUT.so@
/usr/lib/libIL.so.1@ /usr/lib/libILU.so.1@ /usr/lib/libILUT.so.1@
/usr/lib/libIL.so.1.1.0* /usr/lib/libILU.so.1.1.0* /usr/lib/libILUT.so.1.1.0*
There does seem to be an error in Codec-Image-DevIL.cabal: where it says
Extra-Libraries: IL
it should say any of the following (take your choice, all of them work):
Extra-Libraries: IL, pthread
Extra-Libraries: IL, rt
Extra-Libraries: IL, pthread, rt
It seems that using the IL library in a C program requires linking with -lrt or -pthread in addition to -lIL.
I have the impression that in the
configuration step, when Cabal sees the line
Extra-Libraries: IL
it writes a small C program that tries to include that library,
and reports the library is missing if there's an error
in compiling and linking the C program. Maybe Cabal needs to interpret the C compiler's and linker's error messages more carefully.
" GregoryWeber
3 User guide 653 no documentation for cpp-options defect normal 2010-04-03T12:37:27-0700 2010-12-10T01:50:58-0800 "The User's Guide doesn't mention the ""cpp-options:"" field in the documentation for ""Package Properties""." guest
3 cabal-install tool 658 cabal-install doesn't work with National account name. defect normal 2010-04-09T06:30:15-0700 2012-03-05T07:19:57-0800 "If Windows user uses national account name, cabal update is fail.
See: http://www.sampou.org/cgi-bin/w3ml.cgi/haskell-jp/msg/545 (in Japanese)
I thought this problem is GHC 6.10.x and older's bug. So, I tested on Haskell Platform 2010.1.0.0 Windows installer RC3's cabal-install (version 0.8.1), and more recently version cabal-install 0.8.2. But this problem occur newer version (with my National account), too.
{{{
C:\Documents and Settings\崇裕>cabal update
Downloading the latest package list from hackage.haskell.org
cabal: invalid argument
}}}
And I tried to use cabal install command in package's directory. But cabal install is also fail.
{{{
C:\home\working\parsec-3.1.0>cabal install
cabal: C:\Documents and Settings\ﾕ\Application
Data\cabal\packages\hackage.haskell.org\00-index.tar: invalid argument
}}}
Above error message shows wrong path, but GHC 6.12.1's getTemporaryDirectory, getAppUserDataDirectory and getHomeDirectory show correct path.
{{{
Prelude System.Directory> getTemporaryDirectory
""C:\\DOCUME~1\\\23815\35029\\LOCALS~1\\Temp\\""
Prelude System.Directory> getAppUserDataDirectory ""cabal""
""C:\\Documents and Settings\\\23815\35029\\Application Data\\cabal""
Prelude System.Directory> getHomeDirectory
""C:\\Documents and Settings\\\23815\35029""
}}}
So, I think cabal's function passes ascii version's API (*A) instead of wide charactor version's API (*W) internally.
I don't know where this problem come from, cabal-install or Cabal or GHC's library. So, I report this bug on Hackage's Bug Tracker." shelarcy
3 Cabal library 659 Cabal doesn't work if account name is changed on Windows. defect normal 2010-04-09T07:03:18-0700 2012-01-05T07:59:24-0800 "Windows can change account name by account management tool. But this causes problem when using Cabal.
{{{
C:\home\working\parsec-3.1.0>runhaskell Setup.hs configure
Configuring parsec-3.1.0...
: error: directory portion of ""C:\\DOCUME~1\\\144\146\151T\\LOCALS
~1\\Temp\\1860.o"" does not exist (used with ""-o"" option.)
}}}
This is same as TMP environment value's behavior.
{{{
Prelude System.Directory> getTemporaryDirectory
""C:\\DOCUME~1\\\23815\35029\\LOCALS~1\\Temp\\""
}}}
{{{
Prelude System.Environment> getEnv ""TMP""
""C:\\DOCUME~1\\\144\146\151T\\LOCALS~1\\Temp""
Prelude System.Environment> getEnv ""TEMP""
""C:\\DOCUME~1\\\144\146\151T\\LOCALS~1\\Temp""
}}}
But It seems that Cabal uses getTemporaryDirectory. So, I don't know why Cabal causes this problem." shelarcy
3 Cabal library 660 dist checks defined on GenericPackageDescription are inert defect normal 2010-04-10T23:36:00-0700 2010-04-11T12:37:25-0700 "Some checks in {{{Distribution.PackageDescription.Check}}} are defined on {{{GenericPackageDescription}}} and are called via {{{checkPackage}}}. {{{checkPackage}}} is called by {{{configure}}}, which ignores dist-related checks, but not by {{{sdist}}}, which only calls {{{checkConfiguredPackage}}}.
So any dist-related checks on {{{GenericPackageDescription}}}, e.g. warning of {{{base}}} version not bounded above, will have no effect." kmcallister
3 Cabal library 663 Setup.hs doesn't look into ~/.cabal/bin for build tools. defect normal 2010-04-21T01:27:25-0700 2012-01-05T08:30:22-0800 Cabal currently only checks the current PATH for buildtools. If the user installs and new pre-processor with the default --user installation, these tools wind up in ~/.cabal/bin. However, cabal doesn't find these unless ~/.cabal/bin has been added to the PATH. This is irritating since it is then not possible to make a library depend on a cabal package that contains it's build tools: Even if cabal-install installs the build tools first, building the library still fails since the tools cannot be found. The solution is very simple: Add ~/.cabal/bin to the search path when looking for build tools! Axel Simon
3 cabal-install tool 665 Confusion situation when linking ./dist/setup/setup is interrupted defect normal 2010-04-24T22:35:47-0700 2012-03-05T06:08:42-0800 "If one accidentally interrupts cabal when it's linking `./dist/setup/setup` then you can end up with the file existing it not being executable.
This leads to a confusing situation for the user. Running `cabal install` or `cabal configure` will fail silently. Running with -v indicates that something returns exit code 127. This corresponds to a permission error when trying to execute `./dist/setup/setup`
Two improvements could be made:
* Report the failure to execute `./dist/setup/setup`
* If ghc is interrupted when creating `./dist/setup/setup`, cabal should delete the file, if it exists. That way, cabal will recompile on the next invocation." duncan
3 Cabal library 666 configure should warn about using base 3 defect normal 2010-04-27T04:29:18-0700 2010-09-24T14:05:56-0700 "http://haskell.org/pipermail/haskell-cafe/2010-April/076823.html
For backwards compatibility we make cabal-install prefer base 3 if there is no upper bound on the version of base.
This is necessary however it is also confusing. People writing new packages should be getting base 4. We want to encourage people to use base 4, as version 3 is deprecated.
We should make `cabal configure` warn if base 3 is selected since this is deprecated. The message should indicate the appropriate solution, ie to put an upper bound on the version of base." duncan
3 Cabal library 671 better error message for broken build tools defect normal 2010-04-29T19:30:20-0700 2012-01-05T08:30:31-0800 "Consider:
{{{
Configuring haskell-src-exts-1.9.0...
setup: happy version >=1.17 is required but the version of
/usr/local/bin/happy could not be determined.
}}}
The actual problem is:
{{{
/usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
}}}
We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different." duncan
3 cabal-install tool 673 cabal init: fail gracefully if bogus files are found during recursive search for source code defect normal 2010-05-01T10:02:44-0700 2012-03-05T06:00:51-0800 "cabal init does a recursive search looking for things that look like Haskell modules to be added to the exports list. The following error messages were reported by Ivan Miljenovic:
{{{
cabal: /scratch/ghc-6.12.1/distrib/installer-scripts/MacOS: does not exist
cabal: /tmp/pulse-a7kaqGHss6Yh/native: inappropriate type
}}}
Not sure exactly what causes these errors, but in any case cabal init should not crash." byorgey
3 cabal-install tool 675 template-haskell cannot be upgraded (broken data-accessor-template) defect normal 2010-05-01T15:05:29-0700 2012-03-05T15:32:35-0800 "data-accessor-template-0.2.1.3 has flags in the cabal file on template-haskell versions, which makes it broken for cabal-install on ghc-6.12:
cabal-install tries to install template-haskell-2.3, which fails (and it can't be expected to succeed because TH is integrated into ghc due to quotes)
You can work around the build failure with:
{{{
cabal install data-accessor-template --constraint='template-haskell >= 2.4'
}}}
cabal-install ought to know that template-haskell isn't something it should install (as it does with base)." guest
3 cabal-install tool 681 cabal-install init should not overwrite files without good reason defect normal 2010-05-05T09:02:35-0700 2012-03-05T04:57:07-0800 "If you run ""cabal init"" in a directory with an already existing .cabal file, it will happily overwrite the old version without asking you. It should detect that a file exists and ask you before writing it out (or even prompting you for info). Alternatively, it could fill up it's defaults using the existing .cabal file.
Furthermore, if you pass -n for non-interactive mode, cabal can't ask whether or not the user wanted to overwrite, so probably adding a --force flag is in order." ezyang
3 Cabal library 684 Flags combined in the wrong order when nested defect minor 2010-05-07T22:01:47-0700 2010-05-07T22:04:55-0700 "One explanation of this problem is here:
http://www.mail-archive.com/cabal-devel@haskell.org/msg05939.html
It would appear that when some flags are specified outside of an if-statement the are combined in a different order than when they are combined inside an if-statement.
I have confirmed that Brent's work around works on the darcs.cabal file." guest
3 cabal-install tool 685 "cabal install does not work when /tmp/ is mounted ""noexec""" defect normal 2010-05-09T12:36:53-0700 2012-03-05T04:52:27-0800 "Wanting to to build darcs 2.4.3, I downloaded the tarball (
http://wiki.darcs.net/Releases/2.4 ) and uncompressed it in /tmp/ to
run cabal install.
I got the following error :
cabal: Error: some packages failed to install:
darcs-2.4.3 failed during the configure step. The exception was:
ExitFailure 127
See http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25412#a25412 for a
full verbose log, but i think there is nothing informative to it.
However, if I do ""rm -fr dist"" and try cabal install again, darcs
build fine. Also, if I try in $HOME, cabal install works directly.
Here are the versions of the software I'm using:
cabal-install version 0.8.2
using version 1.8.0.4 of the Cabal library
ghc 6.12.1
Linux distribution: Ubuntu 10.04 (Lucid Lynx).
I hope this will help you!" guest
3 Cabal library 693 Missing instructions for running Cabal's testsuite defect normal 2010-05-26T14:52:38-0700 2012-01-05T07:57:33-0800 "It's not quite clear to me how to get `tests/suite.cabal` to build using an in-place build of Cabal. I played around with passing `--package-db ../dist/package.conf.inplace` to `configure` when configuring `tests/suite.cabal` without success.
A `tests/README` file would be very useful." tibbe
3 cabal-install tool 695 cabal install world always reinstalls programs defect normal 2010-05-31T06:15:59-0700 2012-04-15T23:17:50-0700 "cabal-install does not currently track the installed state of programs. It does now list them in the world file however. This leads to it always wanting to reinstall programs.
Probably we do want to keep the programs in the world file, since we hopefully will track programs better in future. The temporary hack would be to filter out packages that have no lib when retrieving packages from the world file." duncan
3 Cabal library 696 better error message for when /tmp is mounted noexec defect normal 2010-05-31T12:34:02-0700 2010-05-31T12:34:02-0700 "See also http://hackage.haskell.org/trac/ghc/ticket/4110
If /tmp is mounted noexec then we get a poor error message when we fail to compile and execute `Setup`, or anything else like pre-processors or tests." duncan
3 cabal-install tool 700 seemingly too liberal behaviour on overlapping dependency constraints across packages defect normal 2010-06-13T15:19:45-0700 2012-03-05T04:00:25-0800 "There's a high chance this is not actually a bug, but I'm filing one anyway.
In http://bugs.darcs.net/isuse1763 we have darcs-2.4 which depends on mmap >= 0.2 and on hashed-storage >= 0.4.7 && < 0.5
The hashed-storage 0.4.x line depends on mmap == 0.4.*
The bug in darcs happened when darcs was linked against mmap-0.5 while hashed-storage against mmap-0.4.
Is it reasonable to expect that if I depend on a package, that the package can indirectly impose at least soft constraints (on the cabal-install level) on our shared dependencies? Should cabal-install have been smart enough to work out that darcs should actually only pick up mmap 0.4? I think I could be quite happy with ""no""" kowey
3 miscellaneous 703 "Cabal ""Getting the Code"" web page does not link to Cabal-1.8 branch" defect minor 2010-06-17T14:26:00-0700 2010-06-17T14:26:00-0700 http://www.haskell.org/cabal/code.html lists the 1.6 branch, but not the 1.8 branch. It might be a good idea to just link to the directory that contains all of the branches for ease of maintenance. For reference, the link to the 1.8 branch is: http://darcs.haskell.org/cabal-branches/cabal-1.8/ j3h
3 cabal-install tool 705 Non-deterministic behaviour when overlapping packages are installed defect normal 2010-06-25T15:10:43-0700 2012-03-05T03:55:15-0800 "See [http://stackoverflow.com/questions/3119782/mysterious-cabal-install-problems].
This user took a standard Haskell Platform install, installed a new version of the time package, and then installed random. The random package was rebuilt and installed against the new time package. However, re-running `cabal install random` installs random again; it doesn't reach a fixed point.
The problem (I presume) is that when cabal-install merges the package databases it chooses which `random-1.0.0.2` to use non-deterministically. In fact it seems to depend on the exact package Ids, because I get different results with GHC 6.12.2 where the package Ids of the two `random-1.0.0.2` packages are ordered differently.
I realise there are larger issues about how to do resolution here, but I think at least we should make cabal-install deterministic, and preferably idempotent.
" guest
3 cabal-install tool 707 "cabal-install config setting ""documentation: True"" ignores base library dependency" defect normal 2010-07-06T20:13:02-0700 2012-03-05T03:53:49-0800 "I use ""documentation: True"" setting in the cabal-install config file (in linux $HOME/.cabal/config) since I prefer to install documentation locally with the library, and recently found out that this ignores the base library version in the .cabal files. I am not sure about whether they ignore other libraries but for base it is for sure. Even though the package cabal file specifies base >= 4 the cabal-install seems to revert back to base version 3 when I use ""documentation: True"" in the config file.
In particular, I found this bug when I was working with the RepLib package. I had a link error when I was using the ""documentation: True"" option in the config, but when I commented that out and worked with the default config file everything worked." KiYungAhn
3 Cabal library 708 extension list defect normal 2010-07-11T04:00:49-0700 2010-08-21T14:34:34-0700 "I was going to add the new `DatatypeContexts` extension to Cabal's extension list, but the datatype confused me. It seems to list the extensions relative to Haskell98 (i.e. `NoFoo` if Foo is H98, `Foo` otherwise), but this seems odd now that we also have a Haskell2010 standard. And does it allow extensions to be toggled on or off, regardless of which way they are listed in the datatype?
Also, the haddock comments refer the GHC manual sections, but don't say what version of GHC's manual the numbers refer to. I think it would be better to drop the numbers, rather than having to manually keep them up-to-date - especially as someone might use a Cabal release with a different GHC version.
" igloo
3 Cabal library 709 cabal doesn't handle error conditions from getAppUserDataDirectory defect normal 2010-07-12T11:25:46-0700 2012-01-05T07:57:52-0800 "Distribution.Simple.InstallDirs.defaultInstallDirs fails if getAppUserDataDirectory fails, and it does so with a very uninformative error:
{{{ # On Cabal 1.8.0.2:
cabal.exe: illegal operation
}}}
This is a slight regression from the HP 2009 version:
{{{ # On Cabal 1.6.0.3:
cabal.exe: System.Directory.getAppUserDataDirectory: unsupported operation (unsupported operation)
}}}
This happens on Windows Vista, in cygwin, when the user doesn't have a windows user directory (eg: c:\users\username )." creswick
3 cabal-install tool 714 "cabal: Couldn't read cabal file "".\\HaTeX\\1.0.0\\HaTeX.cabal""" defect normal 2010-07-20T05:51:01-0700 2012-03-05T03:51:07-0800 "I have a similar error than exposed in Ticket#677.
This error appears when I try to install the HaTeX package:
cabal: Couldn't read cabal file "".\\HaTeX\\1.0.0\\HaTeX.cabal""
Even when I'm installing version 1.0.1.
A link to the package in Hackage:
http://hackage.haskell.org/package/HaTeX
Note that the same error appears in Hackage.
I'm the author of the package, and I want a fix for him. But I don't know how to attack the problem, because error appears before reading a new version of the package (When ""Resolving dependencies..."").
" guest
3 Cabal library 718 Behaviour of postCopy and postInstall hook is confusing defect normal 2010-07-23T17:02:31-0700 2010-07-28T02:24:10-0700 "While working on the Bluetile cabal package ( http://hackage.haskell.org/package/bluetile ) I used Cabal's hook system to install executables to the libexec directory.
It took me a while to figure out that the postCopy hook is _the only hook_ to run when you invoke 'cabal copy' and the postInstall hook is _the only hook_ to run when you invoke 'cabal install'.
This is both confusing and unfortunate.
Since the Cabal documentation elsewhere states that 'cabal install' is just ""register + copy"" one would assume that upon 'cabal install' the postCopy hook runs as well.
Now I had to write two hooks, both for postCopy and for postInstall, to make it work for users that run 'cabal install' as well as cases where 'cabal copy' is used (for example by distributions, while preparing their packages).
This can probably not be fixed without breaking a bunch of Cabal packages, so maybe some kind of warning or big note in the documentation would help in the meantime.
Best regards!
Jan
" guest
3 Cabal library 720 Executables fail on windows if the executable name has a dot in it defect normal 2010-07-28T10:31:48-0700 2010-07-28T11:49:34-0700 "If an executable name has a dot in it, it is not generated with an .exe extension on Windows. It works fine under Linux. See the attached example to reproduce.
{{{
$ cabal --version
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library
$ cabal install
Resolving dependencies...
Configuring bad-exe-0.1...
Preprocessing executables for bad-exe-0.1...
Building bad-exe-0.1...
[1 of 1] Compiling Main ( Main.hs, dist\build\bad.name\bad.name-tmp\Main.o )
Main.hs:1:0:
Warning: Module `Prelude' is deprecated:
You are using the old package `base' version 3.x.
Future GHC versions will not support base version 3.x. You
should update your code to use the new base version 4.x.
Linking dist\build\bad.name\bad.name ...
Installing executable(s) in C:\Users\hudson\AppData\Roaming\cabal\bin
cabal.exe: dist\build\bad.name\bad.name.exe: does not exist
cabal.exe: Error: some packages failed to install:
bad-exe-0.1 failed during the final install step. The exception was:
ExitFailure 1
}}}" j3h
3 Cabal library 721 Unknown subsections are silently ignored defect normal 2010-07-28T16:04:19-0700 2010-07-28T18:09:26-0700 "Sections not on the top-level (like those used in conditionals) appear to be ignored silently if they are not recognized.
{{{
Name: cabal-elseif
Version: 0.1
License: BSD3
License-file: LICENSE
Category: Bug
Build-type: Simple
Cabal-version: >=1.2
Library
if os(linux) {
Ghc-options: -O2
} elseif os(windows) {
Ghc-options: -O
}
}}}
Expected behavior: Cabal warns that elseif is not a supported section name
Actual behavior: Cabal silently accepts this and ignores the elseif section." ezyang
3 cabal-install tool 723 Strip path error under Cygwin defect normal 2010-08-13T07:05:10-0700 2012-03-05T03:43:17-0800 "I am using a new Windows 7 box using cygwin and the Haskell Platform 2010.2.0.0. I am working with cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library. Cabal config is default located here:
\\fs1\grad\users\pkeir\Application Data\cabal\config
Installing packages with cabal-install ends with an error relating to the path argument provided to strip (strip is present on cygwin):
cabal install cpphs
...
Linking dist\build\cpphs\cpphs.exe ...
Installing library in \\fs1\grad\users\pkeir\Application
Data\cabal\cpphs-1.11\ghc-6.123
Installing executable(s) in \\fs1\grad\users\pkeir\Application Data\cabal\bin
/usr/bin/strip: '\fs1\grad\users\pkeir\Application Data\cabal\bin\cpphs.exe': No such file
cabal.exe: Error: some packages failed to install:
cpphs-1.11 failed during the final install step. The exception was:
ExitFailure 1
It looks like strip is being given one less backslash than it needs at the start. The exe is however installed, and so this command does work:
strip '\\fs1\grad\users\pkeir\Application Data\cabal\bin\cpphs.exe'
Though of course the package remains formally uninstalled.
" guest
3 User guide 728 Rewrite user guide, document cabal-install defect normal 2010-08-18T04:53:25-0700 2010-08-21T14:36:21-0700 "The Cabal user guide is rather out of date. There is no documentation for the cabal-install tool (which should cover the config file format too).
We should also have a man page for cabal-install and perhaps the Cabal file format too." duncan
3 Cabal library 733 Cabal should give haddock per-package source entity paths defect normal 2010-09-04T06:59:44-0700 2010-09-04T06:59:44-0700 "Cabal should give haddock per-package source entity paths, so that haddock can make cross-package source links when necessary.
See http://hackage.haskell.org/trac/ghc/ticket/3810 for more details.
" igloo
3 Cabal library 738 Recompiling the same library version can change its ABI, causing breakage (even of Cabal) defect major 2010-09-12T10:06:52-0700 2010-09-12T10:06:52-0700 "On my system, cabal recompiled a package on which Cabal itself depended, breaking the linking of Setup.hs when trying to update new packages.
My problem was partially due to an upgrade of a ""core package"" (on which cabal depends): install of core packages should be refused, for the same reason that ""cabal upgrade"" is disabled. But that's a side issue, probably known.
Recompiling a non-core package could break silently another non-core package, in the same way. The root problem, IMHO, stems from handling of dependencies. Compiler-generated identifiers are exported, due to cross-module linking, and they depend from used modules and options about compilation (especially optimization).
It thus seems that the ABI of a module is a (pure) function of the versions of all its (transitive) dependencies, and their compilation options - in particular, the optimization options and the used compiler version. Surely, the ABI does not depend just on the package version.
More formally, my conjecture is:
- let us represent ""package a depends on b"" as ""a =>> b"", where a, b are package names tagged with a version
- let =>>* be the transitive-reflexive closure of =>>
we need to compute:
DEPS(p) = {q | p =>>* q }
TAGGED_DEPS(p) = { (q, compilation_opts(q)) | q \in DEPS(p) }
where compilation_opts(q) are the compilation options used to compile package q.
Then, the ABI of package p is a pure function of TAGGED_DEPS(p), not just of p. My experience proves at least that the ABI does not depend just on p.
Possibly, a package ABI depends on the build ID, if internally generated identifiers are random, but it does not look like that on my system (they are sequentially generated).
Finally, there should be a way to automatically recompile dependent packages, as in Gentoo's revdep-rebuild. In my case, I wasn't prevented by ghc-pkg from removing a package on which other packages depended, while it does do some dependency tracking.
Further info is being discussed on Haskell-cafe in this thread:
http://groups.google.com/group/haskell-cafe/browse_thread/thread/838f2c098941bac9
Software versions:
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library (installed through Hackage, not available in this bug report form under ""version"").
GHC 6.10.4" Blaisorblade
3 Cabal library 739 cabal install regression with GHC HEAD - ghc-paths defect normal 2010-09-13T22:06:48-0700 2012-01-05T08:30:46-0800 "with the Cabal library installed with GHC 6.13.20100911 I can no longer install the package ghc-paths-0.1.0.6
In 'ghci Setup.hs' I get the error:
Setup.hs:41:25:
Ambiguous occurrence `None'
It could refer to either `Distribution.Simple.Setup.None', imported from Distribution.Simple.Setup at Setup.hs:2:1-32
or `Pkg.None', imported from Distribution.Simple.PackageIndex at Setup.hs:7:1-46
It looks like the 'None' constructor didn't exist in Distribution.Simple.Setup in Cabal 1.8.x. While we can't guarantee that an added constructor doesn't conflict with data declarations used in every Setup.hs, it seems in poor form to export the same constructor in two types in the same library." AntoineLatter
3 cabal-install tool 745 cabal-install sometimes gives empty build-log and no build-summary defect normal 2010-10-04T09:14:04-0700 2012-03-05T03:38:48-0800 "
Building `NaturalSort-0.2.1` with GHC 7.0.1 RC 1:
{{{
$ cabal install --build-summary=log.bs --build-log=log.bl
Resolving dependencies...
Warning: NaturalSort.cabal: This package requires Cabal version: >=1.6 && <1.9
cabal: Error: some packages failed to install:
NaturalSort-0.2.1 failed during the configure step. The exception was:
user error (The package requires Cabal library version -any && >=1.6 && <1.9
but no suitable version is installed.)
$ cat log.bs
cat: log.bs: No such file or directory
$ cat log.bl
$
}}}
I would like the build log to contain the error.
I have
{{{
$ cabal --version
cabal-install version 0.9.2
using version 1.9.2 of the Cabal library
}}}
but this is not a released version; if nothing else, I have the #697 patch applied.
" igloo
3 Cabal library 746 Cabal should complain if you give an upperbound on Cabal-Version defect normal 2010-10-04T10:12:09-0700 2012-01-05T08:01:29-0800 "Some packages (e.g. `NaturalSort-0.2.1`) give an upper-bound on `Cabal-Version`. This doesn't make sense for this field, so Cabal should complain about it (or perhaps even reject it).
" igloo
3 Cabal library 747 symlinks in sdists defect normal 2010-10-12T05:37:40-0700 2010-10-12T07:13:31-0700 "Should hackage reject tarballs that contain symlinks? Or broken symlinks?
I just ran across a broken symlink in ipprint 0.4:
{{{
ipprint-0.4/.#ipprint.cabal -> gleb@gleb.kiev.zoral.com.ua.3270:1271836339
}}}
" igloo
3 cabal-install tool 748 cabal does not use JavaScript proxy autoconfiguration defect normal 2010-10-13T05:51:16-0700 2012-03-05T03:33:40-0800 "I've installed Haskell Platform 2010.2.0.0 and I cannot make any use of cabal since ""cabal update"" results in:
Config file path source is default config file.
Config file C:\Users\suszynsk\AppData\Roaming\cabal\config not found.
Writing default configuration to
C:\Users\suszynsk\AppData\Roaming\cabal\config
Downloading the latest package list from hackage.haskell.org
cabal: failed
cabal -V returns:
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library
I'm using Windows Vista Enterprise
GHC ver. 6.12.3
[I was unable to select correct versions of cabal and ghc in this ""create new ticket"" form]" guest
3 Cabal library 749 Package check cannot handle byte-order-mark in .cabal file defect normal 2010-10-20T12:44:24-0700 2010-10-20T17:44:33-0700 "When I edit a .cabal file with Notepad (Windows XP) and save it as UTF-8, Notepad writes a byte-order-mark at the start of the file. When testing the package for upload, I got the message:
400 Error in upload
line 1: unrecognised field or section: ""\65279Name: GeBoP""
Henk-Jan van Tuyl
" guest
3 Cabal library 754 cabal should pass extra lib/include dirs to configure scripts defect normal 2010-10-27T02:57:21-0700 2012-03-03T10:21:59-0800 cabal install SDL-gfx with macports has always failed for me, because that package's configure script doesn't know about the required extra lib dir /opt/local/lib. This made it work: LDFLAGS=-L/opt/local/lib cabal install SDL-gfx . cabal-install should probably use this or some other method to tell configure scripts about extra lib and include dirs. simonmic
3 cabal-install tool 759 document hackage archive format defect normal 2010-11-04T07:52:42-0700 2012-03-03T10:19:43-0800 "I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages.
The source code has an undocumented(?) option `--remote-repo` that seems to serve that purpose, but there is little documentation, sometimes conflicting info, about how to put this to use.
Mailing list threads:
http://www.haskell.org/pipermail/haskell-cafe/2010-November/085860.html
http://www.haskell.org/pipermail/haskell-cafe/2010-November/085900.html
Repo layout descriptions (differs between hackage 1.0 and 2.0, which is hardcoded in `cabal-install`):
http://hackage.haskell.org/trac/hackage/wiki/HackageDB
http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0/URIs
Related tickets: #758, comment:6:ticket:428" claus
3 hackageDB website 767 Highlighted source code on hackage.haskell.org mangles Unicode defect normal 2010-11-19T01:42:04-0800 2011-11-09T00:01:59-0800 "On hackage.haskell.org, when you browse the source of a module that contains Unicode (e.g. [http://hackage.haskell.org/packages/archive/base-unicode-symbols/latest/doc/html/src/Data-Eq-Unicode.html Data.Eq.Unicode]), it is sent with a `Content-Type: text/html` header with no charset. There is a charset in the XML declaration ``, but that is ignored by Firefox because of the non-XML `Content-Type`. Therefore, the wrong encoding is detected and the Unicode symbols get mangled.
Possible fixes include sending `Content-Type: text/html; charset=UTF-8`, or sending `Content-Type: application/xhtml+xml` so that the XML declaration is respected , or both (`Content-Type: application/xhtml+xml; charset=utf-8`), or adding equivalent `` tags." andersk
3 cabal-install tool 768 Cabal cannot find GHC when using relative path in -w flag defect normal 2010-11-19T05:30:41-0800 2012-03-03T09:52:17-0800 "Trying to build the network package while standing at the root of a GHC build tree fails to find GHC:
{{{
$ cabal install -w inplace/bin/ghc-stage2 network -v2
inplace/bin/ghc-stage2 --numeric-version
looking for package tool: ghc-pkg near compiler in inplace/bin
found package tool in inplace/bin/ghc-pkg
inplace/bin/ghc-pkg --version
inplace/bin/ghc-stage2 --supported-languages
Reading installed packages...
inplace/bin/ghc-pkg dump --global
inplace/bin/ghc-pkg dump --user
inplace/bin/ghc-stage2 --print-libdir
Reading available packages...
Resolving dependencies...
selecting network-2.3 (hackage) and discarding network-2.0, 2.1.0.0, 2.2.0.0,
2.2.0.1, 2.2.1, 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7,
2.2.1.8, 2.2.1.9, 2.2.1.10, 2.2.3 and 2.2.3.1
selecting base-4.3.0.0 (installed)
selecting ffi-1.0 (installed)
selecting ghc-prim-0.2.0.0 (installed)
selecting integer-gmp-0.2.0.2 (installed)
selecting rts-1.0 (installed)
selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0,
3.0.1 and 3.1.0
selecting unix-2.4.1.0 (installed) and discarding unix-2.0, 2.2.0.0, 2.3.0.0,
2.3.1.0, 2.3.2.0, 2.4.0.0, 2.4.0.1 and 2.4.0.2
selecting bytestring-0.9.1.8 (installed) and discarding bytestring-0.9,
0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3,
0.9.1.4, 0.9.1.5, 0.9.1.6 and 0.9.1.7
In order, the following would be installed:
parsec-2.1.0.1 (new package)
network-2.3 (new package)
parsec-2.1.0.1 has already been downloaded.
Extracting
/home/tibell/.cabal/packages/hackage.haskell.org/parsec/2.1.0.1/parsec-2.1.0.1.tar.gz
to /tmp/parsec-2.1.0.117969...
Configuring parsec-2.1.0.1...
cabal: Cannot find the program 'ghc' at 'inplace/bin/ghc-stage2' or on the
path
cabal: Error: some packages failed to install:
network-2.3 depends on parsec-2.1.0.1 which failed to install.
parsec-2.1.0.1 failed during the configure step. The exception was:
ExitFailure 1
}}}
" tibbe
4 hackageDB website 769 HackageDB messes up {-# OPTIONS_HADDOCK hide #-} defect minor 2010-11-25T16:07:44-0800 2010-11-26T05:00:22-0800 "Have a look at the SCC 0.6 package page (http://hackage.haskell.org/package/scc) and then try to see, say, its XML module API (http://hackage.haskell.org/packages/archive/scc/0.6/doc/html/Control-Concurrent-SCC-XML.html).
The reason for the 404 message that this module has a {-# OPTIONS_HADDOCK hide #-} pragma. When I tried Haddock locally, the effect was that the module became invisible, which was my intention. Making the module name visible but its documentation missing was not.
" blamario
3 Cabal library 770 cabal is not reading or respecting ~/.cabal/config defect minor 2010-11-27T15:02:29-0800 2010-11-30T15:20:22-0800 "I changed my ~/.cabal/config file to keep global packages under /usr/local/lib/haskell and /usr/local/share/haskell to avoid cluttering the main /usr/local/lib and /usr/local/share/doc directories. ghc-pkg finds them just fine, and ghc-pkg recache works as expected. However, when I do 'cabal install whatever --global' it still throws everything into the old default directories, and more distressingly it isn't updating the access timestamp on ~/.cabal/config (as revealed by ls -u.)
cabal --version reports 0.8.2 using library 1.8.0.6, nothing else unusual about my setup." guest
3 Cabal library 771 Package registered twice in the same database defect normal 2010-11-30T08:54:01-0800 2010-11-30T08:54:01-0800 "We have an example of a package registered twice in the same database. In this case, Cabal 1.8.0.6 with GHC 6.12 and Haskell Platform 2010.2, where the Cabal package appears registered twice in the global db.
The machine is a Windows Vista box.
{{{
C:\Users\darrelll>ghc-pkg list Cabal
C:/Program Files/Haskell Platform/2010.2.0.0\lib\package.conf.d:
Cabal-1.8.0.6
Cabal-1.8.0.6
C:\Users\darrelll\AppData\Roaming\ghc\i386-mingw32-6.12.3\package.conf.d:
Cabal-1.8.0.6
}}}" dons
3 Cabal library 776 cabal check gives invalid duplicate modules warning defect minor 2010-12-11T08:12:50-0800 2012-01-05T07:57:00-0800 "Given the Cabal file:
{{{
cabal-version: >= 1.2
build-type: Simple
name: test
version: 4.1
license: GPL
category: Test
author: Test
maintainer: Test
synopsis: Test
description: Test
flag extended-library
library
if flag(extended-library)
exposed-modules:
Test
else
other-modules:
Test
}}}
I get the {{{cabal check}}} output:
{{{
The following warnings are likely affect your build negatively:
* Duplicate modules in library: Test
These warnings may cause trouble when distributing the package:
* A 'license-file' is not specified.
The following errors will cause portability problems on other environments:
* The package is missing a Setup.hs or Setup.lhs script.
Hackage would reject this package.
}}}
The error about Test being duplicate is incorrect - the flag means it will occur at most once. This bug is annoying for Hoogle, which wants to have a library exposing internal details, mainly for documentation purposes, and a normal library as well.
Thanks, Neil" guest
3 cabal-install tool 777 cabal install {hledger, others} ExitFailure 11 defect normal 2010-12-12T10:21:35-0800 2012-08-14T09:25:07-0700 "I am getting ExitFailure 11 when trying to install hledger on Debian and openSUSE. I reported this to the hledger author, Simon, and he said he is experiencing this on his machines too and for other packages, not just hledger.
Log file attached. Summary below:
{{{
ledger:~/ $ cabal install -v3 hledger
Lots of debug output (see attached)...
hledger-0.13 failed during the configure step. The exception was:
ExitFailure 11
ledger:~/ $ cabal --version
cabal-install version 0.8.2
using version 1.8.0.2 of the Cabal library
ledger:~/ $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
}}}" philips
3 Cabal library 778 ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=... defect normal 2010-12-17T14:40:25-0800 2012-01-05T07:57:04-0800 "I have custom Flag declaration in .cabal file:
Flag debug
Description: Build with debug support
Default: True
and some conditionals (if flag(debug) ...) which depend on this flag. In custom Setup.hs I use data structure Distribution.Simple.Setup.ConfigFlags and its field configConfigurationsFlags to get value of 'debug' flag. But it seems that field contains flag entry only when I explicitly mention flag during configuration phase in command line with '-fdebug' or '--flags=debug'.
I think it is wrong because even if I don't mention flag in command line he will be initialized to True and conditionals (in *.cabal) which depend on it will be evaluated according to this default value. It would be awesome if I could access flag with its implicitly assigned value via ConfigFlags { configConfigurationsFlags }.
My custom Setup.hs machinery heavily depends on values of such flags, and it is inconvenient to explicitly define all of them via command line during configuration phase.
Thanks." nartamonov
3 Cabal library 784 Cabal strips out { and } in literate code blocks of the description field defect normal 2010-12-28T17:38:50-0800 2010-12-28T17:38:50-0800 "If you have a description like this:
{{{
description: Here is some C code:
.
> for(i = 0; i < 100; i++){
> printf(""%d\n"",i);
> }
.
}}}
Cabal will strip out the brackets. You can use @..@ syntax with { and } except that then the whitespace is off in your code block and you have to escape any symbols that haddock knows. Putting a blackslash (\) in front the braces does not help.
The above example works fine in plain haddock leading me the conclusion that cabal is eating the braces." guest
3 Cabal library 785 "check fails ""No (or multiple) ghc rts package is registered""" defect normal 2011-01-06T11:34:05-0800 2012-01-05T08:01:13-0800 "For packages that do not depend indirectly on the rts package (ie that have no dependencies specified at all), then the check in the hsc2hs package for the rts package fails.
{{{
hackRtsPackage index =
case PackageIndex.lookupPackageName index (PackageName ""rts"") of
[(_, [rts])]
-> PackageIndex.insert rts { Installed.ldOptions = [] } index
_ -> error ""No (or multiple) ghc rts package is registered!!""
}}}
The reason is that we only store the transative deps of the package in the saved config, so the rts package is not found.
This is of course not a helpful error message. We should remove this check from this place and add something else elsewhere with a more helpful error message. We could do a sanity check during configure or build (but note that we don't do it anymore when configuring ghc itself due to the odd things ghc does during its own build process).
We should probably have a build warning about missing the base package." duncan
3 Cabal library 786 Bad errors from getProgramInvocationOutput and friends defect normal 2011-01-08T08:41:03-0800 2011-01-08T08:41:03-0800 "In http://hackage.haskell.org/trac/ghc/ticket/4883 `ghc-cabal` gives an unhelpful error:
{{{
ghc-cabal:
}}}
This comes from `getProgramInvocationOutput`:
{{{
(output, errors, exitCode) <- rawSystemStdInOut verbosity
path args
Nothing utf8
when (exitCode /= ExitSuccess) $
die errors
}}}
as there was nothing on `stderr`. There are several similar functions in `Cabal`.
Cabal ought to also say what it was running and what the error code was, without needing a verbosity flag to be given.
" igloo
3 Cabal library 788 Optionally exposed modules / APIs should be banned defect normal 2011-01-10T17:38:23-0800 2012-01-05T07:56:53-0800 "It is a deliberate decision that packages cannot depend on package + flag combinations, only on packages. The point is that flags are not supposed to change the API of a package.
This needs to be enforced.
Consider a real example (from Chart package: http://hackage.haskell.org/packages/archive/Chart/0.14/Chart.cabal)
{{{
if flag(gtk)
build-depends: gtk >= 0.9.11
exposed-modules: Graphics.Rendering.Chart.Gtk
}}}
The criterion package depends on Chart and imports `Graphics.Rendering.Chart.Gtk` meaning that it breaks if you build Chart with the gtk flag turned off.
The solution is that Chart should be prevented from conditionally exposing modules. We should add a QA check that looks for exposed modules that are conditional on a flag. It is annoying but somewhat less bad for modules to change between platforms.
Should it be a hard failure or just a warning?" duncan
3 cabal-install tool 789 build-depends on packages that provide no library defect normal 2011-01-13T11:47:55-0800 2012-04-10T07:03:15-0700 "It is possible to list build-depends on packages that have just an executable and no library. Currently the behaviour of cabal-install does not consider this and it will allow such packages to be pulled in as dependencies. It leads to problems however because the non-lib package never gets registered with ghc-pkg and so it leads to re-install loops.
The solution is for cabal-install to not consider exe-only packages to be valid for satisfying a build-depends requirement. It should produce a suitable error message.
Note that it must take into account the posibility that a newer or older version of a package may switch from exe only to exe+lib or just lib, or indeed vica versa.
We should mark exe-only versions of the package as excluded with a reason. Then if the dep is not satisfiable then we can explain why all the excluded ones were excluded (ie due to not exposing a lib)." duncan
2 Cabal library 791 Large libraries not installable on OS X defect normal 2011-01-18T02:08:58-0800 2012-01-05T08:27:21-0800 "For example:
{{{
cabal unpack highlighting-kate-0.2.8.1
cd highlighting-kate-0.2.8.1
ghc --make Setup.hs
./Setup configure
./Setup build
}}}
This fails:
{{{
ld: scattered reloc r_address too large for inferred architecture i386
}}}
The underlying reason is that Cabal is trying to create an object file for use with GHCi, but that is not possible (see http://hackage.haskell.org/trac/ghc/ticket/3260).
Cabal's GHC.hs should not use combineObjectFiles on with GHC >= 7 and OS X." batterseapower
3 Cabal library 793 On OS X, warn about filenames that only differ in case defect normal 2011-01-18T12:19:00-0800 2012-01-05T07:56:57-0800 "I managed to make Cabal fail to build a project by having
{{{
Name: hamt
Version: 0.1
License: BSD3
License-file: LICENSE
Author: Johan Tibell
Maintainer: johan.tibell@gmail.com
Category: Data
Build-type: Simple
Cabal-version: >=1.2
Library
Exposed-modules: HAMT
Other-modules: PopCount
Build-depends: base, vector
C-sources: popcount.c
}}}
The result was:
{{{
Building hamt-0.1...
[1 of 2] Compiling PopCount ( PopCount.hs, dist/build/PopCount.o )
ld: duplicate symbol _popcount in dist/build/popcount.o and dist/build/PopCount.o for inferred architecture i386
}}}
`_popcount` is only defined in `popcount.c`. Looking in `dist/` showed that there was only a popcount.o there (from the C file). Renaming `popcount.c` to `popc.c` solved the problem.
Cabal ought to warn in this case.
" tibbe
3 Cabal library 794 Wildcards in data-files don't work with filenames containing multiple dots defect normal 2011-01-22T09:25:59-0800 2011-01-30T16:50:18-0800 "The Hoogle cabal file reads:
{{{
data-files:
resources/*.js
-- surely a Cabal bug that this isn't picked up by *.js
-- but that hoogle.js is matched
resources/jquery-1.4.2.js
resources/jquery.cookie.js
}}}
It seems that the filename {{{a.b.ext}}} doesn't get picked by the wildcard {{{*.ext}}}.
-- Neil Mitchell" guest
3 Cabal library 798 "install gives ""removeLink: does not exist"" for a dependency that exists" defect normal 2011-02-01T15:27:53-0800 2012-01-05T08:00:55-0800 "In installing regex-pcre in an installation with regex-base already installed, I get:
Registering regex-base-0.93.2...
/usr/bin/ghc-pkg update - --global --no-user-package-conf
cabal: ghc-pkg:
/usr/lib/ghc-6.12.3/package.conf.d/regex-base-0.93.2-93d41c404776e7153a3c56abb15299c9.conf:
removeLink: does not exist (No such file or directory)
and regex-pcre does not install. However, prior to running cabal 'ghc-pkg list' had shown that regex-base was already installed.
I suspect this is a problem due to the way haskell is installed on Fedora. Basically, you:
1. install a haskell-platform rpm, which leads to a bunch of ghc rpms being installed.
2. you supplement these rpms with any other Fedora
haskell package rpms you may need. At this point everything works.
3. when you cabal install other packages from hackagedb, 1 of 3 things usually happens:
a. install is successful.
b. install fails, but can be done by using an older version of the package.
c. install fails as above.
I have already submitted a bug report to Fedora, and they thought it might be useful to kick it up.
BTW, I have also noticed that the global package.conf.d directory has a mixed format (entries with and w/o a hash) as in:
random-1.0.0.2-f4208c3677aeaaaf41e4d36309c0b4ff.conf
ranges-0.2.3-2cf5a2473b624130e73c098781871f09.conf
regex-base-0.93.2.conf
" tsueako
3 Cabal library 802 copy command should not overwrite files defect normal 2011-02-11T06:21:42-0800 2012-01-05T08:09:31-0800 "see http://hackage.haskell.org/trac/ghc/ticket/4955
Cabal can inadvertently get users into situations where they have registered packages that do not match their package registration information.
Consider the package darcs and darcs-fastconvert which depends on the darcs library. If one installs darcs, then later in the darcs build tree do a `cabal copy` then it will overwrite the library .hi files but not update the library registration. This will mean that subsequent builds of darcs-fastconvert will fail with very confusing error messages (see the ghc ticket above).
A similar thing could happen with inplace registrations.
The suggestion to avoid this problem is for `cabal copy` to refuse to overwrite .hi files (executables are fine).
This is also partly related to #645 because some people are using `cabal copy` to avoid having to use `cabal install` which spends too long reconfiguring and checking nothing needs building before actually installing." duncan
3 Cabal library 807 inplace is shadowed by package defect normal 2011-03-04T22:17:04-0800 2012-03-15T15:13:44-0700 "I have a library, persistent, that builds. When I try to build the test suite, I get:
{{{
Preprocessing library persistent-0.4.0.1...
Preprocessing test suites for persistent-0.4.0.1...
Building persistent-0.4.0.1...
Registering persistent-0.4.0.1...
: cannot satisfy -package-id persistent-0.4.0.1-inplace:
persistent-0.4.0.1-inplace is shadowed by package persistent-0.4.0.1-f5ffa1e952f5d8b58608c8d1f9f69825
(use -v for more information)
}}}
The test-suite build-depends has:
{{{
persistent >= 0.4.0.1,
persistent-mongoDB,
persistent-postgresql,
persistent-sqlite,
}}}
persistent-mongoDB (and postgresql and sqlite) depends on persistent to build.
I have tried this twice now from a fairly clean install- immediately after upgrading to a new version of ghc." guest
3 Cabal library 808 Cabal fails to compile with undefined reference to `resTimerSignal' defect major 2011-03-06T16:03:37-0800 2012-01-05T08:10:05-0800 "When compiling Cabal-1.8.0.4 from source with `ghc --make Setup.hs', it fails on the linking step with:
/home/me/.cabal/lib/unix-2.4.2.0/ghc-6.12.1/libHSunix-2.4.2.0.a(Signals.o): In function `spzw_info':
(.text+0x4d14): undefined reference to `rtsTimerSignal'
" guest
3 cabal-install tool 810 cabal-install requests credentials even when they are listed in the config defect normal 2011-03-09T04:36:46-0800 2012-04-24T15:27:04-0700 "I have listed my Hackage username and password in my cabal config:
`/home/bas/.cabal/config`:
{{{
username: BasVanDijk
password: **********
}}}
Previously this enabled me to `cabal upload` packages to Hackage without entering my credentials. However the new `cabal-install` requests my credentials.
{{{
$ cabal --version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library
}}}" basvandijk
3 Cabal library 817 """main-is"" misparsed in if/else, only by sdist" defect normal 2011-03-21T22:51:16-0700 2011-06-20T10:38:13-0700 "An if/else block which sets the main-is value for an executable based on a flag is misparsed when running ""cabal sdist"" (it's parsed correctly when running ""cabal install"").
Upon failure, it appears that it's looking for a filename that is the two main-is options concatenated together. E.g., I get the error ""cabal: HackerMain.hsMain.hs doesn't exist"".
The problematic bit looks like:
if flag(hacking)
main-is: HackerMain.hs
else
main-is: Main.hs
My entire config can be found on hpaste: http://hpaste.org/44939/yicabal (problematic lines around 268)." jeffwheeler
3 cabal-install tool 820 cabal-install clobbers itself on multi-arch platforms defect normal 2011-03-23T12:47:47-0700 2012-03-03T09:31:29-0800 "On my Mac, I have 32-bit and 64-bit versions of GHC 7.0.2 installed, and cabal installs the object and interface files into the same directory.
The {{{$arch}}} variable looks like it should do the right thing, but in fact it's expanded to whatever architecture cabal-install was built for, not the architecture that's supported by GHC itself." bos
3 cabal-install tool 822 world-file does not support $arch, $os, $compiler defect normal 2011-03-25T09:08:36-0700 2012-03-05T06:33:36-0800 "In my ~/.cabal/config, I have:
install-dirs user
prefix: /home/josh/.cabal/install/$arch-$os-$compiler
This allows packages for multiple architectures (such as 32-bit and 64-bit) or multiple compilers (such as ghc6 and ghc7) to coexist. It also ensures that after upgrading the compiler, old libraries that won't work automatically disappear.
Recent cabal added a ""world"" file, under ~/.cabal/world. I tried to move this to the same directory, by adding:
world-file: /home/josh/.cabal/install/$arch-$os-$compiler/world
However, this generated the following error:
Error while Error while updating world-file. : /home/josh/.cabal/install/$arch-$os-$compiler/: openNewBinaryFile: does not exist (No such file or directory)
From this, I'd guess that cabal doesn't support those variables in world-file like it does in prefix." josh
3 Cabal library 828 Distribution.License datatype and comment weirdness defect minor 2011-04-01T15:21:29-0700 2012-01-05T07:58:24-0800 "Looking at the Distribution.License source, I notice some issues with the comments and (sadly) the data License type. Some of these seem like bugs, some maybe more like enhancement requests.
What seems to me like bugs
==========================
* In the comments, GPL is expanded as ""GNU Public License"". The correct expansion is ""GNU General Public License"".
* AllRightsReserved is really a misnomer. ""All rights reserved"" doesn't mean what many people seem to think it means. Specifically it does NOT mean ""no license granted"". Rather it is a boilerplate text that once was, but no longer is, required in some jurisdictions to get full copyright protection. Nowadays it is entirely superfluous, but still often added to copyright notices by custom. It is *entirely orthogonal* to whether there is some license granted or not.
Possible enhancements
=====================
First, GPL versions. It's quite common to have at least GPLv2 only (for example the Linux kernel is so licensed), GPLv2+ (lots of software), GPLv3 only and GPLv3+ (new software releases by FSF). It appears that there is no distinction between these.
It is also common to grant exceptions (additional permissions) to the GPL (in the way specified by FSF in their FAQ) to allow linking to some GPL-incompatible library. Perhaps a ""plus additional permissions"" modifier could be added.
Second, it's also quite common to have disjunctive licenses, like ""you may distribute this software either under the Q Public License, or the GNU General Public License, version 2 or (at your option) any later version"".
You may want to look at how the Debian project maintains machine-readable specifications of licenses. See, for example, http://dep.debian.net/deps/dep5/
." sli
3 Cabal library 832 Cabal aggregates dependencies for executables defect normal 2011-04-17T20:50:28-0700 2012-01-05T08:09:54-0800 "I discovered over the weekend while trying to subpackage bluetile,
that Cabal seems to aggregate dependencies of executables.
For example
http://hackage.haskell.org/packages/archive/bluetile/0.5.3/bluetile.cabal
generates several executables. Some depend on gtk, others not,
and yet Cabal passes ""--package-id gtk-..."" to ""ghc --make"" for all of them
and as a result the bluetile program (which doesn't depend on gtk)
gets linked against gtk (and glade), leading to executable/dependency bloat.
Only the executables that are listed with explicit build-depends on gtk
should be linked against the gtk package, etc.
I will try to dig into the source later and maybe even cook up
a patch if I can: a code pointer would be appreciated.
I assume Cabal is currently just accumulating all the build-depends which is
sub-optimal. (Arguably ghc shouldn't link unused libraries
to executables either, though I think that is pretty standard compiler behaviour. But I can file a bug against ghc too if appropriate.)" juhp
3 Cabal library 833 Cabal mangles exceptions defect normal 2011-04-21T12:07:25-0700 2011-04-21T12:07:25-0700 "Cabal mangles exceptions, e.g.:
{{{
$ ""utils/ghc-cabal/dist/build/tmp/ghc-cabal"" install ""/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc"" ""/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc-pkg"" "":"" ""/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421"" libraries/ghc-prim dist-install '' '/home/ian/ghc/git/ghc/bindisttest/install dir' '/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421' '/home/ian/ghc/git/ghc/bindisttest/install dir/share/doc/ghc/html/libraries'
Installing library in /home/ian/ghc/git/ghc/bindisttest/install
dir/lib/ghc-7.1.20110421/ghc-prim-0.2.0.0
ghc-cabal: /home/ian/ghc/git/ghc/bindisttest/install
dir/lib/ghc-7.1.20110421/settings: openFile: does not exist (No such file or
directory)
}}}
where a space in the filename has been replaced with a '\n'. This can be very confusing!
It looks like `Distribution.Simple.Utils.topHandler` / `wrapText` is the culprit.
" igloo
3 cabal-install tool 842 cabal appears to complain about relative paths defect normal 2011-05-16T04:27:48-0700 2012-03-10T05:06:17-0800 "With `cabal configure --extra-lib-dirs=foo`
$ cabal build
Preprocessing library HENet-0.0.1...
Building HENet-0.0.1...
Registering HENet-0.0.1...
cabal.exe: HENet-0.0.1: library-dirs: .libs is a relative path (use --force to
override)
Originally reported on irc:
jeffz: the right solution here would be for cabal to make the paths absolute before passing them on to ghc-pkg" jeffz
3 Cabal library 850 Configure fails when an Objective-C .h file is specified defect normal 2011-05-27T11:23:15-0700 2011-05-31T07:03:45-0700 "When configuring a library or executable which has specified a C header with includes: in its .cabal file, and that header is actually Objective-C or includes other headers which are, configure fails. This is because of the test that Cabal does to determine whether all prerequisite C libraries are present, in which it compiles with gcc directly rather than going through the Haskell compiler as it does in the build phase.
I'm working on a patch to this and should have it in about an hour." dankna
3 Cabal library 854 BSD2 and ISC license defect normal 2011-06-01T18:48:20-0700 2012-01-05T08:33:26-0800 Cabal provides BSD3 and BSD4 but not BSD2 and ISC. Please provide them. kazu-yamamoto
3 cabal-install tool 855 http proxy using authentication does not work defect normal 2011-06-08T11:23:13-0700 2012-03-03T09:19:10-0800 "I'm getting an error
No action for prompting/generating user+password credentials provided (use: setAuthorityGen); returning Nothing
when using 'cabal update' being behind proxy that is requiring authentication.
My login and password contain \ and @ symbols, so I have them escaped in HTTP_PROXY environment variable:
HTTP_PROXY=http://domain%5Cuser:passw%40rd@proxy.host:3128
" sms
3 cabal-install tool 856 windows unicode problem with cabal list defect normal 2011-06-18T03:56:04-0700 2012-04-15T23:18:56-0700 "C:\>cabal list dedukti
* dedukti
Synopsis: A type-checker for the cabal.EXE: : invalid argument
http://hackage.haskell.org/packages/archive/dedukti/1.1.4/dedukti.cabal
""A type-checker for the λΠ-modulo calculus.""" guest
3 Cabal library 863 Can't pass extra arguments to c2hs defect normal 2011-07-16T14:48:42-0700 2012-01-05T08:31:56-0800 "With cabal-install 0.10.2, I am no longer able to pass extra arguments to c2hs. When invoked as:
{{{
cabal install -O --c2hs-option=--cppopts=-U__BLOCKS__ --c2hs-options=""--dump=trace"" -v
}}}
c2hs is then called as
{{{
/Users/localuser/.cabal/bin/c2hs --cpp=/usr/bin/gcc --cppopts=-E --cppopts=-D__GLASGOW_HASKELL__=700 --cppopts=-Ddarwin_BUILD_OS --cppopts=-Ddarwin_HOST_OS --cppopts=-Dx86_64_BUILD_ARCH --cppopts=-Dx86_64_HOST_ARCH --cppopts=-Icbits --cppopts=-DUSE_SSE2 --include=dist/build --cppopts=-I/Users/localuser/.cabal/lib/vector-0.7.0.1/ghc-7.0.4/include --cppopts=-I/Users/localuser/.cabal/lib/primitive-0.3.1/ghc-7.0.4/include --cppopts=-I/opt/local/include/ --cppopts=-I/usr/local/lib/ghc-7.0.4/base-4.3.1.0/include --cppopts=-I/usr/local/lib/ghc-7.0.4/include --cppopts=-I/usr/local/lib/ghc-7.0.4/include --output-dir=dist/build --output=Sound/Barnet/BandedLib.hs src/Sound/Barnet/BandedLib.chs --cppopts=-U__BLOCKS__ --dump=trace
}}}
The extra arguments are appended to the end of the call, however c2hs (at least c2hs-0.16.3) requires that the .chs binding file come after all options." guest
3 cabal-install tool 864 worldfile written with incorrect case defect normal 2011-07-17T13:59:44-0700 2012-04-16T00:00:03-0700 "If I issue a command like `cabal install bindings-dsl`, cabal will happily install `bindings-DSL` and write `bindings-dsl` to the world file. Then when I `cabal install --dry-run world`, I get
{{{
Warning: The following 'world' packages will be ignored because they refer to
packages that cannot be found: bindings-dsl
}}}
This seems to be because of the discrepancies in capitalisation -- the world file is case-sensitive, the install command isn't." benmachine
3 Cabal library 866 Making sure external C library DLLs are available at runtime is too easy to get wrong defect normal 2011-07-21T16:59:42-0700 2011-07-24T06:33:37-0700 "I recently installed the hmatrix package on a Windows 7 system via using the Haskell Platform (installed only a few months ago). The hmatrix installation appeared to be successful (with an OK on foreign functions), and I can successfully compile Haskell programs that use hmatrix functions. However, when I attempt to run these programs I get the follow system error:
""The program can't start because lapack.dll is missing from your computer. Try reinstalling the program to fix this problem.""
I get similar error messages if I attempt to use hmatrix functions in ghci (after importing Numeric.LinearAlgebra).
The file lapack.dll is clearly visible in my folder C:\Haskell\gsl, which also includes a gsl subfolder, blas.dll, libgsl-0.dll, and libgslcblas-0.dll. I installed hmatrix with the following parameters
cabal install hmatrix --extra-lib-dir=C:\Haskell\gsl --extra-include-dir=C:\Haskell\gsl
Why is lapack.dll inaccessible at runtime despite successful installation of the package?" guest
3 cabal-install tool 867 sudo cabal update doesn't use http_proxy defect normal 2011-08-02T02:03:14-0700 2012-03-03T09:10:51-0800 "Hi. I'm just installed ghc and some packages including cabal-install and want to do ""cabal update"". I have squid proxy in local network. When i use just ""cabal update"", i see:
=================================================================
sparrow@vb:~/.cabal$ cabal update -v3
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.10.2
Host: hackage.haskell.org
proxy uri host: local_proxy, port: :proxy_port
Creating new connection to local_proxy:proxy_port
Received:
HTTP/1.0 200 OK
Date: Tue, 02 Aug 2011 08:51:16 GMT
Server: Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2
Last-Modified: Tue, 02 Aug 2011 04:38:12 GMT
ETag: ""1bda0be-2de1d4-4a97e50b73500""
Accept-Ranges: bytes
Content-Length: 3006932
Content-Type: application/x-tar
Content-Encoding: x-gzip
X-Cache: MISS from local_proxy
X-Cache-Lookup: MISS from local_proxy:proxy_port
Via: 1.0 local_proxy (squid/3.0.STABLE2)
Proxy-Connection: close
Downloaded to
/home/sparrow/.cabal/packages/hackage.haskell.org/00-index.tar.gz
cabal: /home/sparrow/.cabal/packages/hackage.haskell.org/: permission denied
sparrow@vb:~/.cabal$
=================================================================
When i try to use ""sudo cabal update"":
=================================================================
sparrow@vb:~/.cabal$ sudo cabal update -v3
Downloading the latest package list from hackage.haskell.org
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/0.10.2
Creating new connection to hackage.haskell.org
cabal: timeout
sparrow@vb:~/.cabal$
=================================================================
http_proxy and cabal version:
=================================================================
sparrow@vb:~/.cabal$ set | grep HTTP
HTTP_PROXY=http://local_proxy:proxy_port/
sparrow@vb:~/.cabal$ cabal --v
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library
sparrow@vb:~/.cabal$
=================================================================
So, if i son't use sudo, cabal go through proxy, but hasn't permissions. And if i use sudo, cabal don't use proxy." guest
3 Cabal library 869 patch to make --enable-executable-dynamic work for TemplateHaskell defect normal 2011-08-05T02:56:59-0700 2012-01-05T08:03:19-0800 "The attached patch fixes --enable-executable-dynamic failing when building a executable that uses template-haskell.
The patch just makes ghc output .dyn_hi and .dyn_o files
and builds like for executable profiling:
ie first build a vanilla executable for ghci loading
and then the dynamic executable to keep ghc happy." juhp
3 Cabal library 870 hsc2hs should include cabal_macros.h defect normal 2011-08-08T03:05:16-0700 2012-01-05T08:31:41-0800 "I need to use the `MIN_VERSION_base(x,y,z)` macro in one of my `.hsc` files. However, when building the package with cabal, I get an error that the macro is unknown.
It would be great if `cabal_macros.h` was automatically included." basvandijk
4 Cabal library 876 Build fails for zlib 0.5 defect minor 2011-08-20T04:57:34-0700 2011-09-14T11:01:37-0700 Build fails when using zlib 0.5, version 0.5.3 works fine. Deps should be updated. guest
3 Cabal library 877 "Cabal config breaks on Windows with username ""{""" defect major 2011-08-20T07:51:20-0700 2012-01-05T08:32:14-0800 "I can't do anything because my username is ""{"". Either the parsing is being done incorrectly or the config file was generated incorrectly.
I named myself this deliberately to see if any software would break; kind of sad that the one thing that broke so far is cabal, thought you would know better... My config file is attached.
C:\Program Files (x86)\Console2>cabal --version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library
C:\Program Files (x86)\Console2>cabal update
Warning: Error parsing config file C:\Users\{\AppData\Roaming\cabal\config:46:
opening brace '{'has no matching closing brace '}'
Warning: Using default configuration.
Downloading the latest package list from hackage.haskell.org" guest
3 hackageDB website 879 source link broken for some Prelude types in online documentation defect normal 2011-08-27T23:14:13-0700 2011-08-27T23:14:13-0700 "http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html links to http://hackage.haskell.org/packages/archive/base/latest/doc/ghc-prim-0.2.0.0/src/GHC-Types.html and http://hackage.haskell.org/packages/archive/base/latest/doc/integer-gmp-0.2.0.3/src/GHC-Integer-Type.html and http://hackage.haskell.org/packages/archive/base/latest/doc/ghc-prim-0.2.0.0/src/GHC-Bool.html which obtain 404s.
Apologies if reporting bug in wrong place." mlinksva
3 miscellaneous 882 bootstrap.sh fails to compile transformers-0.2.2.0 defect normal 2011-09-12T12:03:32-0700 2012-01-05T08:00:18-0800 "When running the bootstrap.sh script, it downloads and tries to compile transformers-0.2.2.0, but fails to compile its Setup.hs (???)
Downloading transformers-0.2.2.0...
<<>>
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
ghc: fd:9: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)
" guest
3 Cabal library 886 when installing globally, cabal shouldn't use umask, should set mods to 755 or 644 defect normal 2011-09-18T11:01:44-0700 2012-01-05T08:32:51-0800 "I have an umask 077 on my root user, but when i type:
cabal install --global pkg
or I have a global setting in my configuration file, cabal installs the package globally, but with root's umask.
cabal is a package manager and if I install a package globally, I expect it to be accessible globally." alistra
3 Cabal library 888 runTests deprecated message should be more helpful defect normal 2011-09-27T10:00:05-0700 2012-02-16T12:31:00-0800 "It would be great if this message explained what the new testing interface was, where to find it, and optimally how to quickly create something more or less equivalent to the runTests function so we can get on with our lives. :)
Warning: In the use of `runTests'
(imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks):
Deprecated: ""Please use the new testing interface instead!""" dsfox
4 Cabal library 893 Bad cabal build error message with mangled top of file defect normal 2011-10-02T05:56:21-0700 2012-01-05T08:31:47-0800 "I accidentally executed an Emacs keystroke that switched tokens around and mangled the top of my file:
{-# Language BangPatterns, CPP #-} # OPTIONS_GHC
{--fno-warn-name-shadowing -fwarn-unused-imports #-}
When GHC is run directly on this file it gives a sensible error message
Control/Monad/Par/Stream.hs:1:36: parse error on input `#'
But when building through cabal build it looks like there is a module-name-finding heuristic that is failing (and defaulting to Main), resulting in this weird error message:
Building monad-par-0.1.0.2...
Control/Monad/Par/Stream.hs:1:1:
File name does not match module name:
Saw: `Main'
Expected: `Control.Monad.Par.Stream'
Which really caused me to scratch my head when I saw it ;-). (""No where does it say Main!!"") I was afraid I had messed up paths and was loading a different version of the file from another directory or something...
" rrnewton
3 Cabal library 895 Mis-parses curly braces in package description defect normal 2011-10-05T05:46:08-0700 2012-01-05T08:26:44-0800 "Curly braces can be used to replace the layout rule in cabal file. This features seems to go wrong when curly braces are used in the description field, where they are also replaced by line breaks or something similar.
This is inconvenient for those trying to give good documentation already in the description, e.g.
http://hackage.haskell.org/package/BlogLiterately
and
http://hackage.haskell.org/package/hamlet
Curly braces inside the description (or probably inside any field) should be left alone; or at least some escaping mechanisms needs to be provided." nomeata
3 Cabal library 898 "With TH, when doing ""cabal haddock"", GHCi ""couldn't find symbol""" defect normal 2011-11-11T15:41:19-0800 2011-11-13T00:58:31-0800 "GHC 7.2.1, Cabal HEAD, Haddock 2.9.2. The message
{{{
During interactive linking, GHCi couldn't find the following symbol:
Allurezm0zi4zi2_UtilsziMultiline_multiline_closure
}}}
How to reproduce: get package http://hackage.haskell.org/package/Allure-0.4.2, cabal install, cabal haddock --executables and you should get the following:
{{{
Running Haddock for Allure-0.4.2...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ConfigFile-1.1.1, HUnit-1.2.4.2,
MissingH-1.1.1.0, ffi-1.0, rts-1.0, cairo-0.12.1, deepseq-1.1.0.2, gio-0.12.1,
glib-0.12.1, gtk-0.12.1, hslogger-1.1.5, mtl-2.0.1.0, network-2.3.0.6,
pango-0.12.1, parsec-3.1.2, random-1.0.1.0, regex-base-0.93.2,
regex-compat-0.95.1, regex-posix-0.95.1, text-0.11.1.6, transformers-0.2.2.0,
zlib-0.5.3.1
Preprocessing executable 'BotAllure' for Allure-0.4.2...
haddock coverage for dist/build/tmp-28531/src/Bot.hs: 0/3 0%
Warning: Main: could not find link destinations for:
System.Random.StdGen
Documentation created: dist/doc/html/Allure/BotAllure/index.html
Preprocessing executable 'Allure' for Allure-0.4.2...
haddock coverage for dist/build/autogen/Paths_Allure.hs: 0/4 0%
haddock coverage for dist/build/tmp-28531/src/Utils/File.hs: 0/3 0%
haddock coverage for dist/build/tmp-28531/src/Frequency.hs: 0/6 0%
haddock coverage for dist/build/tmp-28531/src/Strategy.hs: 1/7 14%
haddock coverage for dist/build/tmp-28531/src/Content/Content.hs: 0/2 0%
haddock coverage for dist/build/tmp-28531/src/Utils/Multiline.hs: 1/2 50%
During interactive linking, GHCi couldn't find the following symbol:
Allurezm0zi4zi2_UtilsziMultiline_multiline_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
}}}
The same problem for a library, with or without executables, with the same code. Hiding, in the library, the offending module Multiline does not help. The only thing that helps is eta-expanding the Multiline code as follows:
{{{
-multiline = TQ.QuasiQuoter (TH.litE . TH.stringL) undefined undefined undefined
+multiline = TQ.QuasiQuoter (\x -> (TH.litE . TH.stringL) x) undefined undefined undefined
}}}
and _not_ using the function in the only place where it's used." MikolajKonarski
3 Cabal library 900 cabal no longer supports package version tags defect minor 2011-11-20T04:27:22-0800 2011-11-21T04:06:39-0800 "The following cabal file below triggers an assertion fail on the second install:
{{{
$ cabal --version
cabal-install version 0.13.3
using version 1.13.3 of the Cabal library
$ cabal install
Resolving dependencies...
Configuring foobar-0.2.0...
Building foobar-0.2.0...
Preprocessing library foobar-0.2.0...
[1 of 1] Compiling FooBar ( FooBar.hs, dist/build/FooBar.o )
[1 of 1] Compiling FooBar ( FooBar.hs, dist/build/FooBar.p_o )
Registering foobar-0.2.0...
Installing library in /home/hvr/.cabal/lib/foobar-0.2.0/ghc-7.2.2
Registering foobar-0.2.0...
$ cabal install
Resolving dependencies...
Configuring foobar-0.2.0...
cabal: Distribution/Simple/PackageIndex.hs:123:8-13: Assertion failed
}}}
Only when I unregister the installed package via `ghc-pkg unregister foobar` I can configure the package again...
The cabal file causing this behaviour:
{{{
name: foobar
version: 0.2.0-git20111120
synopsis: none
license: BSD3
license-file: LICENSE
author: foo
maintainer: foo@bar
build-type: Simple
cabal-version: >=1.10
library
default-language: Haskell2010
exposed-modules: FooBar
build-depends: base
}}}
The `FooBar` module is just a dummy empty module. This used to work previously, e.g. with
{{{
$ cabal-0.11.2 --version
cabal-install version 0.11.2
using version 1.12.0 of the Cabal library
}}}" guest
3 User guide 903 Broken links in user guide defect minor 2011-12-05T07:17:08-0800 2011-12-05T07:17:08-0800 "This page contains links that give 404 Not Found:
http://www.haskell.org/cabal/users-guide/
For example ""Distribution.Make"" link: http://www.haskell.org/cabal/libraries/Cabal/Distribution-Make.html" graphov
2 Hackage 2 server 911 Package uploading is completely unsecured defect major 2012-02-14T08:46:42-0800 2012-02-14T20:10:57-0800 "Right now, anyone can register an account (without passing any kind of CAPTCHA or anything, so bots will overrun the place quickly on a live site) and upload new packages to their heart's content. This is a major risk for several reasons (package installation can do evil stuff with custom build types, easy to use up tons of disk space, etc.)
Of course, nothing can truly solve the security issue, but I suggest the following:
1. A simple but Hackage-specific CAPTCHA on the registration page (e.g. ""What language are HackageDB packages written for?"") — it's unlikely that spambots will target it specifically, and a simple but unique CAPTCHA will be stronger than a generic solution like reCAPTCHA which has a lot of effort going into breaking it (e.g. someone being paid to fill out CAPTCHAs isn't going to have any idea that the answer is ""Haskell"")
2. Limit package uploading to members of a group which only admins can add to
This should be a simple change to the code. The workflow for a package uploader would be:
1. Register an account
2. Email the maintainer asking for a package upload
This is basically the same as the Hackage1 registration process, but a bit easier for the maintainer.
{{{
bgamari, cmccann, elliott: so the auth system in the new design copes ok with package
uploaders, what it does not cover well is casual users who might want to post reviews, vote etc,
but not upload packages
since you probably want self-registration for those users
but for uploaders it's sensible to have a human in the loop
Certainly
like we do in the current system
so there's an admin user group who can edit other groups
ie grant permissions
[...]
elliott, cmccann: right, plus in the new system since there's a per-package uploader
group then unknown users cannot subvert well known names (ie packages)
so in the new system malicious people can still upload *new* malicious packages
but cannot subvert e.g. base
}}}
An ideal solution would be something like:
1. Reasonable per-user quotas (liftable on request) for disk usage, to stop people spamming the system
2. Users by default can upload packages, but they're in a quarantine: not visible on the site or installable
3. Whenever a user uploads their first package, the maintainer gets an email and can check it out and approve the user (making their packages public) if it looks OK
That would be nicer, but probably require a lot more coding than the simpler solution.
" bgamari
3 Hackage 2 server 919 hackage-mirror should handle errors more gracefully defect normal 2012-02-21T16:22:14-0800 2012-02-21T16:22:14-0800 "hackage-mirror against hackage.haskell.org fails with,
{{{
$ hackage-mirror http://hackage.haskell.org/ http://bgamari:xxx@localhost:8080/
17816 packages to mirror.
mirroring PlslTools-0.0.1
hackage-mirror: Failed to upload package PlslTools-0.0.1,
HTTP error code 400, Bad Request
http://bgamari:...@localhost:8080/package/PlslTools-0.0.1/PlslTools-0.0.1.tar.gz
short tar trailer
}}}
While the source of the error is unclear, it's a sign that the error handling should be more robust. Perhaps failing packages should be skipped until it's very clear that something is horribly wrong (e.g. a heuristic like 10 packages fail in a row)?" bgamari
3 cabal-install tool 922 “lexical error (UTF-8 decoding error)” in WIndows 7 defect minor 2012-03-02T05:02:11-0800 2012-04-15T23:20:27-0700 "==== Symptom ====
When I type
> cabal install cabal
it fails with the following error:
> Distribution\Compat\Exception.hs:0:4: lexical error (UTF-8 decoding error)
==== Environment ====
It happens with 64 bit version of Windows 7.
It came to occur after I failed to install HXT. (I am not sure it is related.)
==== Workaround ====
By setting
> set LANG=C
in command line, cabal comes to work.
I regard this is just a workaround and this issue should be reported as a bug.
==== Related links ====
http://stackoverflow.com/questions/9371438/cabal-install-complains-built-in04-lexical-error-utf-8-decoding-error/9533205#9533205
http://trac.haskell.org/network/ticket/43" hamukazu
3 cabal-install tool 924 symlink-bindir does not play nice with program-suffix defect normal 2012-03-05T12:22:06-0800 2012-03-09T00:39:58-0800 "I'd expect symlinks to be created with the program-suffix. Instead what happens is that cabal-install correctly suffixes the installed binary, but attempts to create a symlink to it from an unsuffixed name, which can fail if the unsuffixed name already exists in the symlink-bindir.
{{{
~ $ cabal --version
cabal-install version 0.13.3
using version 1.14.0 of the Cabal library
}}}
Example:
{{{
gruff $ cabal install --program-suffix=-fixed
...[snip]...
Warning: could not create a symlink in /home/claude/opt/bin for gruff because
the file exists there already but is not managed by cabal. You can create a
symlink for this executable manually if you wish. The executable file has been
installed at /home/claude/.cabal/bin/gruff-fixed
}}}
(The symlink already existed in this particular case, because I wanted to install my development program with a suffix to avoid clobbering the known working version.)
" guest
3 cabal-install tool 928 Modular solver needs support for ghc-6.12's base-wrapping defect normal 2012-03-11T03:52:14-0700 2012-04-05T00:04:31-0700 "In ghc-6.12, we had the situation that base-3 was a wrapper around base-4. The modular solver can currently not handle that situation, thereby making it mostly useless when used with ghc-6.12. For later ghc versions, this no longer occurs, thus isn't an issue. This is one reason why the modular solver currently is not the default.
Options:
* Add a hack to the modular solver to deal with it, much like it is done in the topdown solver.
* Make the default solver being used dependent on the version of ghc (but that might be confusing).
" kosmikus
3 Cabal library 930 cabal test is dropping --test-option flags defect normal 2012-03-12T08:25:23-0700 2012-04-15T23:24:06-0700 "Adding two `--test-option` flags doesn't work correctly. For example, this
{{{
cabal test --test-option=--plain
}}}
causes cabal to (correctly) pass the `--plain` flag to the underlying test-framework binary. However, this
{{{
cabal test --test-option=--plain --test-option=--jxml=dist/unit-tests.xml
}}}
drops it on the ground. Some debug output
{{{
cabal test --test-option=--plain --test-option=--jxml=dist/unit-tests.xml -v3
Using external setup method with build-type Custom
Creating ./dist/setup (and its parents)
Using Cabal library version 1.14.0
Using ./Setup.hs as setup script.
./dist/setup/setup test --verbose=3 --test-options=--jxml=dist/unit-tests.xml
--test-option=--jxml=dist/unit-tests.xml
}}}
There looks like there's an extra newline in the `./dist/setup/setup` invocation, perhaps that's the issue?
The problem can be reproduced on Cabal's own test suite." tibbe
3 cabal-install tool 934 cabal seems to require access to user HOME directory defect normal 2012-03-15T05:46:20-0700 2012-03-15T05:46:20-0700 "Jason Dusek reports:
I am trying to do an automated install of Cabal packages, on EC2
using Ubuntu's cloud-config. The error above was caught in my
logs.
Cloud-config sets up a minimal environment prior to running any
tasks. All the package managers I've worked with so far -- gem,
npm, apt -- have no problem with this. It would be nice to find
a way to turn off Cabal's user-centric behaviour.
Duncan says:
You may need to hack the code I'm afraid. It gets the home dir as part
of reading the configuration file. Look for where it uses
getAppUserDataDirectory. In particular it's used indirectly in
baseSavedConfig, though it should mostly get overridden if the config
file is found. So additionally you'd need to specify a cabal config
file on the command line to avoid it looking for ~/.cabal/config
Let us know how it goes, we can integrate changes you make.
" kosmikus
3 Cabal library 937 cabal-install cannot pass package ids to the build process defect normal 2012-04-05T11:40:30-0700 2012-04-05T11:44:02-0700 "The solver determines an install plan that fixes package ids of installed packages.
However, the Setup interface currently does not allow us to specify package ids once we start building; we can only fix the versions.
This can lead to problems in situations where multiple instances of the same package version are installed on a system, and the install plan selects one, but we cannot uniquely communicate that to the builder." kosmikus
3 cabal-install tool 938 cabal test does not tail standard output of the running test executable defect minor 2012-04-10T02:52:41-0700 2012-04-24T23:11:19-0700 "== Problem: ==
cabal test does not tail standard output of the running test executable. Instead, any output from the executable is output right at the end of the test process in one batch.
== Motivation: ==
It is incredibly useful to have cabal test tail the stdout of the test executable currently being executed such that CI tools such as TeamCity can be made to record the time it takes to run individual tests.
== Reproduction: ==
Run the following simple executable as a test executable with
{{{cabal test --show-details=always}}}
{{{
module Main where
import Control.Concurrent
delay = 5000000
main = do
putStrLn ""First message""
threadDelay delay
putStrLn ""Second message""
threadDelay delay
putStrLn ""Third message""
threadDelay delay
}}}
Instead of outputting each line (""First/Second/Third message"") five seconds after another, all three lines are output along with test result reporting all at once at the end of the test suite." fushunpoon
3 cabal-install tool 942 cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag defect normal 2012-04-20T10:43:18-0700 2012-05-04T00:42:35-0700 kosmikus
2 Cabal library 943 Synopsis field causes haddock build failure defect normal 2012-04-20T17:48:36-0700 2012-04-21T00:12:13-0700 "For some reason the presence of the 'synopsis' field causes haddock documentation to fail to build.
Steps:
$ cabal unpack dclabel
$ cabal configure
$ cabal haddock
{{{
Running Haddock for dclabel-0.0.6...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: rts-1.0, cereal-0.3.5.1
Preprocessing library dclabel-0.0.6...
:
Could not find module `The'
Use -v to see a list of the files searched for.
}}}
I assume something is mis-configured on my system but have no idea what and how to fix it
Versions:
{{{
$ cabal --version
cabal-install version 0.14.0
using version 1.14.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
$ haddock --version
Haddock version 2.10.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
}}}
This is on Ubuntu Linux 11.10." davidt
3 Cabal library 944 Duplicate C symbol names defect normal 2012-04-22T06:07:53-0700 2012-04-22T06:07:53-0700 "I've run into a problem where I want to include the vty and haskeline packages, which both contain the same C code, of which the symbol names are not translated or made unique. When I use both packages, and try to compile something which has Template Haskell (which triggers loading of all dependencies), I get the following error.
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_mk_wcswidth
whilst processing object file
/Users/paul/.cabal/lib/haskeline-0.6.4.6/ghc-7.2.2/HShaskeline-0.6.4.6.o
A workaround is to patch the libraries to make the function names unique, but this is less than ideal. " PaulVanDerWalt
2 cabal-install tool 945 Fails to find install plan for containers package tests defect major 2012-04-24T11:50:08-0700 2012-04-25T03:40:16-0700 "The containers package has a test-suite section which seems to create a cycle when building the package. Could it be that Cabal treats the package as one unit instead of treating the library and test-suite sections separately, which should remove the cycle.
{{{
$ cabal install --enable-tests -v3
searching for ghc in path.
found ghc at /usr/local/bin/ghc
(""/usr/local/bin/ghc"",[""--numeric-version""])
/usr/local/bin/ghc is version 7.4.1
looking for tool ""ghc-pkg"" near compiler in /usr/local/bin
found ghc-pkg in /usr/local/bin/ghc-pkg
(""/usr/local/bin/ghc-pkg"",[""--version""])
/usr/local/bin/ghc-pkg is version 7.4.1
(""/usr/local/bin/ghc"",[""--supported-languages""])
(""/usr/local/bin/ghc"",[""--info""])
Reading installed packages...
(""/usr/local/bin/ghc-pkg"",[""dump"",""--global"",""-v0""])
(""/usr/local/bin/ghc-pkg"",[""dump"",""--user"",""-v0""])
(""/usr/local/bin/ghc"",[""--print-libdir""])
Reading available packages...
Choosing modular solver.
Resolving dependencies...
[__0] trying: containers-0.5.0.0 (user goal)
[__1] next goal: base (dependency of containers-0.5.0.0)
[__1] rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance)
[__1] trying: base-4.5.0.0/installed-f76...
[__2] trying: rts-1.0/installedbuil... (dependency of base-4.5.0.0/installed-f76...)
[__3] trying: integer-gmp-0.4.0.0/installed-ec8... (dependency of base-4.5.0.0/installed-f76...)
[__4] rejecting: containers-0.5.0.0:!test (global constraint requires opposite flag selection)
[__4] trying: containers-0.5.0.0:*test
[__5] trying: test-framework-quickcheck2-0.2.12.1 (dependency of containers-0.5.0.0:*test)
[__6] trying: test-framework-quickcheck2-0.2.12.1:+base4
[__7] trying: test-framework-quickcheck2-0.2.12.1:-base3
[__8] trying: random-1.0.1.1/installed-3be... (dependency of test-framework-quickcheck2-0.2.12.1:+base4)
[__9] trying: time-1.4/installed-3e1... (dependency of random-1.0.1.1/installed-3be...)
[_10] trying: old-locale-1.0.0.4/installed-29b... (dependency of time-1.4/installed-3e1...)
[_11] trying: extensible-exceptions-0.1.1.4/installed-d27... (dependency of test-framework-quickcheck2-0.2.12.1)
[_12] trying: test-framework-hunit-0.2.7 (dependency of containers-0.5.0.0:*test)
[_13] trying: test-framework-hunit-0.2.7:+base4
[_14] trying: test-framework-hunit-0.2.7:-base3
[_15] trying: test-framework-0.6 (dependency of containers-0.5.0.0:*test)
[_16] trying: test-framework-0.6:-tests
[_17] trying: test-framework-0.6:+splitbase
[_18] trying: hostname-1.0 (dependency of test-framework-0.6)
[_19] trying: xml-1.3.12 (dependency of test-framework-0.6)
[_20] trying: text-0.11.2.0/installed-a62... (dependency of xml-1.3.12)
[_21] trying: bytestring-0.9.2.1/installed-4ad... (dependency of xml-1.3.12)
[_22] trying: regex-posix-0.95.1 (dependency of test-framework-0.6)
[_23] trying: regex-posix-0.95.1:+splitbase
[_24] trying: regex-posix-0.95.1:+newbase
[_25] trying: regex-base-0.93.2 (dependency of regex-posix-0.95.1:+newbase)
[_26] trying: regex-base-0.93.2:+splitbase
[_27] trying: regex-base-0.93.2:+newbase
[_28] trying: mtl-2.1/installed-0a8... (dependency of regex-base-0.93.2:+newbase)
[_29] trying: transformers-0.3.0.0/installed-f23... (dependency of mtl-2.1/installed-0a8...)
[_30] trying: ansi-wl-pprint-0.6.4 (dependency of test-framework-0.6)
[_31] trying: ansi-wl-pprint-0.6.4:+newbase
[_32] trying: ansi-wl-pprint-0.6.4:-example
[_33] trying: ansi-terminal-0.5.5 (dependency of test-framework-0.6)
[_34] trying: ansi-terminal-0.5.5:+splitbase
[_35] trying: ansi-terminal-0.5.5:-example
[_36] trying: unix-2.5.1.0/installed-346... (dependency of ansi-terminal-0.5.5)
[_37] trying: QuickCheck-2.4.2 (dependency of containers-0.5.0.0:*test)
[_38] trying: QuickCheck-2.4.2:+templatehaskell
[_39] trying: QuickCheck-2.4.2:+base4
[_40] trying: QuickCheck-2.4.2:+base3
[_41] next goal: template-haskell (dependency of QuickCheck-2.4.2:+templatehaskell)
[_41] rejecting: template-haskell-2.7.0.0/installed-164... (conflict: containers==0.5.0.0, template-haskell => containers==0.4.2.1/installed-7c5...)
[_41] trying: template-haskell-2.7.0.0
[_42] trying: pretty-1.1.1.0/installed-7e1... (dependency of template-haskell-2.7.0.0)
[_43] trying: HUnit-1.2.4.2 (dependency of containers-0.5.0.0:*test)
[_44] trying: HUnit-1.2.4.2:+base4
[_45] trying: ghc-prim-0.2.0.0/installed-bd2... (dependency of containers-0.5.0.0)
[_46] trying: deepseq-1.3.0.0/installed-6c1... (dependency of containers-0.5.0.0)
[_47] next goal: array (dependency of containers-0.5.0.0)
[_47] trying: array-0.4.0.0/installed-0b3...
[_48] done
cabal: internal error: could not construct a valid install plan.
The proposed (invalid) plan contained the following problems:
The following packages are involved in a dependency cycle test-framework-hunit-0.2.7, test-framework-0.6, regex-posix-0.95.1, regex-base-0.93.2, containers-0.5.0.0, test-framework-quickcheck2-0.2.12.1, QuickCheck-2.4.2, template-haskell-2.7.0.0
}}}
" tibbe
2 Cabal library 946 Packages are downloaded insecurely defect major 2012-04-26T03:16:56-0700 2012-04-26T03:16:56-0700 "It appears that when running cabal install package, the package is downloaded without any transport security.
Anyone who can perform a man in the middle attack could tamper with the package that is being downloaded, resulting in a complete compromise of the cabal user.
This makes it impossible to use cabal.
The servers should utilize TLS, it is possible to get a free certificate from startcom if price is a concern.
Additionally when packages are verified as non-malicious, they should be signed with a ""cabal"" signing key, and then the package signatures should be verified by cabal." cooldude
3 Cabal library 950 no dyn_o generated for C files defect normal 2012-05-11T13:01:43-0700 2012-05-11T13:01:43-0700 "When verifying a bug in GHC-7.5.20120510 I think I discovered a bug in Cabal-1.15.0 that is shipped with the nightly build of GHC.
In the llvm-base package the C/C++ modules in the cbits directory are only compiled for the static version and the dynamic objects are not generated. This results in the compiler error:
{{{
gcc: dist/build/cbits/extra.dyn_o: file not found
gcc: dist/build/cbits/free.dyn_o: file not found
gcc: dist/build/cbits/malloc.dyn_o: file not found
gcc: dist/build/cbits/support.dyn_o: file not found
}}}
" guest
3 cabal-install tool 952 cabal-install-0.14.0 dependencies are incorrect defect normal 2012-05-15T05:08:23-0700 2012-05-15T05:08:23-0700 "Apparently, we depend on transformers >= 0.2.2.0 (indirectly via mtl).
Should either adapt the code to work with older versions or fix the dependency." kosmikus
3 Cabal library 953 Alex-generated Lexer isn't found when building test-suite defect normal 2012-05-15T15:24:12-0700 2012-05-15T15:24:12-0700 "I'd like to use my Alex-generated lexer in my test-suite. I've tried adding other-modules/build-tools to my test-suite section, but upon building the Lexer module isn't found.
I've got no problems using the lexer within my normal executable. Should I be able to use my Lexer in the test-suite?
I'll attach a fairly minimal example, the Main module and the TestSuite module both use the Lexer, Main will compile, TestSuite won't:
$ cabal configure --enable-tests
$ cabal build
[... blurb]
Preprocessing test suite 'tests' for test-suite-with-alex-0.0...
tests/TestSuite.hs:7:8:
Could not find module `MyLexer'
Perhaps you meant Lexer (needs flag -package ghc-7.4.1)
Use -v to see a list of the files searched for.
" owst
3 Cabal library 954 setup haddock fails for packages without modules defect normal 2012-05-20T08:42:59-0700 2012-05-20T08:42:59-0700 "http://hackage.haskell.org/package/diagrams-0.5 is a meta-package, i.e. only depends on other packages. Running setup haddock fails:
{{{
$ ./Setup haddock --hyperlink-source
Running Haddock for diagrams-0.5...
Running hscolour for diagrams-0.5...
Preprocessing library diagrams-0.5...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: rts-1.0
Preprocessing library diagrams-0.5...
haddock: No input file(s).
}}}
Not a big deal, but still a corner-case that could be fixed." nomeata
3 Cabal library 955 Incorrect hpcdir during cabal test for testsuites w/ library coverage enabled defect normal 2012-05-20T23:08:05-0700 2012-05-20T23:08:05-0700 "When running ""cabal test"" on a project configured with ""cabal configure --enable-tests --enable-library-coverage"", the hpcdir for test suites points to dist/hpc/mix/PackageName, not dist/hpc/mix/TestSuiteName.
This results in an aborted run:
{{{
PS C:\Users\Albert Fong\Repositories\working\projects\Simple> runhaskell.exe .\Setup.hs test -v
Running 3 test suites...
Test suite Tests3: RUNNING...
Test suite Tests3: PASS
Test suite logged to: dist\test\Simple-0.1.0.0-Tests3.log
C:\Users\Albert Fong\Repositories\working\devenv\tools\ghc-7.4.1\bin\hpc.exe markup dist\hpc\tix\Tests3\Tests3.tix --hpc
dir=dist\hpc\mix\Simple-0.1.0.0 --destdir=dist\hpc\html\Tests3 --exclude=Main
hpc.exe: can not find Library in [""./dist\\hpc\\mix\\Simple-0.1.0.0""]
PS C:\Users\Albert Fong\Repositories\working\projects\Simple>
}}}
Note the hpcdir during build (""-fhpc -hpcdir dist\hpc\mix\Tests3"") is not what's used during test (""--hpcdir=dist\hpc\mix\Simple-0.1.0.0"")
{{{
Preprocessing test suite 'Tests3' for Simple-0.1.0.0...
Building test suite Tests3...
creating dist\build\Tests3
creating dist\build\Tests3\Tests3-tmp
C:\Users\Albert Fong\Repositories\working\devenv\tools\ghc-7.4.1\bin\ghc.exe --make -o dist\build\Tests3\Tests3.exe -hid
e-all-packages -fbuilding-cabal-package -no-user-package-conf -package-conf dist\package.conf.inplace -i -idist\build\Te
sts3\Tests3-tmp -i. -idist\build\autogen -Idist\build\autogen -Idist\build\Tests3\Tests3-tmp -optP-include -optPdist\bui
ld\autogen\cabal_macros.h -odir dist\build\Tests3\Tests3-tmp -hidir dist\build\Tests3\Tests3-tmp -stubdir dist\build\Tes
ts3\Tests3-tmp -package-id base-4.5.0.0-597748f6f53a7442bcae283373264bb6 -O -fhpc -hpcdir dist\hpc\mix\Tests3 -XHaskell9
8 .\Tests.hs
}}}
Here's the layout of the dist/hpc folder:
{{{
dist\hpc\mix
dist\hpc\mix\Simple-0.1.0.0
dist\hpc\mix\Simple-0.1.0.0\Simple-0.1.0.0
dist\hpc\mix\Simple-0.1.0.0\Simple-0.1.0.0\Library.mix
dist\hpc\mix\Tests1
dist\hpc\mix\Tests1\Library.mix
dist\hpc\mix\Tests1\Main.mix
dist\hpc\mix\Tests2
dist\hpc\mix\Tests2\Library.mix
dist\hpc\mix\Tests2\Main.mix
dist\hpc\mix\Tests3
dist\hpc\mix\Tests3\Library.mix
dist\hpc\mix\Tests3\Main.mix
dist\hpc\tix
dist\hpc\tix\Tests3
dist\hpc\tix\Tests3\Tests3.tix
}}}
The double nested ""Simple-0.1.0.0"" under mix may be another issue as well.
A cabal project used to repro this issue is attached." albertfong