Those who have been following the saga of my attempt (did I hear someone
say quixotic) to build Subversion from the Source RPMs will be happy to
know that I have finally achieved this goal.
What I learned along the way may be of interest to those who are putting
together Subversion source rpms for Linux systems as well as to those
who try to build from these RPMs.
Actually, I already had a version of SVN 1.1.3 running, built on my
Redhat 9 system from David Summers binary RPMs. Thanks, David.
But I wanted source so I could build JavaHL and put it into subeclipse.
I still haven't even gotten to that part yet, I spent the better part
of a week getting the source RPM to build. Which is the subject of this
tale.
For those who haven't been following, the problems came during the
running of the tests that are included in the source rpm. Yes, I know,
these can be turned off in the spec file, but maybe they're important?
Someone turned them on for a reason. What was the reason? Who am I to
take them out? Anyway, that's the sort of guy I am. I don't like
taking the easy way out.
The tests that failed were always those following this line:
*** Running regression tests on RA_DAV (HTTP method) layer ***
as follows:
+ killall httpd
+ sleep 1
++ pwd
+ sed -e 's;@SVNDIR@;/usr/src/redhat/BUILD/subversion-1.1.3;'
++ pwd
+ /usr/sbin/httpd -f /usr/src/redhat/BUILD/subversion-1.1.3/httpd.conf
httpd: Could not determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName
+ sleep 1
+ make check BASE_URL=http://localhost:15835
Running all tests in config-test...success
...
Running all tests in getopt_tests.py...success
Running all tests in basic_tests.py...FAILURE
Running all tests in commit_tests.py...FAILURE
...
At least one test FAILED, checking
/usr/src/redhat/BUILD/subversion-1.1.3/tests.log
Looking at tests.log (thanks to Max Bowsher for pointing this haystack
needle out) the failures appeared here:
svn: PROPFIND request failed on '/local_tmp/repos'
svn: PROPFIND of '/local_tmp/repos': could not connect to server
(http://localhost:15835)
Could not connect to server. That's interesting. Hmm, why not?
# /sbin/service httpd status
httpd dead but subsys locked
httpd dead?
Well, it was running before. Hmm, that's right, the script killed it.
Then it wouldn't start a few lines later. Why not? A timing issue?
Not likely, but then what?
I started looking at the apache logs in /var/log/httpd. No clue there.
Why won't the damned thing start?
Something wrong with the config. But the apache config syntax check
command is passing the new config that is supplied in the source RPM.
Then I caught a lucky break! (Days are going by between all these
steps, by the way). I got lucky when I accidentally
typed "tail error_log" from the /usr/src/redhat/BUILD directory instead
of "tail /var/log/httpd/error_log" and found where the real log messages
were going!
Aha!
[Thu Feb 10 20:56:21 2005] [alert] (2)No such file or directory:
getpwuid: couldn't determine user name from uid 4294967295, you probably
need to modify the User directive
From there, a simple google quickly brought me to the nub of the issue:
The User and Group directives in the httpd.conf that comes in the
source RPM were commented out - and apache can't start without them.
D'OH!!!!!!!!!!!!
Well, from here it was simple to hack up the spec file to pass the User
and Group directives into the apache startup command:
%define apache_user apache
%define apache_group apache
...
/usr/sbin/httpd -C "User %{apache_user}" -C "Group %{apache_group}" -f
`pwd`/httpd.conf
AND THE SRC RPM BUILD COMPLETES SUCCESSFULLY! BREAK OUT THE CHAMPAGNE!!!
I realize that this may not be a universally applicable solution. There
may not even be one unless we want to insist on creating the "apache"
user. For one thing, the Apache documentation says that the User
directive is only applicable when running as root - and I was building
as root, against the advice of more experienced Linux administrative
types. How would you handle this if you were not root? You'd have to
modify the httpd.conf file. But that comes from INSIDE the source rpm.
There may be a way around this that more experienced rpm builders know
about, but I don't. I suppose a python script could be written to take
the user's real httpd.conf file and make a copy with the mods needed to
run the tests.
It's understandable that the creators of the source rpm would comment
these lines out, since different installers might have their Apache
configured to run as different users. But without these directives
APACHE WON'T START!!!!! And the tests will fail, and leave poor user
scratching his head.
The source RPM should not turn tests on by default when they are
absolutely going to fail!
===================================================================
And so we come to the real question for the Subversion test developers
and Subversion packagers (source rpm builders)?
Should such tests be part of build scripts for the general public such
as source rpms? Or are these tests the province of the Subversion
developers themselves? When their source is released to the world
should the users out there in the world be entitled to assume that unit
tests have passed and that this version of subversion works in a
properly configured environment? Or should they run the tests to prove
that their environment is good? There is very little documented
guidance on these questions, and people are getting discouraged, going
wrong. It's wrong to blame this one on Linux, or RedHat. I was
seriously thinking of upgrading my OS until I found the simple way out
of this.
No, this is a self-inflicted wound by the Subversion development
community. If the Subversion community doesn't want its product to get
the reputation of being "too hard" it ought to answer questions like these.
Are the tests testing subversion or subversion plus its environment? Or
either one? It seems to me that this whole process would have been
easier had there been more documentation of what these tests did and
their proper configuration. But to just plop them into a source rpm
package without this information seems like the wrong way to go.
Open source development is difficult enough without all this easily
avoided toe-stubbing. Better documentation is needed.
Oh well. Perhaps this tale of mine will help someone else out in the
future.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 04:47:41 2005