* fix(26.04): dangling cpp-15 copyright on cross arches

The /usr/share/doc entry of a cpp-15-<triplet> package is a symlink whose
target depends on how that package was built: gcc-15-base for the native
build, gcc-15-<triplet>-base for the cross builds. Pulling gcc-15-base
unconditionally left the symlink dangling everywhere but on the native
architecture.

The four gcc-15-<triplet>-base packages get copyright slices of their own.
The two comments claiming the symlink always points at gcc-15-base are
reworded, and the same marker is added to the two sibling entries that
were missing it.

The gcc-15-<triplet> slices have the same bug and are fixed on top of this
branch, since they need the base slices added here.

Fixes #1050 for 26.04.

* test(26.04): fix dynamic linker lookup in the cpp-15 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests and the cpp-15 s390x and ppc64le tests already use, so all
four cpp-15 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never ran on those two runners.

* fix(26.04): dangling gcc-15 copyright on cross arches

Same bug and same fix as the cpp-15 slices this branch builds on: the
/usr/share/doc entry of a gcc-15-<triplet> package is a symlink to
gcc-15-base for the native build and to gcc-15-<triplet>-base for the
cross builds, so pulling gcc-15-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-15-<triplet>-base slices added by the cpp-15 branch.

* fix(26.04): dangling cpp-15 copyright on cross arches

The /usr/share/doc entry of a cpp-15-<triplet> package is a symlink whose
target depends on how that package was built: gcc-15-base for the native
build, gcc-15-<triplet>-base for the cross builds. Pulling gcc-15-base
unconditionally left the symlink dangling everywhere but on the native
architecture.

The four gcc-15-<triplet>-base packages get copyright slices of their own.
The two comments claiming the symlink always points at gcc-15-base are
reworded, and the same marker is added to the two sibling entries that
were missing it.

The gcc-15-<triplet> slices have the same bug and are fixed on top of this
branch, since they need the base slices added here.

Fixes #1050 for 26.04.

* test(26.04): fix dynamic linker lookup in the cpp-15 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests and the cpp-15 s390x and ppc64le tests already use, so all
four cpp-15 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never ran on those two runners.

* fix(26.04): dangling cpp-15 copyright on cross arches

The /usr/share/doc entry of a cpp-15-<triplet> package is a symlink whose
target depends on how that package was built: gcc-15-base for the native
build, gcc-15-<triplet>-base for the cross builds. Pulling gcc-15-base
unconditionally left the symlink dangling everywhere but on the native
architecture.

The four gcc-15-<triplet>-base packages get copyright slices of their own.
The two comments claiming the symlink always points at gcc-15-base are
reworded, and the same marker is added to the two sibling entries that
were missing it.

The gcc-15-<triplet> slices have the same bug and are fixed on top of this
branch, since they need the base slices added here.

Fixes #1050 for 26.04.

* test(26.04): fix dynamic linker lookup in the cpp-15 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests and the cpp-15 s390x and ppc64le tests already use, so all
four cpp-15 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never ran on those two runners.

* fix(26.04): dangling cpp-15 copyright on cross arches

The /usr/share/doc entry of a cpp-15-<triplet> package is a symlink whose
target depends on how that package was built: gcc-15-base for the native
build, gcc-15-<triplet>-base for the cross builds. Pulling gcc-15-base
unconditionally left the symlink dangling everywhere but on the native
architecture.

The four gcc-15-<triplet>-base packages get copyright slices of their own.
The two comments claiming the symlink always points at gcc-15-base are
reworded, and the same marker is added to the two sibling entries that
were missing it.

The gcc-15-<triplet> slices have the same bug and are fixed on top of this
branch, since they need the base slices added here.

Fixes #1050 for 26.04.

* test(26.04): fix dynamic linker lookup in the cpp-15 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests and the cpp-15 s390x and ppc64le tests already use, so all
four cpp-15 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never ran on those two runners.

* fix(26.04): dangling gcc-15 copyright on cross arches

Same bug and same fix as the cpp-15 slices this branch builds on: the
/usr/share/doc entry of a gcc-15-<triplet> package is a symlink to
gcc-15-base for the native build and to gcc-15-<triplet>-base for the
cross builds, so pulling gcc-15-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-15-<triplet>-base slices added by the cpp-15 branch.

* feat(26.04): add cpp-13 slices for s390x and ppc64le

Forward port of #1091 from ubuntu-24.04, rewritten for chisel format v3.

The /usr/share/doc entry of a cpp-13-<triplet> package is a symlink whose
target depends on how that package was built: gcc-13-base for the native
build, gcc-13-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-13-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-13 on s390x and ppc64le

The existing cpp-13 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-13 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-13 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-13 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(libc6-dev): omit absent s390x headers

The s390x libc6-dev package no longer ships gnu/lib-names-64.h or
gnu/stubs-64.h. Restrict those entries to amd64 while retaining the
generic headers, restoring s390x slice installation on Ubuntu 26.10.

---------

Co-authored-by: Zhijie Yang <[email protected]>

* feat(26.04): add cpp-13 slices for s390x and ppc64le

Forward port of #1091 from ubuntu-24.04, rewritten for chisel format v3.

The /usr/share/doc entry of a cpp-13-<triplet> package is a symlink whose
target depends on how that package was built: gcc-13-base for the native
build, gcc-13-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-13-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-13 on s390x and ppc64le

The existing cpp-13 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-13 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-13 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-13 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* feat(26.04): add cpp-13 slices for s390x and ppc64le

Forward port of #1091 from ubuntu-24.04, rewritten for chisel format v3.

The /usr/share/doc entry of a cpp-13-<triplet> package is a symlink whose
target depends on how that package was built: gcc-13-base for the native
build, gcc-13-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-13-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-13 on s390x and ppc64le

The existing cpp-13 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-13 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-13 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-13 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(26.04): dangling gcc-13 copyright on cross arches

Same bug and same fix as the cpp-13 slices this branch builds on: the
/usr/share/doc entry of a gcc-13-<triplet> package is a symlink to
gcc-13-base for the native build and to gcc-13-<triplet>-base for the
cross builds, so pulling gcc-13-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-13-<triplet>-base slices added by the cpp-13 branch.

* test(26.04): run the gcc-13 tests on the s390x and ppc64le runners

Both suites bailed out with "Unsupported architecture" there, which fails
outright now that a change to these slices schedules them on all four
runners. The arch lists match what gcc-15 already carries.

* docs(26.04): align the gcc-13 slice notes with gcc-15

Three generations of these slices each spelled the same guidance
differently. Adopt the wording gcc-15 carries.

* feat(26.04): add gcc-13 slices for s390x and ppc64le

Forward port of the remaining half of #1092. The two new triplet slices
follow gcc-15's, including the per-architecture copyright split the rest of
this branch applies to the existing two.

gcc-13.yaml gains the matching cc1 and gcc-13 entries, so gcc-13_gcc-13 --
the architecture-independent slice that carries /usr/bin/gcc-13 along with
an assembler, a linker and cc1 -- resolves on all four architectures rather
than only amd64 and arm64.

* test(26.04): add integration tests for gcc-13 on s390x and ppc64le

Copies of the gcc-15 suites, which already cover these two runners.

* test(26.04): drop the chisel_arch workaround from the gcc-13 test

Obsolete since canonical/chisel#256, and its Unsupported architecture
fallback fails outright on the s390x and ppc64le runners -- which a change
to gcc-13.yaml now schedules. Same shape the gcc-15 test already has.

* feat(26.04): add cpp-13 slices for s390x and ppc64le

Forward port of #1091 from ubuntu-24.04, rewritten for chisel format v3.

The /usr/share/doc entry of a cpp-13-<triplet> package is a symlink whose
target depends on how that package was built: gcc-13-base for the native
build, gcc-13-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-13-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-13 on s390x and ppc64le

The existing cpp-13 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-13 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-13 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-13 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(26.04): dangling gcc-13 copyright on cross arches

Same bug and same fix as the cpp-13 slices this branch builds on: the
/usr/share/doc entry of a gcc-13-<triplet> package is a symlink to
gcc-13-base for the native build and to gcc-13-<triplet>-base for the
cross builds, so pulling gcc-13-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-13-<triplet>-base slices added by the cpp-13 branch.

* test(26.04): run the gcc-13 tests on the s390x and ppc64le runners

Both suites bailed out with "Unsupported architecture" there, which fails
outright now that a change to these slices schedules them on all four
runners. The arch lists match what gcc-15 already carries.

* docs(26.04): align the gcc-13 slice notes with gcc-15

Three generations of these slices each spelled the same guidance
differently. Adopt the wording gcc-15 carries.

* feat(26.04): add gcc-13 slices for s390x and ppc64le

Forward port of the remaining half of #1092. The two new triplet slices
follow gcc-15's, including the per-architecture copyright split the rest of
this branch applies to the existing two.

gcc-13.yaml gains the matching cc1 and gcc-13 entries, so gcc-13_gcc-13 --
the architecture-independent slice that carries /usr/bin/gcc-13 along with
an assembler, a linker and cc1 -- resolves on all four architectures rather
than only amd64 and arm64.

* test(26.04): add integration tests for gcc-13 on s390x and ppc64le

Copies of the gcc-15 suites, which already cover these two runners.

* test(26.04): drop the chisel_arch workaround from the gcc-13 test

Obsolete since canonical/chisel#256, and its Unsupported architecture
fallback fails outright on the s390x and ppc64le runners -- which a change
to gcc-13.yaml now schedules. Same shape the gcc-15 test already has.

* feat(26.04): add cpp-14 slices for s390x and ppc64le

Same shape as the cpp-13 slices, one toolchain generation up.

The /usr/share/doc entry of a cpp-14-<triplet> package is a symlink whose
target depends on how that package was built: gcc-14-base for the native
build, gcc-14-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-14-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-14 on s390x and ppc64le

The existing cpp-14 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-14 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-14 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-14 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(libc6-dev): omit absent s390x headers

The s390x libc6-dev package no longer ships gnu/lib-names-64.h or
gnu/stubs-64.h. Restrict those entries to amd64 while retaining the
generic headers, restoring s390x slice installation on Ubuntu 26.10.

---------

Co-authored-by: Zhijie Yang <[email protected]>

* feat(26.04): add cpp-14 slices for s390x and ppc64le

Same shape as the cpp-13 slices, one toolchain generation up.

The /usr/share/doc entry of a cpp-14-<triplet> package is a symlink whose
target depends on how that package was built: gcc-14-base for the native
build, gcc-14-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-14-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-14 on s390x and ppc64le

The existing cpp-14 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-14 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-14 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-14 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* feat(26.04): add cpp-14 slices for s390x and ppc64le

Same shape as the cpp-13 slices, one toolchain generation up.

The /usr/share/doc entry of a cpp-14-<triplet> package is a symlink whose
target depends on how that package was built: gcc-14-base for the native
build, gcc-14-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-14-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-14 on s390x and ppc64le

The existing cpp-14 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-14 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-14 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-14 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(26.04): dangling gcc-14 copyright on cross arches

Same bug and same fix as the cpp-14 slices this branch builds on: the
/usr/share/doc entry of a gcc-14-<triplet> package is a symlink to
gcc-14-base for the native build and to gcc-14-<triplet>-base for the
cross builds, so pulling gcc-14-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-14-<triplet>-base slices added by the cpp-14 branch.

* test(26.04): run the gcc-14 tests on the s390x and ppc64le runners

Both suites bailed out with "Unsupported architecture" there, which fails
outright now that a change to these slices schedules them on all four
runners. The arch lists match what gcc-15 already carries.

* docs(26.04): correct and align the gcc-14 slice notes

The notes pointed at cpp-12-<triplet> for the cc1 compiler, two
generations off. They also carried a TODO saying the architecture-
independent gcc-14 slices do not exist yet, which slices/gcc-14.yaml has
since made untrue.

Replaced with the wording gcc-15 already carries, so the three generations
read the same.

* feat(26.04): add gcc-14 slices for s390x and ppc64le

The two new triplet slices follow gcc-15's, including the per-architecture
copyright split the rest of this branch applies to the existing two. Noble
has no gcc-14, so there is nothing to forward port from -- this is #1092
applied to a generation that release never carried.

gcc-14.yaml gains the matching cc1 and gcc-14 entries, so gcc-14_gcc-14 --
the architecture-independent slice that carries /usr/bin/gcc-14 along with
an assembler, a linker and cc1 -- resolves on all four architectures rather
than only amd64 and arm64.

* test(26.04): add integration tests for gcc-14 on s390x and ppc64le

Copies of the gcc-15 suites, which already cover these two runners.

* test(26.04): drop the chisel_arch workaround from the gcc-14 test

Obsolete since canonical/chisel#256, and its Unsupported architecture
fallback fails outright on the s390x and ppc64le runners -- which a change
to gcc-14.yaml now schedules. Same shape the gcc-15 test already has.

* feat(26.04): add cpp-14 slices for s390x and ppc64le

Same shape as the cpp-13 slices, one toolchain generation up.

The /usr/share/doc entry of a cpp-14-<triplet> package is a symlink whose
target depends on how that package was built: gcc-14-base for the native
build, gcc-14-<triplet>-base for the cross builds. The copyright slices
are keyed by architecture accordingly, and the four gcc-14-<triplet>-base
packages get copyright slices of their own.

* test(26.04): add integration tests for cpp-14 on s390x and ppc64le

The existing cpp-14 tests also learn about the two new spread runners, on
which they are cross-compilation cases.

* docs(26.04): mark cpp-14 copyright paths as symlinks

Matches the marker the binutils and cpp-15 slices carry, and makes it
clear the entry is not the directory it looks like.

* test(26.04): fix dynamic linker lookup in the cpp-14 tests

The ld-linux-*.so.* glob matches nothing on ppc64el and s390x, whose
loaders are ld64.so.2 and ld64.so.1. Use the same lookup #1090 gave the
binutils tests, so all four cpp-14 suites agree.

Nothing was failing: the value is only consumed on the native-architecture
path, which never runs on those two runners.

* fix(26.04): dangling gcc-14 copyright on cross arches

Same bug and same fix as the cpp-14 slices this branch builds on: the
/usr/share/doc entry of a gcc-14-<triplet> package is a symlink to
gcc-14-base for the native build and to gcc-14-<triplet>-base for the
cross builds, so pulling gcc-14-base unconditionally left it dangling
everywhere but on the native architecture.

Depends on the gcc-14-<triplet>-base slices added by the cpp-14 branch.

* test(26.04): run the gcc-14 tests on the s390x and ppc64le runners

Both suites bailed out with "Unsupported architecture" there, which fails
outright now that a change to these slices schedules them on all four
runners. The arch lists match what gcc-15 already carries.

* docs(26.04): correct and align the gcc-14 slice notes

The notes pointed at cpp-12-<triplet> for the cc1 compiler, two
generations off. They also carried a TODO saying the architecture-
independent gcc-14 slices do not exist yet, which slices/gcc-14.yaml has
since made untrue.

Replaced with the wording gcc-15 already carries, so the three generations
read the same.

* feat(26.04): add gcc-14 slices for s390x and ppc64le

The two new triplet slices follow gcc-15's, including the per-architecture
copyright split the rest of this branch applies to the existing two. Noble
has no gcc-14, so there is nothing to forward port from -- this is #1092
applied to a generation that release never carried.

gcc-14.yaml gains the matching cc1 and gcc-14 entries, so gcc-14_gcc-14 --
the architecture-independent slice that carries /usr/bin/gcc-14 along with
an assembler, a linker and cc1 -- resolves on all four architectures rather
than only amd64 and arm64.

* test(26.04): add integration tests for gcc-14 on s390x and ppc64le

Copies of the gcc-15 suites, which already cover these two runners.

* test(26.04): drop the chisel_arch workaround from the gcc-14 test

Obsolete since canonical/chisel#256, and its Unsupported architecture
fallback fails outright on the s390x and ppc64le runners -- which a change
to gcc-14.yaml now schedules. Same shape the gcc-15 test already has.