- cabal-devel - Haskell.org

setting up a chroot jail
by Sascha Böhme 15 Jun '07

15 Jun '07

Hello, although my question may be out of topic, I kindly ask for your help. I am working on the Google summer of code project to enhance the HackageDB website, especially by a tool to automatically generate Haddock documentation. For this to work, it is necessary to set up a chroot jail, in which packages are unpacked, configured and Haddock documentation is build. Some packages also need to be build, which could include running untrustable code. Up to now, I considered several ideas to set up a chroot jail, but they all do not fully satisfy my needs or I could not test them on my machine. Here are my proposals for setting up a chroot environment: 1) use a hand-written script 2) use makejail, jail, jailkit (or a similar tool) 3) use debootstrap 4) use dpkg to install necessary debian packages My distribution is gentoo, which is why I did not test 3). However, I thought that 4) is suitable, although it's very tedious. In fact, it seems to me like rewriting parts of debian installers. Option 1) is just not maintainable. Finally, 2) seems to be of use just for servers like ssh or ftp. I haven't tested it, but I doubt it will work in an environment with several different applications like ghc, haddock, cpphs, happy, ... Does anyone have an idea how to (automatically, maintainably) set up a chroot jail for this particular situation? I'm grateful for any help. Thanks, Sascha

4 3

Parsec as a Dependency?
by Thomas Schilling 13 Jun '07

13 Jun '07

Hi Caballers, now that .cabal files are getting a more complex syntax (due to configurations), I'd really like to use Parsec instead of lots of hand-written and hard to maintain parsing code. By getting rid of ReadP-based field parsing, we'd also get proper error messages for field values. At the Parsec homepage I says that it's now included by default in GHC, Hugs and NHC, so it'll most likely be present on any sufficiently recent system. What would be arguments against this proposal? / Thomas

5 8

Bugs and interface changes
by Ian Lynagh 07 Jun '07

07 Jun '07

Hi all, I've gone through the Cabal bugs and tried to make sure that those that mean interface changes are marked as high priority. Any of these that we can get done before the next round of releases will hopefully mean fewer headaches in the longrun. By the way, do bugs get automatically assigned to ijones? That doesn't seem very useful to me. Thanks Ian

2 1

#140 (Cabal doesn't allow doc/html/<package name> to be overridden)
by Ross Paterson 06 Jun '07

06 Jun '07

igloo writes: > Distribution.Simple.LocalBuildInfo uses > > haddockPref pkg_descr > = foldl1 (</>) [distPref, "doc", "html", pkgName (package pkg_descr)] > > and provides no way to override it. This should be a new field docdir > (or similar), and be overridable with a configure flag. haddockPref determines where the documentation is built; mkHaddockDir says where it is installed, currently $datadir/$datasubdir/doc/html/$pkg, where $datasubdir defaults to $pkgid. That default doesn't seem right in any case. Perhaps we want --docdir (defaulting to $prefix/share/doc on Unix and something else on Windows) --htmlsubdir (defaulting to $pkgid/html)

2 1

copy / register / --gen-script and --destdir
by Marc Weber 05 Jun '07

05 Jun '07

I can use ./setup copy --destdir to copy all hi files etc to some directory. But how do I register it then? Setting --prefix when using configure does'nt seem to adjust the register.sh using --gen-script I just can't add --destdir. What am I missing? Marc

3 4

Re: Cabal -extra-lib-dirs and -rpath, also framework-dirs
by Duncan Coutts 04 Jun '07

04 Jun '07

On Sun, 2007-06-03 at 15:48 -0700, Ashley Yakeley wrote: > 1. It seems entries on the extra-lib-dirs line in cabal (GHC 6.6) are > not passed to the linker with -rpath. Instead, you have to do that in > ld-options with "-Wl,-rpath -Wl,mylibdir". The trouble is this is not > portable, as the Darwin (Mac OS X) linker doesn't accept the -rpath > option and (I think) simply uses all -L directories for the runtime path > or some clever thing. > > I recommend that either extra-lib-dirs be passed as -rpath (as > appropriate for the platform), or a new field such as "extra-rpath-dirs" > be added. Ugg. This is somewhat a can of worms. For one thing it doesn't work on windows, but also it's not necessarily what one always wants. For example building on one machine and deploying on another, if there are specific paths baked into the libraries/executables that might be intended to be on the standard dynamic linker path on the target machine. I think this issue needs a fair bit of thought before we go and implement something. We should see what other systems do etc. > 2. Cabal doesn't recognise "framework-dirs" as a field name, even though > it shows up in "ghc-pkg describe". Yes, cabal does not currently support that field. It probably should. The format used by ghc-pkg is quite similar to the cabal format, but not exactly the same, so don't be surprised by things appearing in one and not the other, or having slightly different names or meanings. Duncan

2 1

Re: copy / register / --gen-script and --destdir
by Duncan Coutts 04 Jun '07

04 Jun '07

oops, sent to Marc without also cc'ing the list... On Sun, 2007-06-03 at 23:26 +0100, Duncan Coutts wrote: > On Sun, 2007-06-03 at 22:54 +0200, Marc Weber wrote: > > I can use ./setup copy --destdir to copy all hi files etc to some > > directory. > > > > But how do I register it then? > > Setting --prefix when using configure does'nt seem to adjust the > > register.sh > > using --gen-script I just can't add --destdir. > > > > What am I missing? > > Sounds like a bug to me. Can you file a bug report with all the exact > details of what you expected and what really happened. And if you > happened to send in a patch fixing said bug that'd be even better :-) > > Duncan

1 0

Re: [Gtk2hs-devel] [Gtk2hs-users] Problem compiling development version
by Duncan Coutts 01 Jun '07

01 Jun '07

On Thu, 2007-05-31 at 22:36 -0400, Peter Gavin wrote: > Oops, I guess I hit the send button too early :) > > On 5/31/07, Peter Gavin <pgavin(a)gmail.com> wrote: > > Ok, so I've taken a look at the cabal sources, and I've decided to add > > a very simple way for preprocessors to specify dependecies. > > Basically, I'm going to add a field to the PreProcessor datatype: > > calcDependencies :: (FilePath, FilePath) -> Verbosity -> IO [Module], > > that returns the modules that should be preprocessed before the source > > file passed as the first argument. The only preprocessor that will > > really take advantage of this is the C2hs one, of course. Then the > > preprocessSources function will call calcDependencies > to build the dependency graph. > > How does that sound? That sounds sensible. I'm cc'ing the cabal-devel list which is the place to ask questions and get opinions and where patches should be sent for wider review by cabal hackers. Duncan

1 0

Cabal for the GHC build
by Ross Paterson 31 May '07

31 May '07

It's a pity that even simple libraries need a 67-line Setup.hs to make the GHC build work. How about moving the --ghc-option and --configure-option flags into Cabal? --configure-option might be a better idea than the current behaviour of "setup configure" in defaultUserHooks, namely to pass through all unrecognized arguments.

2 1

Plain email addresses on hackage
by Neil Mitchell 29 May '07

29 May '07

Hi When email addresses are in a .cabal file, they are including on the hackage website in plain text. For example: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/derive-0.1 Can someone please hide these email addresses in some way? Thanks Neil

2 1