Bug#1021735: libffi upgrade breaks Wayland on aarch64
Hi, This libffi upgrade also completely breaks all use of Wayland on aarch64. We use libffi to dispatch protocol messages (requests received by the server and events received by the client) to native-code handlers, and we are now getting completely nonsensical values from it. Can this upgrade please be rolled back until it can be root-caused and fixed? Cheers, Daniel
Bug#771952: RM: xresprobe -- hugely obsolete
Package: ftp.debian.org Severity: normal Hi, Please remove xresprobe from the archive. It exists to fork Xorg in probe-only mode and run a series of embarrassing regexes through the log file in order to generate a xorg.conf file. Quite aside from Xorg having run without a config file for the last several years, all the drivers have changed the strings they output, so the tool is almost certainly broken now. I only found out it was still in the archive when I went to show someone how hilarious it was, and accidentally discovered it was still in sid. Ouch. Thanks! Cheers, Daniel
Bug#688601: make: fails to execute extraordinarily long command lines
Package: make
Version: 3.81-8.2
Severity: important
Tags: patch
Hi,
When presented with a very very long command line (e.g. WebKit's linking
of libWebCore.la in current git), make fails to execute the command as
it doesn't split the command line to fit within the limits.
There are a number of workarounds discussed upstream[0], none of which
are particularly pleasant, but I've attached what seems to be the
preferred option, as used by Gentoo and others. I'm using this package
locally and it fixes the problem.
Cheers,
Daniel
[0]: http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.6.0-rc5+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages make depends on:
ii libc6 2.13-35
make recommends no packages.
Versions of packages make suggests:
pn make-doc none
-- no debconf information
diff -u make-dfsg-3.81/job.c make-dfsg-3.81/job.c
--- make-dfsg-3.81/job.c
+++ make-dfsg-3.81/job.c
@@ -29,6 +29,15 @@
#include string.h
+#if defined(__linux__) /* defined (HAVE_LINUX_BINFMTS_H) defined (HAVE_SYS_USER_H) */
+#include sys/user.h
+#include unistd.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE sysconf(_SC_PAGE_SIZE)
+#endif
+#include linux/binfmts.h
+#endif
+
/* Default shell to use. */
#ifdef WINDOWS32
#include windows.h
@@ -2697,9 +2706,19 @@
#endif
unsigned int line_len = strlen (line);
+#ifdef MAX_ARG_STRLEN
+static char eval_line[] = eval\\ \\\set\\ x\\;\\ shift\\;\\ ;
+#define ARG_NUMBER_DIGITS 5
+#define EVAL_LEN (sizeof(eval_line)-1 + shell_len + 4 \
+ + (7 + ARG_NUMBER_DIGITS) * 2 * line_len / (MAX_ARG_STRLEN - 2))
+#else
+#define EVAL_LEN 0
+#endif
char *new_line = (char *) alloca (shell_len + (sizeof (minus_c) - 1)
- + (line_len * 2) + 1);
+ + (line_len*2) + 1 + EVAL_LEN);
+
char *command_ptr = NULL; /* used for batch_mode_shell mode */
+char *args_ptr;
# ifdef __EMX__ /* is this necessary? */
if (!unixy_shell)
@@ -2712,6 +2731,30 @@
bcopy (minus_c, ap, sizeof (minus_c) - 1);
ap += sizeof (minus_c) - 1;
command_ptr = ap;
+
+#if !defined (WINDOWS32) defined (MAX_ARG_STRLEN)
+if (unixy_shell line_len MAX_ARG_STRLEN)
+ {
+ unsigned j;
+ memcpy (ap, eval_line, sizeof (eval_line) - 1);
+ ap += sizeof (eval_line) - 1;
+ for (j = 1; j = 2 * line_len / (MAX_ARG_STRLEN - 2); j++)
+ ap += sprintf (ap, \\$\\{%u\\}, j);
+ *ap++ = '\\';
+ *ap++ = '';
+ *ap++ = ' ';
+ /* Copy only the first word of SHELL to $0. */
+ for (p = shell; *p != '\0'; ++p)
+ {
+ if (isspace ((unsigned char)*p))
+ break;
+ *ap++ = *p;
+ }
+ *ap++ = ' ';
+ }
+#endif
+args_ptr = ap;
+
for (p = line; *p != '\0'; ++p)
{
if (restp != NULL *p == '\n')
@@ -2760,6 +2803,14 @@
}
#endif
*ap++ = *p;
+
+#if !defined (WINDOWS32) defined (MAX_ARG_STRLEN)
+ if (unixy_shell line_len MAX_ARG_STRLEN (ap - args_ptr MAX_ARG_STRLEN - 2))
+ {
+ *ap++ = ' ';
+ args_ptr = ap;
+ }
+#endif
}
if (ap == new_line + shell_len + sizeof (minus_c) - 1)
/* Line was empty. */
diff -u make-dfsg-3.81/debian/changelog make-dfsg-3.81/debian/changelog
--- make-dfsg-3.81/debian/changelog
+++ make-dfsg-3.81/debian/changelog
@@ -1,3 +1,11 @@
+make-dfsg (3.81-8.3) unstable; urgency=low
+
+ * Apply upstream patch to allow extraordinarily long command lines, stolen
+from Gentoo for convenience:
+http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/make/files/make-3.81-long-cmdline.patch?revision=1.2
+
+ -- Daniel Stone dan...@fooishbar.org Wed, 19 Sep 2012 08:10:12 +1000
+
make-dfsg (3.81-8.2) unstable; urgency=low
* Non-maintainer upload.
Bug#687388: Completely breaks libsoup
severity 687388 grave thanks g_pollable_stream_read() and friends are only provided by glib 2.33, which has only ever been in experimental. 2.32 is in unstable (tragically, versioned as 2.33+2.32 due to a misguided upload), and 2.33 seems to have disappeared from experimental, thus libsoup2.4-1 is totally broken in both unstable and experimental. I've set this to severity grave since it completely breaks everything using libsoup unless you happen to have a version of glib that was in experimental once but not anymore. As an aside, it seems like an error on the glib side that the relevant shlib dependencies weren't set to = 2.33, but oh well. Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684931: Not XKB at all
reassign 684931 libgtk-3-0 retitle 684931 GTK+ compose tables don't handle dead_stroke properly kthxbye This is nothing to do with XKB or its data set. XKB produces zero or one keysyms (in this case, dead_stroke for one key, and l for another) for each key press. Dead key handling is the responsibility of the input method, as Troy has repeatedly pointed out. The problem is that libX11's default XIM input method, through the /usr/share/X11/locale/*/Compose tables, will combine dead_stroke and l to ł, and GTK+'s compose tables for its own internal method don't contain this. tl;dr: Nothing to do with XKB. GNOME input method bug. Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684302: please re-enable EGL backend for Cairo
Package: libcairo2 Version: 1.12.2-2 Severity: wishlist Hi, The changelog for cairo 1.10.2-5, uploaded a year and a half ago, contains: * debian/control, debian/libcairo2.symbols, debian/rules: + Temporarily disable the OpenGL/EGL backend, since that makes us block on mesa / libdrm / linux-2.6 to migrate to testing, and we're blocking the gobject-introspection transition, and we don't want to tie them. It will be re-enabled soon after we migrate. There shouldn't be anything depending on these symbols yet, so this should be safe. Unfortunately, the EGL backend (which is useful for Wayland) is still not enabled in the Debian packaging. Could you please re-enable it? Thanks. :) Cheers, Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcairo2 depends on: ii libc6 2.13-33 ii libfontconfig1 2.9.0-6 ii libfreetype6 2.4.9-1 ii libpixman-1-0 0.26.0-3 ii libpng12-0 1.2.49-1 ii libx11-6 2:1.5.0-1 ii libxcb-render0 1.8.1-1 ii libxcb-shm01.8.1-1 ii libxcb11.8.1-1 ii libxrender11:0.9.7-1 ii multiarch-support 2.13-33 ii zlib1g 1:1.2.7.dfsg-13 libcairo2 recommends no packages. libcairo2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678250: Cause fix established
severity 678250 serious tags 678250 + upstream patch thanks Hi, The check in the media-keys plugin for XI2 support is broken: it looks for XI2, doesn't find it because the XIQueryVersion check is broken (admittedly, so is the protocol), and bails out. This has already been fixed upstream, per this bug: https://bugzilla.gnome.org/show_bug.cgi?id=673964 with this patch: http://bugzilla-attachments.gnome.org/attachment.cgi?id=211898 So it only happens on newer xserver/libXi, but I expect fixed versions of those to start making their way into Debian pretty soon. So, if you could please apply that to the next g-s-d upload, I'd be a very happy man. Thanks. :) Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678248: Local problem
close 678248 thanks Turns out this was a local issue, caused by a broken Cairo build. After rebuilding new Cairo with Xlib-XCB (but still Xlib and XCB separately) support disabled, the segfaults went away. Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678248: gnome-settings-daemon: g-s-d crashes on startup, has to be started by hand
Package: gnome-settings-daemon Version: 3.4.2-3 Severity: important Unfortunately I don't have much more useful information than this. But when I start my machine (using systemd, if that's in any way relevant), the following things happen: - gdm3 starts - the greeter is using the standard 1980s CDE theme, with gdm logs showing that gsd has crashed and thus the greeter is unthemed - I log in - (sometimes my entire session is just hung on a black screen, sometimes killall and restart either of gnome-shell or gnome-settings-daemon a couple of times fixes it, sometimes not) - sometimes my session works perfectly (aside from all the other things broken in sid's GNOME right now) at this point; - sometimes I get my background, but the theme and window decorations are different (possibly some kind of Debian default?) from what I've chosen, and I have to killall and restart gsd, at which point everything works fine; - sometimes my background is bright blue, same theme/decoration issue as above, and killall/restart makes things work again. I'm at a loss as to how to debug this, given that the GDM segfault in particular happens before I can really get my hands on any of the system. Cheers, Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4.0-rc7+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-1 ii dpkg 1.16.4.3 ii gsettings-desktop-schemas3.4.2-1 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.12.2-2 ii libcairo21.12.2-2 ii libcanberra-gtk3-0 0.28-4 ii libcanberra0 0.28-4 ii libcolord1 0.1.21-1 ii libcomerr2 1.42.4-3 ii libcups2 1.5.3-1 ii libdbus-glib-1-2 0.98-1 ii libfontconfig1 2.9.0-6 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgnomekbd7 3.4.0.2-1 ii libgnutls26 2.12.20-1 ii libgssapi-krb5-2 1.10.1+dfsg-1 ii libgtk-3-0 3.4.2-1 ii libgudev-1.0-0 175-3.1 ii libk5crypto3 1.10.1+dfsg-1 ii libkrb5-31.10.1+dfsg-1 ii liblcms2-2 2.2+git20110628-2.2 ii libnotify4 0.7.5-1 ii libnspr4 2:4.9.1-1 ii libnspr4-0d 2:4.9.1-1 ii libnss3 2:3.13.5-1 ii libnss3-1d 2:3.13.5-1 ii libpackagekit-glib2-14 0.7.4-4 ii libpango1.0-01.30.0-1 ii libpolkit-gobject-1-00.105-1 ii libpulse-mainloop-glib0 2.0-3 ii libpulse02.0-3 ii libsqlite3-0 3.7.13-1 ii libupower-glib1 0.9.16-3 ii libwacom20.5-1 ii libx11-6 2:1.5.0-1 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.1-1 ii libxklavier165.2.1-1 ii libxtst6 2:1.2.1-1 ii nautilus-data3.4.2-1 ii zlib1g 1:1.2.7.dfsg-11 Versions of packages gnome-settings-daemon recommends: ii pulseaudio 2.0-3 Versions of packages gnome-settings-daemon suggests: ii gnome-screensaver3.4.1-1 ii metacity [x-window-manager] 1:2.34.3-2 ii x11-xserver-utils7.7~3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678250: gnome-settings-daemon: media keys totally non-functional
Package: gnome-settings-daemon Version: 3.4.2-3 Severity: important Hi, Since a recent-ish upgrade (I'm not sure which, sorry), all the media keys in gnome-settings-daemon have ceased to function. Curiously, I'm pretty sure it wasn't the upgrade that broke all my other shortcuts and meant I had to go back and reconfigure everything, but one of the subsequent ones. Anyway, my media keys are all mapped completely correctly, it's just that g-s-d never grabs them, as can be seen from this xev output: KeyPress event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30025104, (603,366), root:(605,489), state 0x0, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30025224, (603,366), root:(605,489), state 0x0, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30025872, (603,366), root:(605,489), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30025976, (603,366), root:(605,489), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30029360, (370,-16), root:(372,107), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30029512, (370,-16), root:(372,107), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30030007, (370,-16), root:(372,107), state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x2e1, root 0xb0, subw 0x0, time 30030167, (370,-16), root:(372,107), state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4.0-rc7+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-1 ii dpkg 1.16.4.3 ii gsettings-desktop-schemas3.4.2-1 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.12.2-2 ii libcairo21.12.2-2 ii libcanberra-gtk3-0 0.28-4 ii libcanberra0 0.28-4 ii libcolord1 0.1.21-1 ii libcomerr2 1.42.4-3 ii libcups2 1.5.3-1 ii libdbus-glib-1-2 0.98-1 ii libfontconfig1 2.9.0-6 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgnomekbd7 3.4.0.2-1 ii libgnutls26 2.12.20-1 ii libgssapi-krb5-2 1.10.1+dfsg-1 ii libgtk-3-0 3.4.2-1 ii libgudev-1.0-0 175-3.1 ii libk5crypto3 1.10.1+dfsg-1 ii libkrb5-31.10.1+dfsg-1 ii liblcms2-2 2.2+git20110628-2.2 ii libnotify4 0.7.5-1 ii libnspr4 2:4.9.1-1 ii libnspr4-0d 2:4.9.1-1 ii libnss3
Bug#678251: gnome-shell: sometimes crashes instead of suspending
Package: gnome-shell Version: 3.4.1-6 Severity: important Hi, Somtimes when I close the lid, my entire GNOME session (so, could be Shell or something else - not sure) dies and dumps me back at the GDM login screen, so my laptop remains on draining its battery with the lid shut, rather than suspended. Happens probably one time in 4. Cheers, Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4.0-rc7+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-1 ii gconf-service3.2.5-1 ii gir1.2-accountsservice-1.0 0.6.21-4 ii gir1.2-atk-1.0 2.4.0-2 ii gir1.2-caribou-1.0 0.4.2-2 ii gir1.2-clutter-1.0 1.10.6-1 ii gir1.2-cogl-1.0 1.10.2-3 ii gir1.2-coglpango-1.0 1.10.2-3 ii gir1.2-folks-0.6 0.6.9-1 ii gir1.2-freedesktop 1.32.1-1 ii gir1.2-gconf-2.0 3.2.5-1 ii gir1.2-gcr-3 3.4.1-3 ii gir1.2-gdesktopenums-3.0 3.4.2-1 ii gir1.2-gdkpixbuf-2.0 2.26.1-1 ii gir1.2-gee-1.0 0.6.4-2 ii gir1.2-gkbd-3.0 3.4.0.2-1 ii gir1.2-glib-2.0 1.32.1-1 ii gir1.2-gmenu-3.0 3.4.2-1 ii gir1.2-gnomebluetooth-1.03.4.1-1 ii gir1.2-gtk-3.0 3.4.2-1 ii gir1.2-json-1.0 0.14.2-1 ii gir1.2-mutter-3.03.4.1-4 ii gir1.2-networkmanager-1.00.9.4.0-5 ii gir1.2-pango-1.0 1.30.0-1 ii gir1.2-polkit-1.00.105-1 ii gir1.2-soup-2.4 2.38.1-2 ii gir1.2-telepathyglib-0.120.18.1-2 ii gir1.2-telepathylogger-0.2 0.4.0-1 ii gir1.2-upowerglib-1.00.9.16-3 ii gjs 1.32.0-2 ii gnome-bluetooth 3.4.1-1 ii gnome-icon-theme-symbolic3.4.0-2 ii gnome-settings-daemon3.4.2-3 ii gnome-shell-common 3.4.1-6 ii gnome-themes-standard3.4.2-1 ii gsettings-desktop-schemas3.4.2-1 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.12.2-2 ii libcairo21.12.2-2 ii libcamel-1.2-29 3.2.2-3 ii libcanberra0 0.28-4 ii libclutter-1.0-0 1.10.6-1 ii libcogl-pango0 1.10.2-3 ii libcogl9 1.10.2-3 ii libcroco30.6.5-1 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-2 0.98-1 ii libebook-1.2-12 3.2.2-3 ii libecal-1.2-10 3.2.2-3 ii libedataserver-1.2-153.2.2-3 ii libedataserverui-3.0-1 3.2.2-3 ii libffi5 3.0.10-3 ii libfolks25 0.6.9-1 ii libgck-1-0 3.4.1-3 ii libgconf-2-4 3.2.5-1 ii libgcr-3-1 3.4.1-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgee2 0.6.4-2 ii libgirepository-1.0-11.32.1-1 ii libgjs0b [libgjs0-libmozjs185-1.0] 1.32.0-2 ii libgl1-mesa-glx [libgl1] 8.0.3-1 ii libglib2.0-0 2.32.3-1 ii libgnome-keyring03.4.1-1 ii libgnome-menu-3-03.4.2-1 ii libgstreamer0.10-0 0.10.36-1 ii libgtk-3-0 3.4.2-1 ii libical0 0.48-2 ii libjson-glib-1.0-0 0.14.2-1 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-3 ii libmutter0 3.4.1-4 ii libnm-glib4 0.9.4.0-5 ii libnm-util2 0.9.4.0-5 ii libnspr4 2:4.9.1-1 ii libnspr4-0d
Bug#678250: gnome-settings-daemon: media keys totally non-functional
Hi, On 20 June 2012 13:37, Michael Biebl bi...@debian.org wrote: Yes media-keys are handled by g-s-d. There is some known breakage with a/ custom shortcuts not being migrated from gconf to gsettings Right, I fixed these by hand (e.g. using Super+Tab instead Alt+Tab), but these aren't the media keys. b/ non-wm shortcuts using Super being broken, as Super is grabbed by the shell. This isn't Super, this is just about, e.g. raise/lower volume. I tried rebinding them explicitly in the control centre and it gets the right keysyms, but still they aren't grabbed at all and thus do nothing. Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678251: gnome-shell: sometimes crashes instead of suspending
Hi, On 20 June 2012 13:38, Michael Biebl bi...@debian.org wrote: We will need a bit more information that. A backtrace would helpful. How do I get this? Bear in mind that I usually only have one machine, and don't really want to carry two laptops (and some kind of connection between them) at all times just in case it crashes on suspend. Anything relevant in ~/.xsession-errors or the system logs? I'll check next time. What kind of grahics hardware / drivers do you use? i965, self-built kernel/Xorg/Mesa from git master. Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667027: flex: no protypes for yy_[gs]etcolumn in re-entrant mode
Package: flex Version: 2.5.35-10 Severity: normal Tags: upstream patch Hi, When using flex in re-entrant mode, no prototypes are generated for yy_getcolumn and yy_setcolumn, despite non-static declarations. This leads to warnings which can tank a build if using -Werror (I know, pointless in distributions and tarballs, but useful for upstream maintenance ...): CC src/xkbcomp/xkbscan.lo src/xkbcomp/xkbscan.c:2416:5: error: no previous prototype for 'yyget_column' [-Werror=missing-prototypes] src/xkbcomp/xkbscan.c:2492:6: error: no previous prototype for 'yyset_column' [-Werror=missing-prototypes] The attached patch has been shipped in Fedora since Fedora 13, with no complaints AFAICT. Please consider including this in the Debian package. Cheers, Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-rc5+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flex depends on: ii debconf [debconf-2.0] 1.5.42 ii dpkg 1.16.2 ii install-info 4.13a.dfsg.1-9 ii libc6 2.13-27 ii m4 1.4.16-2 Versions of packages flex recommends: ii gcc [c-compiler] 4:4.6.3-3 ii gcc-4.6 [c-compiler] 4.6.3-1 Versions of packages flex suggests: ii bison1:2.5.dfsg-2.1 ii build-essential 11.5 -- no debconf information diff -up flex-2.5.35/flex.skl\~ flex-2.5.35/flex.skl --- flex-2.5.35/flex.skl~ 2010-07-13 17:18:43.0 +0200 +++ flex-2.5.35/flex.skl 2010-07-13 17:23:49.0 +0200 @@ -960,6 +960,22 @@ m4_ifdef( [[M4_YY_NO_SET_LINENO]],, void yyset_lineno M4_YY_PARAMS( int line_number M4_YY_PROTO_LAST_ARG ); ]]) +m4_ifdef( [[M4_YY_REENTRANT]], +[[ +m4_ifdef( [[M4_YY_NO_GET_COLUMN]],, +[[ +int yyget_column M4_YY_PARAMS( M4_YY_PROTO_ONLY_ARG ); +]]) +]]) + +m4_ifdef( [[M4_YY_REENTRANT]], +[[ +m4_ifdef( [[M4_YY_NO_SET_COLUMN]],, +[[ +void yyset_column M4_YY_PARAMS( int column_no M4_YY_PROTO_LAST_ARG ); +]]) +]]) + %if-bison-bridge m4_ifdef( [[M4_YY_NO_GET_LVAL]],, [[ Diff finished. Tue Jul 13 17:27:50 2010
Bug#666176: tracker-miner-evolution: evo miner hangs on startup, totally nonfunctional
Package: tracker-miner-evolution Version: 0.14.0-2 Severity: grave Justification: renders package unusable Hi, Sorry, I feel like a bit of a tool reporting an RC bug as my first bug in pretty much forever, but ... whenever I have tracker-miner-evolution installed, evolution just plain refuses to start, being totally hung. I've inlined a gdb backtrace to the end of the message showing that the miner is the cause. Even leaving it for an hour didn't result in Evolution ever starting (judging from the backtrace, the timeout on the D-Bus method call is near on 25 days). I'm sure this bug report is pretty useless on the face of it, so please let me know how I can get you more details to help debug it. As it is, I've had to remove the Evolution plugins that this package installs (given I can't uninstall it without also removing gnome-documents) to be able to start evolution at all. Cheers, Daniel (gdb) run Starting program: /usr/bin/evolution [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Gtk-Message: Failed to load module canberra-gtk-module [New Thread 0x7fffe413d700 (LWP 6380)] [New Thread 0x7fffe3928700 (LWP 6381)] [New Thread 0x7fffd4416700 (LWP 6382)] ^C Program received signal SIGINT, Interrupt. 0x7fffee6c7cc3 in *__GI___poll (fds=optimized out, nfds=optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) thread apply all bt Thread 4 (Thread 0x7fffd4416700 (LWP 6382)): #0 0x7fffee6c7cc3 in *__GI___poll (fds=optimized out, nfds=optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7fffeebd0af6 in g_main_context_poll (n_fds=1, fds=0x18036b0, timeout=-1, context=0x1803710, priority=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3417 #2 g_main_context_iterate (dispatch=1, block=optimized out, context=0x1803710, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3118 #3 g_main_context_iterate (context=0x1803710, block=optimized out, dispatch=1, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3060 #4 0x7fffeebd0f5a in g_main_loop_run (loop=0x17fef70) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3317 #5 0x7fffd441bd3b in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so #6 0x7fffeebf2405 in g_thread_proxy (data=0x17fe850) at /tmp/buildd/glib2.0-2.32.0/./glib/gthread.c:801 #7 0x744a3b50 in start_thread (arg=optimized out) at pthread_create.c:304 #8 0x7fffee6d290d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x in ?? () Thread 3 (Thread 0x7fffe3928700 (LWP 6381)): #0 0x7fffee6c7cc3 in *__GI___poll (fds=optimized out, nfds=optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7fffeebd0af6 in g_main_context_poll (n_fds=5, fds=0x7fffdc002780, timeout=-1, context=0x14c4e10, priority=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3417 #2 g_main_context_iterate (dispatch=1, block=optimized out, context=0x14c4e10, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3118 #3 g_main_context_iterate (context=0x14c4e10, block=optimized out, dispatch=1, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3060 #4 0x7fffeebd0f5a in g_main_loop_run (loop=0x14caed0) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3317 #5 0x7fffefec8916 in gdbus_shared_thread_func (user_data=0x14c4de0) at /tmp/buildd/glib2.0-2.32.0/./gio/gdbusprivate.c:277 #6 0x7fffeebf2405 in g_thread_proxy (data=0x14cb5e0) at /tmp/buildd/glib2.0-2.32.0/./glib/gthread.c:801 #7 0x744a3b50 in start_thread (arg=optimized out) at pthread_create.c:304 #8 0x7fffee6d290d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x in ?? () Thread 2 (Thread 0x7fffe413d700 (LWP 6380)): #0 0x7fffee6c7cc3 in *__GI___poll (fds=optimized out, nfds=optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7fffeebd0af6 in g_main_context_poll (n_fds=1, fds=0x1412f90, timeout=-1, context=0x1412aa0, priority=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3417 #2 g_main_context_iterate (dispatch=1, block=optimized out, context=0x1412aa0, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3118 #3 g_main_context_iterate (context=0x1412aa0, block=optimized out, dispatch=1, self=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3060 #4 0x7fffeebd0c24 in g_main_context_iteration (context=0x1412aa0, may_block=1) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3184 #5 0x7fffeebd0c71 in glib_worker_main (data=optimized out) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:4856 #6 0x7fffeebf2405 in g_thread_proxy (data=0x1458370) at
Bug#600860: Possibly an X bug
Hi, This could well be an X bug, which I fixed in http://cgit.freedesktop.org/xorg/xserver/commit/xkb?id=3231962db826f5efd431596a309c96e907a191d1 - check if this still occurs with xserver 1.11, I guess? Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632549: [PATCH] Xephyr/dri: register screen and window privates on init
On Tue, Jul 26, 2011 at 08:41:58PM +0200, Julien Cristau wrote: On Thu, Jul 7, 2011 at 19:18:03 +0200, Julien Cristau wrote: Fixes assertion failure when calling dixSetPrivate Debian bug#632549 http://bugs.debian.org/632549 Reported-and-tested-by: Mohammed Sameer msam...@foolab.org Signed-off-by: Julien Cristau jcris...@debian.org --- hw/kdrive/ephyr/ephyrdriext.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Ping. Anyone? Reviewed-by: Daniel Stone dan...@fooishbar.org Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631299: dpkg: upgrade to multiarch packages removed locally diverted files
Hi, On Thu, Jun 23, 2011 at 08:24:07AM +0200, Raphael Hertzog wrote: On Wed, 22 Jun 2011, Daniel Stone wrote: Hmm. Seems plausible, but I went through quite a few libX11 uploads without losing my diversion: I would've noticed quite quickly, as the failure mode (which prompted the xkbcomp 1.2.2 and 1.2.3 releases) with my local XKB dataset and any distribution-shipped libX11 involved my entire keyboard doing nothing at all under X. Would you notice it instantly or only when you restart X? Only when I restart, but I do this twice a day at a bare minimum (as suspend/resume is broken), and usually quite a few times more than that, as I do all my X development on my live running server. I usually dist-upgrade every couple of weeks or so, so I'd be pretty stunned if I just managed not to manage it until multiarch came along. Do you have any backups of the /var/lib/dpkg/diversions file? Unfortunately not, I'm afraid. Is there any more information I can provide? If you can't give us a hint on how they might have disappeared from /var/lib/dpkg/diversions, there's not much we can do. Hmm. dpkg itself when dealing with upgrades only uses /var/lib/dpkg/diversions in a read-only mode and there's no way a simple package upgrade would have resulted in the loss of those entries. Sounds reasonable. Is there anything else that uses dpkg-divert and that could have resulted in this behaviour ? Maybe look around in /var/lib/dpkg/info/* for maintainer scripts (of local packages?) which could have some weird usage of dpkg-divert ? I can't see anything obvious, no. I don't have any local packages; if I did, I'd just have packaged my self-built X libraries with an epoch, rather than diversions. How did you put in place all your diversions, do you have script for this? Maybe it did not work as you thought it did. By hand: for i in /usr/lib/libX11.*; do sudo dpkg-divert --add $i; done Seems to have worked just fine since May 2010, and I've not touched it since then. It's a shame there's not more information I can give you. Cheers, Daniel signature.asc Description: Digital signature
Bug#631299: dpkg: upgrade to multiarch packages removed locally diverted files
Hi, On Thu, Jun 23, 2011 at 03:19:54PM +0200, Raphael Hertzog wrote: tag 631299 + unreproducible severity 631299 important thanks Fair enough. :) On Thu, 23 Jun 2011, Daniel Stone wrote: By hand: for i in /usr/lib/libX11.*; do sudo dpkg-divert --add $i; done Hum, this doesn't rename the existing file. So when you install your custom lib, you overwrite the packaged files. The diverted file are only installed on the next package upgrade. Yep, that seems fine. dpkg.log shows me going through at least four libx11 upgrades this year prior to the multiarch transition, and I definitely remember seeing the *.distrib files, so. There were also a number of other X library diversions (e.g. libXau, libxcb) which suffered the same fate. Seems to have worked just fine since May 2010, and I've not touched it since then. It's a shame there's not more information I can give you. Hum I remember Steve Langasek saying that diverting libraries in the same directory causes troubles because ldconfig/ld.so doesn't care of the extension and might be confused by seeing the same SONAME twice. Yeah, I certainly remember seeing that problem, but it seemed to generally be resolved in my local library winning. I don't see how it could have resulted in loosing files and/or diversions but maybe someone else can. Maybe we should also add some sort logging to dpkg-divert just like we added logging to update-alternatives. This would at least give some supplementary information for cases like this one. Yeah, that would be nice. Cheers, Daniel signature.asc Description: Digital signature
Bug#631299: dpkg: upgrade to multiarch packages removed locally diverted files
Package: dpkg Version: 1.16.0.3 Severity: grave Justification: causes non-serious data loss I have pretty much the entirety of the X stack diverted through dpkg-divert so I can keep package dependencies, but still run all my own built-from-git X stuff. This includes all the client libraries. Perhaps not quite what dpkg-divert was designed for, or necessarily ideal, but oh well. Anyway, when upgrading from sid as of about two weeks ago to sid as of this week, the X libraries apparently underwent the multiarch transition. I realised because I went from having /usr/lib/libX11.so.6.2.1 and /usr/lib/libX11.so.6.2.1.distrib, as well as all the others, to having nothing X-related at all in /usr/lib. So, the upgrade, as well as removing the .distrib file as it should've, also appears to have removed my locally-installed file, which is very bad. Happily I could just run make install again, but this could've been much worse, I guess. smcv claims that multiarch had no special transition logic and this must be a dpkg bug, so I'm filing this here. Cheers, Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-rc3+ (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 8.5-1GNU core utilities ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libselinux1 2.0.98-1+b1 SELinux runtime shared libraries ii xz-utils5.0.0-2 XZ-format compression utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.8.14.1 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631299: dpkg: upgrade to multiarch packages removed locally diverted files
Hi, On Wed, Jun 22, 2011 at 11:06:39PM +0200, Sven Joachim wrote: On 2011-06-22 21:10 +0200, Daniel Stone wrote: On Wed, Jun 22, 2011 at 08:50:40PM +0200, Sven Joachim wrote: This is bad indeed. However, I am unable to reproduce this behavior. Could you please send your /var/log/dpkg.log (compress it first) and the output of dpkg-divert --list? Sure. dpkg-divert --list doesn't list any of the libraries anymore, presumably because they're gone? It may be the other way around: somehow your local diversions got lost, and the subsequent package upgrades removed the files themselves. When I made a local diversion of /usr/lib/libX11.so.6.3.0 and then upgraded libx11-6 from 2:1.4.3-1 to 2:1.4.3-2, dpkg left both the file and the diversion alone, removing only /usr/lib/libX11.so.6.3.0.distrib as it is supposed to do. Hmm. Seems plausible, but I went through quite a few libX11 uploads without losing my diversion: I would've noticed quite quickly, as the failure mode (which prompted the xkbcomp 1.2.2 and 1.2.3 releases) with my local XKB dataset and any distribution-shipped libX11 involved my entire keyboard doing nothing at all under X. Do you have any backups of the /var/lib/dpkg/diversions file? Unfortunately not, I'm afraid. Is there any more information I can provide? Cheers, Daniel signature.asc Description: Digital signature
Bug#589300: zsh: multibyte character support broken again
Package: zsh Version: 4.3.10-14 Severity: important So it looks like support for multibyte characters has regressed. :( Using setopt VI, though this has confirmed to not be important: zsh% unicode ䷥ pressing esc, 0, w, i, ' -w', which should yield 'unicode -w ䷥', instead yields 'unicode -w䷥', by the looks. Additionally, once that's in your history, just pressing up to get it back to the current line and then down to clear it, will gradually clear one character too many from your prompt until it's empty. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zsh depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcap2 1:2.17-2 support for getting/setting POSIX. ii libncursesw5 5.7+20100313-2 shared libraries for terminal hand Versions of packages zsh recommends: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libpcre3 8.02-1 Perl 5 Compatible Regular Expressi Versions of packages zsh suggests: pn zsh-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589300: Bug #589300: zsh: multibyte character support broken again
On Fri, 16 Jul 2010 at 03:19:05PM +, Clint Adams wrote: On Fri, Jul 16, 2010 at 03:29:10PM +0100, Daniel Stone wrote: Using setopt VI, though this has confirmed to not be important: zsh% unicode ䷥ pressing esc, 0, w, i, ' -w', which should yield 'unicode -w ䷥', instead yields 'unicode -w䷥', by the looks. This part confuses me; shouldn't w position you at the start of the word, and therefore i,' -w' do exactly as you say? Sorry, you're right: the prompt being broken threw me off. The cursor for me is one to the left of where it should be. Esc-0 puts me on the space between % and unicode, instead of at the starting u. Additionally, once that's in your history, just pressing up to get it back to the current line and then down to clear it, will gradually clear one character too many from your prompt until it's empty. I can't reproduce this part; can you do it with zsh -f? Yes. Here's the output of printenv: WINDOWPATH=7 ORBIT_SOCKETDIR=/tmp/orbit-daniels DISPLAY=:0.0 GNOME_KEYRING_PID=2302 GDM_KEYBOARD_LAYOUT=us LOGNAME=daniels PWD=/home/daniels HOME=/home/daniels XAUTHORITY=/var/run/gdm3/auth-for-daniels-xUUgJa/database LANG=en_AU.utf8 PATH=/home/daniels/bin:/home/daniels/src/toolchain/arm-2008q3/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/games GTK_RC_FILES=/etc/gtk/gtkrc:/home/daniels/.gtkrc-1.2-gnome2 GNOME_KEYRING_CONTROL=/tmp/keyring-HaLO0J SSH_AUTH_SOCK=/tmp/keyring-HaLO0J/ssh SHELL=/bin/zsh XDG_DATA_DIRS=/usr/share/gnome:/usr/share/gdm/:/usr/local/share/:/usr/share/ SSH_AGENT_PID=2353 DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-HbPa0q2Z0K,guid=53f1570412eec942044e5a4f0038 TERM=xterm COLORTERM=gnome-terminal DESKTOP_SESSION=default USER=daniels USERNAME=daniels GDMSESSION=default GDM_LANG=en_AU.utf8 GTK_MODULES=canberra-gtk-module XDG_SESSION_COOKIE=adfdf83159ce0ddd4a06966a25ce-1279178153.572784-224439268 WINDOWID=25165827 SESSION_MANAGER=local/tempa:@/tmp/.ICE-unix/2321,unix/tempa:/tmp/.ICE-unix/2321 GNOME_DESKTOP_SESSION_ID=this-is-deprecated SHLVL=2 OLDPWD=/home/daniels EDITOR=vim LC_CTYPE=en_AU.UTF-8 LC_MONETARY=en_AU.UTF-8 LC_NUMERIC=C LC_COLLATE=C LESSOPEN=| /bin/lesspipe %s LESSCLOSE=/bin/lesspipe %s %s git_author_email=dan...@fooishbar.org git_committer_email=dan...@fooishbar.org ps1...@%m:%~%% _=/usr/bin/printenv and my options: setopt GLOB EXTENDED_GLOB MAGIC_EQUAL_SUBST RC_EXPAND_PARAM \ HIST_EXPIRE_DUPS_FIRST HIST_IGNORE_DUPS HIST_VERIFY CORRECT HASH_CMDS \ PRINT_EXIT_VALUE RC_QUOTES AUTO_CONTINUE MULTIOS VI INC_APPEND_HISTORY \ APPENDHISTORY unsetopt beep unset MAIL Let me know if there's anything more you need. Cheers, Daniel signature.asc Description: Digital signature
Bug#480737: xserver-xephyr: -extension Composite does not disable composite extension
On Sun, May 11, 2008 at 11:21:11PM +0200, Julien Cristau wrote: Confirmed. This is because kdrive's InitOutput() function resets noCompositeExtension to FALSE after the command-line arguments have been parsed. Daniel, this change was introduced by commit 'new KDrive input world order' (02d09105113fb9b560a770fe15f7bb041165831c), when Composite was disabled by default. Maybe it would make sense to remove this now that composite is enabled by default, so it's possible to disable it? Yep, that's fine, please feel free to merge (without [PATCH]) to master and any branches you feel would be appropriate. Cheers, Daniel signature.asc Description: Digital signature
Bug#464721: uninstallable is not normal
severity 464721 critical kthxbye Failure to install would count as slightly more severe, I'd say ... signature.asc Description: Digital signature
Bug#464721: uninstallable is not normal
On Fri, Mar 28, 2008 at 03:29:27PM +0100, Matthias Klose wrote: severity 464721 important thanks no, an out-of-date package which was not yet built on the buildd is not severity `critical', or else there would be hundreds of such bug reports. It makes the package uninstallable, and thus unusable. Evidently, it's been this way for almost two months: surely buildds aren't that slow? Cheers, Daniel signature.asc Description: Digital signature
Bug#57116: LBX deprecated by X.Org
[Please CC me if you want me to reply: I'm not subscribed.] Hi, lbxproxy has been deprecated upstream (X.Org) for quite a while, and we completely removed LBX support in 7.2 or so (maybe 7.1). This bug should probably be closed. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 07:55:35PM -0400, ext David Nusinow wrote: On Wed, Oct 24, 2007 at 01:53:40PM +0300, Daniel Stone wrote: As I've said before, the X server isn't the only user of the field. :) Ubuntu were trying to move to cxkb a year or so ago, and the only thing that stopped them in the end was how huge the XKB codebase was, which I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets us finaly unify console and X keymaps ... Ok, I missed that somehow. So it should probably be hal that generates this and not the xserver? Yep. Well, you could even have a postinst that scans xorg.conf and generates the FDI, but yes, the X server should be responsible for checking this and not breaking existing setups. Yeah, I'm mainly concerned with not breaking existing setups. I feel like we've been doing that a lot lately. Luckly, lenny is a ways away so we have time to break things quite a bit before we get it right. Sweet. Well, I'll happily take patches. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 08:17:10PM -0400, ext David Nusinow wrote: On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: Whenever xorg input hotplugging kicks in, the evdev driver is used. The kbd keyboard settings from xorg.conf are ignored and the en_US keyboard layout is used. Yes, this should probably be fixed up, I guess. But the long-term fix is to provide an FDI file in /etc that specifies the keyboard layout. My feeling is the other way around, provided that the X server is the only user of this field. People already know how to edit xorg.conf, and they expect it. Telling them to edit a relatively obscure file among many other fdi's is more painful. There's also userspace tools that exist to help with generating a xorg.conf, but nothing friendly to deal with fdi's. As I've said before, the X server isn't the only user of the field. :) Ubuntu were trying to move to cxkb a year or so ago, and the only thing that stopped them in the end was how huge the XKB codebase was, which I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets us finaly unify console and X keymaps ... Preferably, the X server should use the keyboard layout specified in xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. Yes, probably. My sense is that if we're going to do this, then there's no need to generate the fdi. Just generate the xorg.conf. We can patch the server to use libhal_device_set_property_string to dynamically set the keyboard layout at runtime in hal's database, and the server can just draw that information from xorg.conf initially. Well, you could even have a postinst that scans xorg.conf and generates the FDI, but yes, the X server should be responsible for checking this and not breaking existing setups. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 02:47:06PM +0200, ext Julien Cristau wrote: On Tue, Oct 23, 2007 at 20:02:31 +0200, Michael Biebl wrote: You were right, Julien. It was because of hal (specifically the file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi) that the evdev driver was enabled. BTW, should we change the fdi to load synaptics instead of evdev when it detects a touchpad? It seems most people are using that. Yep, seems sensible to me. I'm using evdev right now on my laptop, but I need to run xinput to set the device to relative mode every time I start X (and I had to modify xinput to let me do that, because it doesn't think my touchpad is an extended device). Ah, yes. I assume it was just checking for XExtensionDevice, instead of Device/Keyboard/Pointer? Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: Whenever xorg input hotplugging kicks in, the evdev driver is used. The kbd keyboard settings from xorg.conf are ignored and the en_US keyboard layout is used. Yes, this should probably be fixed up, I guess. But the long-term fix is to provide an FDI file in /etc that specifies the keyboard layout. Unfortunately, the evdev driver seems to lack functionality, e.g. my multimedia keys don't work anymore, also, very important, STRG+ALT+F1 is non-functional (maybe this is just a misconfiguration, I don't know. At least the default configuration seems to lack this functionality). Sounds like the keymap isn't getting loaded correctly; it's always worked fine here. It gets even worse, if you try to apply a pc105 keyboard layout over evdev (which can happen if you use GNOMEs/KDEs keyboard selector). Then you not only have missing keys but also some keys are mis-mapped. E.g. the UP key is mapped to PRINT [1]. This really makes it hard to navigate. Use the evdev layout, not pc105. If I understood Daniel correctly, he proposes to set the keyboard layout (probably based on the values from xorg.conf) via a generated fdi file. I'd like to avoid that, because that would complicate things. How would it complicate anything? xorg.conf is a file, so is an FDI. We're already using FDIs through HAL, anyway ... Preferably, the X server should use the keyboard layout specified in xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. Yes, probably. For the second part (DEs applying a pc105 keyboard layout over evdev) I can't think of a proper solution right now. All I can say is, that I would prefer, if we don't break working setups. Unfortunately, there's not much we can do here, except possibly the evdev driver hacking pc105 to evdev. Cheers, Daniel signature.asc Description: Digital signature
Bug#399183: xserver-xorg: incorrectly calculates TrueType font metrics
On Wed, Sep 05, 2007 at 10:02:33AM +0200, Juliusz Chroboczek wrote: Hi. (I'm the original author of the FreeType backend in X.Org.) This bug was introduced in revision 1.32 of ftfuncs.c[1] in XFree86 CVS[2] on 19 October 2003 by David Dawes [EMAIL PROTECTED]. This commit was made against my opinion (as expressed on the internal XFree86 mailing list), and was one of the reasons why I resigned from XFree86. The current version of ftfuncs.c in X.Org was branched from XFree86, unfortunately after the afore-mentioned commit. I believe that there is currently nobody who understands the mess that has been made out of my formerly relatively clean code (to the extent that anything relating to core fonts can be clean). If you wish to work on the FreeType backend, I encourage you to study commit 1.32 and undo the mess. For now, I'm marking this report as wontfix and CC-ing upstream. Hi Juliusz, As our resident font luminary (being that you seem to know the turf, and none of the rest of us know much about it), you're more than welcome to fix it, should you choose to. Cheers, Daniel signature.asc Description: Digital signature
Bug#432138: More random errors
I also get this on startup occasionally: [EMAIL PROTECTED]:~% o zsh: exit 100 offlineimap -u Curses.Blinkenlights No output, just immediate exit. Cheers, Daniel signature.asc Description: Digital signature
Bug#338820: Fixed?
If the assertion failure at elflink.c:6081 and the TLS mismatch error message are indeed one and the same, then this should be marked fixed, since it's a) a code issue, and b) handled gracefully by newer versions of binutils. Cheers, Daniel signature.asc Description: Digital signature
Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY)
On Mon, Aug 06, 2007 at 05:56:44PM +0300, Kari Pahula wrote:
1 write(0, (II) RADEON(0): RADEONRestoreMem..., 50) = 50
1 write(0, (II) RADEON(0): MC_FB_LOCATION..., 48) = 48
1 write(0, (II) RADEON(0): MC_AGP_LOCATIO..., 48) = 48
199 nanosleep({0, 1000}, NULL) = 0
Sounds like the CRTC2 wait-for-vblank disaster, which is fixed in git.
Cheers,
Daniel
signature.asc
Description: Digital signature
Bug#432138: offlineimap: Race (?) causes failure to start
Package: offlineimap Version: 4.0.16 Severity: normal About 20% of the time, when using either 4 or 8 threads, offlineimap will fail to start, throwing the following backtrace: .Thread 'InputHandler loop' terminated with exception: Traceback (most recent call last): File /var/lib/python-support/python2.5/offlineimap/threadutil.py, line 153, in run Thread.run(self) File threading.py, line 440, in run self.__target(*self.__args, **self.__kwargs) File /var/lib/python-support/python2.5/offlineimap/ui/Curses.py, line 263, in bgreaderloop ch = s.c.stdscr.getch() AttributeError: CursesUtil instance has no attribute 'stdscr' No debug messages were logged for InputHandler loop. zsh: exit 100 offlineimap -u Curses.Blinkenlights Note that it's indented with a dot: presumably it's got some of the way through it. I see this a lot at work (SMP Xeon, eight threads), and on my laptop (Core Duo, four threads), but don't recall seeing it on my old laptop (Pentium M, one thread). Unfortunately I don't have a non-SMP machine to verify this with, since someone stole my old laptop. Also, I'm using Ubuntu with Python 2.5.1 (2.5.1-0ubuntu1), but I don't think this is an Ubuntu-specific bug. Cheers, Daniel signature.asc Description: Digital signature
Bug#408482: Rationale for the US default
[Please keep me CC'ed if you want me to see it: I'm not subscribed.] Hi, I was the one who implemented the prompting, way back in the Ubuntu days. The reason is that Ubuntu originally shipped with French Canadian as the default, but several irritated users, as well as Jeff Bailey (from Montréal), assured me that it's nearly impossible to actually buy one of these keyboards, and that Canadians would be annoyed if ca(fr), rather than us, was the default. I don't have anything more to back it up, and I'm an Australian living in Finland, so probably wildly unqualified to comment on it. But that's why it was done in the first place. Cheers, Daniel signature.asc Description: Digital signature
Bug#329416: xserver-xorg: Bug with non-working three layouts is not fixed
On Wed, Sep 27, 2006 at 09:59:23PM +0200, Denis Barbier wrote: On Fri, Apr 21, 2006 at 06:01:12PM +0300, Daniel Stone wrote: On Fri, Apr 21, 2006 at 06:23:56PM +0300, Yauhen Kharuzhy wrote: This bug is not fixed in current unstable. In upstream it was fixed. XSF: http://webcvs.freedesktop.org/xorg/xserver/xorg/xkb/xkbUtils.c?r1=1.7r2=1.8 Thanks Daniel, but this patch is obviously wrong ;) Ivan Pascal gave a better patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345803;msg=32 It has been committed into our SVN repository, can you please commit it upstream? Sorry, my bad. I'll commit the fix. signature.asc Description: Digital signature
Bug#388998: xserver-xorg-video-tdfx: Missing include headers
On Sun, Sep 24, 2006 at 05:22:07AM +0300, Guillem Jover wrote: The problem here is that xserver-xorg-video-tdfx is lacking some included headers, and the getsecs macro does not get expanded, so module ends up with an unresolvable symbol which makes X crash. The error can only be seen on the console. Attached a patch which can be imported into the quilted package. It fixes a missing header for the abs function as well. Hm. xf86_ansic.h is dead and shouldn't be used: you should use stdlib and friends instead. signature.asc Description: Digital signature
Bug#382706: amaya crashes with GDK error traced to this component
On Wed, Sep 13, 2006 at 02:58:03AM -0700, Steve Langasek wrote: The title and severity of this bug are incorrect. The only reproducible problem reported in the original report that's related to libgl1-mesa-dri is display errors using the Radeon driver. I imagine this isn't a bug in libgl at all, but anyway it's not a release-critical one. Does the problem occur with LIBGL_ALWAYS_INDIRECT=1? signature.asc Description: Digital signature
Bug#385976: strange (and annoying) delay on startup
On Mon, Sep 11, 2006 at 10:18:03PM +0200, Robert Millan wrote: Thanks for the ellaboration. This sounds like a strange race, though. It would require the user to launch the client before the server has finished its startup, which AFAICT can only be done from a shell that doesn't belong to this server session. Er, the server doesn't provide ICE functionality, that's purely a client-side adventure. So yes, it's entirely possible -- and plausible. Cheers, Daniel signature.asc Description: Digital signature
Bug#387133: libx11: FTBFS: floating point exception
On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: Package: libx11 Version: 2:1.0.0-8 Severity: serious Justification: no longer builds from source Hi, when I try to build libx11 under etch or sid I get the following error: make[3]: Leaving directory `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' ../src/util/makekeys /usr/include/X11/keysymdef.h ks_tables_h /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys /usr/include/X11/keysymdef.h ks_tables_h make[2]: *** [ks_tables.h] Error 136 make[2]: Leaving directory `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' Full debuild log for sid is attached. Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks the build of libx11 1.0.1. signature.asc Description: Digital signature
Bug#387133: libx11: FTBFS: floating point exception
On Tue, Sep 12, 2006 at 01:23:52PM -0700, Steve Langasek wrote: On Tue, Sep 12, 2006 at 03:50:04PM +0300, Daniel Stone wrote: On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: Hi, when I try to build libx11 under etch or sid I get the following error: make[3]: Leaving directory `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' ../src/util/makekeys /usr/include/X11/keysymdef.h ks_tables_h /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys /usr/include/X11/keysymdef.h ks_tables_h make[2]: *** [ks_tables.h] Error 136 make[2]: Leaving directory `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' Full debuild log for sid is attached. Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks the build of libx11 1.0.1. Then we have a problem, given that David says the new libx11 is not targetted for etch and the new x11proto-core is already there. So backport the makekeys.c fix. Problem solved. signature.asc Description: Digital signature
Bug#385033: libxvmc: missing debian/copyright file
On Sun, Sep 10, 2006 at 12:10:08PM +0200, David Schmitt wrote: The new debian/copyright only contains licensing information for src/XvMCWrapper.c. The other source files ./include/X11/extensions/XvMClib.h ./src/XvMClibint.h ./src/XvMC.c do not contain any licensing information and are therefore undistributable. Please contact upstream for a clarification. No, they do not make it undistributable at all. See: http://webcvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/doc/COPYRIGHT?hideattic=0view=markup which was in force at the time this code was written. --- 1. XFree86 Copyright XFree86 code without an explicit copyright is covered by the following copy- right: [XFree86 1.0 licence snipped; it's benign] --- Cheers, Daniel signature.asc Description: Digital signature
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
On Thu, Sep 07, 2006 at 11:07:02AM +0200, Jan Willem Stumpel wrote:
This is a 'simultaneous bug' in xkb-data and libx11-data.
In /usr/share/X11/xkb/symbols/gr, the keys generating the Classical Greek
'breathing' signs are defined as follows
key AC10 { [ dead_acute, dead_horn ] };
key AC11 { [ dead_grave, dead_ogonek ] };
The breathing signs are the shifted symbols (dead_horn and dead_ogonek).
This means that these keys do not work in an international UTF-8 locale,
because the international Compose file
(/usr/share/X11/locale/en_US.UTF-8/Compose), which has definitions for the
full set of Ancient Greek accent combinations, expects the breathing signs to
be U0313 and U0314 respectively.
The dead_horn and dead_ogonek are only recognized by the Greek UTF-8 Compose
file, /usr/share/X11/locale/el_GR.UTF-8/Compose.
The solution is to change dead_horn to U0313 and dead_ogonek to U0314 both in
/usr/share/X11/xkb/symbols/gr and in
/usr/share/X11/locale/el_GR.UTF-8/Compose. It is important to do this
simultaneously.
Er, could dead_horn and dead_ognek sequences not just be added to en_US?
Unicode syms are nice, but not much point in using them when we already
have clearly-defined X keysyms for the same purpose.
Cheers,
Daniel
signature.asc
Description: Digital signature
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
On Thu, Sep 07, 2006 at 12:31:28PM +0200, Jan Willem Stumpel wrote: Daniel Stone wrote: Er, could dead_horn and dead_ognek sequences not just be added to en_US? Of course they could. But that would be perpetuating a kludge. dead_horn and dead_ogonek were chosen by the original Greek designer *) because they do not occur in the Greek language, so he thought they were unused and made them do double duty as breathing signs. The real dead_horn and dead_ogonek are completely different -- they are accents below the letters, not above, like the breathing signs are. Apparently he was not aware that the keysyms starting with U are by default valid keysyms in xkb, nor of the fact that the true breathings signs had already been defined in Unicode: Actually, at the time the Greek support was written, that wasn't true. U+0313 COMBINING COMMA ABOVE, Greek psili, smooth breathing mark U+0314 COMBINING REVERSED COMMA ABOVE, Greek dasia, rough breathing mark Apparently, the creators of the Greek polytonic xkb file and of the international Compose file worked independently of one another. It is time to put it right. *) See http://www.mail-archive.com/linux-utf8@nl.linux.org/msg05200.html (near the end of the message): When I made an initial try at a polytonic Greek keyboard, I couldn't find a dead_comma_above and a dead_reversed_comma_above, so I just (ab)used the first two keysyms that weren't otherwise meaningful on a Greek keyboard. Subsequent updates to the Greek keyboard layout and Compose files kept this (perhaps not strictly correct) arrangement. Okay, thanks for your analysis and pointing out that I was wrong. :) Your suggested fix seems fine to me. Cheers, Daniel signature.asc Description: Digital signature
Bug#383465: Contains obfuscated source code, DFSG violation?
On Tue, Aug 29, 2006 at 01:21:26AM +0200, Steinar H. Gunderson wrote:
On Thu, Aug 17, 2006 at 02:12:17PM +0100, Matthew Garrett wrote:
The nv driver appears to be heavily obfuscated and is effectively
The idea that nvidia do not posess an electronic list of register names
and offsets is entirely implausible. The only rational explanation is
that register information is postprocessed out in order to reduce
information leakage.
Or that nVidia never wrote the driver in the first place. I cannot find any
nVidia copyrights on it -- it seems to have been reverse-engineered and then
written up by the current copyright holders.
The output of the below has been tidied up a bit to remove duplicates:
[EMAIL PROTECTED]:~/x/xorg/driver/xf86-video-nv/src% for i in *.[ch]; do echo
-n $i:\ ; grep Copyright $i || echo no copyright; done
nv_const.h: no copyright
nv_cursor.c: |* Copyright 2003 NVIDIA, Corporation. All rights reserved.
*|
nv_dac.c: |* Copyright 2003 NVIDIA, Corporation. All rights reserved.
*|
nv_dga.c: no copyright
nv_dma.h: |* Copyright 2003 NVIDIA, Corporation. All rights reserved.
*|
nv_driver.c: * Copyright 1996-1997 David J. McKay
nv_hw.c: |* Copyright 1993-2003 NVIDIA, Corporation. All rights
reserved. *|
nv_include.h: no copyright
nv_local.h: |* Copyright 1993-2003 NVIDIA, Corporation. All rights
reserved. *|
nv_proto.h: no copyright
nv_setup.c: |* Copyright 2003 NVIDIA, Corporation. All rights reserved.
*|
nv_shadow.c:Copyright (c) 1999, The XFree86 Project Inc.
nv_type.h: no copyright
nv_video.c: no copyright
nv_xaa.c: |* Copyright 2003 NVIDIA, Corporation. All rights reserved.
*|
nvreg.h: * Copyright 1996-1997 David J. McKay
nvvga.h: * Copyright 1996-1997 David J. McKay
riva_const.h: no copyright
riva_cursor.c: * Copyright 1996-1997 David J. McKay
riva_dac.c: * Copyright 1996-1997 David J. McKay
riva_dga.c: no copyright
riva_driver.c: * Copyright 1996-1997 David J. McKay
riva_hw.c: |* Copyright 1993-1999 NVIDIA, Corporation. All rights
reserved. *|
riva_hw.h: |* Copyright 1993-1999 NVIDIA, Corporation. All rights
reserved. *|
riva_include.h: no copyright
riva_local.h: |* Copyright 1993-1999 NVIDIA, Corporation. All rights
reserved. *|
riva_proto.h: no copyright
riva_setup.c: * Copyright 1996-1997 David J. McKay
riva_shadow.c:Copyright (c) 1999, The XFree86 Project Inc.
riva_tbl.h: |* Copyright 1993-1999 NVIDIA, Corporation. All rights
reserved. *|
riva_type.h: no copyright
riva_xaa.c: |* Copyright 1993-1999 NVIDIA, Corporation. All rights
reserved. *|
So, of those, a few Riva files for the ancient Riva 128 chipset are
copyright David J. McKay as well as nvreg.h and nvvga.h,
riva_shadow.c and nv_shadow.c are copyright XFree86, and
riva_include.h, riva_proto.h, riva_type.h, riva_dga.c, riva_const.h,
nv_video.c, nv_type.h, nv_proto.h, nv_include.h, nv_dga.c,
and nv_const.h have no copyright. The rest are NVIDIA.
riva_shadow.c and nv_shadow.c implement a 'shadow framebuffer' option,
which isn't about hardware access. The files were almost certainly just
taken from some other driver, with a quick sed run.
Assuming the dates for David McKay's copyright run correct, they are
almost nine years old now. nvreg.h does not actually contain register
definitions, but is a fairly trivial set of macros and declaration of a
few pointers to register locations (extern unsigned char *nvDAC, et al).
nvvga.h contains a register definition for the NV1, which was released
in 1995. All the fun parts of the Riva driver -- and this is for an
ancient chip -- are in NVIDIA-copyrighted files, like riva_hw.c:
VGA_WR08(chip-PCIO, 0x3D4, 0x19); tmp = VGA_RD08(chip-PCIO, 0x3D5);
VGA_WR08(chip-PCIO, 0x3D5, (offset 0x01F) | (tmp ~0x1F));
VGA_WR08(chip-PCIO, 0x3D4, 0x2D); tmp = VGA_RD08(chip-PCIO, 0x3D5);
VGA_WR08(chip-PCIO, 0x3D5, (offset 0x60) | (tmp ~0x60));
and riva_tbl.h:
static unsigned nv3TablePRAMIN[][2] =
{
{0x0500, 0x0001},
{0x0501, 0x007F},
{0x0200, 0x8000},
{0x0201, 0x00C20341},
{0x0204, 0x8001},
[...]
But 'nv' is the interesting one, since that supports current
hardware, and nv_hw.c is the one with genius section such as:
cr11 = VGA_RD08(pNv-PCIO, 0x3D5);
if(Lock) cr11 |= 0x80;
else cr11 = ~0x80;
VGA_WR08(pNv-PCIO, 0x3D5, cr11);
Sadly this isn't even remotely out of the ordinary for the nv driver:
it's one of the most benign sections I could find in the first function
of nv_hw.c.
For recent history, looking at:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-nv.git;a=shortlog
you can see that all code commits have been made either by Aaron
Plattner (an NVIDIA employee, as you can see from his email address,
also you can google him on site:lists.freedesktop.org to see him
offering
Bug#383465: Contains obfuscated source code, DFSG violation?
On Tue, Aug 29, 2006 at 09:53:34AM +0200, Xavier Bestel wrote: True. But as the driver is distributed under the MIT licence, I don't think it has to be under the preferred form for modification. Unless Debian requires it ? Um, the subject is about a DFSG violation, not a licence violation. According to -legal, everything must be provided with its pure, original source -- the head of the coder that hand-wrote some firmware, the instruments used to record any particular Ogg Vorbis track, et al. Random hex constants are apparently not source in firmware (and thus distribution of such is a violation of the DFSG), but I fail to see how random hex constants are source here either. Cheers, Daniel signature.asc Description: Digital signature
Bug#363517: xorg-server and kfreebsd
On Mon, Aug 28, 2006 at 12:06:27PM +0200, Petr Salinger wrote: - attached changes to debian packaging - it looks like kdrive is (still) linux only, Fixing this should be quite trivial, given that Xephyr is a 'fake' server. signature.asc Description: Digital signature
Bug#363517: xorg-server and kfreebsd
On Mon, Aug 28, 2006 at 01:55:26PM +0200, Michael Banck wrote: Samuel Thibault sent in a patch in #358015 and upstream #5613 for the kdrive issue. The byteswap part should be taken from Petr's patch, as it is more general (__GLIBC__ vs. __GNU__, so working on kfreebsd as well). I'm not entirely satisfied with that patch for a few reasons: firstly, the AM_CONDITIONAL placement is wrong (it should never be in an if; set a variable you need in an if and put the AM_CONDITIONAL on the outer), and secondly, we need to reject compilation of 'real' servers at configure time if we don't have an OS lib for things like VT switching, keyboard handling ... you know, the little things. ;) The byteswap bit looks fine though. Cheers, Daniel signature.asc Description: Digital signature
Bug#363517: xorg-server and kfreebsd
On Mon, Aug 28, 2006 at 04:03:50PM +0200, Petr Salinger wrote: Well, I have been confused by mandatory subdir linux, so 2nd attempt. That's pretty close, thanks. I'll try to clean it up a little bit tonight and commit those two to upstream git; I'll bounce -x the patches when I do. - kfreebsd-kdrive.diff - presence of sys/vm86.h is not sufficient for VESA drivers, let hw/kdrive/linux/agp.c compile also on kfreebsd should be submitted upstream ? - kfreebsd-man_suffix.diff - again sync man pages suffixes with linux (aclocal.m4), changed in 1:1.1.1-2 only for linux We fixed that better upstream by removing the x suffix madness in util-macros 1.1.1. - kfreebsd-debian.diff - debian packaging, files in usr/lib/xorg/modules/freebsd/*.so are needed for us That's fine. diff -ur x/xorg-server-1.1.1/hw/kdrive/linux/agp.c xorg-server-1.1.1/hw/kdrive/linux/agp.c --- x/xorg-server-1.1.1/hw/kdrive/linux/agp.c 2006-07-05 20:31:39.0 +0200 +++ xorg-server-1.1.1/hw/kdrive/linux/agp.c 2006-08-28 13:38:45.0 +0200 @@ -65,7 +65,7 @@ #include linux/agpgart.h -#elif defined(__FreeBSD__) +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) #include sys/ioctl.h #include sys/agpio.h #endif Oh my god, why is this in linux/? diff -ur x/xorg-server-1.1.1/configure.ac xorg-server-1.1.1/configure.ac --- x/xorg-server-1.1.1/configure.ac 2006-08-28 17:01:11.0 +0200 +++ xorg-server-1.1.1/configure.ac2006-08-28 16:43:11.0 +0200 @@ -1433,7 +1436,11 @@ AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) if test $ac_cv_header_sys_vm86_h = yes; then -AC_DEFINE(KDRIVEVESA, 1, [Build VESA-based kdrive servers]) + case $host_os in + kfreebsd*-gnu) kdrivevesa=no ;; + *) AC_DEFINE(KDRIVEVESA, 1, [Build VESA-based kdrive servers]) + kdrivevesa=yes;; + esac fi AC_CHECK_HEADERS([linux/fb.h]) @@ -1473,7 +1480,7 @@ AC_SUBST(KDRIVE_LIBS) AM_CONDITIONAL(TSLIB, false) AM_CONDITIONAL(H3600_TS, false) -AM_CONDITIONAL(KDRIVEVESA, [test x$ac_cv_header_sys_vm86_h = xyes]) +AM_CONDITIONAL(KDRIVEVESA, [test x$kdrivevesa = xyes]) AM_CONDITIONAL(KDRIVEFBDEV, [test x$ac_cv_header_linux_fb_h = xyes]) Surely KDRIVEFBDEV also needs to be Linux-only? Cheers, Daniel signature.asc Description: Digital signature
Bug#384056: xkb-data 0.8-7 -- it isn't possible to load the czsk layout
On Wed, Aug 23, 2006 at 05:53:22PM +0200, [EMAIL PROTECTED] wrote: Er, have you tried using /usr/share/X11/xkb instead of /etc/X11/xkb? ~$ setxkbmap -model pc104 -layout pc/czsk -print | xkbcomp -w0 -I/usr/share/X11/xkb - :0 Error: Can't find file pc/czsk for symbols include Exiting Abandoning symbols file (null) Error: success in unknown Couldn't write keyboard description to :0 Yes, pc/ has gone with xkeyboard-config. Have you tried using czsk instead? Also, what's the output of setxkbmap ... -print? signature.asc Description: Digital signature
Bug#384204: 32-bit biarch support
On Tue, Aug 22, 2006 at 05:22:48PM +0200, Robert Millan wrote: Patch attached for 32-bit biarch support (lib32sm6 and lib32sm-dev). (needs lib32ice first) Um, why don't you focus your energies on proper multiarch support instead of trying to propagate hacks like this further than they need to be? signature.asc Description: Digital signature
Bug#384204: 32-bit biarch support
On Tue, Aug 22, 2006 at 06:35:08PM +0200, Robert Millan wrote: On Tue, Aug 22, 2006 at 07:19:29PM +0300, Daniel Stone wrote: On Tue, Aug 22, 2006 at 05:22:48PM +0200, Robert Millan wrote: Patch attached for 32-bit biarch support (lib32sm6 and lib32sm-dev). (needs lib32ice first) Um, why don't you focus your energies on proper multiarch support instead of trying to propagate hacks like this further than they need to be? Wait, this is not proper multiarch? No. signature.asc Description: Digital signature
Bug#384204: 32-bit biarch support
On Tue, Aug 22, 2006 at 07:12:33PM +0200, Robert Millan wrote: On Tue, Aug 22, 2006 at 07:49:34PM +0300, Daniel Stone wrote: On Tue, Aug 22, 2006 at 06:35:08PM +0200, Robert Millan wrote: On Tue, Aug 22, 2006 at 07:19:29PM +0300, Daniel Stone wrote: On Tue, Aug 22, 2006 at 05:22:48PM +0200, Robert Millan wrote: Patch attached for 32-bit biarch support (lib32sm6 and lib32sm-dev). (needs lib32ice first) Um, why don't you focus your energies on proper multiarch support instead of trying to propagate hacks like this further than they need to be? Wait, this is not proper multiarch? No. Can you point me to any of: a) documentation/description of the right thing. http://www.google.com/search?q=multiarchbtnI=I'm+Feeling+Lucky b) current status / timeline. c) reason why everyone else (including glibc and gcc maintainers) seems to be following this scheme instead. These two questions are left as an exercise to the reader. signature.asc Description: Digital signature
Bug#384204: 32-bit biarch support
On Tue, Aug 22, 2006 at 08:28:19PM +0200, Robert Millan wrote: Ok, if I understood correctly, changes in comparison with what we have now are: - A more standarised pathset, instead of just /emul/ia32-linux. According to http://wiki.debian.org/toolchain-multiarch, there are plans to make the toolchain aware of the new paths. Sounds a lot like post-etch, but AFAIK we can do the same without it (by using --libdir at build time, and adequate /etc/ld.so.conf at runtime) - dpkg / dak / katie major rework (I haven't read in-depth, but I assume the point is using the same ia32 code from the i386 port without compiling it separately. Definitely post-etch..) Did I miss something? Is someone able to guess which of them is Daniel concerned with? And the crucial points: - generalised: works on any architecture, not just amd64/i386, - non-intrusive: dak/dpkg changes are easy. changing every package to have such horrendous hacks as this, with hardcoded triplets, is never going to fly, - cleaner: see previous two. signature.asc Description: Digital signature
Bug#383918: FTBFS on non-DRM systems
diff -ur xserver-xorg-video-i810-1.6.5/src/brw_structs.h xserver-xorg-video-i810-1.6.5-hurd/src/brw_structs.h --- xserver-xorg-video-i810-1.6.5/src/brw_structs.h 2006-08-08 22:51:25.0 + +++ xserver-xorg-video-i810-1.6.5-hurd/src/brw_structs.h 2006-08-20 17:23:05.0 + @@ -28,6 +28,8 @@ #ifndef BRW_STRUCTS_H #define BRW_STRUCTS_H +#include GL/gl.h + /* Command packets: */ struct header This should be guarded with #ifdef XF86DRI (or whatever), and so should the relevant struct members. Or it just shouldn't be included if the whole file is GL-specific. signature.asc Description: Digital signature
Bug#384056: xkb-data 0.8-7 -- it isn't possible to load the czsk layout
On Mon, Aug 21, 2006 at 05:17:15PM +0200, [EMAIL PROTECTED] wrote: After lastest upgrade (package akb-data and xlibs-data) I can't load my keyboard based on layout czsk. (if I substitute pc/czsk or only czsk, result is the same) ~$ setxkbmap -model pc104 -layout pc/czsk -print | xkbcomp -w0 -I/etc/X11/xkb - :0 Error:Error interpreting include file pc Exiting Abandoning symbols file (null) Error: success in unknown Couldn't write keyboard description to :0 Er, have you tried using /usr/share/X11/xkb instead of /etc/X11/xkb? signature.asc Description: Digital signature
Bug#376055: x11-common: dexconf ignores mouse port and protocol selections
On Mon, Aug 14, 2006 at 12:11:03PM +0200, Denis Barbier wrote: On Thu, Jun 29, 2006 at 08:42:59PM -0400, Ilguiz Latypov wrote: Trying to figure why my choice of ImPS/2 isn't stored in xorg.conf, I found that dexconf ignored it. Here is the patch. The changelog has this entry: * Change default mouse protocol to ExplorerPS/2 (closes: Ubuntu#4106). Daniel, is there some problem with applying this patch? Looks fine to me. Cheers, Daniel signature.asc Description: Digital signature
Bug#376765: dpkg-reconfigure xserver-xorg issues strange warning about /etc/X11/X
On Mon, Aug 14, 2006 at 01:21:05PM +0200, Alejandro Exojo wrote: I don't fully understand the purpose of lines 1631 to 1637 of xserver-xorg.postinst (in version 1:7.0.23), and it seems I'm not the only one (see the comment why, why, why, why, why, why, why are we md5suming this? -daniels) but there are some obvious errors: the md5sums, are calculated not on the file, but on the _name_ of the file. See the attached patch. Um, that would mean that the link would be seen as a custom link every single time the X server binary was changed. The correct fix would be to cat the link target in there, not the MD5 sum (which actually makes it longer in all but the most utterly pathological of cases, thus neatly defeating the point of summing it in the first place ...). signature.asc Description: Digital signature
Bug#269860: fixed in input-hotplug
On Mon, Aug 14, 2006 at 09:03:57PM +, David Nusinow wrote: On Sat, Aug 12, 2006 at 10:03:36PM +0300, Daniel Stone wrote: I've pushed the fix for this (make the DIX more tolerant of devices without a CtrlProc: we return BadDevice) to the input-hotplug branch upstream. Thanks. Speaking of which, I'd like to put input-hotplug in Debian at some point very early in the etch+1 cycle. Do you think it'll be ready for a wider audience by then? Should be, yeah. Barring major catastrophes, it'll be in 7.3 upstream anyway. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362641: committed upstream
Hi, I've committed this patch upstream (thanks). I'd suggest that ioport just not be built for S390. Cheers, Daniel signature.asc Description: Digital signature
Bug#379480: (no subject)
I'd be stunned if this was actually a server problem, and not a client-side problem related to grabs. Which window manager do you use? Does changing it fix anything? signature.asc Description: Digital signature
Bug#373711: sure
Hi, This copyright file looks fine ([EMAIL PROTECTED] is me, but I don't use that address anymore). However, I should note that libxv1 was packaged from scratch (being a part of the modular tree), so at least the first paragraph should be removed. I don't think it's terribly important information and can be found in the changelog anyway, so the second paragraph should probably go as well. Cheers, Daniel signature.asc Description: Digital signature
Bug#269860: fixed in input-hotplug
I've pushed the fix for this (make the DIX more tolerant of devices without a CtrlProc: we return BadDevice) to the input-hotplug branch upstream. Thanks. signature.asc Description: Digital signature
Bug#93810: AEST vs EST, redux
FWIW, http://en.wikipedia.org/wiki/List_of_time_zones lists: UTC + 10, K * Australia (AEST— Eastern Standard Time) o Australian Capital Territory**, o New South Wales** (except Broken Hill, which observes South Australia time), o Queensland, o Tasmania** (which observes DST starting on the first weekend of October instead of the last), o Victoria** Cheers, Daniel signature.asc Description: Digital signature
Bug#372756: pkg-config?
While your bug report is perfectly valid, you're supposed to use pkg-config to check for xfixes. signature.asc Description: Digital signature
Bug#381950: doesn't know debian-installer/keymap = no-latin1 = xkblayout = no
On Tue, Aug 08, 2006 at 01:14:26AM +0200, Steinar H. Gunderson wrote: The xserver-xorg config script attempts to grok debian-installer/keymap and set XkbModel/XkbLayout accordingly. However, it doesn't recognize no-latin1, only no, and thus falls back to the default (pc104/us). I don't really think there's an exact mapping for no-latin1 in the Xkb rules, but no should at least be ages better than us. :-) At one point, we were stripping -usb, -macintosh, and -latin1 off the end of the d-i layouts. This should probably start happening again. signature.asc Description: Digital signature
Bug#381118: sbuild: schroot + apt download is broken
Package: sbuild Version: 0.48 Severity: important Justification: breaks a major use case Hi, When using schroot and apt to download packages, the build tanks quite early: apt-get source is called from within the chroot, but none of the verify_md5sum stuff is, so it tries to verify the dsc in ~/build/ in the host, and fails when it isn't there. Interestingly, the failure mode is a hang in verify_md5sums, because dsc_md5sums returns null, and verify_md5sums ends up calling /usr/bin/md5sum, which hangs waiting for input ... Cheers, Daniel signature.asc Description: Digital signature
Bug#381118: [Buildd-tools-devel] Bug#381118: sbuild: schroot + apt download is broken
On Wed, Aug 02, 2006 at 12:44:57PM +0100, Roger Leigh wrote: Daniel Stone [EMAIL PROTECTED] writes: When using schroot and apt to download packages, the build tanks quite early: apt-get source is called from within the chroot, but none of the verify_md5sum stuff is, so it tries to verify the dsc in ~/build/ in the host, and fails when it isn't there. Interesting. Perhaps we should still run apt-get outside the chroot, even when using schroot? I originally introduced it to make setup simpler, and to work around some bugs with apt-get (specifically, apt-listchanges and friends, and it running some things outside the chroot even when you set all the config parameters to use the chroot). Depends what your usecase is. My use for this is running an i386 builder on amd64 (just requires a couple of hacks to pass the architecture name in). I'd rather not have an sbuild chroot inside the i386 chroot inside my real amd64 system ... Interestingly, the failure mode is a hang in verify_md5sums, because dsc_md5sums returns null, and verify_md5sums ends up calling /usr/bin/md5sum, which hangs waiting for input ... That looks like an outright bug. dsc_md5sums should, IMO, return an empty hashref on failure, but doesn't currently. Correct. I'm moving house in, ooh.. an hour and a half, and this computer is about to be packed into a box, so I'll have to take a better look tomorrow or Friday! Thanks a lot. :) Cheers, Daniel signature.asc Description: Digital signature
Bug#380061: dpkg-reconfigure xserver-xorg doesn't update /etc/X11/xorg.conf
On Thu, Jul 27, 2006 at 10:35:15AM +0200, Christoph Pfister wrote: Reconfiguring xserver-xorg doesn't change /etc/X11/xorg.conf at all because of an obvious error in the postinst script. Please find a patch attached (and hopefully you agree on it ;-) which fixes the bug. --- xserver-xorg.postinst_old 2006-06-12 05:46:09.0 +0200 +++ xserver-xorg.postinst 2006-07-27 10:26:19.0 +0200 @@ -1666,7 +1666,7 @@ else fi # here's a novel concept: DON'T TOUCH THE CONFIG ON UPGRADES -if [ -z $UPGRADE ] || dpkg --compare-versions $2 le 1:7.0.14; then +if [ -z $UPGRADE ] || dpkg --compare-versions $2 le $SOURCE_VERSION; then # compare the current and stored checksums; if they do not match, assume # that's the way the user wants it. if we're reconfiguring, overwrite # it regardless and back it up. Nope, the problem is that $UPGRADE is non-zero on reconfigures; I think there's a patch around already for this. Your patch would ensure that the behaviour was exactly contrary to the comment, and would always be true AIUI. signature.asc Description: Digital signature
Bug#362641: Making xorg-server FTBFS RC
On Thu, Jul 27, 2006 at 03:56:00AM +0200, Julien Cristau wrote: On Sat, Jul 8, 2006 at 21:42:11 +0200, Adeodato Simó wrote: I'm raising the severity of this bug to critical because, although xorg-server was never compiled in s390 before (thus bug was filed with severity: important), it provides binary packages like xvfb that used to be available for s390 and now are not, causing other packages to FTBFS due to unmet build-dependencies. xorg-server shouldn't even try to build Xorg on s390. Maybe the attached patch helps? It disables xorg and xdmx on this arch, but leaves xvfb and xnest enabled. Totally untested, as I don't have access to the hardware :) Xorg provides a dummy video driver and a void input driver, so yes, building Xorg is perfectly valid. Cheers, Daniel signature.asc Description: Digital signature
Bug#375667: x11-common and xserver-xorg unupgradeable due to mutual deathgrip
On Wed, Jul 19, 2006 at 11:13:34AM +0100, Ian Jackson wrote: Ian Jackson writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable due to mutual deathgrip): Daniel Stone writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable due to mutual deathgrip): On Wed, Jun 28, 2006 at 05:41:28PM +0100, Ian Jackson wrote: /usr/bin/X11 is a bit tricky. I think the right answer is to have some preinst move all of the binaries from /usr/bin/X11 to /usr/bin and then sort out the links but this should be done with care. There should be no need for any Conflicts. Happily mangling binaries from other packages? Ugh. I think that the results would be correct. How about I do some tests and get back to you ? I was thinking about this and discussing it in the pub with some people and came to the following question: why do we mind if some binaries are in /usr/bin/X11 and some in /usr/bin, halfway through the transition ? Ie, why not just keep /usr/bin/X11 around until it vanishes ? There's no need for it to be a symlink; you just keep both directories on the path. Some people have hardcoded /usr/bin/X11/xauth, et al. As I'm reading the FHS, it must continue to work. signature.asc Description: Digital signature
Bug#354490: RFP: multiseat
On Wed, Jul 05, 2006 at 06:08:51PM -0700, Matt Taggart wrote: I noticed your comments in #354490 about multiseat maybe not quite being ready for primetime (back in May). Has the situation changed at all? What are the things you think needs to happen before this could be packaged/integrated with Debian to support multiseat easily? It would be nice to be able to support this in etch. Hi, Nothing's changed on this front. multiseat hasn't seen any serious attention since about March 2005, and I don't expect it will unless some seriously interested party picks up the pieces and: * better integrates it with the current xorg and gdm configurations, * investigates wider support (e.g. on ATI, Intel). I'm no longer working on Ubuntu or Debian stuff at all, so I haven't been looking at it. Sorry. Cheers, Daniel signature.asc Description: Digital signature
Bug#374775: kdeinit symbol lookup error for libSM6
On Tue, Jul 04, 2006 at 11:50:00AM -0600, Michael Dawson wrote: I had the exact same problem and temporarily fixed it by downloading an older version of libSM.6.0.0 (in libsm6_4.3.0.dfsg.1-14sarge1_i386.deb) and used it to replace the new one in /usr/lib. KDE has been working fine so far. I hope the next upgrade to the libSM package fixes it. libSM needs a versioned dependency on a modular libICE, which has this symbol (previously it was _IceGetPeerName). What I'm trying to say, of course, is that libICE's shlibs needs bumping. Cheers, Daniel signature.asc Description: Digital signature
Bug#375667: x11-common and xserver-xorg unupgradeable due to mutual deathgrip
On Wed, Jun 28, 2006 at 05:41:28PM +0100, Ian Jackson wrote:
So
before /usr/{lib,include}/X11 - /usr/X11R6/{lib,include}
after /usr/{lib,include}/X11 - /usr/X11R6/{lib,include}
and
before /usr/bin/X11 - /usr/X11R6/bin (real dir)
after /usr/bin/X11 - ../usr/X11R6/bin - /usr/bin (by some name)
That's fine and there are ways of doing these things.
Are there any other difficulties etc. ?
Only the sheer number of packages that ignored policy, FHS, etc, and
installed a bunch of crap into /usr/X11R6. Some of them are external
(e.g. Opera).
A lot of people have hardcoded paths into /usr/X11R6. Sucks.
I'm not sure I understand why it is necessary to adjust old systems to
conform to the new standard wrt {lib,include}. Why can't they just be
left with the symlinks pointing to where new systems have directories
and vice versa ?
I dind't bother transitioning /usr/X11R6 for Ubuntu, I just left it
hanging.
/usr/bin/X11 is a bit tricky. I think the right answer is to have
some preinst move all of the binaries from /usr/bin/X11 to /usr/bin
and then sort out the links but this should be done with care. There
should be no need for any Conflicts.
Happily mangling binaries from other packages? Ugh.
signature.asc
Description: Digital signature
Bug#375667: x11-common and xserver-xorg unupgradeable due to mutual deathgrip
On Tue, Jun 27, 2006 at 03:08:33PM +0100, Ian Jackson wrote: It is not possible to upgrade these packages without either (a) deinstalling nearly the entire system or (b) using a --force option to dpkg to force violation of the declared dependencies. (a) is absurd and (b) should not be necessary (dependencies which should be violated shouldn't be declared by the packages). Patches welcome. If you know of a better way to do this transition, I'm all ears. signature.asc Description: Digital signature
Bug#345958: patch
On Thu, Jun 22, 2006 at 11:39:20AM +0200, Robert Millan [ackstorm] wrote: This patch from Ubuntu worked for me. XSF: This is from CVS/git, so should be fine to apply. signature.asc Description: Digital signature
Bug#372918: negative refresh rates in xrandr
On Mon, Jun 12, 2006 at 02:43:34PM +0200, Soeren Sonnenburg wrote: when I look at the output of xrandr I see negative refresh rates not only confusing me but also e.g. gnome-display-properties (i.e. I can no longer change resolutions on the fly with that tool) This is a known issue with MergedFB, since there is no good way to express one refresh rate for two displays which almost certainly have differing refresh rates. Section Device Identifier ATI Radeon Internal Driver radeon BusID PCI:0:16:0 Option UseFBDev false IIRC this is the default. Option AllowGLXWithComposite true This option is only useful with the nvidia driver. Option AccelMethod xaa This option is also the default. Optionbackingstore true This option will not help your performance. Option EnablePageFliptrue This option is highly problematic. Option AGPMode 4 This option is almost certainly unnecessary. Option AGPFastWrite true This option could well kill your machine. Option MonitorLayout LVDS,TMDS This option is almost certainly unnecessary, unless you really need to force it when you don't have a second monitor. Option PanelSize 1280x854 This option is almost certainly unnecessary. Screen 0 EndSection Section Device Identifier ATI Radeon External [... more insanity ...] Screen 1 EndSection You don't need to have separate Device sections for MergedFB: that's the entire point behind it. signature.asc Description: Digital signature
Bug#372278: xserver-xorg-input-all: using clipboard with 8 bits characters doesn't work
On Fri, Jun 09, 2006 at 11:02:01AM +0200, Bartosz Fenski aka fEnIo wrote: I'm not sure which package should I choose for this particular problem cause I'm not aware of internal mechanismes in X.org. Please forward/reassign this bugreport to the correct place if this is wrong one. The problem is when I try to mark some text (in Firefox for example) and it contains some characters like apostrophe wrote using entities like rsquo;. X clipboard seems to have problems with such characters and it's not possible to paste marked text to the other application like xterm. I suppose it's problem with UTF handling, but it's not possible to paste even broken text without that 8 bit characters. Middle mouse button doesn't paste anything. Maybe it should simply strip 8 bits characters and paste only these that are correct for 8bit encoding. Define 'broken'. X actually has no clipboard role. What happens is this: * you select something in Firefox, * Firefox informs X that it now owns the PRIMARY selection, * you middle-click in xterm, * xterm queries X as to who owns the PRIMARY selection, * Firefox and xterm do type negotiation, and the most acceptable type is sent to xterm. So you'd have to be looking at what went on in the type negotiation between Firefox and xterm. I assume you're pasting UTF-8 quotation marks (‘’´) into a non-UTF-8 terminal, and things go south? If so, it's a bug in either Firefox for not gracefully dealing with other encodings, or xterm. Cheers, Daniel signature.asc Description: Digital signature
Bug#370149: FTBFS: not compatible with FreeType 2.2
On Sat, Jun 03, 2006 at 07:43:11PM +0200, Martin Michlmayr wrote: Your package fails to build in unstable with the following errors. The changelog from xpdf (which had the same problem) will help you resolve this issue: xpdf (3.01-8) unstable; urgency=low * Add patch 05_freetype-2.2.dpatch: make splash/SplashFTFont.cc compatible with FreeType 2.2 (ie don't use FreeType internals directly any more). Fixes unreported FTBFS. There are various patches floating around, but all of them are rather incomplete. signature.asc Description: Digital signature
Bug#369389: xresprobe: Regression between 0.4.18-1 and 0.4.23debian1 on a HP Pavillon zv5000
On Mon, May 29, 2006 at 04:30:57PM +0200, Free Ekanayaka wrote: I'm running bleeding-edge etch on my laptop HP Pavillon zv5000. The latest xresprobe version 0.4.23debian1 seems to fail to detect the proper resolution: [EMAIL PROTECTED]:/# xresprobe nv grep: /tmp/xprobe.19627/xorg.log: No such file or directory grep: /tmp/xprobe.19627/xorg.log: No such file or directory id: res: freq: disptype: lcd/lvds Note that version 0.4.18-1 is working fine: [EMAIL PROTECTED]:/# xresprobe nv id: res: 1280x800 freq: disptype: lcd/lvds I've tried to upgrade to sid and this time xresprobe 0.4.23debian1 works nicely: [EMAIL PROTECTED]:/# xresprobe nv id: res: 1280x800 freq: disptype: lcd/lvds It probably means that you should depend on higher versions of some packages.. XSF, you need a dependency on a modular version of xserver-xorg: xprobe.sh calls /usr/bin/Xorg directly. signature.asc Description: Digital signature
Bug#367986: Acknowledgement (sylpheed-gtk1: ..moving mail between folders within Sg1-1.0.6, crashes X.)
On Wed, May 24, 2006 at 08:11:09PM -0700, Steve Langasek wrote: On Thu, May 25, 2006 at 04:17:02AM +0200, Arnt Karlsen wrote: ..could it be a font thing? These crashes started after the font I had set up for Sylpheed-gtk1, disappeared off this box, everything else works like it should, AFAICT. Uh, it could be tied somehow to the fonts, but I don't see any way to debug it on that basis alone as I can't imagine any way that would cause an X server to crash *or* cause an app to chew up memory. GTK2 app maybe, but GTK1 was all about core (i.e. server-side) fonts, so I don't see how that could occur. signature.asc Description: Digital signature
Bug#367844: xkeycaps: FTBFS: imake config files have moved
On Sun, May 21, 2006 at 02:24:54PM -0500, Steve Langasek wrote: On Thu, May 18, 2006 at 03:11:35PM +0200, Daniel Schepler wrote: Package: xkeycaps Version: 2.47-1 Severity: serious From my pbuilder build log: ... debian/rules build dh_testdir imake -DUseInstalled -I/usr/X11R6/lib/X11/config \ -D`dpkg --print-architecture` Imakefile.c:39: error: Imake.tmpl: No such file or directory imake: Exit code 1. Stop. make: *** [build-stamp] Error 1 Isn't it sort of odd for Imake.tmpl to not be in the default search path for imake itself? Should these bugs be reassigned to xutils-dev? Not entirely: this is the exact reason why xmkmf exists. I'd say leave it on xkeycaps, to either update its search path, or use xmkmf. signature.asc Description: Digital signature
Bug#365488: Current GNOME crashes X
On Thu, May 18, 2006 at 04:16:01AM +0200, Josselin Mouette wrote: Le mercredi 17 mai 2006 à 12:26 -0500, Donald King a écrit : Ever since a GNOME upgrade around late April, I haven't been able to use GNOME at all. By downgrading to Sarge versions of the kernel, X, and GNOME, I narrowed it down to GNOME, although not to any particular package. However, it's almost certainly gnome-session or one of its dependencies. Sorry I can't be more specific, but gnome-session pulls in a big circular mess. This has nothing to do with gnome-session, this is a X server bug triggered by gnome-settings-daemon when setting the keyboard properties. If it's an X server bug, how is it causing the crash of the splash screen, which occupies an entirely different address space? To be able to log in, you have to run: gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard Behavior: When using GDM or startx, GNOME crashes during the startup screen. [...] This is a really nasty bug in Xorg 6.9, which seems to be triggered by libxklavier. It's really hurting testing users as they can't login to gnome when they have set some keyboard settings. How is going the testing migration of Xorg 7.0? As it doesn't look like it will happen soon, would it be possible to upload fixed packages for this bug to testing-proposed-updates, if the actual patch that fixed this bug is known? What's the actual bug? Have you got a backtrace? signature.asc Description: Digital signature
Bug#366427: xfonts-encodings: circular dependency: doesn't need to depend on xutils
On Mon, May 15, 2006 at 11:12:56PM -0400, David Nusinow wrote: checking for mkfontscale... no configure: error: mkfontscale is needed to build fontenc. FIXME: when we know where it is going to live, put a more informative comment here *chuckle*. Whoops. signature.asc Description: Digital signature
Bug#354490: Not as straightforward as you think
Hi, I'm the primary author/ex-maintainer of multiseat. I'd like to request that anyone who wants to package this for Debian, not do so unless: * you are either part of the X Strike Force already, or plan to collaborate very closely with them, * you have a good understanding of how the Xorg server works, and its configuration system. Due to lack of time/interest, the package never really evolved beyond 'gigantic hack' status, so it would need a lot of informed work to get it to being something maintainable. There's also a massive driver support issue: most cards are extremely fragile regarding resource routing in particular, and this is something not handled well by the multiple independent server case. I had very limited success (nVidia cards only with the binary-only nVidia driver, and only after they fixed strange bugs; some ATI cards, but not all -- a seemingly random selection) when testing over a range of cards. Co-ordination with the d-i team would also be needed, as this contains a udeb. However, I'm happy to answer any questions anyone might have about this package. Cheers, Daniel signature.asc Description: Digital signature
Bug#211765: Where have these files gone?
On Sat, May 06, 2006 at 10:32:25PM -0400, Nathanael Nerode wrote: With the modular split of Xorg 7, these files have probably scattered to different packages. Can someone suggest a good strategy for figuring out which packages currently contain the affected files? I don't want to download every single package source one at a time and grep through it, but I'll do it if that's the only way. I also suspect that most of the files have gone to a small number of packages, and that a fair number of them may have disappeared (the Imakefiles). The FreeB stuff is all in mesa, and x11proto-gl. signature.asc Description: Digital signature
Bug#366514: Automatic upgrade from Xfree86 needs to fix mouse
On Tue, May 09, 2006 at 08:55:03PM +1000, Peter Chubb wrote: I tried to upgrade from Xserver-xfree86 to xserver-xorg. The XF86Config-4 file had the mouse device as /dev/input/mice. The rewritten xorg.conf file had /dev/mouse, which doesn't exist on my system. It looks as though the info in XF86Config-4 is not consulted for the upgrade. I assume what happened is that you selected /dev/mouse in the Debconf prompts for xserver-xfree86 when you first set it up, then later modified XF86Config-4 by hand to use /dev/input/mice. In this case, the Debconf answers were migrated, but the changes to XF86Config-4 not. signature.asc Description: Digital signature
Bug#365353: missing debconf template: xserver-xorg/config/inputdevice/mouse/zaxismapping
On Tue, May 02, 2006 at 09:00:50PM -0400, David Nusinow wrote: On Tue, May 02, 2006 at 01:08:21PM +0300, Daniel Stone wrote: On Mon, May 01, 2006 at 09:08:35PM -0400, David Nusinow wrote: Right, I'm not really sure why Daniel removed the template in the ubuntu stuff. I'll look in to it and possibly add it back. Removing it will go well with my ultimate plan to dismember dexconf though, so that'll be my preference if it's something sensible. It was removed because the code in current X.Org servers should work just fine without ZAxisMapping. Sweet! Let's just kill it then. I'll add some code to the postinst to remove the questions all together. Christian, let's just make it dead and give the translators a little rest :-) Emphasis there on 'should'. Fabio found some problems so ended up adding the default ZAM back, but I don't know whether or not that's resolved in current CVS. signature.asc Description: Digital signature
Bug#365714: emacs21: FTBFS on most architectures, xaw issues.
On Tue, May 02, 2006 at 11:48:07AM +0200, Frank Küster wrote: As to the actual failure, it doesn't look as if it should be related to the NMU patch, and this is some other strange thing. On i386, it fails with i486-linux-gnu-gcc -c -DUSE_LUCID -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs21-21.4a/src -D_BSD_SOURCE -DDEBIAN -g -O2 -DPURESIZE=500 -I../src /build/buildd/emacs21-21.4a/lwlib/lwlib.c /build/buildd/emacs21-21.4a/lwlib/lwlib.c:52:27: error: X11/Xaw/Paned.h: No such file or directory make[5]: *** [lwlib.o] Error 1 Now Paned.h is in libxaw8-dev, which is installed as an indirect build-dependency. Maybe this has to do with the XOrg transition, the headers have changed there location: usr/X11R6/include/X11/Xaw/Paned.h libdevel/libxaw8-dev usr/include/X11/Xaw/Paned.h x11/libxaw-headers And maybe the underlying bug is that xaw3dg-dev still depends on libxaw8-dev | libxaw7-dev | libxaw6-dev but should have dropped libxaw8-dev? Yep, correct. libxaw7-dev | libxaw-dev would be better. signature.asc Description: Digital signature
Bug#365353: missing debconf template: xserver-xorg/config/inputdevice/mouse/zaxismapping
On Mon, May 01, 2006 at 09:08:35PM -0400, David Nusinow wrote: On Sun, Apr 30, 2006 at 12:44:01AM -0700, Steve Langasek wrote: On Sun, Apr 30, 2006 at 08:40:03AM +0200, Christian Perrier wrote: Quoting Adam Borowski ([EMAIL PROTECTED]): The debconf question xserver-xorg/config/inputdevice/mouse/zaxismapping is needed by xserver-xorg's preinst, yet its template is missing. Without it, installation fails on new installs unless manually preseeded. I grabbed this template back from the 6.9 branch, along with translations. However, I'm not involved in X packages maintenance enough for knowing whether re-adding it is the way to go. Please, XSF people, tell me if that is what needs to be done. If so, I'll apply my pending change. David added some code to the preinst which copes with the absence of the template in question, but it seems to me that the code isn't useful *at all* if we're not going to use the template. Since the purpose of this code is to convert the values for this question, and there are no other uses of this question in the config or postinst scripts, I think the correct solution is to simply drop this block of code from the config script. Right, I'm not really sure why Daniel removed the template in the ubuntu stuff. I'll look in to it and possibly add it back. Removing it will go well with my ultimate plan to dismember dexconf though, so that'll be my preference if it's something sensible. It was removed because the code in current X.Org servers should work just fine without ZAxisMapping. signature.asc Description: Digital signature
Bug#365028: xbase-clients: setxbmap man page at odds with /usr/lib/X11/xkb/README.config
On Thu, Apr 27, 2006 at 01:28:43PM +0100, Reuben Thomas wrote: The man page for setxkbmap says Only one layout is permitted. for -layout. But /usr/lib/X11/xkb/README.config has examples like: -layout us,cz,de. One of them must be wrong. Only one layout option is permitted (e.g. -layout us -layout cz -layout de), is invalid. So it's technically right, but yeah. Very clunky. signature.asc Description: Digital signature
Bug#365126: HELP!! Re: Bug#365126: wmrack - FTBFS: error: WMRack needs X Windows!!!
On Sat, Apr 29, 2006 at 08:55:16AM +0200, Andreas Metzler wrote: AC_PATH_X searches[1] for [Xt],[X11/Intrinsic.h],[XtMalloc (0)] by default, so this shouldn't have worked[2], as you do not build-depend on libxt-dev. Try purging libxt-dev and rebuild after dpkg-source -x. Er, no, that's AC_PATH_XTRA. AC_PATH_X searches for [X11],[X11/Xlib.h],[XrmInitialize ()]. Unfortunately a lot of people use AC_PATH_XTRA when they only need AC_PATH_X, but this is not one of those cases, AFAICT. Cheers, Daniel signature.asc Description: Digital signature
Bug#365028: xbase-clients: setxbmap man page at odds with /usr/lib/X11/xkb/README.config
On Sat, Apr 29, 2006 at 12:34:32PM +0100, Reuben Thomas wrote: On Thu, 27 Apr 2006, Daniel Stone wrote: On Thu, Apr 27, 2006 at 01:28:43PM +0100, Reuben Thomas wrote: The man page for setxkbmap says Only one layout is permitted. for -layout. But /usr/lib/X11/xkb/README.config has examples like: -layout us,cz,de. One of them must be wrong. Only one layout option is permitted (e.g. -layout us -layout cz -layout de), is invalid. So it's technically right, but yeah. Very clunky. In that case, you need to correct /usr/lib/X11/xkb/README.config. Also, you could clarify the man page to indicate that you can use -layout multiple times. Closing parenthesis was in the wrong place. -layout us -layout cz -layout de, is invalid. -layout us,cz,de is correct. Cheers, Daniel signature.asc Description: Digital signature
Bug#364838: xkb-data: systematically kills GNOME session during login
On Wed, Apr 26, 2006 at 10:25:35AM +0300, Martin-Éric Racine wrote: ke, 2006-04-26 kello 08:13 +0100, Daniel Stone kirjoitti: On Wed, Apr 26, 2006 at 10:07:54AM +0300, Martin-Éric Racine wrote: ke, 2006-04-26 kello 07:47 +0100, Daniel Stone kirjoitti: On Wed, Apr 26, 2006 at 09:40:28AM +0300, Martin-Éric Racine wrote: X dies half-way through the GNOME session launching. Config and logs attached. GNOME does not give me that dialog; it dies before any of the desktop becomes visible. The log you give doesn't show anything meaningful, except authentication getting screwed up. I assume the clients all die, which makes the server exit, too: check ~/.xsession-errors. .xsession-errors is empty. Grsecurity reports a signal 6 on X.org resulting from the death of child gnome-session. Well, there you have it. Indeed, but that doesn't change the cause. xkb-data is the problem. No, xkb-data *exposes* the problem. Applications should *never* crash, even when faced with invalid data, which this isn't, given that pc105/fi works just fine here. You should know this, being in NM. signature.asc Description: Digital signature
Bug#364554: mgapdesk: FTBFS: xf86Parser.h: No such file or directory
On Mon, Apr 24, 2006 at 10:52:41AM +0200, Matej Vela wrote: mgapdesk fails to build because it can't find xf86Parser.h. It used to be in xlibs-static-dev, but doesn't seem to be in any of the Xorg 7.0 packages. [...] make[3]: Entering directory `/home/mvela/deb/mgapdesk/mgapdesk-1.00.7beta/src' gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include-g -O2 -Wall -c callbacks.c callbacks.c:31:24: error: xf86Parser.h: No such file or directory [...] Correct, we're not shipping libxf86config anymore. I assume mgapdesk uses it to generate its own custom config files? signature.asc Description: Digital signature
Bug#364830: gnome-control-center: gnome-settings-daemon makes the X server segfault
On Wed, Apr 26, 2006 at 09:47:28AM +0200, Josselin Mouette wrote: Le mercredi 26 avril 2006 à 00:22 +0100, Sam Morris a écrit : When I try to log in to Gnome, the X server segfaults (leaving my console in a very bad state, I have to shell in from another machine to fix it). Attached is the X server's log file. Noticing that it dies while setting up the keymap, I logged in with just an xterm and ran gnome-settings-daemon, and the server died again. This happens since the upgrade of libxklavier10 to version 2.2-3. The output of gconftool -R /desktop/gnome/peripherals/keyboard. is also attached. There may be a bug in libxklavier (and *sigh* this wouldn't be the first one), but a X server crashing is nevertheless a symptom of a bug in the X server. Thanks for your report, I'm reassigning it. Eep. Could you please attach the output of: xkbcomp -xkb :0 - setxkbmap -layout dvorak,gb -model pc105 -option compose:rwin -print | xkbcomp -xkb - - setxkbmap -layout gb -model pc105 -option compose:rwin,altwin:super_win | xkbcomp -xkb - - Also, whether or not either of the following commands take the server down: setxkbmap -layout dvorak,gb -model pc105 -option compose:rwin setxkbmap -layout gb -model pc105 -option compose:rwin,altwin:super_win Cheers, Daniel signature.asc Description: Digital signature
Bug#365028: xbase-clients: setxbmap man page at odds with /usr/lib/X11/xkb/README.config
On Sat, Apr 29, 2006 at 12:54:01PM +0100, Reuben Thomas wrote: On Sat, 29 Apr 2006, Daniel Stone wrote: On Sat, Apr 29, 2006 at 12:34:32PM +0100, Reuben Thomas wrote: On Thu, 27 Apr 2006, Daniel Stone wrote: On Thu, Apr 27, 2006 at 01:28:43PM +0100, Reuben Thomas wrote: The man page for setxkbmap says Only one layout is permitted. for -layout. But /usr/lib/X11/xkb/README.config has examples like: -layout us,cz,de. One of them must be wrong. Only one layout option is permitted (e.g. -layout us -layout cz -layout de), is invalid. So it's technically right, but yeah. Very clunky. In that case, you need to correct /usr/lib/X11/xkb/README.config. Also, you could clarify the man page to indicate that you can use -layout multiple times. Closing parenthesis was in the wrong place. -layout us -layout cz -layout de, is invalid. -layout us,cz,de is correct. Right, so you can clarify that in the man page. Only one layout option is permitted, but it can specify multiple comma-separated layouts, e.g. Something like that? Sounds alright to me. signature.asc Description: Digital signature
Bug#364838: xkb-data: systematically kills GNOME session during login
On Wed, Apr 26, 2006 at 09:40:28AM +0300, Martin-Éric Racine wrote: ke, 2006-04-26 kello 06:03 +0100, Daniel Stone kirjoitti: On Wed, Apr 26, 2006 at 04:34:38AM +0300, Martin-Éric Racine wrote: Since tonight's dinstall run, a libxklavier10 version that explicitely depends upon xkb-data entered Testing. This combination systematically and repeatedly kills X. After 4 hours of debuging, what fixed it was dpkg -P --force-depends xkb-data (or alternately, pinning xkb-data to priority -1 and reverting to the previous libxklavier10 release). You need to be specific. How does it 'kill' GNOME? Can you attach your xorg.conf? Can you also attach your Xorg.0.log from a crashing session? If GNOME gives you the dialog where it asks you to attach the output from two commands if reporting a bug, can you attach the output from those two commands? X dies half-way through the GNOME session launching. Config and logs attached. GNOME does not give me that dialog; it dies before any of the desktop becomes visible. The log you give doesn't show anything meaningful, except authentication getting screwed up. I assume the clients all die, which makes the server exit, too: check ~/.xsession-errors.
