Bug 341323

Summary:	[TRACKER] apps calling libXext.so incorrectly for XRANDR detection
Product:	Gentoo Linux	Reporter:	DEMAINE Benoît-Pierre, aka DoubleHP <dhp_gentoo>
Component:	[OLD] Unspecified	Assignee:	Gentoo X packagers <x11>
Status:	RESOLVED OBSOLETE
Severity:	normal	Keywords:	Tracker
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:	340445
Bug Blocks:

Description DEMAINE Benoît-Pierre, aka DoubleHP 2010-10-16 17:25:57 UTC

This bug is following
http://bugs.gentoo.org/show_bug.cgi?id=340445
and
https://bugs.freedesktop.org/show_bug.cgi?id=30806
(you need to read both bugs before reading this; i won't paste here all info they give)

At start time, many apps produce this ennoying, stupid, and useless message:
Xlib: extension "RANDR" missing on display ":0.0".

Thunderbird 3.1.3 , Firefox 3.6.9 , Pidgin 2.7.2 , gkrellm 2.3.2 ,
Xdialogs 2.3.1 , Rox-Memo (Python), Rox-Filer, gmpc, xrandr (obvious, but see
below), acroread, dvdrip (twice !!!), grip, gnumeric, pcb (Geda), gschem
(Geda), Dia, Opera, amule, pornview

for all the ones I use at least weekly, and could think on the top of my head.

The bug have been isolated, in how apps call libXext.so and perform detection of Xrandr support. The X team have fixed xrandr. All other apps should be fixed. Many of them are directly linked to libgtk but not all. In particular, not Opera, and not Xdialogs. Some may load GTK "manually" so that gtk won't be found by ldd.

Dispite what I have been said several times in http://bugs.gentoo.org/ ... i don't think I should create one bug per application. But one bug for all of them is not either a suffisant approach: too much source to edit, and too many upstreams to contact for a single bug. At least, this bug could be used to set up the list of applications that trigger the issue. We could start by listing all applications which have an ebuild depending (directly, or not) on libXext (owned by x11-libs/libXext ATM).

Alan Coopersmith identified that in GTK, the issue is in
http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkscreen-x11.c#n1052

I don't think I will be brave enough to track for so many broken app all by myself, and poke upstreams one by one. There may be hundresds of them. And they need to be fixed. Missdetection of xrandr means possible breakage when Xrandr layer will be updated in a few years (and it *WILL* be, when they will merge support for both Xrandr and Xinerama in the same cession).

Comment 1 SpanKY gentoo-dev

2010-10-17 04:19:50 UTC

someone is going to have to file a bug for each broken package.  but the core code needs fixing first.

Comment 2 DEMAINE Benoît-Pierre, aka DoubleHP 2010-10-17 10:22:26 UTC

(In reply to comment #1)
> someone is going to have to file a bug for each broken package.  but the core
> code needs fixing first.
> 

Read http://bugs.gentoo.org/show_bug.cgi?id=340445 as I asked: there is no core code that needs to be fixed upstream.

Comment 3 Michael Weber (RETIRED) gentoo-dev

2010-10-26 15:54:09 UTC

asigning to x11 which is maint of x11-libs/libXext which is package of libXext.so

Comment 4 Matt Turner gentoo-dev

2015-02-22 21:50:54 UTC

Tracker with one bug... I guess there was nothing to do?