March 2010 - cabal-devel

[Hackage] #640: Cabal should warn about haskell98 dependencies
by Hackage 09 Mar '10

09 Mar '10

#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- 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 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/640> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #636: cabal-install: premature end of compressed stream
by Hackage 07 Mar '10

07 Mar '10

#636: cabal-install: premature end of compressed stream ---------------------------------+------------------------------------------ Reporter: migmit | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ $ cabal -v3 update 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 Date: Thu, 18 Feb 2010 11:07:11 GMT Server: Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2 Last-Modified: Thu, 18 Feb 2010 04:35:56 GMT ETag: "1bda0bd-167306-47fd880b74300" Accept-Ranges: bytes Content-Length: 1471238 Content-Type: application/x-tar Content-Encoding: x-gzip Downloaded to C:\Documents and Settings\mmitrofanov\Application Data\cabal\packages\hackage.haskell.org\00-index.tar.gz cabal.exe: Codec.Compression.Zlib: premature end of compressed stream Windows, CygWin, GHC 6.10.4 ghc-pkg: $ ghc-pkg list D:/ghc/ghc-6.10.4\package.conf: Cabal-1.6.0.3, Cabal-1.8.0.2, HTTP-4000.0.9, HUnit-1.2.0.3, QuickCheck-1.2.0.0, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.4), ghc-prim-0.1.0.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.2, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.4, xhtml-3000.2.0.1, zlib-0.5.2.0 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/636> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #641: Cabal-1.8 install of darcs installs manpage with permission 0600
by Hackage 07 Mar '10

07 Mar '10

#641: Cabal-1.8 install of darcs installs manpage with permission 0600 ----------------------------+----------------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/641> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #638: cabal install cabal-install fails
by Hackage 07 Mar '10

07 Mar '10

#638: cabal install cabal-install fails ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.1 Platform: Mac OS | ----------------------------+----------------------------------------------- On my Mac OS X (Snow Leopard) I get the following error when trying to install the current version of cabal... Linking dist/build/cabal/cabal ... Undefined symbols: "_networkzm2zi2zi1zi1_NetworkziSocket_a111_info", referenced from: _sop4_info in libHSHTTP-4000.0.6.a(TCP.o) _sorZ_info in libHSHTTP-4000.0.6.a(TCP.o) _souN_info in libHSHTTP-4000.0.6.a(TCP.o) _soyj_info in libHSHTTP-4000.0.6.a(TCP.o) "_networkzm2zi2zi1zi1_NetworkziSocket_a226_closure", referenced from: _HTTPzm4000zi0zi6_NetworkziTCP_a21_srt in libHSHTTP-4000.0.6.a(TCP.o) _HTTPzm4000zi0zi6_NetworkziTCP_a22_srt in libHSHTTP-4000.0.6.a(TCP.o) _HTTPzm4000zi0zi6_NetworkziTCP_a23_srt in libHSHTTP-4000.0.6.a(TCP.o) _HTTPzm4000zi0zi6_NetworkziTCP_a26_srt in libHSHTTP-4000.0.6.a(TCP.o) "_networkzm2zi2zi1zi1_NetworkziSocket_a226_info", referenced from: _sorl_info in libHSHTTP-4000.0.6.a(TCP.o) _soub_info in libHSHTTP-4000.0.6.a(TCP.o) _sox2_info in libHSHTTP-4000.0.6.a(TCP.o) _soAv_info in libHSHTTP-4000.0.6.a(TCP.o) ld: symbol(s) not found Thanks, John Launchbury -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/638> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #635: Display checksum of tarball on Hackage
by Hackage 07 Mar '10

07 Mar '10

#635: Display checksum of tarball on Hackage --------------------------------+------------------------------------------- Reporter: dons | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/635> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #634: cabal-install does not recognise internal capability from Cabal 1.8
by Hackage 07 Mar '10

07 Mar '10

#634: cabal-install does not recognise internal capability from Cabal 1.8 ---------------------------------+------------------------------------------ Reporter: kowey | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If I understand correctly, Cabal 1.8 introduced a feature that lets our executable depend on a library from the same package (is this #89?). We would very much like to use this for Darcs as this would speed up our build times dramatically, but it seems that the cabal-install tool does not know how to deal with this it yet. This means we can do "runghc Setup configure" but not "cabal configure" Here is the patch that uses this for darcs: http://bugs.darcs.net/patch147 PS. I think this tracker may need to be updated with new versions (currently stops at 1.6) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/634> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #632: After updating cabal-install Zlib incompatible version
by Hackage 07 Mar '10

07 Mar '10

#632: After updating cabal-install Zlib incompatible version ---------------------------------+------------------------------------------ Reporter: captainCrash | Owner: Type: defect | Status: new Priority: high | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ When I ran cabal update it suggested that I had to update cabal-install. Which I did. Then running cabal update again gave the error: > cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version Any other action requiring ZLib also fails. I downloaded a new version of cabal itself, untarred it, and cabal installed it. The problem still exists. I run ZLib version 0.5.2.0. I have GHC version 6.10.3. And run this all on Mac OS X 10.6.3 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/632> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #633: Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs
by Hackage 07 Mar '10

07 Mar '10

#633: Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs ----------------------------+----------------------------------------------- Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/633> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Cabal bugs on Windows
by Neil Mitchell 07 Mar '10

07 Mar '10

Hi, I get this error on multiple machines running Windows, with both GHC 6.10.4 and 6.12.1: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library $ cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: premature end of compressed stream This is the same error as reported on http://hackage.haskell.org/trac/hackage/ticket/636. I'm also not the only Windows user I know who has got this. Is Cabal broken in some way? It's fairly serious and annoying that GHC 6.12.1 can't be used with Cabal. Thanks, Neil

1 1

[Hackage] #517: make cabal install command support haddock options
by Hackage 03 Mar '10

03 Mar '10

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ 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) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9