January 2014 - arch-haskell

additions to ghc's provides list?
by Peter Johnson 01 Mar '14

01 Mar '14

Since the Arch ghc package includes binaries for hsc2hs and haddock, should these be added to the "provides=" list in its PKGBUILD? pete

2 1

No updates for a little while
by Magnus Therning 05 Feb '14

05 Feb '14

Hi all! Unfortunately my current computer situation means I won't be able to make any updates to ArchHaskell until early March. I'm looking into options for getting my hands on an ArchLinux system, e.g. whether kiwilight is back up, if I succeed I'll get back to pushing out updates earlier. Hopefully the situation will be sorted well in time for the GHC 7.8 release. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

4 5

Simple, general template for cabal packages?
by Jeff Johnson 22 Jan '14

22 Jan '14

Hi everyone! I've been becoming more and more dependent on Haskell programs lately. There aren't many popular ones (yet!), but those that do exist seem uncommonly good and have quickly become core parts of my workflow: pandoc, gitit, git-annex, and hoodle are the main ones so far, plus maybe xmonad. But they also seem idiosyncratic and hard to install: builds often fail, pacman spits tons of errors even when upgrading successfully, you sometimes have to reinstall them all at once to maintain compatibility, etc. I've read these pages: http://comments.gmane.org/gmane.comp.lang.haskell.arch-linux/1743 http://wiki.archlinux.org/index.php/Haskell_package_guidelines And I'm confused about the point of separate [haskell-*] repositories. Why all the overhead? The simplest thing I could imagine working would be a PKGBUILD with a "snapshot" of compatible dependency versions. Then you could do a sandboxed build from scratch each time. Somehing like: _pkgname=hoodle pkgname=$_pkgname-cabal ... makedepends=('cabal-git') # sandboxes introduced in 1.18 _cabaldepends=( ... 'coroutine-object-0.2.0.0' 'hoodle-types-0.2.2' 'xournal-types-0.5.0.2' 'hoodle-builder-0.2.2.0' 'hoodle-parser-0.2.2' 'xournal-parser-0.5.0.2' ... ) build() { ... cabal-git sandbox init cabal-git update cabal-git install $_cabaldepends $_pkgname-$pkgver ... } The only downside would be a lot of compilation, but that could be solved the same way it is for non-Haskell packages: popular ones get adopted into [community]. Does that sound sensible? Or am I on the way to deciding I should contribute to an existing repository? Should I just try it and see? Oh and apologies if this has been answered; I just joined the mailing list. Jeff

2 2

working with HABS
by Linus Arver 19 Jan '14

19 Jan '14

Hello, I want to compile HABS packages with the 'makeahpkg' script but the uses of 'sudo' require me to enter my root password every once in a while. This is annoying because I cannot just do ./makeahpkg -c -- $(cblrepo build base | tail -n +2) and let it run overnight. In fact, at one instance the script just exited on its own because I did not enter the root pasword in time. Is there a workaround for this? Also does anyone have recommendations for web storage services that would work well with hosting my build of HABS packages? I've tried DropBox but the current AUR package for it is unusable, at least with Xmonad. -L

4 4

Improve user experience with Haskell
by Fabien Dubosson 12 Jan '14

12 Jan '14

Hello ArchHaskellers, This thread follows a discussion started on github [1]. Brief summary: The discussion started from a pull request to make `haskell-archlinux` work with GHC 7.6.3. Magnus informed me that this project is nearly abandoned and asked for my usage of it. I answered that my goal was to write an Haskell tool to monitor AUR `haskell-*` packages because a lot are outdated/orphan. Then Magnus explained me that you decided to drop AUR support some years ago. Finally I gave the reasons of my original idea and we agreed to port the discussion here. The original observation that brings me planning to monitor AUR packages came from the forum. People continue to use AUR packages (or even cabal) for Haskell because they don't know that an ArchHaskell effort exist to bring, in a clean way, Haskell packages to Archlinux. For me, the two reasons are 1. all old `haskell-*` packages still exist in AUR, and 2. the informations about [haskell-core] repo are «hidden» in the Haskell packaging guidelines page in the wiki — not an obvious place for normal users. So to improve user experience with Haskell I suggest two improvements: 1. Create a `Haskell` page in the wiki to explain: - What is Haskell - The different ways to handle packages (AUR/Cabal/ArchHaskell) - All other Haskell-related stuffs (Haskell-platform, etc...) 2. Remove from AUR all `haskell-*` packages that are both: - Not needed as dependency of another package, and - Orphan So any observations, objections, suggestions, recommendations before I start to work on that (i.e. create the wiki page and prepare the list)? Kind regards, Fabien [1] https://github.com/archhaskell/archlinux/pull/14

4 6