- cabal-devel - Haskell.org

patch applied (cabal-branches/cabal-1.8): Bump version to 1.8.0.4
by Duncan Coutts 31 Mar '10

31 Mar '10

Wed Mar 31 04:52:30 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Bump version to 1.8.0.4 M ./Cabal.cabal -3 +3 M ./Makefile -3 +3

1 0

[Hackage] #650: cabal-install clueless of previously installed lib with custom package-db
by Hackage 28 Mar '10

28 Mar '10

#650: cabal-install clueless of previously installed lib with custom package-db ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ This bug was reported by a Debian user: {{{ This seems to happen for any library that carried dependencies, not just parallel/deepseq. lane@biped:~/src/test $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library lane@biped:~/src/test $ cabal update Downloading the latest package list from hackage.haskell.org lane@biped:~/src/test $ echo "[]" > my-package-db lane@biped:~/src/test $ cabal install parallel --package- db="/home/lane/src/test/my-package-db" --prefix="/home/lane/src/test/prefix/" Resolving dependencies... Downloading deepseq-1.1.0.0... Configuring deepseq-1.1.0.0... Preprocessing library deepseq-1.1.0.0... Building deepseq-1.1.0.0... [1 of 1] Compiling Control.DeepSeq ( Control/DeepSeq.hs, dist/build/Control/DeepSeq.o ) Registering deepseq-1.1.0.0... Installing library in /home/lane/src/test/prefix//lib/deepseq-1.1.0.0/ghc-6.12.1 Registering deepseq-1.1.0.0... Downloading parallel-2.2.0.1... Configuring parallel-2.2.0.1... Preprocessing library parallel-2.2.0.1... Building parallel-2.2.0.1... [1 of 2] Compiling Control.Parallel ( Control/Parallel.hs, dist/build/Control/Parallel.o ) [2 of 2] Compiling Control.Parallel.Strategies ( Control/Parallel/Strategies.hs, dist/build/Control/Parallel/Strategies.o ) Registering parallel-2.2.0.1... cabal: parallel-2.2.0.1: dependency "deepseq-1.1.0.0-14fbf43e1c607f21a1eab1783c9c45d4" doesn't exist (use --force to override) cabal: Error: some packages failed to install: parallel-2.2.0.1 failed during the building phase. The exception was: ExitFailure 1 }}} Was he doing something wrong, or is this a bug in cabal-install? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/650> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #645: cabal-install ignores --prefix
by Hackage 27 Mar '10

27 Mar '10

#645: cabal-install ignores --prefix ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ This is not a duplicate of #601. Installing a package with rm -rf ~/.ghc ~/.cabal cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'. I'll attach a toy project demonstrating this. System: sk@watarrka:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 sk@watarrka:~> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/645> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #532: Can't find libraries on Windows (Cabal 1.6.0.2)
by Hackage 27 Mar '10

27 Mar '10

#532: Can't find libraries on Windows (Cabal 1.6.0.2) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- When trying to install the com-1.2.2 package from the Hackage tarball, configure reports that it cannot find the header file "include/WideStringSrc.h", which is part of the com-1.2.2 source, and is clearly there; and that it cannot find the libraries "kernel32", "user32", etc which are standard system libraries (the corresponding .lib files are part of the Platform SDK), even after giving it the library paths in every possible way (environment variable, command line option, modifying the "com.cabal" file). The former problem was mysteriously eliminated by some random modification of the .cabal file (namely, rearranging the order of the includes). The OS is Windows XP (servicepack 2). Everything works fine with Cabal 1.6.0.1. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/532> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #648: Cabal incorrectly reports missing C library IL
by Hackage 27 Mar '10

27 Mar '10

#648: Cabal incorrectly reports missing C library IL ----------------------------+----------------------------------------------- Reporter: GregoryWeber | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- This problem occurs with Cabal version 1.8.0.2 on Arch Linux (this version number does not appear in the Version selector, so I have left it at 1.6.0.1) and ghc version 6.12.1. Trying to install Codec-Image-DevIL, either version 0.1 or 0.2.0, 'runghc Setup configure' produces a misleading error message: $ runghc Setup configure Configuring Codec-Image-DevIL-0.2.0... Setup: Missing dependency on a foreign library: * Missing C library: IL This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. The error message "Missing C library: IL" is incorrect: the Arch 'devil' package is installed, and the include and library files are present in the normal locations: $ pacman -Q devil devil 1.7.8-6 $ ls /usr/include/IL devil_cpp_wrapper.hpp il.h ilu.h ilu_region.h ilut.h $ ls /usr/lib/*IL* /usr/lib/libIL.a /usr/lib/libILU.a /usr/lib/libILUT.a /usr/lib/libIL.so@ /usr/lib/libILU.so@ /usr/lib/libILUT.so@ /usr/lib/libIL.so.1@ /usr/lib/libILU.so.1@ /usr/lib/libILUT.so.1@ /usr/lib/libIL.so.1.1.0* /usr/lib/libILU.so.1.1.0* /usr/lib/libILUT.so.1.1.0* There does seem to be an error in Codec-Image-DevIL.cabal: where it says Extra-Libraries: IL it should say any of the following (take your choice, all of them work): Extra-Libraries: IL, pthread Extra-Libraries: IL, rt Extra-Libraries: IL, pthread, rt It seems that using the IL library in a C program requires linking with -lrt or -pthread in addition to -lIL. I have the impression that in the configuration step, when Cabal sees the line Extra-Libraries: IL it writes a small C program that tries to include that library, and reports the library is missing if there's an error in compiling and linking the C program. Maybe Cabal needs to interpret the C compiler's and linker's error messages more carefully. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/648> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #646: cabal-install does not install data-files
by Hackage 27 Mar '10

27 Mar '10

#646: cabal-install does not install data-files ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ Installing a package with {{{ cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install }}} does not copy the data-files listed in the project.cabal file to the desired destination. It does not copy them anywhere at all. I would expect them to end below something like {{{/home/sk/opt/share/project-0.1}}}, as is reported by function {{{Paths_project.getDataFileName}}}. I'll attach a toy project demonstrating this. System: {{{ sk@watarrka:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 sk@watarrka:~> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/646> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Remove an out-of-date comment
by Ian Lynagh 27 Mar '10

27 Mar '10

Fri Mar 26 06:17:52 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Remove an out-of-date comment M ./Distribution/ModuleName.hs -2

1 0

[Hackage] #649: better warning messages for why dependencies are missing / cannot be selected
by Hackage 26 Mar '10

26 Mar '10

#649: better warning messages for why dependencies are missing / cannot be selected ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The cabal-install constraint solver should be given all packages but if some are unsable (e.g. due to broken dependencies) then it should be given constraints to avoid them. That way when it finds it needed the broken package it can give a suitable error message. Consider the following (real) confusing scenario: * usual core global packages * mtl as user package * gtk etc in a local package db `ghc-pkg list --global -f local gtk` reports that gtk is installed and deps are ok. `cabal install --global --package-db=local hsclock` reports {{{ cabal: cannot configure hsclock-1.0. It requires cairo -any and gtk -any There is no available version of cairo that satisfies -any There is no available version of gtk that satisfies -any }}} How can this be? It is because when we use --global and --package-db then we are excluding the user package db. But gtk depends on mtl from the user package db. Hence Cabal detects gtk as broken. We did not notice because `ghc-pkg --global` still includes the `--user` package db. If we use `ghc- pkg --global --no-user-package-conf -f local list` then indeed gtk etc are reported as broken. The point is, cabal should tell us not that gtk isn't installed, but that it was excluded because it is broken, missing dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/649> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Gtk2hs-devel] cabalized Gtk2Hs
by Duncan Coutts 26 Mar '10

26 Mar '10

On Sat, 2010-03-13 at 18:31 +0100, Axel Simon wrote: > Dear all, > > this is a first announcement of cabal packages for Gtk2Hs. This is > meant for all those who can spare five minutes to check the packages > and to improve them. This is great Axel. I'm glad you've taken this on (and a bit sorry I never got round to it). Can you let us know what annoyances you've hit in Cabal, so we can make sure they are all filed properly in the Cabal trac and so we can prioritise them appropriately. I expect your main problems are with .chs and .chi files. Both the fact that there is no proper dependency tracking, and the fact that .chi files from one package are not installed, yet needed when processing other packages (how do you get around that btw?). Another thing that I bet is annoying is that cabal-install isn't great for building local collections of interdependent packages. One wants a feature to be able to tell cabal that there are several locally unpacked packages (ie the gtk2hs source tree, one package per subdir) and have cabal build them in order. Similarly, once you've generated tarballs for each package, cabal isn't yet able to easily be told to install a bunch of tarballs and do dep-tracking. I have plans to make cabal-install accept more notions of package, not just the local dir and package names from hackage but also specific dir(s) or specific tarballs. On the "gtk2hs-buildtools" front, that seems like a reasonably way to go. I hope we can pull the c2hs fork out of that at some point however and use the mainline c2hs (even if initially that involves putting some of the gtk2hs syntax quirks into mainline c2hs while gtk2hs migrates to the standard syntax -- or new agreed syntax). Duncan

1 0

patch applied (cabal-branches/cabal-1.8): Fix a duplicate import
by Ian Lynagh 26 Mar '10

26 Mar '10

Thu Mar 25 13:44:20 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Fix a duplicate import M ./Distribution/Simple/Register.hs -1 +1

1 0