March 2010 - cabal-devel

[Hackage] #570: Include distributions status on package page
by Hackage 19 Mar '10

19 Mar '10

#570: Include distributions status on package page --------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: patch Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Hi, I would find it very helpful if the package pages on hackage would include information as to which packages are available in distributions (Debian, arch, gentoo...). I have implemented a patch that reads this information from a simple formatted text and displays it. I have also implemented the generation of the list for Debian at http://people.debian.org/~nomeata/cabalDebianMap.txt, see README. A cronjob should fetch this regularly (maybe 4 times a day). To add distributions, you need to create the appropriate list (URLs are optional), add the distribution name to DistroMap.hs and put the lists in the right location. It would be great if this could be deployed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/570> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 23

[Hackage] #587: Get all of Hackage indexed by Google Code Search
by Hackage 19 Mar '10

19 Mar '10

#587: Get all of Hackage indexed by Google Code Search ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Google Code Search is a really nice (and fast!) way of browsing lots of code online. It would be cool if the whole of Hackage would be searchable from Code Search. One useful thing is to be able to find all mentions of a function in all packages on Hackage. Another good thing is to be able to find examples of how other people use libraries (i.e. use Code Search as a learning tool). What we need to make this work is to host and XML file (that we could regenerate N times daily) in a public location (e.g. http://hackage.haskell.org/sitemap.xml) Instructions on how to set it up: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=75224 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/587> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #526: hugs-options aren't passed to ffihugs
by Hackage 18 Mar '10

18 Mar '10

#526: hugs-options aren't passed to ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Options in hugs-options aren't passed through to ffihugs, most importantly -98 and +o are the ones we'd like to pass. For enabling the +o flag Hugs-Sept06 does not honor: * pragma {-# LANGUAGE !OverlappingInstances #-} * pragma {-# OPTIONS_HUGS +o #-} * cabal extensions: !OverlappingInstances And the -98 flag has similar issues. Therefore this is a real problem. Immediate solution: The options set in hugs-options should be passed to ffihugs as well. As of Cabal 1.6 they are not passed (verified by Duncan Coutts). The two programs accept all the same options, so this is valid. Ideal solution: Based on the extensions field, Cabal should automatically determine whether -98 and +o need to be enabled (for both hugs and ffihugs). A simple example demonstrating this bug can be found in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/526> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #527: CPP not called before ffihugs
by Hackage 18 Mar '10

18 Mar '10

#527: CPP not called before ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When building for Hugs, if CPP is being used in conjunction with FFI, then cpp/cpphs is not called before ffihugs is called. Thus, users must pass an -F flag to ffihugs in order to declare a code filter (and must pass all cpp-options to -F manually). For example: {{{ --ffihugs-option=-F'cpp -P -traditional -D__HUGS__ -D__BLAH__' }}} This requires duplicating the build specifications, which defeats the point of Cabal. Also it leads to tricky issues about ensuring the proper level of quoting/escaping. (e.g. using the plural, --ffihugs-options=..., breaks it. Wrapping the -F'cpp...' in double quotes breaks it.) A simple example of this bug can be seen in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/527> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #284: Cannot upload packages that require specific cabal versions
by Hackage 18 Mar '10

18 Mar '10

#284: Cannot upload packages that require specific cabal versions --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- I have a package that requires a custom Setup.lhs.The package works for ghc 6.8.x and 6.6.x and, thus, the Setup.lhs script was designed to work with Cabal 1.2.x, the one that comes with ghc 6.8.x. This is clearly indicated in the cabal-version field. However, if I try to upload this package to hackage I get this error: {{{ hint-0.2.0.1/hint.cabal: This package requires Cabal version: >=1.2&&<1.3 }}} As a workaround I used cabal-version: >= 1.2 but now, although the description explicitly says that it works with ghc 6.8.x, hackage indicates that it fails to build. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/284> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #626: Package build error due to unicode
by Hackage 18 Mar '10

18 Mar '10

#626: Package build error due to unicode --------------------------------+------------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- The following packages don't build on hackage due to the same error: * http://hackage.haskell.org/package/regions-0.3 * http://hackage.haskell.org/package/ftdi-0.1 The [http://hackage.haskell.org/packages/archive/regions/0.3/logs/failure/ghc-6.… log] contains the following error: {{{haddock: internal Haddock or GHC error: dist/doc/html/regions/regions.txt: commitAndReleaseBuffer: invalid argument (Invalid or incomplete multibyte or wide character)}}} I think the .txt file is generated because of the haddock {{{--hoogle}}} flag. '''Note that these package make heavy use of Unicode syntax and symbols.''' Note that {{{cabal haddock}}} works perferctly on my local system (tested with ghc-6.10.4 + haddock-2.5 + cabal-install-0.6.2 and ghc-6.12.1 + haddock-2.6.0 + cabal-install-0.8.0) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/626> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Document the "manual" attribute of flags
by Ian Lynagh 17 Mar '10

17 Mar '10

Wed Mar 17 13:37:44 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Document the "manual" attribute of flags M ./doc/Cabal.xml +15

1 0

patch applied (cabal): Tweak doc Makefile
by Ian Lynagh 17 Mar '10

17 Mar '10

Wed Mar 17 13:24:18 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Tweak doc Makefile M ./doc/Makefile -1 +5

1 0

[Hackage] #644: Equivalent of autoconf's --without-bla
by Hackage 17 Mar '10

17 Mar '10

#644: Equivalent of autoconf's --without-bla ----------------------------+----------------------------------------------- Reporter: Eelis | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a package comprising multiple executables. One of these is optional and has additional dependencies. Because the majority of my users will want to use this executable, I want to build it by default. However, users who do /not/ need it should have the option of turning off building of the executable (removing the need for the additional dependencies). My naive approach to accomplish this with Cabal is as follows: I first declare a flag corresponding to the executable, with a default value of true. I then use: executable theexecutable if flag(theflag) ... else buildable: False This almost does what I need. The problem is that when the user does /not/ have the dependencies needed for the executable, Cabal actually silently sets the flag to false and doesn't build the executable. I realize this is part of some clever backtracking/satisfiability scheme which is undoubtedly useful in certain cases, but in this case it just gets in the way and confuses the hell out of my users who end up missing the executable (because they lacked the additional dependencies). What I really want is for Cabal to keep its paws off this particular flag, so that if the user lacks the dependencies, they get an error (unless they manually unset the flag to inhibit building of the executable). In other words, all I really want is an equivalent of autoconf's --without-bla option. Surely this can't be too hard for Cabal? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/644> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #576: Show reverse dependencies
by Hackage 16 Mar '10

16 Mar '10

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide exmaples or documentation. It could be very helpful to look at packages which use the package on is interested in. This can be made easier if every package on http://hackage.haskell.org/ displays which other packages depend on it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5