From nikita at karetnikov.org  Tue Apr  1 17:22:51 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Tue, 01 Apr 2014 21:22:51 +0400
Subject: [PATCH] Bootstrap over HTTPS.
Message-ID: <87d2h1t15g.fsf@karetnikov.org>

A non-text attachment was scrubbed...
Name: 0001-Bootstrap-over-HTTPS.patch
Type: text/x-diff
Size: 801 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140401/f2e73845/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140401/f2e73845/attachment.sig>

From the.dead.shall.rise at gmail.com  Tue Apr  1 20:31:18 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 1 Apr 2014 22:31:18 +0200
Subject: [PATCH] Bootstrap over HTTPS.
In-Reply-To: <87d2h1t15g.fsf@karetnikov.org>
References: <87d2h1t15g.fsf@karetnikov.org>
Message-ID: <CA+tcxkC3WAZ9iSnd+VSNhg4t_tWoDDpaw55p3u=2hU31YC3yQw@mail.gmail.com>

Hi,

2014-04-01 19:22 GMT+02:00 Nikita Karetnikov <nikita at karetnikov.org>:
>

Can you please do a pull request on GitHub:
https://github.com/haskell/cabal/pulls ?

From nikita at karetnikov.org  Tue Apr  1 20:43:47 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Wed, 02 Apr 2014 00:43:47 +0400
Subject: cabal-install: Replacing HTTP with HTTPS (was: [PATCH] Bootstrap over
 HTTPS.)
In-Reply-To: <87d2h1t15g.fsf@karetnikov.org> (Nikita Karetnikov's message of
 "Tue, 01 Apr 2014 21:22:51 +0400")
References: <87d2h1t15g.fsf@karetnikov.org>
Message-ID: <87txacrda4.fsf@karetnikov.org>

Turns out cabal-install itself uses HTTP.  (Try to grep for ?hackage? in
the source tree.)  Is it due to the HTTP library, which doesn?t support
HTTPS (4000.2.12 returns ?user error (https not supported)?)?

Is there any interest in changing the current state of things?  And if
so, what is the best way to do it?  Would you like to switch to a
different library?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140402/ca922fe4/attachment.sig>

From nikita at karetnikov.org  Tue Apr  1 21:22:23 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Wed, 02 Apr 2014 01:22:23 +0400
Subject: [PATCH] Bootstrap over HTTPS.
In-Reply-To: <CA+tcxkC3WAZ9iSnd+VSNhg4t_tWoDDpaw55p3u=2hU31YC3yQw@mail.gmail.com>
 (Mikhail Glushenkov's message of "Tue, 1 Apr 2014 22:31:18 +0200")
References: <87d2h1t15g.fsf@karetnikov.org>
 <CA+tcxkC3WAZ9iSnd+VSNhg4t_tWoDDpaw55p3u=2hU31YC3yQw@mail.gmail.com>
Message-ID: <87ioqsrbhs.fsf@karetnikov.org>

> Can you please do a pull request on GitHub:
> https://github.com/haskell/cabal/pulls ?

My apologies, but I have no interest in using GitHub for a bunch of
reasons.  GitHub ToS require people to use their real names (which is
not a problem for me, but dangerous for some people) as well as ?defend
GitHub against any claim, demand, suit or proceeding made or brought
against GitHub by a third party? [1].  I?m also concerned that more and
more people rely on a for-profit company, which may do whatever it
wishes in the future.  Last but not least, it?s powered by non-free
software [2].

[1] https://help.github.com/articles/github-terms-of-service
[2] https://www.gnu.org/philosophy/free-sw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140402/31d13b36/attachment.sig>

From hvr at gnu.org  Wed Apr  2 10:22:47 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 02 Apr 2014 12:22:47 +0200
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <87txacrda4.fsf@karetnikov.org> (Nikita Karetnikov's message of
 "Wed, 02 Apr 2014 00:43:47 +0400")
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
Message-ID: <87y4zoghe0.fsf@gnu.org>

On 2014-04-01 at 22:43:47 +0200, Nikita Karetnikov wrote:
> Turns out cabal-install itself uses HTTP.  (Try to grep for ?hackage? in
> the source tree.)  Is it due to the HTTP library, which doesn?t support
> HTTPS (4000.2.12 returns ?user error (https not supported)?)?
>
> Is there any interest in changing the current state of things?  And if
> so, what is the best way to do it?  Would you like to switch to a
> different library?

The main problem is, that cabal-install tries to rely only on
HP packages; so for now HTTP is the only HTTP-library included
in the HP, maybe a good place to start would be

  https://github.com/haskell/HTTP/issues/17

HTH,
  hvr

From johan.tibell at gmail.com  Wed Apr  2 10:59:47 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 2 Apr 2014 12:59:47 +0200
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <87y4zoghe0.fsf@gnu.org>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
Message-ID: <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>

On Wed, Apr 2, 2014 at 12:22 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2014-04-01 at 22:43:47 +0200, Nikita Karetnikov wrote:
> > Turns out cabal-install itself uses HTTP.  (Try to grep for "hackage" in
> > the source tree.)  Is it due to the HTTP library, which doesn't support
> > HTTPS (4000.2.12 returns "user error (https not supported)")?
> >
> > Is there any interest in changing the current state of things?  And if
> > so, what is the best way to do it?  Would you like to switch to a
> > different library?
>
> The main problem is, that cabal-install tries to rely only on
> HP packages; so for now HTTP is the only HTTP-library included
> in the HP, maybe a good place to start would be
>
>   https://github.com/haskell/HTTP/issues/17


The big question we have to answer first is, how do we want to support SSL?
Do we want to use an existing, well-tested, well scrutinized SSL
implementation and FFI bind to it? If so, which one and why? If not, are we
comfortable enough with writing a correct SSL implementation? That's very
hard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140402/8ef15b57/attachment.html>

From nikita at karetnikov.org  Wed Apr  2 22:02:28 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Thu, 03 Apr 2014 02:02:28 +0400
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 (Johan Tibell's message of "Wed, 2 Apr 2014 12:59:47 +0200")
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
Message-ID: <87txabo0ej.fsf@karetnikov.org>

> The big question we have to answer first is, how do we want to support SSL?
> Do we want to use an existing, well-tested, well scrutinized SSL
> implementation and FFI bind to it? If so, which one and why? If not, are we
> comfortable enough with writing a correct SSL implementation? That's very
> hard.

Why write your own?  We could try to come up with a list of
requirements, so every HTTPS library on Hackage could be evaluated.  Is
anyone knowledgeable of cabal-install interested in composing such a
list?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140403/f72efad2/attachment.sig>

From johan.tibell at gmail.com  Thu Apr  3 08:55:43 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 3 Apr 2014 10:55:43 +0200
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <87txabo0ej.fsf@karetnikov.org>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
Message-ID: <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>

On Thu, Apr 3, 2014 at 12:02 AM, Nikita Karetnikov <nikita at karetnikov.org>wrote:

> > The big question we have to answer first is, how do we want to support
> SSL?
> > Do we want to use an existing, well-tested, well scrutinized SSL
> > implementation and FFI bind to it? If so, which one and why? If not, are
> we
> > comfortable enough with writing a correct SSL implementation? That's very
> > hard.
>
> Why write your own?  We could try to come up with a list of
> requirements, so every HTTPS library on Hackage could be evaluated.  Is
> anyone knowledgeable of cabal-install interested in composing such a
> list?
>

"Write our own" as in "use a pure Haskell implementation of SSL from
Hackage". This has been suggested when this question came up in the past
and I'm skeptical to that from a security perspective.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140403/7425e786/attachment.html>

From bob at redivi.com  Thu Apr  3 14:44:58 2014
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 3 Apr 2014 07:44:58 -0700
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
 <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
Message-ID: <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>

On Thursday, April 3, 2014, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Thu, Apr 3, 2014 at 12:02 AM, Nikita Karetnikov <nikita at karetnikov.org<javascript:_e(%7B%7D,'cvml','nikita at karetnikov.org');>
> > wrote:
>
>> > The big question we have to answer first is, how do we want to support
>> SSL?
>> > Do we want to use an existing, well-tested, well scrutinized SSL
>> > implementation and FFI bind to it? If so, which one and why? If not,
>> are we
>> > comfortable enough with writing a correct SSL implementation? That's
>> very
>> > hard.
>>
>> Why write your own?  We could try to come up with a list of
>> requirements, so every HTTPS library on Hackage could be evaluated.  Is
>> anyone knowledgeable of cabal-install interested in composing such a
>> list?
>>
>
> "Write our own" as in "use a pure Haskell implementation of SSL from
> Hackage". This has been suggested when this question came up in the past
> and I'm skeptical to that from a security perspective.
>

If it works, how would it be worse than using no encryption
whatsoever? Sure, maybe there would be a false sense of security, but it
seems like a step in the right direction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140403/3f2070a0/attachment.html>

From bos at serpentine.com  Thu Apr  3 15:38:37 2014
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu, 3 Apr 2014 08:38:37 -0700
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
 <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
 <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>
Message-ID: <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>

On Thu, Apr 3, 2014 at 7:44 AM, Bob Ippolito <bob at redivi.com> wrote:

> If it works, how would it be worse than using no encryption
> whatsoever? Sure, maybe there would be a false sense of security, but it
> seems like a step in the right direction.
>

Presumably that's the problem. We'd have a possibly zero amount of
end-to-end security, coupled with a possibly zero amount of trust in the
remote endpoint, but we have 20 years of human factors experience
demonstrating that people trust SSL by default even when they shouldn't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140403/76471be7/attachment.html>

From bob at redivi.com  Thu Apr  3 15:57:26 2014
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 3 Apr 2014 08:57:26 -0700
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
 <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
 <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>
 <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>
Message-ID: <CACwMPm8g+eY2aFKgOssxT69dHX9667SunhHC6MA38SwieOhq8A@mail.gmail.com>

On Thu, Apr 3, 2014 at 8:38 AM, Bryan O'Sullivan <bos at serpentine.com> wrote:

>
> On Thu, Apr 3, 2014 at 7:44 AM, Bob Ippolito <bob at redivi.com> wrote:
>
>> If it works, how would it be worse than using no encryption
>> whatsoever? Sure, maybe there would be a false sense of security, but it
>> seems like a step in the right direction.
>>
>
> Presumably that's the problem. We'd have a possibly zero amount of
> end-to-end security, coupled with a possibly zero amount of trust in the
> remote endpoint, but we have 20 years of human factors experience
> demonstrating that people trust SSL by default even when they shouldn't.
>

Aren't we already well into the "people trust cabal-install by default even
when they shouldn't" phase? :)

For libraries that wrap a well scrutinized implementation, it appears that
HsOpenSSL has some usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140403/94918acc/attachment.html>

From greg at gregorycollins.net  Fri Apr  4 03:21:44 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Fri, 4 Apr 2014 05:21:44 +0200
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CACwMPm8g+eY2aFKgOssxT69dHX9667SunhHC6MA38SwieOhq8A@mail.gmail.com>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
 <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
 <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>
 <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>
 <CACwMPm8g+eY2aFKgOssxT69dHX9667SunhHC6MA38SwieOhq8A@mail.gmail.com>
Message-ID: <CAHZrzdpzaihG+kyk7hZ8R1TkrY9JbGk4+zhFBa7735VUrCO_0Q@mail.gmail.com>

On Thu, Apr 3, 2014 at 5:57 PM, Bob Ippolito <bob at redivi.com> wrote:

> it appears that HsOpenSSL has some usage.


If you care about security, it's the only viable option. Gnu TLS is really
buggy in my experience and the Haskell "tls" package is not widely enough
used to be a candidate (it also doesn't follow the Hackage package
versioning policy, so is highly likely to cause build failures in the
future).

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140404/7137f40f/attachment.html>

From the.dead.shall.rise at gmail.com  Fri Apr  4 22:41:27 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 5 Apr 2014 00:41:27 +0200
Subject: cabal-install: Replacing HTTP with HTTPS
In-Reply-To: <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>
References: <87d2h1t15g.fsf@karetnikov.org> <87txacrda4.fsf@karetnikov.org>
 <87y4zoghe0.fsf@gnu.org>
 <CAK-tuPZtfMA52hqcxAftM7ucpivM37FK4CbU35rzTi6yN5h87A@mail.gmail.com>
 <87txabo0ej.fsf@karetnikov.org>
 <CAK-tuPZjsvDChwzi3CFWxFQqpS87WR_99XS4421dq8bKnFcZNw@mail.gmail.com>
 <CACwMPm_N=yvNfgB6OvQ9t_VM2UFTbK0kV_zHAqUL=RTtAN4_yQ@mail.gmail.com>
 <CACw0niLzvfrpE7yueXTi8z9nt84gKe-=eJ+Y_mjk5TU0WHZm=Q@mail.gmail.com>
Message-ID: <CA+tcxkATpkABK3vVJwwMSthPK7iNGGB5tMn+NBqst7KHtk1K+Q@mail.gmail.com>

On 3 April 2014 17:38, Bryan O'Sullivan <bos at serpentine.com> wrote:
>
> Presumably that's the problem. We'd have a possibly zero amount of
> end-to-end security, coupled with a possibly zero amount of trust in the
> remote endpoint, but we have 20 years of human factors experience
> demonstrating that people trust SSL by default even when they shouldn't.

There was a suggestion to make Hackage digitally sign packages and
ship the public key inside the cabal-install tarball. This could be
used in addition to HTTPS downloads.

From daniel.trstenjak at gmail.com  Wed Apr  9 13:13:44 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Wed, 9 Apr 2014 15:13:44 +0200
Subject: GenericPackageDescription and 'build-depends' field
Message-ID: <20140409131344.GA15645@machine>


Hi all,

am I right, that the 'build-depends' field of the cabal file is now
always represented by 'condTreeConstraints' in 'CondTree'?

So is the 'targetBuildDepends' in 'BuildInfo' now only available for
backward compatibility reasons?


Greetings,
Daniel

From johan.tibell at gmail.com  Wed Apr  9 21:03:00 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 9 Apr 2014 23:03:00 +0200
Subject: Planning to make 1.20 release in about one week
Message-ID: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>

Hi!

I looked over and replied to the remaining outstanding pull requests a
couple of days ago. I'm happy to call what's in master now 1.20 (although
I'm also happy if any of the outstanding pull requests make it in.) If
nothing major happens I will make a release on the 15th.

P.S. There are 360 commits since the last release according to `git log
--pretty=oneline Cabal-v1.18.1.3..`.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140409/f6017354/attachment.html>

From slyich at gmail.com  Wed Apr  9 21:36:23 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Thu, 10 Apr 2014 00:36:23 +0300
Subject: Planning to make 1.20 release in about one week
In-Reply-To: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>
References: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>
Message-ID: <20140410003623.2f3789c5@sf>

On Wed, 9 Apr 2014 23:03:00 +0200
Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi!
> 
> I looked over and replied to the remaining outstanding pull requests a
> couple of days ago. I'm happy to call what's in master now 1.20 (although
> I'm also happy if any of the outstanding pull requests make it in.) If
> nothing major happens I will make a release on the 15th.
> 
> P.S. There are 360 commits since the last release according to `git log
> --pretty=oneline Cabal-v1.18.1.3..`.

I have quite odd error on current Cabal master.
It's a Cabal installed on top of ghc-7.8.1.

Many .cabal files fail to parse including cabal-install-master one:

    cabal-install $ runhaskell Setup.hs configure
    Setup.hs: cabal-install.cabal:160: Parse of field 'hs-source-dirs' failed.

Latest commit is:

    commit 65e9b88bc849e76040ed7947591ea7172cd02db5
    Author: Herbert Valerio Riedel <hvr at gnu.org>
    Date:   Wed Apr 9 22:55:36 2014 +0200

    Add `integer-{gmp,simple}` and `template-haskell` to list of non-upgradables
    
    This is related to #667 and similiar issues

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140410/2ffd76b4/attachment.sig>

From johan.tibell at gmail.com  Wed Apr  9 21:43:32 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 9 Apr 2014 23:43:32 +0200
Subject: Planning to make 1.20 release in about one week
In-Reply-To: <20140410003623.2f3789c5@sf>
References: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>
 <20140410003623.2f3789c5@sf>
Message-ID: <CAK-tuPYHx9fbpAuYPDk-Omgr5tV=hJN65tgxq6N62VYTXMf5Lg@mail.gmail.com>

Could you try to `git bisect` it down to the failing commit?


On Wed, Apr 9, 2014 at 11:36 PM, Sergei Trofimovich <slyich at gmail.com>wrote:

> On Wed, 9 Apr 2014 23:03:00 +0200
> Johan Tibell <johan.tibell at gmail.com> wrote:
>
> > Hi!
> >
> > I looked over and replied to the remaining outstanding pull requests a
> > couple of days ago. I'm happy to call what's in master now 1.20 (although
> > I'm also happy if any of the outstanding pull requests make it in.) If
> > nothing major happens I will make a release on the 15th.
> >
> > P.S. There are 360 commits since the last release according to `git log
> > --pretty=oneline Cabal-v1.18.1.3..`.
>
> I have quite odd error on current Cabal master.
> It's a Cabal installed on top of ghc-7.8.1.
>
> Many .cabal files fail to parse including cabal-install-master one:
>
>     cabal-install $ runhaskell Setup.hs configure
>     Setup.hs: cabal-install.cabal:160: Parse of field 'hs-source-dirs'
> failed.
>
> Latest commit is:
>
>     commit 65e9b88bc849e76040ed7947591ea7172cd02db5
>     Author: Herbert Valerio Riedel <hvr at gnu.org>
>     Date:   Wed Apr 9 22:55:36 2014 +0200
>
>     Add `integer-{gmp,simple}` and `template-haskell` to list of
> non-upgradables
>
>     This is related to #667 and similiar issues
>
> --
>
>   Sergei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140409/96803ea2/attachment.html>

From slyich at gmail.com  Wed Apr  9 22:57:01 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Thu, 10 Apr 2014 01:57:01 +0300
Subject: Planning to make 1.20 release in about one week
In-Reply-To: <CAK-tuPYHx9fbpAuYPDk-Omgr5tV=hJN65tgxq6N62VYTXMf5Lg@mail.gmail.com>
References: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>
 <20140410003623.2f3789c5@sf>
 <CAK-tuPYHx9fbpAuYPDk-Omgr5tV=hJN65tgxq6N62VYTXMf5Lg@mail.gmail.com>
Message-ID: <20140410015701.2bb47f62@sf>

On Wed, 9 Apr 2014 23:43:32 +0200
Johan Tibell <johan.tibell at gmail.com> wrote:

> Could you try to `git bisect` it down to the failing commit?

Sure [CCed Daniel]

commit 73dd1c261a62a546774bb732026ddcfc1245bd8b
Author: Daniel Trstenjak <daniel.trstenjak at gmail.com>
Date:   Sat Mar 1 15:45:59 2014 +0100

    More diff friendly pretty printing of cabal files
    
    Now the 'fieldGet' function of 'FieldDescr' does the
    whole pretty printing of the field. Previously only the
    values have been pretty printed by 'fieldGet' and the
    name of the field with the colon have been printed
    in the 'PrettyPrint' module.
    
    But this separation made it more difficult to handle the
    pretty printing of fields differently, because some fields
    should be just printed in one lines and others - having several
    values - should be printed nested with each value on a new line.
    
    This difference in the printing of the fields is now handled by
    the 'FieldDescr' constructor functions in 'ParseUtils'.
    
    Now the 'listField' and 'commaListField' functions create 'FieldDescr'
    that nest their values and all other functions create one line
    for the whole field.

How it's done:
  ~/dev/git/cabal $ cat bisector.sh 
    #!/bin/bash
    cd cabal-install
    r=`runhaskell -hide-all-packages -package={base,directory,pretty,array,unix,filepath,bytestring,process,deepseq,containers,time} -i../Cabal/ Setup.hs configure 2>&1`
    [[ $r == *"Parse of field"* ]] && exit 1
    echo "all 'ok': $r"
    exit 0

  ~/dev/git/cabal $ git bisect start master Cabal-v1.18.1.3 
    Bisecting: a merge base must be tested
    [e2ad772a072c0a7c0c248f3fdc38c4cef276275c] Fix a build error when Clang is used as a preprocessor.
  ~/dev/git/cabal $ git bisect run ./bisector.sh

running ./bisector.sh
all 'ok': Configuring cabal-install-1.18.0.1...
Bisecting: 179 revisions left to test after this (roughly 8 steps)
[cceb52d55223856f6b6843f5f47ba1d49c57f0ec] Merge pull request #1618 from nh2/refactor-jobs-parser
running ./bisector.sh
all 'ok': Configuring cabal-install-1.19.2...
Setup.hs: At least the following dependencies are missing:
Cabal ==1.19.2
Bisecting: 89 revisions left to test after this (roughly 7 steps)
[36e932a2808a44431ab596583ac4763dff581597] check linker, other script fixups
running ./bisector.sh
all 'ok': Configuring cabal-install-1.19.2...
Setup.hs: At least the following dependencies are missing:
Cabal ==1.19.2
Bisecting: 44 revisions left to test after this (roughly 6 steps)
[a573d4ba73b403b85ae6e80364841fbbf011f545] .travis.yml: recache the user package DB after installing GHC.
running ./bisector.sh
all 'ok': Configuring cabal-install-1.19.2...
Setup.hs: At least the following dependencies are missing:
Cabal ==1.19.2
Bisecting: 21 revisions left to test after this (roughly 5 steps)
[c2cb3795e4e664aedb2ad3ad78b992748570bb24] Merge pull request #1748 from ianbollinger/fix-#1569
running ./bisector.sh
all 'ok': Configuring cabal-install-1.19.2...
Setup.hs: At least the following dependencies are missing:
Cabal ==1.19.2
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[d9286320cde32cc049a037af64307c9db92bc3bb] Merge pull request #1707 from 23Skidoo/haddock-saved-config
running ./bisector.sh
all 'ok': Configuring cabal-install-1.19.2...
Setup.hs: At least the following dependencies are missing:
Cabal ==1.19.2
Bisecting: 3 revisions left to test after this (roughly 3 steps)
[0038d05a9d5af1daeae2e160da69f946760813e8] Merge branch 'master' of https://github.com/dan-t/cabal
running ./bisector.sh
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[c13850d1328b308dd2d62b29c4f5df2cecbcb5fd] Merge remote-tracking branch 'cabal/master'
running ./bisector.sh
Bisecting: 0 revisions left to test after this (roughly 1 step)
[77ccb23cd5342dc0715e50353a9f707092b19cd1] Remove module 'PrettyPrintIndent' and move function 'indentWith' into module 'ParseUtils'
running ./bisector.sh
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[73dd1c261a62a546774bb732026ddcfc1245bd8b] More diff friendly pretty printing of cabal files
running ./bisector.sh
73dd1c261a62a546774bb732026ddcfc1245bd8b is the first bad commit
commit 73dd1c261a62a546774bb732026ddcfc1245bd8b
Author: Daniel Trstenjak <daniel.trstenjak at gmail.com>
Date:   Sat Mar 1 15:45:59 2014 +0100

    More diff friendly pretty printing of cabal files
    
    Now the 'fieldGet' function of 'FieldDescr' does the
    whole pretty printing of the field. Previously only the
    values have been pretty printed by 'fieldGet' and the
    name of the field with the colon have been printed
    in the 'PrettyPrint' module.
    
    But this separation made it more difficult to handle the
    pretty printing of fields differently, because some fields
    should be just printed in one lines and others - having several
    values - should be printed nested with each value on a new line.
    
    This difference in the printing of the fields is now handled by
    the 'FieldDescr' constructor functions in 'ParseUtils'.
    
    Now the 'listField' and 'commaListField' functions create 'FieldDescr'
    that nest their values and all other functions create one line
    for the whole field.

:040000 040000 cde590c0af54a14608dd8c4dc0c0002195445188 a80f1fc7aa134e7c976f21bc50d3bd044e414b72 M      Cabal
bisect run success

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140410/84806c35/attachment.sig>

From the.dead.shall.rise at gmail.com  Thu Apr 10 01:10:32 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 10 Apr 2014 03:10:32 +0200
Subject: GenericPackageDescription and 'build-depends' field
In-Reply-To: <20140409131344.GA15645@machine>
References: <20140409131344.GA15645@machine>
Message-ID: <CA+tcxkAUStfyh7oFdKT=4wq+bBawCeFg4GZ8sp+EmOVmPKC2bg@mail.gmail.com>

Hi,

On 9 April 2014 15:13, Daniel Trstenjak <daniel.trstenjak at gmail.com> wrote:
>
> Hi all,
>
> am I right, that the 'build-depends' field of the cabal file is now
> always represented by 'condTreeConstraints' in 'CondTree'?
>
> So is the 'targetBuildDepends' in 'BuildInfo' now only available for
> backward compatibility reasons?

IIRC it's what condtrees get simplified to after finalizePackageDescription.

From the.dead.shall.rise at gmail.com  Thu Apr 10 04:15:18 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 10 Apr 2014 06:15:18 +0200
Subject: Planning to make 1.20 release in about one week
In-Reply-To: <20140410015701.2bb47f62@sf>
References: <CAK-tuPaf6p7624-4aC-gkZ3KCBWK9F3HmdfMTT-KDb+uDsLzbw@mail.gmail.com>
 <20140410003623.2f3789c5@sf>
 <CAK-tuPYHx9fbpAuYPDk-Omgr5tV=hJN65tgxq6N62VYTXMf5Lg@mail.gmail.com>
 <20140410015701.2bb47f62@sf>
Message-ID: <CA+tcxkDdhANDszcL+0h4fuEe2hDk9CQQfq5rVhQSOAeYT9UPNg@mail.gmail.com>

Hi,

On 10 April 2014 00:57, Sergei Trofimovich <slyich at gmail.com> wrote:
> On Wed, 9 Apr 2014 23:43:32 +0200
> Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> Could you try to `git bisect` it down to the failing commit?
>
> Sure [CCed Daniel]
>
> commit 73dd1c261a62a546774bb732026ddcfc1245bd8b
> Author: Daniel Trstenjak <daniel.trstenjak at gmail.com>
> Date:   Sat Mar 1 15:45:59 2014 +0100
>
>     More diff friendly pretty printing of cabal files

Thanks for investigating. I've reverted those commits for now.

From johan.tibell at gmail.com  Thu Apr 10 16:04:56 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 10 Apr 2014 18:04:56 +0200
Subject: Needed: cabal-install-1.18.0.3 binaries
Message-ID: <CAK-tuPbHtL1iWVT=S_k6wjoP0p_8ahbp+boJjmSFseQEyqkPJw@mail.gmail.com>

We currently have an OS X Mavericks binary but we also need at least a
Windows binary:
http://www.haskell.org/cabal/download.html

If someone could build me a Windows binary that would be great.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140410/f8300067/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Apr 10 20:24:10 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 10 Apr 2014 22:24:10 +0200
Subject: [PATCH] Bootstrap over HTTPS.
In-Reply-To: <87d2h1t15g.fsf@karetnikov.org>
References: <87d2h1t15g.fsf@karetnikov.org>
Message-ID: <CA+tcxkDze1er3mULY1kHUSf1N4amQw3jrzTiYEr6NFXMXH4hWA@mail.gmail.com>

Applied, thanks!

From johan.tibell at gmail.com  Tue Apr 15 08:33:52 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 15 Apr 2014 10:33:52 +0200
Subject: 1.20 release candidates
Message-ID: <CAK-tuPZYDFS3Ft0Sd703pUGxo4cJVMFwvD9FOhdNZJY7=C87sQ@mail.gmail.com>

Hi all,

I've prepared the 1.20 release candidates. I now need some help testing,
especially on Windows as I don't have a Windows machine.

To install the release candidates simply run:

    cabal install http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz
http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz

Please report any issues on the bug tracker:
https://github.com/haskell/cabal/issues

If I haven't heard of anything release blocking bugs (or last minute
important patches) in a couple of days, I will make these tarballs the
official release.

The commits used are tagged in the repo as Cabal-v1.20.0-rc and
cabal-install-v1.20.0-rc.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140415/18dfac88/attachment.html>

From johan.tibell at gmail.com  Tue Apr 15 09:07:43 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 15 Apr 2014 11:07:43 +0200
Subject: 1.20 release candidates
In-Reply-To: <CAK-tuPZYDFS3Ft0Sd703pUGxo4cJVMFwvD9FOhdNZJY7=C87sQ@mail.gmail.com>
References: <CAK-tuPZYDFS3Ft0Sd703pUGxo4cJVMFwvD9FOhdNZJY7=C87sQ@mail.gmail.com>
Message-ID: <CAK-tuPaT_a+3QE1FbcfEVgxsedo80NFtA+mUZDBgvQoZXEGvBA@mail.gmail.com>

If you run into this error:

Network/HTTP/Auth.hs:192:49:
    Couldn't match expected type `Maybe URI' with actual type `URI'
    In the second argument of `fromMaybe', namely
      `(u `relativeTo` baseURI)'
    In the expression: fromMaybe u (u `relativeTo` baseURI)
    In the first argument of `map', namely
      `(\ u -> fromMaybe u (u `relativeTo` baseURI))'

try using the 1.20 branch on GitHub instead, as I had to work around a
missing upper bound on network in the HTTP package. cabal-install only
builds reliably with HTTP-4000.2.5 and higher.


On Tue, Apr 15, 2014 at 10:33 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Hi all,
>
> I've prepared the 1.20 release candidates. I now need some help testing,
> especially on Windows as I don't have a Windows machine.
>
> To install the release candidates simply run:
>
>     cabal install http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz
> http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz
>
> Please report any issues on the bug tracker:
> https://github.com/haskell/cabal/issues
>
> If I haven't heard of anything release blocking bugs (or last minute
> important patches) in a couple of days, I will make these tarballs the
> official release.
>
> The commits used are tagged in the repo as Cabal-v1.20.0-rc and
> cabal-install-v1.20.0-rc.
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140415/681faab9/attachment.html>

From johan.tibell at gmail.com  Tue Apr 15 10:00:27 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 15 Apr 2014 12:00:27 +0200
Subject: 1.20 release candidates
In-Reply-To: <CAK-tuPaT_a+3QE1FbcfEVgxsedo80NFtA+mUZDBgvQoZXEGvBA@mail.gmail.com>
References: <CAK-tuPZYDFS3Ft0Sd703pUGxo4cJVMFwvD9FOhdNZJY7=C87sQ@mail.gmail.com>
 <CAK-tuPaT_a+3QE1FbcfEVgxsedo80NFtA+mUZDBgvQoZXEGvBA@mail.gmail.com>
Message-ID: <CAK-tuPYjDsH8jMT_nNH3Amt918tmaTAWNPu3Fp9HBa8DdWEQLg@mail.gmail.com>

The above tarballs should work if you manually constrain the install to use
HTTP-4000.2.5 or higher:

  cabal install --constraint="HTTP >= 4000.2.5"
http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz
http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz



On Tue, Apr 15, 2014 at 11:07 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> If you run into this error:
>
> Network/HTTP/Auth.hs:192:49:
>     Couldn't match expected type `Maybe URI' with actual type `URI'
>     In the second argument of `fromMaybe', namely
>       `(u `relativeTo` baseURI)'
>     In the expression: fromMaybe u (u `relativeTo` baseURI)
>     In the first argument of `map', namely
>       `(\ u -> fromMaybe u (u `relativeTo` baseURI))'
>
> try using the 1.20 branch on GitHub instead, as I had to work around a
> missing upper bound on network in the HTTP package. cabal-install only
> builds reliably with HTTP-4000.2.5 and higher.
>
>
> On Tue, Apr 15, 2014 at 10:33 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> Hi all,
>>
>> I've prepared the 1.20 release candidates. I now need some help testing,
>> especially on Windows as I don't have a Windows machine.
>>
>> To install the release candidates simply run:
>>
>>     cabal install http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz
>> http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz
>>
>> Please report any issues on the bug tracker:
>> https://github.com/haskell/cabal/issues
>>
>> If I haven't heard of anything release blocking bugs (or last minute
>> important patches) in a couple of days, I will make these tarballs the
>> official release.
>>
>> The commits used are tagged in the repo as Cabal-v1.20.0-rc and
>> cabal-install-v1.20.0-rc.
>>
>> -- Johan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140415/f21166a0/attachment.html>

From johan.tibell at gmail.com  Thu Apr 17 07:06:46 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 17 Apr 2014 09:06:46 +0200
Subject: Please test: Cabal/cabal-install 1.20 RC2
Message-ID: <CAK-tuPYOSMzUK2KS_zBFUHC22-s7QRC-vHadO_S3qHGhNi47sQ@mail.gmail.com>

Hi all,

The second, and hopefully last, release candidate for Cabal and
cabal-install 1.20 is ready. If no issues are discovered, I plan to release
this on Sunday, April 20th.

You can help test by installing the release candidate and use it for your
day-to-day work:

    cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz
http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz

Please report any issues at https://github.com/haskell/cabal/issues

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140417/03e50237/attachment.html>

From carter.schonwald at gmail.com  Thu Apr 17 17:32:46 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 17 Apr 2014 13:32:46 -0400
Subject: [Haskell-cafe] Please test: Cabal/cabal-install 1.20 RC2
In-Reply-To: <CAK-tuPYOSMzUK2KS_zBFUHC22-s7QRC-vHadO_S3qHGhNi47sQ@mail.gmail.com>
References: <CAK-tuPYOSMzUK2KS_zBFUHC22-s7QRC-vHadO_S3qHGhNi47sQ@mail.gmail.com>
Message-ID: <CAHYVw0zDR+7jk20ssPqwHxsnnfV_Sw0SyEkpPoYTdAbbBiQhGw@mail.gmail.com>

I'm trying to use the new haddock flags

haddock
  -- keep-temp-files: False
  -- hoogle: False
  -- html: False
  -- html-location:
  -- executables: False
  -- tests: False
  -- benchmarks: False
  -- all:
  -- internal: False
  internal: True
  -- css:
  -- hyperlink-source: False
  hyperlink-source: True


and it looks like hyperlink-source isn't quite working! What am i doing
wrong?


On Thu, Apr 17, 2014 at 3:06 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Hi all,
>
> The second, and hopefully last, release candidate for Cabal and
> cabal-install 1.20 is ready. If no issues are discovered, I plan to release
> this on Sunday, April 20th.
>
> You can help test by installing the release candidate and use it for your
> day-to-day work:
>
>     cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz
> http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz
>
> Please report any issues at https://github.com/haskell/cabal/issues
>
> -- Johan
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140417/367f04f1/attachment.html>

From carter.schonwald at gmail.com  Thu Apr 17 18:28:01 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 17 Apr 2014 14:28:01 -0400
Subject: [Haskell-cafe] Please test: Cabal/cabal-install 1.20 RC2
In-Reply-To: <CAHYVw0zDR+7jk20ssPqwHxsnnfV_Sw0SyEkpPoYTdAbbBiQhGw@mail.gmail.com>
References: <CAK-tuPYOSMzUK2KS_zBFUHC22-s7QRC-vHadO_S3qHGhNi47sQ@mail.gmail.com>
 <CAHYVw0zDR+7jk20ssPqwHxsnnfV_Sw0SyEkpPoYTdAbbBiQhGw@mail.gmail.com>
Message-ID: <CAHYVw0y16hCXvLMEFdk3etsEWn5xMjnYTmKOMeoRKzWVRk8mBQ@mail.gmail.com>

also bizzarely, the haddocks for cabal 1.20 aren't showing up in my
haddocks index or anywhere!


On Thu, Apr 17, 2014 at 1:32 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I'm trying to use the new haddock flags
>
> haddock
>   -- keep-temp-files: False
>   -- hoogle: False
>   -- html: False
>   -- html-location:
>   -- executables: False
>   -- tests: False
>   -- benchmarks: False
>   -- all:
>   -- internal: False
>   internal: True
>   -- css:
>   -- hyperlink-source: False
>   hyperlink-source: True
>
>
> and it looks like hyperlink-source isn't quite working! What am i doing
> wrong?
>
>
>  On Thu, Apr 17, 2014 at 3:06 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>>  Hi all,
>>
>> The second, and hopefully last, release candidate for Cabal and
>> cabal-install 1.20 is ready. If no issues are discovered, I plan to release
>> this on Sunday, April 20th.
>>
>> You can help test by installing the release candidate and use it for your
>> day-to-day work:
>>
>>     cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz
>> http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz
>>
>> Please report any issues at https://github.com/haskell/cabal/issues
>>
>> -- Johan
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140417/b73195da/attachment.html>

From johan.tibell at gmail.com  Fri Apr 18 08:20:04 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 18 Apr 2014 10:20:04 +0200
Subject: [Haskell-cafe] Please test: Cabal/cabal-install 1.20 RC2
In-Reply-To: <CAHYVw0y16hCXvLMEFdk3etsEWn5xMjnYTmKOMeoRKzWVRk8mBQ@mail.gmail.com>
References: <CAK-tuPYOSMzUK2KS_zBFUHC22-s7QRC-vHadO_S3qHGhNi47sQ@mail.gmail.com>
 <CAHYVw0zDR+7jk20ssPqwHxsnnfV_Sw0SyEkpPoYTdAbbBiQhGw@mail.gmail.com>
 <CAHYVw0y16hCXvLMEFdk3etsEWn5xMjnYTmKOMeoRKzWVRk8mBQ@mail.gmail.com>
Message-ID: <CAK-tuPasZ8dCsPAuQTNHPd2bM_Gj07pfh26fRtJA16wXWE6x0A@mail.gmail.com>

I believe I've fixed the Windows issue by release a new network (2.4.2.3)
and the Haddock issue by reverting a botched merge commit. The latter means
that `cabal exec` is currently out of this release unless someone can
successfully merge the commit to the 1.20 branch. Currently this causes a
bunch of conflicts.


On Thu, Apr 17, 2014 at 8:28 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> also bizzarely, the haddocks for cabal 1.20 aren't showing up in my
> haddocks index or anywhere!
>
>
> On Thu, Apr 17, 2014 at 1:32 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> I'm trying to use the new haddock flags
>>
>> haddock
>>   -- keep-temp-files: False
>>   -- hoogle: False
>>   -- html: False
>>   -- html-location:
>>   -- executables: False
>>   -- tests: False
>>   -- benchmarks: False
>>   -- all:
>>   -- internal: False
>>   internal: True
>>   -- css:
>>   -- hyperlink-source: False
>>   hyperlink-source: True
>>
>>
>> and it looks like hyperlink-source isn't quite working! What am i doing
>> wrong?
>>
>>
>>  On Thu, Apr 17, 2014 at 3:06 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>>
>>>  Hi all,
>>>
>>> The second, and hopefully last, release candidate for Cabal and
>>> cabal-install 1.20 is ready. If no issues are discovered, I plan to release
>>> this on Sunday, April 20th.
>>>
>>> You can help test by installing the release candidate and use it for
>>> your day-to-day work:
>>>
>>>     cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz
>>>  http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz
>>>
>>> Please report any issues at https://github.com/haskell/cabal/issues
>>>
>>> -- Johan
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140418/28cd4710/attachment.html>

From johan.tibell at gmail.com  Mon Apr 21 07:19:52 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 21 Apr 2014 09:19:52 +0200
Subject: Needed: distributable executables for the 1.20 release
Message-ID: <CAK-tuPZOh--su5-JsgAf28kchjc414JGVm2wU-zzaknyYr2+Bg@mail.gmail.com>

Hi,

As per usual I want to provide executables for download for download on the
cabal homepage, for Windows and OS X. I can build the OS X one myself.
Could someone please send me a 64-bit Windows cabal executable?

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140421/54329b4d/attachment.html>

From daniel.trstenjak at gmail.com  Mon Apr 21 11:47:28 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 21 Apr 2014 13:47:28 +0200
Subject: GenericPackageDescription and 'build-depends' field
In-Reply-To: <CA+tcxkAUStfyh7oFdKT=4wq+bBawCeFg4GZ8sp+EmOVmPKC2bg@mail.gmail.com>
References: <20140409131344.GA15645@machine>
 <CA+tcxkAUStfyh7oFdKT=4wq+bBawCeFg4GZ8sp+EmOVmPKC2bg@mail.gmail.com>
Message-ID: <20140421114728.GA7635@machine>


On Thu, Apr 10, 2014 at 03:10:32AM +0200, Mikhail Glushenkov wrote:
> IIRC it's what condtrees get simplified to after finalizePackageDescription.

What's the reason for this?

Because it makes it a bit awkward to handle the different sections
(library/executable/testsuite/benchmark) respectively their BuildInfos
in a generic way.


Greetings,
Daniel

From juhp at community.haskell.org  Tue Apr 22 01:31:35 2014
From: juhp at community.haskell.org (Jens Petersen)
Date: Tue, 22 Apr 2014 10:31:35 +0900
Subject: Needed: distributable executables for the 1.20 release
In-Reply-To: <CAK-tuPZOh--su5-JsgAf28kchjc414JGVm2wU-zzaknyYr2+Bg@mail.gmail.com>
References: <CAK-tuPZOh--su5-JsgAf28kchjc414JGVm2wU-zzaknyYr2+Bg@mail.gmail.com>
Message-ID: <CAEDGBqLPyT56_AKOoiDa1OSoSnkZbuBbgqJ1wZu4kZVKvBEjQg@mail.gmail.com>

Hi!

I built cabal-1.20.0.0 for Fedora 19 and 20 in my copr repo:

https://copr.fedoraproject.org/coprs/petersen/cabal-install/

Thanks, Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140422/373a49d3/attachment.html>

From johan.tibell at gmail.com  Thu Apr 24 09:53:36 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 24 Apr 2014 11:53:36 +0200
Subject: Themes for 1.22
Message-ID: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>

Hi all,

While I'm sure we still have a bugfix release or two to make on the 1.20
branch, I thought it'd be worth looking at what we want to accomplish for
1.22. Here are my thoughts on what we should focus on:

## A dependency solver that always works

As Hackage has grown so have the requirements of the dependency solver.
There are three distinct problems I'm seeing now that we should tackle:

 * Treat each sections (i.e. library, test suite, benchmark, and
executable) in the .cabal file separately for the purpose of dependency
resolution. Today all the sections' dependencies are merged and used as the
constraints of the package as a whole. This is troublesome for all packages
that are dependencies of QC, HUnit, test-framework, and criterion, as
there's a dependency cycle if you treat e.g. the containers package and its
test suite as one unit.

   The solution here is to treat each unit as a mini package for the
purpose of dependency resolution. This would also allow you to have e.g.
several executables with conflicting dependencies.

 * Improve performance. Some packages (e.g. yesod) can take over 10 seconds
to run over. This problem will get worse as Hackage grows and we build
bigger applications on top of it, so we need to tackle this now before it
becomes a real problem.

 * Fix Hackage package blacklisting. Users can blacklist packages on
Hackage e.g. if they know them to be broken. However, this doesn't really
work as the Hackage blacklist translates to a soft preference in the
dependency solver and is thus often ignored. See
https://github.com/haskell/cabal/issues/1792 for the gory details.

## Do the right thing automatically

This is a carry-over from the 1.20 goals, as we didn't make much progress
here.

The focus here should be on avoiding manual steps the cabal could do
for the user.

 * Automatically install dependencies when needed. When `cabal build`
would fail due to a missing dependency, just install this dependency
instead of bugging the user to do it. This will probably have to be
limited to sandboxes where we can't break the user's system

 * GHCi support could be improved by rebinding :reload to rerun e.g.
preprocessors automatically. This would enable the users to develop
completely from within ghci (i.e. faster edit-save-type-error cycle).
We have most of what we need here (i.e. GHC macro support) but someone
needs to make the final change to generate a .ghci file to pass in the
ghci invocation.

## Faster builds

I think we're almost done here. There's really only one remaining thing to
do:

 * Build components and different ways (e.g. profiling) in parallel.
We could build both profiling and non-profiling versions in parallel.
We could also build e.g. all test suites in parallel. The key
challenge here is to coordinate all parallel jobs so we don't spawn
too many.

## Support large projects

This is also a carry-over from the 1.20 goals.

We still don't have a good story for large projects. Sandboxes are too
annoying to use if there are 100 add-source deps. We need more automation
and more opinionated defaults (e.g. scan the sub-directories from in which
cabal was run to find source packages.)

What we need most of all here is a design. Perhaps we could try to get
together at some Hackathon/ICFP and discuss.

## Issue tracker spring cleaning and test suite improvements

The issue tracker is out-of-hand. It's too unwieldy to use for planning our
work and get an overview of the most important issues. We should try to
close down bugs that haven't had updates in years with extreme prejudice.
If the issue is important it will pop up again.

We're also severely lacking in the testing department. There are two
problems:

 * There aren't enough tests: the cabal user facing surface is quite larger
(lots of features and flags) and many of them are not tested at all, which
will lead to regressions as we keep fixing bugs and adding features.

 * The tests take too long to run: we have too many end-to-end style tests
(i.e. build a whole package) and not enough unit style tests. We need to
add more of the latter kind.

Cheers,
  Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/4928e745/attachment.html>

From edwards.benj at gmail.com  Thu Apr 24 11:33:11 2014
From: edwards.benj at gmail.com (Benjamin Edwards)
Date: Thu, 24 Apr 2014 11:33:11 +0000
Subject: Themes for 1.22
References: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
Message-ID: <CAN6k4ni9VsTSkB8rCRWQUuUVfRYbZPn5kLqVC+xwaGY+f=4PBA@mail.gmail.com>

Hi Johan,

Not sure if this mail is a request for comments, but on the story for large
projects one thing that I would like to see is the ability to add packages
that aren't in hackage to the depends list. I agree that adding some
scanning and auto add ability is definitely sorely needed, but this
information goes into add-source-timestamps in the sandbox folder, and if
you blow away the sandbox, it's gone. Or you can try and version a file
that contains ever changing timestamps. Right now I have a shell script
that maintains a list of added sources and I keep that versioned in the
project. It would be nice to have git dependencies in there as well, and
then disallow a hackage upload for any cabal file with a non-hackage
dependency listed. I would be happy to contribute time to both design and
implementation.

Ben

On Thu Apr 24 2014 at 10:53:59, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi all,
>
> While I'm sure we still have a bugfix release or two to make on the 1.20
> branch, I thought it'd be worth looking at what we want to accomplish for
> 1.22. Here are my thoughts on what we should focus on:
>
> ## A dependency solver that always works
>
> As Hackage has grown so have the requirements of the dependency solver.
> There are three distinct problems I'm seeing now that we should tackle:
>
>  * Treat each sections (i.e. library, test suite, benchmark, and
> executable) in the .cabal file separately for the purpose of dependency
> resolution. Today all the sections' dependencies are merged and used as the
> constraints of the package as a whole. This is troublesome for all packages
> that are dependencies of QC, HUnit, test-framework, and criterion, as
> there's a dependency cycle if you treat e.g. the containers package and its
> test suite as one unit.
>
>    The solution here is to treat each unit as a mini package for the
> purpose of dependency resolution. This would also allow you to have e.g.
> several executables with conflicting dependencies.
>
>  * Improve performance. Some packages (e.g. yesod) can take over 10
> seconds to run over. This problem will get worse as Hackage grows and we
> build bigger applications on top of it, so we need to tackle this now
> before it becomes a real problem.
>
>  * Fix Hackage package blacklisting. Users can blacklist packages on
> Hackage e.g. if they know them to be broken. However, this doesn't really
> work as the Hackage blacklist translates to a soft preference in the
> dependency solver and is thus often ignored. See
> https://github.com/haskell/cabal/issues/1792 for the gory details.
>
> ## Do the right thing automatically
>
> This is a carry-over from the 1.20 goals, as we didn't make much progress
> here.
>
> The focus here should be on avoiding manual steps the cabal could do
> for the user.
>
>  * Automatically install dependencies when needed. When `cabal build`
> would fail due to a missing dependency, just install this dependency
> instead of bugging the user to do it. This will probably have to be
> limited to sandboxes where we can't break the user's system
>
>  * GHCi support could be improved by rebinding :reload to rerun e.g.
> preprocessors automatically. This would enable the users to develop
> completely from within ghci (i.e. faster edit-save-type-error cycle).
> We have most of what we need here (i.e. GHC macro support) but someone
> needs to make the final change to generate a .ghci file to pass in the
> ghci invocation.
>
> ## Faster builds
>
> I think we're almost done here. There's really only one remaining thing to
> do:
>
>  * Build components and different ways (e.g. profiling) in parallel.
> We could build both profiling and non-profiling versions in parallel.
> We could also build e.g. all test suites in parallel. The key
> challenge here is to coordinate all parallel jobs so we don't spawn
> too many.
>
> ## Support large projects
>
> This is also a carry-over from the 1.20 goals.
>
> We still don't have a good story for large projects. Sandboxes are too
> annoying to use if there are 100 add-source deps. We need more automation
> and more opinionated defaults (e.g. scan the sub-directories from in which
> cabal was run to find source packages.)
>
> What we need most of all here is a design. Perhaps we could try to get
> together at some Hackathon/ICFP and discuss.
>
> ## Issue tracker spring cleaning and test suite improvements
>
> The issue tracker is out-of-hand. It's too unwieldy to use for planning
> our work and get an overview of the most important issues. We should try to
> close down bugs that haven't had updates in years with extreme prejudice.
> If the issue is important it will pop up again.
>
> We're also severely lacking in the testing department. There are two
> problems:
>
>  * There aren't enough tests: the cabal user facing surface is quite
> larger (lots of features and flags) and many of them are not tested at all,
> which will lead to regressions as we keep fixing bugs and adding features.
>
>  * The tests take too long to run: we have too many end-to-end style tests
> (i.e. build a whole package) and not enough unit style tests. We need to
> add more of the latter kind.
>
> Cheers,
>   Johan
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/18ec2d90/attachment-0001.html>

From hesselink at gmail.com  Thu Apr 24 11:50:25 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 24 Apr 2014 13:50:25 +0200
Subject: Themes for 1.22
In-Reply-To: <CAN6k4ni9VsTSkB8rCRWQUuUVfRYbZPn5kLqVC+xwaGY+f=4PBA@mail.gmail.com>
References: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
 <CAN6k4ni9VsTSkB8rCRWQUuUVfRYbZPn5kLqVC+xwaGY+f=4PBA@mail.gmail.com>
Message-ID: <CAPeieQE_j_+eJLCN=7faBMi74Xx8WefU6i=1W+acDdcjNNpUfg@mail.gmail.com>

You can handle this scenario pretty easily by setting up a private
hackage. Then add a second remote-repo to your cabal config, either
globally or in the sandbox. We do this, and it works pretty well.

Regards,

Erik

On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards
<edwards.benj at gmail.com> wrote:
> Hi Johan,
>
> Not sure if this mail is a request for comments, but on the story for large
> projects one thing that I would like to see is the ability to add packages
> that aren't in hackage to the depends list. I agree that adding some
> scanning and auto add ability is definitely sorely needed, but this
> information goes into add-source-timestamps in the sandbox folder, and if
> you blow away the sandbox, it's gone. Or you can try and version a file that
> contains ever changing timestamps. Right now I have a shell script that
> maintains a list of added sources and I keep that versioned in the project.
> It would be nice to have git dependencies in there as well, and then
> disallow a hackage upload for any cabal file with a non-hackage dependency
> listed. I would be happy to contribute time to both design and
> implementation.
>
> Ben
>
> On Thu Apr 24 2014 at 10:53:59, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> Hi all,
>>
>> While I'm sure we still have a bugfix release or two to make on the 1.20
>> branch, I thought it'd be worth looking at what we want to accomplish for
>> 1.22. Here are my thoughts on what we should focus on:
>>
>> ## A dependency solver that always works
>>
>> As Hackage has grown so have the requirements of the dependency solver.
>> There are three distinct problems I'm seeing now that we should tackle:
>>
>>  * Treat each sections (i.e. library, test suite, benchmark, and
>> executable) in the .cabal file separately for the purpose of dependency
>> resolution. Today all the sections' dependencies are merged and used as the
>> constraints of the package as a whole. This is troublesome for all packages
>> that are dependencies of QC, HUnit, test-framework, and criterion, as
>> there's a dependency cycle if you treat e.g. the containers package and its
>> test suite as one unit.
>>
>>    The solution here is to treat each unit as a mini package for the
>> purpose of dependency resolution. This would also allow you to have e.g.
>> several executables with conflicting dependencies.
>>
>>  * Improve performance. Some packages (e.g. yesod) can take over 10
>> seconds to run over. This problem will get worse as Hackage grows and we
>> build bigger applications on top of it, so we need to tackle this now before
>> it becomes a real problem.
>>
>>  * Fix Hackage package blacklisting. Users can blacklist packages on
>> Hackage e.g. if they know them to be broken. However, this doesn't really
>> work as the Hackage blacklist translates to a soft preference in the
>> dependency solver and is thus often ignored. See
>> https://github.com/haskell/cabal/issues/1792 for the gory details.
>>
>> ## Do the right thing automatically
>>
>> This is a carry-over from the 1.20 goals, as we didn't make much progress
>> here.
>>
>> The focus here should be on avoiding manual steps the cabal could do
>> for the user.
>>
>>  * Automatically install dependencies when needed. When `cabal build`
>> would fail due to a missing dependency, just install this dependency
>> instead of bugging the user to do it. This will probably have to be
>> limited to sandboxes where we can't break the user's system
>>
>>  * GHCi support could be improved by rebinding :reload to rerun e.g.
>> preprocessors automatically. This would enable the users to develop
>> completely from within ghci (i.e. faster edit-save-type-error cycle).
>> We have most of what we need here (i.e. GHC macro support) but someone
>> needs to make the final change to generate a .ghci file to pass in the
>> ghci invocation.
>>
>> ## Faster builds
>>
>> I think we're almost done here. There's really only one remaining thing to
>> do:
>>
>>  * Build components and different ways (e.g. profiling) in parallel.
>> We could build both profiling and non-profiling versions in parallel.
>> We could also build e.g. all test suites in parallel. The key
>> challenge here is to coordinate all parallel jobs so we don't spawn
>> too many.
>>
>> ## Support large projects
>>
>> This is also a carry-over from the 1.20 goals.
>>
>> We still don't have a good story for large projects. Sandboxes are too
>> annoying to use if there are 100 add-source deps. We need more automation
>> and more opinionated defaults (e.g. scan the sub-directories from in which
>> cabal was run to find source packages.)
>>
>> What we need most of all here is a design. Perhaps we could try to get
>> together at some Hackathon/ICFP and discuss.
>>
>> ## Issue tracker spring cleaning and test suite improvements
>>
>> The issue tracker is out-of-hand. It's too unwieldy to use for planning
>> our work and get an overview of the most important issues. We should try to
>> close down bugs that haven't had updates in years with extreme prejudice. If
>> the issue is important it will pop up again.
>>
>> We're also severely lacking in the testing department. There are two
>> problems:
>>
>>  * There aren't enough tests: the cabal user facing surface is quite
>> larger (lots of features and flags) and many of them are not tested at all,
>> which will lead to regressions as we keep fixing bugs and adding features.
>>
>>  * The tests take too long to run: we have too many end-to-end style tests
>> (i.e. build a whole package) and not enough unit style tests. We need to add
>> more of the latter kind.
>>
>> Cheers,
>>   Johan
>>
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/cabal-devel
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>

From edwards.benj at gmail.com  Thu Apr 24 12:10:05 2014
From: edwards.benj at gmail.com (Benjamin Edwards)
Date: Thu, 24 Apr 2014 12:10:05 +0000
Subject: Themes for 1.22
References: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
 <CAN6k4ni9VsTSkB8rCRWQUuUVfRYbZPn5kLqVC+xwaGY+f=4PBA@mail.gmail.com>
 <CAPeieQE_j_+eJLCN=7faBMi74Xx8WefU6i=1W+acDdcjNNpUfg@mail.gmail.com>
Message-ID: <CAN6k4ngtzv6=QDdbt4Wv0dc_eAKbsTzynegFPL3M_QkKayLGXg@mail.gmail.com>

I will definitely look into that! Thank you. The one your that does force
you down though is the path only developing against releases, and even
those are light-weight internal patch releases to your own hackage it still
means a longer compile-test cycle. Maybe if that's a problem it indicates
that my package boundaries are too fine, but I find add-source to be
invaluable, I would find it even nicer if it was a little bit more first
class. If you look at how source dependencies are covered in VS when
programming in .Net, that's somewhat how I would like to see it managed in
cabal. It's trivial to have common assemblies in a source tree shared
between projects.

Ben

On Thu Apr 24 2014 at 12:50:45, Erik Hesselink <hesselink at gmail.com> wrote:

> You can handle this scenario pretty easily by setting up a private
> hackage. Then add a second remote-repo to your cabal config, either
> globally or in the sandbox. We do this, and it works pretty well.
>
> Regards,
>
> Erik
>
> On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards
> <edwards.benj at gmail.com> wrote:
> > Hi Johan,
> >
> > Not sure if this mail is a request for comments, but on the story for
> large
> > projects one thing that I would like to see is the ability to add
> packages
> > that aren't in hackage to the depends list. I agree that adding some
> > scanning and auto add ability is definitely sorely needed, but this
> > information goes into add-source-timestamps in the sandbox folder, and if
> > you blow away the sandbox, it's gone. Or you can try and version a file
> that
> > contains ever changing timestamps. Right now I have a shell script that
> > maintains a list of added sources and I keep that versioned in the
> project.
> > It would be nice to have git dependencies in there as well, and then
> > disallow a hackage upload for any cabal file with a non-hackage
> dependency
> > listed. I would be happy to contribute time to both design and
> > implementation.
> >
> > Ben
> >
> > On Thu Apr 24 2014 at 10:53:59, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> While I'm sure we still have a bugfix release or two to make on the 1.20
> >> branch, I thought it'd be worth looking at what we want to accomplish
> for
> >> 1.22. Here are my thoughts on what we should focus on:
> >>
> >> ## A dependency solver that always works
> >>
> >> As Hackage has grown so have the requirements of the dependency solver.
> >> There are three distinct problems I'm seeing now that we should tackle:
> >>
> >>  * Treat each sections (i.e. library, test suite, benchmark, and
> >> executable) in the .cabal file separately for the purpose of dependency
> >> resolution. Today all the sections' dependencies are merged and used as
> the
> >> constraints of the package as a whole. This is troublesome for all
> packages
> >> that are dependencies of QC, HUnit, test-framework, and criterion, as
> >> there's a dependency cycle if you treat e.g. the containers package and
> its
> >> test suite as one unit.
> >>
> >>    The solution here is to treat each unit as a mini package for the
> >> purpose of dependency resolution. This would also allow you to have e.g.
> >> several executables with conflicting dependencies.
> >>
> >>  * Improve performance. Some packages (e.g. yesod) can take over 10
> >> seconds to run over. This problem will get worse as Hackage grows and we
> >> build bigger applications on top of it, so we need to tackle this now
> before
> >> it becomes a real problem.
> >>
> >>  * Fix Hackage package blacklisting. Users can blacklist packages on
> >> Hackage e.g. if they know them to be broken. However, this doesn't
> really
> >> work as the Hackage blacklist translates to a soft preference in the
> >> dependency solver and is thus often ignored. See
> >> https://github.com/haskell/cabal/issues/1792 for the gory details.
> >>
> >> ## Do the right thing automatically
> >>
> >> This is a carry-over from the 1.20 goals, as we didn't make much
> progress
> >> here.
> >>
> >> The focus here should be on avoiding manual steps the cabal could do
> >> for the user.
> >>
> >>  * Automatically install dependencies when needed. When `cabal build`
> >> would fail due to a missing dependency, just install this dependency
> >> instead of bugging the user to do it. This will probably have to be
> >> limited to sandboxes where we can't break the user's system
> >>
> >>  * GHCi support could be improved by rebinding :reload to rerun e.g.
> >> preprocessors automatically. This would enable the users to develop
> >> completely from within ghci (i.e. faster edit-save-type-error cycle).
> >> We have most of what we need here (i.e. GHC macro support) but someone
> >> needs to make the final change to generate a .ghci file to pass in the
> >> ghci invocation.
> >>
> >> ## Faster builds
> >>
> >> I think we're almost done here. There's really only one remaining thing
> to
> >> do:
> >>
> >>  * Build components and different ways (e.g. profiling) in parallel.
> >> We could build both profiling and non-profiling versions in parallel.
> >> We could also build e.g. all test suites in parallel. The key
> >> challenge here is to coordinate all parallel jobs so we don't spawn
> >> too many.
> >>
> >> ## Support large projects
> >>
> >> This is also a carry-over from the 1.20 goals.
> >>
> >> We still don't have a good story for large projects. Sandboxes are too
> >> annoying to use if there are 100 add-source deps. We need more
> automation
> >> and more opinionated defaults (e.g. scan the sub-directories from in
> which
> >> cabal was run to find source packages.)
> >>
> >> What we need most of all here is a design. Perhaps we could try to get
> >> together at some Hackathon/ICFP and discuss.
> >>
> >> ## Issue tracker spring cleaning and test suite improvements
> >>
> >> The issue tracker is out-of-hand. It's too unwieldy to use for planning
> >> our work and get an overview of the most important issues. We should
> try to
> >> close down bugs that haven't had updates in years with extreme
> prejudice. If
> >> the issue is important it will pop up again.
> >>
> >> We're also severely lacking in the testing department. There are two
> >> problems:
> >>
> >>  * There aren't enough tests: the cabal user facing surface is quite
> >> larger (lots of features and flags) and many of them are not tested at
> all,
> >> which will lead to regressions as we keep fixing bugs and adding
> features.
> >>
> >>  * The tests take too long to run: we have too many end-to-end style
> tests
> >> (i.e. build a whole package) and not enough unit style tests. We need
> to add
> >> more of the latter kind.
> >>
> >> Cheers,
> >>   Johan
> >>
> >> _______________________________________________
> >> cabal-devel mailing list
> >> cabal-devel at haskell.org
> >> http://www.haskell.org/mailman/listinfo/cabal-devel
> >
> >
> > _______________________________________________
> > cabal-devel mailing list
> > cabal-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/cabal-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/9fbdc15d/attachment.html>

From johan.tibell at gmail.com  Thu Apr 24 12:41:52 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 24 Apr 2014 14:41:52 +0200
Subject: Themes for 1.22
In-Reply-To: <CAN6k4ngtzv6=QDdbt4Wv0dc_eAKbsTzynegFPL3M_QkKayLGXg@mail.gmail.com>
References: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
 <CAN6k4ni9VsTSkB8rCRWQUuUVfRYbZPn5kLqVC+xwaGY+f=4PBA@mail.gmail.com>
 <CAPeieQE_j_+eJLCN=7faBMi74Xx8WefU6i=1W+acDdcjNNpUfg@mail.gmail.com>
 <CAN6k4ngtzv6=QDdbt4Wv0dc_eAKbsTzynegFPL3M_QkKayLGXg@mail.gmail.com>
Message-ID: <CAK-tuPbtj0M5akNxsmu7iS28FveZLnMb46FiXyiogaUxR5a5yA@mail.gmail.com>

Having to share code via releases is indeed the problem with an internal
Hackage. I don't see that scaling well as an organization gets bigger. You
really need to be able to check out the organization's source repo and have
that contain a bunch of (non-released) packages and build them together.


On Thu, Apr 24, 2014 at 2:10 PM, Benjamin Edwards <edwards.benj at gmail.com>wrote:

> I will definitely look into that! Thank you. The one your that does force
> you down though is the path only developing against releases, and even
> those are light-weight internal patch releases to your own hackage it still
> means a longer compile-test cycle. Maybe if that's a problem it indicates
> that my package boundaries are too fine, but I find add-source to be
> invaluable, I would find it even nicer if it was a little bit more first
> class. If you look at how source dependencies are covered in VS when
> programming in .Net, that's somewhat how I would like to see it managed in
> cabal. It's trivial to have common assemblies in a source tree shared
> between projects.
>
> Ben
>
> On Thu Apr 24 2014 at 12:50:45, Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> You can handle this scenario pretty easily by setting up a private
>> hackage. Then add a second remote-repo to your cabal config, either
>> globally or in the sandbox. We do this, and it works pretty well.
>>
>> Regards,
>>
>> Erik
>>
>> On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards
>> <edwards.benj at gmail.com> wrote:
>> > Hi Johan,
>> >
>> > Not sure if this mail is a request for comments, but on the story for
>> large
>> > projects one thing that I would like to see is the ability to add
>> packages
>> > that aren't in hackage to the depends list. I agree that adding some
>> > scanning and auto add ability is definitely sorely needed, but this
>> > information goes into add-source-timestamps in the sandbox folder, and
>> if
>> > you blow away the sandbox, it's gone. Or you can try and version a file
>> that
>> > contains ever changing timestamps. Right now I have a shell script that
>> > maintains a list of added sources and I keep that versioned in the
>> project.
>> > It would be nice to have git dependencies in there as well, and then
>> > disallow a hackage upload for any cabal file with a non-hackage
>> dependency
>> > listed. I would be happy to contribute time to both design and
>> > implementation.
>> >
>> > Ben
>> >
>> > On Thu Apr 24 2014 at 10:53:59, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> While I'm sure we still have a bugfix release or two to make on the
>> 1.20
>> >> branch, I thought it'd be worth looking at what we want to accomplish
>> for
>> >> 1.22. Here are my thoughts on what we should focus on:
>> >>
>> >> ## A dependency solver that always works
>> >>
>> >> As Hackage has grown so have the requirements of the dependency solver.
>> >> There are three distinct problems I'm seeing now that we should tackle:
>> >>
>> >>  * Treat each sections (i.e. library, test suite, benchmark, and
>> >> executable) in the .cabal file separately for the purpose of dependency
>> >> resolution. Today all the sections' dependencies are merged and used
>> as the
>> >> constraints of the package as a whole. This is troublesome for all
>> packages
>> >> that are dependencies of QC, HUnit, test-framework, and criterion, as
>> >> there's a dependency cycle if you treat e.g. the containers package
>> and its
>> >> test suite as one unit.
>> >>
>> >>    The solution here is to treat each unit as a mini package for the
>> >> purpose of dependency resolution. This would also allow you to have
>> e.g.
>> >> several executables with conflicting dependencies.
>> >>
>> >>  * Improve performance. Some packages (e.g. yesod) can take over 10
>> >> seconds to run over. This problem will get worse as Hackage grows and
>> we
>> >> build bigger applications on top of it, so we need to tackle this now
>> before
>> >> it becomes a real problem.
>> >>
>> >>  * Fix Hackage package blacklisting. Users can blacklist packages on
>> >> Hackage e.g. if they know them to be broken. However, this doesn't
>> really
>> >> work as the Hackage blacklist translates to a soft preference in the
>> >> dependency solver and is thus often ignored. See
>> >> https://github.com/haskell/cabal/issues/1792 for the gory details.
>> >>
>> >> ## Do the right thing automatically
>> >>
>> >> This is a carry-over from the 1.20 goals, as we didn't make much
>> progress
>> >> here.
>> >>
>> >> The focus here should be on avoiding manual steps the cabal could do
>> >> for the user.
>> >>
>> >>  * Automatically install dependencies when needed. When `cabal build`
>> >> would fail due to a missing dependency, just install this dependency
>> >> instead of bugging the user to do it. This will probably have to be
>> >> limited to sandboxes where we can't break the user's system
>> >>
>> >>  * GHCi support could be improved by rebinding :reload to rerun e.g.
>> >> preprocessors automatically. This would enable the users to develop
>> >> completely from within ghci (i.e. faster edit-save-type-error cycle).
>> >> We have most of what we need here (i.e. GHC macro support) but someone
>> >> needs to make the final change to generate a .ghci file to pass in the
>> >> ghci invocation.
>> >>
>> >> ## Faster builds
>> >>
>> >> I think we're almost done here. There's really only one remaining
>> thing to
>> >> do:
>> >>
>> >>  * Build components and different ways (e.g. profiling) in parallel.
>> >> We could build both profiling and non-profiling versions in parallel.
>> >> We could also build e.g. all test suites in parallel. The key
>> >> challenge here is to coordinate all parallel jobs so we don't spawn
>> >> too many.
>> >>
>> >> ## Support large projects
>> >>
>> >> This is also a carry-over from the 1.20 goals.
>> >>
>> >> We still don't have a good story for large projects. Sandboxes are too
>> >> annoying to use if there are 100 add-source deps. We need more
>> automation
>> >> and more opinionated defaults (e.g. scan the sub-directories from in
>> which
>> >> cabal was run to find source packages.)
>> >>
>> >> What we need most of all here is a design. Perhaps we could try to get
>> >> together at some Hackathon/ICFP and discuss.
>> >>
>> >> ## Issue tracker spring cleaning and test suite improvements
>> >>
>> >> The issue tracker is out-of-hand. It's too unwieldy to use for planning
>> >> our work and get an overview of the most important issues. We should
>> try to
>> >> close down bugs that haven't had updates in years with extreme
>> prejudice. If
>> >> the issue is important it will pop up again.
>> >>
>> >> We're also severely lacking in the testing department. There are two
>> >> problems:
>> >>
>> >>  * There aren't enough tests: the cabal user facing surface is quite
>> >> larger (lots of features and flags) and many of them are not tested at
>> all,
>> >> which will lead to regressions as we keep fixing bugs and adding
>> features.
>> >>
>> >>  * The tests take too long to run: we have too many end-to-end style
>> tests
>> >> (i.e. build a whole package) and not enough unit style tests. We need
>> to add
>> >> more of the latter kind.
>> >>
>> >> Cheers,
>> >>   Johan
>> >>
>> >> _______________________________________________
>> >> cabal-devel mailing list
>> >> cabal-devel at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/cabal-devel
>> >
>> >
>> > _______________________________________________
>> > cabal-devel mailing list
>> > cabal-devel at haskell.org
>> > http://www.haskell.org/mailman/listinfo/cabal-devel
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/7f06a1a9/attachment-0001.html>

From greg at gregorycollins.net  Thu Apr 24 13:14:40 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 24 Apr 2014 15:14:40 +0200
Subject: Themes for 1.22
In-Reply-To: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
References: <CAK-tuPbz72w+vEKDgB4DYRObXv6vM1v6gQdoOMiBCQBnXi93Bg@mail.gmail.com>
Message-ID: <CAHZrzdo3=hDcxwehZRQ9QJ37iUhcg2vG0fZgdi4iFDZeuFh5+w@mail.gmail.com>

I'd like to add to the list: "change cabal-install so that most of its code
is exported to hackage as a library". In the past I've occasionally wanted
to do some of the same things the cabal binary does from code, and it would
be much more convenient to link the relevant code in than to exec the
binary all the time.


On Thu, Apr 24, 2014 at 11:53 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Hi all,
>
> While I'm sure we still have a bugfix release or two to make on the 1.20
> branch, I thought it'd be worth looking at what we want to accomplish for
> 1.22. Here are my thoughts on what we should focus on:
>
> ## A dependency solver that always works
>
> As Hackage has grown so have the requirements of the dependency solver.
> There are three distinct problems I'm seeing now that we should tackle:
>
>  * Treat each sections (i.e. library, test suite, benchmark, and
> executable) in the .cabal file separately for the purpose of dependency
> resolution. Today all the sections' dependencies are merged and used as the
> constraints of the package as a whole. This is troublesome for all packages
> that are dependencies of QC, HUnit, test-framework, and criterion, as
> there's a dependency cycle if you treat e.g. the containers package and its
> test suite as one unit.
>
>    The solution here is to treat each unit as a mini package for the
> purpose of dependency resolution. This would also allow you to have e.g.
> several executables with conflicting dependencies.
>
>  * Improve performance. Some packages (e.g. yesod) can take over 10
> seconds to run over. This problem will get worse as Hackage grows and we
> build bigger applications on top of it, so we need to tackle this now
> before it becomes a real problem.
>
>  * Fix Hackage package blacklisting. Users can blacklist packages on
> Hackage e.g. if they know them to be broken. However, this doesn't really
> work as the Hackage blacklist translates to a soft preference in the
> dependency solver and is thus often ignored. See
> https://github.com/haskell/cabal/issues/1792 for the gory details.
>
> ## Do the right thing automatically
>
> This is a carry-over from the 1.20 goals, as we didn't make much progress
> here.
>
> The focus here should be on avoiding manual steps the cabal could do
> for the user.
>
>  * Automatically install dependencies when needed. When `cabal build`
> would fail due to a missing dependency, just install this dependency
> instead of bugging the user to do it. This will probably have to be
> limited to sandboxes where we can't break the user's system
>
>  * GHCi support could be improved by rebinding :reload to rerun e.g.
> preprocessors automatically. This would enable the users to develop
> completely from within ghci (i.e. faster edit-save-type-error cycle).
> We have most of what we need here (i.e. GHC macro support) but someone
> needs to make the final change to generate a .ghci file to pass in the
> ghci invocation.
>
> ## Faster builds
>
> I think we're almost done here. There's really only one remaining thing to
> do:
>
>  * Build components and different ways (e.g. profiling) in parallel.
> We could build both profiling and non-profiling versions in parallel.
> We could also build e.g. all test suites in parallel. The key
> challenge here is to coordinate all parallel jobs so we don't spawn
> too many.
>
> ## Support large projects
>
> This is also a carry-over from the 1.20 goals.
>
> We still don't have a good story for large projects. Sandboxes are too
> annoying to use if there are 100 add-source deps. We need more automation
> and more opinionated defaults (e.g. scan the sub-directories from in which
> cabal was run to find source packages.)
>
> What we need most of all here is a design. Perhaps we could try to get
> together at some Hackathon/ICFP and discuss.
>
> ## Issue tracker spring cleaning and test suite improvements
>
> The issue tracker is out-of-hand. It's too unwieldy to use for planning
> our work and get an overview of the most important issues. We should try to
> close down bugs that haven't had updates in years with extreme prejudice.
> If the issue is important it will pop up again.
>
> We're also severely lacking in the testing department. There are two
> problems:
>
>  * There aren't enough tests: the cabal user facing surface is quite
> larger (lots of features and flags) and many of them are not tested at all,
> which will lead to regressions as we keep fixing bugs and adding features.
>
>  * The tests take too long to run: we have too many end-to-end style tests
> (i.e. build a whole package) and not enough unit style tests. We need to
> add more of the latter kind.
>
> Cheers,
>   Johan
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/2b04de65/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Apr 24 14:27:34 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 24 Apr 2014 16:27:34 +0200
Subject: GenericPackageDescription and 'build-depends' field
In-Reply-To: <20140421114728.GA7635@machine>
References: <20140409131344.GA15645@machine>
 <CA+tcxkAUStfyh7oFdKT=4wq+bBawCeFg4GZ8sp+EmOVmPKC2bg@mail.gmail.com>
 <20140421114728.GA7635@machine>
Message-ID: <CA+tcxkDk4QxpfMEw=p76oz7DPzDxLJ_GAqXAJ_9D8qwketYPYA@mail.gmail.com>

Hi,

On 21 April 2014 13:47, Daniel Trstenjak <daniel.trstenjak at gmail.com> wrote:
>
> On Thu, Apr 10, 2014 at 03:10:32AM +0200, Mikhail Glushenkov wrote:
>> IIRC it's what condtrees get simplified to after finalizePackageDescription.
>
> What's the reason for this?

Condtrees represent conditional blocks in the .cabal file. Example:

if impl(ghc):
   build-depends: a, b, c
   ...

If we know the flag assignment, we can simplify them. This is what
finalizePackageDescription does.

> Because it makes it a bit awkward to handle the different sections
> (library/executable/testsuite/benchmark) respectively their BuildInfos
> in a generic way.

If your function needs to work on GenericPackageDescriptions, you'll
have to traverse condtrees, like I do here:
https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/Dependency.hs#L346

If you only work with finalized PackageDescriptions, you can get away
with looking only at buildInfos.

From nikita at karetnikov.org  Tue Apr 29 23:15:17 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Wed, 30 Apr 2014 03:15:17 +0400
Subject: Proposal: cabal-install: verify OpenPGP signatures
Message-ID: <87eh0fafsq.fsf@karetnikov.org>

Following up on the ?cabal-install: Replacing HTTP with HTTPS? thread.
I think we can do better.  I want to make sure that people will notice
if someone compromises the packages on hackage.haskell.org.

Here?s a rough plan:

1. Patch ?hackage-server? to allow uploading of OpenPGP signatures.

2. Patch ?cabal-install? to use GPG for verification.  (GPG trust levels
   could be useful here.)  ?cabal install? should also support
   ?--skip-verification? or some such to avoid disaster during the
   adoption stage.

   In addition, ?cabal update? would fetch the list of fingerprints from
   Hackage and cache each revision.  A warning would be raised if a
   fignerprint cannot be found in the cache.

   If a maintainer wants to use a new key, it must be signed with the
   previously used one.  If a maintainer loses their private key, for
   instance, this should be resolved by the admins.  For example, an
   admin (admins?) could sign the new key.

   After a while, a web of trust would be formed.  The fingerprints of
   active maintainers would be well-known.

I?ve been thinking about this for quite a while and don?t see other ways
to achive the same level of trust while allowing arbitrary uploads.  The
proposal also doesn?t require much manual intervention.

What do you think?  I?m willing to work on this but want to make sure
that my time won?t be wasted.  Will you accept such a patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140430/bf7157bd/attachment.sig>

From johan.tibell at gmail.com  Sun Apr 20 11:42:05 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 20 Apr 2014 13:42:05 +0200
Subject: Announcing cabal 1.20
Message-ID: <CAK-tuPYVqrEhFCqFj+1FXtJBAYGpGYOvMrpEYekAaOC5pHZd7g@mail.gmail.com>

Hi all,

On behalf of all the cabal contributors, I'm proud to announce cabal 1.20.
With 404 commits since the 1.18 release, this is a feature packed release.
Here's a short summary of the perhaps most notable changes:

 * Dependency freezing
 * Parallel cabal build
 * Flag to temporary ignore upper bounds
 * Unnecessary re-linking avoidance
 * Streaming cabal test output
 * New cabal exec command
 * Haddock configuration options

I did a longer write-up about the new features on my blog:
http://blog.johantibell.com/2014/04/announcing-cabal-120.html

## Contributors

Here are the contributors for this release, ordered by number of commits:

 * Mikhail Glushenkov
 * Johan Tibell
 * Duncan Coutts
 * Thomas Tuegel
 * Ian D. Bollinger
 * Ben Armston
 * Niklas Hamb?chen
 * Daniel Trstenjak
 * Tuncer Ayaz
 * Herbert Valerio Riedel
 * Tillmann Rendel
 * Liyang HU
 * Dominic Steinitz
 * Brent Yorgey
 * Ricky Elrod
 * Geoff Nixon
 * Florian Hartwig
 * Bob Ippolito
 * Bj?rn Peem?ller
 * Wojciech Danilo
 * Sergei Trofimovich
 * Ryan Trinkle
 * Ryan Newton
 * Roman Cheplyaka
 * Peter Selinger
 * Niklas Haas
 * Nikita Karetnikov
 * Nick Smallbone
 * Mike Craig
 * Markus Pfeiffer
 * Luke Iannini
 * Luite Stegeman
 * John Lato
 * Jens Petersen
 * Jason Dagit
 * Gabor Pali
 * Daniel Velkov
 * Ben Millwood

Apologies if someone was left out. Once in a while we have to make commits
on behalf of an author. Those authors are not captured above.

Enjoy,
  Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140420/4de74d22/attachment.html>