Bug#631845: ..unable to setup glx-alternative-mesa, glx-diversions or recover diversions set by libgl1-diversions

Tue Jun 28 00:01:47 UTC 2011

On Mon, 27 Jun 2011 20:32:22 +0200, Andreas wrote in message 
<4E08CCB6.3060502 at abeckmann.de>:

> On 2011-06-27 19:26, Arnt Karlsen wrote:
> > Package: glx-diversions
> > Version: 0.1.2
> 
> Looks like you are suffering an upgrade issue from the very first
> experimental version of glx-alternatives.

..yeah, I was looking for a nice easy way to go between radeon, 
fglrx and radeonhd to help swat FlightGear shader bugs that the 
Nvidea owner crowd doesn't see, and that they might see if they 
get a nice easy way to try test the nouveau driver. 

> > > pH  libgl1-diversions
> > > 0.0.0
> > > simplifies replacing MESA libGL with GPU vendor libraries
> > iu  glx-alternative-mesa          0.1.2      allows the selection of
> MESA as GL
> 
> > Removing 'diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1
> > to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by
> > libgl1-diversions' dpkg-divert: error: rename involves overwriting
> > `/usr/lib/x86_64-linux-gnu/libGL.so.1' with different file
> > `/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1', not allowed
> 
> Where is the /usr/lib/x86_64-linux-gnu/libGL.so.1 symbolic link
> pointing to?

..both libgl1-mesa-glx's link 'n file, and those appears to 
work now, and they are the ones to be used with radeon, no?
celsius:/var/cache/apt/archives# ll \
/usr/lib/x86_64-linux-gnu/libGL.so.1 
lrwxrwxrwx 1 root root 12 Jun 27 01:34 
/usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2
celsius:/var/cache/apt/archives# ll \
/usr/lib/x86_64-linux-gnu/libGL.so.1* 
lrwxrwxrwx 1 root root     12 Jun 27 01:34 
/usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 482752 Jun 19 22:06 
/usr/lib/x86_64-linux-gnu/libGL.so.1.2
celsius:/var/cache/apt/archives# dpkg -S \
/usr/lib/x86_64-linux-gnu/libGL.so.1* 
diversion by libgl1-diversions
from: /usr/lib/x86_64-linux-gnu/libGL.so.1 
diversion by libgl1-diversions
to: /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/libGL.so.1
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/libGL.so.1.2
celsius:/var/cache/apt/archives# 

> Could be from glx-alternative-mesa, so remove that package (and any
> other glx-alternative-{nvidia,fglrx}, too. Remove glx-diversions as
> well. This will probably need some more packages to be removed, you
> can install them again later on (if you need them at all).

..this worked, I dpkg -P --force-all etc and then apt-get -f install, 
and finally aptitude -t experimental.

> Eventually remove libgl1-mesa-glx, too.

..this was thrown out on my apt-get -f install, and 
came back in again with my upgrade to Experimental.

> If that doesn't help, delete /usr/lib/x86_64-linux-gnu/libGL.so.1
> (and eventually similar links that may produce errors later on),
> thereafter the removal of libgl1-diversions should succeed.

..ok, my impression was  the removal of libgl1-diversions failed 
because of an apt or dpkg database conflict, they only "see" the
permission "problem" running apt(itude|-get) or dpkg, AFAICT the 
"file system terrain" was ok.

> Reinstall libgl1-mesa-glx and everything you removed (and still want
> to have).

..done.  Now, automate it, so the package gets fixed, 
and not just my laptop?

> Unfortunately your log does not contain the steps that brought you
> into this situation - which package version was upgraded/installed in
> which order and what packages (and versions) were installed before.
> Eventually /var/log/dpkg.log* has some more history

..yeah, all of 3 days back.  I do have aptitude and apt history 
for the same 3 days.
celsius:/var/cache/apt/archives# less /var/log/dpkg.log
celsius:/var/cache/apt/archives# ll -h /var/log/dpkg.log*
-rw-r--r-- 1 root root 224K Jun 27 19:01 /var/log/dpkg.log
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.1
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.10.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.11.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.12.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.2.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.3.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.4.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.5.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.6.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.7.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.8.gz
-rw-r--r-- 1 root root    0 Jun 24 10:05 /var/log/dpkg.log.9.gz
celsius:/var/cache/apt/archives# 

..I see more glx mention:
celsius:~# grep glx /var/log/alternatives.log
update-alternatives 2011-06-24 10:33:41: run with
--install /usr/lib/glx glx /usr/lib/mesa-diverted 5
--slave /usr/lib/libGL.so.1
libGL.so.1 /usr/lib/mesa-diverted/libGL.so.1
--slave /usr/lib/i386-linux-gnu/libGL.so.1
libGL.so.1-i386-linux-gnu /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
--slave /usr/lib/x86_64-linux-gnu/libGL.so.1
libGL.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
--slave /usr/lib/xorg/modules/extensions/libglx.so
libglx.so /usr/lib/mesa-diverted/libglx.so
--slave /usr/lib/debug/usr/lib/xorg/modules/extensions/libglx.so
libglx.so.dbg /usr/lib/mesa-diverted/libglx.so.dbg update-alternatives
2011-06-24 10:33:41: auto-repair link group glx update-alternatives
2011-06-27 01:34:45: run with --remove-all glx update-alternatives
2011-06-27 01:34:45: link group glx fully removed celsius:~# 

..a new way to trash Konsole and command line history:
'mc /var/cache/apt/', then [F3] on pkgcache.bin. ;o)

> In my tests upgrades from 0.0.0 to 0.0.1 (which had replaced
> libgl1-diversions and libglx-diversions by glx-diversions)) went
> smoothly.
> 
> And there was no package ever (even in experimental) that needed
> 0.0.0, the first user was nvidia-graphics-drivers 275.09.07-2 which
> needed glx-alternative-nvidia (>= 0.0.1), so 0.0.0 and therefore
> libgl1-diversions should have been no longer available at that time.

..chances are I didn't auto-install it, I vaguely recall leaving 
all suggests picks green and that fglrx would not install and RL
issues taking precedence, nice recipe for debug guinea pigs. ;o)

> > ...apart from running out of nuclear ammo, I'm wondering WTF I have
> > to remove closed source Nvidea cruft from an ATI graphics laptop
> > running X.org's radeon driver, below paste is a few days worth of
> > nuclear snippets:
> 
> But obviously you had old packages from nvidia-graphics-drivers
> installed. 

..only: celsius:~# dpkg -l |grep nvidia |fmt -tu
ii nvidia-installer-cleanup 20110515+1 Cleanup after driver installation
   with the nvidia-installer
celsius:~# 

..or could this be it??????
celsius:~# dpkg -l |grep nouveau  |fmt -tu
ii libdrm-nouveau1a 2.4.26-1 Userspace interface to nouveau-specific
   kernel DRM services -- runtime

..I only brought in libdrm-nouveau1a in to chk it out.

> Or why did you install libgl1-diversions? Probably as a
> dependency of some upgrade, but that couldn't have happened.

..see above.  On how, I'm guessing I may have done 
a dpkg -EGi *.deb in /var/cache/apt/archives/.
celsius:~# apt-cache show libgl1-diversions  |fmt -tu 
Package: libgl1-diversions 
Status: deinstall ok half-installed 
Priority: optional 
Section: contrib/libs 
Installed-Size: 80 
Maintainer: Debian NVIDIA
Maintainers 
<pkg-nvidia-devel at lists.alioth.debian.org> 
Architecture: amd64 
Source: glx-alternatives 
Version: 0.0.0 
Config-Version: 0.0.0 
Replaces: libgl1-nvidia-alternatives (<= 275.09.07-1) 
Depends: dpkg (>= 1.15), glx-alternative-mesa 
Pre-Depends: nvidia-installer-cleanup 

> And if you want to read a bit about the diversions and alternatives,
> there is /usr/share/doc/glx-diversions/README.Debian (in the latest
> version).

..is this the root cause of what keeps the Nvidia crowd from seeing 
the shader bug we radeon card fliers see in FlightGear?:
libGL.so
========

The libGL.so link is managed by a dpkg trigger as an alternative, too.
But there are no alternative solutions available besides the diverted
link from the libgl1-mesa-dev package (if this package is installed),
so this cannot be reconfigured.  The intention behind this is to always
link an application at compile time to the MESA implementation of
libGL.so.1 in order to produce portable binaries, but to use the
accelerated libGL.so.1 when the application is being executed.

 -- Andreas Beckmann <debian at abeckmann.de>  Wed, 22 Jun 2011 12:44:11
 +0200

..I got:
celsius:/var/cache/apt/archives# update-alternatives --config glx
update-alternatives: error: no alternatives for glx.
celsius:/var/cache/apt/archives# 

..now, I get: :o)
celsius:~# update-alternatives --config glx
There is only one alternative in link group glx: /usr/lib/mesa-diverted
Nothing to configure.
celsius:~# 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.