Victory - built subversion from RH9 source rpm!

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.