Re: fix for failing tests with gmime 2.6.19

[Tomi Ollila <tomi.ollila@iki.fi>]

On Sun, Nov 10 2013, David Bremner <david@tethera.net> wrote:

> Although Jeffrey Stedfast fixed gmime bug 711305 amazingly quickly, it
> looks like many people still have to live with a buggy version of
> gmime for a while yet. Here is an opt-in fix that stops the test suite
> from failing; this is a simple fix for e.g. the debian build process.

After looking throught all the comments and thinking about the options
I see the following 2 options

1) Keep things as those currently are. Anyone who runs tests when 
   gmime 2.6.19 is in use will see some tests fail (and some may not have
   a clue what's going on). We could mention this first thing in the NEWS
   so that the "professional" users who run test *and* reads NEWS will
   get the clue. 

2) Push the current patches to release branch *only* (maybe the test
   could be changed to if [ pkg-config --exact-version=2.6.19 gmime-2.6 ] (*)
   instead of checking the WORKAROUNDS flag so that users would not have
   to bother (and some may not have a clue what's going on)). During merge
   to master (as it has been done in the past) these changes would probably
   be dropped.

2b) Merge to master, release 0.17, follow gmime deployments, revert
    patches.


IMHO for temporary problems there could be temporary cruft (which would
not be cruft if the problem wasn't temporary). The test system must
be as strict as it can be to ensure best failure coverage.

Tomi


(*) The fastest (& most cruftiest) implementation:

notmuch_reply_sanitize ()
{
   if pkg-config --exact-version=2.6.19 gmime-2.6 >/dev/null
   then
        notmuch_reply_sanitize () {
	   # work around GMIME bug #711305
	    sed -e 's/^References:  /References: /'
        }
   else     
        notmuch_reply_sanitize () {
	    cat
        }
   fi
   notmuch_reply_sanitize # call just rewritten version of this function
}