[Hackage] #955: Incorrect hpcdir during cabal test for testsuites w/ library coverage enabled

#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>
 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>

[Hackage] #954: setup haddock fails for packages without modules

#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.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/954>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

Heads up: importing the Cabal issue tracker to github next week

[Hackage] #953: Alex-generated Lexer isn't found when building test-suite

#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.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/953>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

[Hackage] #952: cabal-install-0.14.0 dependencies are incorrect

#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 >= 0.2.2.0 (indirectly via mtl).

 Should either adapt the code to work with older versions or fix the
 dependency.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/952>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

[Hackage] #951: Incorrect error messages for non-existing dependencies

#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 => mtl>=2.0 && <2.1)
 rejecting: mtl-2.0.1.0, 2.0.0.0 (conflict: transformers==0.3.0.0, mtl =>
 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 => mtl>=2.0 && <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
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/951>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

[Hackage] #950: no dyn_o generated for C files

#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
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/950>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

Heads up - moving the bug tracker to github

[Hackage] #949: cabal should fail if compilation depends on a file not existing in the cabal file

#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.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/949>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

Re: cabal/pull/2

On Fri, 2012-05-04 at 21:50 +0200, Tuncer Ayaz wrote:
> Hi guys,
> 
> wrt https://github.com/haskell/cabal/pull/2 , I didn't comment there
> as there seems to be a consensus on "fork".
> 
> Still, I'd like to question that decision given that "fork" for me
> at least carries too much of a "publish an alternative version
> with changes" meaning.
> 
> Would fetch or checkout or grab or fetch-scm or something
> not be more precise terminology wise?

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

Darcs home page updated

With 2.8 released, I felt Darcs deserves better presentation. After surveying other VCS sites I worked on
an update to 
our home page layout and content over the last few days, with review and input from #darcs, and it went live
last night. 
It's far from perfect but I hope it's a good step forward. Thanks for the input, and have at it:

http://darcs.net

-Simon