Re: Quarterly 13.3 amd64 package inconsistency?

> On Aug 19, 2024, at 08:33, Chris Ross <cross+freebsd@distal.com> wrote:
> Yes.  I would expect that downgrading py-cryptography might be best, but
> upgrading py-openssl would also work.  And you’re right there isn’t
> a build problem, but trying to run deluge produces:
> 
> --- 8< —-- 8<- --- 8< --- 8< ---
> Starting deluged.
> Traceback (most recent call last):
>  File "/usr/local/lib/python3.11/site-packages/pkg_resources/__init__.py", line 581, in _build_master
>    ws.require(__requires__)
> [...]
>  File "/usr/local/lib/python3.11/site-packages/pkg_resources/__init__.py", line 596, in _build_from_requirements
>    dists = ws.resolve(reqs, Environment())
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  File "/usr/local/lib/python3.11/site-packages/pkg_resources/__init__.py", line 795, in resolve
>    raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'cryptography!=40.0.0,!=40.0.1,<42,>=38.
> 0.0' distribution was not found and is required by pyopenssl
> /usr/local/etc/rc.d/deluged: WARNING: failed to start deluged
> 
> --- 8< —-- 8<- --- 8< --- 8< ---
> 
> Inspecting the tree at https://github.com/pyca/pyopenssl/blob/23.3.0/setup.py
> (tag 23.3.0) shows:
> 
>        install_requires=[
>            "cryptography>=41.0.5,<42",
>        ],
> 
> and at tag 24.0.0 shows
> 
>        install_requires=[
>            "cryptography>=41.0.5,<43",
>        ],
> 
> Maybe that is a miss in the build/pkg crosschecking of requirements?
> It seems like python packages setup.py would be accounted.  (Note also
> that pyopenssl 23.2.0 retained <41 support, but that went away by
> 23.3.0.)
> 
>> I haven't tested that software nor confirmed version dependencies. The ports tree shows the versions in the trees as mentioned but does not have a version requirement checked for dependencies.
> 
> Dependency info referenced above.  Is there perhaps an issue with the
> py-openssl port then?

Coming back to this.  I temporarily switched my pkg config to use latest
instead of quarterly, which allowed me to pull in pyopenssl 24.1.0.1
and I am now running.  However, I think the problem still exists in
quarterly, and should be corrected.

I’ll drop it if no-one else cares, but it seems a “broken window” that
should be fixed.

           - Chris