Bug#704914: glx-alternatives: The libGL diversion does not work

2013-04-07 Thread Christian Weeks
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

2013-04-07 Thread Andreas Beckmann
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

2013-04-07 Thread Christian Weeks

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

2013-04-07 Thread Andreas Beckmann
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

2013-04-07 Thread Christian Weeks

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

2013-04-07 Thread Andreas Beckmann
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

2013-04-07 Thread Christian Weeks

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

2013-04-07 Thread Andreas Beckmann
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