Bug#797008: xterm: not logging to utmp
Package: xterm Version: 319-1 Severity: normal Apparently since the latest xterm version 319-1 which arrived on my Sid machine 2015-08-23 14:52 -0600 xterm no longer logs entries to the utmp file. Using "last -10" shows the most recent entries to have been logged prior to that update. Even explicitly adding +ut does not log to utmp. xterm +ut Downgrading to 318-2 fixes the problem. Thank you for maintaining xterm in Debian. Thanks, Bob -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xterm depends on: ii libc6 2.19-19 ii libfontconfig1 2.11.0-6.3 ii libice6 2:1.0.9-1+b1 ii libtinfo5 6.0+20150810-1 ii libutempter01.1.6-1 ii libx11-62:1.6.3-1 ii libxaw7 2:1.0.13-1 ii libxft2 2.3.2-1 ii libxmu6 2:1.1.2-1 ii libxpm4 1:3.5.11-1+b1 ii libxt6 1:1.1.4-1+b1 ii xbitmaps1.1.1-2 Versions of packages xterm recommends: ii x11-utils 7.7+3 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
Bug#581653: xterm: please add pointerMode change to NEWS.Debian file
Package: xterm Version: 258-1 Severity: wishlist Previously (through Lenny) the default XTerm pointerMode was pointerMode (class PointerMode) Specifies when the pointer may be hidden as the user types. It will be redisplayed if the user moves the mouse, or clicks one of its buttons. 0 never. This is the default. 1 the application running in xterm has not activated mouse mode. 2 always. This has changed in Squeeze. And it is quite a user visible change. 0 never 1 the application running in xterm has not activated mouse mode. This is the default. 2 always. Since it was such a visible change I know I immediately went looking for it in a NEWS entry to find how to control this behavior. Of course it is documented in the man page but it would have been nice if this information could have been and found more easily in a NEWS.Debian file. Let me suggest the following as some place to start. The default value for 'pointerMode' has changed. 'pointerMode' specifies when the pointer may be hidden as the user types. It will be redisplayed if the user moves the mouse, or clicks one of its buttons. Previously the default value was "0" meaning never hide the pointer. The default is now "1" meaning hide the pointer after the user has typed, if the xterm has not activated mouse mode. To restore the previous behavior set the X resource XTerm*pointerMode to "0". (e.g. XTerm*pointerMode:0) Thanks, Bob -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100514171422.27586.26288.report...@hysteria.proulx.com
Bug#581647: xterm: README.Debian refers to non-existent x11-common/FAQ file
Package: xterm Version: 258-1 Severity: minor The /usr/share/doc/xterm/README.Debian file contains this: Newcomers to the X Window System should first read the Debian X FAQ (Frequently Asked Questions list): /usr/share/doc/x11-common/FAQ.gz. You can view this file with your favorite pager program after decompressing it. For example: $ zcat /usr/share/doc/x11-common/FAQ.gz | pager However that file does not exist: $ ls -log /usr/share/doc/x11-common/ total 240 -rw-r--r-- 1801 Jan 6 09:41 NEWS.Debian.gz -rw-r--r-- 1184 Sep 29 2009 TODO -rw-r--r-- 1 194817 Jan 15 2009 changelog.Debian.old.gz -rw-r--r-- 1 28870 May 7 05:34 changelog.gz -rw-r--r-- 1 3232 Jan 15 2009 copyright Package: x11-common Version: 1:7.5+6 Thanks, Bob Versions of packages xterm depends on: ii libc6 2.10.2-8 Embedded GNU C Library: Shared lib ii libfontconfig12.8.0-2.1 generic font configuration library ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libncurses5 5.7+20100313-2 shared libraries for terminal hand ii libutempter0 1.1.5-3A privileged helper for utmp/wtmp ii libx11-6 2:1.3.3-3 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii xbitmaps 1.1.0-1Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.5+3 X11 utilities ii xutils1:7.5+6X Window System utility programs m Versions of packages xterm suggests: pn xfonts-cyrillic(no description available) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100514163451.16095.61600.report...@hysteria.proulx.com
Bug#496519: Missing dependency on libcompizconfig0
Vincent Danjean wrote: > I suffered from #496519 I as well. > So, I want to report this useless backtrace and see that the 'compiz' package > itself was not installed. So I installed it with its suggestion: > 'compizconfig-settings-manager'. > > To be sure, I retried, and this time it was working! Confirmed. I get the same result. > I checked that 'compiz' was really only a metapackage (removing it > does not change anything). But removing libcompizconfig0 makes > /usr/bin/compiz segfault again. And reinstalling it makes it > working. > So, I think you are missing a dependency on libcompizconfig0 somewhere > (compiz-core ?, compiz-plugins ?) Agreed. Installing libcompizconfig0 corrected the segfault. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xsession and login shells
Marc Wilson wrote: > Bob Proulx wrote: > > Xsession does not spawn a login shell. > > Why should it? * Because it provides the most user convenient way for the user to log in and have their login environment. * Because not doing so has been a long term problem for users. * Because not doing so causes there to be a difference between logging in with xdm versus logging in with ssh. * Because this is a needless distro difference and it would be useful to converge on behavior. > There's no shell running. When the user starts a terminal window, such as an xterm, then the shell is running at that time in that window. But even if I launch a graphical, non-terminal, application I will want that application to have my login environment available to it. > If the user is starting X from a console prompt, then their > environment is already initialized, Agreed. In those cases the user's profile will be sourced again. That is a very small penalty. Avoiding that is not an optimization that I think is good to make. It does no harm. Compared to the time it takes X to load and initialize the time penalty is insignificant. User's who log in with text mode and then start X tend to be the more advanced, long time unix users. They are also the ones who know better the workings of the system and are not as troubled by these things. > and if they're using a display manager, then it's the display > manager's problem if it wants to source environment variables (which > is what this is really about), Agreed again. That is exactly the point of this. When a user logs into a graphical login session they expect their environment to be sourced. Currently it is not. Currently a user must know to create a ~/.xsession file with '#!/bin/bash --login' or whatever for their shell in order to load their login environment. I am going to ignore your subtle point that [gkx]dm is not the same as Xsession. To the user logging in they can't tell the difference. > not that the display manager has any business doing it either. Why should logging in with a graphical login manager be different than logging in with ssh? > And yes, I've read the bug you point to. I don't agree with it. That is always your prerogative. Do you have an alternative suggestion? I am interested in any and all options. > If the user wants a particular set of environment variables, then > their ~/.xsession should source $ENV (or the csh equivalent, which I > dis-remember). But this is also something that only a more advanced Debian user knows to do. And if you are not running Debian then you don't need to do this since other distros do load your login environment. If you were to compare two distros side by side this really looks like breakage in Debian. The proposed change does not make it more difficult for an advanced user. But leaving it as it is today does keep it more difficult for the typical user. Can anyone think of alternatives? How can we solve this problem for our users? Bob pgpI3mN9c3rWA.pgp Description: PGP signature
Xsession and login shells
Xsession does not spawn a login shell. There has been much discussion lately on the debian lists about the problems users see because Xsession does not spawn a user shell. This has been causing a lot of trouble for users. It is different than other distros. Much discussion ensued after martin f krafft <[EMAIL PROTECTED]> filed this as a bug against kdm. Many of us now believe the problem really lies with xfree86-common's /etc/X11/Xsession. I plan on reassigning Bug#250765 to xfree86-common but wanted to introduce the problem here first and to get people's comments on this problem. Please look at Bug#250765 and comment on the solution proposed there. In summary it is to change /etc/X11/Xsession so that it spawns the user's $SHELL as a login shell. This converges Debian with at least one other popular distro and provides the user with a login environment. Thanks Bob pgpc2mc1YMM4K.pgp Description: PGP signature
Re: backing store not enabled by default?
Michel Daenzer wrote: > Bob Proulx wrote: > > The current train of thought here is to require that X on linux always > > runs with backing store. Which means starting the X server with +bs > > or adding 'Option "backingstore"' to the XF86Config-4 file. > > You can choose between that or fixing the code. Did you mean the XFree86 code or our in house code? My understanding is that our own code was not "broken". It gets an expose event and it must redraw. But this can take a while on a complicated image. With backing store enabled it is very fast because it avoids this operation. Which sounds much more efficient. How do other X applications handle this? Does everyone just brute force through it and suffer the redraw time? > Backing store is disabled by default in XFree86 because the current > implementation is inefficient. Does inefficient imply broken functionality? Inefficient how? Does it leak memory? Looking for a way to get a handle on the issue. What is the downside to enabling backing store "+bs" on the server. It sounds like a safe default to me right now. Thanks Bob pgpL19bfVx8ti.pgp Description: PGP signature
Re: backing store not enabled by default?
Michel Daenzer wrote: > Bob Proulx wrote: > > The current train of thought here is to require that X on linux always > > runs with backing store. Which means starting the X server with +bs > > or adding 'Option "backingstore"' to the XF86Config-4 file. > > You can choose between that or fixing the code. Did you mean the XFree86 code or our in house code? My understanding is that our own code was not "broken". It gets an expose event and it must redraw. But this can take a while on a complicated image. With backing store enabled it is very fast because it avoids this operation. Which sounds much more efficient. How do other X applications handle this? Does everyone just brute force through it and suffer the redraw time? > Backing store is disabled by default in XFree86 because the current > implementation is inefficient. Does inefficient imply broken functionality? Inefficient how? Does it leak memory? Looking for a way to get a handle on the issue. What is the downside to enabling backing store "+bs" on the server. It sounds like a safe default to me right now. Thanks Bob pgp0.pgp Description: PGP signature
backing store not enabled by default?
Looking for an education... On hpux 11.11 the following produces: xdpyinfo | grep backing options:backing-store YES, save-unders YES In woody the following produces: xdpyinfo | grep backing options:backing-store NO, save-unders NO Which appears to mean that application requests such as the following have no effect. (This is very old code and I am not an X11 programmer so I will just assume up front that some types will have changed.) XSetWindowAttributes attr; unsigned long vm = CWBackingStore; attr.backing_store = Always; XChangeWindowAttributes(XtDisplay(graphics),XtWindow(graphics),vm,&attr); Which means that at least this application does not get any backing store and is very slow when processing window events. This application is an in house graphics program which has a very old cold base. I am not an X programmer myself and am just helping out other folks with this problem. With backing store it has fine performance. So I am confused and looking for information. Are there no applications which need backing store these days? I would have assumed that many applications would have benefited from this and being available was normal. Or perhaps something completely different is needed or is going on? The current train of thought here is to require that X on linux always runs with backing store. Which means starting the X server with +bs or adding 'Option "backingstore"' to the XF86Config-4 file. I don't really like either of those options since it would seem to lead to a messy configuration problem. Words of wisdom? Thanks Bob pgpaBfmLacH99.pgp Description: PGP signature
backing store not enabled by default?
Looking for an education... On hpux 11.11 the following produces: xdpyinfo | grep backing options:backing-store YES, save-unders YES In woody the following produces: xdpyinfo | grep backing options:backing-store NO, save-unders NO Which appears to mean that application requests such as the following have no effect. (This is very old code and I am not an X11 programmer so I will just assume up front that some types will have changed.) XSetWindowAttributes attr; unsigned long vm = CWBackingStore; attr.backing_store = Always; XChangeWindowAttributes(XtDisplay(graphics),XtWindow(graphics),vm,&attr); Which means that at least this application does not get any backing store and is very slow when processing window events. This application is an in house graphics program which has a very old cold base. I am not an X programmer myself and am just helping out other folks with this problem. With backing store it has fine performance. So I am confused and looking for information. Are there no applications which need backing store these days? I would have assumed that many applications would have benefited from this and being available was normal. Or perhaps something completely different is needed or is going on? The current train of thought here is to require that X on linux always runs with backing store. Which means starting the X server with +bs or adding 'Option "backingstore"' to the XF86Config-4 file. I don't really like either of those options since it would seem to lead to a messy configuration problem. Words of wisdom? Thanks Bob pgp0.pgp Description: PGP signature
Re: ~/.xsession not read
Matthijs Melchior wrote: > I think this is correct behaviour, systems like Kde and Gnome have their > own session manager to start anything you want > [/usr/bin/gnome-session uses ~/.gnomerc for customizations and logs > everything in ~/.gnome-errors. Expect kde to have similar setup] I faced a similar issue with kde recently and this is what my research found. http://www.kde.org/documentation/faq/configure.html#id2913380 "9.7. KDE (kdm) does not read my .bash_profile!". The login managers xdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files. I think I understand why they did that. This is my conjecture. As soon as you open up the system kde startup to running user scripts there are now a zillion reasons why kde might not start up all pointing to the user files being buggy. It is very common for a user to have a problem in their .profile. And when that happens, blupt!, you are back to the login screen. CNTL-ALT-F2 and failsafe modes are your friends in that case. Also, those scripts are run with 'set -e' which definitely requires special script handling. I don't know why people love that mode so much but trying to run a user .profile and also trying to run in -e mode is insane. But let's assume you turn that off for running the user scripts. Then you have to handle different shells. Do you run in /bin/sh mode? Makes sense, that is standard. But then bash users can't load /etc/bash_completion for one example. Why should it? It is a bash specific mode not /bin/sh. And how do you handle users with ksh, zsh and other similar shells? So I think they took the road of the system startup only running system scripts by default just so that they could reliably start up always. No complaints from the clueless that it does not start. And truly I think many use it for a simple newbie environment for just the reasons that it is very reliable. And by pushing the problem off to the local admin they avoid the problem of shells and other such trouble entirely. But meanwhile I still am not happy with the fact that it leads to only local, ad-hoc, non-standard solutions to the problem. I still need to deal with the problem on my site. I have dropped a new script in place in Xsession.d/95 that effectively does this. set +e test -f /etc/profile && . /etc/profile test -f $HOME/.Xprofile && . $HOME/.Xprofile And then I deal with users who complain that it is not loading their profiles and then after they try .Xprofile they complain that they can no longer log into the machine because of errors in their files. Sigh. That is when I started to understand at least one reason why it was not done by default. Just my two cents... Bob pgpD3Cw6167pi.pgp Description: PGP signature
Re: ~/.xsession not read
Matthijs Melchior wrote: > I think this is correct behaviour, systems like Kde and Gnome have their > own session manager to start anything you want > [/usr/bin/gnome-session uses ~/.gnomerc for customizations and logs > everything in ~/.gnome-errors. Expect kde to have similar setup] I faced a similar issue with kde recently and this is what my research found. http://www.kde.org/documentation/faq/configure.html#id2913380 "9.7. KDE (kdm) does not read my .bash_profile!". The login managers xdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files. I think I understand why they did that. This is my conjecture. As soon as you open up the system kde startup to running user scripts there are now a zillion reasons why kde might not start up all pointing to the user files being buggy. It is very common for a user to have a problem in their .profile. And when that happens, blupt!, you are back to the login screen. CNTL-ALT-F2 and failsafe modes are your friends in that case. Also, those scripts are run with 'set -e' which definitely requires special script handling. I don't know why people love that mode so much but trying to run a user .profile and also trying to run in -e mode is insane. But let's assume you turn that off for running the user scripts. Then you have to handle different shells. Do you run in /bin/sh mode? Makes sense, that is standard. But then bash users can't load /etc/bash_completion for one example. Why should it? It is a bash specific mode not /bin/sh. And how do you handle users with ksh, zsh and other similar shells? So I think they took the road of the system startup only running system scripts by default just so that they could reliably start up always. No complaints from the clueless that it does not start. And truly I think many use it for a simple newbie environment for just the reasons that it is very reliable. And by pushing the problem off to the local admin they avoid the problem of shells and other such trouble entirely. But meanwhile I still am not happy with the fact that it leads to only local, ad-hoc, non-standard solutions to the problem. I still need to deal with the problem on my site. I have dropped a new script in place in Xsession.d/95 that effectively does this. set +e test -f /etc/profile && . /etc/profile test -f $HOME/.Xprofile && . $HOME/.Xprofile And then I deal with users who complain that it is not loading their profiles and then after they try .Xprofile they complain that they can no longer log into the machine because of errors in their files. Sigh. That is when I started to understand at least one reason why it was not done by default. Just my two cents... Bob pgp0.pgp Description: PGP signature
Re: my x logs out after 15 minutes!!!
Sven Luther wrote: > On Fri, Jan 24, 2003 at 02:46:41PM +, giotto wrote: > > > > if dont touch the keybord my X logs out after 15 minutes :( > > but if you touch the keyboard, it is ok, right ? Is it really X or is it autolog? apt-cache show autolog Autolog terminates connections considered to be idle based on a large variety of parameters. IIRC: ls -ld /etc/autolog.conf Bob msg05476/pgp0.pgp Description: PGP signature
Re: my x logs out after 15 minutes!!!
Sven Luther wrote: > On Fri, Jan 24, 2003 at 02:46:41PM +, giotto wrote: > > > > if dont touch the keybord my X logs out after 15 minutes :( > > but if you touch the keyboard, it is ok, right ? Is it really X or is it autolog? apt-cache show autolog Autolog terminates connections considered to be idle based on a large variety of parameters. IIRC: ls -ld /etc/autolog.conf Bob pgpsPRRmJJyPv.pgp Description: PGP signature
