Bug 1288743
Summary: | This is a tracking bug for letsencrypt in EPEL7 | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | James Hogarth <james.hogarth> |
Component: | letsencrypt | Assignee: | James Hogarth <james.hogarth> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | bviktor, d.bz-redhat, james.hogarth, mharris, nick, pde-lists, pierre-bugzilla, rbu, seb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | letsencrypt-0.2.0-3.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-25 01:29:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 998679, 1267548, 1279261, 1288221, 1288487, 1288688, 1289345, 1289348, 1291573, 1332519 | ||
Bug Blocks: |
Description
James Hogarth
2015-12-05 18:59:51 UTC
*** Bug 1288746 has been marked as a duplicate of this bug. *** Besides all the packages currently blocking this bug, we'll need the following additional packages for either letencrypt or python-acme in EPEL7 - python-sphinxcontrib-programoutput, currently has no epel7 branch - python-pyrfc3339 - python-dialog, already approved for epel, but no build. See bug 998679 and bug 1288356 - pyOpenSSL: package is in EL7 (0.13.1) acme (claims it) needs >= 0.15 RH maintainer denied upgrading to 0.14 or later in bug 1227505 In addition, python-six is needed from RHEL 7.2 which currently requires CentOS's CR repository. I would like to see the security issue in python-cryptography in RHEL fixed before we start using letencrypt with that, bug 1267548. (In reply to Robert Buchholz from comment #2) > Besides all the packages currently blocking this bug, we'll need the > following additional packages for either letencrypt or python-acme in EPEL7 > > - python-sphinxcontrib-programoutput, currently has no epel7 branch I'm happy to change the way docs are currently handled and carry a patch (to submit back upstream) with a decent man page and not the poor thing that is just the output of --help all ... We can potentially drop this if it becomes troublesome. > - python-pyrfc3339 I hear the maintainer of this is a real pain to work with ... ;) > - python-dialog, already approved for epel, but no build. See bug 998679 and That's fairly easy to poke someone or just take over if need be > bug 1288356 > - pyOpenSSL: > package is in EL7 (0.13.1) > acme (claims it) needs >= 0.15 > RH maintainer denied upgrading to 0.14 or later in bug 1227505 > This could be a pain. Let's just build against the existing pyOpenSSL and see what breaks (or even if it just works!) ... If it doesn't work with the version in base we'll need to look at the letsencrypt code and work out a way of accomplishing the same thing against the version in the repos. Once that's sorted we can initially carry a maintainer patch to get this going and submit a pull request upstream. SO far my interaction with upstream has been positive so I don't expect to see much difficulty in such a patch lowering the pyOpenSSL requirements as being troublesome to push back up. > > In addition, python-six is needed from RHEL 7.2 which currently requires > CentOS's CR repository. > The main release is any day now, certainly before we get this out so it's not a problem. > I would like to see the security issue in python-cryptography in RHEL fixed > before we start using letencrypt with that, bug 1267548. Have you verified the actual issue still exists in the version released in RHEL? Since it's a base package now they tend to backport and fix up things like that there ... worth grabbing the changelog from the equivalent centos package and taking a look. If we could work out a way to drop the dependency for sphinx etc for docs then that would save a lot of work in the long run. A simple man page would be much more useful IMHO. Regarding the man page, I actually like the man page generated from the verbose documentation and realized we don't actually package that. I've to head out right now, but I'll push a patch later that also packages that man: http://pastebin.centos.org/37046/ Regarding pyOpenSSL, the 0.13 version won't do as a dep for python-acme. While documentation only lists one of the >= 0.15 functions in use, it actually uses several internal (!) and public APIs of pyOpenSSL. I've tried building with the 0.13, but about 5% of unit tests fail (for different reasons). I think the safest route would be to introduce 0.15 as a new package that blocks pyOpenSSL 0.13, but I'll need to check the reverse dependencies to avoid that rendering the system unusable. (In reply to Robert Buchholz from comment #5) > Regarding the man page, I actually like the man page generated from the > verbose documentation and realized we don't actually package that. I've to > head out right now, but I'll push a patch later that also packages that man: > http://pastebin.centos.org/37046/ > The current Fedora package does. Note that the pastebin can't be used as is since it refers to letsencrypt-auto ... I corrected that in the current Fedora spec. > Regarding pyOpenSSL, the 0.13 version won't do as a dep for python-acme. > While documentation only lists one of the >= 0.15 functions in use, it > actually uses several internal (!) and public APIs of pyOpenSSL. I've tried > building with the 0.13, but about 5% of unit tests fail (for different > reasons). > > I think the safest route would be to introduce 0.15 as a new package that > blocks pyOpenSSL 0.13, but I'll need to check the reverse dependencies to > avoid that rendering the system unusable. We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This is a strict policy matter which we can't bypass. If that is the case we need to provide patches to remove this dependency and, ideally, submit and have it included upstream. If we can't do this then it's likely this package is not going to be viable for inclusion in EPEL after all. (In reply to James Hogarth from comment #6) > The current Fedora package does. Note that the pastebin can't be used as is > since it refers to letsencrypt-auto ... I corrected that in the current > Fedora spec. Ah, yes the "auto" documentation. But the "webroot" docs are rather good. Any idea how we could build conditional parts of the docs? Probably easiest to patch/remove the parts we're not building and then provide the lentencrypt(7)? > We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This > is a strict policy matter which we can't bypass. Oh, I forgot again my own comment above. Does that policy even forbid a "pyOpenSSL015" package that conflicts with the RHEL-provided pyOpenSSL? > If that is the case we need to provide patches to remove this dependency > and, ideally, submit and have it included upstream. Oh pains. > If we can't do this then it's likely this package is not going to be viable > for inclusion in EPEL after all. The same goes for the EPEL6 inclusion where pyOpenSSL-0.13.1-2.el6.x86_64 is in the EL tree. (In reply to Robert Buchholz from comment #7) > (In reply to James Hogarth from comment #6) > > The current Fedora package does. Note that the pastebin can't be used as is > > since it refers to letsencrypt-auto ... I corrected that in the current > > Fedora spec. > > Ah, yes the "auto" documentation. But the "webroot" docs are rather good. > Any idea how we could build conditional parts of the docs? Probably easiest > to patch/remove the parts we're not building and then provide the > lentencrypt(7)? > I think better generation overall would benefit everybody. Let's work out a way of making upstream happy for improved docs being generated in an easier manner. > > We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This > > is a strict policy matter which we can't bypass. > > Oh, I forgot again my own comment above. Does that policy even forbid a > "pyOpenSSL015" package that conflicts with the RHEL-provided pyOpenSSL? > > > If that is the case we need to provide patches to remove this dependency > > and, ideally, submit and have it included upstream. > > Oh pains. > > > If we can't do this then it's likely this package is not going to be viable > > for inclusion in EPEL after all. > > The same goes for the EPEL6 inclusion where pyOpenSSL-0.13.1-2.el6.x86_64 is > in the EL tree. Good news on this front! https://github.com/letsencrypt/letsencrypt/issues/1861 One of the devs there looked into this for us and doesn't see why they can't drop this to 0.13+ ... especially since this easies Debian 7 support for them as well. Hopefully this isn't too tricky and they can make their 0.1.1 milestone reasonably swiftly. https://community.letsencrypt.org/t/client-version-0-2-0-released/8886 : "Relaxed PyOpenSSL version requirements. This adds support for systems with PyOpenSSL versions 0.13 or 0.14." The relaxed PyOpenSSL dependency was included in our upstream 0.2.0 release. Please let us know if there's anything else we can do to facilitate EPEL7 backporting. Thanks Peter. Just an issue with sphinx to resolve and then we can push this package. letsencrypt-0.2.0-1.el7 python-acme-0.2.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4826773e90 I have went ahead and pushed a version to EPEL7 that has docs disabled, although I'd like to get the docs built eventually. letsencrypt-0.2.0-3.el7, python-acme-0.2.0-1.el7, python-configargparse-0.10.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4826773e90 letsencrypt-0.2.0-3.el7, python-acme-0.2.0-1.el7, python-configargparse-0.10.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. |