<div dir="ltr">Is anyone helping to progress this?  I just checked that stable/ussuri devstack is still broken.<div><br></div><div>Best wishes,</div><div>    Neil</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 9:20 AM Neil Jerram <<a href="mailto:neil@tigera.io">neil@tigera.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">But I don't think that solution works for devstack, does it?  Is there a way to pin setuptools in a stable/ussuri devstack run, except by changing the stable branch of the requirements project?<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 27, 2021 at 7:50 PM Előd Illés <elod.illes@est.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi again,<br>
<br>
as I see there is no objection yet about using gibi's solution [1] (as I <br>
already summarized the situation in my previous mail [2]) for a fix for <br>
similar cases, so with a general stable core hat on, I *suggest* <br>
everyone to use that solution to pin the setuptools in tox for every <br>
failing cases (so that to avoid similar future errors as well).<br>
<br>
[1] <a href="https://review.opendev.org/810461" rel="noreferrer" target="_blank">https://review.opendev.org/810461</a><br>
[2] <br>
<a href="http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025059.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025059.html</a><br>
<br>
Előd<br>
<br>
<br>
On 2021. 09. 27. 14:47, Balazs Gibizer wrote:<br>
><br>
><br>
> On Fri, Sep 24 2021 at 10:21:33 PM +0200, Thomas Goirand <br>
> <<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>> wrote:<br>
>> Hi Gibi!<br>
>><br>
>> Thanks for bringing this up.<br>
>><br>
>> As a distro package maintainer, here's my view.<br>
>><br>
>> On 9/22/21 2:11 PM, Balazs Gibizer wrote:<br>
>>>  Option 1: Bump the major version of the decorator dependency on <br>
>>> stable.<br>
>><br>
>> Decorator 4.0.11 is even in Debian Stretch (currently oldoldstable), for<br>
>> which I don't even maintain OpenStack anymore (that's OpenStack<br>
>> Newton...). So I don't see how switching to decorator 4.0.0 is a<br>
>> problem, and I don't understand how OpenStack could be using 3.4.0 which<br>
>> is in Jessie (ie: 6 years old Debian release).<br>
>><br>
>> PyPi says Decorator 3.4.0 is from 2012:<br>
>> <a href="https://pypi.org/project/decorator/#history" rel="noreferrer" target="_blank">https://pypi.org/project/decorator/#history</a><br>
>><br>
>> Do you have your release numbers correct? If so, then switching to<br>
>> Decorator 4.4.2 (available in Debian Bullseye (shipped with Victoria)<br>
>> and Ubuntu >=Focal) looks like reasonable to me... Sticking with 3.4.0<br>
>> feels a bit crazy (and I wasn't aware of it).<br>
><br>
> Thanks for the info. So from Debian perspective it is OK to bump the <br>
> decorator version on stable. As others noted in this thread it seems <br>
> to be more than just decorator that broke. :/<br>
><br>
>><br>
>>>  Option 2: Pin the setuptools version during tox installation<br>
>><br>
>> Please don't do this for the master branch, we need OpenStack to stay<br>
>> current with setuptools (yeah, even if this means breaking changes...).<br>
><br>
> I've no intention to pin it on master. Master needs to work with the <br>
> latest and greatest. Also on master it is easier to fix / replace the <br>
> dependencies that become broken with new setuptools.<br>
><br>
>><br>
>> For already released OpenStack: I don't mind much if this is done (I<br>
>> could backport fixes if something breaks).<br>
><br>
> ack<br>
><br>
>><br>
>>>  Option 3: turn off lower-constraints testing<br>
>><br>
>> I already expressed myself about this: this is dangerous as distros rely<br>
>> on it for setting lower bounds as low as possible (which is always<br>
>> preferred from a distro point of view).<br>
>><br>
>>>  Option 4: utilize pyproject.toml[6] to specify build-time requirements<br>
>><br>
>> I don't know about pyproject.toml.<br>
>><br>
>> Just my 2 cents, hoping it's useful,<br>
><br>
> Thanks!<br>
><br>
> Cheers,<br>
> gibi<br>
><br>
>> Cheers,<br>
>><br>
>> Thomas Goirand (zigo)<br>
>><br>
><br>
><br>
><br>
<br>
<br>
</blockquote></div>
</blockquote></div>