debian-haskell May 2006

debian-haskell@lists.urchin.earth.li

11 participants
11 discussions

First cut at cabal/debian template
by Jeremy Shaw 20 Jun '06

20 Jun '06

Hello, I have a first cut of a template for cabalizing and debianizing haskell libraries. Do a, darcs get http://www.n-heptane.com/nhlab/repos/cabalDebianTemplate ...and see the terse instructions in INSTRUCTIONS.txt. The instructions assume you already know the basics of cabal and debian. I have used the template to debianize or cabalize+debianize a few third party libraries for local use, and it only takes 1-2 mins. Of course, for local use I don't bother to update all the descriptions in debian/control, etc. This version does not generate profiling libraries -- so if we decide that it should, I will add that. My current plan is something like this: (1) Get a template hammered out that everyone likes (profiling, etc) (2) Write some newbie friendly documentation for it (3) Publish the docs on the wiki (4) Write an script to automate the template->specific package conversion process. It is possible that (4) may get moved between (1) and (2) depending on how difficult and desirable it is. If you have any suggestions or improvements let me know. j.

4 5

should we provide -prof .debs by default?
by Jeremy Shaw 05 Jun '06

05 Jun '06

Hello, Recently I was trying to profile some code, and GHC complained that it could not find profiling versions of some 3rd party libraries I was using. According to the GHC manual: 5.2. Compiler options for profiling -prof: To make use of the profiling system all modules must be compiled and linked with the -prof option. Cabal already supports profiling (from the cabal manual section 3.1.3): --enable-library-profiling or -p Request that an additional version of the library with profiling features enabled be built and installed (only for implementations that support profiling). So, perhaps in addition to the libghc6-*-dev packages, we should be providing libghc6-*-prof packages by default? Or is there some trick that will let me profile my application even if I link against some non-profiling-enabled modules? j.

4 3

Re: [Debian-haskell] First cut at cabal/debian template
by Jeremy Shaw 31 May '06

31 May '06

At Wed, 31 May 2006 10:30:14 -0700, Isaac Jones wrote: > > I haven't had a chance to look at this, but could you explain to the > list what it does? Like, we already have dh_haskell, does it use > dh_haskell? Is it a set of debian/ files that are suitable for > Haskell libs? I would describe it as a 'reference package' or 'best practices' for using cabal + dh_haskell. In my experience, people are going to try to cabalize+debianize a package by copying a pre-existing package. So I figure we should provide a canonical reference package that "does it right". It contains the extra files you would need to take a non-cabalized, non-debianized haskell library, and cabalize and debianize it. You could use this either as a starting point for a library you are about to write, or you could copy the parts you need in order to package a pre-existing library. The following sample files are provided: ./Makefile ./debian ./debian/control ./debian/rules ./debian/changelog ./debian/compat ./debian/haskell-package-doc.docs ./debian/copyright ./Setup.hs ./Package.cabal I believe that in most cases you can adapt the sample files to a specific haskell library using these steps (which are included in the repository): (1) Rename Package.cabal to YourPackage.cabal (2) Edit YourPackage.cabal (3) update debian/copyright (4) edit debian/control and: (a) change occurances 'package' to 'yourpackage' (b) modify the 'Description' fields (c) add any extra Build-Depends (5) edit debian/changelog Documentation Generation Steps: (6) Edit Makefile and change the 'doc' target as necessary - by default it just attempts to build Haddock documentation (7) rename debian/haskell-package-doc.docs to debian/haskell-yourpackage-doc.docs (8) edit the contents of haskell-yourpackage-doc.docs if neccessary The above steps obviously assume you are familar with cabal and debian. j.

2 1

Re: Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
by Jeremy Shaw 31 May '06

31 May '06

At Thu, 25 May 2006 13:42:11 +0400, Bulat Ziganshin wrote: > > Hello Jeremy, > > Monday, May 22, 2006, 12:20:54 AM, you wrote: > > > For my own needs, I cabalized and debianized the Streams library. It > > generates binary debs for ghc6 and hugs -- but I think the hugs > > version is broken. In any case, it is a start, you can download the > > packaging at: > > > http://www.n-heptane.com/nhlab/tmp/Streams_packaging.tar.gz > > can i include your work in the library itself? Absolutely. > is it better to include 'debian' directory to my archive or left > this to the debian packagers? If someone volunteers to maintain the package -- then it is probably better to not keep a copy of the debian directory in your archive -- because it will often be out of date and confuse people -- and debian users will be able to get the debianized source easily by typing, 'apt-get source haskell-streams'. On the other hand -- if there is no one officially maintaing it -- it would be useful to provide the debian directory (with a disclaimer) so that debian users can easily build and install the .deb, since subverting the debian package system tends to lead to long-term complications. > can you say how you are use my library? it's both interesting for me > and can be helpful in deciding how it should be further developed I am using it to serialize/deserialize haskell data structures so I can store them in a Berkeley database. To get them into BDB I need to convert the haskell data structure into a C structure that looks like this: struct __db_dbt { void *data; /* Key/data */ u_int32_t size; /* key/data length */ }; Currently I am doing it like this -- but this will clearly fail if the serialized data structure is longer than 512 bytes... withDBT :: (Binary a) => a -> (Ptr DBT -> IO b) -> IO b withDBT thedata f = allocaBytes #{size DBT} $ \dbtPtr -> allocaBytes 512 $ \dataPtr -> do h <- openMemBuf dataPtr 512 withByteAlignedLE h $ flip put_ thedata wrote <- vTell h vClose h #{poke DBT, data} dbtPtr (castPtr dataPtr) #{poke DBT, size} dbtPtr ((fromIntegral wrote) :: Int) f dbtPtr I don't really need the file-system interface for this project -- what would be nice is something like 'withCStringLen' and 'peekCString' for the encode/decode functions: type PtrLen a = (Ptr a, Int) encodePtrLen :: (Binary a) => a -> (PtrLen a -> IO b) -> IO b decodePtr :: (Binary a) => Ptr a -> IO a I could simulate this by using 'encode' to convert the data structure to a String and then use 'withCStringLen' to get the pointer and length -- but having the intermediate String seems like it could be a big performance hit. Two alternative ideas are: (1) accurately pre-calculate the size of the serialized structure and allocate the correct amount of memory from the start (2) start with a 'guess' and realloc the memory if the initial guess is too small. Both of those alternatives have their own problems -- so I think only testing will tell what works best... I have not looked at the library exhaustively, so if there is already a good way to do this, let me know. Thanks! j.

2 2

Re: [Haskell-cafe] Re: [Haskell] installing streams library
by Jeremy Shaw 22 May '06

22 May '06

Hello, I really wanted to respond to the parent thread, but I deleted it already, so this message will be a bit out of context. For my own needs, I cabalized and debianized the Streams library. It generates binary debs for ghc6 and hugs -- but I think the hugs version is broken. In any case, it is a start, you can download the packaging at: http://www.n-heptane.com/nhlab/tmp/Streams_packaging.tar.gz That tarball contains only the packaging -- you just untar it over top of an existing 'Streams' directory that already contains the source. I have only done minimal testing on it. Cabal Question: The streams library uses cpphs to do some preprocessing. There is a hugs specific Makefile that invokes cpphs with the command-line: cpphs --noline -D__HUGS__ -D__HUGS_VERSION__=2005 -DSIZEOF_HSINT=4 -DSIZEOF_HSWORD=4 I tried adding the -D stuff to the cc-includes section of the .cabal file, but that caused the ghc6 build to start failing. Is there an easy way to specify flags that should only be used with cpphs and only when building hugs? Or is this one of those cases when I need to use some of the fancy hook features of cabal? Thanks. j.

3 2

dh_haskell and haddock
by Jeremy Shaw 17 May '06

17 May '06

Hello, I was thinking of modifying 'dh_haskell -i' so that if it sees a binary package named, 'haskell-.+-doc', it will run 'setup haddock'. Does that seem reasonable? j.

2 2

libghc6-FOO-dev packages should Pre-Depends on ghc6
by Arjan Oosting 17 May '06

17 May '06

Hi people, I was just looking at the bugs of c2hs (I am thinking about adopting it) and noticed bug 366184 [1]. The submitter did a big upgrade and the configuration of libghc6-c2hs-dev failed because ghc-pkg was not available yet because ghc6 was not yet configured. ghc-pkg is an alternative configured in ghc6 postinst script. My first though was just calling ghc-pkg6 which is available before ghc6 postinst script has run. But this also cause problems because the global package configuration file of ghc6 is not available before ghc6 postinst has run. Here are the relevant parts of the postinst from ghc6 case "$1" in configure|abort-upgrade|abort-remove|abort-deconfigure) ... update-alternatives \ --install $execdir/ghc ghc $bindir/ghc 600 \ --slave $execdir/ghc-pkg ghc-pkg $bindir/ghc-pkg \ ... if [ ! -e $libdir/package.conf ] then cp $libdir/package.conf.shipped $libdir/package.conf fi .... What we see is that the ghc-pkg command is only available after ghc6 postinst and more importantly that the global package.conf is only available after the postinst. So every libghc6-FOO-dev package will have this bug and could cause problem during upgrades. To solve this we either Pre-Depends on ghc6 so it is configured before we install or we have to change the ghc6 package to support registering packages right after unpacking. Personally I think Pre-Depends is the way to go because we really need ghc6 configured before registering libghc6-FOO-dev. It also is much easier to implement than alternative two. I would like to hear your opinions. Greetings Arjan 1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366184

2 2

Linspire/Freespire Core OS Team and Haskell
by Clifford Beshers 15 May '06

15 May '06

The OS team at Linspire, Inc. would like to announce that we are standardizing on Haskell as our preferred language for core OS development. We are redoing a bunch of our infrastructure using Haskell as our common standard language. Our first task is redoing our Debian package builder (aka autobuilder) in Haskell. Other tools such as ISO builders, package dependency checkers are in progress. The goal is to make a really tight simple set of tools that will let developers contribute to Freespire, based on Debian tools whenever possible. Our hardware detector, currently in OCaml, is on the block to be rewritten as well. There are four of us using Haskell, all CCed on this message. All of us have been using functional languages for quite some time. At Linspire, our choices have been OCaml and Haskell. David Fox wrote the hardware detector in OCaml and is now porting it to Haskell. Jeremy Shaw has been doing various utilities in Haskell for several years. Sean Meiners recently wrote an application for managing his recipe collection and is now hooked. I am porting our CD build procedure from OCaml to Haskell. We are interested in many other uses of Haskell. The recent discussion about Haskell as a shell interests greatly, for example, as we have all suffered through years of bash code. We'd also like to make some Haskell bindings for Qt and KDE, though at the moment we don't have a good plan to tackle that problem efficiently. To date, Linspire (formerly Lindows) has focused on polishing Linux for the consumer market. I mentioned Freespire, above. We announced Freespire recently (www.freespire.org). Essentially it is a more open, developer friendly version of Linspire. http://freespire.org/about/vision and http://freespire.org/support/faqs have good overviews. Access through apt, open-source CNR client and many other good things. I mention Freespire because some of our colleagues were concerned that using Haskell would isolate us from the larger community of developers and make it hard to find new employees skilled in Haskell, should we need to. From our perspective, functional programming makes us more effective and we think that getting even a few people who know Haskell hacking with us is a better combination than lots of Perl and bash. I'm not sure I expect anyone on this list to disagree, but still I'd love to hear your thoughts on the subject. Also, Linspire is based on Debian. We've talked a little with John Goerzen who announced his missingH library here a while back. We've imported it and expect to pass updates back to him as well as any other libraries and tools that he would be interested in includng in the Debian archive. Also, it seems there are quite a few other libraries out there which are either not debianized or stale, but perhaps that is because I haven't fully caught up with what people on this list have done. If there isn't a cron job running somewhere that updates an archive with Cabalized libraries and apps, we would like to help set one up. I will be at Debconf from Sunday, May 14 through Tuesday evening. If anyone on this list is there, I would love to chat and see how we can help each other. Clifford Beshers <clifford.beshers(a)linspire.com> OS Team Lead Linspire, Inc. (I'm subscribed to this list from my personal account. Feel free to use either address.)

2 1

RFS: drift
by Arjan Oosting 13 May '06

13 May '06

Hi, I am searching a sponsor for DrIFT which I maintain. My regular sponsor, Isaac Jones, is quite busy right now and has not uploaded it yet. Below is the changelog, the packages fixes a bug and upgrades the package to the new upstream release. It is available from my webpage [1]. Just do dget http://moonshine.dnsalias.org/debian/unstable/drift_2.2.0-2_i386.changes When rebuilding the package don't forget the -v2.1.2-2 -sa flags for dpkg-buildpackage to include the complete changelog and source in the upload. Greetings Arjan [1] http://moonshine.dnsalias.org/debian/unstable drift (2.2.0-2) unstable; urgency=low . * debian/changelog: fix some spelling mistakes. * debian/drift.doc-base: add missing Index field for info format. (Closes: #366198) * debian/control.in: update to policy version 3.7.2. No changes needed. . drift (2.2.0-1) unstable; urgency=low . * New upstream release. * debian/control: update build dependencies.

2 1

best practices documentation?
by Jeremy Shaw 11 May '06

11 May '06

Hello, Here at Linspire, we are getting ready to cabalize+debianize a bunch of haskell libraries -- either stuff we write or unpackaged 3rd party libraries. Is there any 'best practices' documentation around yet? If not, can anyone recommend some well-done packages that we can use as a reference? If there is no existing documentation, I'll start a wiki page. Thanks! j.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

debian-haskell May 2006