Bug#347857: xdm: Xsetup does not get run
Package: xdm Version: 6.9.0.dfsg.1-3 Severity: normal Upon upgrading xdm to version 6.9.0.dfsg-1.3, dpkg silently rewrote /etc/X11/xdm/xdm-config such that my Xsetup script does not get run anymore. This is contrary to the xdm(1) manual page which clearly states that the Xsetup script will get run: After resetting the X server, xdm runs the Xsetup script to assist in setting up the screen the user sees along with the xlogin widget. If there is some good reason why the default configuration should prevent local customizations of the login screen (such as installing a nice background picture, or starting some buttons to shutdown or reboot the machine), this should at least be documented. Neither the changelog nor the NEWS file warned me that my local setup would stop working. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27makholm6 Locale: LANG=en_DK, LC_CTYPE=en_DK.iso88591 (charmap=ISO-8859-1) Versions of packages xdm depends on: ii cpp 4:4.0.2-2 The GNU C preprocessor (cpp) ii debconf [debconf-2.0] 1.4.67 Debian configuration management sy ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libice6 6.9.0.dfsg.1-3 Inter-Client Exchange library ii libpam-modules0.79-3 Pluggable Authentication Modules f ii libpam-runtime0.79-3 Runtime support for the PAM librar ii libpam0g 0.79-3 Pluggable Authentication Modules l ii libselinux1 1.28-2 SELinux shared libraries ii libsm66.9.0.dfsg.1-3 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-3 X Window System protocol client li ii libxau6 6.9.0.dfsg.1-3 X Authentication library ii libxaw8 6.9.0.dfsg.1-3 X Athena widget set library ii libxdmcp6 6.9.0.dfsg.1-3 X Display Manager Control Protocol ii libxext6 6.9.0.dfsg.1-3 X Window System miscellaneous exte ii libxinerama1 6.9.0.dfsg.1-3 X Window System multi-head display ii libxmu6 6.9.0.dfsg.1-3 X Window System miscellaneous util ii libxp66.9.0.dfsg.1-3 X Window System printing extension ii libxpm4 6.9.0.dfsg.1-3 X pixmap library ii libxt66.9.0.dfsg.1-3 X Toolkit Intrinsics ii xbase-clients 6.9.0.dfsg.1-3 miscellaneous X clients xdm recommends no packages. -- debconf information: xdm/stop_running_server_with_children: false xdm/daemon_name: /usr/bin/X11/xdm * shared/default-x-display-manager: xdm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepting .Xdefaults by default
Scripsit Branden Robinson <[EMAIL PROTECTED]> > On Thu, Apr 01, 2004 at 12:26:23AM +0100, Henning Makholm wrote: > > Debian does not use the name .Xdefaults bu default, but instead > > .Xdefaults-. That is presumably intentional. > It is. The reason is that because the application-defaults are loaded > client-side, you may want to customize them on a per-host basis. You > already get this with the server-side resources because your X session > runs out of $HOME. Not necessarily. In fact I have accounts on three different university sites where my $HOME is shared between all workstations and xdm servers in the department. They all load the same .Xresources when I log in. That would have caused me trouble if I had happened to physically move between differently-equipped workstations often. (Of course I know how to solve this by appropriate ad-hoc magic in .xsession, and splitting .Xresources by hostname would not be a good solution nevertheless, so I'm not proposing to change the default behavior of Debian's X packages). > > If that does not work (and you're sure its not your own fault, or > > the individual application's), file a bug report against libXt6. > The package's name is libxt6 (all lowercase), but yes. Curses, foiled again! I just tried 'dpkg -L libXt6' and it worked. -- Henning Makholm "Al lykken er i ét ord: Overvægtig!"
Bug#211765: Non-free licenses in XFree86 package
Package: xfree86 Version: 4.2.1-6 Severity: serious The following sections of the debian/copyright file for xfree86: 2.4 GLX Public License 2.5 CID Font Code Public License contain clauses which debian-legal has found to be non-free according to the DFSG - see thread starting at http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00723.html Code covered by these licenses need to be relicensed or removed from Debian's distribution of XFree86. The licence "SGI FREE SOFTWARE LICENCE B" which is found in the copyright file for version 4.2.1-11, also contains a non-free clause (discussed in the same thread). Since only the Debian revision differs, I suppose that whatever code that is covered by will also be present in 4.2.1-6. Since the BTS wants a version, I give the one curtrently in sarge (which is where we need most urgently to keep track of release-critical issues), but the ones in woody and sid, plus the expermental 4.3.0 packages, all look to be affected too. -- Henning Makholm"*Vi vil ha wienerbrød!*"
Bug#211765: Non-free licenses in XFree86 package
Package: xfree86 Version: 4.2.1-6 Severity: serious The following sections of the debian/copyright file for xfree86: 2.4 GLX Public License 2.5 CID Font Code Public License contain clauses which debian-legal has found to be non-free according to the DFSG - see thread starting at http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00723.html Code covered by these licenses need to be relicensed or removed from Debian's distribution of XFree86. The licence "SGI FREE SOFTWARE LICENCE B" which is found in the copyright file for version 4.2.1-11, also contains a non-free clause (discussed in the same thread). Since only the Debian revision differs, I suppose that whatever code that is covered by will also be present in 4.2.1-6. Since the BTS wants a version, I give the one curtrently in sarge (which is where we need most urgently to keep track of release-critical issues), but the ones in woody and sid, plus the expermental 4.3.0 packages, all look to be affected too. -- Henning Makholm"*Vi vil ha wienerbrød!*" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#179286: xterm: alt-return has a strange effect
Alessandro Dalvit <[EMAIL PROTECTED]> writes > When typing alt+return the cursor goes up one line (causing other > text to scroll downwards when it reaches the top of the window). > The most boring fact is that the terminal keeps an abnormal > behavior when scrolling in the history with the up key: as soon as > it tries to show the command line with these codes, the text layout > gets broken as the cursor writes to already written areas. This is consistent with the documented behavior of xterm when the eightBitInput resource is "yes" (which it is by default). In this state, the meta key makes xterm set the most significant-bit of the characters you type. In the present case it converts the usual ASCII CR, 0x0D that Return produces to 0x8D. If your locale is not C or POSIX, bash will default to 8-bit clean mode and not recognize 0x8D as a control character but instead try to echo it to the terminal. When xterm *recieves* an 0x8D it acts on it, correctly, as the control character RI and performs a "Reverse Index" operation; i.e. moving the cursor upwards and scrolling backwards if necessary. It is arguably a bug (or at least a shortcoming) in bash that it treats 0x8D as a printing character even in 8-bit-clean mode. The bash source (bash-2.05b.orig/lib/realine/emacs_keymap.c) says that it is because "these might be used in some character set", but even so the Right Thing would be to ask the locale-enabled ctype functions which characters are printable. Nonprintable characters should be unbound by default. However, I *also* think that it is wrong for Debian to ship an xterm that has eightBitInput set by default. Many of xterm's resources have counterintuivite names; eightBitInput really means "I'm only ever going to input 7-bit characters, so xterm is welcome to appropriate the 8th bit for its own purposes". I think the default configuration should be 8-bit clean - in other words, the default /etc/X11/app-defaults/XTerm should contain *eightBitInput: false -- Henning Makholm "The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors."
Bug#182292: Debian Bugs information: logs for Bug#182292
> Message received at [EMAIL PROTECTED]:
> 1) Start mc on xterm
> 2) Ctrl-O
> 3) Start new mc
> 4) Ctrl-O Ctrl-O
> 5) F10
> 6) Ctrl-O
> 7) F10
> Now try to use mouse for working with clipboard. Mouse is broken on this
> xterm. Pressing the buttons results in something like "h,#h,"
The symptom is that the procedure leaves xterm in a "mouse reporting"
state where mouseclicks are translated to escape sequences that are
sent down the pseudotty. Mc uses this to enable point-and-click with
the mouse, and usually turns it off before it exits.
(The reason why the behavior does not occur with rxvt is that mc
refuses to even try to enable mouse reporting when $TERM is not
xterm-foo, even though rxvt does implement the feature).
Here is what happens with two telescoped mc processes, where I only
note occurences of the control sequences
^[[?1001s "save mouse reporting flag"
^[[?1001r "restore mouse reporting flag"
^[[?1000h "set mouse reporting mode"
^[[?1000l "clear mouse reporting mode"
--state-
I type mc 1 sends mc 2 sendscurrrent saved
1 mc save off off
2setonoff
3(draws itself)
4 ^Oclear off off
5restoreoff off
6 mcsaveoff off
7 set onoff
8 (draws itself)
9 ^Osave onon
10setonon
11(draws itself)
12 ^Oclear off on
13restoreonon
14 F10 ("exit y/n?" box)
15 clear off on
16 restore on (!!) on
17 ^Osave onon
18setonon
19(draws itself)
20 F10("exit y/n?" box)
21clear off on
22restoreonon
The problem arises between the two ^O's in line 9 and 12. The inner mc
never sees these keypresses; they are captured by the outer one. The
outer mc temporarily turns mouse reporting on, but tries to preserve
the terminal state by wrapping its actions in a save/restore
pair. Superficially, that works well: after line 13 the terminal is
still in mouse reporting mode just as before line 9. But the save in
line 9 has clobbered the old saved value from line 6 that the inner mc
plans to restore in step 16. Therefore mouse reporting is still on
efter step 16, and this faulty state is again preserved by the
save/restore pair in lines 17-22.
In my HO, xterm is acting in agreement with its specification; the
basic problem is that mc uses "save" and "restore" as if they were
"push" and "pop", which they aren't. But it does not have many other
options; xterm does not offer control sequences to query the current
mouse-tracking state.
An attempt to solve the problem by having the to mc's actively
coordinate their state is doomed to fail - the scenario could work
with *any* mouse-aware program in place of the inner mc. A
quasi-sultion would work in most case woud be that all programs the
use mouse reporting stopped generatinng save and restore and simply
turing mouse reporting off unconditionally when they release the
screen. Then, reporting would sometimes be unexpectedly off after
mc has interrupted itself, but that is surely better than it being
unexpectedly *on*.
--
Henning Makholm "Special: see sub-basement floors 3 and 4"
Bug#29363: Debian Bugs information: logs for Bug#29363
[EMAIL PROTECTED] reported this bug ages ago, and it still sits in the
BTS, being flagged "inportant":
> If I press shift-kp_9 in an xterm (which is running on my Debian
> machine) at some stage after the xterm has beeped, the xterm
> seg-faults.
[...]
> I have reproduced this on the local (Debian) X server using the
> following (key 96 is F12):
>
> Run: xmodmap -e 'keycode 96 = F27'
> In an xterm type: echo -e \\a
> Then press: shift-F12
> Segmentation fault
>
> It seems to have this effect for function keys F21 onwards, and any
> keycode I tried.
[...]
> xbase3.3.2.3-2
This bug is no longer present in xterm, and can be closed.
To support this assertation, here is a detailed explanation of what
went wrong in the XFree86 3.3.2.3 source:
* Input() in input.c (cvsweb.xfree86.org revision 3.11.2.3) calls
decfuncvalue() in input.c to determine the number in the VTxxx
control sequence for the keysym.
* When the keysym is an F-key greater than F20, decfuncvalue() returns
-1, signifying "unknown key".
* Without checking (yet) for the "unknown key" condition, Input() notices
that shift is down and passes the DEC number to udk_lookup() in misc.c
(cvsweb.xfree86.org revision 3.17.2.4) to check if the key has had
a string defined for it by escape sequences. The source for
udk_lookup is
char *
udk_lookup(keycode, len)
int keycode;
int *len;
{
if (keycode < MAX_UDK) {
*len = user_keys[keycode].len;
return user_keys[keycode].str;
}
return 0;
}
thus when the keycode argument is -1, it indexes before the
beginning of the user_keys array.
* user_keys is a static array declared just before the definition
of hexvalue() in misc.c. It so happens that the most closely
preceding static variable that is not #ifdef'ed away (ALLOWLOGGING
is disabled by default).
static long lastBellTime;
immediately before the definition of Bell(). This means that
"user_keys[-1].str" ends up being an alias for lastBellTime.
* Initially lastBellTime will be 0, so udk_lookup(-1,&nbytes) indeed does
return 0. But as soon as the bell sounds, lastBellTime changes,
and the timestamp ends up as the return value from udk_lookup.
* Input() proceeds to try to dereference the timestamp as a char*,
which triggers a SIGSEGV.
This problem wias fixed in XFree.3.9.17b (cvs revision 3.46 of
misc.c), where the conditional in udk_lookup() was changed to read
if (keycode >= 0 && keycode < MAX_UDK) {
The xterm in Debian stable is currently 4.1.0-16; therefore this bug
is not relevant anymore.
--
Henning Makholm "We will discuss your youth another time."
Bug#189764: Inconsistent doc for shifted keypad in xterm's terminfo entry
Package: xterm Version: 4.2.1-3 Severity: minor /usr/share/doc/xterm/xterm.terminfo.gz contains # The terminfo defines some special keys which are documented as "shifted", # e.g., kDC is shifted-delete-character. In this description, the modifier is # actually the control key, to avoid conflict with the common usage of shifted # pageup and pagedown for window manager functions. # xterm-xfree86|xterm-new|xterm terminal emulator (XFree86), npc, kDC=\E[3;2~, kEND=\EO2F, kHOM=\EO2H, where the funny thing is that "\E[3;2~" is actually what xterm sends when one presses shift-del, rather than control-del. Control-del would be \E[3;5~. Similarly for the other shifted capabilities. Thus the actual terminfo code differs from what the comment claims about it. Interestingly, the actual terminfo record for xterm in ncurses-base (5.3.20021109-2) contains, according to infocmp: # Reconstructed via infocmp from file: /etc/terminfo/x/xterm xterm|X11 terminal emulator, am, bce, km, mc5i, mir, msgr, npc, xenl, (... blah blah blah ...) kDC=\E[3;5~, kEND=\EO5F, kHOM=\EO5H, kIC=\E[2;5~, kLFT=\EO5D, kNXT=\E[6;5~, kPRV=\E[5;5~, kRIT=\EO5C, (... blah blah blah ...) which matches the *comment* in the xterm doc file, rather than the actual *code*. -- Henning Makholm "Eat the bunnies. Stomp the hamsters. And boil three mice for gold!"
