Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

i am in the process of a stage1 install following the handbook and using
setting
~amd64 in make.conf.  upon moving from stage1 to stage2 with the "emerge -e
system" command, pkgconfig is being emerged before automake, which causes
pkgconfig to die.  "emerge automake && emerge -e system" fixed the problem and
stage2 finished as expected.  i will attempt to reproduce in a chroot once this
system is running...

Reproducible: Didn't try
Steps to Reproduce:
1. stage 1 install as per handbook
2. emerge -e system (dies on pkgconfig)
3. emerge automake && emerge -e system (works)

Actual Results:  
emerge -e system died and could not be saved by emerge --resume.  step 3 solved
it.

Expected Results:  
emerged automake then emerged pkgconfig

Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0,
2.6.11-morph9 x86_64)
=================================================================
System uname: 2.6.11-morph9 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.12.0_pre1
dev-lang/python:     2.3.4-r1
sys-apps/sandbox:    1.2.11
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.16.1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -march=athlon64 -pipe -ffast-math -funroll-all-loops -fpeel-loops
-ftracer -funswitch-loops -funit-at-a-time"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon64 -pipe -ffast-math -funroll-all-loops -fpeel-loops
-ftracer -funswitch-loops -funit-at-a-time"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac aalib acpi aim alsa avi bash-completion bitmap-fonts
browserplugin bzip2 cd cdr clamav crypt cups dbus dv dvd dvdr dvdread eds
encode
exif firefox flash foomaticdb fortran gif gnome gpm gtk gtk2 hal imagemagick
imlib ithreads java javascript jikes jpeg live lzw lzw-tiff mbox mozilla
moznocompose moznoirc moznomail mozsvg mp3 mpeg mysql ncurses network nls nptl
nptlonly nvidia offensive opengl oss pam pdflib perl pic png posix python
quicktime readline real samba sdl spell ssl svg tcltk tcpd tiff truetype
truetype-fonts type1-fonts unicode usb userlocales videos xml xml2 xmms xpm
xprint xv xvid xvmc zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

my mistake, i of course meant when moving from stage2 to stage3.  

autotools are in base, pkgconfig isn't. I'm not quite sure how this could
happen ?

reporter: were you able to reproduce this?

Unfortunately, the machine suffered a hardware failure not long after my
report.
 M/B is currently under RMA to Giga-byte.  Will look into again when hardware
is
back....apologies to all.

I ran into this too when bootstrapping from 2005.0 yesterday. Unfortunately I 
resolved the problem to continue merging system during night so logs are gone 
and emerge --info is no longer correct with regards to version numbers.

*** Bug 101103 has been marked as a duplicate of this bug. ***

looks like a few others have come across this too...so i'll reopen as the other
was marked as a dup.

Apparently there are packages in the base profile (or packages implicitly
brought by the default USE flags) that depend on pkgconfig, which could be
causing this.

I've added automake as a dependency in the relevant ebuild. If it's possible,
it'd be nice if someone could test this on a clean system and let us know the
result.

Thanks.

no activity for over two weeks, any objections to marking as resolved?  this
fix
would have undoubtedly fixed my problem, and it appears no one else is running
into it thanks to the fix.

nope :)