Re-apply reverted commit Iabda95073faa2191fd117e9637e0858c589e9d9e
("Drop python2 support"), but with additional changes to make the
scripts actually work with python3 and to make it build without python2.
I have verified, that the contrib/jenkins.sh scripts of all Osmocom
repositories (with their python3 patches on top) are working with this
patch and that all Osmocom repositories with the python3 patches build
in OBS (tested in own namespace).
All related patches for changing from python2 to 3 in other repositories
must be merged shortly after this one, as soon as the build slaves were
(automatically) updated to have the new osmo-python-tests installed:
https://gerrit.osmocom.org/q/topic:drop-py2
New fixes:
* osmopy/obscvty.py: verify: fix compare
Comparing maps in python3 does not work the same as in python2. Convert
them to lists first, so the compare works as intended again.
Fix error:
File "/home/user/code/osmo-dev/src/osmo-python-tests/scripts/osmotestvty.py", line 57, in test_history
assert(self.vty.w_verify(test_str, [t1]))
AssertionError
* osmopy/obscvty.py: use enc/dec with send/recv
Fix error:
self.socket.send("%s\r" % request)
TypeError: a bytes-like object is required, not 'str'
* scripts/osmotestconfig.py: use encode() before writing to file
Fix error:
File "/home/user/code/osmo-dev/src/osmo-python-tests/scripts/osmotestconfig.py", line 91, in copy_config
tmpfile.write(open(config).read())
File "/usr/lib/python3.5/tempfile.py", line 622, in func_wrapper
return func(*args, **kwargs)
TypeError: a bytes-like object is required, not 'str'
* debian/control: add --buildsystem=pybuild. Otherwise "--with python3"
is ignored and the build fails if python2 is not installed, with:
Can't exec "pyversions": No such file or directory at /usr/[...]/python_distutils.pm line 120.
Related: OS#2819
Change-Id: I3ffc3519bf6c22536a49dad7a966188ddad351a7
This reverts commit fb1dc7c405.
I was under the impression, that all previous scripts were already
working with python 3. But as it turns out, this isn't true. Reverting,
so I can properly post follow-up patches, that fix the issues before we
apply this "drop python2" patch again.
Related: OS#2819
Change-Id: Ic1559d1a9f7839fa86a841d62a04b22e1caed466
Remove all compatibility code for python2.
All scripts are already python 3 compatible since
I80e5850a8978d78cda793e2192ef4bd3fd54a121 and
I1b4a629f12863c498a8681b555f57b4e255cebfb.
dpkg-buildpackage shows that it is still invoking setup.py with python
in addition to python3, on debian stretch. But after spending quite some
time on trying to convince it to not care about python2 without success
(trying different variables, overrides, --without python2 flags etc.),
I'm leaving it as is. The resulting package is the python3 package, which
is what we want.
Related: OS#2819
Change-Id: Iabda95073faa2191fd117e9637e0858c589e9d9e
If older incompatible version of osmopython is already available, it
might be chosen fori mport instead of current version. Fix this by
explicitly prepending the proper version to path.
Change-Id: Icbe2af1e3815406213be29e0c0360432dc9fd6fb
Related: OS#2821
This helps with debugging of import-related issues - we know the version
under test before the test has a chance to hang.
Change-Id: If13cba60a19e9c15885355f85def4d134fa37993
Related: OS#2821
As of 577f2a95e4f01c58a0a4f4ccb3b70d9c048b626e in osmo-ci, the
contrib/jenkins.sh isused forinstallation. This causes the issue with
python3 because test coded use absolute import by default.
Fix this by adding relative path and import from ../osmopy to make
sure test code uses the current module and not the one which might be
already installed in the system.
Change-Id: I8ac3c0d45fb2e1d18646048703ac405be1c7e539
* make parse() return command id in addition to variable name and value
* introduce parse_kv() wrapper which ignores that id and use it instead
of old parse()
* make parse() compatible with python3 where we got bytes, not string
from the socket so we have to decode it properly before using split()
* expand test_py3.py with simply asyn server which verifies that
osmo_ctrl.py works properly
Change-Id: I599f9f5a18109929f59386ab4416b8bfd75c74d1
* make sure jenkins.sh fails on any errors similar to other jenkins jobs
* always explicitly use python2 instead of generic python
* add basic module import tests for python 2 and 3
* add comments
Change-Id: I0f4639537d227c513859d4552533ce1e41df9deb
Oliver Smith
Max