From michael at snoyman.com Mon May 4 06:31:08 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 04 May 2015 06:31:08 +0000 Subject: Making cabal-install SSL capable In-Reply-To: <87618gisk9.fsf@gnu.org> References: <87618gisk9.fsf@gnu.org> Message-ID: Just a little update on this. I pinged the author of publicsuffixlist (necessary for proper cookie domain handling) about removing the data-default dependency, and after discussion we decided to just merge the code into http-client instead. With that change, the full dependency list for http-client-openssl is in fact smaller that http-streams: cabal install --dry-run --package-db=clear --package-db=global http-client-openssl Resolving dependencies... In order, the following would be installed (use -v for more details): base64-bytestring-1.0.0.1 data-default-class-0.0.1 network-2.6.0.2 HsOpenSSL-0.11.1.1 random-1.1 stm-2.4.4 text-1.2.0.4 blaze-builder-0.4.0.1 cookie-0.4.1.5 hashable-1.2.3.2 case-insensitive-1.2.0.4 http-types-0.8.6 mime-types-0.1.0.6 transformers-0.4.3.0 mtl-2.2.1 parsec-3.1.9 network-uri-2.6.0.3 transformers-compat-0.4.0.4 exceptions-0.8.0.2 zlib-0.6.1.0 streaming-commons-0.1.12 http-client-0.4.11.2 http-client-openssl-0.2.0.1 On Tue, Apr 28, 2015 at 11:08 AM Herbert Valerio Riedel wrote: > On 2015-04-28 at 06:08:38 +0200, Michael Snoyman wrote: > > [...] > > > I offered Duncan last week that I'd port cabal-install over to > > http-client/http-client-tls to add SSL support. That offer still stands. > > I did a quick check trying to find out the additional dependencies > (relative to what 'cabal-install' currently depends on) http-client-tls > would pull in (it seems http-client and tls each roughly account for > half the ~50 deps below): > > async-2.0.2 > base64-bytestring-1.0.0.1 > blaze-builder-0.4.0.1 > byteable-0.1.1 > cereal-0.4.1.1 > clock-0.4.5.0 > cryptohash-0.11.6 > data-default-class-0.0.1 > data-default-instances-base-0.0.1 > data-default-instances-containers-0.0.1 > data-default-instances-old-locale-0.0.1 > dlist-0.7.1.1 > data-default-instances-dlist-0.0.1 > data-default-0.5.3 > cookie-0.4.1.4 > hashable-1.2.3.2 > case-insensitive-1.2.0.4 > hourglass-0.2.9 > asn1-types-0.3.0 > asn1-encoding-0.9.0 > asn1-parse-0.9.0 > crypto-pubkey-types-0.4.3 > http-types-0.8.6 > mime-types-0.1.0.6 > pem-0.2.2 > primitive-0.6 > securemem-0.1.7 > crypto-cipher-types-0.0.9 > cipher-aes-0.2.10 > cipher-des-0.0.6 > cipher-rc4-0.1.4 > socks-0.5.4 > streaming-commons-0.1.12 > transformers-compat-0.4.0.4 > exceptions-0.8.0.2 > utf8-string-1 > publicsuffixlist-0.1 > http-client-0.4.11.1 > vector-0.10.12.3 > crypto-random-0.0.9 > crypto-numbers-0.2.7 > crypto-pubkey-0.2.8 > x509-1.5.0.1 > x509-store-1.5.0 > x509-system-1.5.0 > x509-validation-1.5.1 > tls-1.2.17 > connection-0.2.4 > http-client-tls-0.2.2 > > In contrast, I was surprised to see, that extending the HTTP package (or > maybe just writing a 'HTTPS'-companion package) to use HsOpenSSL seems > to pull in 'HsOpenSSL' as the only additional package... > > For comparision here's what http-streams (which I'm not suggesting right > now, as I think going the 'HTTP'+'HsOpenSSL'-route would be better > currently) would pull in (which could have a few deps less if it didn't > pull in 'aeson'...): > > HsOpenSSL-0.11.1.1 > base64-bytestring-1.0.0.1 > blaze-builder-0.4.0.1 > bytestring-builder-0.10.6.0.0 > dlist-0.7.1.1 > hashable-1.2.3.2 > case-insensitive-1.2.0.4 > primitive-0.6 > scientific-0.3.3.8 > attoparsec-0.12.1.6 > syb-0.4.4 > unordered-containers-0.2.5.1 > http-common-0.8.2.0 > vector-0.10.12.3 > aeson-0.8.0.2 > zlib-bindings-0.1.1.5 > io-streams-1.3.0.0 > openssl-streams-1.2.1.0 > http-streams-0.8.3.1 > > Cheers, > hvr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue May 5 11:29:17 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 5 May 2015 13:29:17 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Hi, On 4 May 2015 at 08:31, Michael Snoyman wrote: > Just a little update on this. I pinged the author of publicsuffixlist > (necessary for proper cookie domain handling) about removing the > data-default dependency, and after discussion we decided to just merge the > code into http-client instead. With that change, the full dependency list > for http-client-openssl is in fact smaller that http-streams: I think we would accept a patch making cabal-install depend on http-client or http-streams if it was enabled with a flag. Refactorings required to make this work would also make it simpler to add support for curl/wget/whatever. From gershomb at gmail.com Tue May 5 14:15:10 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 5 May 2015 10:15:10 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Note that I?ve started some refactorings to support curl/wget/etc already. I?m not sure how best to keep these patches from stepping on one another?s toes. I?ll try to get my stuff to an unfinished, untested stopping point where nonetheless there is a clear extension point, and then perhaps a fork off of that branch would make sense? ?Gershom On May 5, 2015 at 7:29:21 AM, Mikhail Glushenkov (the.dead.shall.rise at gmail.com) wrote: > Hi, > > On 4 May 2015 at 08:31, Michael Snoyman wrote: > > Just a little update on this. I pinged the author of publicsuffixlist > > (necessary for proper cookie domain handling) about removing the > > data-default dependency, and after discussion we decided to just merge the > > code into http-client instead. With that change, the full dependency list > > for http-client-openssl is in fact smaller that http-streams: > > I think we would accept a patch making cabal-install depend on > http-client or http-streams if it was enabled with a flag. > Refactorings required to make this work would also make it simpler to > add support for curl/wget/whatever. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > From ryan at ryant.org Tue May 5 21:46:44 2015 From: ryan at ryant.org (Ryan Thomas) Date: Tue, 5 May 2015 22:46:44 +0100 Subject: ANN: cabal-install 1.22.4.0, 1.20.1.0, 1.18.1.0, 1.16.1.0, 0.14.1 released Message-ID: A minor release of 1.22, 1.20, 1.18, 1.16 & 0.14 has been completed for cabal-install, mainly to pick up the change to no longer use basic authentication over HTTP. The full changelog entries are below for each release, along with a sha1sum of each binary that was uploaded to hackage and the haskell.org site. Cheers, ryan 1.22.4.0 Ryan Thomas May 2015 * Force cabal upload to always use digest auth and never basic auth. * Add dependency-graph information to `printPlan` output * bootstrap.sh: fixes linker matching to avoid cases where tested linker names appear unexpectedly in compiler output (fixes #2542) 1.20.1.0 Ryan Thomas May 2015 * Force cabal upload to always use digest auth and never basic auth. * bootstrap.sh: install network-uri before HTTP 1.18.1.0 Ryan Thomas May 2015 * Force cabal upload to always use digest auth and never basic auth. * Merge pull request #2367 from juhp/patch-2 * Fix bootstrap.sh by bumping HTTP to 4000.2.16.1 1.16.1.0 Ryan Thomas May 2015 * More restrictive upper bound on network. * Force cabal upload to always use digest auth and never basic auth. 0.14.1 Ryan Thomas May 2015 * More restrictive upper bound on network. * Force cabal upload to always use digest auth and never basic auth. * Add the missing JobControl module. * Drop the "ghc-options: -rtsopts" on cabal-install. * Add -threaded and -rtsopts to cabal-install's ghc-options. * Parallelise the install command. * InstallPlan: Add a Processing package state. * Add a '-j' flag for the 'install' command. * Force the log for the error to be printed in parallel with the complete trace. * Remove goal choice nodes after reordering is completed. SHA1 Sums: b98eea96d321cdeed83a201c192dac116e786ec2 cabal-install-1.22.4.0.tar.gz 338fc09b0aa56fead06cecfae2bccd573f5dd3da cabal-install-1.20.1.0.tar.gz ab5c6801c6949a86edf41833c782201e0df1108f cabal-install-1.18.1.0.tar.gz ffb2cd81d620122982f5c1e4d8672c98d85296a0 cabal-install-1.16.1.0.tar.gz 35cd57eae72e0488a6a37ea503b906248da5230a cabal-install-0.14.1.tar.gz From gershomb at gmail.com Tue May 5 22:26:08 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 5 May 2015 18:26:08 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https We have some initial support for multibackend downloads and uploads both. Lots of bits are still missing, but the basic downloads work with curl and wget both, and the basic uploads with curl. The code regarding uploading build reports (which isn't in use anyway) is now commented out temporarily. Any work at adding other backends or further improving these (note the many TODO comments littering the code) can hopefully build on this. In particular, note there's an HttpTransportType, and a function `findHttpTransport`. In turn both `getHTTP` and `uploadToURI` now call this function, then case on the result to dispatch to different transports. All the transport specific logic should now be localized to those two places. This code is still rather ugly and could use some cleanup. But it should provide an extension point for using other https layers as well. On top of that, I haven't tackled the issue of making choice of transport configurable instead of just doing auto-discovery in a fixed order. It seems to me that this is something that could be added to the config file, or a command line flag, or both. So anyone that wants to fixate on that part of the problem, feel free to jump in :-) For my part, I wanted to get this out there to help anyone else interested in adding a transport. At this point, I intend mainly to just clean up what exists, fill in the powershell (and possibly bitsadmin) transport for windows, and then reenable HTTP as a fallback layer in some fashion (with warnings or confirmation or something). (I had commented out the layer entirely to make sure I wasn't missing any uses of it). Again, normally I wouldn't be sharing something in this halfway shape, but it seems useful to make it available for others interested in doing related work. Cheers, Gershom On Tue, May 5, 2015 at 10:15 AM, Gershom B wrote: > Note that I?ve started some refactorings to support curl/wget/etc already. > I?m not sure how best to keep these patches from stepping on one another?s > toes. I?ll try to get my stuff to an unfinished, untested stopping point > where nonetheless there is a clear extension point, and then perhaps a fork > off of that branch would make sense? > > ?Gershom > > > On May 5, 2015 at 7:29:21 AM, Mikhail Glushenkov ( > the.dead.shall.rise at gmail.com) wrote: > > Hi, > > > > On 4 May 2015 at 08:31, Michael Snoyman wrote: > > > Just a little update on this. I pinged the author of publicsuffixlist > > > (necessary for proper cookie domain handling) about removing the > > > data-default dependency, and after discussion we decided to just merge > the > > > code into http-client instead. With that change, the full dependency > list > > > for http-client-openssl is in fact smaller that http-streams: > > > > I think we would accept a patch making cabal-install depend on > > http-client or http-streams if it was enabled with a flag. > > Refactorings required to make this work would also make it simpler to > > add support for curl/wget/whatever. > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mietek at bak.io Wed May 6 04:03:47 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Wed, 6 May 2015 05:03:47 +0100 Subject: ANN: Cabal and cabal-install 1.22.3.0 released In-Reply-To: References: Message-ID: <17EAD8AD-EBE7-402A-AF5E-C056B796FBB6@bak.io> Ryan, cabal-install binaries for 1.20.1.0, 1.22.3.0, and 1.22.4.0 are now available in Halcyon on the following platforms: - Amazon Linux 2014.09 (x86_64) - Arch Linux (x86_64) - CentOS 6 (i386 and x86_64) - CentOS 7 (x86_64) - Debian 6 (i386 and x86_64) - Debian 7 (i386 and x86_64) - Fedora 20 (i386 and x86_64) - Fedora 21 (x86_64) - openSUSE 13.2 (x86_64) - OS X 10.8 (x86_64) - OS X 10.9 (x86_64) - OS X 10.10 (x86_64) - Red Hat Enterprise Linux 6 (x86_64) - Red Hat Enterprise Linux 7 (x86_64) - SUSE Linux Enterprise Server 12 (x86_64) - Ubuntu 10.04 LTS (x86_64) - Ubuntu 12.04 LTS (i386 and x86_64) - Ubuntu 14.04 LTS (i386 and x86_64) - Ubuntu 14.10 (i386 and x86_64) Fedora 19 (i386 and x86_64), Red Hat Enterprise Linus 6 (i386), and Ubuntu 10.04 LTS (i386) are gone. Support for Debian 8 and Ubuntu 15.04 is coming soon. Please note the Cabal download page is currently misleading users into believing they can download cabal-binaries directly from the Halcyon website. This is not the case. The idea is to use Halcyon to set up a Haskell environment, without depending on packages provided (or, more likely, not provided) by the distribution maintainers. -- Mi?tek https://mietek.io On 2015-04-20, at 15:56, Ryan Thomas wrote: > A minor release of Cabal and cabal-install has been completed. > > This is available for download on haskell.org as well as hackage. The > main reason for this release was a fix for the ghcjs-pkg version > number handling. The changelog entries for both are below. > > Cabal: > 1.22.3.0 Ryan Thomas April 2015 > * Fix for the ghcjs-pkg version number handling (Luite Stegeman) > * filterConfigureFlags: filter more flags (Mikhail Glushenkov) > * Cabal check will fail on -fprof-auto passed as a ghc-option > - Fixes #2479 (John Chee) > > cabal-install: > 1.22.3.0 Ryan Thomas April 2015 > * Fix bash completion for sandbox subcommands - Fixes #2513 > (Mikhail Glushenkov) > * filterConfigureFlags: filter more flags (Mikhail Glushenkov) > > Mi?tek, Mikhail: If you would be willing to build the additional > binaries as was done with 1.22.2.0 I will update the downloads page > with them too. > > Cheers, > > Ryan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From mietek at bak.io Wed May 6 04:04:45 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Wed, 6 May 2015 05:04:45 +0100 Subject: Cabal and cabal-install minor release (1.22.2.0) In-Reply-To: <294D41B5-7D15-4859-93ED-36C2DE77344B@bak.io> References: <0754B7EF-BA0E-4802-9906-203BA5594281@bak.io> <294D41B5-7D15-4859-93ED-36C2DE77344B@bak.io> Message-ID: <701EE2C6-1F1C-4368-BB6C-2928489E3CAC@bak.io> Likewise: Bootstrapped on OS X 10.10: https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.1.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.3.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.4.0.tar.gz Bootstrapped on OS X 10.9: https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.1.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.3.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.4.0.tar.gz Bootstrapped on OS X 10.8: https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.1.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.3.0.tar.gz https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.4.0.tar.gz -- Mi?tek https://mietek.io On 2015-03-29, at 15:14, Mi?tek Bak wrote: > Yes, it is possible, and no, sandboxes are kept in separate archives. > > Each of the following archives contains the cabal-install executable only, bootstrapped using GHC 7.8.4, located in `./bin/cabal`. > > Bootstrapped on OS X 10.10: > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.3.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.5.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.6.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.2.0.tar.gz > > Bootstrapped on OS X 10.9: > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.3.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.5.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.6.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.2.0.tar.gz > > Bootstrapped on OS X 10.8: > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.3.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.5.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.6.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.0.0.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.0.1.tar.gz > https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.2.0.tar.gz > > Note it?s also possible to browse Halcyon public storage: > https://halcyon.global.ssl.fastly.net/ > > > -- > Mi?tek > https://mietek.io > > > > > On 2015-03-29, at 06:55, Bob Ippolito wrote: > >> Is it possible to download and use these binary builds without halcyon? On Mac it's a bit hard to set up halcyon due to the bash 4 requirement, and there are no official cabal-install binaries of the latest releases for Mac (latest is 1.22.0.0). I took a look at the halcyon source but wasn't able to quickly figure out what the URL scheme for cabal-install on public storage would be, I'm guessing it's just included in a larger sandbox rather than distributed on its own? >> >> On Sun, Mar 22, 2015 at 5:58 PM, Mi?tek Bak wrote: >> Thanks, Ryan. I?ve since added binaries of 1.22.2.0 for: >> >> - Gentoo Linux (x86_64) >> - Slackware 14.1 (x86_64) >> >> I should note this is in addition to binaries of 1.22.0.0 and 1.20.0.3, also available for all of the previously mentioned platforms. >> >> Other versions can also be selected by the user to be bootstrapped and automatically cached: >> https://halcyon.sh/reference/#halcyon_cabal_version >> >> >> -- >> Mi?tek >> https://mietek.io >> >> >> >> >> On 2015-03-22, at 08:38, Ryan Thomas wrote: >> >>> Agreed, I'd love to have the CI tools build all of the release artifacts. >>> >>> Mi?tek: I'll update the downloads page with a link to halcyon for >>> those platforms. >>> >>> Cheers, >>> >>> ryan >>> >>> On 22 March 2015 at 08:36, Chris Wong wrote: >>>> On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell wrote: >>>>> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas wrote: >>>>>> >>>>>> - The Windows/OSX/Linux specific binaries need to be built and updated >>>>>> on the download page; Johan I will probably need some guidance on the >>>>>> process for this. >>>>> >>>>> >>>>> There's not much of a process I'm afraid. I usually send out and email to >>>>> cabal-devel@, asking for people to build binaries and send them to me. I >>>>> build some myself. Ideally at least one binary would be built by the release >>>>> process itself (and the others perhaps by build bots). >>>> >>>> AppVeyor and Travis CI support Windows and OS X respectively; perhaps >>>> we can arrange something with those. >>>> >>>>> _______________________________________________ >>>>> cabal-devel mailing list >>>>> cabal-devel at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel >>>>> >>>> >>>> -- >>>> https://lambda.xyz >>> _______________________________________________ >>> cabal-devel mailing list >>> cabal-devel at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel >> >> >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From ryan at ryant.org Wed May 6 07:27:48 2015 From: ryan at ryant.org (Ryan Thomas) Date: Wed, 6 May 2015 08:27:48 +0100 Subject: ANN: Cabal and cabal-install 1.22.3.0 released In-Reply-To: <17EAD8AD-EBE7-402A-AF5E-C056B796FBB6@bak.io> References: <17EAD8AD-EBE7-402A-AF5E-C056B796FBB6@bak.io> Message-ID: Thanks Mi?tek, I'll update the page and wording this evening (UTC) - do you have some preferred wording I should use on the page? Cheers, ryan On 6 May 2015 at 05:03, Mi?tek Bak wrote: > Ryan, > > cabal-install binaries for 1.20.1.0, 1.22.3.0, and 1.22.4.0 are now available in Halcyon on the following platforms: > > - Amazon Linux 2014.09 (x86_64) > - Arch Linux (x86_64) > - CentOS 6 (i386 and x86_64) > - CentOS 7 (x86_64) > - Debian 6 (i386 and x86_64) > - Debian 7 (i386 and x86_64) > - Fedora 20 (i386 and x86_64) > - Fedora 21 (x86_64) > - openSUSE 13.2 (x86_64) > - OS X 10.8 (x86_64) > - OS X 10.9 (x86_64) > - OS X 10.10 (x86_64) > - Red Hat Enterprise Linux 6 (x86_64) > - Red Hat Enterprise Linux 7 (x86_64) > - SUSE Linux Enterprise Server 12 (x86_64) > - Ubuntu 10.04 LTS (x86_64) > - Ubuntu 12.04 LTS (i386 and x86_64) > - Ubuntu 14.04 LTS (i386 and x86_64) > - Ubuntu 14.10 (i386 and x86_64) > > Fedora 19 (i386 and x86_64), Red Hat Enterprise Linus 6 (i386), and Ubuntu 10.04 LTS (i386) are gone. Support for Debian 8 and Ubuntu 15.04 is coming soon. > > Please note the Cabal download page is currently misleading users into believing they can download cabal-binaries directly from the Halcyon website. This is not the case. The idea is to use Halcyon to set up a Haskell environment, without depending on packages provided (or, more likely, not provided) by the distribution maintainers. > > > -- > Mi?tek > https://mietek.io > > > > > On 2015-04-20, at 15:56, Ryan Thomas wrote: > >> A minor release of Cabal and cabal-install has been completed. >> >> This is available for download on haskell.org as well as hackage. The >> main reason for this release was a fix for the ghcjs-pkg version >> number handling. The changelog entries for both are below. >> >> Cabal: >> 1.22.3.0 Ryan Thomas April 2015 >> * Fix for the ghcjs-pkg version number handling (Luite Stegeman) >> * filterConfigureFlags: filter more flags (Mikhail Glushenkov) >> * Cabal check will fail on -fprof-auto passed as a ghc-option >> - Fixes #2479 (John Chee) >> >> cabal-install: >> 1.22.3.0 Ryan Thomas April 2015 >> * Fix bash completion for sandbox subcommands - Fixes #2513 >> (Mikhail Glushenkov) >> * filterConfigureFlags: filter more flags (Mikhail Glushenkov) >> >> Mi?tek, Mikhail: If you would be willing to build the additional >> binaries as was done with 1.22.2.0 I will update the downloads page >> with them too. >> >> Cheers, >> >> Ryan > From the.dead.shall.rise at gmail.com Wed May 6 07:32:43 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 6 May 2015 09:32:43 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: On 6 May 2015 at 00:26, Gershom B wrote: > Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https Looks like a good first step. Consider using machinery in Distribution.Simple.Program.Db for searching for curl/wget in path or in user-provided location. I'd also use something like data Transport = { getHttp :: URI -> FilePath -> IO (Int, String), putHttp :: URI -> FilePath -> ...} configureTransport :: ProgramDB -> IO Transport instead of switching on TransportType in getHttp/uploadToUri. From gershomb at gmail.com Wed May 6 15:43:14 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 6 May 2015 11:43:14 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: The ?Transport? data type you suggest seems like a good refactor. I?m less certain about the use of ProgramDB ? the documentation suggests it will only be populated from command line flags in the ?configure? step, or from .cabal files. Since upload/download do not take place in such settings, I don?t think it will contain useful information yet. So it might be the right approach to use it, but it would also require, I suspect, modifying other parts of the cabal-install executable to populate it properly? ?Gershom On May 6, 2015 at 3:32:44 AM, Mikhail Glushenkov (the.dead.shall.rise at gmail.com) wrote: > On 6 May 2015 at 00:26, Gershom B wrote: > > Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https > > Looks like a good first step. Consider using machinery in > Distribution.Simple.Program.Db for searching for curl/wget in path or > in user-provided location. > > I'd also use something like > > data Transport = { getHttp :: URI -> FilePath -> IO (Int, String), > putHttp :: URI -> FilePath -> ...} > > configureTransport :: ProgramDB -> IO Transport > > instead of switching on TransportType in getHttp/uploadToUri. > From the.dead.shall.rise at gmail.com Wed May 6 16:53:07 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 6 May 2015 18:53:07 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: On 6 May 2015 at 17:43, Gershom B wrote: > I?m less certain about the use of ProgramDB ? the documentation suggests it will only be populated from command line flags in the ?configure? step, or from .cabal files. Since upload/download do not take place in such settings, I don?t think it will contain useful information yet. So it might be the right approach to use it, but it would also require, I suspect, modifying other parts of the cabal-install executable to populate it properly? You may need to use a separate ProgramDb (populated at runtime) just for curl/wget and friends. The point is that we already have some code for locating executables that supports setting program locations on command line ('--with-PROG-path') and in the config file, so it'd be nice to reuse it. From ttuegel at gmail.com Wed May 6 18:08:12 2015 From: ttuegel at gmail.com (Thomas Tuegel) Date: Wed, 6 May 2015 13:08:12 -0500 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: On Wed, May 6, 2015 at 11:53 AM, Mikhail Glushenkov wrote: > On 6 May 2015 at 17:43, Gershom B wrote: >> I?m less certain about the use of ProgramDB ? the documentation suggests it will only be populated from command line flags in the ?configure? step, or from .cabal files. Since upload/download do not take place in such settings, I don?t think it will contain useful information yet. So it might be the right approach to use it, but it would also require, I suspect, modifying other parts of the cabal-install executable to populate it properly? > > You may need to use a separate ProgramDb (populated at runtime) just > for curl/wget and friends. The point is that we already have some code > for locating executables that supports setting program locations on > command line ('--with-PROG-path') and in the config file, so it'd be > nice to reuse it. The saved program configuration is not serialized in `dist/setup-config`, [1] so it must be regenerated at runtime every time, anyway. [1]. https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple.hs#L426 -- Thomas Tuegel From the.dead.shall.rise at gmail.com Thu May 7 09:02:32 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 7 May 2015 11:02:32 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Hi, On 6 May 2015 at 20:08, Thomas Tuegel wrote: > The saved program configuration is not serialized in > `dist/setup-config`, [1] so it must be regenerated at runtime every > time, anyway. We don't want to configure all known built-in programs on each 'cabal upload', though, so we should introduce a 'configTransport' function to be used in 'uploadAction' instead of 'configCompiler'. From simonpj at microsoft.com Thu May 7 20:34:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 May 2015 20:34:05 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Dear Cabal developers I guess everyone is busy, but I feel a bit stuck on knowing how to make progress on this thread. Thanks Simon From: Simon Peyton Jones Sent: 20 April 2015 09:12 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: RE: Cabal and simultaneous installations of the same package Friends We started this thread (below) a month ago, but it has once more run out of steam. The last contribution was from Vishal Agrawal I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. Can you review the proposal and give me suggestions. I don't feel qualified to drive this process, but I do think it's important to complete it. (I might be wrong about this too... please say so if so.) Nor do I understand why it's difficult to tie up the bow; the underlying infrastructure work is done. Duncan especially: how can we make progress? Do you think it's important to make progress, or are other things in cabal-land more important? My reason for thinking that it's important is that it appears to be the root cause of many people's difficulties with Haskell and Cabal. It might not be a panacea for all ills; but it might be a cheap remedy for a significant proportion of ills. And that would be a Good Thing. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Peyton Jones | Sent: 23 March 2015 08:46 | To: cabal-devel at haskell.org | Cc: haskell-platform at projects.haskell.org; haskell- | infrastructure at community.galois.com; Haskell Libraries; ghc- | devs at haskell.org | Subject: Cabal and simultaneous installations of the same package | | Dear Cabal developers | | You'll probably have seen the thread about the Haskell Platform. | | Among other things, this point arose: | | | Another thing we should fix is the (now false) impression that HP | | gets in the way of installing other packages and versions due to | cabal hell. | | People mean different things by "cabal hell", but the inability to | simultaneously install multiple versions of the same package, | compiled against different dependencies is certainly one of them, | and I think it is the one that Yitzchak is referring to here. | | But some time now GHC has allowed multiple versions of the same package | (compiled against different dependencies) to be installed | simultaneously. So all we need to do is to fix Cabal to allow it too, | and thereby kill of a huge class of cabal-hell problems at one blow. | | But time has passed and it hasn't happened. Is this because I'm | misunderstanding? Or because it is harder than I think? Or because | there are much bigger problems? Or because there is insufficient | effort available? Or what? | | Unless I'm way off beam, this "multiple installations of the same | package" thing has been a huge pain forever, and the solution is within | our grasp. What's stopping us grasping it? | | Simon | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu May 7 21:19:46 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 7 May 2015 23:19:46 +0200 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 7 May 2015 at 22:34, Simon Peyton Jones wrote: > Dear Cabal developers > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > progress on this thread. Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have to wait and see what comes out of it now. From gershomb at gmail.com Thu May 7 21:28:32 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 7 May 2015 17:28:32 -0400 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: For the info of all, here is the proposal: https://gist.github.com/fugyk/37510958b52589737274 The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project proceeds, Vishal will be checking in with us, asking questions and seeking clarification where necessary, etc. --Gershom On Thu, May 7, 2015 at 5:19 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > On 7 May 2015 at 22:34, Simon Peyton Jones wrote: > > Dear Cabal developers > > > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > > progress on this thread. > > Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have > to wait and see what comes out of it now. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu May 7 22:14:41 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 7 May 2015 18:14:41 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: On my branch now, everything "should" work: https://github.com/gbaz/Cabal/tree/https By "should" I mean the refactor is in place, and we have support for curl, wget, powershell, and insecure-http. You can pass a global flag to set your preferred transport (and it will not try insecure-http unless you explictly request it). If you use any transport but insecure-http it will convert http to https urls automatically. Things that remain outstanding 1) ETags are not enabled on the new transports -- this is just some tedious work to emit them from the programs and parse them out. 2) http-transport is a global option and can be passed, but it doesn't seem to wind up in the documentation correctly. Not sure how to configure the options properly. 3) Proxy support is not fully tested on curl/wget -- it _did_ work on my machine at one point, but it lives behind a particularly perverse proxy and ceased working in a way I can't diagnose and might just be due to a hopeless proxy. 4) I haven't properly tested upload support on wget, which is fiddly since it needs to do its own multipart encoding just like insecure-http. 5) Proxies are not enabled on powershell -- this is some tedious work to automate parsing out the proxy settings better, since the "correct powershell" way to handle proxies with user/passwords doesn't seem to actually work. 6) Powershell also needs real escaping, in case package names/urls perversely have quotation marks in them. Anyway, this touched a bunch of stuff in small ways and could use some review and _especially_ some testers across various platforms and transports to see what's still missing, If any brave souls want to try out the various transports, or pick up some of the remaining work, please do! This was a nice exercise, but I could really use another set or two of eyes/hands to take it to 100%. (note that even though I branched before the digest fix, I ported it over to this branch, so that the insecure-http transport _should_ be using digest auth properly already). --Gershom On Thu, May 7, 2015 at 5:02 AM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 6 May 2015 at 20:08, Thomas Tuegel wrote: > > The saved program configuration is not serialized in > > `dist/setup-config`, [1] so it must be regenerated at runtime every > > time, anyway. > > We don't want to configure all known built-in programs on each 'cabal > upload', though, so we should introduce a 'configTransport' function > to be used in 'uploadAction' instead of 'configCompiler'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Fri May 8 16:46:44 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Fri, 8 May 2015 18:46:44 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: On 8 May 2015 at 00:14, Gershom B wrote: > On my branch now, everything "should" work: > https://github.com/gbaz/Cabal/tree/https Thanks for working on this. I only had time to take a brief glance, but everything looks good so far. Hope we can merge your patches soon. > (note that even though I branched before the digest fix, I ported it over to > this branch, so that the insecure-http transport _should_ be using digest > auth properly already). You could've just rebased (which is a good practice anyway). From pengyu.ut at gmail.com Sat May 16 01:55:48 2015 From: pengyu.ut at gmail.com (Peng Yu) Date: Fri, 15 May 2015 20:55:48 -0500 Subject: Why alex can not be automatically installed? Message-ID: Hi, I see the following error. Why alex can not be automatically installed? $ cabal install language-javascript Resolving dependencies... Configuring language-javascript-0.5.13.3... Failed to install language-javascript-0.5.13.3 Build log ( /Users/pengy/.cabal/logs/language-javascript-0.5.13.3.log ): Configuring language-javascript-0.5.13.3... setup-Simple-Cabal-1.22.2.0-x86_64-osx-ghc-7.10.1: The program 'alex' version >=3.1 is required but it could not be found. cabal: Error: some packages failed to install: language-javascript-0.5.13.3 failed during the configure step. The exception was: ExitFailure 1 -- Regards, Peng From pengyu.ut at gmail.com Sat May 16 01:57:47 2015 From: pengyu.ut at gmail.com (Peng Yu) Date: Fri, 15 May 2015 20:57:47 -0500 Subject: What is the error mean for bloomfilter? Message-ID: $ cabal install bloomfilter Resolving dependencies... Configuring bloomfilter-2.0.0.0... Building bloomfilter-2.0.0.0... Failed to install bloomfilter-2.0.0.0 Build log ( /Users/pengy/.cabal/logs/bloomfilter-2.0.0.0.log ): Configuring bloomfilter-2.0.0.0... Building bloomfilter-2.0.0.0... Preprocessing library bloomfilter-2.0.0.0... [1 of 7] Compiling Data.BloomFilter.Array ( Data/BloomFilter/Array.hs, dist/build/Data/BloomFilter/Array.o ) [2 of 7] Compiling Data.BloomFilter.Mutable.Internal ( Data/BloomFilter/Mutable/Internal.hs, dist/build/Data/BloomFilter/Mutable/Internal.o ) [3 of 7] Compiling Data.BloomFilter.Util ( Data/BloomFilter/Util.hs, dist/build/Data/BloomFilter/Util.o ) [4 of 7] Compiling Data.BloomFilter.Mutable ( Data/BloomFilter/Mutable.hs, dist/build/Data/BloomFilter/Mutable.o ) Data/BloomFilter/Mutable.hs:136:9: Non type-variable argument in the constraint: Data.Array.Base.MArray (Data.Array.Base.STUArray s) Hash m (Use FlexibleContexts to permit this) When checking that ?loop? has the inferred type loop :: forall (m :: * -> *). Data.Array.Base.MArray (Data.Array.Base.STUArray s) Hash m => [Int :* Int] -> m Bool In an equation for ?elem?: elem elt mb = loop (hashesM mb elt) where mu = bitArray mb loop ((word :* bit) : wbs) = do { i <- unsafeRead mu word; .... } loop _ = return True cabal: Error: some packages failed to install: bloomfilter-2.0.0.0 failed during the building phase. The exception was: ExitFailure 1 -- Regards, Peng From the.dead.shall.rise at gmail.com Sat May 16 12:45:35 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 16 May 2015 14:45:35 +0200 Subject: What is the error mean for bloomfilter? In-Reply-To: References: Message-ID: Hi, On 16 May 2015 at 03:57, Peng Yu wrote: > Data/BloomFilter/Mutable.hs:136:9: > Non type-variable argument > in the constraint: [...] Not a Cabal issue: the library wasn't updated to work with GHC 7.10. See https://github.com/bos/bloomfilter/issues/11 and https://github.com/bos/bloomfilter/pull/10 From the.dead.shall.rise at gmail.com Sat May 16 12:50:44 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 16 May 2015 14:50:44 +0200 Subject: Why alex can not be automatically installed? In-Reply-To: References: Message-ID: Hi, On 16 May 2015 at 03:55, Peng Yu wrote: > Hi, I see the following error. Why alex can not be automatically installed? See https://github.com/haskell/cabal/issues/220. Patches welcome! From pengyu.ut at gmail.com Sat May 16 14:31:14 2015 From: pengyu.ut at gmail.com (Peng Yu) Date: Sat, 16 May 2015 09:31:14 -0500 Subject: What is the error mean for bloomfilter? In-Reply-To: References: Message-ID: I'm not sure how to fix the problem after reading the links you pointed. Would you please be specific what should be done? Thanks. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 On Sat, May 16, 2015 at 7:45 AM, Mikhail Glushenkov wrote: > Hi, > > On 16 May 2015 at 03:57, Peng Yu wrote: >> Data/BloomFilter/Mutable.hs:136:9: >> Non type-variable argument >> in the constraint: [...] > > Not a Cabal issue: the library wasn't updated to work with GHC 7.10. > See https://github.com/bos/bloomfilter/issues/11 and > https://github.com/bos/bloomfilter/pull/10 -- Regards, Peng From fuuzetsu at fuuzetsu.co.uk Sat May 16 15:12:11 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 16 May 2015 16:12:11 +0100 Subject: What is the error mean for bloomfilter? In-Reply-To: References: Message-ID: <55575E4B.8040907@fuuzetsu.co.uk> On 05/16/2015 03:31 PM, Peng Yu wrote: > I'm not sure how to fix the problem after reading the links you > pointed. Would you please be specific what should be done? Thanks. > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > > On Sat, May 16, 2015 at 7:45 AM, Mikhail Glushenkov > wrote: >> Hi, >> >> On 16 May 2015 at 03:57, Peng Yu wrote: >>> Data/BloomFilter/Mutable.hs:136:9: >>> Non type-variable argument >>> in the constraint: [...] >> >> Not a Cabal issue: the library wasn't updated to work with GHC 7.10. >> See https://github.com/bos/bloomfilter/issues/11 and >> https://github.com/bos/bloomfilter/pull/10 > It's not a cabal problem, it's not relevant on this list. The links you were given already point out that the issue is known and even a link to the pull request that fixes it. -- Mateusz K. From pengyu.ut at gmail.com Sat May 16 15:35:01 2015 From: pengyu.ut at gmail.com (Peng Yu) Date: Sat, 16 May 2015 10:35:01 -0500 Subject: What is the error mean for bloomfilter? In-Reply-To: <55575E4B.8040907@fuuzetsu.co.uk> References: <55575E4B.8040907@fuuzetsu.co.uk> Message-ID: But I am not able to install version 2.0.1. How to get 2.0.1 via cabal? On Sat, May 16, 2015 at 10:12 AM, Mateusz Kowalczyk wrote: > On 05/16/2015 03:31 PM, Peng Yu wrote: >> I'm not sure how to fix the problem after reading the links you >> pointed. Would you please be specific what should be done? Thanks. >> >> $ ghc --version >> The Glorious Glasgow Haskell Compilation System, version 7.10.1 >> >> On Sat, May 16, 2015 at 7:45 AM, Mikhail Glushenkov >> wrote: >>> Hi, >>> >>> On 16 May 2015 at 03:57, Peng Yu wrote: >>>> Data/BloomFilter/Mutable.hs:136:9: >>>> Non type-variable argument >>>> in the constraint: [...] >>> >>> Not a Cabal issue: the library wasn't updated to work with GHC 7.10. >>> See https://github.com/bos/bloomfilter/issues/11 and >>> https://github.com/bos/bloomfilter/pull/10 >> > > It's not a cabal problem, it's not relevant on this list. The links you > were given already point out that the issue is known and even a link to > the pull request that fixes it. > > > -- > Mateusz K. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -- Regards, Peng From the.dead.shall.rise at gmail.com Sat May 16 15:55:32 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 16 May 2015 17:55:32 +0200 Subject: What is the error mean for bloomfilter? In-Reply-To: References: <55575E4B.8040907@fuuzetsu.co.uk> Message-ID: On 16 May 2015 at 17:35, Peng Yu wrote: > But I am not able to install version 2.0.1. How to get 2.0.1 via cabal? It hasn't been released yet. You can get a patched version from GitHub: $ git clone https://github.com/mikeizbicki/bloomfilter.git bloomfilter-2.0.1 $ cd bloomfilter-2.0.1 $ cabal install From gershomb at gmail.com Mon May 18 18:22:52 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 18 May 2015 14:22:52 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: I've been happily using the curl backend for a bit now and it seems to work fine, so I'd like to get this polished and committed. Since the curl backend works, then even if the wget and powershell backends aren't fully tested, the workaround can just be to tell users to install curl and make sure it is in their path (or to pass the insecure-http option that falls back to the existing implementation). So perhaps we can just patch cabal to warn on using wget or powershell backends that if there are issues they should try one of the fully finished options, and then we can merge? Alternately, someone can jump in and try to give a hand with the other two backends -- they're very close. -g On Fri, May 8, 2015 at 12:46 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > On 8 May 2015 at 00:14, Gershom B wrote: > > On my branch now, everything "should" work: > > https://github.com/gbaz/Cabal/tree/https > > Thanks for working on this. I only had time to take a brief glance, > but everything looks good so far. Hope we can merge your patches soon. > > > (note that even though I branched before the digest fix, I ported it > over to > > this branch, so that the insecure-http transport _should_ be using digest > > auth properly already). > > You could've just rebased (which is a good practice anyway). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Mon May 18 20:15:30 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 18 May 2015 22:15:30 +0200 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Hi, On 18 May 2015 at 20:22, Gershom B wrote: > So perhaps we can just patch cabal to warn on using wget or powershell > backends that if there are issues they should try one of the fully finished > options, and then we can merge? Sure, please send us a pull request. From gershomb at gmail.com Wed May 27 22:00:34 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 27 May 2015 18:00:34 -0400 Subject: Making cabal-install SSL capable In-Reply-To: References: <87618gisk9.fsf@gnu.org> Message-ID: Done: https://github.com/haskell/cabal/pull/2613 :-) --Gershom On Mon, May 18, 2015 at 4:15 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 18 May 2015 at 20:22, Gershom B wrote: > > So perhaps we can just patch cabal to warn on using wget or powershell > > backends that if there are issues they should try one of the fully > finished > > options, and then we can merge? > > Sure, please send us a pull request. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meditans at gmail.com Tue May 26 18:39:38 2015 From: meditans at gmail.com (Carlo Nucera) Date: Tue, 26 May 2015 20:39:38 +0200 Subject: Nix configuration for cabal hacking Message-ID: Hi all, I will be at ZuriHack in a few days, and I'd like to start hacking on Cabal. I'm reading the cabal codebase description on github, and I'd like a few suggestion on how to set up the environment, so that I won't waste time setting up. I use the nix package manager for all things haskell-related, so I'm wary to just do cabal install in a sandbox, as suggested by the tutorial in the github page. Here it is my current ~/.nixpkgs/config.nix: https://gist.github.com/meditans/d66371137814d0dc3707 I stripped away most of the non necessary things. As you can see from the gist, I tried to install Cabal that as a package, but it didn't work the naive way. Is there among you anyone that develops with nix? What's your configuration? Thanks, see you friday! Carlo