Bug 35044 – Cannot resolve a virtual package name to an ebuild

• Status: VERIFIED NEEDINFO
• Product: Portage Development

[Description Freyr Gunnar Ólafsson 2003-12-04 03:51:43 UTC]

when search portage or updateing (with -up or -DUup world) it complaines that it
cannot resolve a virtual package to an ebuild. The virtual package is
virtual/cdrtools-2.01_alpha18-r1
virtual/cdrtools-2.01_alpha16
virtual/cdrtools-1.11.40
virtual/cdrtools-1.11.39-r1
virtual/cdrtools-2.01_alpha19
virtual/cdrtools-2.01_alpha14

So in short .. all cdrtools virtual packages cannot be traced to an ebuild. This
is immediately stopping me from upgrading my world profile :(




Reproducible: Always
Steps to Reproduce:
1. emerge sync
2. emerge -DUup world
3. emerge -u cdrtools

Actual Results:  
Calculating dependencies   !!! Cannot resolve a virtual package name to an ebuild.
!!! This is a bug, please report it. (virtual/cdrtools-2.01_alpha18-r1)

!!! Problem in virtual/cdrtools dependencies.
!!! 1


Expected Results:  
to update package !  

Portage 2.0.49-r18 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.23-pre9)
=================================================================
System uname: 2.4.23-pre9 i686 AMD Athlon(tm) processor
Gentoo Base System version 1.4.3.12
ccache version 2.3 [enabled]
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-mcpu=athlon-tbird -O3 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://gentoo.oregonstate.edu
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
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="3dnow S3TC X aalib alsa apache2 apm avi berkdb cdr crypt cups dga directfb
doc dvd encode fbcon fbdev foomaticdb gdbm gif gpm gtk gtk2 java jpeg mad
maildir mikmod mmx mozilla mpeg music mysql nas ncurses nls nocd oggvorbis
openal opengl oss pam pdflib perl png python qt quicktime readline scanner sdl
slang speedo ssl stencil-buffer svga tcltk tcpd tetex tiff truetype usb x86
xface xml2 xmms xv xvid zlib"

[Comment 1 Lars Weiler (RETIRED) 2003-12-04 20:09:29 UTC]

I can reproduce it on my stable x86-box with the (testing) cdrtools-2.01_alpha20 installed, when I run  ACCEPT_KEYWORDS="~x86" emerge -DUp cdrdao  (it's a dependency).

I saw, that virtual/cdrtools is not listed in the profiles.  But adding it locally didn't changed anything.  Sorry, I don't know further.

So I call vapier that he may help ;-)

[Comment 2 SpanKY 2003-12-15 01:39:49 UTC]

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

[Comment 3 SpanKY 2003-12-15 01:40:14 UTC]

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

[Comment 4 Lars Weiler (RETIRED) 2004-01-21 17:37:45 UTC]

Does not seem to be valid any more after I added a newer version of cdrtools to portage.  Maybe it could also have been a bug in portage.  AFAIR there were some issues with virtual packages.  May you test it?

[Comment 5 SpanKY 2004-01-21 17:40:15 UTC]

sorry man, i was totally unable to reproduce this :/

[Comment 6 Lars Weiler (RETIRED) 2004-01-21 18:31:12 UTC]

No problem.  Let's wait a day or two what others in the Cc say.

[Comment 7 Andrea Cerrito 2004-01-22 02:21:31 UTC]

My problem was a missing entry in the virtuals file.
Virtuals now it's ok, so I cannot reproduce this neither mine (35856) bug.

[Comment 8 Lars Weiler (RETIRED) 2004-01-22 08:46:36 UTC]

Thanks for testing.  I close this bug.