At a quick glance this seems to be an m2r bug: https://github.com/sphinx-doc/sphinx/issues/8705. m2r seems to be abandoned, switching to m2r2 might be a workaround, as that seems to have a fix merged.
For now the best might be to stick to the documented package versions. I am wondering if the requirements file should be more strict on Spninx version.

Fix is merged to integration and master. (https://git.trustedfirmware.org/TS/trusted-services.git/commit/?h=refs/heads/main&id=840696b9ac1ba6aa9ccd024ca9dc3b4be12bf837)

Fix is on review here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9379

Blocked by https://developer.trustedfirmware.org/T901

After the initial investigation I found two possible approaches to the task:

Fix merged as daf2efdaa78.

For more context see https://review.trustedfirmware.org/c/TS/trusted-services/+/8310/comment/5e4373b3_998e475f/

Fix is available here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9046

This was introduced by change: d80f856adf59.
That change makes deployments targeting the "arm-linux" environment accept non Linux specific GCC binaries like "aarch64-none-elf-gcc". Since these GCC builds are not bundled with a standard library built with Linux support, compilation errors arise due to missing Linux kernel headers.

I think tags in the subject of the commit message are problematic in general. Since commits are expected to capture "logical unit of change", the granularity of tags and commit scope often mismatches. While not mandated in the "Contributors Guide" sections, some commits indeed use tags already (i.e. libc, spmd, docs, etc..). What if a "logical unit of change" affects multiple components (i.e. a fix affects both libc and spmd)?

This page lists cmake versions available in different Linux distributions.
https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros

In T228#6978, @CJKay wrote:

Snapcraft distributes builds for the latest stable versions of CMake: https://snapcraft.io/cmake

Perhaps consider recommended it be installed through that? On Ubuntu it is as simple as sudo snap install cmake --classic.

Fix has been merged.

I think we shall discuss the issue internally with the team first.

What's wrong with virtualenv? How does it hurt the user experience?

Using pip instead of the Linux distributions package manager is considered bad practice because:

• may end up having two version of a package installed which can trigger problems. (Packages installed by pip are not visible to apt and vice-versa.)
• some pip packages have binary components. Some versions of these components may be not compatible to other binaries installed on the machine. This means only some versions of such pip packages are compatible with a specific distro.

Fix merged.

Patch-set with the fix: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1884/

Fix was merged.

Can you please create a pull request with the fix?

Can you please double check you modification? Line 84-88 should be:

if(_SPHINX_VERSION)
        if(_SPHINX_VERSION MATCHES ".*sphinx-build[^0-9.]*([0-9.]+).*")
		string(REGEX REPLACE ".*sphinx-build ([0-9.]+).*" "\\1" SPHINX_VERSION "${_SPHINX_VERSION}")
	endif()
endif()

Note: there was a patch pushed to work around the issue. See commit: https://git.trustedfirmware.org/trusted-firmware-m.git/commit/BuildMbedtls.cmake?id=a0f505c659e2af2ffa278d215045add711f7f2d8
The workaround only helps when the build is run from git-bash (or Msys/Msys2) or cygwin but will fail when building from cmd.exe (ln command not available).

Process documentation has been merged (https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=5c87323db941c3470eb4d4998981ced8b33cf84c) and process is in place.

Newer versions of sphinx seem to print the version as:

$ sphinx-build.exe --version
sphinx-build 2.1.2

I think the ) character is making the reqexp on this line https://git.trustedfirmware.org/trusted-firmware-m.git/tree/cmake/FindSphinx.cmake#n85 fail to match.
Can you please check if changing line 85 like this helps?: if(_SPHINX_VERSION MATCHES ".*sphinx-build[^0-9.]*([0-9.]+).*")

The same issue seems to affect mbedcrypto and this commit has the fix: https://github.com/ARMmbed/mbed-crypto/pull/118/commits/7346b312e12a54d77608fc6bb8aa3c55cf046d90
In TF-M build instructions (https://git.trustedfirmware.org/trusted-firmware-m.git/about/docs/user_guides/tfm_build_instruction.rst ) the following dependencies are defined:

1. mbedtls v2.7.9
2. mbedcrypto v1.1.0

@jainvikas8: Thank you for volunteering! Please create a patch to fix the documentation.

That's a valid point, the documentation needs to be fixed.

Based on my investigations this is not a bug and no fix is needed.

Summary:

It is wrong to set PLANTUML_JAR_PATH as export PLANTUML_JAR_PATH="~/plantuml/plantuml.jar" and instead export PLANTUML_JAR_PATH=~/plantuml/plantuml.jar shall be used (Note: quotation marks removed).

For the design proposal published to the TSC please refer to the archive of the TSC mailing-list: https://lists.trustedfirmware.org/mailman/listinfo/tsc .

Fix was merged.

Fix was merged.

It seems the fix has been merged to mbedtls development branch. (See it https://github.com/ARMmbed/mbedtls/commit/7346b312e12a54d77608fc6bb8aa3c55cf046d90?diff=unified).
We may be able to update supported mbedtls version after the next mdbedtls release.

I tested the behavior and found the following:

• if GNUARM_PATH is set to point to the /bin directory of the GNUARM install tree, then the compiler is found ok. This behavior is not matching the documentation in FindGnuArm.cmake.
• if GNUARM_PATH is set as mentioned above, but there is another version available on the PATH, then the one on the PATH gets used.

A related change seems to be: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/862/

Turned to be a documentation update task. Fixed in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/661/ .

No. T95 needs deeper investigation to check what cmake version the fix supports and if all aspects are addressed. Response files not only affect the linker but the archiver too.
There was an important bugfix for response file handling merged into cmake 3.9 so we might need to drop support for anything below 3.10.

The response file problem is another ticket. See https://developer.trustedfirmware.org/T95

and what error do you get?