Re: [exim] SPF not working in Exim 4.91 ?

Top Page
Delete this message
Reply to this message
Author: Odhiambo Washington
Date:  
To: Mike Tubby
CC: exim users
Subject: Re: [exim] SPF not working in Exim 4.91 ?
On Wed, 16 Jan 2019 at 18:26, Mike Tubby via Exim-users <exim-users@???>
wrote:

>
> On 15/01/2019 10:21, Jeremy Harris via Exim-users wrote:
> > On 15/01/2019 09:54, Mike Tubby via Exim-users wrote:
> >> Can someone point me in the right direction?
> > Presumably your build didn't actually include SPF. Check
> > the "Support for" line from "exim -bV". If it's not there,
> > check you have a consistent set of source files and that
> > you didn't try and build on top of some previous version.
>
> I did build on a previous version that had:
>
> EXPERIMENTAL_SPF=yes
>
> In Local/Makefile
>
> I changed it to:
>
> SUPPORT_SPF=yes
>
> but it didn't work possibly because I just did a "make; make install"
> ... I have now performed:
>
> make clean
> make makefile
> make
> make install
>
> and it fixed it.
>


Great!



>
> However, I noticed two other issues:
>
>
> *1. Double increment of build numbers*
>
> I only get even-numbered compile numbers due to what looks like a double
> increment:
>
> root@relay1:~/exim-4.91# make install
> /bin/sh scripts/source_checks
> `Makefile' is up to date.
>
> make[1]: Entering directory '/home/mike/exim-4.91/build-Linux-x86_64'
> *>>> version 4.91 #9
> >>> version 4.91 #10*
>


I have always never bothered about the compile numbers. Are they important
in a way??



>
> >>> exicyclog script built
> >>> exinext script built
> >>> exiwhat script built
>
> *2. Warning for unused return in usr1_handler*
>
> GCC compiler generates a warning for unsied return codes in usr1_handler:
>
> gcc exim.c
> exim.c: In function ‘usr1_handler’:
> exim.c:242:1: warning: ignoring return value of ‘write’, declared with
> attribute warn_unused_result [-Wunused-result]
> (void)write(fd, process_info, process_info_len);
> ^
> gcc expand.c
>
> I have created a fix and sent a separate email with a proposed patch.
>


Aha. Why don't you try the 4.92RC and see if the same issue exists, and
give a patch
as well. I am saying that because we already started looking ahead -
towards 4.92.





--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)