Murdock results

✔️ PASSED

1924b06 sys/psa_crypto: use SHA256 CSPRNG as default

Artifacts

I am confused about the history of murdock actions here. The auto merge got aborted due to a failing build but the latest result from murdock succeeded? As far as I can tell, nobody initiated a re-run...so the result should be the same? Maybe I should go home for today...

The auto merge got aborted due to a failing build but the latest result from murdock succeeded?

So we have a two-stage merge: first, the PR needs to succeed. then github adds the PR to a merge queue, which also has to succeed. if you click on the button "view details" next to the last "github-merge-queue removed this pull request ..." message, on the bottom there's alink to the failed build (https://ci.riot-os.org/details/a8022e73e76440269b7e481861624473).

@Einhornhool I think you need to black-list more boards :/
Maybe have a look at ./dist/tools/insufficient_memory/create_makefile.ci.sh

In theory, the re-triggered Murdock build should have been a full build with no fast fail, i.e., show all board where builds are failing. It should™ thus be sufficient to disable nucleo-l011k4 for tests/sys/psa_crypto_hashes.

Thanks for the update! How did you come up with the boards you've added to the files? The last Murdock build did succeed for tests/sys/psa_crypto_se_{ecdsa,mac} on arduino-leonardo:gnu: https://ci.riot-os.org/details/7bf60f6406c5401cbfe0917cc35efa8f/builds/tests:sys:psa_crypto_se_ecdsa and https://ci.riot-os.org/details/7bf60f6406c5401cbfe0917cc35efa8f/builds/tests:sys:psa_crypto_se_mac

looks at Release'o'clock Ping @Einhornhool

I ran 'create_makefile.ci.sh' on all psa test directories.
I just ran it again to check and it turns out the same.
So looks like we can't trust that script. How should I proceed? I'd rather not check each test for each board manually.

I ran 'create_makefile.ci.sh' on all psa test directories. I just ran it again to check and it turns out the same. So looks like we can't trust that script.

Hum strange, maybe a mismatch between the compiler versions used on the CI and on your system. The script should automatically build in Docker, so maybe your local docker container is outdated? Maybe try docker images to see how old your local copy is and docker image pull riot/riotbuild for updating it. Related to #20472.

How should I proceed? I'd rather not check each test for each board manually.

Given that the CI performed a full build (i.e. all that would also be built during merge) and only one board was reported as failing, I would suggest to fixup your last commit to only exclude nucleo-l011k4 for tests/sys/psa_crypto_hashes.

I ran 'create_makefile.ci.sh' on all psa test directories. I just ran it again to check and it turns out the same. So looks like we can't trust that script.

Hum strange, maybe a mismatch between the compiler versions used on the CI and on your system. The script should automatically build in Docker, so maybe your local docker container is outdated? Maybe try docker images to see how old your local copy is and docker image pull riot/riotbuild for updating it. Related to #20472.

How should I proceed? I'd rather not check each test for each board manually.

Given that the CI performed a full build (i.e. all that would also be built during merge) and only one board was reported as failing, I would suggest to fixup your last commit to only exclude nucleo-l011k4 for tests/sys/psa_crypto_hashes.

I almost never build in docker, so yeah, could be a mismatch. I will update tomorrow morning, when I'm at HAW.

Sorry for the 35 force pushes. Should be fine now.

Great thanks! Did docker pull do the trick?

Feel free to squash already.

Great thanks! Did docker pull do the trick?

Unfortunately not, I am trusting your word right now^^

So for the record, I just checked the output of the arduino-leonardo:gnu build for tests/sys/psa_crypto_se_ecdsa again and it contains make: 'test-input-hash' is up to date., thereby actually skipping the build. That means we probably have two actually failing builds on master.

Given that the symlinks in those tests do not work well with the CI logic, we should consider changing them to actual copies. Or maybe @MrKevinWeiss has another idea?

Or maybe @MrKevinWeiss has another idea?

Hmmm, I didn't consider the symlink thing... Maybe something like what we did with the ieee802.15.4 radio tests. For example: tests/drivers/cc2420