Hide Forgot
bit of a quandary as to best option here :-/ @ Latest upstream release: 1.3.2 https://sourceforge.net/projects/opendmarc/files/ released, 804 commit 0d65077648569076c103b73f30ca86c14e1811a5 (tag: rel-opendmarc-1-3-2, origin/master, origin/HEAD, master) 805 Author: Murray S. Kucherawy <msk> 806 Date: Sat Mar 4 05:28:22 2017 -0800 807 808 1.3.2 announcement since then, there have been 123 commits -- some of them critical -- to upstream source. last being, git log -n1 1 commit 363e4a82231b4366bdb92e72e612331ecda70c01 (HEAD -> develop, tag: rel-opendmarc-1-4-0-Beta1, origin/develop) 2 Merge: 23ef549 442b6b1 3 Author: Murray S. Kucherawy <msk> 4 Date: Thu Nov 15 07:58:31 2018 +0700 5 6 Merge pull request #27 from jikamens/develop 7 8 Fix trusteddomainproject/OpenDMARC#21 1.3.2's a mess / unusable in many circumstances, tho, WORKSFORSOME Current version/release in: Fedora 33 NONE AVAILABLE Fedora 32 opendmarc-1.3.2-1.fc32 Can this be possibly bumped to latest commit tag -- old as it is -- to collect/benefit from the fixes since 'last release'? fwiw, here, DIY builds with latest commit run in production (not yet on Fedora ... working on it), with no noticeable issues. if not doable for this specific pkg release, perhaps an "opendkim-latest" pkg, or somesuch? And, yes, I'm very aware upstream is famously & consistently non-responsive.
any response?
Hi, sorry for the late response. Do i understand it correctly that you are running opendmarcs snapshot of the latest commit? If so, for how long? If it is truly stable then i see no problem in updating the package to the snapshot of latest commit. I see that in [0] there is version 1.4.0-beta1, would rebase to that version be sufficient? [0] - https://github.com/trusteddomainproject/OpenDMARC/releases
> Do i understand it correctly that you are running opendmarcs snapshot of the latest commit? yep. > If so, for how long? I've been building from src, @ 'develop' branch, for years. until recently, that's been on openSUSE & ubuntu. It's been in production working with postfix instances with -- in my use case -- no problems. ~ 2 months ago, I began migrating my production OS to Fedora32. lacking up-to-date pkgs, and _hoping_ to no longer DIY from source, I've been running my own pkgs, built on COPR. fyi, https://download.copr.fedorainfracloud.org/results/pgfed/opendmarc/fedora-32-x86_64/01607172-opendmarc/opendmarc.spec ( & no, it's _not_ pkg'd 'properly' for official inclusion as a F32 pkg ) > I see that in [0] there is version 1.4.0-beta1, would rebase to that version be sufficient? not IMO ... 1.4.0-Beta1 was 'released' on Nov 14, 2018 -- heading for 2 years ago. There are 11 commits since, https://github.com/trusteddomainproject/OpenDMARC/compare/rel-opendmarc-1-4-0-Beta1...develop several of which are quite useful. Given the almost complete non-responsiveness of the upstream dev @ "Trusted Domain Project", I don't trust the 'release' the slightest bit more than the branch tip. IME -- & backed up with comments from others -- building the latest commit has been reliable. The *right* solution is to find & switch-to a well-maintained project; not a lot of options available afaict. Yes, there's effort on developing OpenARC as 'next gen' solution ... but, frankly, it's from the same folks; _not_ holding my breath ... Bottom line? *I* build & use the latest commit. It works, *here*. I think others might be interested as well. But, I cannot guarantee it's a 'safe bet'. Hence, the quandary ...
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hi, unfortunately i do not have time to maintain Opendmarc. The package is now orphaned. If you are a maintainer then please consider taking it. Apologies.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
I have a 1.4.0 version I am testing out: rawhide/f35: http://koji.fedoraproject.org/koji/taskinfo?taskID=66668437 f34: http://koji.fedoraproject.org/koji/taskinfo?taskID=66668626 f33: http://koji.fedoraproject.org/koji/taskinfo?taskID=66668868 f32: http://koji.fedoraproject.org/koji/taskinfo?taskID=66668906 epel8: http://koji.fedoraproject.org/koji/taskinfo?taskID=66668617 epel7: http://koji.fedoraproject.org/koji/taskinfo?taskID=66669466 I'll probibly push this to rawhide later today and see about pushing other releases based on feedback.
Thank you Kevin. Are your changes in an upstream repo? I took a look at https://src.fedoraproject.org/rpms/opendmarc/commits/rawhide and didn't see anything there. I'm wondering if the build contains the fix for #1915468 as well.
I haven't pushed to rawhide yet, will try and do so later tonight. ;) yes, it will have a fix for 1915468.
> I'll probibly push this to rawhide later today and see about pushing other > releases based on feedback. fyi, v1.4.0-1.fc33 (re)built for f33, @ https://copr.fedorainfracloud.org/coprs/pgfed/opendmarc/build/2148208/ installs OK. _initial_ in-/out-bound tests appear OK as well.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FEDORA-2021-c1b846164e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c1b846164e
FEDORA-2021-c1b846164e has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c1b846164e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c1b846164e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-c1b846164e has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.