From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041115 Description of problem: gftp cannot locate its config file and aborts at startup. Version-Release number of selected component (if applicable): gftp-2.0.17-3 How reproducible: Always Steps to Reproduce: 1. At a shell prompt enter: $ gftp & Actual Results: When started using the gftp desktop icon, nothing happens. When started at a shell prompt, it produces the following error message: gFTP Error: Cannot find master config file /usr/local/share/gftp/gftprc Did you do a make install? Expected Results: gftp should start up to its graphical screen Additional info: This may be a faulty rpm build from the original tar.gz distribution. Perhaps the spec file has a problem?
Doc, sounds like an rpmmacros file might be a little off. That gftprc file is actually in /usr/share/gftp in the shipping package and I just rebuilt it on a RHEL4 box and it landed in the same place. Something appears to be changing that path to "/usr/local/share" in your environment. Any ideas?
*** Bug 149586 has been marked as a duplicate of this bug. ***
Jay, I tried installing gftp-2.0.18-1 from rawhide/development and got the same error message. I also compared the subdirectory structures in /usr/local/share on my FC3 laptop (where gftp 2.0.18 runs perfectly). They're exactly alike (no gftp subdir). My RHEL4 setup is an "everything" setup on a dual-Athlon system. It's fully updated. The user's PATH variable is identical to that on my FC3 laptop. When you say "landed in the same place" do you mean /usr/local/share or /usr/share/gftp? I must be overlooking something fundamental because this makes no sense to me at all. --Doc
Sorry, I meant that gftprc landed in /usr/share/gftp/ after the rebuild. The next thing I would suggest is getting a build log from one of the failing builds and attaching that to the bug. We should be able to figure out what's happening from that.
There was a gftp-2.0.17-3.i386.rpm pushed onto RHN on Feb 23. I deleted the 2.0.18-1 version and installed 2.0.17-3, but it didn't change anything. I've thought about trying to build an rpm from source on my system, but Brian Masney's source is only available as a tarball. His 2.0.18-1 source includes a gftp.spec file, but there's no 'make rpm' option in the Makefile. I've long since forgotten how to cob together an rpm from a tarball and spec file. Is there '101' anywhere to refresh my memory?
With respect to the spec file, you should be able to steal the Red Hat gftp spec file and just make the appropriate changes to match the new tarball you're building against (change the version to match the tarball format, and may need to remove the references to Patch0.) After doing that, just run 'rpmbuild -ba gftp.spec' which will build both the binary and source packages. That all having been said, I still think something is whacked in your environment, as there's no other reason for files to get written to /usr/local/share (something is redefining %{_prefix} from the default.) Do you have redhat-rpm-config installed?
Jay, Yes: redhat-rpm-config-8.0.32.1-1. This is an "everything" build using iso sources from a local hard drive. There was a glitch in that process; see Bugzilla #149184. I'll upload 'set environment' for root and an ordinary user.
Created attachment 111734 [details] Outputs of 'set' for root and ordinary user.
Created attachment 111735 [details] The last few output lines from 'rpmbuild -ba gftp.spec' w/error detail The last 25 lines of [root@lion] ~/gftp-2.0.18 # rpmbuild -ba gftp.spec
Hmmmm. Not sure this is useful, but will toss it into the pot. Just did an rpmbuild using Brian Masney's latest gftp-2.0.18-1.tar.gz source and his gftp.spec file. The last few lines are attached.
Something is definitely pointing the build towards "/usr/local" as opposed to just "/usr." Try running this and attaching the results: egrep -r "%_prefix|%_datadir" /usr/lib/rpm ~/.rpmmacros Looks like from comment 9 you're building as root, so running this as root should work to pick up any RPM macros that root has in its home directory.
Created attachment 111768 [details] Output of '# egrep -r "%_prefix|%_datadir" /usr/lib/rpm ~/.rpmmacros'
Jay, The egrep output is attached... --Doc
Wow, I'm just striking out all around. Everything in there seems to point to files landing in /usr/share, as would be expected. Going back through the bug, it's not entirely clear to me if you're rebuilding each of these packages before installing, or if even after installing packages directly from Red Hat they are still failing. If you're rebuilding and getting this behavior, please attach the build output (shouldn't be too big and you can tar it up.) If it's happening even after installing a package directly from Red Hat, then please run strace -o /tmp/gftp.out gftp And send along the resulting /tmp/gftp.out file.
Created attachment 111775 [details] Output of '# strace -o /tmp/gftp.out gftp
Jay, The packages I've installed have all been from Red Hat: 1. The original gftp-2.0.17- for RHEL4 2. gftp-2.0.18-1.i386.rpm from development 3. The latest gftp-2.0.17-3.i386.rpm posted to RHN on Feb 23 (which has the same md5sum as the original. The 2.0.18-1 tarball I've tried to build an rpm from has been from Brian Masney's ftp://ftp.gftp.org/pub/gftp Here's the stack trace you asked for. I hope it tells you something... --Doc
OK, this is really weird. The very first line in the strace is: execve("/usr/local/bin/gftp", ["gftp"], [/* 24 vars */]) = 0 So it's running a gftp from /usr/local/bin as opposed to the one in /usr/bin . . . I suspect that's where all of the problems result from. Just checking back in your 'set' output from above, I see that /usr/local/bin is in $PATH before /usr/bin, therefore I suspect that all of these installs you've been doing haven't really changed anything because the new code never got run. Try running '/usr/bin/gftp' directly and seeing what happens. I suspect that at some point in time a rebuilt gftp got installed on your system which was using /usr/local as %_datadir.
Jay, /usr/bin/gftp works. Now the question is, "How did the $PATH order get inverted?". Well, it didn't. I did a fresh install of RHEL4, but that same night I recovered my /usr/local/bin scripts from a backup of my RHEL3 installation. And, of course, in that directory I found: -rwxr-xr-x 1 root root 339 Mar 28 2004 gftp -rwxr-xr-x 1 root root 289400 Mar 28 2004 gftp-gtk -rwxr-xr-x 1 root root 160280 Mar 28 2004 gftp-text which must certainly be the 'make install' products of a tarball almost a year ago. Which means this was self-inflicted, and your diagnosis was bang on. I've been so focused on the RHEL4 installation that it never occurred to me to look anywhere else. Dumb. Thanks for staying with me on this, and I apologize for wasting your time. --Doc
No worries at all. Just glad we got it worked out.