Done. Sorry about that. I only looked through my inbox. And our scripts don't pick things up from the stable-queue. In any case they will be picked up once the stable kernels including them are

Hi! Could you push your changes to cip-kernel-sec? These are queued for 5.10.35 and 4.19, I believe they may be related. v |8373088d4 b9b34d o: 5.10| bpf: Fix masking negation logic upon negative

Hi everyone, Two new CVEs this week: - CVE-2021-31829 [bpf: stack pointer protection from speculative arithmetic] - fixed Fixes just landed in mainline as part of the merge window. Fixes

And for that, it needs u-boot-config as package, not u-boot-<machine>. Build order is meaningless if you are not consuming the output - which I assume is the case via fw_env.config from u-boot-config

SWUpdate does not depends on the u-boot-binary. SWUpdate needs 'fw_env.config'(u-boot-config) to interact with the u-boot environment. As libubootenv does not request or provide 'fw_env.config' the

But does SWUpdate really depends on the U-Boot binary that is going to be put on the device - or rather on u-boot-config? This looks fishy. Jan -- Siemens AG, T RDA IOT Corporate Competence Center

SWUPDATE_U_BOOT should be the name of the u-boot package. In case the layer (e.g. isar-cip-core) supplies the u-boot binary, `SWUPDATE_U_BOOT` should be defined as `u-boot-${MACHINE}`. Debian

Thanks, applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux

Still leaves me and probably other users clueless what SWUPDATE_U_BOOT should be. Simply "u-boot-${MACHINE}"? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux

...but the in-tree handler does. How much effort is needed to port that feature into the new handler? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux

Do you want to mention qemu-system-x86_64 --version should be 5.2.0 or higher as default Debian buster has older version of qemu and this step fails with older version. Also these steps can't be

From: Quirin Gylstorff <quirin.gylstorff@...> The new swupdate round robin handler is available under[1]. Add the Option `SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO` to use the handler directly

From: Quirin Gylstorff <quirin.gylstorff@...> - Add code block for key insertion for better visibility - Correct the template for user-generated keys - Add information where to store the

From: Quirin Gylstorff <quirin.gylstorff@...> The variables U_BOOT and BOOTLOADER are only used for swupdate. Add the prefix SWUPDATE to indicate the intended usage. Signed-off-by: Quirin

Does not fully parse to me. Do you mean "The variables U_BOOT and BOOTLOADER are only used for swupdate. Add the prefix SWUPDATE to indicate the intended usage." ? This doesn't make sense. There is

These two look spurious. Unneded new-line? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux

From: Quirin Gylstorff <quirin.gylstorff@...> - Add code block for key insertion for better visibility - Correct the template for user-generated keys - Add information where to store the

From: Quirin Gylstorff <quirin.gylstorff@...> The variables U_BOOT and BOOTLOADER are only used for swupdate mark add the prefix SWUPDATE to indicate the intended usage. Signed-off-by:

It looks to me we have some regressions in master (which does deployment), caused by these commits. Could you have a look

Hi everyone, This was a quiet week. Only one new issue: - CVE-2021-3501 [x86: KVM: VMX: data race condition] - fixed Nothing else to report on. Regards ChenYu