On Sun, Jan 07, 2018 at 05:58:40PM +0100, Max wrote:
Hi.
Seems like jobs which update osmo-ci and osmo-python-tests on build slaves are failing for 20+ days. This only happens for some of the slaves but not the others.
I'd like to understand why this is happening and, ideally, fix it. However, there're few obstacles:
It's because of "ImportError: No module named setuptools" since your commit, where you obviously never checked whether setuptools is available on the build slaves: Author: Max <msuraev@sysmocom.de> AuthorDate: Fri Dec 15 12:12:01 2017 +0100 Commit: Max <msuraev@sysmocom.de> CommitDate: Fri Dec 15 20:40:41 2017 +0100 Use setuptools for packaging According to https://docs.python.org/3/library/distutils.html the setuptools are used in place of distutils anyway. Using it directly allows us to make packaging more flexible: specify dependencies, automatically find package name etc. Change-Id: I39ee53f352001e47c6df055cbec52d638480253d I see console logs fine. https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=Os... https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=bu... So do we really need this setuptools thing or can we just revert the change? ~N
On 07.01.2018 22:19, Neels Hofmeyr wrote:
It's because of "ImportError: No module named setuptools"
since your commit, where you obviously never checked whether setuptools is available on the build slaves
My bad, for some reason I was sure it's part of the standard library.
I see console logs fine. https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=Os... https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=bu...
I've looked in the wrong place after all - I don't see equivalent for update-osmo-python-on-slaves job.
So do we really need this setuptools thing or can we just revert the change?
Yes, we really need it because that's how jenkins.sh used by update-osmo-python-on-slaves works: by calling python setup.py ... Besides, it's only missing on build1-debian9-lxc <https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/update-osmo-python-on-slaves/label=build1-debian9-lxc/> - we should bring it on par with build2-deb8build <https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/update-osmo-python-on-slaves/label=build2-deb8build/> andOsmocomBuild1 slaves. <https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/update-osmo-python-on-slaves/label=OsmocomBuild1/> Or, better yet, unify the process of provisioning a build slave. <https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/update-osmo-python-on-slaves/label=OsmocomBuild1/> -- Max Suraev <msuraev@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
On Mon, Jan 08, 2018 at 10:27:53AM +0100, Max wrote:
Yes, we really need it because that's how jenkins.sh used by update-osmo-python-on-slaves works: by calling python setup.py ...
How then did it always work until now, without setuptools installed.
Besides, it's only missing on build1-debian9-lxc
*And* in the Dockerfile that is building the docker image we use for various tests, which is why we see the same error on various slaves. With the problem I encountered described in the mail I sent a minute ago, I am reluctant to enable the installation of newest osmo-python-tests because then it will likely install osmotestvty.py as py3, which will render numerous py tests unusable. So I will not install setuptools before the osmotestvty.py problem is resolved. ~N
participants (2)
-
Max -
Neels Hofmeyr