March 2009 - cabal-devel

[Hackage] #528: Permissions on "cabal fetch" files too tight
by Hackage 21 Mar '09

21 Mar '09

#528: Permissions on "cabal fetch" files too tight ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ 13:54 <twb> Why has cabal seemingly ignored my umask and made files in /home/twb/.cabal/packages unreadable by the "nobody" user? 00:14 <dcoutts> ah, I think I know 00:14 <dcoutts> it's the writeFileAtomic function 00:14 <dcoutts> are you using Cabal HEAD or 1.6? 00:15 <twb> whatever cabal upgrade gave me, I think 00:15 <dcoutts> we create a temp file and rename it over the dest 00:15 <twb> Probably not HEAD 00:15 <dcoutts> but the System.Directory function to create a temp file makes it readable only by the current user 00:16 <dcoutts> file a ticket, so we don't forget -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/528> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #451: dependency not listed on the hackageDB page
by Hackage 17 Mar '09

17 Mar '09

#451: dependency not listed on the hackageDB page --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- The haskeline-0.6 package uses the terminfo package by default on POSIX systems. However, the hackageDB page for haskeline does not list terminfo as a possible dependency: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/haskeline-0.5.0.1 -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/451> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #266: cabal haddock plus cpp preprocessing with relative #include files
by Hackage 17 Mar '09

17 Mar '09

#266: cabal haddock plus cpp preprocessing with relative #include files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Duncan says: Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/266> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #188: file extensions
by Hackage 16 Mar '09

16 Mar '09

#188: file extensions --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | --------------------------+------------------------------------------------- GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

problem in documentation generation
by Jean-Philippe Bernardy 16 Mar '09

16 Mar '09

Hi, If a library depends on the auto-generated Paths module, cabal cannot generate the documentation: eg. Preprocessing library yi-0.6.1... Preprocessing executables for yi-0.6.1... cabal: can't find source for module Paths_yi I looked for a ticket about this but could not find anything. Is there work being done about this? Is there a workaround? Thanks, JP.

1 1

[Hackage] #524: support file, directory and url targets for packages and .cabal files
by Hackage 16 Mar '09

16 Mar '09

#524: support file, directory and url targets for packages and .cabal files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently the `cabal` program supports two ways to specify a package. One is implicitly to look in the current directory for a .cabal file. The other is a package name (actually a dependency) which we look for in the current set of repositories. We can imagine adding more. We could: * specify the file name of a .cabal file, eg to target an unpacked package in another directory * specify the directory name and look in that directory for a .cabal file * specify the file name or url of a `.tar.gz` package For example: {{{ cabal list ../some/other/dir/ cabal info http://code.haskell.org/xmonad/xmonad.cabal cabal install http://haskell.org/cabal/dev/Cabal-1.7.2.tar.gz cabal install ./demo/ }}} The case `cabal info http://code.haskell.org/xmonad/xmonad.cabal` is very much like the `lscabal` program that was uploaded to hackage recently so apparently it is useful. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/524> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Clarify the instructions in the README and bootstrap.sh
by Duncan Coutts 15 Mar '09

15 Mar '09

Sun Mar 15 05:54:07 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Clarify the instructions in the README and bootstrap.sh Addresses the complaint in ticket #523. M ./README -7 +27 M ./bootstrap.sh -4 +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090315125407-adfee-…

1 0

[Hackage] #523: Config file not automatically generated if symlink-bindir is only item in config
by Hackage 15 Mar '09

15 Mar '09

#523: Config file not automatically generated if symlink-bindir is only item in config ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: minor | Keywords: config Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I just spent an hour trying to make cabal-install work. After reading the README, I specified the symlink-bindir in the config file. The file did not exist so I created it. Then, when I executed an update, cabal complained that there was no specified repos. I searched and could not find what variable I needed to define in the config file. Then, after skimming the cabal source code, I noticed that the config file is automatically generated if it does not exist. So I deleted it and now all is fine because it was automatically generated. So by following the README instructions by specifying a symlink-bindir variable in a config file I created, I was unable to make cabal work. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/523> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #522: Nicer error message when source files are not found.
by Hackage 13 Mar '09

13 Mar '09

#522: Nicer error message when source files are not found. ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- It can be confusing sometimes when source files are not found. Eg: {{{ $ runhaskell Setup.lhs build Preprocessing executables for nm8-0.1... Setup.lhs: can't find source for Data.MaybeI in src, dist/build/autogen $ find src/ | grep Data src//Data src//Data/MabyeI.hs }}} In this case it's simply a spelling error, but it's still hard to spot initially. The suggestion is to look look at all files in that directory and do an edit distance match and suggest any similar file. This would also help for case-sensitivity mistakes, see #521. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/522> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #521: Check that module names match file names case-sensitively on Windows
by Hackage 13 Mar '09

13 Mar '09

#521: Check that module names match file names case-sensitively on Windows ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: Windows | ------------------------------+--------------------------------------------- It's possible to specify a module name like `Foo.Bar` but have ghc actually find `foo/Bar.hs` or something. This is ok for local use but we should warn or reject it for distributed packages. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/521> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0