Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, 15 Feb 2012 21:31:02 -0500, Allan Gottlieb wrote: That's it! I had collision-protect in make.conf. I just now removed it and indeed emerge --info shows protect-owned. I have an emerge of libreoffice running now. But hope tomorrow to be able to retry the nvidia-drivers emerge and see if it goes through. There's no reason why you can't do it while the LO emerge is still running. -- Neil Bothwick WORM: (n.) acronym for Write Once, Read Mangled. Used to describe a normally-functioning computer disk of the very latest design. signature.asc Description: PGP signature
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Thu, Feb 16 2012, Neil Bothwick wrote: On Wed, 15 Feb 2012 21:31:02 -0500, Allan Gottlieb wrote: That's it! I had collision-protect in make.conf. I just now removed it and indeed emerge --info shows protect-owned. I have an emerge of libreoffice running now. But hope tomorrow to be able to retry the nvidia-drivers emerge and see if it goes through. There's no reason why you can't do it while the LO emerge is still running. First, let me report success (I ran the emerge of nvidia-drivers after LO finished and it worked fine) and thanks. I didn't realize that I could run emerges together. The emerge of LO was the penultimate merge coming from an emerge update world (the last was LO-l10n) While this LO merge was in progress could I have safely started another emerge update world ? I am guessing the point is that, since the running emerge was essentially just LO, it was safe to run the nvidia-drivers emerge since there are no shared dependencies. Is emerge by some chance clever enough that you can always start an update world, while one is running? thanks again, allan
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.02.2012 14:09, Allan Gottlieb wrote: On Thu, Feb 16 2012, Neil Bothwick wrote: On Wed, 15 Feb 2012 21:31:02 -0500, Allan Gottlieb wrote: That's it! I had collision-protect in make.conf. I just now removed it and indeed emerge --info shows protect-owned. I have an emerge of libreoffice running now. But hope tomorrow to be able to retry the nvidia-drivers emerge and see if it goes through. There's no reason why you can't do it while the LO emerge is still running. First, let me report success (I ran the emerge of nvidia-drivers after LO finished and it worked fine) and thanks. I didn't realize that I could run emerges together. The emerge of LO was the penultimate merge coming from an emerge update world (the last was LO-l10n) While this LO merge was in progress could I have safely started another emerge update world ? I am guessing the point is that, since the running emerge was essentially just LO, it was safe to run the nvidia-drivers emerge since there are no shared dependencies. Is emerge by some chance clever enough that you can always start an update world, while one is running? thanks again, allan Two emerge update worlds I wouldn't recommend, because most likely you would emerge some packages two times. emerge package while emerge --update world is running is reasonably stable, at least in my experience. The biggest problem is slowdown and maybe out-of-memory-errors if you emerge multiple big packages (e.g. libre office and chromium). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPPQL4AAoJEJwwOFaNFkYcEkkIAKPS7VgHjeFC6eG700aMOu/7 PHvgkKpsyeEZO78V65zFJePMyNBSzbskY5uXCtz2MLLHsuSkyznvJxzXNy/kycL8 6vFAHx6yKgQeudTaXkYxh9FhhVRSbnkedBqVR1x2k+1yhHTjQdsG5iDq0yBZucYi Hij1KIPKuylhAegp6v0c37dHbB9y9dmKAIW8wYxGfU2sOj6om2ALFZgKWfS1UpQx 1oWjWW93SV68qGVEGXDAyW1DvfDAhfYXF4b6WkCfBBZGVAyRtfRbSIQCs5R6piJi lr97+765+FFOXc/4DxtNPL4bLg40iEynJRQUJrQV2ukibAFusACfskB9MFpg4WY= =Bw/t -END PGP SIGNATURE-
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Thu, 16 Feb 2012 08:09:38 -0500, Allan Gottlieb wrote: I didn't realize that I could run emerges together. The emerge of LO was the penultimate merge coming from an emerge update world (the last was LO-l10n) While this LO merge was in progress could I have safely started another emerge update world No, because LO still needed to be updated, so you'd have ended up trying to compile it twice in parallel. I am guessing the point is that, since the running emerge was essentially just LO, it was safe to run the nvidia-drivers emerge since there are no shared dependencies. Is emerge by some chance clever enough that you can always start an update world, while one is running? There's an easy way to test this, if we don't hear back from you I'll assume it is not safe :) -- Neil Bothwick Windows will never cease. signature.asc Description: PGP signature
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage).
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage). It may be related to all the OpenCL stuff that was just included in this last set of nvidia-driver packages. Possibly the ebuild hasn't handled the new stuff correctly? - Mark
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15 2012, Paul Hartman wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? I ran equery belongs and each of those files are owned by nvidia-drivers, the package that is being emerged. They are of course owned by the current version -295.10-r1. I am trying to merge the new version -295.20-r1. thanks allan
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15 2012, Mark Knecht wrote: On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage). It may be related to all the OpenCL stuff that was just included in this last set of nvidia-driver packages. Possibly the ebuild hasn't handled the new stuff correctly? - Mark Perhaps. All the files are links to files with OpenCL in the path. But I am still unsure what to do. I mentioned a three step procedure above. Perhaps best is to do nothing and hope -r2 will come along and install cleanly. Toward that end should I file a bug at bugs.gentoo.org? allan
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb gottl...@nyu.edu wrote: On Wed, Feb 15 2012, Mark Knecht wrote: On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage). It may be related to all the OpenCL stuff that was just included in this last set of nvidia-driver packages. Possibly the ebuild hasn't handled the new stuff correctly? - Mark Perhaps. All the files are links to files with OpenCL in the path. But I am still unsure what to do. I mentioned a three step procedure above. Perhaps best is to do nothing and hope -r2 will come along and install cleanly. Toward that end should I file a bug at bugs.gentoo.org? allan I'm emerging the package here to investigate whether it's a global issue or maybe just one you are seeing. I'll get back to you on that. I think if it was me (and it may be in 10 minutes...) then I'd drop into the console, emerge -C nvidia-drivers, probably run revdep-rebuild or something to look for files that aren't owned, remove them by hand, and then emerge nvidia-drivers back in. - Mark
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 11:43 AM, Mark Knecht markkne...@gmail.com wrote: On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb gottl...@nyu.edu wrote: On Wed, Feb 15 2012, Mark Knecht wrote: On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage). It may be related to all the OpenCL stuff that was just included in this last set of nvidia-driver packages. Possibly the ebuild hasn't handled the new stuff correctly? - Mark Perhaps. All the files are links to files with OpenCL in the path. But I am still unsure what to do. I mentioned a three step procedure above. Perhaps best is to do nothing and hope -r2 will come along and install cleanly. Toward that end should I file a bug at bugs.gentoo.org? allan I'm emerging the package here to investigate whether it's a global issue or maybe just one you are seeing. I'll get back to you on that. I think if it was me (and it may be in 10 minutes...) then I'd drop into the console, emerge -C nvidia-drivers, probably run revdep-rebuild or something to look for files that aren't owned, remove them by hand, and then emerge nvidia-drivers back in. - Mark OK, here I saw the same file list but the emerge didn't fail. The installation told me it was overwriting the files because no one claimed to own them. That's some sort of ebuild problem and I'd agree that a bug should be filed. HTH, Mark
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 2:04 PM, Mark Knecht markkne...@gmail.com wrote: On Wed, Feb 15, 2012 at 11:43 AM, Mark Knecht markkne...@gmail.com wrote: On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb gottl...@nyu.edu wrote: On Wed, Feb 15 2012, Mark Knecht wrote: On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb gottl...@nyu.edu wrote: Nvidia-drivers fails with package collisions * Detected file collision(s): * * /usr/lib32/libnvidia-compiler.so * /usr/lib32/libcuda.so * /usr/lib32/libcuda.so.1 * /usr/lib64/libnvidia-compiler.so * /usr/lib64/libcuda.so * /usr/lib64/libcuda.so.1 But the owner of all these (via a symlink) is the currently installed version of nvidia-drivers. For example ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 * Searching for /usr/lib32/libcuda.so.1 ... x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) ajglap gottlieb # ls -l !$ ls -l /usr/lib32/libcuda.so.1 lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 - OpenCL/vendors/nvidia/libcuda.so.290.10 So I don't really see the collision. Is the correct procedure 1. Copy the 12 files (both ends of the 6 links) someplace else 2. Get out of X 3. Try the emerge again thanks, allan Are the collisions with owned files, or just files that it doesn't know about? i use protect-owned so it will overwrite any unknown files, but abort on files owned by another known installed package. If portage does not report them as owned by another package I think it's usually safe to override (unless you have been installing things outside of portage). It may be related to all the OpenCL stuff that was just included in this last set of nvidia-driver packages. Possibly the ebuild hasn't handled the new stuff correctly? - Mark Perhaps. All the files are links to files with OpenCL in the path. But I am still unsure what to do. I mentioned a three step procedure above. Perhaps best is to do nothing and hope -r2 will come along and install cleanly. Toward that end should I file a bug at bugs.gentoo.org? allan I'm emerging the package here to investigate whether it's a global issue or maybe just one you are seeing. I'll get back to you on that. I think if it was me (and it may be in 10 minutes...) then I'd drop into the console, emerge -C nvidia-drivers, probably run revdep-rebuild or something to look for files that aren't owned, remove them by hand, and then emerge nvidia-drivers back in. - Mark OK, here I saw the same file list but the emerge didn't fail. The installation told me it was overwriting the files because no one claimed to own them. That's some sort of ebuild problem and I'd agree that a bug should be filed. That behavior can be controlled by your FEATURES settings (collision-protect or protect-owned) and optionally modified further in make.conf by COLLISION_IGNORE.
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 12:49 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: SNIP OK, here I saw the same file list but the emerge didn't fail. The installation told me it was overwriting the files because no one claimed to own them. That's some sort of ebuild problem and I'd agree that a bug should be filed. That behavior can be controlled by your FEATURES settings (collision-protect or protect-owned) and optionally modified further in make.conf by COLLISION_IGNORE. Good to know. I guess the default setting must be to overwrite as I've not made any of those setting changes. - Mark
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, 15 Feb 2012 13:00:57 -0800, Mark Knecht wrote: That behavior can be controlled by your FEATURES settings (collision-protect or protect-owned) and optionally modified further in make.conf by COLLISION_IGNORE. Good to know. I guess the default setting must be to overwrite as I've not made any of those setting changes. emerge --info will show you the settings in use. -- Neil Bothwick Top Oxymorons Number 48: freewill offering signature.asc Description: PGP signature
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15, 2012 at 2:18 PM, Neil Bothwick n...@digimed.co.uk wrote: On Wed, 15 Feb 2012 13:00:57 -0800, Mark Knecht wrote: That behavior can be controlled by your FEATURES settings (collision-protect or protect-owned) and optionally modified further in make.conf by COLLISION_IGNORE. Good to know. I guess the default setting must be to overwrite as I've not made any of those setting changes. emerge --info will show you the settings in use. -- Neil Bothwick Of course, but if you don't know about collision-protect, for instance, then how would one even know to put it there? man make.conf does show the collision-protect option, along with some others that look cool. I haven't read that man page in literally years, if not close to a decade! Cheers, Mark FEATURES=assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, 15 Feb 2012 14:44:18 -0800, Mark Knecht wrote: Good to know. I guess the default setting must be to overwrite as I've not made any of those setting changes. emerge --info will show you the settings in use. Of course, but if you don't know about collision-protect, for instance, then how would one even know to put it there? emerge --info shows the defaults and settings from your profile, not just what you put in make.conf. I have nothing relating to collision protection in make.conf but emerge --info shows protect-owned in FEATURES (I think the default used to be collision-protect). -- Neil Bothwick This message has been cruelly tested on sweet little furry animals. signature.asc Description: PGP signature
Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1
On Wed, Feb 15 2012, Neil Bothwick wrote: On Wed, 15 Feb 2012 14:44:18 -0800, Mark Knecht wrote: Good to know. I guess the default setting must be to overwrite as I've not made any of those setting changes. emerge --info will show you the settings in use. Of course, but if you don't know about collision-protect, for instance, then how would one even know to put it there? emerge --info shows the defaults and settings from your profile, not just what you put in make.conf. I have nothing relating to collision protection in make.conf but emerge --info shows protect-owned in FEATURES (I think the default used to be collision-protect). That's it! I had collision-protect in make.conf. I just now removed it and indeed emerge --info shows protect-owned. I have an emerge of libreoffice running now. But hope tomorrow to be able to retry the nvidia-drivers emerge and see if it goes through. thanks, allan
