- cabal-devel - Haskell.org

Re: [Hackage] #134: Clean up hooks
by Hackage 19 Jan '09

19 Jan '09

#134: Clean up hooks ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: Cabal-2.0 Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: very hard (<1 week) Ghcversion: 6.4.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * priority: high => normal -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/134#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #449: Report bugs via cabal-install
by Hackage 19 Jan '09

19 Jan '09

#449: Report bugs via cabal-install ---------------------------------+------------------------------------------ Reporter: Peaker | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ It would be great if once I found a bug and/or a means to fix that bug, I could report it uniformly, rather than go to the homepage of the specific package and hope that they have a trac site. cabal report <packagename> [-f<attachfile>] [-f<anotherfile>] <Bug information> Perhaps a new field can be added to each package: "Report mail recipient" or "Report website" into which these bug reports will go. Alternatively, if no such field exists, it could go to a default bug mailing list or such. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/449> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-install): Add initial implementation of cabal info
by Duncan Coutts 19 Jan '09

19 Jan '09

Sun Jan 18 18:52:02 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Add initial implementation of cabal info It provides more detailed information on a particular package. Still a few TODOs. Fixes #361, #449 and #456. M ./Distribution/Client/List.hs -40 +184 M ./Distribution/Client/Setup.hs -12 +34 M ./Main.hs -1 +19 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090119025202-adfee-…

1 0

[Hackage] #461: "ghc-options: -O0" causes upload error; blocks xmonad-contrib release
by Hackage 18 Jan '09

18 Jan '09

#461: "ghc-options: -O0" causes upload error; blocks xmonad-contrib release --------------------------------+------------------------------------------- Reporter: sjanssen | Owner: Type: defect | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- When attempting to upload [http://code.haskell.org/~sjanssen/xmonad- contrib-0.8.1.tar.gz xmonad-contrib-0.8.1] to Hackage: {{{ 400 Error in upload 'ghc-options: -O0' is not needed. Use the --disable-optimization configure flag. }}} xmonad-contrib.cabal has the following: {{{ if impl (ghc >= 6.10.1) && arch (x86_64) ghc-options: -O0 }}} This is a workaround for GHC bug http://hackage.haskell.org/trac/ghc/ticket/2961 . If we do not disable optimizations on x86_64 and GHC 6.10.1, our users experience lockups and crashes. This is rather critical for us, as we are now unable to release a stable version of xmonad. This error should be changed to a strong warning -- sometimes the package author really does know better than the package manager. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/461> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

patch applied (cabal-branches/cabal-1.6): Make 'ghc-options: -O0' a warning rather than an error
by Duncan Coutts 18 Jan '09

18 Jan '09

Sun Jan 18 06:19:49 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Make 'ghc-options: -O0' a warning rather than an error M ./Distribution/PackageDescription/Check.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2009011814…

1 0

patch applied (cabal-branches/cabal-1.6): Improve runE parse error message
by Duncan Coutts 18 Jan '09

18 Jan '09

Fri Jan 16 05:32:14 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Improve runE parse error message Only really used in parsing config files derived from command line flags. M ./Distribution/ParseUtils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2009011613…

1 0

patch applied (cabal): Make 'ghc-options: -O0' a warning rather than an error
by Duncan Coutts 18 Jan '09

18 Jan '09

Sun Jan 18 06:19:49 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Make 'ghc-options: -O0' a warning rather than an error M ./Distribution/PackageDescription/Check.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090118141949-adfee-1bd11839…

1 0

patch applied (cabal): Improve runE parse error message
by Duncan Coutts 18 Jan '09

18 Jan '09

Fri Jan 16 05:32:14 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Improve runE parse error message Only really used in parsing config files derived from command line flags. M ./Distribution/ParseUtils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090116133214-adfee-65f8f9f2…

1 0

[Hackage] #447: do parallel builds
by Hackage 18 Jan '09

18 Jan '09

#447: do parallel builds ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ The latest version of the gentoo portage tool is rather slick. It can do parallel builds and it displays a nice summary on the command line, eg: {{{ # emerge -uD system -j --load-average=4.5 Calculating dependencies... done! >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 14) dev-libs/expat-2.0.1-r1 >>> Emerging (2 of 14) sys-devel/autoconf-wrapper-6 >>> Emerging (3 of 14) sys-kernel/linux-headers-2.6.27-r2 >>> Installing sys-devel/autoconf-wrapper-6 >>> Jobs: 0 of 14 complete, 1 running Load avg: 2.99, 1.59, 0.67 }}} Note how they solve the problem of how to display what is going on when there are multiple builds happening. The answer is not to display it at all! This would have to go hand-in-hand with logging all builds so that we can still diagnose failures. Note the final line, that gets updated to display the current number of jobs running, the number completed etc. It also shows the load average. The job scheduler has two parameters, one is a maximum number of jobs (or unlimited) and the other is a load average. It will only launch new jobs if the load average is less than the given maximum. That allows it to interact reasonably well with builds that use `make -j` internally. In the example above I set the load average to be just slightly more than the number of CPUs I've got. It looks to me like it serialises some bits, like installing, since saturating the disk with multiple parallel installs is generally of no benefit, indeed it can be slower. Also downloads seem to be serialised, again because there is probably little benefit to making multiple connections to the same server. Anyway, the point is, cabal-install ought to be able to do all this. Some bits we can do now. We already have a graph representation of the install plan and we recalculate when a package fails to install. We will need an improved download api, probably involving sending requests off to a dedicated download thread (which would serialise them). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/447> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

4 7

Cabal 2.0
by Duncan Coutts 17 Jan '09

17 Jan '09

All, I've started a wiki page to collect ideas for Cabal 2 http://hackage.haskell.org/trac/hackage/wiki/Cabal-2 The basic idea for Cabal 2 is to learn lessons from our how the existing design has fared and how we can make a better design to tackle an expanded set of goals. I'd like the page to be about suggested design concepts. I don't want to fill it with "wouldn't it be nice if we had a feature to help me doing ..." I guess it would also be useful to make links on that page to some of the discussions we've had on various lists, eg on the ghc users and libraries mailing lists where various people have made criticisms of the current design and suggested alternatives and improvements. Duncan

1 0