[Mailman-Users] ht://Dig integration patches with Mailman 2.1.12/RHEL 6.5

[Greg Earle]

At work I'm dealing with migrating a legacy production system that
uses Mailman 2.1.9 with ht://Dig integration on a RHEL 5.x box.

I'm trying to migrate it to a RHEL 6.5 system with Mailman 2.1.12-18.

I have the indexing and ht://Dig patches for 2.1.12 and I'm trying
to integrate it into a custom RPM build, like its predecessor.  Basing
it on mailman-2.1.12-18.el6.src.rpm.

Has anyone on the list done this before?

It seems like no matter where I try to put the 2 patches in the .spec
file, there is a conflict between the htdig patch and some other patch
(like the "cron" patch or the "FHS" patch).

What's strange is that the patches for 2.1.9 seem not all that very
different, and yet that rpmbuild worked perfectly for me!  But no
such luck with 2.1.12 so far.

If I look in the old 2.1.9 version of the htdig patch file, I see
this segment for "crontab.in.in", for example:

--
diff -ruP --exclude=.DS_Store mailman-2.1.9-index/cron/crontab.in.in mailman-2.1
.9-htdig/cron/crontab.in.in
--- mailman-2.1.9-index/cron/crontab.in.in      2002-01-06 06:28:12.000000000 +0
000
+++ mailman-2.1.9-htdig/cron/crontab.in.in      2006-09-20 16:06:17.000000000 +0
100
@@ -18,6 +18,11 @@
 # or want to exclusively use a callback strategy instead of polling.
 0,5,10,15,20,25,30,35,40,45,50,55 * * * * @PYTHON@ -S @prefix@/cron/gate_news
 #
+# At 2:19am every night, regenerate htdig search files.  Only
+# turn this on if the internal archiver is used and htdig
+# use enabled in mm_cfg.py with USE_HTDIG
+19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
+#
 # At 3:27am every night, regenerate the gzip'd archive file.  Only
 # turn this on if the internal archiver is used and
 # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
--

which assumes that line 19 has "gate_news" and "@PYTHON@" in it.

Yet if I look at the actual diffs after the 2.1.9 htdig patch was
(successfully) applied, it's somehow not the same:

--
[root at rushmore cron]# diff -u crontab.in.in.htdig crontab.in.in
--- crontab.in.in.htdig	2009-04-02 01:45:29.000000000 -0700
+++ crontab.in.in	2009-04-02 01:45:29.000000000 -0700
@@ -41,6 +41,11 @@
 # or want to exclusively use a callback strategy instead of polling.
 0,5,10,15,20,25,30,35,40,45,50,55 * * * * @MAILMAN_USER@ @prefix@/cron/gate_news
 #
+# At 2:19am every night, regenerate htdig search files.  Only
+# turn this on if the internal archiver is used and htdig
+# use enabled in mm_cfg.py with USE_HTDIG
+19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
+#
 # At 3:27am every night, regenerate the gzip'd archive file.  Only
 # turn this on if the internal archiver is used and
 # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
--

Note the "@MAILMAN_USER@" on the "gate_news" line (which is now line 42
after the "cron" patch had been applied).  Plus, after the "cron" patch
was applied, the line numbers in the "htdig" patch are no longer correct.

In other words, shouldn't the 2.1.9 patch have choked as well, just
as the 2.1.12 patch seems to be doing to me now?

I tried changing the current 2.1.12 htdig patch and put in "@MAILMAN_USER@".

Now the htdig patch works - but then I get an immediate .rej file from
the FHS patch right afterwards.  :-(

The htdig patch assumes FHS hasn't been applied yet - but if htdig is
applied before FHS, then FHS breaks because it doesn't know about the
added "archives/htdig" entry in VAR_DIRS that the htdig patch put there.

I re-ran the 2.1.9 rpmbuild and sure enough, it worked perfectly fine:

--
[...]
Patch #4 (mailman-cron.patch):
+ patch -p1 -b --suffix .cron -s
+ echo 'Patch #5 (indexing-2.1.9-0.1.patch):'
Patch #5 (indexing-2.1.9-0.1.patch):
+ patch -p1 -b --suffix .indexing -s
+ echo 'Patch #6 (htdig-2.1.9-0.1.patch):'
Patch #6 (htdig-2.1.9-0.1.patch):
+ patch -p1 -b --suffix .htdig -s
+ echo 'Patch #7 (mailman-FHS.patch):'
Patch #7 (mailman-FHS.patch):
+ patch -p1 -b --suffix .FHS -s
[...]
--

At this point I'm more shocked that the 2.1.9 patches worked, given what
I've seen with the 2.1.12 patches.  Color me baffled at this point!

If anyone has successfully done this integration and can offer any pointers
(like what order to do the patching, and what patch number in the spec file
to insert them into, or what obvious thing I'm doing wrong), feel free to
respond or send me e-mail directly and take it off-line.

Thanks,

	- Greg