Here is what happens when I emerge portage: Calculating dependencies | emerge: there are no ebuilds to satisfy "sys-libs/db:4.5". ---------------- I have extracted a new portage snapshot, the most recent version of my custom portage overlay and ran emerge --sync. I am at a stand still. Any help would be appreciated. Reproducible: Always Steps to Reproduce: 1.emerge portage Actual Results: portage failed to emerge because of sys-libs/db:4.5 Expected Results: successfully emerged portage
*** Bug 239276 has been marked as a duplicate of this bug. ***
*** Bug 239278 has been marked as a duplicate of this bug. ***
Have you tried to disable your overlay? What was the exact command you ran?
What version of sys-apps/portage do you have? Please post emerge --info output. I suspect that this might be some variant of bug 239006.
same problem: emerge --info emerge --info Portage 2.0.51.22-r2 (hardened/x86, gcc-3.3.6, glibc-2.3.5-r2, 2.6.11-hardened-r15 i686) ================================================================= System uname: 2.6.11-hardened-r15 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.13 app-admin/eselect-compiler: [Not Present] app-shells/bash: 3.0-r14 dev-java/java-config: [Not Present] dev-lang/python: 2.3.5 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/cmake: [Not Present] dev-util/confcache: [Not Present] sys-apps/baselayout: 1.11.13 sys-apps/openrc: [Not Present] sys-apps/sandbox: 1.2.12 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.16.1 sys-devel/gcc-config: 1.3.12-r6 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/X11/xkb /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks 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.asia.gentoo.org/gentoo-portage" USE="acl apache2 audiofile berkdb bzip2 cracklib crypt curl ethereal expat gd gdbm gmp gpm hardened idn imap jpeg libwww maildir mhash midi mysql ncurses nls notlsbeforeauth opengl pam pcre perl perlsuid pic png python readline slang ssl tcpd truetype urandom x86 xml2 xorg zlib apache2_modules_actions apache2_modules_alias apache2_modules_auth_basic apache2_modules_authn_alias apache2_modules_authn_anon apache2_modules_authn_dbm apache2_modules_authn_default apache2_modules_authn_file apache2_modules_authz_dbm apache2_modules_authz_default apache2_modules_authz_groupfile apache2_modules_authz_host apache2_modules_authz_owner apache2_modules_authz_user apache2_modules_autoindex apache2_modules_cache apache2_modules_dav apache2_modules_dav_fs apache2_modules_dav_lock apache2_modules_deflate apache2_modules_dir apache2_modules_disk_cache apache2_modules_env apache2_modules_expires apache2_modules_ext_filter apache2_modules_file_cache apache2_modules_filter apache2_modules_headers apache2_modules_include apache2_modules_info apache2_modules_log_config apache2_modules_logio apache2_modules_mem_cache apache2_modules_mime apache2_modules_mime_magic apache2_modules_negotiation apache2_modules_rewrite apache2_modules_setenvif apache2_modules_speling apache2_modules_status apache2_modules_unique_id apache2_modules_userdir apache2_modules_usertrack apache2_modules_vhost_alias input_devices_mouse input_devices_keyboard userland_GNU kernel_linux elibc_glibc alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mmap_emul alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol lcd_devices_bayrad lcd_devices_cfontz lcd_devices_cfontz633 lcd_devices_glk lcd_devices_hd44780 lcd_devices_lb216 lcd_devices_lcdm001 lcd_devices_mtxorb lcd_devices_ncurses lcd_devices_text" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY
(In reply to comment #6) > Portage 2.0.51.22-r2 (hardened/x86, gcc-3.3.6, glibc-2.3.5-r2, > 2.6.11-hardened-r15 i686) Well, what do you expect with a portage version that's been obsolete for over three years? It is vital that you regulary update sys-apps/portage to prevent problems caused by incompabilities between portage and the tree due to new features. (Zac: why do we keep 2.0.* in the tree, and why 2.0.51.22 instead of 2.0.54?) Looking at your emerge --info other critical packages on your system are also completely outdated. You'll have quite some trouble getting that system up to date by now as we generally cannot support such upgrade paths (I strongly recommend a general system update _at least_ every six months). A reinstall will be _much_ easier and quicker than an update of that system. There is nothing we can do about the problem in your case. Closing as CANTFIX, asusming that the reporter also uses an outdated system. If that's not the case please reopen.
(In reply to comment #7) > (Zac: why do we keep 2.0.* in the tree, and why 2.0.51.22 instead of 2.0.54?) 2.0.54 has no advantage over 2.1.1 since both require at least python 2.3 (see bug 124302). The only reason to keep 2.0.51.22 in the tree now would be as a means to upgrade a system which has python-2.2 installed and the installed portage is broken by bug 114798. In this case the user could conceivably find it useful to upgrade to portage-2.0.51.22 by following these instructions: http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml However, the situation is also complicated by the need to convert manifest2 to manifest1 as described here: http://www.gentoo.org/proj/en/portage/doc/converting-manifest2.xml The conversion script is affected by bug #238498. You can use FEATURES="-strict" to get around it but that entirely defeats the purpose of running the manifest221 script. Considering the number of issues that you are likely to encounter when attempting to upgrade an outdated system like this, it's probably a lot easier to reinstall from scratch.
(In reply to comment #8) > (In reply to comment #7) > > (Zac: why do we keep 2.0.* in the tree, and why 2.0.51.22 instead of 2.0.54?) > > 2.0.54 has no advantage over 2.1.1 since both require at least python 2.3 (see > bug 124302). The only reason to keep 2.0.51.22 in the tree now would be as a > means to upgrade a system which has python-2.2 installed and the installed > portage is broken by bug 114798. In this case the user could conceivably find > it useful to upgrade to portage-2.0.51.22 by following these instructions: > > http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml In that case at the very least it should be p.masked with a comment clearly telling the user that the version shouldn't be used in any other situation. But as you said, those users will encounter numerous other problems, so I don't think it's worth keeping that version in the tree at all, which indicates some level of support for it. But that's your call.
I've removed 2.0.51.22-r3 from the tree due to lack of EAPI support which renders it useless.
