In the spec file, one can find that strange/ugly line, that displays a 
warnings when building:
Requires: httpd-mmn = %(cat %{_includedir}/httpd/.mmn || echo missing)

That line isn't particularly strange, though; the technique is commonly used. 
What do you find odd about it?

I guess the only thing I'd do is add 2>/dev/null to quiet the case where the
file doesn't exist.

merged long ago, closing.

Jeff, dumb Red Hat employee! You are not allowed to close this review
before a reviewer has set fedora-review+ - reopening...

Jeff,

1)   If you was not triaging this bug, if you are not reviewing this package and assuming you are maintaining this package, will you please fix following rpmlint messages?

subversion.src: W: strange-permission filter-requires.sh 0775L
subversion.src:7: E: hardcoded-library-path in /usr/lib/jvm/java
subversion.src:222: E: use-of-RPM_SOURCE_DIR
subversion.src: W: patch-not-applied Patch6: subversion-1.6.0-pie.patch


subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/i686-debian-sarge1/svnlog.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/i686-debian-sarge1/svnclean.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/osx10.4-gcc4.0.1-ia32/svnbuild.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/osx10.4-gcc4.0.1-ia32/svncheck.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/i686-debian-sarge1/svnbuild.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/osx10.4-gcc4.0.1-ia32/svnlog.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/i686-debian-sarge1/svncheck.sh
subversion.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/subversion-1.6.12/tools/buildbot/slaves/osx10.4-gcc4.0.1-ia32/svnclean.sh


subversion-gnome.x86_64: E: library-without-ldconfig-postin /usr/lib64/libsvn_auth_gnome_keyring-1.so.0.0.0
subversion-gnome.x86_64: E: library-without-ldconfig-postun /usr/lib64/libsvn_auth_gnome_keyring-1.so.0.0.0
subversion-kde.x86_64: E: library-without-ldconfig-postin /usr/lib64/libsvn_auth_kwallet-1.so.0.0.0
subversion-kde.x86_64: E: library-without-ldconfig-postun /usr/lib64/libsvn_auth_kwallet-1.so.0.0.0


2) I am not sure why you need both python and python-devel as BuildRequires:
as per https://fedoraproject.org/wiki/Packaging/Python, you should change it to 

BuildRequires: python2-devel 

3) you don't need following in spec as per guidelines.
%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

3) you don't need perl macro as its not included in /usr/lib/rpm/macros.perl
drop following line
%define perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch)

4) Drop Buildroot tag, %clean section and cleaning of buildroot in %install in devel branch as its not needed now.

Note: This is not complete review, just initial comments.

Unfortunately no time in future to work on this. Removing myself.

Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Think that this can be closed now, anyone disagree please provide a fix for the bit you disagree on