February 2010 - arch-haskell

Current status
by Don Stewart 19 Feb '10

19 Feb '10

http://archhaskell.wordpress.com/2010/02/19/arch-haskell-news-february-2010/ vegai: we need to do the parsec 2 "downgrade". Cheers, Don

1 0

[jgm@berkeley.edu: Re: Pandoc restriction for Parsec <3]
by Don Stewart 17 Feb '10

17 Feb '10

The main user of parsec -- pandoc -- is *not* going to move to parsec 3, since it is twice as slow. That means that neither is the Haskell Platform That means that we should downgrade to parsec 2 on arch and *not move to parsec 3 for the foreseeable future*. -- Don ----- Forwarded message from John MacFarlane <jgm(a)berkeley.edu> ----- Date: Mon, 15 Feb 2010 16:59:32 -0800 From: John MacFarlane <jgm(a)berkeley.edu> To: Don Stewart <dons(a)galois.com> Cc: Peter Simons <simons(a)cryp.to> Subject: Re: Pandoc restriction for Parsec <3 Don, Peter Simons says that pandoc won't build on arch because parsec 2 is not available there, and pandoc depends on parsec < 3. I don't want to change that dependency, because when compiled against the current parsec 3, pandoc is about twice as slow as when compiled against parsec 2. Peter proposes uploading a new 'open-pandoc' package with the parsec restriction removed. I think that will just confuse users who want to install pandoc; a better solution, obviously, would be for parsec 2 to be made available on Arch. I don't know why it wouldn't be; after all, parsec 2 is (last I checked) still the version in the Haskell platform, and the default for cabal-install; and many Hackage packages besides pandoc depend on parsec < 3. So I thought I'd ping you to see what the story is; please cc Peter in your reply... John +++ Peter Simons [Feb 16 10 01:47 ]: > Hi John, > > > Suppose you're using pandoc in a web app that delivers up hundreds of > > pages, some quite long. > > if you do that, Pandoc is a mission-critical component in your setup and > it's fine to dedicate extra effort to, say, building it with Parsec 2. > For occasional users like me, however, the difference in performance is > hardly measurable. > > > >> Well, if you don't want your software to work on ArchLinux, then this is > >> the way to go. It's your choice. > > > > It's not my fault that it doesn't work on Arch. > > Of course it is. You deliver a cabal file that refuses to build Pandoc > with Parsec 3, even though it would build just fine! Who else do you > think should be responsible for that? > > Anyway, I have found a solution that should work. I'll fix Pandoc's > Cabal file and upload that version to Hackage calling it, say > open-pandoc. The automatic cabal2arch converter will make that package > available in ArchLinux within a couple of days, and then everything will > be fine. > > Take care, > Peter ----- End forwarded message -----

2 3

MissingH breakage
by Thomas Girod 16 Feb '10

16 Feb '10

hi there. MissingH is in conflict with haskell-quickcheck : Setup: At least the following dependencies are missing: QuickCheck >=1.0 && <2.0, regex-compat -any, testpack -any Is there a way to avoid the problem ? thomas

3 4

Hackage support in bauerbill & follow-up on cabal2arch
by Xyne 16 Feb '10

16 Feb '10

Hi, I've added preliminary support for Hackage to Bauerbill. The following now work: "bauerbill -S --hackage [pkgs]" : build [pkgs] directly from Hackage* "bauerbill -Si --hackage [pkgs]" : look up information about [pkgs] "bauerbill -Ss --hackage [args]" : search for [args] "bauerbill -Qu --hackage" : list upgradable Hackage packages * with dependency resolution and build dependency tracking and removal I've only run a few simple tests so far and I haven't announced this on my site or on the forum yet. I'm waiting because I still have some issues with cabal2arch which I hope can be solved before I push ahead (see below, although I suppose what follows mostly concerns Don). Btw, for now at least, if you enable AUR support as well (--aur) then AUR packages take precedence over Hackage packages. The reasoning is that AUR packages are more likely to be consistent as they're managed by arch-haskell and thus have some human oversight. This may change later if it's deemed move useful to give precedence to Hackage when both are enabled. Feedback and bug reports are always welcome. Don, I've updated to the latest version of cabal2arch and I've noticed that most of the clutter is gone. I appreciate the changes and consider them to be a great improvement, but it still creates an archive of the build directory which I neither need nor want. I would like to make the following suggestions: *) add an option to create the archive of the build directory and suppress it by default so that cabal2arch only create the build dir with the PKGBUILD and install file when run with no options *) add an option to create the PKGBUILD and install file in the current working directory, and create nothing else *) enable batching of multiple cabal files, so that it can accept multiple URLs and paths on the command line (including paths to directories which contain multiple cabal files) I've also noticed that it downloads source files from Hackage. Is that just to get the checksums for the archive? If so, it seems rather wasteful. Would it not be possible to provide that information in the cabal file or via a web API on Hackage? If it is not possible to create the PKGBUILD without the source archive, please add an option to first check if the source archive exists in the build directory and mirror it if it doesn't. This would prevent redundant downloads when building packages (which saves time and bandwidth for all involved). Bauerbill in particular would benefit from this by being able to handle the downloads itself (e.g. in parallel). It could also preserve them between build sessions and mirror them to only update when necessary. Apropos the availability of information from Hackage, the Hackage backend of Bauerbill currently uses the log and pkg-list.html (in /packages/archives/) to create a plain-text database of all packages on Hackage. You can view the "database" file created by bauerbill (/tmp/bauerbill/hackage/hackage_db by default). This file is smaller than both the log and pkg-list.html and follows the line format <name> <version> <category> <type>: <synopsis> Would it be possible to generate this file directly on Hackage? Again, this would save bandwidth and it would also enable control over the versions built by Bauerbill. Currently it tracks the latest versions by simple parsing of the log. If the database file were instead provided then it would use whichever versions it contained. This would make it possible to specify which versions should be built. I don't know if this would be an issue but version compatibility does seem to come up quite often. Of course even if it isn't an issue, it would still be beneficial to provide such a plain-text file which applications such as Bauerbill could use. One final niggle: cabal2arch doesn't understand relative paths to parent directories, e.g. "../cabal/foo.cabal". Sorry for the long message with several suggestions/requests. I hope they're considered reasonable and not too difficult to implement. I would particularly appreciate the option to use local source files to avoid redundant downloads and the option to suppress creation of the build dir archive. Many thanks if you can do this. Regards, Xyne p.s. Would it be useful to be able to rebuild all Hackage packages with a simple command? If cabal2arch placed Hackage packages in a group, I could easily add a "--rebuild-group" option to Bauerbill. I'm asking because I don't actually know if this would be useful

4 6

bytestring-lexing
by Magnus Therning 14 Feb '10

14 Feb '10

There are two problems with getting bytestring-lexing compiled on Arch, since Don tends to read in here I'll report both here: 1. The PKGBUILD lacks a dependency on 'alex', I'm guessing a 'makedepends' would suffice. 2. Generating the documentation fails. Cheers, M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 3

Unable to build haskell-franchise from AUR
by Wei Hu 05 Feb '10

05 Feb '10

Hi, Did anyone succeed in building haskell-franchise with ghc 6.12? The PKGBUILD was updated on Jan 30, which seems to suggest we should be able to build it.

1 0

[donotreply@wordpress.com: [Arch Linux and Haskell] Please moderate: "Arch Linux Updates to GHC 6.12"]
by Don Stewart 03 Feb '10

03 Feb '10

----- Forwarded message from "WordPress.com" <donotreply(a)wordpress.com> ----- Date: Wed, 3 Feb 2010 00:19:04 +0000 From: "WordPress.com" <donotreply(a)wordpress.com> To: dons(a)cse.unsw.edu.au Subject: [Arch Linux and Haskell] Please moderate: "Arch Linux Updates to GHC 6.12" A new comment on the post #274 "Arch Linux Updates to GHC 6.12" is waiting for your approval http://archhaskell.wordpress.com/2010/01/31/arch-linux-updates-to-ghc-6-12/ Author : sargon (IP: 86.103.203.159 , 159-203-103-86.dynamic.dsl.tng.de) E-mail : danielehlers(a)mindeye.net URL : Whois : http://ws.arin.net/cgi-bin/whois.pl?queryinput=86.103.203.159 Comment: It first seems to be fine that we now have 6.12, but under the fact that many of the tools and library's haven't adopted this ghc release and the big red stop on the ghc download page for 6.12 it seems unwary. Personally, I currently develop some apps which use gtk2hs and c2hs, which both didn't build with stable releases or in the case of c2hs only with some handwork, but also parts of code running fine with 6.10 didn't build with 6.12. But enough blubbering, is there any way to have 6.10 back or maybe aside from 6.12. Approve it: http://archhaskell.wordpress.com/wp-admin/comment.php?action=approve&c=157 Trash it: http://archhaskell.wordpress.com/wp-admin/comment.php?action=trash&c=157 Spam it: http://archhaskell.wordpress.com/wp-admin/comment.php?action=spam&c=157 Currently 1 comment is waiting for approval. Please visit the moderation panel: http://archhaskell.wordpress.com/wp-admin/edit-comments.php?comment_status=… ----- End forwarded message -----

2 1

parsec troubles
by Don Stewart 01 Feb '10

01 Feb '10

The version of parsec in [extra] is 3.x, which isn't part of the Haskell Platform. This means a lot of stuff doesn't build :/ Are there any apps (darcs??) that need parsec3? If not, we should switch to parsec 2 vegai? -- Don

3 5