moin,
people are complaining about being unable to unlock their session.
that happens when they installed as a regular user other than the one
they are running kde4 with.
the root of the evil is this line in kcheckpass's cmakelists:
install(TARGETS kcheckpass DESTINATION ${BIN_INSTALL_DIR} PERMISSIONS SETUID
OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE
WORLD_READ)
cmake fails to chown - of course - but does not abort and simply goes on
with the chmod to setuid. of course, the result is complete nonsense.
note that in kde3 this was mostly no problem, as the makefile had a
compound statement chown && chmod that did either both or none - none
works with linux-pam for several years now, so this was no problem
generally.
what to do? we can just install kcheckpass in a regular way and have a
post-command just like in kde3 - see attached patch.
still, this is "sort of" a cmake bug, no?
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 728806)
+++ CMakeLists.txt (working copy)
@@ -22,7 +22,11 @@
macro_add_compile_flags(kcheckpass -U_REENTRANT)
target_link_libraries(kcheckpass ${KDE4_KDEFAKES_LIBS} ${UNIXAUTH_LIBRARIES} ${SOCKET_LIBRARIES})
-install(TARGETS kcheckpass DESTINATION ${BIN_INSTALL_DIR} PERMISSIONS SETUID OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ)
+install(TARGETS kcheckpass DESTINATION ${BIN_INSTALL_DIR})
+install(CODE "
+ set(KCP_PATH \"\$ENV{DESTDIR}${BIN_INSTALL_DIR}/kcheckpass\")
+ EXECUTE_PROCESS(COMMAND sh -c \"chown root \${KCP_PATH} && chmod +s \${KCP_PATH}\")
+")
install_pam_service(kcheckpass)
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
