February 2010 - cabal-devel

[Hackage] #626: Package build error due to unicode
by Hackage 18 Mar '10

18 Mar '10

#626: Package build error due to unicode --------------------------------+------------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- 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.… 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) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/626> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #576: Show reverse dependencies
by Hackage 16 Mar '10

16 Mar '10

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide exmaples 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

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

08 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 06 Mar '10

06 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] #638: cabal install cabal-install fails
by Hackage 06 Mar '10

06 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 06 Mar '10

06 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 06 Mar '10

06 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 06 Mar '10

06 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 06 Mar '10

06 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