Description of problem: by "accident", python3-dns-1.15.0-10.el8.noarch was installed and suddenly pypolicyd-spf-2.0.2-7.el8.noarch stopped working Version-Release number of selected component (if applicable): pypolicyd-spf-2.0.2-7.el8.noarch How reproducible: after installation of python3-dns-1.15.0-10.el8.noarch Steps to Reproduce: 1. install pypolicyd-spf-2.0.2-7.el8.noarch 2. configure postfix to use policyd-spf 3. install python3-dns-1.15.0-10.el8.noarch Actual results: Oct 24 17:01:19 server postfix/smtpd[1992481]: warning: premature end-of-input on private/policyd-spf while reading input attribute name Oct 24 17:01:19 server postfix/smtpd[1992481]: warning: problem talking to server private/policyd-spf: Success Oct 24 17:01:19 server policyd-spf[1998244]: Traceback (most recent call last): Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/libexec/postfix/policyd-spf", line 809, in <module> Oct 24 17:01:19 server policyd-spf[1998244]: instance_dict, configData, peruser, peruserconfigData) Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/libexec/postfix/policyd-spf", line 525, in _spfcheck Oct 24 17:01:19 server policyd-spf[1998244]: res = heloquery.check() Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 594, in check Oct 24 17:01:19 server policyd-spf[1998244]: spf = self.dns_spf(self.d) Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 1165, in dns_spf Oct 24 17:01:19 server policyd-spf[1998244]: a = [t for t in self.dns_txt(domain) if RE_SPF.match(t)] Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 1215, in dns_txt Oct 24 17:01:19 server policyd-spf[1998244]: dns_list = self.dns(domainname, rr,ignore_void=ignore_void) Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 1359, in dns Oct 24 17:01:19 server policyd-spf[1998244]: for k, v in DNSLookup(name, qtype, self.strict, timeout): Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 130, in DNSLookup_dnspython Oct 24 17:01:19 server policyd-spf[1998244]: answers = dns.resolver.query(name, qtype, lifetime=timeout) Oct 24 17:01:19 server policyd-spf[1998244]: TypeError: query() got an unexpected keyword argument 'lifetime' Expected results: working as before Additional info: it would be very good to add an RPM conflict into SPEC file like Conflicts: python3-dns to avoid such issues without getting better attention
FEDORA-2020-80d4c18034 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-80d4c18034
FEDORA-2020-deaa23fd0d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-deaa23fd0d
FEDORA-EPEL-2020-59c598230b has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-59c598230b
FEDORA-EPEL-2020-a02617e709 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a02617e709
FEDORA-2020-deaa23fd0d has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-deaa23fd0d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-deaa23fd0d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-80d4c18034 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-80d4c18034` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-80d4c18034 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-f0b55eb9de has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f0b55eb9de` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f0b55eb9de See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-a02617e709 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a02617e709 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-59c598230b has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-59c598230b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-80d4c18034 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-deaa23fd0d has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-f0b55eb9de has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-a02617e709 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-59c598230b has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
This is not a solution. Unable to install both pyspf and python3-dns. I need them both for 2 different applications. python3-pyspf doesn't provide dns module, see: [ondrejj@work ~]$ python3 Python 3.9.0 (default, Oct 6 2020, 00:00:00) [GCC 10.2.1 20200826 (Red Hat 10.2.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import dns Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'dns' >>> When I install python3-dns, pyspf is immediatelly downgraded. Later all updates fails due to problem of conflicts. Which file is conflicting? I don't see any conflicts in latest pyspf.
I have not so deep insights into python's dependency hell, but fact is: pypolicyd-spf-2.0.2-7.el8.noarch will stop working once python3-dns-1.15.0-10.el8.noarch is installed, see traceback above, which shows that one has introduced a new *mandatory* parameter "lifetime" instead of keeping that optional with a default...this is imho a major backwards compatibility break...but learnt from the past that backwards compatibility is in python's world not seen as a real goal...
I see something else: Oct 24 17:01:19 server policyd-spf[1998244]: File "/usr/lib/python3.6/site-packages/spf.py", line 130, in DNSLookup_dnspython Oct 24 17:01:19 server policyd-spf[1998244]: answers = dns.resolver.query(name, qtype, lifetime=timeout) Your version of pyspf uses an parameter of lifetime, which is present in python-dns-2.0, but isn't present in python-dns-1.15 available in centos 8. Not sure, how it's possible to update incompatible python-dns in EPEL. But why you conflicted python3-dns as is also in Fedora? You can conflict python3-dns in CentOS 8, but better only conflict with versions of python3-dns<2.0 (old version). But this is still not a good solution. According to pyspf sources, dnspython (python3-dns) is preferred and should be used, because it's a more complete library. Disabling dnspython can make pyspf less useable in some cases. It would be better to patch pyspf to be backward compatible with old version of dnspython. This is a harder way, but with better results later. You can send your patch upstream or ask upstream to do this.
I have not requested from maintainer to add the conflict to all versions - potentially your suggestion to reduce the conflict to EL8 and also only to an older version is a good solution -> task for the package maintainer - thank you for reporting.
But still, dnspython is a preferred solution for pyspf. Disabling it in EPEL-8 is a step back. EPEL-8 is modular, it's possible to have 2 different version of some packages, but not sure if it's possible for python3-dns too. But it's still possible to create a python3-dns2 package.
I think I'll probably revert all this. That conflicts can then be put into pypolicyd-spf package, for whatever branch should have it.
Hmm, the conflict is caused by /usr/lib/python3.6/site-packages/spf.py:130 # FIXME: how to disable TCP fallback in dnspython if not tcpfallback? answers = dns.resolver.query(name, qtype, lifetime=timeout) <-!!! File is contained in this particular package: rpm -qf /usr/lib/python3.6/site-packages/spf.py python3-pyspf-2.0.14-3.el8.noarch Putting a "Conflicts" into "pypolicyd-spf" won't help in case someone uses "python3-pyspf-2.0.14-3.el8.noarch" without "pypolicyd-spf" for a valid reason. The problematic code is here in /usr/lib/python3.6/site-packages/spf.py: try: # prefer dnspython (the more complete library) import dns import dns.resolver # http://www.dnspython.org import dns.exception if not hasattr(dns.rdatatype,'SPF'): # patch in type99 support dns.rdatatype.SPF = 99 dns.rdatatype._by_text['SPF'] = dns.rdatatype.SPF DNSLookup = DNSLookup_dnspython except: import DNS # https://launchpad.net/pydns if not hasattr(DNS.Type, 'SPF'): # patch in type99 support DNS.Type.SPF = 99 DNS.Type.typemap[99] = 'SPF' DNS.Lib.RRunpacker.getSPFdata = DNS.Lib.RRunpacker.getTXTdata # Fails on Mac OS X? Add domain to /etc/resolv.conf DNS.DiscoverNameServers() DNSLookup = DNSLookup_pydns in conjunction with def DNSLookup_dnspython(name, qtype, tcpfallback=True, timeout=30): retVal = [] try: # FIXME: how to disable TCP fallback in dnspython if not tcpfallback? answers = dns.resolver.query(name, qtype, lifetime=timeout) -> python3-pyspf has to detect that it can happpen that older "dns.resolver" functions are available on the "python market" which are not supporting "timeout" and do not use this additional parameter where not supported. Unfortunatly my python knowledge are not that good to support here further, I would expect something like (syntax potentially not supported/correct): if version("import dns.resolver") < 2.0 answers = dns.resolver.query(name, qtype) else answers = dns.resolver.query(name, qtype, lifetime=timeout) otherwise an additional try-catch block potentially would help, e.g. like (syntax potentially not correct): try: answers = dns.resolver.query(name, qtype, lifetime=timeout) except "TypeError" answers = dns.resolver.query(name, qtype)
FEDORA-2020-486a3cef65 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-486a3cef65
FEDORA-2020-36e9ab745d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-36e9ab745d
FEDORA-EPEL-2020-6aa5208bed has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6aa5208bed
FEDORA-EPEL-2020-206fa89bfd has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-206fa89bfd
FEDORA-2020-ad0e89cc29 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad0e89cc29
FEDORA-EPEL-2020-6aa5208bed has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6aa5208bed See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-ad0e89cc29 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ad0e89cc29` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad0e89cc29 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-206fa89bfd has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-206fa89bfd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-36e9ab745d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-36e9ab745d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-36e9ab745d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-486a3cef65 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-486a3cef65` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-486a3cef65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
digging through the latest updates and wondering, why it works on EPEL7 which has an older python-dns version than EL8 installed I found EPEL7: pyspf-2.0.14-dns-query.patch diff -ruN pyspf-2.0.14-v/spf.py pyspf-2.0.14/spf.py --- pyspf-2.0.14-v/spf.py 2020-01-02 08:02:26.000000000 +1100 +++ pyspf-2.0.14/spf.py 2020-02-18 20:34:24.818456657 +1100 @@ -128,7 +128,7 @@ retVal = [] try: # FIXME: how to disable TCP fallback in dnspython if not tcpfallback? - answers = dns.resolver.query(name, qtype, lifetime=timeout) + answers = dns.resolver.query(name, qtype) for rdata in answers: if qtype == 'A' or qtype == 'AAAA': retVal.append(((name, qtype), rdata.address)) -> either apply this patch also to EPEL8 or add a conflict - then all is fine again python3-pyspf: Conflicts: python3-dns < 2.0.0
Btw, in latest python3-dns (available in Fedora) dns.resolver.query is deprecated. >>> import dns.resolver >>> dns.resolver.query("www.fedoraproject.org") <stdin>:1: DeprecationWarning: please use dns.resolver.resolve() instead <dns.resolver.Answer object at 0x7f4446f3f6a0> Should be replaced with dns.resolver.resolve. Same arguments works for me.
(In reply to Peter Bieringer from comment #32) > digging through the latest updates and wondering, why it works on EPEL7 > which has an older python-dns version than EL8 installed I found > > EPEL7: pyspf-2.0.14-dns-query.patch > > diff -ruN pyspf-2.0.14-v/spf.py pyspf-2.0.14/spf.py > --- pyspf-2.0.14-v/spf.py 2020-01-02 08:02:26.000000000 +1100 > +++ pyspf-2.0.14/spf.py 2020-02-18 20:34:24.818456657 +1100 > @@ -128,7 +128,7 @@ > retVal = [] > try: > # FIXME: how to disable TCP fallback in dnspython if not > tcpfallback? > - answers = dns.resolver.query(name, qtype, lifetime=timeout) > + answers = dns.resolver.query(name, qtype) > for rdata in answers: > if qtype == 'A' or qtype == 'AAAA': > retVal.append(((name, qtype), rdata.address)) > > > -> either apply this patch also to EPEL8 or add a conflict - then all is > fine again > > python3-pyspf: > Conflicts: python3-dns < 2.0.0 Interesting. RHEL 7 uses Python 2, RHEL 8 uses Python 3 here. I am surprised this was not broken in Fedoras, where python3-dns is also below 2.0.0.
Fedora 32: python3-dns 1.16 /usr/lib/python3.8/site-packages/dns/resolver.py def query(self, qname, rdtype=dns.rdatatype.A, rdclass=dns.rdataclass.IN, tcp=False, source=None, raise_on_no_answer=True, source_port=0, lifetime=None): EL8: python3-dns 1.15 /usr/lib/python3.6/site-packages/dns/resolver.py def query(qname, rdtype=dns.rdatatype.A, rdclass=dns.rdataclass.IN, tcp=False, source=None, raise_on_no_answer=True, source_port=0): -> the border is 1.15 <-> 1.16 and not so far mentioned < 2
(In reply to Peter Bieringer from comment #35) > -> the border is 1.15 <-> 1.16 and not so far mentioned < 2 Ah, that makes sense then. Thanks.
Current packages: python3-dns 2.0.0-1.fc33 (0:noarch) fedora (Fedora 33) python3-dns 1.16.0-10.fc32 (0:noarch) updates (Fedora 32) python3-dns 1.16.0-7.fc31 (0:noarch) updates (Fedora 31) python3-dns 1.15.0-10.el8 (0:noarch) BaseOS (CentOS 8) python-dns 1.12.0-4.20150617git465785f.el7 (0:noarch) base (CentOS 7) Looks like 1.16 has this attribute, this is because Fedora 31-32 works well, but should warn in Fedora 33. This can fix this problem (not tested, just written code): diff -ur a/spf.py b/spf.py --- a/spf.py 2020-01-01 22:02:26.000000000 +0100 +++ b/spf.py 2020-11-10 09:23:13.926030108 +0100 @@ -128,7 +128,13 @@ retVal = [] try: # FIXME: how to disable TCP fallback in dnspython if not tcpfallback? - answers = dns.resolver.query(name, qtype, lifetime=timeout) + dns_version = dns.version.MAJOR+dns.version.MINOR/100 + if dns_vesion<1.16: + answers = dns.resolver.query(name, qtype) + elif dns_version<2.0: + answers = dns.resolver.query(name, qtype, lifetime=timeout) + else: # >=2.0 + answers = dns.resolver.resolve(name, qtype, lifetime=timeout) for rdata in answers: if qtype == 'A' or qtype == 'AAAA': retVal.append(((name, qtype), rdata.address)) @@ -152,6 +158,7 @@ try: # prefer dnspython (the more complete library) import dns + import dns.version import dns.resolver # http://www.dnspython.org import dns.exception Also I am not sure, if removing lifetime parameter can't cause other problems.
FEDORA-EPEL-2020-9d43805520 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d43805520
FEDORA-EPEL-2020-9d43805520 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d43805520 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-486a3cef65 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-36e9ab745d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-ad0e89cc29 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-206fa89bfd has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-9d43805520 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.