Re: Quarterly 13.3 amd64 package inconsistency?
- Reply: Chris Ross : "Re: Quarterly 13.3 amd64 package inconsistency?"
- In reply to: Chris Ross : "Quarterly 13.3 amd64 package inconsistency?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 18 Aug 2024 20:55:44 UTC
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? 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? > I see that 13.4 has py311-openssl-24.1. And, latest (for 13.3) might have > that too. But right now quarterly seems broken because the supplied > py311-openssl won’t accept the supplied py311-cryptography. 13.3 and 13.4 don't use different ports trees for packaging; both should get latest and quarterly as separate package sets. Unless anything has changed, 13.4 won't have packages made for it until 3 months after 13.4's release + 3 months, which is when 13.3 becomes EOL. 13.4 uses 13.3's packages in the meantime. The latest and quarterly packages are made at different times which is just a question of when a build job is sent to the servers (sets the versions built) + when it completes (and any delay for oversight/distribution) so sometimes comparing the ports trees vs the packages you can see a mismatch and sometimes quarterly could have a package faster than latest. > Am I doing something wrong, or is this a correct assessment of the state of > Quarterly package repo at the moment? 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. > - Chris > > >