March 2010 - arch-haskell

packaging the haskell platform: another shot
by Thomas Girod 29 Mar '10

29 Mar '10

Hi people. yesterday I tried to write a PKGBUILD for the haskell-platform. it looks like this (work in progress): ---- pkgname=haskell-platform pkgver=2010.1.0.0 pkgrel=1 pkgdesc="the haskell platform" arch=('i686' 'x86_64') url="http://hackage.haskell.org/platform/" license=('BSD') groups=() depends=('ghc>=6.12.1') makedepends=() optdepends=() provides=('cabal-install=0.8.0' 'alex=2.3.2' 'happy=1.18.4' 'haddock=2.7.2' 'haskell-cgi=3001.1.7.2' 'haskell-fgl=5.4.2.2' 'haskell-glut=2.1.2.1' 'haskell-haskell-src=1.0.1.3' 'haskell-html=1.0.1.2' 'haskell-hunit=1.2.2.1' 'haskell-mtl=1.1.0.2' 'haskell-network=2.2.1.7' 'haskell-opengl=2.2.3.0' 'haskell-parallel=2.2.0.1' 'haskell-parsec=2.1.0.1' 'haskell-quickcheck=2.1.0.3' 'haskell-regex-base=0.93.1' 'haskell-regex-compat=0.92' 'haskell-regex-posix=0.94.1' 'haskell-stm=2.1.1.2' 'haskell-xhtml=3000.2.0.1' 'haskell-zlib=0.5.2.0' 'haskell-http=4000.0.9' 'haskell-deepseq=1.1.0.0') conflicts=() replaces=() backup=() options=() install= source=(http://hackage.haskell.org/platform/$pkgver/$pkgname-$pkgver.tar.gz) noextract=() md5sums=('ad96a12535b955f2f5e11769b02e0f76') build() { cd "$srcdir/$pkgname-$pkgver" ./configure --prefix=/usr make || return 1 make DESTDIR="$pkgdir/" install } ---- as you can see, it is supposed to build *all* the platform in one bundle, and it uses the "provides" field to list all the packages offered by the platform, rather than building its content through dependencies. If one wants to have the platform version and the bleeding edge of a package, it might be problematic. A possible solution could be to use a different naming scheme for non-platform versions, like using the prefix "hackage-" rather than "haskell-" for example. Well I guess there are reasons for not using this approach already, and I'm not seeing them. If it is the case, I would be glad to hear them. ---- note : the above script doesn't work, for sure I did some stuff wrong. Maybe it could be better to use the cabalized version of the haskell-platform and then declare cabal-install, alex, happy and haddock as external dependencies - but then if any of those gets pushed ahead of the platform, it *will* cause troubles. Tom

2 2

lhs2tex broken
by Wei Hu 29 Mar '10

29 Mar '10

After the gmp upgrade, I had to upgrade this package too. It failed to find polycode.fmt when processing .lhs files: lhs2TeX: user error (File `polycode.fmt' not found in search path: . /home/wh5a/lhs2tex-1.15 /home/wh5a/lhs2tex /home/wh5a/lhs2TeX /home/wh5a/.lhs2tex-1.15 /home/wh5a/.lhs2tex /home/wh5a/.lhs2TeX /usr/share/lhs2tex-1.15 /usr/local/share/lhs2tex-1.15 /usr/local/lib/lhs2tex-1.15 /usr/lib/lhs2tex-1.15 /usr/local/share/lhs2tex /usr/local/lib/lhs2tex /usr/share/lhs2tex /usr/lib/lhs2tex /usr/local/share/lhs2TeX /usr/local/lib/lhs2TeX /usr/share/lhs2TeX /usr/lib/lhs2TeX ) However, I do have /usr/share/lhs2tex-1.15/polycode.fmt. Any ideas?

1 0

Could not find module Distribution.Simple
by pete morris 28 Mar '10

28 Mar '10

Hi all, Since the recent gmp/ghc upgrades in Arch, I get an error trying to build haskell packages on i686. For example, haskell-binary: $ cd /var/abs/local/haskell-binary && makepkg ... ==> Starting build()... Setup.hs:3:7: Could not find module `Distribution.Simple': Use -v to see a list of the files searched for. ==> ERROR: Build Failed. Aborting... I have the following haskell related packages installed: local/ghc 6.12.1-4 local/haskell-http 4000.0.9-4 local/haskell-mtl 1.1.0.2-3 local/haskell-network 2.2.1.7-3 local/haskell-parsec 2.1.0.1-2 local/haskell-stm 2.1.1.2-2 local/haskell-utf8-string 0.3.6-3 local/haskell-x11 1.5.0.0-1 local/haskell-x11-xft 0.3-12.1 local/haskell-zlib 0.5.2.0-3 local/xmonad 0.9.1-3 local/xmonad-contrib 0.9.1-2 local/xmobar 0.9.2-2 local/cabal-install 0.8.0-2 Any thoughts on the missing module error? Thanks, Pete

2 2

Codec-Image-DevIL, Arch Linux, haskell-codec-image-devil
by Gregory D. Weber 27 Mar '10

27 Mar '10

I. Problem: Codec-Image-DevIL 0.1 and 0.2.0 will not build on Arch Linux A. Attempted installation from Arch User Repository (AUR) I attempted to install the package haskell-codec-image-devil 0.2.0-2 (http://aur.archlinux.org/packages.php?ID=18919) with bauerbill: $ bauerbill --aur -Sy haskell-codec-image-devil ... ==> Starting build()... Configuring Codec-Image-DevIL-0.2.0... Setup: Missing dependency on a foreign library: * Missing C library: IL This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. ==> ERROR: Build Failed. Aborting... ERROR: makepkg exited with an error (512) ERROR: no package found: /tmp/bauerbill/build/aur/haskell-codec-image-devil/haskell-codec-image-devil-0.2.0-2-x86_64.pkg.tar.gz $ The error message "Missing C library: IL" is incorrect: the Arch 'devil' package is installed, and the include and library files are present in the normal locations: $ pacman -Q devil devil 1.7.8-6 $ ls /usr/include/IL devil_cpp_wrapper.hpp il.h ilu.h ilu_region.h ilut.h $ ls /usr/lib/*IL* /usr/lib/libIL.a /usr/lib/libILU.a /usr/lib/libILUT.a /usr/lib/libIL.so@ /usr/lib/libILU.so@ /usr/lib/libILUT.so@ /usr/lib/libIL.so.1@ /usr/lib/libILU.so.1@ /usr/lib/libILUT.so.1@ /usr/lib/libIL.so.1.1.0* /usr/lib/libILU.so.1.1.0* /usr/lib/libILUT.so.1.1.0* B. Attempted installation from Hackage Trying to install either version 0.1 or 0.2.0 from Hackage yields essentially the same result: $ runghc Setup configure Configuring Codec-Image-DevIL-0.2.0... Setup: Missing dependency on a foreign library: * Missing C library: IL This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. $ C. Missing comment on AUR package page Incidentally -- I'm pretty sure I posted a comment reporting the problem earlier this month (March 2010) on http://aur.archlinux.org/packages.php?ID=18919 -- but the comment seems to have disappeared. Or maybe I'm not going through the right hoops to view comments -- I remember having that trouble before, but can't remember the solution. II. Solution There seem to be two errors, one involving Codec-Image-DevIL and one involving Cabal. I have solutions for the first, but not the second. A. Fixing Codec-Image-DevIL 1. Quick fix: Edit Codec-Image-DevIL.cabal and replace the line Extra-Libraries: IL with one of the following (take your choice): Extra-Libraries: IL, pthread Extra-Libraries: IL, rt Extra-Libraries: IL, pthread, rt These all work in Arch Linux, and they also work (though they are not needed) in Fedora 10. 2. How I discovered this: I wrote a small C program that calls a few DevIL functions (such as ilInit, ilLoadImage) just to demonstrate that they are truly there. Compiling and linking with -lIL failed: $ gcc -o ctestil -lIL ctestil.o /usr/lib/libIlmThread.so.6: undefined reference to `sem_init' /usr/lib/libIlmThread.so.6: undefined reference to `sem_destroy' /usr/lib/libIlmThread.so.6: undefined reference to `pthread_create' /usr/lib/libIlmThread.so.6: undefined reference to `sem_post' /usr/lib/libIlmThread.so.6: undefined reference to `sem_trywait' /usr/lib/libIlmThread.so.6: undefined reference to `sem_getvalue' /usr/lib/libIlmThread.so.6: undefined reference to `sem_wait' /usr/lib/libIlmThread.so.6: undefined reference to `pthread_join' collect2: ld returned 1 exit status Reading 'man sem_init', I found the statement "Link with -lrt or -pthread." Sure enough, both of these worked: $ gcc -o ctestil -lIL -lrt ctestil.o $ gcc -o ctestil -lIL -pthread ctestil.o B. Whether to fix Cabal? But why is Cabal spuriously reporting the absence of libIL? It is an error, isn't it? I have the impression, formed from browsing around on http://hackage.haskell.org/trac/hackage/, that in the configuration step, when Cabal sees the line Extra-Libraries: IL it writes a small C program that tries to include that library, and reports the library is missing if there's an error in compiling it. Maybe Cabal needs to interpret the C compiler's error messages more carefully. Greg -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

2 1

More GHC/GMP woes
by Matthew William Cox 23 Mar '10

23 Mar '10

Hello, Version 6.12.1-3.1 of ghc still has a hidden dependency on gmp, even though it's built with integer-simple. > % pacman -Qo /usr/lib/ghc-6.12.1/unlit > /usr/lib/ghc-6.12.1/unlit is owned by ghc 6.12.1-3.1 > % ldd /usr/lib/ghc-6.12.1/unlit| grep not\ found > libgmp.so.3 => not found This version of ghc will build simple packages, but will fail when trying to rebuild ghc itself. I suppose there's some sort of bug in the GHC makefile that cause libgmp to be linked against libgmp whatever integer library is in use? Matt

2 1

STAT: GHC needs a rebuild for new gmp in testing
by Matthew William Cox 21 Mar '10

21 Mar '10

Heads up: The new gmp in [testing] has a new SO_VERSION, and the ghc package needs a rebuild. Once gmp clears testing, it'll break ghc for everyone, which will definitely hurt platform compliance ;) Regards, Matt.

1 0

BSD guy needing help with haskell-platform
by david fries 15 Mar '10

15 Mar '10

Hi Archers, I have been working on porting the Haskell-Platform to the FreeBSD operating system for a while now and some issues have come up. I've come here because I think Arch Linux has the best Haskell support among all the Linux distros and I was hoping that I could learn from your experience and maybe adopt some best practices too. I know this is way off topic, but we *nix guys must stick together, right ;) The haskell-platform has been released over a year ago and it still isn't available on FreeBSD. So I decided to do it myself. However I've run into problems. Let me begin by giving you an idea of the situation: Our approach is very compiler-centric. We're still running on GHC-6.10.4 (6.12 is in the testing phase). Our ghc compiler package contains a couple of "builtin" (i.e. not available as separate separate packages) libraries that it requires. For instance, network-2.2.1.2 is one of them. The problem is that the Haskell-Platform requires version 2.2.1.4. Under normal circumstances I would port network-2.2.1.4 to FreeBSD and then specify it as a dependency of the Platform port (Currently, the plan is to make it a meta package). But then we would end up with two (exposed) versions of the network library installed on the system. For example, let's assume that I have the following Haskell source (Networking.hs): module Networking where import Data.ByteString.Lazy import Data.Maybe import Network.HTTP import Network.Stream import Network.URI getBinary :: String -> IO ByteString getBinary url = do uri <- return $ fromJust $ parseURI url rsp <- simpleHTTP $ request uri getResponseBody rsp where request uri = Request { rqURI = uri , rqMethod = GET , rqHeaders = [] , rqBody = empty } When I try to compile it (`ghc --make Networking.hs`) I get the following: Networking.hs:12:30: Couldn't match expected type `network-2.2.1.2:Network.URI.URI' against inferred type `URI' In the first argument of `request', namely `uri' In the second argument of `($)', namely `request uri' In a stmt of a 'do' expression: rsp <- simpleHTTP $ request uri However, the following thing could help: $ ghc --make Networking.hs -package network-2.2.1.2 The above workaround ain't acceptable to the FreeBSD committers, so I have to come up with something better to get the Port into the official repository. The way things are setup, there is no way for me to replace the network-2.2.1.2 library which is part of our ghc compiler package. In a perfect world, I'd be able to install the required HP dependencies without tripping ghc up. Then we could switch over to the platform and use that as a foundation for GHC-6.12. In your opinion, what would be the best approach to updating network? BTW, I guess it would involve rebuilding all installed packages that had previously been compiled with ghc? Currently the attitude in our camp is that cabal packages that were installed together with the compiler is simply are off limits and shouldn't be tampered with. Do you have a similar policy? I've been also reading the debian-haskell mailing list archives. It seems they have been facing similar version discrepancies. They've dealt with it by patching the setup to make cabal shut up [1]. What approach did you guys take? I'm grateful for any comments regards and TIA, dave [1] http://lists.debian.org/debian-haskell/2009/10/msg00007.html

1 0

parsec-2.1.0.1 rebuild done
by Vesa Kaihlavirta 03 Mar '10

03 Mar '10

Hey, Just a heads-up for those who need to care. haskell-parsec-2.1.0.1 was uploaded just now, with the triggered rebuilds of haskell-network and haskell-http. If your packages depend on any of these, you'll probably need to rebuild. Are we platform now? --vk

2 1