- The others seem to either be platforms where openssl is part of the
base system, or where I can't quickly confirm that it's safe to ask
for installation of something called "openssl".
- If we miss any platforms, the OCSP checking code in "certbot
certificates" should fail gracefully.
* Added support for shells without default variable support
* Added support for BusyBox installs that do not have `command` but has `which`
* Style fixes as suggested by reviewer
* Renamed `WHERE_IS` to `EXISTS` as suggested by review
* Removed expansion of `$LE_AUTO_SUDO` to `x` as the `-n` can check empty strings.
* Added `EXISTS` to debian bootstrap as suggested in review
* pin requests version in py26-oldest
* Determine requests security deps dynamically
Starting with requests 2.12, pyasn1 and ndg-httpsclient are no longer
needed to inject pyopenssl into urllib3. This change allows us to
determine whether or not these dependencies are required at install
time. If an older version of requests is used, these packages are
still installed. If a new version of requests is used, they are not
reducing the number of dependencies we have.
* Bump requests version in certbot-auto
* Use pkg_resources in activate test
Due to pip's lack of dependency resolution, the change to use
requests[extras] causes errors in acme.util_test because pkg_resources
accurately detects the "missing" dependency.
There isn't a real problem here. The problem comes from a brand new
requests and ancient pyopenssl as well as a unit test for
functionality we plan to remove in our next release. I modified
the unit test to fix the problem for now.
* Use six instead of pkg_resources for test
* Require requests<=2.11.1 in py27-oldest test
If we don't do this, we get test failures for the certbot package
which is actually a good thing! pkg_resources is catching the
unlikely but possible problem I describe in #3803 and erroring out
saying it is missing the necessary dependencies to run certbot.
Good job package resources.
* Undo changes to acme.util_test
* disallow binary (wheel) install for pycparser
pycparser has uploaded a broken wheel for 2.14, failing for two reasons
1. sha mismatch, due to not instructing pip which dist to install
2. bug in the wheel itself
* regen letsencrypt-auto-source/letsencrypt-auto
On Debian 7 (and probably relative distro's) `aptitude show virtualenv` exits
with 0, since it is a virtual package. However, it doesn't have any installation
candidates, so filter on this case before trying to install `virtualenv` to
prevent installation-errors while bootstrapping.
NB, to make this clear:
(0)#: apt-cache show virtualenv
N: Can't select versions from package 'virtualenv' as it is purely virtual
N: No packages found
(0)#: echo $?
0
Furthermore, --quiet=0 is necessary, to be able to grep through `apt-cache`'s
output via a pipe. More details on
http://unix.stackexchange.com/questions/201869/why-isnt-apt-cache-policy-output-piped/202041#202041.
Brad Warren