Hi all,
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
Currently the only extralib packaged is mtl (libghc6-mtl-{dev,prof,doc}). More will probably follow soon.
Note that these packages may not be what end up being uploaded to Debian, and they are barely tested at all. Yada yada standard no disclaimer stuff.
Thanks Ian
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.
The unexpected amount of work required by what could be seen as a very basic task inspired some thoughts wrote at the end of this mail.
My setup for this builds was the following: * pbuilder with a sid chroot, * after adding haskell-unsafe as another apt source, ghc6 was installed into the chroot, * MadCoder's scripts where used to easily build packages on top of previously built packages [1].
[1] http://blog.madism.org/index.php/2006/06/27/93-pbuilder-custom-configuration...
Here's the summary of my results:
Build without errors --------------------
alex bnfc c2hs cpphs drift frown ghc-cvs ghc6 haddock happy haskell-filepath haskell-hsql haskell-src-exts haskell-utils haskell-uulib haxml helium kaya lhs2tex whitespace
Built successfully after updating Build-Depends for ghc ------------------------------------------------------- (order matters)
haskell-network haskell-opengl haskell-openal haskell-alut haskell-arrows haskell-binary haskell-fgl haskell-haskell-src haskell-glut haskell-html haskell-hunit haskell-mtl haskell-quickcheck haskell-time haskell-x11 haskell-xhtml hs-plugins ldap-haskell magic-haskell washngo darcs haskell-cgi
FTBFS -----
haskell98-report
This is due to the LaTeX transition, see #420479.
hdbc
setup: cannot satisfy dependency mtl-any
pugs
Module `Control.Monad.RWS' does not export `msum'
gtk2hs
zcat: /usr/share/doc/ghc6-doc/html/libraries/base/base.haddock.gz: No such file or directory
haskell-edison
Could not find module `Control.Monad.Identity':
missingh
ghc-pkg: package filepath-1.0 is already installed
Not rebuilt due to missing dependencies listed above ---------------------------------------------------- hdbc-missingh hdbc-odbc hdbc-postgresql arch2darcs darcs-buildpackage dfsbuild ftphs gtk2hs haskell-anydbm haskell-configfile haskell-hsh haskelldb hat hdbc-sqlite3 hg-buildpackage hmake hpodder hsffig missingpy srcinst uuagc
Unexpected problems due to pbuilder -----------------------------------
haskell-cabal haskell-http hslogger happs haskell-hgl
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+)". These uploads will need to be carefully done in the correct order if we want to see theses packages in testing some day...
Is this dull work really needed?
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 would be glad if someone could remember me the reason of the current technical constraints for this limitation in Build-Depends. :)
If there no better solutions, I think it would be a good idea to set up a common package repository and a team around to share the workload of such transitions.
Cheers,
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.htmlIn 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
On Fri, May 11, 2007 at 03:35:54PM +0100, Ian Lynagh wrote:
FTBFS
hdbc
setup: cannot satisfy dependency mtl-anyI 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.
Already reported as #422290, as a matter of fact.
Unexpected problems due to pbuilder
haskell-cabal haskell-http hslogger happs haskell-hglSo these aren't ghc6-related, right?
I don't think so, but I did not have enough time to dig the issues properly...
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)
*ahem*, I should have looked at it more closely. :)
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.
Being subscribed to debian-release@l.d.o for quite a while now, I have always seen RMs responsive to binNMU requests. The other problem, IMHO, is that _you_ have a button for your own package, but you don't have one for packages maintained by others. Or through the way of NMU, but that really means a lot of work (testing the package correctly, sending diff, etc).
We'll always need to coordinate when we are doing toolchain updates, but I tend to think that if Haskell gets more popular, it will not scale well to break every single Haskell packages at each update.
I would be glad if someone could remember me the reason of the current technical constraints for this limitation in Build-Depends. :)
[...]
Maybe I wasn't clear enough. Why most packages currently cointains "ghc6 (>= 6.6), ghc6 (<< 6.6+)" in their Build-Depends, instead of a more straightforward "ghc6 (>= 6.4.2)" (or the first version needed)?
Cheers,
On Sun, May 13, 2007 at 11:20:56PM +0200, Jérémy Bobbio wrote:
On Fri, May 11, 2007 at 03:35:54PM +0100, Ian Lynagh wrote:
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.
Being subscribed to debian-release@l.d.o for quite a while now, I have always seen RMs responsive to binNMU requests. The other problem, IMHO, is that _you_ have a button for your own package, but you don't have one for packages maintained by others. Or through the way of NMU, but that really means a lot of work (testing the package correctly, sending diff, etc).
Lack of testing is another reason binNMUs are a bad solution, incidentally. It would be better to do an untested source NMUs, so we at least know it compiles, than untested binNMUs triggered by the RMs, IMO.
I would be glad if someone could remember me the reason of the current technical constraints for this limitation in Build-Depends. :)
[...]
Maybe I wasn't clear enough. Why most packages currently cointains "ghc6 (>= 6.6), ghc6 (<< 6.6+)" in their Build-Depends, instead of a more straightforward "ghc6 (>= 6.4.2)" (or the first version needed)?
The lower bound (ghc6 (>= 6.6)) is important when updating libraries at around the same time as updating a compiler, as you don't want the new packages building with the old compiler.
The upper bound is probably not important.
Thanks Ian
On Mon, May 28, 2007 at 02:51:10PM +0100, Ian Lynagh wrote:
On Sun, May 13, 2007 at 11:20:56PM +0200, Jérémy Bobbio wrote:
On Fri, May 11, 2007 at 03:35:54PM +0100, Ian Lynagh wrote:
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.
Being subscribed to debian-release@l.d.o for quite a while now, I have always seen RMs responsive to binNMU requests. The other problem, IMHO, is that _you_ have a button for your own package, but you don't have one for packages maintained by others. Or through the way of NMU, but that really means a lot of work (testing the package correctly, sending diff, etc).
Lack of testing is another reason binNMUs are a bad solution, incidentally. It would be better to do an untested source NMUs, so we at least know it compiles, than untested binNMUs triggered by the RMs, IMO.
You made a point. :)
Even if there's no formal Haskell team, could we imagine to have some kind of NMU agreement to handle compiler upgrades?
Maybe I wasn't clear enough. Why most packages currently cointains "ghc6 (>= 6.6), ghc6 (<< 6.6+)" in their Build-Depends, instead of a more straightforward "ghc6 (>= 6.4.2)" (or the first version needed)?
The lower bound (ghc6 (>= 6.6)) is important when updating libraries at around the same time as updating a compiler, as you don't want the new packages building with the old compiler.
The upper bound is probably not important.
I strongely suggest to drop it, then. :)
Cheers,
On Tue, May 08, 2007 at 04:27:18PM +0100, Ian Lynagh wrote:
Hi all,
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.htmlCurrently the only extralib packaged is mtl (libghc6-mtl-{dev,prof,doc}). More will probably follow soon.
All the extralibs are there now, along with a new haskell-utils. Also, ghc6 and mtl have changed.
Incidentally, the major differences from the 6.6 packages are:
* From the developer's PoV, debian/control.in is the same for all the libraries and the library (build)-deps are automatically generated.
* From the user's PoV, the docs at /usr/share/doc/ghc6-doc/html/libraries/index.html include docs for all libraries that are installed. Also, the -prof stuff is in its own package, so doesn't drag in gh6-prof.
Unless something comes up, I plan to start uploading these to Debian this weekend, but as before, note that these packages may not be what end up being uploaded to Debian and <insert standard no disclaimer stuff here>.
Thanks Ian
debian-haskell@lists.urchin.earth.li
-
Ian Lynagh -
Jérémy Bobbio