On Fri, May 11, 2007 at 01:28:59AM +0200, Jérémy Bobbio wrote:
On Tue, May 08, 2007 at 04:27:18PM +0100, Ian Lynagh wrote:
GHC 6.6.1 packages are in Haskell Unsafe (amd64 only, although you can build the source on your arch if you want (please let me know if you try this, regardless of whether it succeeds or fails)):
http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html
In order to smooth the transition, I have spent a quite huge amount of time to rebuild every packages that have a Build-Depends on ghc6 with the version in haskell-unsafe. The packages themselves where not tested, only their build processes.
Great, thanks for this effort, Jérémy!
FTBFS
haskell98-report
This is due to the LaTeX transition, see #420479.
Right, this is unrelated to the new ghc6, as you note.
hdbc
setup: cannot satisfy dependency mtl-any
I don't see how this ever could have built with pbuilder or the like, and from http://buildd.debian.org/pkg.cgi?pkg=hdbc it looks like it never did.
pugs
Module `Control.Monad.RWS' does not export `msum'
This one confuses me. It doesn't look like it should work with 6.6 either (and doesn't in my (unclean) root), but http://buildd.debian.org/pkg.cgi?pkg=pugs claims it did. Anyone know what's going on here?
gtk2hs
zcat: /usr/share/doc/ghc6-doc/html/libraries/base/base.haddock.gz: No such file or directory
The file is no longer compressed; this probably just needs a hack reverted :-)
haskell-edison
Could not find module `Control.Monad.Identity':
This one is because edison tries to build for profiling, but doesn't build-dep on libghc6-mtl-prof.
missingh
ghc-pkg: package filepath-1.0 is already installed
filepath now comes with ghc6, so that's expected.
Unexpected problems due to pbuilder
haskell-cabal haskell-http hslogger happs haskell-hgl
So these aren't ghc6-related, right?
In order to complete the transition to GHC 6.6.1, at least 48 packages will need a sourceful upload in order to update their Build-Depends field to replace "ghc6 (>= 6.6), ghc6 (<< 6.6+)" with "ghc6 (>= 6.6.1), ghc6 (<< 6.6.1+)".
This can be done in an autmated way, though. (e.g. "debian/rules update-generated-files" will do it for my packages)
These uploads will need to be carefully done in the correct order if we want to see theses packages in testing some day...
The auto-dep-wait mechanism should sort this out for us.
Now that Debian has an infrastructure to easily schedule unattented package rebuild (binNMU), I tend to think that it would be better if Haskell packages could benefit from it.
I have a (proverbial) button to do a source upload, but I don't (AFAIK) have a button to do a binNMU (or n binNMUs, where there are n arches). I'm pretty sure (based on past experience) that n binNMUs will require more time and effort than 1 source upload.
I would be glad if someone could remember me the reason of the current technical constraints for this limitation in Build-Depends. :)
Given we're going to be doing source uploads, we may as well restrict them to use the GHC we want, so we don't have to wait for the slow arches to build ghc6 before uploading any libraries (and similarly don't have to wait for tier-1 libraries to build everywhere before uploading tier-2, and so on).
Thanks Ian