Milter-greylist

my spf changes to the spec file didn't actually make it into the release. do 
you need a patch again?

On Thu, Oct 02, 2008 at 09:23:55AM -0700, Joe Pruett wrote:
> my spf changes to the spec file didn't actually make it into the release. do 
> you need a patch again?

I must have missed it, go ahead and resend.

-- 
Emmanuel Dreyfus
manu@...

it was in the release notes, that's why i was confused.  it also seems 
that my nolog logic isn't working.  the config file is accepted, but 
logging still happens.  i'll dig into this more later.

>  it also seems that my nolog logic isn't working.  the config file is
>  accepted, but logging still happens.  i'll dig into this more later.
>
> I fixed a bug where nolog wasn't respected when logging whitelist
> actions, and manu@ has already checked in it.

it looks like one line of my patch didn't make it in.  was it this that 
you fixed in acl.c?

1941c1966
<   if (retval & EXF_WHITELIST && (! (retval & EXF_NOLOG))) {
---
>   if (retval & EXF_WHITELIST) {

attached is the spec diff for libspf2.  enable with:

--define 'build_libspf2 1'

Joe Pruett <joey@...> wrote:

> 1941c1966
> <   if (retval & EXF_WHITELIST && (! (retval & EXF_NOLOG))) {
> ---
> >   if (retval & EXF_WHITELIST) {

Is that against CVS? Also, please use cvs diff -U4, it helps.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Joe Pruett <joey@...> wrote:

> attached is the spec diff for libspf2.  enable with:
> 
> --define 'build_libspf2 1'

Don't you also want to patch milter-greylist.spec.in?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

>> 1941c1966
>> <   if (retval & EXF_WHITELIST && (! (retval & EXF_NOLOG))) {
>> ---
>>>   if (retval & EXF_WHITELIST) {
>
> Is that against CVS? Also, please use cvs diff -U4, it helps.

that was pulled from the diff i had sent in before.  somehow that line 
didn't get updated in what is 4.1.6.  i was just trying to verify if that 
was what the other poster had submitted a patch for.  i guess i can go dig 
into the yahoo archive.

>> attached is the spec diff for libspf2.  enable with:
>>
>> --define 'build_libspf2 1'
>
> Don't you also want to patch milter-greylist.spec.in?

ah, i didn't even think about that.  i'm not sure i see the purpose of a 
spec.in file.  if you're using rpm, you aren't going to run configure 
first.  you just grab the spec and tar file and go.  but i know there is 
some rpmbuild option that starts from just a tar file, but i have never 
used that method.  i would guess it just uses the .spec file as well.  can 
anyone else speak to this?

>>> 1941c1966
>>> <   if (retval & EXF_WHITELIST && (! (retval & EXF_NOLOG))) {
>>> ---
>>>>   if (retval & EXF_WHITELIST) {
>>
>> Is that against CVS? Also, please use cvs diff -U4, it helps.
>
> that was pulled from the diff i had sent in before.  somehow that line
> didn't get updated in what is 4.1.6.  i was just trying to verify if that
> was what the other poster had submitted a patch for.  i guess i can go dig
> into the yahoo archive.

i think i found the patch that greg sent in and that isn't it.  so it 
looks like that line didn't make it in.  i'll use -U4 from now on.  i 
haven't setup cvs for mg yet, i guess i'll go do that so i can submit an 
update.

> i think i found the patch that greg sent in and that isn't it.  so it looks 
> like that line didn't make it in.  i'll use -U4 from now on.  i haven't setup 
> cvs for mg yet, i guess i'll go do that so i can submit an update.

i just looked at the cvs and a slightly different version of my change is 
in there so the next release should have it.

> ah, i didn't even think about that.  i'm not sure i see the purpose of a
> spec.in file.  if you're using rpm, you aren't going to run configure
> first.  you just grab the spec and tar file and go.  but i know there is
> some rpmbuild option that starts from just a tar file, but i have never
> used that method.  i would guess it just uses the .spec file as well.  can
> anyone else speak to this?

i just did some testing with rpmbuild -t and it just grabs the .spec file 
from inside the tarball and uses it directly.  so i think that having a 
spec.in file is probably not very useful.  if you used it in your process 
for building a tarball, that would be ok, but having the spec.in flow 
through to the user doesn't seem to add any benefit.  and all that is 
different between the files is @PACKAGE_VERSION@ vs 4.1.6 so the patch 
works for both files.

Joe Pruett <joey@...> wrote:

> ah, i didn't even think about that.  i'm not sure i see the purpose of a
> spec.in file.  if you're using rpm, you aren't going to run configure
> first.  you just grab the spec and tar file and go.  but i know there is
> some rpmbuild option that starts from just a tar file, but i have never
> used that method.  i would guess it just uses the .spec file as well.  can
> anyone else speak to this?

I always run configure before releasing so that the spec file is up to
date. That also produces a Makefile, which is not suitable for any
setup, but that is easier to hack if configure does not want to help at
all.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Hi John,

> attached is the spec diff for libspf2.  enable with:
> 
> --define 'build_libspf2 1'

You also need to add a patch to change the ownerships of this directory:

drwxr-xr-x  2 smmsp smmsp 4096 Oct  3 15:07 /var/milter-greylist/

ie. when building the RPM from the spec, it makes it:

drwxr-xr-x  2 root root 4096 Oct  3 15:07 /var/milter-greylist/

and sendmail fails to be able to read that directory because it doesn't have
permission to.

When I download any new release, I always have to add this into the spec or do
it manually after applying the RPM.

Regards,

Michael.

>> attached is the spec diff for libspf2.  enable with:
>>
>> --define 'build_libspf2 1'
>
> You also need to add a patch to change the ownerships of this directory:
>
> drwxr-xr-x  2 smmsp smmsp 4096 Oct  3 15:07 /var/milter-greylist/
>
> ie. when building the RPM from the spec, it makes it:
>
> drwxr-xr-x  2 root root 4096 Oct  3 15:07 /var/milter-greylist/
>
> and sendmail fails to be able to read that directory because it doesn't have
> permission to.
>
> When I download any new release, I always have to add this into the spec or do
> it manually after applying the RPM.

that is already handled by:

--define 'build_user smmsp'

> I always run configure before releasing so that the spec file is up to
> date. That also produces a Makefile, which is not suitable for any
> setup, but that is easier to hack if configure does not want to help at
> all.

in that case, you can apply the same spec patch to spec.in.