Updating ttf-bitstream-vera to version 1.10-r3 yields a package collision for file /usr/share/fonts/ttf-bitstream-vera/encodings.dir. Isn't this file supposed to be generated by ttmkfdir or somesuch? Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. emerge -1av ttf-bitstream-vera Actual Results: * checking 17 files for package collisions existing file /usr/share/fonts/ttf-bitstream-vera/encodings.dir is not owned by this package * spent 0.0289587974548 seconds checking for file collisions * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package media-fonts/ttf-bitstream-vera-1.10-r3 NOT merged Expected Results: Emerged the package normally. Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.12-gentoo-r9 i686) ================================================================= System uname: 2.6.12-gentoo-r9 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5 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.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /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/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mirror.switch.ch/mirror/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LC_ALL="it_IT.utf8" LINGUAS="it" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d aalib acpi alsa arts avi berkdb bitmap-fonts bzip2 bzlib caps cdparanoia cdr crypt cups curl dga dio divx4linux doc eds emboss encode exif fam fbcon ffmpeg fftw flac foomaticdb fortran ftp gcj gd gdbm gif glut gmp gphoto2 gpm gstreamer gtk2 hal iconv imagemagick java javascript jpeg kde kdeenablefinal kdexdeltas libg++ libwww lm_sensors mad maildir memlimit mikmod mime mmap mmx mng motif mozilla mp3 mpeg ncurses nls nptl offensive ogg oggvorbis openal opengl oss pam pcre pdflib perl png posix ppds python qt quicktime readline recode samba sdl sharedmem slang sndfile sockets sox speex spell sse ssl svg symlink sysfs sysvipc tcpd tetex threads tidy tiff truetype truetype-fonts type1-fonts unicode usb vcd vorbis win32codecs wmf xine xml2 xv xvid zlib linguas_it userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, PORTDIR_OVERLAY
So what owns that file currently? (equery belongs /usr/share/fonts/ttf-bitstream-vera/encodings.dir) It looks like the Vera fonts are being provided with Xorg now, at least with xorg-x11-6.8.2-r2, what version of X do you have?
I tried at the time and the file belonged to no package. As for X at the time I had xorg-x11-6.8.2-r2 (which now has been replaced by 6.8.2-r4). Now the files belongs to ttf-bitstream-vera: equery belongs /usr/share/fonts/ttf-bitstream-vera/encodings.dir [ Searching for file(s) /usr/share/fonts/ttf-bitstream-vera/encodings.dir in *... ] media-fonts/ttf-bitstream-vera-1.10-r3 (/usr/share/fonts/ttf-bitstream-vera/encodings.dir)
So this isn't still a problem? Seeing as we can't tell where the colliding file originally came from, reopen if it persists.
