Bug#1020715:

[James Addison]

A correction for a mistake in my previous message:

> Because Debian builds packages from a fixed build path, neither the 
> 'reprotest'
> utility in Salsa-CI, nor the Reproducible Builds team's package test
> infrastructure for Debian[1] currently check for equivalent binary package
> output from differing source package build paths.
>
> This means that your package will pass current reproducibility tests; ...
> [ snip ]

Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise
variations of the build-path, and will fail if it builds binary packages that
contain different contents as a result.

Bug#1020715:

[James Addison]

Control: severity -1 wishlist

Dear Maintainer,

Because Debian builds packages from a fixed build path, neither the 'reprotest'
utility in Salsa-CI, nor the Reproducible Builds team's package test
infrastructure for Debian[1] currently check for equivalent binary package
output from differing source package build paths.

This means that your package will pass current reproducibility tests; however
we believe that source code and/or build steps still embed the build path into
the binary package output, making it more difficult than necessary for
independent consumers to check the integrity of those packages by rebuilding
them themselves.

As a result, this bugreport will remain open and be re-assigned the 'wishlist'
severity[2].

For more information about build paths and how they can affect reproducibility,
please refer to: https://reproducible-builds.org/docs/build-path/

Thanks,
James

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities

Bug#1065666: Compiz 0.8.18 appears to be broken in testing

[James Bielefeldt]

Hi
This address is listed as a maintainer on the Compiz package search page.
0.8.18 black screens on boot after a recent update when building a iso with
livebuild. I have been building the xfce-Compiz iso for about 4 months
without issue. The xfce (testing amd64) iso is built without errors, but it
is unusable with the black screen. Rebuilding the source package does not
fix it. I cant seem to get any more info with the black screen,
ctrl+alt+F(any number) stays a black screen and booting into safe mode also
results in a black screen. Xfce images without compiz build and work fine.

Thanks
Jim

Bug#1065666: Compiz 0.8.18 appears to be broken in testing

[James Bielefeldt]

Not sure if this helps, but I keep package lists of each build. Here is 
a diff of 2/24 build (works) vs 3/24 (broken). 
https://spins.tuxfamily.org/package-list-diff.txt I dont know if any 
changes would break compiz, but at least its more info.


Jim

On 3/6/24 11:25, Steve Langasek wrote:

On Wed, Mar 06, 2024 at 06:19:48PM +0100, Colomban Wendling wrote:

Le 06/03/2024 à 17:31, Steve Langasek a écrit :

On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote:

Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they
have extra clues.

The only change in the NMU was to rename the libdecoration0 package to
libdecoration0t64 for the 64-bit time_t transition.  Unless this managed to
break the *contents* of that package (i.e. the library has gone missing),
this should not have had any effect on the behavior of compiz.

So the package has not been rebuilt with different flags or anything?

Not *deliberately* as part of this upload.  The only change to flags should
be on 32-bit architectures, excluding i386.  I have assumed you are not
trying to run compiz on one of these archs!

But the toolchain also evolves over time, so this could certainly be a
misbuild due to underlying changes.


Anyway, I hardly expect this to be an issue, I just wanted to eliminate the
only Compiz-side change that happened in the last months.

Bug#1059145: libpixman-1-0: arm64 segfault while using proxmox console mode

[James Berry]

Package: libpixman-1-0
Version: 0.42.2-1
Severity: important
X-Debbugs-Cc: ja...@coppermoth.com

Dear Maintainer,

While using proxmox 8 (arm64 port) and viewing the console of a kvm session in 
novnc the kvm
process regularly terminates.  Using gdb and installing symbols I have traced 
this to
libpixman-1-0

Thread 15 "SPICE Worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfffab37ea3e0 (LWP 238200)]
0xf7ef913c in pixman_composite_src___asm_neon ()
at ../../pixman/pixman-arma64-neon-asm.S:1331
Downloading source file 
/build/pixman-phIJcH/pixman-0.42.2/build/pixman/../../pixman/pixman-arma64-neon-asm.S
1331../../pixman/pixman-arma64-neon-asm.S: Directory not empty.  


I am making the assumption that libpixman should not cause the segfault and the 
bug should be
reported here; if I should raise against kvm please advise

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-16-arm64 (SMP w/80 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpixman-1-0 depends on:
ii  libc6  2.36-9+deb12u3

libpixman-1-0 recommends no packages.

libpixman-1-0 suggests no packages.

-- no debconf information

Bug#1016530:

[Sam James]

It looks like this might be 
https://gitlab.freedesktop.org/mesa/demos/-/issues/27 / 
https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/84.


signature.asc
Description: Message signed with OpenPGP

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

I reported this bug a long time ago. I had been hoping that by now some 
update to Debian would contain a fixed Nouveau that would work as 
expected with this old hardware. I'm still hoping ...


I have also been playing around with this myself -- I don't know enough 
about video hardware (or anything about the Nouveau driver) to try to 
meddle with the source, but I've changed configuration options in a 
number of ways to see what would happen.


The first thing I should say is that I think the error lines in 
Xorg.0.log are misleading. I had tried to disable acceleration in 
Nouveau because it had caused problems in Stretch and earlier. The error 
message lines:


[45.875] (EE) NOUVEAU(0): Error creating GPU channel: -19
[45.875] (EE) NOUVEAU(0): Error initialising acceleration.  Falling
back to NoAccel
[45.875] (**) NOUVEAU(0): [COPY] acceleration disabled

seemed to me to be showing that the system was trying to use 
acceleration. I have tried disabling acceleration by providing a kernel 
parameter (either "noaccel" or "nouveau-noaccel=1") which I think worked 
in Stretch, but this does NOT seem to disable acceleration in Buster, 
which why I was getting the errors above. Those errors appear to have 
masked the actual error, making it harder to diagnose the problem.


If I create a fairly minimal xorg.cong file containing just:

Section "Device"
Identifier "GeForce_6150"
Driver "nouveau"
VendorName "NVIDIA Corporation"
Option  "NoAccel"
Option  "AccelMethod" "None"
EndSection

Section "Monitor"
Identifier "Default monitor"
VendorName "DELL"
ModelName "U2410"
EndSection

Section "Screen"
Identifier "Screen0"
Device "GeForce_6150"
Monitor "Default monitor"
EndSection

then acceleration DOES seem to be disabled and I no longer get the 
errors in Xorg.0.log.


In this state Buster boots to the login/greeting screen in the monitor's 
default resolution of 1920x1200 and I can enter a username and password. 
These are validated correctly and the screen blanks for a few moments 
and returns to the login/greeter.


If I open a commandline console with ALT+F1 I can log in. If I then try 
to start an X session with startx I get the following.


(Sorry, this is retyped by hand on another machine and may not be 100% 
correct (and lines may have wrapped). Many of the original lines were 
terminated with LF but not CR at the end and so the following lines 
appeared indented.



X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian
Current Operating System: Linux welly-buster 4.19.0-16-amd64 #1 SMP 
Debian 4.19.191-1 (2021-03-19) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-16-amd64 
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic

Build Date: 01 December 2020  05:59:57PM
xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support)
Current version of pixman: 0.36.0
Before reporting problems, check http://wiki.x.org
to make sure you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warnoing, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/daniel/.local/share/xorg/Xorg.1.log", Time: Sat 
Mar 27 23:32:08 2021

(==) Using config file: "/etc/X11/xorg.conf"
(==) Uing system config directory "/usr/share/X11/xorg.conf.d"
resize called 1920 1200
usr/lib/xorg/Xorg: symbol lookup error: 
/usr/lib/xorg/modules/drivers/nouveau_drv.so: undefined symbol: 
exaGetPixmapDriverPrivate

xinit: connection to X server lost

It now seems to me that the main problem is this undefined symbol error, 
which is causing the xorg to fail to load.


I hope this is useful. Is there any more information I can provide to 
help get this matter resolved?


--
Regards,
  Daniel James

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

On Thu, 31 Oct 2019 15:46:30 + Daniel James 
 wrote:
I normally try to stay clear of testing and unstable, but I'll try those 
when I get a chance ...


Sorry it's taken a while.

With Testing (Kernel 5.2.0, Nouveau 1.0.16) the system boots to a 
full-screen graphical login. I can enter my username and password, and 
the screen then switches to a garbled version of the desktop (a bit like 
an old CRT television whose horizontal hold is incorrectly set, but 
static not moving).


On this system, "dmesg | grep -E '(drm|nouveau)'" (as root) gives:

[2.743125] nouveau :00:05.0: NVIDIA C51 (04e000a2)
[2.752186] nouveau :00:05.0: bios: version 05.51.22.33.07
[2.753091] nouveau :00:05.0: fb: 128 MiB of unknown memory type
[4.052950] nouveau :00:05.0: DRM: VRAM: 125 MiB
[4.052985] nouveau :00:05.0: DRM: GART: 512 MiB
[4.053022] nouveau :00:05.0: DRM: TMDS table version 1.1
[4.053058] nouveau :00:05.0: DRM: DCB version 3.0
[4.053094] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023
[4.053131] nouveau :00:05.0: DRM: DCB outp 01: 03011312 
[4.053168] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[4.053205] nouveau :00:05.0: DRM: DCB conn 00: 
[4.053240] nouveau :00:05.0: DRM: DCB conn 01: 0131
[4.053275] nouveau :00:05.0: DRM: DCB conn 02: 0210
[4.053311] nouveau :00:05.0: DRM: DCB conn 03: 0211
[4.053346] nouveau :00:05.0: DRM: DCB conn 04: 0213
[4.054701] nouveau :00:05.0: DRM: MM: using M2MF for buffer copies
[4.055157] nouveau :00:05.0: DRM: Saving VGA fonts
[4.093998] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.094037] [drm] Driver supports precise vblank timestamp query.
[4.095028] nouveau :00:05.0: DRM: Setting dpms mode 3 on TV 
encoder (output 2)
[4.176611] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 
0x9000, bo (ptrval)

[4.218180] fbcon: nouveaudrmfb (fb0) is primary device
[4.329239] nouveau :00:05.0: fb0: nouveaudrmfb frame buffer device
[4.345656] [drm] Initialized nouveau 1.3.1 20120801 for :00:05.0 
on minor 0


Interestingly, when I switch between "terminals" (is that the right 
word?) with Ctrl+Alt+F1 and back with Ctrl+Alt+F7 I see a perfect 
desktop display briefly before changing away to the text terminial, and 
again when I switch back but this then changes to the garbled display 
again. Every time I switch away from the graphics terminal to a text one 
and back this happens, for slightly varying time periods but never more 
than about half a second.


There are no obvious relevant errors in /var/log/Xorg.0.log (and it's 
quite long) -- should I post it here?


I've yet to try unstable ... I haven't any more spare hard drives so I'd 
have to overwrite the testing system and I don't want to do that if 
there's a chance that it may tell us something.


--

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

On Thu, 31 Oct 2019 10:31:48 +0100 Sven Joachim  wrote:


With nomodeset X will fallback to the fbev or vesa drivers.  The latter
has very limited support for modern wide screens, the former does not
let you change the resolution at all.


Yes, I assumed vesa.

inxi -G says:

Graphics:
  Device-1: NVIDIA C51PV [GeForce 6150] driver: N/A
  Display: x11 server: X.Org 1.20.4 driver: nouveau,vesa
  unloaded: fbdev,modesetting resolution: 1280x1024~N/A
  OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6

I can change to lower resolutions, and back, just not to higher ones.


> The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset
> and GeForce 61500 onboard graphics. The monitor is a Dell U2410 which
> has a native resolution of 1920x1200 pixels.

There have been many problems with these onboard graphics, quite a large
fraction of the nouveau bug reports in Debian are from system with it.


Agreed ... but note that this hardware had no difficulties with graphics 
in Debian Stretch or Jessie. The failure is new with Buster.



> On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and
> the full screen resolution was used.
>
> This bug report is being prepared from a text console after booting
> WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial.

I think you are right here.

> [45.875] (EE) NOUVEAU(0): Error creating GPU channel: -19
> [45.875] (EE) NOUVEAU(0): Error initialising acceleration.
> Falling back to NoAccel
> [45.875] (**) NOUVEAU(0): [COPY] acceleration disabled

That's not good.  Can you please send some kernel logs?  Run
"sudo dmesg| grep -E '(drm|nouveau)" to retrieve them.


Without nomodeset I get:

[2.722181] nouveau :00:05.0: NVIDIA C51 (04e000a2)
[2.731283] nouveau :00:05.0: bios: version 05.51.22.33.07
[2.732373] nouveau :00:05.0: fb: 128 MiB of unknown memory type
[4.033290] nouveau :00:05.0: DRM: VRAM: 125 MiB
[4.033325] nouveau :00:05.0: DRM: GART: 512 MiB
[4.033363] nouveau :00:05.0: DRM: TMDS table version 1.1
[4.033399] nouveau :00:05.0: DRM: DCB version 3.0
[4.033435] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023
[4.036555] nouveau :00:05.0: DRM: DCB outp 01: 03011312 
[4.036592] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[4.036629] nouveau :00:05.0: DRM: DCB conn 00: 
[4.036664] nouveau :00:05.0: DRM: DCB conn 01: 0131
[4.036699] nouveau :00:05.0: DRM: DCB conn 02: 0210
[4.036735] nouveau :00:05.0: DRM: DCB conn 03: 0211
[4.036770] nouveau :00:05.0: DRM: DCB conn 04: 0213
[4.037233] nouveau :00:05.0: DRM: Saving VGA fonts
[4.075567] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.075607] [drm] Driver supports precise vblank timestamp query.
[4.076570] nouveau :00:05.0: DRM: Setting dpms mode 3 on TV 
encoder (output 2)
[4.174450] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 
0x8000, bo (ptrval)

[4.217697] fbcon: nouveaufb (fb0) is primary device
[4.357759] nouveau :00:05.0: fb0: nouveaufb frame buffer device
[4.376957] [drm] Initialized nouveau 1.3.1 20120801 for :00:05.0 
on minor 0


(Sorry, Thunderbird has made some lines wrap)

With nomodeset no lines match.


You may want to try different kernels (4.9 from stretch, 5.2 from
testing and/or 5.3 from unstable) and see if they give better results.


As I said: Stretch works fine as it is. That is: The Stretch kernel 
works in Stretch using nouveau 1.0.13 with a 4.9 kernel. I haven't tried 
the Stretch kernel in Buster ...


(Snippet from /var/log/Xorg.0.log under Stretch)
[16.673] (II) Module nouveau: vendor="X.Org Foundation"
[16.673]compiled for 1.19.3, module version = 1.0.13
[16.673]Module class: X.Org Video Driver
[16.673]ABI class: X.Org Video Driver, version 23.0

(Snippet from /var/log/Xorg.0.log under Buster)
[39.974] (II) Module nouveau: vendor="X.Org Foundation"
[39.974]compiled for 1.20.3, module version = 1.0.16
[39.974]Module class: X.Org Video Driver
[39.974]ABI class: X.Org Video Driver, version 24.0

Looks like the video driver ABI version has changed as well as the 
version of nouveau ... I guess it wouldn't be simple to mix and match.


I normally try to stay clear of testing and unstable, but I'll try those 
when I get a chance ...


--
Regards,
  Daniel James

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important
File: nouveau

Dear Maintainer,

[Message prepared by reportbug 7.5.3-de10u1 but mailed from Thunderbird 
on a different system]


In Debian 10 "Buster" the Nouveau driver does not start correctly unless 
the "nomodeset" kernel parameter is supplied.


Without "nomodeset" the system boots to a full-screen graphical login 
screen. Login credentials can be entered, but the screen then flashes 
off (black) for a fraction of a second and returns to the login dialog.


With "nomodeset" Debian starts but the screen resolution is not optimal, 
and cannot be changed. The system boots to a graphical login screen with 
the edges black -- apparently a 1280x1024 displayed full-height but 
narrower than the screen. When login credentials are entered the system 
boots but still only shows a 1280x1024 desktop. Attempts to change the 
resolution (e.g. using xrandr to add a new mode and switch to it fail).


The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset and 
GeForce 61500 onboard graphics. The monitor is a Dell U2410 which has a 
native resolution of 1920x1200 pixels.


On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and 
the full screen resolution was used.


This bug report is being prepared from a text console after booting 
WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I 
have compared /var/log/Xorg.0.log files from this system when booting 
Buster and when booting Stretch, and (apart from minor details like 
module version numbers and the time field) the logs are identical up to 
this point.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV 
[GeForce 6150] [10de:0240] (rev a2)


/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)


Xorg X server log files on system:
--
-rw-r--r-- 1 daniel daniel 33547 Oct 13 15:34 
/home/daniel/.local/share/xorg/Xorg.0.log

-rw-r--r-- 1 root   root   26008 Oct 29 16:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[45.542]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[45.542] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[45.542] Current Operating System: Linux welly-buster 4.19.0-6-amd64 
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
[45.542] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic

[45.542] Build Date: 05 March 2019  08:11:12PM
[45.542] xorg-server 2:1.20.4-1 (https://www.debian.org/support)
[45.542] Current version of pixman: 0.36.0
[45.542]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[45.542] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[45.543] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 29 
16:57:10 2019

[45.543] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[45.543] (==) No Layout section.  Using the first Screen section.
[45.543] (==) No screen section available. Using defaults.
[45.543] (**) |-->Screen "Default Screen Section" (0)
[45.543] (**) |   |-->Monitor ""
[45.544] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[45.544] (==) Automatically adding devices
[45.544] (==) Automatically enabling devices
[45.544] (==) Automatically adding GPU devices
[45.544] (==) Max clients allowed: 256, resource mask: 0x1f
[45.545] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[45.545]Entry deleted from font path.
[45.545] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[45.545] (==) ModulePath set to "/usr/lib/xorg/modules"
[45.545] (II) The server relies on udev to provide the list of input 
devices.

If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[45.545] (II) Loader magic: 0x562deaa57e20
[45.545] (II) Module ABI 

Re: Bug#912827: mpv 0.29.1 cannot display video on Weston 5.0.0

[James Cowgill]

Control: reassign -1 weston
Control: severity -1 normal
Control: retitle -1 weston: add support for stable xdg-shell
Control: affects -1 mpv
Control: tags -1 upstream

Hi,

On 04/11/2018 07:04, Kelly Clowers wrote:
> Package: mpv
> Version: 0.28.2-3
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> Updated MPV to 0.29.1 from 0.28.2
> 
> * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Tried to play a video file I have played many times before
> 
> * What was the outcome of this action?
> 
> MPV failed to play the file with the following error message:
> 
> krc@ken:~/NFS/public/video/documentaries/David_Attenborough$ mpv
> 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv
> Playing: 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv
> Unable to revert mtime: /usr/local/share/fonts
>  (+) Video --vid=1 (*) (h264 1920x1080 25.000fps)
>  (+) Audio --aid=1 --alang=eng (*) (dts 6ch 48000Hz)
>  Subs  --sid=1 --slang=eng (*) (hdmv_pgs_subtitle)
> [vo/gpu/wayland] Compositor doesn't support the required xdg_wm_base protocol!
> [vo/gpu] Failed initializing any suitable GPU context!
> Error opening/initializing the selected video_out (--vo) device.
> Video: no video

As of this commit (first in 0.29.0), mpv dropped support for xdg-shell
v6 and now only supports the stable version of xdg-shell:
https://github.com/mpv-player/mpv/commit/76211609e3c589dafe3ef9a36cacc06e8f56de09

Unfortunately Weston doesn't support stable xdg-shell yet. I have a
feeling that currently mutter is the only compositor which does
(although I may be wrong).

There is an upstream mpv bug about this which hasn't seen any activity.
I'll poke it and see what upstream has to say, but I doubt they're going
to reintroduce xdg-shell v6 support.
https://github.com/mpv-player/mpv/issues/6110

James



signature.asc
Description: OpenPGP digital signature

Re: Bug#903373: kitty: image rendering seems to be broken

[James McCoy]

Control: reassign -1 libxkbcommon-x11-0 0.8.0-2
Control: retitle -1 "not a valid UTF-8 string" errors creating compose table in 
en_IN locale

On Mon, Jul 09, 2018 at 11:15:49AM +0530, Ritesh Raj Sarraf wrote:
> Thank you for packaging the newer version of kitty.
> 
> With this version, the `icat` and `diff` commands fail with the
> following error:

This also happens simply when starting kitty, but those go into your
session error log.

> rrs@priyasi:~$ kitty diff rrs-home/Data/Pictures/debian-transparent.png 
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:87:34: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:88:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:89:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:90:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:91:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:92:27: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:93:27: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:94:27: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:95:27: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:96:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: string 
> literal is not a valid UTF-8 string
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: too many 
> errors
> xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: failed to 
> parse file
> [190 11:11:39.666312] [glfw error 65544]: Failed to create XKB compose table
> 
> 
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
> (charmap=UTF-8)

That error is directly from xkbcommon's code[0].  If you instead use
LANG=en_IN.UTF-8, then there are no issues.  It appears that xkbcommon
is falling back incorrectly when there isn't an explicit codeset.

[0]: 
https://sources.debian.org/src/libxkbcommon/0.8.0-2/src/compose/parser.c/?hl=207#L207

That being said, just "en_IN" is what "dpkg-reconfigure locales"
generates when selecting that locale.  Both reportbug and "locale -c
charmap" are able to figure out that the codeset is UTF-8.

kitty is using essentially the exact code[1] that xkbcommon's
documentation suggests to use when calling
xkb_compose_table_new_from_locale().

I'm reassigning to xkbcommon to see if there's something they can do to
better handle this.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#884599: libinput10: jittery synaptics touchpad in wayland session

[James Cowgill]

Hi,

On 19/12/17 09:50, Tomas Janousek wrote:
> Hi James,
> 
> On Sun, Dec 17, 2017 at 03:00:46PM +0000, James Cowgill wrote:
>> [...]
>> Yes I can confirm that reverting fix-lp1696929.patch from 1.9.4-1 fixes
>> my touchpad issues.
> 
> If you can spare a few minutes, can you please take a look at the recent
> discussion at https://bugs.freedesktop.org/show_bug.cgi?id=98839 ?
>
> Notably:
> 
> - I had a similar problem on my wife's T440p which I fixed by upgrading the
>   touchpad firmware (which wasn't easy as I had to boot into Windows and
>   download a firmware update package for an entirely different laptop model),
>   and now it behaves *much* better with the patch.

I don't think there is any new tochpad firmware for my laptop. It's
quite a few years old and it doesn't seem Dell has released any updates
for about 4 years now. I also don't own a copy of Windows anymore so
doing the upgrade may be slightly complicated :)

> - Peter would like to investigate and fix the patch so it works for people
>   like you, can you please provide him with the details he needs?

I've replied to the upstream bug with some evemu recordings.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#884599: libinput10: jittery synaptics touchpad in wayland session

[James Cowgill]

Hi,

On 17/12/17 13:40, Andreas Boll wrote:
> On Sun, Dec 17, 2017 at 01:09:16PM +0000, James Cowgill wrote:
>> Package: libinput10
>> Version: 1.9.4-1
>> Severity: normal
>>
>> Hi,
>>
>> Since upgrading to libinput 1.9.4-1, I have noticed my synaptics
>> touchpad on my laptop has become very jittery. Placing my finger on the
>> touchpad without moving it causes the mouse to move around very
>> slightly. This is a massive PITA when trying to click precisely somewhere.
>>
>> Downgrading to 1.9.3-1 fixes this.
>>
>> The laptop is an old Dell XPS 15 L502X, but I'm not sure how to get any
>> extra information about my touchpad (if that would be useful).
>>
>> Thanks,
>> James
> 
> Could be related to the new patch fix-lp1696929.patch we ship since
> 1.9.4-1. Can you rebuild and test libinput 1.9.4-1 without that patch?

Yes I can confirm that reverting fix-lp1696929.patch from 1.9.4-1 fixes
my touchpad issues.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#884599: libinput10: jittery synaptics touchpad in wayland session

[James Cowgill]

Package: libinput10
Version: 1.9.4-1
Severity: normal

Hi,

Since upgrading to libinput 1.9.4-1, I have noticed my synaptics
touchpad on my laptop has become very jittery. Placing my finger on the
touchpad without moving it causes the mouse to move around very
slightly. This is a massive PITA when trying to click precisely somewhere.

Downgrading to 1.9.3-1 fixes this.

The laptop is an old Dell XPS 15 L502X, but I'm not sure how to get any
extra information about my touchpad (if that would be useful).

Thanks,
James

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libinput10 depends on:
ii  libc6 2.26-0experimental1
ii  libevdev2 1.5.7+dfsg-1
ii  libinput-bin  1.9.4-1
ii  libmtdev1 1.1.5-1+b1
ii  libudev1  235-3
ii  libwacom2 0.26-1

libinput10 recommends no packages.

libinput10 suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#881789: libglvnd: missing libGLX_indirect.so, breaks GLX with remote X server

[James Braid]

Package: libglx0
Version: 1.0.0-1
Severity: important

Dear Maintainer,

I'm running testing on a headless system, and a recent change to use
libglxvnd has stopped GLX from working when displayed to a remote
machine. This was working fine before the migration to use glvnd for
libGL/libGLX.

e.g. running glxinfo fails with the following error:

$ glxinfo
name of display: localhost:11.0
Error: couldn't find RGB GLX visual or fbconfig

strace'ing glxinfo shows it trying to load libGLX_indirect.so.0 and
failing:

$ strace -etrace=open glxinfo

open("/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)

Adding a symlink from libGLX_mesa.so.0 to libGLX_indrect.so.0 makes
things work:

$ sudo ln -s /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 
/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
$ glxinfo | head
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
name of display: localhost:11.0
display: localhost:11  screen: 0
direct rendering: No (If you want to find out why, try setting 
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample,
GLX_SGIX_fbconfig

Looking at the source for glvnd and reading some NVIDIA documentation,
it seems like glvnd is trying to fallback to a generic libGLX_indirect
library if vendor-specific library doesn't exist or GLX_EXT_glvnd is not
present on the remote X server (this is my situation).

However, I can't find libGLX_indirect.so.0 provided by any Debian
packages. It seems like either libglvnd or mesa should provide a symlink
from libGLX_indirect.so.0 to a default GL implementation for these
situations.

I'd provide a patch but I'm not sure what package should be taking care
of this 



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libglx0:amd64 depends on:
ii  libc6 2.24-17
ii  libglvnd0 1.0.0-1
ii  libglx-mesa0 [libglx-vendor]  17.2.4-1+b1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2

libglx0:amd64 recommends no packages.

libglx0:amd64 suggests no packages.

-- no debconf information

Bug#875446: libglvnd-dev: overwrites files in old libegl1-mesa-dev

[James Cowgill]

Package: libglvnd-dev
Version: 0.2.999+git20170802-3
Severity: serious

Hi,

On upgrading today I got this error:
> Unpacking libglvnd-dev (0.2.999+git20170802-3) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-Go1Tzy/19-libglvnd-dev_0.2.999+git20170802-3_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libEGL.so', which is also in 
> package libegl1-mesa-dev:amd64 17.1.5-1

I am guessing that libglvnd-dev needs to Breaks/Replaces the old mesa
dev packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[James McCoy]

On Fri, Apr 07, 2017 at 07:23:39AM -0400, G. Branden Robinson wrote:
> At 2017-04-06T21:56:13-0400, James McCoy wrote:
> > On Fri, Apr 07, 2017 at 12:54:19AM +0200, Francesco Poli wrote:
> > > On Thu, 6 Apr 2017 15:06:17 -0400 G. Branden Robinson wrote:
> > > 
> > > > At 2017-04-06T13:33:58-0400, James McCoy wrote:
> > > > > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote:
> > > > > > The below is not a sufficient reproduction receipe for me.
> > > > > > 
> > > > > > I'm running Debian Stretch (testing).
> > > > > > 
> > > > > > Things do not go wrong at step #5, nor afterward.
> > > > > 
> > > > > Make sure the terminal is sized small enough (80x24).  That causes the
> > > > > syntax highlighting in Vim to get a little confused and enable some 
> > > > > bold
> > > > > highlighting, which then causes the visual bell to turn everything 
> > > > > bold.
> > > > 
> > > > It was.
> > > 
> > > Hello Branden!
> > > Thanks for trying to reproduce the bug.
> > > 
> > > Does it help to know that I have:
> > > 
> > >   xset b off
> > > 
> > > in my ~/.xsession script?
> > 
> > I don't think that's relevant.  My bell is on.  I was also able to
> > reproduce it without causing the bell.
> > 
> > I've attached an asciinema recording of me reproducing the problem.
> > When I replay the recording, it causes the same problem to the xterm in
> > which it is running, so hopefully this helps debug the problem.
> 
> That's really interesing.  I _still_ can't repro this, even playing back
> James's demo with asciinema--a tool of which I wasn't aware, thanks!
> 
> I'm launching xterm in GNOME with the GNOME command runner, whatever
> that's called--the Alt+F2 thing.
> 
> However, my xterms are somewhat customized.  I'm attaching my
> .Xresources file.

Perfect! That seems to be the difference.  I, and presumably Francesco, aren't
using TTF fonts.  If I change your Xresources to use

XTerm.*.VT100.Font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1

instead of the FaceName/FaceSize resources, then playing the recording
reproduces the problem.

Cheers,
James

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[James McCoy]

On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote:
> The below is not a sufficient reproduction receipe for me.
> 
> I'm running Debian Stretch (testing).
> 
> Things do not go wrong at step #5, nor afterward.

Make sure the terminal is sized small enough (80x24).  That causes the
syntax highlighting in Vim to get a little confused and enable some bold
highlighting, which then causes the visual bell to turn everything bold.

> At 2017-04-05T22:03:50-0400, James McCoy wrote:
> > On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote:
> > > I finally found a reliable way to reproduce it.
> > > 
> > > Steps to reproduce:
> > > 
> > >   0) open the attached test.md file:
> > > 
> > >  $ vim -u NONE test.md
> > > 
> > >   1) enable syntax highlighting:
> > > 
> > >  :set bg=dark
> > >  :syn on
> > > 
> > >   2) go to the end of the file:
> > > 
> > >  [Shift+G]
> > > 
> > >   3) go back to the beginning of the file (line by line):
> > > 
> > >  [k].[k] ← hold the key pressed until you reach the first line
> > > 
> > >   4) visualize file info on the status line:
> > > 
> > >  [Ctrl+G]
> > > 
> > >   5) the syntax highlighting has gone crazy (even the status line is
> > >  in boldface!): see the attached screenshot
> > >  wrong_vim_syntaxmarkdown.png
> > > 
> > >   6) exit from vim:
> > > 
> > >  :q
> > > 
> > >   7) the terminal (xterm), or rather the shell (bash), has also gone
> > >  crazy (it now prints everything in boldface by default): see
> > >  the attached screenshot
> > >  wrong_vim_syntaxmarkdown2.png
> > > 
> > >   8) the terminal won't come back to normal behavior until I quit it;
> > >  another trick to regain the normal behavior of the terminal is
> > >  opening test.md again, enable syntax highlighting, and exit vim
> > >  (steps 0, 1, and 6 above)
> 
> Regards,
> Branden



-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[James McCoy]

Control: tag -1 confirmed
Control: reassign -1 xterm
Control: retitle -1 Terminal stays bold after visual bell with bold text 
displayed

On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote:
> I have experienced this bug for a fairly long time, when editing
> markdown documents with vim. It has been triggered in a seemingly
> random manner.

It's the visual bell that happens when you get to the top of the buffer
and try to keep going.  That causes Vim to send the BEL (Ctrl-G) to the
terminal.  The way the buffer is currently highlighted (some bold text)
at that point is causing xterm to get stuck.

You can reset it by Ctrl-RightClick -> "Escape Sequence".

It works fine in at least pangoterm, but I haven't tried other more
mainstream terminals.

I'm reassigning to xterm for now.  Rest of the context is below.

> I finally found a reliable way to reproduce it.
> 
> Steps to reproduce:
> 
>   0) open the attached test.md file:
> 
>  $ vim -u NONE test.md
> 
>   1) enable syntax highlighting:
> 
>  :set bg=dark
>  :syn on
> 
>   2) go to the end of the file:
> 
>  [Shift+G]
> 
>   3) go back to the beginning of the file (line by line):
> 
>  [k].[k] ← hold the key pressed until you reach the first line
> 
>   4) visualize file info on the status line:
> 
>  [Ctrl+G]
> 
>   5) the syntax highlighting has gone crazy (even the status line is
>  in boldface!): see the attached screenshot
>  wrong_vim_syntaxmarkdown.png
> 
>   6) exit from vim:
> 
>  :q
> 
>   7) the terminal (xterm), or rather the shell (bash), has also gone
>  crazy (it now prints everything in boldface by default): see
>  the attached screenshot
>  wrong_vim_syntaxmarkdown2.png
> 
>   8) the terminal won't come back to normal behavior until I quit it;
>  another trick to regain the normal behavior of the terminal is
>  opening test.md again, enable syntax highlighting, and exit vim
>  (steps 0, 1, and 6 above)

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Bug#856156: vim-gtk: launching gvim as root from terminal crashes X server

[James McCoy]

Control: reassign -1 xserver-xorg-core 2:1.19.1-4
Control: affects -1 vim-gtk

Reassigning to xserver-xorg-core.  Vim's gtk2 code hasn't changed
significantly in some time, so it's more likely an issue with the glamor
driver.

On Sat, Feb 25, 2017 at 12:54:21PM -0500, Bruno Dantas wrote:
> Either command in a terminal consistently crashes the X server:
> # gvim foo.txt
> $ gksudo gvim foo.txt
> 
> I upgraded from Jessie to Stretch, which is when the problem started. The 
> error
> message in the text console that appears after the crash is this:
> "glamor_largepixmap.c:1448: glamor_composite_largepixmap_region: Assertion `0'
> failed. xinit: connection to X server lost"
> 
> Interestingly, starting gvim from within the file manager running as root (via
> context menu's "Open with") works fine. Also, these work fine:
> 
> # pluma foo.txt
> $ gksudo pluma foo.txt
> $ gvim foo.txt
> 
> It seems the problem is isolated to launching gvim as root from the command
> line. glamor_largepixmap.c is part of the xorg-server source package. If I
> should report the bug there instead/in addition to here, please let me know. I
> don't want to create noise.
> 
> These are my package versions:
> vim-gtk 2:8.0.0197-2
> xorg 1:7.7+18
> 
> If you need any further information, please let me know. gvim is my favorite
> editor and I'm in a terminal most of the time, so I'm highly motivated to 
> help.

-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

libx11: Issues with Data32/_XData32

[James Clarke]

Hi,
I've been debugging an issue in gtk2-perl causing it to SIGBUS on
sparc64, and traced it back to what seems to be dodgy code inside
libx11. One of the tests calls gdk_window_set_opacity, which calls
XChangeProperty with a pointer to a guint32, cast to char*, with the
length set to 32 bits as expected. However, this data pointer then gets
cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed,
the definition of Data32 specifies that data is a (long *) on sparc64,
since LONG64 is defined. This feels very wrong, but in and of itself is
not too bad (I believe it violates strict aliasing).

The problem really comes inside the implementation of _XData32. The
destination buffer, buf, is an (int *), but data is still a (long *).
These are not the same size. The issues with this are as follows:

 1. Incrementing data increases the pointer by 8, so it skips over every
other 4-byte int, and reads twice as many bytes as it should.

 2. On big-endian systems, (int)*(long *)an_int_pointer will end up
getting the 4 bytes *after* an_int_pointer, which means it gets
completely the wrong data even in the case of len being 4 (bytes).

 3. On sparc64, pointers have strict alignment requirements - they must
be size aligned (ie (int *) must be 4-byte aligned, (long *) must be
8-byte aligned). In this case, the data pointer (which came all the
way from gdk_window_set_opacity) is only 4-byte aligned (which is
fine, since it's a pointer to a guint32), but it has been cast to a
(long *) and dereferenced, so it is required to be 8-byte aligned.
This is the cause of the observed crash.

However, I wonder how 1. is not seen currently given the wide use
of X11 on amd64. I can only assume 2. not being seen is because the only
64-bit big-endian architectures are generally used for servers, and
there aren't many of them.

I don't know what the solution to the problem is. There are various
places in the call stack where this could be fixed up. The "correct" fix
seems to be to change Data32 to take an (int *) (or some other data type
of your choosing if you're worried about int's size not being portable)
and fix up the casts at all the call sites, but this is an intrusive
change to a public header, and I worry that there are things out there
relying on the current behaviour.

Alternatively, Data32 could be altered to still take a (long *), but
cast it back to an (int *). This has the advantage of not touching
public headers, but the prototype is then lying about what it's actually
doing, and this still has the problem of breaking behaviour.

The final, ugly alternative, is to alter XChangeProperty so it makes a
copy of data as an array of long, padding or sign-extending each
element, before passing it to Data32.

I can't claim to have spent much time looking through the code, so it's
highly likely I've missed something. Could those with more knowledge
please comment on the above?

Thanks,
James

Bug#847073: X doesn't start with new xserver-xorg-video-intel

[James Clarke]

Control: tags -1 fixed-upstream

> On 5 Dec 2016, at 12:49, Micha vor dem Berge 
> <micha.vordembe...@christmann.info> wrote:
>> Am 05.12.2016 um 12:27 schrieb James Clarke:
>> Package: xserver-xorg-video-intel
>> Version: 2:2.99.917+git20161105-1
>> Severity: important
>> Tags: patch upstream
>> Control: retitle -1 segfaults due to missing NULL check in 
>> has_connector_backlight
>> 
>>> On 5 Dec 2016, at 10:25, Micha vor dem Berge 
>>> <micha.vordembe...@christmann.info> wrote:
>>> 
>>> Hi all,
>>> 
>>> 
>>> I recently upgraded my xserver-xorg-video-intel package to the newest 
>>> jessie-backports (version 2:2.99.917+git20161105-1~bpo8+1). After a reboot, 
>>> X doesn't start anymore. I used this package from backports for several 
>>> months, so the newest update must have caused the trouble, I think.
>>> 
>>> After a downgrade to jessie stable (version 2:2.21.15-2+b2) X is starting 
>>> fine again, but I have no HW acceleration... :(
>>> 
>>> 
>>> Please find attached the Xorg.log.
>>> 
>>> Just for information: I'm using Linux Mint Debian Edition, so my desktop is 
>>> Cinnamon. And I compiled my own kernel (which was no problem in the past). 
>>> I also tried some of my older kernels of the 4.8.x kernel series - just to 
>>> be sure that the problem is not introduced by the newest kernel upgrade.
>>> 
>>> 
>>> Best regards,
>>> 
>>> Micha
>>> 
>>> 
>>> 
>>> PS: Please keep me in the loop when discussing this error as I didn't 
>>> subscribe to the backports mailing-list. Thanks!
>>> 
>> 
>> 
>> This looks like [1] was reached with dir being NULL, though since you don't
>> have debugging symbols (and I don't know/can't seem to work out what address
>> intel_drv.so was loaded at) I can't know for sure. Having said that, this is
>> the only place where the result of readdir is not checked for NULL, so I 
>> don't
>> know how else this would happen. This bug was introduced by [2]. Can you 
>> please
>> try the attached patch? Whether or not this is the problem, I'll forward it
>> upstream.
>> 
>> Regards,
>> James
>> 
>> [1] 
>> https://sources.debian.net/src/xserver-xorg-video-intel/2:2.99.917%2Bgit20161105-1%7Ebpo8%2B1/src/sna/sna_display.c/#L1036
>> [2] 
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/325570e731b5819e28ce6bae72242914bb2d7f8e
> 
> I can confirm that this patch
> 
> https://lists.x.org/archives/xorg-devel/2016-December/051958.html
> 
> solves the problem! :-)

This has now been merged upstream[1].

Regards,
James

[1] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a1b39eb6dd1717501a0546275d07df8321fe4905

Bug#847073: X doesn't start with new xserver-xorg-video-intel

[James Clarke]

> On 5 Dec 2016, at 12:05, Emilio Pozuelo Monfort <poch...@gmail.com> wrote:
> 
> On 05/12/16 12:27, James Clarke wrote:
>> Package: xserver-xorg-video-intel
>> Version: 2:2.99.917+git20161105-1
>> Severity: important
>> Tags: patch upstream
>> Control: retitle -1 segfaults due to missing NULL check in 
>> has_connector_backlight
>> 
>> This looks like [1] was reached with dir being NULL, though since you don't
>> have debugging symbols (and I don't know/can't seem to work out what address
> 
> What's wrong with xserver-xorg-video-intel-dbg ?

I was being an idiot; I had unpacked -dbg, but pointed addr2line at the stripped
library...

debian:xserver-xorg-video-intel james% addr2line -e 
root/usr/lib/debug/usr/lib/xorg/modules/drivers/intel_drv.so 0x74502
/build/xserver-xorg-video-intel-CxTaWA/xserver-xorg-video-intel-2.99.917+git20161105/build/src/sna/../../../src/sna/sna_display.c:1036

So yes, this was the problem (though I wasn't really in any doubt after seeing 
the
source).

James

Bug#847073: X doesn't start with new xserver-xorg-video-intel

[James Clarke]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20161105-1
Severity: important
Tags: patch upstream
Control: retitle -1 segfaults due to missing NULL check in 
has_connector_backlight

This looks like [1] was reached with dir being NULL, though since you don't
have debugging symbols (and I don't know/can't seem to work out what address
intel_drv.so was loaded at) I can't know for sure. Having said that, this is
the only place where the result of readdir is not checked for NULL, so I don't
know how else this would happen. This bug was introduced by [2]. Can you please
try the attached patch? Whether or not this is the problem, I'll forward it
upstream.

Regards,
James

[1] 
https://sources.debian.net/src/xserver-xorg-video-intel/2:2.99.917%2Bgit20161105-1%7Ebpo8%2B1/src/sna/sna_display.c/#L1036
[2] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/325570e731b5819e28ce6bae72242914bb2d7f8e

> On 5 Dec 2016, at 10:25, Micha vor dem Berge 
> <micha.vordembe...@christmann.info> wrote:
> 
> Hi all,
> 
> 
> I recently upgraded my xserver-xorg-video-intel package to the newest 
> jessie-backports (version 2:2.99.917+git20161105-1~bpo8+1). After a reboot, X 
> doesn't start anymore. I used this package from backports for several months, 
> so the newest update must have caused the trouble, I think.
> 
> After a downgrade to jessie stable (version 2:2.21.15-2+b2) X is starting 
> fine again, but I have no HW acceleration... :(
> 
> 
> Please find attached the Xorg.log.
> 
> Just for information: I'm using Linux Mint Debian Edition, so my desktop is 
> Cinnamon. And I compiled my own kernel (which was no problem in the past). I 
> also tried some of my older kernels of the 4.8.x kernel series - just to be 
> sure that the problem is not introduced by the newest kernel upgrade.
> 
> 
> Best regards,
> 
> Micha
> 
> 
> 
> PS: Please keep me in the loop when discussing this error as I didn't 
> subscribe to the backports mailing-list. Thanks!
> 

Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table

[James Cowgill]

Control: tags -1 patch

Hi,

On 18/11/16 23:39, James Cowgill wrote:
> On 16/11/16 17:15, James Cowgill wrote:
>> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828
>>
>> Hi,
>>
>> I've submitted the bug upstream with a reduced testcase and a bisection.
>>
>> As the bug requires -Wl,--gc-sections to occur, it may be possible to
>> workaround in mesa by recompiling without it.
> 
> I have attached two patches:
> 
> binutils-pr20828-v1.patch attempts to fix the underlying issue in
> binutils where local symbols appear intermixed with global symbols. It
> does this by applying another pass over the symbol table to assign all
> the local symbol indexes first, then ignoring local symbols in the
> second pass. This seems to fix my testcase and mesa, although I am not
> 100% sure of it and I would like to get some feedback from upstream as
> well since I don't really do much work with binutils.

I think the breakage is too much to wait any longer, so please can you
apply this patch to binutils so we can start recovering from all this.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table

[James Cowgill]

Hi,

On 16/11/16 17:15, James Cowgill wrote:
> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828
> 
> Hi,
> 
> I've submitted the bug upstream with a reduced testcase and a bisection.
> 
> As the bug requires -Wl,--gc-sections to occur, it may be possible to
> workaround in mesa by recompiling without it.

I have attached two patches:

binutils-pr20828-v1.patch attempts to fix the underlying issue in
binutils where local symbols appear intermixed with global symbols. It
does this by applying another pass over the symbol table to assign all
the local symbol indexes first, then ignoring local symbols in the
second pass. This seems to fix my testcase and mesa, although I am not
100% sure of it and I would like to get some feedback from upstream as
well since I don't really do much work with binutils.

mesa-mips-844227-workaround.patch is a workaround for mesa I was
investigating in the meantime. It turns out that removing
--Wl,gc-sections triggers some more undefined references so you need to
link libnir.a in a few extra places.

Thanks,
James
--- a/bfd/elfxx-mips.c
+++ b/bfd/elfxx-mips.c
@@ -743,6 +743,8 @@ static struct mips_got_entry *mips_elf_create_local_got_entry
struct mips_elf_link_hash_entry *, int);
 static bfd_boolean mips_elf_sort_hash_table_f
   (struct mips_elf_link_hash_entry *, void *);
+static bfd_boolean mips_elf_sort_hash_table_local_f
+  (struct mips_elf_link_hash_entry *, void *);
 static bfd_vma mips_elf_high
   (bfd_vma);
 static bfd_boolean mips_elf_create_dynamic_relocation
@@ -3850,6 +3852,11 @@ mips_elf_sort_hash_table (bfd *abfd, struct bfd_link_info *info)
 = hsd.min_got_dynindx
 = (elf_hash_table (info)->dynsymcount - g->reloc_only_gotno);
   hsd.max_non_got_dynindx = count_section_dynsyms (abfd, info) + 1;
+
+  mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *)
+elf_hash_table (info)),
+mips_elf_sort_hash_table_local_f,
+);
   mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *)
 elf_hash_table (info)),
 			   mips_elf_sort_hash_table_f,
@@ -3879,28 +3886,40 @@ mips_elf_sort_hash_table_f (struct mips_elf_link_hash_entry *h, void *data)
 {
   struct mips_elf_hash_sort_data *hsd = data;
 
-  /* Symbols without dynamic symbol table entries aren't interesting
- at all.  */
-  if (h->root.dynindx == -1)
+  /* Only interested in global symbols with dynamic symbol table entries */
+  if (h->root.dynindx == -1 || h->root.forced_local)
 return TRUE;
 
-  switch (h->global_got_area)
-{
-case GGA_NONE:
+  if (h->global_got_area == GGA_NONE) {
   h->root.dynindx = hsd->max_non_got_dynindx++;
-  break;
+  } else {
+  if (h->global_got_area == GGA_NORMAL)
+  h->root.dynindx = --hsd->min_got_dynindx;
+  else
+  h->root.dynindx = hsd->max_unref_got_dynindx++;
 
-case GGA_NORMAL:
-  h->root.dynindx = --hsd->min_got_dynindx;
-  hsd->low = (struct elf_link_hash_entry *) h;
-  break;
+  if (hsd->low == NULL || h->root.dynindx < hsd->low->dynindx)
+  hsd->low = (struct elf_link_hash_entry *) h;
+  }
 
-case GGA_RELOC_ONLY:
-  if (hsd->max_unref_got_dynindx == hsd->min_got_dynindx)
-	hsd->low = (struct elf_link_hash_entry *) h;
-  h->root.dynindx = hsd->max_unref_got_dynindx++;
-  break;
-}
+  return TRUE;
+}
+
+/* All local symbols must be appear before global symbols in the dynamic symbol
+   table so they're assigned indexs first. */
+
+static bfd_boolean
+mips_elf_sort_hash_table_local_f (struct mips_elf_link_hash_entry *h, void *data)
+{
+  struct mips_elf_hash_sort_data *hsd = data;
+
+  /* Only interested in local symbols with dynamic symbol table entries */
+  if (h->root.dynindx == -1 || !h->root.forced_local)
+return TRUE;
+
+  h->root.dynindx = hsd->max_non_got_dynindx++;
+  if (h->global_got_area != GGA_NONE && hsd->low == NULL)
+  hsd->low = (struct elf_link_hash_entry *) h;
 
   return TRUE;
 }

--- a/configure.ac
+++ b/configure.ac
@@ -543,17 +543,7 @@ AC_SUBST([BSYMBOLIC])
 dnl
 dnl Check if linker supports garbage collection
 dnl
-save_LDFLAGS=$LDFLAGS
-LDFLAGS="$LDFLAGS -Wl,--gc-sections"
-AC_MSG_CHECKING([whether ld supports --gc-sections])
-AC_LINK_IFELSE(
-[AC_LANG_SOURCE([static char UnusedFunc() { return 5; } int main() { return 0;}])],
-[AC_MSG_RESULT([yes])
-GC_SECTIONS="-Wl,--gc-sections";],
-[AC_MSG_RESULT([no])
-GC_SECTIONS="";])
-LDFLAGS=$save_LDFLAGS
-
+GC_SECTIONS=""
 AC_SUBST([GC_SECTIONS])
 
 dnl
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -29,6 +29,7 @@ gallium_drv_video_la_LIBADD = \
 	$(top_builddir)/src/gallium/auxiliary/libgalliumvl.la \
 	$(top_builddir)/src/gallium/auxiliary/libgallium

Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table

[James Cowgill]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828

Hi,

I've submitted the bug upstream with a reduced testcase and a bisection.

As the bug requires -Wl,--gc-sections to occur, it may be possible to
workaround in mesa by recompiling without it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table (Was: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd')

[James Cowgill]

On 16/11/16 11:32, James Cowgill wrote:
> Here 3 = the index of the first non-global symbol, and 9 = the total

s/non-global/non-local/

James



signature.asc
Description: OpenPGP digital signature

Re: Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'

[James Cowgill]

Control: reassign -1 binutils 2.25-5
Control: severity -1 important
Control: affects -1 src:fracplanet
Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol 
table

Hi,

On 14/11/16 19:08, Adrian Bunk wrote:
> Package: fracplanet
> Version: 0.4.0-5
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=fracplanet=sid
> 
> g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet 
> obj/common.o obj/control.o obj/control_about.o obj/control_render.o 
> obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o 
> obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o 
> obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o 
> obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o 
> obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o 
> obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o 
> obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o 
> obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o 
> obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o 
> obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o 
> obj/moc_control_terrain.o obj/moc_dialog_documentation.o 
> obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang
>  le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib 
> -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
> /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd'
> 
> 
> Michael Biebl mentioned #844227 on IRC, are these bugs coincidence,
> or is there something that broke/changed in Mesa on mips* recently?

Looking at this a bit closer, it appears to be a longstanding binutils
bug which was recently made worse due to a change in counting local
symbols.

Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the
first (long standing) bug:

$ readelf --syms libGL.so.1 | head -n15
Symbol table '.dynsym' contains 1559 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1: 000163c0 0 SECTION LOCAL  DEFAULT   10
 2: 000902a8 0 SECTION LOCAL  DEFAULT   16
 3: 0007264052 FUNCGLOBAL DEFAULT   11 
glCheckFramebufferStatusE
 4: 0006c47052 FUNCGLOBAL DEFAULT   11 glConvolutionFilter1D
 5: 0007219828 FUNCGLOBAL DEFAULT   11 glVertexAttrib3fvARB
 6: 0006b73052 FUNCGLOBAL DEFAULT   11 glLoadMatrixd
 7: 000943d0 0 NOTYPE  LOCAL  DEFAULT   24 _fbss
 8: 0006c6a052 FUNCGLOBAL DEFAULT   11 
glGetConvolutionParameter
 9: 0006973052 FUNCGLOBAL DEFAULT   11 glVertex4i
10: 0006ebe052 FUNCGLOBAL DEFAULT   11 
glGetBufferPointervARB
11: 0006e3d828 FUNCGLOBAL DEFAULT   11 glWindowPos2f

Here the _fbss symbol is LOCAL which is prohibited by the ELF standard
which requires all LOCAL symbols to precede GLOBAL symbols. This bug is
definitely present in jessie's binutils, because jessie's libGL also
has a symbol table similar to this. Wheezy's mesa doesn't have this bug
but I don't know if binutils definitely doesn't have it in wheezy.

Ordinarily this wasn't much of an issue since glibc and ld would just
skip LOCAL symbols when processing the symbol tables. However somewhere
between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for
calculating the 'st_info' field for the .dynsym section header changed.
Recompiling mesa with both versions of binutils gives identical libGL
binaries except for this difference in the section header:

diffoscope output (- 2.27-9, + 2.27.51.20161108-1):
│ -  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   3  8
│ +  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   9  8

Here 3 = the index of the first non-global symbol, and 9 = the total
number of local symbols. These values should of course be equal if the
rules about symbol ordering were followed. ld uses the value of the
'st_info' field to skip LOCAL symbols when linking, which explains why
only the 5 symbols from 3-8 in the above symbol table cause link errors.

I'm still investigating, but getting a reduced testcase is quite tricky
and recompiling mesa on mips takes about an hour.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#827651: vulkan: FTBFS on mips64el -- relocation truncated to fit: R_MIPS_CALL16

[James Cowgill]

Source: vulkan
Version: 1.0.8.0+dfsg1-1
Severity: important
Tags: patch

Hi,

vulakn FTBFS on mips64el because the libVkLayer_core_validation.so
library contains too many symbols and overflows the default GOT. This
is what causes the relocation errors. This can be fixed by compiling
vulkan with the -mxgot flag, although this does have a performance
penalty.

Before this can happen, the validation layer CMakeLists.txt file must
be updated so it doesn't clobber the CXXFLAGS variable.

Patches to do both of these tasks are attached.

Thanks,
JamesDescription: Don't clobber CXXFLAGS when building validation layers
Author: James Cowgill <jcowg...@debian.org>
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/layers/CMakeLists.txt
+++ b/layers/CMakeLists.txt
@@ -91,7 +91,7 @@ if (WIN32)
 set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -D_CRT_SECURE_NO_WARNINGS /bigobj")
 endif()
 if (NOT WIN32)
-set (CMAKE_CXX_FLAGS "-std=c++11")
+set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
 set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wpointer-arith")
 set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wpointer-arith")
 endif()
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,10 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
 
+ifeq ($(DEB_HOST_ARCH),mips64el)
+export DEB_CXXFLAGS_MAINT_APPEND := -mxgot
+endif
+
 # main packaging script based on dh7 syntax
 %:
 	dh $@ --with quilt --builddirectory=build/


signature.asc
Description: This is a digitally signed message part

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[James Clarke]

Control: forwarded -1 https://patchwork.freedesktop.org/series/6272/
Control: tags -1 upstream

> On 24 Apr 2016, at 08:44, Emilio Pozuelo Monfort <po...@debian.org> wrote:
> 
>> On 23/04/16 17:27, James Clarke wrote:
>> 
>> I rebuilt xorg-server-2_1.18.3-1 having patched Xpoll.h with this exact
>> patch (with s/Xpoll.h.in/Xpoll.h, of course) and can confirm it works.
> 
> Great. Please send the patch to xorg-de...@lists.x.org

Done (thanks jcristau for the moderator approval!).

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[James Clarke]

> On 23 Apr 2016, at 15:03, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Hi,
>> On 23 Apr 2016, at 14:55, Samuel Thibault <sthiba...@debian.org 
>> <mailto:sthiba...@debian.org>> wrote:
>> 
>> Hello,
>> 
>> James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote:
>>> I have attached a proposed patch which ensures XFD_SETSIZE never
>>> exceeds FD_SETSIZE.
>> 
>> Did you test it?
> 
> Not this specific version, but changing it to 256 directly in the header.
> I’m about to test this exact patch.

I rebuilt xorg-server-2_1.18.3-1 having patched Xpoll.h with this exact
patch (with s/Xpoll.h.in/Xpoll.h, of course) and can confirm it works.

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[James Clarke]

> On 23 Apr 2016, at 15:06, Samuel Thibault <sthiba...@debian.org> wrote:
> 
> James Clarke, on Sat 23 Apr 2016 15:03:29 +0100, wrote:
>>> AIUI, nothing uses XFD_SETSIZE actually, it's just the default value
>>> that X uses for FD_SETSIZE in case it's not already defined.
>> 
>> No, in e.g. os/WaitFor.c in xorg-server, there are for loops using
>> howmany(XFD_SETSIZE, NFDBITS) to iterate over each element,
> 
> Ergl, ok, so XFD_SETSIZE also needs to be fixed.

This *is* changing XFD_SETSIZE...

>> These lines are fine; the indexing is guarded by the howmany check, and uses
>> the real FD_SETSIZE.
> 
> Ah, right.  Overlooked the whole thing too fast.
> 
> Sorry for the noise,

Not to worry; always best to question these things :)

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[James Clarke]

Hi,
> On 23 Apr 2016, at 14:55, Samuel Thibault <sthiba...@debian.org> wrote:
> 
> Hello,
> 
> James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote:
>> I have attached a proposed patch which ensures XFD_SETSIZE never
>> exceeds FD_SETSIZE.
> 
> Did you test it?

Not this specific version, but changing it to 256 directly in the header.
I’m about to test this exact patch.

> 
> AIUI, nothing uses XFD_SETSIZE actually, it's just the default value
> that X uses for FD_SETSIZE in case it's not already defined.

No, in e.g. os/WaitFor.c in xorg-server, there are for loops using
howmany(XFD_SETSIZE, NFDBITS) to iterate over each element, which invokes
undefined behaviour and a warning from GCC due to aggressive loop optimisations.
There are a few more if you grep the xorg-server source tree, and who knows
about other packages.

> I.e. your
> change doesn't actually change anything: if FD_SETSIZE is define on
> poll.h inclusion, it'll be used, not 512.  What probably actually breaks
> is the
> 
> (howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) ||
> 
> lines when FD_SETSIZE is not big enough.  Probably these can be made
> conditioned by the value of FD_SETSIZE, something like:
> 
> #if FD_SETSIZE >= 512
> #define XFD_ANYSET_512(p) \
>   ((howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 9 && (__XFDS_BITS(p, 9))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 10 && (__XFDS_BITS(p, 10))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 11 && (__XFDS_BITS(p, 11))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 12 && (__XFDS_BITS(p, 12))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 13 && (__XFDS_BITS(p, 13))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 14 && (__XFDS_BITS(p, 14))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 15 && (__XFDS_BITS(p, 15
> #else
> #define XFD_ANYSET_512(p) 0
> #endif
> 
> #define XFD_ANYSET(p) \
>   ((howmany(FD_SETSIZE, NFDBITS) > 0 && (__XFDS_BITS(p, 0))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 1 && (__XFDS_BITS(p, 1))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 2 && (__XFDS_BITS(p, 2))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 3 && (__XFDS_BITS(p, 3))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 4 && (__XFDS_BITS(p, 4))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 5 && (__XFDS_BITS(p, 5))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 6 && (__XFDS_BITS(p, 6))) || \
>(howmany(FD_SETSIZE, NFDBITS) > 7 && (__XFDS_BITS(p, 7))) || \
>   XFD_ANYSET_512(p))


These lines are fine; the indexing is guarded by the howmany check, and uses
the real FD_SETSIZE.

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[James Clarke]

Control: tags -1 - moreinfo
Control: tags -1 + patch
Control: reassign x11proto-core-dev 7.0.28-1

Hi,
I looked into this, and it turns out
https://anonscm.debian.org/cgit/pkg-xorg/proto/x11proto-core.git/commit/?id=2c94cdb453bc641246cc8b9a876da9799bee1ce7
is to blame, not the server itself. On GNU/Hurd FD_SETSIZE is only 256, so
XFD_SETSIZE exceeds this, and when various files in os/ (e.g. WaitFor.c)
iterate over the set, they go out of bounds; GCC very helpful gives "warning:
iteration 8u invokes undefined behavior [-Waggressive-loop-optimizations]" for
these. I have attached a proposed patch which ensures XFD_SETSIZE never exceeds
FD_SETSIZE.

Regards,
James

> On 22 Apr 2016, at 20:32, Julien Cristau <jcris...@debian.org> wrote:
> 
> Control: tags -1 moreinfo help
> 
> On Thu, Apr 21, 2016 at 23:16:02 +0200, Matthias wrote:
> 
>> Package: xorg
>> Version: 1:7.7+14
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> X crashes instantly when starting any application, e.g. FF or system 
>> configuration settings or display settings. The Xorg.0.log file states, 
>> xorg-server version is 2:1.18.3-1 . System is Debian testing running under 
>> hurd.
>> 
> This would have to be looked at by a hurd person.  (Also, there's no
> such thing as debian testing for hurd, afaik, only unstable)
> 
> Cheers,
> Julien
> 
>> 
>> -- Package-specific info:
>> X server symlink status:
>> 
>> lrwxr-xr-x 1 root root 13 Dec 28 11:32 /etc/X11/X -> /usr/bin/Xorg
>> -rwxr-xr-x 1 root root 274 Apr  5 11:40 /usr/bin/Xorg
>> 
>> VGA-compatible devices on PCI bus:
>> --
>> 
>> Xorg X server configuration file status:
>> 
>> -rw-r--r-- 1 root root 131 Dec 28 11:38 /etc/X11/xorg.conf
>> 
>> Contents of /etc/X11/xorg.conf:
>> ---
>> Section "InputDevice"
>>   Identifier "Generic Keyboard"
>>   Driver "kbd"
>>   Option "XkbOptions" "terminate:ctrl_alt_bksp"
>> EndSection
>> 
>> /etc/X11/xorg.conf.d does not exist.
>> 
>> /etc/modprobe.d contains no KMS configuration files.
>> 
>> Kernel version (/proc/version):
>> ---
>> Linux version 2.6.1 (GNU 0.7 GNU-Mach 1.6+git20160311-486/Hurd-0.7 
>> i686-AT386)
>> 
>> Xorg X server log files on system:
>> --
>> -rw-r--r-- 1 root root 29974 Apr 21 22:45 /var/log/Xorg.0.log
>> 
>> Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
>> -
>> [982589.873]
>> X.Org X Server 1.18.3
>> Release Date: 2016-04-04
>> [982589.873] X Protocol Version 11, Revision 0
>> [982589.873] Build Operating System: GNU 0.7 i686-AT386 Debian
>> [982589.873] Current Operating System: GNU debian 0.7 GNU-Mach 
>> 1.6+git20160311-486/Hurd-0.7 i686-AT386
>> [982589.873] Build Date: 05 April 2016  09:20:21AM
>> [982589.873] xorg-server 2:1.18.3-1 (http://www.debian.org/support)
>> [982589.873] Current version of pixman: 0.33.6
>> [982589.873] Before reporting problems, check http://wiki.x.org
>>  to make sure that you have the latest version.
>> [982589.873] Markers: (--) probed, (**) from config file, (==) default 
>> setting,
>>  (++) from command line, (!!) notice, (II) informational,
>>  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [982589.873] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Apr 21 22:44:30 
>> 2016
>> [982589.883] (==) Using config file: "/etc/X11/xorg.conf"
>> [982589.883] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>> [982589.883] (==) No Layout section.  Using the first Screen section.
>> [982589.883] (==) No screen section available. Using defaults.
>> [982589.883] (**) |-->Screen "Default Screen Section" (0)
>> [982589.883] (**) |   |-->Monitor ""
>> [982589.893] (==) No monitor specified for screen "Default Screen Section".
>>  Using a default monitor configuration.
>> [982589.893] (==) Not automatically adding devices
>> [982589.893] (==) Not automatically enabling devices
>> [982589.893] (==) Not automatically adding GPU devices
>> [982589.893] (==) Max clients allowed: 256, resource mask: 0x1f
>> [982589.893] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
>> exist.
>> [982589.893] En

Bug#822286: libvulkan1: calls ldconfig multiple times

[James Cowgill]

Package: libvulkan1
Version: 1.0.8.0+dfsg1-1
Severity: minor

Hi,

Another minor bug I just noticed :)

libvulkan1 ships a postinst and postrm to call ldconfig, but the call
to ldconfig is already handled by debhelper through a dpkg trigger.
This means that installing libvulkan1 ends up calling ldconfig 3 times
instead of once.

Removing the maintainer scripts should solve this.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#822284: vulkan: split validation layers out of libvulkan1

[James Cowgill]

Source: vulkan
Version: 1.0.8.0+dfsg1-1
Severity: wishlist

Hi,

Firstly I haven't be using Vulkan that long so I might not have this
totally right but...

It seems to me that the validation layer files (*.json, libVkLayer_*.so
and liblayer_utils.so) are not required to actually run Vulkan
applications but are only used during development. These files should
therefore be in a separate package, possibly depended or recommended on
by libvulkan-dev. This would shave about 9M off the installed package
size as well.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#822283: libvulkan1: typo in package description

[James Cowgill]

Package: libvulkan1
Version: 1.0.8.0+dfsg1-1
Severity: minor
Tags: patch

Hi,

The package description for libvulkan1 claims to include the
"vulkaninfo" binary, but it does not - it's in vulkan-utils instead.

While looking at the control file I also noticed that vulkan-utils
depends on libvulkan1 which seemed strange (since it's added
automatically) so I removed it, but feel free to ignore that bit of the
patch if you want.

Thanks,
Jamesdiff -ur a/debian/control b/debian/control
--- a/debian/control	2016-04-14 11:57:06.0 +0100
+++ b/debian/control	2016-04-22 23:06:30.906063978 +0100
@@ -25,7 +25,7 @@
  this, it dispatches API calls to the correct driver, and to the correct
  layers, based on the GPU object selected by the application.
  .
- This package includes the loader library and vulkaninfo binary.
+ This package includes the loader library.
 
 Package: libvulkan-dev
 Section: libdevel
@@ -45,6 +45,5 @@
 Architecture: any
 Section: graphics
 Depends: ${shlibs:Depends}, ${misc:Depends},
- libvulkan1,
 Description: Miscellaneous Vulkan utilities
  This package provides utilities for Vulkan, including vulkaninfo.


signature.asc
Description: This is a digitally signed message part

Bug#801847: Cannot type after X restart

[James Richardson]

Julien Cristau writes:

> On Tue, Oct 27, 2015 at 22:32:15 -0200, Andre N Batista wrote:
>
>
>> [  2832.788] (EE) systemd-logind: failed to get session: The name 
>>  org.freedesktop.login1 was not provided by any .service files
>
> You need to be running logind.  Install the libpam-systemd package and
> things should work better.
>

or install xserver-xorg-legacy.

Bug#801401: Workarounds for rootless Xorg

[Christopher James Halse Rogers]

On Fri, Oct 23, 2015 at 5:01 AM, Lingzhu Xiang 
 wrote:

* Privilege to drmSetMaster()

If there is only one drm device no setup is needed.


This is an incorrect understanding of what drmSetMaster() does. It is 
not setting a primary device, it's the process claiming the DRM_MASTER 
capability, which is required for things like modesetting and 
authorising other drm clients' access to the device.


Claiming DRM_MASTER requires root.

Bug#801401: cannot start X from the console command line

[James Richardson]

Julien Cristau writes:

> On Mon, Oct 12, 2015 at 10:59:27 -0400, James Richardson wrote:
>
>> Package: xserver-xorg
>> Version: 1:7.7+12
>> Followup-For: Bug #801401
>> 
>> Dear Maintainer,
>> 
>> I resolved this on my workstation by installing xserver-xorg-legacy
>> and adding the line
>> 
>> needs_root_rights=yes
>> 
>> to /etc/X11/Xwrapper.config
>> 
>> 
>> In case it matters: my init system is runit, I run fluxbox via startx.
>
> It does.  X won't work as non-root without logind:
>
>> [   172.319] (EE) systemd-logind: failed to get session: The name 
>> org.freedesktop.login1 was not provided by any .service files

I don't have systemd-logind installed, so obviously it will not get a
systemd session, nor do I need such a thing. Other than that it works.

Bug#801614: xserver-xorg-legacy: ask for needs_root_rights in Xwrapper.config

[James Richardson]

Package: xserver-xorg-legacy
Version: 2:1.17.2-3
Severity: wishlist

Dear Maintainer,

Would it be possible to add the line

needs_root_rights=auto

to Xwrapper.config and have debconf query the user for the proper value. (I 
need it set to yes in my particular config).

If such a thing is indeed acceptable, I am willing to do the particulars...

-- System Information:
Debian Release: stretch/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages xserver-xorg-legacy depends on:
ii  debconf [debconf-2.0]  1.5.57
ii  libaudit1  1:2.4.4-4
ii  libc6  2.19-22
ii  xserver-common 2:1.17.2-3

xserver-xorg-legacy recommends no packages.

xserver-xorg-legacy suggests no packages.

-- debconf information:
* xserver-xorg-legacy/xwrapper/allowed_users: Console Users Only
  xserver-xorg-legacy/xwrapper/actual_allowed_users: console

Bug#801401: cannot start X from the console command line

[James Richardson]

Package: xserver-xorg
Version: 1:7.7+12
Followup-For: Bug #801401

Dear Maintainer,

I resolved this on my workstation by installing xserver-xorg-legacy
and adding the line

needs_root_rights=yes

to /etc/X11/Xwrapper.config


In case it matters: my init system is runit, I run fluxbox via startx.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Dec 11  2011 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct  6 03:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GLM [Quadro 
1000M] [10de:0dfa] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1

Kernel version (/proc/version):
---
Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-4) ) #1 SMP Debian 4.2.3-1 (2015-10-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  9410 Dec 14  2011 /var/log/Xorg.8.log
-rw-r--r-- 1 root root 38010 Jul 27 18:15 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 34217 Oct 12 10:35 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   172.294] 
X.Org X Server 1.17.2
Release Date: 2015-06-16
[   172.296] X Protocol Version 11, Revision 0
[   172.296] Build Operating System: Linux 4.2.0-1-amd64 x86_64 Debian
[   172.297] Current Operating System: Linux weasel 4.2.0-1-amd64 #1 SMP Debian 
4.2.3-1 (2015-10-06) x86_64
[   172.297] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64 
root=/dev/mapper/vg00-root ro quiet
[   172.298] Build Date: 06 October 2015  07:27:47AM
[   172.299] xorg-server 2:1.17.2-3 (http://www.debian.org/support) 
[   172.300] Current version of pixman: 0.33.2
[   172.301]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   172.301] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   172.304] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 12 10:35:32 
2015
[   172.309] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   172.310] (==) No Layout section.  Using the first Screen section.
[   172.310] (==) No screen section available. Using defaults.
[   172.310] (**) |-->Screen "Default Screen Section" (0)
[   172.310] (**) |   |-->Monitor ""
[   172.311] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   172.311] (==) Automatically adding devices
[   172.312] (==) Automatically enabling devices
[   172.312] (==) Automatically adding GPU devices
[   172.313] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   172.313]Entry deleted from font path.
[   172.317] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[   172.317]Entry deleted from font path.
[   172.317] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[   172.317]Entry deleted from font path.
[   172.317] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
built-ins
[   172.317] (==) ModulePath set to "/usr/lib/xorg/modules"
[   172.317] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   172.317] (II) Loader magic: 0x555adf6cbde0
[   172.317] (II) Module ABI versions:
[   172.317]X.Org ANSI C Emulation: 0.4
[   172.318]X.Org Video Driver: 19.0
[   172.318]X.Org XInput driver : 21.0
[   172.318]X.Org Server Extension : 9.0
[   172.319] (EE) systemd-logind: failed to get session: The name 
org.freedesktop.login1 was not provided by any .service files
[   172.321] (II) xfree86: Adding drm device (/dev/dri/card0)
[   172.737] (--) PCI:*(0:1:0:0) 10de:0dfa:17aa:21cf rev 161, Mem @ 
0xd200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x5000/128, BIOS @ 0x/524288
[   172.739] (II) LoadModule: "glx"
[   172.741] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   172.759] (II) Module glx: vendor="X.Org Foundation"
[   172.759]compiled for 1.17.2, module version = 1.0.0
[   172.759]ABI class: X.Org Server Extension, version 9.0
[   172.759] (==) AIGLX enabled
[   172.759] (==) Matched nouveau as autoconfigured driver 0
[   172.759] (==) Matched nv as autoconfigured driver 1
[   172.759] (==) Matched nouveau as autoconfigured driver 2
[   172.759] (==) Matched nv as autoconfigured 

Bug#800959: xserver-xorg-core: fails to upgrade with old version of x11-common installed

[James Cowgill]

Package: xserver-xorg-core
Version: 1.17.2-2
Severity: serious

Hi,

xserver-xorg-core does not upgrade to the version in experimental if
the old version of x11-common is installed.

# dpkg -l xserver-xorg x11-common xserver-xorg-core
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture 
Description
+++-===---
ii  x11-common  1:7.7+9  all  X 
Window System (X.Org) infrastructure
ii  xserver-xorg1:7.7+9  amd64
X.Org X server
ii  xserver-xorg-core   2:1.17.2-1.1 amd64
Xorg X server - core server

# dpkg -i /var/cache/apt/archives/xserver-xorg_1%3a7.7+11_amd64.deb 
/var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb 
(Reading database ... 209469 files and directories currently installed.)
Preparing to unpack .../xserver-xorg_1%3a7.7+11_amd64.deb ...
Unpacking xserver-xorg (1:7.7+11) over (1:7.7+9) ...
Preparing to unpack .../xserver-xorg-core_2%3a1.17.2-2_amd64.deb ...
Unpacking xserver-xorg-core (2:1.17.2-2) over (2:1.17.2-1.1) ...
dpkg: error processing archive 
/var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb (--install):
 trying to overwrite '/usr/share/man/man5/Xwrapper.config.5.gz', which is also 
in package x11-common 1:7.7+9
dpkg: dependency problems prevent configuration of xserver-xorg:
 xserver-xorg depends on xserver-xorg-core (>= 2:1.17.2-2); however:
  Version of xserver-xorg-core on system is 2:1.17.2-1.1.

dpkg: error processing package xserver-xorg (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.7.3-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb
 xserver-xorg

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#778187: xorg-server: ftbfs with GCC-5

[James Cowgill]

Control: tags -1 patch fixed-upstream

On Thu, 12 Feb 2015 10:38:13 + Matthias Klose d...@debian.org wrote:
 The package fails to build in a test rebuild on at least amd64 with
 gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9. The
 severity of this report may be raised before the stretch release.

Fixed upstream. The patch applied there is attached.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=21b896939c5bb242f3aacc37baf12379e43254b6

Thanks,
James
From 21b896939c5bb242f3aacc37baf12379e43254b6 Mon Sep 17 00:00:00 2001
From: Egbert Eich e...@freedesktop.org
Date: Tue, 3 Mar 2015 16:27:05 +0100
Subject: symbols: Fix sdksyms.sh to cope with gcc5

Gcc5 adds additional lines stating line numbers before and
after __attribute__() which need to be skipped.

Signed-off-by: Egbert Eich e...@freedesktop.org
Tested-by: Daniel Stone dani...@collabora.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index 2305073..05ac410 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -350,13 +350,25 @@ BEGIN {
 if (sdk) {
 	n = 3;
 
+# skip line numbers GCC 5 adds before __attribute__
+while ($n ==  || $0 ~ /^# [0-9]+ /) {
+   getline;
+   n = 1;
+}
+
 	# skip attribute, if any
 	while ($n ~ /^(__attribute__|__global)/ ||
 	# skip modifiers, if any
 	$n ~ /^\*?(unsigned|const|volatile|struct|_X_EXPORT)$/ ||
 	# skip pointer
-	$n ~ /^[a-zA-Z0-9_]*\*$/)
+	$n ~ /^[a-zA-Z0-9_]*\*$/) {
 	n++;
+# skip line numbers GCC 5 adds after __attribute__
+while ($n ==  || $0 ~ /^# [0-9]+ /) {
+   getline;
+   n = 1;
+}
+}
 
 	# type specifier may not be set, as in
 	#   extern _X_EXPORT unsigned name(...)
-- 
cgit v0.10.2



signature.asc
Description: This is a digitally signed message part

Bug#780656: xserver-xorg-input-evdev: Logitech wireless keyboard ignores locale in X.org, defaults to en-us

[Daniel James]

Package: xserver-xorg-input-evdev
Version: 1:2.9.0-2
Severity: normal

After upgrading a machine from squeeze to wheezy to jessie, my Logitech
K400 wireless keyboard no longer functioned correctly. My locale is
en-gb but key presses resulted in en-us characters appearing in
applications running under X.org, for example the pipe symbol on the
keyboard became a chevron on the screen.

It appears to be an old bug filed (twice) in Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/993827
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715

There is a detailed explanation of the issue here:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715/comments/19

Linux kernel 3.2 introduced the logitech_dj HID driver to explicitly
support the Logitech Unifying Receiver. This wireless USB hardware is
designed for compatible mice and keyboards so that you only need one
dongle for multiple devices. It worked fine for both mice and keyboards
under squeeze, using a generic USB driver.

However the xserver-xorg-input-evdev package does not seem to support
this change of drivers, as far as keyboards are concerned.

The workaround is for the display manager startup script to force the
locale. In my case, I did this in ~/.fluxbox/startup with the line:

setxkbmap gb

Thanks!

Daniel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55082579.3040...@64studio.com

Bug#767869: xserver-xorg-video-vmware: (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.

[James Turton]

Package: xserver-xorg-video-vmware
Version: 1:13.0.2-3+b1
Severity: important

Running Debian Jessie in VMware Fusion 7.0.1 on Mac OS 10.10.  3D accleration
for guests is enabled in the VMware Fusion settings.  When X starts, render
acceleration fails to initialise.  Relevant parts of Xorg.0.log below.


[27.477] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
[27.477] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render
acceleration available.
[27.477] (WW) vmware(0): Skipped initialization of direct rendering due to
lack of render acceleration.
[27.478] (--) vmware(0): Render acceleration is disabled.
[27.478] (==) vmware(0): Rendercheck mode is disabled.
[27.478] (--) vmware(0): Direct rendering (3D) is disabled.
[27.478] (==) vmware(0): Backing store disabled
[27.478] (==) vmware(0): Silken mouse enabled
[27.478] (II) vmware(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
[27.478] (==) vmware(0): DPMS enabled
[27.478] (II) vmware(0): No 3D acceleration. Not setting up textured video.
..
..
..
[28.883] (II) AIGLX: Loaded and initialized swrast
[28.883] (II) GLX: Initialized DRISWRAST GL provider for screen 0



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct 22 10:30 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2397280 Sep 22 23:49 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:0f.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.16-3-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 61574 Oct 22 17:52 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[25.821] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[25.821] X Protocol Version 11, Revision 0
[25.821] Build Operating System: Linux 3.11-2-amd64 x86_64 Debian
[25.821] Current Operating System: Linux jtvm 3.2.0-4-amd64 #1 SMP Debian 
3.2.63-2 x86_64
[25.821] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=56b6fb69-8c73-487a-94f8-b15453581301 ro quiet
[25.821] Build Date: 17 December 2013  07:37:58PM
[25.821] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau 
jcris...@debian.org) 
[25.822] Current version of pixman: 0.26.0
[25.822]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[25.822] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[25.822] (==) Log file: /var/log/Xorg.0.log, Time: Wed Oct 22 15:07:18 
2014
[25.874] (==) Using system config directory /usr/share/X11/xorg.conf.d
[25.917] (==) No Layout section.  Using the first Screen section.
[25.917] (==) No screen section available. Using defaults.
[25.917] (**) |--Screen Default Screen Section (0)
[25.917] (**) |   |--Monitor default monitor
[25.918] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[25.918] (==) Automatically adding devices
[25.918] (==) Automatically enabling devices
[26.070] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[26.070]Entry deleted from font path.
[26.276] (WW) The directory 
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist.
[26.276]Entry deleted from font path.
[26.276] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[26.276] (==) ModulePath set to /usr/lib/xorg/modules
[26.276] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[26.276] (II) Loader magic: 0x7f708cbe5ae0
[26.276] (II) Module ABI versions:
[26.276]X.Org ANSI C Emulation: 0.4
[26.276]X.Org Video Driver: 12.1
[26.276]X.Org XInput driver : 16.0
[26.276]X.Org Server Extension : 6.0
[26.285] (--) PCI:*(0:0:15:0) 15ad:0405:15ad:0405 rev 0, Mem @ 
0xe800/134217728, 0xfe00/8388608, I/O @ 0x1070/16, BIOS @ 
0x/32768
[26.286] (II) Open ACPI 

Bug#742475: xserver-xorg-dev: X comes up with black screen lower 1/2 ignores xrandr until TV output shut off

[James Durham]

Package: xserver-xorg-dev
Version: 2:1.15.0-2
Severity: important
Tags: upstream
Bug#742472
Dear Maintainer,


 * What led up to the situation?

I installed a new install of Debian PPC on my iMacG5 and was trying
to get X working properly  The session using the default desktop opened
very strangely with missing characters, distorted menus barely readable.
Tried Xfce desktop and that worked considerably better. Tried Lxde and
that opened with the bottom 1/2 of the desktop background in black.
Windows would open, but if you maximized them the lower portions would
not have text. If you dragged them with the mouse and made them larger,
then they were all OK.   In no case did X configure the external monitor.
It would flash and report that it was being asked to do 12 hz refresh!

 * What exactly did you do (or not do) that was effective (or
   ineffective)?

I tried to create an xorg.conf file.  X -configure failed saying the number
of screens was incorrect. I found a single-monitor xorg.conf where the
TV output of the iMac was turned off, along with the external monitor
output. That worked properly for the single built-in monitor. I tried to
turn on the external monitor in xorg.conf, leaving the TV output off,
but that failed.  Also, the iMac screen showed a darker area that looked
to be 1024x768, the highest mode of the TV output.  I finally did  
xrandr --output TV-1 --off  followed by xrandr --output VGA-1 
--mode 1280x1024 left-of DVI-D-1 .

 * What was the outcome of this action?
That cleared most of the problems, but left the external monitor as the primary
monitor.  I found that whatever monitor was told to be the left monitor
would become primary.

 * What outcome did you expect instead?

I expected that having the TV output (TV-1) on but nothing plugged into the
connector would cause it to be ignored and that the external monitor would
auto-configure (I had tried --output VGA-1 --auto and it did not work). 
I expected X -configure to make a proper xorg.conf file.



-- System Information:
Debian Release: 7.4
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: powerpc (ppc64)

Kernel: Linux 3.2.0-4-powerpc64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xserver-xorg-dev depends on:
ii  libpciaccess-dev  0.13.1-2
ii  libpixman-1-dev   0.32.4-1
ii  libxkbfile-dev1:1.0.8-1
ii  mesa-common-dev   9.2.2-1
ii  x11proto-core-dev 7.0.23-1
ii  x11proto-dri2-dev 2.8-2
ii  x11proto-dri3-dev 1.0-1
ii  x11proto-fonts-dev2.1.2-1
ii  x11proto-gl-dev   1.4.17-1
ii  x11proto-input-dev2.3-1
ii  x11proto-kb-dev   1.0.6-2
ii  x11proto-present-dev  1.0-1
ii  x11proto-randr-dev1.4.0-2
ii  x11proto-render-dev   2:0.11.1-2
ii  x11proto-resource-dev 1.2.0-3
ii  x11proto-scrnsaver-dev1.2.2-1
ii  x11proto-video-dev2.3.1-2
ii  x11proto-xext-dev 7.3.0-1
ii  x11proto-xf86bigfont-dev  1.2.0-3
ii  x11proto-xf86dri-dev  2.1.1-2
ii  x11proto-xinerama-dev 1.2.1-2

xserver-xorg-dev recommends no packages.

xserver-xorg-dev suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5f36da21-8ecf-46ec-b0d0-8eb16e595...@gmail.com

Bug#505893: seems fixed upstream

[James Cloos]

Unless this bug is specific to debian, this should be fixed in xmessage-1.0.4
with a current Xorg server.

At least it does the right thing for me on my Gentoo workstation.

(I only use debian on my servers)

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m3ha9p283k@carbon.jhcloos.org

Bug#699746: probably fixed upstream

[James Cloos]

Xprop(1) got a significant overhall a while back.  This should work
correcly now.

That said, xterm(1) doesn’t do the right thing with such titles in
that it stores them on the server as STRING where they ought to be
stored as COMPOUND_TEXT for WM_NAME and WM_ICON_NAME and as UTF8_STRING
for _NET_WM_NAME and _NET_WM_ICON_NAME (which xterm does not set at all).

(The latter two props, of course, were created just to provided the
names as UTF8_STRINGs rather than as COMPOUND_TEXT.)

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6




signature.asc
Description: PGP signature

Re: Help with linking with libglapi

[Christopher James Halse Rogers]

On Fri, 2012-11-30 at 10:37 +0900, Norbert Preining wrote:
 Dear maintainers of libglapi-mesa,
 
 I am trying to update asymptote to use OSmesa and the configure script
 of it also checks for libglapi. THe check is done by compiling a simple
 program and trying to link it with
   ... -lglapi ...
 Now that does not work, because there is no link
   libglapi.so - libglapi.so.0
 which would normally be shipped with a -dev package.
 
 Can you recommend a way how to fix this? Thanks a lot

Is there a particular reason why it's attempting to link to libglapi?
libglapi is essentially an implementation detail of mesa to allow
multiple providers of GL symbols in the same process (eg: libGL and
libGLESv2).

Possibly the correct way to fix this is just to remove the check?


signature.asc
Description: This is a digitally signed message part

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

 Can you try a newer kernel?  3.6 or 3.7?  That may help with the
 modesettings.  As for the acceleration, corruption, you might try a
 newer version of mesa.

I cheated a little and tried the latest aptosid kernel
linux-image-aptosid-amd64_3.6-12_amd64  - same screen corruption
issues.

I followed some documentation and started to compile and install the
latest mesa on Sid...  I gave up after a few hours and as a test
installed Arch as it has a new Kernel 3.6.3-1 and the latest Mesa
9.0-1 - Still had screen corruption issues.

Bad for a Debian bug report, sorry about that but I was getting a bit
frustrated.

I can't help but think it's something to do with the monitors.  I
mean, why would a different model monitor (Benq) that has native
1920x1080 work fine when used paired with one of my AOC's?  But using
the 2 identical model AOC's causes the problem?

I am going to try fglrx on Arch for a test.


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMALoy9fZt8CEVt0x3rSu=1c7u9m-5ul1sahhhqqph3feg5...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

 The only other option I was going to try was using a Display port to
 DVI adapter from the side of my laptop to replace the VGA from the
 docking station.  If I purchase one to  try that I'll let you know.

I bought a an Active display port adapter for my laptop.  That won't
even work with resolutions above 1280x1024 under Debian (works fine up
to native 1980x1080 res on Windows 7).

I wanted to use one of my monitors in portrait mode but the the
rotation would not work if I had Option NoAccel true.  Of course
disabling it meant I get the hideous screen corruption.

All of this works fine on Windows 7 with DVI/VGA or Display Port so at
least I can confirm it's not a hardware limitation.

I am quite bummed to have this problem.  Can anyone suggest ways in
which I can troubleshoot/resolve it?

Thanks


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camaloy_qnu3_kwn9gc9jrw+koqjvzpreocnvdjt4zsgxe+t...@mail.gmail.com

apitrace in Debian

[Christopher James Halse Rogers]

Hey all,

I've wrangled apitrace back into a pretty-much acceptable form in alioth
git¹. The main remaining query is (1) manpages (urgh), and (2)
statically linked zlib, png, snappy.

For (2), the wrapper libraries probably should use the statically linked
libs, as they'll be interposed in to arbitrary executables and won't
want to have possibly-conflicting versions. Which means fixing the UI
tools to link against the system libraries.

It all works, and the tracing wrappers (glxtrace.so and egltrace.so) are
multiarched and the correct architecture is automatically loaded. Which
is nice.

I'm looking for a once-over review at this point, so I can happily bug
Timo to upload when I've fixed the static linking.

Chris


signature.asc
Description: This is a digitally signed message part

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

Update...  Setting option

Option NoAccel true

Has fixed the problem.  I haven't noticed any problems having this
enabled in the way I use my computer, videos, glxgears etc. all work
ok.

So I suppose this bug report can be closed if desired.

The only other option I was going to try was using a Display port to
DVI adapter from the side of my laptop to replace the VGA from the
docking station.  If I purchase one to  try that I'll let you know.

Regards,

James


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camaloy8cowo8foupomgxl0px1oj2hfwq6hla61ml_qpsztm...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

On 2 August 2012 20:31, Michel Dänzer daen...@debian.org wrote:
 Thanks. That's not what we generally call 'tearing' but looks like some
 kind of intermittent display corruption.

 Unfortunately, I don't have any ideas offhand what could cause that.

I did some more testing and it seems as though the monitor,
combination of identical monitor models or VGA port on the monitors
might be the issue.

The monitors I am using are identical AOC's.  Product Name:
e2250Swda, Model No:  215LM00019.  I had a older spare Benq monitor
E2200HD with native resolution of 1920x1080 and swapped it with the
VGA connected AOC.  Everything worked fine on both displays with
1920x1080 without disabling EXAPixmaps!
I then swapped it around so AOC on VGA and Benq on DVI and the
corruption came back.  I also swapped out the AOC's in case the issue
was with one of them but same problem on both.

Previously even if I disabled the VGA port with the AOC attached to
it, the AOC on the DVI port would still get display corruption.  With
the Benq connected to VGA but disabled no corruption occurs on (either
of) the DVI connected AOC.

I have attached an xrandr --verbose for both combinations in case it
shows something useful.  I couldn't see anything that might explain
why sorry.

Thanks again.

James
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192
DVI-0 connected 1920x1080+0+0 (0x55) normal (normal left inverted right x axis 
y axis) 477mm x 268mm
Identifier: 0x51
Timestamp:  324965
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000009d10c794554
27120103802f1a782e3585a656489a24
125054a56bba710081408100950f8180
9500b3000101023a801871382d40582c
4500dd0c111e00ff004e3938
30343134373032360a2000fd0032
4c1e5e15000a20202020202000fc
0042656e5120453232303048440a0042
load detection: 1 (0x0001)  range:  (0,1)
underscan vborder: 0 (0x)   range:  (0,128)
underscan hborder: 0 (0x)   range:  (0,128)
underscan:  off
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
  1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   67.5KHz
v: height 1080 start 1084 end 1089 total 1125   clock   60.0Hz
  1680x1050 (0x56)  146.2MHz -HSync +VSync
h: width  1680 start 1784 end 1960 total 2240 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
  1280x1024 (0x57)  135.0MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock   80.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   75.0Hz
  1280x1024 (0x58)  108.0MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock   64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   60.0Hz
  1440x900 (0x59)  136.8MHz -HSync +VSync
h: width  1440 start 1536 end 1688 total 1936 skew0 clock   70.6KHz
v: height  900 start  903 end  909 total  942   clock   75.0Hz
  1440x900 (0x5a)  106.5MHz -HSync +VSync
h: width  1440 start 1520 end 1672 total 1904 skew0 clock   55.9KHz
v: height  900 start  903 end  909 total  934   clock   59.9Hz
  1280x960 (0x5b)  108.0MHz +HSync +VSync
h: width  1280 start 1376 end 1488 total 1800 skew0 clock   60.0KHz
v: height  960 start  961 end  964 total 1000   clock   60.0Hz
  1280x800 (0x5c)   83.5MHz +HSync -VSync
h: width  1280 start 1352 end 1480 total 1680 skew0 clock   49.7KHz
v: height  800 start  803 end  809 total  831   clock   59.8Hz
  1152x864 (0x5d)  108.0MHz +HSync +VSync
h: width  1152 start 1216 end 1344 total 1600 skew0 clock   67.5KHz
v: height  864 start  865 end  868 total  900   clock   75.0Hz
  1152x720 (0x5e)   67.3MHz -HSync +VSync
h: width  1152 start 1208 end 1328 total 1504 skew0 clock   44.7KHz
v: height  720 start  721 end  724 total  746   clock   60.0Hz
  1024x768 (0x5f)   78.8MHz +HSync +VSync
h: width  1024 start 1040 end 1136 total 1312 skew0 clock   60.1KHz
v: height  768 start  769 end  772 total  800   clock   75.1Hz
  1024x768 (0x60)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

On 22 July 2012 13:20, James Robertson j...@mesrobertson.com wrote:
 On 21 July 2012 03:45, Michel Dänzer daen...@debian.org wrote:

 Can you elaborate on what exactly 'tearing and corruption' means?

 I have created a brief video to show the tearing.  It occurs when
 basically any input occurs such as typing, moving the mouse and as per
 the video moving windows.

 https://docs.google.com/open?id=0B2vLcjUrgXL-aUdWekU0dE9qbHM

 Does booting with radeon.disp_priority=2 on the kernel command line
 help?

 No

 Please provide the output of xrandr --verbose for each case

 Please see attached txt file.

 On 21 July 2012 04:33, Alex Deucher alexdeuc...@gmail.com wrote:
 Also note that rendering can only be synchronized to one head at a
 time to avoid tearing.  If you have windows that span multiple heads,
 you may get tearing on the non-synced heads.

 I don't fully understand the technical side of what you have described
 but wouldn't this mean tearing should only occur when using multiple
 monitors?  I get tearing on DVI-0 or VGA-0 standalone.

 I would also note that the tearing is worse when using both DVI-0 and
 VGA-0 together.  I also physically removed DVI-0 and visa versa for
 VGA-0 and still had the problem.

 Thanks

Whilst watching a flash video in Chromium this evening, I scrolled
down the web page and noticed the tearing even when I had EXAPixmaps
off.  The tearing was not as severe, but nonetheless occurred.

As a quick test I tried setting the VGA-0 Display to 1680x1050 (DVI-0
still at 1920x1080) and it was fine.  Using just DVI-0 standalone
@1920x1080 also had tearing.

Thanks


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMALoy_2OT00eyb+mjqMGCNQ=KnTZzb8M=napxitducp8tn...@mail.gmail.com

Bug#581398: kde4-window-decorator crash when starting

[James]

Still broken after all these years.

 Application: KDE Window Decorator (kde4-window-decorator), signal: 
Segmentation fault
 Using host libthread_db library 
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
 [KCrash Handler]
 #6  0xb6e7579b in QRasterWindowSurface::~QRasterWindowSurface (this=0x9759860, 
__in_chrg=optimized out) at
 painting/qwindowsurface_raster.cpp:117
 #7  0xb6e75832 in QRasterWindowSurface::~QRasterWindowSurface (this=0x9759860, 
__in_chrg=optimized out) at
 painting/qwindowsurface_raster.cpp:121
 #8  0xb6e90ce4 in QWidgetBackingStore::~QWidgetBackingStore (this=0x976be40, 
__in_chrg=optimized out) at
 painting/qbackingstore.cpp:909
 #9  0xb6c99fbc in QWidgetBackingStoreTracker::destroy (this=0x9779660) at 
kernel/qwidget.cpp:217
 #10 0xb6c9a118 in QWidgetPrivate::deleteExtra (this=0x96d57a8) at 
kernel/qwidget.cpp:1830
 #11 0xb6c9a32c in QWidgetPrivate::~QWidgetPrivate (this=0x96d57a8, 
__in_chrg=optimized out) at kernel/qwidget.cpp:357
 #12 0xb6c9a642 in QWidgetPrivate::~QWidgetPrivate (this=0x96d57a8, 
__in_chrg=optimized out) at kernel/qwidget.cpp:362
 #13 0xb68ef0cb in cleanup (pointer=optimized out) at 
../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:62
 #14 ~QScopedPointer (this=0x96247ec, __in_chrg=optimized out) at
 ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:100
 #15 QObject::~QObject (this=0x96247e8, __in_chrg=optimized out) at 
kernel/qobject.cpp:817
 #16 0xb6c9c50d in QWidget::~QWidget (this=0x96247e8, __in_chrg=optimized 
out) at kernel/qwidget.cpp:1551
 #17 0xb5e2dc0a in ?? () from /usr/lib/libplasma.so.3
 #18 0xb5e94c4b in ?? () from /usr/lib/libplasma.so.3
 #19 0xb5e936cb in Plasma::Theme::~Theme() () from /usr/lib/libplasma.so.3
 #20 0xb5e93a89 in ?? () from /usr/lib/libplasma.so.3
 #21 0xb5da19e9 in ?? () from /usr/lib/libplasma.so.3
 #22 0xb5a9c50f in __run_exit_handlers (status=0, listp=0xb5bc6324, 
run_list_atexit=true) at exit.c:78
 #23 0xb5a9c57f in *__GI_exit (status=0) at exit.c:100
 #24 0xb5a83e4e in __libc_start_main (main=0x804fe30, argc=2, 
ubp_av=0xbfc2ad44, init=0x8064550, fini=0x8064540,
 rtld_fini=0xb77f0300, stack_end=0xbfc2ad3c) at libc-start.c:260
 #25 0x08050ab5 in ?? ()


The latest stable release of Compiz is 0.8.8, while the current debian
version is 0.8.4-5.1, so I don't know how much sympathy there would be from
the Compiz people.

Anyone know how it is that debian _unstable_ is a couple of years and four
minor releases behind upstream?


Is this ultimately a bug in the Qt libraries?

There is also idle curiosity here,

 http://forums.debian.net/viewtopic.php?f=6t=73980
 KDE + compiz crashes kde4 window decorator


 http://ubuntuforums.org/showthread.php?t=1475164
 KDE4 Window Decorator Crashes with Compiz in Lucid Lynx 10.04
This is a thread to discuss Bug #572780


 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/572780
 KDE4 Window Decorator Crashes with Compiz in Lucid Lynx 10.04



James




-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1swtzw-00068j...@jasper.nurealm.net

Bug#581398: kde4-window-decorator crash when starting

[James]

 Because nobody has shown any interest in working on it? Are you
 volunteering?

Ha!  Can you give me a clue about what would be involved?  I would naively
suppose that all I have to do is download the latest release, add a debian/
directory, and compile the application for a bunch of different architectures
- not counting also needing a login on some debian server, to upload the
packages.  But then, I also suspect that it's not that simple.  Still, one
step at a time.  What's to do?


James




-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1swxuu-0007bn...@jasper.nurealm.net

Bug#641197: patch submitted

[James Robertson]

It appears as though a patch has been submitted for this.

http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bcdd461b1f6cc64370793f52d7c170187d0



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMALoy_2HyEoV=6iK=1f9eJ8EZ6oBTEzH=3uks6zrdwxgdq...@mail.gmail.com

Bug#641197: libxft2: Include Ubuntu LCD filter patch

[James Robertson]

Package: libxft2
Version: 2.2.0-3
Severity: wishlist

Dear Maintainer,

xft does not utilise the lcdfilter option.  An example is when using
Openbox and GTK2 based apps with the following configuration in
~/fonts.conf.

 match target=font
   edit mode=assign name=lcdfilter
   constlcddefault/const
   /edit
 /match

The result is that the fonts rendered by Openbox look slightly different to 
those rendered by GTK2.

I researched and found that Ubuntu had added a patch in the following version 
that utilises lcdfilter:

http://archive.ubuntu.com/ubuntu/pool/main/x/xft/xft_2.1.14-2ubuntu1.diff.gz

I tested the patch on 2.2.0-3 and it has worked well and my Window Manager 
fonts now look the same as GTK2.
Attached is the patch (100-libXft-2.1.10-lcd-filter-3.patch)

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libxft2 depends on:
ii  libc6  2.13-20  
ii  libfontconfig1 2.8.0-3  
ii  libfreetype6   2.4.6-2  
ii  libx11-6   2:1.4.4-1
ii  libxrender11:0.9.6-2
ii  multiarch-support  2.13-20  

libxft2 recommends no packages.

libxft2 suggests no packages.

-- no debconf information
--- a/src/xftdpy.c
+++ b/src/xftdpy.c
@@ -369,6 +369,10 @@
 	goto bail1;
 if (!_XftDefaultInitInteger (dpy, pat, FC_RGBA))
 	goto bail1;
+#ifdef FC_LCD_FILTER
+if (!_XftDefaultInitInteger (dpy, pat, FC_LCD_FILTER))
+	goto bail1;
+#endif
 if (!_XftDefaultInitBool (dpy, pat, FC_ANTIALIAS))
 	goto bail1;
 #ifdef FC_EMBOLDEN
@@ -521,6 +525,14 @@
 			  XftDefaultGetInteger (dpy, FC_RGBA, screen, 
 		subpixel));
 }
+#ifdef FC_LCD_FILTER
+if (FcPatternGet (pattern, FC_LCD_FILTER, 0, v) == FcResultNoMatch)
+{
+	FcPatternAddInteger (pattern, FC_LCD_FILTER,
+			 XftDefaultGetInteger (dpy, FC_LCD_FILTER, screen,
+		   FC_LCD_DEFAULT));
+}
+#endif
 if (FcPatternGet (pattern, FC_MINSPACE, 0, v) == FcResultNoMatch)
 {
 	FcPatternAddBool (pattern, FC_MINSPACE,
--- a/src/xftfreetype.c
+++ b/src/xftfreetype.c
@@ -469,6 +469,21 @@
 	goto bail1;
 }
 
+#ifdef FC_LCD_FILTER 
+/*
+ * Get lcd_filter value
+ */
+switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, fi-lcd_filter)) {
+case FcResultNoMatch:
+	fi-lcd_filter = FC_LCD_DEFAULT;
+	break;
+case FcResultMatch:
+	break;
+default:
+	goto bail1;
+}
+#endif
+
 /*
  * Get matrix and transform values
  */
--- a/src/xftglyphs.c
+++ b/src/xftglyphs.c
@@ -21,27 +21,18 @@
  */
 
 #include xftint.h
-#include freetype/ftoutln.h
 
 #if HAVE_FT_GLYPHSLOT_EMBOLDEN
 #include freetype/ftsynth.h
 #endif
 
-static const intfilters[3][3] = {
-/* red */
-#if 0
-{65538*4/7,65538*2/7,65538*1/7 },
-/* green */
-{65536*1/4, 65536*2/4, 65537*1/4 },
-/* blue */
-{65538*1/7,65538*2/7,65538*4/7 },
+#if FREETYPE_MAJOR*1 + FREETYPE_MINOR*100 + FREETYPE_PATCH  20202
+#  error  FreeType 2.2.2 or later required to compile this version of libXft
 #endif
-{65538*9/13,65538*3/13,65538*1/13 },
-/* green */
-{65538*1/6, 65538*4/6, 65538*1/6 },
-/* blue */
-{65538*1/13,65538*3/13,65538*9/13 },
-};
+
+#include FT_OUTLINE_H
+#include FT_LCD_FILTER_H
+#include FT_SYNTHESIS_H
 
 /*
  * Validate the memory info for a font
@@ -69,6 +60,295 @@
 		font-glyph_memory, glyph_memory);
 }
 
+
+/* we sometimes need to convert the glyph bitmap in a FT_GlyphSlot
+ * into a different format. For example, we want to convert a
+ * FT_PIXEL_MODE_LCD or FT_PIXEL_MODE_LCD_V bitmap into a 32-bit
+ * ARGB or ABGR bitmap.
+ *
+ * this function prepares a target descriptor for this operation.
+ *
+ * input :: target bitmap descriptor. The function will set its
+ *  'width', 'rows' and 'pitch' fields, and only these
+ *
+ * slot  :: the glyph slot containing the source bitmap. this
+ *  function assumes that slot-format == FT_GLYPH_FORMAT_BITMAP
+ *
+ * mode  :: the requested final rendering mode. supported values are
+ *  MONO, NORMAL (i.e. gray), LCD and LCD_V
+ *
+ * the function returns the size in bytes of the corresponding buffer,
+ * it's up to the caller to allocate the corresponding memory block
+ * before calling _fill_xrender_bitmap
+ *
+ * it also returns -1 in case of error (e.g. incompatible arguments,
+ * like trying to convert a gray bitmap into a monochrome one)
+ */
+static int
+_compute_xrender_bitmap_size( FT_Bitmap*  target,
+  FT_GlyphSlotslot,
+  FT_Render_Mode  mode )
+{
+FT_Bitmap*  ftbit;
+int width, height, pitch;
+
+if ( slot-format != FT_GLYPH_FORMAT_BITMAP )
+return -1;
+
+// compute the size of the final bitmap
+ftbit  = slot-bitmap;
+
+width  = ftbit-width;
+   

Bug#635251: any news on multi-arch for libpciaccess?

[Christopher James Halse Rogers]

On Wed, 2011-08-24 at 11:54 +0300, Riku Voipio wrote:
 On Wed, Aug 24, 2011 at 09:51:08AM +0200, Julien Cristau wrote:
  On Wed, Aug 24, 2011 at 10:27:56 +0300, Riku Voipio wrote:
   Any updates here? As a udev reverse dependency this is quite important
   for earlt multi-arch conversion.
 
  It'll probably happen on the next upload, but I'm not going to rush
  that.  (What does this have to do with udev?)
 
 Looks like an ubuntuisim. needed inderectly for animated startup graphics,
 sigh. No hurry on debian side then it seems.

libdrm-intel now depends on libpciaccess, plymouth depends on
libdrm-intel, and so on.

The -dev package shouldn't be marked as multiarch; the i386 package is
not parallel installable with the amd64 package as they both
ship /usr/include.  In general, my understanding is that -dev packages
should not be multiarched (yet).

I should apparently also read Debian bug reports more often.  I'd just
pushed a dh7 cleanup branch which also adds multiarch to the
debian-experimental git branch before reading this mail.



signature.asc
Description: This is a digitally signed message part

Bug#635251: any news on multi-arch for libpciaccess?

[Christopher James Halse Rogers]

On Mon, 2011-08-29 at 16:38 +0300, Riku Voipio wrote:
 On Mon, Aug 29, 2011 at 05:48:44PM +1000, Christopher James Halse Rogers 
 wrote:
  The -dev package shouldn't be marked as multiarch; the i386 package is
  not parallel installable with the amd64 package as they both
  ship /usr/include.  In general, my understanding is that -dev packages
  should not be multiarched (yet).
 
 It is ok to incude same files in multiarch coinstallable packages, as long as
 they are identical on all archictectures. Think 
 /usr/share/doc/libpciaccess0/copyright
 for example. Hence all -dev packages where headers are same on all 
 architectures
 are safe for multiarch.

Yeah.  I was confused by the documentation on
wiki.debian.org/MultiArch/Implementation which said policy forbids -dev
packages from being marked as Multi-Arch: same.  As you say, that only
applies where the contents of headers change across architectures.  I've
updated that documentation to hopefully be clearer.



signature.asc
Description: This is a digitally signed message part

Re: libpciaccess: Changes to 'dhify+multiarch'

[Christopher James Halse Rogers]

On Mon, 2011-08-08 at 06:10 +, Christopher Halse Rogers wrote:
 New branch 'dhify+multiarch' available with the following commits:
 commit 8d5d28a71feb352574a22598487ef47ba7906ebf
 Author: Christopher James Halse Rogers r...@ubuntu.com
 Date:   Mon Aug 8 15:40:09 2011 +1000
 
 Switch to compat 9 for easy multiarch
 
 commit 0b100bef8fccb4ce362f6b1a29c2789b775c41a0
 Author: Christopher James Halse Rogers r...@ubuntu.com
 Date:   Mon Aug 8 15:38:23 2011 +1000
 
 Bump standards version; no changes needed
 
 commit d7c5c5d8f6e11a2930518a80a76ec12645d4572d
 Author: Christopher James Halse Rogers r...@ubuntu.com
 Date:   Mon Aug 8 13:15:54 2011 +1000
 
 Switch to dh and compat 7.
 
 Also kill the *.la files, and dh_install --fail-missing.
 

Does anyone have any objections to me merging this into either sid or
experimental (depending on preference)?  It's now required for libdrm
multiarch, and hence for mesa multiarch, and I'd really, really like to
not be dependent on ia32-libs for mesa.


signature.asc
Description: This is a digitally signed message part

Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

[Christopher James Halse Rogers]

On Fri, 2011-07-22 at 21:12 +0200, Cyril Brulebois wrote:
 Julien Cristau jcris...@debian.org (22/07/2011):
  So in principle I dislike the idea of making the mesa packages messier
  to make the closed driver packages' life easier.  One thing that's been
  a source of countless bug in the current system is diversions, because
  they're evil, and people keep getting them wrong, and users don't
  understand/expect them, and all kinds of fun ensues.  If mesa were to
  not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but
  instead ship an alternative itself, would that be enough to put an end
  to the diversions?  Not that I think alternatives are ideal either, but
  if we're going to have to put up with something I'd rather it wasn't
  *both* alternatives and diversions.
  
  Not sure what other X people think.
 
 I'd rather avoid the mess of diversions *AND* alternatives indeed. If
 adding alternative support to mesa is the price to pay, I guess we could
 work something out.
 
 Please note I'm very busy right now, consequently far behind on anything
 X-related; sorry for that.
 

In Ubuntu we use an alternatives system for switching between libGL
(and, soon, libEGL) implementations.  We indeed had endless troubles
with the diversions we used to have; the alternatives system seems to
have been significantly less trouble.

We ship the GL implementations in a private directory and use a
ld.so.conf snippet hung off the $DEB_HOST_MULTIARCH_GL_conf alternative
to add that directory to the library search path.

The proprietary drivers hang a bunch of other stuff off that
alternative, too: modprobe blacklists to prevent nouveau/radeon loading,
their annoyingly special libglx xorg modules, that sort of thing.  Based
on my informal impressions, I think this single-switch approach has
resulted in fewer bugs where users are using a broken mix of
proprietary/open pieces of the stack.  Bryce would probably have better
metrics on that.

If it's desired I'd be very happy to add the equivalent to the Debian
mesa packages, since it'd significantly reduce the Ubuntu changes we're
carrying.


signature.asc
Description: This is a digitally signed message part

Re: handling proprietary vendor libs for OpenGL ES [Was: implement gles-alternatives like glx-alternatives]

[Christopher James Halse Rogers]

On Mon, 2011-07-18 at 13:50 +0200, Heiko Stübner wrote:
 Hi,
 
 short summary for debian-x:
 It seems that also on embedded systems vendors start shipping proprietary 
 graphics drivers and OpenGL ES implementations like NVidia and AMD do for x86.
 Therefore I talked to Andreas on what would be the best way to implement a 
 functionality like glx-alternatives for the OpenGL ES libs.
 
 Driver candidates I know off are:
 - NVidia Tegra (http://tegradeveloper.nvidia.com/tegra/forum/linux-tegra-
 release-12-alpha-1-released)
 - Omap4 (http://launchpad.net/~tiomap-dev)
 - Omap3
 and probably more.
 
 
 Am Montag, 18. Juli 2011, 01:44:09 schrieb Andreas Beckmann:
  On 2011-07-16 22:26, Heiko Stübner wrote:
   Hi,
   
   glx-alternatives provides the means to have more than one libGL and glx
   implementation on a machine.
   
   I'm working on the Toshiba AC100 (NVidia Tegra ARM SoC) which also got a
   proprietary driver released two weeks ago [1].
   
   Tegra, like Omap, and probably other SoCs support only OpenGL ES (1 and
   2) wich is also provided by Mesa libs.
   
   So I was wondering what would be the best way to realise a diversion
   system like glx-alternatives for the OpenGL ES stuff.
  
  I think we should include the MESA packagers to see how they intended to
  make glx/gles and vendor implementations working together (I do know
  nothing about egl/gles).
  Please repost your question (and my comments below and eventual answers
  to them) including debian-x@lists.debian.org in the Cc:
   Possibilities I came up with were:
   - build a completely separate gles-alternatives source package realising
   the same functionality like glx-alternatives
  
  Is there any library (and diversion) overlap between glx and gles?
  yes - merge with glx-diversions
  no - separate packages (but eventually still the same source package
  for better code sharing)
 there seems to be no overlap library-wise between OpenGL and OpenGL ES (1 and 
 2)  for the ones vendors want to replace.
 Therefore my thoughts were on simply letting glx-alternatives also build 
 packages for handling OpenGL ES stuff (i.e. gles-diversions, gles-alternative-
 tegra, ... like the glx-* packages) but sharing the same source package for 
 the code sharing you mentioned.
 
 
   Libs that need to be diverted most of the time are libEGL.so.1,
   libGLESv1_CM.so.1 and libGLESv2.so.2 (at least for Tegra and Omap4[2] ).
  
  Is libEGL.so.1.0 (from package libegl1-mesa) a fixed filename or is it
  expected to be changed regularily? (libGL.so.1.2 from libgl1-mesa-glx is
  fixed, but libgl1-mesa-swx11 provides libGL.so.5.* which changes with
  each upstream version and is therefore not divertible).
  Same question for the other libraries.
 Hopefully one of the mesa-guys can answer this :-)
 
 Libraries in question are:
 - libGLESv1_CM.so.1.1.0
 - libGLESv2.so.2.0.0
 - libEGL.so.1.0

Filenames which *are* fixed are libGLESv1_CM.so.1, libGLESv2.so.2 and
libEGL.so.1, as those are the SONAMEs of the respective libraries.  I
wouldn't guarantee that the filenames listed above won't change (I'm
somewhat surprised it isn't libEGL.so.1.4, for example).

dpkg-divert should be happy to divert those symlinks, right?

Chris


signature.asc
Description: This is a digitally signed message part

Re: mesa: Changes to 'debian-experimental'

[Christopher James Halse Rogers]

On Tue, 2011-06-21 at 18:51 +0200, Cyril Brulebois wrote:
 Hi Michel,
 
 thanks for keeping an eye on the commits.
 
 Michel Dänzer daen...@debian.org (20/06/2011):
  This is wrong. r300g works fine without LLVM. The reason for the
  dependency is that without LLVM, Gallium's software vertex processing is
  very slow. But this only affects integrated GPUs without vertex shaders,
  which are only available for x86 CPUs.
 
 AFAICT, configure disagrees. But it's strange-ish anyway, so it might
 just need some targeted patching.
 
   commit 7d332507bbffa1fdb59723808ef39b9e50983e16
   Author: Cyril Brulebois k...@debian.org
   Date:   Sun Jun 19 15:37:18 2011 +0200
   
   Stop building i915g at all.
   
   It's apparently never going to be a suitable replacement for i915c.
  

It's also worth noting that even without shipping i915g_dri it might be
worth building i915g to get OpenVG support - egl_dri2 can load the
classic driver for GLES support, but only the gallium pipe drivers
support OpenVG.



signature.asc
Description: This is a digitally signed message part

Bug#612529: Upstream status

[Christopher James Halse Rogers]

The status of the Ubuntu patch upstream, as best I can remember it, is
that they think it's fixing the problem in the wrong place.  The libc
dynamic loader is meant to have some special magic set aside so that at
least some TLS code with the initial-exec class can be loaded, but this
clearly isn't working properly.

I started investigating this, then got busy with other things.


signature.asc
Description: This is a digitally signed message part

Bug#627367: xkb-data: Upgrade from 1.8 to 2.1 adds deadkeys to dvorak-intl

[Christopher James Halse Rogers]

Package: xkb-data
Version: 2.1-2
Severity: normal


In commit b611a52d8 upstream kindly renamed dvorak-intl (which did not have
dead keys) to dvorak-alt-intl.  dvorak-intl now has dead keys, so upgrades from
1.8 or earlier to 2.1 will switch the user's keyboard behaviour.

On upgrade from = 1.8 we should transition users from dvorak-intl to
dvorak-alt-intl.

See also https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/742683,
but I've verified this also affects Debian by upgrading an oldstable chroot to
wheezy.


-- System Information:
Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-8-generic (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110520035757.12275.89629.reportbug@Ed

Bug#622606: xserver-xorg-video-r128: [regression] [powerpc] X dies with SIGBUS if I tell it UseFBDev false

[James Tappin]

On Wed, 13 Apr 2011 08:08:00 -0300
Rogério Brito rbr...@ime.usp.br wrote:

RB X-Debbugs-CC: debian-powe...@lists.debian.org
RB Package: xserver-xorg-video-r128
RB Version: 6.8.1-5
RB Severity: important
RB 
RB Hi there.
RB 
RB This is a PowerPC (iBook G3), with a R128 video card and with a very
RB recent kernel (2.6.38), all from Debian, none compiled by me.
RB 
RB As per bug #484015 (see my comments there), I have to provide an
RB xorg.conf file or I get a completely screwed X.
RB 
RB When I use the file attached below by the bug script, I get a SIGBUS
RB when I tell the X server that I want to disable UseFBDev. This is a
RB regression of, at least, version 1:6.8.0-1 of the driver.
RB 
RB I am attaching the last log from X here. If any further information
RB is desired, please let me know.
RB 
RB 
RB Regards.

I've got a similar machine that I just resurrected to test for
endian-ness issues in a project I'm working on. I'm using the xorg.conf
that was recommened to me a couple of weeks ago:
http://mac.linux.be/content/xorgconf-ibook-g3-500-dual-usb-0

Changing UseFBDev to false with that configuration does not cause a
problem, though I think (I've not done any detailed comparison) that it
is a little slower (maybe 5%).

As for needing an xorg.conf -- I think that the problem is that the
screen does not send valid EDID information (presumably Apple were
cutting corners and built OSX to know the screen capability from the
machine's identity). IMHO -- Xorg needs to have a manual fallback that
asks for information if there is neither an xorg.conf nor valid EDID and
then creates an xorg.conf.

-- 
++---+-+
| James Tappin   | School of Physics  Astronomy |  O__|
| s...@star.sr.bham.ac.uk | University of Birmingham  | --  \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722  | |
++-+



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110415144950.6a31d131@star.sr.bham.ac.uk

Bug#576326: xserver-xorg: keys repeat without being held down

[James Cameron]

On Sat, Feb 26, 2011 at 12:53:30PM +0100, Cyril Brulebois wrote:
 is that still happening with squeeze or higher? If so, please follow
 up with more info:
   http://pkg-xorg.alioth.debian.org/howto/report-bugs.html

Thanks for following up.

The affected host is currently tracking wheezy, updated weekly, last
updated on Friday, and the symptom has not been seen for some months.
Currently on 1:7.5+8 of xserver-xorg.

On the other hand, having learned not to place the system under memory
pressure, it is possible my learning has prevented the symptom from
happening.

I've just done a test by creating a workload (three parallel builds and
an rsync of television transport stream), and was unable to reproduce
the symptom.

On that basis, assuming the other user no longer sees the problem, I
think the bug can be closed.

I'm interested to know if the problem was fixed though.  There's nothing
relevant in the changelog.gz for 1:7.5+6 onwards.  Perhaps kernel?  Was
2.6.30-2-686 now 2.6.32-5-686 .

-- 
James Cameron
http://quozl.linux.org.au/



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110227234406.gc4...@us.netrek.org

Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal

[James Zuelow]

Original Message
From: Cyril Brulebois [mailto:k...@debian.org]
Sent: Tuesday, February 22, 2011 2:31 PM
To: James Zuelow; 578...@bugs.debian.org
Subject: Re: Bug#578082: xserver-xorg-video-intel: xorg
freezes and locks keyboard/mouse when switching to a virtual terminal


 
 what's the status with squeeze? Or sid?
 
 KiBi.


I do not see this behaviour with Squeeze.

I'm not running any Sid machines to test, but I can set one up if need be.

I think this is resolved.

James


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4A09477D575C2C4B86497161427DD94C15C2C4B847@city-exchange07

Bug#556064: FTBFS with binutils-gold

[James Vega]

On Thu, Feb 10, 2011 at 1:41 PM, Julien Cristau jcris...@debian.org wrote:
 On Fri, Jan 15, 2010 at 21:55:24 -0500, James Vega wrote:

 reassign 556064 libxft-dev 2.1.12-3
 retitle 556064 fontconfig incorrectly listed as a private library
 thanks

 As shown below, the patch introduced in #389831 incorrectly moved
 fontconfig to Requires.private.  Thus, packages linking against Xft with
 --no-add-needed (or binutils-gold) FTBFS.  This can also be verified by
 seeing that many of the symbols defined by Xft are simply a #define of
 XftFoo to FcFoo.

 All those macros are in the XftCompat header though, which seems to
 imply that users should use the fontconfig names instead nowadays, and
 link to fontconfig themselves?
 A similar change is now upstream in libXft 2.2.0 fwiw:
 http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=8751e341bcc29952b4603e18767ab994653c6b01

I don't see any includes for XftCompat, only Xft.h, in the plt-scheme
code (well the wxxt code they were using) that was failing.
Regardless, plt-scheme (now racket) has removed the code that was
using this, so it doesn't affect me anymore.

Hmm, looking into it, Xft.h includes XftCompat.h unless
_XFT_NO_COMPAT_ is defined and portions of their API still directly
ask for (XftTextExtents*) and return (XftFontMatch) fontconfig types.
If the expectation is that Xft users shouldn't be using either the
XftCompat defines or XftFontMatch and as such don't need to link
against fontconfig, I'm fine with that but it should be called out in
the documentation and noted that doing so does require explicit
linking against fontconfig.  Instead, they're currently taking the
route of providing API compatibility but dropping the required
information to actually build with that compatibility, as I understand
it.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimuauyuinbyoiq-o0wdtwbaqc+tzsa9ku451...@mail.gmail.com

Re: Upcoming package updates

[Christopher James Halse Rogers]

On Wed, 2011-02-02 at 06:47 +0100, Cyril Brulebois wrote:
 Hi folks,
 
 xsfbs was nice once upon a time, since it made it possible to handle
 several repetitive tasks:
  - patching/unpatching.
  - computing substitution variables.
  - generating maintainer scripts using macros.
 
 Now, during the last year, I've noticed the following:
  - a simple mistake in xsfbs (e.g. the dependency issue we have when
patching, leading to unnecessary rebuilds) has to be fixed once but
merged into each package. That's not really nice. And quilt makes
it easy to get patches applied/unapplied today, either through
quilt.mk or through dh --with quilt.
  - when updating the method used to compute substitution variables,
one has to merge it into all drivers, which is also not
nice. Shipping a script in xserver-xorg-dev (and consequently
bumping the build-dep on it) and calling it from drivers' rules
file is sufficient. Code duplication goes away. Hence the proposed
dh_xsf_substvars proposed on [1]. If that script needs tweaking,
it'll probably happen with a new major version, meaning we'd have
to bump the build-dep on xserver-xorg-dev anyway. Or we could just
handle this through binNMUs.
  - a really small number of drivers (didn't check other packages yet)
use maintainer scripts. We could probably replace xsfbs macros with
dpkg-maintscript-helper. Or keep xsfbs merged into those for a
while.
 
 Also, trying to lower the packaging noise, I'm quite tempted to just
 use dh, so that only non-trivial bits appear in debian/rules, see
 libxkbcommon's rules file for example [2].
 

I, too, like the way dh makes the interesting parts of the packaging
obvious by omitting all the non-interesting bits.  Also, unlike CDBS,
it's quite straightforward to make the interesting bits happen :).

 It would mostly boils down to something based on:
 | #!/usr/bin/make -f
 | 
 | %:
 | dh $@ --with autoreconf,quilt --builddirectory=build/
 
 I've pushed an update to -evdev to a personal repository on alioth
 [3,4] to show another example.
 
 If we want to refine it a little bit more, we could also ship an xsf
 sequence in xserver-xorg-dev. At the moment, it would just ensure
 dh_xsf_substvars gets called before dh_gencontrol. But it could also
 be used to run some other dh_xsf_* commands at some other places,
 should we ever need more xsf-specific stuff. The call would then
 become:
 | %:
 | dh $@ --with autoreconf,quilt,xsf --builddirectory=build/
 

I'm a fan of automating common tasks.  I think this might also be
helpful in getting the small, but annoying, number of drivers that
aren't maintained by the XSF to properly declare dependencies.

 Finally, I'm not sure we need to build out-of-tree. It's easy to
 clean, but I guess we could just fix clean targets if they break. As
 far as auto*-related files, they are taken care of by dh-autoreconf,
 so the debian clean target does its job properly. So I guess we could
 get rid of --builddirectory=build/ as well. Of course, building OOT is
 the way to go for the small amount of packages with several flavours.
 

I think that out-of-tree interacts poorly with ccache, but (a) that
could be PEBKAC, and (b) for the packages where ccache is interesting we
need to do out-of-tree builds anyway for the multiple flavours.

I'm therefore of no strong opinion on out-of-tree.

 
 References:
  1. http://pkg-xorg.alioth.debian.org/reference/dependencies.html
  2. 
 http://git.debian.org/?p=pkg-xorg/lib/libxkbcommon.git;a=blob;f=debian/rules
  3. http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git
  4. 
 http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git;a=blob;f=debian/rules;hb=debian-experimental
 
 
 Any drawback/objection for any of this? Summarizing:
  - kiss xsfbs good bye.
  - new dh_xsf_substvars in xserver-xorg-dev.
  - probable move to dpkg-maintscript-helper where needed.
  - switch to dh.
  - ship a dh sequence.
  - stop building OOT for single-flavoured packages.
 
 I might wait for the new upstream release (candidate?) of the server
 to upload a dh_xsf_substvars-enabled xserver-xorg-dev package, so that
 we can bump the build-dep in drivers to a new upstream release, rather
 than having to remember the debian-specific revision in which this
 command got introduced. (Preparing drivers in git should keep me busy
 already.)
 
 KiBi.




signature.asc
Description: This is a digitally signed message part

Re: mesa: Changes to 'debian-experimental'

[Christopher James Halse Rogers]

On Mon, 2011-01-24 at 17:40 +0100, Cyril Brulebois wrote:
 Christopher Halse Rogers raof-gu...@alioth.debian.org (24/01/2011):
   debian/changelog   |4 +++-
   debian/libopenvg1-mesa.symbols |   12 
   2 files changed, 15 insertions(+), 1 deletion(-)
 
 You know, you could have replied to my mail from yesterday [1] instead
 of duplicating work…
 
  1. http://lists.debian.org/debian-x/2011/01/msg00728.html

Sorry.  I didn't see that mail before starting work!



signature.asc
Description: This is a digitally signed message part

Re: Ubuntu plans for Natty release

[Christopher James Halse Rogers]

On Fri, 2010-11-26 at 08:44 +0100, Michel Dänzer wrote:
 On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers
 wrote: 
  On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote:
   On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers
   wrote: 
   
Can you see an easy solution which allows changes during X's runtime and
will handle UMS transparently?
   
   One possibility would be an r[36]00_dri.so wrapper which can pass
   through to the classic or Gallium drivers based on KMS vs. UMS and
   configuration via environment variables and/or configuration files. This
   might be appropriate for upstream as well.
   
  That sounds an awful lot like work :).
 
 I've thought of a simpler possible solution:
 
   * Fix the Gallium drivers to bail gracefully instead of crashing
 with UMS (this will need to happen anyway). 
   * Ship the classic and Gallium drivers in separate directories and
 set the libGL search path such that the two directories will be
 tried one after another.
 
 r300g would be in the first directory searched. With UMS, it would fail
 to initialize, and libGL would pick up r300 from the second directory.
 
 This solution would also allow overriding the default driver with
 $LIBGL_DRIVERS_PATH.
 
 I really hope you don't have to stick with your ugly X driver patch. :}
 

That sounds like a good plan.  Do you know off the top of your head how
much of this is already ready?


signature.asc
Description: This is a digitally signed message part

Re: Ubuntu plans for Natty release

[Christopher James Halse Rogers]

On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote:
 On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers
 wrote: 
  On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote:
   On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers
   wrote: 

1) Ship both the classic and gallium versions of r300  r600, and have
the DDX select between them based on kms support and an xorg.conf
setting (default to r300g, as that's the default upstream, and whichever
r600 driver ends up being default in 7.10).  This is not going to be
accepted upstream, but is, I think, a reasonable distro-patch to retain
UMS support for radeon while defaulting to the upstream-default driver.
   
   IMHO any solution which doesn't allow easily choosing between the 3D
   drivers during the X server's runtime (when KMS is enabled) isn't
   adequate.
  
  Certainly not adequate for driver development, 
 
 Actually, driver developers probably tend to have their own custom
 setups anyway.
 
  but is it necessary for end-users?  This would be necessary for
  allowing per-application overrides, but should we care about this?
 
 Probably not as long as the default 3D driver works (well enough), but
 e.g. for comparing between the 3D drivers it would be much more
 convenient and save nerves and time, also for bug triagers.
 
 
  Can you see an easy solution which allows changes during X's runtime and
  will handle UMS transparently?
 
 One possibility would be an r[36]00_dri.so wrapper which can pass
 through to the classic or Gallium drivers based on KMS vs. UMS and
 configuration via environment variables and/or configuration files. This
 might be appropriate for upstream as well.
 
That sounds an awful lot like work :).

Also, my understanding was that UMS / classic mesa would not be
particularly supported upstream.  If you'd welcome such a patch, maybe
that work is justified.

I was only expecting to carry this dual-stack UMS/KMS hack for one
release, maybe two, and then not caring at all about UMS after that.

 However, given that switching to UMS will require some kind of tweaking
 anyway, I'm not sure why the script / procedure for that couldn't just
 include appropriate update-alternatives calls.
 
The trick is getting all the users to see the same documentation :).


signature.asc
Description: This is a digitally signed message part

Re: Ubuntu plans for Natty release

[Christopher James Halse Rogers]

On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote:
 On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers
 wrote: 
  
  1) Ship both the classic and gallium versions of r300  r600, and have
  the DDX select between them based on kms support and an xorg.conf
  setting (default to r300g, as that's the default upstream, and whichever
  r600 driver ends up being default in 7.10).  This is not going to be
  accepted upstream, but is, I think, a reasonable distro-patch to retain
  UMS support for radeon while defaulting to the upstream-default driver.
 
 IMHO any solution which doesn't allow easily choosing between the 3D
 drivers during the X server's runtime (when KMS is enabled) isn't
 adequate.
 

Certainly not adequate for driver development, but is it necessary for
end-users?  This would be necessary for allowing per-application
overrides, but should we care about this?

Mainly I'm concerned with ensuring that users who turn off KMS get 3D.
I don't expect upstream to care or support this; focusing on kms/gallium
is a perfectly reasonable decision to make.  From our end though, if UMS
is *not too much effort* to keep going then it's both useful for
debugging (when UMS works  KMS doesn't) and allows people to have a
usable system while those bugs are being fixed.

Changing the DRI driver name when using UMS seems like the simplest
solution here, and once we're doing that it's close to no extra effort
to add an xorg.conf option for users to twiddle.

Can you see an easy solution which allows changes during X's runtime and
will handle UMS transparently?


signature.asc
Description: This is a digitally signed message part

Re: Ubuntu plans for Natty release

[Christopher James Halse Rogers]

On Wed, 2010-11-10 at 11:27 +0100, Cyril Brulebois wrote:
 Christopher James Halse Rogers christopher.halse.rog...@canonical.com 
 (10/11/2010):
  There are a couple of things in mesa that we'd like to do for Natty that
  could do with some coördination with Debian-X: […]
 
 Unfortunately I haven't played with mesa at all yet, so I can't
 comment for now. I guess I would prefer having your work kept in the
 ubuntu branches for now.
 

No problem.  I'll make sure it's easy to cherry-pick should you end up
wanting it.


signature.asc
Description: This is a digitally signed message part

Re: Ubuntu plans for Natty release

[Christopher James Halse Rogers]

On Wed, 2010-11-10 at 13:58 -0800, Eric Anholt wrote:
 On Wed, 10 Nov 2010 18:57:45 +1100, Christopher James Halse Rogers 
 christopher.halse.rog...@canonical.com wrote:
  Hey all.
  
  There are a couple of things in mesa that we'd like to do for Natty that
  could do with some coördination with Debian-X:
  
  1) Ship both the classic and gallium versions of r300  r600, and have
  the DDX select between them based on kms support and an xorg.conf
  setting (default to r300g, as that's the default upstream, and whichever
  r600 driver ends up being default in 7.10).  This is not going to be
  accepted upstream, but is, I think, a reasonable distro-patch to retain
  UMS support for radeon while defaulting to the upstream-default driver.
  
  2) As always, we need more space on the CDs.  The DRI drivers are both
  large (~44MB) and contain substantial quantities of common code.  Fedora
  at one point linked their DRI drivers with a shared libdricore¹, and I'm
  looking at doing something similar for the gallium drivers.  This shaves
  about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching
  the gallium drivers.
  
  Are either of these interesting to debian-x?  Should I be committing
  these changes to the debian branches, or keeping them Ubuntu-specific?
  
  Also,
  3) We'll possibly strip out all the less-used (ie: non-intel,
  non-radeon) DRI drivers into a separate package  add jockey hooks for
  users to install them if needed.  That's not going to be so interesting
  for Debian, though.
 
 I'd like to see libdricore patches pushed upstream as a build option if
 it's not too invasive.  Fedora dropped them because they got tired of
 porting them forward, but I think at the point where two+ distros and
 half the mesa developers want the patch in place, we should just shove
 it in.

Fair enough.  I'll see how upstream-friendly I can make them, then
submit them.


signature.asc
Description: This is a digitally signed message part

Ubuntu plans for Natty release

[Christopher James Halse Rogers]

Hey all.

There are a couple of things in mesa that we'd like to do for Natty that
could do with some coördination with Debian-X:

1) Ship both the classic and gallium versions of r300  r600, and have
the DDX select between them based on kms support and an xorg.conf
setting (default to r300g, as that's the default upstream, and whichever
r600 driver ends up being default in 7.10).  This is not going to be
accepted upstream, but is, I think, a reasonable distro-patch to retain
UMS support for radeon while defaulting to the upstream-default driver.

2) As always, we need more space on the CDs.  The DRI drivers are both
large (~44MB) and contain substantial quantities of common code.  Fedora
at one point linked their DRI drivers with a shared libdricore¹, and I'm
looking at doing something similar for the gallium drivers.  This shaves
about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching
the gallium drivers.

Are either of these interesting to debian-x?  Should I be committing
these changes to the debian branches, or keeping them Ubuntu-specific?

Also,
3) We'll possibly strip out all the less-used (ie: non-intel,
non-radeon) DRI drivers into a separate package  add jockey hooks for
users to install them if needed.  That's not going to be so interesting
for Debian, though.


¹:
http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=blob;f=mesa-7.1-link-shared.patch;h=592e2e2163e8e06a1607dcaa5608024dab196745;hb=HEAD
 


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1289375866.5263.4.ca...@ed

EGL/GLES virtual packages

[Christopher James Halse Rogers]

Hey all.

As I mentioned on #debian-x yesterday, we're going to get some
proprietary implementations of libEGL and libGLES and I think it would
be good if we had a set of virtual packages for them.

I therefore propose the following virtual packages:
libgles1
libgles2
libegl-x11

There was concern that there's not necessarily a well-defined meaning
for these packages.  Reading the Khronos implementors guide¹ it looks
like there's an official “strongly recommended” ABI defined for the GL|
ES APIs.  We could therefore define those virtual packages to provide
that Khronos ABI, which looks well-defined to me.

For EGL it is a little different - the ABI seems to be dependent on what
EGLNativeDisplayType is.  It looks like you need to initialise an
EGLDisplay from an EGLNativeDisplayType which you've constructed
yourself outside the EGL interface.  Thus, the EGL ABI is
backend-dependent, so we define a libegl-x11 virtual package for a
libEGL with EGLNative*Types using the Khronos-defined X11 types.

[1]:
http://www.khronos.org/registry/implementers_guide.html#uncontrolled


signature.asc
Description: This is a digitally signed message part

Bug#546741: Kernel patches

[Christopher James Halse Rogers]

The kernel patches on that upstream page were incorporated into the
mainline kernel around 2008.  They're no problem.

So an xf86-video-sis-imedia source package is feasible, although ugly.
Merging the 671/771 support into the freedesktop.org driver would
clearly be better, but… urgh that's a big diff.


signature.asc
Description: This is a digitally signed message part

Bug#583346: xserver-xorg-input-synaptics: TapButton1 configuration option not respected in xorg.conf

[James Andrewartha]

Hi,

I had this problem too, and worked out it was the GNOME mouse preferences. 
Touchpad/Enable mouse clicks with touchpad was disabled. There's also an 
option to enable two-finger and horizontal scrolling. 
http://who-t.blogspot.com/2010/06/incomplete-roundup-of-touchpad-features.html 
has a list of what features can be controlled from the GNOME GUI.

-- 
# TRS-80  trs80(a)ucc.gu.uwa.edu.au #/ Otherwise Bub here will do \
# UCC Wheel Member http://trs80.ucc.asn.au/ #|  what squirrels do best |
[ There's nobody getting rich writing  ]|  -- Collect and hide your   |
[  software that I know of -- Bill Gates, 1980 ]\  nuts. -- Acid Reflux #231 /



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1006191234590.26...@martello.ucc.gu.uwa.edu.au

Bug#586085: xserver-xorg-video-nouveau: segfault prevents X start

[James Cameron]

Package: xserver-xorg-video-nouveau
Version: 1:0.0.15+git20100329+7858345-4
Severity: important


After an apt-get dist-upgrade just now, X fails to start, a manual invokation 
of X from text console reveals this error:

Backtrace:
0: X (xorg_backtrace+0x3b) [0x80addcb]
1: X (0x8048000+0x5ab75) [0x80a2b75]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb78e040c]
3: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_ref+0x84) [0xb745e404]
4: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_new_tile+0xed) [0xb745e74d]
5: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_new+0x62) [0xb745e7c2]
6: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0xb746+0xc86a) [0xb746c86a]
7: X (AddScreen+0x198) [0x806db98]
8: X (InitOutput+0x820) [0x80b0b00]
9: X (0x8048000+0x1e73b) [0x806673b]
10: /lib/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb761bc76]
11: X (0x8048000+0x1e4e1) [0x80664e1]
Segmentation fault at address 0xc4



-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Feb  3  2009 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1725180 Jun  4 02:14 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 
15)

/etc/X11/xorg.conf does not exist.

Kernel version (/proc/version):
Linux version 2.6.32-5-686 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jun 1 04:59:47 UTC 2010

Xorg X server log files on system:
-rw-r--r-- 1 root root 50812 Dec 28  2007 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 21368 Jun 16 19:25 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32.14-dsa-ia32 i686 Debian
Current Operating System: Linux nestor 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 
UTC 2010 i686
Kernel command line: auto BOOT_IMAGE=normal ro 
root=UUID=486d9cc8-ec18-44ee-9e25-faeaf3ee5755 quiet
Build Date: 03 June 2010  04:08:50PM
xorg-server 2:1.7.7-2 (Julien Cristau jcris...@debian.org) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Wed Jun 16 19:25:33 2010
(==) Using system config directory /usr/share/X11/xorg.conf.d
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |--Screen Default Screen Section (0)
(**) |   |--Monitor default monitor
(==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
(==) ModulePath set to /usr/lib/xorg/modules
(II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
(II) Loader magic: 0x81eac60
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 6.0
X.Org XInput driver : 7.0
X.Org Server Extension : 2.0
(--) using VT number 7

(--) PCI:*(0:1:0:0) 10de:002c:10de:0072 nVidia Corporation NV6 [Vanta/Vanta LT] 
rev 21, Mem @ 0xf700/16777216, 0xfc00/33554432
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) LoadModule: extmod
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension SELinux
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: dbe
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: glx

Bug#586062: mesa-dri-experimental: Missing /usr/lib/dri/nouveau_vieux_dri.so

[Christopher James Halse Rogers]

nouveau_vieux_dri.so is the classic mesa driver for nv04-nv2x nVidia
chips.  It currently doesn't build against the libdrm in experimental.

It appears to be more usable in mesa git master.  I plan to add it when
we start packaging from the mesa 7.9 branch.


signature.asc
Description: This is a digitally signed message part

Bug#586085: xserver-xorg-video-nouveau: segfault prevents X start

[James Cameron]

On Wed, Jun 16, 2010 at 01:09:54PM +0200, Sven Joachim wrote:
 This is the same segfault as in #579425, fixed in libdrm git.  Could
 somebody please upload libdrm 2.4.18-6 to fix that problem?

I've downloaded libdrm 2.4.18-6 and built it locally, and it does indeed
fix this bug.  Thanks!

-- 
James Cameron
http://quozl.linux.org.au/



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100616203120.gb6...@us.netrek.org

Bug#585618: mesa: FTBFS on kfreebsd and hurd (gallium/auxiliary: os/os_time.c:51:4: error: #error Unsupported OS

[Christopher James Halse Rogers]

On Sat, 2010-06-12 at 13:59 +0200, Julien Cristau wrote:
 Package: mesa
 Version: 7.8.1-2
 Severity: serious
 
 mesa in experimental ftbfs on kfreebsd and hurd:
 https://buildd.debian.org/pkg.cgi?pkg=mesamaint=dist=experimental
 
 gcc -c -I. -I../../../src/gallium/include
 -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers  -Wall
 -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
 -fvisibility=hidden -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE
 -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING
 -DHAVE_ALIAS -D__STDC_CONSTANT_MACROS os/os_time.c -o os/os_time.o
 os/os_time.c:51:4: error: #error Unsupported OS
 os/os_time.c: In function 'os_time_get':
 os/os_time.c:93: warning: control reaches end of non-void function
 make[4]: *** [os/os_time.o] Error 1
 
 Would be nice if porters could take a look.  Otherwise we can disable
 gallium there (I thought we already did, but apparently not).

We only build the DRI drivers on Linux but we do build gallium swrast
everywhere.



signature.asc
Description: This is a digitally signed message part

Bug#585651: nouveau: Fails to use same resolution than console

[Christopher James Halse Rogers]

This probably is due to your high resolution and low video memory - a
1900x1200 truecolour framebuffer takes up slightly more than half your
VRAM.



signature.asc
Description: This is a digitally signed message part

Ubuntu X plans for the next release

[Christopher James Halse Rogers]

Hi all,

I understand that it Bryce's habit to give the Debian XSF a heads up on
the plans that Ubuntu have for the X stack each release.  As Bryce is
off hacking on Launchpad this release, I'll be responsible for X this
cycle.  So here's my attempt at a “heads up” email!

I'd like to ensure that we don't unnecessarily duplicate work.  I get
the impression that Squeeze will be freezing sometime relatively soon,
so I'd guess that you don't want these mesa and X versions in Sid, but
would experimental be appropriate?  I've had good experiences in the
past with the Debian-mono team, and while X is a bit more tied to
platform specifics I'd like to get as much as possible done in Debian.

I can easily test-build against Debian and do some limited testing, and
encourage others to do so, but that might not be sufficient.  If that
isn't regarded as sufficient then we can try and ensure our changes are
easily merged with git.  I've somewhat been watching on the sidelines
before now - what would you find most helpful?

So, without further ado, here's what we're aiming for in the next Ubuntu
release:

* Planned versions:

We aim for xserver 1.9 and mesa 7.9.  These are fairly aggressive
targets, and we'll want to track git and pre-releases quite closely.  

We'll be on a 2.6.35 kernel, so we'll have the new 0.0.16 nouveau ABI
which will be reflected in our libdrm packages.

For intel, we're looking at 2.11 or potentially 2.12.

* Packaging changes:

In support of our ARM friends we'd like to package mesa's GLES support.
It looks like this would be split into a libegl1-mesa containing the
library and a libegl1-mesa-drivers containing the dri, dri2 and glx
drivers.

I'd like to ship nouveau's mesa component in a separate
libgl1-mesa-experimental package.  Considering upstream's “no 3D
support!” policy I've had relatively good experiences with these drivers
myself, but I think we want them to be opt-in.  

Additionally, I understand that the r300g gallium driver is maturing
rapidly, and there's a chance that it'll be the recommended 3D driver
for mesa 7.9.  If not, I think this would also be a good candidate for a
libgl1-mesa-experimental package.

Any comments, queries, complaints?  What are the feelings for how we
should collaborate most effectively?


signature.asc
Description: This is a digitally signed message part

Re: Ubuntu X plans for the next release

[Christopher James Halse Rogers]

On Thu, 2010-05-20 at 11:19 +0200, Michel Dänzer wrote:
 On Don, 2010-05-20 at 17:53 +1000, Christopher James Halse Rogers
 wrote: 
  
  In support of our ARM friends we'd like to package mesa's GLES support.
 
 Cool, though can you elaborate how exactly this will help them?
 

From what I gathered at UDS, ARM hardware tends to have only EGL/GLES
support.  We want to have Unity, based on clutter, available on ARM
hardware, so we need to build the egl clutter backend, so we need an egl
library.  Even better if we can also test these on regular desktop
systems.

So what we *need* is EGL to build the clutter backend.  Having ES
drivers to actually test on desktop hardware would be nice, too.

  It looks like this would be split into a libegl1-mesa containing the
  library and a libegl1-mesa-drivers containing the dri, dri2 and glx
  drivers.
 
 Note that EGL and GLES are different beasts - similar to GLX vs. OpenGL,
 but there are actually separate EGL and GLES libraries.
 

Right.  As I understand it, EGL is basically the windowing-system
integration bit, covering what in OpenGL would be glx, wgl, and whatever
Apple's got (agl?).  GLES is the actual rendering API which was at one
point kinda-sorta a subset of GL, but is now kinda-sorta a parallel API.

 BTW, are you talking about the Gallium or non-Gallium EGL stacks, or
 both?
 
Whichever works best, really.  I haven't played around enough to make
and informed decision here yet.  Plausibly both.

 
  Additionally, I understand that the r300g gallium driver is maturing
  rapidly, and there's a chance that it'll be the recommended 3D driver
  for mesa 7.9.  If not, I think this would also be a good candidate for a
  libgl1-mesa-experimental package.
 
 Sounds good. It might also be nice to provide other Gallium options,
 e.g. llvmpipe powered swrastg_dri.so / libgl1-mesa-swx11 or OpenVG.

There's a bunch of interesting stuff there.  I'm sure either I, or one
of our intrepid contributors, would love to enable all the shiny.

OpenVG at least seems safe to enable, and possibly g3dvl, too, although
that's less interesting as (a) no one really cares about accelerating
MPEG2 and (b) only nouveau has the hardware glue.


signature.asc
Description: This is a digitally signed message part

Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal

[James Zuelow]

Package: xserver-xorg-video-intel
Version: 2:2.9.1-3
Severity: normal

When I switch from the X session on VT7 to another virtual terminal, X
will lock up and the keyboard and mouse are unresponsive.

The rest of the machine is operating normally and I can ssh in, but I
cannot restart the X daemon or kdm.  I usually reboot.

While the system is in this locked state, Xorg.0.log gets filled up with
these lines, several times a second:

(II) AIGLX: Suspending AIGLX clients for VT switch

Xorg.0.log gets quite large quite fast when this happens.

I have a tarball of the Xorg.0.log file from the last time this happened
-- however the tarball is 9.2MB.  Please let me know if you want it (and
how to attach to a bug report).  The system was only locked for a few
minutes, but the uncompressed Xorg.0.log file is 5.2GB.

Thanks!

-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Oct 28  2008 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1876992 Apr  5 06:37 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
Graphics Controller (rev 02)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 1212 Mar  2 11:45 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type man xorg.conf at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  XkbRules  xorg
Option  XkbModel  pc104
Option  XkbLayout us
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
EndSection

Section Device
Identifier  Configured Video Device
Driver  intel
EndSection

Section Monitor
Identifier  VGA
Option  DPMS  true
EndSection

Section Monitor
Identifier  TMDS-1
Option  DPMS  true
EndSection

Section Screen
Identifier  Screen0
Monitor VGA
SubSection Display
Virtual 2880 900
EndSubSection
EndSection


Xorg X server log files on system:
-rw-r--r-- 1 root root 31201 Dec  5  2008 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 37464 Oct 15  2009 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 39025 Apr 16 08:34 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.7.6
Release Date: 2010-03-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-4-amd64 x86_64 Debian
Current Operating System: Linux mis-jz-lnx 2.6.32-3-amd64 #1 SMP Wed Feb 24 
18:07:42 UTC 2010 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-3-amd64 
root=UUID=cb1579ea-6000-4af5-9fe7-f70e3e915a64 ro quiet
Build Date: 05 April 2010  02:21:15PM
xorg-server 2:1.7.6-2 (Timo Aaltonen tjaal...@ubuntu.com) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Fri Apr 16 08:33:44 2010
(==) Using config file: /etc/X11/xorg.conf
(==) No Layout section.  Using the first Screen section.
(**) |--Screen Screen0 (0)
(**) |   |--Monitor VGA
(==) No device specified for screen Screen0.
Using the first device section listed.
(**) |   |--Device Configured Video Device
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
(==) ModulePath set to /usr/lib/xorg/modules
(II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure 

Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal

[James Zuelow]

Hi Julien --

It does not appear to, at least not right away.

Sometimes this behavior waits until the machine has been up for a few days.

James


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4a09477d575c2c4b86497161427dd94c14a6c83...@city-exchange07

Bug#576326: xserver-xorg: keys repeat without being held down

[James Cameron]

Package: xserver-xorg
Version: 1:7.5+5
Severity: normal

infrequently, roughly once or twice a day, a keyboard key will begin to repeat 
without being held down.

another key press cancels the repeating symptom.

the symptom occurs more frequently with xterm, wmaker, and mplayer.

the symptom is more likely to occur if the system has been placed under memory 
pressure, such as a backup, playback of a DVB-T transport stream, or a kernel 
compile.

in three scenarios has the symptom been observed:

1.  while scp'ing a large file from another host, while playing a television 
programme using mplayer, pressing the f key to toggle between fullscreen and 
partial screen ... mplayer responded by oscillating between the two sizes until 
another key was pressed,

2.  while doing a backup with tar, and no active screen use, pressing F12 to 
start an xterm (via a wmaker key definition), resulted in several hundred 
xterm's being forked, until an out-of-memory condition was triggered,

3.  while playing a video with mplayer, pressing 'q' to quit, mplayer properly 
quits, and then finding the 'q' begins to repeat in the xterm that was being 
mplayer's window.



-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Jun  3  2006 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1712808 Feb 16 19:39 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 
PCI/AGP or 662/761Gx PCIE VGA Display Adapter

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2662 Sep 16  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type man XF86Config-4 at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the ### BEGIN DEBCONF SECTION line above, and/or after the
# ### END DEBCONF SECTION line below.
#
# To change things within the debconf section, run the command:
#   dpkg-reconfigure xserver-xfree86
# as root.  Also see How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz.

Section ServerFlags
Option AutoAddDevices False
EndSection

Section Files
FontPath/usr/share/fonts/X11/misc
FontPath/usr/lib/X11/fonts/misc
FontPath/usr/lib/X11/fonts/cyrillic
FontPath/usr/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/share/fonts/X11/Type1
FontPath/usr/lib/X11/fonts/Type1
FontPath/usr/lib/X11/fonts/Speedo
FontPath/usr/share/fonts/X11/100dpi
FontPath/usr/lib/X11/fonts/100dpi
FontPath/usr/share/fonts/X11/75dpi
FontPath/usr/lib/X11/fonts/75dpi
EndSection

Section Module
Loadbitmap
Loaddbe
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadrecord
Loadvbe
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  keyboard
Option  CoreKeyboard
Option  XkbRules  xfree86
Option  XkbModel  lk450
Option  XkbLayout us
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
# kernel 2.4.x
# OptionDevice/dev/psaux
# kernel 2.6.x
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  ZAxisMapping  4 5
EndSection

Section Device
Identifier  Intel Corp. 82815 CGC [Chipset Graphics Controller]
Driver  sis
#   VideoRam16384
# 8192
EndSection

Section Monitor
Identifier  hp L2035
HorizSync 30-140
# 75.1
VertRefresh 60
DisplaySize 408 306
Option  DPMS
EndSection

Section Screen
Identifier  Default Screen
Device  Intel Corp. 82815 CGC [Chipset Graphics Controller]
Monitor hp L2035
DefaultDepth24
SubSection Display
Depth   24
Modes   1600x1200 800x600
EndSubSection
EndSection

Section ServerLayout
Identifier  Default Layout
Screen  Default Screen
InputDevice Generic 

Bug#252045: [font/mutt-misc PATCH] ClearlyU: fix off-by-one error in U+FFE1 through U+FFE6 range

[James Cloos]

 Julien == Julien Cristau jcris...@debian.org writes:

Julien The range U+FFE1 (￡, fullwidth pound sign) through U+FFE6 (￦,
Julien fullwidth won sign) is shifted by one position, pound being at position
Julien U+FFE0.

Julien Debian bug#252045 http://bugs.debian.org/252045

Julien Reported-by: Adrian 'Dagurashibanipal' von Bidder avbid...@fortytwo.ch
Julien Signed-off-by: Julien Cristau jcris...@debian.org
Julien ---
Julien  cu12.bdf |   24 
Julien  1 files changed, 12 insertions(+), 12 deletions(-)

Reviewed-by: James Cloos cl...@jhcloos.com

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#487635: Performance degradation over remote ssh X11 forwarded display (and any other remote X connection)

[Seb James]

I've been experiencing this problem in Lenny myself. I use unencrypted,
remote X, using XDMCP to establish a connection. I find particular
problems when using Evolution - it's unusable to scroll the lists. I
also experience slow performance using X tunneled via ssh.

I've applied Stephane Graber's patch for libxcb, which he created for
Ubuntu. See the libxcb patch in:
https://launchpad.net/~stgraber/+archive/ppa

You can find my application of this patch to Lenny (for i386 only right
now) here:

http://www.wmltd.co.uk/debian/libxcb1/

This patch restores the acceptable performance I was experiencing in
Debian Etch (prior to my upgrade to Lenny last week).

I've uploaded all the files I edited there; you can download the .deb
files and install (all of) them. The build tree is there, too. The patch
is only a couple of lines.

Hope it's helpful.

Seb James






-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#508767: /usr/bin/setxkbmap: setxkbmap resets xmodmap settings

[James Vega]

Package: x11-xkb-utils
Version: 7.4+1
Severity: normal
File: /usr/bin/setxkbmap

If after running xmodmap ~/.xmodmaprc, I run
setxkbmap -option ctrl:nocaps the settings from my .xmodmaprc are no
longer in effect.  xmodmap has to be re-run.

$ cat ~/.xmodmaprc
keysym Alt_R = Escape
keycode 227 = Super_L

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (499, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages x11-xkb-utils depends on:
ii  cpp 4:4.3.2-2The GNU C preprocessor (cpp)
ii  libc6   2.7-16   GNU C Library: Shared libraries
ii  libice6 2:1.0.4-1X11 Inter-Client Exchange library
ii  libsm6  2:1.1.0-1X11 Session Management library
ii  libx11-62:1.1.99.2-1 X11 client-side library
ii  libxaw7 2:1.0.4-2X11 Athena Widget library
ii  libxkbfile1 1:1.0.5-1X11 keyboard file manipulation lib
ii  libxmu6 2:1.0.4-1X11 miscellaneous utility library
ii  libxt6  1:1.0.5-3X11 toolkit intrinsics library
ii  x11-common  1:7.4~4  X Window System (X.Org) infrastruc

x11-xkb-utils recommends no packages.

x11-xkb-utils suggests no packages.

-- no debconf information

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org


signature.asc
Description: Digital signature

Bug#374026: Try deleting dotfiles...

[Daniel James]

I also experienced keyboard failure after upgrading to Lenny and running 
Thunderbird. I was replying to a mail and hit ctrl-shift-r, then 
couldn't type anything else. Logging out with the mouse, the keyboard 
still worked in gdm and on a virtual console.


I noticed that I was the only user on the system with the problem, so I 
deleted all the .dotfiles in my home directory, and the problem went away.


Cheers!

Daniel





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#454202: Status poke

[James Vega]

Any chance this can get enabled?

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED]


signature.asc
Description: Digital signature