Summary: | security/py-certbot@py27: script crashes with traceback | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Jesse Smith <jsmith> |
Component: | Individual Port(s) | Assignee: | Kubilay Kocak <koobs> |
Status: | Closed Not Enough Information | ||
Severity: | Affects Only Me | CC: | meta, python |
Priority: | --- | Keywords: | needs-qa |
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Jesse Smith
2019-08-20 14:54:29 UTC
@jsmith Is this still an issue with the latest version of the port/package? If so, could you please provide: - A full traceback as an attachment - pkg version -v output (as an attachment) (In reply to Kubilay Kocak from comment #1) Since Python 2.7 is no longer supported, I think this bug can be closed. Certbot is working with Python 3, giving us a reasonable workaround. (In reply to jsmith from comment #2) Python is EoL (as of Jan 1 2020), but is in sunset with a final release still to come (April, 2020 [1]) Nevertheless, Python 2.7 is set to be deprecated December 2020 in FreeBSD, with work taking place to upgrade, or retire unmaintained an deprecated packages in the meantime. What this means is that if an upstream package supports 2.7 and is maintained (upstream and downstream), that it still ought to work, work meaning: gets bugfixes if they are reproducible and resolvable based on the description of the issue provided so far: The first issue is the name of the executable changed from /usr/local/bin/certbot to /usr/local/bin/certbot-2.7 This sounds like the default version of Python on that system is not 2.7. Since only the default version of Python ports/packages get canonical (not version-suffixed script names, the lack of a certbot scriptname is intended. It is up to the administrator to either: - Invoke python scripts using their script-X.Y version, OR - Ensure that if/when invoking <script> without a version suffix, ensure that the systems configured default Python version is the one that's expected On the second issue: issue is running the new path of the script results in a Python traceback error and no certificates being fetched If this is still an issue, in any Python version of the certbot port, a full command line invocation and traceback is what's required to isolate the issue, along with information about where exactly said command points to (if one is using 'certbot', not 'certbot-X.Y' as the invoking command [1] "As a final service to the community, python-dev will bundle those fixes -- and only those fixes -- into a final 2.7.18 release," the Python Foundation noted in an update. "The release date for 2.7.18 will be in April 2020, because that allows time for the release managers to complete a release candidate and final release." If this is still an issue in the latest versions of certbot in FreeBSD ports, please re-open the issue with additional information |