- cabal-devel - Haskell.org

patch applied (cabal): Do the check for foreign libs after running configure
by Duncan Coutts 31 Jan '09

31 Jan '09

Sat Jan 31 10:22:13 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Do the check for foreign libs after running configure This lets us pick up build info discovered by the ./configure script M ./Distribution/Simple.hs -13 +35 M ./Distribution/Simple/Configure.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090131182213-adfee-61a8d55e…

1 0

patch applied (cabal): move imports outside ifdef GHC
by Ross Paterson 30 Jan '09

30 Jan '09

Fri Jan 30 07:35:05 PST 2009 Ross Paterson <ross(a)soi.city.ac.uk> * move imports outside ifdef GHC M ./Distribution/Compat/CopyFile.hs -3 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090130153505-b47d3-6f196a88…

1 0

patch applied (cabal): Document most of the new file utility functions
by Duncan Coutts 30 Jan '09

30 Jan '09

Fri Jan 30 07:16:40 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Document most of the new file utility functions M ./Distribution/Simple/Utils.hs -7 +70 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090130151640-adfee-789783fa…

1 0

patch applied (cabal): #262 iterative tests for foreign dependencies
by Duncan Coutts 30 Jan '09

30 Jan '09

Fri Jan 30 04:02:28 PST 2009 Gleb Alexeyev <gleb.alexeev(a)gmail.com> * #262 iterative tests for foreign dependencies Optimize for succesful case. First try all libs and includes in one command, proceed with further tests only if the first test fails. The same goes for libs and headers: look for an offending one only when overall test fails. M ./Distribution/Simple/Configure.hs -15 +48 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090130120228-667a8-421ede83…

1 0

darcs patch: #262 iterative tests for foreign dependencies
by Gleb Alexeyev 30 Jan '09

30 Jan '09

Fri Jan 30 14:02:28 EET 2009 Gleb Alexeyev <gleb.alexeev(a)gmail.com> * #262 iterative tests for foreign dependencies Optimize for succesful case. First try all libs and includes in one command, proceed with further tests only if the first test fails. The same goes for libs and headers: look for an offending one only when overall test fails.

1 0

[Hackage] #480: "cabal list" fails after "cabal update"
by Hackage 30 Jan '09

30 Jan '09

#480: "cabal list" fails after "cabal update" ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.3 Platform: Mac OS | ----------------------------+----------------------------------------------- I've got cabal-install version 0.5.2 and Cabal version 1.4.0.2. After doing a "cabal update", "cabal list" fails with the following error: {{{ ... * GeoIp Latest version available: 0.3 Category: Network Synopsis: Pure bindings for the MaxMind IP database. License: OtherLicense cabal: Couldn't read cabal file "./Glob/0.1/Glob.cabal" }}} I looked at some version numbers, and it ''seems'' like some version of GeoIp is confusing the tools. On another machine (Arch Linux, not Mac OSX) I built a new 1.6.0.1, did "cabal update" and then "cabal list" and it worked fine. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/480> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #454: file permissions of executable on vista
by Hackage 30 Jan '09

30 Jan '09

#454: file permissions of executable on vista ----------------------------+----------------------------------------------- Reporter: Toxaris | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: Windows | ----------------------------+----------------------------------------------- When installing a binary on Windows Vista using ghc 6.10.1 and Cabal 1.6.0.1, it is not accessible for ordinary users. Old binaries installed with ghc 6.8.2 and Cabal 1.4 had "read" and "execute" permissions set for "all users", while new binaries have only permissions set for "administrators". Cabal should set "read" and "execute" permissions for "all users" for binaries. A workaround is to manually set these permissions using the executable's properties dialog. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/454> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 30 Jan '09

30 Jan '09

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Fixed in cabal head and the 1.6 branch. The behavior now when installing is that we ignore the permissions the files had in the build tree and the user's umask. We explicitly set permissions for all files we install. The only inconsistency is that we're not yet setting the permissions of directories we create when installing. So they currently inherit the umask of the installing user. In the case in this bug that will work fine. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: Bug in Cabal?
by Duncan Coutts 29 Jan '09

29 Jan '09

On Wed, 2009-01-28 at 13:13 +0000, Duncan Coutts wrote: > The solution I think, is never to copy the read-only attribute when > installing files. It's thoroughly unhelpful. I've got a patch to do this > which I shall push to Cabal HEAD shortly. If you have a moment to help > me test that it would be much appreciated. I've attached a darcs patch against the Cabal-1.6 branch (rather than the head branch). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.6/ If you or anyone else can test it on Windows that'd be great. I checked it by setting the read-only attribute on a LICENSE file and where previously the attribute would get copied (preventing further re-installs) it is now not copied. On Unix it should solve this problem: http://hackage.haskell.org/trac/hackage/ticket/93 Though I've not tested that yet. The patch for the 1.6 branch is fairly minimal and doesn't change any API. In Cabal HEAD I'll do it slightly differently so that the code is more consistent and comprehensible, but it involves api changes to exposed utility functions. Duncan

1 1

patch applied (cabal-branches/cabal-1.6): Make the Compat.CopyFile module with with old and new ghc
by Duncan Coutts 29 Jan '09

29 Jan '09

Thu Jan 29 14:54:23 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Make the Compat.CopyFile module with with old and new ghc M ./Distribution/Compat/CopyFile.hs -9 +26 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2009012922…

1 0