January 2010 - arch-haskell

Status update
by Don Stewart 25 Jan '10

25 Jan '10

Hey all, cabal2arch is updated and building packages, under ghc 6.12, with the new tweaks: - full dependency listings - fixed to find the haddock index. You should be able to update via your favorite provides-supporting package tool, e.g. sudo bauerbill --build-as $USER --no-color --noconfirm --aur -S cabal2arch So I think we're in better shape now. Many packages in AUR are missing their dependencies on e.g. haskell-network or haskell-mtl, so I'll script up a full rebuild of AUR against ghc 6.12, at which point we'll be done. I've started with the most popular packages. So, e.g. haskell-binary is now updated. -- Don

2 3

gtk2hs?
by Don Stewart 25 Jan '10

25 Jan '10

Looks like gtk2hs isn't working? $ sudo pacman -S gtk2hs warning: gtk2hs-0.10.1-3 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets (1): gtk2hs-0.10.1-3 Total Download Size: 0.00 MB Total Installed Size: 50.01 MB Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [###########################################] 100% (1/1) upgrading gtk2hs [###########################################] 100% ghc-pkg: cannot find package glade ghc-pkg: cannot find package gconf ghc-pkg: cannot find package sourceview ghc-pkg: cannot find package gtksourceview2 ghc-pkg: cannot find package svgcairo ghc-pkg: cannot find package gtkglext ghc-pkg: cannot find package soegtk ghc-pkg: cannot find package gtk ghc-pkg: cannot find package cairo ghc-pkg: cannot find package glib building GHCi library /usr/lib/gtk2hs/HSglib.o... done. glib-0.10.1: missing id field glib-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) Reading package info from "/usr/lib/gtk2hs/glib.package.conf" ... done. building GHCi library /usr/lib/gtk2hs/HScairo.o... done. cairo-0.10.1: missing id field cairo-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) cairo-Reading package info from "/usr/lib/gtk2hs/cairo.package.conf" ... done. 0.10.1: dependency "mtl-1.1.0.2" doesn't exist (use --force to override) cairo-0.10.1: dependency "glib-0.10.1" doesn't exist (use --force to override) cairo-0.10.1: dependency "bytestring-0.9.1.4" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSgtk.o... done. Reading package info from "/usr/lib/gtk2hs/gtk.package.conf" ... done. gtk-0.10.1: missing id field gtk-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) gtk-0.10.1: dependency "mtl-1.1.0.2" doesn't exist (use --force to override) gtk-0.10.1: dependency "glib-0.10.1" doesn't exist (use --force to override) gtk-0.10.1: dependency "cairo-0.10.1" doesn't exist (use --force to override) gtk-0.10.1: dependency "containers-0.2.0.1" doesn't exist (use --force to override) gtk-0.10.1: dependency "array-0.2.0.0" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSsoegtk.o... done. soegtk-0Reading package info from "/usr/lib/gtk2hs/soegtk.package.conf" ... done. .10.1: missing id field soegtk-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) soegtk-0.10.1: dependency "mtl-1.1.0.2" doesn't exist (use --force to override) soegtk-0.10.1: dependency "gtk-0.10.1" doesn't exist (use --force to override) soegtk-0.10.1: dependency "cairo-0.10.1" doesn't exist (use --force to override) soegtk-0.10.1: dependency "old-time-1.0.0.2" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSglade.o... done. glade-0.Reading package info from "/usr/lib/gtk2hs/glade.package.conf" ... done. 10.1: missing id field glade-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) glade-0.10.1: dependency "gtk-0.10.1" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSgconf.o... done. gconf-0.10.Reading package info from "/usr/lib/gtk2hs/gconf.package.conf" ... done. 1: missing id field gconf-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) gconf-0.10.1: dependency "glib-0.10.1" doesn't exist (use --force to override) ghc-pkg: /usr/lib/gtk2hs/sourceview.package.conf: openFile: does not exist (No such file or directory) building GHCi library /usr/lib/gtk2hs/HSgtksourceview2.o... done. Reading package info from "/usr/lib/gtk2hs/sourceview.package.conf" ... Reading package info from "/usr/lib/gtk2hs/gtksourceview2.package.conf" ... done. gtksourceview2-0.10.1: missing id field gtksourceview2-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) gtksourceview2-0.10.1: dependency "gtk-0.10.1" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSsvgcairo.o... done. Reading package info from "/usr/lib/gtk2hs/svgcairo.package.conf" ... done. svgcairo-0.10.1: missing id field svgcairo-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) svgcairo-0.10.1: dependency "mtl-1.1.0.2" doesn't exist (use --force to override) svgcairo-0.10.1: dependency "glib-0.10.1" doesn't exist (use --force to override) svgcairo-0.10.1: dependency "cairo-0.10.1" doesn't exist (use --force to override) building GHCi library /usr/lib/gtk2hs/HSgtkglext.o... done. gtkglextReading package info from "/usr/lib/gtk2hs/gtkglext.package.conf" ... done. -0.10.1: missing id field gtkglext-0.10.1: dependency "base-4.1.0.0" doesn't exist (use --force to override) gtkglext-0.10.1: dependency "gtk-0.10.1" doesn't exist (use --force to override) error: command failed to execute correctly

2 3

Survey: list of yaourt-replacements that support "provides"?
by Don Stewart 25 Jan '10

25 Jan '10

What are the tools the Arch Haskell community wants to recommend instead of the broken "yaourt" tool. Which AUR resolvers understand "provides" syntax? The answer will be added to this page: http://haskell.org/haskellwiki/Arch_Linux/Preferred_Package_Tools And I added a pointer to the haskell-cabal AUR page: http://aur.archlinux.org/packages.php?ID=25443 Once we have some examples of how to migrate, I'll post on the Arch Haskell blog with the news. We're going to kill off yaourt pretty quickly now, or else they'll have to fix yaourt.. -- Don

2 3

Example PKGBUILD
by Don Stewart 22 Jan '10

22 Jan '10

Here's an example of what new PKGBUILDs look like if we rely on the "provides" semantics. You see how this works even if say, haskell-containers is moved out of the ghc set? Our deps will continue to be correct. We should never have relied on cabal2arch to fake "provides" in the first place :) The key now will be ensuring that GHC's provides list is 100% accurate. # Contributor: Arch Haskell Team <arch-haskell(a)haskell.org> # Package generated by cabal2arch 0.7 # Note: we list all package dependencies. # Your package tool should understand 'provides' syntax # pkgname=xmonad pkgrel=1 pkgver=0.9 pkgdesc="A tiling window manager" url="http://hackage.haskell.org/package/xmonad" license=('custom:BSD3') arch=('i686' 'x86_64') makedepends=() depends=('gmp' 'ghc' 'haskell-cabal' 'haskell-x11>=1.4.6.1' 'haskell-containers' 'haskell-directory' 'haskell-filepath' 'haskell-mtl' 'haskell-process' 'haskell-unix') options=('strip') source=(http://hackage.haskell.org/packages/archive/xmonad/0.9/xmonad-0.9.t… install=xmonad.install md5sums=('5ec4ec7b6ab1ec841ceca07184a28ba7') build() { cd ${srcdir}/xmonad-0.9 runhaskell Setup configure --prefix=/usr --docdir=/usr/share/doc/${pkgname} || return 1 runhaskell Setup build || return 1 runhaskell Setup haddock || return 1 runhaskell Setup register --gen-script || return 1 runhaskell Setup unregister --gen-script || return 1 install -D -m744 register.sh ${pkgdir}/usr/share/haskell/$pkgname/register.sh install -m744 unregister.sh ${pkgdir}/usr/share/haskell/$pkgname/unregister.sh install -d -m755 $pkgdir/usr/share/doc/ghc/libraries ln -s /usr/share/doc/${pkgname}/html ${pkgdir}/usr/share/doc/ghc/libraries/xmonad runhaskell Setup copy --destdir=${pkgdir} || return 1 install -D -m644 LICENSE ${pkgdir}/usr/share/licenses/$pkgname/LICENSE || return 1 rm -f ${pkgdir}/usr/share/doc/${pkgname}/LICENSE }

4 4

Arch Haskell Policy Proposal
by Don Stewart 20 Jan '10

20 Jan '10

So, the big question for the team is what versions of packages we support and where. 1. Should Arch track the newest version of every Hackage package, in [extra], [community] or AUR? (the current behaviour, mostly) OR 2. Should Arch provide the binary Haskell Platform set in [extra] and [community] (+ any other popular executables), and the newest version of everything else that forms a coherent install plan, in AUR. Most other distros are trying to support the first half of 2. That is, they provide only what the Haskell Platform specifies (e.g. ghc 6.10.4 + other things), in binary form. Currently, we have a mixture of 6.12 + ad hoc set of packages in binary form, plus AUR is the latest of everything that I can construct a coherent install plan for [1]. This is a pressing issue, since the move to 6.12 has broken a lot of things -- mostly since the HP isn't moving to 6.12.x until 6.12.1 is out, and thus many libraries and tools aren't ready to support 6.12. This will likely break many things for a few weeks at least. I propose the following: * Arch Linux supports precisely the Haskell Platform spec, in its binary repos. * AUR supports the latest version of a maximal install plan from Hackage, separately. The consequence of this policy will be that no binary packages are upgraded until the HP is updated. This should make vegai's work easier. ** It would also mean downgrading ghc 6.12 back to 6.10.4 ** If there is consensus, we can adopt this as policy, refer to it on the website. Users who wish newer versions of things (such as ghc 6.12) can use AUR packages. -- Don [1]: A 'coherent install plan' is the largest set of hackage packages that build together, depending only on one unique version for each library. (That is no QC1 + QC2. Pick one!)

5 7

cabal2arch and clutter
by Xyne 19 Jan '10

19 Jan '10

Hi, Would it be possible to add an option to cabal2arch to prevent it from creating files outside of the directory which contains the PKGBUILD and install file (i.e. "link", "title", "desc", the source tarball and the cabal file)? Tangentially, is all of the necessary metainformation contained in the cabal file, or does cabal2arch require further information contained in the source tarball? I found it strange that it downloaded the latter. Presuming that the cabal file contains all the necessary information, I would really prefer it if cabal2arch could simply read the file remotely without saving it and then generate the directory with the PKGBUILD and install file, and nothing else. I ask this because I'm considering adding cabal support to bauerbill, which is a full yaourt replacement with additional features such as integrated support for building repo packages froms source. I am hoping to use cabal2arch to do this but I do now want to deal with the clutter that it creates as all I require are the PKGBUILD and install file. I do not want to implement my own "cabal2arch" though because it seems silly to duplicate the effort and then have to monitor changes in cabal2arch for compatibility. Also, as issues with yaourt have been previously mentioned, along with a mention of paktahn as an alternative, I invite you all to try bauerbill, which you can find here: http://xyne.archlinux.ca/info/bauerbill http://bbs.archlinux.org/viewtopic.php?id=88247 All feedback and suggestions are welcome. Additionally, please consider changing the cabal2arch help message as it does not describe what cabal2arch actually does: cabal2pkg: [-h|--help] [directory|url] Generate PKGBUILD to stdout for .cabal file in <directory> or at <url> Finally, the dependencies array does not specify minimum versions as specified in the cabal file, e.g. "Cabal-Version >= 1.2" does not translate to "haskell-cabal>=1.2". I realize that this example is trivial as haskell-cabal is already at a later version, but should this not be remedied to prevent possible issues in the future? I'm sorry that I haven't supplied any patches, but I'm still only just beginning to learn haskell and I doubt that any patches that I submit at this point would save more effort than their review would require. Regards, Xyne

3 7

Why is haskell-utf8-string installed?
by Magnus Therning 19 Jan '10

19 Jan '10

I suspect this is a bug in pacman, but would really like someone else to confirm that I'm not just confused ;-) I just removed all my haskell-related packages and re-installed the bare minimum I need: % sudo pacman -Rncs ghc % sudo pacman -S xmonad-contrib After this I find that I have two versions on utf8-string: % ghc-pkg list|grep utf8 utf8-string-0.3.4 utf8-string-0.3.6 That seems a bit strange to me so I had a look at the packages. First I confirmed that ghc provides utf8-string, which it does, version 0.3.4. Then I took a look at haskell-utf8-string (the package, version 0.3.6): % pacman -Qi haskell-utf8-string|grep Required Required By : haskell-x11-xft xmonad-contrib However, having a look at both haskell-x11-xft and xmonad-contrib it looks like they don't have a dependency that requires 0.3.6 to be installed: % pacman -Qi haskell-x11-xft|grep Depends Depends On : ghc=6.12.1 haskell-x11=1.5.0.0 haskell-utf8-string>=0.3 % pacman -Qi xmonad-contrib|grep Depends Depends On : xmonad=0.9.1 sh haskell-x11-xft=0.3 haskell-utf8-string So, why does pacman insist on installing haskell-utf8-string, when it doesn't really have to? Does pacman not use Provides properly in its dependency resolution? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 3

darcs patch: Handle change in doc location in GHC 6.12
by magnus＠therning.org 18 Jan '10

18 Jan '10

Sat Jan 16 07:35:39 GMT 2010 magnus(a)therning.org * Handle change in doc location in GHC 6.12

3 2

cabal2arch 0.6: now builds haddocks for libraries
by Don Stewart 18 Jan '10

18 Jan '10

http://aur.archlinux.org/packages.php?ID=17471 Thanks Magnus for the patch. Note this means ghc <=> haddock need to stay in sync. -- Don

2 3

Policy change in cabal2arch wrt. "provides"
by Don Stewart 18 Jan '10

18 Jan '10

Hey all, After some discussion on the IRC channel, I've changed the policy in cabal2arch wrt. "provides". That is, whether to list explicitly all dependencies on a package -- even those provided in the GHC bundle. Not listing things is convenient -- as it means that tools that don't understand 'provides' will work. However, it means we have to update cabal2arch on every major GHC release. And all the PKGBUILDs!! Listing all dependencies, then relying on tools to readd the provides field of GHC and get it right, means we do *zero* work when a GHC major release happens -- since libs can move in and out of the provides set without problems. So that is now the policy, and the upcoming cabal2arch update will generate PKGBUILDS including the following deps (as needed): -- Official Provides: http://repos.archlinux.org/wsvn/packages/ghc/repos/extra-x86_64/PKGBUILD -- ,Dependency (PackageName "array") (ThisVersion (Version [0,3,0,0] [])) -- ,Dependency (PackageName "bytestring") (ThisVersion (Version [0,9,1,5] [])) -- ,Dependency (PackageName "Cabal") (ThisVersion (Version [1,8,0,2] [])) -- ,Dependency (PackageName "containers") (ThisVersion (Version [0,3,0,0] [])) -- ,Dependency (PackageName "directory") (ThisVersion (Version [1,0,1,0] [])) -- ,Dependency (PackageName "extensible-exceptions") (AnyVersion) -- ,Dependency (PackageName "filepath") (ThisVersion (Version [1,1,0,3] [])) -- ,Dependency (PackageName "haskell98") (ThisVersion (Version [1,0,1,1] [])) -- ,Dependency (PackageName "hpc") (ThisVersion (Version [0,5,0,4] [])) -- ,Dependency (PackageName "old-locale") (ThisVersion (Version [1,0,0,2] [])) -- ,Dependency (PackageName "old-time") (ThisVersion (Version [1,0,0,1] [])) -- ,Dependency (PackageName "pretty") (ThisVersion (Version [1,0,1,1] [])) -- ,Dependency (PackageName "process") (ThisVersion (Version [1,0,1,2] [])) -- ,Dependency (PackageName "random") (ThisVersion (Version [1,0,0,2] [])) -- ,Dependency (PackageName "syb") (ThisVersion (Version [0,1,0,2] [])) -- ,Dependency (PackageName "template-haskell") (ThisVersion (Version [2,4,0,0] [])) -- ,Dependency (PackageName "time") (ThisVersion (Version [1,1,4] [])) -- ,Dependency (PackageName "unix") (ThisVersion (Version [2,4,0,0] [])) -- utf8-string It will continue to **NOT** list these: ,Dependency (PackageName "base") (ThisVersion (Version [4,1,0,0] [])) ,Dependency (PackageName "dph-base") (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "dph-par" ) (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "dph-prim-interface") (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "dph-prim-par" ) (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "dph-prim-seq" ) (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "dph-seq" ) (ThisVersion (Version [ 0,3 ] [] )) ,Dependency (PackageName "ghc") (AnyVersion) ,Dependency (PackageName "ghc-prim") (AnyVersion) Which are all "magic" Now, we will need a list of package tools that don't support "provides" to not recommend. And I will have cabal2arch insert a comment regarding our requirement to support "provides" Comments? -- Don

1 0