Issue with non-normalized paths in BBLAYERS during populate_sdk_ext This one-liner applies to Yocto Jethro and fixes a failure of populate_sdk_ext when copying bitbake and the layers. This failure occ

Hi Oliver, It is not not clear to me what the root cause of this could be... Is this directory shared by several pacakages by any chance? One trick I am using to figure out in which recipe/package a f

Hi Charmi, I am not entirely sure of what is going on in your case, but one possible issue that could occur is that you are behind a network proxy inside a corporate network. When using the GIT protoc

Hi Christian, In pyro the creation of users and group (using the useradd class) is done during the package pre-installation. So my best guess is that you could move the owner/group change in the packa

[ all: Let me share the replay I made in private to Ajit. ] Hi Ajith, Unfortunately because you do not provide much information about the "some error" you are seeing there is not much that can be done

Hi there, Questions based on experience: * Doesn't your network require you to use a network proxy to access URLs that are external to your network? If so: * Do you have the right environment variable

Hi JH, As you are not providing enough details in your request we have to guess the nature of the issue you are seeing. I will just point out a few things that could help in your situation. If this is

Hi Zoran, The issue seems to be that the executable /usr/bin/cannelloni has a reference to a shared library (libcannelloni-common.so.0) for which the Yocto build system is not able to determine automa

Hi Zoran, You are almost there! I can feel it... :-) The issue I see is that the following files have been build but NOTinstalled: * libcannelloni-common.so.0 * libcannelloni-common.so.0.0.1 If you ma

Hi Zoran, I just saw your reply now. I think that you might want to remove the INHIBIT_SYSROOT_STRIP and other INHIBIT_* options from your recipe. For reference a message from Khem warning that this o

Ciao Mauro, My best guess is that you should do the following: 1. Create a linux-imx_%.bbappend recipe in your layer (assuming you have one). 2. Add a do_install_append function which overrides $D/boo

Hi Mauro, Glad this helps. Another option I thought of after replying was to change which dtb is loaded by u-boot at boot time. This would involve changes to u-boot-imx. Kind regards, Laurent.

Hi all, I would second what Nicolas pointed out: * on the server side you want to make sure that you extract the rootfs tar file as user root. Kind Regards, Laurent.

Hi Emily, To find the solution to your issue in a rational and deterministic way we need to start from the error message. What I understand is that while build recipe "opc-ua-server-gfex" you get an e

Hi again Emily, You have put your finger on the core issue there. The name of the boost python library which is linked in your "opc-ua-server-gfex" recipe is "boost_python-mt" where it seems that it s

Also as Quentin suggested it might be needed to remove the "-mt" suffix, but I see it in the do_install() method of the "boost" recipe for revision 1.64. Kind regards, Laurent. On Tue, Mar 17, 2020 at

Hi Mauro, all, During the creation of the rootfs of your image yocto will try to install both packages, and should complain loudly because the same file is provided by two packages. There are a few wa

Hi Mauro, From my experience there should be an error reported during the image creation as long as the two *packages* that contain a file with the same name are BOTH installed in the root filesystem.

I would guess so. Here is a way to figure out all the packages in which your file is delivered (small trick that has proven quite useful for me to figure out which recipe/package provides a specific f

Hehe, who needs a new command when you have already have "echo" :-)