[yocto] sysroot not being populated

Patrick Vacek patrick.vacek at here.com
Tue Jun 12 01:45:31 PDT 2018


On 12.06.2018 00:48, Andre McCurdy wrote:
> On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek <patrick.vacek at here.com> wrote:
>> On 08.06.2018 10:26, Khem Raj wrote:
>>> On 6/8/18 12:27 AM, Patrick Vacek wrote:
>>>> On 07.06.2018 19:06, Khem Raj wrote:
>>>>> Hi Patrick
>>>>>
>>>>> On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek
>>>>> <patrick.vacek at here.com> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I have a recipe (aktualizr-hsm-prov) that depends on another
>>>>>> (aktualizr)
>>>>>> to provide an executable and a config file. The former recipe includes
>>>>>> `DEPENDS = "aktualizr-native"`, and my do_install() for
>>>>>> aktualizr-hsm-prov has a line something like this:
>>>>>>
>>>>>> aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf
>>>>>>
>>>>>> The binary executable (aktualizr) runs, which tells me that the recipe
>>>>>> can find that. (Although to be honest, I'm not sure which version
>>>>>> it is
>>>>>> running.) However, it doesn't find the config file, and sure enough,
>>>>>> ${STAGING_DIR_NATIVE}${libdir} does not have the config file I
>>>>>> expect. I
>>>>>> can see that aktualizr-native is populating its sysroot-destdir,
>>>>>> but it
>>>>>> isn't getting copied to the sysroot for aktualizr-hsm-prov.
>>>>>>
>>>>>> I see this problem in sumo and master, although previously this logic
>>>>>> has worked just fine in morty/pyro/rocko.
>>>>>>
>>>>>> Switching to depending on aktualizr (instead of aktualizr-native) and
>>>>>> using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in
>>>>>> fact
>>>>>> makes it worse, as it can't even find the aktualizr executable in
>>>>>> that case.
>>>>>>
>>>>>> What am I doing wrong? What changed between rocko and sumo?
>>>>> is aktualizr recipe installing this .conf file when building native
>>>>> version. If not may be
>>>>> add it to do_install
>>>>>
>>>>> install -D -m 0644 <path/to/sota.conf> ${D}${libdir}/sota.conf
>>>> Hello Khem,
>>>>
>>>> I believe so. The aktualizr recipe includes the following (edited for
>>>> simplicity):
>>>>
>>>> BBCLASSEXTEND =+ "native"
>>>>
>>>> do_install_append () {
>>>>      install -m 0644 ${S}/config/sota.conf ${D}/${libdir}/sota.conf
>>>> }
>>>>
>>>> PACKAGES =+ " ${PN}-host-tools "
>>>>
>>>> FILES_${PN}-host-tools = " ${libdir}/sota.conf "
>>>>
>>> Can you check location of sota.conf in the build tree for
>>> aktualizr-native in directory called package/
>> Oddly, I do not see a package subdirectory inside the aktualizr-native
>> directory in the build tree. I do see it inside the aktualizr directory,
>> though, and it contains everything that I would expect. Is there some
>> sort of configuration of the packaging system for a native recipe that I
>> haven't done correctly?
> No, what you see is expected - there's no packaging for -native recipes.
>
> Back to the original problem, I think you should consider the
> aktualizr executable and the sota.conf file as two separate things.
> The host executable should always be provided by aktualizr-native.
> It's less clear what should provide sota.conf - it depends whether
> it's just required for building other recipes (ie like a header file)
> or whether it needs to be present in the final rootfs? If it's only
> required for building other packages, then it should be in the -dev
> package for aktualizr. If it needs to be present in the final rootfs
> then it should be in the default package for aktualizr. Either way,
> recipes which need to find sota.conf in sysroot would then depend on
> "aktualizr". Therefore recipes which need both the host executable and
> sota.conf in sysroot should depend on both aktualizr and
> aktualizr-native.

Hello Andre,

Thanks for your insight. I didn't realize that there was no packaging
for native recipes (although that makes sense now that you've explained
it). In my use case, the second recipe just needs the config file from
the first for building a package, and it looks like your advice has
solved my problem perfectly. Thank you!

Patrick


More information about the yocto mailing list