December 2009 - cabal-devel

patch applied (cabal-install): Distribution/Client/Haddock.hs: removed redundant instances
by Duncan Coutts 22 Dec '09

22 Dec '09

Sun Dec 20 13:37:57 PST 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Haddock.hs: removed redundant instances Ignore-this: efffb1cd16256496f70314cce6001c6f M ./Distribution/Client/Haddock.hs -3 +3 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20091220213757-6895e-…

1 0

patch applied (cabal-install): Distribution/Client/BuildReports/Anonymous.hs: removed unused import of BuildResult
by Duncan Coutts 22 Dec '09

22 Dec '09

Sun Dec 20 13:33:50 PST 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/BuildReports/Anonymous.hs: removed unused import of BuildResult Ignore-this: 50c449c43df34ceb1b13c61788bb0758 M ./Distribution/Client/BuildReports/Anonymous.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20091220213350-6895e-…

1 0

patch applied (cabal-install): Distribution/Client/IndexUtils.hs: fixed warning on -Wall (unused result)
by Duncan Coutts 22 Dec '09

22 Dec '09

Sun Dec 20 13:19:40 PST 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/IndexUtils.hs: fixed warning on -Wall (unused result) Ignore-this: a74aded9f99237229dbfe762fcf20478 M ./Distribution/Client/IndexUtils.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20091220211940-6895e-…

1 0

patch applied (cabal-install): Distribution/Client/SrcDist.hs: fixed warning on -Wall (unused result)
by Duncan Coutts 22 Dec '09

22 Dec '09

Sun Dec 20 13:17:17 PST 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/SrcDist.hs: fixed warning on -Wall (unused result) Ignore-this: d7d4fade7b5e5464d114995efdabb216 M ./Distribution/Client/SrcDist.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20091220211717-6895e-…

1 0

[Hackage] #620: Cabal-1.8.0.2 doesn't build on x86_64, GHC 6.10.4
by Hackage 22 Dec '09

22 Dec '09

#620: Cabal-1.8.0.2 doesn't build on x86_64, GHC 6.10.4 -----------------------------+---------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -----------------------------+---------------------------------------------- {{{ $ cabal install 'Cabal >= 0.8' }}} ... {{{ Linking /tmp/Cabal-1.8.0.214524/Cabal-1.8.0.2/dist/setup/setup ... /usr/local/lib/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_d_name': PrelIOUtils.c:(.text+0x1c0): multiple definition of `__hscore_d_name' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x0): first defined here /usr/local/lib/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_free_dirent': PrelIOUtils.c:(.text+0x4f0): multiple definition of `__hscore_free_dirent' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x10): first defined here /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk63_info': (.text+0x30c4): undefined reference to `fcntl_read' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk6A_info': (.text+0x31f0): undefined reference to `fcntl_write' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk8h_info': (.text+0x36cc): undefined reference to `fcntl_read' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl4O_info': (.text+0x3a52): undefined reference to `fcntl_lock' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl6S_info': (.text+0x3cc2): undefined reference to `fcntl_lock' /home/ashley/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl9I_info': (.text+0x402a): undefined reference to `fcntl_lock' collect2: ld returned 1 exit status cabal: Error: some packages failed to install: Cabal-1.8.0.2 failed during the configure step. The exception was: exit: ExitFailure 1 }}} {{{ $ uname -a Linux glastonbury 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/620> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #299: Add changelog feature to hackagedb
by Hackage 22 Dec '09

22 Dec '09

#299: Add changelog feature to hackagedb --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- It would be great if releases on hackagedb were required (or even permitted) to include short descriptions of the changes made since the last release. Currently there is no easy way to get this information for most packages, since many packages have no home page other than their hackagedb page. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/299> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

Template Haskell in cabal-install
by Mikhail Glushenkov 21 Dec '09

21 Dec '09

Hi, Would it be worthwile to reimplement Distribution/Client/Init/Licenses.hs using a TH macro that parses and loads license files at compile time? IIUC, currently one has to use a Perl script to add new licenses. Pros: easier to add new licenses Cons: dependency on TH -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 2

darcs patch: Distribution/Client/SrcDist.hs: fixed wa... (and 10 more)
by Sergei Trofimovich 21 Dec '09

21 Dec '09

Sun Dec 20 23:17:17 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/SrcDist.hs: fixed warning on -Wall (unused result) Sun Dec 20 23:19:40 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/IndexUtils.hs: fixed warning on -Wall (unused result) Sun Dec 20 23:32:35 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Dependency/TopDown.hs: commented out unused 'addPackageExcludeConstraint' Sun Dec 20 23:33:50 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/BuildReports/Anonymous.hs: removed unused import of BuildResult Sun Dec 20 23:35:30 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/BuildReports/Upload.hs: marked result as unused Sun Dec 20 23:37:57 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Haddock.hs: removed redundant instances Sun Dec 20 23:43:46 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/BuildReports/Storage.hs: removed double import if InstallPlan Sun Dec 20 23:44:48 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Setup.hs: suppress warning (unused variable) Sun Dec 20 23:45:45 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Unpack.hs: removed redundant import Sun Dec 20 23:55:08 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/Install.hs: removed unused 'compilerTemplateEnv' from import Mon Dec 21 00:01:05 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * Distribution/Client/InstallSymlink.hs: explicitely import 'catch' and friend tom System.IO

2 3

Re: cabal-install-0.8 final testing
by Duncan Coutts 21 Dec '09

21 Dec '09

On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote: > Hi Duncan, > > Installation was easy (I typed "cabal-install HTTP zlib > cabal-install" ;-). Thanks for testing it. I've uploaded it to hackage. > Overall, seems to work fine. I couldn't build darcs, but I couldn't do > that by hand either; I used their binary installer. I don't think they > build yet under GHC 6.12.1. > > One oddity, I tried to use cabal install to install mmap, and it > failed because the HUnit package was missing. I then installed HUnit > without incident, went back and installed mmap without incident. No > idea why this didn't work in one pass, but I have "sandbox" systems if > you'd like me to see if I can reliably reproduce this. Mm. This is a worse bug than I thought. It's not trivial to fix. I'll have to think about it. The problem is mmap uses: Executable mmaptest Main-is: tests/mmaptest.hs if flag(mmaptest) Buildable: True else Buildable: False Build-depends: base<5, bytestring, HUnit, directory Now the question is what does this mean exactly. The previous version of Cabal said essentially "well the executable needs HUnit thus the package needs HUnit". This despite the fact that we're not going to actually built this test executable! The current Cabal code takes a slightly different approach. It says at the end "oh this exe isn't buildable, so its deps do not contribute to the deps of the package". The problem is what it was doing before that. It sees the dependency on HUnit and checks that it can be satisfied. It's only at the end that it ends up discarding it. So if it was not actually available then it fails earlier. The reason it's then inconsistent between configuring a package and what the cabal install planner is doing is that the planner assumes all the packages on hackage are available (sort of) while when we get to actually configuring a package to install it, only the other installed packages are available. So that's why the same solver gives us different answers, because we're making different assumptions about the available packages. So the issue is we need to treat "Buildable: False" specially in the solver because if we end up picking a configuration with "Buildable: False" for a component then have to have not already required the dependencies for that component. Essentially we want to reinterpret it as something like: if flag(test) Buildable: True Build-depends: base<5, bytestring, HUnit, directory else Buildable: False So that the dependencies themselves are conditional on the component being buildable. Then the solver would do the right thing. In general I guess the transformation would look like: if A1 Buildable: False if A2 Buildable: False ... if B1 Build-depends: blah if B2 Build-depends: blah where A1,A2,... and B1,B2,... are arbitrary conditions (including none) then this becomes: if A1 Buildable: False if A2 Buildable: False ... if B1 && ! (A1 || A2 || ...) Build-depends: blah if B2 && ! (A1 || A2 || ...) Build-depends: blah ... I don't especially like this though. It makes the meaning of buildable rather magic. In the short term I may have to revert the change in behaviour so that these dependencies become unconditional again, even though they're not used. Sigh. Duncan

2 2

[Hackage] #619: Add support for package logo's
by Hackage 21 Dec '09

21 Dec '09

#619: Add support for package logo's ----------------------------------+----------------------------------------- Reporter: basvandijk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------------+----------------------------------------- It would be nice if it was possible to associate a logo with a package. The advantage of a logo compared to just a textual name is that it aids in the instant recognition of a package. Humans are faster at pattern matching graphics than text (TODO: add rigorous scientific proof for this statement ;-) ) Once a logo has been associated with a package it can be used in the hackage page of a package and it can be used in graphical package installers. Design questions: 1. How to associate a logo with a package? Probably best to add a logo field to the cabal file, as in: "Logo: mylogo.png". (The logo filepath should be relative to the location of the cabal file.) 2. Should there be restrictions on the logo file? 1. What should be the allowed logo formats? png, svg, etc. It's probably best to restrict them to open formats. 2. Should there be a restriction on the logo width and height? Maybe we need support for multiple sized logo's: a big one to put on the hackage page and a small one to display in package lists. (Maybe we even need support for favicons) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/619> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0