Some CI jobs on Fedora Rawhide fail with Podman rootless builds due to
missing subuid/subgid ranges for the zuul-worker user:

    Error: cannot find mappings for user zuul-worker in /etc/subuid

Fedora 42 and other distros already ship default ranges
(e.g., zuul-worker:524288:65536), but Rawhide seems to lack them.

Add pre-tasks to setup-env.yaml to:

- Dump current /etc/subuid and /etc/subgid contents for debug
- Ensure the required ranges exist without overwriting existing configs

Once the Rawhide base image is fixed, this can be reverted.

containers#1688

Some CI jobs on Fedora Rawhide still failed after adding the missing
subuid/subgid ranges for zuul-worker, showing:

potentially insufficient UIDs or GIDs available in user namespace
(requested 0:42 for /etc/shadow): Check /etc/subuid and /etc/subgid
if configured locally and run "podman system migrate"

Add a podman system migrate step right after updating the mappings to
ensure Podman refreshes its user namespace configuration.

This can be reverted once the Rawhide base image ships proper defaults.

containers#1688

The fix was first added to setup-env.yaml but ran too late in the CI job.
Since Podman is invoked early in dependencies-fedora.yaml, the workaround
now runs right after installing shadow-utils-subid-devel.

containers#1688

Some CI jobs on Fedora Rawhide fail with Podman rootless builds due to
missing subuid/subgid ranges for the zuul-worker user:

    Error: cannot find mappings for user zuul-worker in /etc/subuid

Fedora 42 and other distros already ship default ranges
(e.g., zuul-worker:524288:65536), but Rawhide seems to lack them.

Add pre-tasks to setup-env.yaml to:

- Dump current /etc/subuid and /etc/subgid contents for debug
- Ensure the required ranges exist without overwriting existing configs

Once the Rawhide base image is fixed, this can be reverted.

containers#1688

Some CI jobs on Fedora Rawhide still failed after adding the missing
subuid/subgid ranges for zuul-worker, showing:

potentially insufficient UIDs or GIDs available in user namespace
(requested 0:42 for /etc/shadow): Check /etc/subuid and /etc/subgid
if configured locally and run "podman system migrate"

Add a podman system migrate step right after updating the mappings to
ensure Podman refreshes its user namespace configuration.

This can be reverted once the Rawhide base image ships proper defaults.

containers#1688

The fix was first added to setup-env.yaml but ran too late in the CI job.
Since Podman is invoked early in dependencies-fedora.yaml, the workaround
now runs right after installing shadow-utils-subid-devel.

containers#1688

Some CI jobs on Fedora Rawhide fail with Podman rootless builds due to
missing subuid/subgid ranges for the zuul-worker user:

    Error: cannot find mappings for user zuul-worker in /etc/subuid

Fedora 42 and other distros already ship default ranges
(e.g., zuul-worker:524288:65536), but Rawhide seems to lack them.

Add pre-tasks to dependencies-fedora.yaml to ensure the required ranges
exist without overwriting existing configs, and run `podman system migrate`
to refresh user namespace mappings.

Once the Rawhide base image is fixed, this can be reverted.

containers#1688

On Fedora 42 onwards, useradd(8) stopped automatically assigning
subordinate user and group ID ranges [1,2] to address a security concern
marked as CVE-2024-56433 [3].  This breaks rootless Podman and Skopeo,
and therefore Toolbx [4].

Restore the subordinate user and group ID ranges until a different
solution emerges.

[1] Fedora shadow-utils commit e1cfa31731cd68aa
    https://src.fedoraproject.org/rpms/shadow-utils/c/e1cfa31731cd68aa
    https://bugzilla.redhat.com/show_bug.cgi?id=2334168

[2] Fedora shadow-utils commit 4929903292e027ca
    https://src.fedoraproject.org/rpms/shadow-utils/c/4929903292e027ca
    https://bugzilla.redhat.com/show_bug.cgi?id=2334169

[3] shadow-maint/shadow#1157

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2382662

containers#1688

In the new version of bash, the error output has been changed in
this situation:

GNU bash, version 5.2.37 (bash-5.2.37-1.fc42.x86_64):
  $ bash -c 'exec "$@"' bash /etc
  bash: line 1: /etc: Is a directory
  bash: line 1: exec: /etc: cannot execute: Is a directory

GNU bash, version 5.3.0 (bash-5.3.0-2.fc43.x86_64):
  $ bash -c 'exec "$@"' bash /etc
  bash: line 1: /etc: Is a directory

containers#1688 (review)

In the new version of bash, the error output has been changed in
this situation:

GNU bash, version 5.2.37 (bash-5.2.37-1.fc42.x86_64):
  $ bash -c 'exec "$@"' bash /etc
  bash: line 1: /etc: Is a directory
  bash: line 1: exec: /etc: cannot execute: Is a directory

GNU bash, version 5.3.0 (bash-5.3.0-2.fc43.x86_64):
  $ bash -c 'exec "$@"' bash /etc
  bash: line 1: /etc: Is a directory

containers#1688 (review)

Bash 5.3.0 changed the error messages shown by its exec built-in [1].

With Bash 5.2.37:
  $ exec /etc
  bash: /etc: Is a directory
  bash: exec: /etc: cannot execute: Is a directory

With Bash 5.3.0:
  $ exec /etc
  bash: /etc: Is a directory

The 'assert' function cannot directly handle compound commands.  So,
those need to be wrapped in 'bash -c "..."' [2].

[1] Bash commit b8c60bc9ca365f82
    See how exec_builtin() handles EX_NOEXEC and EISDIR from
    shell_execve() to avoid printing a duplicate error message.
    https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?id=b8c60bc9ca365f82

[2] https://github.com/bats-core/bats-assert

containers#1688
containers#1699

Bash 5.3.0 changed the error messages shown by its exec built-in [1].

With Bash 5.2.37:
  $ exec /etc
  bash: /etc: Is a directory
  bash: exec: /etc: cannot execute: Is a directory

With Bash 5.3.0:
  $ exec /etc
  bash: /etc: Is a directory

The 'assert' function cannot directly handle compound commands.  So,
those need to be wrapped in 'bash -c "..."' [2].

[1] Bash commit b8c60bc9ca365f82
    See how exec_builtin() handles EX_NOEXEC and EISDIR from
    shell_execve() to avoid printing a duplicate error message.
    https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?id=b8c60bc9ca365f82

[2] https://github.com/bats-core/bats-assert

containers#1688
containers#1699

Bash 5.3.0 changed the error messages shown by its exec built-in [1].

With Bash 5.2.37:
  $ exec /etc
  bash: /etc: Is a directory
  bash: exec: /etc: cannot execute: Is a directory

With Bash 5.3.0:
  $ exec /etc
  bash: /etc: Is a directory

The 'assert' function cannot directly handle compound commands.  So,
those need to be wrapped in 'bash -c "..."' [2].

[1] Bash commit b8c60bc9ca365f82
    See how exec_builtin() handles EX_NOEXEC and EISDIR from
    shell_execve() to avoid printing a duplicate error message.
    https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?id=b8c60bc9ca365f82

[2] https://github.com/bats-core/bats-assert

containers#1688
containers#1699
containers#1739
(backported from commit 6c98db6)

Bash 5.3.0 changed the error messages shown by its exec built-in [1].

With Bash 5.2.37:
  $ exec /etc
  bash: /etc: Is a directory
  bash: exec: /etc: cannot execute: Is a directory

With Bash 5.3.0:
  $ exec /etc
  bash: /etc: Is a directory

The 'assert' function cannot directly handle compound commands.  So,
those need to be wrapped in 'bash -c "..."' [2].

[1] Bash commit b8c60bc9ca365f82
    See how exec_builtin() handles EX_NOEXEC and EISDIR from
    shell_execve() to avoid printing a duplicate error message.
    https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?id=b8c60bc9ca365f82

[2] https://github.com/bats-core/bats-assert

containers#1688
containers#1699
containers#1739
containers#1743
(backported from commit 6c98db6)
(cherry picked from commit 0090893)

Bash 5.3.0 changed the error messages shown by its exec built-in [1].

With Bash 5.2.37:
  $ exec /etc
  bash: /etc: Is a directory
  bash: exec: /etc: cannot execute: Is a directory

With Bash 5.3.0:
  $ exec /etc
  bash: /etc: Is a directory

The 'assert' function cannot directly handle compound commands.  So,
those need to be wrapped in 'bash -c "..."' [2].

[1] Bash commit b8c60bc9ca365f82
    See how exec_builtin() handles EX_NOEXEC and EISDIR from
    shell_execve() to avoid printing a duplicate error message.
    https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?id=b8c60bc9ca365f82

[2] https://github.com/bats-core/bats-assert

containers#1688
containers#1699
containers#1739
containers#1744
(backported from commit 6c98db6)
(cherry picked from commit 0090893)