October 2009 - cabal-devel

writeFileAtomic Problem? was: New patch for Ticket #199 - support for a world file
by Peter Robinson 30 Oct '09

30 Oct '09

Does the new patch Wed Oct 28 17:31:48 CET 2009 Duncan Coutts <duncan(a)haskell.org> [Allow building with base 4 change the behaviour of 'writeFileAtomic'? After applying it, writeFileAtomic doesn't seem to update the world file anymore. Peter 2009/10/28 Peter Robinson <thaldyron(a)gmail.com>: > 2009/10/28 Duncan Coutts <duncan.coutts(a)googlemail.com>: >> On Tue, 2009-09-29 at 22:27 +0200, Peter Robinson wrote: >>> [Updated patch for world-file support >> > >From a manual look at the patch it looks good. Since you're re-sending, >> if you can check it still applies to the current state of the darcs repo >> that'd be great. > > The attached patch can be applied to the latest darcs checkout. > Btw, I'm wondering if there's a better name for the "--one-shot" option. > > Peter >

1 0

Re: ghc-options: -threaded breaks some arches
by twb＠cybersource.com.au 29 Oct '09

29 Oct '09

Cabal developers, Joachim Breitner <nomeata(a)debian.org> writes: > Am Sonntag, den 16.08.2009, 17:47 +0100 schrieb Neil Mitchell: >> > trying to build hlint does not work on some architectures (at least >> > alpha, s390, mips) where no threaded RTS is available. An example build >> > log is available at >> > http://buildd.debian.org/build.php?arch=alpha&pkg=hlint&ver=1.6.4-1 >> > >> > This is caused by >> > ghc-options: -fno-warn-overlapping-patterns -threaded >> > in your hlint.cabal file. >> > [..] >> > If not, would it be possible to make this option dependent >> > on the availability of a threaded RTS (either by direct support in cabal >> > for checking it, similar to os(..) checks, or by passing a "-fthreaded" >> > flag to setup configure)? >> >> Yes, of course. What suits you? Any os checks would go wrong, so an >> -fnothreaded flag seems sensible? I'd still like threading to be the >> default. > > that would be a start, thanks. > > Of course I’d prefer if cabal had automatic support for this. I guess is > does not ATM, so for now the flag is ok, and I’m hereby telling the > Cabal people about this :-) Did a trac ticket ever get created for this? This affects Darcs 2.3.0, so I'm about to add an -f-threaded to darcs.cabal for 2.4.0, because I don't know how to tell Cabal "use -threaded iff you can".

2 1

Cabal-install and GHC
by Simon Peyton-Jones 22 Oct '09

22 Oct '09

Dear Cabal developers As you know, we are almost ready to release GHC 6.12. The Glorious Master Plan is that, because of your fantastic efforts with Cabal and Hackage, we are getting out of the libraries business, so that the 6.12 release will be "no batteries included"; Joe User will wait until the Haskell Platform release, which (on the 6-month timetable) would be in March 2010. Thank you for this. Although we've tested GHC 6.12 against all our own tests, we are reluctant to release without having tested it against Hackage. Doing so might reveal serious bugs in GHC or (even worse) something wrong with the APIs that come with GHC, and we are not suppose to change APIs after release. Alas, to test GHC against Hackage we need a working cabal-install. But cabal-install is currently broken, because of the recent changes to package ids, a change instigated by us but I think one you welcome. So in effect, we do still have a dependency on cabal-install. As a result, the GHC 6.12 release is stalled, awaiting a working cabal-install. We could go ahead and release, but we want people to test the release, and they are unlikely to do so without cabal-install. So there doesn't seem much point. So: Could you [I'm afraid this means you, Duncan] give us a *date* for the new cabal-install, so that we can in turn tell our users what to expect? I'm certainly not expecting you to drop everything to do this. Even if you say "Christmas" I'm sure we'll find a way to live with it, by staying with a Release Candidate for 6.12. [Presumably it must be done way before the Haskell Platform release, so that people can test the HP itself.] Regardless, it really would help our planning to know. Many thanks Simon

3 3

[Hackage] #382: 'cabal ghci' mode
by Hackage 21 Oct '09

21 Oct '09

#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ 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 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 11

patch applied (cabal): Only pass -B... to gcc for GHC < 6.11
by Ian Lynagh 20 Oct '09

20 Oct '09

Mon Oct 12 07:47:07 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Only pass -B... to gcc for GHC < 6.11 It is no longer needed in 6.12. M ./Distribution/Simple/GHC.hs -4 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091012144707-3fd76-fcace98d…

1 0

cabal-install for ghc 6.12 rc1
by Robin Green 20 Oct '09

20 Oct '09

Hi, I've been trying to modify cabal-install so that it builds and works on ghc 6.12 rc1. Made some easy fixes, then came upon this compilation error: Building cabal-install-0.7... [14 of 35] Compiling Distribution.Client.IndexUtils ( Distribution/Client/IndexUtils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/IndexUtils.o ) Distribution/Client/IndexUtils.hs:111:6: Couldn't match expected type `Distribution.InstalledPackageInfo.InstalledPackageInfo' against inferred type `AvailablePackage' In the expression: AvailablePackage {packageInfoId = pkgid, packageDescription = pkg, packageSource = RepoTarballPackage repo} In the first argument of `PackageIndex.fromList', namely `[AvailablePackage {packageInfoId = pkgid, packageDescription = pkg, packageSource = RepoTarballPackage repo} | (pkgid, pkg) <- pkgs]' In the second argument of `($)', namely `PackageIndex.fromList [AvailablePackage {packageInfoId = pkgid, packageDescription = pkg, packageSource = RepoTarballPackage repo} | (pkgid, pkg) <- pkgs]' Uh-oh. This looks like a big chunk of work (the package index type is no longer polymorphic in cabal 1.8.0). Has anyone else worked on this? Is there some secret branch of cabal-install somewhere that works on ghc 6.12? -- Robin

2 1

Reverse dependencies in Hackage
by Roel van Dijk 14 Oct '09

14 Oct '09

A few weeks ago I wrote a patch that adds reverse dependencies to hackage [1]. I have know hosted a small test hackage which demonstrates this feature. It can be found here: http://bifunctor.homelinux.net/~roel/hackage Browse to your favorite packages and find out how much other packages depend on them! I also noticed that work is underway to implement a new hackage-server [2] based on happstack. If people find this feature useful I could also write a patch against the hackage-server code base [3]. Regards, Roel van Dijk [1] - http://hackage.haskell.org/trac/hackage/ticket/576 [2] - http://sparky.haskell.org:8080/ [3] - http://code.haskell.org/hackage-server/

3 2

'cabal upload' and errors
by Conal Elliott 12 Oct '09

12 Oct '09

It would be great if 'cabal upload' passed on error messages from the server. Currently I just get a message like ERROR: tarballs/reactive-0.11.1.tar.gz: 400 Error in upload Thanks, - Conal

2 1

darcs patch: cabal init
by Brent Yorgey 11 Oct '09

11 Oct '09

Hi all, I've attached the (long-awaited) patch adding a 'cabal init' command. There's still lots that could be improved but I think it's now at a useful/complete enough state to be released into the wild. Credit also goes to Benedikt Huber who developed a lot of the automagic-guessing heuristic goodness. Naturally, comments/suggestions/improvements welcome! -Brent

1 0

How not to indirectly depend on multiple versions of the same package?
by Bas van Dijk 10 Oct '09

10 Oct '09

Hello, My usb package fails to build on hackage: http://hackage.haskell.org/package/usb-0.2 usb depends both on bytestring and text but text also depends on bytestring. Now, during configuring, a different bytestring version is choosen than the one text was build with: http://hackage.haskell.org/packages/archive/usb/0.2/logs/failure/ghc-6.10 ... Dependency bytestring ==0.9.*: using bytestring-0.9.1.5 Dependency text ==0.4.*: using text-0.4 Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. ... http://hackage.haskell.org/packages/archive/text/0.4/logs/success/ghc-6.10 ... Dependency bytestring >=0.9 && <1.0: using bytestring-0.9.1.4 ... Is it possible to specify in my cabal file that I depend on the same bytestring version as to one text was build with? If not, what is the best way to get my package to build on hackage? Thanks, Bas

2 2