1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
kdebase (4:3.4.2-3) unstable; urgency=low
*** Changes to KDM conffiles:
* Users upgrading KDM from 3.3.x, will find that KDM no longer uses the
/etc/trinity/kdm/Xservers file, if /etc/trinity/kdm/kdmrc was updated to
the version shipped with KDM 3.4.x. The package upgrade scripts
will not remove Xservers even if kdmrc has been upgraded, if they detect
local modifications. This should allow administrators to merge their
Xservers changes into kdmrc before themselves removing Xservers. The new
ServerArgsLocal key in kdmrc is where most old Xservers customizations
should be placed.
* Irrespective of the removal of the Xservers file, we highly recommend that
all administrators accept the installation of the updated kdmrc file
during the package upgrade. Many important changes to KDM's defaults have
been made, and KDM is exceedingly bad at handling anything but the latest
kdmrc format, so the nuissance of re-customizing KDM will likely prove
less than the nuissance of dealing with a KDM that isn't working properly.
If you have already upgraded KDM package without accepting the new kdmrc,
purging and reinstalling the package should achieve the desired result.
*** Changes to user login script handling:
* Another important change that users upgrading from KDM 3.3.x may notice
is that KDM's ability to source personal login scripts, long disabled, has
been restored. The exact files sourced on login will depend on the user's
choice of shell. For users of bash, KDM will source /etc/profile, followed
by ~/.bash_profile or, if that is not present, ~/.profile. Note that KDM
is NOT spawning a login shell, but is merely mimicking the behaviour that
popular shells would exhibit if they were login shells, by manually
sourcing the customary login scripts. /etc/trinity/kdm/Xsession controls this
behaviour.
* The important downside of the above approach is that KDM will utterly fail
to start a user's session if the newly sourced files contain certain types
of commands. For instance, many commands will cause the login attempt to
fail because they expect an interactive shell, or because you are trying
to "exec" something that cannot provide an X session. For instance,
"exec ksmserver" will launch KDE, but "exec bash" will fail. Thus if you
are unsure why KDM is refusing to start your session, try commenting out
elements of the newly sourced login scripts, and you may find the problem
resolved.
-- Debian Qt/KDE Maintainers <[email protected]> Thu, 8 Sep 2005 11:13:41 -0400
kdebase (4:3.3.2-1) unstable; urgency=low
* Users upgrading from KDE 3.2 might find that their keyboards seem no longer
to work in KDM. This problem is caused by a change in KDE's handling of
virtual terminals. The setting which puts KDM on vt7, which was contained
in /etc/trinity/kdm/Xservers, has changed, and is also now located in
/etc/trinity/kdm/kdmrc.
* Users who, when upgrading to KDE 3.3, opted to replace their Xservers file
with the version shipped by the package, but chose to retain their
/etc/trinity/kdm/kdmrc file, will thus have a KDM configuration which nowhere
contains a setting which properly places KDM on vt7. This can result in a
race condition which has the end effect of breaking the keyboard when using
KDM.
* The solution to the problem is either to replace both of Xservers and
kdmrc, or neither, when upgrading to KDE 3.3 for the first time.
* Users already stuck can, after killing KDE, purge and re-install the kdm
package, ensuring that the latest, fresh copies are installed.
Alternatively, they can edit /etc/trinity/kdm/kdmrc and add the following
line:
ServerVTs=-7
in the [General] section of the file.
-- Debian Qt/KDE Maintainers <[email protected]> Sun, 23 Jan 2005 16:11:07 +0100
|
