February 2015 - cabal-devel

inactive issues
by lennart spitzner 22 Apr '15

22 Apr '15

hi, i noticed today's run at the closing "inactive" issues on the tracker. i would like to to ask an innocent question: what exactly is the benefit of this action? (i disclose that it seems to me that valid, if inactive, issues are being closed, which i do not like. but before complaining, i want to know the counter-arguments). Lennart

6 10

Issues to close
by Justin Leitgeb 01 Mar '15

01 Mar '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 25 Feb '15

25 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 11 Feb '15

11 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 07 Feb '15

07 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