August 2014 - cabal-devel

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

27 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

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

01 Sep '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 17 Aug '14

17 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 16 Aug '14

16 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

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

14 Aug '14

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. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward

3 5