- cabal-devel - Haskell.org

patch applied (cabal-install): Remove unused var
by Duncan Coutts 15 Jan '08

15 Jan '08

Tue Jan 15 07:08:38 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Remove unused var M ./Hackage/Install.hs -1 +1

1 0

patch applied (cabal-install): Use commandDefaultFlags = mempty rather than commandAddActionWithEmptyFlags
by Duncan Coutts 15 Jan '08

15 Jan '08

Tue Jan 15 07:07:25 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use commandDefaultFlags = mempty rather than commandAddActionWithEmptyFlags Simpler and simplifies the Command api in the Cabal lib M ./Hackage/Setup.hs -4 +6 M ./Main.hs -2 +2

1 0

Re: [Hackage] #88: Stripping
by Hackage 15 Jan '08

15 Jan '08

#88: Stripping ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): It seems that we cannot portably strip .a files. On solaris doing so removes the symbol index which is required for linking: {{{ If strip is executed on a common archive file (see ar(3HEAD)) in addition to processing the members, strip will remove the archive symbol table. The archive symbol table must be restored by executing the ar(1) command with the -s option before the archive can be linked by the ld(1) com- mand. strip will produce appropriate warning messages when this situation arises. }}} With GNU strip it seems to be ok and only remove stuff from within the individual .o files within the .a archive. The `install` program that automake uses only seems to strip binary executables, not library archives so we should probably do the same. If you think otherwise then complain now. So I suggest we only strip on installation, that we do it by default and add an install flag to turn it off (eg some distro packaging systems prefer to manage striping themselves). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/88#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #58: darcs integration idea: track location of darcs repo, create new repo
by Hackage 15 Jan '08

15 Jan '08

#58: darcs integration idea: track location of darcs repo, create new repo --------------------------------+------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux --------------------------------+------------------------------------------- Comment (by duncan): We need a spec for how we should specify the source control in a .cabal file. Here are some questions to consider. They are not necessarily all requirements. * what are the use cases? * what kinds of integration would we like with other tools, eg hackage or cabal-install. * how to specify the kind of source control being uses, eg darcs, svn, git etc. Though it's for hackage to support darcs better than others we should allow all necessary info for other systems to be specified in the .cabal file for other tools to take advantage of. * how to specify the url, does that work for other SCMs? * what about tags or branches? * what if the package is not at the root of the repo but within some sub- dir? We may want to find it. * should we be specifying the repo/tag for the exact release? should we specify the branch this release was made from or the main development branch, or both? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Fix compilation on windows
by Duncan Coutts 14 Jan '08

14 Jan '08

Mon Jan 14 06:34:56 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Fix compilation on windows Silly #ifdefs making things harder to test. M ./Hackage/HttpUtils.hs +1

1 0

patch applied (cabal-install): After refactoring the http proxy code we don't need the unix package
by Duncan Coutts 14 Jan '08

14 Jan '08

Mon Jan 14 06:23:01 PST 2008 Duncan Coutts <duncan(a)haskell.org> * After refactoring the http proxy code we don't need the unix package Which was just being used for an exception-free version of getEnv but we have to cope with exceptions anyway for the Win32 registry. M ./cabal-install.cabal -2

1 0

patch applied (cabal-install): Set the user install flag when restoring saved config
by Duncan Coutts 14 Jan '08

14 Jan '08

Mon Jan 14 06:13:13 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Set the user install flag when restoring saved config M ./Hackage/Config.hs +1

1 0

patch applied (cabal-install): Allow finding the proxy to fail without failing overall
by Duncan Coutts 14 Jan '08

14 Jan '08

Sun Jan 13 12:16:27 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Allow finding the proxy to fail without failing overall On windows, if looking up the info in the registry failed then we failed overall. Now we just don't use the proxy. Also refactored a bit. M ./Hackage/HttpUtils.hs -38 +37

1 0

Re: [Haskell-Cafe] Add "number of downloads" to hackageDB page?
by Duncan Coutts 14 Jan '08

14 Jan '08

On Sun, 2008-01-13 at 23:18 +0100, Hugh Perkins wrote: > I seem to remember a thread about this a while back actually, but... > > Any chance of adding the number of downloads to the hackageDB page? > > For those packages that are included in ghc, hugs etc, perhaps add a > green tick with "included in ghc", "included in hugs", etc? > > That way it should be relatively easier to know for newbies which > packages are more or less mature/stable. That is indeed the highest priority for hackage at the moment, that is, getting enough information onto the hackage pages for people to make sensible decisions about what packages to choose. This is also closely related to measuring package QA, ie what packages work on what platforms. > Optional: perhaps include a tick-box/dropdown to only show packages > with more than a certain (configurable) number of downloads? There are loads of great ideas like these floating around and we've had a few discussions on what the most important ones are and how to go about implementing them. The block to progress is enough people with enough time to actually implement these suggestions. So let me take this opportunity to invite everyone who is interested in improving hackage to speak up. If you're interested you should: * Join the cabal-devel mailing list * Take a look at the feature requests in the hackage trac and make sure all your suggestions are properly documented * Post to cabal-devel to say that you're interested and we can discuss things in more detail and suggest where to start and what approach to take http://www.haskell.org/mailman/listinfo/cabal-devel http://hackage.haskell.org/trac/hackage At the moment I am particularly keen on the idea of getting cabal-install to send build reports back to the hackage server and then using that information to show what packages work on what platforms (where platform is the os, compiler version etc etc). So if someone is interested in helping with that then do get in touch. Duncan

1 0

patch applied (cabal): Inform users of max verbosity (fixes ticket 176)
by Duncan Coutts 14 Jan '08

14 Jan '08

Sun Jan 13 12:35:36 PST 2008 thomas.dubuisson(a)gmail.com * Inform users of max verbosity (fixes ticket 176) M ./Distribution/Verbosity.hs -1 +2

1 0