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: (Jake Wheat's message of "Tue, 30 Dec 2014 22:23:19 +0200") References: 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: <87zja2g1zv.fsf@gnu.org> Message-ID: 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 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: 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: References: Message-ID: 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" 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: 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: References: <87zja2g1zv.fsf@gnu.org> Message-ID: I have a pull request here for review: https://github.com/haskell/cabal/pull/2312 On 1 January 2015 at 18:43, Johan Tibell 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 > 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: Hi, On 3 January 2015 at 03:36, Johan Tibell 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: References: Message-ID: 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 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: 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: References: Message-ID: On 3 January 2015 at 15:05, Johan Tibell 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: 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: References: Message-ID: 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 wrote: > > On 3 January 2015 at 15:05, Johan Tibell 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: 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: References: Message-ID: I'm pretty sure we just need to update the submodule. On Sat, Jan 3, 2015 at 5:20 PM, Alan & Kim Zimmerman 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 > 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 >> wrote: >> >>> >>> On 3 January 2015 at 15:05, Johan Tibell 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: 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: 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: 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: 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: 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: References: Message-ID: Hi, On 5 January 2015 at 00:26, Johan Tibell 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: ??Hi, On 5 January 2015 at 00:26, Johan Tibell 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: 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: References: 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: References: Message-ID: 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 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 > > ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <20150105152731.GA26573@machine> Message-ID: 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: 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: References: Message-ID: <874mrz26df.fsf@gmail.com> Johan Tibell 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: 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: References: Message-ID: Hi, On 5 January 2015 at 16:48, Johan Tibell 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: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: On 11 January 2015 at 14:35, Johan Tibell 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: 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: References: Message-ID: On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat 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: 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: References: Message-ID: I've made an application for OS X builds for cabal. On Sun, Jan 11, 2015 at 8:39 PM, Brandon Allbery wrote: > On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat > 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: 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: References: Message-ID: 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 wrote: > I've made an application for OS X builds for cabal. > > On Sun, Jan 11, 2015 at 8:39 PM, Brandon Allbery > wrote: > >> On Sun, Jan 11, 2015 at 1:10 PM, Jake Wheat >> 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: 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: 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: 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: References: 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: References: Message-ID: Sorry Carl I missed your reply... On 3 January 2015 at 02:03, Carl Eyeinsky 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: 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: References: 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