January 2011 - arch-haskell

What version of cabal2arch should be used to build HABS?
by Magnus Therning 13 Jan '11

13 Jan '11

My recent commit to HABS[1] revealed that HABS is built using a development (i.e. unreleased) version of cabal2arch. I feel strongly that this practice is wrong and that we should only use the latest released version of cabal2arch to build HABS. Peter just reverted my commit, which arguably is the correct action to take at this point, but I would like to redo my commit ASAP. I'm assuming archlinx and cabal2arch should be released together, so are they in a state where new versions can be released right now? /M [1]: https://github.com/archhaskell/habs/commit/5eda709d3401e2b0d8bea07de6e76e40… -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

2 9

AUR Comment for haskell-haskore
by simons＠cryp.to 13 Jan '11

13 Jan '11

from http://aur.archlinux.org/packages.php?ID=20383 palmfron wrote: also, needs earlier versions of haskell-event-list and haskell-non-negative --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.

1 0

AUR Out-of-date Notification for haskell-haskore
by simons＠cryp.to 13 Jan '11

13 Jan '11

Your package haskell-haskore has been flagged out of date by palmfron [1]. You may view your package at: http://aur.archlinux.org/packages.php?ID=20383 [1] - http://aur.archlinux.org/account.php?Action=AccountInfo&ID=24647

1 0

Most popular Haskell packages based on AUR voting
by Peter Simons 12 Jan '11

12 Jan '11

Hi guys, for your information, AUR allows users to vote for packages. If you a haven't done that yet, you might want to install "aurvote" and run the following command (in bash): aurvote -v $(pacman -Qqm) Anyway, these are our top 50 most popular packages: |---------------------------------+--------------+-------| | Name | Version | Votes | |---------------------------------+--------------+-------| | haskell-opengl | 2.2.3.0-4 | 145 | | haskell-time | 1.2.0.3-2 | 107 | | haskell-cabal | 1.8.0.6-2 | 100 | | haskell-glut | 2.1.2.1-4 | 100 | | haskell-hinotify | 0.3.1-2 | 99 | | haskell-ghc-paths | 0.1.0.8-2 | 88 | | haskell-puremd5 | 2.1.0.3-3 | 85 | | haskell-missingh | 1.1.0.3-2 | 84 | | haskell-haxml | 1.20.2-2 | 74 | | haskell-transformers | 0.2.2.0-2 | 71 | | haddock | 2.8.1-2 | 68 | | haskell-testpack | 2.0.1-2 | 68 | | haskell-uniplate | 1.6-2 | 66 | | haskell-fgl | 5.4.2.3-2 | 64 | | cpphs | 1.11-2 | 63 | | haskell-haskell-src-exts | 1.9.6-2 | 61 | | haskell-xml | 1.3.7-2 | 60 | | haskell-diff | 0.1.2-2 | 58 | | haskell-unix-compat | 0.2-2 | 58 | | haskell-json | 0.4.4-2 | 56 | | haskell-split | 0.1.3-1 | 54 | | haskell-syb | 0.2.2-2 | 54 | | cabal2arch | 0.7.6-5 | 53 | | haskell-zip-archive | 0.1.1.6-3 | 52 | | haskell-pandoc | 1.6-6 | 51 | | haskell-utility-ht | 0.0.5.1-2 | 51 | | haskell-configfile | 1.0.6-2 | 50 | | haskell-curl | 1.3.5-2 | 50 | | haskell-digest | 0.0.0.9-1 | 50 | | haskell-data-accessor | 0.2.1.4-2 | 48 | | haskell-pcre-light | 0.4-2 | 48 | | haskell-regex-tdfa | 1.1.6-2 | 48 | | hscolour | 1.17-2 | 48 | | haskell-fingertree | 0.0.1.0-2 | 46 | | haskell-array | 0.3.0.1-1 | 45 | | haskell-data-accessor-template | 0.2.1.5-2 | 44 | | haskell-safe | 0.3-2 | 44 | | haskell-bytestring | 0.9.1.7-2 | 43 | | haskell-sdl | 0.6.2-2 | 43 | | haskell-rosezipper | 0.2-2 | 42 | | haskell-vty | 4.4.0.0.1-2 | 42 | | haskell-platform | 2010.2.0.0-2 | 40 | | haskell-hsh | 2.0.3-3 | 39 | | haskell-syb-with-class | 0.6.1-2 | 39 | | haskell-strict-concurrency | 0.2.4.1-2 | 38 | | derive | 2.3.0.2-2 | 37 | | haskell-monads-fd | 0.2.0.0-2 | 37 | | haskell-action-permutations | 0.0.0.0-2 | 35 | | haskell-tagsoup | 0.12-1 | 35 | | haskell-data-accessor-monads-fd | 0.2.0.2-2 | 34 | |---------------------------------+--------------+-------| Take care, Peter

1 0

State of Affairs: Summarizing 83 days worth of experience
by Peter Simons 12 Jan '11

12 Jan '11

Hi guys, it's been 83 days since I've begun to actively contribute to the ArchHaskell project. During that period, I've maintained our habs tree. I've seen to it that AUR is in sync with that tree. I've made an effort to compile a repository of binary packages, and I've also addressed all kinds of user feedback and bug reports. Based on that experience, I'd like to take a step back and summarize my overall impression of where this projects stands today. First of all, I believe that our joint efforts have been very worthwhile and successful. habs is in better shape today than it was before. To the best of my knowledge, none of the PKGBUILDs that we publish is outright broken, which is a *major* improvement. Secondly, ArchLinux now complies to the Haskell Platform, which also feels like an important achievement. Furthermore, a fairly large number of small annoyances have been addressed, i.e. we have consistent support for shared linking, our generated PKGBUILD files have been improved in terms of both style and substance, and we've taken on the habit of utilizing $pkgrel to trigger necessary re-builds, which is something our users had to figure out on their own in the past. Given all that, I think we can be a little proud. At the same time, I feel a little pessimistic about the future of our endeavor. When I said "habs" in the previous paragraph, I really meant a subset of habs worth 118 packages that I actively maintain, namely those packages that I personally care about. I didn't even try to keep packages up-to-date that I don't personally care about. Hackage, however, features a whopping total of 2670 packages, which means that I've been actively maintaining less than 5% of Hackage! Now, based on my experience from maintaining 5% of Hackage, I've arrived at the conclusion that our tools and our procedures are quite inadequate to get the job done. Maintaining 118 packages in an orderly fashion has been really difficult. I wouldn't dream of even trying to maintain 2500+ packages that way. The most significant problems I've encountered are: 1) A lack of coordination. We have made a couple of attempts to define policies, procedures, and responsibilities for this project, but ultimately we never really got anywhere. The net result is that everyone of us is working on whatever interests him, but the others mostly don't even know about it. Consequently, we are inefficient. For instance, we develop patches for the ArchLinux library, and when they're ready, we throw them away, because we realize way too late that we don't like what they do. Similarly, we perform updates in [extra], and then we revert them again, because we notice way too late that they break someone else's efforts. It feels like most of the things we've accomplished were being accomplished though individual machismo, rather than through a coordinated team effort. 2) Lack of communication. In my experience, it's incredible hard to get any sort of response from those of us who maintain [extra] and [community]. The packages in those repositories are the foundation on which everything else has to be built. Yet, the packages in those repositories tend to be modified without any consultation or advance warning. In some cases, changes in [extra] broke compilation of other habs packages -- such as cabal2arch --, but for the longest time it was impossible to get anyone to care about that. On the other hand, I've repeatedly asked for packages in [extra] to be updated, because I needed newer versions to build other packages in habs, but those updates just don't happen. Maybe there are good technical reasons why those updates don't happen, but that's beside the point. The point is that I don't know anything about it, and I don't know how to find out either. 3) Inadequate tools. The cabal2arch utility is a great, but in its current shape it cannot re-generate the habs in a fashion that I'd call "automatic". For some packages, such as OpenGL or GLUT, the cabal2arch output is outright broken and doesn't compile. For other packages, such as cabal2arch itself, the generated PKGBUILD compiles but is incorrect anyway, because run-time dependencies are declared as being build-time dependencies. There are several other packages that cannot be generated with cabal2arch, such as haskell-platform, and that need manual editing before they can be published. So far, we have been addressing these problems in a way that feels "ad hoc", to put it mildly. Being a professional software engineer, that makes me quite uncomfortable, because I have the impression that we don't fully understand what it is that we're trying to do. Furthermore, we seem to have no functioning tools that help us automate the updating process. My experience so far is that even the tiniest trivial update has a significant potential to break the build of dozens of other packages. Basically, there seem to be trivial updates in Haskell land. Whenever such breakage occurs, there is no easy way to figure out how to remedy the version conflicts. Doing that manually is quite an effort when 118 packages ought to compile, but remedying those conflicts manually for 2500+ packages is not going to be possible. In my humble opinion, we have to figure out how to improve our team work if we want to succeed at providing a comprehensive set of Haskell packages for ArchLinux. Take care, Peter

4 20

RFC: A new tool for dependencies
by Magnus Therning 11 Jan '11

11 Jan '11

The last few days I've been thinking a bit about dependencies among our packages in HABS. My belief is that it would be beneficial to be able to very quickly see whether a set of packages is consistent in dependencies and therefore ought to compile. Now I may be wrong about this, which is why I'm asking for comments early on. I've only spent about an hour hacking on this so far, I'm confident such a tool is possible (actually rather easy) to make. So, please comment before I waste too much time on something that in fact is useless! The central part is a database of tuples: <name, version, dependencies>. Initially it's populated with the packages that GHC come with (base, array, etc). After that it would basically be used something like this: % pkgdb add http://hackage.haskell.org/packages/archive/dataenc/0.13.0.1/dataenc.cabal Package added, all dependencies satisfied. % pkgdb add http://hackage.haskell.org/packages/archive/dataenc/0.13.0.4/dataenc.cabal Package added, all dependencies satisfied. % pkgdb add http://hackage.haskell.org/packages/archive/nanoparsec/0.1/nanoparsec.cabal Package not added, the following dependencies not satisfied ListLike ==2.0.* base >=4.3 && <5 % pkgdb deps dataenc array >=0.1.0 && <0.4 base >=3.0.0 && <4.4 containers >=0.1.0 && <0.5 % pkgdb reqby base dataenc In short, it would make sure that the set of packages in the database is consistent at all times, and it would offer some querying functionality. Some problems: - not all CABAL files specify the complete set of dependencies (as highlighted in a few bug on cabal2arch[1]) - dependencies on non-Haskell packages isn't tracked, so it's very possible to add a package to the database that wouldn't actually compile on an Arch system because a C library is of the wrong version Possible extensions: - hooking it up to cabal2arch (e.g. by generating output that can be consumed by it) for generating PKGBUILDs and .install files So, what are your thoughts. Should I continue hacking on this? /M [1] https://github.com/archhaskell/cabal2arch/issues#issue/22 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

2 2

AUR Comment for hpong
by simons＠cryp.to 11 Jan '11

11 Jan '11

from http://aur.archlinux.org/packages.php?ID=26171 luinuz wrote: I'm using only AUR haskell packages. Updated with complete output in http://aur.pastebin.com/N83wR7GA Thanks! --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.

1 0

On datafiles in libraries
by Magnus Therning 10 Jan '11

10 Jan '11

I've just created issue 20[1] for cabal2arch. Basically there's a problem with the data files provided in archlinux, but used in cabal2arch. Having data files in a library package breaks our basic assumption that executables only need to makedepend on the libraries it uses. In this case I still think that we should remove the data files completely from the packages and only host them at a well-known URL (on kiwilight.com or haskell.org) cabal2arch should then default to use that URL, for development and testing it might be interesting to add a command line switch to load it from another location, a URL or file. For now I assigned the issue to Remy. Feel free to re-assign it if you want to. This is a larger issue though and in the future we may have to revisit the assumption. I have a feeling that using shared objects (dynamic libraries) will force us to change it anyway. /M [1] https://github.com/archhaskell/cabal2arch/issues#issue/20 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

4 10

AUR Comment for hpong
by simons＠cryp.to 09 Jan '11

09 Jan '11

from http://aur.archlinux.org/packages.php?ID=26171 peti wrote: Hi Luinuz, after reading Magus posting, I tried running the build locally, too, and I believe he is right. The package did compile successfully for me, too. I have posted a complete build log at <http://aur.pastebin.com/N83wR7GA>. If you still get those errors, then it's probably because of some other problem in your installation. Could you please post a complete build log, so that we can see what versions of the dependent libraries are chosen? --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.

1 0

AUR Comment for hpong
by simons＠cryp.to 09 Jan '11

09 Jan '11

from http://aur.archlinux.org/packages.php?ID=26171 magus wrote: I'm not so sure about that. I just successfully built hpong in a clean chroot (with some packages from the [archhaskell] repo). --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.

1 0