August 2013 - cabal-devel

Lag in new hackage mirroring of old hackage
by Gregory Weber 11 Sep '13

11 Sep '13

Hello, I want to report some lag in the mirroring of old hackage by the new hackage. "Note: we are mirroring packages from the old server (currently every 30min) so it is suitable to use as your main hackage server with some caveats: because we are allowing package authors to upload (as well as the mirroring) then you may find a slightly different set of packages on this server. " -- http://new-hackage.haskell.org/ viewed on August 2, 2013 But for some elm packages, I just noticed today, the versions on new hackage are considerably more than 30 minutes older than those on old hackage: Elm: new hackage 0.7.1.1 uploaded January 25, 2013 old hackage 0.8.0.3 uploaded May 28, 2013 elm-server: new hackage 0.7 uploaded January 4, 2013 old hackage 0.8 uploaded May 22, 2013 I've been happily using the new hackage for some weeks now, and occasionally enjoying the new features. Other than this lag, it's been a good experience. Thanks! -- Gregory D. Weber, Ph. D. http://mypage.iu.edu/~gdweber/ Associate Professor of Informatics Tel (765) 973-8420 Indiana University East FAX (765) 973-8550

3 2

Hackage 2 trustees
by Erik Hesselink 11 Sep '13

11 Sep '13

Hi all, I just upgraded our internal hackage to the latest HEAD. I found that the behavior of the 'trustees' group has changed. Previously, they could upload any (existing) package, but that doesn't work anymore. This functionality was very useful for us, since otherwise, we'd have to add all our coders as maintainers to all our packages. I've patched our local code, but my question is: * Is this a bug and should I push a patch? * Is this intended and should I push a patch to the text at http://hackage.typlab.com/packages/trustees/, since it doesn't correspond to the current behavior? Regards, Erik

2 1

Re: Setting up a build bot
by Johan Tibell 01 Sep '13

01 Sep '13

I've been running a Jenkins build bot for cabal for quite a while: http://ci.johantibell.com/job/cabal/ It's not as good as it could be, because the Cabal test suite isn't in the best shape. In particular the InternalLibrary tests are failing at the moment and I think it's because the tests actually modify the shared package DB (i.e. the user DB)! If you could figure out why they're failing and/or make the test suite more robust (i.e. it should create a new empty package DB every time) that would be great. On Sat, Aug 31, 2013 at 9:43 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com>wrote: > Hi all, > I'm at Zurihac and I'm experimenting with setting up Travis > integration for cabal (I've never used Travis before); Duncan Coutts > told me to coordinate with you, since you've been also thinking about > this. > > I'm also trying out using Ceh (presented at this ZuriHac itself, > presentation visible by downloading > > https://github.com/errge/ceh/blob/master/doc/fpafternoon-zurich-20130829/fi… > ) > to get an updated Haskell version (rather than the default Haskell > platform from last year); if this works, we can maybe try out testing > cabal on different versions. > > I'll keep playing with this for a while. > Comments and suggestions are welcome! > > Cheers, > Paolo > > -- > Paolo G. Giarrusso - Ph.D. Student, Philipps-University Marburg > http://www.informatik.uni-marburg.de/~pgiarrusso/ >

3 2

Cabal/cabal-install 1.18 RC2
by Johan Tibell 30 Aug '13

30 Aug '13

Hi, I've prepared another RC, including some fixes. This one is based on 9f374ab45e62924506b992db9157c970c7259a03 on the master branch. If we don't see any problems with this RC the next few days, I'll release it as 1.18. Again, to install the RC just run: cabal install http://johantibell.com/files/Cabal-1.18.0-rc2.tar.gz http://johantibell.com/files/cabal-install-1.18.0-rc2.tar.gz These are the changes since RC1: 9f374ab Give the xxx_HOST_OS and xxx_HOST_ARCH options that were probed from ghc's target platform, rather than assuming HOST == BUILD. This fixes things for cross compiling. 0bd367f Fix the 'index.cache' up-to-date check. 323460e Unit tests: use configure GHC 473f76a Merge pull request #1440 from 23Skidoo/ghc-info-ignore-ghc-options 85cb83d Merge pull request #1441 from 23Skidoo/repl-extralibs 2d938de Rename 'pref' to 'libTargetDir'. d9283d2 Rearrange the code a bit. 7802fa0 Ignore 'ghc-options' when parsing 'ghc --info' output. 218c6bb Add 'suppressOverrideArgs'. 43624cf Formatting. a3bbf4c Pass linker options when loading *libraries* in GHCi. c977ddd Merge changes from GHC HQ fork 5fa5c41 Merge branch 'master' into roles dd3ca38 Fix link to users' guide. 2803d87 Added a new extension (RoleAnnotations) to the list -- Johan

5 6

Cabal-1.18.0 and cabal-install-1.18.0 release candidates (please test)
by Johan Tibell 28 Aug '13

28 Aug '13

Hi all, We're close to a new release of Cabal/cabal-install and I'd appreciate some help in testing the new release. To install the release candidate, simply run: cabal install http://johantibell.com/files/Cabal-1.18.0.tar.gz http://johantibell.com/files/cabal-install-1.18.0.tar.gz Please try on different OSes if you have several available. Report bugs at https://github.com/haskell/cabal/issues *Things to try* This is not a complete list of new features (and bugs fixed)! *Sandboxing* Sandboxes help prevent "dependency hell" by having each project you're working on use a separate package database to install its dependencies in. Try it out on one of your projects like so: cd my-pkg cabal sandbox init # only once cabal install --only-dependencies cabal configure cabal build *GHCi support* The new cabal repl commands lets you load up your library inside GHCi without lots of command line fiddling. Just run cabal repl instead of cabal build and play around without your library. *Known issues to be fixed before release* https://github.com/haskell/cabal/issues/1439 Cheers, Johan

2 2

Gearing up for a 1.18 release
by Johan Tibell 26 Aug '13

26 Aug '13

Hi all, The sandbox functionality now works well enough that I think we should let it out in the wild. I've created a 1.18 release branch at https://github.com/haskell/cabal/tree/cabal-install-1.18 My intention is to make any necessary bug fixes on that branch before the release and then merge those fixes into master once the release is done (i.e. using a work flow similar to http://nvie.com/posts/a-successful-git-branching-model/ but without the develop branch). Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further. P.S. In the future I hope we can make a release every 3-6 months instead of the current almost yearly release cycle. Cheers, Johan

7 27

Cabal Hacking at ZuriHac 2013
by Dominic Steinitz 25 Aug '13

25 Aug '13

Hi All, I and a small team hacked on Cabal at OdHac earlier this year (http://www.haskell.org/haskellwiki/OdHac/Projects#Cabal) I am going to ZuriHac (http://www.haskell.org/haskellwiki/ZuriHac2013) next week and will carry on going through the issues list (https://github.com/haskell/cabal/issues?labels=&milestone=&page=1&state=open) But let me know if there are any items that people would really like implemented / fixed and I (we) can work on those. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

GHCJS support for Cabal
by Luite Stegeman 23 Aug '13

23 Aug '13

hi all, We're readying the GHCJS [1] compiler for the first release, to coincide with GHC's 7.8.1 release. For now, GHCJS is a stand-alone executable that uses the GHC API and manages its own package database. We've been maintaining a Cabal patch with the intention to get it merged in 1.18, but now that release appears to be earlier than I expected (thanks Carter for warning me!) The current diff is here (the js-sources / extra-js-files field additions would be left out for 1.18, and some of the Distribution.Simple.GHC module changes can be cleaned. Give me a few days if you want a full patch for review): https://github.com/ghcjs/cabal/compare/ghcjs I'm not sure if it's still feasible to get the whole thing in (I have time to hack on it the coming weeks and can discuss at ZuriHac) 1.18, but if not, there are some very small parts that change the API a bit, that could perhaps go in 1.18, postponing full GHCJS support to 1.18.1 or similar. Does that sound reasonable? Overview of the changes: 1. CompilerId gets an extra field, indicating that compiler x is based on compiler y. Both compilers have their own version. impl(x >= x-version), impl(y >= y-version) flags would both be true for this flavor. (This is the public API change). GHCJS is added as a compiler flavor 2. Support for the GHCJS flavor is plumbed throughout Cabal 3. The Distribution.Simple.GHC module exports internal functions, some of those are modified so the program can be passed in explicitly. For most things, the Distribution.Simple.GHCJS module calls back to the GHC module pretending to have the version of the underlying GHC. 1. changes existing API a tiny bit, so that would be nice to go in 1.18 if still possible. 3. is a bit messy, but doing it this way appears to avoid by far the most code duplication. Perhaps some restructuring of the GHC module would make it better, then it could be done without touching exported API. I'd be happy to hear comments or suggestions and clean it up a bit. luite [1] https://github.com/ghcjs

2 2

patch applied (hackage-server): "Use -threaded for the doc client " and 2 others
by devnull＠community.haskell.org 19 Aug '13

19 Aug '13

Mon Aug 19 16:43:08 BST 2013 Edsko de Vries <edsko(a)well-typed.com> * Use -threaded for the doc client Ignore-this: 6bdd91218f06fd259e1b0cf2fc5cb20f This seems to be necessary for correct handling of CTRL-C, although I do not understand why. M ./hackage-server.cabal -1 +3 Mon Aug 19 16:49:59 BST 2013 Edsko de Vries <edsko(a)well-typed.com> * Trivial continuous doc-building script Ignore-this: b2a25cd42dfd7f5e59f695e81dc78cf A ./rundocs.sh Mon Aug 19 17:02:49 BST 2013 Edsko de Vries <edsko(a)well-typed.com> * Add TODOs Ignore-this: 316c30306e7fb23b4f08d43cbd74156e M ./TODO -2 +20

1 0

patch applied (hackage-server): "Remove redundant check"
by devnull＠community.haskell.org 19 Aug '13

19 Aug '13

Mon Aug 19 14:14:56 BST 2013 edsko(a)well-typed.com * Remove redundant check Ignore-this: 9e9ecc306bf94d1d6b70557f9af5b176 M ./BuildClient.hs -13 +10

1 0