On 04/20/2012 09:51 PM, Darrell Anderson wrote: Thanks Darrell, I've just started looking at the sftp kio code. It's Greek.... The tough part is all the errors are spit out by some other part of tdebase and not the kio files, so I can't grep errors and find anything.... -- David C. Rankin, J.D.,P.E.

There might not be any kdebug strings to parse.... Darrell

Do you have a KDE3 system to compare outputs? I have both desktops but I never used sftp. Only fish. I could run dual tests, but I need a punch list of what to check and watch. Darrell

Now that might be a stupid question, but do sftp:// and fish:// provide the same functionality? nik Am Samstag, 21. April 2012 schrieb David C. Rankin:

On 04/21/2012 04:30 PM, Serghei Amelian wrote: I corresponded with Andreas Schneider, the person who rewrote kde4 sftp-kio, kde4 was a complete rewrite: <quote> kio_sftp in KDE4 has been rewritten using libssh. I don't know the process calling code, so you're on your own. Sorry ... </quote> So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug. As for the original question above, sftp:// has always been more reliable than the fish:// protocol. You can google 'fish:// kde3 error' (or sftp for that matter) and see what I mean. Since one of the most valuable capabilities provided by kde3/TDE was seemless remote operation, this is a big issue. konqueror, kwite, and kate all make use of this capability (quanta+ provides its own workaround, but it is also broken due to the same sftp-kio issue). -- David C. Rankin, J.D.,P.E.

This is very useful information that should be posted to the bug report. My initial guess would be that the mechanism TDE uses to determine SSH version is failing with the latest SSH binaries. Can you also post the output of 'ssh -v' on your system, specifically the version line? Thanks! Tim

On 04/22/2012 08:19 PM, Darrell Anderson wrote: Darrell, The tests that are needed are simply to open konqueror file manager (or kwrite, or kate) and then just enter a sftp address (and compare with fish). fish should work, sftp should fail. The address form you should use is: sftp://username@www.myhostname.com:port/dir1/dir2/ and so on It can be as simple as sftp://hostname (for local network) ** kde will use your default username and default port (22) As long as ssh is configured, you should connect fine -- but it fails due to the bug. The do the same thing with fish:// fish://username@www.myhostname.com:port/dir1/dir2/ It also can be as simple as: fish://hostname I can use fish:// and connect in TDE (I use it a lot). But sftp is what we need to fix. I still have some older opensuse 11.0 boxes at the office I can test and compare ssh connect strings with. The sftp:// still works on openSuSE 11.0 with the old openssh version. Any testing you can do will just help. If you don't have a test host for remote ssh connections, let me know, I can set one up for you. -- David C. Rankin, J.D.,P.E.

On 04/22/2012 09:31 PM, Darrell Anderson wrote: <snip> No sftp relies on ssh or ssl, so no ftp is required :) -- David C. Rankin, J.D.,P.E.

I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail. Tim

I know. :-) I am tracing the issue now, but it appears that ssh > 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing. Tim

I have narrowed this down to a problem in how ssh and select() are interacting. To be specific, running select() on the open ssh output file descriptor always returns data available, but when an attempt is made to actually read said data with read() there is no data (an error occurs). I do not know if this is an ssh problem or a problem with some other aspect of the system regarding pipes. Tim

I don't know how much this information helps, but I tested both fish and sftp between two Trinity systems, one real and one virtual. Both systems using OpenSSH 5.5p1 and OpenSSL 0.9.8t. Using sftp worked both ways all the time without any event. Connecting with fish from the virtual system to the real system was the same. When trying to connect with fish from the real system to the virtual I always received the infamous "protocol died unexpectedly error." When I deleted the ksycoca cache and set KDE_FORK_SLAVES=true, then fish always connected. In hindsight that makes no sense because the environment variable was changed some time ago to TDE_FORK_SLAVES. I'm guessing the real issue is something in the ksycoca cache causes problems for fish. I'll test again and add more information as possible. Darrell

Le 23/04/2012 09:44, Timothy Pearson a écrit : Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).

Le 23/04/2012 21:47, Slávek Banko a écrit : Yes I do.

On Tue, 24 Apr 2012 01:40:11 +0200, Slávek Banko wrote: Monday 23 of April 2012 21:54:27 Francois Andriot wrote: 23/04/2012 21:47, Slávek Banko a écrit : Francois Andriot napsal(a): Fedora 16 (patch applied to TDE 3.5.13). packages for Fedora? Slávek here that I had some time to deal with backporting for Debian and Ubuntu. I therefore ask if you backport Fedora? Or, if you want to use the patches, which I have already prepared? Update to 3.5.13 could thus be not only for Debian, but also for Hello, I'm already backporting lots patches myself, including some which are the same as you: You can find the packaging-related files (Redhat SPEC file + patches) in the GIT tree: http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/ The current RHEL/Fedora TDE build is already heavily patched compared to the stock 3.5.13. But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too. Francois

Dne út 24. dubna 2012 François Andriot napsal(a): Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you. My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz Slavek --

Dne st 2. května 2012 David C. Rankin napsal(a): David, From my kdebase changelog: * commit e72f4926, closes #897 Fix sftp failure on newer systems * commit 073dc86a Fix sftp when nonstandard port is specified in ssh config I think I have a patches already incorporated into the updates. Slávek --

Le 24/04/2012 22:43, Darrell Anderson a écrit : I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part). Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...

On Tue, 24 Apr 2012 14:27:06 -0700 (PDT) Darrell Anderson &lt;humanreadable(a)yahoo.com&gt; wrote: The RHEL packages are way more likely to be compatible with Scientific Linux than the Fedora ones, since SL is supposed to be binary compatible with the corresponding RHEL version. Didn't test at all, though.

On Tue, 24 Apr 2012 14:34:57 -0700 (PDT) Darrell Anderson &lt;humanreadable(a)yahoo.com&gt; wrote: IIRC the RHEL packages are also from François Andriot.

On 04/24/2012 04:54 PM, François ANDRIOT wrote: Francios, Is this configurable for those distros that do NOT utilize lib64 for 64-bit library packages? While openSuSE does put 64-bit libs in lib64, Archlinux puts all libs lin 'libs' on 64-bit boxes. This needs to be configurable for just this case. Otherwise always putting 64-bit libs in lib64 on boxes that do NOT use lib64 will really screw up the library search and build system. Can it be something like a --target option or a --with-64bit-lib-dirs= configure option? We don't want a one-size doesn't fit all solution. That would cause about an equal number of problems as it purportedly resolves for those distros that put 64bit libs in libs. -- David C. Rankin, J.D.,P.E.

I appreciate the patches but they did not help. :( The problem is not detecting $QTDIR but $LIBDIR when $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib. The configuration process always fails because libtqt-mt.so.3 is located in $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib. The whole problem is telling the configure process where to find libtqt-mt.so.3. Darrell

I install TQt3 to a $PREFIX of /opt/trinity. qmake, moc, uic, etc. all are installed in /opt/trinity/bin. After TQt3 is installed, $QTDIR then is set to /opt/trinity as well. Using this method I don't have to install TQt3 to any weird subdirectories as was the past practice with Qt3. In 32-bit I have no trouble building any Trinity package. In 64-bit I have no trouble building any Trinity package except tqca, tqca-tls, python-tqt and python-trinity. For 32-bit builds libtqt-mt.so.3 is installed in /opt/trinity/lib. For 64-bit builds libtqt-mt.so.3 is installed in /opt/trinity/lib64. The configure process does not have a problem finding $PREFIX, $QTDIR because I explicitly declare those variables. The only problem with building tqca and tqca-tls is when $LIBDIR changes from $PREFIX/lib to $PREFIX/lib64. Adding ${PREFIX}/lib64 does not help because the configuration process finds $PREFIX and $QTDIR. I explicitly define those variables in my build script. The problem is not finding $PREFIX/lib64 ($QTDIR/lib64). OK. I tried that. I can't get that to work either. Here is the build output: =========================================================== g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -O2 -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/trinity/mkspecs/default -I. -Isrc -I/usr/include/tqt -I/opt/trinity/include -I.ui/ -I.moc/ -o .obj/qca.o src/qca.cpp rm -f libqca.so.1.0.0 libqca.so libqca.so.1 libqca.so.1.0 g++ -Wl,-rpath,/opt/trinity/lib -shared -Wl,-soname,libqca.so.1 -o libqca.so.1.0.0 .obj/qca.o -L/opt/trinity/lib -ltqt-mt -lpthread /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -ltqt-mt =========================================================== The output shows that /opt/trinity/lib is being used rather than /opt/trinity/lib64. I can run this process manually and manually edit Makefile to /opt/trinity/lib64. Then make runs without error. The trick is to force tqca to look in /opt/trinity/lib64 and not in /opt/trinity/lib. Darrell

QTLIB probably the same as what I define as QT_LIB_DIR. Nonetheless, I tried using QTLIB anyway. No difference. Here is my build information: =========================================================== PREFIX: /opt/trinity SYSCONFDIR: /etc/trinity LIBDIR: /opt/trinity/lib64 MANDIR: /opt/trinity/man PKG_CONFIG_PATH: /opt/trinity/lib64/pkgconfig:/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig:/opt/trinity/lib/pkgconfig QTDIR: /opt/trinity QT_INCLUDE_DIR: /opt/trinity/include QT_LIB_DIR: /opt/trinity/lib64 LD_LIBRARY_PATH: /opt/trinity/lib64:/opt/trinity/lib64/trinity PATH: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/opt/trinity/bin:/usr/bin:/bin:/usr/games:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/java/bin:/usr/share/texmf/bin =========================================================== My configure options: =========================================================== export QC_DEBUG=Y CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --qtdir=${QTDIR} =========================================================== The build output: =========================================================== Verifying TQt 3.x Multithreaded (MT) build environment ... fail There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up. One possible reason is that you don't have libtqt-mt.so.3 installed in /opt/trinity/lib/. make: *** No targets specified and no makefile found. Stop. There was an error trying to build tqca. EXIT_CODE: 1 =========================================================== Here is the config.log: =========================================================== g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR ='"/usr/X11R6/lib"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/trinity/mkspecs/default -I. -I' /usr/include/tqt' -I/opt/trinity/include -I/usr/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/trinity/lib -o conf conf.o -L/opt/trinity/lib -L/usr/X11R6/lib -ltqt-mt -lXext -lX11 -lm -lpthread /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -ltqt-mt collect2: ld returned 1 exit status make: *** [conf] Error 1 =========================================================== The config.log shows the process halts because -L is set to /opt/trinity/lib rather than /opt/trinity/lib64. I tried patching both qca.pro and qcextra (lib -> lib64) but that does not help. Here is the contents of tqt-mt.pc: =========================================================== prefix=/opt/trinity exec_prefix=${prefix} libdir=${prefix}/lib64 includedir=${prefix}/include qt_config=qt warn_on release incremental link_prl thread nocrosscompiler dlopen_opengl minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace inputmethod network canvas table xml opengl sql opengl release dll thread largefile stl ipv6 system-mng system-jpeg jpeg system-png png gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype tablet xkb inputmethod dylib create_prl link_prl qt warn_on depend_includepath qmake_cache x11 x11inc create_libtool create_pc moc x11lib Name: TQt Description: Libtqt-mt.so.3.3.8 Library Version: 3.3.8 Libs: -L${libdir} -ltqt-mt -L/usr/lib64 -L/usr/X11R6/lib -lfontconfig -ljpeg -lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread Cflags: -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -I${includedir} =========================================================== The configuration process does not seem to be using tqt-mt.pc because the information is correct. Darrell

On 04/23/2012 03:26 PM, David C. Rankin wrote: Tim, I built tdelibs and tdebase and tested sftp. There is GOOD news and BAD news. The good new - I can connect with sftp!! The bad news - the kio is not reading host/port information from ~/.ssh/config. This requires that you manually specify a port (if not 22) where sftp:// used to read this information from the HOST/PORT information contained in ~/.ssh/config. Eg: Host arete.3111skyline.com arete Port 6629 Host fax.rlfpllc.com fax Port 6631 I don't know what reads this file, but it is read currently when fish:// is invoked and it was previously read by sftp:// before this bug appeared. Any idea where this occurs? -- David C. Rankin, J.D.,P.E.

On 04/23/2012 06:50 PM, David C. Rankin wrote: Tim, It looks like the port is set in kio_sftp.cpp: if( port > 0 ) mPort = port; else { struct servent *pse; if( (pse = getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); } I have looked at the man pages for both getservbyname and ntohs. For the port to fail, it looks like the pse->s_port byte order port number returned by getservbyname must be mucked up also. I'm not sure about the remainder of what the man page is telling me. Are you familiar with what should be returned? Is there something I can test for you so we can check if the port is being set? A patch to make it spit the port number to kdialog? How to do this? -- David C. Rankin, J.D.,P.E.

On 04/23/2012 09:12 PM, Timothy Pearson wrote: I think you are correct. I didn't know what the hell it did, so I wrote a code snippet to look at it and the pse structure created. What I don't get is how the heck this would ever get the correct port since you are never providing getservbyname with any remote host information. I run this and I get port numbers -- but 1+1!=2 yet...: #include <limits.h> #include <errno.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #include <netdb.h> #include <arpa/inet.h> int getval (char *str, int base); int main(int argc, char *argv[]) { int mPort; long port; if (argc < 2) { fprintf(stderr, "Usage: %s port_str [base]\n", argv[0]); exit(EXIT_FAILURE); } port = getval(argv[1], (argc > 2) ? atoi(argv[2]) : 10); printf("port: %d\n", port); struct servent *pse; pse = getservbyname("ssh", "tcp"); if( port > 0 ) mPort = port; else { if( (pse) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); } printf("mPort: %d\n", mPort); printf("(servant *pse)\n\ pse->s_name: %s\n\ pse->s_aliases: %s\n\ pse->s_port %d\n\ pse->s_proto %s\n", pse->s_name, pse->s_aliases, pse->s_port, pse->s_proto); printf ("The host byte order -> Network byte order: %d\n\n", ntohs(pse->s_port)); return 0; } int getval (char *str, int base) { char *endptr; long val; errno = 0; /* To distinguish success/failure after call */ val = strtol(str, &endptr, base); /* Check for various possible errors */ if ((errno == ERANGE && (val == LONG_MAX || val == LONG_MIN)) || (errno != 0 && val == 0)) { perror("strtol"); return(EXIT_FAILURE); } if (endptr == str) { fprintf(stderr, "No digits were found\n"); return(EXIT_FAILURE); } /* If we got here, strtol() successfully parsed a number */ printf("strtol() returned %ld\n", val); if (*endptr != '\0') /* Not necessarily an error... */ printf("Further characters after number: %s\n", endptr); return (val); } -- David C. Rankin, J.D.,P.E.

The thing is, that snippet should never work in the first place. Miracle engineering, even if it worked in 3.5.10, usually fails once assumed conditions change. Tim

On 04/24/2012 08:36 AM, David C. Rankin wrote: I think the CHANGELOG narrows down the search and it is what was identified earlier: 2-19-2002 - get() now emits mimetype, fixes problem with konqi not downloading file for viewing in kpart. - get port number using getservbyname instead of hard coding it. So it is the 'getservbyname' call that is relied upon to get the port information -- and I'll bet the fix is just what we talked about above. Now how to figure out how to make the pieces of 'getservbyname' return the port correctly again from the ssh output? -- David C. Rankin, J.D.,P.E.

On 04/23/2012 11:03 PM, Darrell Anderson wrote: Moreover, it still works correctly in the kioslave/fish code. I looked at that, but I wasn't able to discern the port gathering part of it. I'll try and take another look later today, but we could also use a 2nd pair of eyes figuring this one out. -- David C. Rankin, J.D.,P.E.