- cabal-devel - Haskell.org

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3
by Björn Peemöller 17 Mar '15

17 Mar '15

Am 16.03.2015 um 21:30 schrieb Austin Seipp: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ The current version of cabal-install located at Hackage can not be installed for the RC because of the following dependency error: Setup: At least the following dependencies are missing: filepath >=1.0 && <1.4 The problem is that cabal-install require filepath < 1.4, while the RC ships with filepath-1.4. This issue [1] has already been solved in cabal-install, so a new release available at Hackage would be desirable. Regards, Björn [1]: https://github.com/haskell/cabal/issues/2461

1 0

[patch] lincenses warning
by Francesco Ariis 09 Mar '15

09 Mar '15

Dear Cabal developers, spurred by this discussion on haskell-cafe [1], I attach a small patch on licence warnings. It: - reverts AllRightsReserved as PackageDistInexcusable, as it was before this commit [2]. Reading the comments in Check.hs, this datatype is for issues which "[are] OK in the author's environment but [are] almost certain to be a portability problems for other environments", which I think it is the case. - adds a PackageDistSuspicious warning on OtherLicense. The text of the warning encourages the developer to choose from licences suggested by the OSI or FSF, if they don't want to use a licence recognised by cabal. Thanks -Francesco [1] http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html [2] https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a55…

3 7

Issues to close
by Justin Leitgeb 28 Feb '15

28 Feb '15

Hi, I've gone through a dozen or so cabal issues that are old, and which seem to have been resolved or are not serious enough to keep open. I've commented on all of those tickets with reasons I think they should be closed. If someone with permissions to close tickets on GitHub would go through this list I'd appreciate it. https://gist.github.com/jsl/93623588e788c4ad34d6 Also, I found it helpful to filter by open issues that haven't been updated since May 2012 <https://github.com/haskell/cabal/issues?q=is%3Aissue+is%3Aopen+updated%3A%3…>. There are still another 36 stale issues currently in this category if anyone wants to take a look. :) Thanks! Justin -- Justin Leitgeb <http://justinleitgeb.com> Twitter: @justinleitgeb <http://twitter.com/justinleitgeb> Github: @jsl <https://github.com/jsl> Co-Founder and CTO, Stack Builders Inc. <http://www.stackbuilders.com>

2 1

Status of Cabal-2.0 plans?
by Thomas Tuegel 27 Feb '15

27 Feb '15

Hi cabal-devel, Is anyone actively working toward the Cabal-2.0 plan [1]? I'm referring primarily to the plan to split up the Cabal library. (I think the multi-package ideas are good, but orthogonal.) Thanks, -- Thomas Tuegel [1]. https://github.com/haskell/cabal/wiki/Cabal-2

1 0

Looking for a new release manager for cabal
by Johan Tibell 27 Feb '15

27 Feb '15

(bcc: haskell-cafe) Hi, After about 3 years of cabal releases I'm looking for someone else to take over the responsibility as cabal release manager. As a release manager I try to keep on top of pull requests, make releases, and make sure bugs get triaged and bugfixes get release. Anyone interested? -- Johan

5 4

Cabal-1.22 keyed library filepaths
by Jens Petersen 24 Feb '15

24 Feb '15

Hi, I see that with Cabal-1.22, library paths are now of the form: /usr/lib64/ghc-7.10.0.20141222/direc_3m6Ew9I164U5MIkATLCdb8/ libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so etc. Is the 5 character truncation of package names (and no version) necessary? It makes it pretty hard to see at a glance what package a particular directory or file belongs to and seems there is no easy way to work out the package version without referring to the package.conf file/dir. If possible I would prefer a filepath format like: /usr/lib64/ghc-7.10.0.20141222/directory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8/ libHSdirectory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so Would that be feasible/make sense? Jens

2 3

New features should have unit tests
by Johan Tibell 10 Feb '15

10 Feb '15

Lately it's become more and more clear to me that we cannot release (or work) on cabal effectively without often breaking previously working features. Cabal is a big project by now and has a large surface area, both in terms of features and in terms of systems (e.g. compilers, OSes, etc) it interacts with. On top of that, Cabal, being a glorified system for doing command line I/O, gets less support from the type system than your average Haskell program. I strongly suggest that future feature additions come with unit tests, preferable of the fast kind in Cabal/tests/UnitTests.hs but at the very least of the kind in Cabal/tests/PackageTests (and similarly for cabal-install). We also need to spend some time adding tests for existing features. A good start would be to look at the regressions we saw in 1.22 and writing test cases for those. -- Johan, release manager

1 0

building without the global package-db
by Chris Dornan 08 Feb '15

08 Feb '15

Hi, I am trying to build a self-contained package-db that is independent of the global package-db. I am using ghc-7.8.4 and cabal-1.22.0.0. I create an empty package-db in package-db and type the following: cabal-1.22.0.0 install --package-db=clear --package-db=package-db bytestring-0.10.4.1 but I get cabal-1.22.0.0: With current ghc versions the global package db is always used and must be listed first. This ghc limitation may be lifted in future, see http://hackage.haskell.org/trac/ghc/ticket/5977 5977 was fixed 3 years ago -- should the error message be updated? I am told that cabal allows building without the global package db, but how? Cheers, Chris

1 0

Getting ready for the 1.22.1.0 release, please verify that your fixes are in
by Johan Tibell 06 Feb '15

06 Feb '15

I've merged all the patches that I'm aware of that needs merging for this patch release*. Here's the complete list: https://github.com/haskell/cabal/compare/Cabal-v1.22.0.0...1.22 Please verify that all the fixes that you need are included. The only open issue I'm aware of is https://github.com/haskell/cabal/issues/2375. * Technically it's 1.22.1.0, but in spirit it's a patch release.

1 0

making cabal-install into a library?
by Jens Petersen 21 Jan '15

21 Jan '15

Hi, For a while I have been thinking cabal-install should really be a library. Has anyone considered or thought about this? I am wondering how much work it may be? Best wishes, Jens

4 4