| Summary: | <=app-crypt/acme-0.24.0 and <=app-crypt/certbot-0.24.0 are broken | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Quincy <bbc.quincy> |
| Component: | Current packages | Assignee: | Matthew Thode ( prometheanfire ) <prometheanfire> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | jstein, mlspamcb |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/ I cannot rule out, that my individual system is part of the problem and I do not expect individual help, as I already solved the problem for myself. It looks more like an outdated version of the client marked as stable is not able to communicate with the external server involved. Therefore the currently stable versions should be checked if working properly or otherwise (as in my case) the 0.25 versions should be stabilised instead. certbot 1.0.0 is missing a S= entry for extracting the sources:
The following makes it usable: (for 1.0.0)
if [[ ${PV} == 9999* ]]; then
EGIT_REPO_URI="https://github.com/certbot/certbot.git"
inherit git-r3
else
SRC_URI="https://github.com/${PN}/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
KEYWORDS="~amd64 ~arm ~arm64 ~ppc64 ~x86"
S=${WORKDIR}/certbot-${PV}/certbot
fi
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f104e8f23c8a7f4503b998333d38207fcbd7bc29 commit f104e8f23c8a7f4503b998333d38207fcbd7bc29 Author: Matthew Thode <prometheanfire@gentoo.org> AuthorDate: 2019-12-06 22:16:07 +0000 Commit: Matthew Thode <prometheanfire@gentoo.org> CommitDate: 2019-12-06 22:16:21 +0000 app-crypt/certbot: fix install for 1.0.0 Bug: https://bugs.gentoo.org/658740 Package-Manager: Portage-2.3.80, Repoman-2.3.19 Signed-off-by: Matthew Thode <prometheanfire@gentoo.org> app-crypt/certbot/certbot-1.0.0.ebuild | 2 ++ 1 file changed, 2 insertions(+) The subdirectory should be .../certbot not .../acme The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c590d3756fce5715dffc6de05c2ab22f1c1dad57 commit c590d3756fce5715dffc6de05c2ab22f1c1dad57 Author: Matthew Thode <prometheanfire@gentoo.org> AuthorDate: 2019-12-06 22:29:28 +0000 Commit: Matthew Thode <prometheanfire@gentoo.org> CommitDate: 2019-12-06 22:29:28 +0000 app-crypt/certbot: fix the S dir for real this time Bug: https://bugs.gentoo.org/658740 Package-Manager: Portage-2.3.80, Repoman-2.3.19 Signed-off-by: Matthew Thode <prometheanfire@gentoo.org> app-crypt/certbot/certbot-1.0.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Gone from the tree, closing. |
Having the stable version of =app-crypt/acme-0.24.0 and =app-crypt/certbot-0.24.0 and theri dependencies installed leads to an error when calling the staging server for the second time within a "dry-run": First call: certbot certonly --dry-run --webroot -w /abc/xyz -d domain.de Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for domain.de Using the webroot path /abc/xyz for all unmatched domains. Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - The dry run was successful. Second call: certbot certonly --dry-run --webroot -w /abc/xyz -d domain.de Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate An unexpected error occurred: Traceback (most recent call last): File "/usr/lib64/python3.5/site-packages/josepy/json_util.py", line 280, in fields_from_json fields[slot] = field.decode(value) File "/usr/lib64/python3.5/site-packages/josepy/json_util.py", line 88, in decode return self.fdec(value) File "/usr/lib64/python3.5/site-packages/acme/messages.py", line 123, in from_json '{0} not recognized'.format(cls.__name__)) josepy.errors.DeserializationError: Deserialization error: Status not recognized Examining the logs shows that indeed the "status" reported in the logs is different in the second call. Obviously versions <=0.24.0 cannot cope with that as a downgrade to 0.23.0 did not solve the issue, but an upgrade to 0.25.0 did.