Bug 206643 - dev-lang/ghc-6.8.2 DEPEND/pkg_setup logic is broken
|
Bug#:
206643
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: REOPENED
|
Severity: major
|
Priority: P2
|
|
Resolution:
|
Assigned To: haskell@gentoo.org
|
Reported By: pocmatos@gmail.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: dev-lang/ghc-6.8.2 DEPEND/pkg_setup logic is broken
|
|
Keywords: KEYWORDREQ
|
|
Status Whiteboard:
|
|
Opened: 2008-01-19 14:33 0000
|
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
ppc was keyworded but ppc64 isn't even if comment 19 says it is
