The default Trinity KDM welcome message:
Welcome to Kubuntu at %n
Should be:
Welcome to Trinity at %n
The log file name should be changed to something like tdm.log to avoid conflicts with the KDE 4 KDM.
KDM defaults to using Secure Attention Key. This might cause havoc on systems not using PAM or whatever SAK is tied to. The default should be off.
I'll file bug reports against those.
More importantly for now, after disabling SAK, I am unable to login with the Trinity Login Manager. Even fails with root and AllowRootLogin=true.
The kdm.log helps very little but there are several messages such as:
QSettings: failed to open file '/tmp/0491199751/.qt/qt_plugins_3.3rc QSettings::sync: filename is null/empty
Any ideas?
Slackware 13.1.
Thanks.
Darrell
"Darrell Anderson" humanreadable@yahoo.com pisze:
The default Trinity KDM welcome message:
Welcome to Kubuntu at %n
Should be:
Welcome to Trinity at %n
The log file name should be changed to something like tdm.log to avoid conflicts with the KDE 4 KDM.
KDM defaults to using Secure Attention Key. This might cause havoc on systems not using PAM or whatever SAK is tied to. The default should be off.
I'll file bug reports against those.
More importantly for now, after disabling SAK, I am unable to login with the Trinity Login Manager. Even fails with root and AllowRootLogin=true.
The kdm.log helps very little but there are several messages such as:
QSettings: failed to open file '/tmp/0491199751/.qt/qt_plugins_3.3rc QSettings::sync: filename is null/empty
Any ideas?
Slackware 13.1.
Thanks.
Darrell
I've been able to login as root after changing some kdm settings in "control center". Whatever I did I couldn't login as normal user. Slackware 13.37.
---------------------------------------------------------------- Nudzisz sie w pracy? Zagraj >>> http://linkint.pl/f2a8b
I've been able to login as root after changing some kdm settings in "control center". Whatever I did I couldn't login as normal user. Slackware 13.37.
Would you please send me a copy of your Trinity kdmrc? I'll compare that to mine. I can't login as root. The KDE 4 KDM seems okay. I'm using the same kdmrc as I am in KDE 3 except file paths.
Darrell
"Darrell Anderson" humanreadable@yahoo.com pisze:
I've been able to login as root after changing some kdm settings in "control center". Whatever I did I couldn't login as normal user. Slackware 13.37.
Would you please send me a copy of your Trinity kdmrc? I'll compare that to mine. I can't login as root. The KDE 4 KDM seems okay. I'm using the same kdmrc as I am in KDE 3 except file paths.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I'm sorry, but I don't remember exactly what I did before to make it work. I don't have the "working" kdmrc anymore, as I couldn't log in as normal user anyway.
---------------------------------------------------------------- Kilkunastu pracodawcow szuka wlasnie Ciebie! Skontaktuj sie z nimi >> http://linkint.pl/f2a82
I have also noticed the lack of session types in kdm menu - only "default", "xfce" and "failsafe" are present. After compiling and installation of kde 3.5.10 all of the DE's I had installed were on the list.
---------------------------------------------------------------- Masz strone www? Dodaj ja do katalogu! Sprawdz >> http://linkint.pl/f2a8a
I have also noticed the lack of session types in kdm menu - only "default", "xfce" and "failsafe" are present. After compiling and installation of kde 3.5.10 all of the DE's I had installed were on the list.
I haven't seen that problem exactly, but I ran into a similar problem. I was not seeing Trinity as an option in the KDE 4 KDM. The cause was I had no copy of the trinity.desktop file in /usr/share/apps/kdm/sessions, which is where the KDE 4 KDM looks for those files. I updated my build script to ensure that file is installed in both locations (/opt/trinity/share/apps/kdm/sessions).
Darrell
More importantly for now, after disabling SAK, I am unable to login with the Trinity Login Manager. Even fails with root and AllowRootLogin=true.
Need help with this folks. I'm close to being able to upload packages for Slackware but this KDM problem is a stopper.
Whether logging in as root or normal user all I get is "Login failed."
Enabling/disabling SAK makes no difference.
Are there are any build options I am missing? Any packages I need to build? Missing patches? Special configuration options?
The KDE 4 KDM works fine with almost the same exact kdmrc settings.
My kdebase build options:
-DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ -DMAN_INSTALL_DIR=${MANDIR} \ -DWITH_SAMBA=ON \ -DWITH_OPENEXR=ON \ -DWITH_XCOMPOSITE=ON \ -DWITH_XCURSOR=ON \ -DWITH_XFIXES=ON \ -DWITH_XRANDR=ON \ -DWITH_XINERAMA=ON \ -DWITH_ARTS=ON \ -DWITH_XRENDER=ON \ -DWITH_XFIXES=ON \ -DWITH_XDAMAGE=ON \ -DWITH_XEXT=ON \ -DWITH_I8K=OFF \ -DWITH_XDMCP=ON -DBUILD_ALL=ON
Thanks.
Darrell
To anybody who can help me troubleshoot why I can't login with KDM:
Here is an strace debug log (warning: large file if not on broadband):
http://humanreadable.nfshost.com/trinity/build_logs/kdm-trinity.log.gz
Slackware uses shadow passwords and does not include or support PAM. Therefore I built kdebase with the following:
-DWITH_SHADOW=ON -DWITH_PAM=OFF
Thanks!
Darrell
Le Tue, 15 Nov 2011 19:00:01 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
To anybody who can help me troubleshoot why I can't login with KDM:
Here is an strace debug log (warning: large file if not on broadband):
http://humanreadable.nfshost.com/trinity/build_logs/kdm-trinity.log.gz
Slackware uses shadow passwords and does not include or support PAM. Therefore I built kdebase with the following:
-DWITH_SHADOW=ON -DWITH_PAM=OFF
Thanks!
Darrell
I think the problem is that /tmp/ksocket-global doesn't exist on your system. Can you try the attached (quick & dirty, not to be put upstream) patch ? The seemingly infinite loop is because of a missing error check on the opening of the pipe, and since nothing interesting gets out of ::read, it is called again and again. The same issue applies both to kdmgreeter.cpp and sakdlg.cpp.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Le Wed, 16 Nov 2011 04:28:42 +0100, /dev/ammo42 mickeytintincolle@yahoo.fr a écrit :
Le Tue, 15 Nov 2011 19:00:01 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
To anybody who can help me troubleshoot why I can't login with KDM:
Here is an strace debug log (warning: large file if not on broadband):
http://humanreadable.nfshost.com/trinity/build_logs/kdm-trinity.log.gz
Slackware uses shadow passwords and does not include or support PAM. Therefore I built kdebase with the following:
-DWITH_SHADOW=ON -DWITH_PAM=OFF
Thanks!
Darrell
I think the problem is that /tmp/ksocket-global doesn't exist on your system. Can you try the attached (quick & dirty, not to be put upstream) patch ? The seemingly infinite loop is because of a missing error check on the opening of the pipe, and since nothing interesting gets out of ::read, it is called again and again. The same issue applies both to kdmgreeter.cpp and sakdlg.cpp.
Stupid me. Here is the patch.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I think the problem is that /tmp/ksocket-global
doesn't exist on your
system. Can you try the attached (quick & dirty,
not to be put
upstream) patch ? The seemingly infinite loop is because of a missing
error check on the
opening of the pipe, and since nothing interesting
gets out of ::read,
it is called again and again. The same issue applies both to kdmgreeter.cpp and
sakdlg.cpp. Stupid me. Here is the patch.
Thanks much. First I tried manually creating the directory and then logging in. No deal. Then I rebuilt kdebase with your patch. No deal. :(
Here is a new strace based upon your patch:
http://humanreadable.nfshost.com/trinity/build_logs/kdm-trinity.log-2.gz
Darrell
On a whim I tried this really big hammer. I created a patch to strip from the kdebase code all references of consolekit.c and CONSOLE_KIT. Seemed like a reasonable idea.
No luck. Still can't login with KDM.
Would somebody please provide me a knee-bone-connected-to-the-thigh-bone explanation or simple flow chart how KDM runs through everything? I'm still leaning toward this being an authentication problem. Perhaps with some kind of flow chart I can try something.
Thanks!
Darrell
On a whim I tried this really big hammer. I created a patch to strip from the kdebase code all references of consolekit.c and CONSOLE_KIT. Seemed like a reasonable idea.
No luck. Still can't login with KDM.
Would somebody please provide me a knee-bone-connected-to-the-thigh-bone explanation or simple flow chart how KDM runs through everything? I'm still leaning toward this being an authentication problem. Perhaps with some kind of flow chart I can try something.
Some progress.
I tried some different -debug options with kdm. I saw an error message "password verify failed." The only place the message is found is in kdm/backend/client.c.
Any ideas where to attack next?
Darrell
use gdb and figure out where in the code it is failing?
maybe try using a breakpoint at the function that calls that error message. If you step through the function you si could see where it fails.
Calvin Morrison On 17 November 2011 21:17, Darrell Anderson humanreadable@yahoo.com wrote:
On a whim I tried this really big hammer. I created a patch to strip from the kdebase code all references of consolekit.c and CONSOLE_KIT. Seemed like a reasonable idea.
No luck. Still can't login with KDM.
Would somebody please provide me a knee-bone-connected-to-the-thigh-bone explanation or simple flow chart how KDM runs through everything? I'm still leaning toward this being an authentication problem. Perhaps with some kind of flow chart I can try something.
Some progress.
I tried some different -debug options with kdm. I saw an error message "password verify failed." The only place the message is found is in kdm/backend/client.c.
Any ideas where to attack next?
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On a whim I tried this really big hammer. I created a patch to strip from the kdebase code all references of consolekit.c and CONSOLE_KIT. Seemed like a reasonable idea.
No luck. Still can't login with KDM.
Would somebody please provide me a knee-bone-connected-to-the-thigh-bone explanation or simple flow chart how KDM runs through everything? I'm still leaning toward this being an authentication problem. Perhaps with some kind of flow chart I can try something.
Some progress.
I tried some different -debug options with kdm. I saw an error message "password verify failed." The only place the message is found is in kdm/backend/client.c.
Any ideas where to attack next?
Darrell
Hi Darrell,
That snippet you posted above I think contains a very important clue to the solution.
In kdm/backend/client.c , try commenting out the #ifdefs for HAVE_CRYPT. I am pretty sure that HAVE_CRYPT is not being set by CMake, which would cause non-PAM (encrypted) password checks to fail.
If this temporary hack fixes the problem, a simple fix to CMake should squash this bug for good!
Tim
On a whim I tried this really big hammer. I created a patch to strip from the kdebase code all references of consolekit.c and CONSOLE_KIT. Seemed like a reasonable idea.
No luck. Still can't login with KDM.
Would somebody please provide me a knee-bone-connected-to-the-thigh-bone explanation or simple flow chart how KDM runs through everything? I'm still leaning toward this being an authentication problem. Perhaps with some kind of flow chart I can try something.
Some progress.
I tried some different -debug options with kdm. I saw an error message "password verify failed." The only place the message is found is in kdm/backend/client.c.
Any ideas where to attack next?
Darrell
Hi Darrell,
That snippet you posted above I think contains a very important clue to the solution.
In kdm/backend/client.c , try commenting out the #ifdefs for HAVE_CRYPT. I am pretty sure that HAVE_CRYPT is not being set by CMake, which would cause non-PAM (encrypted) password checks to fail.
If this temporary hack fixes the problem, a simple fix to CMake should squash this bug for good!
Tim
To clarify, you should (as a test ONLY) replace this whole block:
# if defined(ultrix) || defined(__ultrix__) if (authenticate_user( p, curpass, NULL ) < 0) # elif defined(HAVE_CRYPT) if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd )) # else if (strcmp( curpass, p->pw_passwd )) # endif
With this single line:
if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
Tim
To clarify, you should (as a test ONLY) replace this whole block:
# if defined(ultrix) || defined(__ultrix__) if (authenticate_user( p, curpass, NULL ) < 0) # elif defined(HAVE_CRYPT) if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd )) # else if (strcmp( curpass, p->pw_passwd )) # endif
With this single line:
if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
Nope. :(
First I tried this (as you posted):
-# if defined(ultrix) || defined(__ultrix__) - if (authenticate_user( p, curpass, NULL ) < 0) -# elif defined(HAVE_CRYPT) - if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd )) -# else - if (strcmp( curpass, p->pw_passwd )) -# endif +if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
That FTBFS. :( Hoping what you typed was a copy-and-paste error, next I tried this:
+if (strcmp( curpass, p->pw_passwd ))
That built. :)
But I still could not login. The log showed the same error.
I looked at the 3.5.12 and 3.5.10 code. That snippet is exactly the same in all three versions.
As you mentioned, the problem likely is how the package builds with cmake and not the code itself.
Next I tried the test patch again, but with the build option -DWITH_SHADOW=OFF. Still can't login. :(
If you have a proposed patch for cmake I will backport and test right away.
Darrell
To clarify, you should (as a test ONLY) replace this whole block:
# if defined(ultrix) || defined(__ultrix__) if (authenticate_user( p, curpass, NULL ) < 0) # elif defined(HAVE_CRYPT) if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd )) # else if (strcmp( curpass, p->pw_passwd )) # endif
With this single line:
if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
Nope. :(
First I tried this (as you posted):
-# if defined(ultrix) || defined(__ultrix__)
- if (authenticate_user( p, curpass, NULL ) < 0)
-# elif defined(HAVE_CRYPT)
- if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
-# else
- if (strcmp( curpass, p->pw_passwd ))
-# endif +if (strcmp( crypt( curpass, p->pw_passwd ), p->pw_passwd ))
That FTBFS.
<snip>
Can you post the error log please?
+if (strcmp( curpass, p->pw_passwd ))
That built. :)
But won't work on most systems! :-)
Tim
Can you post the error log please?
+if (strcmp( curpass, p->pw_passwd ))
That built. :)
But won't work on most systems! :-)
This is odd. With parallel building enabled the package fails in the middle of the process. With parallel building disabled the build fails at about 3/4 of the way.
Tail end of the build error log with your original test patch with parallel building disabled:
============================================== [ 77%] Building C object kdm/backend/CMakeFiles/kdm.dir/xdmcp.c.o cd /dev/shm/kdebase.build/kdm/backend && /usr/bin/gcc -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -I/dev/shm/kdebase.build/kdm/backend -I/dev/shm/kdebase.build -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o CMakeFiles/kdm.dir/xdmcp.c.o -c /dev/shm/kdebase/kdm/backend/xdmcp.c Linking C executable kdm cd /dev/shm/kdebase.build/kdm/backend && /usr/bin/cmake -E cmake_link_script CMakeFiles/kdm.dir/link.txt --verbose=1 /usr/bin/gcc -O2 -march=i486 -mtune=i686 CMakeFiles/kdm.dir/access.c.o CMakeFiles/kdm.dir/auth.c.o CMakeFiles/kdm.dir/bootman.c.o CMakeFiles/kdm.dir/choose.c.o CMakeFiles/kdm.dir/client.c.o CMakeFiles/kdm.dir/consolekit.c.o CMakeFiles/kdm.dir/ctrl.c.o CMakeFiles/kdm.dir/daemon.c.o CMakeFiles/kdm.dir/dm.c.o CMakeFiles/kdm.dir/dpylist.c.o CMakeFiles/kdm.dir/error.c.o CMakeFiles/kdm.dir/genauth.c.o CMakeFiles/kdm.dir/inifile.c.o CMakeFiles/kdm.dir/krb5auth.c.o CMakeFiles/kdm.dir/mitauth.c.o CMakeFiles/kdm.dir/netaddr.c.o CMakeFiles/kdm.dir/policy.c.o CMakeFiles/kdm.dir/process.c.o CMakeFiles/kdm.dir/protodpy.c.o CMakeFiles/kdm.dir/reset.c.o CMakeFiles/kdm.dir/resource.c.o CMakeFiles/kdm.dir/rpcauth.c.o CMakeFiles/kdm.dir/server.c.o CMakeFiles/kdm.dir/session.c.o CMakeFiles/kdm.dir/sessreg.c.o CMakeFiles/kdm.dir/socket.c.o CMakeFiles/kdm.dir/streams.c.o CMakeFiles/kdm.dir/util.c.o CMakeFiles/kdm.dir/xdmauth.c.o CMakeFiles/kdm.dir/xdmcp.c.o -o kdm -rdynamic -lX11 -lXau -ldbus-tqt-1 -ldbus-1 -lpthread -lrt CMakeFiles/kdm.dir/client.c.o: In function `Verify': client.c:(.text+0x1263): undefined reference to `crypt' collect2: ld returned 1 exit status make[2]: *** [kdm/backend/kdm] Error 1 make[2]: Leaving directory `/dev/shm/kdebase.build' make[1]: *** [kdm/backend/CMakeFiles/kdm.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/kdebase.build' make: *** [all] Error 2 ==============================================
The error makes some sense with respect to what we are doing. I see the function Verify, but I don't know how to define the reference crypt. :) If you provide a patch or instructions I'll try again.
Cmake build options:
rm ${TMP}/${PRGNAM}/CMakeCache.txt 2>/dev/null mkdir ${TMP}/${PRGNAM}.build cd ${TMP}/${PRGNAM}.build cmake ${TMP}/${PRGNAM} \ -DCMAKE_C_FLAGS:STRING="$CPUOPT" \ -DCMAKE_CXX_FLAGS:STRING="$CPUOPT" \ -DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ -DMAN_INSTALL_DIR=${MANDIR} \ -DWITH_XCOMPOSITE=ON \ -DWITH_XCURSOR=ON \ -DWITH_XFIXES=ON \ -DWITH_XRANDR=ON \ -DWITH_ARTS=ON \ -DWITH_XRENDER=ON \ -DWITH_XFIXES=ON \ -DWITH_XDAMAGE=ON \ -DWITH_XEXT=ON \ -DWITH_SHADOW=ON \ -DWITH_PAM=OFF \ -DBUILD_ALL=ON
Darrell
Can you post the error log please?
+if (strcmp( curpass, p->pw_passwd ))
That built. :)
But won't work on most systems! :-)
This is odd. With parallel building enabled the package fails in the middle of the process. With parallel building disabled the build fails at about 3/4 of the way.
Tail end of the build error log with your original test patch with parallel building disabled:
============================================== [ 77%] Building C object kdm/backend/CMakeFiles/kdm.dir/xdmcp.c.o cd /dev/shm/kdebase.build/kdm/backend && /usr/bin/gcc -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -I/dev/shm/kdebase.build/kdm/backend -I/dev/shm/kdebase.build -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o CMakeFiles/kdm.dir/xdmcp.c.o -c /dev/shm/kdebase/kdm/backend/xdmcp.c Linking C executable kdm cd /dev/shm/kdebase.build/kdm/backend && /usr/bin/cmake -E cmake_link_script CMakeFiles/kdm.dir/link.txt --verbose=1 /usr/bin/gcc -O2 -march=i486 -mtune=i686 CMakeFiles/kdm.dir/access.c.o CMakeFiles/kdm.dir/auth.c.o CMakeFiles/kdm.dir/bootman.c.o CMakeFiles/kdm.dir/choose.c.o CMakeFiles/kdm.dir/client.c.o CMakeFiles/kdm.dir/consolekit.c.o CMakeFiles/kdm.dir/ctrl.c.o CMakeFiles/kdm.dir/daemon.c.o CMakeFiles/kdm.dir/dm.c.o CMakeFiles/kdm.dir/dpylist.c.o CMakeFiles/kdm.dir/error.c.o CMakeFiles/kdm.dir/genauth.c.o CMakeFiles/kdm.dir/inifile.c.o CMakeFiles/kdm.dir/krb5auth.c.o CMakeFiles/kdm.dir/mitauth.c.o CMakeFiles/kdm.dir/netaddr.c.o CMakeFiles/kdm.dir/policy.c.o CMakeFiles/kdm.dir/process.c.o CMakeFiles/kdm.dir/protodpy.c.o CMakeFiles/kdm.dir/reset.c.o CMakeFiles/kdm.dir/resource.c.o CMakeFiles/kdm.dir/rpcauth.c.o CMakeFiles/kdm.dir/server.c.o CMakeFiles/kdm.dir/session.c.o CMakeFiles/kdm.dir/sessreg.c.o CMakeFiles/kdm.dir/socket.c.o CMakeFiles/kdm.dir/streams.c.o CMakeFiles/kdm.dir/util.c.o CMakeFiles/kdm.dir/xdmauth.c.o CMakeFiles/kdm.dir/xdmcp.c.o -o kdm -rdynamic -lX11 -lXau -ldbus-tqt-1 -ldbus-1 -lpthread -lrt CMakeFiles/kdm.dir/client.c.o: In function `Verify': client.c:(.text+0x1263): undefined reference to `crypt' collect2: ld returned 1 exit status make[2]: *** [kdm/backend/kdm] Error 1 make[2]: Leaving directory `/dev/shm/kdebase.build' make[1]: *** [kdm/backend/CMakeFiles/kdm.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/kdebase.build' make: *** [all] Error 2 ==============================================
The error makes some sense with respect to what we are doing. I see the function Verify, but I don't know how to define the reference crypt. :) If you provide a patch or instructions I'll try again.
Cmake build options:
rm ${TMP}/${PRGNAM}/CMakeCache.txt 2>/dev/null mkdir ${TMP}/${PRGNAM}.build cd ${TMP}/${PRGNAM}.build cmake ${TMP}/${PRGNAM} \ -DCMAKE_C_FLAGS:STRING="$CPUOPT" \ -DCMAKE_CXX_FLAGS:STRING="$CPUOPT" \ -DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ -DMAN_INSTALL_DIR=${MANDIR} \ -DWITH_XCOMPOSITE=ON \ -DWITH_XCURSOR=ON \ -DWITH_XFIXES=ON \ -DWITH_XRANDR=ON \ -DWITH_ARTS=ON \ -DWITH_XRENDER=ON \ -DWITH_XFIXES=ON \ -DWITH_XDAMAGE=ON \ -DWITH_XEXT=ON \ -DWITH_SHADOW=ON \ -DWITH_PAM=OFF \ -DBUILD_ALL=ON
Darrell
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
Thanks!
Tim
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
I did not include the full log but I now noticed these error messages a few dozen lines up in the log:
/dev/shm/kdebase/kdm/backend/client.c: In function 'Verify': /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of 'strlen' makes pointer from integer without a cast /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of 'strlen' makes pointer from integer without a cast /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int'
Darrell
Le Fri, 18 Nov 2011 11:58:32 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
I did not include the full log but I now noticed these error messages a few dozen lines up in the log:
/dev/shm/kdebase/kdm/backend/client.c: In function 'Verify': /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of 'strlen' makes pointer from integer without a cast /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of 'strlen' makes pointer from integer without a cast /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int' /dev/shm/kdebase/kdm/backend/client.c:742: warning: passing argument 1 of '__builtin_strcmp' makes pointer from integer without a cast /dev/shm/kdebase/kdm/backend/client.c:742: note: expected 'const char *' but argument is of type 'int'
C89 assumes a return type of int when an undeclared function is called, so these warnings were to be expected and are related with crypt() not being detected by CMake.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 18 November 2011 21:32:49 Timothy Pearson wrote: [...]
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
I think is useless to detect libcrypt, because it is part of libc, we can assume that any system based on libc have this library.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
Sorry, I did not understood this sentence :) Please rephrase it.
On Friday 18 November 2011 21:32:49 Timothy Pearson wrote: [...]
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
I think is useless to detect libcrypt, because it is part of libc, we can assume that any system based on libc have this library.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
Sorry, I did not understood this sentence :) Please rephrase it.
Sorry about that. Can you create a patch for the TDE CMake files, based on the TDE v3.5.13 source tarballs, that enables the libcrypt-dependent code in kdebase? Right now the libcrypt-dependent code is disabled when built under CMake because of an unset C++ #define and a missing linker flag.
Thanks!
Tim
On Friday 18 November 2011 21:32:49 Timothy Pearson wrote: [...]
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
I think is useless to detect libcrypt, because it is part of libc, we can assume that any system based on libc have this library.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
Sorry, I did not understood this sentence :) Please rephrase it.
Sorry about that. Can you create a patch for the TDE CMake files, based on the TDE v3.5.13 source tarballs, that enables the libcrypt-dependent code in kdebase? Right now the libcrypt-dependent code is disabled when built under CMake because of an unset C++ #define and a missing linker flag.
Thanks!
Tim
I forgot to add that other TDE modules may expect to see HAVE_CRYPT defined as well, so it would probably be a good idea to pass HAVE_CRYPT as a #define to all TDE modules (i.e. add the fix the CMake code in the common cmake/ directory, not just to the CMake modules in kdebase).
Tim
On Friday 18 November 2011 23:27:46 Timothy Pearson wrote:
On Friday 18 November 2011 21:32:49 Timothy Pearson wrote: [...]
OK, looks like someone is going to have to create a CMake patch to add libcrypt detection in order for this to work. Problem is the partial GIT migration and KDE-->TDE make it quite difficult for me to do at this time.
I think is useless to detect libcrypt, because it is part of libc, we can assume that any system based on libc have this library.
Serghei, do you think you could whip something up based on the 3.5.13 sources?
Sorry, I did not understood this sentence :) Please rephrase it.
Sorry about that. Can you create a patch for the TDE CMake files, based on the TDE v3.5.13 source tarballs, that enables the libcrypt-dependent code in kdebase? Right now the libcrypt-dependent code is disabled when built under CMake because of an unset C++ #define and a missing linker flag.
Sure, I will do this.
I forgot to add that other TDE modules may expect to see HAVE_CRYPT defined as well, so it would probably be a good idea to pass HAVE_CRYPT as a #define to all TDE modules (i.e. add the fix the CMake code in the common cmake/ directory, not just to the CMake modules in kdebase).
Hmm, it will be a useless check when crypt is not needed. I think we should identify modules which need HAVE_CRYPT.
Tim
I forgot to add that other TDE modules may expect to see HAVE_CRYPT defined as well, so it would probably be a good idea to pass HAVE_CRYPT as a #define to all TDE modules (i.e. add the fix the CMake code in the common cmake/ directory, not just to the CMake modules in kdebase).
Hmm, it will be a useless check when crypt is not needed. I think we should identify modules which need HAVE_CRYPT.
OK, it's up to you. :-) Grepping through the top-level TDE source directory should turn up any other crypt-dependent modules and applications.
Tim
Hmm, it will be a useless check when crypt is not
needed. I think we
should identify modules which need HAVE_CRYPT.
OK, it's up to you. :-) Grepping through the top-level TDE source directory should turn up any other crypt-dependent modules and applications.
Just asking, nothing more --- do we have a time estimated completion time for this?
I want to get my Slackware binary packages out, but I'll wait if this patch is soon forthcoming.
Darrell
On Friday 18 November 2011 23:24:29 Timothy Pearson wrote: [...]
Sorry about that. Can you create a patch for the TDE CMake files, based on the TDE v3.5.13 source tarballs, that enables the libcrypt-dependent code in kdebase? Right now the libcrypt-dependent code is disabled when built under CMake because of an unset C++ #define and a missing linker flag.
Thanks!
Tim
The patch is attached. Seems that kdm is the only kdebase application wich use libcrypt.
Le 19/11/2011 00:11, Serghei Amelian a écrit :
On Friday 18 November 2011 23:24:29 Timothy Pearson wrote: [...]
Sorry about that. Can you create a patch for the TDE CMake files, based on the TDE v3.5.13 source tarballs, that enables the libcrypt-dependent code in kdebase? Right now the libcrypt-dependent code is disabled when built under CMake because of an unset C++ #define and a missing linker flag.
Thanks!
Tim
The patch is attached. Seems that kdm is the only kdebase application wich use libcrypt.
check_function_exists( crypt LIBC_HAVE_CRYPT ) if( LIBC_HAVE_CRYPT ) set( HAVE_CRYPT 1 CACHE INTERNAL "" FORCE ) else( ) check_library_exists( crypt crypt "" HAVE_CRYPT ) if( HAVE_CRYPT ) set( CRYPT_LIBRARY crypt ) endif( ) endif( )
I doubt the first test is useful. I believe check_function_exists always fails here.
$ man 3 crypt --> "Link with -lcrypt."
This would be better, no?:
check_library_exists( crypt crypt "" HAVE_CRYPT ) if( HAVE_CRYPT ) set( CRYPT_LIBRARY crypt ) endif( )
On Saturday 19 November 2011 01:44:06 Laurent Dard wrote: [...]
I doubt the first test is useful.
On our modern Linux systems, probably is useless. But we don't know if other unix like systems do not incorporate it in libc.
I believe check_function_exists always fails here.
$ man 3 crypt --> "Link with -lcrypt."
This would be better, no?:
check_library_exists( crypt crypt "" HAVE_CRYPT ) if( HAVE_CRYPT ) set( CRYPT_LIBRARY crypt ) endif( )
Sorry about that. Can you create a patch for the
TDE CMake files, based
on the TDE v3.5.13 source tarballs, that enables the
libcrypt-dependent
code in kdebase? Right now the
libcrypt-dependent code is disabled when
built under CMake because of an unset C++ #define and
a missing linker
flag.
Thanks!
Tim
The patch is attached. Seems that kdm is the only kdebase application wich use libcrypt.
Serghei and Tim, you two are just plain old fashioned darned good!
I can login through KDM as both normal user and root.
Thank you!
I will attach a copy of the patch to Bug Report 624. :)
Darrell
Le 19/11/2011 00:11, Serghei Amelian a écrit :
Seems that kdm is the only kdebase application wich use libcrypt.
Yes but I saw that kdelibs has the same problem: the crypt function is not detected. I fear other parts of the trinity code are affected.
On Sunday 20 November 2011 05:16:40 Laurent Dard wrote:
Le 19/11/2011 00:11, Serghei Amelian a écrit :
Seems that kdm is the only kdebase application wich use libcrypt.
Yes but I saw that kdelibs has the same problem: the crypt function is not detected. I fear other parts of the trinity code are affected.
Where is used crypt in kdelibs?
Le 20/11/2011 16:29, Serghei Amelian a écrit :
On Sunday 20 November 2011 05:16:40 Laurent Dard wrote:
Le 19/11/2011 00:11, Serghei Amelian a écrit :
Seems that kdm is the only kdebase application wich use libcrypt.
Yes but I saw that kdelibs has the same problem: the crypt function is not detected. I fear other parts of the trinity code are affected.
Where is used crypt in kdelibs?
Nowhere, it seems, except here ;-) : kdelibs-trinity-3.5.13/CMakeLists.txt:303:check_function_exists( crypt HAVE_CRYPT ) kdelibs-trinity-3.5.13/config.h.cmake:75:#cmakedefine HAVE_CRYPT 1
It doesn't work and seems useless: * crypt is redefined in several files, as in: kdelibs-trinity-3.5.13/kio/kssl/kopenssl.h:37:#define crypt _openssl_crypt kdelibs-trinity-3.5.13/kio/kssl/kopenssl.h:50:#undef crypt * crypt isn't invoked, as far as I can tell (encrypt or setkey) * HAVE_CRYPT is not used either.
Bug report: http://bugs.trinitydesktop.org/show_bug.cgi?id=654
On Sunday 20 November 2011 19:40:19 Laurent Dard wrote:
Le 20/11/2011 16:29, Serghei Amelian a écrit :
On Sunday 20 November 2011 05:16:40 Laurent Dard wrote:
Le 19/11/2011 00:11, Serghei Amelian a écrit :
Seems that kdm is the only kdebase application wich use libcrypt.
Yes but I saw that kdelibs has the same problem: the crypt function is not detected. I fear other parts of the trinity code are affected.
Where is used crypt in kdelibs?
Nowhere, it seems, except here ;-) : kdelibs-trinity-3.5.13/CMakeLists.txt:303:check_function_exists( crypt HAVE_CRYPT ) kdelibs-trinity-3.5.13/config.h.cmake:75:#cmakedefine HAVE_CRYPT 1
It doesn't work and seems useless:
- crypt is redefined in several files, as in: kdelibs-trinity-3.5.13/kio/kssl/kopenssl.h:37:#define crypt
_openssl_crypt kdelibs-trinity-3.5.13/kio/kssl/kopenssl.h:50:#undef crypt
- crypt isn't invoked, as far as I can tell (encrypt or setkey)
- HAVE_CRYPT is not used either.
Bug report: http://bugs.trinitydesktop.org/show_bug.cgi?id=654
In this case, the crypt check should be removed for kdelibs.
Le 20/11/2011 18:45, Serghei Amelian a écrit :
In this case, the crypt check should be removed for kdelibs.
Probably.
But, please, take a look at my bug report. 'alloca' and 'dlerror' aren't detected by cmake but used in the code.
Maybe it would be good to check for the error you corrected in the whole trinity tree: grep -rl check_function_exists( crypt HAVE_CRYPT ) . and replace it by your code (or remove it if useless).
-
/dev/ammo42 -
alekow -
Calvin Morrison -
Darrell Anderson -
Laurent Dard -
Serghei Amelian -
Timothy Pearson