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

Full Text Bug Listing

Pulling bridge-utils pulls
sysfsutils,ncurses,readline,sysvinit,coreutils,bash,baselayout.

solar helped me fix this by suggesting 
14:25 <@solar> RDEPEND=""
14:25 <@solar> DEPEND="${RDEPEND} virtual/os-headers"

in both ebuilds. Which appears to work for me.


Reproducible: Always
Steps to Reproduce:
0. chroot into gentoo-embedded development fs
1. mkdir /tmp/junk
2. ROOT=/tmp/junk emerge -pv bridge-utils wireless-tools


Actual Results:  
Long list of packagenames I don't want in my custom root fs appears on screen

Expected Results:  
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] net-misc/bridge-utils-1.0.6-r2  to /tmp/junk/ 0 kB 
[ebuild  N    ] net-wireless/wireless-tools-27-r1  to /tmp/junk/ (-nls) 0 kB 

dagb-home / # ROOT=/usr/src/soekris CFLAGS="-march=i386 -Os -pipe
-fomit-frame-pointer" USE="-X -pam -gtk -nls -gpm -tcpd -berkdb -gdbm
make-symlinks savedconfig ssl" emerge info          
Portage 2.0.51.22-r2 (uclibc/x86/2.4, gcc-3.3.5-20050130, uclibc-0.9.27-r0,
2.6.12-gentoo-r6 i686)
=================================================================
System uname: 2.6.12-gentoo-r6 i686 
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.4.22-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i386-gentoo-linux-uclibc"
CFLAGS="-march=i386 -Os -pipe -fomit-frame-pointer"
CHOST="i386-gentoo-linux-uclibc"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-Os -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks nodoc noinfo noman sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 make-symlinks ncurses readline savedconfig ssl uclibc zlib userland_GNU
kernel_linux elibc_uclibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY

Filed on solar's request.

wireless-tools updated. 
Waiting a day or so for feedback from robbat2 on bug #69292 before fixing it.

uhh, the baselayout DEPEND was in there for a valid reason ... wireless-tools +
older baselayouts wont work properly

this is a transient thing ... once baselayout has been in stable for a while we
can take the DEPEND back out

wireless-tools itself does not need to depend on any version of 
baselayout to function. They are low level system tools. Simply because
1 virtual/baselayout happens to have support for iwconfig/iwpriv/etc 
does not directly make wireless-tools directly depend on a baselayout to 
function.

Solar: In the future, do not touch any ebuilds maintained by me without
contacting me first. That DEPEND was put in there for a reason.

Sorry brix I generally only have to touch things when they are broken. The best
way to ensure that I wont have to touch a package you maintain is to ensure you
 don't cause breakage in other things. In the past you and the formation of the 
wifi herd have always indicated that I was pretty free to commit on those pkgs.
I even added myself to the metadata.xml to make it clear my role in that pkg.

In both of the cases reported here the DEPENDS are/were clearly wrong 
as outlined in comment #4. The core package has not changed functionality so 
it's a Q/A fix for a silly oversight.

While the DEPEND on baselayout is temporary to avoid confusion amongst our
users
and will be removed at a later point, I have added a proper fix for this issue: 

    !elibc_uclibc? ( >=sys-apps/baselayout-1.11.13 )

The bridge-utils issue is handled in bug #69292.