FS#32193 - [kdebase-workspace] install file needs to run genkdmconf

Attached to Project: Arch Linux
Opened by Greg (dolby) - Wednesday, 24 October 2012, 07:57 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 06 November 2012, 21:36 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andrea Scarpino (BaSh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

genkdmconf is used to generate configuration files for kdm.
it reads /usr/share/config/kdm/kdmrc and creates the face directory /usr/share/apps/kdm/faces and writes back to /usr/share/config/kdm/kdmrc.

if it isnt run you get this error in the logs:
kdm_greet[238]: Cannot load /usr/share/apps/kdm/faces/.default.face: No such file or directory

genkdmconf needs to run in post_install() maybe with --no-old and figure out a way to remove /usr/share/apps/kdm/faces in post_remove() as genkdmconf cant do that on it own.

there was an old bug report for this:  FS#13954  which is closed as 'upstream' but its really downstream.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 06 November 2012, 21:36 GMT
Reason for closing:  Fixed
Additional comments about closing:  kdebase-workspace 4.9.2-6
Comment by Andrea Scarpino (BaSh) - Wednesday, 24 October 2012, 08:50 GMT
I'll use genkdmconf --no-old --no-backup in post_install.

Shouldn't genkdmconf be run in post_update too?
Comment by Greg (dolby) - Wednesday, 24 October 2012, 09:24 GMT
I guess it should.
Comment by Greg (dolby) - Wednesday, 24 October 2012, 10:20 GMT
Note that this rewrites the files in /usr/share/config/kdm/ saving the pre-existing ones as .bak.
So this is also relevant to  FS#14252 . I wonder how other distributions handle this.
Comment by Andrea Scarpino (BaSh) - Thursday, 25 October 2012, 10:27 GMT
Fixed on trunk.
Comment by J. Berger (jmb) - Thursday, 01 November 2012, 08:42 GMT
genkdmconf should probably not be run in post_uprade since it rewrites the user's configuration. Instead, we should rely on the .pacnew mechanism and let users upgrade their config themselves.
Comment by Andrea Scarpino (BaSh) - Thursday, 01 November 2012, 09:29 GMT
On post_upgrade we actually run: genkdmconf with no params; Its help says: "If an older xdm/kdm configuration is found, its config files are "absorbed""
Comment by J. Berger (jmb) - Thursday, 01 November 2012, 09:37 GMT
Well, the reason I noticed (and reacted) is because it did change my configuration visibly. Specifically, it set UseTheme=true where I have it commented to keep the default (false) value.
Comment by Andrea Scarpino (BaSh) - Thursday, 01 November 2012, 09:42 GMT
From what I see the default value is true
kdmrc.pacnew:UseTheme=true
Comment by J. Berger (jmb) - Thursday, 01 November 2012, 10:43 GMT
The "default value" I was referring to is not the value that is in the default kdmrc file, but the value that will be used by KDM if it is not specified (i.e. if the relevant line is commented out in kdmrc). This is "false", both according to the comment in kdmrc and to the way my setup behaves.
Comment by Andrea Scarpino (BaSh) - Thursday, 01 November 2012, 10:59 GMT
Is the first time I see a non-default value set as default.

Anyway, just set UseTheme to false (don't comment it); genkdmconf will not overwrite it (I just tried).
Comment by J. Berger (jmb) - Thursday, 01 November 2012, 12:54 GMT
This will only fix the symptom, not the real issue. This time I saw it because the difference between UseTheme=true and UseTheme=false is pretty hard to miss. Changes to other settings may be near invisible and have much more dangerous consequences (AllowRootLogin comes to mind). Those changes should never be done behind the user's back (one of the things I like about Arch is that there are very few "automated" tasks that change things without warning).

It probably makes sense to add a message in post_upgrade recommending that the user run genkdmconf, and it certainly makes sense to run it in post_install, but I really think it shouldn't be run automatically in post_upgrade.

Loading...