I try to emerge ghc in ~ppc64 (PS3) and it doesn't work (no USE variables set): >>> Emerging (1 of 1) dev-lang/ghc-6.8.2 to / * ghc-6.8.2-src.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking ghc-6.8.2-src.tar.bz2 ;-) ... [ ok ] * No binary .tbz2 package available yet for these arches: * alpha, hppa, ia64, ppc, ppc64 * Please try emerging with USE=ghcbootstrap and report build * sucess or failure to the haskell team (haskell@gentoo.org) Trying with binary use flag or ghcbootstrap flag doesn't work either. Reproducible: Always Steps to Reproduce: 1. ACCEPT_KEYWORDS="~ppc64" emerge ghc --> fails 2. USE="binary" ACCEPT_KEYWORDS="~ppc64" emerge ghc --> fails 3. USE="ghcbootstrap" ACCEPT_KEYWORDS="~ppc64" emerge ghc --> fails # emerge --info Portage 2.1.3.19 (default-linux/ppc/ppc64/2007.0/64bit-userland/desktop/970, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-ps3 ppc64) ================================================================= System uname: 2.6.23-ps3 ppc64 Cell Broadband Engine, altivec supported Timestamp of tree: Sat, 19 Jan 2008 12:16:01 +0000 app-shells/bash: 3.2_p17 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="ppc64" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl altivec arts berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dri dvd dvdr eds emboss encode esd fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde ldap mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre perl png ppc64 pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sqlite ssl tcpd truetype truetype-fonts type1-fonts unicode vorbis xml xorg xv zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev mach64 mga nv r128 radeon vega" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
<snip> SRC_URI="!binary? ( http://haskell.org/ghc/dist/${EXTRA_SRC_URI}/${P}-src.tar.bz2 ) amd64? ( mirror://gentoo/ghc-bin-${PV}-amd64.tbz2 ) sparc? ( mirror://gentoo/ghc-bin-${PV}-sparc.tbz2 ) x86? ( mirror://gentoo/ghc-bin-${PV}-x86.tbz2 )" </snip> So, when we don't want binary, then lets download both source and binary? And what's going to happen for the rest of arches in IUSE? Did you intend something like !ghcbootstrap? ( amd64? ( mirror://gentoo/ghc-bin-${PV}-amd64.tbz2 ) )? Or maybe binary? ( amd64? ( mirror://gentoo/ghc-bin-${PV}-amd64.tbz2 ) )? <snip> if use ghcbootstrap; then ... [[ -z $(type -P ghc) ]] && \ die "Could not find a ghc to bootstrap with." </snip> So, what's exactly USE=ghcbootstrap supposed to do? Die when there's no ghc installed? One would suppose that the whole purpose of ghcbootstrap use flag is to be able to emerge this even when there's no ghc installed, at least the ebuild comments suggest this: <snip> elif use alpha || use hppa || use ia64 || use ppc || use ppc64; then eerror "Please try emerging with USE=ghcbootstrap and report build" eerror "sucess or failure to the haskell team (haskell@gentoo.org)" die "No binary available for this arch yet, USE=ghcbootstrap" fi </snip> Nice, so on alpha/hppa/ia64/ppc/use ppc64 you can either: - set USE="binary" and die on src_unpack because there's nothing to unpack - or set USE="ghcbootstrap" and die on missing ghc (people are supposed to grow themselves one in some mysterious way?) - or set USE="binary ghcbootstrap" and die on conflicting use flags - or not to set any of those flags and die on "No binary available for this arch yet, USE=ghcbootstrap" Hmmm... eh... *scratching my head* maybe those KEYWORDS should be rather dropped and we need some serious rethinking here?
I don't really understand the bug report, and I also don't understand why it's classified major. GHC *always* needs a version of GHC already installed to build. The standard way we achieve this is that the ebuild downloads a binary along with the sources, and tries the build the sources with the binary. That configuration is the default (USE="-ghcbootstrap -binary"). If there is a binary available for your arch, you might rightfully ask why you have to recompile the sources with it once more, so you can shortcut and say USE="-ghcbootstrap binary". In this case, only the binary will be downloaded and installed. No compilation at all. If there's no binary for your arch, there's still the situation where you might be able to get a binary from elsewhere. Options here are binaries of older GHC versions you might still have installed, or binaries from other distributions. In such a case, install that binary, make sure it's found on your PATH, and run the ebuild with (USE="ghcbootstrap"). This is probably what you should try in your case. If all these fail, then this means you have to port GHC to the platform. This is non-trivial, and certainly requires some knowledge about both GHC internals and the platform you want to port to. HTH, kosmikus
(In reply to comment #2) > I don't really understand the bug report, and I also don't understand why it's > classified major. Well, simply because an ebuild being broken on 5 out of 8 keyworded arches is a *major* issue. > GHC *always* needs a version of GHC already installed to > build. The standard way we achieve this is that the ebuild downloads a binary > along with the sources, and tries the build the sources with the binary. We used to have a virtual/ghc for this, which basically worked (using the now masked-for-removal dev-lang/ghc-bin)... It has these binaries available for all arches keyworded. With the new dev-lang/ghc solution now 5 out of 8 arches are broken. Sounds like a huge regression to me. > configuration is the default (USE="-ghcbootstrap -binary"). If there is a > binary available for your arch, you might rightfully ask why you have to > recompile the sources with it once more, so you can shortcut and say > USE="-ghcbootstrap binary". In this case, only the binary will be downloaded > and installed. No compilation at all. And if there's not any binary then you have screwed dependency tree because everything that uses ghc depends on something we fail to provide in a working state on a majority of keyworded arches. > If there's no binary for your arch, there's still the situation where you might > be able to get a binary from elsewhere. Options here are binaries of older GHC > versions you might still have installed, or binaries from other distributions. > In such a case, install that binary, make sure it's found on your PATH, and run > the ebuild with (USE="ghcbootstrap"). This is probably what you should try in > your case. But we still have those, just an improper solution was taken to the sucky old-style virtual issues. So, now for some viable solutions instead of relying on users getting theirs hand on ghc-bin out of the blue somewhere: - create a *new-style* virtual/ghc; you can have as many version of that as you need - unmask dev-lang/ghc-bin (6.4.2 at least) again - make dev-lang/ghc DEPEND on dev-lang/ghc-bin (*not* on the virtual itself, which was basically the mistake that broke the old-style sucky virtual even more). - dev-lang/ghc-bin-6.4.2 can be used to bootstrap the newer dev-lang/ghc versions for all those arches that are broken now. This all has been extensively discussed w/ zmedico recently on #gentoo-portage, so CCing him here as well as he might be able to explain the issue here and the solution better.
(In reply to comment #2) > I don't really understand the bug report, and I also don't understand why it's > classified major. GHC *always* needs a version of GHC already installed to > build. The standard way we achieve this is that the ebuild downloads a binary > along with the sources, and tries the build the sources with the binary. That > configuration is the default (USE="-ghcbootstrap -binary"). If there is a > binary available for your arch, you might rightfully ask why you have to > recompile the sources with it once more, so you can shortcut and say > USE="-ghcbootstrap binary". In this case, only the binary will be downloaded > and installed. No compilation at all. > [snip] I emerged ghc-bin, and then: # USE="ghcbootstrap" ACCEPT_KEYWORDS="~ppc64" emerge -av ghc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-lang/ghc-6.8.2 USE="ghcbootstrap -bash-completion -binary -doc" 0 kB [blocks B ] dev-lang/ghc-bin (is blocking dev-lang/ghc-6.8.2) > HTH, > kosmikus >
You have to use the 'binary' USE flag. The current ghc-bin is kind of deprecated in favor of this new use flag support, so it can't compile ghc6.8.
(In reply to comment #5) > You have to use the 'binary' USE flag. > > The current ghc-bin is kind of deprecated in favor of this new use flag > support, so it can't compile ghc6.8. > Are you joking? Comment 2 just says that I need to use ghcbootstrap, moreover, using binary doesn't work as I said initially.
I think it's a simple mistake. Those arches should not be keyworded until they have binaries available. When it was in the overlay it was fine to have it the other way since we could expect users to USE=ghcbootstrap themselves if there was no binary yet. However that's no good for other users who are likely to not have any ghc at all to bootstrap from (except an older dev-lang/ghc that does have a binary available - but that's not especially obvious). So lets stop arguing and just drop the keywords and ask the arch teams to make us some new binaries. We may also consider moving to a two-tier model where some arches use an older ghc to bootstrap from and then do not have the option to USE=binary.
(In reply to comment #3) > Well, simply because an ebuild being broken on 5 out of 8 keyworded arches is a > *major* issue. I guess you're right. I apologize in case my reply appeared unfriendly. It seems I was lacking information that dcoutts was able to provide. Cheers, ks
Fixed. Dropped ~alpha ~hppa ~ia64 ~ppc ~ppc64 keywords. They will have to wait for new binaries.
(In reply to comment #7) > just drop the keywords and ask the arch teams to make > us some new binaries. Oh no, not again. You forgot to ask arch teams to provide new binaries. Let's call this bug fixed when the arches are rekeyworded (properly), shall we?
So how are we supposed to create binaries? with USE="ghcbootstrap" i get: * checking ghc-6.8.2-src.tar.bz2 ;-) ... [ ok ] * 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.8.2 failed. * Call stack: * ebuild.sh, line 1717: Called dyn_setup * ebuild.sh, line 768: Called qa_call 'pkg_setup' * ebuild.sh, line 44: Called pkg_setup * ghc-6.8.2.ebuild, line 129: Called die * The specific snippet of code: * [[ -z $(type -P ghc) ]] && \ * die "Could not find a ghc to bootstrap with." * The die message: * Could not find a ghc to bootstrap with. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-lang/ghc-6.8.2/temp/build.log'. And without it i get: * checking ghc-6.8.2-src.tar.bz2 ;-) ... [ ok ] * No binary .tbz2 package available yet for these arches: * alpha, hppa, ia64, ppc, ppc64 * Please try emerging with USE=ghcbootstrap and report build * sucess or failure to the haskell team (haskell@gentoo.org) * * ERROR: dev-lang/ghc-6.8.2 failed. * Call stack: * ebuild.sh, line 1717: Called dyn_setup * ebuild.sh, line 768: Called qa_call 'pkg_setup' * ebuild.sh, line 44: Called pkg_setup * ghc-6.8.2.ebuild, line 135: Called die * The specific snippet of code: * die "No binary available for this arch yet, USE=ghcbootstrap" * The die message: * No binary available for this arch yet, USE=ghcbootstrap * * If you need support, post the topmost build error, and the call stack if relevant.
(In reply to comment #11) > So how are we supposed to create binaries? See Comment #1; you cannot because you need to already have the binaries to build the binaries. So, now can we revisit the new-style virtual thing, please?
(In reply to comment #12) > (In reply to comment #11) > > So how are we supposed to create binaries? > > See Comment #1; you cannot because you need to already have the binaries to > build the binaries. So, now can we revisit the new-style virtual thing, please? Actually you can, but you'll have to use an earlier binary (maybe 6.6.1) to build a 6.8.2. I have a 6.8.2 for HPPA built with 6.6.1, but I haven't yet found the CPU time to build a 6.8.2 with minimal arch (think -march= and alike) settings to use as a binary package yet.
Yes, one needs some pre-existing ghc to start from. The obvious choice is: USE=binary emerge '<ghc-6.8' We use this script from the haskell overlay: http://haskell.org/~gentoo/gentoo-haskell/projects/build-ghc-bin.sh It currently ignores your CFLAGS and uses CFLAGS="-O2 -pipe" so you may need to hack the script as necessary for your arch. * the script builds /usr/portage/packages/dev-lang/ghc-$version.tbz2 * this needs to be renamed to ghc-bin-$version-$arch.tbz2 * the .tbz2 has to be uploaded to the mirrors * the ghc ebuild has to be updated, which involves: * listing the arch binary in SRC_URI * adjusting the KEYWORDS * removing the arch from the "no binary" list in pkg_setup()
ghc-bin-6.8.2-hppa.tbz2 should be available on mirrors soon. Meanwhile, I updated the ebuild and marked it ~hppa.
Is there a stablization request with this bug? If so, mind spelling out exactly what you want done and I will hop-to.
(In reply to comment #16) > Is there a stablization request with this bug? If so, mind spelling out > exactly what you want done and I will hop-to. Comment #14 explains what needs to be done so that you can keyword this ebuild for your arch.
alpha is done, dcoutts is doing ia64
working on ppc64 binary
I have some problems on ppc64: bug #212305, bug #212307
~ia64 done now
ppc already HAS a binary (http://dev.gentoo.org/~mabi/ghc-bin-6.8.2-ppc.tbz2, from last year) - should i push this to the mirrors and rekeyword?
ppc was keyworded but ppc64 isn't even if comment 19 says it is
Minor: Conditional source/binary fetch for certain USE flags was added to ghc-6.10+ ebuilds. All keyworded ebuilds have binaries in SRC_URI, so closing as FIXED.
