- cabal-devel - Haskell.org

darcs patch: bugfix: --state-dir not used for backup ... (and 2 more)
by Joachim Breitner 07 Nov '10

07 Nov '10

Hi, here is the support for Distro releases. The release name "default", if used in the public API, is special to indicate "no release name", for distributions that doe not distinguish between releases. I’ll update the Wiki to reflect the new paths now. Greetins, Joachim 3 patches for repository http://code.haskell.org/hackage-server: Sun Nov 7 10:27:23 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * bugfix: --state-dir not used for backup tarball name Sun Nov 7 10:49:52 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Fix importing of empty groups from backup Sun Nov 7 11:01:59 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Support for more than one release per distribution

1 0

darcs patch: allow authorization to be passed on for a redirect on ...
by Antoine Latter 06 Nov '10

06 Nov '10

1 patch for repository http://darcs.haskell.org/cabal-install: Sat Nov 6 17:51:12 CET 2010 Antoine Latter <aslatter(a)gmail.com> * allow authorization to be passed on for a redirect on upload

1 0

Re: [Hackage] #402: Automatic hoogle database for installed packages
by Hackage 06 Nov '10

06 Nov '10

#402: Automatic hoogle database for installed packages ---------------------------------+------------------------------------------ Reporter: Peaker | Owner: dschoepe Type: enhancement | Status: assigned Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Comment(by dschoepe): I've been using my patch for the past few months now and it appears to work fine, so once the required haddock-patch(about generating hoogle and html output in one call[1]) is applied, this patch should be ready to be applied. [1] http://thread.gmane.org/gmane.comp.lang.haskell.cabal.devel/5617 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/402#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-branches/cabal-1.10): Export commandParseArgs
by Duncan Coutts 05 Nov '10

05 Nov '10

Fri Nov 5 07:06:55 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Export commandParseArgs M ./Distribution/Simple/Command.hs -3 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0

patch applied (cabal): Export commandParseArgs
by Duncan Coutts 05 Nov '10

05 Nov '10

Fri Nov 5 07:06:55 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Export commandParseArgs M ./Distribution/Simple/Command.hs -3 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #428: cabal update uses too much bandwidth
by Hackage 04 Nov '10

04 Nov '10

#428: cabal update uses too much bandwidth --------------------------------+------------------------------------------- Reporter: claus | Type: defect Status: new | Priority: normal Milestone: cabal-install-0.8 | Component: cabal-install tool Version: 1.6.0.1 | Severity: normal Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.3 | Platform: --------------------------------+------------------------------------------- Comment(by claus): I just found another reason why this is annoying: when using `--remote- repo`, cabal requires `update`, and that will always re-download the huge hackage index as well as the tiny index for the remote repo. Not to mention that we still have to re-download the huge index every time we want to install a newly updloaded package. The compressed index has now grown to over 2MB! Given that hackage only adds, almost never removes packages, why not have checkpoints of the index every week, and daily tarballs with just the added-since-checkpoint .cabal` files? Then cabal could download just the dailies, starting from the last downloaded local checkpoint. Very little additional technology - just untar the dailies on top of the last checkpoint (if the repo doesn't support dailies, fall back to the current scheme; for hackage, one could either have a server-side script selecting the dailies, or even let cabal do that client-side - the former being more efficient, the latter placing fewer burdens on non-hackage repo providers). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/428#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

About building wx and Cabal
by Duncan Coutts 04 Nov '10

04 Nov '10

Jeremy, I've briefly been following your posts about building wx using Cabal (for the benefit of other cabal-devel readers the latest is:) http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-ca… I want to make sure we don't lose what the core problem is and I'd like to work out what the "right" solution would be in terms of extra Cabal features. Perhaps you can translate into a feature request ticket that says what the core problem is (e.g. is it simply that static linking does not work for this C lib etc). Without yet understanding all the details, my first impression is that this problem would fit well with a feature I've been imagining for defining "foreign library" sections in a .cabal file, as opposed to Haskell libraries. These could contain C,C++ code as normal, but would be built using the platform rules, rather than the Haskell compiler rules. I don't yet understand why you've got a constraint on using a shared library, but perhaps the thing to do is simply to allow foreign lib sections to state such a constraint, e.g. the point might be to make a shared lib for a plugin, so a static lib is not the goal. Otoh, if it's possible to both build a static and shared lib from the same description, that's probably a useful thing in many circumstances. Duncan

1 0

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 03 Nov '10

03 Nov '10

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.12.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by guest): * ghcversion: 6.10.1 => 6.12.1 * version: 1.1.4 => 1.8.0.6 Comment: It hasn't been mentioned that this actually causes a system-level problem on GNU/Linux which potentially makes it more severe: it makes the mandb cron task at least complain and, I think, actually fail after getting {{{ /usr/bin/mandb: can't open /usr/local/share/man/man1/markdown2pdf.1: Permission denied }}} following a `cabal install --global pandoc', although the binary is installed appropriately. This is with {{{ cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library }}} -- d.love(haskell) @ liv.ac.uk -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:10> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs optimize http://darcs.haskell.org/cabal-install/?
by Christian Maeder 01 Nov '10

01 Nov '10

Can I persuade the cabal-install maintainer? I'm using the new darcs-2.5 Cheers Christian maeder@denebola:~/haskell> darcs get http://darcs.haskell.org/cabal-install/ Converting old-fashioned repository to hashed format... ******************************************************************************* Fetching a hashed repository would be faster. Perhaps you could persuade the maintainer to run darcs optimize --upgrade with darcs 2.4.0 or higher? *******************************************************************************

1 0

Re: [Hackage] #399: More information in the Paths_pkg.hs module, or a new module
by Hackage 31 Oct '10

31 Oct '10

#399: More information in the Paths_pkg.hs module, or a new module ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Comment(by guest): I have a package, where I like to enable debug output based on a package configuration flag. To this end it would be nice to have the state of this Cabal flag as top-level constant in an automatically generated module like Paths. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/399#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0