From ezyang at mit.edu  Thu Jul  3 13:45:02 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 03 Jul 2014 14:45:02 +0100
Subject: Procedure for updating GHC submodule pointer to Cabal
Message-ID: <1404394928-sup-5028@sabre>

Hello all,

I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407)
and this functionality requires concurrent changes to GHC and Cabal.
However, GHC is currently tracking 1.20, but Cabal HEAD has marched on.

My question is, if I am to do this development on HEAD, what is the
standard operating procedure for retargeting GHC to a recent version of
Cabal?  Of course I have to go and validate the build, but are there
any other considerations? Is this recorded anywhere?

Thanks,
Edward

From johan.tibell at gmail.com  Thu Jul  3 13:57:00 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 3 Jul 2014 15:57:00 +0200
Subject: Procedure for updating GHC submodule pointer to Cabal
In-Reply-To: <1404394928-sup-5028@sabre>
References: <1404394928-sup-5028@sabre>
Message-ID: <CAK-tuPZHfakPcBs8vGRAM7aqFLNiRBznLmm-4G0D+hTC_-kQBA@mail.gmail.com>

With my Cabal maintainer hat on there are two important considerations:

 * Make sure your patches make it upstream.
 * Make sure that we make a Cabal release with your changes in it before
the next GHC release you're targeting your feature for.

In the past we had problems with GHC HQ releasing packages at HEAD without
upstream's blessing and sometimes with extra patches that never made it
upstream (which leaves a big risk that these patches get lost next time
upstream makes a release).

You can sync GHC's submodule to the latest Cabal HEAD and test to make sure
your patches work there. Alternatively GHC HQ can have a local Git branch
of 1.20 with your extra patches (but then really make sure that the above
holds.)



On Thu, Jul 3, 2014 at 3:45 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Hello all,
>
> I am working on module reexports (
> https://ghc.haskell.org/trac/ghc/ticket/8407)
> and this functionality requires concurrent changes to GHC and Cabal.
> However, GHC is currently tracking 1.20, but Cabal HEAD has marched on.
>
> My question is, if I am to do this development on HEAD, what is the
> standard operating procedure for retargeting GHC to a recent version of
> Cabal?  Of course I have to go and validate the build, but are there
> any other considerations? Is this recorded anywhere?
>
> Thanks,
> Edward
> _______________________________________________
> 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/20140703/223a7d69/attachment.html>

From hvr at gnu.org  Fri Jul  4 13:53:34 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 04 Jul 2014 15:53:34 +0200
Subject: Procedure for updating GHC submodule pointer to Cabal
In-Reply-To: <CAK-tuPZHfakPcBs8vGRAM7aqFLNiRBznLmm-4G0D+hTC_-kQBA@mail.gmail.com>
 (Johan Tibell's message of "Thu, 3 Jul 2014 15:57:00 +0200")
References: <1404394928-sup-5028@sabre>
 <CAK-tuPZHfakPcBs8vGRAM7aqFLNiRBznLmm-4G0D+hTC_-kQBA@mail.gmail.com>
Message-ID: <87iondnsbl.fsf@gnu.org>

Hi,

On 2014-07-03 at 15:57:00 +0200, Johan Tibell wrote:
> With my Cabal maintainer hat on there are two important considerations:
>
>  * Make sure your patches make it upstream.
>  * Make sure that we make a Cabal release with your changes in it before
> the next GHC release you're targeting your feature for.
>
> In the past we had problems with GHC HQ releasing packages at HEAD without
> upstream's blessing and sometimes with extra patches that never made it
> upstream (which leaves a big risk that these patches get lost next time
> upstream makes a release).
>
> You can sync GHC's submodule to the latest Cabal HEAD and test to make sure
> your patches work there. Alternatively GHC HQ can have a local Git branch
> of 1.20 with your extra patches (but then really make sure that the above
> holds.)

(Note: In the following, you can optionally replace 'master' by HEAD
while reading)

Fyi, right now, github.com/haskell/Cabal is automatically mirrored to
git.haskell.org/packages/Cabal, which for example means that pushing to
git.haskell.org's Cabal.git 'master' branch is disallowed via
configuration.

This setup was made possible by having Cabal.git as a submodule, so that
this provides implicitly a lagged mirror repository, while avoiding the
risk to ever diverge from the upstream Cabal repo (as you've mentioned
happened in the past).

ideally (IMHO), the changes needed for #8407 should be submitted to and
accepted by Cabal upstream first (as they need to be backward compat
with older GHCs anyway, so there's should be no reason not to get them
into Cabal 'master') and after they got merged into Cabal 'master',
ghc.git 'master's submodule can be updated to Cabal 'master' -- and from
that point on, GHC 7.10 will no longer be based on Cabal 1.20 but rather
be doomed to depend on a future Cabal 1.22+ release... probably.


From daniel.trstenjak at gmail.com  Tue Jul 15 10:48:53 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Tue, 15 Jul 2014 12:48:53 +0200
Subject: Library version choosing of cabal sandbox build
Message-ID: <20140715104853.GA21651@machine>


Hi,

if I'm having a cabal file without an upper bound for a library, the
newest available version of the library is 3, there's a local/user
installation of the version 2 of the library, which version of the
library is a cabal sandbox build supposed to use?

In my case I can see that version 2 of the library is used. If this
is intended, how can I ensure that always the newest version is used
independent of any local/user installations?

Thanks!


Greetings,
Daniel

From daniel.trstenjak at gmail.com  Tue Jul 15 10:57:40 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Tue, 15 Jul 2014 12:57:40 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140715104853.GA21651@machine>
References: <20140715104853.GA21651@machine>
Message-ID: <20140715105740.GA21963@machine>


dan at machine ~> cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.1 of the Cabal library

From johan.tibell at gmail.com  Tue Jul 15 11:07:17 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 15 Jul 2014 13:07:17 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140715105740.GA21963@machine>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
Message-ID: <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>

Cabal is allowed to use any version that fullfills the required bounds. It
uses a heuristic the tends to prefer

 * installed
 * newest
 * other

in that order.

If you want to make sure the newest version is used temporarily you can
pass --constraint="foo-1.2.3.4" to cabal install. If you want to make this
change more permanent you can set an exact version in a cabal.config file
in the same directory as the .cabal file.


On Tue, Jul 15, 2014 at 12:57 PM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

>
> dan at machine ~> cabal --version
> cabal-install version 1.20.0.3
> using version 1.20.0.1 of the Cabal library
> _______________________________________________
> 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/20140715/9d091b23/attachment.html>

From daniel.trstenjak at gmail.com  Tue Jul 15 11:15:23 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Tue, 15 Jul 2014 13:15:23 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
Message-ID: <20140715111523.GA22410@machine>


Hi Johan,

> Cabal is allowed to use any version that fullfills the required bounds. It uses
> a heuristic the tends to prefer
> 
> ?* installed
> ?* newest
> ?* other
> 
> in that order.
> 
> If you want to make sure the newest version is used temporarily you can pass
> --constraint="foo-1.2.3.4" to cabal install. If you want to make this change
> more permanent you can set an exact version in a cabal.config file in the same
> directory as the .cabal file.

So there's no flag to always use the newest one, right?

In my use case it would be a bit cumbersome to first find these libraries
and then to list all of them by hand.

The concrete use case is to test your project with the newest available library versions.


Greetings,
Daniel

From roma at ro-che.info  Tue Jul 15 12:33:47 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 15 Jul 2014 15:33:47 +0300
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140715111523.GA22410@machine>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140715111523.GA22410@machine>
Message-ID: <20140715123347.GA19357@sniper>

* Daniel Trstenjak <daniel.trstenjak at gmail.com> [2014-07-15 13:15:23+0200]
> 
> Hi Johan,
> 
> > Cabal is allowed to use any version that fullfills the required bounds. It uses
> > a heuristic the tends to prefer
> > 
> > ?* installed
> > ?* newest
> > ?* other
> > 
> > in that order.
> > 
> > If you want to make sure the newest version is used temporarily you can pass
> > --constraint="foo-1.2.3.4" to cabal install. If you want to make this change
> > more permanent you can set an exact version in a cabal.config file in the same
> > directory as the .cabal file.
> 
> So there's no flag to always use the newest one, right?
> 
> In my use case it would be a bit cumbersome to first find these libraries
> and then to list all of them by hand.
> 
> The concrete use case is to test your project with the newest available library versions.

You should create a fresh sandbox per build, then.

This is both sufficient (nothing is installed => no reason to prefer an older
version) and necessary (when in a sandbox, cabal won't let you have two
different versions of the library installed).

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140715/a81c832f/attachment.sig>

From daniel.trstenjak at gmail.com  Tue Jul 15 12:40:33 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Tue, 15 Jul 2014 14:40:33 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140715123347.GA19357@sniper>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140715111523.GA22410@machine> <20140715123347.GA19357@sniper>
Message-ID: <20140715124033.GA24730@machine>


Hi Roman,

> You should create a fresh sandbox per build, then.
> 
> This is both sufficient (nothing is installed => no reason to prefer an older
> version) and necessary (when in a sandbox, cabal won't let you have two
> different versions of the library installed).

As long as you haven't installed the library locally (in ~/.cabal) then
it's sufficient, otherwise it isn't.


Greetings,
Daniel

From roma at ro-che.info  Tue Jul 15 13:42:09 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 15 Jul 2014 16:42:09 +0300
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140715124033.GA24730@machine>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140715111523.GA22410@machine> <20140715123347.GA19357@sniper>
 <20140715124033.GA24730@machine>
Message-ID: <20140715134209.GA21273@sniper>

* Daniel Trstenjak <daniel.trstenjak at gmail.com> [2014-07-15 14:40:33+0200]
> 
> Hi Roman,
> 
> > You should create a fresh sandbox per build, then.
> > 
> > This is both sufficient (nothing is installed => no reason to prefer an older
> > version) and necessary (when in a sandbox, cabal won't let you have two
> > different versions of the library installed).
> 
> As long as you haven't installed the library locally (in ~/.cabal) then
> it's sufficient, otherwise it isn't.

When in a sandbox, cabal ignores the user package database. As long as you don't
install it *globally*, you should be fine.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140715/98dacfc5/attachment.sig>

From daniel.trstenjak at gmail.com  Wed Jul 16 07:42:45 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Wed, 16 Jul 2014 09:42:45 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
Message-ID: <20140716074245.GA2810@machine>


Hi Johan,

On Tue, Jul 15, 2014 at 01:07:17PM +0200, Johan Tibell wrote:
> Cabal is allowed to use any version that fullfills the required bounds. It uses
> a heuristic the tends to prefer
> 
> ?* installed
> ?* newest
> ?* other
> 
> in that order.

Just to make it clear, a cabal sandbox build does consider the installed
libraries in the user package database, right?


Greetings,
Daniel

From johan.tibell at gmail.com  Wed Jul 16 08:00:59 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 16 Jul 2014 10:00:59 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140716074245.GA2810@machine>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140716074245.GA2810@machine>
Message-ID: <CAK-tuPajvRBfAWMdurm8oTRDWsE+qLpbqd341h1-GKh0HeqyPg@mail.gmail.com>

Right


On Wed, Jul 16, 2014 at 9:42 AM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

>
> Hi Johan,
>
> On Tue, Jul 15, 2014 at 01:07:17PM +0200, Johan Tibell wrote:
> > Cabal is allowed to use any version that fullfills the required bounds.
> It uses
> > a heuristic the tends to prefer
> >
> >  * installed
> >  * newest
> >  * other
> >
> > in that order.
>
> Just to make it clear, a cabal sandbox build does consider the installed
> libraries in the user package database, right?
>
>
> Greetings,
> Daniel
> _______________________________________________
> 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/20140716/1ca6d2fb/attachment.html>

From roma at ro-che.info  Wed Jul 16 09:59:13 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 16 Jul 2014 12:59:13 +0300
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <CAK-tuPajvRBfAWMdurm8oTRDWsE+qLpbqd341h1-GKh0HeqyPg@mail.gmail.com>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140716074245.GA2810@machine>
 <CAK-tuPajvRBfAWMdurm8oTRDWsE+qLpbqd341h1-GKh0HeqyPg@mail.gmail.com>
Message-ID: <20140716095913.GA5731@sniper>

This doesn't make sense to me. Can you elaborate?

* Johan Tibell <johan.tibell at gmail.com> [2014-07-16 10:00:59+0200]
> Right
> 
> 
> On Wed, Jul 16, 2014 at 9:42 AM, Daniel Trstenjak <
> daniel.trstenjak at gmail.com> wrote:
> 
> >
> > Hi Johan,
> >
> > On Tue, Jul 15, 2014 at 01:07:17PM +0200, Johan Tibell wrote:
> > > Cabal is allowed to use any version that fullfills the required bounds.
> > It uses
> > > a heuristic the tends to prefer
> > >
> > >  * installed
> > >  * newest
> > >  * other
> > >
> > > in that order.
> >
> > Just to make it clear, a cabal sandbox build does consider the installed
> > libraries in the user package database, right?
> >
> >
> > Greetings,
> > Daniel
> > _______________________________________________
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140716/bc1a0c63/attachment.sig>

From johan.tibell at gmail.com  Wed Jul 16 10:00:27 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 16 Jul 2014 12:00:27 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140716095913.GA5731@sniper>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140716074245.GA2810@machine>
 <CAK-tuPajvRBfAWMdurm8oTRDWsE+qLpbqd341h1-GKh0HeqyPg@mail.gmail.com>
 <20140716095913.GA5731@sniper>
Message-ID: <CAK-tuPZazn+vGk+AL_SKCGr6ahongG7nWrDKN2tEtU+p7d2U0g@mail.gmail.com>

Sorry, I read this to quickly as I was in a rush this morning. Sandboxes
consider only the global package DB, not the user package DB.


On Wed, Jul 16, 2014 at 11:59 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> This doesn't make sense to me. Can you elaborate?
>
> * Johan Tibell <johan.tibell at gmail.com> [2014-07-16 10:00:59+0200]
> > Right
> >
> >
> > On Wed, Jul 16, 2014 at 9:42 AM, Daniel Trstenjak <
> > daniel.trstenjak at gmail.com> wrote:
> >
> > >
> > > Hi Johan,
> > >
> > > On Tue, Jul 15, 2014 at 01:07:17PM +0200, Johan Tibell wrote:
> > > > Cabal is allowed to use any version that fullfills the required
> bounds.
> > > It uses
> > > > a heuristic the tends to prefer
> > > >
> > > >  * installed
> > > >  * newest
> > > >  * other
> > > >
> > > > in that order.
> > >
> > > Just to make it clear, a cabal sandbox build does consider the
> installed
> > > libraries in the user package database, right?
> > >
> > >
> > > Greetings,
> > > Daniel
> > > _______________________________________________
> > > 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/20140716/303bca33/attachment-0001.html>

From daniel.trstenjak at gmail.com  Wed Jul 16 10:22:33 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Wed, 16 Jul 2014 12:22:33 +0200
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <CAK-tuPZazn+vGk+AL_SKCGr6ahongG7nWrDKN2tEtU+p7d2U0g@mail.gmail.com>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140716074245.GA2810@machine>
 <CAK-tuPajvRBfAWMdurm8oTRDWsE+qLpbqd341h1-GKh0HeqyPg@mail.gmail.com>
 <20140716095913.GA5731@sniper>
 <CAK-tuPZazn+vGk+AL_SKCGr6ahongG7nWrDKN2tEtU+p7d2U0g@mail.gmail.com>
Message-ID: <20140716102233.GA7098@machine>


On Wed, Jul 16, 2014 at 12:00:27PM +0200, Johan Tibell wrote:
> Sorry, I read this to quickly as I was in a rush this morning. Sandboxes
> consider only the global package DB, not the user package DB.

Ok, I just saw, that I've irritated myself, because just removing the
upper bound of the library wasn't sufficient, because an indirect
dependency of my project also depends on the library and still had an
upper bound.

Sorry for the confusion.


Greetings,
Daniel

From allbery.b at gmail.com  Wed Jul 16 13:00:18 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 16 Jul 2014 09:00:18 -0400
Subject: Library version choosing of cabal sandbox build
In-Reply-To: <20140716074245.GA2810@machine>
References: <20140715104853.GA21651@machine> <20140715105740.GA21963@machine>
 <CAK-tuPZC5tc1ap-qMYefgOpYkrc4YbmAZiVCxeDaWRdVv3ZAKg@mail.gmail.com>
 <20140716074245.GA2810@machine>
Message-ID: <CAKFCL4W_tMb33mXkbakksr_r39SauUK4fR5Kp7fOxgv-+iv_4g@mail.gmail.com>

On Wed, Jul 16, 2014 at 3:42 AM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

> Just to make it clear, a cabal sandbox build does consider the installed
> libraries in the user package database, right?
>

No, the sandbox mechanism coopts the user package database mechanism, so it
cannot see anything in the normal user package database --- the sandbox
*is* the user package database.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140716/0da55d46/attachment.html>

From ezyang at mit.edu  Fri Jul 18 16:58:45 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 18 Jul 2014 17:58:45 +0100
Subject: Heads up: Updating Cabal pointer to Cabal HEAD
Message-ID: <1405702570-sup-1753@sabre>

Hello folks,

In the interest in as small changes as possible, I am planning on
updating the version Cabal we're tracking against to Cabal HEAD
(after my build finishes validating, that is!)  At a later point,
when someone finally merges https://github.com/haskell/cabal/pull/1991
I'll make a smaller bump. I'll also file a bug on GHC Trac milestoned
for 7.10 to make sure we get a new Cabal release before next release.

Edward

Excerpts from Edward Z. Yang's message of 2014-07-03 14:45:02 +0100:
> Hello all,
> 
> I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407)
> and this functionality requires concurrent changes to GHC and Cabal.
> However, GHC is currently tracking 1.20, but Cabal HEAD has marched on.
> 
> My question is, if I am to do this development on HEAD, what is the
> standard operating procedure for retargeting GHC to a recent version of
> Cabal?  Of course I have to go and validate the build, but are there
> any other considerations? Is this recorded anywhere?
> 
> Thanks,
> Edward

From ezyang at mit.edu  Mon Jul 21 17:43:10 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 21 Jul 2014 18:43:10 +0100
Subject: Multi-instance packages status report
Message-ID: <1405962902-sup-6315@sabre>

Hello all,

As you may have noticed, I've been knocking around GHC and Cabal the
past few weeks.  One of the tasks that has been on my list is
essentially reimplementing Philipp Schuster's 2012 GSoC, with a few
small but important architectural differences.  Here is a status report
of what is going on.

In my copy of GHC and Cabal [1,2], you can now install multiple copies of a
package with differing dependencies to the package database, i.e. q-1.0
compiled against p-1.0, and against p-2.0.  The packages in the database
are distinguished via a *package key*, which is an md5 hash of the
package id (e.g. q-1.0) and the sorted list of the package IDs of the
transitive closure of dependencies (e.g. p-1.0 or p-2.0).  The package
key is used to generate linker symbols for packages, so it's possible to
link together both copies of q in the same program, as long as you
rename the modules appropriately (of course, the redefined types are
considered unequal).  When registering a package, ghc-pkg now checks
and removes duplicate package keys, as opposed to package IDs.

I've also implemented many of the necessary niceties for making it
pleasant to deal with duplicated package IDs: for example, GHC's output
logic has been adjusted to only qualify a package ID with the package
key when there are multiples of the same package ID exposed in the
database.  I've also adjusted GHC's build system to use package keys
rather than package IDs to refer to packages when building.

Like the original GSoC project, we still need to have decisions on some
of the major design choices.  I think the most pressing one is
"simplistic dependency resolution" when you use, e.g. ghc -package
foo-1.0 or ./Setup configure --with-constraint="foo==1.0".  Right now, I
pick dependencies in an unspecified manner, check if they are
consistent, and bail out if they are not.  As it turns out, both
GHC and ./Setup configure will already compute the transitive closure of
dependencies, so I suspect we might be able to do something clever here.
Less pressing but eventually necessary is clueing in cabal-install.

Comments would be especially appreciated.

Cheers,
Edward

[1] https://phabricator.haskell.org/D80
[2] https://github.com/haskell/cabal/pull/2002

From kgadek at gmail.com  Wed Jul 23 21:10:59 2014
From: kgadek at gmail.com (=?utf-8?Q?Konrad_G=C4=85dek?=)
Date: Wed, 23 Jul 2014 23:10:59 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
Message-ID: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>

Hi,


It seems that?http://www.haskell.org/cabal/release/cabal-install-latest/?is pointing to cabal-install-1.20.0.1 while there is 1.20.0.3 already ? is this a "whoopsie" or is there a reason for this?

--?
Konrad G?dek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140723/ccfdbee7/attachment.html>

From johan.tibell at gmail.com  Thu Jul 24 05:51:46 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 24 Jul 2014 07:51:46 +0200
Subject: Enhancement: Default cabal to `-p` profiling enabled
In-Reply-To: <CAHXt_SU-OC+1KcG-impfYc3zqCt3nW5obGkGvbZM0kYfyi=YGQ@mail.gmail.com>
References: <CAHXt_SUMcOs=8KXYX4a-3i9jKs1oGmviAfKsogQbi=13ULN6OQ@mail.gmail.com>
 <CACbaDy5g5brud6EjjcxEDAUYcEvW1LQsth9rcV1z5BCxoLLq0w@mail.gmail.com>
 <53D049B2.1000807@nh2.me>
 <CAHXt_SU-OC+1KcG-impfYc3zqCt3nW5obGkGvbZM0kYfyi=YGQ@mail.gmail.com>
Message-ID: <CAK-tuPYys0kQ4txqW-nuxg5TcrVfRQiURcTNs6V8q3BhPJsG4A@mail.gmail.com>

It will be less painful to enable profiling by default when someone
finishes the parallel build support for profiling "ways". That would
mean that we can build the vanilla and profiling version of a library
at the same time, saving quite a bit of time.

From johan.tibell at gmail.com  Thu Jul 24 09:41:32 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 24 Jul 2014 11:41:32 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
In-Reply-To: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
References: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
Message-ID: <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>

Hi,

We don't have any binary builds of 1.20.0.3 so I thought it better to
point to a release where we have such. If someone can provide me with
a windows build (.tar.gz containing exe please, built using latest
Cabal-1.20. Include the arch used in the email.)
I can create a OS X binary and update the website.

On Wed, Jul 23, 2014 at 11:10 PM, Konrad G?dek <kgadek at gmail.com> wrote:
> Hi,
>
>
> It seems that http://www.haskell.org/cabal/release/cabal-install-latest/ is
> pointing to cabal-install-1.20.0.1 while there is 1.20.0.3 already ? is this
> a "whoopsie" or is there a reason for this?
>
> --
> Konrad G?dek
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>

From ezyang at mit.edu  Thu Jul 24 13:56:22 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 24 Jul 2014 14:56:22 +0100
Subject: Removing GHC's dependency on Cabal
Message-ID: <1406208563-sup-6481@sabre>

Hello all,

I know Duncan and SPJ have been keen on removing GHC's dependency on
Cabal for some time now.  Simon and I were chatting about the subject
today, and we wanted to propose an alternative way of doing the
remodularization.

Here are diagrams of the proposals:
http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf

As I understand it, Duncan's proposal is to take the current
constellation of libraries, and just remove the dependency to Cabal from
GHC and bin-package-db, duplicating data structures as necessary.
ghc-pkg is now responsible for converting between Cabal's format and
GHC's format.

Simon suggested that this 'ghc-pkg' functionality (which specifies
the database format and how to handle it) should be placed in a library
of its own.  So in the third graph, we have a new package ghc-db which
everyone depends on.  Cabal no longers shells out to ghc-pkg to modify
database, instead it directly converts to ghc-db's format and then
invokes library functions in the library.

We were wondering if there was any reason to prefer the former
situation over the latter. One answer might be that Cabal is less keen
to have a dependency on a very GHC specific library (although the
ghc-pkg dependency is quite a fairly tightly coupled one.)

Cheers,
Edward

From the.dead.shall.rise at gmail.com  Thu Jul 24 14:03:13 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 24 Jul 2014 16:03:13 +0200
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <1406208563-sup-6481@sabre>
References: <1406208563-sup-6481@sabre>
Message-ID: <CA+tcxkAgV5Mej_V+skW5PPf_APui+EGxcP1xVW6hrzue6GKpLg@mail.gmail.com>

Hi,

On 24 July 2014 15:56, Edward Z. Yang <ezyang at mit.edu> wrote:
> We were wondering if there was any reason to prefer the former
> situation over the latter. One answer might be that Cabal is less keen
> to have a dependency on a very GHC specific library (although the
> ghc-pkg dependency is quite a fairly tightly coupled one.)

If this new proposal will allow us not to ship Cabal with GHC, then I
think it's preferable to the old one. For example, Haskell Platform is
often forced to use an old version of Cabal because the Cabal version
is determined by the GHC version.

From mail at joachim-breitner.de  Thu Jul 24 14:07:14 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 24 Jul 2014 16:07:14 +0200
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <1406208563-sup-6481@sabre>
References: <1406208563-sup-6481@sabre>
Message-ID: <1406210834.4078.8.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang:
> We were wondering if there was any reason to prefer the former
> situation over the latter. 

One way to decide that is to ask ?What is the more stable interface??
I.e. under what circumstances will upgrading Cabal require upgrading
packages depended upon by ghc.

So while Duncan?s Proposal has no such dependency, in Simon?s proposal
there is one. Will ghc-db?s interface be stable enough that the Cabal
developers will be happy to build against a very old version of it?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140724/ec44692e/attachment.sig>

From allbery.b at gmail.com  Thu Jul 24 14:07:34 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 24 Jul 2014 10:07:34 -0400
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <1406208563-sup-6481@sabre>
References: <1406208563-sup-6481@sabre>
Message-ID: <CAKFCL4VOJA512WiTifDzoiRb4L8+-CAmMp8vQCESSNQjSPC_Tw@mail.gmail.com>

On Thu, Jul 24, 2014 at 9:56 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> We were wondering if there was any reason to prefer the former
> situation over the latter. One answer might be that Cabal is less keen
> to have a dependency on a very GHC specific library (although the
> ghc-pkg dependency is quite a fairly tightly coupled one.)
>

I continue to think cabal-install should use a plugin architecture. How
that is relevant here is that either the Cabal library also would use
plugins, or the existing Cabal library would stop pretending to be
compiler-agnostic and become a Cabal-ghc plugin/library. (Or quite possibly
both, depending on expected usage.)

(Of course, then there is the question of how to do compiler-agnostic
plugins that have a chance of working with currently nonexistent
alternative compilers....)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140724/5da42314/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Jul 24 14:30:02 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 24 Jul 2014 16:30:02 +0200
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <1406210834.4078.8.camel@joachim-breitner.de>
References: <1406208563-sup-6481@sabre>
 <1406210834.4078.8.camel@joachim-breitner.de>
Message-ID: <CA+tcxkDktTZRoHFSdzm=oBBt6wAsqWxL5-9tYDdE3+mxD-fP3Q@mail.gmail.com>

Hi,

On 24 July 2014 16:07, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> So while Duncan?s Proposal has no such dependency, in Simon?s proposal
> there is one. Will ghc-db?s interface be stable enough that the Cabal
> developers will be happy to build against a very old version of it?

Cabal's policy is to support versions of GHC that are up to 3 years
old, so I think this could be solved with a combination of #ifdefs and
automatic testing.

From simonpj at microsoft.com  Thu Jul 24 14:55:03 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Jul 2014 14:55:03 +0000
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <1406210834.4078.8.camel@joachim-breitner.de>
References: <1406208563-sup-6481@sabre>
 <1406210834.4078.8.camel@joachim-breitner.de>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF1043804B@DB3PRD3001MB020.064d.mgd.msft.net>

The way I am thinking of it is this. In "Simon's proposal" in
  http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf
the ghc-db library is simply a Haskell library that gives a programmatic way to interact with GHC's installed package database(s). GHC needs that.  ghc-pkg needs that.  cabal needs that.  There should be one thing that supplies it.

Cabal currently shells out to ghc-pkg, which in turn mandates a special file format (the .conf file) that Cabal uses to communicate its wishes to ghc-pkg.  This needs syntax, a parser, a pretty printer, and is, to all intents and purposes  just as stable, or unstable, as a Haskell API to ghc-db would be.

To me it seems simple and obvious!  Why are we going round the houses to do something so simple?

Simon


| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 24 July 2014 15:07
| To: ghc-devs at haskell.org
| Cc: cabal-devel
| Subject: Re: Removing GHC's dependency on Cabal
| 
| Hi,
| 
| 
| Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang:
| > We were wondering if there was any reason to prefer the former
| > situation over the latter.
| 
| One way to decide that is to ask ?What is the more stable interface??
| I.e. under what circumstances will upgrading Cabal require upgrading
| packages depended upon by ghc.
| 
| So while Duncan?s Proposal has no such dependency, in Simon?s proposal
| there is one. Will ghc-db?s interface be stable enough that the Cabal
| developers will be happy to build against a very old version of it?
| 
| Greetings,
| Joachim
| 
| 
| --
| Joachim ?nomeata? Breitner
|   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|   Debian Developer: nomeata at debian.org


From allbery.b at gmail.com  Thu Jul 24 14:59:37 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 24 Jul 2014 10:59:37 -0400
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF1043804B@DB3PRD3001MB020.064d.mgd.msft.net>
References: <1406208563-sup-6481@sabre>
 <1406210834.4078.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF1043804B@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAKFCL4VKwjo384wg2yGiPe6ZsnO9HotgdEXaszVF9u2zfv2k1g@mail.gmail.com>

On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> To me it seems simple and obvious!  Why are we going round the houses to
> do something so simple?


So cabal can maintain its conceit that it supports more than just ghc.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140724/9ecd5a38/attachment.html>

From ydewit at gmail.com  Thu Jul 24 15:32:43 2014
From: ydewit at gmail.com (Yuri de Wit)
Date: Thu, 24 Jul 2014 12:32:43 -0300
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <CAKFCL4VKwjo384wg2yGiPe6ZsnO9HotgdEXaszVF9u2zfv2k1g@mail.gmail.com>
References: <1406208563-sup-6481@sabre>
 <1406210834.4078.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF1043804B@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAKFCL4VKwjo384wg2yGiPe6ZsnO9HotgdEXaszVF9u2zfv2k1g@mail.gmail.com>
Message-ID: <CA++tqLbxtrqn6-4CMBQKWBq0oB6GM9PiFdjfKQ_9a_gk9qbziQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>> To me it seems simple and obvious!  Why are we going round the houses to
>> do something so simple?
>
>
>  So cabal can maintain its conceit that it supports more than just ghc.
>

I don't understand this as an argument against the ghc-db library, which to
me also seems the simple and obvious solution.

Having a ghc-db library will mean one of two options:
1. The *ghc-db* is GHC-specific and will be used by the GHC specific
wrappers in Cabal: doesn't cabal already deals with each compiler
differently?
2. The ghc-db is really *hs-db* and a library contract that can be reused
by all haskell compilers (i.e. part of The Haskell Cabal)

In both cases, the assumption is that ghc-db/hs-db should have a stable API.

Now, choosing option (1) doesn't eliminate option (2). When and if there is
a broad agreement across all compilers, ghc-db could become hs-db and be
incorporate into The Haskell Cabal.




>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> 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/20140724/d8108706/attachment-0001.html>

From allbery.b at gmail.com  Thu Jul 24 15:36:35 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 24 Jul 2014 11:36:35 -0400
Subject: Removing GHC's dependency on Cabal
In-Reply-To: <CA++tqLbxtrqn6-4CMBQKWBq0oB6GM9PiFdjfKQ_9a_gk9qbziQ@mail.gmail.com>
References: <1406208563-sup-6481@sabre>
 <1406210834.4078.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF1043804B@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAKFCL4VKwjo384wg2yGiPe6ZsnO9HotgdEXaszVF9u2zfv2k1g@mail.gmail.com>
 <CA++tqLbxtrqn6-4CMBQKWBq0oB6GM9PiFdjfKQ_9a_gk9qbziQ@mail.gmail.com>
Message-ID: <CAKFCL4VLPZ-c4mcWnBe5rZ=gqMPo21EotQUNhzSfT95iG2+bjQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 11:32 AM, Yuri de Wit <ydewit at gmail.com> wrote:

> On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>> To me it seems simple and obvious!  Why are we going round the houses to
>>> do something so simple?
>>
>>
>>  So cabal can maintain its conceit that it supports more than just ghc.
>>
>
> I don't understand this as an argument against the ghc-db library, which
> to me also seems the simple and obvious solution.
>

I did not say it was a *sane* conceit; and in fact my choice of wording
there was intended to bring it into question. My experience is Cabal and
cabal-install try to maintain this, but in a way that doesn't actually
accomplish the goal very well (see for example the abortive attempt at jhc
cabal support).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140724/1e19cc21/attachment.html>

From nikita at karetnikov.org  Fri Jul 25 13:44:57 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Fri, 25 Jul 2014 17:44:57 +0400
Subject: [PATCH] Change 'whenCacheOutOfDate' to use '>' again.
Message-ID: <87y4vhmu1y.fsf@karetnikov.org>

As some of you may know, I?m trying to make ?cabal install? verify
OpenPGP signatures that come from Hackage.  I modified
?updatePackageIndexCacheFile? to ask whether a certain OpenPGP public
key should be trusted, but I later discovered that the mentioned
function is called twice during ?cabal update?*, which means that all
questions are also asked twice.

I believe this doesn?t affect #1443 anymore.  If so, please apply the
attached patch.

* ?update? uses ?updateRepo? and ?checkForSelfUpgrade?.  The former runs
  ?updatePackageIndexCacheFile? via ?updateRepoIndexCache?.  The latter
  calls ?updatePackageIndexCacheFile? via a sequence of calls from
  ?getSourcePackages? to ?getSourcePackages?? to ?readRepoIndex? to
  ?whenCacheOutOfDate?.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Change-whenCacheOutOfDate-to-use-again.patch
Type: text/x-diff
Size: 946 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140725/c768365c/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/20140725/c768365c/attachment.sig>

From the.dead.shall.rise at gmail.com  Fri Jul 25 13:49:37 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Fri, 25 Jul 2014 15:49:37 +0200
Subject: [PATCH] Change 'whenCacheOutOfDate' to use '>' again.
In-Reply-To: <87y4vhmu1y.fsf@karetnikov.org>
References: <87y4vhmu1y.fsf@karetnikov.org>
Message-ID: <CA+tcxkCseQ2SKso=PUAXQMp2nq8E_-8vg+tSGBkJtnTG8jcphg@mail.gmail.com>

Hi,

On 25 July 2014 15:44, Nikita Karetnikov <nikita at karetnikov.org> wrote:
>
> I believe this doesn?t affect #1443 anymore.

Why? Have you tested this patch ?

From nikita at karetnikov.org  Fri Jul 25 17:21:19 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Fri, 25 Jul 2014 21:21:19 +0400
Subject: [PATCH] Change 'whenCacheOutOfDate' to use '>' again.
In-Reply-To: <CA+tcxkCseQ2SKso=PUAXQMp2nq8E_-8vg+tSGBkJtnTG8jcphg@mail.gmail.com>
 (Mikhail Glushenkov's message of "Fri, 25 Jul 2014 15:49:37 +0200")
References: <87y4vhmu1y.fsf@karetnikov.org>
 <CA+tcxkCseQ2SKso=PUAXQMp2nq8E_-8vg+tSGBkJtnTG8jcphg@mail.gmail.com>
Message-ID: <87k371jqwg.fsf@karetnikov.org>

(Oops, resending to the list.)

>> I believe this doesn?t affect #1443 anymore.

> Why? Have you tested this patch ?

I said ?believe? because I had to explicitly install process and
texmath, but I think that?s not relevant.  ?cabal install --only-dep?
and ?cabal info pandoc-types-1.12.4? succeeded after that.

Do you have a better testcase?  Why does ?whenCacheOutOfDate? run the
action on ?=? in the first place?  If the cache file has the same
modification time as the original, it means that the cache is
up-to-date, no?
-------------- 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/20140725/5116e6b2/attachment.sig>

From the.dead.shall.rise at gmail.com  Fri Jul 25 20:42:40 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Fri, 25 Jul 2014 22:42:40 +0200
Subject: [PATCH] Change 'whenCacheOutOfDate' to use '>' again.
In-Reply-To: <87k371jqwg.fsf@karetnikov.org>
References: <87y4vhmu1y.fsf@karetnikov.org>
 <CA+tcxkCseQ2SKso=PUAXQMp2nq8E_-8vg+tSGBkJtnTG8jcphg@mail.gmail.com>
 <87k371jqwg.fsf@karetnikov.org>
Message-ID: <CA+tcxkDKHnsmBPfcP6mfie_8p-0wBDcjDxu5vPq+oAL58Z-8hA@mail.gmail.com>

Hi,

On 25 July 2014 19:21, Nikita Karetnikov <nikita at karetnikov.org> wrote:
>
> Do you have a better testcase?  Why does ?whenCacheOutOfDate? run the
> action on ?=? in the first place?  If the cache file has the same
> modification time as the original, it means that the cache is
> up-to-date, no?

OK, I tested your patch and it seems to work. I guess that what
actually fixed that bug was the change from getModificationTime to
getModTime (which has higher resolution).

From nikita at karetnikov.org  Fri Jul 25 22:20:44 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Sat, 26 Jul 2014 02:20:44 +0400
Subject: [PATCH] Print a more friendly message when http_proxy is down.
Message-ID: <87fvhpgjwj.fsf@karetnikov.org>

An attempt to fix #1962.  I think the exception comes from ?connect? in
?Network.Socket?. I doubt that the proposed error message is friendly
enough.  Ideas?  Also, can ?handleJust? catch ?IOException?s that are
not related to http_proxy?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Print-a-more-friendly-message-when-http_proxy-is-dow.patch
Type: text/x-diff
Size: 2072 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140726/9fb39ab7/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/20140726/9fb39ab7/attachment.sig>

From the.dead.shall.rise at gmail.com  Fri Jul 25 22:56:21 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 26 Jul 2014 00:56:21 +0200
Subject: [PATCH] Print a more friendly message when http_proxy is down.
In-Reply-To: <87fvhpgjwj.fsf@karetnikov.org>
References: <87fvhpgjwj.fsf@karetnikov.org>
Message-ID: <CA+tcxkBJK--o57cG57sYDY5j4Pe9jp2bWbcb9LunB0TnS4b-ew@mail.gmail.com>

Hi,

On 26 July 2014 00:20, Nikita Karetnikov <nikita at karetnikov.org> wrote:
> An attempt to fix #1962.  I think the exception comes from ?connect? in
> ?Network.Socket?.

Perhaps it's better to solve this in HTTP itself? It gives decent
error messages in other cases:

$ export HTTP_PROXY=foo
$ cabal update
Downloading the latest package list from hackage.haskell.org
cabal: openTCPConnection: host lookup failure for "foo"

$ export HTTP_PROXY=http://localhost:3128
$ cabal update
Downloading the latest package list from hackage.haskell.org
cabal: does not exist

From nikita at karetnikov.org  Sat Jul 26 06:55:40 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Sat, 26 Jul 2014 10:55:40 +0400
Subject: [PATCH] Print a more friendly message when http_proxy is down.
In-Reply-To: <CA+tcxkBJK--o57cG57sYDY5j4Pe9jp2bWbcb9LunB0TnS4b-ew@mail.gmail.com>
 (Mikhail Glushenkov's message of "Sat, 26 Jul 2014 00:56:21 +0200")
References: <87fvhpgjwj.fsf@karetnikov.org>
 <CA+tcxkBJK--o57cG57sYDY5j4Pe9jp2bWbcb9LunB0TnS4b-ew@mail.gmail.com>
Message-ID: <87iomkfw2b.fsf@karetnikov.org>

> Perhaps it's better to solve this in HTTP itself?

I think so.

> cabal: openTCPConnection: host lookup failure for "foo"

What version of network is it?  I ran ?grep -r ?host lookup failure?? on
the source of 2.5.0.0 and didn?t find anything.
-------------- 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/20140726/42f05ea7/attachment.sig>

From the.dead.shall.rise at gmail.com  Sat Jul 26 08:15:23 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 26 Jul 2014 10:15:23 +0200
Subject: [PATCH] Print a more friendly message when http_proxy is down.
In-Reply-To: <87iomkfw2b.fsf@karetnikov.org>
References: <87fvhpgjwj.fsf@karetnikov.org>
 <CA+tcxkBJK--o57cG57sYDY5j4Pe9jp2bWbcb9LunB0TnS4b-ew@mail.gmail.com>
 <87iomkfw2b.fsf@karetnikov.org>
Message-ID: <CA+tcxkCE1JL=KUF6_=rd0T+pmOE5KVLEQPzkRpC=9sP41QhhZQ@mail.gmail.com>

Hi,

On 26 July 2014 08:55, Nikita Karetnikov <nikita at karetnikov.org> wrote:
>
> What version of network is it?  I ran ?grep -r ?host lookup failure?? on
> the source of 2.5.0.0 and didn?t find anything.

$ cabal sandbox hc-pkg list | grep network
    network-2.5.0.0

It probably uses perror or something like it.

From allbery.b at gmail.com  Sat Jul 26 15:01:29 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 26 Jul 2014 11:01:29 -0400
Subject: [PATCH] Print a more friendly message when http_proxy is down.
In-Reply-To: <CA+tcxkCE1JL=KUF6_=rd0T+pmOE5KVLEQPzkRpC=9sP41QhhZQ@mail.gmail.com>
References: <87fvhpgjwj.fsf@karetnikov.org>
 <CA+tcxkBJK--o57cG57sYDY5j4Pe9jp2bWbcb9LunB0TnS4b-ew@mail.gmail.com>
 <87iomkfw2b.fsf@karetnikov.org>
 <CA+tcxkCE1JL=KUF6_=rd0T+pmOE5KVLEQPzkRpC=9sP41QhhZQ@mail.gmail.com>
Message-ID: <CAKFCL4U03TAiPME-i_cLTUVSX9AKSO9K9KxGmrFS8+p3hqGJVQ@mail.gmail.com>

On Sat, Jul 26, 2014 at 4:15 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> On 26 July 2014 08:55, Nikita Karetnikov <nikita at karetnikov.org> wrote:
> > What version of network is it?  I ran ?grep -r ?host lookup failure?? on
> > the source of 2.5.0.0 and didn?t find anything.
>
> $ cabal sandbox hc-pkg list | grep network
>     network-2.5.0.0
>
> It probably uses perror or something like it.


gai_strerror(3) or hstrerror(3) depending on whether ipv6 support was found
or not, I'd think.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140726/9da79b3a/attachment.html>

From ezyang at mit.edu  Sat Jul 26 21:36:57 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 26 Jul 2014 22:36:57 +0100
Subject: Killing or resurrecting version tags for good
Message-ID: <1406409546-sup-6363@sabre>

Hello all,

A while back, I was nattering around the parsing code for Cabal,
and I noticed that Cabal still had code for parsing version tags,
but was explicitly *not* printing out version tags.  I proposed
that we should get rid of the parsing code as well, but when
I mentioned this on #ghc Mark Lentczner (cc'ed) mentioned that
they were using version tags to identify different versions during
a build, e.g. what Git version things correspond to.

I am not going to claim to know the right answer to this question,
but in either case, it is terrible that we are PARSING tags but
not PRINTING them.  This leads to terrible error messages, among
other things, such as in this case:

    $ ghc-pkg describe json-0.7-foo
    ghc-pkg: cannot find package json-0.7

(NB: json-0.7 is installed.)

So if we're keeping tags around, at least for the immediate future,
then we should print them; otherwise, we should get rid of them
entirely!

Edward

From the.dead.shall.rise at gmail.com  Sat Jul 26 22:44:39 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sun, 27 Jul 2014 00:44:39 +0200
Subject: Killing or resurrecting version tags for good
In-Reply-To: <1406409546-sup-6363@sabre>
References: <1406409546-sup-6363@sabre>
Message-ID: <CA+tcxkCenkp+LK2nS6D3Uenj7Ne=twY5JX2OZ5Lgo3qREXsevQ@mail.gmail.com>

Hi,

On 26 July 2014 23:36, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hello all,
>
> A while back, I was nattering around the parsing code for Cabal,
> and I noticed that Cabal still had code for parsing version tags,
> but was explicitly *not* printing out version tags. [...]
>
> So if we're keeping tags around, at least for the immediate future,
> then we should print them; otherwise, we should get rid of them
> entirely!

IIRC, Duncan wants to remove version tags both from Cabal and
Data.Version. So perhaps it's time to deprecate them.

From ezyang at mit.edu  Sat Jul 26 22:50:28 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 26 Jul 2014 23:50:28 +0100
Subject: Killing or resurrecting version tags for good
In-Reply-To: <CA+tcxkCenkp+LK2nS6D3Uenj7Ne=twY5JX2OZ5Lgo3qREXsevQ@mail.gmail.com>
References: <1406409546-sup-6363@sabre>
 <CA+tcxkCenkp+LK2nS6D3Uenj7Ne=twY5JX2OZ5Lgo3qREXsevQ@mail.gmail.com>
Message-ID: <1406414990-sup-9778@sabre>

Excerpts from Mikhail Glushenkov's message of 2014-07-26 23:44:39 +0100:
> IIRC, Duncan wants to remove version tags both from Cabal and
> Data.Version. So perhaps it's time to deprecate them.

My question here is orthogonal to the question of deprecation:
if we are deprecating them, but not removing them, we should
still print the tags while we still ostensibly support them!

Edward

From the.dead.shall.rise at gmail.com  Tue Jul 29 01:13:19 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 29 Jul 2014 03:13:19 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
In-Reply-To: <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>
References: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
 <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>
Message-ID: <CA+tcxkAtZ=Tn6809PXq986c=TDFFP_J9foBctbdrfehf3jfoCw@mail.gmail.com>

Hi,

On 24 July 2014 11:41, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi,
>
> We don't have any binary builds of 1.20.0.3 so I thought it better to
> point to a release where we have such. If someone can provide me with
> a windows build (.tar.gz containing exe please, built using latest
> Cabal-1.20. Include the arch used in the email.)
> I can create a OS X binary and update the website.

Attached.
?
 cabal-1.20.0.3-i386-unknown-mingw32.tar.gz
<https://docs.google.com/file/d/0B-gmfQNqT8HteERTeGlGODZERVU/edit?usp=drive_web>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140729/c30a1edb/attachment.html>

From johan.tibell at gmail.com  Tue Jul 29 07:44:13 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 29 Jul 2014 09:44:13 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
In-Reply-To: <CA+tcxkAtZ=Tn6809PXq986c=TDFFP_J9foBctbdrfehf3jfoCw@mail.gmail.com>
References: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
 <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>
 <CA+tcxkAtZ=Tn6809PXq986c=TDFFP_J9foBctbdrfehf3jfoCw@mail.gmail.com>
Message-ID: <CAK-tuPYjeqpjJB2mW=DZwnjQXG-JxvpcgsWOMjZXxGtU+KqqwQ@mail.gmail.com>

Uploaded, thanks!


On Tue, Jul 29, 2014 at 3:13 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi,
>
>
> On 24 July 2014 11:41, Johan Tibell <johan.tibell at gmail.com> wrote:
> > Hi,
> >
> > We don't have any binary builds of 1.20.0.3 so I thought it better to
> > point to a release where we have such. If someone can provide me with
> > a windows build (.tar.gz containing exe please, built using latest
> > Cabal-1.20. Include the arch used in the email.)
> > I can create a OS X binary and update the website.
>
> Attached.
> ?
>  cabal-1.20.0.3-i386-unknown-mingw32.tar.gz
> <https://docs.google.com/file/d/0B-gmfQNqT8HteERTeGlGODZERVU/edit?usp=drive_web>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140729/2b58c363/attachment.html>

From nikita at karetnikov.org  Tue Jul 29 22:17:56 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Wed, 30 Jul 2014 02:17:56 +0400
Subject: Proposal: cabal-install: verify OpenPGP signatures
In-Reply-To: <87oaxel7rf.fsf@karetnikov.org> (Nikita Karetnikov's message of
 "Fri, 27 Jun 2014 18:57:56 +0400")
References: <87eh0fafsq.fsf@karetnikov.org>
 <1399287343.18197.190.camel@dunky.localdomain>
 <87iopjuq7j.fsf@karetnikov.org> <87zjhh349d.fsf@karetnikov.org>
 <87oaxel7rf.fsf@karetnikov.org>
Message-ID: <87bns7stbf.fsf@karetnikov.org>

I?ve just pushed the commit [1] allowing to cache OpenPGP public keys on
?cabal update?.  (Note that I haven?t written the needed code for ?cabal
install? yet, so the rest of this message is only about ?update?.)

After talking to people on #gnupg (thanks!), I decided to abandon the
previous idea of relying on a ?positive certification of a User ID and
Public-Key packet? [2] in order to determine whether a certain key is
trusted.  Key changes must be treated with care, so now a user must
manually mark each key contained in the index tarball [3] as trusted or
untrusted.  This is tedious, but there are workarounds (like sharing the
list of (un)trusted keys with people you trust).  I also assume this
should happen rarely after the initial update.  A short demo follows.

First, you need to obtain the source code from this repository [4] and
switch to the ?openpgp? branch.  Configure and install as usual, then
run these commands:

$ dist/build/hackage-server/hackage-server init
$ dist/build/hackage-server/hackage-server run --static-dir=datafiles

Register a couple of test accounts [5] (this process requires sendmail).
And don?t forget to upload a public key at the temporary page.  Keep the
server running because it currently cannot recover public keys after
shutdown.

Clone this repository [6], checkout the ?openpgp? branch, and build it.
Create a test config file.  In mine, these lines differ from the
defaults:

remote-repo: localhost:http://localhost:8080/packages/archive
remote-repo-cache: /home/nikita/cabal/test-cabal-dir/packages
world-file: /home/nikita/cabal/test-cabal-dir/world

After that you should be able to see something similar:

$ dist/build/cabal/cabal \
>   --config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \
>   --ignore-sandbox update
Downloading the latest package list from localhost
Do you trust the following key of test01? (yes/no/Skip)
Test Key (do not use) <root at localhost>
  1024 bit RSA key B10D 6514 06C6 9846 F0BF  C2E6 1E50 C29A F1EE 591F, created: 2014-06-21 11:38:39 UTC
yes
Marking the key as trusted.
Do you trust the following key of test02? (yes/no/Skip)
Test Key2 (do not use) <root at localhost>
  1024 bit RSA key E2C2 CA45 9442 3F0D 58D3  059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC
s
Skipping the key.

(See the code in ?IndexUtils.hs? for the list of supported commands.)

?Yes? writes the key into
?test-cabal-dir/packages/localhost/public-keys?, which may later be used
by ?cabal install? to verify a signature.  (This is not implemented
yet.)

?Skip? (or any unrecognized command) simply prints the message.  So
the question will be asked again when ?cabal update? is run:

$ dist/build/cabal/cabal \
>   --config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \
>   --ignore-sandbox update
Downloading the latest package list from localhost
Do you trust the following key of test02? (yes/no/Skip)
Test Key2 (do not use) <root at localhost>
  1024 bit RSA key E2C2 CA45 9442 3F0D 58D3  059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC
no
Marking the key as untrusted.

?No? adds the fingerprint to
?test-cabal-dir/packages/localhost/untrusted-fingerprints?.  After that
a user will never be asked about this key:

$ dist/build/cabal/cabal \
>   --config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \
>   --ignore-sandbox update
Downloading the latest package list from localhost

A warning is raised if a trusted key is already present in the cache:

$ cd /home/nikita/cabal/test-cabal-dir/packages/localhost/public-keys
$ mv test02-public.txt test01-public.txt
$ cd -
$ dist/build/cabal/cabal \
>   --config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \
>   --ignore-sandbox update
Downloading the latest package list from localhost
Warning: the cache already contains the following public key corresponding to test01:
Test Key2 (do not use) <root at localhost>
  1024 bit RSA key E2C2 CA45 9442 3F0D 58D3  059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC
Do you trust the following key of test01? (yes/no/Skip)
Test Key (do not use) <root at localhost>
  1024 bit RSA key B10D 6514 06C6 9846 F0BF  C2E6 1E50 C29A F1EE 591F, created: 2014-06-21 11:38:39 UTC
  C-c C-c

(?Yes? would replace the existing key.)

That?s all for now.  Any comments are appreciated.

Next I?m planning to make this process optional (via a command line
flag) and augment ?cabal install? to use this.

It also bothers me that ?hackage-server? and ?cabal-install? have nearly
the same code in ?OpenPGP.hs?.  I?ll try to contribute it to ?hOpenPGP?,
so it can be imported from there.

[1] https://gitorious.org/cabal/cabal/commits/openpgp
[2] https://tools.ietf.org/html/rfc4880#section-5.2.1
[3] http://localhost:8080/packages/index.tar.gz
[4] https://git.gitorious.org/hackage-server/hackage-server.git
[5] http://localhost:8080/users/register-request
[6] https://git.gitorious.org/cabal/cabal.git
-------------- 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/20140730/0fdb4b34/attachment.sig>

From the.dead.shall.rise at gmail.com  Tue Jul 29 22:42:27 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Wed, 30 Jul 2014 00:42:27 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
In-Reply-To: <CAK-tuPYjeqpjJB2mW=DZwnjQXG-JxvpcgsWOMjZXxGtU+KqqwQ@mail.gmail.com>
References: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
 <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>
 <CA+tcxkAtZ=Tn6809PXq986c=TDFFP_J9foBctbdrfehf3jfoCw@mail.gmail.com>
 <CAK-tuPYjeqpjJB2mW=DZwnjQXG-JxvpcgsWOMjZXxGtU+KqqwQ@mail.gmail.com>
Message-ID: <CA+tcxkCmTwRGS-WKsC84WzkFPF22vaH3RrH+=_E-oHjmBiXcnw@mail.gmail.com>

Hi,


On 29 July 2014 09:44, Johan Tibell <johan.tibell at gmail.com> wrote:
>
> Uploaded, thanks!

I've also built the (32-bit) Linux binary.
?
 cabal-1.20.0.3-i386-unknown-linux.tar.gz
<https://docs.google.com/file/d/0B-gmfQNqT8Hta3ExNzlUWnVqM3M/edit?usp=drive_web>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140730/e1742e74/attachment.html>

From johan.tibell at gmail.com  Wed Jul 30 07:17:37 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 30 Jul 2014 09:17:37 +0200
Subject: Fw: cabal-install-latest is not pointing to latest release
In-Reply-To: <CA+tcxkCmTwRGS-WKsC84WzkFPF22vaH3RrH+=_E-oHjmBiXcnw@mail.gmail.com>
References: <etPan.53d024f2.1befd79f.313a@haswellpro.lan>
 <CAK-tuPYwTdgKAmbQ9-m_Jg0VykCkJwjXzqYnUSXmdCPF4FShoA@mail.gmail.com>
 <CA+tcxkAtZ=Tn6809PXq986c=TDFFP_J9foBctbdrfehf3jfoCw@mail.gmail.com>
 <CAK-tuPYjeqpjJB2mW=DZwnjQXG-JxvpcgsWOMjZXxGtU+KqqwQ@mail.gmail.com>
 <CA+tcxkCmTwRGS-WKsC84WzkFPF22vaH3RrH+=_E-oHjmBiXcnw@mail.gmail.com>
Message-ID: <CAK-tuPZdEWxvvxdG5XC6h_ibT7bW7GyhTv_B79h6X-wv3oaxmQ@mail.gmail.com>

Uploaded thanks!


On Wed, Jul 30, 2014 at 12:42 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi,
>
>
> On 29 July 2014 09:44, Johan Tibell <johan.tibell at gmail.com> wrote:
> >
> > Uploaded, thanks!
>
> I've also built the (32-bit) Linux binary.
> ?
>  cabal-1.20.0.3-i386-unknown-linux.tar.gz
> <https://docs.google.com/file/d/0B-gmfQNqT8Hta3ExNzlUWnVqM3M/edit?usp=drive_web>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140730/4b337a16/attachment.html>