debian-haskell June 2005

debian-haskell@lists.urchin.earth.li

7 participants
5 discussions

Information for people packaging Gtk2Hs 0.9.8
by Duncan Coutts 10 Jun '05

10 Jun '05

Hi all, This is directed primarily at people packaging Gtk2Hs 0.9.8 for distros. A Gtk2Hs 0.9.8 release candidate is currently available: http://haskell.org/gtk2hs/gtk2hs-0.9.7.92.tar.gz (md5sum 48b2df4bf62143fa34d4c2bde8b7c509) This is the second releae candidate which contains very minor changes since the first release candidate: * fix bug in treeSelectionSelectedForeach * enable the use of the new GClosure-based signals system on amd64 machines. * update the website address in the cabal package files * build fixes to support ghc 6.4 on windows * additional build system code for packager mode on windows to make building the windows installer easier Since the last major release of Gtk2Hs we've made some changes to the ./configure script to make things slightly easier (we hope!) for packagers while at the same time making the build process slightly simpler for ordinary users. When you run ./configure normally it will now automatically detect whether the appropriate dependencies are installed and select to build the various optional packages automatically (ie libglade, gconf, sourceview, mozembed etc). This is great for users since it means you can just run ./configure and it should "Just Work"tm. For packagers this behaviour is not so great since it means you can pick up extra untracked dependencies without realising it (especially if we add new optional packages and you don't notice that we've done that!). So for packagers we have a new option --enable-packager-mode which turns off automatic detection and the optional packages will only be selected if they are explicitly requested with --enable-libglade, --enable-gconf etc. Also, the optional packages can now be enabled/disabled individually rather than --enable-gnome selecting several optional packages. Also, the --enable-packager-mode turns off package registration on installation by default which is normally what packagers want. So the make install process installs the .pkg/.cabal files in the same directory as it puts the libHS*.a files. These are the ones you want to register. For reference there is a gentoo ebuild that I maintain that might be useful to you: http://haskell.org/~gentoo/gentoo-haskell/portage/dev-haskell/gtk2hs/gtk2hs… You should expect this release to work on x86, sparc and probably ppc arches. amd64 might work with the upcomming GHC 6.4.1 release. If you choose to include pre-built documentation, I reccomend building it with the as-yet-unreleased Haddock 0.7 version since it does a much better job with getting links going to the appropriate targets. We will be using Haddock 0.7 for the docs we put on the website. Of course this is only possible if you're including pre-built docs otherwise we're stuck with Haddock 0.6. You should expect Gtk2Hs to work with GHCi (except on sparc (until ghc-6.4.1) and win32). Some testing that I would reccomend you try: * check that the new c2hs C parser is parsing the headder files on your platform correctly. See this email for details: http://sourceforge.net/mailarchive/message.php?msg_id=11998853 (I would very much apreciate reports of sucess or failure on this issue, especially on non-glibc based platforms.) * run "make installcheck" after "make install" to build all the demos and then one can manually run each of them to check they are working. mozembed probably still doesn't work on FreeBSD due to 'rpath' problems. We can have another go at fixing that if anyone can figure out what's going wrong. If you have any other packaging questions or problems please do ask. Duncan

1 0

haxml, hunit and quickcheck
by Ian Lynagh 09 Jun '05

09 Jun '05

Hi all, The latest release of ghc6, nhc98 and hugs all ship with quickcheck and hunit. What's our plan here? Just remove the hunit Debian package and let them continue to do so? (I'm not too bothered about ghc5 being left without it). Also, nhc98 and hugs ship with haxml but ghc6 doesn't. I think the best thing is for us to remove haxml from the nhc98 and hugs packages and have a single Debian (source) package provide it for all implementations. Does that sound reasonable? (If hugs can cope with both being installed at once then that also seems reasonable. AFAICS nhc98 can't). (I think we're anticipating the planned upstream change here, but I didn't get a definitive answer when I asked Malcolm. I think separate libraries are generally much better anyway). Thanks Ian

4 10

Bug#312256: ITP: washngo -- Web Authoring System for Haskell
by John Goerzen 06 Jun '05

06 Jun '05

Package: wnpp Severity: wishlist Owner: John Goerzen <jgoerzen(a)complete.org> * Package name : washngo Version : 2.3.1 Upstream Author : Peter Thiemann * URL : http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ * License : 3-clause BSD Description : Web Authoring System for Haskell WASH is a family of embedded domain specific languages (EDSL) for programming Web applications. Each language is embedded in the functional language Haskell, which means that it is implemented as a combinator library. . Currently, WASH has the following components: . wash2hs, a preprocessor for including literal XHTML fragments in the style of Haskell Server Pages (HSP) . WASH/CGI for server-side web scripting . WASH/HTML for dynamic generation of HTML and XHTML . WASH/Mail for email processing I expect one binary to be built from the source at this time, and it will be named libghc6-wash-dev. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.12-rc4-mm2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

1 0

hsc2hs and ghc 6.4 package
by Jérémy Bobbio 04 Jun '05

04 Jun '05

Hi, GHC 6.4 package found on haskell-unsafe ship with hsc2hs in: /usr/lib/ghc-6.4/bin/hsc2hs Is there any rationale about not installing it in /usr/bin? Cheers, Jérémy.

2 1

libghc6-gtk2-dev
by Will Thompson 04 Jun '05

04 Jun '05

Hi, libghc6-gtk2-dev appears to depend on a version of ghc6 older than that in unstable. Is there any chance of it being rebuilt for ghc 6.4? I'd offer to do it myself, but I don't have the requisite 1gb of memory :-( Thanks, Will

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

debian-haskell June 2005