<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/meta-cloud-services.git/meta-openstack/recipes-devtools/python/python-pbr_1.8.1.bb, branch kirkstone</title>
<subtitle>Mirror of git.yoctoproject.org/meta-cloud-services.git</subtitle>
<id>https://git.enea.com/cgit/linux/meta-cloud-services.git/atom?h=kirkstone</id>
<link rel='self' href='https://git.enea.com/cgit/linux/meta-cloud-services.git/atom?h=kirkstone'/>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-cloud-services.git/'/>
<updated>2017-01-17T19:37:48+00:00</updated>
<entry>
<title>python-pbr: drop recipe</title>
<updated>2017-01-17T19:37:48+00:00</updated>
<author>
<name>Mark Asselstine</name>
<email>mark.asselstine@windriver.com</email>
</author>
<published>2017-01-17T15:56:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-cloud-services.git/commit/?id=be8a24d60cc68e2c2a47f290201abe5ed2f062d8'/>
<id>urn:sha1:be8a24d60cc68e2c2a47f290201abe5ed2f062d8</id>
<content type='text'>
We often include our own versions of recipes in meta-virtualization
and meta-cloud-services in order to satisfy specific version
dependencies, ie. grouping recipes by usecase. Historically python-pbr
versions have been extremely flexible (most recipes only specify the
very old 1.6 as a minimum version) and python-pbr can arguably be seen
as a core python package, so remove our version of the recipe in favor
of the one in meta-python.

Signed-off-by: Mark Asselstine &lt;mark.asselstine@windriver.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@windriver.com&gt;
</content>
</entry>
<entry>
<title>python: satisfy setup.py 'setup_requires'</title>
<updated>2017-01-17T19:37:44+00:00</updated>
<author>
<name>Mark Asselstine</name>
<email>mark.asselstine@windriver.com</email>
</author>
<published>2017-01-17T19:34:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-cloud-services.git/commit/?id=39087ecc8581227a7c469260485229f71511215d'/>
<id>urn:sha1:39087ecc8581227a7c469260485229f71511215d</id>
<content type='text'>
Python setuptools will attempt to satisfy the packages defined as
'setup_requires' in setup.py by first looking for the package
availability locally and ultimately by downloading it from PyPI. This
is actually a huge security hole and packages should move to using pip
instead, but this is another story that the upstream packages have to
address. This also disregards BB_NO_NETWORK and may prove to introduce
host contamination.

The best approach is to ensure we have the -native version of the
'setup_requires' packages present such that setup.py will not attempt
to complete the download from PyPI.

Make 'pbr' -native available and for packages which we have identified
as having 'setup_requires' include 'pbr' add the necessary
python-pbr-native DEPENDS.

Signed-off-by: Mark Asselstine &lt;mark.asselstine@windriver.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@windriver.com&gt;
</content>
</entry>
<entry>
<title>python-*: uprev to versions required for liberty</title>
<updated>2016-02-05T19:42:17+00:00</updated>
<author>
<name>Mark Asselstine</name>
<email>asselsm@gmail.com</email>
</author>
<published>2016-02-04T01:41:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-cloud-services.git/commit/?id=3dd375570e0c1bc3a94d1d821946c511b17b1382'/>
<id>urn:sha1:3dd375570e0c1bc3a94d1d821946c511b17b1382</id>
<content type='text'>
This is a collection of recipe uprevs that bring various packages up
to the version required to support the liberty release.

These uprevs are mostly trivial with the expected SRC_URI and CHECKSUM
updates along with updates to the list of dependencies. Where possible
recipes have been updated to use git to facilitate future uprevs.

For python-futures we need to add a PREFERRED_VERSION to ensure the
git version will take precedence over a versioned recipe found in
another layer.

Signed-off-by: Mark Asselstine &lt;asselsm@gmail.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@windriver.com&gt;
</content>
</entry>
</feed>
