December 2011 - cabal-devel

[Hackage] #711: cabal install cabal-install fails for OSX dmg
by Hackage 05 Jan '12

05 Jan '12

#711: cabal install cabal-install fails for OSX dmg ----------------------------+----------------------------------------------- Reporter: hartrock | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Mac OS | ----------------------------+----------------------------------------------- After installing http://hackage.haskell.org/platform/2010.1.0.0/haskell- platform-2010.1.0.1-i386.dmg the following occurs: see attached file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/711> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #829: Happstack overrides MissingH
by Hackage 05 Jan '12

05 Jan '12

#829: Happstack overrides MissingH ----------------------------+----------------------------------------------- Reporter: mcandre | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: Mac OS | ----------------------------+----------------------------------------------- I just updated to the new Haskell Platform 2011.2.0.0-i386. Someone needs to update Trac to let us input these version numbers into the relevant fields: The GHC version is 7.0.2, NOT 6.12.3. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.2 $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library }}} I've got a [https://github.com/mcandre/doeshappstackwork web app] that needs Happstack for the server API and MissingH for the string API. But I can't install the packages at the same time. {{{ $ cabal install missingh $ runhaskell doeshappstackwork.hs doeshappstackwork.hs:8:8: Could not find module `Happstack.Server' $ cabal install happstack-server $ runhaskell doeshappstackwork.hs doeshappstackwork.hs:14:8: Could not find module `Data.String.Utils' $ cabal install missingh $ runhaskell doeshappstackwork.hs doeshappstackwork.hs:8:8: Could not find module `Happstack.Server' ... And so on }}} This is madness! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/829> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #824: cabal install --enable-tests does not install test dependencies.
by Hackage 05 Jan '12

05 Jan '12

#824: cabal install --enable-tests does not install test dependencies. ---------------------------------+------------------------------------------ Reporter: creswick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Cabal install normally installs all the necessary project dependencies; however, this is not happening for the dependencies specified in the Test- suite stanzas. Here's an example cabal file: {{{ Name: foo Version: 1.0 License: BSD3 Cabal-Version: >= 1.9.2 Build-Type: Simple executable foo main-is: foo.hs build-depends: base , xml == 1.3.7 Test-Suite test-foo type: exitcode-stdio-1.0 main-is: test-foo.hs build-depends: base , QuickCheck >= 2.0 }}} `cabal install` will install xml if necessary, then build foo, but `cabal install --enable-tests` complains that QuickCheck is not available: {{{ $ cabal install --enable-tests Resolving dependencies... Configuring foo-1.0... cabal: At least the following dependencies are missing: QuickCheck >=2.0 cabal: Error: some packages failed to install: foo-1.0 failed during the configure step. The exception was: ExitFailure 1 }}} This causes some problems when building tests with `cabal-dev`: https://github.com/creswick/cabal-dev/issues#issue/10 (Using cabal-install 0.10.2 built with Cabal 1.10.1.0) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/824> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #828: Distribution.License datatype and comment weirdness
by Hackage 05 Jan '12

05 Jan '12

#828: Distribution.License datatype and comment weirdness ----------------------------+----------------------------------------------- Reporter: sli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- 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/ . -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/828> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #811: test-suite type not detected
by Hackage 05 Jan '12

05 Jan '12

#811: test-suite type not detected ----------------------------+----------------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I just installed the latest `cabal`: {{{ $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library }}} I'm trying to rewrite the custom test-suite of my [http://hackage.haskell.org/package/threads threads] package to the new Cabal test-suite feature. The original `.cabal` contains: {{{ ... executable test-threads main-is: test.hs ... }}} When I rewrite that to: {{{ ... test-suite test-threads type: exitcode-stdio-1.0 main-is: test.hs ... }}} And than configure it, I get the following error: {{{ $ cabal configure cabal: threads.cabal:60: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 }}} I attached the package. Duncan on `#haskell` figured out that if a .cabal contains conditionals, like the one I have, the bug appears. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/811> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #697: Add "cabal build-dep" command
by Hackage 05 Jan '12

05 Jan '12

#697: Add "cabal build-dep" command ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The [http://hackage.haskell.org/trac/ghc/wiki/HackageTesting hackage testing tool] needs a "cabal build-dep" command to work. I had an inadequate patch that was good enough for my experiments (http://osdir.com/ml/cabal-devel@haskell.org/2010-01/msg00029.html) but lack the familiarity with the cabal-install design necessary to implement it properly. Sadly, the patch no longer applies to cabal-install HEAD, and regardless, it would make things a lot easier if it Just Worked out of the box. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/697> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #709: cabal doesn't handle error conditions from getAppUserDataDirectory
by Hackage 05 Jan '12

05 Jan '12

#709: cabal doesn't handle error conditions from getAppUserDataDirectory ----------------------------+----------------------------------------------- Reporter: creswick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Windows | ----------------------------+----------------------------------------------- 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 ). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/709> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #698: Hayoo! links on Hackage are broken
by Hackage 05 Jan '12

05 Jan '12

#698: Hayoo! links on Hackage are broken --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.3 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- The links to Hayoo! on Hackage point to http://holumbus.fh- wedel.de/hayoo/hayoo.html, which is returning a 404 File Not Found error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/698> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #693: Missing instructions for running Cabal's testsuite
by Hackage 05 Jan '12

05 Jan '12

#693: Missing instructions for running Cabal's testsuite ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/693> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #778: ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=...
by Hackage 05 Jan '12

05 Jan '12

#778: ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=... ----------------------------+----------------------------------------------- Reporter: nartamonov | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: | ----------------------------+----------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/778> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3