[Kartikey1306]

Twelve of the fourteen failing checks on a pull request here come from eos-simulation.yml, and none of them are about the code. They are about two sibling repositories that cannot be cloned, and a cache configured to be fatal.

embeddedos-org/eFab does not exist

$ gh api repos/embeddedos-org/eFab
{"message":"Not Found","status":"404"}

fatal: repository 'https://github.com/embeddedos-org/eFab/' not found

Two jobs check it out:

• build-kernel clones it only to run cad_pipeline.py over eFab/samples/eos_reference_board.kicad_pcb. The failed checkout kills the job — which takes simulate-qemu and integration-summary with it, and the summary is the one job that hard-fails the whole workflow. Checkout and CAD step commented out; the artifact directory the upload step expects is created empty instead.
• test-cad-pipeline exists only to exercise eFab. Its steps are commented out and replaced with one that says why.

embeddedos-org/eVera does not exist either

Same 404, from the test-middleware matrix. Removed from the matrix, and the job's display name updated to match. The other ten repositories in that matrix do exist.

cache: pip is a hard failure, not a fallback

No file in /home/runner/work/eos/eos matched to
[**/requirements.txt or **/pyproject.toml], make sure you have checked out
the target repository

setup-python errors when the repository it is caching for has neither file — true of this repository and of most of the middleware matrix. Eight matrix jobs died on this before running a single test. Dropped from both eos-simulation.yml and python-tests.yml: a dependency cache is an optimisation, and failing a job over a missing lockfile is not a trade worth making.

Two more of a defect this repo has elsewhere

Both in build-kernel, and both the same shape as things already fixed in #75:

-DBOARD=qemu_arm64	eBoot's option is EBLDR_BOARD. This set an unrelated cache variable, so the board silently defaulted to none — the ARM64 board port was never being built.
-DCMAKE_TOOLCHAIN_FILE=cmake/aarch64-linux-gnu.cmake	cmake/ holds only cppcheck.cmake, deps.cmake, ebuild_layers.cmake. The toolchain file is in toolchains/. Identical to the ARM job defect fixed in #75.

Verification

Check	Result
ctest --no-tests=error	26/26 pass
both workflow files	parse

Everything removed is commented, not deleted — restoring it is a revert once the repositories are published.

What this does not fix

Stated plainly so the remaining red is not a surprise:

• Host Tests (x86_64) (tests/test_e2e.c under -Werror) and Cross-compile ARM Cortex-M4 (missing -Ihal/include) are the other two failures. fix: restore a green build on master #71 already fixes both and I have deliberately not duplicated a maintainer's open PR.
• build-kernel will still fail at its eBoot build step until eBoot's master compiles again. That is eBoot fix(kernel): restore mutex owner priority after waiter timeout #55/feat: transition package verification from stubs to production-grade crypto #57/fix(power): reject negative peripheral IDs #58 — nothing this repository can do about it. With -DEBLDR_BOARD=qemu_arm64 now actually taking effect, that step will build more than it used to, so it may surface eBoot board-port errors that the silent none fallback was hiding.

[Kartikey1306]

Final state: 14 failing checks → 4, and every remaining one is accounted for.

Check	Cause	Fixed by
Cross-compile ARM Cortex-M4	hal/src/hal_rtos.c: eos/hal.h: No such file — missing -Ihal/include	#71
Host Tests (x86_64)	tests/test_e2e.c under -Werror (implicit eos_tick_get, misleading-indentation, sign-compare)	#71
Cross-compile ARM64 kernel	eBoot's master does not compile	eBoot #55/#57/#58
Full-stack integration summary	needs: build-kernel	as above

I have not touched the first two: #71 is a maintainer's open PR that fixes exactly those files, and duplicating it would only create a conflict.

On the ARM64 job — worth reading, because this PR changed what it does. It used to die at the eFab checkout, which hid two further failures behind it. Removing that revealed them one at a time:

1. -- Check for working C compiler: aarch64-linux-gnu-gcc - broken. Ubuntu's gcc-aarch64-linux-gnu ships the compiler but not the target C library, so CMake could not link its test binary. Fixed here by adding libc6-dev-arm64-cross.
2. With that fixed the job now reaches the real work and fails on eBoot itself:

eBoot/core/image_verify.c:63:10: error: conflicting types for 'eos_crc32';
  have 'uint32_t(uint32_t, size_t)'

That is eBoot's master breakage, not anything in this repository. This job has been failing for it all along — the eFab 404 and the missing cross-libc were simply reached first.

So this workflow is now blocked on exactly two things, both already in flight and neither of them here: #71, and eBoot's build restore.