I don't know if this is a configuration issue on my side but I found nothing suspicious. When running "emerge -pvuND @world" I get the following warning: WARNING: One or more updates have been skipped due to a dependency conflict: app-arch/libarchive:0 (app-arch/libarchive-3.1.2-r1::gentoo, ebuild scheduled for merge) conflicts with app-arch/libarchive:0/0= required by (gnome-base/gvfs-1.12.3-r1::gentoo, installed) Output of "emerge -pv --depclean app-arch/libarchive" Calculating dependencies ... done! app-arch/libarchive-3.0.4-r1 pulled in by: dev-util/cmake-2.8.9 requires >=app-arch/libarchive-2.8.0 gnome-base/gvfs-1.12.3-r1 requires app-arch/libarchive:=, app-arch/libarchive:0/0= So only dev-util/cmake and gnome-base/gvfs require libarchive and from the dependencies libarchive-3.1.2-r1 should satisfy it. Output of "emerge --info" Portage 2.1.11.55 (default/linux/x86/13.0, gcc-4.6.3, glibc-2.15-r3, 3.7.10-gentoo i686) ================================================================= System uname: Linux-3.7.10-gentoo-i686-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.1 KiB Mem: 2071704 total, 182892 free KiB Swap: 2008120 total, 2004200 free Timestamp of tree: Wed, 10 Apr 2013 16:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 ccache version 3.1.9 [enabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/ccache: 3.1.9 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo sunrise portage-billie ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/media/system/source/distfiles" EMERGE_DEFAULT_OPTS="--oneshot --with-bdeps=y" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs buildpkg candy ccache collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans xattr" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirror.netcologne.de/gentoo/ http://ftp.halifax.rwth-aachen.de/gentoo/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://ftp.heanet.ie/pub/gentoo/" LANG="POSIX" LC_ALL="POSIX" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=gnu" MAKEOPTS="-j3" PKGDIR="/media/system/source/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--human-readable" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/media/system/tmp" PORTDIR="/media/system/repositories/portage" PORTDIR_OVERLAY="/media/system/repositories/sunrise /media/system/repositories/portage-billie" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl adns alsa amr bash-completion berkdb bidi bluray branding bs2b bzip2 cairo caps cdda cddb cdio cli consolekit cracklib crypt cups curl cxx dbus dga dirac djvu dri dts dv dvb dvd encode exif faac fbcon ffmpeg fftw flac fontconfig fortran gdbm gif gimp gnutls gpm graphviz gsm gstreamer gtk gtk3 iconv icu id3tag idn ieee1394 imlib introspection ipv6 java jbig jpeg jpeg2k kate ladspa lame lcms libass libcaca libnotify libproxy libsamplerate lua lzma lzo mad metalink midi mms mmx mmxext mng modplug modules mono mp3 mpeg mudflap musepack ncurses nls nptl nsplugin ogg openal opengl openmp opus oss pam pcre pdf phonon png policykit postscript pvr qt4 readline rle rtmp scanner schroedinger session sid slang sndfile speex spell sse sse2 sse3 ssl ssse3 startup-notification svg taglib tcpd theora threads tiff truetype twolame udev unicode v4l vaapi vcd vidix vim-syntax vorbis vpx wavpack webkit win32codecs wmf wxwidgets x264 x86 xattr xcb xml xmp xv xvid zlib" ABI_X86="32" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LIBREOFFICE_EXTENSIONS="nlpsolver pdfimport presenter-console presenter-minimizer report-builder" LINGUAS="de en" OFFICE_IMPLEMENTATION="libreoffice" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="hp" USERLAND="GNU" VIDEO_CARDS="fbdev v4l vesa vga nv nouveau" XFCE_PLUGINS="clock logout trash" USE_PYTHON="2.7 3.2" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
I can't reproduce. The ebuilds look all fine in CVS. I suspect this is something to do with the new subslots and how the package manager picks them up.
This may be a duplicate of bug 461464. Please post the output of this command: emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs
(In reply to comment #2) > This may be a duplicate of bug 461464. Please post the output of this > command: > > emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild U ] app-arch/libarchive-3.1.2-r1:0/13 [3.0.4-r1:0/0] USE="acl bzip2 e2fsprogs iconv lzma lzo%* xattr zlib -expat -nettle -static-libs" 4,422 kB [ebuild R ] dev-util/cmake-2.8.9 USE="ncurses qt4 vim-syntax -emacs {-test}" 0 kB [ebuild R ] gnome-base/gvfs-1.12.3-r1 USE="archive bluray cdda http udev -afp -avahi -bluetooth -doc -fuse -gdu -gnome-keyring -gphoto2 -ios -samba (-udisks*)" 0 kB Total: 3 packages (1 upgrade, 2 reinstalls), Size of downloads: 4,422 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: gnome-base/gvfs:0 (gnome-base/gvfs-1.12.3-r1::gentoo, installed) pulled in by >=gnome-base/gvfs-1.10.1[udisks,udev] required by (xfce-base/thunar-1.4.0::gentoo, installed) (gnome-base/gvfs-1.12.3-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) app-arch/libarchive:0 (app-arch/libarchive-3.1.2-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (app-arch/libarchive-3.0.4-r1::gentoo, installed) pulled in by app-arch/libarchive:0/0= required by (gnome-base/gvfs-1.12.3-r1::gentoo, installed) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
(In reply to comment #3) > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > (xfce-base/thunar-1.4.0::gentoo, installed) This one dependency may be the source of all your problems. It looks like gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you rebuild thunar too: emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs xfce-base/thunar
(In reply to comment #4) > (In reply to comment #3) > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > (xfce-base/thunar-1.4.0::gentoo, installed) > > This one dependency may be the source of all your problems. It looks like > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > rebuild thunar too: The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, it was later corrected and masked again in base/package.use.mask Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be capable of being satisfied by it on the fly without re-emerging anything :-/
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > > (xfce-base/thunar-1.4.0::gentoo, installed) > > > > This one dependency may be the source of all your problems. It looks like > > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > > rebuild thunar too: > > The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, > it was later corrected and masked again in base/package.use.mask Okay, that explains it. > Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's > defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be > capable of being satisfied by it on the fly without re-emerging anything :-/ He has to re-emerge it with USE=gdu enabled, because he has it disabled, as you can see in comment #3.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > > > (xfce-base/thunar-1.4.0::gentoo, installed) > > > > > > This one dependency may be the source of all your problems. It looks like > > > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > > > rebuild thunar too: > > > > The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, > > it was later corrected and masked again in base/package.use.mask > > Okay, that explains it. > > > Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's > > defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be > > capable of being satisfied by it on the fly without re-emerging anything :-/ > > He has to re-emerge it with USE=gdu enabled, because he has it disabled, as > you can see in comment #3. Thank you both. So the problem was me having installed gvfs with use udisks while it was temporarily unmasked?
(In reply to comment #7) > Thank you both. So the problem was me having installed gvfs with use udisks > while it was temporarily unmasked? Yeah, so the dep is satisfied by the installed version, since it was built before the flag got masked. Meanwhile, rebuilding it would break the || ( >=gnome-base/gvfs-1.10.1[udisks,udev] >=gnome-base/gvfs-1.10.1[gdu,udev] ) dependency, since udisks is now masked and you don't have USE=gdu enabled.
(In reply to comment #8) > (In reply to comment #7) > > Thank you both. So the problem was me having installed gvfs with use udisks > > while it was temporarily unmasked? > > Yeah, so the dep is satisfied by the installed version, since it was built > before the flag got masked. Meanwhile, rebuilding it would break the || ( > >=gnome-base/gvfs-1.10.1[udisks,udev] >=gnome-base/gvfs-1.10.1[gdu,udev] ) > dependency, since udisks is now masked and you don't have USE=gdu enabled. So, there was nothing to do here and this can be closed as INVALID or WORKSFORME? Or is the bug open still for reason? unCCing libarchive maintainers (including myself) ->
(In reply to comment #9) > So, there was nothing to do here and this can be closed as INVALID or > WORKSFORME? > Or is the bug open still for reason? Well, if portage output is confusing then maybe we can improve it somehow.
Well, I CCed myself because I had a similar issue some days ago and I needed to figure out that a rebuild of affected packages was necessary. If portage can improve its message to show this tip, would be nice. If it's hard to do, no problem :)
(In reply to comment #10) > (In reply to comment #9) > > So, there was nothing to do here and this can be closed as INVALID or > > WORKSFORME? > > Or is the bug open still for reason? > > Well, if portage output is confusing then maybe we can improve it somehow. Improving the output would definitely help. I was unable to figure out what went wrong.
