After
3a553e0bb9
there are no more base images shared between the net8.0 and
net9.0 images, so this cleans up the directory structure a bit by
separating net8.0 from net9.0.
Fixes failures running tests on the new arm32 images in
https://github.com/dotnet/runtime/pull/102059:
```
[BEGIN EXECUTION]
+ sudo python -m pip install --disable-pip-version-check -r /root/helix/scripts/runtime_python_requirements.txt
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
```
This fix is only for the arm32 image, which is the only one used
in dotnet/runtime.
There are references to debian-12 arm images in aspnetcore, but
they seem to be unused. The arm64 and amd64 images have similar
errors if I try 'sudo pip install' locally, so they are probably
broken as well, but I'm limiting the fix to arm32 images that we
know we need for ci.
This fixes two problems with the Azure Linux images when building
runtime:
- lld was failing because it didn't have zlib support
The mariner images had zlib-devel installed as a dependency of
other packages (debootstrap, binutils), which no longer bring
in zlib-devel on Azure Linux.
- The toolchain was picking up clang-17 instead of our source-built clang-16
This was brought in by the lldb-devel package, so removing it
for now. We may need to build this from source for the
diagnostics repo.