- cabal-devel - Haskell.org

cabal-install-1.18 on GHC-6.12
by Henning Thielemann 30 Oct '13

30 Oct '13

I am trying to compile cabal-install-1.18.0.2 on GHC-6.12.1. It aborts with: ... [12 of 73] Compiling Distribution.Client.Compat.Semaphore ( Distribution/Client/Compat/Semaphore.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Compat/Semaphore.o ) Distribution/Client/Compat/Semaphore.hs:12:26: Module `Control.Exception' does not export `mask_' That is, you must either narrow the dependency on 'base' or avoid 'mask_'.

5 6

how to package cabalized binaries with assets for a package manager?
by Carter Schonwald 28 Oct '13

28 Oct '13

Hey All, the mac homebrew folks are trying to understand how they can distro haskell tools like Pandoc, and I"m out of my league in terms of the cabal / cabal-install sandbox fu needed for them to do it correctly, esp since Pandoc is one of those tools that needed a bunch of asset files installed, could someone who's more comfortable / familiar with how to do it right step in to help em out? http://librelist.com/browser//homebrew/2013/10/25/building-ghc-takes-30-min… thanks -Carter

2 2

Re: Hackage 'changelog' display (was: Fwd: [commit: packages/stm] master: Refactor & update `stm.cabal` to `cabal-version>=1.10` (aa4774b))
by Duncan Coutts 25 Oct '13

25 Oct '13

On Fri, 2013-10-18 at 16:05 +0200, Herbert Valerio Riedel wrote: > Hello Duncan, > > ...any recommendation on this one? For isntance, how do I best add a link from the > description-field pointing to the changelog file? No I think the longer term solution is to treat the changelog properly in some machine-readable form so that hackage can show the changes in a reasonable way, e.g. most recent changes, expand to more detail. I don't think we really want to have the current situation where some packages have these huge descriptions including long changelogs and others have nothing. It's all rather inconsistent. We should probably have hackage show only the first ~20-30 lines of the description and let the user expand that if they want to see more, and do a similar thing for the changelog. Simon makes the point that he likes having the changelog in the .cabal file rather than a separate file because it's less mental effort to update, as you can see it at the same time as the version. So perhaps what we should do is add a changelog field to the .cabal file an allow that to be inline, or to refer to a file, e.g. "changelog:" or "changlog-file:". Either way we can then do a bit of simple syntax checking so we know we can format it ok on hackage and in other tools. Duncan

2 1

hackage reverse dependencies
by Jens Petersen 14 Oct '13

14 Oct '13

Not really complaining :) but one of the things I had been looking forward to with Hackage2 was the display of reverse-dependencies, but I gather it was disabled for now (because it loads the server too much when updating the data iirc?). I was thinking perhaps a compromise would be to show only direct reverse-dependencies rather than including all indirect dependencies too. Perhaps that would make it scale better? I think direct dependency information is the most useful anyway (and also what packdeps provides). Before doing anything I thought I would ask here first if this makes sense and should be work? I for one would still really like to see basic reverse dependencies info listed on hackage (I noticed yesterday that npm has them too). Jens

5 5

Hackage updating of distro data
by Jens Petersen 14 Oct '13

14 Oct '13

Hi, it is great that Hackage 2 finally was deployed in production. :-) How often does Hackage 2 update/pull distro data? Hackage 1 had a cronjob I believe which ran every few hours I think. But the new Hackage does not seem to pull often/regularly. For Fedora I updated the data on 18 Sept and then 26 Sept. The update from 18th Sept is reflected in Hackage but not 26th Sept. Checking more I guess the 18 Sept was still during Hackage1 so it looks like Hackage2 has not updated it distro data since going into production? Is there a cronjob setup on the new hackage server currently for pulling distro package data? Thanks, Jens

2 2

Feature Idea: --no-remote-fetching flag
by Adam Foltzer 08 Oct '13

08 Oct '13

Hello, With the wonderful advent of sandboxes in mainline cabal, I'd like to see what folks think of a flag to disable remote fetching of dependencies. The idea is that one could `cabal sandbox add-source` a set of trusted dependencies, and then be assured that a subsequent `cabal install --no-remote-fetching` would *only* resolve dependencies in that trusted set. I'd be willing to explore implementing this myself, if it would be appropriate for a first-time cabal hacker. I'm also quite interested to hear whether this would be a useful feature for others, or other ways you might propose to address the problem. I also understand that I can get this behavior by modifying the ~/.cabal/config, but this is a kludgey approach that is not workable in all deployment environments. Thanks! Adam

4 5

ANN: Cabal v1.18.0 released
by Johan Tibell 16 Sep '13

16 Sep '13

Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of "dependency hell" and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-in… (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors.

4 4

How can I get SSH access to www.haskell.org to upload the Cabal user guide?
by Johan Tibell 11 Sep '13

11 Sep '13

Hi all, Who manages www.haskell.org? Where's the machine? How can I get an SSH account so I can upload the Cabal user guide for the Cabal version I just released? -- Johan

5 6

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