http://blog.gmane.org/gmane.comp.lang.haskell.cabal.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8990 <pre> Haven't had time to look at it yet (on the road atm) but I just wanted to say a big thank you Bryan for all the hard work! Will do when I get back (unless Andres beats me to it) Duncan _______________________________________________ cabal-devel mailing list cabal-devel&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel </pre> Duncan Coutts 2012-05-24T17:06:53 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8989 <pre> At least one of the ticket cross-references has gone wrong: https://github.com/haskell/cabal/issues/653 I refer to #719 in this ticket, which links to github issue #719, but that's Trac ticket #729. I wanted the ticket imported from Trac #719, i.e. this one https://github.com/haskell/cabal/issues/710 </pre> Ben Millwood 2012-05-24T14:49:10 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8988 <pre>Hi Bryan. First of all, thanks. It looks great. On Thu, May 24, 2012 at 8:14 AM, Bryan O'Sullivan &lt;bos&lt; at &gt;serpentine.com&gt; wrote: Sorry for noting this only once I go through the Wiki page. The difficulty level has not been converted? It's not terribly important, but we've used it in the past to point interested newcomers to supposedly "easy" tasks. If it's a lot of work to change now, then don't. But perhaps it could be done by just modifying the already converted tickets in one batch process and adding new tags? I have tried to delete ticket modification permissions for authenticated users in the trac. I'm hesitating to change the file permissions, as we'll probably still want to use the Wiki for now. I changed the pointers on the Trac main page and on haskell.org/cabal -- there are probably other references elsewhere. If you know of anything important that should be changed, please let me know. Cheers, Andres </pre> Andres Löh 2012-05-24T06:43:16 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8987 <pre>You can now find open issues here: https://github.com/haskell/cabal/issues?state=open Duncan or Andres, could one of you please chmod -w the files owned by Trac, and add a note pointing people to github for filing bugs? </pre> Bryan O'Sullivan 2012-05-24T06:14:01 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8986 <pre>#282: profiling versions of libraries not managed well ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: profiling Difficulty: hard (&lt; 1 day) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Changes (by rrnewton): * cc: rrnewton&lt; at &gt;… (added) </pre> Hackage 2012-05-23T15:50:13 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8985 <pre>#955: Incorrect hpcdir during cabal test for testsuites w/ library coverage enabled ----------------------------+----------------------------------------------- Reporter: albertfong | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 7.4.1 Platform: Windows | ----------------------------+----------------------------------------------- When running "cabal test" on a project configured with "cabal configure --enable-tests --enable-library-coverage", the hpcdir for test suites points to dist/hpc/mix/PackageName, not dist/hpc/mix/TestSuiteName. This results in an aborted run: {{{ PS C:\Users\Albert Fong\Repositories\working\projects\Simple&gt; runhaskell.exe .\Setup.hs test -v Running 3 test suites... Test suite Tests3: RUNNING... Test suite Tests3: PASS Test suite logged to: dist\test\Simple-0.1.0.0-Tests3.log C:\Users\Albert Fong\Repositories\working\devenv\tools\ghc-7.4.1\bin\hpc.exe markup dist\hpc\tix\Tests3\Tests3.tix --hpc dir=dist\hpc\mix\Simple-0.1.0.0 --destdir=dist\hpc\html\Tests3 --exclude=Main hpc.exe: can not find Library in ["./dist\\hpc\\mix\\Simple-0.1.0.0"] PS C:\Users\Albert Fong\Repositories\working\projects\Simple&gt; }}} Note the hpcdir during build ("-fhpc -hpcdir dist\hpc\mix\Tests3") is not what's used during test ("--hpcdir=dist\hpc\mix\Simple-0.1.0.0") {{{ Preprocessing test suite 'Tests3' for Simple-0.1.0.0... Building test suite Tests3... creating dist\build\Tests3 creating dist\build\Tests3\Tests3-tmp C:\Users\Albert Fong\Repositories\working\devenv\tools\ghc-7.4.1\bin\ghc.exe --make -o dist\build\Tests3\Tests3.exe -hid e-all-packages -fbuilding-cabal-package -no-user-package-conf -package- conf dist\package.conf.inplace -i -idist\build\Te sts3\Tests3-tmp -i. -idist\build\autogen -Idist\build\autogen -Idist\build\Tests3\Tests3-tmp -optP-include -optPdist\bui ld\autogen\cabal_macros.h -odir dist\build\Tests3\Tests3-tmp -hidir dist\build\Tests3\Tests3-tmp -stubdir dist\build\Tes ts3\Tests3-tmp -package-id base-4.5.0.0-597748f6f53a7442bcae283373264bb6 -O -fhpc -hpcdir dist\hpc\mix\Tests3 -XHaskell9 8 .\Tests.hs }}} Here's the layout of the dist/hpc folder: {{{ dist\hpc\mix dist\hpc\mix\Simple-0.1.0.0 dist\hpc\mix\Simple-0.1.0.0\Simple-0.1.0.0 dist\hpc\mix\Simple-0.1.0.0\Simple-0.1.0.0\Library.mix dist\hpc\mix\Tests1 dist\hpc\mix\Tests1\Library.mix dist\hpc\mix\Tests1\Main.mix dist\hpc\mix\Tests2 dist\hpc\mix\Tests2\Library.mix dist\hpc\mix\Tests2\Main.mix dist\hpc\mix\Tests3 dist\hpc\mix\Tests3\Library.mix dist\hpc\mix\Tests3\Main.mix dist\hpc\tix dist\hpc\tix\Tests3 dist\hpc\tix\Tests3\Tests3.tix }}} The double nested "Simple-0.1.0.0" under mix may be another issue as well. A cabal project used to repro this issue is attached. </pre> Hackage 2012-05-21T06:08:07 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8984 <pre>#954: setup haddock fails for packages without modules ----------------------------+----------------------------------------------- Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- http://hackage.haskell.org/package/diagrams-0.5 is a meta-package, i.e. only depends on other packages. Running setup haddock fails: {{{ $ ./Setup haddock --hyperlink-source Running Haddock for diagrams-0.5... Running hscolour for diagrams-0.5... Preprocessing library diagrams-0.5... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library diagrams-0.5... haddock: No input file(s). }}} Not a big deal, but still a corner-case that could be fixed. </pre> Hackage 2012-05-20T15:43:01 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8983 <pre>I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, please brace yourself. </pre> Bryan O'Sullivan 2012-05-17T03:44:21 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8982 <pre>#953: Alex-generated Lexer isn't found when building test-suite ----------------------------+----------------------------------------------- Reporter: owst | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I'd like to use my Alex-generated lexer in my test-suite. I've tried adding other-modules/build-tools to my test-suite section, but upon building the Lexer module isn't found. I've got no problems using the lexer within my normal executable. Should I be able to use my Lexer in the test-suite? I'll attach a fairly minimal example, the Main module and the TestSuite module both use the Lexer, Main will compile, TestSuite won't: $ cabal configure --enable-tests $ cabal build [... blurb] Preprocessing test suite 'tests' for test-suite-with-alex-0.0... tests/TestSuite.hs:7:8: Could not find module `MyLexer' Perhaps you meant Lexer (needs flag -package ghc-7.4.1) Use -v to see a list of the files searched for. </pre> Hackage 2012-05-15T22:24:13 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8981 <pre>#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message, solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by guest): What about outputting all fails from the solver? Something that would behave similar to {{{ $ cabal install -v3 | grep fail }}} If this is too verbose as the default behavior, it might be good as one verbosity level. </pre> Hackage 2012-05-15T14:40:41 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8980 <pre>#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message, solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by kosmikus): It's really a question about which error message to choose. If you scan up in your log, you will see another "fail (backjumping ..." line before the one you've just shown. Currently, the solver tries backtracking to a limit, and if it fails, it will print the *first* error it encountered. This is based on the heuristic that usually, the first choices involve the least compromises, and are most likely to point to the actual problem. In this case, it actually points at a real problem (namely "transformers-3" being incompatible with your package), but that's not the main problem you're interested in. I do have something in mind that might fix this. I am planning to use the backtracking solver to generate several install plans and pick a "best" one according to heuristics. We could do the same for error messages. However, it's less clear to me how to define heuristics for what constitutes the best among several error messages. </pre> Hackage 2012-05-15T13:58:32 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8979 <pre>#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message, solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by guest): Thanks for answering! Sounds complicated. I guess, good error reporting for unsuccessful constraint solving is a big subject in its own right. BTW: Increased verbosity (-v3) results in a message containing this: {{{ [_39] fail (unknown package: bogus) [__0] fail (backjumping, conflict set: bogus, foo) }}} Which is what I would expect from cabal-install without increased verbosity. </pre> Hackage 2012-05-15T13:36:00 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8978 <pre>#952: cabal-install-0.14.0 dependencies are incorrect ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: kosmikus Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Apparently, we depend on transformers &gt;= 0.2.2.0 (indirectly via mtl). Should either adapt the code to work with older versions or fix the dependency. </pre> Hackage 2012-05-15T12:08:23 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8977 <pre>#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message, solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ Changes (by kosmikus): * keywords: message solver =&gt; message, solver * type: defect =&gt; enhancement * milestone: =&gt; cabal-install-0.16 Comment: Thanks for the report. I'm not sure what you would actually expect here. The solver has some freedom in which order to try to resolve the goals. And the problem it reports is the first problem it hits. The presence of the bogus dependency in this case prevents the solver from successfully backtracking. So yes, there's more than one problem in this case, and in general, it's difficult to judge which one's the one you want to hear about. If you remove the bogus dependency, it will still run into the problem you show above at first, but continue backtracking, and will ultimately find a solution (probably by picking an older version of transformers). So I agree that this might not be the error message you expect, and I see it as a valid enhancement request. But the error message given isn't "incorrect", and I unfortunately don't see a clear heuristics to apply here. </pre> Hackage 2012-05-15T12:05:15 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8976 <pre>#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ When the build-depends-field contains non-existing packages, cabal-install sometimes does not report that these packages could not be found but complains about other constraints being unsolvable. The attached cabal-file contains a dependency for a non-existing package called "bogus". This is what I get: {{{ $ cabal install --only-dependencies --dry-run Resolving dependencies... cabal: Could not resolve dependencies: next goal: foo (user goal) rejecting: foo-1.0 (global constraint requires ==0.1.0.0) trying: foo-0.1.0.0 trying: heist-0.8.0 (dependency of foo-0.1.0.0) trying: transformers-0.3.0.0 (dependency of heist-0.8.0) next goal: mtl (dependency of heist-0.8.0) rejecting: mtl-2.1.1, 2.1 (conflict: heist =&gt; mtl&gt;=2.0 &amp;&amp; &lt;2.1) rejecting: mtl-2.0.1.0, 2.0.0.0 (conflict: transformers==0.3.0.0, mtl =&gt; transformers==0.2.*) rejecting: mtl-1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (conflict: heist =&gt; mtl&gt;=2.0 &amp;&amp; &lt;2.1) }}} When removing "bogus" from the build-depends, cabal-install is able to come up with a working install plan. Used versions: {{{ $ cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library }}} </pre> Hackage 2012-05-15T11:43:42 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8975 <pre>#950: no dyn_o generated for C files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: dynamic objects Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When verifying a bug in GHC-7.5.20120510 I think I discovered a bug in Cabal-1.15.0 that is shipped with the nightly build of GHC. In the llvm-base package the C/C++ modules in the cbits directory are only compiled for the static version and the dynamic objects are not generated. This results in the compiler error: {{{ gcc: dist/build/cbits/extra.dyn_o: file not found gcc: dist/build/cbits/free.dyn_o: file not found gcc: dist/build/cbits/malloc.dyn_o: file not found gcc: dist/build/cbits/support.dyn_o: file not found }}} </pre> Hackage 2012-05-11T20:01:44 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8974 <pre>Hi folks - Some time next week, I am planning to import all open Cabal bugs into the github issue tracker. At that point, we should put the Trac issue tracker into read-only mode. Here's a preview of what the imported issues will look like: https://github.com/bos/test1/issues Most issue metadata is preserved, except for being able to attribute issues and their comments directly to users (github's API doesn't allow this). </pre> Bryan O'Sullivan 2012-05-11T07:55:31 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8973 <pre>#949: cabal should fail if compilation depends on a file not existing in the cabal file ---------------------------------+------------------------------------------ Reporter: LeventErkok | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Cabal doesn't complain if the build depends on a Haskell module that exists in the filesystem properly, but is not mentioned in the cabal file itself as part of "exposed-modules" or "other-modules". The build succeeds because ghc can find the relevant file just fine. I've got bitten by this several times, especially after pushing a package to hackage, only to get it fail to build on the server because I've failed to put the name of a file in the appropriate section of the cabal file, thus it didn't make it to the .tar.gz bundle that got uploaded to the server. I realize this might be hard to ensure, as it would require a deeper look into the dependencies between modules, but I trust the GHC API should have all the information necessary for cabal to complain appropriately. </pre> Hackage 2012-05-11T04:14:14 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8972 <pre> Andres and I discussed this the other day. I think our consensus was to use 'get' and to have that also work for tarballs (like the current 'unpack'). We didn't discuss in detail what a 'get' command would look like, e.g. how to say you want to get the scm version rather than the tarball version. Duncan </pre> Duncan Coutts 2012-05-07T19:17:43 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8971 <pre>#942: cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by refold): The same probably applies to `--disable-tests`. </pre> Hackage 2012-05-04T07:42:35 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/8970 <pre>#942: cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by creswick): This bit me because I do all my work in sandboxes, so the system-installed version of Cabal was 1.12 (which came with ghc-7.2.x, I think 1.14 is needed for --disable-benchmarks). cabal-installing Cabal-1.14.0 to my user-package db "fixed" the problem, because that cabal was then visible when building setup.hs; however, that's an unfortunate (and non-obvious) requirement. Explicitly specifying the build-dependencies for setup.hs would help with this, and other similar build failures enormously. I think cabal-install makes the (implicit?) assumption that whatever version of Cabal it was built with is available when it is building setup.hs. That's not a safe assumption any longer -- it would help enormously if we could actually control the environment that setup.hs is built in; as it has /nothing/ to do with the dependencies of the actual program that you're trying to compile. </pre> Hackage 2012-05-03T21:29:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.cabal.devel