Re: [yocto] eSDK install script failure

2017-09-21 Thread Paul Eggleton 
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

2017-09-21 Thread Richard Purdie 
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

2017-09-21 Thread Andre McCurdy 
On Thu, Sep 21, 2017 at 1:00 PM, 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?

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

2017-09-21 Thread Andrea Galbusera 
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

2017-09-21 Thread Paul Eggleton 
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.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "(-)"??

2017-09-21 Thread Gunnar Andersson 

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 Andersson 
Development Lead
GENIVI Alliance



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Path to current bb-file or layer

2017-09-21 Thread Svein Seldal 


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

2017-09-21 Thread Richard Purdie 
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

2017-09-21 Thread Bruce Ashfield 

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

2017-09-21 Thread Andrea Galbusera 
On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera  wrote:

> 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?

2017-09-21 Thread Robert P. J. Day 
On Thu, 21 Sep 2017, Burton, Ross wrote:

> On 21 September 2017 at 11:01, Robert P. J. Day  wrote:
>     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

2017-09-21 Thread Syed Mohamad Fauzi, Syed Johan Arif 
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

2017-09-21 Thread Syed Mohamad Fauzi, Syed Johan Arif 
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?

2017-09-21 Thread Svein Seldal 

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] "(-)"??

2017-09-21 Thread Martin Jansa 
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

2017-09-21 Thread Andersen, Christian 
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?

2017-09-21 Thread Robert P. J. Day 
On Thu, 21 Sep 2017, Burton, Ross wrote:

> On 21 September 2017 at 11:01, Robert P. J. Day  wrote:
>     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?

2017-09-21 Thread Burton, Ross 
On 21 September 2017 at 11:01, Robert P. J. Day 
wrote:

>   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

2017-09-21 Thread Joshua Lock 



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?

2017-09-21 Thread Robert P. J. Day 

  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

2017-09-21 Thread Joshua Lock 



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] "(-)"??

2017-09-21 Thread Peter Kjellerstedt 
> -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