Re: [yocto] eSDK install script failure
On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote: > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton < > paul.eggle...@linux.intel.com> wrote: > > Right, so the next step would be looking for the hash for > > python-native.do_populate_sysroot in conf/locked_sigs.inc within the > > failed SDK install directory and then looking for that in both the sstate- > > cache directory within the failed SDK and then in the sstate-cache > > directory of the build that built it. I suspect it may not be there, but > > let me know what you find. > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor > sstate-cache do include any python-native signature or object... Only > python3-native stuff is there. Weird! As said, SDKs from the same build > directory, used to work since a few weeks ago. May any recent change in > poky master have caused this while periodically upgrading without > regenerating the sstate-cache? No, I can't see any added references to python-native anywhere in the last few weeks. If you do bitbake -c clean python-native and then rebuild the SDK does the issue go away? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Path to current bb-file or layer
On Thu, 2017-09-21 at 22:00 +0200, Svein Seldal wrote: > To determine a image version, I'd like to read a VERSION file which > is > located in the root of the layer. (Per our development procedure.) > I'd > like to read it from a bbclass file. However I seem to be unable to > find > any methods or variables to find a useful path to either the current > bb-file or the root of the layer. > > The only way I have found is to parse through BBLAYERS and guess at > what > my own layer is of those, and then use the found to access the file. > But > this feels very wacky. > > Is there a reason why bitbake doesn't have a variable path reference > to the current file? You mean like ${FILE} ? $ bitbake bash -e | grep ^FILE= FILE="/media/build1/poky/meta/recipes-extended/bash/bash_4.4.bb" Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Path to current bb-file or layer
On Thu, Sep 21, 2017 at 1:00 PM, Svein Seldalwrote: > > To determine a image version, I'd like to read a VERSION file which is > located in the root of the layer. (Per our development procedure.) I'd like > to read it from a bbclass file. However I seem to be unable to find any > methods or variables to find a useful path to either the current bb-file or > the root of the layer. > > The only way I have found is to parse through BBLAYERS and guess at what my > own layer is of those, and then use the found to access the file. But this > feels very wacky. > > Is there a reason why bitbake doesn't have a variable path reference to the > current file? Doesn't FILE give you exactly that? http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#var-FILE You can derive from it using python, e.g. MYFILE := "${@os.path.abspath(os.path.dirname(d.getVar('FILE')) + '/../../myfile.txt')}" If you want to construct paths relative to the top level meta layers then COREBASE might be useful too. > > Best regards, > Svein > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eSDK install script failure
On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > On Friday, 22 September 2017 1:06:19 AM NZST Andrea Galbusera wrote: > > On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera> wrote: > > > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton < > > > paul.eggle...@linux.intel.com> wrote: > > >> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera > wrote: > > >> > Seeing the errors below while installing an eSDK. This is a > routinely > > >> > generated VM that installs the eSDK from installation script. The > errors > > >> > appeared with the latest iteration of the eSDK script, which is > > >> generated > > >> > with almost up-to-date revisions from master. Of course I have extra > > >> layers > > >> > in the mix, but none of them apparently had relevant changed since > last > > >> > (working) iteration: mostly synching to master branches happened. > Can > > >> > anyone help suggesting how to investigate this further? What do > those > > >> > unexpected task mean? I'm blocked on releasing this SDK to > developers > > >> and > > >> > clues from expert would be very appreciated... > > >> > > > >> > ==> default: Checking sstate mirror object availability... > > >> > ==> default: done. > > >> > ==> default: ERROR: Task python-native.do_fetch attempted to execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot > > >> attempted > > >> > to execute unexpectedly > > >> > ==> default: ERROR: Task python-native.do_unpack attempted to > execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_patch attempted to execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_populate_lic attempted to > > >> execute > > >> > unexpectedly and should have been setscened > > >> > ==> default: ERROR: Task python-native.do_configure attempted to > execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_compile attempted to > execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_install attempted to > execute > > >> > unexpectedly > > >> > ==> default: ERROR: Task python-native.do_populate_sysroot > attempted to > > >> > execute unexpectedly and should have been setscened > > >> > ==> default: ERROR: SDK preparation failed: error log written to > > >> > /home/vagrant/poky_sdk/preparing_build_system.log > > >> > > > >> > > >> Basically this means that these tasks tried to execute where really > the > > >> results should have been able to be restored from sstate. > > >> > > >> The cause of this type of error is one of three things: > > >> > > >> 1) The sstate archive corresponding to a task wasn't able to be > fetched > > >> from > > >> the server (for a minimal eSDK) or wasn't present in the installer > (for a > > >> full > > >> eSDK - less likely as we basically do a trial run as part of building > the > > >> eSDK > > >> in the first place) > > >> > > >> 2) The signature was somehow different to what it should have been. > > >> (Locked > > >> signatures are supposed to guard against this.) > > >> > > >> 3) A task that wasn't expected to execute did execute and thus the > sstate > > >> wasn't available. > > >> > > >> Given that this was python-native which I would expect would be a > normal > > >> part > > >> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. > what > > >> is > > >> SDK_EXT_TYPE set to)? > > >> > > > > > > That was a "full" eSDK. I noticed that the "same" eSDK installer from > > > another build host was not affected and I'm trying to rebuild on the > > > original one with even more recent revision and see if it still > happens or > > > not. Failure with the first one was repeatable, hence I suspect an > issue at > > > sdk population stage, not during installation. > > > > Nuking tmp/ and rebuilding with the same revisions of the successful > build > > host didn't fix the issue... Same error on installation of the generated > > eSDK. Would you suggest any other investigation step? On my todo list I'd > > put using the sstate from that other build host than nuking local > > sstate-cache/ and going to take a very long coffee break. :-( > > Right, so the next step would be looking for the hash for > python-native.do_populate_sysroot in conf/locked_sigs.inc within the > failed > SDK install directory and then looking for that in both the sstate-cache > directory within the failed SDK and then in the sstate-cache directory of > the build that built it. I suspect it may not be there, but let me know > what > you find. > Good catch! In the failing SDK neither conf/locked_sigs.inc nor sstate-cache do include any python-native signature or object... Only python3-native stuff is there. Weird! As said, SDKs from the same build directory, used to work since a few weeks ago. May any recent change in poky master have caused this while periodically upgrading without regenerating the sstate-cache? --
Re: [yocto] eSDK install script failure
On Friday, 22 September 2017 1:06:19 AM NZST Andrea Galbusera wrote: > On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbuserawrote: > > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton < > > paul.eggle...@linux.intel.com> wrote: > >> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera wrote: > >> > Seeing the errors below while installing an eSDK. This is a routinely > >> > generated VM that installs the eSDK from installation script. The errors > >> > appeared with the latest iteration of the eSDK script, which is > >> generated > >> > with almost up-to-date revisions from master. Of course I have extra > >> layers > >> > in the mix, but none of them apparently had relevant changed since last > >> > (working) iteration: mostly synching to master branches happened. Can > >> > anyone help suggesting how to investigate this further? What do those > >> > unexpected task mean? I'm blocked on releasing this SDK to developers > >> and > >> > clues from expert would be very appreciated... > >> > > >> > ==> default: Checking sstate mirror object availability... > >> > ==> default: done. > >> > ==> default: ERROR: Task python-native.do_fetch attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot > >> attempted > >> > to execute unexpectedly > >> > ==> default: ERROR: Task python-native.do_unpack attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_patch attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_populate_lic attempted to > >> execute > >> > unexpectedly and should have been setscened > >> > ==> default: ERROR: Task python-native.do_configure attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_compile attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_install attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_populate_sysroot attempted to > >> > execute unexpectedly and should have been setscened > >> > ==> default: ERROR: SDK preparation failed: error log written to > >> > /home/vagrant/poky_sdk/preparing_build_system.log > >> > > >> > >> Basically this means that these tasks tried to execute where really the > >> results should have been able to be restored from sstate. > >> > >> The cause of this type of error is one of three things: > >> > >> 1) The sstate archive corresponding to a task wasn't able to be fetched > >> from > >> the server (for a minimal eSDK) or wasn't present in the installer (for a > >> full > >> eSDK - less likely as we basically do a trial run as part of building the > >> eSDK > >> in the first place) > >> > >> 2) The signature was somehow different to what it should have been. > >> (Locked > >> signatures are supposed to guard against this.) > >> > >> 3) A task that wasn't expected to execute did execute and thus the sstate > >> wasn't available. > >> > >> Given that this was python-native which I would expect would be a normal > >> part > >> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. what > >> is > >> SDK_EXT_TYPE set to)? > >> > > > > That was a "full" eSDK. I noticed that the "same" eSDK installer from > > another build host was not affected and I'm trying to rebuild on the > > original one with even more recent revision and see if it still happens or > > not. Failure with the first one was repeatable, hence I suspect an issue at > > sdk population stage, not during installation. > > Nuking tmp/ and rebuilding with the same revisions of the successful build > host didn't fix the issue... Same error on installation of the generated > eSDK. Would you suggest any other investigation step? On my todo list I'd > put using the sstate from that other build host than nuking local > sstate-cache/ and going to take a very long coffee break. :-( Right, so the next step would be looking for the hash for python-native.do_populate_sysroot in conf/locked_sigs.inc within the failed SDK install directory and then looking for that in both the sstate-cache directory within the failed SDK and then in the sstate-cache directory of the build that built it. I suspect it may not be there, but let me know what you find. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "(-)"??
On Thu, 2017-09-21 at 12:43 +0200, Martin Jansa wrote: > null and nothing can also be matched in MACHINE names, so to make sure > people should use: > > COMPATIBLE_MACHINE = "(^$)" > [trimmed] > > > > > > COMAPTIBLE_MACHINE uses regexp syntax > > > > Which actually makes that a pretty weird COMPATIBLE_MACHINE, > > > > especially if it is intended for blacklisting. Yes, I think seeking consensus on the best practice here would make a lot of sense. Clearly people copy each other, but there are still *so* many variants of this out there! Very often machine overrides are used because there's no real sane way of adding a specific machine, to the value that is there already: This is actually written in many places: COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}" So if I see it correctly, that's going to apply if and only if MACHINE is core2-32-intel-common and if so, then the ${MACHINE} regexp will also expand to "core2-32-intel-common", and then finally bitbake will match that (as a regexp) against the same $MACHINE name again to see if it yields true (which it always will)... I mean it's a little crazy isn't it? Luckily special characters are usually not used in the machine names, or the above might have unintended consequences too. Sometimes the pattern matching is good but most of the time we just to say basically: IS_COMPATIBLE(mymachinename)! There are also these variations in various layers: COMPATIBLE_MACHINE_genericx86 = "genericx86" and this one seems popular: # (Always match my string, but using MACHINE override): COMPATIBLE_MACHINE_x86-64 = "(.*)" That's a bit more straight forward, but not much. If it's a true regexp match as Martin indicates with the ^$ example to exclude non-empty string - presumably then, this syntax is yet another working alternative because an empty regexp matches, right? COMPATIBLE_MACHINE_x86-64 = "" Being able to append your new machine in a sane way would make sense, but with regexps it seems the reasonable syntax would then be: COMPATIBLE_MACHINE_append = "|core2-32-intel-common" Is that right? And is that syntax also being used? I'm not sure if that will result in a valid regexp 100% of the time, but presumably it might work. And what is this? I'm not sure I understand this one... COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}" There is legacy and compatibility to consider I understand, but just looking at it with fresh eyes, this thing seems to beg for a more easy to understand mechanism. I wonder if what one might like is a kind of array (of regexps), so you can add new machines or machine-patterns to it in a sane manner. Admittedly it makes it harder to reset/subtract from the value if you want to remove some previous setting. Perhaps in a new design I'd consider two mechanisms, one for exact matches, which could act as a list of words - many other bitbake variables do - and one for patterns: COMPATIBLE_MACHINE_EXACT = "first-machine second-machine" COMPATIBLE_MACHINE_EXACT += " third-machine" COMPATIBLE_MACHINE_PATTERN = "(.*x86.*)" Just my 2c, take it for what it's worth. - Gunnar -- Gunnar AnderssonDevelopment Lead GENIVI Alliance -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Path to current bb-file or layer
To determine a image version, I'd like to read a VERSION file which is located in the root of the layer. (Per our development procedure.) I'd like to read it from a bbclass file. However I seem to be unable to find any methods or variables to find a useful path to either the current bb-file or the root of the layer. The only way I have found is to parse through BBLAYERS and guess at what my own layer is of those, and then use the found to access the file. But this feels very wacky. Is there a reason why bitbake doesn't have a variable path reference to the current file? Best regards, Svein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Backwards compatibility checking sstate-cache
On Fri, 2017-06-30 at 09:48 +, Michael Ho wrote: > Hi, at BMW Car IT we are working on an experimental feature to > improve sstate cache hits and we are looking for comments on the > approach who might have some insights to the problem and seeing if > anyone is interested in the feature for mainline. Sorry I didn't see this before now but it was brought to my attention. I have given this problem quite some thought off and on. I do worry that the interface you propose is complex and requires changes throughout the metadata and those changes impose "policy". One of our strengths is that we're managed to keep "policy" out of the metadata. In this context by policy, I mean when a recipe is equivalent and when it is not. I do have a counter-proposal of how we could solve this in a less invasive way. This isn't implemented but wouldn't in theory be hard to do. The idea would be to have some kind of equivalence list. The first built object's sstate checksum would become the definitive checksum and the object added to the sstate cache. If a new object is built, it would be compared with the one in sstate. If deemed equivalent (by whatever policy), a mapping would be added to the list. If not, there is no mapping and it becomes a new definitive checksum. All runqueue would then have to do is present its list of sstate checksums to the list and convert them (in dependency order) into canonical checksums. This list could be a local equivalence file, or an equivalence server which could resolve list of checksums. Doing it this way totally isolates the comparison from the metadata itself and in my view protects us from future changes in definition of equivalence. How does that sound? Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel-cache][PATCH] intel-common-drivers: Add x2apic
On 09/21/2017 07:28 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote: Dear maintainer, The Intel Denverton platform requires x2apic to boot hence the need to enable it in intel-common-drivers as a built-in feature I may have overlooked it in the patch, but what kernel versions is this for ? 4.9, 4.10, 4.12+ ? Bruce Syed Mohamad Fauzi, Syed Johan Arif (1): intel-common: adding x2apic bsp/intel-common/intel-common-drivers.scc | 1 + 1 file changed, 1 insertion(+) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] eSDK install script failure
On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbuserawrote: > Hi Paul, > thanks for explaining and helping sorting this out. > > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton < > paul.eggle...@linux.intel.com> wrote: > >> Hi Andrea, >> >> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera wrote: >> > Seeing the errors below while installing an eSDK. This is a routinely >> > generated VM that installs the eSDK from installation script. The errors >> > appeared with the latest iteration of the eSDK script, which is >> generated >> > with almost up-to-date revisions from master. Of course I have extra >> layers >> > in the mix, but none of them apparently had relevant changed since last >> > (working) iteration: mostly synching to master branches happened. Can >> > anyone help suggesting how to investigate this further? What do those >> > unexpected task mean? I'm blocked on releasing this SDK to developers >> and >> > clues from expert would be very appreciated... >> > >> > ==> default: Checking sstate mirror object availability... >> > ==> default: done. >> > ==> default: ERROR: Task python-native.do_fetch attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot >> attempted >> > to execute unexpectedly >> > ==> default: ERROR: Task python-native.do_unpack attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_patch attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_populate_lic attempted to >> execute >> > unexpectedly and should have been setscened >> > ==> default: ERROR: Task python-native.do_configure attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_compile attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_install attempted to execute >> > unexpectedly >> > ==> default: ERROR: Task python-native.do_populate_sysroot attempted to >> > execute unexpectedly and should have been setscened >> > ==> default: ERROR: SDK preparation failed: error log written to >> > /home/vagrant/poky_sdk/preparing_build_system.log >> > >> >> Basically this means that these tasks tried to execute where really the >> results should have been able to be restored from sstate. >> >> The cause of this type of error is one of three things: >> >> 1) The sstate archive corresponding to a task wasn't able to be fetched >> from >> the server (for a minimal eSDK) or wasn't present in the installer (for a >> full >> eSDK - less likely as we basically do a trial run as part of building the >> eSDK >> in the first place) >> >> 2) The signature was somehow different to what it should have been. >> (Locked >> signatures are supposed to guard against this.) >> >> 3) A task that wasn't expected to execute did execute and thus the sstate >> wasn't available. >> >> Given that this was python-native which I would expect would be a normal >> part >> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. what >> is >> SDK_EXT_TYPE set to)? >> > > That was a "full" eSDK. I noticed that the "same" eSDK installer from > another build host was not affected and I'm trying to rebuild on the > original one with even more recent revision and see if it still happens or > not. Failure with the first one was repeatable, hence I suspect an issue at > sdk population stage, not during installation. > Nuking tmp/ and rebuilding with the same revisions of the successful build host didn't fix the issue... Same error on installation of the generated eSDK. Would you suggest any other investigation step? On my todo list I'd put using the sstate from that other build host than nuking local sstate-cache/ and going to take a very long coffee break. :-( -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] which is the official(?) OE/YP openbmc layer?
On Thu, 21 Sep 2017, Burton, Ross wrote: > On 21 September 2017 at 11:01, Robert P. J. Daywrote: > colleague just yesterday asked me a couple questions about openbmc, > so i investigated the OE/YP layer, and i'm a bit confused ... the > official OE layers page here: > > https://layers.openembedded.org/layerindex/branch/master/layers/ > > refers to a meta-openbmc layer at https://github.com/facebook/openbmc, > implying it's a facebook project, but github also hosts: > > https://github.com/openbmc > > can anyone clarify the relationship between those two? if there is > any? > > > Oh I really hope that isn't a Google/IBM vs Facebook fork war. > > I think the best way to get an answer is to email both > maintainers... for curiosity's sake, i spent a few minutes ignoring the apparent facebook fork and concentrated strictly on the top-level github/openbmc content, and it seems amazingly convoluted. starting here: https://github.com/openbmc i further checked out the next-level openbmc/openbmc git repo and, holy mackinaw, it contains a ton of layers. ignoring all of the symlinked layers for regular OE/YP content contained therein, one sees, from the top of that clone, all of the following "layer.conf" files: $ find . -name layer.conf ./meta-phosphor/conf/layer.conf ./meta-openbmc-machines/meta-x86/meta-mellanox/conf/layer.conf ./meta-openbmc-machines/meta-x86/meta-mellanox/meta-msn/conf/layer.conf ./meta-openbmc-machines/meta-x86/conf/layer.conf ./meta-openbmc-machines/meta-x86/meta-quanta/meta-q71l/conf/layer.conf ./meta-openbmc-machines/meta-x86/meta-quanta/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-rackspace/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-rackspace/meta-barreleye/conf/layer.conf ./meta-openbmc-machines/meta-openpower/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ingrasys/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ingrasys/meta-zaius/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/meta-garrison/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/meta-firestone/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/meta-romulus/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/meta-palmetto/conf/layer.conf ./meta-openbmc-machines/meta-openpower/meta-ibm/meta-witherspoon/conf/layer.conf ./meta-openbmc-machines/meta-evb/conf/layer.conf ./meta-openbmc-machines/meta-evb/meta-evb-aspeed/conf/layer.conf ./meta-openbmc-machines/meta-evb/meta-evb-aspeed/meta-evb-ast2500/conf/layer.conf ./meta-openbmc-bsp/meta-aspeed/conf/layer.conf ./meta-openbmc-bsp/meta-aspeed/meta-ast2500/conf/layer.conf ./meta-openbmc-bsp/meta-aspeed/meta-ast2400/conf/layer.conf $ not only does that single "git clone" apparently contain 23 individual layers, some of the content represents independent projects in github. for example: openbmc/meta-aspeed <==> openbmc/openbmc/meta-openbmc-bsp/meta-aspeed same with meta-openpower, possibly others. sorry to pollute this ML with questions about a specific layer, i just figured it would be a piece of cake to take a look at this stuff for a colleague and it got ugly in a hurry. i'll check in with the actual maintainers, but if anyone out there is doing current work with openbmc, any pointers as to the current state of that content would be appreciated. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [kernel-cache][PATCH] intel-common-drivers: adding x2apic
Included features/x2apic/x2apic.scc to enable x2apic as a built-in feature. Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif--- bsp/intel-common/intel-common-drivers.scc | 1 + 1 file changed, 1 insertion(+) diff --git a/bsp/intel-common/intel-common-drivers.scc b/bsp/intel-common/intel-common-drivers.scc index bd56165..6b0de8d 100644 --- a/bsp/intel-common/intel-common-drivers.scc +++ b/bsp/intel-common/intel-common-drivers.scc @@ -76,6 +76,7 @@ include cfg/dmaengine.scc include features/uio/uio.scc include cfg/efi-ext.scc include features/input/keyboard-gpio.scc +include features/x2apic/x2apic.scc # default policy for standard kernels include cfg/usb-mass-storage.scc -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [kernel-cache][PATCH] intel-common-drivers: Add x2apic
Dear maintainer, The Intel Denverton platform requires x2apic to boot hence the need to enable it in intel-common-drivers as a built-in feature Syed Mohamad Fauzi, Syed Johan Arif (1): intel-common: adding x2apic bsp/intel-common/intel-common-drivers.scc | 1 + 1 file changed, 1 insertion(+) -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Sysroot bug in bitbake or wrong configuration?
Perfect, that worked. On 21. sep. 2017 03:45, Andre McCurdy wrote: > Since image recipes don't have a do_configure task (or at least, they > do their work in tasks such as do_rootfs which don't depend on > do_configure), using the DEPENDS shorthand for setting dependencies > for the do_configure task doesn't work. Technically, this isn't a Yocto image recipe per se, but a general recipe for processing some file which happens to have the name "image" in it. The naming was perhaps a little misleading. Notice that this recipe does not disable the default tasks, so all of them run, including do_configure. What I learned after some experimentation is that DEPENDS seems to works fine if you place your custom tasks after the do_configure tasks: addtask do_spu_rootfs before do_build after do_compile This construct seems to work even if you disable the confiugre task with do_configure[noexec]="1" But agreed, this works because of the implicit dependency on do_populate_* by do_compile. Setting the dep explicitly with the "longhand" format is more robust. Best regards, Svein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "(-)"??
null and nothing can also be matched in MACHINE names, so to make sure people should use: COMPATIBLE_MACHINE = "(^$)" On Thu, Sep 21, 2017 at 8:41 AM, Peter Kjellerstedt < peter.kjellerst...@axis.com> wrote: > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Khem Raj > > Sent: den 21 september 2017 07:15 > > To: Takashi Matsuzawa; yocto@yoctoproject.org > > Subject: Re: [yocto] "(-)"?? > > > > On 9/20/17 8:18 PM, Takashi Matsuzawa wrote: > > > Hello. > > > I am seeing some of the recipes contains lines like below. > > > > > >> COMPATIBLE_MACHINE = "(-)" > > > > > > Sorry being novice, but what is the intended effect of this line? > > > I can see submit comments that this is for blacklisting but I am not > > > sure how it works. It simply means a '-' letter? > > > > COMAPTIBLE_MACHINE uses regexp syntax > > Which actually makes that a pretty weird COMPATIBLE_MACHINE, > especially if it is intended for blacklisting. Given that it would > match any machine with a dash in it, it would match, e.g., qemux86-64 > but not qemux86. It would also happen to match about half of our > machines which happen to have dashes in their names. > > A more appropriate way to blacklist machines using COMPATIBLE_MACHINE > would be something like: > > COMPATIBLE_MACHINE = "null" > > or: > > COMPATIBLE_MACHINE = "nothing" > > I found two occurrences of "(-)" being used as COMPATIBLE_MACHINE in > meta-openembedded for Morty and Pyro, but they have been removed for > Rocko. If you see them anywhere else, consider changing them. > > //Peter > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Public key for U-Boot verified boot is not inserted in DTB when rebuilding from sstate
Hello, I have a problem with U-Boot verified boot and the sstate caching of build artifacts. On a clean rebuild (deleted sstate and tmp dir), the signed FIT image and U-Boot incl. the public key are correctly created. But when I delete the tmp dir and let bitbake recreate it from sstate, the public key in U-Boot is missing. The task sequence according to uboot-sign.bbclass is: # u-boot:do_deploy_dtb # u-boot:do_deploy # virtual/kernel:do_assemble_fitimage # u-boot:do_concat_dtb # u-boot:do_install The problem seems to be that while assembling the FIT image (from the kernel recipe), the U-Boot DTB in DEPLOY_IMAGE_DIR is modified and the public key is inserted. After that U-Boot and the new DTB are concatenated. This happens for the U-Boot image in DEPLOYDIR as well in DEPLOY_IMAGE_DIR. The problem now is, that the sstate caches the versions of U-Boot and DTB while deploying it. Since this happens before assembling the FIT image, the sstate now contains U-Boot and DTB without the public key. U-Boot unfortunately (silently!) disables verified boot when the public key is not available in the DTB. I already filed a bug (#12112) for this, but has anybody an idea how to easily fix this (other than cleaning the sstate of U-Boot/Kernel after deleting the tmp dir)? A possible solution would be to remove the dependency between kernel and U-Boot. But in this case it would be necessary to insert the public key into the DTB while building U-Boot without using the FIT image from the kernel build. Unfortunately uboot-mkimage does not support this at the moment. Regards Christian -- KOSTAL Industrie Elektrik GmbH www.kostal-industrie-elektrik.com KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170 Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49 2351 16-0 * Telefax: +49 2351 16-2400 Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 2331 8040-602 Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec. Andreas Kostal -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] which is the official(?) OE/YP openbmc layer?
On Thu, 21 Sep 2017, Burton, Ross wrote: > On 21 September 2017 at 11:01, Robert P. J. Daywrote: > colleague just yesterday asked me a couple questions about openbmc, > so i investigated the OE/YP layer, and i'm a bit confused ... the > official OE layers page here: > > https://layers.openembedded.org/layerindex/branch/master/layers/ > > refers to a meta-openbmc layer at https://github.com/facebook/openbmc, > implying it's a facebook project, but github also hosts: > > https://github.com/openbmc > > can anyone clarify the relationship between those two? if there is > any? > > > Oh I really hope that isn't a Google/IBM vs Facebook fork war. > > I think the best way to get an answer is to email both > maintainers... after just cursory examination of both repos, i have to say, neither of them looks particularly well-organized. or am i just being overly critical? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] which is the official(?) OE/YP openbmc layer?
On 21 September 2017 at 11:01, Robert P. J. Daywrote: > colleague just yesterday asked me a couple questions about openbmc, > so i investigated the OE/YP layer, and i'm a bit confused ... the > official OE layers page here: > > https://layers.openembedded.org/layerindex/branch/master/layers/ > > refers to a meta-openbmc layer at https://github.com/facebook/openbmc, > implying it's a facebook project, but github also hosts: > > https://github.com/openbmc > > can anyone clarify the relationship between those two? if there is > any? > Oh I really hope that isn't a Google/IBM vs Facebook fork war. I think the best way to get an answer is to email both maintainers... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder][PATCH] CheckYoctoCompat.py: rename yocto-compat-layer to yocto-check-layer
On 21/09/17 09:47, Joshua Lock wrote: On 21/09/17 02:36, Stephano Cetola wrote: This script name was changed in the following commit: b46e05677b342df44829ffe8bcfbfc954e906030 This patch updates the script name to match. [YOCTO #12110] Signed-off-by: Stephano Cetola--- lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py index 134adaa51..62eddae50 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py @@ -41,11 +41,12 @@ class CheckYoctoCompat(BitbakeShellCommand): layerversioncore = int(self.getProperty("layerversion_core", "0")) # yocto-compat-layer-wrapper was introduced in Pyro + # it was renamed to yocto-check-layer-wrapper Rocko if layerversioncore >= 10: command = ". ./oe-init-build-env;" for layer in self.layers: layerpath = os.path.join(builddir, layer) - cmd = "yocto-compat-layer-wrapper {}".format(layerpath) + cmd = "yocto-check-layer-wrapper {}".format(layerpath) This will result in failures on Pyro (layer version 10). We should either: a) bump the layer version check to only run this for Rocko (layer version 11) I went ahead and merged it with this change. Joshua b) use different program names for layer version 10 vs. layer version 11. I'm inclined to suggest a, the yocto-compat-layer scripts only really became useful in the Rocko cycle. cmd = cmd + " || export CL_FAIL=1;" command = command + cmd command = command + 'if [ "$CL_FAIL" = "1" ]; then exit 1; fi;' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] which is the official(?) OE/YP openbmc layer?
colleague just yesterday asked me a couple questions about openbmc, so i investigated the OE/YP layer, and i'm a bit confused ... the official OE layers page here: https://layers.openembedded.org/layerindex/branch/master/layers/ refers to a meta-openbmc layer at https://github.com/facebook/openbmc, implying it's a facebook project, but github also hosts: https://github.com/openbmc can anyone clarify the relationship between those two? if there is any? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder][PATCH] CheckYoctoCompat.py: rename yocto-compat-layer to yocto-check-layer
On 21/09/17 02:36, Stephano Cetola wrote: This script name was changed in the following commit: b46e05677b342df44829ffe8bcfbfc954e906030 This patch updates the script name to match. [YOCTO #12110] Signed-off-by: Stephano Cetola--- lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py index 134adaa51..62eddae50 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckYoctoCompat.py @@ -41,11 +41,12 @@ class CheckYoctoCompat(BitbakeShellCommand): layerversioncore = int(self.getProperty("layerversion_core", "0")) # yocto-compat-layer-wrapper was introduced in Pyro +# it was renamed to yocto-check-layer-wrapper Rocko if layerversioncore >= 10: command = ". ./oe-init-build-env;" for layer in self.layers: layerpath = os.path.join(builddir, layer) -cmd = "yocto-compat-layer-wrapper {}".format(layerpath) +cmd = "yocto-check-layer-wrapper {}".format(layerpath) This will result in failures on Pyro (layer version 10). We should either: a) bump the layer version check to only run this for Rocko (layer version 11) b) use different program names for layer version 10 vs. layer version 11. I'm inclined to suggest a, the yocto-compat-layer scripts only really became useful in the Rocko cycle. cmd = cmd + " || export CL_FAIL=1;" command = command + cmd command = command + 'if [ "$CL_FAIL" = "1" ]; then exit 1; fi;' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "(-)"??
> -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Khem Raj > Sent: den 21 september 2017 07:15 > To: Takashi Matsuzawa; yocto@yoctoproject.org > Subject: Re: [yocto] "(-)"?? > > On 9/20/17 8:18 PM, Takashi Matsuzawa wrote: > > Hello. > > I am seeing some of the recipes contains lines like below. > > > >> COMPATIBLE_MACHINE = "(-)" > > > > Sorry being novice, but what is the intended effect of this line? > > I can see submit comments that this is for blacklisting but I am not > > sure how it works. It simply means a '-' letter? > > COMAPTIBLE_MACHINE uses regexp syntax Which actually makes that a pretty weird COMPATIBLE_MACHINE, especially if it is intended for blacklisting. Given that it would match any machine with a dash in it, it would match, e.g., qemux86-64 but not qemux86. It would also happen to match about half of our machines which happen to have dashes in their names. A more appropriate way to blacklist machines using COMPATIBLE_MACHINE would be something like: COMPATIBLE_MACHINE = "null" or: COMPATIBLE_MACHINE = "nothing" I found two occurrences of "(-)" being used as COMPATIBLE_MACHINE in meta-openembedded for Morty and Pyro, but they have been removed for Rocko. If you see them anywhere else, consider changing them. //Peter -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto