Bug#704914: glx-alternatives: The libGL diversion does not work
Source: glx-alternatives Version: 0.2.90 Severity: grave Justification: renders package unusable There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). This means the gnome desktop in 3.8 is NOT co-installable with nvidia graphics drivers, a situation this diversion was meant to prevent. The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. I read bug 389971, on the reasons the nvidia-glx* packages don't directly provide libgl1, but it may be that unless the gnome team changes their libgl deps, this might be the only solution (or, alternatively, making the glx-alternatives packages provide libgl1?) It should be noted, that the nvidia alternative clearly *works*, however, making it so is pretty challenging. Info on my system as it stands at present: # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions from: /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions to: /usr/lib/mesa-diverted/x86_64-linux- gnu/libGL.so.1 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1 # dpkg --remove libgl1-mesa-glx:amd64 dpkg: dependency problems prevent removal of libgl1-mesa-glx:amd64: gnome-session-bin depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libvisual-0.4-plugins:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libglew1.7:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. enblend depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. mplayer depends on libgl1-mesa-glx | libgl1; however: Package libgl1-me dpkg: error processing libgl1-mesa-glx:amd64 (--remove): dependency problems - not removing Errors were encountered while processing: libgl1-mesa-glx:amd64 Thanks Christian -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
Control: reassign -1 glx-diversions 0.2.90 Control: tag -1 moreinfo On 2013-04-07 17:43, Christian Weeks wrote: There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). I'm sorry, but what exactly is the problem you experienced? The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. So what is broken before this command and fixed afterwards? # dpkg --remove libgl1-mesa-glx:amd64 and why would you want to do that? Unfortunately you reported this against the source package, so no scripts were run that could collect additional information. I've reassigned this bug to the glx-diversions package, please run reportbug -N 704914 on the *broken* system, that should collect some helpful information. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:17 PM, Andreas Beckmann wrote: Control: reassign -1 glx-diversions 0.2.90 Control: tag -1 moreinfo On 2013-04-07 17:43, Christian Weeks wrote: There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). I'm sorry, but what exactly is the problem you experienced? libGL is brokenly referring to the libgl from mesa whereas it should be referring to the libGL from the nvidia packages. This breaks the gnome desktop. Gnome shell fails to start with an error, or any gnome application fails to launch, as the link is gone, replaced by the actual lib from that libgl-mesa-glx package. This affects almost all desktop applications that are linked against gnome. This is with the current gnome 3.8 environment in experimental. The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. So what is broken before this command and fixed afterwards? Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 Running the command: # update-alternatives --config glx There is only one alternative in link group glx (providing /usr/lib/glx): /usr/lib/nvidia Nothing to configure. update-alternatives: warning: forcing reinstallation of alternative /usr/lib/nvidia because link group glx is broken After: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 Apr 7 12:23 /usr/lib/x86_64-linux-gnu/libGL.so.1 - /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu If I do not run this command, after any package installation or update, Gnome is completely broken, because mesa isn't functional on this system, because it is using the NVIDIA libraries. # dpkg --remove libgl1-mesa-glx:amd64 and why would you want to do that? Because it's the wrong thing for this system? It keeps replacing the nvidia GL with it's own? But I added it here because it shows how the libgl1 virtual dependency has crept from the base packages into the gnome packages. Unfortunately you reported this against the source package, so no scripts were run that could collect additional information. I've reassigned this bug to the glx-diversions package, please run reportbug -N 704914 on the *broken* system, that should collect some helpful information. Acknowledged. That'll be run forthwith. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
Control: severity -1 wishlist Control: retitle -1 does not divert libGL.so.1.2.0 from mesa 9.0.1-1 On 2013-04-07 18:26, Christian Weeks wrote: Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 This is not the Debian libgl1-mesa-glx. That would contain /usr/lib/x86_64-linux-gnu/libGL.so.1.2 which is properly diverted. On 2013-04-07 18:30, Christian Weeks wrote: Versions of packages glx-diversions is related to: ii libgl1-mesa-glx [libgl1] 9.0.1-1 Exactly :-) $ rmadison --arch amd64 libgl1-mesa-glx libgl1-mesa-glx | 7.7.1-5 | squeeze | amd64 libgl1-mesa-glx | 7.10.3-4~bpo60+1 | squeeze-backports | amd64 libgl1-mesa-glx | 8.0.5-4 | wheezy| amd64 libgl1-mesa-glx | 8.0.5-4 | sid | amd64 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:52 PM, Andreas Beckmann wrote: Control: severity -1 wishlist Control: retitle -1 does not divert libGL.so.1.2.0 from mesa 9.0.1-1 On 2013-04-07 18:26, Christian Weeks wrote: Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 This is not the Debian libgl1-mesa-glx. That would contain /usr/lib/x86_64-linux-gnu/libGL.so.1.2 which is properly diverted. On 2013-04-07 18:30, Christian Weeks wrote: Versions of packages glx-diversions is related to: ii libgl1-mesa-glx [libgl1] 9.0.1-1 Exactly :-) $ rmadison --arch amd64 libgl1-mesa-glx libgl1-mesa-glx | 7.7.1-5 | squeeze | amd64 libgl1-mesa-glx | 7.10.3-4~bpo60+1 | squeeze-backports | amd64 libgl1-mesa-glx | 8.0.5-4 | wheezy| amd64 libgl1-mesa-glx | 8.0.5-4 | sid | amd64 Andreas OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 2013-04-07 18:58, Christian Weeks wrote: OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. and having a bad version number that looks like an official Debian package I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. probably an intentional library rename done by upstream you'll have to divert libGL.so.1.2.0 to move it away from /usr/lib/triplet, otherwise ldconfig (which is run from many maintainer scripts - so nearly every packaging operation breaks the setup) will always recreate (and overwrite) the libGL.so.1 link Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 01:11 PM, Andreas Beckmann wrote: On 2013-04-07 18:58, Christian Weeks wrote: OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. and having a bad version number that looks like an official Debian package Sorry about that. It's because I try and pbuild exactly what's in the git. (Not subversion like I said before- this is all from the pkg-xorg sub projects- wayland and mesa and, with the recent updates, now libdrm too *sigh*). I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. probably an intentional library rename done by upstream you'll have to divert libGL.so.1.2.0 to move it away from /usr/lib/triplet, otherwise ldconfig (which is run from many maintainer scripts - so nearly every packaging operation breaks the setup) will always recreate (and overwrite) the libGL.so.1 link Ah, yes, OK, that's the guilty party here then I guess. I'll see what I can come up with and share it here. No doubt others are or will soon be in the same boat. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
Control: tag -1 pending
On 2013-04-07 19:43, Christian Weeks wrote:
and having a bad version number that looks like an official Debian
package
Sorry about that. It's because I try and pbuild exactly what's in the
git.
I usually use a Debian revision like -0anbe0 or -0~anbe0 or ... for my
local packages that could clash with official ones ...
you'll have to divert libGL.so.1.2.0 to move it away from
Ah, yes, OK, that's the guilty party here then I guess. I'll see what I
can come up with and share it here. No doubt others are or will soon be
in the same boat.
I just added a completely untested commit to the glx-alternatives SVN
repository that should add support for diverting libGL.so.1.2.0 like we
already divert libGL.so{,.1,.1.2}. Please test it.
But I don't plan to upload the package now for this change only (unless
MESA 9 gets uploaded to experimental).
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
