This version has an officially documented support for python3, so it
plays along our plans of removing python2 in favor of python3. When
the switch actually happens, we will need to update the ebuild to
mention the correct path to python modules. The path contains python
version, which is a hindrance. Would be nice to have it hidden behind
some variable.
There is also a version 2.4.0.2, but it's marked as a prerelease on
github, so decided to package 2.3.1.1 instead.
This is some fallout from converting scripts from python2 to
python3. Output received from the functions in subprocess module now
return bytearrays, but we operate on them as if they were a text. So
decode the bytearrays to strings. Otherwise we are either getting some
junk values passed to the command line utilities (for example:
`b'/dev/loop2'` instead of `/dev/loop2`), or exceptions are thrown,
because a function expected a string.
This is just a conversion done by 2to3 with a manual updates of
shebangs to mention python3 explicitly. The fixups for bytearray vs
string issues will follow up.
The script is potentially useful, but it seems to be unused anyway. We
can bring it back later if there's a need. Note that this will need
updating it to python3 first. Which is why I'm dropping it currently -
it's one python2 script less to port.
Upstream has switched to go 1.16, but still doesn't use go modules. The ebuilds
needed fixing up after the automated PR was created.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
To be able to support arm64 native SDK without cross builds, we should
make generate_au_zip support both architectures, amd64 and arm64.
Without doing that, `build_image` fails with `ERROR : Required
WHITE_LIST items ld-linux-x86-64.so.2 not found!!!`, because the
script recognizes only amd64 libs in WHITE_LIST.
We should first determine the architecture in build_image, before
running generate_au_zip, and pass the architecture, either amd64 or
arm64. Also add allow_list and ld_linux parameters to necessary
functions.
Set PYTHON_COMPAT to python 3.6 and 3.7 to be suitable for the current
code base.
Add a custom patch to replace error with warning when running autoconf
for cross builds, because libkrb5 is not able to detect
cross-compilation.
Based on 64e33c9f826d8fd951fd58ba1ed70debaf65be8d .
The SystemdCgroup=true setting is incompatible with kubelet
cgroupDriver: cgroupfs. So to prevent kube clusters from failing, we
will be freezing a nodes config.toml during an update. For that purpose,
we install a second configuration file that can then be selected using a
systemd drop-in unit.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Now that Docker has been updated to 20.10, we can use cgroupv2 so have
systemd mount the unified cgroup hierarchy by default. Other ways of
achieving the same would have been to pass 'systemd.unified_cgroup_hierarchy=1'
on the kernel cmdline, but this way the change propagates nicely to all
OEM consumers.
Signed-off-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
The upstream docker repository location has changed to docker/docker.
Additionally, the cli component has been split out which which requires
fetching two hashes and updating two ebuilds. We also took the chance to
align the ebuild with gentoo's, which means there are is no more live ebuild
and no symlink.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
We are switching flatcar to cgroupv2 which is support by docker 20.10 and
kubernetes 1.19. This requires setting the systemd cgroup driver in the kubelet
config.
Due to the unified cgroup hierarchy, kubernetes <1.19 will not work so
remove all older versions.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Compared to previous torcx images the docker-cli package is a separate
package, following upstream Docker repo layout changes.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The patches do the following:
* install flatcar specific wrappers and systemd config
* force some USE flags to default on
* allow injecting CFLAGS/LDFLAGS so that torcx can work
* force building with go1.13 (like upstream does) - this won't be
necessary next time because docker master already uses go1.16
This is the version needed by docker 20.10.7. ROADMAP.md doesn't exist so it
has been removed from src_install.
Signed-off-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
This is the version used by docker-19.03. We will be updating the live
ebuild to build docker 20.10 dependencies.
Signed-off-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
We use coreos-go* eclass so that we can override several environment
variables and build with the same go version as docker upstream. These
changes are modeled after what was previously done in app-emulation/docker,
the cli ebuild has only been split out since v20.10.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Docker upstream split the cli component into a separate repo, so there is
a separate ebuild that builds the docker utility. This is a prerequisite
of the update of docker to 20.10.
This is an import from portage commit 69d01a4273a556b1205a7a575cb3811ab7e2443d.
Signed-off-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
