Bug 905304 - Review Request: OpenDMARC - Domain-based Message Authentication, Reporting & Conformance (DMARC) milter and library
Summary: Review Request: OpenDMARC - Domain-based Message Authentication, Reporting & ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Adam Williamson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 921797 980281 983551 1022349
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-29 06:07 UTC by Steve Jenkins
Modified: 2015-05-20 04:55 UTC (History)
13 users (show)

Fixed In Version: opendmarc-1.3.1-13.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-06 16:08:13 UTC
Type: ---
Embargoed:
awilliam: fedora-review+


Attachments (Terms of Use)
opendmarc-1.1.3.spec (5.42 KB, text/x-rpm-spec)
2013-07-11 17:25 UTC, Patrick Laimbock
no flags Details
OpenDMARC spec file version 1.1.3-3 (6.78 KB, text/x-rpm-spec)
2013-07-26 13:36 UTC, Patrick Laimbock
no flags Details
OpenDMARC SRPM version 1.1.3-3 (578.64 KB, application/x-rpm)
2013-07-26 13:38 UTC, Patrick Laimbock
no flags Details

Description Steve Jenkins 2013-01-29 06:07:37 UTC
Spec URL: http://stevej.fedorapeople.org/OpenDMARC/opendmarc.spec
SRPM URL: http://stevej.fedorapeople.org/OpenDMARC/opendmarc-1.0.1-1.fc17.src.rpm
Description: Domain-based Message Authentication, Reporting & Conformance, or DMARC, builds on the successes of technologies such as DomainKeys Identified Mail (DKIM) and the Sender Policy Framework (SPF) to create an infrastructure that enforces policy on domain names that are visible to end users, and creates a feedback framework for identifying and tracking fraudulent use of domain names in email.

Fedora Account System Username: stevej

Comment 1 Steve Jenkins 2013-01-29 06:11:03 UTC
Additional description:

OpenDMARC (Domain-based Message Authentication, Reporting & Conformance)
provides an open source library that implements the DMARC verification
service plus a milter-based filter application that can plug in to any
milter-aware MTA, including sendmail, Postfix, or any other MTA that supports
the milter protocol.

Comment 2 Adam Williamson 2013-02-22 04:34:55 UTC
I was just looking at implementing DMARC and packaging this, so I'll review it instead. (Thanks for your work on OpenDKIM, BTW). I might sneak a few support requests into the review ;)

Comment 3 Steve Jenkins 2013-02-22 04:59:07 UTC
Great - thanks, Adam! I've been waiting around for a review to help kick this off, so I appreciate it! :)

Comment 4 Adam Williamson 2013-02-22 05:45:42 UTC
* Comment: I noticed some problems on the licensing front in the course of review - problems in upstream, not your package. See https://sourceforge.net/p/opendmarc/tickets/42/ .

* Comment: I don't think this is a blocker for the review, but it seems a shame to be introducing a SysV-native package at this point. If you feel like adding a systemd service and contributing it upstream, that might be nice. See https://fedoraproject.org/wiki/Features/SysVtoSystemd .

MUST: rpmlint output (SRPM and spec): PASS

W: rpm-buildroot-usage %build make DESTDIR=%{buildroot} %{?_smp_mflags} %{LIBTOOL}
W: spelling-error Summary(en_US) milter -> molter, miler, miter
W: spelling-error %description -l en_US milter -> molter, miler, miter
W: spelling-error %description -l en_US sendmail -> send mail, send-mail, Sendai

All bogus.

MUST: rpmlint output (RPMs): NEEDSWORK

W: incoherent-version-in-changelog 1.0.1 ['1.0.1-1.fc17', '1.0.1-1']

Bogus.

E: wrong-script-interpreter /usr/share/doc/opendmarc-1.0.1/dmarcfail.py /usr/local/bin/python

Doesn't seem significant, as it's in an example in the doc dir.

W: non-standard-uid /var/run/opendmarc opendmarc
W: non-standard-gid /var/run/opendmarc opendmarc
W: non-standard-uid /var/spool/opendmarc opendmarc
W: non-standard-gid /var/spool/opendmarc opendmarc

You're using the correct scriptlet snippets, so I figure these are bogus - probably rpmlint getting confused.

E: executable-marked-as-config-file /etc/opendmarc.conf

The spec has:

install -m 0755 opendmarc/%{name}.conf.sample %{buildroot}%{_sysconfdir}/%{name}.conf

That does look wrong. Should be 0644 I guess? Or maybe even 0600? Not sure if it needs to be secured.

E: script-without-shebang /etc/opendmarc.conf

I think this is another symptom of it being marked executable.

W: no-manual-page-for-binary opendmarc-importstats
W: install-file-in-docs /usr/share/doc/opendmarc-1.0.1/INSTALL

Not our problem.

W: service-default-enabled /etc/rc.d/init.d/opendmarc

Indeed, the upstream service file is default enabled. So, here we wade into shark-infested waters:

https://fedoraproject.org/wiki/Starting_services_by_default

"If a service does not require configuration to be functional and does not listen on a network socket, it may be enabled by default (but is not required to do so)...All other services must not be enabled by default. If you think that your package contains a service that should be enabled by default, but does not meet the above criteria, you may request an exception from the FESCo."

Now I may be wrong here, but I *think* the package is set up to listen on a network socket by default. opendmarc.conf.sample has:

# Socket inet:8893@localhost

and the spec does:

sed -i 's|^# Socket |Socket |' %{buildroot}%{_sysconfdir}/%{name}.conf

Which I believe will result in opendmarc listening on port 8893 by default. Please explain if I'm wrong here. I believe acceptable alternatives would be to use a domain socket by default instead (though the opendmarc README notes a chrooted postfix may not be able to see it), or to not enable the service by default, or to request an exception, but again, IMBW.

MUST: The package must be named according to the Package Naming Guidelines: PASS
MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines: NEEDSWORK

See above comment / upstream bug - the Sendmail license states "Redistributions of Source Code must retain the copyright notices as they appear in each Source Code file, these license terms, and the disclaimer/limitation of liability set forth as paragraph 6 below.", and the opendmarc tarball does not include the Sendmail license. If upstream doesn't respond to to the ticket promptly, you could just include it as an additional source file. If you think I'm being too much of a license weenie here, CC spot and see what he thinks :)

MUST: The License field in the package spec file must match the actual license: PASS (though I like to include a comment on multi-license packages, briefly explaining in more detail)

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 must be included in %doc: PASS (but see above)
MUST: The spec file must be written in American English: PASS
MUST: The spec file for the package MUST be legible: PASS
MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the sources file once imported into git. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this: PASS
MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture: PASS http://koji.fedoraproject.org/koji/taskinfo?taskID=5042209

MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line: N/A (AFAIK)
MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense: PASS
MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden: N/A
MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun: PASS
MUST: Packages must NOT bundle copies of system libraries: PASS
MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker: N/A
MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory: PASS
MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations): PASS
MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example: NEEDSWORK (see rpmlint item)
MUST: Each package must consistently use macros: PASS
MUST: The package must contain code, or permissable content: PASS
MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity): N/A
MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present: PASS
MUST: Static libraries must be in a -static package: N/A
MUST: Development files must be in a -devel package: PASS
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}: NEEDSWORK - the %{?_isa} is missing (though that's a new wrinkle on me, too - there's a note attached to the guideline, read that :>)
MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built: PASS
MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation: N/A
MUST: Packages must not own files or directories already owned by other packages: PASS
MUST: All filenames in rpm packages must be valid UTF-8: PASS

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: I did that for you!

SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available: N/A
SHOULD: The reviewer should test that the package builds in mock: PASS (used koji)
SHOULD: The package should compile and build into binary rpms on all supported architectures: PASS
SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example: I'll work on that later
SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity: PASS
SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency: N/A
SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb: N/A (no .pc file)
SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself: N/A
SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense: PASS

Overall result - NEEDSWORK, but fairly minor. I'll start trying to actually deploy the package here soon, and add any additional comments (or pleas for help) :)

Comment 5 Steve Jenkins 2013-02-22 17:40:34 UTC
Good stuff, Adam. Thanks. I'm sharing your latest comment with the developer(s) in IRC right now, and will work through them all. I also welcome any additional input you generate while you deploy it.

Comment 6 Adam Williamson 2013-02-23 23:38:08 UTC
OK, so here's my first dumb support question: according to the docs, opendmarc "does not itself do DKIM or SPF evaluation" - http://www.trusteddomain.org/opendmarc/opendmarc.8.html . So when configuring postfix, you're told "Note that this must come after filters that do DKIM and SPF evaluation, as this filter relies on the addition of authentication results data to the header by upstream filters."

Okay, fine. Obviously we use opendkim as our DKIM milter, that's straightforward enough. But what do we use for SPF? I can't find any SPF milter packaged in Fedora. The candidates appear to be gmilt and smf-spf, but we don't have either of those.

Is it just me, or are the opendmarc 'how to deploy' docs pretty incomplete? There's no kind of information on a recommended DKIM / SPF milter setup, and I also feel like it's somehow missing instructions on database configuration - it seems like the report generation stuff possibly requires a database, somehow, but I just don't see any instructions on how to set that up.

Do you actually have a working opendmarc config set up over there? Did you find any better docs? :)

Comment 7 Patrick 2013-07-04 12:10:01 UTC
Adam: I was wondering the same thing and did some digging. An SPF checking policy needs to be setup in /etc/postfix/main.cf smtpd_recipient_restrictions section so that an SPF check result is added to the email headers which can then be evaluated by OpenDMARC. Afaict these are the two main SPF milters (the python one is actively developed):

postfix-policyd-spf-python https://launchpad.net/pypolicyd-spf/
postfix-policyd-spf-perl https://launchpad.net/postfix-policyd-spf-perl/

So I guess at least the python one needs to be packaged too if you want to be able to use OpenDMARC. And off course you need the TXT record(s) too:

http://www.unlocktheinbox.com/dmarcwizard.aspx
http://support.google.com/a/bin/answer.py?hl=en&answer=2466563

Hope this helps.

Comment 8 Adam Williamson 2013-07-04 21:34:15 UTC
Steve, are you still working on this?

Comment 9 Patrick Laimbock 2013-07-11 17:25:18 UTC
Created attachment 772337 [details]
opendmarc-1.1.3.spec

This is the opendmarc spec file updated to version 1.1.3

Comment 10 Patrick Laimbock 2013-07-11 17:43:23 UTC
I have just uploaded an updated opendmarc spec file for version 1.1.3. Here are the results of the scratch build (for EL6):

http://koji.fedoraproject.org/koji/taskinfo?taskID=5594963

The results of rpmlint:

$ rpmlint ./opendmarc-1.1.3.spec 
./opendmarc-1.1.3.spec:59: W: rpm-buildroot-usage %build make DESTDIR=%{buildroot} %{?_smp_mflags} %{LIBTOOL}
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Did a test drive and it works for me besides a bunch of AVCs which unsurprisingly are caused by the lack of an OpenDMARC SELinux policy. Filed as BZ983551

Since Steve has not responded (yet), I'm happy to pitch in to co-maintain this package. I'm new to the packager process (not packaging) so did some reading:
I already have a FAS account (patrickl), did $ sudo yum install fedora-packager, did $ fedora-packager-setup, imported certs into Firefox, create new ssh key and submitted it to my FAS account, did the koji scratch build, subscribed to devel and devel-announce.

Adam: would you be willing to sponsor me?

Comment 11 Christopher Meng 2013-07-11 18:16:30 UTC
Have you emailed Steve? 

I think it's impolite to interrupt a review, and why not packaging a newthing?

Comment 12 Patrick Laimbock 2013-07-11 18:56:42 UTC
Christopher: No, I did not email Steve. Bugzilla sent him an email on 7/4. Shouldn't that suffice? I did not know that updating the spec file to be in sync with upstream's latest version is considered impolite and interrupting the review process. I was merely trying to be helpful.

Comment 13 Patrick Laimbock 2013-07-11 19:03:19 UTC
(In reply to Adam Williamson from comment #4)

About the license issue, LICENSE.Sendmail is included in the source of version 1.1.3 (currently the latest version).

Comment 14 Adam Williamson 2013-07-11 19:58:51 UTC
Christopher: well, Patrick and I both actually *want this piece of software*, the goal is not 'make Patrick a maintainer' but 'damn well get opendmarc in the distribution already'.

Note that the bug has been 'in Steve's court' since February with no apparent action from his side. The 'are you still working on this?' I posted last week was a ping.

Comment 15 Steve Jenkins 2013-07-11 23:24:50 UTC
Sorry guys - was on vacation. I have no problem co-maintaining or even handing off maintenance to someone who actively uses OpenDMARC. You guys are making great progress. Anybody interested? :)

Comment 16 Steve Jenkins 2013-07-11 23:37:09 UTC
Ah - scrolling back I see Patrick's volunteering to co-maintain. That sounds awesome. OpenDKIM is the only thing I currently maintain, and I've never co-maintained anything, and I think giving co-maintenance a shot sounds fun. :)

Patrick: I use GitHub to manage versions of spec files for my packages. That cool with you? If so, I just need to figure out how to give you write access to the OpenDMARC spec repo. Email me your github account name if you don't want to post it here.

https://github.com/stevejenkins/OpenDMARC-Fedora

Comment 17 Adam Williamson 2013-07-11 23:42:07 UTC
"Patrick: I use GitHub to manage versions of spec files for my packages. That cool with you? If so, I just need to figure out how to give you write access to the OpenDMARC spec repo. Email me your github account name if you don't want to post it here."

Why would you...when the Fedora package SCM is *already* git?

Comment 18 Steve Jenkins 2013-07-11 23:49:14 UTC
Good question - and the answer is because I'll often work on the spec file and break stuff, and keep it in the "develop" branch in a broken state until I get around to fixing it. I don't like uploading broken stuff to the Fedora SCM system.

Comment 19 Adam Williamson 2013-07-11 23:56:37 UTC
AFAIK it's totally fine to create and use arbitrarily named branches within the Fedora SCM. Not something a lot of people use for whatever reason, but I'm not aware of any reason you can't.

Comment 20 Steve Jenkins 2013-07-11 23:59:34 UTC
I didn't know that! I might start experimenting with that.

Although, I also use GitHub because I've had guys on the OpenDKIM dev team in the past (who don't have access to the Fedora SCM) do pull requests on my spec file repos and submit changes, which I can then accept or reject.

Comment 21 Adam Williamson 2013-07-12 00:01:22 UTC
Anon read-only access to the Fedora SCM is available.

Comment 22 Steve Jenkins 2013-07-12 00:07:46 UTC
Your argument gets more and more convincing by the minute! ;)

Comment 23 Patrick Laimbock 2013-07-19 14:27:50 UTC
Sorry for the delay. This time I was away for a few days. Good to see things start up again. To move forward, is it safe to conclude the following:

- Steve and I will co-maintain
- we will use Fedora SCM, optionally using github as secondary if that's the only place were OpenDMARC developers can put their code. But github will be merged back to Fedora SCM so that Fedora SCM is the one repo to rule them all

TODO:

- If I understand "Depends On" correctly, we should add BZ983551 since OpenDMARC with SELinux enabled will not work without a proper SELinux policy. I don't have rights to do that. Steve, if correct, can you please add it?

From Adam's review:

0) W: service-default-enabled /etc/rc.d/init.d/opendmarc

I'm not sure if OpenDMARC starts with either a socket or port and default config. Will test and provide feedback.

1) MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example: NEEDSWORK (see rpmlint item)

Will check/fix that this weekend and upload new spec file.

2) MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}: NEEDSWORK - the %{?_isa} is missing (though that's a new wrinkle on me, too - there's a note attached to the guideline, read that :>)

Will check/fix that this weekend and upload new spec file.

3) SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example: I'll work on that later
I have not seen OpenDMARC segfault. But I did configure it before starting. Will check that this weekend and provide feedback.

Anything I forgot?

Comment 24 Patrick Laimbock 2013-07-26 13:36:53 UTC
Created attachment 778766 [details]
OpenDMARC spec file version 1.1.3-3

Comment 25 Patrick Laimbock 2013-07-26 13:38:50 UTC
Created attachment 778767 [details]
OpenDMARC SRPM version 1.1.3-3

Comment 26 Patrick Laimbock 2013-07-26 13:44:13 UTC
Here are the updated spec file and SRPM (version 1.1.3-3).

About the list in comment #23:

0) I tested the package with the default config and it starts (and stops) fine

1) permissions are set for all files

2) %{?_isa} added to all Requires:

3) package does not segfault with default config


(Adam:) Is there anything else that should be done?

If possible can someone with proper rights please delete the old spec file (the top one called opendmarc-1.1.3.spec). I missed clicking the obsolete button when uploading the new one. Thanks!

Comment 27 Patrick Laimbock 2013-07-26 13:45:55 UTC
Changelog from the spec file for easier browsing:

* Mon Jul 22 2013 Patrick Laimbock <patrick> 1.1.3-3
- add %{?_isa} to Requires
- add sendmail-milter to Requires
- set permissions on all files
- add SELinux rules from bz983551 in post
- add policycoreutils{-python} to Requires for semanage in post
- set conf file perms to 640 and owned by opendmarc
- set /var/run/opendmarc perms to 750
- set /var/spool/opendmarc perms to 750
- in opendmarc.conf set Socket to local:/var/run/opendmarc/opendmarc.sock

Comment 28 Michael Schwendt 2013-07-26 14:59:09 UTC
Comment on attachment 772337 [details]
opendmarc-1.1.3.spec

You should be able to edit the details of your own attachments.

Comment 29 Adam Williamson 2013-07-26 22:49:43 UTC
well, arguably, an SPF milter should be packaged before we add this; it's generally considered bad form to add something to Fedora which requires something *outside* of Fedora to be of any use.

Comment 30 Patrick Laimbock 2013-07-29 13:19:16 UTC
Yes that makes sense. I did some digging and here's what I found:

python-pypolicyd-spf needs python-pyspf and python-pydns. Looking in koji and the EPEL repo neither is available for EL6. So those packages would first need to be build for EL6 and Fxx before it's possible to move forward with python-pypolicyd-spf. Anyone have an idea how that can be acomplished?

Comment 31 Michael Schwendt 2013-07-29 15:26:10 UTC
Odd. In pkgdb, there is a maintainer for both of them in EPEL6 and EPEL5:

  https://admin.fedoraproject.org/pkgdb/acls/name/python-pyspf
  https://admin.fedoraproject.org/pkgdb/acls/name/python-pydns

Even more strange, python-pydns has been built for EPEL5 but not EPEL6:

  http://koji.fedoraproject.org/koji/packageinfo?packageID=3631

So, contact the maintainers and ask. It could be that you would need to maintain the packager in EPEL.

Comment 32 Patrick Laimbock 2013-07-29 17:34:18 UTC
Thank you for your feedback Michael. Odd indeed. It seems that pwouters is the owner of both packages. I have sent him an email asking for an EL6 build or possibly co-maintainership of both packages.

Comment 33 Adam Williamson 2013-08-07 20:56:07 UTC
It looks like pydns is now built for EL6 and awaiting feedback:

https://admin.fedoraproject.org/updates/python-pydns-2.3.3-5.el6

Perhaps you could file a bug against python-pyspf requesting a build for EL6? And in the mean time, work on the spec for python-pypolicyd-spf ? Builds of both pyspf and pydns are available for Fedora, so it should be possible to work on the package while we wait for the deps to be available on EL6.

Comment 34 Adam Williamson 2013-08-07 21:06:36 UTC
There's actually a python-pypolicyd-spf review in already:

https://bugzilla.redhat.com/show_bug.cgi?id=921797

Comment 36 Adam Williamson 2013-08-07 23:09:41 UTC
python-ipaddr, which is required by python-pyspf, is not built for EL6. I have filed a bug requesting a build:

https://bugzilla.redhat.com/show_bug.cgi?id=994741

if one is not forthcoming in a week, I'll do it myself (as per EPEL policies). Someone poke me if I seem to have forgotten.

Comment 37 Patrick Laimbock 2013-08-08 14:21:51 UTC
(In reply to Adam Williamson from comment #35)
> I've built the latest python-pyspf and python-pydns for EL6, F18 and F19 and
> submitted updates:

Thanks Adam. I sent Paul an email but never heard back from him. Your updates seem to work fine for me so I left karma.

Comment 38 Adam Williamson 2013-08-17 06:25:44 UTC
I've pushed the updates from c#35 stable and requested the EL6 branch of python-ipaddr:

https://bugzilla.redhat.com/show_bug.cgi?id=589737#c13

looks like we're close to getting this done!

Comment 39 Adam Williamson 2013-10-01 21:11:11 UTC
OK, python-ipaddr is now in EL6 stable, pypolicyd-spf is in stable for EL6, F19 and F20 (still in u-t for F18, but eh), and the SELinux policy was put in Fedora back in July so I expect should be on all branches by now, if not, we can file bugs for it. AFAICS that's all the 'blockers' for this review. I think it's about time this went through; I'll try and deploy it onto my server some time soon and file any remaining bugs I come across. Thanks for sticking with it, Steve!

Comment 40 Patrick Laimbock 2013-10-01 22:08:04 UTC
Excellent, will do the same and report back if I come across any bugs. Thanks all!

Comment 41 Adam Williamson 2013-10-23 05:19:08 UTC
Looks like we need to get something into selinux-policy:

Oct 22 22:16:45 mail.happyassassin.net kernel: type=1400 audit(1382505405.071:12314): avc:  denied  { name_bind } for  pid=31163 comm="opendmarc" src=8893 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
Oct 22 22:16:45 mail.happyassassin.net opendmarc[31163]: OpenDMARC Filter: Unable to bind to port inet:8893@localhost: Permission denied
Oct 22 22:16:45 mail.happyassassin.net opendmarc[31163]: OpenDMARC Filter: Unable to create listening socket on conn inet:8893@localhost
Oct 22 22:16:45 mail.happyassassin.net opendmarc[31163]: smfi_opensocket() failed
Oct 22 22:16:45 mail.happyassassin.net opendmarc[31161]: Starting OpenDMARC Milter: opendmarc: smfi_opensocket() failed
Oct 22 22:16:45 mail.happyassassin.net opendmarc[31161]: [FAILED]

Comment 42 Adam Williamson 2013-10-23 05:23:01 UTC
[root@mail adamw]# dmesg | grep dkim | audit2allow


#============= dkim_milter_t ==============

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow dkim_milter_t unreserved_port_t:tcp_socket name_bind;

Comment 43 Adam Williamson 2013-10-23 06:21:30 UTC
Good news is that other than that, it seems to work fine.

Comment 44 Adam Williamson 2013-10-23 06:24:12 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1022349

Comment 45 Adam Williamson 2013-11-05 01:57:00 UTC
No. The review does not depend on that bug. I have already completed the review and marked it as approved.

Comment 46 Christopher Meng 2013-11-28 01:33:51 UTC
Well before solving that I think this package is in futile status.

Comment 47 Adam Williamson 2013-11-28 02:30:05 UTC
Hardly, it's easy enough to generate a local policy. I already have the package deployed on my production mail server.

Comment 48 Derek Atkins 2013-12-09 15:48:18 UTC
What is the status of this issue?

Comment 49 Matt Domsch 2014-01-25 07:15:16 UTC
(In reply to Patrick from comment #7)
> Adam: I was wondering the same thing and did some digging. An SPF checking
> policy needs to be setup in /etc/postfix/main.cf
> smtpd_recipient_restrictions section so that an SPF check result is added to
> the email headers which can then be evaluated by OpenDMARC. Afaict these are
> the two main SPF milters (the python one is actively developed):
> 
> postfix-policyd-spf-python https://launchpad.net/pypolicyd-spf/
> postfix-policyd-spf-perl https://launchpad.net/postfix-policyd-spf-perl/

For sendmail, there is also smf-spf, which is by all accounts unmaintained but it seems to work well enough.  It uses libspf2.  Paul Howarth (now copied) packaged these up.  I've updated libspf2 to the latest version from upstream github.  These 

http://domsch.com/fedora/libspf2/
has SRPMS, spec, and the selinux changes necessary.

All credit to Paul.  To review these properly, we will also need to get an selinux policy change in place for smf-spf to allow a domain socket.  It seems crazy to me that each new milter gets its own foo_milter_t defined, and then only to allow its own socket to exist and be used to talk to sendmail, but I leave that up to the SELinux gods.

Comment 50 Matt Domsch 2014-01-25 15:57:32 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1057874 (libspf2)
https://bugzilla.redhat.com/show_bug.cgi?id=1057876 (smf-spf)
reviews are now open.  These don't block opendkim, as opendkim can run without any SPF milters at all just fine for collecting reports, and reporting itself, or it can use postfix and the SPF milters there.  But for sendmail users, these seem to be the best candidates for an SPF milter.

Comment 51 Andrew J. Schorr 2014-09-03 15:18:56 UTC
For SPF milters, have you considered packing sid-milter (senderid-milter)?
I have not tried it yet myself, but others have reported success combining postfix + sid-milter + opendkim + opendmarc.  It would be nice to have them all packaged as rpms.

This thread sheds some light on this issue:
http://www.trusteddomain.org/pipermail/opendmarc-users/2014-March/000261.html

Regards,
Andy

Comment 52 Murray McAllister 2014-09-05 06:15:37 UTC
Hi,

There are two crashes (not sure if there is more impact than that) reported in the Debian bug tracking system:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755808

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760491

Those may be worth following to ensure they are fixed before the package is released in Fedora.

Comment 53 Andrew J. Schorr 2014-09-06 17:22:01 UTC
Hi,

FYI, the new version of opendmarc 1.3.0 seems to have the ability to perform SPF checks internally.  So there may be no need to package smf-spf.  From "man opendmarc.conf":

       SPFIgnoreResults (Boolean)
              Causes the filter to ignore any SPF results in the header of the
              message.  This is useful if you want the filter to  perfrom  SPF
              checks  itself,  or because you don't trust the arriving header.
              The default is "false".

       SPFSelfValidate (Boolean)
              Causes the filter to perform a fallback SPF check itself when it
              can  find no SPF results in the message header.  If SPFIgnoreRe‐
              sults is also set, it never looks for SPF results in headers and
              always  performs  the  SPF  check  itself when this is set.  The
              default is "false".

It seems to use libspf2.  I have not tried it myself, so I cannot say how well it works.

Regards,
Andy

Comment 54 Matt Domsch 2014-09-27 04:31:15 UTC
https://domsch.com/fedora/opendmarc/opendmarc-1.3.0-2/el6/

is built now using --with-spf, editing the config file to turn on SPFIgnoreResults and SPFSelfValidate.  I have removed smf-spf from my running config and am letting opendmarc do SPF validation, which for my limited testing appears to be working.

Please take for a spin.

Murray - the debian reports are closed - can't reproduce on 1.3.0.

Comment 55 Matt Domsch 2014-09-27 04:36:16 UTC
Koji scratch build for el6: http://koji.fedoraproject.org/koji/taskinfo?taskID=7707725

Comment 56 Murray McAllister 2014-09-29 22:46:43 UTC
(In reply to Matt Domsch from comment #54)
> https://domsch.com/fedora/opendmarc/opendmarc-1.3.0-2/el6/
> 
> is built now using --with-spf, editing the config file to turn on
> SPFIgnoreResults and SPFSelfValidate.  I have removed smf-spf from my
> running config and am letting opendmarc do SPF validation, which for my
> limited testing appears to be working.
> 
> Please take for a spin.
> 
> Murray - the debian reports are closed - can't reproduce on 1.3.0.

Thank you!

Comment 57 Adam Williamson 2014-12-10 20:39:09 UTC
I've got an F21 scratch build of Matt's package going at http://koji.fedoraproject.org/koji/taskinfo?taskID=8340301 . Why did we not go ahead with this yet anyway? Still the SELinux thing? I've drunk away all the memories.

Comment 58 Patrick Laimbock 2014-12-11 15:51:31 UTC
Adam: no idea. The 1.3.0 version with built-in SPF checks worked fine for me. But version 1.3.0 is pretty old as OpenDKIM is currently at version 2.9.2. So it first should be updated to that. For EL6 that's not an a problem but EL7, F20 and F21 require magical SystemD incantations and I have not looked into that yet. I will update the spec file for EL6 and upload it.

Comment 59 Adam Williamson 2014-12-11 17:13:48 UTC
Patrick: this is OpenDMARC, not OpenDKIM :) OpenDMARC is still at 1.3.0 upstream.

the systemd snippets are at https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd , shouldn't really be too much trouble.

Comment 60 Steve Jenkins 2014-12-11 18:09:21 UTC
OK - shaking off the cobwebs and jumping back in.

I'm working on trying to get one final OpenDKIM package update in before the F19 EOL, but then I'll turn attention to this.

Comment 61 Matt Domsch 2015-03-01 03:45:44 UTC
 http://koji.fedoraproject.org/koji/taskinfo?taskID=9104515
is an EL6 scratch build of v1.3.1 released this week.

Comment 62 Matt Domsch 2015-03-01 03:59:27 UTC
I installed this into a relatively fresh RHEL6 system, which has no extra selinux policies.  It starts just fine.  So I don't think we have an SELinux issue with opendmarc.

Comment 63 Adam Williamson 2015-03-01 08:27:11 UTC
Just to clear up any confusion I might've caused, some of my SELinux issues with dmarc/dkim were caused by having an old policy lying around. With:

opendmarc-1.3.0-2.x86_64
opendkim-2.9.2-3.fc21.x86_64

both come up and work for me on boot with SELinux enabled, no special tweaking needed.

Comment 64 Steve Jenkins 2015-03-05 17:13:37 UTC
Using the spec file that was last updated Feb 28, I can also get it to build on EL6:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9143828

but the same spec file chokes on EL5:

https://koji.fedoraproject.org/koji/taskinfo?taskID=9143827

The build log appears empty, so I can't figure out why it's choking on EL5. Anyone see anything obvious?

Comment 65 Adam Williamson 2015-03-05 17:28:56 UTC
root.log:

DEBUG util.py:388:  error: unpacking of archive failed on file /builddir/build/SOURCES/opendmarc-1.3.1.tar.gz;54f88cd2: cpio: MD5 sum mismatch

probably some issue in el5's ridiculously ancient toolchain.

Comment 66 Steve Jenkins 2015-03-05 17:59:56 UTC
Thanks, Adam. That put me on the right path. I remembered having to deal with that on something else a while back, and solved it by building the src.rpm with:

rpmbuild --nodeps -bs --define "_source_filedigest_algorithm md5" --define "_binary_filedigest_algorithm md5" opendmarc.spec

That got us a good build on EL5:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9144100

My next question is: can you please provide a link to the spec file you're using to build on F21? I'm trying to make a single spec file for both SysV and systemd versions, which simply allows commenting and uncommenting of different sections depending on the version (of course, after March 2017, we won't have to worry about SysV).

Comment 67 Steve Jenkins 2015-03-05 20:58:24 UTC
Ok - I think we made some progress today. I was able to consolidate a lot of the previous work done by Adam, Matt, and Patrick and generate two separate (but related) spec files that build on all currently supported Fedora-based systems:

- EL5 & EL6 (SysV)
- F23, F22, F21, F20 (systemd)

Spec files are here:

https://github.com/stevejenkins/OpenDMARC-Fedora/

https://github.com/stevejenkins/OpenDMARC-SysV

Please feel free to snoop through there and look for things to improve. I've only actually installed a build RPM on my F21 system, but it installs, starts up, and shuts down cleanly.

Here are the Koji results for all the builds based on those spec files:

F23: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145388

F22: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145392

F21: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145397

F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145404

EL7: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145410

EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145420

EL5: http://koji.fedoraproject.org/koji/taskinfo?taskID=9145424

So, what do you guys think? Is it finally time to get this baby into the testing repos? :)

One more FYI - I've sent my systemd opendmarc.service file to Murray (OpenDMARC developer) and he'll include it in the contrib folder of the next version, so we won't have to spit it out from the spec file.

Adam: I never got a chance to see your systemd service file, but if there's something in yours that should be in mine, lemme know and I'll get it in there.

Comment 68 Steve Jenkins 2015-03-06 01:20:40 UTC
I see Adam's has set the + flag (I don't know if that's recent, or if it's been that way for a while).

I'm going to proceed with the SCM Admin request... unless anyone has an objection.

Comment 69 Steve Jenkins 2015-03-06 01:27:45 UTC
New Package SCM Request
=======================
Package Name: opendmarc
Short Description: A Domain-based Message Authentication, Reporting & Conformance (DMARC) Milter and Library
Upstream URL: http://www.trusteddomain.org/opendmarc/
Owners: stevej patrickl
Branches: f20 f21 f22 f23 el5 el6 epel7
InitialCC: adamwill mdomsch

Comment 70 Adam Williamson 2015-03-06 01:34:41 UTC
Sorry I didn't get back to you on this lately - it's a busy day, we're trying to get 22 Alpha signed off. The package I'm using on my F21 system ATM is simply a rebuild of Matt's build from #c55 - I took the .src.rpm from his EL6 build and built it on F21, and used that.

Comment 71 Steve Jenkins 2015-03-06 01:47:02 UTC
Hi, Adam. No prob. I think I've got things under control, and I used the opendkim.service file as a template for opendmarc.service. I think we're actually good to go!

AFAIK, the SCM request will only look at the last comment on this bug, so I think I need to paste in that SCM request again. I'm hoping your "+" on the review flag means you're cool with that? I'll wait for confirmation from you until I paste it in again. :)

Comment 72 Adam Williamson 2015-03-06 01:55:39 UTC
yeah, I'm totally fine with that. Thanks for sticking with the package.

Comment 73 Steve Jenkins 2015-03-06 02:15:44 UTC
Sweet! Here I go. :)

Comment 74 Steve Jenkins 2015-03-06 02:16:04 UTC
New Package SCM Request
=======================
Package Name: opendmarc
Short Description: A Domain-based Message Authentication, Reporting & Conformance (DMARC) Milter and Library
Upstream URL: http://www.trusteddomain.org/opendmarc/
Owners: stevej patrickl
Branches: f20 f21 f22 f23 el5 el6 epel7
InitialCC: adamwill mdomsch

Comment 75 Gwyn Ciesla 2015-03-06 14:03:37 UTC
patrickl is not in the packager group.

Comment 76 Fedora Update System 2015-03-07 02:04:12 UTC
opendmarc-1.3.1-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.fc20

Comment 77 Fedora Update System 2015-03-07 02:04:19 UTC
opendmarc-1.3.1-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.fc21

Comment 78 Fedora Update System 2015-03-07 02:04:25 UTC
opendmarc-1.3.1-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.el7

Comment 79 Fedora Update System 2015-03-07 02:04:32 UTC
opendmarc-1.3.1-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.fc22

Comment 80 Fedora Update System 2015-03-07 02:04:38 UTC
opendmarc-1.3.1-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.el6

Comment 81 Fedora Update System 2015-03-07 02:04:44 UTC
opendmarc-1.3.1-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-2.el5

Comment 82 Fedora Update System 2015-03-07 06:43:04 UTC
opendmarc-1.3.1-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.fc21

Comment 83 Fedora Update System 2015-03-07 06:43:13 UTC
opendmarc-1.3.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.fc20

Comment 84 Fedora Update System 2015-03-07 06:43:20 UTC
opendmarc-1.3.1-3.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.el5

Comment 85 Fedora Update System 2015-03-07 06:43:26 UTC
opendmarc-1.3.1-3.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.el7

Comment 86 Fedora Update System 2015-03-07 06:43:33 UTC
opendmarc-1.3.1-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.fc22

Comment 87 Fedora Update System 2015-03-07 06:43:40 UTC
opendmarc-1.3.1-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-3.el6

Comment 88 Fedora Update System 2015-03-08 22:40:53 UTC
Package opendmarc-1.3.1-3.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing opendmarc-1.3.1-3.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1054/opendmarc-1.3.1-3.el6
then log in and leave karma (feedback).

Comment 89 Steve Jenkins 2015-03-12 23:27:52 UTC
EL 5 version when installed from testing repo yields:

opendmarc-1.3.1-3.el5.i386 from epel-testing has depsolving problems
  --> Missing Dependency: perl(IO::Compress::Zip) is needed by package opendmarc-1.3.1-3.el5.i386 (epel-testing)
Error: Missing Dependency: perl(IO::Compress::Zip) is needed by package opendmarc-1.3.1-3.el5.i386 (epel-testing)

Working to solve those now.

Comment 90 Steve Jenkins 2015-03-13 01:03:48 UTC
Dang... those appear unsolvable, since fixing it requires manual removal of a package on an EL5 system and then installing an RPMForge repo, since perl-IO-Compress is no longer part of EL5. So I'm dropping EL5 support for this package (tho anyone who wants to do the manual steps can easily use the SRPM to build their own EL5 RPM and jump through the necessary hoops).

But tool this opportunity to fix a minor typo and tweak the default settings and will re-push as 1.3.1-4 in a few minutes.

Comment 91 Fedora Update System 2015-03-13 01:09:04 UTC
opendmarc-1.3.1-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.fc22

Comment 92 Fedora Update System 2015-03-13 01:09:12 UTC
opendmarc-1.3.1-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.fc21

Comment 93 Fedora Update System 2015-03-13 01:09:21 UTC
opendmarc-1.3.1-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.fc20

Comment 94 Fedora Update System 2015-03-13 01:10:32 UTC
opendmarc-1.3.1-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.el6

Comment 95 Fedora Update System 2015-03-13 01:11:42 UTC
opendmarc-1.3.1-4.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.el7

Comment 96 Paul Howarth 2015-03-13 09:00:24 UTC
(In reply to Steve Jenkins from comment #90)
> Dang... those appear unsolvable, since fixing it requires manual removal of
> a package on an EL5 system and then installing an RPMForge repo, since
> perl-IO-Compress is no longer part of EL5.

Can you explain this in more detail?

I think it's do-able. EL-5 dates back to a time when IO-Compress was split into separate packages: IO-Compress-Base, IO-Compress-Bzip2, IO-Compress-Zlib. Version 2.005 of IO-Compress-Base and IO-Compress-Bzip2 are currently in EPEL-5 but for reasons that I don't know, IO-Compress-Zlib isn't. The package exists in dist-git though and there's already an EPEL-4 branch of it. It should be possible to get it branched and build version 2.005 (to match the others) for EPEL-5. I think it's worth giving it a try and see if it installs cleanly anyway.

http://search.cpan.org/~pmqs/IO-Compress-Zlib-2.005/

Comment 97 Paul Howarth 2015-03-13 09:07:40 UTC
Scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9220288

Comment 98 Steve Jenkins 2015-03-13 13:50:30 UTC
Hi, Paul. I agree -- if we can get someone to build IO-Compress-Zlib for EPEL5 then we're home free.

Looks like it's been a LONG time since anyone's messed with it, tho:

http://koji.fedoraproject.org/koji/packageinfo?packageID=4688

And I'm no familiar with the protocol of trying to get someone to build and push an existing package like that. Do I post a Bugzilla report and tag the previous packager (doesn't look like he's built anything in 5+ years)?

I'll also look upstream to see if that dependency is truly required. Perhaps working on both directions we can solve the issue.

Comment 99 Paul Howarth 2015-03-13 13:58:09 UTC
(In reply to Steve Jenkins from comment #98)
> Hi, Paul. I agree -- if we can get someone to build IO-Compress-Zlib for
> EPEL5 then we're home free.
> 
> Looks like it's been a LONG time since anyone's messed with it, tho:
> 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=4688

That's because (a) the package was swallowed up by perl-IO-Compress around Fedora 8/9 time, and (b) IO-Compress became a core perl module in perl 5.10 (Fedora 9).

> And I'm no familiar with the protocol of trying to get someone to build and
> push an existing package like that. Do I post a Bugzilla report and tag the
> previous packager (doesn't look like he's built anything in 5+ years)?
> 
> I'll also look upstream to see if that dependency is truly required. Perhaps
> working on both directions we can solve the issue.

Can you try the scratch build and see if it installs cleanly without conflicts (and resolves the dependency issue)? If it looks OK, I'll sort the branching and building out myself. I'm one of the current maintainers of the perl-IO-Compress package.

Comment 100 Fedora Update System 2015-03-13 15:43:51 UTC
Package opendmarc-1.3.1-4.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing opendmarc-1.3.1-4.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1235/opendmarc-1.3.1-4.el7
then log in and leave karma (feedback).

Comment 101 Steve Jenkins 2015-03-13 16:28:33 UTC
Paul:

# uname -r
2.6.18-398.el5

# rpm -ivh perl-IO-Compress-Zlib-2.005-1.el5.noarch.rpm
error: Failed dependencies:
        perl(Compress::Raw::Zlib) >= 2.005 is needed by perl-IO-Compress-Zlib-2.005-1.el5.noarch
        perl(IO::Compress::Base) >= 2.005 is needed by perl-IO-Compress-Zlib-2.005-1.el5.noarch
        perl(IO::Compress::Base::Common) >= 2.005 is needed by perl-IO-Compress-Zlib-2.005-1.el5.noarch
        perl(IO::Uncompress::Base) >= 2.005 is needed by perl-IO-Compress-Zlib-2.005-1.el5.noarch

# yum install perl-IO-Compress*
...
Resolving Dependencies
--> Running transaction check
---> Package perl-IO-Compress-Base.noarch 0:2.005-2.el5 set to be updated
---> Package perl-IO-Compress-Bzip2.noarch 0:2.005-3.el5 set to be updated
--> Processing Dependency: perl(Compress::Raw::Bzip2) >= 2.005 for package: perl-IO-Compress-Bzip2
--> Running transaction check
---> Package perl-Compress-Raw-Bzip2.i386 0:2.005-5.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved
...
Running Transaction
  Installing     : perl-Compress-Raw-Bzip2
  Installing     : perl-IO-Compress-Base
  Installing     : perl-IO-Compress-Bzip2

Installed:
  perl-IO-Compress-Base.noarch 0:2.005-2.el5
  perl-IO-Compress-Bzip2.noarch 0:2.005-3.el5

Dependency Installed:
  perl-Compress-Raw-Bzip2.i386 0:2.005-5.el5

Complete!

# yum install perl-Compress-Zlib
...
Resolving Dependencies
--> Running transaction check
---> Package perl-Compress-Zlib.i386 0:1.42-1.fc6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved
...
Running Transaction
  Installing     : perl-Compress-Zlib

Installed:
  perl-Compress-Zlib.i386 0:1.42-1.fc6

Complete!

# yum install perl-Compress-Raw-Zlib
...
Resolving Dependencies
--> Running transaction check
---> Package perl-Compress-Raw-Zlib.i386 0:2.020-1.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved
...
Installing:
 perl-Compress-Raw-Zlib
...
Running Transaction
  Installing     : perl-Compress-Raw-Zlib

Installed:
  perl-Compress-Raw-Zlib.i386 0:2.020-1.el5

Complete!

# rpm -ivh perl-IO-Compress-Zlib-2.005-1.el5.noarch.rpm
Preparing...                ########################################### [100%]
   1:perl-IO-Compress-Zlib  ########################################### [100%]

# wget https://kojipkgs.fedoraproject.org//packages/opendmarc/1.3.1/3.el5/i386/libopendmarc-1.3.1-3.el5.i386.rpm

# wget https://kojipkgs.fedoraproject.org//packages/opendmarc/1.3.1/3.el5/i386/opendmarc-1.3.1-3.el5.i386.rpm

(had to do wget because I had unpushed the EL5 pkg from testing... I've requested to have it pushed it back in now)

# rpm -ivh libopendmarc-1.3.1-3.el5.i386.rpm opendmarc-1.3.1-3.el5.i386.rpm
error: Failed dependencies:
        perl(HTTP::Request) is needed by opendmarc-1.3.1-3.el5.i386

# yum install perl-HTTP-Request
...
No package perl-HTTP-Request available.

# yum install perl-libwww-perl
...
Resolving Dependencies
--> Running transaction check
---> Package perl-libwww-perl.noarch 0:5.805-1.1.1 set to be updated
--> Processing Dependency: perl-HTML-Parser >= 3.33 for package: perl-libwww-perl
--> Processing Dependency: perl(HTML::Entities) for package: perl-libwww-perl
--> Running transaction check
---> Package perl-HTML-Parser.i386 0:3.55-1.fc6 set to be updated
--> Processing Dependency: perl-HTML-Tagset >= 3.03 for package: perl-HTML-Parser
--> Processing Dependency: perl(HTML::Tagset) for package: perl-HTML-Parser
--> Running transaction check
---> Package perl-HTML-Tagset.noarch 0:3.10-2.1.1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved
...
Installing:
 perl-libwww-perl

Installing for dependencies:
 perl-HTML-Parser
 perl-HTML-Tagse
...
Running Transaction
  Installing     : perl-HTML-Tagset
  Installing     : perl-HTML-Parser
  Installing     : perl-libwww-perl

Installed:
  perl-libwww-perl.noarch 0:5.805-1.1.1

Dependency Installed:
  perl-HTML-Parser.i386 0:3.55-1.fc6
  perl-HTML-Tagset.noarch 0:3.10-2.1.1

Complete!

# rpm -ivh libopendmarc-1.3.1-3.el5.i386.rpm opendmarc-1.3.1-3.el5.i386.rpm
Preparing...                ########################################### [100%]
   1:libopendmarc           ########################################### [ 50%]
   2:opendmarc              ########################################### [100%]

# service opendmarc start
Starting OpenDMARC Milter:                                 [  OK  ]

Thanks for not giving up, Paul!

So if you can get the perl-IO-Compress-Zlib package in for EL5, do I simply need to add that package, as well as the perl-libwww-perl, as additional "Requires" in the spec file for the EL5 spec file, and we should be good to go?

Now I'm wondering if the perl-libwww-perl package will also be required for EL6.

Comment 102 Paul Howarth 2015-03-13 17:26:48 UTC
EPEL-5 branch of perl-IO-Compress-Zlib requested in Bug 243019.

You don't need to add any additional requires, it already has the right ones. When dealing with perl module requirements, it's best to use the 'perl(module-name)' syntax. So, in your example above, instead of:

# yum install perl-HTTP-Request

you could just have done:

# yum install 'perl(HTTP::Request)'

and that would have pulled in the perl-libwww-perl package that provides it.

Comment 103 Steve Jenkins 2015-03-13 17:46:07 UTC
(In reply to Paul Howarth from comment #102)
> EPEL-5 branch of perl-IO-Compress-Zlib requested in Bug 243019.

Thanks, Paul. I've added myself to that bug's CC to track.
 
> You don't need to add any additional requires, it already has the right
> ones.

Excellent.

> When dealing with perl module requirements, it's best to use the
> 'perl(module-name)' syntax. So, in your example above, instead of:
> 
> # yum install perl-HTTP-Request
> 
> you could just have done:
> 
> # yum install 'perl(HTTP::Request)'
> 
> and that would have pulled in the perl-libwww-perl package that provides it.

Awesome! I love learning new stuff. Thanks! :)

Comment 104 Fedora Update System 2015-03-13 18:08:34 UTC
opendmarc-1.3.1-4.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-4.el5

Comment 105 Fedora Update System 2015-03-13 19:14:49 UTC
perl-IO-Compress-Zlib-2.005-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/perl-IO-Compress-Zlib-2.005-2.el5

Comment 106 Fedora Update System 2015-03-18 10:25:32 UTC
opendmarc-1.3.1-4.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 107 Fedora Update System 2015-03-26 21:44:27 UTC
opendmarc-1.3.1-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 108 Fedora Update System 2015-03-26 22:01:28 UTC
opendmarc-1.3.1-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 109 Andrew J. Schorr 2015-03-28 17:19:56 UTC
I have a few questions about the packaging:

1. Why does this rpm install both /etc/rc.d/init.d/opendmarc and /usr/lib/systemd/system/opendmarc.service?  Shouldn't /etc/rc.d/init.d/opendmarc be removed?

2. The opendmarc binary requires libmilter.  Why doesn't the spec file say "Requires: sendmail-milter"?  This was mentioned in Comment #27, but I don't see it in the spec file.

3. The opendmarc binary is linked against libbsd. So why is libbsd specified as "BuildRequires:" instead of "Requires:"?

Thanks,
Andy

Comment 110 Steve Jenkins 2015-03-28 19:20:23 UTC
(In reply to Andrew J. Schorr from comment #109)

Hi, Andy. Thanks for the great feedback.

> I have a few questions about the packaging:
> 
> 1. Why does this rpm install both /etc/rc.d/init.d/opendmarc and
> /usr/lib/systemd/system/opendmarc.service?  Shouldn't
> /etc/rc.d/init.d/opendmarc be removed?

I believe I fixed this a couple of versions ago while cleaning up (what I hope to be) all the systemd vs. SysV stuff when I consolidated into a shared spec file and used conditionals. Do lines 99 thru 122 here address this?:

https://github.com/stevejenkins/OpenDMARC-Fedora/blob/15c0d9a948baee1ef1b5c20c212a3bf6187b42d1/SPECS/opendmarc.spec

> 2. The opendmarc binary requires libmilter.  Why doesn't the spec file say
> "Requires: sendmail-milter"?  This was mentioned in Comment #27, but I don't
> see it in the spec file.

Good catch added. See line 14 in the above link.

> 
> 3. The opendmarc binary is linked against libbsd. So why is libbsd specified
> as "BuildRequires:" instead of "Requires:"?

Another great question. :) See also line 14 in the above link.

Feel free to peek through that version of the spec file and see if anything else looks out of place. I'll hold off a bit before I push those changes and rebuild.

Thanks!

Steve

Comment 111 Andrew J. Schorr 2015-03-28 19:50:58 UTC
Thanks Steve.  I think you fixed all the problems I mentioned.  -Andy

Comment 112 Steve Jenkins 2015-03-28 20:07:36 UTC
Awesome. Thanks, Andy. I'll start building and pushing now. :)

Comment 113 Fedora Update System 2015-03-28 20:53:41 UTC
opendmarc-1.3.1-7.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.fc21

Comment 114 Fedora Update System 2015-03-28 20:53:49 UTC
opendmarc-1.3.1-7.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.el7

Comment 115 Fedora Update System 2015-03-28 20:53:56 UTC
opendmarc-1.3.1-7.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.el5

Comment 116 Fedora Update System 2015-03-28 20:54:04 UTC
opendmarc-1.3.1-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.fc20

Comment 117 Fedora Update System 2015-03-28 20:54:12 UTC
opendmarc-1.3.1-7.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.fc22

Comment 118 Fedora Update System 2015-03-28 20:55:23 UTC
opendmarc-1.3.1-7.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-7.el6

Comment 119 Paul Howarth 2015-03-29 11:02:12 UTC
The dependencies on sendmail-milter and libbsd should not have been added as rpm detects them automatically. Check the requires for the built opendmarc package and you will see the following in addition to your manual libbsd and sendmail-milter dependencies:

libbsd.so.0()(64bit)
libbsd.so.0(LIBBSD_0.0)(64bit)
...
libmilter.so.1.0()(64bit)

The guidelines expressly prohibit manual library dependencies except under special circumstances, which would in any case require a versioned dependency:
http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

%defattr was last needed for EL-4 - you can get rid of it.

You should also use %license rather than %doc for the license files. I suggest:
%if 0%{?_licensedir:1}
%license LICENSE LICENSE.Sendmail
%else
%doc LICENSE LICENSE.Sendmail
%endif
%doc README RELEASE_NOTES docs/draft-dmarc-base-13.txt

instead of:
%doc LICENSE LICENSE.Sendmail README RELEASE_NOTES docs/draft-dmarc-base-13.txt

Your macro usage for %{name} is inconsistent. For example, you create user/group "%{name}" but explicitly use user/group "opendmarc" in the systemd service file. My personal preference is only to use %{name} where it's truly boilerplate such as in the buildroot tag, explicit dependencies for sub-packages etc., and use the explicit package name elsewhere. Whatever you choose, make sure your use is consistent. A good rule of thumb would be that if you renamed the package, it would still build and run correctly.

Comment 120 Steve Jenkins 2015-03-30 00:39:46 UTC
Hey, Paul. Thanks for the great feedback. I'll make those changes. 

On the macro usage, however, I wasn't sure how "far" to take it. :) I changed the service file to include the variable (use more) instead of using fewer. Anywhere else I should plug them in?

Comment 121 Fedora Update System 2015-03-30 01:47:18 UTC
opendmarc-1.3.1-8.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.fc21

Comment 122 Fedora Update System 2015-03-30 01:47:25 UTC
opendmarc-1.3.1-8.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.el5

Comment 123 Fedora Update System 2015-03-30 01:47:34 UTC
opendmarc-1.3.1-8.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.fc22

Comment 124 Fedora Update System 2015-03-30 01:48:44 UTC
opendmarc-1.3.1-8.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.el7

Comment 125 Fedora Update System 2015-03-30 01:48:52 UTC
opendmarc-1.3.1-8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.fc20

Comment 126 Fedora Update System 2015-03-30 01:48:59 UTC
opendmarc-1.3.1-8.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-8.el6

Comment 127 Paul Howarth 2015-03-30 15:03:44 UTC
(In reply to Steve Jenkins from comment #120)
> Hey, Paul. Thanks for the great feedback. I'll make those changes. 
> 
> On the macro usage, however, I wasn't sure how "far" to take it. :) I
> changed the service file to include the variable (use more) instead of using
> fewer. Anywhere else I should plug them in?

Well if you can grep -i the spec for "opendmarc" and it finds only the "Name:" line, you're probably done :-)

Comment 128 Steve Jenkins 2015-03-30 15:20:24 UTC
(In reply to Paul Howarth from comment #127)
> Well if you can grep -i the spec for "opendmarc" and it finds only the
> "Name:" line, you're probably done :-)

LOL - alright! Noted!

Would that include the sub-package names? Is it kosher for me to name them lib%{name} ?

Comment 129 Paul Howarth 2015-03-30 15:33:25 UTC
(In reply to Steve Jenkins from comment #128)
> (In reply to Paul Howarth from comment #127)
> > Well if you can grep -i the spec for "opendmarc" and it finds only the
> > "Name:" line, you're probably done :-)
> 
> LOL - alright! Noted!
> 
> Would that include the sub-package names? Is it kosher for me to name them
> lib%{name} ?

I wouldn't. Particularly if the software ships a library called "libopendmarc". But it's up to you. Just bear in mind that the purpose of using %{name} is largely to facilitate renaming the package at some point in the future if necessary. So think about what's related to the rpm package name and what might be unchanged if there was a need to rename the package for some reason.

Comment 130 Fedora Update System 2015-04-01 01:54:58 UTC
opendmarc-1.3.1-4.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 131 Fedora Update System 2015-04-01 01:58:04 UTC
opendmarc-1.3.1-4.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 132 Fedora Update System 2015-04-01 02:02:13 UTC
perl-IO-Compress-Zlib-2.005-2.el5 has been pushed to the Fedora EPEL 5 stable repository.

Comment 133 Steve Jenkins 2015-04-02 14:55:07 UTC
(In reply to Patrick Laimbock from comment #27)
> Changelog from the spec file for easier browsing:
> - add policycoreutils{-python} to Requires for semanage in post

policycoreutils-python isn't available in EL5 (though policycoreutils is). Not knowing a lot about it, is this package truly required for opendmarc to function properly?

Both policycoreutils and policycoreutils-python seem to be available in all current Fedora builds, as well as EL6 and EL7, so is it worth conditionally including for those builds only?

Comment 134 Fedora Update System 2015-04-02 18:34:14 UTC
opendmarc-1.3.1-9.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.fc21

Comment 135 Fedora Update System 2015-04-02 18:35:26 UTC
opendmarc-1.3.1-9.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.el6

Comment 136 Fedora Update System 2015-04-02 18:35:33 UTC
opendmarc-1.3.1-9.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.el5

Comment 137 Fedora Update System 2015-04-02 18:36:44 UTC
opendmarc-1.3.1-9.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.el7

Comment 138 Fedora Update System 2015-04-02 18:37:55 UTC
opendmarc-1.3.1-9.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.fc22

Comment 139 Fedora Update System 2015-04-02 18:38:04 UTC
opendmarc-1.3.1-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-9.fc20

Comment 140 Patrick Laimbock 2015-04-03 11:53:45 UTC
(In reply to Steve Jenkins from comment #133)
> (In reply to Patrick Laimbock from comment #27)
> > Changelog from the spec file for easier browsing:
> > - add policycoreutils{-python} to Requires for semanage in post
> 
> policycoreutils-python isn't available in EL5 (though policycoreutils is).
> Not knowing a lot about it, is this package truly required for opendmarc to
> function properly?

The policycoreutils (on EL5) and policycoreutils-python (on EL6/EL7) packages contain "semanage" which was needed to set the proper SELinux labels in %post.
A while back I filed a BZ regarding SELinux and OpenDMARC on EL6 and it was resolved:
https://bugzilla.redhat.com/show_bug.cgi?id=983551
https://rhn.redhat.com/errata/RHBA-2013-1598.html

I did some digging and AFAICT EL5 does not have OpenDMARC support in the milter.pp policy while EL6 and EL7 do.

> Both policycoreutils and policycoreutils-python seem to be available in all
> current Fedora builds, as well as EL6 and EL7, so is it worth conditionally
> including for those builds only?

It seems the semanage code in %post is still required for EL5 so how about leaving the "Requires: policycoreutils" and associated code in %post in within an if-its-EL5 condition and remove the policycoreutils-python requirement?

Comment 141 Steve Jenkins 2015-04-03 14:23:20 UTC
Good call, Patrick. Thanks. That's exactly what I'll do.

Comment 142 Steve Jenkins 2015-04-03 21:31:49 UTC
Patrick:

Would changing:

%if (0%{?fedora} && 0%{?fedora} >= 18) || (0%{?rhel} && 0%{?rhel} >= 6)
Requires (post): policycoreutils, policycoreutils-python
%endif

to:

%if 0%{?rhel} && 0%{?rhel} == 5
Requires (post): policycoreutils
%endif

do the trick?

Comment 143 Fedora Update System 2015-04-03 23:15:46 UTC
opendmarc-1.3.1-10.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.fc21

Comment 144 Fedora Update System 2015-04-03 23:15:55 UTC
opendmarc-1.3.1-10.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.el6

Comment 145 Fedora Update System 2015-04-03 23:16:03 UTC
opendmarc-1.3.1-10.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.el7

Comment 146 Fedora Update System 2015-04-03 23:16:12 UTC
opendmarc-1.3.1-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.fc20

Comment 147 Fedora Update System 2015-04-03 23:16:20 UTC
opendmarc-1.3.1-10.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.fc22

Comment 148 Fedora Update System 2015-04-03 23:16:29 UTC
opendmarc-1.3.1-10.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-10.el5

Comment 149 Patrick Laimbock 2015-04-04 08:46:52 UTC
(In reply to Steve Jenkins from comment #142)
> Patrick:
> 
> Would changing:
> 
> %if (0%{?fedora} && 0%{?fedora} >= 18) || (0%{?rhel} && 0%{?rhel} >= 6)
> Requires (post): policycoreutils, policycoreutils-python
> %endif
> 
> to:
> 
> %if 0%{?rhel} && 0%{?rhel} == 5
> Requires (post): policycoreutils
> %endif
> 
> do the trick?

That should do it although I don't think I have seen "Requires (post):" before so if that doesn't work try it without the space: "Requires(post):"

Comment 150 Fedora Update System 2015-04-09 16:12:00 UTC
opendmarc-1.3.1-11.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.fc21

Comment 151 Fedora Update System 2015-04-09 16:12:14 UTC
opendmarc-1.3.1-11.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.el7

Comment 152 Fedora Update System 2015-04-09 16:12:26 UTC
opendmarc-1.3.1-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.fc20

Comment 153 Fedora Update System 2015-04-09 16:12:39 UTC
opendmarc-1.3.1-11.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.fc22

Comment 154 Fedora Update System 2015-04-09 16:12:51 UTC
opendmarc-1.3.1-11.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.el5

Comment 155 Fedora Update System 2015-04-09 16:13:03 UTC
opendmarc-1.3.1-11.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-11.el6

Comment 156 Fedora Update System 2015-04-14 03:40:28 UTC
opendmarc-1.3.1-12.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.el6

Comment 157 Fedora Update System 2015-04-14 03:40:38 UTC
opendmarc-1.3.1-12.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.fc21

Comment 158 Fedora Update System 2015-04-14 03:40:45 UTC
opendmarc-1.3.1-12.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.fc20

Comment 159 Fedora Update System 2015-04-14 03:41:56 UTC
opendmarc-1.3.1-12.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.el7

Comment 160 Fedora Update System 2015-04-14 03:42:04 UTC
opendmarc-1.3.1-12.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.el5

Comment 161 Fedora Update System 2015-04-14 03:42:12 UTC
opendmarc-1.3.1-12.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-12.fc22

Comment 162 Fedora Update System 2015-04-22 22:53:13 UTC
opendmarc-1.3.1-12.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 163 Fedora Update System 2015-04-29 13:05:09 UTC
opendmarc-1.3.1-12.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 164 Fedora Update System 2015-04-29 13:07:57 UTC
opendmarc-1.3.1-12.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 165 Fedora Update System 2015-04-30 01:06:05 UTC
opendmarc-1.3.1-13.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-13.el6

Comment 166 Fedora Update System 2015-04-30 01:06:13 UTC
opendmarc-1.3.1-13.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-13.el5

Comment 167 Fedora Update System 2015-04-30 01:07:25 UTC
opendmarc-1.3.1-13.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-13.el7

Comment 168 Fedora Update System 2015-04-30 01:07:34 UTC
opendmarc-1.3.1-13.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-13.fc20

Comment 169 Fedora Update System 2015-04-30 01:07:43 UTC
opendmarc-1.3.1-13.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendmarc-1.3.1-13.fc21

Comment 170 DO NOT USE account not monitored (old adamwill) 2015-04-30 01:28:51 UTC
You really don't have to mark every update to the package ever as fixing the review request, it's spamming the hell out of my mailbox.

Comment 171 Fedora Update System 2015-05-10 23:39:38 UTC
opendmarc-1.3.1-13.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 172 Fedora Update System 2015-05-10 23:50:04 UTC
opendmarc-1.3.1-13.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 173 Fedora Update System 2015-05-20 04:49:43 UTC
opendmarc-1.3.1-13.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 174 Fedora Update System 2015-05-20 04:50:54 UTC
opendmarc-1.3.1-13.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 175 Fedora Update System 2015-05-20 04:55:32 UTC
opendmarc-1.3.1-13.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.