September 2014 - cabal-devel

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