On Thu, 10 Feb 2005, Steve Cohen wrote:
> 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.
I'm glad it was useful to you.
> 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.
Sorry you had to pull your hair out, if you still run into problems, let
me know.
> 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!!!!!!!!!!!!
Hmm, I've been building as non-root user for 3+ years with these RPMs and
apache always starts for me......
> 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!!!
Glad you got it figured out!
> 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.
As far as I know, "it just works (TM)" without being root. I try very
hard to make all my RPMs not require root to build.
Don't build my RPMs as root user, you may run into problems. :-)
> 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.
Hmm, are you sure? I've never had problems running it this way.
> The source RPM should not turn tests on by default when they are absolutely
> going to fail!
They've not failed for me.
> ===================================================================
>
> 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.
I think of it as "the last line of defense". I've had times when
Subversion built and tested OK for everyone else except for me. When I
ran into test-suite failures, I checked with the developers and they found
issues in the code that needed to be addressed.
Because of that I don't want to take them out, the RPM builds are not
perfect but the built-in testing has saved us from a bad build for the
RedHat 7.3, 8.0, 9.0, RHEL3/WBEL3 packages in the past.
> 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.
My take is that the tests are testing everything that can be tested
without actually installing and running the programs.
> Open source development is difficult enough without all this easily avoided
> toe-stubbing. Better documentation is needed.
Let me know how it can be better documented. (better yet, send a patch!
:-)
I love making things better.
> Oh well. Perhaps this tale of mine will help someone else out in the future.
>
Yes, I hope so. Thanks for the tale.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 12 00:50:56 2005