There's an actual (and draft) PR now in case anyone else is interested in following this:https://github.com/zephyrproject-rtos/zephyr/pull/13805 Still just a demo. Off the list now.

Quick update. Non-determinism found and explained: https://github.com/zephyrproject-rtos/zephyr/pull/13973 Thanks to the reviewers for the very quick reviews. Still unclear. Mystery solved:

This seems to have gone unanswered. For my use, I've always had an "outer" makefile that invokved the cmake and ninja build on the Zephyr target (as well as mcuboot), and then used imgtool.py and

Issue resolved. From: devel@... [mailto:devel@...]On Behalf Of Ramakrishna Pallala Sent: Thursday, February 28, 2019 2:11 PM To: devel@... Subject: [Zephyr-devel] k_poll_signal_raise linker error

Hi, is anyone facing following linking error: In function

Welcome to the Zephyr Project Quarterly Newsletter

Hi Ryan Erickson, We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands: After then , we can find out device(named “2019bt”) in our phone , and we can pair it. But

Hi Billy, If I were to guess, you’re calling the configuration client APIs without waiting for the responses (passing NULL for the response parameters, like the status) and some previous call has

Hi, As a funny coincidence I experienced three (!) CI issues relevant to this discussion today: 1. Some one-line "typo" fix failed to link some C code for a totally unrelated reason. Shippable

256:bug 121:priority: medium 103:priority: low 8:priority: high 22:Coverity 21:platform: NXP 18:area: Networking 17:area: Bluetooth 14:platform: nRF 14:area: Logging 13:area: MISRA-C 12:area:

Hi, I'm new to this and struggling with BLE Mesh provisioning and need help, I am using Micro-bit (nrf51) which struggle to provision via BlueZ meshctl as they have such little memory hence i am

Oh! I somehow missed that. Thanks, that's good enough for me. -- Björn

Hi, A couple things I find confusing: - There's only the ("beautified") output but not the commands that produced them as is typical in CI, so no obvious indication of what to do to test the next

Status is actually available as a comment in the PR. We are planning at some point to use the Checks API from GH which would make things more clear. The scripts now provide the output so you do not

The actual output is always available in a comment posted by zephyrbot in the same PR. The comment is updated for every run. Is this what you are looking for? Anas From:<devel@...> on behalf of

Hi Björn, I asked this question on Slack some time back and Anas answered it's not possible (yet?) for various reasons, one of them related to github accounts and security. Fortunately

Hi Aaron, This is indeed the expected way to do it. Don't forget to also add "arduino_i2c" in boards' yaml files. Cheers Erwan

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists? -- Björn

Hi, Recently we enabled a new CI check that verifies if newly added files are covered in the CODEOWNERS file. For more information about the CODEOWNERS file please check

Hi, When I try to compile "samples\shields\x_nucleo_iks01a1\" for my Nordic dev. kits(pca10040 and pca10056), occurred this error: I noticed that the Arduino interface, like default i2c and so on, not