Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 312085 - emerge update failed: file collision between gettext/glibc-2
Summary: emerge update failed: file collision between gettext/glibc-2
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: ARM Linux
: High normal (vote)
Assignee: Embedded Gentoo Team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2010-03-30 15:57 UTC by Guillaume Estival
Modified: 2010-08-18 12:27 UTC (History)
2 users (show)

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


Attachments
full emerge log of gettext (log_emerge.txt.gz,57.79 KB, application/octet-stream)
2010-03-30 15:58 UTC, Guillaume Estival
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Estival 2010-03-30 15:57:48 UTC
I am using an ARM beagleboard system on which I installed a stage 3 gentoo system which needs updating. It hangs when emerge try to install gettext. (see actual results)

After googling, I found out this bug:
http://bugs.gentoo.org/249213
Quite similar but he has a compilation error on a missing API, as I got a file collision. It's not exactly the same so I fill this new bug with a link with something similar.

Reproducible: Always

Steps to Reproduce:
1.emerge gettext

Actual Results:  
* Detected file collision(s):
 *      /usr/include/libintl.h
 * Searching all installed packages for file collisions...
 * sys-libs/glibc-2.11-r1
 *      /usr/include/libintl.h


Expected Results:  
gettext should be installed fine, as both gettext and glibc are needed on the system.

I was digging through the problem and found out gettext normally wipe out libintl stuff on a glibc system through a use condition on his ebuild:
    # remove stuff that glibc handles
    if use elibc_glibc ; then
        rm -f "${D}"/usr/include/libintl.h
        rm -f "${D}"/usr/$(get_libdir)/libintl.*
    fi
I tried to found out a way to know what "use elibc_glibc" result on my ARM system but I didn't find a lot of clues. Got this http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 and that http://devmanual.gentoo.org/ebuild-writing/index.html but I'm not able to find myself a clean fix. (I'm not familiar with gentoo, I usually use debian or redhat)
A (very) ugly fix can be found here http://forums.gentoo.org/viewtopic-p-6224547.html , as I manage to force the libintl stuff removing from gettext.
On attachment, the full emerge log of gettext, gzip. Sorry I can't pinpoint the relevant informations on this.
I set the bug as Major but in my opinion, it is blocker. But I already found a (ugly) way to unblock myself so I set down the severity.
I can provide some help for trying a newly made ebuild which will work on ARM system. Feel free to ask.

Portage 2.1.8.3 (embedded, gcc-4.4.3, glibc-2.11-r1, 2.6.29 armv7l)
=================================================================
System uname: Linux-2.6.29-armv7l-ARMv7_Processor_rev_3_-v7l-with-gentoo-2.0.1
Timestamp of tree: Fri, 26 Mar 2010 12:45:01 +0000
app-shells/bash:     4.1_p2-r1
dev-lang/python:     2.6.4, 3.1.1-r1
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.63-r1
sys-devel/automake:  1.10.2, 1.11
sys-devel/binutils:  2.20.1
sys-devel/gcc:       4.4.3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="arm ~arm"
ACCEPT_LICENSE="* -@EULA"
CBUILD="arm-unknown-linux-gnueabi"
CFLAGS="-Os -pipe -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-ftree-vectorize -fomit-frame-pointer"
CHOST="arm-unknown-linux-gnueabi"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gentoo-release /e
tc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-Os -pipe -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softf
p -ftree-vectorize -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned
 sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://gentoo.imj.fr/pub/gentoo/ ftp://mirror.ovh.net/gentoo-dist
files/ http://mirrors.linuxant.fr/distfiles.gentoo.org/ http://mirror.ovh.net/ge
ntoo-distfiles/ "
LDFLAGS=""
LINGUAS="en"
MAKEOPTS="-j1"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclu
de=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="arm bindist cracklib kdrive minimal modules multicall nptlonly pam userloca
les zlib" ELIBC="glibc" INPUT_DEVICES="evdev mouse keyboard tslib" KERNEL="linux
" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="fbdev"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_A
LL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_
OVERLAY
Comment 1 Guillaume Estival 2010-03-30 15:58:58 UTC
Created attachment 225839 [details]
full emerge log of gettext

I'm not familiar enough with emerge to pinpoint the problem here.
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2010-03-30 16:10:15 UTC
Intresting profile choice, embedded/ with glibc. I believe you should be using default/linux/arm/10.0 instead and this problem would go away.

That said. Moving to embedded maintainers to look at...
Comment 3 SpanKY gentoo-dev 2010-03-30 21:52:27 UTC
embedded/ is for uClibc only
Comment 4 solar (RETIRED) gentoo-dev 2010-03-30 22:43:15 UTC
(In reply to comment #3)
> embedded/ is for uClibc only

Not really. crossdev (defaults) a SYSROOT/etc/make.profile to $PORTDIR/profiles/embedded [which can be uClibc or glibc]

However outside of cross-compiles people should not really use it, as it is far from a complete profile.
Comment 5 solar (RETIRED) gentoo-dev 2010-03-30 22:43:43 UTC
The root problem here is that said ebuilds don't list elibc_glibc in IUSE= (that needs to be corrected)
Comment 6 SpanKY gentoo-dev 2010-03-30 23:03:05 UTC
no package should need to list elibc_* in IUSE
Comment 7 solar (RETIRED) gentoo-dev 2010-03-30 23:23:07 UTC
Using commit message:
------------------------------------------------------------------------------
- elibc_glibc has to be defined in IUSE= for profiles that are unable to use.force that flag bug #312085
(Portage version: 2.1.8.2/cvs/Linux x86_64)
------------------------------------------------------------------------------
Comment 8 solar (RETIRED) gentoo-dev 2010-03-30 23:25:48 UTC
(In reply to comment #6)
> no package should need to list elibc_* in IUSE

Yes they have to be listed or bugs exactly like this one happen. It took me a while to track this down in the past (thanks zmedico). portage will not USE_EXPAND the variables unless they are forced or in IUSE=. 

The reason you don't see this happening normally is that most base/ profiles use.force elibc_glibc and kernel_linux
Comment 9 SpanKY gentoo-dev 2010-03-31 00:45:52 UTC
this is portage sucking, not a bug in ebuilds
Comment 10 solar (RETIRED) gentoo-dev 2010-03-31 01:58:58 UTC
(In reply to comment #9)
> this is portage sucking, not a bug in ebuilds

Take it up with the portage team. I will continue to fix ebuilds till portage behaves otherwise. 

Comment 11 Zac Medico gentoo-dev 2010-03-31 02:21:58 UTC
(In reply to comment #6)
> no package should need to list elibc_* in IUSE

The thing is, if we don't have a use.force or a use.mask for these flags, the next possible way to automatically identify them as being exempt from IUSE filtering is to match them against USE_EXPAND_HIDDEN in the profile. So, each time we calculate USE for a package we'll have run through all the flags and check for matches against elibc_*, kernel_*, userland_*, and anything else in USE_EXPAND_HIDDEN. If we're going to do that then we're going to have to optimize it pretty well or else it's going to cause a significant performance penalty for USE calculations (done during dependency calculations).
Comment 12 Zac Medico gentoo-dev 2010-08-18 12:27:30 UTC
(In reply to comment #11)
> The thing is, if we don't have a use.force or a use.mask for these flags, the
> next possible way to automatically identify them as being exempt from IUSE
> filtering is to match them against USE_EXPAND_HIDDEN in the profile. So, each
> time we calculate USE for a package we'll have run through all the flags and
> check for matches against elibc_*, kernel_*, userland_*, and anything else in
> USE_EXPAND_HIDDEN. If we're going to do that then we're going to have to
> optimize it pretty well or else it's going to cause a significant performance
> penalty for USE calculations (done during dependency calculations).

This is in git now:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1b9fcb1a13e85db08b44e414a07df80b60ddc797