Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 120414 - sys-kernel/vanilla-sources-2.6.15.1 fails due to collisions in /usr/share/man/man9/
Summary: sys-kernel/vanilla-sources-2.6.15.1 fails due to collisions in /usr/share/man...
Status: VERIFIED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-26 05:36 UTC by Nathan Adams
Modified: 2006-06-04 11:58 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Log of testing in reply to johnm (gentoo_bug_120414.txt,24.29 KB, text/plain)
2006-02-11 12:05 UTC, Nathan Adams
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Adams 2006-01-26 05:36:06 UTC
# 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.
Comment 1 Nathan Adams 2006-01-26 05:37:03 UTC
# 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
Comment 2 Henrik Brix Andersen 2006-01-30 01:54:38 UTC
Please confirm that the conflicting man pages are owned by another sys-kernel/*-sources package.
Comment 3 Nathan Adams 2006-02-05 20:14:11 UTC
# 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.
Comment 4 Henrik Brix Andersen 2006-02-08 05:43:24 UTC
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.
Comment 5 Nathan Adams 2006-02-09 18:17:12 UTC
Why not have the portage team take a look and make sure the bug isn't in the collision-protect code?
Comment 6 Henrik Brix Andersen 2006-02-10 01:41:34 UTC
(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.
Comment 7 Nathan Adams 2006-02-10 10:20:43 UTC
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.
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2006-02-10 10:45:32 UTC
(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.
Comment 9 Nathan Adams 2006-02-10 13:19:24 UTC
(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.
Comment 10 Henrik Brix Andersen 2006-02-10 14:03:34 UTC
(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.
Comment 11 Nathan Adams 2006-02-10 14:46:34 UTC
(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....
Comment 12 Henrik Brix Andersen 2006-02-10 14:54:33 UTC
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?
Comment 13 Nathan Adams 2006-02-10 15:07:54 UTC
(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()
Comment 14 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-02-10 15:15:16 UTC
(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.
Comment 15 Nathan Adams 2006-02-10 15:45:48 UTC
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.
Comment 16 Nathan Adams 2006-02-10 19:28:56 UTC
Re-opening since we now know who owns the files.
Comment 17 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-02-10 21:08:00 UTC
(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?
Comment 18 Jason Stubbs (RETIRED) gentoo-dev 2006-02-10 21:20:29 UTC
The previous owner seems to be the same cat/pkg. If there's a bug here, it's portage's.
Comment 19 Marius Mauch (RETIRED) gentoo-dev 2006-02-11 07:40:16 UTC
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.
Comment 20 Nathan Adams 2006-02-11 12:05:00 UTC
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
Comment 21 Nathan Adams 2006-02-11 12:09:48 UTC
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
Comment 22 Andrei Slavoiu 2006-06-03 01:05:54 UTC
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)
Comment 23 Nathan Adams 2006-06-03 07:12:15 UTC
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
Comment 24 Andrei Slavoiu 2006-06-03 08:56:53 UTC
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 25 Jakub Moc (RETIRED) gentoo-dev 2006-06-04 11:58:10 UTC
Comment on Bug 131648 if really needed. 

CLOSED.