This appears to be an unmaintained fork of the original code, which
lives elsewhere [1]. Kill it.
[1] https://github.com/cloud-init/cloud-init
Change-Id: I1f57197f1f67aa6adce152b5e4acc63a72277c6a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
- put a brief description of license in LICENSE file
- put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
- simplify the per-file header to reference LICENSE
- also, tox.ini: work around httpretty issue
Change-Id: I259ed23767472047da823c1a67085e47afc561d8
the Requires would get that string rendered into the package's
Depends/Requires (rather than BuildDepends/BuildRequires).
We should have BuildDepends/BuildRequires too, but since
trunk's package builds do not run 'make test', this isn't a big deal.
This also adds 'test-requires' for httpretty.
remove python:Depends macro from the control.in file. This seemed to be
overriding my 'python-json-patch | python-jsonpatch' with whichever
one was installed.
So, we're not getting automatic dependencies on trunk, which is honestly fine.
We'll manage them this way.
debian bug 717916 renames python-json-patch to python-jsonpatch, so ubuntu
cloud-images with cloud-init may not have python-json-patch.
Just accept either one.
saucy split cloud-utils into cloud-guest-utils and cloud-image-utils.
The former is in the cloud image, the latter is not, and
we actually need it for growpart which is in the former.
-d pass through '-d' to debuild
--no-cloud-utils don't depend on cloud-utils package (default: False)
These are essential for building on Debian 6, because there are
no python-mocker (build dependency) and cloud-utils (install dependency)
in squeeze and squeeze-backports.
It seems like its possible that boto 2.5.2 and below have the lazy loading
metadata dictionary so as a precaution we will always take the hit of
unlazying the metadata dictionary by traversing it which in the non-lazy
dictionary case has no effect (its marginal). This also removes the need
to check the boto version and the dependency on setup tools just for this
case.
newer versions of boto lazily load the metadata from the ec2
metadata service. Here, we:
1. Add a ec2_utils module that checks which version of boto is being used and
under the right versions the metadata dictionary will be expanded.
2. Use this new ec2_utils module in the cloudstack and ec2
datasources as there entrypoints into boto.
3. Add a dependency on python-pkg-resources (from pkg_resources import
parse_version) to determine the boto version.
Stephen Finucane