Delete EOL'd freebsd 13

[am11]

See dotnet/arcade#15289 (comment)

[am11]

Nobody is / should be using CBL mariner anymore. We switched to azurelinux https://github.com/dotnet/runtime/blob/e7d837da5b1aacd9325a8b8f2214cfaf4d3f0ff6/eng/pipelines/common/templates/pipeline-with-resources.yml#L122

[am11]

cc @Thefrank @wfurt

[Thefrank]

My comment about 13.x here: dotnet/arcade#15289 (comment)

[am11]

IIUC, v13 out of standard support and it will receive security patches until 2026 right? Do we care for it at this point?

[Thefrank]

TL;DR:
There are enough people that will use 13.x until forced to move that I think we should keep the image. I do not foresee issue in downloading pkg for it until EOL. If there are resource/cost concerns, feel free to drop it.

Longer:
FreeBSD will maintain ports for all ABI versions are in support (currently 13.x and 14.x) so there should not be an issue in grabbing pkg for it.

The checks system in Runtime will be OK just using 14.x as that is where (unlikely) breakage might occur.

Not directly impacted but the ports version of dotnet8 and dotnet9 use a compat layer from FreeBSD 13 when building under 14. I don't remember exactly but I believe it was to resolve an issue with OpenSSL in 14.0 and the bootstrap not seeing the newer version.

On a personal level I use both 13 and 14 images when cross-building as I use both 13 and 14 jails.

[am11]

The checks system in Runtime will be OK just using 14.x as that is where (unlikely) breakage might occur.

Yes, one freebsd image per arch (x64 and arm64) per TFM (net9 and net10) with latest release; while keeping 13.4 and 14.2 in rootfs script sounds reasonable?

[Thefrank]

Yes, one freebsd image per arch (x64 and arm64) per TFM (net9 and net10) with latest release; while keeping 13.4 and 14.2 in rootfs script sounds reasonable?

What docker images will be available? Just x64+arm64 under 14 or those plus 13? If 13 is not a part of that but still buildable with the script that will still be fine.

[am11]

What docker images will be available? Just x64+arm64 under 14 or those plus 13?

Only FreeBSD 14: net8.0-amd64 (no arm64), net9.0-{amd64,arm64} and net10.0-{amd64,arm64}

If 13 is not a part of that but still buildable with the script that will still be fine.

Yes, it's still buildable from script and also existing tags don't get deleted from the Azure container registry (ACR), i.e.
FreeBSD 13 amd64: docker run mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-cross-amd64-freebsd-14
FreeBSD 13 arm64: docker run mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-cross-arm64-freebsd-14

They are basically frozen / set-in-stone; unless someone modifies the container registry entries and edit/delete them which is unlikely.

Note: The way we are using this RootFS (and some linux ones) is basically we don't execute anything from there. We actually need bunch of "skeleton" shared libraries .so files with real versioned symbols. We don't statically link anything from rootfs. We may even have almost-all-empty .so files with only the symbols and headers, if we think about it. The binaries which are compiled when executed on real OS dynamically load those symbols at the launch. Compare this to our current illumos / haiku / android setups, where we actually execute the compiler toolchain from the rootfs dir. Luckily, FreeBSD and Linux rootfs are on a better plan where we use the host compiler and point to the toolchain dir under rootfs, but nothing actually gets executed from there. Given this, we can even throwaway the pkg executable after rootfs is built (packages are downloaded before build-rootfs.sh exits) and treat the resultant dir like a frozen blob.