# emerge -uv vanilla-sources {snip} * Installing manpages ... mkdir -p /var/tmp/portage/vanilla-sources-2.6.15.1/image//usr/share/man/man9/ install Documentation/DocBook/man/*.9.gz /var/tmp/portage/vanilla-sources-2.6.15.1/image//usr/share/man/man9/ [ ok ] man: prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded usr/src/linux-2.6.15.1/scripts/basic/docproc usr/src/linux-2.6.15.1/scripts/basic/fixdep usr/src/linux-2.6.15.1/scripts/basic/split-include strip: i686-pc-linux-gnu-strip --strip-unneeded strip: i686-pc-linux-gnu-strip --strip-unneeded strip: i686-pc-linux-gnu-strip --strip-unneeded >>> Completed installing vanilla-sources-2.6.15.1 into /var/tmp/portage/vanilla-sources-2.6.15.1/image/ * checking 21751 files for package collisions existing file /usr/share/man/man9/mac_vmode_to_var.9.gz is not owned by this package existing file /usr/share/man/man9/mac_var_to_vmode.9.gz is not owned by this package existing file /usr/share/man/man9/mac_map_monitor_sense.9.gz is not owned by this package existing file /usr/share/man/man9/alloc_etherdev.9.gz is not owned by this package 1000 files checked ... existing file /usr/share/man/man9/hcd_buffer_create.9.gz is not owned by this package existing file /usr/share/man/man9/mac_find_mode.9.gz is not owned by this package existing file /usr/share/man/man9/disable_irq.9.gz is not owned by this package existing file /usr/share/man/man9/enable_irq.9.gz is not owned by this package existing file /usr/share/man/man9/disable_irq_nosync.9.gz is not owned by this package existing file /usr/share/man/man9/hcd_buffer_destroy.9.gz is not owned by this package 2000 files checked ... 3000 files checked ... 4000 files checked ... 5000 files checked ... 6000 files checked ... 7000 files checked ... 8000 files checked ... 9000 files checked ... 10000 files checked ... 11000 files checked ... 12000 files checked ... 13000 files checked ... 14000 files checked ... 15000 files checked ... 16000 files checked ... 17000 files checked ... 18000 files checked ... 19000 files checked ... 20000 files checked ... 21000 files checked ... * spent 150.115754843 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 sys-kernel/vanilla-sources-2.6.15.1 NOT merged It was suggested that I -doc the kernel ebuild, but I actually find those manpages useful on occasion.
# emerge --info Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.14.2 i686) ================================================================= System uname: 2.6.14.2 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.2.3-r5, 2.3.5-r2, 2.4.2 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-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -funroll-loops -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/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/X11/app-defaults /etc/gconf /etc/hotplug /etc/hotplug/usb /etc/init.d /etc/lynx /etc/pam.d /etc/snort /etc/sound/events /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -funroll-loops -fprefetch-loop-arrays" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" 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 X a52 acl aim alsa arts artswrappersuid audiofile avi bash-completion bcmath berkdb bitmap-fonts browserplugin bzip2 bzlib caps cdr cpdflib cross crypt cscope ctype cups dedicated dga dio directfb divx4linux doc dts dv dvb dvd dvdr dvdread eds emboss encode ethereal exif expat fam fbcon fdftk ffmpeg fftw flac flash flatfile foomaticdb fortran gd gdbm ggi gif gimpprint ginac glut gmp gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile howl icq idn imagemagick imap imlib innodb iodbc jabber jack java jikes joystick jpeg junit kde kerberos krb4 ladcca lcms libedit libg++ libgda libwww lua mad matroska mcal mhash mikmod mime ming mmap mmx mng motif mp3 mpeg mpi msn ncurses netcdf nls nocd nsplugin offensive ofx ogg oggvorbis openal opengl oscar oss pam pcntl pcre pda pdflib perl plotutils png portaudio posix ppds python qt quicktime radeon readline recode sasl scanner sdl shared sharedmem simplexml slang smime sndfile sockets speex spell ssl svg svga sysvipc szip tcpd theora tidy tiff truetype truetype-fonts type1-fonts udev unicode usb v4l videos vorbis wddx win32codecs wmf x86 xine xml xml2 xmlrpc xpm xsl xv xvid yahoo zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS, MAKEOPTS
Please confirm that the conflicting man pages are owned by another sys-kernel/*-sources package.
# equery belongs /usr/share/man/man9/mac_vmode_to_var.9.gz [ Searching for file(s) /usr/share/man/man9/mac_vmode_to_var.9.gz in *... ] # equery belongs /usr/share/man/man9/mac_var_to_vmode.9.gz [ Searching for file(s) /usr/share/man/man9/mac_var_to_vmode.9.gz in *... ] # equery belongs /usr/share/man/man9/mac_map_monitor_sense.9.gz [ Searching for file(s) /usr/share/man/man9/mac_map_monitor_sense.9.gz in *... ] # equery belongs /usr/share/man/man9/hcd_buffer_create.9.gz [ Searching for file(s) /usr/share/man/man9/hcd_buffer_create.9.gz in *... ] # equery belongs /usr/share/man/man9/mac_find_mode.9.gz [ Searching for file(s) /usr/share/man/man9/mac_find_mode.9.gz in *... ] # equery belongs /usr/share/man/man9/disable_irq.9.gz [ Searching for file(s) /usr/share/man/man9/disable_irq.9.gz in *... ] # equery belongs /usr/share/man/man9/disable_irq_nosync.9.gz [ Searching for file(s) /usr/share/man/man9/disable_irq_nosync.9.gz in *... ] # equery belongs /usr/share/man/man9/hcd_buffer_destroy.9.gz [ Searching for file(s) /usr/share/man/man9/hcd_buffer_destroy.9.gz in *... ] So equery doesn't find the owning packages for those files on my systems. I wonder if they are new files and the bug is actually in the collision-protect code.
Nothing much we can do here since the files in question is not owned by another package. Feel free to reopen if you manage to find out where those files originated from.
Why not have the portage team take a look and make sure the bug isn't in the collision-protect code?
(In reply to comment #5) > Why not have the portage team take a look and make sure the bug isn't in the > collision-protect code? With the symptoms you've described in this bug report it can not be a bug in the collision protect code - the case you've described here is exactly what collision protect should catch. You're trying to install a package (with FEATURES=collision-protect set) which installs files that already exists in your ROOT filesystem, but aren't owned by another version of the package you're trying to install. Portage refuses to do this because of FEATURES=collision-protect, which is the expected behavior. My guess is that you've once manually run `make installmandocs` from a kernel source, causing those man pages to be there.
I've never run 'make installmandocs'; I've always used a script to compile and install kernels (after portage downloads and uncompresses them, mind you). I wrote the script, and all it does is: - backup the .config file - make mrproper - restore the .config file - make oldconfig - make menuconfig - make bzImage - make modules modules_install Perhaps equery is broken, or perhaps portage is broken such that certain files aren't getting recorded as belonging to a package. I have no clue how that actually works; I've never bothered looking at the source code for portage. But something is obviously screwy here.
(In reply to comment #7) So - once again: We cannot fix collisions with orphaned files, since we need to know which ebuild(s) installed the files causing the collision. So, unless you are able to find out the offending package, there's nothing we could here. > I have no clue how that actually works; I've never bothered looking at the >source code for portage. Seems so... Closing, reopen if you find what owns those conflicting files. Thanks.
(In reply to comment #8) > (In reply to comment #7) > > So - once again: We cannot fix collisions with orphaned files, since we need to > know which ebuild(s) installed the files causing the collision. So, unless you > are able to find out the offending package, there's nothing we could here. So *somewhere* there is a bug causing files to be orphaned? Any hints as to how to go about tracking down the files in question? > > I have no clue how that actually works; I've never bothered looking at the >source code for portage. > > Seems so... I could do without the snide remarks; I'm only trying to help track down a problem here... > Closing, reopen if you find what owns those conflicting files. Thanks. Will do.
(In reply to comment #9) > So *somewhere* there is a bug causing files to be orphaned? Any hints as to how > to go about tracking down the files in question? No, there is no such bug. For all I know, you could have created those files yourself using `for m in mac_vmode_to_var mac_var_to_vmode mac_map_monitor_sense alloc_etherdev hcd_buffer_create mac_find_mode disable_irq enable_irq disable_irq_nosync hcd_buffer_destroy; do touch /usr/share/man/man9/$m.9.gz; done` or similar. No more comments on this bug unless you find out where those files came from.
(In reply to comment #10) > (In reply to comment #9) > > So *somewhere* there is a bug causing files to be orphaned? Any hints as to how > > to go about tracking down the files in question? > > No, there is no such bug. > > For all I know, you could have created those files yourself using `for m in > mac_vmode_to_var mac_var_to_vmode mac_map_monitor_sense alloc_etherdev > hcd_buffer_create mac_find_mode disable_irq enable_irq disable_irq_nosync > hcd_buffer_destroy; do touch /usr/share/man/man9/$m.9.gz; done` or similar. > > No more comments on this bug unless you find out where those files came from. Lets think. The vanilla-sources ebuild uses the kernel-2.eclass, and the kernel-2.eclass has a compile_manpages() function that gets called when the doc useflag is set (the doc flag is set on my machine). Also, things such as mac_vmode_to_var, alloc_etherdev, and the like are kernel functions (which the kernel make stream can build manpages for). So which is more likely: I did some obnoxious touch command that just *happens* to collide with linux-2.6.15.1 man pages (and then filed a bug about it), OR a previous kernel ebuild installed those files... Hmmm....
Did we just exchange emails? You know, the one I told you to take this up on the gentoo-dev@ mailing list if you had any further problems with how this bug was dealt with?
(In reply to comment #12) > Did we just exchange emails? You know, the one I told you to take this up on > the gentoo-dev@ mailing list if you had any further problems with how this bug > was dealt with? > Did you read comment #11? You know, the one where I answered your question of where the files came from (comment #10). Hint: kernel-2.eclass::compile_manpages()
(In reply to comment #13) > (In reply to comment #12) > > Did we just exchange emails? You know, the one I told you to take this up on > > the gentoo-dev@ mailing list if you had any further problems with how this bug > > was dealt with? > > > > Did you read comment #11? You know, the one where I answered your question of > where the files came from (comment #10). > > Hint: kernel-2.eclass::compile_manpages() > Find the CONTENTS file in /var/db/pkg/*/* that has the files you speak of; if there is one, then this could be a portage bug. If there is no contents file that specifies them, then at one point *something* touched those files and they weren't unmerged with an earlier kernel due to the mtimes differing.
Thank you, Alec. Here is the first file in question: # ls /var/db/pkg/*/*/CONTENTS | xargs grep -i mac_vmode_to_var /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj /usr/man/man9/mac_vmode_to_var.9.gz 3363b26b5dc529dbd70c11909bd4d7c8 1105452039 /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj /usr/src/linux-2.6.10-r1/Documentation/DocBook/man/mac_vmode_to_var.9.gz 3363b26b5dc529dbd70c11909bd4d7c8 1105452039 /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj /usr/src/linux-2.6.10-r1/Documentation/DocBook/man/mac_vmode_to_var.sgml 034f318f8edc5b4bf776c8561ea38ad3 1105452039 /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj /usr/man/man9/mac_vmode_to_var.9.gz fcf4a413766a71e65d86c58a3a136230 1089084764 /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj /usr/src/linux-2.6.7/Documentation/DocBook/man/mac_vmode_to_var.9.gz fcf4a413766a71e65d86c58a3a136230 1089084764 /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj /usr/src/linux-2.6.7/Documentation/DocBook/man/mac_vmode_to_var.sgml 9db3746960477c217e4ad8bf9807551f 1089084764 /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj /usr/man/man9/mac_vmode_to_var.9.gz dee80191ff020cbb0e2070f925819610 1093237007 /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj /usr/src/linux-2.6.8.1/Documentation/DocBook/man/mac_vmode_to_var.9.gz dee80191ff020cbb0e2070f925819610 1093237007 /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj /usr/src/linux-2.6.8.1/Documentation/DocBook/man/mac_vmode_to_var.sgml 597dad3e8e26e4212d99b12408be4fe8 1093237007 /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj /usr/man/man9/mac_vmode_to_var.9.gz dfb9840ac2e8daf5c0a1ff6cf37d99df 1100599623 /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj /usr/src/linux-2.6.9/Documentation/DocBook/man/mac_vmode_to_var.9.gz dfb9840ac2e8daf5c0a1ff6cf37d99df 1100599623 /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj /usr/src/linux-2.6.9/Documentation/DocBook/man/mac_vmode_to_var.sgml ff4a122d9b4a1fba84f27dafa4a8b2f8 1100599623 The other 9 files return similiar results. Note that I have emerged the following kernels as well: # ls /usr/src/ linux linux-2.6.11.10 linux-2.6.11.11 linux-2.6.11.9 linux-2.6.12.5 linux-2.6.14.2 So now I wonder why kernel ebuilds after 2.6.10-r1 don't show up in the above results. I just recently added the collision-protect flag, so any potential collision bug could have slipped through until now.
Re-opening since we now know who owns the files.
(In reply to comment #15) > Thank you, Alec. Here is the first file in question: > > # ls /var/db/pkg/*/*/CONTENTS | xargs grep -i mac_vmode_to_var > /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj > /usr/man/man9/mac_vmode_to_var.9.gz 3363b26b5dc529dbd70c11909bd4d7c8 1105452039 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj > /usr/src/linux-2.6.10-r1/Documentation/DocBook/man/mac_vmode_to_var.9.gz > 3363b26b5dc529dbd70c11909bd4d7c8 1105452039 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.10-r1/CONTENTS:obj > /usr/src/linux-2.6.10-r1/Documentation/DocBook/man/mac_vmode_to_var.sgml > 034f318f8edc5b4bf776c8561ea38ad3 1105452039 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj > /usr/man/man9/mac_vmode_to_var.9.gz fcf4a413766a71e65d86c58a3a136230 1089084764 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj > /usr/src/linux-2.6.7/Documentation/DocBook/man/mac_vmode_to_var.9.gz > fcf4a413766a71e65d86c58a3a136230 1089084764 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.7/CONTENTS:obj > /usr/src/linux-2.6.7/Documentation/DocBook/man/mac_vmode_to_var.sgml > 9db3746960477c217e4ad8bf9807551f 1089084764 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj > /usr/man/man9/mac_vmode_to_var.9.gz dee80191ff020cbb0e2070f925819610 1093237007 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj > /usr/src/linux-2.6.8.1/Documentation/DocBook/man/mac_vmode_to_var.9.gz > dee80191ff020cbb0e2070f925819610 1093237007 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.8.1/CONTENTS:obj > /usr/src/linux-2.6.8.1/Documentation/DocBook/man/mac_vmode_to_var.sgml > 597dad3e8e26e4212d99b12408be4fe8 1093237007 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj > /usr/man/man9/mac_vmode_to_var.9.gz dfb9840ac2e8daf5c0a1ff6cf37d99df 1100599623 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj > /usr/src/linux-2.6.9/Documentation/DocBook/man/mac_vmode_to_var.9.gz > dfb9840ac2e8daf5c0a1ff6cf37d99df 1100599623 > /var/db/pkg/sys-kernel/vanilla-sources-2.6.9/CONTENTS:obj > /usr/src/linux-2.6.9/Documentation/DocBook/man/mac_vmode_to_var.sgml > ff4a122d9b4a1fba84f27dafa4a8b2f8 1100599623 > > The other 9 files return similiar results. Note that I have emerged the > following kernels as well: > > # ls /usr/src/ > linux linux-2.6.11.10 linux-2.6.11.11 linux-2.6.11.9 linux-2.6.12.5 > linux-2.6.14.2 > > So now I wonder why kernel ebuilds after 2.6.10-r1 don't show up in the above > results. I just recently added the collision-protect flag, so any potential > collision bug could have slipped through until now. > for the older kernels ( 2.6.9,2.6.7 ..etc ) did you just delete their kernel trees but never actually unmerge them?
The previous owner seems to be the same cat/pkg. If there's a bug here, it's portage's.
need at least the following information: - output of `ls -l /var/db/pkg/sys-kernel` - output of `ls -l ` for each file reported by collision-protect - CONTENTS files of package listing those files Please attach those all as separate files, posting inline makes it hard to read.
Created attachment 79518 [details] Log of testing in reply to johnm John Mylchreest wrote: > Basically, if it is colission detect then if the files > exist somewhere, and aren't owned by a package in portage, but another > package attempts to write to them its a collision. Since these docs > should always be available, then that shouldnt be a problem.. > HOWEVER.... > > vanilla-sources revisions will likely use the exact same path to install > mandocs, and since kernel-versions are SLOT'd it will likely look as > though the older revision still owns the files. > when we touch the makeman stuff, we should probably ensure it installs > to ${KV_FULL}, but to confirm this, emerge -C vanilla-sources *-sources, > emerge vanilla-sources and see if it breaks, it wont. then emerge > vanilla-sources-sameversion-diffrevision, and try again. it will likely > collide. > > Let me know how you get on. I was able to emerge vanilla-sources-2.6.15.1 without collision. The only differences I can think of are: - kernel-2.eclass has changed since I originally emerged the other kernels[1] - same for portage and (In reply to comment #17) > for the older kernels ( 2.6.9,2.6.7 ..etc ) did you just delete their kernel > trees but never actually unmerge them? - It is quite possible that I just deleted the old kernels instead of pruning them through portage[2] I also note that for vanilla-sources-2.6.11.11 through vanilla-sources-2.6.14.2 did not install any of the manpages in question, so there might be something worth looking at there. [1] http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/kernel-2.eclass [2] http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap9
Here is the remaining info that Marius Mauch requested (although it has obviously changed due to the last test): # ls -l /var/db/pkg/sys-kernel total 3 drwxr-xr-x 2 root root 920 Jul 9 2005 linux-headers-2.6.11-r2 drwxr-xr-x 2 root root 944 Feb 11 12:46 vanilla-sources-2.6.10 drwxr-xr-x 2 root root 944 Feb 11 13:18 vanilla-sources-2.6.11.11 drwxr-xr-x 2 root root 944 Feb 11 13:44 vanilla-sources-2.6.12.5 drwxr-xr-x 2 root root 944 Feb 11 13:56 vanilla-sources-2.6.14.2 drwxr-xr-x 2 root root 944 Feb 11 14:38 vanilla-sources-2.6.15.1
So why did you mark this as fixed if it still happens? I have the same problem when emerging sys-kernel/gentoo-sources-2.6.16-r9: [ Searching for file(s) /usr/share/man/man9/pid_alive.9.gz in *... ] sys-kernel/gentoo-sources-2.6.16-r7 (/usr/share/man/man9/pid_alive.9.gz) sys-kernel/gentoo-sources-2.6.16-r8 (/usr/share/man/man9/pid_alive.9.gz)
I didn't mark it as 'fixed'; I marked it as RESOLVED WORKSFORME because for me it now works... Try this and report back the output: # ls /var/db/pkg/*/*/CONTENTS | xargs grep -i pid_alive
I only read your last comment and I thought you maked it RESOLVED (this is what I meant to say, not fixed) by mistake. Now I read your previous message and saw that indeed it now works for you. I will open a new bug report for this since it is about a different package.
Comment on Bug 131648 if really needed. CLOSED.
