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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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 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.

Le Tue, 15 Nov 2011 19:00:01 -0800 (PST), Darrell Anderson <humanreadable(a)yahoo.com> a écrit : 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

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

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.

+if (strcmp( curpass, p->pw_passwd )) That built. :)

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

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 --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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: [...] 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. 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.

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

needed. I think we OK, it's up to you. :-) Grepping through the top-level TDE source directory should turn up any other crypt-dependent modules and applications.

On Friday 18 November 2011 23:24:29 Timothy Pearson wrote: [...] 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( )

On our modern Linux systems, probably is useless. But we don't know if other unix like systems do not incorporate it in libc.

Seems that kdm is the only kdebase application wich use libcrypt.

On Sunday 20 November 2011 05:16:40 Laurent Dard wrote: Where is used crypt in kdelibs?

In this case, the crypt check should be removed for kdelibs.