- cabal-devel - Haskell.org

Trac should send bug updates to this list?
by Simon Marlow 24 May '07

24 May '07

We were musing on #ghc today about how visible (or not) the Cabal Trac is. I personally visit it very rarely. It would probably help if Trac sent bug updates to this list. Igloo had a recollection that Isaac didn't like the idea - Isaac, any comments? We could create a separate list if necessary, but I don't honestly think the extra volume will be a problem. Cheers, Simon

2 2

[Conal Elliott] Re: getting cabal to pass more info to haddock
by Isaac Jones 15 May '07

15 May '07

3 7

Re: patch applied (cabal-install): Use user installs by default
by Duncan Coutts 15 May '07

15 May '07

On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > Fri May 4 03:46:52 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> > > * Use user installs by default > > So it "Just Works"tm without needing extra options or sudo fiddling. > > If you care you can still do sudo fiddling and --global-install > > This is inconsistent with Cabal and ghc-pkg, which both use global installs by > default. At the time we felt that global installs were the more common case. I > know this isn't a clear-cut issue though, and there are good arguments on both > sides. For example, one could argue that only the system's package manager > should install packages globally, so since we're bypassing the system package > manager we should default to user installs. > > However, I'm more concerned that we are consistent, and avoid surprising > behaviour where possible. The surprising behaviour I was trying to avoid was that by default it'd fail with an unhelpful error message. Having it work seems to be a better default. When doing manual, configure, build, install steps people are familiar with the notion that the install step needs to be done as root. When we are installing a whole set of packages automagically we don't quite have the same connection to the individual build steps and we kind of expect things to "Just Work"tm without a great deal of intervention. The only way we can do this is if you always run cabal-install as root. We'd have to make it clearer to people through the command line UI that this is the thing to do. This is also a slightly thing to get right, since if the user runs cabal-install update as non-root then the package db gets downloaded to their $HOME/.cabal-install/packages but if you then do cabal-install install as root then /root/.cabal-install/packages or /var/cache/cabal-install/packages probably is not up to date. As it happens, I'm not sure that --global by default for ghc-pkg and --user by default for cabal-install isn't right. The difference is in who is likely to be using the command and what level of control they expect. I'm cc'ing cabal-devel. Hopefully we can get some more opinions on this. Duncan

3 4

cabal-install build-dep error
by Adrian Burciu 13 May '07

13 May '07

Hello, I am a beginner in Haskell, and I am having a problem using cabal-install when I try to install the dependencies for a .cabal file. If I use <sudo cabal-install install package_name> I am able to install every package, one by one. When I installed cabal-install I had no problems and everything went on smoothly. These are the last lines when I installed it: [16 of 16] Compiling Main ( src/CabalInstall.hs, dist/build/cabal-install/cabal-install-tmp/Main.o ) Linking dist/build/cabal-install/cabal-install ... optimus:/usr/local/cabal-install_0 turingson$ sudo runghc Setup.lhs install Installing: /usr/local/lib/cabal-install-0.3.0/ghc-6.6 & /usr/local/bin cabal-install-0.3.0... optimus:/usr/local/cabal-install_0 turingson$ Here is the error I am getting when I try to use build-dep: optimus:/usr/local/hope turingson$ sudo cabal-install build-dep hope.cabal cabal-install: hope.cabal:9: Parse of field 'build-depends' failed: optimus:/usr/local/hope turingson$ That is the only error I am getting. Here is part of the content of the hope.cabal file: License-file: LICENSE Build-depends: base, network, mtl, parsec Do you know what I may be doing wrong or what can I do to work this around? Thanks, Adrian

2 1

Who should be generating lists of files?
by Bryan O'Sullivan 11 May '07

11 May '07

As part of cabal-rpm, I'd like to be able to package up profiling versions of libraries in a separate system-level package from normal libraries, to reduce bloat. What's the best way for me to get a list of the files that would be installed by Setup copy, and determining which are profiling files vs normal? Should I be faking this up inside cabal-rpm, or pushing the knowledge out to Cabal itself? <b

2 1

Stack overflow on hackage upload
by Bjorn Bringert 11 May '07

11 May '07

I can't seem to upload the new GD release to hackage: $ cabal-upload dist/gd-3000.1.0.tar.gz Uploading dist/gd-3000.1.0.tar.gz... ERROR: 500 Internal Server Error <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" ><head ><title >500 Internal Server Error</title ></head ><body ><h1 >500 Internal Server Error</h1 ><p >stack overflow</p ><hr /><address >Haskell CGI on Apache/2.0.54 (Debian GNU/Linux) at hackage.haskell.org, port 80</address ></body ></html > I get the same error when using my web browser to upload. I have attached the tarball I tried to upload. /Björn

3 6

Re: Integrating Cabal, Haddock, HsColour
by Simon Marlow 06 May '07

06 May '07

Roberto Zunino wrote: > I've just extended Cabal so to generate docs with links to highlighted > sources. Now > > ./Setup configure > ./Setup haddock --link-to-hscolour > ./Setup hscolour --css my_own_stylesheet.css > > generates HTML as this one: (run on Cabal itself) > > http://www.di.unipi.it/~zunino/tmp/dist/doc/html/Cabal/Distribution-Program… > > Click on the "Source" links on the right. You will be sent to the exact > line. The whole Cabal docs+sources are online. Colours have been chosen > to match my emacs configuration :-P . > > This relies on a couple of minor tweaks to Haddock and HsColour which I > darcs-sent this morning to the authors. > > Comments are welcome. > > - Is this worth including in the next Cabal version? Looks really nice! (BTW, cabal-devel(a)haskell.org is a better place to discuss Cabal improvements). I'm happy for it to go in. > - Are the options above good choices? I'd make 'Setup haddock --hscolour' do both steps. > - Is the directory tree OK? Currently Haddock creates (under dist/doc/html) Looks fine. Cheers, Simon

4 4

cabal "fails" with no explanation
by Stefan O'Rear 05 May '07

05 May '07

stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 cleaning... stefan@stefans:/usr/local/src/xmonad$ echo $? 1 stefan@stefans:/usr/local/src/xmonad$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 stefan@stefans:/usr/local/src/xmonad$ configure, build, and install all also work but return 1. The same issue is observed with X11-extras. Stefan

3 3

cabal-upload & cabal-install
by Duncan Coutts 04 May '07

04 May '07

Hia Ross, Bjorn, Pepe Iborra and I were hacking on cabal-install today. I hope you like our patches :-). Pepe updated it to use filepath so it'd work on windows and I fiddled with locations of config and things to try and make installation simpler so it'll work "out of the box". I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it. However I failed to upload Cabal-1.1.6.2 which I also released today. Via both the website and cabal-upload interfaces it failed the upload after a few 100k, so I think it's a server side issue. Does it have a limit on the upload size? cabal-1.1.6.2.tar.gz is just over 500k. You can grab it here and try: http://haskell.org/cabal/release/latest/cabal-1.1.6.2.tar.gz My general impression is that cabal-install, hackage and cabal-upload are really nice, especially the hackage web ui. You've done a lot of work! What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it. One longer term thing I was thinking about was using hackage and cabal-install to gather testing feedback. We could have cabal-install report (with user consent) build successes and failures, including useful info about the environment, including the platform, Haskell implementation and version, the version of cabal, cabal-install and versions of the all the dependent packages (not sure if it should be directly or transitively). This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine. Duncan

3 4

Detrimental c2hs / "other-modules" interaction
by mstone＠sccs.swarthmore.edu 04 May '07

04 May '07

Dear Cabal Developers, First, thanks for the excellent work so far. Second, I thought I'd report a frustrating experience I had on my first attempt to package a library. I'm currently extracting a Cairo binding from Gtk2hs because I want to use Cairo on a server that doesn't have X or GTK readily available. As I went about adapting Gtk2hs' binding, I ran into the following issue: 1) Cabal does not clean up after c2hs - in particular, it does not delete the temporary .chi and .chs.h files that c2hs produces for each file it processes. 2) Cabal does not do dependence analysis. Consequently, the "other-modules" field of my cairo.cabal is order-sensitive. Together, these mean that after I manually delete those temporary files, my build fails mysteriously because the dependencies are not being resolved in an order that c2hs can work with. This in turn makes it non-trivial to make reliable builds. Please let me know if you'd like any further information. Thanks, Michael Stone

2 1