October 2010 - arch-haskell

habs updates
by Peter Simons 02 Nov '10

02 Nov '10

Hi guys, the following commits updates a hand full of habs packages to the latest available versions: http://github.com/archhaskell/habs/commit/78b2f329c3b2e5692a40832da3fce2f6c… These files have been generated with the latest tool-chain, which comes with several updates: * the original cabal name of every package is available as ${_hkgname}, * the generated uninstall.sh hook uses --force to avoid warnings during updates, * packages provided by GHC are no longer listed as dependencies, and * our attribution header of choice these days is "Maintainer:". I have tested the changes extensively, and everything seems to work fine. If there is no objection, I would like to upload these updated packages to AUR. Take care, Peter

3 8

What to do about --enable-shared?
by Peter Simons 01 Nov '10

01 Nov '10

Hi guys, I've made some tests with --enable-shared, and the good news is that it works great. The bad news is that Cabal doesn't honor the flag when building executables. Apparently, this is a known issue: http://hackage.haskell.org/trac/hackage/ticket/600 A work-around that has been suggested is to specify --ghc-opt=-dynamic for builds that contain executables, but this solution feels kind of hack'ish. On the other hand, shared linkage cuts down binary size a lot, which is good. How do you feel about this issue? Any preferences? Take care, Peter

4 5

Replacing the current comment with a Maintainer field
by Peter Simons 30 Oct '10

30 Oct '10

Hi guys, how do you feel about this patch to the archlinux repository? Would anyone mind if I'd make that change? Take care, Peter

2 3

Gmane mirrors this list as gmane.comp.lang.haskell.arch-linux
by Peter Simons 28 Oct '10

28 Oct '10

Hi guys, gmane.org mirrors this mailing list, and makes it available to the public via NNTP, which means that you can access the list using your favorite news reader at news.gmane.org. The corresponding newsgroup is called "gmane.comp.lang.haskell.arch-linux". Take care, Peter

1 0

Mysterious build errors
by Peter Simons 27 Oct '10

27 Oct '10

Hi, I've seen the following strange build errors a few times now, but I am at a loss how to explain it. Can someone help me? I run a clean build using Remy's toolchain as follows: scripts/setup-chroots && manycabal2arch PKGLIST ~/.cabal/packages/hackage.haskell.org/00-index.tar habs && sudo ./makeworld The build fine for the most part, until ... | ==> Making package: haskell-haxml 1.20.2-1 (Sun Oct 24 12:24:41 UTC 2010) | ==> Checking Runtime Dependencies... | ==> Installing missing dependencies... | resolving dependencies... | looking for inter-conflicts... | | Targets (1): haskell-polyparse-1.4-1 | | Total Download Size: 0.00 MB | Total Installed Size: 2.34 MB | | Proceed with installation? [Y/n] | checking package integrity... | :: File haskell-polyparse-1.4-1-i686.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] | error: failed to commit transaction (invalid or corrupted package) | haskell-polyparse-1.4-1-i686.pkg.tar.xz is invalid or corrupted | Errors occurred, no packages were upgraded. | ==> ERROR: 'pacman' failed to install missing dependencies. | Build failed, check /home/simons/src/archhaskell-build/chroot-i686/copy/build | Begin building haskell-non-negative... | :: Synchronizing package databases... | core is up to date | extra is up to date | community is up to date | repo is up to date | :: Starting full system upgrade... | there is nothing to do The thing is, though, that haskell-polyparse *is* available. It was build before haskell-haxml, and the build log shows no errors: | Begin building haskell-polyparse... | :: Synchronizing package databases... | core is up to date | extra is up to date | community is up to date | repo 1.4K 4.7M/s 00:00:00 | :: Starting full system upgrade... | there is nothing to do | ==> Making package: haskell-polyparse 1.4-1 (Sun Oct 24 12:15:30 UTC 2010) | ==> Checking Runtime Dependencies... | ==> Checking Buildtime Dependencies... | ==> Retrieving Sources... | -> Found polyparse-1.4.tar.gz | ==> Validating source files with md5sums... | polyparse-1.4.tar.gz ... Passed | ==> Extracting Sources... | -> Extracting polyparse-1.4.tar.gz with bsdtar | ==> Starting build()... | Configuring polyparse-1.4... | Preprocessing library polyparse-1.4... | Building polyparse-1.4... | [ 1 of 11] Compiling Text.ParserCombinators.HuttonMeijerWallace ( src/Text/ParserCombinators/HuttonMeijerWallace.hs, dist/build/Text/ParserCombinators/HuttonMeijerWallace.o ) | [ 2 of 11] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o ) | [ 3 of 11] Compiling Text.ParserCombinators.Poly.Base ( src/Text/ParserCombinators/Poly/Base.hs, dist/build/Text/ParserCombinators/Poly/Base.o ) | [ 4 of 11] Compiling Text.ParserCombinators.Poly.Plain ( src/Text/ParserCombinators/Poly/Plain.hs, dist/build/Text/ParserCombinators/Poly/Plain.o ) | [ 5 of 11] Compiling Text.ParserCombinators.Poly.Lazy ( src/Text/ParserCombinators/Poly/Lazy.hs, dist/build/Text/ParserCombinators/Poly/Lazy.o ) | [ 6 of 11] Compiling Text.ParserCombinators.Poly.State ( src/Text/ParserCombinators/Poly/State.hs, dist/build/Text/ParserCombinators/Poly/State.o ) | [ 7 of 11] Compiling Text.ParserCombinators.Poly.StateLazy ( src/Text/ParserCombinators/Poly/StateLazy.hs, dist/build/Text/ParserCombinators/Poly/StateLazy.o ) | [ 8 of 11] Compiling Text.ParserCombinators.Poly ( src/Text/ParserCombinators/Poly.hs, dist/build/Text/ParserCombinators/Poly.o ) | [ 9 of 11] Compiling Text.Parse ( src/Text/Parse.hs, dist/build/Text/Parse.o ) | [10 of 11] Compiling Text.ParserCombinators.Poly.ByteString ( src/Text/ParserCombinators/Poly/ByteString.hs, dist/build/Text/ParserCombinators/Poly/ByteString.o ) | [11 of 11] Compiling Text.Parse.ByteString ( src/Text/Parse/ByteString.hs, dist/build/Text/Parse/ByteString.o ) | Registering polyparse-1.4... | Running Haddock for polyparse-1.4... | Preprocessing library polyparse-1.4... | Warning: The documentation for the following packages are not installed. No | links will be generated to these packages: ffi-1.0, rts-1.0 | Warning: Text.ParserCombinators.HuttonMeijerWallace: could not find link destinations for: | Text.ParserCombinators.HuttonMeijerWallace.ParseResult | Warning: Text.ParserCombinators.HuttonMeijer: could not find link destinations for: | Text.ParserCombinators.HuttonMeijer.Token | Documentation created: dist/doc/html/polyparse/index.html | Creating package registration script: register.sh | Unregistering polyparse-1.4... | ==> Entering fakeroot environment... | ==> Starting package()... | Installing library in /build/pkg/usr/lib/polyparse-1.4/ghc-6.12.3 | ==> Tidying install... | -> Purging other files... | -> Compressing man and info pages... | -> Stripping unneeded symbols from binaries and libraries... | ==> Creating package... | -> Generating .PKGINFO file... | -> Adding install script... | -> Compressing package... | ==> Leaving fakeroot environment. | ==> Finished making: haskell-polyparse 1.4-1 (Sun Oct 24 12:17:33 UTC 2010) | ==> Extracting database to a temporary location... | ==> Adding package 'haskell-polyparse-1.4-1-i686.pkg.tar.xz' | -> Creating 'desc' db entry... | -> Computing md5 checksums... | -> Creating 'depends' db entry... | ==> Creating updated database file 'repo.db.tar.gz' | Begin building haskell-safe... | :: Synchronizing package databases... | core is up to date | extra is up to date | community is up to date | repo 1.6K 4.7M/s 00:00:00 | :: Starting full system upgrade... | there is nothing to do Now, the error is gone when I run "makeworld" *again*. It appears that this problem occurs every time I perform a clean build from scratch. An incremental build, i.e. one that's run with a previously existing sandbox, however, seems to work. Does anyone know to explain that? Could there be a race condition somewhere? Take care, Peter

1 1

AUR Comment for haskell-numeric-prelude
by simons＠cryp.to 26 Oct '10

26 Oct '10

from http://aur.archlinux.org/packages.php?ID=20274 peti wrote: Hi guys, when you see this e-mail, then our brand-new mail reflector for AUR comments is working okay. Basically, all e-mail sent to the address of the arch-haskell user is forwarded to a little script that performs a strict regular expression match to determine whether the e-mail is actually an AUR comment. If the mail passes that test, it is forwarded on to the list. If the message doesn't match the expression, then it's sent to me (Peter) instead. This way, people can reach us via comments, but they cannot use the "Forgot Password" link to have our password posted to the list and subsequently show up in the public mail archives. If there are any suggestions where bogus e-mails ought to be forwarded to, please let me know. Take care, Peter --- 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

[archhaskell-build] script to set $pkgrel in generated files from value in PKGLIST
by Peter Simons 24 Oct '10

24 Oct '10

It's simple enough, but here is the patch. :-)

1 0

How to update packages in extra?
by Peter Simons 23 Oct '10

23 Oct '10

Hi, the PKGBUILD files in "extra" have been generated with ancient versions of cabal2arch, like 0.4.1, and because of that they lack features such as the generation of Haddock reference documentation. Is there any way for us to update those files? Who has the ability to do that? Take care, Peter

6 25

Binary repo for haskell-platform (64 bit)
by Magnus Therning 23 Oct '10

23 Oct '10

I've put up a binary repo with packages that are part of HP, but are missing in [extra]/[community]. They are 64-bit only (mainly because I haven't bothered looking into setting up a 32-bit chroot yet :-). Enjoy! [archhaskell] Server = http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64 /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 2

Thoughts on Procedure
by Peter Simons 22 Oct '10

22 Oct '10

Hi guys, in my understanding, our current update procedure works like this: 1) We notice that a package was updated (or added) on Hackage by means of RSS. 2) A maintainer runs cabal2arch to generate an updated PKGBUILD. 3) If the generated PKGBUILD looks good, the file is committed to the Git repository and uploaded to AUR. There are a few things worth noting about that procedure: - A maintainer must perform 1 manual step per updated package: that is linear complexity O(n). - There is no mechanism to guarantee that the updated set of PKGBUILD files actually works. - It's common practice to use version control systems like Git to track original source code. Our setup, however, tracks generated files: the PKGBUILDs are produced automatically by cabal2arch. So why do we track them? Shouldn't we rather track the Cabal files? Naturally, one wonders how to improve the update process. There are a few possible optimizations: - The simplest way to verify whether all PKGBUILDs compile is to, well, compile them. Given a set of updated packages, all packages that directly or indirectly depend on any of the updated packages need re-compilation, and the current set of PKGBUILDs is to be considered valid only if all those builds succeed. - It is possible to download the entire state of Hackage in a single tarball. Given all the Cabal files, a Makefile can automatically re-generate those PKGBUILDs that need updating. The same Makefile can also run the necessary builds, and it also perform the necessary uploads to AUR. Based on these thoughts, I would like to propose an improved procedure for discussion. Let our Git repository track a set of Cabal files. Then an update would work like this: 1) A maintainer downloads http://hackage.haskell.org/packages/archive/00-index.tar.gz and extracts the Cabal files into a checked-out Git repository. 2) Optionally, inspect changes with "git status" and "git diff". 3) Run "make all" to re-build all PKGBUILD files that need updating. 4) Run "make check" to perform all necessary re-builds of binary packages. If all builds succeed, proceed with (5). Otherwise, figure out which package broke the build and revert the changes in the corresponding Cabal file. Go back to (3). 5) Run "make upload" and "git commit" the changes. Now, this procedure is supposed to update AUR, but "make upload" can be easily extended to copy the generated packages into a binary repository as well. The worst case scenario occurs when every single available update breaks during "make check". In that case, the procedure has linear complexity O(n). The best case scenario, on the other hand, is the one where every single update succeeds. That case is handled by running "make all && make check && make upload", which gives constant complexity O(1). More importantly, however, the "make check" phase would guarantee that we never ever publish a configuration that doesn't compile. How do you feel about the idea? Take care, Peter

4 19