Bug 149595 - gftp won't start from icon or command line
Summary: gftp won't start from icon or command line
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gftp   
(Show other bugs)
Version: 4.0
Hardware: athlon Linux
Target Milestone: ---
: ---
Assignee: David Zeuthen
QA Contact:
: 149586 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-24 11:56 UTC by Robert G. 'Doc' Savage
Modified: 2013-03-06 03:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-09 05:49:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Outputs of 'set' for root and ordinary user. (3.94 KB, text/plain)
2005-03-07 12:00 UTC, Robert G. 'Doc' Savage
no flags Details
The last few output lines from 'rpmbuild -ba gftp.spec' w/error detail (1.10 KB, text/plain)
2005-03-07 12:46 UTC, Robert G. 'Doc' Savage
no flags Details
Output of '# egrep -r "%_prefix|%_datadir" /usr/lib/rpm ~/.rpmmacros' (861 bytes, text/plain)
2005-03-08 02:58 UTC, Robert G. 'Doc' Savage
no flags Details
Output of '# strace -o /tmp/gftp.out gftp (29.24 KB, text/plain)
2005-03-08 12:10 UTC, Robert G. 'Doc' Savage
no flags Details

Description Robert G. 'Doc' Savage 2005-02-24 11:56:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
gftp cannot locate its config file and aborts at startup. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. At a shell prompt enter:
   $ gftp &

Actual Results:  When started using the gftp desktop icon, nothing

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?

Comment 1 Jay Turner 2005-02-24 15:28:35 UTC
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?

Comment 2 Jay Turner 2005-02-24 15:38:20 UTC
*** Bug 149586 has been marked as a duplicate of this bug. ***

Comment 3 Robert G. 'Doc' Savage 2005-02-25 18:30:05 UTC

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

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.


Comment 4 Jay Turner 2005-02-25 19:33:01 UTC
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.

Comment 5 Robert G. 'Doc' Savage 2005-03-05 22:41:56 UTC
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

Comment 6 Jay Turner 2005-03-07 07:50:09 UTC
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?

Comment 7 Robert G. 'Doc' Savage 2005-03-07 11:54:31 UTC

Yes: redhat-rpm-config-

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.

Comment 8 Robert G. 'Doc' Savage 2005-03-07 12:00:12 UTC
Created attachment 111734 [details]
Outputs of 'set' for root and ordinary user.

Comment 9 Robert G. 'Doc' Savage 2005-03-07 12:46:11 UTC
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

Comment 10 Robert G. 'Doc' Savage 2005-03-07 12:47:47 UTC
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.

Comment 11 Jay Turner 2005-03-07 13:15:21 UTC
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.

Comment 12 Robert G. 'Doc' Savage 2005-03-08 02:58:48 UTC
Created attachment 111768 [details]
Output of '# egrep -r "%_prefix|%_datadir" /usr/lib/rpm ~/.rpmmacros'

Comment 13 Robert G. 'Doc' Savage 2005-03-08 02:59:43 UTC

The egrep output is attached...


Comment 14 Jay Turner 2005-03-08 09:45:25 UTC
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.

Comment 15 Robert G. 'Doc' Savage 2005-03-08 12:10:08 UTC
Created attachment 111775 [details]
Output of '# strace -o /tmp/gftp.out gftp

Comment 16 Robert G. 'Doc' Savage 2005-03-08 12:18:58 UTC

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...


Comment 17 Jay Turner 2005-03-08 14:00:17 UTC
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.

Comment 18 Robert G. 'Doc' Savage 2005-03-09 05:49:22 UTC

/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.


Comment 19 Jay Turner 2005-03-09 11:50:50 UTC
No worries at all.  Just glad we got it worked out.

Note You need to log in before you can comment on or make changes to this bug.