Re: Quarterly 13.3 amd64 package inconsistency?

> On Aug 18, 2024, at 16:55, Edward Sanford Sutton, III <mirror176@hotmail.com> wrote:
> 
> On 8/18/24 13:19, Chris Ross wrote:
>> I’m installing deluge-cli with pkg, and I am (as default I think) pointed to
>> quarterly packages from FreeBSD.  However, deluge-cli needs py311-openssl,
>> which gets me py311-openssl-23.2.0. pyopenssl needs py-cryptography, and
>> when I ask pkg for py311-cryptography it gets me py311-cryptography-42.0.8_1.
>> Pyopenssl 23.2 (and 23.3) require cryptography <42.  So, the above doesn’t work.
> 
>  Just to clarify, you just tried to install deluge-cli and pkg did the right thing gathering all these dependencies at once instead of you manually requesting each?

Probably?  I was actually in the midst of replacing python39 with python311,
so I was reinstalling subsets of the 197 packages that were uninstalled.
I did it in lots of phases.  But, the same set of packages would have been
brought into a new install of deluge-cli.  I just don’t remember for
certain if these came in before or after I asked to [re]install deluge-cli.

> https://cgit.freebsd.org/ports/commit/security/py-cryptography/Makefile?h=2024Q3&id=f02bbcb4046ca0f792a091c4b29e35a4584b6545 shows when it was upgraded to 42 on quarterly (and has had several version bumps since).
> 
>  If building/running py-openssl-23 with the newer py-cryptography-42 fails, then py-openssl either should be patched to work, upgraded to work, or marked broken if it is in a completely unusable state or builds fail. Downgrading "could" be an option, but I'm not sure how they would want to go about that; requires a ,# version bump for quarterly and latest or a falsely labeled version. If this issue is happening, then the two maintainers + a committer should be in the loop.
> 
>  As I haven't found anything in https://portsfallout.com/fallout?port=&maintainer=&env=133amd64-quarterly&category=&flavor=py311 I presume it is not a failing build issue. Do you have logs or output of what is failing?

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.)

>  13.3 and 13.4 don't use different ports trees for packaging; [.]

Thanks for the information.  So it’s just that the packages I was seeing
built for 13.4 quarterly were built more recently I guess.

> 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?

         - Chris