| *** yadnesh|away is now known as yadnesh | 04:28 | |
| opendevreview | Elod Illes proposed openstack/requirements master: DNM: debug patch https://review.opendev.org/c/openstack/requirements/+/873702 | 11:30 |
|---|---|---|
| opendevreview | Elod Illes proposed openstack/requirements master: update constraint for ovsdbapp to new release 2.2.1 https://review.opendev.org/c/openstack/requirements/+/873386 | 11:31 |
| *** yadnesh is now known as yadnesh|away | 13:31 | |
| bauzas | is it me or the requirements gate jobs have problems with lesscpy ? https://zuul.opendev.org/t/openstack/build/7440583829e343089d566af6ece786b8 and https://zuul.opendev.org/t/openstack/build/7440583829e343089d566af6ece786b8 show me something is borked | 14:25 |
| bauzas | context : https://review.opendev.org/c/openstack/requirements/+/873416 seems to be blocked | 14:26 |
| elodilles | bauzas: not exactly with lesscpy but one of its version. but the workaround is on the gate: https://review.opendev.org/c/openstack/requirements/+/873620 | 14:43 |
| elodilles | bauzas: though unfortunately there is another issue with py3*-check-uc jobs | 14:43 |
| bauzas | elodilles: thanks for the heads-up | 14:43 |
| elodilles | bauzas: it seems that those are also breaking probably due to setuptools bundled in the latest virtualenv release :S | 14:44 |
| bauzas | yup, I've seen that the file was pretty old (2018) so something changed in between | 14:45 |
| elodilles | and i could not reproduce it locally as locally everything passing for me (focal, latest virtualenv, pip, tox, so probably the same as in the *-check-uc jobs) | 14:45 |
| opendevreview | Elod Illes proposed openstack/requirements master: Cap virtualenv (<20.19.0) to unblock gate https://review.opendev.org/c/openstack/requirements/+/873732 | 16:54 |
| opendevreview | Elod Illes proposed openstack/requirements master: update constraint for ovsdbapp to new release 2.2.1 https://review.opendev.org/c/openstack/requirements/+/873386 | 16:54 |
| opendevreview | Elod Illes proposed openstack/requirements master: Cap virtualenv (<20.19.0) to unblock gate https://review.opendev.org/c/openstack/requirements/+/873732 | 19:22 |
| opendevreview | Elod Illes proposed openstack/requirements master: update constraint for ovsdbapp to new release 2.2.1 https://review.opendev.org/c/openstack/requirements/+/873386 | 19:22 |
| opendevreview | Elod Illes proposed openstack/requirements master: Cap virtualenv (<20.18.0) to unblock gate https://review.opendev.org/c/openstack/requirements/+/873732 | 19:46 |
| opendevreview | Elod Illes proposed openstack/requirements master: update constraint for ovsdbapp to new release 2.2.1 https://review.opendev.org/c/openstack/requirements/+/873386 | 19:46 |
| elodilles | prometheanfire: hi! the gate is broken (py38, py39, py38-check-uc, py39-check-uc) and i don't have better solution yet but to cap virtualenv to at least make it possible to bump the upper constraints of the newly released libraries. so this patch works finally: https://review.opendev.org/c/openstack/requirements/+/873732 | 20:05 |
| elodilles | prometheanfire: please review it when you have time | 20:05 |
| elodilles | (pkg_resources in the new setuptools fails on multiple packages while parsing their metadata, as far as I understood...) | 20:07 |
| prometheanfire | elodilles: ya, capping sounds like what's needed given the level of breakage | 20:30 |
| prometheanfire | tonyb: you around and want to be ptl this cycle (or co-ptl was talked about iirc)? | 20:45 |
| clarkb | in the case of lesscpy why not change it to >=0.10.0? That is from 2014 so should be safe and won't explode. Gratned there may be other versions that are a problem too but for lesscpy in particular this seems a simple fix | 20:45 |
| clarkb | its also just a test file? | 20:47 |
| clarkb | https://opendev.org/openstack/requirements/src/branch/master/openstack_requirements/tests/files/gr-base.txt#L25 | 20:48 |
| prometheanfire | clarkb: https://review.opendev.org/873620 | 20:49 |
| clarkb | One thing to be aware of with 873732 is that when you use tox requires it will always install and use latest tox unless you also cap tox in the requires | 20:51 |
| prometheanfire | it doesn't look like we are controling that version within requirements at least | 20:54 |
| clarkb | its an annoying behavior that came up when we were trying to pin tox<4 for stable branches | 20:55 |
| clarkb | it always installs tox into the inner venv that it builds for your requires so you have to also set the version cap if you don't want latest tox there | 20:55 |
| clarkb | in this case its probablyfine since the change is on master but if it were against a stable branch you'd need to cap i | 20:56 |
| prometheanfire | master will be a stable branch one day | 20:56 |
| clarkb | true. | 20:57 |
| clarkb | we don't know what to cap it at yet though. But maybe <5 is a reasnable thing. I don't know | 20:58 |
| prometheanfire | ya, given reqs is primarily around for testing reasons I don't think we need to cap it until we have an issue | 20:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!