When trying to emerge -uD I'm getting this... !!! Multiple versions within a single package slot have been !!! pulled into the dependency graph: ('installed', '/', 'sys-libs/glibc-2.3.6-r4', 'nomerge') pulled in by ('installed', '/', 'sys-devel/gcc-4.1.1-r3', 'nomerge') ('ebuild', '/', 'sys-libs/glibc-2.3.5-r3', 'merge') pulled in by ('installed', '/', 'sys-boot/aboot-1.0_pre20040408', 'nomerge') Reproducible: Always
$ grep DEPEND aboot-1.0_pre20040408.ebuild DEPEND="virtual/libc" Really no idea where did you get yours; you should re-emerge aboot using the ebuild that's actually in the official tree.
I do, and it still happens.
Reopen with emerge --info and cat var/db/pkg/sys-boot/aboot*/DEPEND
cat /var/db/pkg/sys-boot/aboot-1.0_pre20040408/DEPEND produces virtual/libc And emerge --info Portage 2.1.2.7 (default-linux/alpha/2006.1, gcc-4.1.1, glibc-2.3.6-r4, 2.6.21-gentoo-r2 alpha) ================================================================= System uname: 2.6.21-gentoo-r2 alpha EV68AL Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 31 May 2007 01:50:01 +0000 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O2 -mcpu=ev67" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-mieee -pipe -O2 -mcpu=ev67" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" 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.gentoo.org/gentoo-portage" USE="alpha berkdb bitmap-fonts cli cracklib crypt cups dri fortran gdbm iconv ipv6 isdnlog ldap libg++ midi mudflap ncurses nls nptl nptlonly openmp pam pcre perl ppds pppd python readline reflection session spl ssl tcpd truetype truetype-fonts type1-fonts unicode xml xorg zlib" ALSA_CARDS="ali5451 als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci" 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" 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="radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Note that in my initial report it's complaining about a clash of two glibc versions.
(In reply to comment #5) > Note that in my initial report it's complaining about a clash of two glibc > versions. Yeah, I did not that. And it plain doesn't make any sense.
From my reading of the GCC ebuild I suspect it's this.... if [[ ${CATEGORY} != cross-* ]]; then PDEPEND="${PDEPEND} elibc_glibc? ( >= sys-libs/glibc-2.3.6 )" fi which is telling gcc to pull in 2.3.6, but the virtual/libc is still 2.3.5.
(In reply to comment #7) > but virtual/libc is still 2.3.5. Erm... I guess not. Where would this be defined?
I don't know - that was a guess. Where is virtual/libc defined anyway ?
mmm. hang on. it seems that 2.3.6-r4 was deleted for glibc and reverted back to 2.3.5-r3. So it looks like I need to downgrade glibc first.
Ugh. And I can't downgrade glibc.
Looking at the Changelog it seems that Bryan sstergaard made glibc-2.3.6-r4 stable on alpha. But now glibc-2.3.6-r5 is the only one available and it's not marked stable for alpha.
@vapier - you removed latest stable glibc for default-linux/alpha/2006.1 profile.
First of all, I am really sorry on the Alpha teams behalf for you to go through this. My advice for you is to try to upgrade to the 2007.0 profile? Let me know about your results.
This obviously works as it switches glibc to 2.5
@vapier - maybe you'd like to clean up after yourself instead of re-assigning bugs to folks that haven't caused them in the first place?!
@vapier - Stop removing yourself from CC until you've fixed the mess you've created here. You've made the profile unusable, so either restore the ebuild, or mark the profile as deprecated. Silently removing yourself from CC over and over again won't fix this bug.
I've readded it. Think before you commit next time.
jakub: stop getting into things that arent your business it's up to the alpha team to decide whether they want to deprecate older profiles old gcc ebuilds were announced for removal and arch teams said OK (including alpha) now stop being a tard
alpha team needs to decide status of older profiles
15:30:31 <+CIA-19> spb * gentoo-x86/sys-libs/glibc/ (ChangeLog glibc-2.3.6-r4.ebuild files/digest-glibc-2.3.6-r4): 15:30:31 <+CIA-19> Attempt to fix vapier's screwup removing alpha's latest 2.3 stable Closing as FIXED again. (In reply to comment #19) > jakub: stop getting into things that arent your business > it's up to the alpha team to decide whether they want to deprecate older > profiles It's *your* business to NOT screw up profiles by removing essential ebuilds. And it's *your* business to fix such screw-ups once they've happened because you can't be bothered to use repoman at all.
the people whose opinion matters: - alpha team anyone else -> noise it's the alpha team's decision how to move forward and no one else's
(In reply to comment #22) > anyone else -> noise > > it's the alpha team's decision how to move forward and no one else's Wonderful... so, users getting screwed by your broken commits are useless noise. Seriously, start using repoman again and if you don't, then at least fix the crap caused by you promptly without such bullshit as you've presented on this bug.
funny, i dont recall Jakub being part of the alpha team ... also, you may want to check your facts wrt my usage of repoman
(In reply to comment #24) > > also, you may want to check your facts wrt my usage of repoman > Yeah I think repoman doesn't complain on glibc as it only checks dependencies. You would need to run it on some package depending directly on glibc probably to spot this.
