> Log file in: > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/ > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/ log.do_rootfs.31340 Could you, please, attach a

That pretty much clarifies the whole thing, thanks for taking the time for this! -- Yann Dirson <yann@...> Blade / Shadow -- http://shadow.tech

<yann.dirson@...> wrote: The best of anything is a matter of opinion. I heavily use git-rebase and sure, you could use it to do something similar here. But the result is the same. There's

Thanks for those clarifications! Some additional questions below I'd think (and I take your further remarks about workflow as confirming this), that when upgrading the kernel the best tool would be

I agree it's a bit annoying that some projects have chosen to rename the existing branches instead of just adopting "main" to be the default branch only for new projects (as the defaults changed e.g.

Iirc there has been the same discussion already last year or the year before... and the agreement was to leave it as it is. IMHO most of the used projects still go with master instead of main, so a

At least some of this is mentioned in the advanced section of the kernel-dev manual, but I can summarize/reword things here, and I'm also doing a presentation related to this in the Yocto summit

I got a fetcher failure on go-systemd today, which puzzled me. That recipe has not changed in ages, and the SRCPV hash is clearly visible in the repository. After looking at it closer, it seems that

Facing following issue : ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot, then please place them into

I am currently working on a kmeta BSP for the rockchip-based NanoPI M4 [1], and I'm wondering how I should be providing kernel patches, as just add ing "patch" directives in the .scc does not get them

Hello All, This is the full report for yocto-3.2.4.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high

<robert.joslyn@...> wrote: Given what I have seen so far, I am wondering if that is the right place to start. To summarize: There appears to be general agreement that the idea is a

User need to specify board value to ZEPHYR_BOARD in local.conf ZEPHYR_BOARD = "minnowboard" By default it set to MinnowBoard Max 'minnowboard' Currently 32-bit supported boards: * up_squared_32 *

User need to specify board value to ZEPHYR_BOARD in local.conf ZEPHYR_BOARD = "ehl_crb" By default it set to Elkhart Lake CRB 'ehl_crb' Currently 64-bit supported boards: * up_squared *

(1) zephyr-kernel-src: fix efi generation failure for x86 boards With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode). To achieve this, an python tool[1] has

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode). To achieve this, an python tool[1] has been added to convert zephyr ELF file into an EFI appliable. But currently

Thanks for the suggestion, but they are using the C++ API as well. I already created a recipe for the C++ API of dlib and it is working, the only thing needed is compitling the Python API.

did you look into http://layers.openembedded.org/layerindex/recipe/135534/

Hi All, Did anyone manage to create a recipe for python dlib from the official site https://github.com/davisking/dlib ? They provide C++ and Python API, (CMakeLists + setup.py). All recipes found for

Hi Nicolas, Thank you for the advice, that would work for files outside the npm packages! Hopefully there's a way to improve npm install speed too, I was hoping there was a way to just run npm install