From hvr at gnu.org  Thu Jan  1 11:43:32 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 01 Jan 2015 12:43:32 +0100
Subject: The bootstrap.sh script has to go
In-Reply-To: <CAGQv8D5Y5-BwaTiK=TSEnJdJGOSFnjFoeM7k2q7+50nZ7F9tdQ@mail.gmail.com>
 (Jake Wheat's message of "Tue, 30 Dec 2014 22:23:19 +0200")
References: <CAK-tuPZE_3yt5owVbaw8pnC34cFzKNNUHLVmOK7z-2wiuJrYkg@mail.gmail.com>
 <CAGQv8D5Y5-BwaTiK=TSEnJdJGOSFnjFoeM7k2q7+50nZ7F9tdQ@mail.gmail.com>
Message-ID: <87zja2g1zv.fsf@gnu.org>

On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote:

[...]

> Simplify the bootstrap.sh process:
>
> * always use a fixed set of versions of packages for the dependencies

For me, the primary use-case of `bootstrap.sh` is to be able to build a
matching `cabal-install` executable for a given major GHC version w/o
requiring having an existing cabal-install executable compatible w/ the
GHC version I'm trying to bootstrap cabal-install with.  (If I had an
older `cabal-install` executable, I would use that to bootstrap the new
one)

So, if a given cabal-install's bootstrap.sh would only support
bootstrapping via its associated GHC major version
(e.g. cabal-install-1.22.x would require GHC 7.10.x) then I guess the
bootstrap.sh wouldn't need to perform any significant package version
resolving, and could just use such a single fixed set of versions (and
preferably in a sandbox to ignore any user pkg-db) as you seem to
propose.


Alternatively, GHC could start bundling cabal-install, which would IMHO
eliminate the need for a bootstrap.sh in the first place (but we had
that discussion already, and it would also require to pull
cabal-install's dependencies into the GHC distribution, while OTOH GHC
is trying to avoid acquiring additional build dependencies...)

Cheers,
  hvr

From johan.tibell at gmail.com  Thu Jan  1 16:43:44 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 1 Jan 2015 11:43:44 -0500
Subject: The bootstrap.sh script has to go
In-Reply-To: <87zja2g1zv.fsf@gnu.org>
References: <CAK-tuPZE_3yt5owVbaw8pnC34cFzKNNUHLVmOK7z-2wiuJrYkg@mail.gmail.com>
 <CAGQv8D5Y5-BwaTiK=TSEnJdJGOSFnjFoeM7k2q7+50nZ7F9tdQ@mail.gmail.com>
 <87zja2g1zv.fsf@gnu.org>
Message-ID: <CAK-tuPari34rB-2Geqvs139Q_smLWw++LhqpUEHi=opGZ1D+Vw@mail.gmail.com>

See https://github.com/haskell/cabal/issues/2310 for a continuation of the
sad bootstrap.sh saga.

On Thu, Jan 1, 2015 at 6:43 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote:
>
> [...]
>
> > Simplify the bootstrap.sh process:
> >
> > * always use a fixed set of versions of packages for the dependencies
>
> For me, the primary use-case of `bootstrap.sh` is to be able to build a
> matching `cabal-install` executable for a given major GHC version w/o
> requiring having an existing cabal-install executable compatible w/ the
> GHC version I'm trying to bootstrap cabal-install with.  (If I had an
> older `cabal-install` executable, I would use that to bootstrap the new
> one)
>
> So, if a given cabal-install's bootstrap.sh would only support
> bootstrapping via its associated GHC major version
> (e.g. cabal-install-1.22.x would require GHC 7.10.x) then I guess the
> bootstrap.sh wouldn't need to perform any significant package version
> resolving, and could just use such a single fixed set of versions (and
> preferably in a sandbox to ignore any user pkg-db) as you seem to
> propose.
>
>
> Alternatively, GHC could start bundling cabal-install, which would IMHO
> eliminate the need for a bootstrap.sh in the first place (but we had
> that discussion already, and it would also require to pull
> cabal-install's dependencies into the GHC distribution, while OTOH GHC
> is trying to avoid acquiring additional build dependencies...)
>
> Cheers,
>   hvr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150101/1afe552e/attachment.html>

From eyeinsky9 at gmail.com  Fri Jan  2 17:03:14 2015
From: eyeinsky9 at gmail.com (Carl Eyeinsky)
Date: Fri, 2 Jan 2015 19:03:14 +0200
Subject: making cabal-install into a library?
In-Reply-To: <CAEDGBqJ7SmniPVwMPVB82AAxAUuAfrgAVB_FnAjkrXfga31QuA@mail.gmail.com>
References: <CAEDGBqJ7SmniPVwMPVB82AAxAUuAfrgAVB_FnAjkrXfga31QuA@mail.gmail.com>
Message-ID: <CADkv3aG-FyeqVq28MaRxr3kdxP9JPNduzXENDt8V7da7vFOZDg@mail.gmail.com>

Hi Jens,

Can you explain what you mean, or how would you use it?

E.g do you mean having the cabal commands as functions, into which you can
pass a directory structure (with file contents included) as data types?
On Dec 25, 2014 4:54 AM, "Jens Petersen" <juhpetersen at gmail.com> wrote:

> Hi,
>
> For a while I have been thinking cabal-install should really be a library.
> Has anyone considered or thought about this?
> I am wondering how much work it may be?
>
> Best wishes,
>
> Jens
>
> _______________________________________________
> 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/20150102/46788c8c/attachment.html>

From jakewheatmail at gmail.com  Fri Jan  2 21:48:33 2015
From: jakewheatmail at gmail.com (Jake Wheat)
Date: Fri, 2 Jan 2015 23:48:33 +0200
Subject: The bootstrap.sh script has to go
In-Reply-To: <CAK-tuPari34rB-2Geqvs139Q_smLWw++LhqpUEHi=opGZ1D+Vw@mail.gmail.com>
References: <CAK-tuPZE_3yt5owVbaw8pnC34cFzKNNUHLVmOK7z-2wiuJrYkg@mail.gmail.com>
 <CAGQv8D5Y5-BwaTiK=TSEnJdJGOSFnjFoeM7k2q7+50nZ7F9tdQ@mail.gmail.com>
 <87zja2g1zv.fsf@gnu.org>
 <CAK-tuPari34rB-2Geqvs139Q_smLWw++LhqpUEHi=opGZ1D+Vw@mail.gmail.com>
Message-ID: <CAGQv8D5m5xzKX2cvfaqeUhyV4KfBk8uh75qBUVVxkvEAGbGRxA@mail.gmail.com>

I have a pull request here for review:
https://github.com/haskell/cabal/pull/2312

On 1 January 2015 at 18:43, Johan Tibell <johan.tibell at gmail.com> wrote:

> See https://github.com/haskell/cabal/issues/2310 for a continuation of
> the sad bootstrap.sh saga.
>
> On Thu, Jan 1, 2015 at 6:43 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote:
>>
>> [...]
>>
>> > Simplify the bootstrap.sh process:
>> >
>> > * always use a fixed set of versions of packages for the dependencies
>>
>> For me, the primary use-case of `bootstrap.sh` is to be able to build a
>> matching `cabal-install` executable for a given major GHC version w/o
>> requiring having an existing cabal-install executable compatible w/ the
>> GHC version I'm trying to bootstrap cabal-install with.  (If I had an
>> older `cabal-install` executable, I would use that to bootstrap the new
>> one)
>>
>> So, if a given cabal-install's bootstrap.sh would only support
>> bootstrapping via its associated GHC major version
>> (e.g. cabal-install-1.22.x would require GHC 7.10.x) then I guess the
>> bootstrap.sh wouldn't need to perform any significant package version
>> resolving, and could just use such a single fixed set of versions (and
>> preferably in a sandbox to ignore any user pkg-db) as you seem to
>> propose.
>>
>>
>> Alternatively, GHC could start bundling cabal-install, which would IMHO
>> eliminate the need for a bootstrap.sh in the first place (but we had
>> that discussion already, and it would also require to pull
>> cabal-install's dependencies into the GHC distribution, while OTOH GHC
>> is trying to avoid acquiring additional build dependencies...)
>>
>> Cheers,
>>   hvr
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150102/deb65185/attachment.html>

From johan.tibell at gmail.com  Sat Jan  3 02:36:21 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 2 Jan 2015 21:36:21 -0500
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
Message-ID: <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>

If I don't hear anything the next few days I will make the release.

On Tue, Dec 30, 2014 at 2:35 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Hi all,
>
> I've now prepared release candidate for Cabal/cabal-install 1.22. Please
> test them and report bugs here and/or on the bug tracker (
> https://github.com/haskell/cabal/issues). To install:
>
>     cabal install http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz
> http://johantibell.com/files/cabal-install-1.22.0.0-rc.tar.gz
>
> Cabal is now such a big project that's used in so many context (e.g.
> different OSes) that we need your help to help us test, to make sure that
> new releases work for you.
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150102/337389f4/attachment.html>

From the.dead.shall.rise at gmail.com  Sat Jan  3 07:36:48 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 3 Jan 2015 08:36:48 +0100
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
 <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
Message-ID: <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>

Hi,

On 3 January 2015 at 03:36, Johan Tibell <johan.tibell at gmail.com> wrote:
> If I don't hear anything the next few days I will make the release.

The test suite doesn't compile with GHC HEAD on Travis.

From johan.tibell at gmail.com  Sat Jan  3 13:05:48 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 3 Jan 2015 08:05:48 -0500
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
 <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
 <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>
Message-ID: <CAK-tuPZb4OoUc3HzrqzyNV99-mJSnUYUJqmdQR_i8XxGxZaLdw@mail.gmail.com>

On Sat, Jan 3, 2015 at 2:36 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi,
>
> On 3 January 2015 at 03:36, Johan Tibell <johan.tibell at gmail.com> wrote:
> > If I don't hear anything the next few days I will make the release.
>
> The test suite doesn't compile with GHC HEAD on Travis.
>

The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
perplexing:

[62 of 77] Compiling Distribution.Client.Config (
Distribution/Client/Config.hs,
dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
)
Distribution/Client/Config.hs:56:12:
    Module
    ?Distribution.Simple.Compiler?
    does not export
    ?DebugInfoLevel(..)?
cabal: Error: some packages failed to install:
cabal-install-1.22.0.0 failed during the building phase. The exception was:
ExitFailure 1

Distribution.Simple.Compiler most definitely does export DebugInfoLevel,
otherwise it wouldn't compile with the other GHC versions.

Does GHC do something special with Cabal nowadays when it's no longer tied
to GHC?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150103/ee8895d9/attachment.html>

From jakewheatmail at gmail.com  Sat Jan  3 13:46:01 2015
From: jakewheatmail at gmail.com (Jake Wheat)
Date: Sat, 3 Jan 2015 15:46:01 +0200
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CAK-tuPZb4OoUc3HzrqzyNV99-mJSnUYUJqmdQR_i8XxGxZaLdw@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
 <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
 <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>
 <CAK-tuPZb4OoUc3HzrqzyNV99-mJSnUYUJqmdQR_i8XxGxZaLdw@mail.gmail.com>
Message-ID: <CAGQv8D5ffiYxA_yx1=_CrXJgVWL0HfDXwC639a8Fk=BkBk=Bhg@mail.gmail.com>

On 3 January 2015 at 15:05, Johan Tibell <johan.tibell at gmail.com> wrote:

> The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
> perplexing:
>
> [62 of 77] Compiling Distribution.Client.Config (
> Distribution/Client/Config.hs,
> dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
> )
> Distribution/Client/Config.hs:56:12:
>     Module
>     ?Distribution.Simple.Compiler?
>     does not export
>     ?DebugInfoLevel(..)?
> cabal: Error: some packages failed to install:
> cabal-install-1.22.0.0 failed during the building phase. The exception was:
> ExitFailure 1
>
> Distribution.Simple.Compiler most definitely does export DebugInfoLevel,
> otherwise it wouldn't compile with the other GHC versions.
>
> Does GHC do something special with Cabal nowadays when it's no longer tied
> to GHC?
>
> Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the
Cabal-1.22.0.0 in github? I get the same error compiling the master branch
cabal-install with ghc-7.10.0-20141222.

I think one solution is to increase the version number of Cabal in github
(for 1.22 and master branches), and to make the latest cabal-install depend
on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no longer
works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the
error for ghc-7.10.0-20141222.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150103/0c597d57/attachment.html>

From johan.tibell at gmail.com  Sat Jan  3 20:17:02 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 3 Jan 2015 15:17:02 -0500
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CAGQv8D5ffiYxA_yx1=_CrXJgVWL0HfDXwC639a8Fk=BkBk=Bhg@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
 <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
 <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>
 <CAK-tuPZb4OoUc3HzrqzyNV99-mJSnUYUJqmdQR_i8XxGxZaLdw@mail.gmail.com>
 <CAGQv8D5ffiYxA_yx1=_CrXJgVWL0HfDXwC639a8Fk=BkBk=Bhg@mail.gmail.com>
Message-ID: <CAK-tuPauwObehzx_GEuxmmcCEjbidHFt6iOTAVdEC=JO+TyUXw@mail.gmail.com>

It might be as simple as bumping the Cabal submodule in GHC to match the
upstream 1.22 branch.

On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat <jakewheatmail at gmail.com> wrote:

>
> On 3 January 2015 at 15:05, Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
>> perplexing:
>>
>> [62 of 77] Compiling Distribution.Client.Config (
>> Distribution/Client/Config.hs,
>> dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
>> )
>> Distribution/Client/Config.hs:56:12:
>>     Module
>>     ?Distribution.Simple.Compiler?
>>     does not export
>>     ?DebugInfoLevel(..)?
>> cabal: Error: some packages failed to install:
>> cabal-install-1.22.0.0 failed during the building phase. The exception
>> was:
>> ExitFailure 1
>>
>> Distribution.Simple.Compiler most definitely does export DebugInfoLevel,
>> otherwise it wouldn't compile with the other GHC versions.
>>
>> Does GHC do something special with Cabal nowadays when it's no longer
>> tied to GHC?
>>
>> Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the
> Cabal-1.22.0.0 in github? I get the same error compiling the master branch
> cabal-install with ghc-7.10.0-20141222.
>
> I think one solution is to increase the version number of Cabal in github
> (for 1.22 and master branches), and to make the latest cabal-install depend
> on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no longer
> works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the
> error for ghc-7.10.0-20141222.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150103/6c662c24/attachment.html>

From johan.tibell at gmail.com  Sat Jan  3 22:46:46 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 3 Jan 2015 17:46:46 -0500
Subject: Cabal 1.22 RC ready to test
In-Reply-To: <CANma=H98qNcR5OXtMi68MqnwLzp+O4+1C3U=F0V18WrKX9n5LA@mail.gmail.com>
References: <CAK-tuPZFahzk4TkY3_O53_=S3CrnhbGgRZ4j5BHSG2o__YHVQA@mail.gmail.com>
 <CAK-tuPaZU8uxh_iM-mBt+KVpsg+-JDyr3gYrDcHf0YOG-RQn1w@mail.gmail.com>
 <CA+tcxkAc_v07phOn9r2jP3Hr0-dGrv4tzD73Mr3TpgDWnahunQ@mail.gmail.com>
 <CAK-tuPZb4OoUc3HzrqzyNV99-mJSnUYUJqmdQR_i8XxGxZaLdw@mail.gmail.com>
 <CAGQv8D5ffiYxA_yx1=_CrXJgVWL0HfDXwC639a8Fk=BkBk=Bhg@mail.gmail.com>
 <CAK-tuPauwObehzx_GEuxmmcCEjbidHFt6iOTAVdEC=JO+TyUXw@mail.gmail.com>
 <CANma=H98qNcR5OXtMi68MqnwLzp+O4+1C3U=F0V18WrKX9n5LA@mail.gmail.com>
Message-ID: <CAK-tuPYmgg4-0WkGrcjYZH8JYdO4GM3zrVxK_V8g=FOeJ3J2FA@mail.gmail.com>

I'm pretty sure we just need to update the submodule.

On Sat, Jan 3, 2015 at 5:20 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> I tried to build https://github.com/ghc/packages-Cabal earlier today and
> got the same error, but it went fine with the version at
> https://github.com/haskell/cabal
>
>
>
> On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> It might be as simple as bumping the Cabal submodule in GHC to match the
>> upstream 1.22 branch.
>>
>> On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat <jakewheatmail at gmail.com>
>> wrote:
>>
>>>
>>> On 3 January 2015 at 15:05, Johan Tibell <johan.tibell at gmail.com> wrote:
>>>
>>>> The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
>>>> perplexing:
>>>>
>>>> [62 of 77] Compiling Distribution.Client.Config (
>>>> Distribution/Client/Config.hs,
>>>> dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
>>>> )
>>>> Distribution/Client/Config.hs:56:12:
>>>>     Module
>>>>     ?Distribution.Simple.Compiler?
>>>>     does not export
>>>>     ?DebugInfoLevel(..)?
>>>> cabal: Error: some packages failed to install:
>>>> cabal-install-1.22.0.0 failed during the building phase. The exception
>>>> was:
>>>> ExitFailure 1
>>>>
>>>> Distribution.Simple.Compiler most definitely does export
>>>> DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions.
>>>>
>>>> Does GHC do something special with Cabal nowadays when it's no longer
>>>> tied to GHC?
>>>>
>>>> Is it because the Cabal-1.22.0.0 bundled with ghc is now different to
>>> the Cabal-1.22.0.0 in github? I get the same error compiling the master
>>> branch cabal-install with ghc-7.10.0-20141222.
>>>
>>> I think one solution is to increase the version number of Cabal in
>>> github (for 1.22 and master branches), and to make the latest cabal-install
>>> depend on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no
>>> longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes
>>> the error for ghc-7.10.0-20141222.
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150103/da2bf0f6/attachment.html>

From johan.tibell at gmail.com  Sun Jan  4 23:24:44 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 4 Jan 2015 18:24:44 -0500
Subject: ANN: Cabal 1.22 and cabal-install 1.22
Message-ID: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>

On behalf of the cabal developers, I'm happy to announce the Cabal 1.22
release!

To install:

    cabal update && cabal install Cabal-1.22.0.0 cabal-install-1.22.0.0

Please report bugs at https://github.com/haskell/cabal/issues. Pre-built
binaries should be available with a week or so.

Non-exhaustive list of changes:

 * Support GHC 7.10.
 * Experimental DWARF debug info output on GHC 7.10 (--enable-debug-info).
 * Preliminary support for relocatable packages.
 * Cabal can now be used inside a cabal exec environment.
 * Fix solver bug where the user's manual flag choice was ignored.
 * Add GHCJS support.
 * Improved command line documentation.
 * Build C sources with -fPIC when GHC is using dynamic libraries.
 * Preliminary support for package keys (a step on the way to NixOS-like
packages).
 * Add a 'user-config' command to help users manage ~/.cabal/config.
 * HPC support improved.

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

   181 Mikhail Glushenkov
    48 Johan Tibell
    35 Edward Z. Yang
    34 Christiaan Baaij
    32 Thomas Tuegel
    24 Ben Armston
    19 Ian D. Bollinger
    17 Lennart Spitzner
    12 Luite Stegeman
    11 Herbert Valerio Riedel
    10 Duncan Coutts
     9 Erik de Castro Lopo
     8 Andres Loeh
     5 Chris Wong
     5 Iain Nicol
     5 Heather
     5 Jake Wheat
     4 Daniel Trstenjak
     4 Tuncer Ayaz
     4 Neil Vice
     4 Rudy Matela
     2 David Feuer
     2 Bertram Felgenhauer
     2 Fujimura Daisuke
     2 Iustin Pop
     2 John Chee
     2 Keshav Kini
     2 Maxwell Swadling
     2 Michael Snoyman
     2 Owen Stephens
     2 Sergey Vinokurov
     2 Thomas Miedema
     2 Vincent Hanquez
     2 jake
     1 Brent Yorgey
     1 Maximilian Tagher
     1 Anton Dessiatov
     1 phischu
     1 Bob Ippolito
     1 Mi?tek Bak
     1 Bardur Arantsson
     1 Nikita Karetnikov
     1 tchakkazulu
     1 Peter Tr?ko
     1 Austin Seipp
     1 Ryan Mulligan
     1 RyanGlScott
     1 Samuel G?lineau
     1 Sergei Trofimovich
     1 jpmoresmau
     1 Simon Hengel
     1 Thomas M. DuBuisson
     1 Harry Garrood
     1 Isamu Mogi
     1 kosmikus
     1 David Fox
     1 Curtis Gagliardi
     1 Antonio Nikishaev
     1 Karel Gardas
     1 Travis Cardwell
     1 Chris Allen
     1 Matthew William Cox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150104/03b9ae2a/attachment.html>

From johan.tibell at gmail.com  Sun Jan  4 23:26:59 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 4 Jan 2015 18:26:59 -0500
Subject: Call for 1.22 binaries
Message-ID: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>

Hi,

As per usual I need help building binaries (to put on haskell.org) for the
release. In particular I need binaries for Windows and Linux. Please
include the architecture in the binary name and any other restrictions for
how it can be used.

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

From the.dead.shall.rise at gmail.com  Mon Jan  5 07:31:01 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 5 Jan 2015 08:31:01 +0100
Subject: Call for 1.22 binaries
In-Reply-To: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
References: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
Message-ID: <CA+tcxkDorb4S=YCKfRGh10B=Qt6mSMQqwYuSPo+NXPsBk3_sTw@mail.gmail.com>

Hi,

On 5 January 2015 at 00:26, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi,
>
> As per usual I need help building binaries (to put on haskell.org) for the
> release. In particular I need binaries for Windows and Linux.

Attaching the Linux binary.?

 cabal-1.22.0.0-i386-unknown-linux.tar.gz
<https://docs.google.com/file/d/0B-gmfQNqT8HtUG94RnJkbER5bDQ/edit?usp=drive_web>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150105/b6422b04/attachment.html>

From the.dead.shall.rise at gmail.com  Mon Jan  5 13:28:29 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 5 Jan 2015 14:28:29 +0100
Subject: Call for 1.22 binaries
In-Reply-To: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
References: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
Message-ID: <CA+tcxkB9Sx6_Patxv0ZnzFEVA+v0TA2c36W8fhrivdL87P3eFg@mail.gmail.com>

??Hi,

On 5 January 2015 at 00:26, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi,
>
> As per usual I need help building binaries (to put on haskell.org) for the
> release. In particular I need binaries for Windows and Linux.

And here's the Windows binary.

?
 cabal-1.22.0.0-i386-unknown-mingw32.exe
<https://docs.google.com/file/d/0B-gmfQNqT8HtV1N4X09sLUhNWlE/edit?usp=drive_web>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150105/0757c1bb/attachment.html>

From simon at joyful.com  Mon Jan  5 14:09:06 2015
From: simon at joyful.com (Simon Michael)
Date: Mon, 05 Jan 2015 06:09:06 -0800
Subject: ANN: Cabal 1.22 and cabal-install 1.22
In-Reply-To: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>
References: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>
Message-ID: <m8e5u0$iu7$1@ger.gmane.org>

On 1/4/15 3:24 PM, Johan Tibell wrote:
> On behalf of the cabal developers, I'm happy to announce the Cabal 1.22
> release!

Hurrah, thank you all very much!


From daniel.trstenjak at gmail.com  Mon Jan  5 15:27:31 2015
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 5 Jan 2015 16:27:31 +0100
Subject: ANN: Cabal 1.22 and cabal-install 1.22
In-Reply-To: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>
References: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>
Message-ID: <20150105152731.GA26573@machine>


Hi,

sorry that I couldn't test Cabal 1.22 earlier, but there seems to be a
change regarding the handling and pretty printing of the 'GenericPackageDescription' in Cabal 1.22.

Now parsing a cabal file with 'parsePackageDescription' and pretty
printing it with 'showGenericPackageDescription' will result into
a cabal file where every section contains the 'build-depends' field twice.

Previously the dependencies have been resolved into 'CondNode.condTreeConstraints'
and the field 'BuildInfo.targetBuildDepends' has been emptied.

Now it seems that both - 'CondNode.condTreeConstraints' and 'BuildInfo.targetBuildDepends' -
contain the dependencies and therefore they're output twice.


The resolving into 'CondNode.condTreeConstraints' always seemed a bit
like a hack to me, because there's already the distiction between 'GenericPackageDescription'
and 'PackageDescription', and 'PackageDescription' already represeting the resolved state,
so I'm wondering if it wouldn't be best to let 'CondNode.condTreeConstraints' just go,
or as a first step, not using it anymore.


Greetings,
Daniel

From johan.tibell at gmail.com  Mon Jan  5 15:48:26 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Jan 2015 10:48:26 -0500
Subject: Call for 1.22 binaries
In-Reply-To: <CA+tcxkB9Sx6_Patxv0ZnzFEVA+v0TA2c36W8fhrivdL87P3eFg@mail.gmail.com>
References: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
 <CA+tcxkB9Sx6_Patxv0ZnzFEVA+v0TA2c36W8fhrivdL87P3eFg@mail.gmail.com>
Message-ID: <CAK-tuPYeSy1x=GosC7sL=2YMyL=iZafcakma5FXTF4rR=snmzA@mail.gmail.com>

Linux, Windows, and OS X binaries uploaded.

On Mon, Jan 5, 2015 at 8:28 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> ??Hi,
>
> On 5 January 2015 at 00:26, Johan Tibell <johan.tibell at gmail.com> wrote:
> > Hi,
> >
> > As per usual I need help building binaries (to put on haskell.org) for
> the
> > release. In particular I need binaries for Windows and Linux.
>
> And here's the Windows binary.
>
> ?
>  cabal-1.22.0.0-i386-unknown-mingw32.exe
> <https://docs.google.com/file/d/0B-gmfQNqT8HtV1N4X09sLUhNWlE/edit?usp=drive_web>
> ?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150105/c2373c40/attachment.html>

From johan.tibell at gmail.com  Mon Jan  5 15:52:07 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Jan 2015 10:52:07 -0500
Subject: ANN: Cabal 1.22 and cabal-install 1.22
In-Reply-To: <20150105152731.GA26573@machine>
References: <CAK-tuPZSp65OmTCkxVF=Pu3VNi+S98MO+oS6=fn8858xQ3auUQ@mail.gmail.com>
 <20150105152731.GA26573@machine>
Message-ID: <CAK-tuPZtM49CaGb5RP9XCbVwOtwe6C_HXODqAEqmyoq-3n4t1Q@mail.gmail.com>

Daniel,

Can you please file a bug at https://github.com/haskell/cabal/issues so we
can track this?

On Mon, Jan 5, 2015 at 10:27 AM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

>
> Hi,
>
> sorry that I couldn't test Cabal 1.22 earlier, but there seems to be a
> change regarding the handling and pretty printing of the
> 'GenericPackageDescription' in Cabal 1.22.
>
> Now parsing a cabal file with 'parsePackageDescription' and pretty
> printing it with 'showGenericPackageDescription' will result into
> a cabal file where every section contains the 'build-depends' field twice.
>
> Previously the dependencies have been resolved into
> 'CondNode.condTreeConstraints'
> and the field 'BuildInfo.targetBuildDepends' has been emptied.
>
> Now it seems that both - 'CondNode.condTreeConstraints' and
> 'BuildInfo.targetBuildDepends' -
> contain the dependencies and therefore they're output twice.
>
>
> The resolving into 'CondNode.condTreeConstraints' always seemed a bit
> like a hack to me, because there's already the distiction between
> 'GenericPackageDescription'
> and 'PackageDescription', and 'PackageDescription' already represeting the
> resolved state,
> so I'm wondering if it wouldn't be best to let
> 'CondNode.condTreeConstraints' just go,
> or as a first step, not using it anymore.
>
>
> 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/20150105/8ab9c435/attachment.html>

From ben at smart-cactus.org  Fri Jan  9 17:47:40 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 09 Jan 2015 12:47:40 -0500
Subject: Call for 1.22 binaries
In-Reply-To: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
References: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
Message-ID: <874mrz26df.fsf@gmail.com>

Johan Tibell <johan.tibell at gmail.com> writes:

> Hi,
>
> As per usual I need help building binaries (to put on haskell.org) for the
> release. In particular I need binaries for Windows and Linux. Please
> include the architecture in the binary name and any other restrictions for
> how it can be used.
>
I would be happy to provide an armhf binary for Debian Jessie. How does
one produce these tarballs?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150109/d2ecf408/attachment.sig>

From the.dead.shall.rise at gmail.com  Fri Jan  9 17:57:55 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Fri, 9 Jan 2015 18:57:55 +0100
Subject: Call for 1.22 binaries
In-Reply-To: <CAK-tuPYeSy1x=GosC7sL=2YMyL=iZafcakma5FXTF4rR=snmzA@mail.gmail.com>
References: <CAK-tuPaGcSx6y+1PZqVu9pUdyosQMPBUXA3B3QhxYLE6Ez0RRw@mail.gmail.com>
 <CA+tcxkB9Sx6_Patxv0ZnzFEVA+v0TA2c36W8fhrivdL87P3eFg@mail.gmail.com>
 <CAK-tuPYeSy1x=GosC7sL=2YMyL=iZafcakma5FXTF4rR=snmzA@mail.gmail.com>
Message-ID: <CA+tcxkC4+YkasiUd8UB59LELU3JDrq55UKhXQX0s8wMA2emfLA@mail.gmail.com>

Hi,

On 5 January 2015 at 16:48, Johan Tibell <johan.tibell at gmail.com> wrote:
>
> Linux, Windows, and OS X binaries uploaded.

BTW, if we're going to compress the Windows binary, it's better to use
.zip since Windows doesn't support .tar.gz by default.

From jakewheatmail at gmail.com  Sat Jan 10 11:52:06 2015
From: jakewheatmail at gmail.com (Jake Wheat)
Date: Sat, 10 Jan 2015 13:52:06 +0200
Subject: Bootstrap.hs
Message-ID: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>

I have an draft rewrite of bootstrap.sh in haskell. I've tried to improve
the maintainability of the code and reliability of running the bootstrap.

https://github.com/JakeWheat/cabal/blob/bootstrap-hs/cabal-install/Bootstrap.hs

Any feedback is appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150110/f697c1e4/attachment.html>

From johan.tibell at gmail.com  Sun Jan 11 12:35:35 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 11 Jan 2015 13:35:35 +0100
Subject: Bootstrap.hs
In-Reply-To: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
References: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
Message-ID: <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>

Overall I like this approach. One problem the old script suffered from was
that its goals and, in particular, non-goals weren't clearly stated. Lets
state the goal clearly:

  Goal: Be able to bootstrap a cabal-install binary of a bare GHC install
from https://www.haskell.org/ghc/download
  Non-goal: Be able to bootstrap using a modified global package DB or
using a user DB in an arbitrary state.

The latter is a non-goal because doing that well requires a constraint
solver. We've tried to to emulate that using regexes in the past and that
has become more and more untenable. The goal is met by the new Bootstrap.hs
by nailing down the exact version numbers to use.

Questions about Bootstrap.sh:

 * Can we make it work in-tree? I tried it on master now and that didn't
work (because it tried to install Cabal-1.23 from Hackage, which doesn't
exist.) This is needed to we can run it on Travis to test it.
 * We need to make sure it works on supported platforms: Linux, OS X, and
Windows. This is mostly about testing.
 * How can I test it in the current state? As mentioned above,
bootstrapping in the master branch didn't work.
 * We should output a message once the install is done to tell the user how
to use the bootstrapped binary. In particular, we might want to tell the
user to use it to reinstall cabal-install not in a sandbox.


On Sat, Jan 10, 2015 at 12:52 PM, Jake Wheat <jakewheatmail at gmail.com>
wrote:

> I have an draft rewrite of bootstrap.sh in haskell. I've tried to improve
> the maintainability of the code and reliability of running the bootstrap.
>
>
> https://github.com/JakeWheat/cabal/blob/bootstrap-hs/cabal-install/Bootstrap.hs
>
> Any feedback is appreciated!
>
> _______________________________________________
> 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/20150111/4c88494d/attachment.html>

From jakewheatmail at gmail.com  Sun Jan 11 18:10:48 2015
From: jakewheatmail at gmail.com (Jake Wheat)
Date: Sun, 11 Jan 2015 20:10:48 +0200
Subject: Bootstrap.hs
In-Reply-To: <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>
References: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
 <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>
Message-ID: <CAGQv8D6QofikcaKHqpA=quNapKMFpgNoM5tQJ=4L210-bsoLEw@mail.gmail.com>

On 11 January 2015 at 14:35, Johan Tibell <johan.tibell at gmail.com> wrote:

> Overall I like this approach. One problem the old script suffered from was
> that its goals and, in particular, non-goals weren't clearly stated. Lets
> state the goal clearly:
>
>   Goal: Be able to bootstrap a cabal-install binary of a bare GHC install
> from https://www.haskell.org/ghc/download
>   Non-goal: Be able to bootstrap using a modified global package DB or
> using a user DB in an arbitrary state.
>

I would like to add a goal:
Boostrap on a modified GHC install, as long as the global packages which
come with GHC are not modified. It will ignore any packages added to
global, or added to the user package database. I think this is useful for
testing and for more convenient recovery if you delete cabal-install. (It
already does this.)

I think it would be a good idea if the platforms it is expected to work on
nailed down a bit more clearly as part of the goals also - not sure what to
do about Linux, but we can say which versions of Windows and OSX it is
tested on.


>
> The latter is a non-goal because doing that well requires a constraint
> solver. We've tried to to emulate that using regexes in the past and that
> has become more and more untenable. The goal is met by the new Bootstrap.hs
> by nailing down the exact version numbers to use.
>
> Questions about Bootstrap.sh:
>
>  * Can we make it work in-tree? I tried it on master now and that didn't
> work (because it tried to install Cabal-1.23 from Hackage, which doesn't
> exist.) This is needed to we can run it on Travis to test it.
>

This is on my todo for this to work automatically. I think it will be
pretty easy.


>  * We need to make sure it works on supported platforms: Linux, OS X, and
> Windows. This is mostly about testing.
>

Can travis test on all these systems? What about e.g. Solaris or FreeBSD,
which have had binary releases of GHC in the past?


>
 * How can I test it in the current state? As mentioned above,
> bootstrapping in the master branch didn't work.
>

The current work-around needs a working cabal-install, run 'cabal sdist' in
the Cabal/ dir, then copy the .tar.gz to cabal-install/ and the
Bootstrap.hs will pick it up.


>  * We should output a message once the install is done to tell the user
> how to use the bootstrapped binary.
>

There is a small message, it can be changed/added easily.


> In particular, we might want to tell the user to use it to reinstall
> cabal-install not in a sandbox.
>

Is there any reason to do this? Won't the bootstrapped cabal install binary
work fine for most users? Alternatively, it could rerun cabal-install
automatically or optionally as part of the bootstrap, or it could copy the
bootstrap binary to ~/.cabal/bin/ or something if this is desired.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150111/408064f6/attachment.html>

From allbery.b at gmail.com  Sun Jan 11 19:39:02 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 11 Jan 2015 14:39:02 -0500
Subject: Bootstrap.hs
In-Reply-To: <CAGQv8D6QofikcaKHqpA=quNapKMFpgNoM5tQJ=4L210-bsoLEw@mail.gmail.com>
References: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
 <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>
 <CAGQv8D6QofikcaKHqpA=quNapKMFpgNoM5tQJ=4L210-bsoLEw@mail.gmail.com>
Message-ID: <CAKFCL4V=9UzaPNuq-3Y7bEQ5e11udrNwWaod2t=Q5=qFow0q=g@mail.gmail.com>

On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat <jakewheatmail at gmail.com> wrote:

> Can travis test on all these systems? What about e.g. Solaris or FreeBSD,
> which have had binary releases of GHC in the past?
>

Travis cannot test on Windows and has only a limited number of OS X
builders (last I checked, a couple weeks ago, they were not accepting new
applications for OS X builds).

-- 
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/20150111/87fa0393/attachment.html>

From johan.tibell at gmail.com  Sun Jan 11 19:51:35 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 11 Jan 2015 20:51:35 +0100
Subject: Bootstrap.hs
In-Reply-To: <CAKFCL4V=9UzaPNuq-3Y7bEQ5e11udrNwWaod2t=Q5=qFow0q=g@mail.gmail.com>
References: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
 <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>
 <CAGQv8D6QofikcaKHqpA=quNapKMFpgNoM5tQJ=4L210-bsoLEw@mail.gmail.com>
 <CAKFCL4V=9UzaPNuq-3Y7bEQ5e11udrNwWaod2t=Q5=qFow0q=g@mail.gmail.com>
Message-ID: <CAK-tuPaoqaOkNKbF5zjkx98+MHWiNcxiZFxc6dZW2BkzgX__Lg@mail.gmail.com>

I've made an application for OS X builds for cabal.

On Sun, Jan 11, 2015 at 8:39 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat <jakewheatmail at gmail.com>
> wrote:
>
>> Can travis test on all these systems? What about e.g. Solaris or FreeBSD,
>> which have had binary releases of GHC in the past?
>>
>
> Travis cannot test on Windows and has only a limited number of OS X
> builders (last I checked, a couple weeks ago, they were not accepting new
> applications for OS X builds).
>
> --
> 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/20150111/8a4ca7c6/attachment.html>

From johan.tibell at gmail.com  Mon Jan 12 01:34:33 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 12 Jan 2015 02:34:33 +0100
Subject: Bootstrap.hs
In-Reply-To: <CAK-tuPaoqaOkNKbF5zjkx98+MHWiNcxiZFxc6dZW2BkzgX__Lg@mail.gmail.com>
References: <CAGQv8D5PLHrCb8pJ5CcO9XMYDwb5i+wrLxHa9d_jjOt4CV7Vdg@mail.gmail.com>
 <CAK-tuPb6GzB2=Fyo1rUk47hbx+up=6KuCmzNEz=wryO0XmUEXw@mail.gmail.com>
 <CAGQv8D6QofikcaKHqpA=quNapKMFpgNoM5tQJ=4L210-bsoLEw@mail.gmail.com>
 <CAKFCL4V=9UzaPNuq-3Y7bEQ5e11udrNwWaod2t=Q5=qFow0q=g@mail.gmail.com>
 <CAK-tuPaoqaOkNKbF5zjkx98+MHWiNcxiZFxc6dZW2BkzgX__Lg@mail.gmail.com>
Message-ID: <CAK-tuPY3jGkgRDXZVFTrRFPq7jwi5g=6szKHVcVFpap8N-0riA@mail.gmail.com>

If you could polish this into a pull request I'd be happy to review it and
merge it when it's ready.

On Sun, Jan 11, 2015 at 8:51 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> I've made an application for OS X builds for cabal.
>
> On Sun, Jan 11, 2015 at 8:39 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat <jakewheatmail at gmail.com>
>> wrote:
>>
>>> Can travis test on all these systems? What about e.g. Solaris or
>>> FreeBSD, which have had binary releases of GHC in the past?
>>>
>>
>> Travis cannot test on Windows and has only a limited number of OS X
>> builders (last I checked, a couple weeks ago, they were not accepting new
>> applications for OS X builds).
>>
>> --
>> 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/20150112/8ed5807b/attachment-0001.html>

From juhpetersen at gmail.com  Mon Jan 19 01:54:34 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 19 Jan 2015 10:54:34 +0900
Subject: Cabal-1.22 keyed library filepaths
Message-ID: <CAEDGBq+mf=CBFsjLi67PvP5wa3vg9n6bmLicBoU+XiBrtJB_3w@mail.gmail.com>

Hi,

I see that with Cabal-1.22, library paths are now of the form:

 /usr/lib64/ghc-7.10.0.20141222/direc_3m6Ew9I164U5MIkATLCdb8/
libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so

etc.

Is the 5 character truncation of package names (and no version) necessary?
It makes it pretty hard to see at a glance what package a particular
directory or file belongs to and seems there is no easy way to work out the
package version without referring to the package.conf file/dir.

If possible I would prefer a filepath format like:

 /usr/lib64/ghc-7.10.0.20141222/directory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8/
libHSdirectory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so

Would that be feasible/make sense?

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150119/a01c7006/attachment.html>

From ezyang at mit.edu  Mon Jan 19 06:47:23 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sun, 18 Jan 2015 22:47:23 -0800
Subject: Cabal-1.22 keyed library filepaths
In-Reply-To: <CAEDGBq+mf=CBFsjLi67PvP5wa3vg9n6bmLicBoU+XiBrtJB_3w@mail.gmail.com>
References: <CAEDGBq+mf=CBFsjLi67PvP5wa3vg9n6bmLicBoU+XiBrtJB_3w@mail.gmail.com>
Message-ID: <1421649947-sup-7083@sabre>

Hey Jens,

The motivation for truncating the names and version was to keep
symbol name sizes manageable even with the addition of the hash,
while giving at least some hint when working with the symbols
directly.  It doesn't seem that this rationale applies for library
names, so it's possible we could separate these (in any case, only
the hash really matters: the package name/version are included
in the hash), but we'd have to figure out where in the current codebase
makes assumptions about this.

Edward

Excerpts from Jens Petersen's message of 2015-01-18 17:54:34 -0800:
> Hi,
> 
> I see that with Cabal-1.22, library paths are now of the form:
> 
>  /usr/lib64/ghc-7.10.0.20141222/direc_3m6Ew9I164U5MIkATLCdb8/
> libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so
> 
> etc.
> 
> Is the 5 character truncation of package names (and no version) necessary?
> It makes it pretty hard to see at a glance what package a particular
> directory or file belongs to and seems there is no easy way to work out the
> package version without referring to the package.conf file/dir.
> 
> If possible I would prefer a filepath format like:
> 
>  /usr/lib64/ghc-7.10.0.20141222/directory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8/
> libHSdirectory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so
> 
> Would that be feasible/make sense?
> 
> Jens

From juhpetersen at gmail.com  Wed Jan 21 01:12:06 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Wed, 21 Jan 2015 10:12:06 +0900
Subject: making cabal-install into a library?
In-Reply-To: <CADkv3aG-FyeqVq28MaRxr3kdxP9JPNduzXENDt8V7da7vFOZDg@mail.gmail.com>
References: <CAEDGBqJ7SmniPVwMPVB82AAxAUuAfrgAVB_FnAjkrXfga31QuA@mail.gmail.com>
 <CADkv3aG-FyeqVq28MaRxr3kdxP9JPNduzXENDt8V7da7vFOZDg@mail.gmail.com>
Message-ID: <CAEDGBqKLqd3myNeTkKdei243kokKxSObAj_2tm_ovo3utgrauA@mail.gmail.com>

Sorry Carl I missed your reply...

On 3 January 2015 at 02:03, Carl Eyeinsky <eyeinsky9 at gmail.com> wrote:


> Can you explain what you mean, or how would you use it?
>
> E.g do you mean having the cabal commands as functions, into which you can
> pass a directory structure (with file contents included) as data types?
>
Pretty much yes.

Since I believe the code is well written, my feeling is it might not be a
huge amount of work though I haven't had time to look into the details.
The hardest part might be working out the name of the library unless
cabal-install becomes a BinLib package. ;o)

I think there are quite a few packages that make use of cabal-install and
so yes better and safer to have a library then having always to call out to
a subprocess...

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150121/fb0e5cc9/attachment.html>

From daniel.trstenjak at gmail.com  Wed Jan 21 07:53:26 2015
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Wed, 21 Jan 2015 08:53:26 +0100
Subject: making cabal-install into a library?
In-Reply-To: <CAEDGBqKLqd3myNeTkKdei243kokKxSObAj_2tm_ovo3utgrauA@mail.gmail.com>
References: <CAEDGBqJ7SmniPVwMPVB82AAxAUuAfrgAVB_FnAjkrXfga31QuA@mail.gmail.com>
 <CADkv3aG-FyeqVq28MaRxr3kdxP9JPNduzXENDt8V7da7vFOZDg@mail.gmail.com>
 <CAEDGBqKLqd3myNeTkKdei243kokKxSObAj_2tm_ovo3utgrauA@mail.gmail.com>
Message-ID: <20150121075326.GA2095@machine>


Hi Jens,

> I think there are quite a few packages that make use of cabal-install and so
> yes better and safer to have a library then having always to call out to a
> subprocess...

If you're using a subprocess, then you're always using the same, the installed
cabal-install version.

With a cabal-install library, your application might use an other
version of cabal-install than the installed cabal-install binary and
this might result into issues.

Also if it seems counterintuitive, the best solution might be to have
a library that usese a subprocess ;).


Greetings,
Daniel