__color__,__group__,ticket,summary,component,version,type,severity,owner,status,created,_changetime,_description,_reporter 2,cabal-install-0.16 Release,945,Fails to find install plan for containers package tests,cabal-install tool,1.14.0,defect,major,kosmikus,assigned,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 3,cabal-install-0.16 Release,234,track installed files to allow uninstall,cabal-install tool,1.2.3.0,enhancement,major,,new,2008-02-11T12:49:26-0800,2012-03-08T00:56:51-0800,"`cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc.",duncan 3,cabal-install-0.16 Release,382,'cabal ghci' mode,cabal-install tool,,enhancement,major,duncan,new,2008-10-27T22:33:14-0700,2012-04-05T20:58:48-0700,"See http://www.haskell.org/pipermail/haskell-cafe/2008-October/049830.html and http://www.haskell.org/pipermail/haskell-cafe/2008-October/049913.html. Two things would be nice: ""cabal ghci"" loads the main-is file in ghci; and ""cabal ghci Data.My.Module"" loads the listed modules in ghci. Reiner",guest 3,Cabal-2.0 Release,128,cabal building broken libraries when module list is not complete,Cabal library,1.1.6,defect,major,,new,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-1.8 Release,808,Cabal fails to compile with undefined reference to `resTimerSignal',Cabal library,1.8.0.6,defect,major,,new,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 2, Release,911,Package uploading is completely unsecured,Hackage 2 server,1.8.0.6,defect,major,,new,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 2, Release,946,Packages are downloaded insecurely,Cabal library,1.10.2.0,defect,major,,new,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, Release,738,"Recompiling the same library version can change its ABI, causing breakage (even of Cabal)",Cabal library,1.8.0.4,defect,major,,new,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, Release,837,Compile the same package with respect to several sets of flag states,Cabal library,1.10.1.0,enhancement,major,,new,2011-04-24T08:53:17-0700,2011-04-24T08:53:17-0700,"Currently I have configured my cabal with --enable-library-profiling, --enable-shared, what leads to problems with the GHC-7.0.* archives that do not contain shared objects for profiling. Actually, I do not need them, but I cannot tell Cabal to omit shared objects for profiling. If I use --enable-library-profiling and --enable-shared, then all combinations of {static, dynamic} x {non-profiling, profiling} are generated. Instead of enabling two variants by each of those 'enable' options and then generating code for all possible combinations, I would find it more useful to define sets of flags and compile modules with respect to all of these flag sets. E.g. I could write something like the following to ~/.cabal/config: {{{ flagset: dyn shared: True optimization: True flagset: p shared: False profiling: True optimization: True rts-options: True flagset: dbg flags: debug optimization: True }}} For every module A this should generate A_dyn.o, A_p.o, A_dbg.o. I do not know whether this problem can be solved in Cabal alone, or whether it also needs adaption of GHC. See also: * #600 * http://hackage.haskell.org/trac/ghc/ticket/5021 ",lemming 3, Release,877,"Cabal config breaks on Windows with username ""{""",Cabal library,1.10.1.0,defect,major,,new,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 2,cabal-install-0.16 Release,447,build multiple packages in parallel,cabal-install tool,,enhancement,normal,refold,assigned,2009-01-10T08:01:35-0800,2012-04-24T15:43:38-0700,"The latest version of the gentoo portage tool is rather slick. It can do parallel builds and it displays a nice summary on the command line, eg: {{{ # emerge -uD system -j --load-average=4.5 Calculating dependencies... done! >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 14) dev-libs/expat-2.0.1-r1 >>> Emerging (2 of 14) sys-devel/autoconf-wrapper-6 >>> Emerging (3 of 14) sys-kernel/linux-headers-2.6.27-r2 >>> Installing sys-devel/autoconf-wrapper-6 >>> Jobs: 0 of 14 complete, 1 running Load avg: 2.99, 1.59, 0.67 }}} Note how they solve the problem of how to display what is going on when there are multiple builds happening. The answer is not to display it at all! This would have to go hand-in-hand with logging all builds so that we can still diagnose failures. Note the final line, that gets updated to display the current number of jobs running, the number completed etc. It also shows the load average. The job scheduler has two parameters, one is a maximum number of jobs (or unlimited) and the other is a load average. It will only launch new jobs if the load average is less than the given maximum. That allows it to interact reasonably well with builds that use `make -j` internally. In the example above I set the load average to be just slightly more than the number of CPUs I've got. It looks to me like it serialises some bits, like installing, since saturating the disk with multiple parallel installs is generally of no benefit, indeed it can be slower. Also downloads seem to be serialised, again because there is probably little benefit to making multiple connections to the same server. Anyway, the point is, cabal-install ought to be able to do all this. Some bits we can do now. We already have a graph representation of the install plan and we recalculate when a package fails to install. We will need an improved download api, probably involving sending requests off to a dedicated download thread (which would serialise them).",duncan 2,cabal-install-0.16 Release,453,"""cabal fetch"" should take output arguments",cabal-install tool,HEAD,enhancement,normal,,new,2009-01-12T13:15:22-0800,2012-03-06T10:46:04-0800,"It would be nice if ""cabal fetch"" could output the fetched tarball to a location specified on the command line, i.e.: cabal fetch bytestring -o foo.tgz This probably depends on #423.",gregorycollins 2,cabal-install-0.16 Release,474,cabal-install needlessly reinstalls an existing package,cabal-install tool,1.6.0.1,defect,normal,kosmikus,new,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,cabal-install-0.16 Release,131,cabal-install should rebuild dependants when a package is upgraded,cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,223,allow per-package configuration options in config file,cabal-install tool,1.2.3.0,enhancement,normal,mnislaih,assigned,2008-01-29T10:18:33-0800,2012-03-08T01:24:54-0800,"Currently only a subset of the configure command line flags can be stored in cabal-install's config file. There is no particularly good reason for this. It should be reasonably straightforward to do it generically and allow all configure options to be kept in the config file. This may require some unification of the API for managing command line flags (the Simple.Command module) and the API for loading and saving from config flags (in ParseUtils). Once this is done, it should be straightforward to keep per-package config options as well as global options in the cabal-install config file. These could be used to augment the options used when configuring a package. The order of overriding in cabal-install is currently: {{{ savedConfig `mappend` configFlags }}} That is, the configure options from the config file are overridden by the ones supplied on the command line. With per-package saved config we would extend this to: {{{ globalSavedConfig `mappend` packageSavedConfig pkg `mappend` configFlags }}} ie per-package saved, overrides global saved, but command line still overrides everything. The slightly tricky bit is in how the api for config files and command line flags should be made to work better with each other, so that one set of information can be read/written from either source. The rest should be straightforward.",duncan 3,cabal-install-0.16 Release,227,cabal-install doesn't consider build-tools as dependencies,cabal-install tool,1.2.3.0,defect,normal,duncan,assigned,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-install-0.16 Release,274,Add a 'build from sdist tarball' feature (aka distcheck),cabal-install tool,1.2.3.0,enhancement,normal,,new,2008-05-07T15:15:32-0700,2012-03-08T01:25:43-0800,"I've often seen Darcs repos where the sdist tarball was incomplete, or where a person had a tarball which was incomplete. I think this is because most people just never use the tarball; if they do ever use it, it's because it's what was downloaded from Hackage. The reason is that doing so is much more complex than 'configure; build; install': you need to configure, create an sdist tarball, cd into dist/; do a tar -xvf or whatever of the correct tarball; cd into *that* - and then you can configure/build/install. Assuming it is a working tarball. Now, of course you can automate it. After the first dozen times, I wrote myself a shellscript to do all that for me: function build_sdist { clean_configure && sdist && cd dist/ && untar *.tar.gz && cd `ls -t ./ | grep ""/"" | head -n 1` && clean_configure && build && hinstall; haddock && hinstall; } (This is pretty long and imperfect, but it would be even longer if all the other aliases and function definitions were included; I think they're pretty straightforwardly named though, so I haven't included them.) It seems to me that this would be, at the very least, a useful adjunct to cabal check - if it makes sense to see whether various fields are filled out sanely, surely it makes sense to see whether needed files are included/listed? It might be even better to make the normal 'runhaskell Setup build' do it from sdist, but this is harder to code (besides the forgoing, you'd need to copy in the configuration from the top-level, from when the user ran 'runhaskell Setup configure' and added whatever options) and possibly more confusing (""But Foo.hs *is* there, right there in src/! Why can't Cabal find it?""). So I'd be satisfied to do something like 'cabal checkdist'. -- gwern",guest 3,cabal-install-0.16 Release,282,profiling versions of libraries not managed well,cabal-install tool,1.2.3.0,defect,normal,,new,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-install-0.16 Release,289,symlink binaries into ~/bin,cabal-install tool,,enhancement,normal,,new,2008-06-07T12:57:31-0700,2012-03-08T01:28:07-0800,"Currently cabal-install uses `--prefix=$HOME/.cabal` and does not specify `--bindir` so we use `$HOME/.cabal/bin` as the bindir. Obviously this is not on the `$PATH` by default. It would be trivial to specify `--bindir=$HOME/bin` however the worry is that we would be stomping on programs that the user has already installed there. One solution is to continue to install into `$HOME/.cabal/bin` and then to make symlinks into `$HOME/bin` if the target name does not already exist. If the name does exist we could give a warning and let the user sort it out. Of course we need to be able to overwrite our own symlinks. We know it's a symlink we're allowed to overwrite if it links into `$HOME/.cabal/bin`. It would be nice to install into `$HOME/.cabal/bin` using versioned binary names (Cabal supports that now) and symlink the generic name into `$HOME/bin`. We can discover the names of the binary we're installing by checking the executable names in the `PackageDescription`. Of course this has to be an optional feature since not everyone wants it and there are no symlinks on windows. I'd imagine we'd have it in the `~/.cabal/config` file something like: {{{ prefix: $HOME/.cabal -- bindir: $HOME/.cabal/bin symlink-bindir: $HOME/bin }}}",duncan 3,cabal-install-0.16 Release,309,cabal install should recognize if package was already configured,cabal-install tool,1.2.3.0,defect,normal,,new,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 3,cabal-install-0.16 Release,371,cabal-install can break installed packages by rebuilding dependents,cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,373,doubled field,cabal-install tool,1.4.0.1,enhancement,normal,,new,2008-10-16T15:15:51-0700,2012-03-08T01:16:39-0800,"I have just uploaded a Cabal package to Hackage which has by accident two Homepage fields. But Hackage does only show the second of the two fields. I think either Hackage should support multiple Homepage fields or 'cabal check' should warn about doubled fields. ",guest 3,cabal-install-0.16 Release,409,Support for creating a static package repo,cabal-install tool,1.2.3.0,enhancement,normal,,new,2008-11-19T02:20:48-0800,2012-03-08T00:41:31-0800,"Usual scenario: Bob has a bunch of packages for personal use he does not want or cannot upload to hackage. All he needs is a public_html folder, his packages in tar.gz files, and a bit of help to set up a private static hackage repo. RubyGems allows this with the ''generate_index'' command, see [http://rambleon.org/2008/08/01/creating-your-own-gem-server-redux/ here]. Since cabal-install supports multiple package sources already, the only thing missing is a command to generate the index and directory structure.",mnislaih 3,cabal-install-0.16 Release,410,cabal sdist does not call the sdist build hook in custom Setup.hs,cabal-install tool,1.2.3.0,defect,normal,,new,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-0.16 Release,412,build-reports: option is invalid in a config file,cabal-install tool,HEAD,defect,normal,,new,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-0.16 Release,419,cabal-install should handle packages that need a later Cabal version better,cabal-install tool,1.4.0.2,defect,normal,,new,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 3,cabal-install-0.16 Release,428,cabal update uses too much bandwidth,cabal-install tool,1.6.0.1,defect,normal,,new,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-0.16 Release,446,Can't set path to tools in ~/.cabal/config,cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,448,cabal-install needs new http download component,Cabal library,1.2.3.0,enhancement,normal,,new,2009-01-10T08:26:27-0800,2012-03-06T02:51:40-0800,"The way in which cabal-install currently uses the HTTP library API is quite sub-optimal. It starts a new `Broswer` session for each connection. This means that it cannot take advantage of HTTP pipelining, connection pooling and other goodies. One design would involve making some HTTP download object and making requests through that. The download object would start a thread to make the actual requests. Requests would be serialised, eg using a `Chan`. It probably wants to work by directing URLS be downloaded to local files. On top of this we should build some caching mechanism so that we can check for example if our package index is up to date before downloading the whole thing. It would also be nice to check the length and md5 header to catch short or corrupted downloads. Something like: {{{ downloader :: Settings -> IO Downloader download :: Downloader -> URL -> FilePath -> IO () }}} The `download` function is given the URL and the local file path. If the local file exists it is taken to be the cached file. It should download the URL to a temp file in the target directory and if all successful it should atomically rename it over the target file. Perhaps error handling needs to be more explicit than just using `IOError`s.",duncan 3,cabal-install-0.16 Release,457,cabal list: filter by pattern,cabal-install tool,1.2.3.0,enhancement,normal,,new,2009-01-15T16:16:27-0800,2012-03-06T10:46:57-0800,"dcoutts: cabal feature request: a way to filter the output of ""cabal list"" by field (e.g. ""cabal list Section=Games"".",guest 3,cabal-install-0.16 Release,471,check for ambigious module names,cabal-install tool,1.6.0.1,defect,normal,,new,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 3,cabal-install-0.16 Release,497,"on package not found error: mention ""cabal update""",cabal-install tool,1.6.0.1,enhancement,normal,byorgey,new,2009-02-12T06:46:21-0800,2012-03-06T10:44:54-0800,"Together with the ""There is no package named .."" error, a message could be provided that updating the package list might solve the problem. ",Martijn 3,cabal-install-0.16 Release,516,Maintain central haddock module index.,cabal-install tool,,enhancement,normal,,reopened,2009-03-03T09:23:08-0800,2012-03-06T10:43:13-0800,"The ghc api documentation includes a central index of [http://haskell.org/ghc/docs/latest/html/libraries/ all the modules in the core libraries]. Some people would like the same for all the modules provided by all the packages they have installed. See #206 for some of the previous discussion on this topic. The questions to resolve are where the index should be kept by default and how it should be configured (eg switched off). For example for a per-user install an index could live in `$HOME/.cabal/share/doc/index.html` but the equivalent is not appropriate for other prefixes like `/usr/local`. For global packages shipped by a distro the problem is much worse. We do not really want to have to have distro packages re-generating an html index every time they add and remove a package. Perhaps we should be looking at alternative solutions like using [http://live.gnome.org/devhelp devhelp] which can give easy access to installed documentation without maintaining a central index/catalog. Similar issues apply to a hoogle index.",duncan 3,cabal-install-0.16 Release,539,add way to query package dependency graph,cabal-install tool,HEAD,enhancement,normal,,new,2009-04-17T09:33:53-0700,2012-03-05T06:25:07-0800,"I'd like to be able to list all the forward or reverse dependencies of a package, optionally recursively. The attached patch makes a 'cabal depends' command that does this, but Duncan (quite reasonably) doesn't want a proliferation of top-level commands. Instead it should be integrated into cabal info in some appropriate way, but this probably requires some refactoring of that command first. The attached patch could also be improved in (at least) two ways: - Deal with package version numbers as well as names. This involves matching the constraints on version numbers against specific version numbers. - Use a less naive transitive closure calculation.",ganesh 3,cabal-install-0.16 Release,556,local config files,cabal-install tool,1.6.0.1,enhancement,normal,,new,2009-05-31T14:04:01-0700,2012-03-06T10:13:31-0800,"It would be nice if I could locally (for a project/directory) store the options I want to pass to ""cabal configure"". An example use case would be in the darcs project which has a flag ""-ftype-witnesses"". We don't want to inflict this on most users because it increases our compile time, but for developers of certain branches of darcs want to be systematically using this flag so that they can catch errors. These developers could just ""cabal configure -ftype-witnesses"", but then if they do a ""cabal clean"" for any reason, the next time they run ""cabal configure"", they may forget to pass the flag along. To be clear, this is something to be used by individual developers; it's not something we want for the .cabal file itself. Duncan says that this would be a bit like a local .ghci file, if it helps.",guest 3,cabal-install-0.16 Release,610,wxcore install fail on Vista,cabal-install tool,1.6.0.1,defect,normal,,new,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,cabal-install-0.16 Release,611,protect users from themselves when they use sudo inappropriately,cabal-install tool,,enhancement,normal,,new,2009-11-26T16:20:41-0800,2012-03-05T06:18:59-0800,"Users sometimes get themselves into trouble with sudo. For example: {{{ sudo cabal install blah }}} or {{{ sudo cabal update }}} In both cases, the user is doing actions as root that modify their normal-user files. In the first case it will install a package into ~/.cabal/ but of course all the files owned by root, so the user cannot delete them again later. In the second case cabal will as root update the per-user package index. This will make further updates not as root fail, and worse because of a file permissions bug, the index will not be readable as their normal user. The aim would be to protect users from themselves and tell them when they're doing something that's almost certainly wrong. We could suggest alternatives, like don't use sudo if you wanted to do a per-user install, or use sudo and --global if you did. The tricky bit is making a suitably accurate test and making it possible to do the silly thing, if that's what the user really really wanted.",duncan 3,cabal-install-0.16 Release,622,"wrong HTTP Content-Type for tar.gz files, breaking cabal-install behind some proxies.",cabal-install tool,1.6.0.1,enhancement,normal,,new,2010-01-03T04:48:25-0800,2012-03-05T14:00:03-0800,"As can be seen here, {{{ > HEAD http://hackage.haskell.org/packages/00-index.tar.gz ... Content-Encoding: x-gzip Content-Length: 1398234 Content-Type: application/x-tar ... }}} the file is declared as a tar file with a {{{gzip}}} content encoding. This breaks with at least on virus scanning proxy, namely !AvkHttp (of !InternetSecurity by G DATA): {{{ > 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.8.0 Creating new connection to hackage.haskell.org Received: HTTP/1.1 200 OK AvkHttp: timeout-protection ... AvkHttp: timeout-protection Date: Sun, 03 Jan 2010 09:52:53 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Sun, 03 Jan 2010 09:38:56 GMT ETag: ""388d94-1555da-5fa0cc00"" Accept-Ranges: bytes Content-Length: 17571840 Content-Type: application/x-tar Downloaded to /home/nils/.cabal/packages/hackage.haskell.org/00-index.tar.gz cabal: Codec.Compression.Zlib: incorrect header check }}} As you can see, the proxy unpacked the data, breaking cabal-install. https://bugs.launchpad.net/malone/+bug/173096 describes a similar problem, and has some discussion about why using {{{Content-Encoding}}} in this way is useful in some cases but hurtful in others.",guest 3,cabal-install-0.16 Release,645,"confusing interface: cabal ""install"" subcommand has two clashing meanings",cabal-install tool,1.6.0.1,defect,normal,,new,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-install-0.16 Release,652,Does not support ~ in paths in .cabal/config,cabal-install tool,1.6.0.1,enhancement,normal,,new,2010-04-03T03:48:25-0700,2012-03-05T06:34:09-0800,"This feature request was submitted via the Debian Bugtracker at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576303: Paths in ~/.cabal/config don't seem to support ~ or any other means of specifying $HOME. This makes it difficult to specify paths like prefix, build-summary, and remote-repo-cache in a non-system-specific way. Greetings, Joachim ",nomeata 3,cabal-install-0.16 Release,655,for every install there should be an uninstall,cabal-install tool,1.6.0.1,enhancement,normal,,new,2010-04-07T16:30:48-0700,2012-03-05T06:30:36-0800,"This is a feature request for a 'cabal uninstall' that will undo all the effects of a 'cabal install'. This should include - Unregistering the package with ghc-pkg - Recovering the disk space - Removing from indices and documentation - Transitively uninstalling packages that were installed only to satisfy dependencies of this package, all of whose dependencies are dead. That last bullet could be a bit of a problem, but the first three should be straightforward I hope. ",nr 3,cabal-install-0.16 Release,658,cabal-install doesn't work with National account name.,cabal-install tool,1.8.0.2,defect,normal,,new,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-install-0.16 Release,665,Confusion situation when linking ./dist/setup/setup is interrupted,cabal-install tool,1.6.0.3,defect,normal,,new,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-install-0.16 Release,669,Allow cabal-install's package build location to be set,cabal-install tool,,enhancement,normal,,new,2010-04-29T15:34:55-0700,2012-03-05T06:06:04-0800,"Apparently some systems mount /tmp such that one cannot create and run executables. This is clearly problematic for cabal-install because it needs somewhere to build packages. http://article.gmane.org/gmane.comp.lang.haskell.cafe/73517 It may be useful for cabal-install to have a config setting to specify where to do package builds (for downloaded packages). If not specified this would default to the temp dir as now.",duncan 3,cabal-install-0.16 Release,670,cabal-install should warn about common problem after installing progs,cabal-install tool,1.6.0.3,enhancement,normal,,new,2010-04-29T18:42:23-0700,2012-03-05T06:04:15-0800,"There are a few common problems have when installing programs. * target bindir (or symlink-bindir) is not on the `$PATH` so they cannot run the program after installation. * target bindir is on the `$PATH` but the installed program is masked by the presence of the same named prog in a dir that is earlier on the `$PATH`. For example `/usr/local/bin/cabal` and `~/.cabal/bin/cabal`, the latter might have just been installed but the earlier one will still be picked up. * the shell keeping a cache of name -> path and so not picking up a new program. Eg in the above example, even if `~/.cabal/bin/` comes first on the `$PATH`, if bash has the mapping `cabal` -> `/usr/local/bin/cabal` then it will not notice when `~/.cabal/bin/cabal` is installed. The fix here is to run `hash -r`. The only time we might want to tell users to run `hash -r` is if the program did not previously exist and if it gets installed in a location that is earlier on the `$PATH` than an existing installed instance (which may thus be in the cache). Sadly we cannot query sh to find out what its cache holds.",duncan 3,cabal-install-0.16 Release,673,cabal init: fail gracefully if bogus files are found during recursive search for source code,cabal-install tool,,defect,normal,,new,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-0.16 Release,675,template-haskell cannot be upgraded (broken data-accessor-template),cabal-install tool,HEAD,defect,normal,,new,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-0.16 Release,681,cabal-install init should not overwrite files without good reason,cabal-install tool,1.8.0.2,defect,normal,,new,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-install-0.16 Release,682,'cabal init' should try to set 'main-is' for executables,cabal-install tool,,enhancement,normal,,new,2010-05-05T09:03:29-0700,2012-03-05T04:53:06-0800,"Currently, `cabal init` will find modules and add them to the `exposed-modules` of a library. It should try to do something similar for executables. The `main-is` field is required for executables and any `other-modules` also need to be listed.",duncan 3,cabal-install-0.16 Release,685,"cabal install does not work when /tmp/ is mounted ""noexec""",cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,694,mention --constraint flag in error essage when dep planning fails,cabal-install tool,,enhancement,normal,,new,2010-05-31T05:38:43-0700,2012-04-15T23:15:51-0700,"Dependency planning problems can often be solved by running with --dry-run -v, seeing what the planner is selecting and forcing it to make different choices using the --constraint flag. When dependency planning fails with particular kinds of constraint problem, it may be useful to users to mention this. We should check if this advice applies to all cases where the dep planner fails, or if its only appropriate for certain classes of failure.",duncan 3,cabal-install-0.16 Release,695,cabal install world always reinstalls programs,cabal-install tool,,defect,normal,,new,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-install-0.16 Release,700,seemingly too liberal behaviour on overlapping dependency constraints across packages,cabal-install tool,1.6.0.3,defect,normal,,new,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,cabal-install-0.16 Release,705,Non-deterministic behaviour when overlapping packages are installed,cabal-install tool,1.8.0.2,defect,normal,,new,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-0.16 Release,707,"cabal-install config setting ""documentation: True"" ignores base library dependency",cabal-install tool,1.8.0.2,defect,normal,,new,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-install-0.16 Release,714,"cabal: Couldn't read cabal file "".\\HaTeX\\1.0.0\\HaTeX.cabal""",cabal-install tool,1.6.0.3,defect,normal,,new,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-install-0.16 Release,716,Inconsistent behavior between custom and simple build types,cabal-install tool,,enhancement,normal,,new,2010-07-23T09:59:26-0700,2012-03-05T03:47:42-0800,"If a Custom build-type is used, Setup.hs may be built with a different version of Cabal than the one that cabal-install was built with. This can cause hard-to-find (seemingly random) build failures. Perhaps cabal-install should warn when it runs Setup.hs with a different version of Cabal than the one that it was built with. Alternatively, it could fail if the version of Cabal that cabal-install was built with is not available when compiling the Setup script.",j3h 3,cabal-install-0.16 Release,719,tool support for checking if a package works with a range of versions,cabal-install tool,,enhancement,normal,,new,2010-07-28T02:22:17-0700,2012-03-05T03:46:32-0800,"[http://www.haskell.org/pipermail/libraries/2010-July/013970.html Doaitse reports] that he would like: {{{ since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too) }}} Others responded that they would also like to do the same thing locally, even though the range of versions they have locally may be limited. So one simple approach would be a flag to indicate a preference that the earliest version of a package (or all packages?) be used rather than the latest version. This might be integrated into a ""cabal disttest"" feature that makes a tarball and builds from the tarball. The same approach could be taken for hackage build bots.",duncan 3,cabal-install-0.16 Release,723,Strip path error under Cygwin,cabal-install tool,1.6.0.3,defect,normal,,new,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,cabal-install-0.16 Release,725,Distinguish speculative and required build-depends upper bound,cabal-install tool,1.6.0.3,enhancement,normal,,new,2010-08-14T15:37:56-0700,2012-03-03T09:53:39-0800,"When a package adds a build-dependency on another package, it's good form to follow the Package Versioning Policy and add a speculative upper bound that is x.(y+1), if the current version is x.y. This is great, but in many cases the next version will /not/ break compatibility with your package. In that case, once you have tested that the dependency is fine, you can bump the upper bound. As the list of dependencies for any respectable Cabal package can be quite long, it may be useful to have some sort of 'cabal whatsnew' command which checks the upper bounds of your build dependencies and notifies you when there are newer versions than your upper bounds availble. Furthermore, there should be a mechanism for telling Cabal that the upper bound is required, and that the package will break if you try to bump it.",ezyang 3,cabal-install-0.16 Release,732,Implement opt-in for anonymous build reporting,cabal-install tool,,enhancement,normal,,new,2010-09-01T13:54:56-0700,2012-03-05T03:39:49-0800,"We want people to send in anonymous build reports. We also want to respect people's privacy. The suggestion is that we should use an opt-in system but make it very easy to opt in. Currently most users have a config file that contains no value set for the config file fields that control the build reporting feature. The suggestion is that when the build reporting config items are not set then we should interactively prompt users like so: {{{ $ cabal update Cabal can send build reports back to to the package server. Build reporting helps to improve package quality. The information sent back is minimal and it does not identify your computer. For more details see: http://haskell.org/cabal/reporting Enable automatic anonymous reporting of package builds? [y/n/?] Downloading the latest package list from hackage.haskell.org }}} We would then rewrite the config file with the updated setting, either on or off. That will require that we correctly preserve settings and comments in the config file.",duncan 3,cabal-install-0.16 Release,745,cabal-install sometimes gives empty build-log and no build-summary,cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,755,high verbosity should make configure verbose as well ?,cabal-install tool,1.8.0.6,enhancement,normal,,new,2010-10-27T03:08:45-0700,2012-03-03T10:12:57-0800,"Even with -v 3, configure scripts run at normal verbosity which is often not enough to debug the problem. AFAIK you have to unpack the package, install/configure again and inspect config.log. If possible it would be convenient to have -v2 or -v3 tell configure to print the full log on stdout.",simonmic 3,cabal-install-0.16 Release,759,document hackage archive format,cabal-install tool,1.8.0.6,defect,normal,,new,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,cabal-install-0.16 Release,768,Cabal cannot find GHC when using relative path in -w flag,cabal-install tool,1.8.0.6,defect,normal,,new,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 3,cabal-install-0.16 Release,777,"cabal install {hledger, others} ExitFailure 11",cabal-install tool,1.8.0.2,defect,normal,,new,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-install-0.16 Release,780,Simpler support for isolated/sandboxed builds,cabal-install tool,,enhancement,normal,refold,assigned,2010-12-21T03:13:10-0800,2012-04-25T06:37:57-0700,"Cabal/cabal-install allows setting the install prefix and the package database. Together these allow creating isolated builds. This is clearly not sufficiently easy to use as there are now two projects that provide wrappers over cabal-install to provide more direct support for this use case: * http://github.com/creswick/cabal-dev/blob/master/README.md * http://www.haskell.org/haskellwiki/Capri The task is to investigate what user behaviour is desired and to integrate this in the best way with Cabal/cabal-install. This is probably related to: * ticket #556 about local config files (e.g. persistently setting some sandbox flag) * ticket #734 about supporting multiple local .cabal files * ticket #524 about supporting file, directory and url targets for packages and .cabal files ",duncan 3,cabal-install-0.16 Release,781,"cabal list should have --with-compiler, --user, --global and --package-db flags",cabal-install tool,,enhancement,normal,,new,2010-12-21T04:51:52-0800,2012-03-03T09:41:56-0800,"`cabal list` is lacking a way to control which compiler and package databases are queried. See also ticket #457 about enhanced filtering for `cabal list`",duncan 3,cabal-install-0.16 Release,789,build-depends on packages that provide no library,cabal-install tool,HEAD,defect,normal,,new,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 3,cabal-install-0.16 Release,809,Improve update performance,cabal-install tool,HEAD,enhancement,normal,,new,2011-03-07T14:27:52-0800,2012-03-03T09:35:21-0800,"I have an automated package build set up using Hudson, and it tries to build my code as often as once every 5 minutes. Right now, that means running cabal update before every build, which takes at least 30 seconds. It would be great if cabal update used the ETag and If-Modified-Since HTTP headers to do conditional fetches of the metadata, so that there would be far less of a performance hit to both the Hackage server and my client.",bos 3,cabal-install-0.16 Release,820,cabal-install clobbers itself on multi-arch platforms,cabal-install tool,1.8.0.6,defect,normal,,new,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-0.16 Release,822,"world-file does not support $arch, $os, $compiler",cabal-install tool,1.10.1.0,defect,normal,,new,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-install-0.16 Release,834,cabal should detect case errors in build-depends:,cabal-install tool,1.8.0.6,enhancement,normal,,new,2011-04-22T05:29:36-0700,2012-03-03T09:24:02-0800,"for example, with a foo.cabal file containing: build depends: http >= 4000 Resolving dependencies... cabal: cannot configure foo-0.0.1. It requires http >=4000 There is no available version of http that satisfies >=4000 The solution is of course to specify HTTP, but the user may be led to believe that there is a version problem, which is confusing. Perhaps a message such as - ""Did you mean package HTTP"" - Would be appropriate.",cmh 3,cabal-install-0.16 Release,842,cabal appears to complain about relative paths,cabal-install tool,1.10.1.0,defect,normal,,new,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-install-0.16 Release,849,[PATCH] Store licenses in text files instead of code.,cabal-install tool,HEAD,enhancement,normal,,new,2011-05-26T14:35:38-0700,2012-03-03T09:22:15-0800,This shaves 300 KiB off the final executable size and makes it slightly easier to add new license types (just drop the text file under %SRCDIR%/licenses and modify the 'licenseFile' function in Distribution.Client.Init.hs).,refold 3,cabal-install-0.16 Release,855,http proxy using authentication does not work,cabal-install tool,1.10.1.0,defect,normal,,new,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-0.16 Release,856,windows unicode problem with cabal list,cabal-install tool,1.10.1.0,defect,normal,,new,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-install-0.16 Release,858,cabal-install needs a manpage,cabal-install tool,1.8.0.6,enhancement,normal,,new,2011-06-19T04:41:56-0700,2012-03-05T04:12:59-0800,"The cabal binary shipped by cabal-install ought to be documented with a manage. Ideally, cabal could generate one by itself from the Command declarations, similar to how darcs does it, this way there is no duplication of documentation.",nomeata 3,cabal-install-0.16 Release,864,worldfile written with incorrect case,cabal-install tool,HEAD,defect,normal,,new,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-install-0.16 Release,867,sudo cabal update doesn't use http_proxy,cabal-install tool,1.8.0.6,defect,normal,,new,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-install-0.16 Release,883,Single command to figure out ghc[i] options needed to compile a single file,cabal-install tool,1.8.0.6,enhancement,normal,,new,2011-09-14T20:46:13-0700,2012-03-03T08:58:03-0800,"I'm thinking of a {{{cabal options }}} command that 1. locates the proper .cabal file for 2. parses that .cabal 3. outputs all options necessary to compile that file as cabal build would do it, that is, {{{-isrc -idist/build/autogen (-Xwhatever)* -hide-all-packages (-package-id whatever)*}}} There's already cabal-ghci on hackage which has one half of the equation, but packages are missing. (which happen to be available via grep and sed from cabal_macros.h...) Needing those options comes up when e.g. working with vim's haskellmode on a cabal project: Most if not all cabal projects' files just fail to compile with default options. Having such a command would give a bullet-proof, non-hackish and low-tech way to integrate cabal with any such IDE tool. (Do note that just building with cabal isn't enough, while haskellmode can parse the resulting warnings and errors, it doesn't stand a chance to figure out types, among other things, that way)",barsoap 3,cabal-install-0.16 Release,889,Add option to list recursive dependencies of a package along with their licenses,cabal-install tool,HEAD,enhancement,normal,,new,2011-09-27T14:20:54-0700,2012-03-05T06:26:22-0800,"It should be possible to list all of the dependencies of a package, including their licenses. This would be useful for: * Developers writing proprietary applications. * Developers who don't want their liberally-licensed libraries to be ""upgraded"" to the GPL or similar by subtle dependencies. Attached is a simple patch that makes cabal-install list this information when the verbosity level is 2 or higher. Sample usage: {{{ $ cabal install --verbose=2 --dry-run gnutls Reading available packages... Resolving dependencies... base BSD3 bytestring BSD3 ffi BSD3 ghc-prim BSD3 gnutls GPL (Just (Version {versionBranch = [3], versionTags = []})) integer-gmp BSD3 monads-tf BSD3 rts BSD3 transformers BSD3 In order, the following would be installed: monads-tf-0.1.0.0 (new package) gnutls-0.1 (new package) }}} This is a quick hack, as I am not familiar with the Cabal codebase. This should probably be wrapped as a {{{--list-licenses}}} command line switch. Pretty-printing licenses would be a plus. I am already finding this feature useful, and hope others will too.",joeyadams 3,cabal-install-0.16 Release,910,per-package configuration,cabal-install tool,1.8.0.6,enhancement,normal,,new,2012-01-02T04:04:58-0800,2012-03-06T10:12:49-0800,"This may be related to #223 but I don't particularly want it in my global config. I'm sick of running ""cabal build"" and not noticing until much later that my test had a compile error because I'd neglected to reconfigure with ""--enable-test"". A similar issue happens with packages with custom flags, say sometimes I lose the ""-f-library"" flag I sometimes use for faster compilation. I wish I had a mechanism to remember the command line flags passed in for a particular package. Editing my global config doesn't seem quite like what I'm looking for; it has to be something that works, eg. with different branches of the same package. What might be better for me is something like the Darcs prefs system, where I could edit a file in the current working directory like "".cabal"" that says something like {{{ configure --enable-test -f-library install -fgui }}}",kowey 3,cabal-install-0.16 Release,924,symlink-bindir does not play nice with program-suffix,cabal-install tool,1.14.0,defect,normal,,new,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-0.16 Release,928,Modular solver needs support for ghc-6.12's base-wrapping,cabal-install tool,HEAD,defect,normal,kosmikus,new,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-install-0.16 Release,931,Support building source trees with many packages,cabal-install tool,1.10.2.0,enhancement,normal,,new,2012-03-12T09:03:37-0700,2012-03-27T04:28:41-0700,"A not uncommon use case is building a package against a set of dependencies that exist in (unreleased) source form. For example, given two packages: {{{ $ ls hashable unordered-containers }}} I'd like to be able to {{{ $ cd unordered-containers cabal build --root=.. }}} Cabal should then recursively traverse directories from `--root`, looking for .cabal files to use when fulfilling dependencies (i.e. in this case it'd find `hashable`.) Those dependencies should also be marked as preferred to any Hackage versions of the package with the same version number. It'd also be convenient to add several `--root` flags, so one can specify specific packages to use in source form (without using e.g. the user's complete `~/src` directory.) {{{ $ cd unordered-containers cabal build --root=../hashable --root=../text }}} ",tibbe 3,cabal-install-0.16 Release,933,cabal configure doesn't suggest cabal install --only-dependencies,cabal-install tool,1.10.2.0,enhancement,normal,,new,2012-03-14T01:24:29-0700,2012-03-14T09:54:12-0700," When running 'cabal configure' on a package that has missing dependencies, cabal fails to point out that the dependencies can be installed by running cabal install --only-dependencies When cabal is used by millions of programmers, this will cause $1bn in lost productivity.",guest 3,cabal-install-0.16 Release,934,cabal seems to require access to user HOME directory,cabal-install tool,1.10.2.0,defect,normal,,new,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-install-0.16 Release,951,Incorrect error messages for non-existing dependencies,cabal-install tool,1.14.0,enhancement,normal,,new,2012-05-15T04:43:41-0700,2012-05-15T07:40:41-0700,"When the build-depends-field contains non-existing packages, cabal-install sometimes does not report that these packages could not be found but complains about other constraints being unsolvable. The attached cabal-file contains a dependency for a non-existing package called ""bogus"". This is what I get: {{{ $ cabal install --only-dependencies --dry-run Resolving dependencies... cabal: Could not resolve dependencies: next goal: foo (user goal) rejecting: foo-1.0 (global constraint requires ==0.1.0.0) trying: foo-0.1.0.0 trying: heist-0.8.0 (dependency of foo-0.1.0.0) trying: transformers-0.3.0.0 (dependency of heist-0.8.0) next goal: mtl (dependency of heist-0.8.0) rejecting: mtl-2.1.1, 2.1 (conflict: heist => mtl>=2.0 && <2.1) rejecting: mtl-2.0.1.0, 2.0.0.0 (conflict: transformers==0.3.0.0, mtl => transformers==0.2.*) rejecting: mtl-1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (conflict: heist => mtl>=2.0 && <2.1) }}} When removing ""bogus"" from the build-depends, cabal-install is able to come up with a working install plan. Used versions: {{{ $ cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library }}}",guest 4,cabal-install-0.16 Release,313,line counting,cabal-install tool,1.2.3.0,enhancement,normal,,new,2008-07-15T08:31:58-0700,2012-03-08T01:00:14-0800,"It would be nice if Cabal had a way to do source line counting. Two programs I know of to do the hard work are sloccount http://www.dwheeler.com/sloccount/ and ohcount http://labs.ohloh.net/ohcount I've also attached a small perlscript from the GHC source tree, but it has some drawbacks (most notably, only supporting Haskell). ",igloo 4,cabal-install-0.16 Release,405,cabal-install finds non-existent conflict due to picking base 3,cabal-install tool,1.6.0.1,defect,normal,kosmikus,new,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 4,cabal-install-0.16 Release,511,requiring consistent package dependencies can give surprising results,cabal-install tool,1.6.0.1,defect,normal,,new,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-install-0.16 Release,538,--constraint= is not respected for base,cabal-install tool,1.6.0.2,defect,normal,kosmikus,new,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-0.16 Release,565,sdist is broken on Windows,cabal-install tool,1.6.0.2,defect,normal,,new,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 4,cabal-install-0.16 Release,608,Files that are only used by cabal setup are not recompiled when they change between runs of 'cabal build',cabal-install tool,1.6.0.1,defect,normal,,new,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 4,cabal-install-0.16 Release,616,Not enough detail in error messages from cabal-install bootstrap script,cabal-install tool,1.6.0.2,enhancement,normal,,new,2009-12-06T15:22:10-0800,2012-03-05T14:06:44-0800,"I just tried to bootstrap cabal 0.6.2 and it failed like this: ""Building the cabal-install package failed"" Because the message lacks any detail, I am forced to give up at this point. I scrolled back through the output (which the failure message didn't even hint that I should do), and I all I saw were some ""warnings"". I didn't see any ""fatal"" or error messages. The reason cabal fails may well have something to do with my environment (Ubuntu Karmic 9.10), but the bug is cabal here is that fails to provide a helpful diagnostic, stonewalling the troubleshooting process. Here's my full ./bootstrap output: {{{ $ sh ./bootstrap.sh Checking installed packages for ghc-6.10.4... parsec is already installed and the version is ok. network is already installed and the version is ok. Cabal is already installed and the version is ok. HTTP-4000.0.4 will be downloaded and installed. zlib-0.5.0.0 will be downloaded and installed. Downloading HTTP-4000.0.4... --2009-12-06 18:05:53-- http://hackage.haskell.org/packages/archive/HTTP/4000.0.4/HTTP-4000.0.4.tar.gz Resolving hackage.haskell.org... 69.30.63.197 Connecting to hackage.haskell.org|69.30.63.197|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 44063 (43K) [application/x-tar] Saving to: `HTTP-4000.0.4.tar.gz' 100%[=====================================================================================================>] 44,063 97.5K/s in 0.4s 2009-12-06 18:05:54 (97.5 KB/s) - `HTTP-4000.0.4.tar.gz' saved [44063/44063] [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Linking Setup ... Configuring HTTP-4000.0.4... Preprocessing library HTTP-4000.0.4... Building HTTP-4000.0.4... [ 1 of 15] Compiling Network.HTTP.Utils ( Network/HTTP/Utils.hs, dist/build/Network/HTTP/Utils.o ) [ 2 of 15] Compiling Network.HTTP.MD5Aux ( Network/HTTP/MD5Aux.hs, dist/build/Network/HTTP/MD5Aux.o ) [ 3 of 15] Compiling Network.HTTP.MD5 ( Network/HTTP/MD5.hs, dist/build/Network/HTTP/MD5.o ) [ 4 of 15] Compiling Network.HTTP.Base64 ( Network/HTTP/Base64.hs, dist/build/Network/HTTP/Base64.o ) Network/HTTP/Base64.hs:184:0: Warning: Pattern match(es) are non-exhaustive In the definition of `int4_char3': Patterns not matched: [_] Network/HTTP/Base64.hs:242:0: Warning: Pattern match(es) are non-exhaustive In the definition of `quadruplets': Patterns not matched: [_] [ 5 of 15] Compiling Network.Stream ( Network/Stream.hs, dist/build/Network/Stream.o ) [ 6 of 15] Compiling Network.HTTP.Headers ( Network/HTTP/Headers.hs, dist/build/Network/HTTP/Headers.o ) [ 7 of 15] Compiling Network.BufferType ( Network/BufferType.hs, dist/build/Network/BufferType.o ) [ 8 of 15] Compiling Network.HTTP.Base ( Network/HTTP/Base.hs, dist/build/Network/HTTP/Base.o ) Network/HTTP/Base.hs:75:0: Warning: Module `Control.Monad' is imported, but nothing from it is used, except perhaps instances visible in `Control.Monad' To suppress this warning, use: import Control.Monad() [ 9 of 15] Compiling Network.StreamSocket ( Network/StreamSocket.hs, dist/build/Network/StreamSocket.o ) Network/StreamSocket.hs:54:9: Warning: orphan instance: instance Stream Socket [10 of 15] Compiling Network.TCP ( Network/TCP.hs, dist/build/Network/TCP.o ) [11 of 15] Compiling Network.StreamDebugger ( Network/StreamDebugger.hs, dist/build/Network/StreamDebugger.o ) [12 of 15] Compiling Network.HTTP.Stream ( Network/HTTP/Stream.hs, dist/build/Network/HTTP/Stream.o ) [13 of 15] Compiling Network.HTTP.HandleStream ( Network/HTTP/HandleStream.hs, dist/build/Network/HTTP/HandleStream.o ) Network/HTTP/HandleStream.hs:30:24: Warning: Imported from `Network.Stream' but not used: type constructor or class `ConnError' [14 of 15] Compiling Network.HTTP ( Network/HTTP.hs, dist/build/Network/HTTP.o ) [15 of 15] Compiling Network.Browser ( Network/Browser.hs, dist/build/Network/Browser.o ) /usr/bin/ar: creating dist/build/libHSHTTP-4000.0.4.a Installing library in /home/mark/.cabal/lib/HTTP-4000.0.4/ghc-6.10.4 Registering HTTP-4000.0.4... Reading package info from ""dist/installed-pkg-config"" ... done. Writing new package config file... done. Downloading zlib-0.5.0.0... --2009-12-06 18:07:32-- http://hackage.haskell.org/packages/archive/zlib/0.5.0.0/zlib-0.5.0.0.tar.gz Resolving hackage.haskell.org... 69.30.63.197 Connecting to hackage.haskell.org|69.30.63.197|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 122533 (120K) [application/x-tar] Saving to: `zlib-0.5.0.0.tar.gz' 100%[=====================================================================================================>] 122,533 183K/s in 0.7s 2009-12-06 18:07:33 (183 KB/s) - `zlib-0.5.0.0.tar.gz' saved [122533/122533] [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Configuring zlib-0.5.0.0... Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... [1 of 5] Compiling Codec.Compression.Zlib.Stream ( dist/build/Codec/Compression/Zlib/Stream.hs, dist/build/Codec/Compression/Zlib/Stream.o ) [2 of 5] Compiling Codec.Compression.Zlib.Internal ( Codec/Compression/Zlib/Internal.hs, dist/build/Codec/Compression/Zlib/Internal.o ) [3 of 5] Compiling Codec.Compression.Zlib.Raw ( Codec/Compression/Zlib/Raw.hs, dist/build/Codec/Compression/Zlib/Raw.o ) [4 of 5] Compiling Codec.Compression.Zlib ( Codec/Compression/Zlib.hs, dist/build/Codec/Compression/Zlib.o ) [5 of 5] Compiling Codec.Compression.GZip ( Codec/Compression/GZip.hs, dist/build/Codec/Compression/GZip.o ) /usr/bin/ar: creating dist/build/libHSzlib-0.5.0.0.a Installing library in /home/mark/.cabal/lib/zlib-0.5.0.0/ghc-6.10.4 Registering zlib-0.5.0.0... Reading package info from ""dist/installed-pkg-config"" ... done. Writing new package config file... done. [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Configuring cabal-install-0.6.2... Preprocessing executables for cabal-install-0.6.2... Building cabal-install-0.6.2... [ 1 of 33] Compiling Distribution.Client.Check ( Distribution/Client/Check.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Check.o ) [ 2 of 33] Compiling Distribution.Client.BuildReports.Types ( Distribution/Client/BuildReports/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Types.o ) [ 3 of 33] Compiling Distribution.Client.Types ( Distribution/Client/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Types.o ) [ 4 of 33] Compiling Distribution.Client.Dependency.TopDown.Types ( Distribution/Client/Dependency/TopDown/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/TopDown/Types.o ) [ 5 of 33] Compiling Distribution.Client.Setup ( Distribution/Client/Setup.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Setup.o ) [ 6 of 33] Compiling Distribution.Client.Config ( Distribution/Client/Config.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Config.o ) [ 7 of 33] Compiling Distribution.Client.Win32SelfUpgrade ( Distribution/Client/Win32SelfUpgrade.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Win32SelfUpgrade.o ) [ 8 of 33] Compiling Paths_cabal_install ( dist/build/autogen/Paths_cabal_install.hs, dist/build/cabal/cabal-tmp/Paths_cabal_install.o ) [ 9 of 33] Compiling Distribution.Client.HttpUtils ( Distribution/Client/HttpUtils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/HttpUtils.o ) [10 of 33] Compiling Distribution.Compat.TempFile ( Distribution/Compat/TempFile.hs, dist/build/cabal/cabal-tmp/Distribution/Compat/TempFile.o ) [11 of 33] Compiling Distribution.Client.Utils ( Distribution/Client/Utils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Utils.o ) [12 of 33] Compiling Distribution.Client.Tar ( Distribution/Client/Tar.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Tar.o ) [13 of 33] Compiling Distribution.Client.IndexUtils ( Distribution/Client/IndexUtils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/IndexUtils.o ) [14 of 33] Compiling Distribution.Client.InstallPlan ( Distribution/Client/InstallPlan.hs, dist/build/cabal/cabal-tmp/Distribution/Client/InstallPlan.o ) [15 of 33] Compiling Distribution.Client.Dependency.Types ( Distribution/Client/Dependency/Types.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/Types.o ) [16 of 33] Compiling Distribution.Client.Dependency.Bogus ( Distribution/Client/Dependency/Bogus.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/Bogus.o ) [17 of 33] Compiling Distribution.Client.InstallSymlink ( Distribution/Client/InstallSymlink.hs, dist/build/cabal/cabal-tmp/Distribution/Client/InstallSymlink.o ) [18 of 33] Compiling Distribution.Client.Dependency.TopDown.Constraints ( Distribution/Client/Dependency/TopDown/Constraints.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/TopDown/Constraints.o ) [19 of 33] Compiling Distribution.Client.Dependency.TopDown ( Distribution/Client/Dependency/TopDown.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/TopDown.o ) Distribution/Client/Dependency/TopDown.hs:37:55: Warning: Imported from `Distribution.Package' but not used: `notThisPackageVersion' Distribution/Client/Dependency/TopDown.hs:555:0: Warning: Defined but not used: `addPackageExcludeConstraint' [20 of 33] Compiling Distribution.Client.Dependency ( Distribution/Client/Dependency.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Dependency.o ) [21 of 33] Compiling Distribution.Client.Fetch ( Distribution/Client/Fetch.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Fetch.o ) [22 of 33] Compiling Distribution.Client.Unpack ( Distribution/Client/Unpack.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Unpack.o ) [23 of 33] Compiling Distribution.Client.SrcDist ( Distribution/Client/SrcDist.hs, dist/build/cabal/cabal-tmp/Distribution/Client/SrcDist.o ) [24 of 33] Compiling Distribution.Client.BuildReports.Anonymous ( Distribution/Client/BuildReports/Anonymous.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Anonymous.o ) [25 of 33] Compiling Distribution.Client.BuildReports.Upload ( Distribution/Client/BuildReports/Upload.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Upload.o ) Distribution/Client/BuildReports/Upload.hs:63:6: Warning: Defined but not used: `response' [26 of 33] Compiling Distribution.Client.Upload ( Distribution/Client/Upload.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Upload.o ) [27 of 33] Compiling Distribution.Client.BuildReports.Storage ( Distribution/Client/BuildReports/Storage.hs, dist/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Storage.o ) [28 of 33] Compiling Distribution.Client.Update ( Distribution/Client/Update.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Update.o ) [29 of 33] Compiling Distribution.Client.SetupWrapper ( Distribution/Client/SetupWrapper.hs, dist/build/cabal/cabal-tmp/Distribution/Client/SetupWrapper.o ) [30 of 33] Compiling Distribution.Client.Configure ( Distribution/Client/Configure.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Configure.o ) [31 of 33] Compiling Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Install.o ) [32 of 33] Compiling Distribution.Client.List ( Distribution/Client/List.hs, dist/build/cabal/cabal-tmp/Distribution/Client/List.o ) [33 of 33] Compiling Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o ) Linking dist/build/cabal/cabal ... Error during cabal-install bootstrap: Building the cabal-install package failed }}}",markstos 4,cabal-install-0.16 Release,688,adopt XDG basedir spec,cabal-install tool,1.8.0.4,enhancement,normal,,new,2010-05-12T05:39:47-0700,2012-03-05T04:18:40-0800,"I want to be able to tell {{{cabal}}} to read the configuration from a different place than {{{$HOME/.cabal/config}}}. The ultimate goal is to get rid of the non-standard {{{.cabal}}} directory altogether, so far careful {{{--package-db}}}/{{{--prefix}}} etc. juggling served me well; {{{config}}} is the last remaining file there. {{{ > cabal --version cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library }}}",guest 4,cabal-install-0.16 Release,804,support remote .cabal files in cabal info,cabal-install tool,,enhancement,normal,,new,2011-02-14T08:29:23-0800,2012-03-03T09:29:11-0800,"Currently, `cabal info` supports local .cabal files and remote tarballs, but not remote .cabal files. The [http://hackage.haskell.org/package/lscabal lscabal] program supports remote .cabal file target like: {{{ $ lscabal http://code.haskell.org/xmonad/xmonad.cabal XMonad XMonad.Main }}} Is this useful? Presumably it would also need a more general query language to pull out the fields that the user is interested in. Note that `lscabal` only lists exposed modules and only unconditional ones (e.g. not ones that are platform dependent).",duncan 3,cabal-install-0.14.2 Release,380,Ability to blacklist packages that are on hackage,cabal-install tool,1.2.3.0,enhancement,normal,,new,2008-10-22T17:46:38-0700,2012-04-18T03:46:57-0700,"Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature. So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file. I also think cabal should tell you when it skips a dependency due to blacklisting.",guest 3,cabal-install-0.14.2 Release,408,cabal install / cabal update should give warning when preferred versions will result in something other than the latest version on hackage,cabal-install tool,HEAD,enhancement,normal,duncan coutts,new,2008-11-16T06:21:04-0800,2012-04-18T03:43:10-0700,"The natural assumption, unless you know better, is that cabal install -- and especially cabal upgrade -- will install the latest verion of a package on hackage. But the preferred-version machinery invalidates this assumptijon. The suggestions is to emit a warning like {{{ cabal install haxml Downloading HaXml-1.13.3... Note: the preferred version is HaXml-1.13.3 but latest version is HaXml-1.19, so put Build-Depends: HaXml == 1.19.4 in your cabal file if you want that version. }}} I would have this message pop up for both cabal install and cabal upgrade See http://groups.google.com/group/fa.haskell/browse_thread/thread/c39dca259a9489ef?q=cabal+preferred+version for discussion thread. ",tphyahoo 3,cabal-install-0.14.2 Release,517,make cabal install command support haddock options,cabal-install tool,,enhancement,normal,,reopened,2009-03-03T09:23:40-0800,2012-09-23T15:49:43-0700,"Currently the `cabal install` command supports just `--enable-documentation` which turns on library docs. The `cabal haddock` option has various other things like enabling docs for executables, specifying css files, linking to source code etc. Some or perhaps all of these would be useful when installing packages. This is not fundamentally difficult. The task is just to work out which options are useful (or perhaps all) and how to present the user interface (command line options and config file). Bonus points for a UI that is usable and orthogonal. See #206 for some of the previous discussion on this topic. See also #516 about maintaining a central haddock module index. For reference the current haddock command options are: {{{ Flags for haddock: -h --help Show this help text -v --verbose[=n] Control verbosity (n is 0--3, default verbosity level is 1) --builddir=DIR The directory where Cabal puts generated build files (default dist) --hoogle Generate a hoogle database --html-location=URL Location of HTML documentation for pre-requisite packages --executables Run haddock for Executables targets --internal Run haddock for internal modules and include all symbols --css=PATH Use PATH as the haddock stylesheet --hyperlink-source Hyperlink the documentation to the source code (using HsColour) --hscolour-css=PATH Use PATH as the HsColour stylesheet --with-haddock=PATH give the path to haddock --haddock-options=OPTS give extra options to haddock --haddock-option=OPT give an extra option to haddock (no need to quote options containing spaces) }}}",duncan 3,cabal-install-0.14.2 Release,661,optionally select the oldest available dependencies rather than the newest,cabal-install tool,HEAD,enhancement,normal,,new,2010-04-19T07:07:04-0700,2012-04-20T02:29:23-0700,"When developing a package, you want to specify as wide a range of build-depends as possible, but it's often quite tedious to keep checking if your latest development effort hasn't made your package incompatible with some ancient version of a library you use. In view of this I think it would be helpful to have an option that asks cabal configure to pick the oldest possible version of each dependency, so you could quickly and easily ensure that at least the two endpoints are covered.",benmachine 3,cabal-install-0.14.2 Release,810,cabal-install requests credentials even when they are listed in the config,cabal-install tool,1.10.1.0,defect,normal,,reopened,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-install-0.14.2 Release,921,cabal build should imply cabal configure,cabal-install tool,1.8.0.6,enhancement,normal,,new,2012-02-29T11:12:21-0800,2012-04-20T02:32:00-0700,"`cabal build` should run `cabal configure` if needed, even if the user never ran `cabal configure` manually before. Right now `cabal build` without `cabal configure` gives: {{{ cabal: Run the 'configure' command first. }}} We should simply run `cabal configure` automatically, with no flags set. If the user wants different flags he/she can run `cabal configure` manually.",tibbe 3,cabal-install-0.14.2 Release,941,add 'hyperlink-source: true/false' to ~/.cabal/config,cabal-install tool,1.14.0,enhancement,normal,,new,2012-04-20T09:36:11-0700,2012-04-24T15:25:12-0700,"Having to remember to add the --hyperlink-source flag to cabal install is a major pain. See also #534, where others have requested the same feature.",bfr 3,cabal-install-0.14.2 Release,942,cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag,cabal-install tool,1.10.2.0,defect,normal,,new,2012-04-20T10:43:18-0700,2012-05-04T00:42:35-0700,,kosmikus 3,cabal-install-0.14.2 Release,947,"let ""cabal -fSomeFlag"" produce error for undeclared flags",cabal-install tool,1.14.0,enhancement,normal,,new,2012-04-27T10:51:02-0700,2012-04-27T23:33:08-0700,"Typos in flags can lead to confusing problems, especially with large projects that take a long time to build. A simple check could be quite useful: {{{ ~> hconfigure -fNonExistentFlag -fSomeFlag cabal: undeclared flag 'NonExistentFlag'. Declared flags are: ExistentFlag, SomeFlag }}}",Oblosys 3,cabal-install-0.14.2 Release,952,cabal-install-0.14.0 dependencies are incorrect,cabal-install tool,1.14.0,defect,normal,kosmikus,new,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,_|_ Release,26,add Threaded as an extension?,Cabal library,,enhancement,normal,,new,2005-12-05T17:19:08-0800,2008-01-21T09:43:10-0800,"igloo's idea. rather than making people use ghc-options: threaded, list it as an extension. Then cabal can give an error for Hugs if the program won't work there?",ijones 3,_|_ Release,42,"make hugs, nhc, lhc and Cabal agree on installed package info",Cabal library,,enhancement,normal,ross@…,new,2006-01-08T21:21:40-0800,2009-03-03T09:05:52-0800,"A pretty simple approach: The package database is a list, mapping package names to directories. Maybe the gentoo folks and others would be happier if it's a directory where each file name is a package name and the content of that file is a directory to find the source for this package. If we go the ""don't alter hugs"" route, we'd need a wrapper around hugs (maybe cabal) to read this file and add the -i flags to the hugs command-line. So this could be implemented outside of hugs, with just cabal and hugs-pkg, then we could include a concept of a package database in the cabal interface to make toast / gentoo happy. In fact, we could do all that in Cabal without a hugs-pkg. Of course, it would be nice if someone could say "":package foo"" on the Hugs command-line, but that's not completely necessary. We could punt on that until we get more clear about the role of packages in the language. == When implementing this, be sure to add == 1. register step to cabal (register in hugs a little bit of something) 1. hugs-pkg as a package tool 1. command-line args to hugs or hugsWrap relating to the packages == Problems with not having hugs-pkg == 1. no way to tell hugs to turn packages on / off 1. register / unregister don't make much sense 1. no way to install into a non-standard location and expect hugs to find the package",ijones 3,_|_ Release,149,Support for building and linking resource files in Windows,Cabal library,HEAD,enhancement,normal,,new,2007-08-23T03:59:38-0700,2008-01-24T07:48:39-0800,Cabal should allow specifying resource scripts and files and link them to at least executable (.exe and .dll).,eivuokko 3,_|_ Release,150,haddock docs are not relocatable in Windows,Cabal library,HEAD,enhancement,normal,,new,2007-08-23T04:13:15-0700,2012-01-05T08:06:04-0800,"Haddock docs are not installed sensibly in Windows. They go under Common Files, which is silly; Their path doesn't contain compiler version, which makes it hard to install docs for same package version installed for different compilers/versions and they are not relocatable because * default uses absolute paths for references * with a lot of work they can refer to each other via relative paths, but ghc installation isn't installed in similar fashion. And then all packages must also be installed into same prefix. (ie user-only vs admin installs)",eivuokko 3,_|_ Release,189,Handle framework paths (-F) in Cabal,Cabal library,1.2.2.0,enhancement,normal,,new,2007-12-10T15:24:10-0800,2012-01-05T08:06:17-0800,"There's been some discussion on the GHC trac ([http://hackage.haskell.org/trac/ghc/ticket/1931 1931], [http://hackage.haskell.org/trac/ghc/ticket/1798 1798], [http://hackage.haskell.org/trac/ghc/ticket/1395 1395]) about adding framework search paths (gcc's `-F` flag, and ghc's `-framework-path` flag). Currently Cabal handles `-framework`, but not `-framework-path`. I propose the following behavior for Cabal: 1. Add a `framework-path:` field which will pass `-framework-path` to `ghc` and `-F` to `gcc`, `hsc2hs`, et. al. 2. Always add `-F$HOME/Library/Frameworks` as an argument to the above programs (regardless of any `framework-path` entries). I believe `#1` to be uncontroversial. My reasoning for `#2` is the following: - `$HOME/Library/Frameworks` is the standard location to put frameworks if you do not have administrative access. - Without it, `readline.cabal` (e.g.) would need {{{ framework-path: /Users/judah/Library/Frameworks }}} which is not portable between machines. Finally, note that these flags only affect build behavior, not runtime loading of libraries (which searches `$HOME/Library/Frameworks` by default). See [http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks OSXFrameworks] for more info. -Judah",guest 3,_|_ Release,195,Specify include and library paths that are used for building the package only,Cabal library,1.2.3.0,enhancement,normal,,new,2007-12-17T07:39:25-0800,2008-01-24T08:05:19-0800,"From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293523 {{{ Specify include and library paths that are used for building the package only, and do not end up in the GHC packages file. }}} I think this needs more explanation. There is certainly a use case for includes that are used to pre-process Haskell code since they are never needed when building dependent packages. On the other hand, library paths to find libraries to link to are always required by dependent packages as far as I know since to link an executable using a package that uses a library we have to specify the library and search path. There is no way with GHC to limit where a C header file might be needed. If a header file is needed to compile a package, then the header file might also be needed to compile code that uses the package due to cross-package inlining. If GHC does gain the feature to limit the scope of where C headers are required then we will want to support that in Cabal, possibly via package-local headers.",duncan 3,_|_ Release,196,ability to specify custom args to haddock,Cabal library,1.2.3.0,enhancement,normal,,new,2007-12-17T07:39:28-0800,2008-05-26T18:05:53-0700,"From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293523 {{{ The ability to specify custom args to haddock, which is necessary to do things such as build docs that encompass parts of other packages }}} We can pass extra options to any program via the generic configure --$PROG-options= mechanism however for haddock this is not very useful since we also have to call haddock for another purpose and passing extra options there causes problems. Since the debian bug was filed there are several more feature of the haddock command, perhaps they solve the problem. If not, perhaps the problem could be explained further. What problem are we trying to solve here that would require passing extra options to haddock, and what extra options would one use?",duncan 3,_|_ Release,263,Multiple compilers of the same version confuse Cabal,Cabal library,1.2.3.0,defect,normal,,new,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 3,_|_ Release,320,cooperation with Windows Vista's User Access Control,Cabal library,1.4.0.1,enhancement,normal,,new,2008-08-05T12:34:00-0700,2012-01-05T08:03:33-0800,"Installation of a cabal package under Windows Vista with UAC activated may fail even when working as administrator, because cabal doesn't request the necessary rights to write to, e.g., ""c:\Program Files\Haskell\"". A workaround is to start an ""Administrator console"" to start Cabal from a process which already acquired admin privileges. Cabal should request the necessary rights instead of failing. cabal-install should check in advance whether the target destination is writeable and fail early or request the necessary rights. (currently, cabal-install fails after compiling all dependencies. After starting cabal-install again from an Administrator console, everything has to be build again). {{{ C:\Downloads\Haskell\typeof-0.1.1>runhaskell Setup install Setup: C:\Program Files\Haskell\doc\typeof-0.1.1: copyFile: permission denied (P ermission denied) }}}",Toxaris 3,_|_ Release,429,Strange error that seems related to repos field in config,cabal-install tool,1.6.0.1,defect,normal,,new,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,_|_ Release,442,remove old packages after successful update,cabal-install tool,1.6.0.1,enhancement,normal,,new,2009-01-05T11:42:58-0800,2012-01-05T08:12:12-0800,"After a successful `cabal update` command, the old version of the package could be removed. (It required to rebuild/reinstall all the dependent packages as well. It is reported in #441 ticket.) I do not think it should be a default behavior, but make it possible would be really nice. :)",guest 3,_|_ Release,481,License compatibility check,Cabal library,,enhancement,normal,,new,2009-01-30T15:02:13-0800,2011-02-15T14:22:33-0800,"It would be nice if Cabal could report license compatibility problems - e.g.: * Trying to build a BSD3-licensed package that depends on a GPL package * Trying to build a proprietary-licensed package that depends on a GPL package",guest 3,_|_ Release,534,cabal haddock should --hyperlink-source by default,Cabal library,1.6.0.1,enhancement,normal,,new,2009-03-28T12:27:38-0700,2012-04-20T09:37:15-0700,"The results from cabal haddock --hyperlink-source are very nice, but quite frequently the haddocks are not built with this (all recent hackage libs iirc). Would there be a problem with generating the source links by default if and only if a HsColour can be found? Or should this issue instead be resolved at the haddock level?",adamvo 3,_|_ Release,578,Allow installation of distro packages,cabal-install tool,,enhancement,normal,,new,2009-08-28T09:42:17-0700,2012-01-05T07:56:28-0800,"It would be very nice indeed if {{{cabal-install}}} could be taught how to install a distro's version of a package. This could amount to simply asking a shell script if the package is available and can be installed, before proceeding with the usual Cabal installation machinery.",bos 3,_|_ Release,748,cabal does not use JavaScript proxy autoconfiguration,cabal-install tool,1.8.0.6,defect,normal,,new,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 4,_|_ Release,28,Shipments in Cabal,Cabal library,,enhancement,normal,Krasimir,new,2005-12-08T11:33:28-0800,2012-01-05T08:27:14-0800,"The shipment will allow to distribute multiple Cabal packages in one distribution. See hawiki pages: * http://www.haskell.org/hawiki/Cabal_2fAggregatePackages * http://www.haskell.org/hawiki/Cabal_2fMultiPackageDistributables",krasimir 4,_|_ Release,47,implement ./setup bdist,cabal-install tool,,enhancement,normal,,new,2006-01-08T21:53:06-0800,2012-01-05T08:11:26-0800,A binary distribution.,ijones 4,_|_ Release,179,support GHC's main-is extension,Cabal library,1.2.2.0,enhancement,normal,,reopened,2007-11-15T10:07:32-0800,2012-01-05T08:31:30-0800,"Query on haskell-cafe: http://haskell.org/pipermail/haskell-cafe/2007-November/034686.html {{{ It seems the meaning of the -main-is switch for GHC and the Main-Is build option for Cabal executables differ. With GHC, I can point to any function ""main"" in any module, but in Cabal I must point to a filename with precisely the module name ""Main"". This is tying my hands with regard to organizing a default executable and exposing some of its functionality as a library. Is there a way to get around this restriction? Concretely, I want to point Cabal's Main-Is to Program/Main.hs which starts with module Program.Main where instead of just module Main where }}} So in GHC it has this meaning: http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-linker {{{ -main-is thing The normal rule in Haskell is that your program must supply a main function in module Main. When testing, it is often convenient to change which function is the ""main"" one, and the -main-is flag allows you to do so. The thing can be one of: A lower-case identifier foo. GHC assumes that the main function is Main.foo. An module name A. GHC assumes that the main function is A.main. An qualified name A.foo. GHC assumes that the main function is A.foo. }}} In Cabal the {{{main-is:}}} field specifies the '''file name''' of the Main module. GHC's {{{-main-is}}} flag is an extension to Haskell that is not supported by the other Haskell implementations.",duncan 4,_|_ Release,245,Cabal should support hsc2hs's stub .c feature,Cabal library,1.2.3.0,defect,normal,,new,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 4,_|_ Release,460,find the http proxy on windows more reliably,cabal-install tool,,defect,normal,,new,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 4,_|_ Release,589,FreeBSD compiles should automatically add --extra-lib-dirs=/usr/local/lib,Cabal library,1.6.0.1,defect,normal,,new,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 2,HackageDB Release,184,cabal-install should report build results to hackage server,hackageDB website,1.2.2.0,enhancement,normal,,reopened,2007-11-22T07:44:21-0800,2012-01-05T08:32:04-0800,"One way to get a lot more testing data on hackage packages is if cabal-install could report back to the hackage server about build successes and failures. This information should be kept by hackage and used to distill information about which platforms configurations a package builds successfully and which it does not. This should provide useful information to developers to enable them to discover problems more quickly and useful information to users. An important consideration is privacy. Users should always have the option to not report anything and any information they report that is kept should not contain identifying information. This is particularly important when it comes to build logs which may contain paths etc. It should be clear to users what information they are reporting to the can decide for themselves if it meets their privacy needs. Since cabal can be used to build private code it is vital that it reports only on packages that were obtained from the hackage server. It is also vital that the information is sent to the correct hackage server. It's possible to set up private hackage server instances and it'd may be useful to collect build information ""in house"" too. So what information would be helpful? * build success or failure (qualified by what failed, build, docs, tests) * package name and version * hash of .cabal file just to make sure it's the same one we're all talking about and to detect local modifications. * precise versions of dependent packages that the package was built with. * os and arch strings * compiler flavour and version * versions of important build tools * In the case of a build failure, some part of the build log would be helpful. This is the most problematic part from a privacy point of view. This is quite a bit of raw data and we can expect to have many hundreds of such reports for popular packages. How can we distill useful information from this kind of data? I expect we would want to do some statistical analysis where we look for common traits in the results. The data forms a multi-dimensional space of boolean values. By looking down the rows/columns of this space we should be able to identify trends. For example if it always fails with ghc-6.8.x, or always fails on Windows. Excluding those obvious failures we then may be able to say that it does work on mac osx (except ghc-6.8.1) or that it does work with regex-posix-0.92 (except on windows), etc. This should allow us to give a summary saying yes/no to various properties of the environment. For failure cases developers should be able to get access to the more detailed data including build logs.",duncan 3,HackageDB Release,56,hackageDB should not accept a package if it is not installable,hackageDB website,,enhancement,normal,,new,2006-01-23T21:46:34-0800,2009-02-07T10:59:19-0800,"hackageDB should try to build and install each package in a chroot before ""accepting"" the package. If it doesn't build, it should email the uploader or maintainer.",ijones 3,HackageDB Release,576,Show reverse dependencies,hackageDB website,1.6.0.1,enhancement,normal,,new,2009-08-21T02:12:40-0700,2012-01-05T08:34:12-0800,"Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide examples or documentation. It could be very helpful to look at packages which use the package on is interested in. This can be made easier if every package on http://hackage.haskell.org/ displays which other packages depend on it.",Lenny222 3,HackageDB Release,767,Highlighted source code on hackage.haskell.org mangles Unicode,hackageDB website,,defect,normal,,new,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,HackageDB Release,840,Download statistics,hackageDB website,,enhancement,normal,,new,2011-05-10T19:05:42-0700,2011-05-10T19:05:42-0700,Provide download statistics for each package version.,VivianMcPhail 3,HackageDB Release,861,doc/html/frames.html broken on many recent packages,hackageDB website,HEAD,enhancement,normal,,new,2011-07-07T22:54:35-0700,2011-07-08T01:18:01-0700,"For example, this works: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/frames.html But this doesn't: http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/frames.html The frames version is rather useful in lieu of Chrome having a sidebar. I'm guessing the original index.html and index-frames.html have been moved (rather than copied) elsewhere. Thanks, /Liyang",liyang 3,HackageDB Release,907,New cabal-install release needed for hackage,hackageDB website,HEAD,task,normal,,new,2011-12-21T22:06:02-0800,2011-12-23T11:15:42-0800,"The bug http://hackage.haskell.org/trac/hackage/ticket/656 is impacting several packages from being correctly installed on the hackage web site. Given this bug was fixed about 5 months ago, and the last cabal-install release was about 6 months ago (Mar 9th, 2011), it sounds like a new release would help move things along. This is per the discussion here: http://www.haskell.org/pipermail/cabal-devel/2011-December/007964.html",LeventErkok 3,Cabal-2.0 Release,13,allow preprocessor chaining,Cabal library,,enhancement,normal,,new,2005-10-30T20:21:52-0800,2008-01-24T07:50:56-0800,Allow preprocessor chaining so that a file can be preprocessed by more than one tool.,ijones 3,Cabal-2.0 Release,15,implement make-style module/file dependency framework,Cabal library,,enhancement,normal,,new,2005-10-30T20:26:02-0800,2009-01-19T10:35:34-0800,"Implement inter-module dependency analysis. This will improve a number of features, including: * Obviate other-modules field * Building DLLs? We might be able to use the code from HMake, but must check w/ copyright holders.",ijones 3,Cabal-2.0 Release,16,relink only when necessary,Cabal library,HEAD,enhancement,normal,,new,2005-10-30T20:28:59-0800,2008-01-24T07:44:24-0800,Re-link only when necessary. This relates to building dependency analysis. ticket:15.,ijones 3,Cabal-2.0 Release,17,re-generate foo.hsc when dependencies change,Cabal library,HEAD,enhancement,normal,,new,2005-10-30T20:30:30-0800,2008-01-24T07:51:19-0800,"This relates to building dependency analysis. ticket:15*. Cabal does not handle dependencies for HSC2HS correctly. For example, if Foo.hsc has {{{ #include ""x.h""}}} then Foo.hs should get regenerated whenever x.h is modified. However, Cabal only regenerates Foo.hs when Foo.hsc has been modified.",ijones 3,Cabal-2.0 Release,34,specify a way to add .o files to a library,Cabal library,HEAD,enhancement,normal,,new,2005-12-11T11:21:03-0800,2008-01-24T07:45:54-0800,".o files may be generated by means outside of cabal, and there should be a way to list them in the .cabal file as being linked with the library.",igloo 3,Cabal-2.0 Release,48,improve c2hs support,Cabal library,,enhancement,normal,,new,2006-01-16T03:48:02-0800,2012-01-05T08:11:17-0800,"To properly support c2hs in Cabal we need a couple enhancements: 1. dependency resolution. Not only do the .hs files depend on the .chs files but .chs files can depend on other .chs files (or strictly speaking on their corresponding .chi files). This is because c2hs supports its own module import mechanism to get information about bindings defined in one module to be used in other modules. From the c2hs [http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-1.html manual]: {{{ If the compiled binding module contains import hooks, C->Haskell needs to find the .chi (C->Haskell interface files) produced while compiling the corresponding binding modules. By default, they will be searched for in the current working directory. If they are located elsewhere, the --include=INCLUDE option has to be used to indicate the location, where INCLUDE is a colon-separated list of directories. Multiple such options are admissible. Paths specified later are searched first. }}} The Gtk2Hs project has a [http://darcs.haskell.org/gtk2hs/mk/chsDepend.in script] to find the dependencies of a .chs file. This should be translated into Haskell and included in Cabal's future pluggable dependency resolution mechanism(!). 2. The .chi files need to be installed If one Cabal package uses .chs files then another package that wants to import that module into another .chs module using c2hs's import mechanism will need access to the .chi file of the imported module. This is basically the same as how ghc needs the .hi file of imported modules. One difference is that .chi modules are transitive (unlike ghc's .hi files) so only the .chi files corresponding to exposed modules need to be installed (where as for ghc every .hi file needs to be installed). Both of these enhancements are essential to be able to package [http://haskell.org/gtk2hs/ Gtk2Hs] using Cabal. Gtk2Hs has many .chs modules and with dependencies between them, including many dependencies between .chs modules in different packages. For example all of the Gtk+ extension packages (OpenGL, !SourceView, Glade, Mozilla embeding widget) import type definitions from .chs modules in the base gtk & glib packages.",duncan 3,Cabal-2.0 Release,50,create compiler frameworks for new compilers,Cabal library,,enhancement,normal,,new,2006-01-20T08:36:41-0800,2012-01-05T08:32:29-0800,"Email from John Meacham below. Another possibility is to make it rather like a hook. I'd rather work on making a general compiler framework for it so that jhc can just drop a file describing its interface in /usr/share/lib/cabal/compilers/jhc.cabal-compiler or something and cabal will automatically be able to use it. Ideally, one would not have to upgrade their cabal just because they install (or write) a new haskell compiler. I think all compilers conform to one of hmake-like: ghc --make, jhc, nhc + hmake interpreter-like: hugs gcc-like: ghc, nhc98 so a compiler declaration file would not have to be much more complicated than a string telling it how to invoke the compiler and a mapping of various extensions/cabal options -> compiler flags. I'd also like to do something like this for preprocessors, which would be a much simpler project so will probably do first.",ijones 3,Cabal-2.0 Release,104,"""setup install"" should configure and build if necessary",Cabal library,1.1.6,enhancement,normal,,new,2006-12-15T08:36:40-0800,2008-08-25T12:32:40-0700,"To make the user experience a little smoother, it should be possible to just 'cabal-setup install' and get a default configure, build, and install sequence in one go. We already roll register into install anyway, this is just more of the same.",guest 3,Cabal-2.0 Release,133,sdist and clean should never be given Maybe LocalBuildInfo,Cabal library,1.1.6,task,normal,,new,2007-05-26T07:16:39-0700,2009-12-01T04:25:54-0800,"Currently cleanHook, postClean, sDistHook, postSDist get a Maybe LocalBuildInfo argument. They shouldn't do something different depending on, e.g., what compiler they have been configured with, so they should not be passed this. If they /need/ something from LocalBuildInfo (e.g. happy in order to generate files to put in the source tarball?) then they should /always/ be passed something (either LocalBuildInfo or a smaller datatype).",guest 3,Cabal-2.0 Release,134,Clean up hooks,Cabal library,1.1.6,task,normal,,new,2007-05-26T08:16:42-0700,2009-01-19T10:34:35-0800,"See * http://www.haskell.org/pipermail/cabal-devel/2007-April/000512.html * http://www.haskell.org/pipermail/cabal-devel/2007-May/000528.html * http://www.haskell.org/pipermail/cabal-devel/2007-May/000534.html * http://www.haskell.org/pipermail/cabal-devel/2007-May/000535.html * #133",guest 3,Cabal-2.0 Release,159,make-style module/file dependencies,Cabal library,HEAD,enhancement,normal,,new,2007-09-27T08:58:38-0700,2008-08-25T12:30:03-0700,"I've already posted this to the list, but I'm reposting it here in the hopes that it will generate some comments. This patch adds dependency analysis to the build phase in Cabal packages. The code hooks in to the build system through the build user hook. The only compiler it currently supports is GHC, but it does support c2hs, hsc, and cpphs, as well as FFI stubs. It still needs support for building executables, split objects, and I'm sure a few other things I'm not thinking about right now. Please try the patch out. If you run ""make setup-dep"", a version of setup using this patch will be built, which then can be run the way you'd usually run setup. Pete",guest 3,Cabal-2.0 Release,230,setup haddock ignores LANGUAGE CPP pragma,Cabal library,1.2.3.0,defect,normal,,new,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-2.0 Release,290,Cabal does some work behind the back of hooks,Cabal library,1.2.3.0,defect,normal,,new,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-2.0 Release,370,Check that packages declare language extensions accurately,Cabal library,HEAD,defect,normal,,new,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-2.0 Release,401,better support for multi-valued configuration flags,Cabal library,,enhancement,normal,,new,2008-11-08T07:52:30-0800,2009-01-16T09:29:24-0800,"For some packages one has to pick one of several mutually exclusive options. For example `yi` has a number of console or gui front ends. That can be expressed in terms of boolean flags but it's a little clumsy. We should consider adding some syntactic sugar. Currently it can be expressed by excluding the choice of picking none: {{{ if flag(gtk) ... if flag(vty) ... if flag(coca) && os(osx) ... if ! ( flag(gtk) || flag(vty) || (flag(coca) && os(osx)) ) buildable: false }}} That doesn't exclude the possibility of picking two options of course. In some cases we would want the options to be mutually exclusive and in others we would want to simply force the choice of one option, but multiple options might be possible. So the question is what kind of syntactic sugar would we like, how would it translate and how would it be exposed to package managers. eg: {{{ flag gui values: gtk, vty, coca if flag(gui==gtk) ... etc }}} and it'd translate into boolean choices that forced a choice of one flag being true and the others false. Needs some thought.",duncan 3,Cabal-2.0 Release,476,cabal should handle missing build-depends better,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-24T07:13:08-0800,2012-01-05T08:11:30-0800," It is a common complaint that missing `build-depends` causes unfriendly error messages. For example http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of-software.html writes {{{ I noticed another nice Cabal feature upon first adding the line import qualified Data.Map as Map to my program. Of course, recompiling produced the message: Preprocessing executables for interpreter-0.1... Building interpreter-0.1... src/Core.hs:8:17: Could not find module `Data.Map': it is a member of package containers-0.1.0.2, which is hidden }}} The commentator notes: {{{ But really, my favorite feature is highlighted by the GHC error message about not being able to find Data.Map. Of course, Data.Map is on my system – GHC’s even found it, and told me where it is. But Cabal’s made an important distinction: just because I have software installed in my development environment doesn’t mean I want to use it! Rather, Cabal’s started out by hiding all the Haskell libraries installed on my system. This helps me really appreciate the packaging system, as I get to individually add each package I’ve previously installed and then wish to use to my metadata file. Of course, keep in mind, this is a per-project effort! Even if I’ve used a library in one project, I might not want to use it in my other projects. }}} Which is of course right. It is rather annoying. For Cabal-2 we plan to track module dependencies directly rather than relying on `ghc --make`. In that case we have two options to improve the above situation. For quick and casual builds (perhaps not even using a .cabal file) we can just use the available packages and not complain. For packages that we expect to distribute we can either give warnings or errors about missing `build-depends`. In either case we can say exactly what is missing (not just the first) and we can make a reasonable suggestion about what version constraints to use.",duncan 3,Cabal-2.0 Release,559,Only allow dependencies on meta-packages from other meta-packages,Cabal library,1.6.0.1,enhancement,normal,,new,2009-06-02T10:53:59-0700,2009-06-02T11:02:07-0700,"Following a discussion between Duncan Coutts and myself on meta-packages (packages that are empty and only depend on other packages), we came to the conclusion that it only ever makes sense to depend on a meta-package if the package is itself a meta-package. This is to support the case where we want to provide a meta-package that is a superset of another meta-package. For instance, we could want to provide a ""happs-base"" meta-package, depending on the basic packages that every happs installation needs, and another ""happs-withlotsofstuff"" package, depending on ""happs-base"" plus some other packages for conveniency. In the case we depend on a meta-package but we're not a meta-package ourself, our dependency is necessarily incorrect, in the sense that we actually depend on less than the meta-package, and we should list those specific dependencies ourselves. Enforcing that restriction on hackage would prevent such abuses.",guest 3,Cabal-2.0 Release,585,specify hidden modules as everything not exposed,Cabal library,1.6.0.1,enhancement,normal,,new,2009-09-15T14:32:57-0700,2009-09-16T12:55:05-0700,"I'm trying to package a large Haskell project (currently built using make) to Cabal, and although we only want to expose around a dozen modules, the implementation of those modules uses hundreds of other modules. It seems like I need to explicitly list each of these hidden modules in the .cabal file in order to generate a library that will link correctly. Ideally, I could just say what the exposed modules are, and have every other module hidden by default.",wisnesky 3,Cabal-2.0 Release,594,"Unhelpful error message for ""module found in multiple packages""",Cabal library,1.6.0.1,enhancement,normal,,new,2009-09-29T12:00:36-0700,2012-01-05T08:09:44-0800,"I was checking whether cabal-install would install my ""extcore"" package, and got: {{{ $ sudo cabal install extcore --enable-library-profiling --reinstall Resolving dependencies... Configuring extcore-0.3... Preprocessing library extcore-0.3... Building extcore-0.3... Language/Core/Core.hs:6:7: Could not find module `Data.Generics': it was found in multiple packages: base-3.0.3.1 syb cabal: Error: some packages failed to install: extcore-0.3 failed during the building phase. The exception was: exit: ExitFailure 1 }}} This is an unhelpful error message because it gives the user no information about what they have to do to continue. Since I'm the package author, I was able to figure out that I needed to change the .cabal file to depend on base >= 4. In general, the error message should explain that this is a bug in the package description and to report it to the package maintainer. cabal-install 0.6.2, library version 1.6.0.3.",Tim 2,Cabal-1.8 Release,458,"inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure",Cabal library,1.2.3.0,defect,normal,,new,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 2,Cabal-1.8 Release,564,Cabal doesn't use LD options when testing linking,Cabal library,1.6.0.1,defect,normal,,new,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 3,Cabal-1.8 Release,24,Cabal shouldn't try to build GHCI libs on platforms without GHCI,Cabal library,,defect,normal,,new,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-1.8 Release,89,Sharing of object files between executable builds?,Cabal library,,enhancement,normal,duncan,new,2006-07-17T13:02:00-0700,2012-01-05T08:31:36-0800,"When building a package which contains multiple executables which share some modules, each module is recompiled for every executable. This can increase the compile time substantially. One problem with compiling each module only once is that different executables can have different compiler options, which can for example affect preprocessing. Maybe modules could be shared if all executables have the same compiler options?",bjorn@… 3,Cabal-1.8 Release,93,Incorrect permissions on library install,Cabal library,1.8.0.6,defect,normal,,reopened,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 3,Cabal-1.8 Release,137,setup sdist places implementation-dependent preprocessor output in the source bundle,Cabal library,HEAD,defect,normal,,new,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-1.8 Release,148,Cabal should be able to produce foreign libs (shared or static),Cabal library,HEAD,enhancement,normal,,new,2007-08-23T03:58:10-0700,2012-01-05T08:06:36-0800,"GHC supports linking final executable into a DLL instead of normal executable. Cabal should support this use, and also support specifying DEF file for exports and building an import library.",eivuokko 3,Cabal-1.8 Release,200,Allow more convenient use of ghc profiling options -auto and -auto-all,Cabal library,,enhancement,normal,kmcallister,assigned,2007-12-18T12:33:37-0800,2012-01-05T08:33:38-0800,"Add Setup.(l)hs options that: 1) tells ghc to make a profiling library; 2) tells ghc to make a profiling executable 3) pass on the (a) -auto or (b) -auto-all option 4) Let you do (1)-(2)-(3a) or (1)-(2)-(3b) with a single option, instead of three. ",guest 3,Cabal-1.8 Release,209,"Implement ""package()"" configurations predicate",Cabal library,1.2.3.0,enhancement,normal,nominolo,new,2008-01-21T12:37:48-0800,2008-11-08T08:01:33-0800,"We often have to write things like: {{{ flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3 }}} Which is verbose and annoying. It would be nicer to say: {{{ library build-depends: base if package(base >= 3) build-depends: containers }}} This is syntactic sugar only. It translates into the existing constructs so no new behaviour is being introduced. It would translate into: {{{ flag _1 library build-depends: base if flag(_1) build-depends: base >= 3 build-depends: containers else build-depends: base < 3 }}} It is described in more detail in this thread: http://www.haskell.org/pipermail/cabal-devel/2007-October/001189.html http://www.haskell.org/pipermail/cabal-devel/2007-November/001336.html",duncan 3,Cabal-1.8 Release,212,Overhaul Cabal's testsuite,Cabal library,1.2.3.0,task,normal,,new,2008-01-24T06:15:09-0800,2012-01-05T08:06:55-0800,"The current testsuite based on HUnit is almost completely bitrotted. Anyone who wants to take this on has essentially a completely clean slate to work from. The current system is split into two parts. There are hunit tests in many of the modules guarded by #ifdef DEBUG. Then there are external tests in the `tests/` subdirectory. The #ifdef DEBUG style is annoying since it involves using more CPP than seem really necessary. A couple notes from the old `TODO` file: {{{ ** add a make target or command for tests we know will fail? ** setup test suite to run on --push? ** redirect non-hunit outputs to a file? }}} One possibility that is available to us now that was not before is using the hackage collection as part of a regression test. For example it should always be possible to parse all the `.cabal` files in the index.",duncan 3,Cabal-1.8 Release,218,Data-files have no way of being installed conditionally,Cabal library,1.2.3.0,enhancement,normal,nominolo,new,2008-01-26T13:34:00-0800,2008-10-09T10:16:11-0700,"Using cabal-1.2.3.0 and Yi, I have the following problem. For the Mac OS X Cocoa port, it has an icon which is a PDF file containing a rendered version of the Yi SVG logo, and which gets installed with it. Installing the PDF only makes sense if you are on a Mac (indeed, the PDF seems to be corrupt if you try to view it with, say, Xpdf). Right now, the yi.cabal file just reads: cabal-Version: == 1.2.3.0 tested-with: GHC==6.8.2 build-type: Custom data-files: art/yi+lambda-fat.pdf -- FIXME: Install Cocoa icon only when Cocoa configured That is, the PDF is always installed. Now, my first attempt was to read the Cabal manual and realize that the obvious solution was to just stick the data-files: field under a flag or conditional - just like the yi.cabal already does for build-depends, ghc-options, buildable, etc. But this doesn't work! Yi will still compile and build, but Cabal says: Warning: Unknown fields: data-files (line 101) Fields allowed in this section: executable, main-is, buildable, build-tools, cpp-options, cc-options, ld-options, pkgconfig-depends, frameworks, c-sources, extensions, extra-libraries, extra-lib-dirs, includes, install-includes, include-dirs, hs-source-dirs, other-modules, ghc-prof-options, ghc-shared-options, ghc-options, hugs-options, nhc98-options, jhc-options The error tells me that the conditional didn't take: gwern@localhost:1023~/bin/yi_0>locate fat|grep lambda|grep .pdf [ 4:31PM] /home/gwern/bin/yi/_darcs/pristine/art/yi+lambda-fat.pdf /home/gwern/bin/yi/art/yi+lambda-fat.pdf /home/gwern/bin/share/yi-0.3/art/yi+lambda-fat.pdf gwern@localhost:1024~/bin/yi_0> (Even though I am on Linux, and the Cocoa flag is emphatically set to False.) -- Anyway, given that what I want to do is sensible, that nowhere in the docs I've been able to find or on #haskell mentions any non-hacky solution, and that it's already supported by Cabal for other kinds of files, I think this is a pretty reasonable feature request.",guest 3,Cabal-1.8 Release,225,"allow installing just specific bits, like just docs",Cabal library,1.2.3.0,enhancement,normal,,new,2008-01-31T07:00:45-0800,2008-08-15T07:16:32-0700," Sometimes people would like to build and install just part of a cabal project, e.g. the documentation or one of the libraries or binaries. Specific use-cases are packaging for OS distro's and generating Haddock docs for code that was installed without it (cf the current state of Debian-stable). Igloo proposes the following user interface: ----- As long as docs, license and binaries can be (de)selected individually I don't really mind. If you want a concrete suggestion, we could have `--foo` and `--no-foo` for each thing, with the default being `--all` and the command line being processed left-to-right, e.g. {{{ cabal install --no-haddock-interfaces --docs --no-html }}} would install * all (which wouldn't actually contain anything) * docs (which wouldn't actually contain anything) * haddock-interfaces * license * everything under binaries ----- I broadly agree, but am slightly concerned there are dependencies amongst the various things that his syntax does not respect (e.g. one may need to install the libraries - e.g. one depending on a foreign library - in order to get a binary working). So either we have to vet the command lines or coarsen the flags. I hope Duncan and Igloo can draw on their packaging experience and determine what is actually useful.",duncan 3,Cabal-1.8 Release,229,Build C sources using the system's C compiler directly,Cabal library,1.2.3.0,enhancement,normal,,new,2008-02-03T03:30:04-0800,2012-01-05T08:07:33-0800,"Currently Cabal builds C sources by going via ghc. On some platforms this introduces some limitations (Windows especially, I think). See this conversation for an example where it would be useful: http://www.mail-archive.com/haskell-cafe@haskell.org/msg37179.html",guest 3,Cabal-1.8 Release,231,"""buildable: False"" should fail the current configuration",Cabal library,1.2.3.0,defect,normal,nominolo,new,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-1.8 Release,266,cabal haddock plus cpp preprocessing with relative #include files,Cabal library,HEAD,defect,normal,,new,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-1.8 Release,276,Add support for convenience libraries,Cabal library,1.2.3.0,enhancement,normal,,new,2008-05-08T22:00:39-0700,2010-08-26T00:28:50-0700,"I'd like to have a package with several binaries which all use a convenience library included in that same package. The convenience library should NOT be installed. For this to work, Cabal needs two things. Firstly, it must allow dependencies within a package such that I could describe the library and have the binaries depend on it. Secondly, it should have an ""installable"" flag, similar to ""buildable"". A thing that's not installable would be built but not installed. The same mechanism could be used for package-internal tools.",rl 3,Cabal-1.8 Release,342,Allow automatic resolving of conditionals on more than just build-depends,Cabal library,HEAD,enhancement,normal,,new,2008-08-25T05:59:35-0700,2010-04-21T07:25:36-0700,"We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not.",duncan 3,Cabal-1.8 Release,362,Disallow uploads of libraries that provide binaries called 'test' and similar,Cabal library,1.2.3.0,defect,normal,,new,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-1.8 Release,374,Hs-Source-Dirs in nested If must be respected by 'sdist',Cabal library,1.4.0.1,defect,normal,,new,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,Cabal-1.8 Release,395,Warn about dependencies like parsec <= 2.1.0.0,Cabal library,,enhancement,normal,kmcallister,assigned,2008-11-08T07:12:28-0800,2010-04-11T02:33:34-0700,"Cabal should warn about dependencies like `parsec <= 2.1.0.0`. It's almost certainly a mistake given the conventional semantics of version numvers. Something like `foo < 2.0` is quite common and it's relatively harmless so there's probably no point in warning. On the other hand `foo < 2.0.0` is weird. It says `foo-2.0` is ok, but `foo-2.0.0` or `foo-2.0.0.1` is not. Something like `foo <= 2.0` is a definately weird though since it excludes bug fixes like `foo-2.0.0.1`",duncan 3,Cabal-1.8 Release,398,better support for static linking,Cabal library,1.2.3.0,enhancement,normal,,new,2008-11-08T07:17:49-0800,2012-01-05T08:30:01-0800,"Generating statically linked binaries on different platforms requires a bit of knowledge about what flags to pass to ghc. It would be nice to just be able to `cabal configure --enable-static-executable` or something and have that pass the extra `-optl-static` and whatever ghc options are required. If it's not possible to generate static binaries it should make some attempt at explaining why.",duncan 3,Cabal-1.8 Release,399,"More information in the Paths_pkg.hs module, or a new module",Cabal library,1.2.3.0,enhancement,normal,,new,2008-11-08T07:28:02-0800,2010-10-31T09:19:50-0700,"There is more information about the system or about the package or configuration that we could include into a generated module. For example: * OS name (from standard enum names, not System.Info.os) * Arch name (similarly) * Compiler used for build * Package version (perhaps moved out of the `Paths_` module) * Other .cabal file package details (as Strings) * `x-foo` extension fields * license enum * authors, copyright * synopsis / description * home page, bug report url * configuration flag values * System details * big or little endian * Revision control context * git hash * darcs context ",duncan 3,Cabal-1.8 Release,400,fail and warnings for build configurations,Cabal library,,enhancement,normal,,new,2008-11-08T07:42:53-0800,2009-01-16T09:29:16-0800,"People expect `buildable: False` to fail the current configuration (rather than letting it configure and then not working at build time). But perhaps we should make that more explicit and allow a message, eg instead of: {{{ if os(windows) buildable: False }}} allow {{{ if os(windows) fail: it doesn't work on windows because, blah blah blah }}} And similarly we might want to warn users about selecting particular configurations eg: {{{ if flag(http) ... else warn: no http implementation selected, only local operations will be possible. You probably really want some http implementation. }}} The semantics roughly is that it's a workable but sub-optimal configuration. The solver should try to avoid warnings, by selecting another alternative.",duncan 3,Cabal-1.8 Release,424,build-depends in global section in new-style .cabal files are ignored,Cabal library,1.6.0.1,defect,normal,,new,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-1.8 Release,434,Let packages opt-in to the Package Versioning Policy,Cabal library,1.2.3.0,enhancement,normal,,new,2008-12-18T14:15:06-0800,2012-01-05T08:10:11-0800,"Package version numbers and version constraints on dependencies are proxies for API compatibility. It is hard for people to specify the dependencies correctly and we would like to improve their quality. We have the [http://haskell.org/haskellwiki/Package_versioning_policy Package versioning policy] which says how the package version number relates to API changes. What we want is a mechanism by which package authors can opt-in to the versioning policy. We should then get hackage to check that the package really is following the policy. Just as important we can use the fact that a package does follow the policy to give suggestions to package authors. For one thing we can discourage or ban upwardly open version ranges and provide a suggestion on what upper version bound to use.",duncan 3,Cabal-1.8 Release,454,file permissions of installed files on windows,Cabal library,1.6.0.1,defect,normal,,new,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 3,Cabal-1.8 Release,465,default global install on windows is a problem,Cabal library,1.6.0.1,defect,normal,,new,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-1.8 Release,466,datadir does not follow prefix on windows (for libs),Cabal library,1.6.0.1,defect,normal,,new,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-1.8 Release,467,Add support for HPC profiling.,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-19T11:00:40-0800,2012-01-05T08:05:08-0800,"Similar to how we support ghc's ""normal"" profiling way, we should enable support to build packages with hpc turned on. This would also eliminate the need for people to add support on a per-package basis, see eg #430. See also #200. We should consider how to support these various flavours of profiling in a more extensible way. Different compilers have different ways, for example nhc has several (especially when used with hat).",duncan 3,Cabal-1.8 Release,472,new field for version policy,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-21T09:23:49-0800,2009-02-01T08:16:02-0800,"We would like packages to be able to describe what version policy they use. One common policy that we have been discussing is called the [http://haskell.org/haskellwiki/Package_versioning_policy Package versioning policy] or PVP for short. In particular we would like packages to be able to opt-in to following this policy. It would enable hackage to enforce the policy (with a suitable API-checking tool) which should provide a strong guarantee for client packages. In addition it would allow hackage and cabal to make suggestions for packages about dependencies on packages that follow the polciy. For example it could suggest not using upwardly open version ranges. So we would like a reasonably extensible syntax for packages to specify what version policy they follow. One suggestion is: {{{ version-policy: PVP-1 }}} That is named (and versioned) policies. The names would have to be well known and defined elsewhere. Only known policies could only be enforced. As with other similar meta-data, the value should be parsed but allow unknown policies. Hackage could reject unknown policies, but it would enable people to make in-house modifications to add new policies.",duncan 3,Cabal-1.8 Release,475,don't describe build actions that are no-ops,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-24T07:12:43-0800,2012-01-05T08:33:34-0800,"from http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of-software.html This is actually an excellent review. It's funny and spot on. It picks up some of the real things that people notice but that Cabal hackers are blind to because we're too used to the way things are. One thing it picks up on: {{{ Preprocessing executables for interpreter-0.1... Building interpreter-0.1.. }}} The commentator notes {{{ This actually illustrates a couple of nice things. First, I really like the message about preprocessing executables. I haven’t said anything about preprocessors in my Cabal metadata file, but Cabal is helping me to realize that perhaps I could have. Or perhaps it’s telling me that it has to do some preprocessing as part of the build, even if I haven’t told it about preprocessors. This is good knowledge to have about the build process }}} Indeed, we could perhaps avoid printing the status message unconditionally, but instead only do it if we're actually going to be doing any work. {{{ Second, I’d like to highlight the line “building interpreter-0.1”. Cabal is actually building a file called dist\build\interp\interp.exe. But it’s not confusing me with that – rather, it’s reminding me of the project name and version I defined in my Cabal metadata file! }}} Perhaps we should make the configure message say the package name, but then for executables and libs say the name of the library or executable.",duncan 3,Cabal-1.8 Release,478,"allow comments on any line, don't require '.' for blank lines",Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-24T07:27:22-0800,2009-12-19T19:18:27-0800,"It confuses people that in `.cabal` files, comments can only appear on lines on their own, and not at the end of other lines. We should consider relaxing this as long as it can be done in a backwards compatible way. The only thing to worry about is command line flags like: {{{ cc-options: --some-flag }}} If we required a space after the `--` that might be sufficient. There are some tools that interpret `--` on its own as an argument, but usually only as a separator between flag arguments and non-flag arguments and we do not expect those to be given in .cabal files. We might like to allow `--` within quotes eg `""--""` however that's also not easy because of the syntax and format of .cabal files. They have no consistent lexical syntax, each field is parsed separately. The overall structure is parsed based on layout without parsing individual fields. In particular .cabal files are not tokenised. The second issue is easier. The original specification required that blank lines within a field include a leading `.` character. This applies to multi-paragraph descriptions. This syntax is totally unnecessary. The parser could cope fine without it. We should accept the convention for backwards compatibility but also allow ordinary blank lines. Multiple blank lines within a field should still be collapsed to one, and trailing blank lines within a field should be trimmed.",duncan 3,Cabal-1.8 Release,546,look for haddock in ghc's bin dir before using findExecutable,Cabal library,1.6.0.2,defect,normal,,new,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 3,Cabal-1.8 Release,553,"wish: Have ""setup configure"" unconditionally pass options like --prefix to user-supplied configure script.",Cabal library,1.6.0.1,enhancement,normal,,new,2009-05-18T12:12:16-0700,2012-01-05T08:33:59-0800,"Cabal's ""setup configure"" can be made to run a user-supplied configure script. When so instructed, it passes command line options like --prefix along to that configure script. However, if no --prefix is given by the user, no --prefix option is passed along to the configure script either. This means that such a configure script cannot actually do anything with the prefix unless it is willing to make assumptions about what the default prefix is when none is specified. It would be better if Cabal passed the configure script a --prefix option (and maybe others) regardless of whether the user specified one, so that the script always has the real prefix available. ",guest 3,Cabal-1.8 Release,663,Setup.hs doesn't look into ~/.cabal/bin for build tools.,Cabal library,HEAD,defect,normal,,new,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 4,Cabal-1.8 Release,421,Cabal shouldn't try to build split-objs when ghc reports it does not support it,Cabal library,HEAD,defect,normal,,new,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 2,Cabal-1.16 Release,943,Synopsis field causes haddock build failure,Cabal library,1.14.0,defect,normal,,new,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-1.16 Release,754,cabal should pass extra lib/include dirs to configure scripts,Cabal library,1.8.0.6,defect,normal,,new,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-1.16 Release,761,could use more options for framework linking on mac,Cabal library,1.8.0.6,enhancement,normal,,new,2010-11-10T13:09:47-0800,2012-03-03T10:17:20-0800,"It seems you can list apple frameworks in a .cabal file like other libs, but I'm not sure how to influence where cabal looks for those frameworks. When trying to link with some in a non-standard place, I wished for an --extra-framework-dirs option. There is a rumoured -framework option, I haven't found much info in --help or online about all this.",simonmic 3,Cabal-1.16 Release,929,cabal test -v3 should output command line used to run test binary,Cabal library,1.10.2.0,enhancement,normal,ttuegel,new,2012-03-12T08:19:41-0700,2012-04-15T23:23:20-0700,"I was trying to debug a `cabal test` issue today and in doing that I needed to understand how cabal invoked the test binary (e.g. a `stdio-exitcode` test suite.) However, passing `-v3` to `cabal test` doesn't cause it to be printed. Proposed fix: Have `cabal test -v3` output all commands being run. Model it after `-v3` for e.g. `build` or `install`.",tibbe 3,Cabal-1.16 Release,930,cabal test is dropping --test-option flags,Cabal library,1.10.2.0,defect,normal,ttuegel,new,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-1.16 Release,936,Add Haddock-Options field to Cabal package description,Cabal specification,1.10.2.0,enhancement,normal,,new,2012-04-01T14:03:25-0700,2012-04-03T14:26:31-0700,"Currently when running 'runhaskell Setup haddock' I can pass options to Haddock with the --haddock-option and --haddock-options option. I would like to add some options in a Cabal description file analogously to the GHC-Options fields and others. ",guest 3,Cabal-1.16 Release,937,cabal-install cannot pass package ids to the build process,Cabal library,1.14.0,defect,normal,,new,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 4,Cabal-1.16 Release,932,Add cabal run,Cabal library,1.10.2.0,enhancement,normal,,new,2012-03-12T10:22:31-0700,2012-03-27T04:18:10-0700,"It would be nice to have a new command, `cabal run`, that builds and runs the executable defined in the package. If there are several executables the user can specify which one to use as `cabal run foo`.",tibbe 4,Cabal-1.16 Release,948,"some way to specify common build-depends for library, executables and test-suites",Cabal library,1.14.0,enhancement,normal,,new,2012-04-27T11:26:28-0700,2012-04-27T12:06:25-0700,"Not sure whether this is a feature request or a bug report. I sometimes have a number of dependencies that are the same for library, executable, and test-suite. The global property 'build-depends' looks like an ideal place to put these, but any dependencies I list there seem to be ignored by cabal.",Oblosys 3,Cabal-1.12 Release,722,Data-Files cabal directive should support directories,Cabal library,,enhancement,normal,,new,2010-08-01T22:39:55-0700,2011-01-30T16:50:37-0800,"It should be possible to use the `Data-Files` directive to include whole directories (recursively) in source distributions. In many cases it's impossible or cumbersome to list all of the files one would like to install, and it seems to me that nobody should have to do that if what they really mean is, ""install everything in that-data-dir/."" In implementation terms, this doesn't strike me as too tricky; after the wildcard parsing that already happens, detect whether the files to be copied are in fact directories and copy them recursively as such. I'm more than willing to hack on this.",cygnus 3,Cabal-1.12 Release,794,Wildcards in data-files don't work with filenames containing multiple dots,Cabal library,1.8.0.2,defect,normal,,new,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-1.12 Release,869,patch to make --enable-executable-dynamic work for TemplateHaskell,Cabal library,HEAD,defect,normal,,new,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 2, Release,791,Large libraries not installable on OS X,Cabal library,1.8.0.6,defect,normal,,new,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 2, Release,916,Verify that HTTP interface is fully/properly implemented,Hackage 2 server,1.8.0.6,task,normal,,new,2012-02-14T09:10:12-0800,2012-02-14T09:10:12-0800,Ensure that server implementation is compliant with interface specified at HackageDB/2.0/URIs,bgamari 2, Release,918,Working documentation builder,Hackage 2 server,1.8.0.6,task,normal,,new,2012-02-19T15:33:40-0800,2012-02-19T15:33:40-0800,"Currently hackage-build is in the repository and can build documentation, but it depends upon a cabal-install patch adding haddock options to the ""install"" sub-command[1], {{{ 18:21 < dcoutts> he sent a patch for cabal-install 18:21 < dcoutts> and this relies on it 18:21 < bgamari> It was merged? 18:21 < dcoutts> the patch should be in the cabal-devel archives, or in the trac 18:22 < dcoutts> bgamari: I've not yet, I was going to see if it could be done nicer / more generically 18:22 < dcoutts> but perhaps I shouldn't bother 18:22 < dcoutts> the difficulty is it affects the ~/.cabal/config format too 18:22 < dcoutts> so it's harder to change later 18:22 < bgamari> ahh 18:23 < bgamari> Yes, I can understand your hesitance in that case }}} [1] http://www.haskell.org/pipermail/cabal-devel/2011-September/007782.html ",bgamari 3, Release,43,"for Hugs executable install, dependencies need to be taken into account for the generated script",Cabal library,,defect,normal,,new,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, Release,46,grep for FIX markings in the source code,Cabal library,,task,normal,,new,2006-01-08T21:49:21-0800,2008-01-18T06:27:33-0800,FIX markings should probably be entered into this system and cross-referenced.,ijones 3, Release,146,cabal should support CPP and haskell string gaps in the same file,Cabal library,1.1.6,defect,normal,,new,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, Release,162,show how often a package has been viewed or downloaded,hackageDB website,HEAD,enhancement,normal,,new,2007-10-09T12:20:07-0700,2008-09-09T03:23:51-0700,"(suggested by Björn Buckwalter) This information would be useful to both users and maintainers. It would be hard to do with the current setup. Downloads aren't intercepted -- they're direct URLs for the tar files. Page views do go through a script, though (but counting them is probably less useful).",ross@… 3, Release,170,pkg-config uses a more general version scheme,Cabal library,1.8.0.6,defect,normal,,new,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 3, Release,183,"Provide ""library-rank"" in hackage",hackageDB website,1.2.2.0,enhancement,normal,,new,2007-11-22T00:57:09-0800,2011-12-01T22:44:19-0800,"Google page rank is assigned to each page depening on (transitive) popularity. Something similar could be used to rank libraries, giving an indication of how central each library is in the haskell community. Google page rank is described in http://en.wikipedia.org/wiki/PageRank -ketil",guest 3, Release,188,Support building Objective-C modules,Cabal library,1.2.2.0,enhancement,normal,,new,2007-12-08T19:40:47-0800,2012-01-05T08:06:23-0800,"GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible.",guest 3, Release,203,Find out what we can learn from ruby gems,miscellaneous,1.2.3.0,task,normal,,new,2008-01-04T16:15:04-0800,2008-12-15T04:16:21-0800,"[http://rubygems.org/ Ruby Gems] is superficially a similar system for Ruby as Cabal + cabal-install + HackageDB is for Haskell. This task is to do some research to compare two systems to find out what lessons we can learn from Ruby Gems. The findings should be recorded on the [wiki:RubyGems] wiki page",duncan 3, Release,207,generate tags files and install them with source files,miscellaneous,HEAD,enhancement,normal,,new,2008-01-13T16:32:58-0800,2010-01-14T13:59:50-0800,"== Introduction == I personally depend on tags because the source code only tells what is really going on. So it would be incredible useful to not only get information using ghci after loading libs but also beeing able to jump to all functions you might be using anywhere (The only solution providing this in all cases is uning tags, right? Because cpp defines can introduce new functions.. To be able to jump to the code source must be installed along with libs (the way you can optionally install haddock docs) == Use case: == setup configure --with-tags --install-source (or something like that) setup build && setup install do this for each dependency given in the .cabal file (VIM:) let tags+=system('ghc-pkg --query-tagfile-location haskell98-1.0.0.0') == Issues: == * Which tool to generate tag files? * ghc(i) when targeting ghc * the hasktags program shipping with ghc * some others? * Tagfile path type relative or absolute? * absolute: After moving/ installing the sources the tagfile must be patched * relative: Do editors take the right base directory to find source files? * When to invoke the tagfile generating program? * Perfect case would be after all preprocessing has been done (Thus the tagging program should understand line number changing comments!) * Template Haskell? ( This is really tricky I think ) * Hmm sorted tagfiles would be useful as well :) == alternatives ? == If you do not think this is useful (mandatory?) how do you lookup code? (Yes I know hoogle :) perhaps using Eclipse or Visual Studio? I'd like to start implementing this somehow the next weeks. So don't hesitate and start discussing Marc Weber",guest 3, Release,214,Package security,miscellaneous,1.2.3.0,task,normal,,new,2008-01-24T07:01:38-0800,2008-05-21T03:15:15-0700,"It'd be nice to avoid getting hacked by a trojaned package. This task is to: * survey the issue * consider the threats * see what solutions other systems use * consider the cost/benefit trade-offs in various security solutions * propose something",duncan 3, Release,222,Hackage should be able to track which version of package is compatible with which version of GHC,hackageDB website,1.2.3.0,enhancement,normal,,new,2008-01-29T07:24:32-0800,2008-02-20T14:39:50-0800,"This is related to ticket #221 and #199. Cabal-install at this time always fetches the highest version of a package. But the highest version may not be compatible with the version of GHC. The example is the HXT package. http://www.fh-wedel.de/~si/HXmlToolbox/ As of this writing, version 7.4 is for GHC 6.8. But for those who have GHC 6.6, version 7.3 should be fetched. If there is a flag in Hackage to indicate this compatibility matrix, then cabal-install can make correct decision which version to fetch based on the GHC version the user has. ",guest 3, Release,236,Installed package config refers to nonexisting haddock interface and html files,Cabal library,1.2.3.0,defect,normal,,new,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, Release,237,Support addition of links to Cabal project pages,hackageDB website,1.2.3.0,enhancement,normal,dons@…,new,2008-02-11T16:58:05-0800,2012-01-05T08:07:48-0800,"Many libraries have documentation online, other than the hackage information. We need a way to tie all the blog and online tutes to the relevant library. Support a way for authenticated users to add links to tutorials, online docs, RSS feeds and other project specific information. Example: ohloh's code metric site: http://www.ohloh.net/projects/6869?p=xmonad allows adding ""Links"" by registered users to the project docs, wikis etc.",dons 3, Release,241,The Make build-type doesn't pass haddock options to make,Cabal library,1.2.3.0,defect,normal,,new,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@… 3, Release,243,Notify maintainers of uploads,hackageDB website,1.2.3.0,enhancement,normal,,new,2008-02-20T08:08:54-0800,2008-02-20T08:14:00-0800,"Ian suggests: one thing we could do is to e-mail the maintainer address (in both the old and new cabal files) when an upload is done, including the username of the uploader and whether the maintainer address has changed.",ross@… 3, Release,259,Release ratings,hackageDB website,1.2.3.0,enhancement,normal,,new,2008-03-12T15:08:13-0700,2010-12-13T07:02:47-0800,"It should be possible to rate package releases on quality of release, to motivate competetive uploaders to focus on quality rather than quantity of uploads.",SamB 3, Release,283,install command doesn't install dist/doc/users-guide/,Cabal library,HEAD,defect,normal,,new,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, Release,286,have alphabetical sorted package list as well as categorized one,hackageDB website,,enhancement,normal,,new,2008-05-30T15:41:31-0700,2008-05-30T15:41:31-0700,"the hackage package list ought to have a link to an alphabetically sorted variant (i often know the package name, but not the likely categories, so i tend to 'search' on that page..). even after hoogle for search, it'd be nice (and probably easy to arrange) to be able to browse both by category and by name. Duncan: The longer term plan is to use hoogle as the primary interface so it can search on package name, package meta-data and of course the content, api and docs. ",guest 3, Release,287,"make better use of existing build/failure reports (provide stats, alert authors)",hackageDB website,1.2.3.0,enhancement,normal,,new,2008-05-30T15:51:42-0700,2012-01-05T07:56:39-0800,"the hackage package list ought to list successful and failed builds (simply a list of compiler versions, each one green or red, depending on success, with direct link to build/failure log; this would fit into the one-line-per-package format) for each entry, and report them to package authors/maintainers (either via direct email or via a daily summary report on a list which all maintainers are subscribed to). build failures currently seem to be created automatically where package authors may not notice them? at least, that would explain things like (just examples of things i happened to have looked at, no offence intended;-) - hint: advertised to work with ghc 6.8.x on the same package page that lists a build failure for ghc-6.8 - haskell-src-exts: lists a build failure for ghc-6.8 the first is probably a too optimistic cabal version spec, the second is a haddock issue. but that makes two out of two for package i looked up recently.. provide cross-package index of builds/failures, so that one might see trends (cabal issues, base package issues, bytestring issues, next big thing issues,..) and statistics(how many hackage packages fail/build, which compiler/cabal/haddock versions are successful for the largest number of packages, etc.)? at the moment, i fully expect this to reflect just as many infrastructure issues as package issues, but that only makes it more important (it is hard to blame package authors if the infrastructure and dependencies keep changing under their feet, or if the tools keep them from providing failure-free packages). Ross provided these rough figures: .. here are some rough figures on failures (for the latest version of each package): 7 configure: prerequisite packages missing or not built 22 configure: other (usually a custom Setup.hs) 6 build: header file for some C library not found on the build system 46 build: a package dependency was not listed (often a base split issue) 14 build: a module was omitted from the package 38 build: other 22 haddock failure 4 install failure It is surprising how many would surely have failed on the maintainer's machine if they had been tested. Duncan points out: It's harder than it looks. The build results from the server builds itself are not very accurate reflections of the real status. That's partly why we do not yet attempt to email maintainers about the results. For example the fact that the build server does not have most C libs installed means that lots of FFI binding packages and all their dependents fail. It also suffers from the diamond dep problem. Also it only reflects one particular operating system and configuration of each package. The plan is to get build results from users. Though then we have to do some statistical analysis to discover if a package works with various versions of compilers and on different OSs etc. http://hackage.haskell.org/trac/hackage/ticket/184 ",guest 3, Release,293,allow installation of non-haskell or haskell script executables,Cabal library,1.2.3.0,enhancement,normal,,new,2008-06-12T06:44:49-0700,2012-01-05T08:03:36-0800,"Sometimes it is desirable to include an auxiliary executable, which is not written in haskell or is written in haskell, but better not be compiled and run as a script instead. Currently cabal doesn't offer any way to install such executables into $bindir. I suggest adding an {{{extra-bin-files}}} property that should be treated similar to {{{data-files}}}, but install into $bindir and take care of correct permissions. The way through the hooks is unsatisfactory, because the hooks allow no way of telling cabal what they have done. This is going to be a problem, when cabal starts tracking all the installed files for uninstall purposes. See also [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9227]",Misha Aizatulin 3, Release,298,Local build logs,cabal-install tool,HEAD,enhancement,normal,,new,2008-06-19T10:47:11-0700,2008-06-19T16:34:24-0700,"As a user of cabal-install, I would like build logs which are organized slightly differently than the logs which are to be used for reporting back to hackage. In particular: * The local build log should have accurate timestamps; for anonymity purposes the reporting logs should not have timestamps. * The local build log should not partition logs per-server. * The local build log should also track things installed from source using cabal-install which may have been obtained somewhere other than a hackage server. Since the different types of logs have different purposes, it makes sense to add separate local logging capabilities (thus duplicating some information) rather than trying to shoehorn both purposes into the same log format. A simple way to start would be to copy Hackage/Reporting.hs to Hackage/Logging.hs and tweak. Later, things could be refactored to pull out common code.",guest 3, Release,299,Add changelog feature to hackagedb,hackageDB website,HEAD,enhancement,normal,,new,2008-06-19T11:50:19-0700,2011-12-01T22:46:29-0800,"It would be great if releases on hackagedb were required (or even permitted) to include short descriptions of the changes made since the last release. Currently there is no easy way to get this information for most packages, since many packages have no home page other than their hackagedb page. ",guest 3, Release,303,cabal clean: Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty),Cabal library,1.4.0.1,defect,normal,,new,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, Release,310,Install with multiple compilers,Cabal library,1.2.3.0,enhancement,normal,,new,2008-07-08T22:20:05-0700,2009-01-20T04:09:55-0800,"It would be nice to be able to install a package with multiple compilers in one pass. For example, with the current Setup.[l]hs interface, {{{runhaskell Setup.hs configure --ghc --hugs --jhc}}} should configure for all three compilers, and then the build and install steps should perform the steps for all three as well.",guest 3, Release,319,Warn if the source file for a module is ambigious.,Cabal library,HEAD,enhancement,normal,,new,2008-08-05T12:22:07-0700,2008-08-05T12:22:07-0700,"For example if we are looking for a module `Foo` and there are files `Foo.hs` and `Foo.y` then we should use `Foo.y` as we do now, but we should warn about the presence of `Foo.hs` (and note the fact that we're ignoring it). Similarly if we find `Foo.x` and `Foo.y` then we should warn about the one we're not using. Or arguably that should be a straight error. There's an obvious order relation between `Foo.hs` and `Foo.y` but not between `Foo.x` and `Foo.y`.",duncan 3, Release,324,Deprecate package-url field,Cabal library,1.2.3.0,enhancement,normal,,new,2008-08-15T08:52:00-0700,2012-01-05T08:04:34-0800,"The package-url field was originally supposed to be to tell users where exactly they could find the .tar.gz package for this version of the package. That was from a time before hackage and so now it is redundant because hackage provides the package url. The field is generally unused and when it is used it often just links to the darcs repo or home page. We should deprecate it and suggest people use the homepage url and the new way of specifying a source control repo (see #58).",duncan 3, Release,325,SHGetFolderPath requiered to configure cabal on windows,Cabal library,1.2.3.0,defect,normal,,new,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, Release,326,Cabal should support Cabal-version-dependent Setup.hs,Cabal library,1.2.3.0,enhancement,normal,,new,2008-08-16T13:22:49-0700,2012-01-05T08:07:02-0800,"The manual says about non-standard `Setup.hs`: ""good luck"". But there are packages that need non-standard `Setup.hs`, often just very small ones. And all of them risk breakage when Cabal changes. The first issue is to specify the dependency on a particular Cabal version (#284). The next issue is that package authors often know how to write their `Setup.hs` for different versions of Cabal, but have to pick one or the other. It would be better to have `Setup.hs` code adapt to as many Cabal versions as possible. Since version mismatch leads to compile errors, that seems to imply either - separate sources (`Setup-v1.4.hs`, `Setup-v1.5.hs`, etc.) - one source, with CPP (#if Cabal==1.4 ..) If I read [http://www.haskell.org/pipermail/cabal-devel/2008-August/003576.html Add auto-generated CPP macros for package version testing] correctly, that almost provides package version info via CPP. It would only need to provide precise versions instead of lower bounds, and for the Cabal package.",claus 3, Release,330,"Support general documentation, not just haddock",Cabal library,1.2.3.0,enhancement,normal,,new,2008-08-20T09:31:28-0700,2010-05-03T05:44:42-0700,"The generation and installation of Non-Haddock documentation (README and INSTALL files, LaTeX and Docbook tutorials/guides, Haskell examples using the package in question) is not currently taken in account by Cabal. Making Cabal understand how to generate documentation for all those formats would probably be too ambitious, but it could be eased (e.g. letting the user provide Makefiles instead of creating custom hooks). More importantly, the installation of documentation would be much easier with a new package property such as ""doc-files"" (""data-files"" nor ""extra-source-files"" are semantically suitable).",fons 3, Release,331,pkg-config error messages could be better,Cabal library,1.4.0.1,defect,normal,,new,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, Release,341,Add a flag to turn warnings into errors,Cabal library,1.2.3.0,enhancement,normal,,new,2008-08-25T04:04:57-0700,2008-08-25T04:46:47-0700,"I would like to be able to turn warnings into errors, so e.g. when Cabal says {{{ Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. }}} the build will fail. Adding a -Werror flag to the various cabal commands is probably the best way to implement this. ",igloo 3, Release,345,Build Tree Proposal,Cabal library,1.4.0.1,enhancement,normal,,new,2008-08-26T20:58:26-0700,2008-08-26T20:58:26-0700,"I've noticed a few issues with cabal for which I have a proposed solution. 1. Currently, if you have two different executables that use the same build options and mostly the same source, the .o files that they share are compiled twice and stored in separate locations, costing both CPU time and disk space. It would be preferable never to compile a .o file more than once with the same set of options. 2. It's handy, when using runhaskell and ghci in your source tree, to be able to freely run either on any source file and have them use any compiled binaries that are available. With the current way Cabal builds things, except in simple projects with only one target, there is no single directory that contains all of the compiled files. Instead there is a separate directory for each target that contains only the files necessary to build that particular target. This leaves no optimal choice for the -hidir and -odir options of runhaskell and ghci. 3. It's not uncommon to build several different executables from the same set of source files with the same build options. Currently the specificiation for this is verbose and repetitive, since all options must be repeated for every executable. A possible change that would help to mitigate all three of these problems, while being fully backward compatable, would be to introduce the concept of a ""build tree""; a single build directory that would contain all of the object files built from a given source tree. This would be specified in the cabal file in the same way that an executable or a library is specified, and would make use of the same hs-source-dirs, extensions, build-depends and similar options. However, within a build section it would be possible also to specify that specific libraries and/or executables be built from that build tree. These subsections would use main-is, exposed-modules and similar options that are currently used by top-level executable and library declarations. Note that this would require, for GHC builds at least, #179 to be implemented, and it would appear to provide the feature requested in #276. ",cjs 3, Release,346,Add a warning for synopsis being a prefix of the description,Cabal library,HEAD,defect,normal,,new,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, Release,350,cabal should check for duplicate module names,Cabal library,1.2.3.0,enhancement,normal,,new,2008-09-11T17:04:17-0700,2012-01-05T08:04:24-0800,"If I write a list like: {{{other-modules: Foo.Bar.Quux, Foo.Bar.Blat, Foo.Bar.Quux}}} in my {{{.cabal}}} file, {{{setup configure}}} will happily accept it. But then when I build, GHC will give me an error message like: {{{ : module `blat:Foo.Bar.Quux' is defined in multiple files: Foo/Bar/Quux.hs Foo/Bar/Quux.hs }}} which is very confusing! Can Cabal check for duplicates in the exposed-modules and other-modules lists? -Tim",guest 3, Release,364,cabal should allow source to be installed with/added to binary packages,Cabal library,1.2.3.0,enhancement,normal,,new,2008-09-29T06:33:52-0700,2008-09-29T06:33:52-0700,"We have the odd situation that package sources are used for `configure`/`build`/`haddock`/`install`/.., but aren't actually managed by cabal. This makes rebuilds (eg,with different options, or for another compiler version) or reinstalls (eg, with added or modified haddocks) somewhat chancey. Unless you keep your sources in a safe place, and remember where that was, you have to start by getting the sources again. (I assume that `cabal-install` has a cache of package source tarballs somewhere, but that doesn't account for modified-before-build-and-install package sources, right?) This is also an issue for source code analysis tools, if binary versions of imported packages aren't sufficient for processing the importing source. Haddock currently works around that by (a) being integrated with cabal and (b) generating its own interface files for installed packages (`*.haddock`); but we cannot expect all tools to be integrated with cabal. If tools and users could get programatic access to the sources that were used to install a package, they could refer to those for further processing. It is slightly ridiculous that the sources may be available in html-ized form (if haddock was used with appropriate options) but not in source form. See also: http://hackage.haskell.org/trac/ghc/ticket/2630",claus 3, Release,367,merge cabal home page and hackage intro page,miscellaneous,,task,normal,,new,2008-10-08T10:40:23-0700,2008-10-08T10:40:23-0700,"Currently nobody finds the cabal user guide or the other useful info on the cabal home page. The links on how to install and create cabal packages should be moved to the hackage info page. Generally there are too many places to find mostly the same information. We've got the hackage pages, the hackage wiki and the cabal web site.",duncan 3, Release,384,suggest use of --user if configure fails with missing deps that are in the user db,Cabal library,HEAD,enhancement,normal,,new,2008-10-29T11:30:15-0700,2008-10-29T11:30:15-0700,"The fact that `runghc Setup configure` and `cabal configure` are different confuses people. The former does a `--global` install by default while the latter does `--user` installs by default. This crops up when people install something via `cabal-install` and then configure another package using `runghc Setup` and are confused when the dependency they just installed is apparently missing. One solution would be that when configure finds that there are missing dependencies, it could check them in the per-user package database and if they are found to suggest that the user might have intended to do a per-user install. Mentioning the constraint that global packages can only depend on other global packages probably would not go amiss either.",duncan 3, Release,386,Cabal changelog is not in user's guide,User guide,HEAD,defect,normal,,new,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 3, Release,388,Add a warning for unknown modules that were compiled,Cabal library,,enhancement,normal,,new,2008-11-01T08:47:21-0700,2008-11-01T09:30:43-0700,"Let's say you are working on a new version of a library; you add a new internal (i.e. non-exposed) module but you forget to update the package description. You locally test your changes, everything works fine so you install it. Now, since the new module is not listed in {{{other-modules}}} it will not be included in the final library. Therefore, when you try to use it you get rather cryptic linker errors. It can take a while until you realize where the problem is coming from. The proposal is to look, during build, for compiled modules under the {{{dist}}} directory that are not included in the final library and warn the user about their presence.",jcpetruzza 3, Release,402,what the heck is goinjg on here,cabal-install tool,1.2.3.0,enhancement,normal,dschoepe,assigned,2008-11-11T07:33:34-0800,2012-07-23T04:19:03-0700,"The hoogle package is very useful to search the standard library. Unfortunately, it does not search packages that you have installed which are not part of the stdlib. It would be great if every package installed always had its haddock generated, and from its .txt file a .hoo file was generated (e.g: hoogle --convert), and then all .hoo files sat in some centralized directory which hoogle would then use for its searches. This would be great documentation, and let you hoogle for anything that you can import. ",Peaker 3, Release,422,Cabal should warn if using a version of ghc that is newer than Cabal knows about,Cabal library,HEAD,defect,normal,,new,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, Release,426,".cabal files should be stored next to tarballs, potentially overriding in-tarball version",Hackage 2 server,1.6.0.1,enhancement,normal,,new,2008-12-05T03:16:51-0800,2012-03-06T02:22:48-0800,"`.cabal` files are *the* description of cabal packages, yet cabal/hackage hide them inside the package tarballs. For easy access, I would like the local package cache to store a copy of the `.cabal` file right next to the tarball. Changes in the out-of-package `.cabal` should override the original, in-package `.cabal`, allowing bug-fixing/adaptation to local packaging issues.",claus 3, Release,431,Distribution.Make requires to use sudo and --global,Cabal library,1.6.0.1,defect,normal,,new,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 3, Release,451,dependency not listed on the hackageDB page,hackageDB website,1.2.3.0,enhancement,normal,,new,2009-01-11T12:38:02-0800,2009-03-17T14:50:46-0700,"The haskeline-0.6 package uses the terminfo package by default on POSIX systems. However, the hackageDB page for haskeline does not list terminfo as a possible dependency: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline-0.6 -Judah",guest 3, Release,459,Find out what we can learn from SCons,miscellaneous,1.2.3.0,task,normal,,new,2009-01-16T10:59:56-0800,2010-08-21T14:18:39-0700,"[http://www.scons.org/ SCons] is a build system for various languages. This task is to do some research to compare SCons to the build component in Cabal and find out what lessons we can learn from SCons. The findings should be recorded on the [wiki:SCons] wiki page.",duncan 3, Release,469,Support relocatable packages,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-20T06:33:50-0800,2012-01-05T08:05:02-0800,"This is both useful and doable on both Windows and Unix systems. We already have limited support for relocatable (also sometimes called prefix-independent) packages on Windows. Specifically, a relocatable package is often what people want when they want to prepare a package for redistribution, especially on Windows for use with an installer. What is required is that an exe and all supporting files (data files and potentially also other shared libs) exist together in one directory hierarchy and that that directory can be placed anywhere in the filesystem and the exe will still be able to find all its associated support files. There are some restrictions on preparing a relocatable package. In particular the user must configure it such that all install directories for the various kinds of files (libdir, datadir etc) are relative to the `$prefix`. Configuring a relocatable package should be something that is done explicitly. At the moment it is done simply by configuring it in the right way, but Cabal is never aware that the user is trying to construct a relocatable package. If it is explicit then we can take different actions if necessary (as it is on unix) and do additional checks. So a configure option `--relocatable` or something should be used. Installing a relocatable package is somewhat of an exception because it involves using a prefix which would otherwise be empty. Creating an image for a relocatable package would use a empty `$prefix`. The tricky issues that have to be addressed are: * data files for the program itself * data files in library dependencies * shared libraries The mechanism for finding data files at runtime is the `Paths_pkgname` module that Cabal generates. On Windows this can make use of the Win32 api that lets a .exe program discover where it was run from. On unix there is no reliable equivalent but the next best alternative is to use wrapper scripts to set environment variables before running the real program. This mechanism can work pretty well for data files that belong to the executable. It is rather harder for data files in dependent packages (see #466). One option would be to copy the data files belonging to dependent packages and install them along with the executable (checking for clashes). This would involve being able to locate the data files of installed libraries which would require extending the data stored for installed packages. Libraries that require data files are relatively rare (though this should be checked) so this feature could be punted for an initial version. In future there will also be the issue of shared libraries to consider. That is, when Haskell implementations can produce Haskell libs as shared libraries. This complicates the construction of relocatable packages. Again the approach taken on Windows and Unix will have to be different. On Windows it will be possible to copy the .dll files into the same directory as the .exe file (or a subdir if using .manifest files). On Unix a wrapper script using `LD_LIBRARY_PATH` will probably be necessary.",duncan 3, Release,479,Enforce build-type Simple,Cabal library,1.6.0.1,enhancement,normal,,new,2009-01-25T10:23:31-0800,2009-01-26T05:15:13-0800,"When a package claims to have ""build-type Simple"", it would be good to enforce that the Setup program actually does what it should. The simplest way to do this would be to enforce that everything after the shabang line exactly match (modulo line-end conventions?) a standard script. (One each for Setup.hs and Setup.lhs.)",SamB 3, Release,482,survey ./configure scripts in hackage packages,miscellaneous,,task,normal,,new,2009-02-01T09:10:03-0800,2009-02-01T09:10:03-0800,"Many packages use `./configure` scripts which make them hard to use on Windows as it requires MSYS. Ideally packages could do these custom checks in `Setup.hs` scripts or very common checks might be possible in the Simple build system itself. This task is to do a survey of the packages on hackage that use `./configure` scripts and identify the most common checks that they are doing. Specifically we would like to know what number of `./configure` scripts could be eliminated by implementing various features in Cabal (either to do the checks directly or to make it easier to do the checks in per-package `Setup.hs` scripts).",duncan 3, Release,483,separate preferred versions into hacks and real preferred versions,hackageDB website,1.6.0.1,enhancement,normal,,new,2009-02-01T15:24:18-0800,2009-02-01T15:24:18-0800,"We have the ""preferred-versions"" file in the hackage index. This is used by cabal-install. It has a dual purpose which we should try to separate. The first is for things like ""base < 4"", to make up for the fact that so many older packages do not specify a version of base. This is basically a hack. It's not that we really would prefer people to use base 3. On the other hand it is useful to be able to put experimental versions of packages on hackage and not have them be the default version. For example HaXml still declares that 1.13.x is the stable version with 1.19.x the current development version. In the latter case the default (unversioned) package package should point to the preferred version (ie 1.13.x). So it would be useful to separate the hacks from the real preferred versions. The cabal-install tool might treat the two slightly differently and the hackage db website should only consider the latter.",duncan 3, Release,498,package downloads confuse IE6 and webkit-gtk browsers,hackageDB website,,defect,normal,,new,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 3, Release,499,develop tool to analyse package dependency splits,miscellaneous,,enhancement,normal,,new,2009-02-14T10:33:08-0800,2009-02-14T11:05:38-0800,"Looking at packages on hackage as a whole we often see cases where different packages require mutually incompatible versions of some dependency. The most notable cases at the present time are parsec 2 vs 3, HaXml 1.13 vs 1.19, HTTP 3000 vs 4000 etc. What we want to know is, which dependencies are the divisive ones. In such cases is there a clear winner? Which are the most divisive packages? A divisive package is one where looking at the packages that depend on it, the intersection of versions constraints is empty. That is we cannot configure all the other packages on hackage without them disagreeing about the devisive package. When we say all, we really only mean the latest recommended version of each package, not all versions of all packages. Looking at the packages depending on a divisive package we may see a clear consensus that can resolve the issue if we ignore the minority. Frist we must discover the 'camps', that is the sets of packages that can agree on versions of the dependency. For example it might be simply two camps, `pkg < 3` vs `pkg >= 3`. Then for each camp we score it based on the importance of the packages in that camp. The importance of packages is calculated separately (based on downloads and importance of dependents). The camp with the biggest score wins. Some packages are more divisive than others. A package is more divisive if the the loosing camps are still quite important. That corresponds to excluding many packages from the maximal consistent package set. It would be useful to make a ranking of the most divisive packages because these correspond to cross-package problems that need resolution in a more coordinated fashion and their impact is bigger. It would also be useful to track trends in the balance of the camps for divisive packages. It may be that such splits can be naturally resolved. If there is a clear trend then we can simply make that the de-facto recommendation. Imagine a summary page on hackage for platform managers to see what the most divisive packages are and the trends for each one. It would help them and maintainers to make decisions on recommendations for dependencies.",duncan 3, Release,500,develop a tool to find the maximal consistent set of hackage packages,miscellaneous,,enhancement,normal,,new,2009-02-14T10:34:45-0800,2009-02-15T03:35:03-0800,"To a great extent the point of libraries is code re-use. It follows that is it useful to be able to install and use two packages simultaneously. The extension of this is that we would like to know the maximal set of packages that we can install consistently. Them being consistent implies that we can use any of them in another package and have consistent dependencies. If we knew a package was within the maximal subset then we can give it a positive mark on hackage. We may also be able to encourage package authors to update their dependencies to as to get their packages within this set. Calculating the maximal consistent subset is certainly an NP-complete problem. It is at least as hard as working out if any single package is installable and that is already NP-complete. However we do not necessarily have to get an exact maximal set, approximation would probably do. We would also like to influence the choice of the set by the importance of packages, especially when it comes to resolving choices about divisive packages (see #499). We would also like to influence the choices by manually supplied preferences. This can probably be implemented as an extension of the standard package dependency resolution algorithm and using the code developed for ticket #499.",duncan 3, Release,504,executables with a C main function,Cabal library,1.6.0.1,enhancement,normal,dankna,assigned,2009-02-22T09:09:12-0800,2012-01-05T08:33:54-0800,"We would like to be able to do: {{{ executable blah main-is: main.c }}} Either for pure C programs or mixed C/Haskell programs with main in the C code rather than Haskell code. == Workaround == Until this is implemented one can use a main in Haskell that calls out to the C main function. For example: `main.c` {{{ int real_main () { return 42; } }}} `Main.hs` {{{ import System.Exit import Foreign.C main = real_main >>= exitWith . ExitFailure . fromIntegral foreign import ccall ""real_main"" real_main :: IO CInt }}} `c-main.cabal` {{{ name: c-main version: 0.0 build-type: Simple cabal-version: >= 1.2 extra-source-files: main.h executable c-main main-is: Main.hs c-sources: main.c includes: main.h extensions: ForeignFunctionInterface build-depends: base }}} == Implementation notes == At the moment Cabal's ""Simple"" build system requires `main-is` to specify a `.hs` or `.lhs` file (though it does allow that to be generated by a pre-processor). If we lift that restriction the first thing to go wrong will be that `ghc --make` does not work with `-no-hs-main`. We will have to do the build and link steps separately (which is probably a good thing anyway). We would use `ghc --make` to compile all Haskell modules to `.o` files and then invoke `ghc` in batch mode passing it all the `.o` files (from Haskell and C modules) and `-package` flags. If we're using a C main then we'd do the link step with `-no-hs-main`.",duncan 3, Release,508,user guide should document new fields with the version of Cabal they appeared in,User guide,,enhancement,normal,,new,2009-02-25T05:15:40-0800,2012-01-05T08:33:47-0800,"It would be nice if the user guide specified in which Cabal version a field was first introduced. This would help package authors work out compatibility. With this documented we should also check that `cabal check` gives the same advice. That is if a package uses a field that is new in version 1.2 say, that `cabal check` warns if the `cabal-version: >=x.y` number is not high enough. It should only be a warning not an error because older Cabal versions only warn about unknown fields. While we're at it, we should document in the user guide that unknown fields give a warning, but should not cause a parse error. This lets people use new non-essential informational fields without having to absolutely require a later Cabal version. Probably a section on version compatibility is wanted.",duncan 3, Release,514,Detect and warn about documentation with broken links.,hackageDB website,,enhancement,normal,,new,2009-03-02T08:31:13-0800,2009-03-11T04:43:18-0700,"There are numerous broken links in the haddock documentation on hackage. Some of these are the result of syntactic mistakes in the markup (eg forgetting to escape quotation marks) and some are just plain stale links. We should have a mechanism to check for such problems and report them to the package author. This would probably involve parsing the html files to look for links. Detecting broken links that are internal to the docs for a single package is not too hard. Broken cross-package links is a bit harder. Detecting stale external links would need to make http GET requests.",duncan 3, Release,519,.cpphs files are processed using GHC's built-in CPP instead of cpphs,Cabal library,1.6.0.2,enhancement,normal,,new,2009-03-07T08:24:16-0800,2012-01-05T08:33:31-0800,"Currently, if you need to use `cpphs`, the only way of going about it is to define a custom `PreProcessor` in your `Setup.hs` and using it as an override in `hookedPreProcessors`. A seemingly sensible way of making this easier would be that `.cpphs` files prefer being processed by `cpphs` instead of GHC's built-in CPP. (Most people probably just use `{-# LANGUAGE CPP #-}` in a `.hs` for the latter anyway.)",Deewiant 3, Release,521,Check that module names match file names case-sensitively on Windows,Cabal library,1.6.0.1,defect,normal,,new,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, Release,526,hugs-options aren't passed to ffihugs,Cabal library,1.6.0.1,defect,normal,,new,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, Release,527,CPP not called before ffihugs,Cabal library,1.6.0.1,defect,normal,,new,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, Release,530,configuration features,Cabal library,1.6.0.1,enhancement,normal,,new,2009-03-22T06:25:32-0700,2009-03-22T06:25:32-0700,"Currently Cabal has support for ''configuration flags''. This is a nice feature, but quite limited. It can only take a boolean value, and the flag must be manually set during ''Setup.hs configure''. Here I propose a more powerfull feature, that it is yet easy to use (and, hopefully, easy to implement). The idea is to add support for ''configuration features''. A configuration feature is similar to a ''configuration flag'', but with some important differences. == Example == {{{ data Feature = Bool | String }}} A feature block: {{{ Feature HAVE_URANDOM action: execute include-dirs: ... c-sources: features/urandom.c -- other possible properties, as listed in -- ""Build information chapter"", excluding `buildable` and -- `other-modules` -- The `action` property can have values `compile` (default) -- or `execute` }}} This means that I'm testing for a feature named ''HAVE_URANDOM'', and the testing requires to compile/build and then execute some code. == Rules == 1. If compilation fails, ''HAVE_URANDOM'' will have value ''Feature False''. If ''action'' property is ''compile'', then a successful compilation will result in ''HAVE_URANDOM'' having a value of ''Feature True''. 2. If ''action'' property is ''execute'' and the executable returns a value /= 1, then ''HAVE_URANDOM'' will have value ''Feature False''. 3. If ''action'' property is ''execute'' and executable write something on stdout, then ''HAVE_URANDOM'' will have value ''Feature string''. 4. Otherwise ''HAVE_URANDOM'' will have value ''Feature True''. This provides a small but useful subset of what can be obtained using ''autoconf'', with the advantages that it is much more declarative, integrated with Cabal and portable.",guest 3, Release,535,Mac OS X 10.4 can't locate gmp,Cabal library,1.6.0.1,defect,normal,,new,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 3, Release,543,ghc global package db should live in /var not /usr,Cabal library,1.6.0.1,defect,normal,,new,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, Release,548,Aid in function lookup in IDEs,miscellaneous,1.6.0.1,enhancement,normal,,new,2009-04-23T06:38:41-0700,2009-04-25T07:49:16-0700,"Currently haskellmode builds an index of functions based on the docs installed on a system. This means a user has to install all docs for all packages. HackageDB builds docs for all modules on the site, so it seems silly that I need to install the docs myself. It would be cool, and probably useful for IDEs if a file was available from HackageDB that contained enough information to build that index, and point to docs on HackageDB. Then people with limited disk space, who are on always-online machines, can enjoy easy function lookup. Even cooler would be if there was a web API (e.g. XML-RPC server) available that could be used to do the function lookups. For instance passing a function name would return a list of pairs of module name and URL.",guest 3, Release,557,Spec does not define the installed package info fields,Cabal specification,,defect,normal,,new,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 3, Release,558,Spec needs updating for hc-pkg,Cabal specification,,enhancement,normal,,new,2009-05-31T15:42:12-0700,2009-05-31T15:43:08-0700,"Section 3.3 describes the hc-pkg tool: http://haskell.org/cabal/proposal/x272.html#AEN351 It leaves these questions unanswered: {{{ Note: Can we give the --user flag to hide, expose, describe? Can we register a package that is already registered? What if it's registered as a global package and we register it as a user package? }}} It makes this suggestion which has never been implemented: {{{ Note: Some of these commands (unregister, hide, and describe) make sense for package IDs which offer a range, such as ""hc-pkg unregister hunit<2.3"". }}} Also, we should standardise `hc-pkg dump` and the format it produces. It's the only sensible way for tools to get that info. Otherwise they must call `hc-pkg describe` 100's of times which is unreasonably slow. There is no method to construct a new package database. There is nothing specified to allow for specific package databases. Should we standardise ghc-pkg's `--force` or `--force-files`? It may also be useful to allow a package to be registered or checked against a virtual root, eg when the files are not yet installed. There is no specification on the meaning of stacks of package databases, ie how do we interpret package collections when we merge several. Current semantics is a bit odd when user packages shadow global packages. Partly this is standardising existing practice and partly it's asking for extensions. If we accept the relative paths extension that that must be documented too along with a way to find the global and user package dbs.",duncan 3, Release,560,Cabal haddock should allow generating Hoogle and HTML simultaneously,Cabal library,1.6.0.1,enhancement,normal,,new,2009-06-03T00:39:27-0700,2009-06-03T00:39:27-0700,"Currently, the --hoogle flag turns off html generation. However, Haddock appears to have no problem with generating both simultaneously, which would save some work.",guest 3, Release,566,Don't try and resolve dependencies for packages that are not buildable,Cabal library,1.6.0.1,defect,normal,,new,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, Release,567,"Allow negation of language extension names by adding/removing ""No"" in front",Cabal library,1.6.0.1,enhancement,normal,,new,2009-07-06T14:06:15-0700,2009-07-06T15:24:57-0700,"GHC supports this, and it could be useful when features are added or removed from the baseline Haskell -- say, record syntax?",SamB 3, Release,575,Cabal configure leaves behind temporary files on Windows,Cabal library,1.6.0.2,defect,normal,,new,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, Release,577,an executable and library differing in capitalization use the same build dir on case-insensitive filesystems,Cabal library,1.6.0.1,defect,normal,,new,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 3, Release,583,create application bundles on demand,Cabal library,,enhancement,normal,dankna,assigned,2009-09-11T09:03:31-0700,2011-05-31T07:03:56-0700,"Currently, getting graphical applications to work on MacOS X involves a bit of manual steps after ""cabal install"", particularly if the applications happen to be command line oriented at the same time (ie. a GUI that supports being called from the command line). The blog post below offers a solution which seems to work for wxHaskell (Setup.hs files also attached). Perhaps it can be generalised somehow so that users can just tell Cabal they want an application bundle? Duncan requested Apple docs on application bundles. I haven't read it yet, but maybe this will help? * Blog post: http://koweycode.blogspot.com/2009/09/cabal-installing-graphical-apps-on.html * Bundle Programming Guide: http://developer.apple.com/mac/library/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html ",kowey 3, Release,584,adding arbitrary .o files to the static archive,Cabal library,1.6.0.1,enhancement,normal,,new,2009-09-15T14:22:40-0700,2009-09-15T14:22:40-0700,"Cabal's Simple build system does not currently provide any mechanism for adding arbitrary .o files into the static archive and similarly no way to link one static archive with another. The only builtin mechanism is to compile C code (specified by the ""c-sources"" field) and that gets included into the same static archive as the Haskell library. I would like to request this feature. Here is a more detailed description: Adding an extra-libraries field to a cabal source package description: {{{ Name: LibraryFoo ... Library Extra-libraries: Bar }}} has the effect that when loading package LibraryFoo in ghci, ghci will necessarily try to open a corresponding Bar.so/.dll/.dylib file: {{{ > ghci -package LibraryFoo Loading package LibraryFoo-0.1 ... : can't load .so/.DLL for: Bar (dlopen(Bar.dylib, 10): image not found) }}} What I want to do is statically link LibraryFoo against Bar before Cabal installs the package, (so that, for instance, I can run ghci without a bunch of command line linking arguments and don't need to have Bar around anymore), and I have a Bar.o file for just such a purpose. ",wisnesky 3, Release,586,missing other-modules breaks --hyperlink-with-source,Cabal library,,enhancement,normal,,new,2009-09-16T08:08:15-0700,2010-04-08T14:35:16-0700,"""cabal haddock --executables"" produces documentation for all modules Main depends on. ""cabal haddock --executables --hyperlink-with-source"" only generates source for main (but links to the dependent modules, which results in broken links.) Cabal 1.6.0.3, cabal-install 0.6.2 ghc 6.10.3 ubuntu 9.04",bastl 3, Release,587,Get all of Hackage indexed by Google Code Search,hackageDB website,1.6.0.1,enhancement,normal,,new,2009-09-17T04:30:17-0700,2012-01-05T08:08:50-0800,"Google Code Search is a really nice (and fast!) way of browsing lots of code online. It would be cool if the whole of Hackage would be searchable from Code Search. One useful thing is to be able to find all mentions of a function in all packages on Hackage. Another good thing is to be able to find examples of how other people use libraries (i.e. use Code Search as a learning tool). What we need to make this work is to host and XML file (that we could regenerate N times daily) in a public location (e.g. http://hackage.haskell.org/sitemap.xml). Instructions on how to set it up: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=75224 ",tibbe 3, Release,592,cabal test does not detect that cabal build needs to be re-run,Cabal library,1.6.0.1,defect,normal,ttuegel,assigned,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, Release,603,--with-PROG=prog option unclear in --help,Cabal library,1.6.0.1,defect,normal,,new,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 3, Release,604,a feature to explicitly allow multiple versions of a single dependency,Cabal library,1.6.0.1,enhancement,normal,,new,2009-11-11T11:40:34-0800,2009-11-11T11:40:34-0800,"I wanted to build two executables for comparing the performance difference between happstack-server-0.3.4 and happstack-server-0.4. So I wrote below cabal file but found that cabal cannot build what I want. Here is the output for ""cabal configure"": {{{ aycan@fgt:~/haskell/tests/happstack-tests$ cabal configure Resolving dependencies... Configuring happstack-tests-0.1... cabal: At least the following dependencies are missing: happstack-server ==0.4 && ==0.3.4 }}} {{{ Name: happstack-tests Version: 0.1 Author: Aycan iRiCAN Stability: Experimental Category: Web Synopsis: Tests for Happstack Packages Cabal-version: >= 1.6 Build-Type: Simple Flag base4 Description: Choose the even newer, even smaller, split-up base package. Executable hello-0.3.3 Main-Is: Hello.hs Hs-source-dirs: happstack-server GHC-options: -threaded -Wall -Wwarn -O2 -fwarn-tabs -fwarn-unused-imports Build-depends: base , happstack-server == 0.3.4 Executable hello-0.4 Main-Is: Hello.hs Hs-source-dirs: happstack-server GHC-options: -threaded -Wall -Wwarn -O2 -fwarn-tabs -fwarn-unused-imports Build-depends: base , happstack-server == 0.4 }}}",guest 3, Release,606,deprecate old-style .cabal files,Cabal library,1.6.0.1,enhancement,normal,,new,2009-11-14T07:52:41-0800,2009-11-14T07:52:41-0800,We should consider deprecating old pre-Cabal-1.2 syntax .cabal files. The way to go is to prevent new ones being uploaded on Hackage.,duncan 3, Release,607,Hackage bitrot watch page,hackageDB website,1.6.0.1,enhancement,normal,,new,2009-11-14T08:45:56-0800,2009-11-14T08:45:56-0800,"It should be possible to make a report of packages that are bitrotted or in danger of becoming so. This would be done using a number of factors, but mainly just looking at the dependency graph and seeing if it's no longer possible to build the package using ""current"" versions of standard dependencies. Additionally it can be based on build reports. Severely bitrotted packages should have their authors notified and be excluded from the main package index on the website.",duncan 3, Release,617,bootstap.sh: post-install message doesn't make sense when using --global,miscellaneous,1.6.0.1,defect,normal,,new,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, Release,618,Detect in advance if install will be impossible due to permissions,miscellaneous,1.6.0.1,enhancement,normal,,new,2009-12-18T19:34:17-0800,2009-12-18T19:34:17-0800,"People sometimes accidentally install into paths where they do not have write permissions. This can happen because they do not know the default behaviour, accidental misconfiguration, accidental use or non-use of sudo. It would be a service to users if these conditions were detected up front and some suitable explanation given rather than failing half way through the installation step. Specifically the directories where files will be installed should be checked. Also any package registration files should also be checked. Note that we should only do this check for commands that are definitely going to install file, we should not do it for configure for example since it's quite possible to configure and build as a user but install as root. See #601 for one example of confusion. See also #611 about sudo.",duncan 3, Release,619,Add support for package logo's,Cabal specification,1.6.0.1,enhancement,normal,,new,2009-12-21T06:44:51-0800,2009-12-21T06:44:51-0800,"It would be nice if it was possible to associate a logo with a package. The advantage of a logo compared to just a textual name is that it aids in the instant recognition of a package. Humans are faster at pattern matching graphics than text (TODO: add rigorous scientific proof for this statement ;-) ) Once a logo has been associated with a package it can be used in the hackage page of a package and it can be used in graphical package installers. Design questions: 1. How to associate a logo with a package? Probably best to add a logo field to the cabal file, as in: ""Logo: mylogo.png"". (The logo filepath should be relative to the location of the cabal file.) 2. Should there be restrictions on the logo file? 1. What should be the allowed logo formats? png, svg, etc. It's probably best to restrict them to open formats. 2. Should there be a restriction on the logo width and height? Maybe we need support for multiple sized logo's: a big one to put on the hackage page and a small one to display in package lists. (Maybe we even need support for favicons) ",basvandijk 3, Release,626,Package build error due to unicode,Cabal library,1.6.0.1,defect,normal,,reopened,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, Release,628,Greencard files are processed incorrectly,Cabal library,HEAD,defect,normal,,new,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, Release,630,Please add support for common modules and options,Cabal specification,1.6.0.1,enhancement,normal,,new,2010-02-07T11:22:54-0800,2010-08-27T01:40:52-0700,"In some packages I have many executables that share modules and/or compilation options but I have no need for a library. In such a case it would be useful to be able to specify modules and compilation options that are common to all executables in the package. See the discussion in #89 for more context.",AnttiJuhaniKaijanaho 3, Release,631,readline-1.0.1.0 not linking with GNU macports readline on darwin,Cabal library,1.6.0.1,defect,normal,,new,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, Release,633,Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs,Cabal library,1.6.0.1,defect,normal,,new,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, Release,637,Allow overriding defaultPackageDesc,Cabal library,HEAD,enhancement,normal,,new,2010-02-18T19:41:20-0800,2010-02-18T19:41:20-0800,"I'm trying to keep the source of multiple packages in a single source repository. Unfortunately, I cannot maintain a .cabal file per package, because some commands invoke function defaultPackageDesc unconditionally. I tried using {{{defaultMainNoRead}}} instead of {{{defaultMain}}} and passing the desired package name through the environment. This solution doesn't work at all in 1.6.0.3. It works only partially in HEAD: {{{Setup configure}}} and {{{Setup build}}} work but {{{Setup sdist}}} does not because it ignores the {{{readDesc}}} field and invokes {{{defaultPackageDesc}}} unconditionally. Would it be possible to add a field to {{{UserHooks}}} which would specify the .cabal filename to use? Then {{{defaultPackageDesc}}} should be always called through this field, never directly, and could thus be consistently overridden. ",guest 3, Release,641,Cabal-1.8 install of darcs installs manpage with permission 0600,Cabal library,HEAD,defect,normal,,new,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, Release,648,Cabal C lib check error message is occasionally misleading,Cabal library,1.6.0.1,defect,normal,,new,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, Release,653,no documentation for cpp-options,User guide,1.8.0.4,defect,normal,,new,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, Release,654,Exposed-packages field,Cabal specification,HEAD,enhancement,normal,,new,2010-04-07T09:10:14-0700,2010-04-08T07:05:14-0700,"Many libraries essentially require the developer to depend not only on the library's package but also some of the library's dependencies. For example, many libraries exposing monad transformers require you to also depend on mtl in order to use them effectively. Another example is GLUT; a package that uses GLUT usually must also depend on at least OpenGL and StateVar in order to work. It would also be nice if we had a mechanism for creating metapackages which, if depended on, implicitly represent dependencies on other packages. For example, it might be nice to have a haskell-platform metapackage. I would like to propose an Exposed-Packages field for .cabal files that would allow libraries to expose packages much like they currently can expose their own modules. There are potentially some issues this could introduce. Namely, what happens of you depend on two such metapackages which both expose different versions of some other package? I haven't decided how I would want Cabal to behave under those circumstances. I'm hoping that some discussion could spark a good idea.",jmcarthur 3, Release,659,Cabal doesn't work if account name is changed on Windows.,Cabal library,1.8.0.2,defect,normal,,new,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, Release,660,dist checks defined on GenericPackageDescription are inert,Cabal library,1.6.0.3,defect,normal,,new,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, Release,666,configure should warn about using base 3,Cabal library,1.6.0.3,defect,normal,,new,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, Release,667,Improve tools to manage ad-hoc package releases,miscellaneous,,enhancement,normal,,new,2010-04-27T04:48:20-0700,2012-01-05T08:34:21-0800,"Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases. For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality. It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks. One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run: {{{ cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix-blah-1.0.1.tar.gz }}} This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks. In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers. Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package ""search path"" promoted by the searchpath project (http://searchpath.org/). Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds.",duncan 3, Release,668,Update simple distribution for LHC,Cabal library,1.8.0.4,enhancement,normal,,new,2010-04-29T12:49:57-0700,2010-04-29T12:49:57-0700,"Cabal needs some updates for its LHC support. Two changes are needed (and implemented in the attached patch): 1) Change the hackRtsPackage to not fail with an error. The hackRtsPackage function was previously throwing an error when it found zero or more than one rts packages. The rts package is not needed in lhc, so the error is now ignored. This change now matches the behavior in the GHC distribution (Distribution/Simple/GHC.hs) 2) Change the value passed to the odir for compiling C files. The current code was doing a version check to catch a bug with GHC < 6.4. Since lhc is only version 0.9, it was also failing on the version check and passing an incorrect value to odir. Changed to use the correct value as with GHC > 6.4. I have attached a patch against the 1.8 branch that implements these changes.",dmp 3, Release,671,better error message for broken build tools,Cabal library,1.8.0.4,defect,normal,,new,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, Release,674,Findable extra documentation,Cabal library,1.6.0.3,enhancement,normal,,new,2010-05-01T14:47:43-0700,2012-01-05T07:55:47-0800,"I have a cabal package that should include extra documentation in the distribution. This documentation should not be written in Haddock. 1. There should be a field for this analogous to data-files or extra-source-files. The former is too much: the files do not need to be accessed by any Haskell runtime. The latter is not enough: it does not store the extracted files on the system on which the package is installed. 2. There should be a way for humans to find these files without loading up a GHC runtime or using Unix's ""find"". I suggest ""cabal list"" also shows, for installed packages with extra data or documentation files installed, where these files can be found.",jbapple 3, Release,678,Add framework to provide ad-hoc diagnostics for common failures,Cabal library,,enhancement,normal,,new,2010-05-03T13:46:50-0700,2010-05-03T13:46:50-0700,"Just as we have a system for doing various QA checks on cabal packages, perhaps we should have something to help users diagnose common problems with the system environment that crop up as e.g. linker errors. For example, a user reported in #haskell that the wx package failed to configure and reported that the `stdc++` C library was missing. We eventually discovered that although the standard C++ library was installed, it was not found by `gcc -lstdc++`. Installing the C++ components of gcc (ie the distro package that provides `g++`) fixed the issue, presumably because installing that package modified the standard gcc linker search path to include the location where `stdc++` was already installed. It would be good if after diagnosing this particular issue, it was easy to code up a test for this situation and add it into Cabal's `Simple` build system so that other users might get more helpful diagnostics in future. It does not need to be comprehensive, so it is ok to try and grok the output of linkers and to work just on some OSs or just with gcc for example. This might also help with common ghc problems.",duncan 3, Release,679,Hackage website should obscure email addresses,hackageDB website,1.6.0.3,enhancement,normal,,new,2010-05-04T13:55:15-0700,2012-01-05T07:55:58-0800,Email addresses on hackage are getting captured by spambots. HackageDB can implement solutions that individual maintainers could not (javascript) or reduce the amount of redundant work maintainers have to do. Leaving the field unprotected discourages maintainers from providing email addresses for contact.,jbapple 3, Release,680,Spec should define the interpretation of the library and includes and search dirs,Cabal specification,,enhancement,normal,,new,2010-05-05T06:28:11-0700,2010-05-05T06:34:10-0700,"See http://hackage.haskell.org/trac/ghc/ticket/3930 The Cabal spec should say how to interpret the `extra-libraries` and `library-dirs` fields in the installed package info. Specifically how this information is interpreted in relation to package dependencies which may also specify libraries and search paths. The interpretation should be that all the `extra-libraries` required by a installed package should be found in `library-dirs` given in that installed package info, or in the ""standard"" system linker path (as used by the standard system linker). That is, the `library-dirs` of dependent packages should not be used. For example: {{{ -- installed package gtk: extra-libraries: gtk-x11-2.0 library-dirs: depends: glib -- installed package glib: extra-libraries: glib-2.0 library-dirs: /opt/local/lib }}} We presume here that `/opt/local/lib` is not on the standard linker path. Then we should only look for the `gtk-x11-2.0` library on the paths specified in the gtk package, which in this case is empty, so that means only on the system linker path. If `gtk-x11-2.0` is in fact only in `/opt/local/lib` then this will and should fail. We should not use the library dirs of the `glib` package to find the libraries of the `gtk` package. The correct information for the above example would be to list `library-dirs: /opt/local/lib` for the gtk package also.",duncan 3, Release,693,Missing instructions for running Cabal's testsuite,Cabal library,HEAD,defect,normal,,reopened,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, Release,696,better error message for when /tmp is mounted noexec,Cabal library,1.6.0.3,defect,normal,,new,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, Release,699,Do additional ghc / ghc-pkg consistency check,Cabal library,1.6.0.3,enhancement,normal,,new,2010-06-05T12:18:47-0700,2010-06-05T12:18:47-0700,"See http://hackage.haskell.org/trac/ghc/ticket/4103 In future, `ghc --info` will report the global package database location. This can be used to check that ghc and ghc-pkg agree on the same one, as a consistency check to make sure the two programs are from the same ghc installation. Note that getting the location of the global package db from ghc-pkg is a bit hacky at the moment. One has to use `ghc-pkg list --global` and parse the result. Perhaps we need another ghc feature request for that.",duncan 3, Release,701,Help packages to avoid linker symbol clashes,Cabal library,1.6.0.3,enhancement,normal,,new,2010-06-14T05:27:38-0700,2012-01-05T08:29:24-0800,"Currently it is all too easy to end up with silently clashing linker symbols. The prime example is C code linked into a Haskell package. Multiple versions of the same package will define the same linker symbols. The system linker is happy to just pick the first occurrence of a symbol (though the ghci linker is stricter). This can cause havoc if the behaviour of the C code changes from one version of the package to another (see for example the problem with mmap and darcs, ticket #700). There are a number of things we could do to improve the situation. * We could make it easier to make versioned C symbols in the C code used in a Haskell package by providing cpp macros. * We could explicitly check for unversioned C symbols in Haskell libs * We could try linking Haskell libs in such a way that the C symbols are not visible and thus cannot clash, but it would also mean they are not exported for other libs to use.",duncan 3, Release,702,cabal should reject relative paths for extra-lib/include-dirs,Cabal library,1.6.0.3,enhancement,normal,,new,2010-06-14T14:47:20-0700,2012-01-05T07:59:16-0800,"It makes no sense and causes problems later. See ghc ticket http://hackage.haskell.org/trac/ghc/ticket/4134 This applies to the paths in the .cabal file. For ones specified on the command line perhaps just making them absolute would be ok. Ones specified in the global config must be absolute. Ones in local config could possibly be relative.",duncan 3, Release,704,sort out design for foreign code in Haskell libraries,Cabal library,1.6.0.3,task,normal,,new,2010-06-21T10:38:08-0700,2010-11-09T03:34:23-0800,"Currently we often happily add little bits of C glue code into Haskell packages. This is perfectly reasonably but we also want to be able to do things like linking multiple versions of a Haskell package into a single application. That does not work if the C symbols are visible outside of the package (see #701). It seems reasonable to require that C code in a Haskell package respects the properties that we want for Haskell packages. However we must also allow for libraries that are foreign code and not Haskell libraries at all. For example, the zlib binding package ships a complete copy of the zlib C code for platforms that do not have it natively. Unlike bits of FFI glue code, it is unreasonable to expect to change the zlib code to conform to Haskell library requirements. Perhaps what we need is to explicitly identify foreign libraries and hold them to different (lower) standards compared to Haskell libraries. One idea would be to draw together the features proposed in these tickets: * #276 : support for convenience libraries * #148 : producing foreign libraires The idea with convenience libraries is that a package can have multiple libraries in it, even though at most one can be the library that has exposed modules. Other libraries could be used by executables or the main library in that package. The main purpose is sharing but it could also be a way to separate the requirements of haskell code and foreign code. Producing foreign libraries is about making libraries (usually but not necessarily containing Haskell code) that export a foreign C API and are not intended to be used by other Haskell code. Combining these two features would allow for the zlib example to work ok. We would declare a foreign library with the zlib C code and make the main Haskell binding library depend on it. Note that packages that depend on the binding package would not directly link to the C library (this is significant for shared libs). The key constraint for foreign libraries is that we cannot link more than one version into a single application (because the symbols would clash), where as we may assume that it is perfectly safe to link multiple versions of a Haskell package. Any design must also consider symbol visibility. This is relevant both for shared and static libs. With static libs it is hard to avoid every symbol being globally visible. With shared libs there is greater control over symbol visibility but also the restriction on some systems that each shared lib must resolve all symbol references. This means we must more explicitly identify which libraries import symbols from others.",duncan 3, Release,708,extension list,Cabal library,HEAD,defect,normal,,new,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, Release,709,cabal doesn't handle error conditions from getAppUserDataDirectory,Cabal library,1.8.0.2,defect,normal,,new,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, Release,710,Track license-file,Cabal library,HEAD,enhancement,normal,,new,2010-07-12T15:00:25-0700,2010-08-09T21:30:46-0700,"ghc-pkg has supported (since 6.4) a license-file field in the package database. It would be useful to make this information available inside of Cabal, as guesses have to be made as to the location of the license file, currently.",elliottt 3, Release,717,Expose libexec option in simple build system,Cabal specification,1.8.0.2,enhancement,normal,,new,2010-07-23T16:49:45-0700,2010-07-23T17:01:45-0700,"For my Bluetile Cabal package ( http://hackage.haskell.org/package/bluetile ) I would like to install some of the executables into the libexec target directory. Cabal already supports a libexec directory, there is just no easy way to get an executable copied there. So I had to write my own custom hooks. To simplify things, I would like to suggest the option of marking an executable to be installed in the libexec directory. I propose a simple flag 'Is-Helper-Executable: True/False' which could be specified as part of an 'Executable' section. Setting this to True should result in Cabal installing the executable to the libexec directory. Quick example of why one wants to use the libexec directory in the first place: Bluetile has a number of such helper applications. While having Bluetile packaged for Debian, it turned out that Debian requires a man page for every binary under /usr/bin. So I would have had to write man pages for every helper application or - which seemed like the proper way to do it - have them installed under /usr/lib/bluetile/ (libexec directory).",guest 3, Release,718,Behaviour of postCopy and postInstall hook is confusing,Cabal library,1.8.0.2,defect,normal,,new,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, Release,720,Executables fail on windows if the executable name has a dot in it,Cabal library,,defect,normal,,new,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, Release,721,Unknown subsections are silently ignored,Cabal library,1.8.0.4,defect,normal,,new,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, Release,724,Functions in Paths_pkgname module need documenting in the user guide,User guide,1.6.0.3,enhancement,normal,,new,2010-08-13T07:05:57-0700,2012-01-05T08:31:07-0800,"Some libraries and programs have a large number of files. Instead of having explicit knowledge of each file (and instead of using a mutation on the result of getDataFilename) there should be a ""getDataDirectory"" or a ""getDataDirectoryContents"": getDataDirectoryContents = getDataDirectory >>= getDirectoryContents",tommd 3, Release,726,Mention in documentation executable-to-library self dependency feature in 1.8.0.4,miscellaneous,1.6.0.3,task,normal,,new,2010-08-14T16:05:23-0700,2010-08-21T06:49:14-0700,"{{{ Thu Jun 10 19:27:49 PDT 2010 ezyang@mit.edu * Mention self-referential dependency feature in Cabal >= 1.8.0.4. hunk ./doc/Cabal.markdown 135 -that library. +that library. Fortunately, starting with Cabal 1.8.0.4, executables can +also declare the package that they are in as a dependency, and Cabal +will treat them as if they were in another package that dependended on +the library. }}}",ezyang 3, Release,728,"Rewrite user guide, document cabal-install",User guide,,defect,normal,,new,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, Release,729,Support generated modules better,Cabal library,HEAD,enhancement,normal,,new,2010-08-21T07:44:02-0700,2010-08-21T07:44:02-0700,"Currently Cabal's simple build system expects that all modules listed in the `exposed-modules` and `other-modules` have some original source file (possibly one that needs a preprocessor). There is a built-in hack for the generated Paths_pkgname module. Adding other generated modules is rather tricky because of the assumption that an original source file can be found. This should not be too hard to fix for build, since we can just look for the generated source file in the build location, but it affects sdist more severely. There is no way for sdist to know if a file is generated or not, so if a source file is not found then currently it just fails. Unlike at build time, it's reasonable to run sdist in a clean build tree. People can hack around it in the Setup.hs by filtering out the module name for various stages, but that is still tricky due to the combination of #410 and #627. This affects some core ghc components and also darcs.",duncan 3, Release,733,Cabal should give haddock per-package source entity paths,Cabal library,1.6.0.3,defect,normal,,new,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, Release,734,support multiple .cabal files,Cabal library,,enhancement,normal,,new,2010-09-06T12:14:06-0700,2012-01-05T08:01:22-0800,"if there are several *.cabal files in the working directory, then ""cabal configure"" complains, and does nothing. That's OK, but it should then have an option for picking one of these files (cf. ""make -f FILE""). ",guest 3, Release,737,Cabal check warns about ill-specified dependencies,Cabal library,1.6.0.3,enhancement,normal,,new,2010-09-09T09:20:15-0700,2010-09-09T09:20:15-0700,"Packages that get listed here: http://hackage.haskell.org/packages/archive/preferred-versions Get special treatment from cabal-install. It would help package authors if 'cabal check' could warn about version ranges, especially for packages listed in the preferred-version file. For example, if the .cabal file just mentions package FOO and preferred-versions asks for FOO < X, then the author might not be aware that some people might expect to use FOO >= X. It would be nice to let the author know that they need to say, FOO == Y.* or FOO > A && FOO < B. This is particularly important for base, where lacking an upper bound leads to bad build behavior. This should probably be implemented in the Cabal library.",guest 3, Release,739,cabal install regression with GHC HEAD - ghc-paths,Cabal library,HEAD,defect,normal,,new,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, Release,740,Allow specifying private C libs to avoid overlinking (but allow static linking),Cabal library,,enhancement,normal,,new,2010-09-20T12:57:48-0700,2010-09-20T12:57:48-0700,"See http://wiki.mandriva.com/en/Overlinking for a discussion of under and overlinking. In different circumstances, we want both to be able to link to C libs statically and dynamically. For the dynamic case we only want to specify direct C lib dependencies or we end up overlinking. For the static case we must specify all direct and indirect C libs or we will miss libs and get missing symbols. A sensible solution is to follow [http://people.freedesktop.org/~dbn/pkg-config-guide.html pkg-config] and specify ""private"" C libs separately from normal public ones. This would require extensions both to .cabal files and package registration files.",duncan 3, Release,746,Cabal should complain if you give an upperbound on Cabal-Version,Cabal library,HEAD,defect,normal,,new,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, Release,747,symlinks in sdists,Cabal library,1.6.0.3,defect,normal,,new,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, Release,749,Package check cannot handle byte-order-mark in .cabal file,Cabal library,1.8.0.6,defect,normal,,new,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, Release,760,exclude all but latest documentation from search results,hackageDB website,1.8.0.6,enhancement,normal,,new,2010-11-04T11:15:38-0700,2011-12-01T18:52:46-0800,"When searching for haskell documentation on google, quite frequently the top search results are versions of the library documentation from the archives. For instance, when searching for Data.Vector, the top hit is version 0.5, whereas the latest is 0.7. Also, if the user selects the 0.7 version, it isn't obvious from the documentation that this version corresponds to the latest since it also appears in the archive (the url is http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data-Vector.html). So I'm wondering if it might not make sense to exclude all but the latest haddock documentation from search results by augmenting the robots.txt file. It might also make sense to provide alternate urls to the latest versions of documents. E.g. Starting from the http://hackage.haskell.org/package/vector page (which is the latest version), and clicking on Data.Vector, one is taken to http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data-Vector.html... but it might be better if this were http://hackage.haskell.org/packages/current/vector/doc/html/Data-Vector.html. This would allow for all files under /archive to be excluded.",warren 3, Release,763,Warn about unused flags in Cabal file,Cabal library,1.8.0.6,enhancement,normal,,new,2010-11-11T06:14:49-0800,2010-11-11T06:14:49-0800,"Cabal should output a warning during configure if a flag is defined but never used. I almost forgot to delete an old flag due to removing its use sites but not its definition. ",tibbe 3, Release,766,"please link ""built on"" entries in package descriptions to hackage build logs",hackageDB website,1.8.0.6,enhancement,normal,,reopened,2010-11-17T11:28:05-0800,2012-01-05T08:27:43-0800,"It seems that build logs are no longer linked from package pages (used to be linked from the `built on` entries, iirc), such as: http://hackage.haskell.org/package/haddock Also, the `latest/` directory has `doc/`, but not `logs/`, while the archived versioned directory has both: http://hackage.haskell.org/packages/archive/haddock/latest/ http://hackage.haskell.org/packages/archive/haddock/2.8.1/ And, since I've more than once confused myself with that directory structure (`package` singular, but `packages/archive` plural? why the different prefix, where a version number postfix should be enough? why both `http://hackage.haskell.org/package/haddock-2.8.0` and `http://hackage.haskell.org/packages/archive/haddock/2.8.0/`?), could that be simplified (or, at least, a link be provided from the `package`-entry to the shadow-hierarchy `packages/archive`)?",claus 3, Release,771,Package registered twice in the same database,Cabal library,1.8.0.6,defect,normal,,new,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, Release,778,"ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=...",Cabal library,HEAD,defect,normal,,new,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, Release,784,Cabal strips out { and } in literate code blocks of the description field,Cabal library,1.8.0.6,defect,normal,,new,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, Release,785,"check fails ""No (or multiple) ghc rts package is registered""",Cabal library,1.8.0.6,defect,normal,,new,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, Release,786,Bad errors from getProgramInvocationOutput and friends,Cabal library,HEAD,defect,normal,,new,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, Release,788,Optionally exposed modules / APIs should be banned,Cabal library,1.8.0.6,defect,normal,,new,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, Release,793,"On OS X, warn about filenames that only differ in case",Cabal library,1.8.0.6,defect,normal,,new,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, Release,798,"install gives ""removeLink: does not exist"" for a dependency that exists",Cabal library,1.8.0.6,defect,normal,,new,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, Release,802,copy command should not overwrite files,Cabal library,1.8.0.6,defect,normal,,new,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, Release,807,inplace is shadowed by package,Cabal library,HEAD,defect,normal,,new,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, Release,814,Avoid orphan flexible instances in Cabal-TestSuite documentation,User guide,1.10.1.0,enhancement,normal,ttuegel,assigned,2011-03-13T04:59:33-0700,2012-01-05T08:28:52-0800,"The example code shown in http://www.haskell.org/cabal/release/cabal-1.10.1.0/doc/users-guide/#test-suites needs FlexibleInstances, and the instance is orphan, too. Although this code is not intended to be used in most packages, it still looks like those instances are necessary or at least good style. I suggest to replace the generic pair by a custom data type like {{{ data TestCase = TestCase String Bool instance TestOptions TestCase where ... }}} in the documentation. Since Cabal is a widely used library, it has automatically an educational aspect. ",guest 3, Release,817,"""main-is"" misparsed in if/else, only by sdist",Cabal library,1.10.0.0,defect,normal,,new,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, Release,819,Pass extra parameters of 'configure' to user hooks,Cabal library,1.8.0.6,enhancement,normal,,new,2011-03-22T13:20:42-0700,2011-03-22T13:20:42-0700,"Non-standard options to 'configure' are not supported by Cabal; to accept new options requires writing a custom version of Cabal's 'defaultMain'. It would be useful to provide some support for extending the command-line parser, or at least passing unrecognized arguments to user hooks. To motivate this feature, here's my use case. During the build phase, my package builds an executable, then uses the executable to build some data files. The executable and data files are installed together. If the executable needs extra arguments (e.g., search paths) to run, they can be supplied as command-line parameters to 'configure'. Supporting these extra parameters required some changes to Cabal. I did it by copying 'defaultMainWithHooks' and some 200-odd lines of non-exported functions from Distribution.Simple into my package's Setup.hs so that I could override 'configureCommand'. This gave me access to the command-line parser. Relatively little code was actually changed, so hopefully this feature would fit nicely into the current codebase.",guest 3, Release,821,Add support for Apache license,Cabal library,1.8.0.6,enhancement,normal,,new,2011-03-23T12:50:15-0700,2011-10-25T05:11:01-0700,"I have several projects licensed under the Apache license due to upstream dependencies, but Cabal doesn't know about it. This would be good to add for e.g. license compatibility checkers (I believe Galois has such a tool).",bos 3, Release,832,Cabal aggregates dependencies for executables,Cabal library,1.10.1.0,defect,normal,,new,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, Release,833,Cabal mangles exceptions,Cabal library,HEAD,defect,normal,,new,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, Release,836,Provide the state of Cabal flags in an auto-generated module,Cabal library,1.10.0.0,enhancement,normal,,new,2011-04-24T08:26:24-0700,2012-01-05T08:09:11-0800,"I would like to query the state of cabal flags at configure time without CPP hackery. I would prefer to import an autogenerated module, that contains Bool variables with the names of the Cabal flags, just like the Paths module contains the paths of installed data files. For instance if my Cabal file contains {{{ Flag buildExamples description: Build example executables default: False Flag buildTests description: Build test suite default: True Flag debug description: Compile with debug messages default: False }}} and I install the package by {{{ $ cabal install -fdebug }}} then the autogenerated module shall contain {{{ module Flags_mypkg where -- | Build example executables buildExamples :: Bool buildExamples = False -- | Build test suite buildTests :: Bool buildTests = True -- | Compile with debug messages debug :: Bool debug = True }}} Maybe this feature would also solve #778. ",lemming 3, Release,850,Configure fails when an Objective-C .h file is specified,Cabal library,HEAD,defect,normal,dankna,assigned,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, Release,851,Add c-source-dirs: field analogous to hs-source-dirs: and include-dirs:,Cabal library,1.8.0.6,enhancement,normal,dankna,assigned,2011-05-28T15:19:44-0700,2011-05-31T07:03:36-0700,"I came across this need in the course of working with a hybrid Haskell-ObjC project; it just seems weird to set include-dirs but not set this, since it happens in my project to be the same directory. Should be an easy feature; I'm going to implement it and keep track of my progress here.",dankna 3, Release,852,"Not possible to #include ""*_stub.h"" from C code",Cabal library,1.8.0.6,enhancement,normal,dankna,assigned,2011-05-28T22:33:37-0700,2011-05-31T07:03:31-0700,"Cabal doesn't make it possible to #include ""*_stub.h"" files from C code, because those files have not yet been generated at the time that it wants to check for their existence, which is during ""cabal configure"". At first I was going to ask for advice because I didn't really see a solution, but now that I think about it, I think correct behavior is to omit the check for whether stub files exist and compile, but to check for the existence of files which /could/ generate them, which is to say, are Haskell files and match the module portion of the name. So I'll implement that. ",dankna 3, Release,853,Building mixed-language programs with Apple's Objective-C garbage-collection feature is difficult,Cabal library,HEAD,enhancement,normal,dankna,assigned,2011-05-31T00:20:56-0700,2011-05-31T07:02:53-0700,"Ideally, there would be a single flag to set the ObjC garbage collection mode. The three possibilities are, semantically, disabled, optional, and mandatory; I was experimenting with the mandatory mode, but there will be related issues with the others. One might expect the following to work: ld-options: -fobjc-gc-only In fact this will compile successfully but the linked object will have very subtle heap corruption due to the lack of a write barrier (which is implemented by gcc by hooking all field accessors, transparently to the developer). Why yes, this /did/ take me a while to track down! It is necessary to also add: cc-options: -fobjc-gc-only But once this is added, it is impossible to link any Haskell objects in, because they do not contain the magic flag which tells the linker they are GC-aware. We therefore need: ghc-options: -optc-fobjc-gc-only (I think this might force compilation via C when it wouldn't otherwise be used, which is of course undesirable, but I haven't looked into it.) This is somewhat of an ugly situation, but fortuitously, it is simple to remedy - Cabal merely needs to understand what needs to be done and do it! I propose to put the new field in BuildInfo, as it applies to both libraries and executables; to call it ""objc-gc:"", and to give it the values ""Disabled"", ""Optional"", and ""Mandatory"". I expect to have a patch for this ready sometime tomorrow. ",dankna 3, Release,854,BSD2 and ISC license,Cabal library,HEAD,defect,normal,,new,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, Release,857,Decide what to do about licenses,Cabal library,1.8.0.6,task,normal,,new,2011-06-18T11:31:55-0700,2011-10-25T05:10:43-0700,"Currently you can specify some partial info about a license in the .cabal file. It's not exhaustive and does not cover all licenses. It seems originally intended so that common licenses will be given the same name (so no confusion over ""bsd"" =? ""BSD""). There are a number of outstanding requests for new licenses to be listed (#854 BSD2 & ISC, #821 Apache). This is based on users expecting that most licenses they might want should be listed. The current alternative of course is that they just list it as `OtherLicense`. So this all comes down to what do we want the license field for, what is it's purpose, does it have any semantics? Currently we can't really say that it has any reliable semantics (even if the info were accurate), it's really just a way to stop people spelling ""GPL"" wrong. It also serves a purpose to indicate what are recommended licenses, to work against license proliferation. So, should we move to a more accurate license system where you can express more precisely the licensing terms? Apart from listing more licenses this would mean we have to tackle: * multiple licenses (conjunctive): the distributor has to comply with multiple licenses, e.g. because different parts of the code have different licenses. * dual licensing (disjunctive): the distributor gets to pick which license to use * GPL open ended versions: The GPL recommends that authors license under terms like ""Version X or any later version"". This is a special kind of dual licensing, it's the infinite disjunction of all later versions of the license and of course those later versions are mostly unknown so it'd have to be handled specially. Then there's the issue in the BSD licenses that there's hardly any standard BSD3 license, people make up all kinds of variations. The 2-clause license is not actually (properly) listed by the FSF or the OSI (bizarrely the OSI has it listed but with the wrong text).",duncan 3, Release,862,Real file glob for extra-source-files,Cabal library,1.8.0.6,enhancement,normal,,new,2011-07-13T10:28:56-0700,2012-01-05T08:00:27-0800,"For the [Yesod scaffolding tool](https://github.com/gregwebs/yesod/tree/org) We have a directory structure of extra files. The current file glob syntax doesn't recurse into directories or recognize files with multiple suffixes. So I am left to manually do a find command and list all the files in the cabal file. The extra-source-files field needs a real shell glob syntax. This does not seem like a hard change to make, but some guidance is needed for the approach. I see there is a [glob package](http://hackage.haskell.org/packages/archive/Glob/). ",guest 3, Release,863,Can't pass extra arguments to c2hs,Cabal library,1.10.1.0,defect,normal,,new,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, Release,866,Making sure external C library DLLs are available at runtime is too easy to get wrong,Cabal library,1.8.0.6,defect,normal,,new,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, Release,870,hsc2hs should include cabal_macros.h,Cabal library,1.10.1.0,defect,normal,,reopened,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 3, Release,873,cabal check: Warn if package misses changelog file,Cabal library,HEAD,enhancement,normal,,new,2011-08-13T14:28:48-0700,2011-08-15T11:29:43-0700,"To encourage author to write ChangeLog files, and as a first step to eventually fix #244 and #299, this makes cabal check warn if no changelog is found in the package",nomeata 3, Release,878,Install rsync on hackage.haskell.org,hackageDB website,,enhancement,normal,,new,2011-08-26T13:46:08-0700,2012-01-05T08:32:23-0800,"I keep a local copy of the HackageDB, which I construct by downloading archive.tar and 00-index.tar.gz on occasion. This is kind of wasteful of bandwidth for me and the hackage.haskell.org server. My proposed solution is to install rsync on hackage.haskell.org in daemon mode, and configure it to serve the HaskellDB archive (or archive.tar and 00-index.tar.gz). This would allow users to download only the differences between their local copy and the official repository's copy. http://everythinglinux.org/rsync/ contains a sample rsync daemon configuration. It looks relatively straight forward to set up. Also, I would suggest that the front page's ""Getting the Raw Data"" section should contain a sample rsync command line invocation users can use to differentially mirror the archive.",guest 3, Release,879,source link broken for some Prelude types in online documentation,hackageDB website,,defect,normal,,new,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, Release,882,bootstrap.sh fails to compile transformers-0.2.2.0,miscellaneous,HEAD,defect,normal,,new,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, Release,886,"when installing globally, cabal shouldn't use umask, should set mods to 755 or 644",Cabal library,1.8.0.6,defect,normal,,new,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, Release,888,runTests deprecated message should be more helpful,Cabal library,1.8.0.6,defect,normal,ttuegel,assigned,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 3, Release,891,Allow unknown fields in .cabal with X- at front,miscellaneous,1.8.0.6,enhancement,normal,,new,2011-09-29T11:21:55-0700,2012-01-05T08:31:26-0800,"I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand. It should also do similar thing with sections named with X- at front, where, it if it doesn't understand that section, it ignore entire section with no warning/error (regardless of field names), but if it can use that section, it is still warnings for unknown fields in that section without X- at front. ",zzo38 3, Release,895,Mis-parses curly braces in package description,Cabal library,1.8.0.6,defect,normal,,new,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, Release,898,"With TH, when doing ""cabal haddock"", GHCi ""couldn't find symbol""",Cabal library,HEAD,defect,normal,,new,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, Release,913,New HTML theme,Hackage 2 server,1.8.0.6,enhancement,normal,,new,2012-02-14T09:07:18-0800,2012-02-14T10:24:25-0800,A mock-up can be found at http://althack.org/hackage/hackage4.png,bgamari 3, Release,914,Fix acid-state usage,Hackage 2 server,1.8.0.6,enhancement,normal,,new,2012-02-14T09:08:20-0800,2012-02-14T09:35:32-0800,"Update use of acid-state so that it's properly modular, rather than the current monolithic shim. ",bgamari 3, Release,919,hackage-mirror should handle errors more gracefully,Hackage 2 server,1.8.0.6,defect,normal,,new,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, Release,944,Duplicate C symbol names,Cabal library,1.14.0,defect,normal,,new,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 3, Release,949,cabal should fail if compilation depends on a file not existing in the cabal file,cabal-install tool,1.10.2.0,enhancement,normal,,new,2012-05-10T21:14:13-0700,2012-05-10T21:14:13-0700,"Cabal doesn't complain if the build depends on a Haskell module that exists in the filesystem properly, but is not mentioned in the cabal file itself as part of ""exposed-modules"" or ""other-modules"". The build succeeds because ghc can find the relevant file just fine. I've got bitten by this several times, especially after pushing a package to hackage, only to get it fail to build on the server because I've failed to put the name of a file in the appropriate section of the cabal file, thus it didn't make it to the .tar.gz bundle that got uploaded to the server. I realize this might be hard to ensure, as it would require a deeper look into the dependencies between modules, but I trust the GHC API should have all the information necessary for cabal to complain appropriately.",LeventErkok 3, Release,950,no dyn_o generated for C files,Cabal library,HEAD,defect,normal,,new,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, Release,953,Alex-generated Lexer isn't found when building test-suite,Cabal library,1.14.0,defect,normal,,new,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, Release,954,setup haddock fails for packages without modules,Cabal library,1.14.0,defect,normal,,new,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, Release,955,Incorrect hpcdir during cabal test for testsuites w/ library coverage enabled,Cabal library,1.14.0,defect,normal,,new,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 4, Release,124,*.cpphs files aren’t preprocessed with -D__HADDOCK__ when needed,Cabal library,1.1.6,defect,normal,,new,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@… 4, Release,177,"Check Include-dirs, extra-lib-dirs etc exist at configure time.",Cabal library,1.2.2.0,defect,normal,,new,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, Release,244,Add Changelog summary feature to sdist,Cabal library,1.2.3.0,enhancement,normal,,new,2008-02-20T17:20:49-0800,2011-08-15T11:30:10-0700,"In a discussion with Audrey Tang, she mentioned that a very nice feature of CPAN which she missed in Hackage was standardized changes files. It seems to me that one way to acheive this would be to add a --changelog flag to sdist (or maybe make default). This call 'darcs changes' and copy into the ChangeLog everything up to 2 tags ago. (2 tags because the first tag might be you preparing for a release). I'd imagine parsing would be dead easy: 'lines' to split it up into individual entries, and then take until you hit a 'tagged' entry. If the resulting list is length of 1, then take again. So you'd go 'runhaskell Setup sdist --changelog', and ChangeLog in the tarball would have, say, for Monadius: ---- Wed Feb 20 18:37:42 EST 2008 gwern0@gmail.com tagged 0.91 Wed Feb 20 18:37:29 EST 2008 gwern0@gmail.com * misc improvements: newtype, cabal, fmt Fri Dec 7 16:23:53 EST 2007 gwern0@gmail.com * rm extra source-files The line was originally there because there is an icon for Monadius in the source-files and some sort of Windows resource text file telling Windows to use it; I'm removing the mention of them in the .cabal because I don't think Cabal handles that right now. Thu Dec 6 16:30:31 EST 2007 gwern0@gmail.com * whitespace changes, add haskell98 to dependencies Tue Dec 4 13:46:38 EST 2007 gwern0@gmail.com * mv cabal field so hackage doesn't complain Tue Dec 4 13:10:47 EST 2007 gwern0@gmail.com * cabal fixes Tue Dec 4 08:32:25 EST 2007 gwern0@gmail.com tagged 0.91 ---- At this point, Hackage could be updated to link to it in the same way as it does for the .cabal file. That way, people could then easily take a look and see what's new since the last version. (Said facility is currently a little difficult unless the package authors manually maintain a ChangeLog and specifically include it into the tarball; you'd still have to either go to the repo or download the tarball simply to find out what's different from the older packages.) --gwern",guest 4, Release,438,Cabal should warn or fail if user specifies a bad configuration flag,Cabal library,HEAD,defect,normal,,new,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 4, Release,513,Version of Cabal lib used to build Setup.hs is not tracked.,Cabal library,1.6.0.1,defect,normal,,new,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 4, Release,635,Display checksum of tarball on Hackage,hackageDB website,1.6.0.1,enhancement,normal,,new,2010-02-15T16:26:33-0800,2010-03-06T16:08:09-0800,"Distro packaging tools have to, currently, download .tar.gz from Hackage in order to compute the md5 or sha has needed for many package systems. This wastes bandwidth. We could simply compute the hash on the server and store it somewhere.",dons 4, Release,643,Cabal should warn & detect when no modules are imported/used from a declared dependency,Cabal library,HEAD,enhancement,normal,,new,2010-03-14T14:54:20-0700,2010-03-14T14:54:20-0700,"For context, see: http://www.haskell.org/pipermail/libraries/2010-March/013115.html http://www.haskell.org/pipermail/libraries/2010-March/013155.html http://www.haskell.org/pipermail/libraries/2010-March/013157.html Not a few Haskell packages had declared in their .cabal files that they used the 'haskell98' package; but they never imported anything from haskell98 (such as the Monad or List modules), as proven by simply removing the dependency and noting that it continued to compile. Apparently the authors were mistaken about the use, had updated the old module imports, or believed haskell98 did something it didn't. The authors never knew, because neither GHC, Cabal, nor cabal-install would ever warn about the superfluous dependency. Given that dependencies can cause failures quite easily via bit-rot or the diamond dependency problem, otiose deps are quite bad.",guest 4, Release,893,Bad cabal build error message with mangled top of file,Cabal library,1.8.0.6,defect,normal,,new,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 4, Release,935,implementation of Distribution.Version.invertVersionRange,Cabal library,1.10.2.0,enhancement,normal,,new,2012-03-23T11:49:44-0700,2012-10-26T05:02:18-0700,Attached is an implementation of a function to return the complement of a VersionRange.,dsf 3,cabal-install-0.16 Release,279,Cabal-upload could have a smarter default,cabal-install tool,1.2.3.0,enhancement,minor,,new,2008-05-13T21:32:36-0700,2012-03-08T01:24:21-0800,"Cabal-upload is a nice enough tool, but it doesn't have a good default: it just errors out if not specifically told exactly where to find a tarball. I think this could be smarter. cabal-upload will almost always be run in the top level of a cabal package. A much better default would be: if no arguments are given, cabal-upload looks in dist/ and if there is an appropriate tarball in it, uploads it. Smarter possibilities: * if there are multiple tarballs, instead of bailing out, cabal-upload just picks the highest numbered one. * before looking in dist/, do a runhaskell Setup sdist. -- gwern",guest 3,cabal-install-0.16 Release,507,Improve `cabal info` output for the local package,cabal-install tool,1.6.0.1,enhancement,minor,,new,2009-02-25T03:43:17-0800,2012-03-06T02:19:30-0800,"Currently cabal configure --help displays only the help for the configure command in general. Often I'd like to say what flags are available for the package in question. Currently the only way to do this seems to be to actually look at the .cabal file in question. Something a bit like: ./configure --help which shows you the generic flags like --prefix but also --enable-glade (for example). ",guest 3,cabal-install-0.16 Release,597,non-exhaustive patterns when trying to install base,cabal-install tool,1.6.0.2,defect,minor,,new,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-install-0.16 Release,672,'cabal init' command should allow for multiple entries in the Category field,cabal-install tool,,enhancement,minor,,new,2010-05-01T09:55:44-0700,2012-03-05T06:02:50-0800,"The .cabal format allows multiple categories (e.g. Data, Network, Math, etc.) to be listed in the Category field, but the 'cabal init' interactive mode only lets the user choose a single category. It would be nice to allow the user to choose multiple categories.",byorgey 3,cabal-install-0.16 Release,922,“lexical error (UTF-8 decoding error)” in WIndows 7,cabal-install tool,HEAD,defect,minor,,new,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 4,cabal-install-0.16 Release,397,"make cabal --cabal-lib-version="""" take a dependency or a specific number",cabal-install tool,1.2.3.0,enhancement,minor,,new,2008-11-08T07:15:38-0800,2012-03-08T01:20:53-0800,"The `--cabal-lib-version=` flag currently takes a specific version number. It could easily be like `--constraint=` or like `cabal install ""foo < 2""` and take a dependency or a specific version number.",duncan 4,cabal-install-0.16 Release,423,add option to fetch a single package without dependencies,cabal-install tool,HEAD,enhancement,minor,,new,2008-12-01T13:20:06-0800,2012-03-06T10:07:33-0800,"Right now, {{{cabal fetch}}} fetches all missing dependencies of a package along with its source. In some cases, in particular when studying code, those dependencies are not useful. It would be nice to have an option, say {{{--no-deps}}} to fetch just the specified packages. (This is related to {{{cabal unpack}}} -- see #390.)",guest 4,cabal-install-0.16 Release,542,installing cabal-install refers to editing nonexistent file $HOME/.cabal/config,cabal-install tool,1.6.0.1,defect,minor,,new,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 4,cabal-install-0.16 Release,544,symlink-bindir should really be a user/global option rather than in the main section,cabal-install tool,,enhancement,minor,Jedai,new,2009-04-19T16:23:04-0700,2012-03-06T11:10:14-0800,"Well, not much to add. symlink-bindir is currently an option from the main section, it would make more sense to make it an option for the installdirs sections since this is really a choice of where to install things.",Jedai 4,cabal-install-0.16 Release,550,bad error message when proxy cannot be resolved,cabal-install tool,,defect,minor,,new,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 4,cabal-install-0.16 Release,613,Update .cabal/config along with cabal-install,cabal-install tool,HEAD,enhancement,minor,,new,2009-11-28T04:05:37-0800,2012-03-06T10:47:40-0800,"When cabal-install is upgraded, it sometimes gains new features with corresponding lines in the default .cabal/config; however, the existing .cabal/config is not updated. One way of updating it would be to make it, at every invocation of cabal-install, rewrite the file using a merger of the current configuration and the default one. There are some issues with this - most particularily, user-written comments in the file should be preserved, without this stopping cabal-install from inserting its own comments for (disabled) new features, or causing duplication of comments. None of this is particularily hard to imagine a solution for, but in the interests of avoiding priming, I won't write down my own suggested solutions here. If whoever eventually decides to try fixing this explains his proposed solution here, I'll chime in then.",guest 4,_|_ Release,135,Epoch Support for Version Numbers,Cabal library,1.1.6,enhancement,minor,nominolo,new,2007-05-28T13:59:19-0700,2008-01-24T08:03:11-0800,"Some packages use Date-based version numbers. This makes it hard to later change that package to the ''major.minor.patchlevel'' format. Debian uses [[http://www.us.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Epochs]] , an optional prefix number (defaulting to zero). I.e.: {{{ version-number ::= [ epoch ':' ] num { '.' num } [ label ] }}} If omitted, the ''epoch'' defaults to 0. Thus: {{{ 2007.04.02 < 1:0.0.1 }}}",nominolo@… 4,_|_ Release,265,Cabal field stability not useful,Cabal library,1.2.3.0,defect,minor,,new,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 4,_|_ Release,321,cabal in non-existant directory fails,Cabal library,1.4.0.1,defect,minor,,new,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-1.8 Release,337,--disable-split-objs has wrong help string,Cabal library,1.2.3.0,defect,minor,,new,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, Release,385,"some packages incorrectly shown as ""program"" but are actually ""library and program""",hackageDB website,,defect,minor,,new,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, Release,487,print less useless info during builds,Cabal library,1.6.0.1,enhancement,minor,,new,2009-02-02T03:01:59-0800,2012-01-05T08:34:08-0800,"Here's an example from a blog post: {{{ $ cabal update $ cabal install gofer-prelude Resolving dependencies... Downloading gofer-prelude-2.30... Configuring gofer-prelude-2.30... Preprocessing library gofer-prelude-2.30... Building gofer-prelude-2.30... [1 of 1] Compiling Prelude.Gofer ( Prelude/Gofer.hs, dist/build/Prelude/Gofer.o ) /usr/bin/ar: creating dist/build/libHSgofer-prelude-2.30.a Installing library in /home/dons/.cabal/lib/gofer-prelude-2.30/ghc-6.10.1 Registering gofer-prelude-2.30... Reading package info from ""dist/installed-pkg-config"" ... done. Writing new package config file... done. }}} Which bits are useful and useless? I mean at the standard verbosity level. I bet this is useless: {{{ Preprocessing library gofer-prelude-2.30... }}} Does it actually do any pre-processing? See also #475. Useless: {{{ /usr/bin/ar: creating dist/build/libHSgofer-prelude-2.30.a }}} This is produced by the `ar` program. We can however pass it a flag to tell it to be quiet. Not especially useful: {{{ Installing library in /home/dons/.cabal/lib/gofer-prelude-2.30/ghc-6.10.1 }}} This message is generated by Cabal. At the default verbosity level we probably only need something like ""Installing gofer-prelude-2.30..."" Useless: {{{ Reading package info from ""dist/installed-pkg-config"" ... done. Writing new package config file... done. }}} This message is generated by ghc-pkg. We should patch ghc-pkg to not be so verbose by default. That message is only needed at a higher verbosity level. So if we get all these things fixed it'd look like: {{{ $ cabal update Downloading package list from hackage.haskell.org $ cabal install gofer-prelude Resolving dependencies... Downloading gofer-prelude-2.30... Configuring gofer-prelude-2.30... Building gofer-prelude-2.30... [1 of 1] Compiling Prelude.Gofer ( Prelude/Gofer.hs, dist/build/Prelude/Gofer.o ) Installing gofer-prelude-2.30... Registering gofer-prelude-2.30... }}} This is assuming the package in question doesn't actually need any pre-processing. Even the pre-processing message could be elided if we don't think it'll take that long. I wonder if we can get ghc to not tell us the source and object file locations. While it is sometimes useful while hacking, for batch builds we do not need it.",duncan 3, Release,684,Flags combined in the wrong order when nested,Cabal library,1.8.0.2,defect,minor,,new,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, Release,703,"Cabal ""Getting the Code"" web page does not link to Cabal-1.8 branch",miscellaneous,,defect,minor,,new,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, Release,757,Building shared libraries to simplify C++ wrappers,Cabal library,1.8.0.6,enhancement,minor,,new,2010-11-04T05:12:06-0700,2012-01-05T08:01:25-0800,"While Haskell cannot directly link with C++ code via the FFI, it is straightforward and pretty common practice to write wrapper functions which are callable using C conventions. These can be used from the FFI. As an example, consider the method functions setFoo and getFoo in the class Bar. Ignoring const correctness and general good design, this might look something like: {{{ class Bar { private: String& val; public: Bar() { val = """"; } String& getFoo() { return val; } void setFoo(const String& v) { val = v; } } }}} C language wrappers would be something like: {{{ void* ""C"" Bar_constructor() { return (void*) new Bar; } char* ""C"" Bar_getFoo(void* ths) { return (char *) ((Bar*) ths)->getFoo(); } void ""C"" Bar_setFoo(void* ths, char* val) { ((Bar*) ths)->setFoo(String(val)); } }}} Cabal is quite capable of compiling this today, but a problem can arise when the code is linked. The issue is that most C++ code needs to be linked with the C++ standard library, libstdc++ (in the example above, it is needed for the String type). On Windows, the MinGW compiler provided in Haskell Platform provides only a static version of libstdc++. When compiling with GHC, this is not an issue, since static linking to libstdc++ works just fine. However, when loading the library into GHCi, loading fails because no shared version of libstdc++ exists, and fix-up fails when attempting to load libstdc++. The proposed solution is to extend Cabal so that C or C++ code listed in the c-sources stanza can (optionally) be built as a shared library. The shared library can safely be linked with a static libstdc++, which removes the need to export this dependency to Haskell (GHC/GHCi need only link to the shared lib). Concretely, this could be implemented as follows: Add a new section {{{ForeignLibrary}}} This would need to contain the following stanzas: '''foreign-lib-name: ''' This is the basename of the library (i.e. without the 'lib' prefix on Unix, and without any extension (.a, .so, .dll) - as this basename is cross-platform compatible. '''foreign-lib-type: shared | static''' Indicate whether the library should be compiled as a shared library (.dll, .so, .dylib etc) or as a static library (.a, .lib). '''foreign-lib-extralibs: ''' A list of libraries with which the foreign library must be linked. In the case where the library is being built as '''shared''', these will not be added to the list of libraries in the module '''extra-libraries''' stanza. Where the foreign library is built as '''static''' these libraries need to be added to '''extra-libraries''' '''foreign-lib-libdirs: ''' Each path gets added to a -L when compiling C/C++ code. '''foreign-lib-includes: ''' Each path gets added to a -I when compiling C/C++ code. '''foreign-lib-generate-def: True | False''' For Windows only, if the library is being built as a '''shared''' library, generate the corresponding .def file detailing the exported functions. '''cc-options''', '''ld-options''' and '''frameworks''' should function in the same way as they do in Cabal today. I believe that this set of changes would be sufficient to allow wrapping of many C++ libraries without the need for significant customization of the Cabal Simple profile. I believe that it might also simplify porting of foreign libraries which were originally designed for Unix systems to run on Windows, since there would be a standard way to build C/C++ code for inclusion with Haskell modules.",jodonoghue 3, Release,770,cabal is not reading or respecting ~/.cabal/config,Cabal library,1.8.0.6,defect,minor,,new,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, Release,776,cabal check gives invalid duplicate modules warning,Cabal library,1.8.0.2,defect,minor,,new,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, Release,828,Distribution.License datatype and comment weirdness,Cabal library,1.10.1.0,defect,minor,,new,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, Release,900,cabal no longer supports package version tags,Cabal library,1.8.0.6,defect,minor,,new,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, Release,903,Broken links in user guide,User guide,1.8.0.6,defect,minor,,new,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 3, Release,938,cabal test does not tail standard output of the running test executable,cabal-install tool,1.10.2.0,defect,minor,ttuegel,assigned,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 4, Release,219,JHC's generated .ho files should go under dist/,Cabal library,1.2.3.0,defect,minor,,new,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 4, Release,522,Nicer error message when source files are not found.,Cabal library,1.6.0.1,enhancement,minor,,new,2009-03-13T07:07:30-0700,2009-03-13T07:07:30-0700,"It can be confusing sometimes when source files are not found. Eg: {{{ $ runhaskell Setup.lhs build Preprocessing executables for nm8-0.1... Setup.lhs: can't find source for Data.MaybeI in src, dist/build/autogen $ find src/ | grep Data src//Data src//Data/MabyeI.hs }}} In this case it's simply a spelling error, but it's still hard to spot initially. The suggestion is to look look at all files in that directory and do an edit distance match and suggest any similar file. This would also help for case-sensitivity mistakes, see #521.",duncan 4, Release,573,package page could mention used language extensions,hackageDB website,1.6.0.1,enhancement,minor,,new,2009-08-04T14:07:50-0700,2009-08-05T08:20:46-0700,"It would be very convenient to see what language extensions a given package uses at its own hackageDB page. This information could be gathered from LANGUAGE pragmas put in distinct files or from GHC's -X options specified in .cabal file. Complete list of used extensions gives a possibility to see how the package can be used, as it's common practice to choose library judging by such features as portability and usability. For example, new library users could see how they possibly could understand code and documentation, as usage of extensions requires some better knowledge of the language. At the same time, power users could seek appropriate libraries which integrate properly with the list of language extensions they already use. The list of used extensions could be produced by hackageDB scripts every time the package is uploaded to hackageDB, or it can be generated by `cabal sdist` when a source distribution file is generated. ",explicitcall 4, Release,640,Cabal should warn about haskell98 dependencies,Cabal library,HEAD,enhancement,minor,,new,2010-02-26T17:40:40-0800,2010-03-08T08:23:43-0800,"I grepped through my collection of repos, and found dozens upon dozens of uses of the 'haskell98' package (for the full list, see http://community.haskell.org/~gwern/wiki/TODO.page & scroll down). Now, either a package uses the haskell98 module names or it doesn't use them. If the package doesn't actually use any of the old module names, then clearly that's bad and it should be removed and the developer should be warned about this unconditionally. If the package does use the old module names, this is bad too: most every Haskeller got started after the hierarchical modules were made official and general, and the old module names are akin to n+k patterns - they are things that should be removed, because modules using the hierarchical module names are more comprehensible to Haskellers than the old haskell98 modules, which mingle things that have been separated (Foreign comes to mind). So use of haskell98 ought to be warned about here as well. Given that both common situations are bad and ought to be warned about, I think Cabal check ought to emit a warning whenever haskell98 is used. There *may* be some compiler or bootstrapping-related cases where haskell98 is genuinely useful, but I'm doubtful any such exist, and such would be far in the minority anyway. -- gwern",guest 4, Release,692,Hackage should not permit hs files encoded as Latin1,hackageDB website,1.6.0.3,enhancement,minor,,new,2010-05-23T20:04:36-0700,2010-05-26T16:31:35-0700,"They seem innocuous (usually hiding in source code comments, lest they fail to compile) but they make uniformly loading *.hs files into memory a pain, since you have to heuristically determine what encoding a file that is not Unicode-enabled is. We should ban them: it's UTF-8 or nothin'.",ezyang 4, Release,769,HackageDB messes up {-# OPTIONS_HADDOCK hide #-},hackageDB website,1.8.0.6,defect,minor,,new,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 4, Release,839,hackage: produce haddock documentation for executable only projects as well,hackageDB website,1.8.0.6,enhancement,minor,,new,2011-04-28T15:23:00-0700,2012-01-05T08:02:51-0800,"Hackage currently only contains haddock documentation for ""libraries"". However, it'd be really cool to be able to see the source code of ""executable"" only projects as well. If the project is not haddock'ized, then a simple hscolor'ed html source base would be fine as well (like in GitHub). One of the more common use cases of Hackage is to look at other people's code, even for projects that you wouldn't download. This can go along way in making that much more pleasurable. Alternatively, the user can specify a cabal flag to indicate if he wants browsable source code to be produced in case of executable only projects. ",guest 4, Release,876,Build fails for zlib 0.5,Cabal library,HEAD,defect,minor,,reopened,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 4, Release,915,Convert to modular use of type-safe URLs,Hackage 2 server,1.8.0.6,enhancement,minor,,new,2012-02-14T09:08:51-0800,2012-02-14T10:48:22-0800,,bgamari