- cabal-devel - Haskell.org

cabal install fails with empty conflict set
by Björn Peemöller 19 May '14

19 May '14

Hi, I am trying to install a cabal package in a fresh, clean sandbox, but cabal fails with: cabal: Could not resolve dependencies: Dependency tree exhaustively searched. I'm using $ cabal -V cabal-install version 1.20.0.1 using version 1.20.0.0 of the Cabal library $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.8.2 Even when I try -v3 I do not get much more information: $cabal install --only-dependencies -v3 Using a sandbox located at /home/bjp/projects/curry-frontend/.cabal-sandbox Searching for ghc in path. Found ghc at /home/bjp/.ghc-config/ghc/bin/ghc ("/home/bjp/.ghc-config/ghc/bin/ghc",["--numeric-version"]) /home/bjp/.ghc-config/ghc/bin/ghc is version 7.8.2 looking for tool ghc-pkg near compiler in /home/bjp/.ghc-config/ghc/bin found ghc-pkg in /home/bjp/.ghc-config/ghc/bin/ghc-pkg ("/home/bjp/.ghc-config/ghc/bin/ghc-pkg",["--version"]) /home/bjp/.ghc-config/ghc/bin/ghc-pkg is version 7.8.2 ("/home/bjp/.ghc-config/ghc/bin/ghc",["--supported-languages"]) ("/home/bjp/.ghc-config/ghc/bin/ghc",["--info"]) The package database already exists: /home/bjp/projects/curry-frontend/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d Reading available packages... Reading available packages... Reading installed packages... ("/home/bjp/.ghc-config/ghc/bin/ghc-pkg",["dump","--package-db=/home/bjp/projects/curry-frontend/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d","-v0"]) ("/home/bjp/.ghc-config/ghc/bin/ghc",["--print-libdir"]) Found no modified add-source deps. Reading installed packages... ("/home/bjp/.ghc-config/ghc/bin/ghc-pkg",["dump","--global","-v0"]) ("/home/bjp/.ghc-config/ghc/bin/ghc-pkg",["dump","--package-db=/home/bjp/projects/curry-frontend/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d","-v0"]) ("/home/bjp/.ghc-config/ghc/bin/ghc",["--print-libdir"]) Reading available packages... Choosing modular solver. Resolving dependencies... [__0] trying: curry-frontend-0.3.10 (user goal) [__1] trying: base-4.7.0.0/installed-018... (dependency of curry-frontend-0.3.10) [__2] trying: rts-1.0/installedbuil... (dependency of base-4.7.0.0/installed-018...) [__3] trying: integer-gmp-0.5.1.0/installed-dc4... (dependency of base-4.7.0.0/installed-018...) [__4] trying: ghc-prim-0.3.1.0/installed-948... (dependency of base-4.7.0.0/installed-018...) [__5] trying: curry-frontend-0.3.10:+split-syb [__6] trying: syb-0.4.1 (dependency of curry-frontend-0.3.10) [__7] trying: syb-0.4.1:!test [__8] trying: transformers-0.3.0.0/installed-7df... (dependency of curry-frontend-0.3.10) [__9] trying: process-1.2.0.0/installed-eaf... (dependency of curry-frontend-0.3.10) [_10] trying: unix-2.7.0.1/installed-23f... (dependency of process-1.2.0.0/installed-eaf...) [_11] trying: time-1.4.2/installed-b47... (dependency of unix-2.7.0.1/installed-23f...) [_12] trying: old-locale-1.0.0.6/installed-be1... (dependency of time-1.4.2/installed-b47...) [_13] trying: bytestring-0.10.4.0/installed-7de... (dependency of unix-2.7.0.1/installed-23f...) [_14] trying: deepseq-1.3.0.2/installed-716... (dependency of process-1.2.0.0/installed-eaf...) [_15] trying: array-0.5.0.0/installed-9f2... (dependency of deepseq-1.3.0.2/installed-716...) [_16] trying: mtl-2.1.2/installed-d71... (dependency of curry-frontend-0.3.10) [_17] trying: either-4.1.2 (dependency of curry-frontend-0.3.10) [_18] trying: transformers-base-0.4.2 (dependency of either-4.1.2) [_19] trying: transformers-base-0.4.2:+orphaninstances [_20] trying: semigroupoids-4.0.2 (dependency of either-4.1.2) [_21] trying: distributive-0.4.4 (dependency of semigroupoids-4.0.2) [_22] trying: distributive-0.4.4:-lib-werror [_23] trying: distributive-0.4.4:!test [_24] trying: transformers-compat-0.3.2 (dependency of distributive-0.4.4) [_25] trying: transformers-compat-0.3.2:-transformers3 [__0] fail (backjumping, conflict set: ) cabal: Could not resolve dependencies: Dependency tree exhaustively searched. Note: when using a sandbox, all packages are required to have consistent dependencies. Try reinstalling/unregistering the offending packages or recreating the sandbox. Does anybody have an idea what the problem is? Best Regards, Björn

2 5

"Showing last 10 lines of the build log"
by Bardur Arantsson 11 May '14

11 May '14

(I'm currently using Cabal 1.18.) Working with sandboxes and multiple cabal packages (via --add-source and a super-package which requires all the others), I've found that the Showing last 10 lines of the build log feature is less useful than one would hope for. When restructuring code across multiple packages there's a lot of potential for huge error messages, *and* furthermore the most interesting lines in the build log are actually towards the *start* og the build log since that's where the *first* error shows up -- given the nature of compilers you generally always want to fix the first-occuring error first since that may fix subsequent errors. So, here's a little feature request: Couldn't we just have cabal install spit out the full build log in case a build fails? Is there any real disadvantage that I'm not seeing?

2 3

Cabal problem
by Simon Peyton Jones 09 May '14

09 May '14

Dear Cabal-ers I have downloaded a binary installation of GHC 7.8.2, for Linux. Now I want to install regex-compat. First I had to deal with the http_proxy problem, in my last email. But now I get this: cabal install regex-compat Resolving dependencies... Downloading regex-posix-0.95.2... Configuring regex-posix-0.95.2... Building regex-posix-0.95.2... Preprocessing library regex-posix-0.95.2... [1 of 6] Compiling Text.Regex.Posix.Wrap ( dist/build/Text/Regex/Posix/Wrap.hs, dist/build/Text/Regex/Posix/Wrap.o ) [2 of 6] Compiling Text.Regex.Posix.String ( Text/Regex/Posix/String.hs, dist/build/Text/Regex/Posix/String.o ) [3 of 6] Compiling Text.Regex.Posix.Sequence ( Text/Regex/Posix/Sequence.hs, dist/build/Text/Regex/Posix/Sequence.o ) [4 of 6] Compiling Text.Regex.Posix.ByteString ( Text/Regex/Posix/ByteString.hs, dist/build/Text/Regex/Posix/ByteString.o ) [5 of 6] Compiling Text.Regex.Posix.ByteString.Lazy ( Text/Regex/Posix/ByteString/Lazy.hs, dist/build/Text/Regex/Posix/ByteString/Lazy.o ) [6 of 6] Compiling Text.Regex.Posix ( Text/Regex/Posix.hs, dist/build/Text/Regex/Posix.o ) /usr/bin/ld: cannot find -lHSregex-base-0.93.2-ghc7.8.2 /usr/bin/ld: cannot find -lHSmtl-2.1.2-ghc7.8.2 collect2: ld returned 1 exit status Failed to install regex-posix-0.95.2 cabal: Error: some packages failed to install: regex-compat-0.95.1 depends on regex-posix-0.95.2 which failed to install. regex-posix-0.95.2 failed during the building phase. The exception was: ExitFailure 1 simonpj@cam-05-unx:~/code/HEAD-1$ cabal install regex-base Resolving dependencies... All the requested packages are already installed: regex-base-0.93.2 Use --reinstall if you want to reinstall anyway. simonpj@cam-05-unx:~/code/HEAD-1$ So regex-base is already installed, but cabal isn't using it for regex-posix; nor is it installing regex-base-0.93.2. This seems to break the user's-eye view of the Cabal claim that it'll download and install the dependencies. Any thoughts? Simon

3 3

RE: Cabal can't open a TCP connection
by Simon Peyton Jones 08 May '14

08 May '14

Spot on, Kim-Ee. Thanks. unsetting http_proxy fixed it. I’m fwding to cabal-devel: it would be great that if “http_proxy” was set to “”, then it behaved just as if it was un-set. The current behaviour is very confusing (to me anyway). Simon From: Kim-Ee Yeoh [mailto:ky3@atamo.com] Sent: 08 May 2014 14:48 To: Simon Peyton Jones Cc: Herbert Valerio Riedel; Simon Marlow; ghc-devs(a)haskell.org Subject: Re: Cabal can't open a TCP connection On Thu, May 8, 2014 at 8:22 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: On a machine that doesn't need to use a proxy server, what should $http_proxy be set to? It's a Maybe (Maybe String) problem. Blame Cabal for not ignoring an empty http_proxy. The *nix programs I've tried treat empty as unset. The solution is: unset HTTP_PROXY. -- Kim-Ee ________________________________ Från: Simon Peyton Jones<mailto:simonpj@microsoft.com> Skickat: ‎2014-‎05-‎08 14:04 Till: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Kopia: Simon Marlow<mailto:marlowsd@gmail.com> Ämne: Cabal can't open a TCP connection Dear ghc-devs Cabal can’t open a TCP connection from my Linux box. It used to work fine. Here’s what it says: cabal -v3 update Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/1.16.0.2 Host: hackage.haskell.org proxy uri host: , port: Creating new connection to cabal: openTCPConnection: host lookup failure for "" simonpj@cam-05-unx:~/code/HEAD$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library simonpj@cam-05-unx:~/code/HEAD$ Can anyone help me work out what to do? git works just fine, so the internet is connected all right. Thanks Simon

1 0

Windows executable for just released cabal-install-1.20.0.1 needed
by Johan Tibell 07 May '14

07 May '14

Hi, It's that time again. 1.20.0.1 is out and I want to put a Windows executable for download on the Hackage website. Could someone provide me with one? -- Johan

4 8

Fedora Copr repo updated to cabal-install-1.20.0.1
by Jens Petersen 06 May '14

06 May '14

I updated my Fedora Copr repos to cabal-install-1.20.0.1 (though due to some copr flakiness the build failed somehow on F20 i686). https://copr.fedoraproject.org/coprs/petersen/cabal-install/ On 4 May 2014 09:25, Johan Tibell <johan.tibell(a)gmail.com> wrote: > It's that time again. 1.20.0.1 is out >

1 0

GenericPackageDescription and 'build-depends' field
by Daniel Trstenjak 24 Apr '14

24 Apr '14

Hi all, am I right, that the 'build-depends' field of the cabal file is now always represented by 'condTreeConstraints' in 'CondTree'? So is the 'targetBuildDepends' in 'BuildInfo' now only available for backward compatibility reasons? Greetings, Daniel

2 3

Themes for 1.22
by Johan Tibell 24 Apr '14

24 Apr '14

Hi all, While I'm sure we still have a bugfix release or two to make on the 1.20 branch, I thought it'd be worth looking at what we want to accomplish for 1.22. Here are my thoughts on what we should focus on: ## A dependency solver that always works As Hackage has grown so have the requirements of the dependency solver. There are three distinct problems I'm seeing now that we should tackle: * Treat each sections (i.e. library, test suite, benchmark, and executable) in the .cabal file separately for the purpose of dependency resolution. Today all the sections' dependencies are merged and used as the constraints of the package as a whole. This is troublesome for all packages that are dependencies of QC, HUnit, test-framework, and criterion, as there's a dependency cycle if you treat e.g. the containers package and its test suite as one unit. The solution here is to treat each unit as a mini package for the purpose of dependency resolution. This would also allow you to have e.g. several executables with conflicting dependencies. * Improve performance. Some packages (e.g. yesod) can take over 10 seconds to run over. This problem will get worse as Hackage grows and we build bigger applications on top of it, so we need to tackle this now before it becomes a real problem. * Fix Hackage package blacklisting. Users can blacklist packages on Hackage e.g. if they know them to be broken. However, this doesn't really work as the Hackage blacklist translates to a soft preference in the dependency solver and is thus often ignored. See https://github.com/haskell/cabal/issues/1792 for the gory details. ## Do the right thing automatically This is a carry-over from the 1.20 goals, as we didn't make much progress here. The focus here should be on avoiding manual steps the cabal could do for the user. * Automatically install dependencies when needed. When `cabal build` would fail due to a missing dependency, just install this dependency instead of bugging the user to do it. This will probably have to be limited to sandboxes where we can't break the user's system * GHCi support could be improved by rebinding :reload to rerun e.g. preprocessors automatically. This would enable the users to develop completely from within ghci (i.e. faster edit-save-type-error cycle). We have most of what we need here (i.e. GHC macro support) but someone needs to make the final change to generate a .ghci file to pass in the ghci invocation. ## Faster builds I think we're almost done here. There's really only one remaining thing to do: * Build components and different ways (e.g. profiling) in parallel. We could build both profiling and non-profiling versions in parallel. We could also build e.g. all test suites in parallel. The key challenge here is to coordinate all parallel jobs so we don't spawn too many. ## Support large projects This is also a carry-over from the 1.20 goals. We still don't have a good story for large projects. Sandboxes are too annoying to use if there are 100 add-source deps. We need more automation and more opinionated defaults (e.g. scan the sub-directories from in which cabal was run to find source packages.) What we need most of all here is a design. Perhaps we could try to get together at some Hackathon/ICFP and discuss. ## Issue tracker spring cleaning and test suite improvements The issue tracker is out-of-hand. It's too unwieldy to use for planning our work and get an overview of the most important issues. We should try to close down bugs that haven't had updates in years with extreme prejudice. If the issue is important it will pop up again. We're also severely lacking in the testing department. There are two problems: * There aren't enough tests: the cabal user facing surface is quite larger (lots of features and flags) and many of them are not tested at all, which will lead to regressions as we keep fixing bugs and adding features. * The tests take too long to run: we have too many end-to-end style tests (i.e. build a whole package) and not enough unit style tests. We need to add more of the latter kind. Cheers, Johan

4 5

Needed: distributable executables for the 1.20 release
by Johan Tibell 21 Apr '14

21 Apr '14

Hi, As per usual I want to provide executables for download for download on the cabal homepage, for Windows and OS X. I can build the OS X one myself. Could someone please send me a 64-bit Windows cabal executable? -- Johan

2 1

Announcing cabal 1.20
by Johan Tibell 20 Apr '14

20 Apr '14

Hi all, On behalf of all the cabal contributors, I'm proud to announce cabal 1.20. With 404 commits since the 1.18 release, this is a feature packed release. Here's a short summary of the perhaps most notable changes: * Dependency freezing * Parallel cabal build * Flag to temporary ignore upper bounds * Unnecessary re-linking avoidance * Streaming cabal test output * New cabal exec command * Haddock configuration options I did a longer write-up about the new features on my blog: http://blog.johantibell.com/2014/04/announcing-cabal-120.html ## Contributors Here are the contributors for this release, ordered by number of commits: * Mikhail Glushenkov * Johan Tibell * Duncan Coutts * Thomas Tuegel * Ian D. Bollinger * Ben Armston * Niklas Hambüchen * Daniel Trstenjak * Tuncer Ayaz * Herbert Valerio Riedel * Tillmann Rendel * Liyang HU * Dominic Steinitz * Brent Yorgey * Ricky Elrod * Geoff Nixon * Florian Hartwig * Bob Ippolito * Björn Peemöller * Wojciech Danilo * Sergei Trofimovich * Ryan Trinkle * Ryan Newton * Roman Cheplyaka * Peter Selinger * Niklas Haas * Nikita Karetnikov * Nick Smallbone * Mike Craig * Markus Pfeiffer * Luke Iannini * Luite Stegeman * John Lato * Jens Petersen * Jason Dagit * Gabor Pali * Daniel Velkov * Ben Millwood Apologies if someone was left out. Once in a while we have to make commits on behalf of an author. Those authors are not captured above. Enjoy, Johan

1 0