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
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.
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 ;)
Great - thanks, Adam! I've been waiting around for a review to help kick this off, so I appreciate it! :)
* 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) :)
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.
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? :)
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.
Steve, are you still working on this?
Created attachment 772337 [details] opendmarc-1.1.3.spec This is the opendmarc spec file updated to version 1.1.3
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?
Have you emailed Steve? I think it's impolite to interrupt a review, and why not packaging a newthing?
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.
(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).
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.
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? :)
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
"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?
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.
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.
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.
Anon read-only access to the Fedora SCM is available.
Your argument gets more and more convincing by the minute! ;)
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?
Created attachment 778766 [details] OpenDMARC spec file version 1.1.3-3
Created attachment 778767 [details] OpenDMARC SRPM version 1.1.3-3
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!
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 on attachment 772337 [details] opendmarc-1.1.3.spec You should be able to edit the details of your own attachments.
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.
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?
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.
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.
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.
There's actually a python-pypolicyd-spf review in already: https://bugzilla.redhat.com/show_bug.cgi?id=921797
I've built the latest python-pyspf and python-pydns for EL6, F18 and F19 and submitted updates: https://admin.fedoraproject.org/updates/python-pyspf-2.0.8-1.el6 https://admin.fedoraproject.org/updates/python-pydns-2.3.6-1.el6 https://admin.fedoraproject.org/updates/python-pyspf-2.0.8-1.fc18 https://admin.fedoraproject.org/updates/python-pydns-2.3.6-1.fc18 https://admin.fedoraproject.org/updates/python-pyspf-2.0.8-1.fc19 https://admin.fedoraproject.org/updates/python-pydns-2.3.6-1.fc19
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.
(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.
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!
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!
Excellent, will do the same and report back if I come across any bugs. Thanks all!
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]
[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;
Good news is that other than that, it seems to work fine.
https://bugzilla.redhat.com/show_bug.cgi?id=1022349
No. The review does not depend on that bug. I have already completed the review and marked it as approved.
Well before solving that I think this package is in futile status.
Hardly, it's easy enough to generate a local policy. I already have the package deployed on my production mail server.
What is the status of this issue?
(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.
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.
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
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.
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
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.
Koji scratch build for el6: http://koji.fedoraproject.org/koji/taskinfo?taskID=7707725
(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!
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.
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.
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.
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.
http://koji.fedoraproject.org/koji/taskinfo?taskID=9104515 is an EL6 scratch build of v1.3.1 released this week.
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.
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.
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?
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.
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).
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.
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.
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
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.
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. :)
yeah, I'm totally fine with that. Thanks for sticking with the package.
Sweet! Here I go. :)
patrickl is not in the packager group.
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
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
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
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
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
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
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
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
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
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
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
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
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).
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.
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.
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
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
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
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
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
(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/
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9220288
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.
(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.
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).
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.
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.
(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! :)
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
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
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.
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.
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.
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
(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
Thanks Steve. I think you fixed all the problems I mentioned. -Andy
Awesome. Thanks, Andy. I'll start building and pushing now. :)
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
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
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
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
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
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
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.
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?
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
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
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
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
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
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
(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 :-)
(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} ?
(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.
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.
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.
perl-IO-Compress-Zlib-2.005-2.el5 has been pushed to the Fedora EPEL 5 stable repository.
(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?
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
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
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
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
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
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
(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?
Good call, Patrick. Thanks. That's exactly what I'll do.
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?
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
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
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
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
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
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
(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):"
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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
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
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
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
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
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.
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.
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.
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.
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.
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.