Please mark the following packages stable on amd64, ppc, ppc64, and x86; dev-lang/ghc-6.12.3 dev-haskell/cabal-1.8.0.6-r1 app-admin/haskell-updater-1.1.0.0 dev-haskell/haddock-2.6.1 (deps needed to build these packages) ghc is as significant package as all the other dev-haskell packages depend on it. A couple other packages of interest to non-Haskell developers that depend on ghc are in portage: darcs and xmonad. darcs has an extensive test suite and can be used to make sure that ghc is working properly. ghc-6.12.3 has been in ~arch on these arches for some time. It's been bug free on these arches for a few months. We've been testing to migrate from earlier versions to ghc-6.12.3 and have not run into any migration problems. haskell-updater is a custom application made to aid the user migrate between ghc versions. It's also useful if you've broken some Haskell packages due to upgrading packages which other packages were built against. Known problems; * bug #311361, problem with linker scripts. It's known upstream, and the fix will be part of ghc-7.0. It's not a new bug, it affects all previous ghc versions. We don't feel it's significant enough to stop ghc-6.12.3 going stable, as most of the Haskell environment will work perfectly and there are workarounds. * bug #326347, problem building with large N in MAKEOPTS=-jN. Problems reported with N=8 and larger. This is also fixed upstreams and will be part of ghc-7.0. Most users will never notice this, and again, we don't feel it's significant to stop making ghc stable. * haddock requires Template Haskell. This stops keywording of haddock for alpha, ia64 and sparc. Unfortunately we will have to wait with those arches as it'd make the USE=doc flag invalid for all haskell packages.
Slightly amending requested keywords: ppc64 does not have TH support, and sparc does have So requested STABLEREQ arches are: amd64 ppc sparc x86 Thanks!
amd64 done
Is there no nicer way to handle this?: devmanual: No combination of USE flags should cause a package to fail to build because users can set any combination of flags. * CPV: dev-lang/ghc-6.12.3 * REPO: gentoo * USE: bash-completion binary elibc_glibc ghcbootstrap kernel_linux test userland_GNU x86 * You requested ghc bootstrapping, this is usually only used * by Gentoo developers to make binary .tbz2 packages for * use with the ghc ebuild's USE="binary" feature. * ERROR: dev-lang/ghc-6.12.3 failed: * USE="ghcbootstrap binary" is not a valid combination. * * Call stack: * ebuild.sh, line 54: Called pkg_setup * ghc-6.12.3.ebuild, line 137: Called die * The specific snippet of code: * use binary && \ * die "USE=\"ghcbootstrap binary\" is not a valid combination." * * If you need support, post the output of 'emerge --info =dev-lang/ghc-6.12.3', * the complete build log and the output of 'emerge -pqv =dev-lang/ghc-6.12.3'. * The complete build log is located at '/var/tmp/portage/dev-lang/ghc-6.12.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-lang/ghc-6.12.3/temp/die.env'. * S: '/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3'
We've tried a few different things in the past, but finally settled for this solution. I don't see why it should be any trouble, though; * 'ghcbootstrap' is only used for dev-lang/ghc, no other package. * It's used to bootstrap the new ghc based on the systems currently installed ghc, which is for developers and possibly some advanced users. As the description says: "Internal: Bootstrap GHC from an existing GHC installation.". It's not for anybody. We use this scheme for all ghc versions and I haven't heard any user complaints so far. It would be bad if it would be common flags, and you would accidentally hit this "feature". Like, for example, you have USE="qt4 gnome" and your ebuild only could support one of them and die otherwise. But, this is not the case here. I hope this explains at least part of our reasoning. Thank you for your interest in the matter, cheers.
Ok, seems reasonable to me. I've been building some rdeps and I saw some build failures that I'll check out (see if they are already reported). One thing that I noticed is that x86 stable hmake depends on ghc-6.8, do we want to have an newer version for this ghc? There is no newer version in tree yet.
Bug 330095 comment #5: We'll bump stable darcs with ghc, so closing the bug as WONTFIX. As this ghc is planned to go stable, we'll need a newer dev-vcs/darcs. We'll be breaking darcs if we don't do this (and description mentions it to use as a test case).
Is there any blockers for x86? I successfully upgraded my both PC. Seems like all works fine.
(In reply to comment #7) > Is there any blockers for x86? I successfully upgraded my both PC. Seems like > all works fine. Yes: Compile time during testing :) I'm on it, bear with us.
x86 done. Thanks a lot Myckel!
Awesome, thanks! I know it's a lot to test :)
sparc done. Marked stable: dev-lang/ghc-6.12.3 dev-haskell/cabal-1.8.0.6-r1 app-admin/haskell-updater-1.1.0.0 dev-haskell/haddock-2.6.1
Adding alpha ia64 ppc64 to CC as we have binaries for them for quite a while too.
alpha/ia64 done
ppc/ppc64 stable