Bug 259279 - sysutils/py-salt: 3004 fails to run: Requirement.parse('pyzmq<22.0.0,>=17.0.0'), {'salt'})
Summary: sysutils/py-salt: 3004 fails to run: Requirement.parse('pyzmq<22.0.0,>=17.0.0...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Kirill Ponomarev
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-10-19 17:15 UTC by Danny McGrath
Modified: 2021-11-05 00:22 UTC (History)
6 users (show)

See Also:
koobs: maintainer-feedback+
koobs: merge-quarterly-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Danny McGrath 2021-10-19 17:15:12 UTC
Hi,

I was noticing that after an upgrade from 3003.3_1 to 3004 that running high states shows some warnings about the version of pyzmq installed:

---

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 568, in _build_master
    ws.require(__requires__)
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 777, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (pyzmq 22.3.0 (/usr/local/lib/python3.8/site-packages), Requirement.parse('pyzmq<22.0.0,>=17.0.0'), {'salt'})

---

 #> pkg info | grep pyz
py38-pyzmq-22.3.0              Python bindings for ZeroMQ

---

The states seem to run fine, so I am not sure if this is just a neglected requirements that was missed, or if there are actual problems with 22.3.0 that is used in 2021Q4.

Anyway, thanks in advance! o/
Comment 1 Michele Possamai 2021-10-25 13:33:08 UTC
This also breaks salt_api if you use a cherrypy webgui like SaltGUI

---------------------------------------------------------------
2021-10-25 15:28:48,994 [salt.loader.lazy                         :787 ][ERROR   ][7065] Failed to import netapi rest_cherrypy, this is due most likely to a syntax error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 568, in _build_master
    ws.require(__requires__)
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 777, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (pyzmq 22.3.0 (/usr/local/lib/python3.8/site-packages), Requirement.parse('pyzmq<22.0.0,>=17.0.0'), {'salt'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/salt/loader/lazy.py", line 745, in _load_module
    mod = spec.loader.load_module()
  File "<frozen importlib._bootstrap_external>", line 522, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 1022, in load_module
  File "<frozen importlib._bootstrap_external>", line 847, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 843, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/usr/local/lib/python3.8/site-packages/salt/netapi/rest_cherrypy/__init__.py", line 16, in <module>
    import cherrypy
  File "/usr/local/lib/python3.8/site-packages/cherrypy/__init__.py", line 60, in <module>
    import pkg_resources
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3243, in <module>
    def _initialize_master_working_set():
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3255, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 570, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyzmq<22.0.0,>=17.0.0' distribution was not found and is required by salt
---------------------------------------------------------------
Comment 2 ari 2021-10-25 14:32:54 UTC
Also breaks any "pip.installed" states.
Comment 3 ari 2021-10-25 14:39:25 UTC
Here is the commit in salt which introduced this new limitation:

https://github.com/saltstack/salt/commit/070597e525bb7d56ffadede1aede325dfb1b73a4

Its really not clear what bug this was fixing.
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-27 00:58:32 UTC
Is latest (ports head) affected in the same, similar of different way? Current Port versions would indicate yes

Do (upstream) tests pass if '<22.0.0' is removed (patched out) of the version-spec ? Worse case we'll need pyzmq21.
Comment 5 ari 2021-10-27 01:07:29 UTC
I reckon that since the change in salt doesn't fix any known bug and everything was working fine before this change, the simplest solution is to patch out the new pyzmq version requirement.

Could we PLEASE have a new salt-latest port to track the latest buggy salt release instead of advancing this port to introduce major new bugs every 6 months?
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-27 01:13:15 UTC
We should ensure (in addition to a -dev port if thats valuable for users) that complete and extensive QA is run as well. TEST_DEPENDS and a test target would go a long way to this.
Comment 7 Danny McGrath 2021-10-28 16:29:17 UTC
I noticed that the patch was applied to the 2021Q4 branch, and so far, everything seems just fine here. I can't speak for the others here, of course.

Thanks!
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-30 00:08:03 UTC
krion@ committed ports 13f3619de8bd

@Kirill Is head/latest also affected or is this issue now resolved? If thelatter, please self-assign and close, thanks!
Comment 9 Kirill Ponomarev freebsd_committer freebsd_triage 2021-10-30 07:17:37 UTC
@Kubilay we're investigating it now at upstream, it will be fixed next week I guess, will let you know and update this PR accordingly.
Comment 10 Kirill Ponomarev freebsd_committer freebsd_triage 2021-11-03 15:53:23 UTC
Fixed in upstream, so I'll close this report.
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2021-11-04 04:51:43 UTC
(In reply to Kirill Ponomarev from comment #10)

If the port/package is currently affected, is this actually resolved?
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2021-11-04 04:52:29 UTC
And could you point us to upstream (issue, pr, commit) references
Comment 13 ari 2021-11-04 04:57:03 UTC
This was resolved for me by this patch: https://cgit.freebsd.org/ports/commit/?id=ddffa24d1a494a4354d84b553f08f493e0220c11


Whether salt upstream fixes it for the next release in six months is irrelevant to the situation today.
Comment 14 Kubilay Kocak freebsd_committer freebsd_triage 2021-11-04 05:02:38 UTC
^Triage: Assign to committer that resolved (PR: not referenced)
Comment 15 Michele Possamai 2021-11-04 14:33:50 UTC
Does anyone know how long it generally takes for a package to be updated after a patch like this is done?

I'm trying to decide if it's worth my time and resources to set up poudriere or not.
Comment 16 Kubilay Kocak freebsd_committer freebsd_triage 2021-11-05 00:22:58 UTC
(In reply to Michele Possamai from comment #15)

Usually up to 48 hours (to complete, not start), all else being equal on the official builders