- cabal-devel - Haskell.org

FW: Building ghc on Windows with msys2
by Simon Peyton Jones 09 Oct '14

09 Oct '14

Cabal folk: it looks as if updating Cabal has made GHC on Windows break. Might you investigate? See below Thanks Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Páli Gábor János Sent: 09 October 2014 06:15 To: ghc-devs(a)haskell.org Subject: Re: Building ghc on Windows with msys2 2014-10-07 17:02 GMT+02:00 Páli Gábor János <pali.gabor(a)gmail.com>: > 2014-10-07 15:04 GMT+02:00 cg <chengang31(a)gmail.com>: >> I guess the current two build server are all Cygwin based, they are >> failing at the same permission issue at early building stage, it >> prevents checking out the real problem. It seems msys2 (or msys) >> seldom has such issue. > > For what it is worth, I have been witnessing those permission issues > with msys2 on my Windows builders. They worked (more or the less) > fine until September 24, but suddenly, something has changed (not on > my side) and all I got those errors since. Looks like the commit with the Cabal submodule update causes this [1]. The revision before that commit still builds fine on my system, while everything else after that commit dies early at build [2]. Is this only me, has anybody else experienced the problem? Perhaps I am doing something wrong? I do not remember to see any related "heads-up" message on the list, like I should update any of the build-time dependencies. [1] http://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f… [2] http://haskell.inf.elte.hu/builders/windows-x86-head/56/10.html _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

tweaks to cabal-install bootstrap.sh
by Jake Wheat 28 Sep '14

28 Sep '14

Hello, I've made some tweaks to the bootstrap.sh here: https://github.com/JakeWheat/cabal/tree/bootstrap-tweaks 1. It avoids downloading the additional haskell package tarballs if these tarballs are already present in the current directory. Motivation: easily install on machines not connected to the internet, and make install more robust against local internet connection problems (we have a lot of these). 2. The SCOPE_OF_INSTALLATION variable use is slightly changed to allow installing cabal-install executable without either using or altering the user's package database, or replacing any cabal-install executable which they already have. Example: ghc-pkg init /home/jake/test_cabal/ SCOPE_OF_INSTALLATION='--global --package-db=/home/jake/test_cabal/packagedb' PREFIX=/home/jake/test_cabal/prefix ./bootstrap.sh Is it possible to put these changes into the main cabal repo? If there are some changes which would make the patch acceptable then please let me know. Also, is there a simpler way to meet these goals which I missed? Thanks, Jake Wheat

2 1

Re: HEADS UP: Running cabal install with the latest GHC
by Edward Z. Yang 27 Sep '14

27 Sep '14

Hi Reid, Ah yes, this is fallout from commit da7289882610ccae3f16c74be7440d19c29ecd20 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Wed Aug 27 16:33:20 2014 +0100 Change testsuite to not use old-style file package databases Now uses ghc-pkg init. The file-style databases are no longer supported. So yes, you will need a new version of cabal-install for GHC HEAD. Cheers, Edward Excerpts from Reid Barton's message of 2014-09-27 09:26:08 -0700: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > > > Hey all, > > > > SPJ pointed out to me today that if you try to run: > > > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > > > with the latest GHC HEAD, this probably will not actually work, because > > your system installed version of Cabal is probably too old to deal with > > the new package key stuff in HEAD. So, how do you get a version > > of cabal-install (and Cabal) which is new enough to do what you need > > it to? > > > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > > (or install it in a sandbox, if you like) and then cd'ing to > > libraries/Cabal/cabal-install and cabal install'ing that. > > > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton

1 0

Re: HEADS UP: Running cabal install with the latest GHC
by Carter Schonwald 27 Sep '14

27 Sep '14

Currently released cabal-install on hackage doesn't know how to do linkery for ghc head afaik, but I could be wrong On Sat, Sep 27, 2014 at 12:26 PM, Reid Barton <rwbarton(a)gmail.com> wrote: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > >> Hey all, >> >> SPJ pointed out to me today that if you try to run: >> >> cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 >> >> with the latest GHC HEAD, this probably will not actually work, because >> your system installed version of Cabal is probably too old to deal with >> the new package key stuff in HEAD. So, how do you get a version >> of cabal-install (and Cabal) which is new enough to do what you need >> it to? >> >> The trick is to compile Cabal using your /old/ GHC. Step-by-step, this >> involves cd'ing into libraries/Cabal/Cabal and running `cabal install` >> (or install it in a sandbox, if you like) and then cd'ing to >> libraries/Cabal/cabal-install and cabal install'ing that. >> > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

1 0

Proposal: cabal-install: verify OpenPGP signatures
by Nikita Karetnikov 26 Sep '14

26 Sep '14

Following up on the “cabal-install: Replacing HTTP with HTTPS” thread. I think we can do better. I want to make sure that people will notice if someone compromises the packages on hackage.haskell.org. Here’s a rough plan: 1. Patch ‘hackage-server’ to allow uploading of OpenPGP signatures. 2. Patch ‘cabal-install’ to use GPG for verification. (GPG trust levels could be useful here.) ‘cabal install’ should also support ‘--skip-verification’ or some such to avoid disaster during the adoption stage. In addition, ‘cabal update’ would fetch the list of fingerprints from Hackage and cache each revision. A warning would be raised if a fignerprint cannot be found in the cache. If a maintainer wants to use a new key, it must be signed with the previously used one. If a maintainer loses their private key, for instance, this should be resolved by the admins. For example, an admin (admins?) could sign the new key. After a while, a web of trust would be formed. The fingerprints of active maintainers would be well-known. I’ve been thinking about this for quite a while and don’t see other ways to achive the same level of trust while allowing arbitrary uploads. The proposal also doesn’t require much manual intervention. What do you think? I’m willing to work on this but want to make sure that my time won’t be wasted. Will you accept such a patch?

3 11

add an x86_64 linux build for cabal-install on the binaries site?
by Carter Schonwald 23 Sep '14

23 Sep '14

Hey All, http://www.haskell.org/cabal/download.html current lacks an x86_64 linux build, and while most linux distros DO provide a relatively recent cabal-install, might be good to make that available, it is one of the most widely used platforms for haskell! (also the 32bit linux build can't really be used on 64bit linux without installing the 32bit userland stuff afaict) perhaps it'd be good to add that? (if only because it'll help some poor soul on some gnarly distro)

2 1

Cabal Preprocessor Defines
by Manuel Schneckenreither 18 Sep '14

18 Sep '14

Hi all, I got some prepocessor constrains in one of my library I use for my new project. The section look like this: ... #ifdef DEBUG [ppSig sig | sig <- sigs ] #else [ppSig sig | sig <- filter ((\(_,_,r) -> not r) . lhsRootSym) sigs ] #endif ... Due to the reason that I am still developing wanted to specify the DEBUG preprocessor symbol to cpphs, gcc, ghc, or whatever program needs it. My suggestion was that cpphs should handle these definitions. So I tried several things, like: cabal configure --cpphs-options="--cpp -DDEBUG" --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build && cabal install , cabal configure --cpphs-options="-DDEBUG" --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build && cabal install or cabal configure && cabal build --cpphs-options="--cpp -DDEBUG" --cpphs-options=-DDEBUG --gcc-options=-DDEBUG && cabal install I tried it also in the cabal file: default-extensions: CPP -- also tried with other-extensions if flag(debug) CPP-Options: -DDEBUG if !os(windows) CC-Options: -DDEBUG else CC-Options: -DNDEBUG and compiling with cabal configure --flags=debug && cabal build && cabal install. None of them worked. Am I doing it wrong, or is there something wrong with cabal, cpphs, ghc, etc. Thanks for your reply, Manuel -- To reply secure use GnuPG encryption: Key Block to use (http://www.pinselzone.com/pgp/public_gpg_key.asc) What is GnuPG? (http://www.gnupg.org/)

2 1

Error of `cabal install cabal-install` on Mac OS X 10.9.4
by Peng Yu 31 Aug '14

31 Aug '14

Hi, I get the following error. Does anybody know how to fix it on Mac OS X 10.9.4? Thanks. $ cabal install cabal-install Resolving dependencies... Configuring Cabal-1.20.0.2... Failed to install Cabal-1.20.0.2 Last 10 lines of the build log ( /Users/py/.cabal/logs/Cabal-1.20.0.2.log ): cabal: Error: some packages failed to install: Cabal-1.20.0.2 failed during the configure step. The exception was: user error ( /var/folders/nn/p4t2bp0n0znc79dc77q45y9m0000gn/T/Cabal-1.20.0.2-95493/Cabal-1.20.0.2/Distribution/Simple/Utils.hs:386:31: Warning: In the use of ‘runGenProcess_’ (imported from System.Process.Internals): Deprecated: "Please do not use this anymore, use the ordinary 'System.Process.createProcess'. If you need the SIGINT handling, use delegate_ctlc = True (runGenProcess_ is now just an imperfectly emulated stub that probably duplicates or overrides your own signal handling)." Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding9_info, _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding3_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info ) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _hs_iconv_open) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.7.0.1.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ) cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. -- Regards, Peng

3 3

Status of encapsulations in the modular dependency solver
by Edward Z. Yang 16 Aug '14

16 Aug '14

Hello all, I wanted to know what the status of the encapsulations feature in Cabal is. Presented in HIW'11, the intent was for it to be used to support private dependencies in Cabal. However, while this is was implemented in the modular solver, it looks like it was never wired up with Cabal proper. Andres, you mentioned you might be getting around to looking at this again? Since we have more fine-grained linker symbols in GHC HEAD, this feature ought to work better. In any case, when I was reviewing the HIW'11, I realized that the semantics of encapsulations discussed there are not quite the ones you might actually want. In particular, there was an example where C encapsulates its dependency on B, but if C has another (non-encapsulated) dependency D which depends on B, now the global choice of B (witnessed through C.D.B) and C.B are required to be the same. However, it might also be useful for these two dependencies to still be different, even in this case. In particular, it may be useful to encapsulate a package *even if it shows up in the interface.* Such packages can be used for: - Building compatibility layers between multiple versions of a package (here, we want to build-depends on the same package multiple times, in an encapsulated way) - Using the encapsulations feature to represent Backpack style mix-ins, where packages with holes are considered encapsulated. (I'm not 100% this is the right way to go about implementing this, but it's one possibility). Cheers, Edward

1 0

cabal sandbox and the dist directory
by Daniel Trstenjak 15 Aug '14

15 Aug '14

Hi, currently it's conceptually and practically a bit unpleasant, that the sandbox is a bit holey, because the 'dist' directory remains when deleting the sandbox. Is there a special reason for this behaviour? In the case of a sandbox, why is there a 'dist' directory at all, respectively why isn't it located inside of the '.cabal-sandbox' directory? Greetings, Daniel

3 3