“Whatever you do, do it upstream” is IMHO one of mottos worth following. So I went upstream wherever possible.
2020 came, Python 2 is no more. So 2019 was full of cleaning and patching. I filled several bugs on projects, created patches to mark some Python packages as Py2 only (or <Py3.5 only). Some projects just dropped support for Py2 packages due to it.
With move to Python 3 came some issues with Unicode characters in README files of packages used by OpenStack components. Filled some bugs, created patches and then, after several emails, someone found out that it is a bug in ‘pbr’ and fixed it ;D
Installing Python packages on AArch64 can be painful. While “pip install numpy” takes few seconds on x86-64 machine it can take an hour on Arm64 + extra time to find out which libraries and compilers need to be installed.
So Python developers created PEP-599 to sort out situation and create ‘manylinux2014’ target which can be then used to build ‘wheels’ (aka binary Python packages) not only for x86(-64) but also for 32-bit Arm, 64-bit Arm, 64-bit Power (big and little endian) and Z/Arch (s390x).
Somehow I managed to be involved in it. Went through pull request on GitHub, build checked, fixed dependencies and some other issues, filled CentOS bugs, discussed with CentOS developers on fixes and then one day all that stuff got merged.
Now you can fetch “manylinux2014” images from “pypa” account on Quay.io container registry and build ‘wheel’ binaries for different architectures. If you lack target hardware then consider services like Travis CI which provide access (free for FOSS projects).
Speaking of Travis CI… Near the end of the year I got task from one of Linaro teams to update CirrOS images with kernels from Ubuntu 18.04 or later.
I fetched current source, built images and started wondering how to do it best. So started discussing with Scott Moser (main developer) and we agreed that such move have sense and that some changes are needed in this project.
Project is now using Travis CI service for tests. With all builds being run parallel we have checks done in less than and hour. Including boot test for aarch64, arm, i386 and x86_64 architectures (ppc/ppc64/ppc64le need work).
Doing releases on GitHub is one of next tasks. Current service will redirect.
After ERP 18.12 release we decided that there will be no more releases and Debian ‘buster’ will be used as it is (ERP based on Debian ‘stretch’). So I spent some time on working with Debian kernel maintainers.
Most important part? Merging kernel configuration changes. We had about twenty extra enabled to get our servers supported. Everything worth using got merged. In meantime we even found a bug in Linux-stable tree which took some time to fix.
We were ready for Debian ‘buster’ release. And it worked out of the box on all machines we supported ;D
Bleh. Java, protobuf 2.5 and other madness… But as build engineer I get such stuff from time to time.
Last year it was mostly Apache Drill and Apache Arrow. In both cases I worked on their Debian packaging (not in-Debian one) to add/fix AArch64 support.
Other projects still wait for ‘let us move to newer protobuf’ but it will take years…