Re: [yocto] sysroot not being populated
On 12.06.2018 00:48, Andre McCurdy wrote: > On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek 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: >>>>> On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek >>>>> wrote: >>>>>> 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. >>>>>> >>>>>> What am I doing wrong? What changed between rocko and sumo? >>> 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. Actually, after some further research, it appears that my problem is not entirely resolved. The explanation of packaging and native vs. target dependencies all makes sense to me and usually works. However, this is not the case for one specific condition which happens to be part of my test suite. One of my tests is to change the MACHINE in my local.conf, add some additional layers, change some other variables, and then bitbake. Then I undo that and bitbake again. For the most part, that works fine. In rocko and before, it worked consistently. But it seems like on sumo and master, when I do the test by changing the MACHINE and the layers, it somehow clears out everything in my recipe's work directory, despite that that recipe is not used by that test. In fact, it removes every single file in tmp/work/core2-64-poky-linux (but leaves most of the directories). When I switch back to how it was before and bitbake, most of the files get recreated or re-copied, but not all. I have to explicitly run `bitbake -c cleanall aktualizr aktualizr-hsm-prov` to get things to work again. (Perhaps cleanall isn't necessary, but some form of cleaning is, and it has to be both recipes.) Can someone help explain why I am seeing this behavior? I don't understand why the files get erased, why they don't get repopulated, and why this was different back in rocko. Thanks! Patrick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot not being populated
On 12.06.2018 00:48, Andre McCurdy wrote: > On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek 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 >>>>> 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 ${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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot not being populated
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 >>> 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 ${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? For the record, here is the actual recipe: https://github.com/advancedtelematic/meta-updater/blob/master/recipes-sota/aktualizr/aktualizr_git.bb -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot not being populated
On 07.06.2018 19:06, Khem Raj wrote: > Hi Patrick > > On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek 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 ${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 " Thanks, Patrick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sysroot not being populated
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? Thanks, Patrick Vacek HERE Technologies -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Boost + Yocto
On 06.10.2017 15:36, Khem Raj wrote: > On Fri, Oct 6, 2017 at 5:05 AM, Patrick Vacek > <patr...@advancedtelematic.com> wrote: >> Hello, >> >> I'm trying to understand how Yocto figures out which Boost libraries to >> install in an image. I've been studying the Boost recipes and it looks >> like RRECOMMENDS is used to specify all of the libraries, but yet my >> image only gets a subset of them. It's the subset that I typically need, >> so it's fine, but I want to understand how the process works. >> >> There's an additional tricky detail that got me looking into this. When >> I bitbake a recipe I've written which just lists "boost" in DEPENDS, >> running ldd the compiled executable does not appear to depend on a >> couple of the boost libraries that I'd specified in CMake (although it >> does depend on several others). Only the libraries that are specifically >> mentioned with ldd are installed in the image. However, if I manually >> cross-compile the same code via the native-sdk, ldd indicates that all >> the expected libraries are dependencies. As such, that executable will >> not be able to run on my device until I install the missing libraries. >> Oddly, those libraries are built with bitbake, but not installed! How >> does bitbake manage to remove some of these dependencies? > > it could be thst applications dependency detection mechanism is behaving > differently and presenting different set to linker. > > Secondly its possible that linker options in play are different e.g. > --as-needed and --copy-dt-needed-entries might be in play > It turns out that the troublesome boost libraries are not actually used after all! I haven't yet deduced if the sort of linker flags you mentioned are being used, but that may be at the root of the issue. What's now confusing me is why, after removing all references to the extraneous libraries, CMake still finds them and the cross-compiled binary still links against them. The only thought I've had so far is that they are a transitive dependency, although that seems unlikely. However, that's probably a matter to look into with CMake, not Yocto... Thanks! -- Patrick Vacek ATS Advanced Telematic Systems GmbH Kantstraße 162, 10623 Berlin HRB 151501 B, Amtsgericht Charlottenburg Vertreten durch die Geschäftsführer Dirk Pöschl, Armin G. Schmidt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Boost + Yocto
Hello, I'm trying to understand how Yocto figures out which Boost libraries to install in an image. I've been studying the Boost recipes and it looks like RRECOMMENDS is used to specify all of the libraries, but yet my image only gets a subset of them. It's the subset that I typically need, so it's fine, but I want to understand how the process works. There's an additional tricky detail that got me looking into this. When I bitbake a recipe I've written which just lists "boost" in DEPENDS, running ldd the compiled executable does not appear to depend on a couple of the boost libraries that I'd specified in CMake (although it does depend on several others). Only the libraries that are specifically mentioned with ldd are installed in the image. However, if I manually cross-compile the same code via the native-sdk, ldd indicates that all the expected libraries are dependencies. As such, that executable will not be able to run on my device until I install the missing libraries. Oddly, those libraries are built with bitbake, but not installed! How does bitbake manage to remove some of these dependencies? Thanks. -- Patrick Vacek ATS Advanced Telematic Systems GmbH Kantstraße 162, 10623 Berlin HRB 151501 B, Amtsgericht Charlottenburg Vertreten durch die Geschäftsführer Dirk Pöschl, Armin G. Schmidt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-security / meta-tpm functionality
Hello, The meta-tpm layer inside the meta-security layer looks like exactly what I want in order to get TPM 2.0 support on my devices. I'm currently using qemu and trying to create a swtpm device on my host and pass it through to the device. Despite my best attempts, I have not yet been able to get a TPM device to be recognized in qemu. To use the meta-tpm layer, is there anything I should be doing beyond adding meta-tpm to my bblayers.conf and adding packagegroup-security-tpm2 to IMAGE_INSTALL_append? If not, is there a way to debug what might be going wrong in this process? Thank you, Patrick -- Patrick Vacek ATS Advanced Telematic Systems GmbH Kantstraße 162, 10623 Berlin HRB 151501 B, Amtsgericht Charlottenburg Vertreten durch die Geschäftsführer Dirk Pöschl, Armin G. Schmidt signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto