Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 106121 - www-apps/mediawiki-1.5.0_rc4-r1 & best_version() in global scope, portage fails update cache...
Summary: www-apps/mediawiki-1.5.0_rc4-r1 & best_version() in global scope, portage fai...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Christian Parpart (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 105435
  Show dependency tree
 
Reported: 2005-09-15 15:39 UTC by Dave Nebinger
Modified: 2005-09-16 16:36 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Nebinger 2005-09-15 15:39:55 UTC
Just did an emerge --sync against crane.gentoo.org.  Seems to have pulled
mediawiki-1.5.0_rc4-r1 down in the process.  I do not have mediawiki installed.
 Anyway tail end of sync process, when portage updates it's cache, results in:

>>> Updating Portage cache:   88%QA Notice: best_version() in global scope:
www-apps/mediawiki-1.5.0_rc4-r1
 *
 * Using
 *
 * Checking for required PHP feature(s):
QA Notice: best_version() in global scope: www-apps/mediawiki-1.5.0_rc4-r1
 *   Discovered missing USE flag pcre
 *
 *  needs to be re-installed with all of the following
 * USE flags enabled:
 *
 *   pcre
 *

!!! ERROR: www-apps/mediawiki-1.5.0_rc4-r1 failed.
!!! Function require_php_with_use, Line 191, Exitcode 0
!!! Re-install
!!! If you need support, post the topmost build error, NOT this status message.


aux_get(): (0) Error in www-apps/mediawiki-1.5.0_rc4-r1 ebuild. (1)
               Check for syntax error or corruption in the ebuild. (--debug)


Failed cache update: www-apps/mediawiki-1.5.0_rc4-r1                        100%

Don't know what the heck this all means, but I do have 'pcre' in my
/etc/make.conf USE flags.

I'm bumping the severity to 'major' because I do not know what the impact to the
portage cache is as a result of this failure, and if it has any impact at all I
would think that's a really important thing to fix...


Reproducible: Always
Steps to Reproduce:
1. emerge --sync
2. view output of portage cache update.
3.

Actual Results:  
Portage seems ok, but I'm not totally sure.  emerge --pretend --update --deep
world reports no results, but I did update completely two days ago and possibly
I have no updates to apply, but I'm not sure.

Expected Results:  
Allow whatever the 'portage cache update' process is supposed to do without
erroring out.

cornholio ~ # emerge info
Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1,
2.6.13-firewall i686)
=================================================================
System uname: 2.6.13-firewall i686 Pentium III (Coppermine)
Gentoo Base System version 1.6.13
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
dev-lang/python:     2.3.5-r2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -pipe -mcpu=i686 -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/control /var/run/dspam
/var/spool/dspam"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium3 -pipe -mcpu=i686 -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles/"
FEATURES="autoconfig distcc distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://mirror.datapipe.net/gentoo/
http://ftp-mirror.internap.com/pub/gentoo/ http://gentoo.binarycompass.org
ftp://ftp-mirror.internap.com/pub/gentoo/"
MAKEOPTS="-j1"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X alsa apm arts atm avi berkdb bitmap-fonts bzlib cdr crypt cups curl
eds emboss encode exif fam foomaticdb fortran ftp gd gdbm gif gnutls gpm
gstreamer gtk gtk2 imlib java jikes jpeg kde kerberos libg++ libwww mad maildir
mikmod mime mmap mmx mng motif mozilla mp3 mpeg mysql ncurses nls nptl ogg
oggvorbis opengl oss pam pcre pdflib perl php pic png posix python qt quicktime
readline samba sasl sdl shared sharedmem slang snmp sockets spell sse ssl svga
sysvipc tcltk tcpd tiff truetype truetype-fonts type1-fonts usb vorbis xml xml2
xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Comment 1 Pat Erley 2005-09-15 15:44:17 UTC
same on amd64 stable.  pcre is not an accepted use flag in dev-php/php and
dev-lang/php is hard masked on my arch.  Maybe an erroneous } in the ebuild?
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2005-09-15 16:12:15 UTC
(In reply to comment #1)
> same on amd64 stable.  pcre is not an accepted use flag in dev-php/php and
> dev-lang/php is hard masked on my arch.  Maybe an erroneous } in the ebuild?

The checks in global scope have been fixed, sorry for that. Emerge sync in an
hour or two. The ebuild still won't install, needs more fixing. Noting that this
ebuild is not compatible w/ dev-php/mod_php. 

@trapni: I removed the things in src_compile() for a reason - they don't exist
in the tarball (http://bugs.gentoo.org/attachment.cgi?id=68531). This also
should not be keyworded ~amd64 until dev-lang/php is keyworded ~amd64, it
depends on it.
Comment 3 Christian Parpart (RETIRED) gentoo-dev 2005-09-16 12:32:48 UTC
I keyworded dev-lang/php to ~amd64 already, I'm most probably very sure about, 
although, I hardmasked mediawiki-1.5.0_rc4-r1 for testing and work-in-progress 
reasons, though, I'm wondering why this comes anyway.... lets see... 
Comment 4 Christian Parpart (RETIRED) gentoo-dev 2005-09-16 12:59:53 UTC
BrBones had fixed the global-scope problem already (while I have been at work).  
  
patch from attachement 68531 has been partially adapted already (I actually  
applied the missing parts).  
  
Although, I checked the dev-lang/php keywords for amd64 now, and indeed, I  
marked it ~amd64 already, but for dev-lang/php-4.4.0 only, though, missing 3.x  
and 5.x; I'll do that within some minutes, too. 
Comment 5 Christian Parpart (RETIRED) gentoo-dev 2005-09-16 16:36:31 UTC
finally everything done....