Bug 634760

Summary: Review Request: amavisd-milter - Sendmail milter for amavisd-new with support for the AM.PDP protocol
Product: [Fedora] Fedora Reporter: Andy Cobaugh <phalenor>
Component: Package ReviewAssignee: Ken Dreyer <ktdreyer>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: curtis, fedora-package-review, ktdreyer, msuchy, phalenor, redhat-bugzilla, sergiobelkin
Target Milestone: ---Flags: ktdreyer: fedora-review?
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-21 13:03:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 201449    

Description Andy Cobaugh 2010-09-16 22:25:54 UTC
Spec URL: http://www.bx.psu.edu/~phalenor/rpm/amavisd-milter/amavisd-milter.spec
SRPM URL: http://www.bx.psu.edu/~phalenor/rpm/amavisd-milter/amavisd-milter-1.5.0-2.src.rpm
Description: Taken from the project website:
"amavisd-milter is a sendmail milter (mail filter) for amavisd-new 2.4.3 or and
sendmail 8.13 and above (limited support for sendmail 8.12 is provided) which
use the new AM.PDP protocol.

Instead of older amavis-milter helper program, full amavisd-new functionality is
available, including adding spam and virus information header fields, modifying
Subject, adding address extensions and removing certain recipients from delivery
while delivering the same message to the rest."

The currently packaged amavisd-new-milter contains a milter that does not support the AM.PDP protocol, preventing it from making full use of the amavisd-new functionality. 

This is my first package, and will need a sponsor.

Comment 1 Sergio Belkin 2011-02-18 18:13:24 UTC
Hi,

I am not still member of packaging group, however I hope that you find my casual review useful:

1. You use localstatedir /var/amavis

Why? AFAIK amavisd-new in fedora doesn't use that directory:

repoquery -l amavisd-new | grep "var\/amavis" |wc -l
0

2. BuildRoot: and clean section are not needed anymore.

3. Beware you have some issue about initscript file, run rpmlint, you should not enable a service by default,  take a look at https://fedoraproject.org/wiki/Packaging/SysVInitScript. Also you will find interesting http://fedoraproject.org/wiki/Packaging:Tmpfiles.d and http://fedoraproject.org/wiki/Features/var-run-tmpfs.

4. Also this is no an error, but be aware that you're not using dist tag: http://fedoraproject.org/wiki/DistTag


Hope that helps.

Comment 2 Andy Cobaugh 2011-03-03 19:57:26 UTC
Thanks for the comments. RHEL uses /var/amavis, so I've put in a test for rhel vs fedora for that.

Regarding builroot and the clean section, what's the recommended way to handle that when building for RHEL? Are those two going away entirely, or just superfluous in fedora?

Comment 3 Ken Dreyer 2012-02-16 14:10:45 UTC
(In reply to comment #2)
> Thanks for the comments. RHEL uses /var/amavis, so I've put in a test for rhel
> vs fedora for that.

Can you post a link to your updated .spec and .srpm?

> Regarding builroot and the clean section, what's the recommended way to handle
> that when building for RHEL? Are those two going away entirely, or just
> superfluous in fedora?

You can just leave these in; they don't hurt anything on Fedora. Once RHEL 5 goes EOL you can remove them.

Comment 4 Jason Tibbitts 2012-04-24 21:36:35 UTC
Did we ever get an updated package?  All I see is the same release 2 package that was originally posted.

I guess I'll close this soon if there's no response.

Comment 5 Andy Cobaugh 2012-04-26 16:46:22 UTC
Hey folks. I changed jobs a few months back, but I'm still interested in getting this package into Fedora.

I'll try to get an updated package online in the next few days.

Comment 6 Ken Dreyer 2012-04-26 16:50:58 UTC
Hi Andy, since I know you a bit from the OpenAFS community, I'd be willing to sponsor you into the packager group in Fedora.

Comment 8 Ken Dreyer 2012-05-25 15:00:43 UTC
Package Review
Generated by fedora-review 0.1.2
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== C/C++ ====
[x]: MUST Package does not contain any libtool archives (.la)
[x]: MUST Package does not contain kernel modules.
[x]: MUST Package contains no static executables.
[x]: MUST Rpath absent or only used for internal libs.
[x]: MUST Package is not relocatable.


==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines. Yes, confirmed BSD.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture. Yes, F-15 i686.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST %config files are marked noreplace or the reason is justified.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: defattr(....) present in %files section. This is OK if packaging
     for EPEL5. Otherwise not needed
[-]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf is only needed if supporting EPEL5
[!]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package meets the Packaging Guidelines.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST No %config files under /usr.
[x]: MUST Package does not generates any conflict.
[!]: MUST Package obeys FHS, except libexecdir and /usr/target.
     See below discussion about /var/amavis.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint output is silent.
[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/ktdreyer/fedora-scm/amavisd-milter/634760/amavisd-milter-1.5.0.tar.gz :
  MD5SUM this package     : 2c9f601012164d14a0c2815a9e0928fe
  MD5SUM upstream package : 2c9f601012164d14a0c2815a9e0928fe

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[-]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[!]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[?]: SHOULD Package functions as described.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD Scriptlets must be sane, if used.
[x]: SHOULD SourceX is a working URL.
[-]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[-]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.

==== Remaining Issues: ==== 
1. Please include the "LICENSE" file in your %doc line.

2. I'm wondering where the "/var/amavis" line comes from, because amavisd-new in both EPEL 5 and EPEL 6 use /var/spool/amavisd. Could this be a holdover from EPEL 4? From what I can see, I think this needs to be /var/spool/amavisd unconditionally.  

==== Nice-to-haves: ====
1. Most packages in Fedora use dist tags, and I highly recommend them.
   For example, you would change the "Release" line to be:

Release: 3%{dist}

2. It would be nice to have a systemd unit file, but it's not required.

3. It's "better" to use %global rather than %define with amavisdir.
   Note: %define amavisdir /var/amavis %define amavisdir /var/spool/amavisd
   %define _localstatedir %{amavisdir}

Overall looks good. If you take care of these things, I'll approve the package and sponsor you.

Comment 9 Andy Cobaugh 2012-05-29 14:43:59 UTC
> ==== Remaining Issues: ==== 
> 1. Please include the "LICENSE" file in your %doc line.

fixed in -4
 
> 2. I'm wondering where the "/var/amavis" line comes from, because
> amavisd-new in both EPEL 5 and EPEL 6 use /var/spool/amavisd. Could this be
> a holdover from EPEL 4? From what I can see, I think this needs to be
> /var/spool/amavisd unconditionally.  

I was wondering that myself. Digging in a bit further, it looks like the RPMforge packaging of amavisd uses /var/amavis, while EPEL uses /var/spool/amavisd. I've removed that logic completely in -4.
 
> ==== Nice-to-haves: ====
> 1. Most packages in Fedora use dist tags, and I highly recommend them.
>    For example, you would change the "Release" line to be:

Yep, I usually use dist tags. Added in -4.

> 3. It's "better" to use %global rather than %define with amavisdir.
>    Note: %define amavisdir /var/amavis %define amavisdir /var/spool/amavisd
>    %define _localstatedir %{amavisdir}

Fixed in -4

New specfile and srpm are here:
http://www.personal.psu.edu/~atc135/rpm/amavisd-milter/amavisd-milter-1.5.0-4.el6.src.rpm
http://www.personal.psu.edu/~atc135/rpm/amavisd-milter/amavisd-milter.spec

--andy

Comment 10 Ken Dreyer 2012-06-01 17:20:29 UTC
Hi Andy,

(In reply to comment #9)
> > 3. It's "better" to use %global rather than %define with amavisdir.
> >    Note: %define amavisdir /var/amavis %define amavisdir /var/spool/amavisd
> >    %define _localstatedir %{amavisdir}
> 
> Fixed in -4

Sorry I wasn't clear here. %global is the preferred option for %define in almost all cases. And it's perferable to not mix %global and %define.

There's a discussion about my sponsorship at https://fedorahosted.org/packager-sponsors/ticket/1, and when cwickert looked at this review he suggested that you preserve the timestamps when installing files. You can do this with the "-p" flag to the "install" command.

I'm going to wait to see how my sponsorship request shakes out, if you're ok waiting a few more days?

Comment 11 Ken Dreyer 2012-06-06 22:11:15 UTC
It looks like systemd unit files are actually required for all new packages: https://fedoraproject.org/wiki/Packaging:Systemd

So amavisd-milter will need to provide a systemd unit file for inclusion in Fedora (sorry I missied this in my comment #8 above.)

Comment 12 Ken Dreyer 2013-12-02 17:59:03 UTC
Hi Andy, I was going through my older bugs and ran across this one. I wanted to see if you're still interested in getting this into Fedora?

Comment 13 Miroslav Suchý 2015-07-21 13:03:40 UTC
Closing due long inactivity. Feel free to reopen if you want to continue.