Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Tue, May 3, 2016 at 3:01 AM, Khem Raj  wrote:

>
> On May 2, 2016, at 7:53 PM, Christopher Larson  wrote:
>
>
>
> On Mon, May 2, 2016 at 9:37 PM, Khem Raj  wrote:
>
>>
>> On May 2, 2016, at 1:37 PM, Christopher Larson  wrote:
>>
>>
>>
>> On Mon, May 2, 2016 at 8:34 PM, Khem Raj  wrote:
>>
>>>
>>> > On May 2, 2016, at 1:09 PM, Christopher Larson 
>>> wrote:
>>> >
>>> > From: Christopher Larson 
>>> >
>>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
>>> default to
>>> > this in the toolchain, while convenient, actually hides bugs, as a
>>> failure to
>>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to
>>> how we
>>> > poison the sysroot -- rather than relying on the default, notice right
>>> away if
>>> > somoeone isn't obeying the needed flags.
>>> >
>>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>>> failure,
>>> > which is what's often seen with external toolchains. This brings us
>>> all on the
>>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>>> >
>>>
>>>
>>> Default or gnu linkers is to use sysv for legacy reasons and by passing
>>> this option
>>> to configuring the toolchain we want to make sure that components are
>>> using sane defaults
>>> even if they have not configured these options.
>>>
>>
>> But that's not what we want. We want to know when we're not passing
>> arguments we need to be passing. For example, the sysroot is poisoned
>> today, so we *know* when the user is trying to run it without --sysroot=.
>>
>>
>> application makefiles can ignore environment e.g. CC, CXX, LD etc and get
>> into same situations.
>> as an application writer I may not be interested in using cross
>> compilation specific nuances.  We may not
>> be able to solve it completely
>>
>
>
> I'm not sure what you mean by that. This is only for gcc-cross and
> gcc-cross-canadian. Anyone using those needs to deal with cross issues
> regardless.
>
>
> I was taking a application developers point of view. not a system
> integrators or OE build masters. applications are supposed to work on all
> kind of env
> and cross build env is one of them which large app developer community may
> not use as primary environment for development.
>
>
> if you do not pass the right linker flags from compiler driver and also
>>> ignore
>>> the LDFLAGS then you now have a safe pass for the app to build without
>>> GNU hash
>>> while I understand it will spread the external toolchain’s pains into
>>> internal toolchain
>>> I fail to understand the benefit of doing this otherwise.
>>
>>
>> Silently ignoring the fact that recipes ignore LDFLAGS is not good
>> default behavior, and this is precisely what oe-core is doing today. If you
>> know of a better way to detect that in another QA check, I'm certainly open
>> to hearing it.
>>
>>
>> linker would emit .hash for sysv and .gnu.hash section for gnu hash in
>> final ELF, may be adding a QA check for that would be enough ?
>>
>
> I don't understand what you mean by this. I don't see how you'd be able to
> distinguish between a gnu.hash used because of the toolchain defaults and a
> gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be
> able to detect the lack of the latter without this patch.
>
>
> I thought you were looking for ways to detect if hash styles are mixed or
> not conforming to default for a given architecture. If the end binary is
> getting build as expected
> and we are able to detect if it does not, then it won’t matter if the
> setting came from LDFLAGS or CFLAFS or implicit defaults.
>

No, that's exactly the point. Recipes have clear brokenness, not obeying
LDFLAGS, which is a clear correctness bug, and there's no easy way to
detect that if the toolchain sets the gnu hash style by default.

The only ones spotting these common, clear bugs are those using external
toolchains. The internal toolchain builds are ignoring these bugs by
letting the toolchain set the default regardless of whether it obeys
LDFLAGS or not.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

> On May 2, 2016, at 7:53 PM, Christopher Larson  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 9:37 PM, Khem Raj  > wrote:
> 
>> On May 2, 2016, at 1:37 PM, Christopher Larson > > wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 8:34 PM, Khem Raj > > wrote:
>> 
>> > On May 2, 2016, at 1:09 PM, Christopher Larson > > > wrote:
>> >
>> > From: Christopher Larson > > >
>> >
>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the 
>> > default to
>> > this in the toolchain, while convenient, actually hides bugs, as a failure 
>> > to
>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
>> > poison the sysroot -- rather than relying on the default, notice right 
>> > away if
>> > somoeone isn't obeying the needed flags.
>> >
>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA 
>> > failure,
>> > which is what's often seen with external toolchains. This brings us all on 
>> > the
>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>> >
>> 
>> 
>> Default or gnu linkers is to use sysv for legacy reasons and by passing this 
>> option
>> to configuring the toolchain we want to make sure that components are using 
>> sane defaults
>> even if they have not configured these options.
>> 
>> But that's not what we want. We want to know when we're not passing 
>> arguments we need to be passing. For example, the sysroot is poisoned today, 
>> so we *know* when the user is trying to run it without --sysroot=.
> 
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get 
> into same situations.
> as an application writer I may not be interested in using cross compilation 
> specific nuances.  We may not
> be able to solve it completely
> 
> 
> I'm not sure what you mean by that. This is only for gcc-cross and 
> gcc-cross-canadian. Anyone using those needs to deal with cross issues 
> regardless.

I was taking a application developers point of view. not a system integrators 
or OE build masters. applications are supposed to work on all kind of env
and cross build env is one of them which large app developer community may not 
use as primary environment for development.

> 
>> if you do not pass the right linker flags from compiler driver and also 
>> ignore
>> the LDFLAGS then you now have a safe pass for the app to build without GNU 
>> hash
>> while I understand it will spread the external toolchain’s pains into 
>> internal toolchain
>> I fail to understand the benefit of doing this otherwise.
>> 
>> Silently ignoring the fact that recipes ignore LDFLAGS is not good default 
>> behavior, and this is precisely what oe-core is doing today. If you know of 
>> a better way to detect that in another QA check, I'm certainly open to 
>> hearing it.
> 
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in final 
> ELF, may be adding a QA check for that would be enough ?
> 
> I don't understand what you mean by this. I don't see how you'd be able to 
> distinguish between a gnu.hash used because of the toolchain defaults and a 
> gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be able 
> to detect the lack of the latter without this patch.

I thought you were looking for ways to detect if hash styles are mixed or not 
conforming to default for a given architecture. If the end binary is getting 
build as expected
and we are able to detect if it does not, then it won’t matter if the setting 
came from LDFLAGS or CFLAFS or implicit defaults.

> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 2, 2016 at 9:37 PM, Khem Raj  wrote:

>
> On May 2, 2016, at 1:37 PM, Christopher Larson  wrote:
>
>
>
> On Mon, May 2, 2016 at 8:34 PM, Khem Raj  wrote:
>
>>
>> > On May 2, 2016, at 1:09 PM, Christopher Larson 
>> wrote:
>> >
>> > From: Christopher Larson 
>> >
>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
>> default to
>> > this in the toolchain, while convenient, actually hides bugs, as a
>> failure to
>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to
>> how we
>> > poison the sysroot -- rather than relying on the default, notice right
>> away if
>> > somoeone isn't obeying the needed flags.
>> >
>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>> failure,
>> > which is what's often seen with external toolchains. This brings us all
>> on the
>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>> >
>>
>>
>> Default or gnu linkers is to use sysv for legacy reasons and by passing
>> this option
>> to configuring the toolchain we want to make sure that components are
>> using sane defaults
>> even if they have not configured these options.
>>
>
> But that's not what we want. We want to know when we're not passing
> arguments we need to be passing. For example, the sysroot is poisoned
> today, so we *know* when the user is trying to run it without --sysroot=.
>
>
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get
> into same situations.
> as an application writer I may not be interested in using cross
> compilation specific nuances.  We may not
> be able to solve it completely
>


I'm not sure what you mean by that. This is only for gcc-cross and
gcc-cross-canadian. Anyone using those needs to deal with cross issues
regardless.

if you do not pass the right linker flags from compiler driver and also
>> ignore
>> the LDFLAGS then you now have a safe pass for the app to build without
>> GNU hash
>> while I understand it will spread the external toolchain’s pains into
>> internal toolchain
>> I fail to understand the benefit of doing this otherwise.
>
>
> Silently ignoring the fact that recipes ignore LDFLAGS is not good default
> behavior, and this is precisely what oe-core is doing today. If you know of
> a better way to detect that in another QA check, I'm certainly open to
> hearing it.
>
>
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in
> final ELF, may be adding a QA check for that would be enough ?
>

I don't understand what you mean by this. I don't see how you'd be able to
distinguish between a gnu.hash used because of the toolchain defaults and a
gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be
able to detect the lack of the latter without this patch.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] mesa: add PACKAGECONFIG for gbm

[Denys Dmytriyenko]

On Tue, Apr 26, 2016 at 10:49:25AM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 26, 2016 at 02:58:23PM +0100, Ross Burton wrote:
> > gbm is an optional library and some environments (for example, mesa-gl where
> > there are separate drivers that provide libgbm) may not want to build it.
> > 
> > Signed-off-by: Ross Burton 
> 
> I was now able to build mesa-gl with TI SGX GLES and own libgbm. Thanks!
> 
> Acked-by: Denys Dmytriyenko 

Ross,

I would like to see these 2 patches pushed early, even if virtual/libgbm 
rework isn't ready yet. Thanks.

-- 
Denys


> > ---
> >  meta/recipes-graphics/mesa/mesa.inc | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> > b/meta/recipes-graphics/mesa/mesa.inc
> > index 442479a..a4e5351 100644
> > --- a/meta/recipes-graphics/mesa/mesa.inc
> > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > @@ -24,11 +24,13 @@ REQUIRED_DISTRO_FEATURES = "opengl"
> >  
> >  EXTRA_OECONF = "--enable-shared-glapi"
> >  
> > -PACKAGECONFIG ??= "egl gles dri ${MESA_CRYPTO} \
> > +PACKAGECONFIG ??= "gbm egl gles dri ${MESA_CRYPTO} \
> > ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}\
> > ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', 
> > '', d)}\
> > "
> >  
> > +PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
> > +
> >  X11_DEPS = "xf86driproto glproto virtual/libx11 libxext libxxf86vm 
> > libxdamage libxfixes"
> >  PACKAGECONFIG[x11] = "--enable-glx-tls,--disable-glx,${X11_DEPS}"
> >  PACKAGECONFIG[xvmc] = "--enable-xvmc,--disable-xvmc,libxvmc"
> > @@ -37,7 +39,7 @@ PACKAGECONFIG[wayland] = ",,wayland-native wayland"
> >  DRIDRIVERS = "swrast"
> >  DRIDRIVERS_append_x86 = ",radeon,r200,nouveau,i965,i915"
> >  DRIDRIVERS_append_x86-64 = ",radeon,r200,nouveau,i965,i915"
> > -PACKAGECONFIG[dri] = "--enable-dri --with-dri-drivers=${DRIDRIVERS} 
> > --enable-gbm, --disable-dri, dri2proto libdrm"
> > +PACKAGECONFIG[dri] = "--enable-dri --with-dri-drivers=${DRIDRIVERS}, 
> > --disable-dri, dri2proto libdrm"
> >  PACKAGECONFIG[dri3] = "--enable-dri3, --disable-dri3, dri3proto 
> > presentproto libxshmfence"
> >  
> >  PACKAGECONFIG[gles] = "--enable-gles1 --enable-gles2, --disable-gles1 
> > --disable-gles2"
> > -- 
> > 2.8.0.rc3
> > 
> > -- 
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image_types.bbclass: add WIC_CREATE_EXTRA_ARGS

[Christopher Larson]

From: Christopher Larson 

This'll be of use to pass things like --bmap.

Signed-off-by: Christopher Larson 
---
 meta/classes/image_types.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 19f89f3..385d47e 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -193,6 +193,8 @@ def wks_search(files, search_path):
 if searched:
 return searched
 
+WIC_CREATE_EXTRA_ARGS ?= ""
+
 IMAGE_CMD_wic () {
out="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}"
wks="${WKS_FULL_PATH}"
@@ -200,7 +202,7 @@ IMAGE_CMD_wic () {
bbfatal "No kickstart files from WKS_FILES were found: 
${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."
fi
 
-   BUILDDIR="${TOPDIR}" wic create "$wks" --vars 
"${STAGING_DIR_TARGET}/imgdata/" -e "${IMAGE_BASENAME}" -o "$out/"
+   BUILDDIR="${TOPDIR}" wic create "$wks" --vars 
"${STAGING_DIR_TARGET}/imgdata/" -e "${IMAGE_BASENAME}" -o "$out/" 
${WIC_CREATE_EXTRA_ARGS}
mv "$out/build/$(basename "${wks%.wks}")"*.direct 
"$out${IMAGE_NAME_SUFFIX}.wic"
rm -rf "$out/"
 }
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] moving OpenEmbedded-core to Python 3

[Khem Raj]

> On May 2, 2016, at 3:14 AM, Alexander Kanavin 
>  wrote:
> 
> On 04/29/2016 11:43 PM, Khem Raj wrote:
> 
>> Can you clarify the scope, are you addressing the case where target
>> images would prefer python3
>> and you are making sure that packages that use python on target are
>> ready for using it.
> 
> There is no way to set a 'preference' for Python 3. Either version of Python 
> is pulled into images either through dependencies, or explicit inclusion into 
> some package list.
> 
> I'm going to move recipes that are dependent on Python 2 to Python 3, 
> whenever possible. I'm not porting the upstream code from Python 2 from 
> Python 3, just configuring the recipes to use Python 3, when the Python code 
> in them has already been ported.

OK, that is a safer bet.

> 
>> bitbake itself is a separate task but then we do write scriptlets that
>> are executed as part of
>> build, are you addressing those too ?
> 
> Not sure what you mean here exactly, but if the scriptlets are executed by 
> bitbake, then I'm not addressing that.

I was referring to bitbake itself needs python2 to run but if we have code like 
classes etc. or external fetchers
with assume python2 since bitbake is python2

> 
>> Thirdly, there is general pythonic code in metadata meant to control
>> build policies
> 
> Again, can you provide an example?

Snippets are all around in metadata where we use python snippets inside recipes 
or configuration metadata. in general we should
be using python3 more, but scoping these changes clearly would help to set the 
expectations from user point of view.

> 
>> Which of these are you addressing specifically.
> 
> Please start using the question mark (?), so I can see more easily what is a 
> question when responding.
> 



> Thanks,
> Alex
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

> On May 2, 2016, at 1:37 PM, Christopher Larson  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 8:34 PM, Khem Raj  > wrote:
> 
> > On May 2, 2016, at 1:09 PM, Christopher Larson  > > wrote:
> >
> > From: Christopher Larson  > >
> >
> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the default 
> > to
> > this in the toolchain, while convenient, actually hides bugs, as a failure 
> > to
> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> > poison the sysroot -- rather than relying on the default, notice right away 
> > if
> > somoeone isn't obeying the needed flags.
> >
> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> > which is what's often seen with external toolchains. This brings us all on 
> > the
> > same page, and makes sure a failure to obey LDFLAGS is seen early.
> >
> 
> 
> Default or gnu linkers is to use sysv for legacy reasons and by passing this 
> option
> to configuring the toolchain we want to make sure that components are using 
> sane defaults
> even if they have not configured these options.
> 
> But that's not what we want. We want to know when we're not passing arguments 
> we need to be passing. For example, the sysroot is poisoned today, so we 
> *know* when the user is trying to run it without --sysroot=.

application makefiles can ignore environment e.g. CC, CXX, LD etc and get into 
same situations.
as an application writer I may not be interested in using cross compilation 
specific nuances.  We may not
be able to solve it completely

> 
> if you do not pass the right linker flags from compiler driver and also ignore
> the LDFLAGS then you now have a safe pass for the app to build without GNU 
> hash
> while I understand it will spread the external toolchain’s pains into 
> internal toolchain
> I fail to understand the benefit of doing this otherwise.
> 
> Silently ignoring the fact that recipes ignore LDFLAGS is not good default 
> behavior, and this is precisely what oe-core is doing today. If you know of a 
> better way to detect that in another QA check, I'm certainly open to hearing 
> it.

linker would emit .hash for sysv and .gnu.hash section for gnu hash in final 
ELF, may be adding a QA check for that would be enough ?

> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/6] oetest.py: Add default pscmd to oeTest

[mariano . lopez]

From: Mariano Lopez 

pscmd is used by some tests to get the process
running on the target. If the test are exported
there won't be any pscmd attibute in the oeTest.

This adds "ps" as default pscmd.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/oetest.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index bef9ac4..6a908ee 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -54,6 +54,7 @@ def filterByTagExp(testsuite, tagexp):
 @LogResults
 class oeTest(unittest.TestCase):
 
+pscmd = "ps"
 longMessage = True
 
 @classmethod
@@ -373,7 +374,8 @@ class RuntimeTestContext(TestContext):
 
 def loadTests(self):
 super(RuntimeTestContext, self).loadTests()
-setattr(oeRuntimeTest, "pscmd", "ps -ef" if 
oeTest.hasPackage("procps") else "ps")
+if oeTest.hasPackage("procps"):
+oeRuntimeTest.pscmd = "ps -ef"
 
 class ImageTestContext(RuntimeTestContext):
 def __init__(self, d, target, host_dumper):
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/6] oeqa/runexported.py: Remove host dumper

[mariano . lopez]

From: Mariano Lopez 

The host dumper is used to get information about the host
running the test when a test fails. This is used for the
autobuilders of Yocto Project.

Now that exported tests have thier own class the host dumper
is not necessary anymore.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/runexported.py | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/lib/oeqa/runexported.py b/meta/lib/oeqa/runexported.py
index cc89e13..f333879 100755
--- a/meta/lib/oeqa/runexported.py
+++ b/meta/lib/oeqa/runexported.py
@@ -116,16 +116,11 @@ def main():
 for key in loaded["target"].keys():
 setattr(target, key, loaded["target"][key])
 
-host_dumper = get_host_dumper(d)
-host_dumper.parent_dir = loaded["host_dumper"]["parent_dir"]
-host_dumper.cmds = loaded["host_dumper"]["cmds"]
-
 target.exportStart()
 tc = ExportTestContext(d)
 
 setattr(tc, "d", d)
 setattr(tc, "target", target)
-setattr(tc, "host_dumper", host_dumper)
 for key in loaded.keys():
 if key != "d" and key != "target" and key != "host_dumper":
 setattr(tc, key, loaded[key])
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 6/6] oetest.py: Use the real ExportTestContext in exported tests

[mariano . lopez]

From: Mariano Lopez 

There are parts of the fuctionallity missing when using the
dummy ExportTestContext class in runexported.py.

This changes the use of ExportTestContext dummy class from
runexported.py to the real class in oetest.py.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/oetest.py  | 26 +-
 meta/lib/oeqa/runexported.py | 16 ++--
 2 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index 6a908ee..70db119 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -186,11 +186,19 @@ def custom_verbose(msg, *args, **kwargs):
 _buffer_logger = ""
 
 class TestContext(object):
-def __init__(self, d):
+def __init__(self, d, exported=False):
 self.d = d
 
 self.testsuites = self._get_test_suites()
-self.testslist = self._get_tests_list(d.getVar("BBPATH", 
True).split(':'))
+
+if exported:
+path = [os.path.dirname(os.path.abspath(__file__))]
+extrapath = ""
+else:
+path = d.getVar("BBPATH", True).split(':')
+extrapath = "lib/oeqa"
+
+self.testslist = self._get_tests_list(path, extrapath)
 self.testsrequired = self._get_test_suites_required()
 
 self.filesdir = os.path.join(os.path.dirname(os.path.abspath(
@@ -213,7 +221,7 @@ class TestContext(object):
 return " ".join(tcs)
 
 # return test list by type also filter if TEST_SUITES is specified
-def _get_tests_list(self, bbpath):
+def _get_tests_list(self, bbpath, extrapath):
 testslist = []
 
 type = self._get_test_namespace()
@@ -227,11 +235,11 @@ class TestContext(object):
 continue
 found = False
 for p in bbpath:
-if os.path.exists(os.path.join(p, 'lib', 'oeqa', type, 
testname + '.py')):
+if os.path.exists(os.path.join(p, extrapath, type, 
testname + ".py")):
 testslist.append("oeqa." + type + "." + testname)
 found = True
 break
-elif os.path.exists(os.path.join(p, 'lib', 'oeqa', type, 
testname.split(".")[0] + '.py')):
+elif os.path.exists(os.path.join(p, extrapath, type, 
testname.split(".")[0] + ".py")):
 testslist.append("oeqa." + type + "." + testname)
 found = True
 break
@@ -333,8 +341,8 @@ class TestContext(object):
 return runner.run(self.suite)
 
 class RuntimeTestContext(TestContext):
-def __init__(self, d, target):
-super(RuntimeTestContext, self).__init__(d)
+def __init__(self, d, target, exported=False):
+super(RuntimeTestContext, self).__init__(d, exported)
 
 self.tagexp =  d.getVar("TEST_SUITES_TAGS", True)
 
@@ -393,8 +401,8 @@ class ImageTestContext(RuntimeTestContext):
 self.target.stop()
 
 class ExportTestContext(RuntimeTestContext):
-def __init__(self, d, target):
-super(ExportTestContext, self).__init__(d, target)
+def __init__(self, d, target, exported=False):
+super(ExportTestContext, self).__init__(d, target, exported)
 self.sigterm = None
 
 class SDKTestContext(TestContext):
diff --git a/meta/lib/oeqa/runexported.py b/meta/lib/oeqa/runexported.py
index f333879..52c1171 100755
--- a/meta/lib/oeqa/runexported.py
+++ b/meta/lib/oeqa/runexported.py
@@ -30,7 +30,7 @@ except ImportError:
 
 sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), 
"oeqa")))
 
-from oeqa.oetest import TestContext
+from oeqa.oetest import ExportTestContext
 from oeqa.utils.sshcontrol import SSHControl
 from oeqa.utils.dump import get_host_dumper
 
@@ -69,10 +69,6 @@ class MyDataDict(dict):
 def getVar(self, key, unused = None):
 return self.get(key, "")
 
-class ExportTestContext(TestContext):
-def __init__(self, d):
-self.d = d
-
 def main():
 
 parser = argparse.ArgumentParser()
@@ -111,20 +107,12 @@ def main():
 if not os.path.isdir(d["DEPLOY_DIR"]):
 print("WARNING: The path to DEPLOY_DIR does not exist: %s" % 
d["DEPLOY_DIR"])
 
-
 target = FakeTarget(d)
 for key in loaded["target"].keys():
 setattr(target, key, loaded["target"][key])
 
 target.exportStart()
-tc = ExportTestContext(d)
-
-setattr(tc, "d", d)
-setattr(tc, "target", target)
-for key in loaded.keys():
-if key != "d" and key != "target" and key != "host_dumper":
-setattr(tc, key, loaded[key])
-
+tc = ExportTestContext(d, target, True)
 tc.loadTests()
 tc.runTests()
 
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/6] testexport.bbclass: Split testimage class

[mariano . lopez]

From: Mariano Lopez 

This adds a new class that only export tests of images,
the code was taken from testimage class and most of it
wasn't modified. Just add some vars for the new class.

testexport class require testimage class to get the
test suites defined for all the images.

Signed-off-by: Mariano Lopez 
---
 meta/classes/testexport.bbclass | 150 
 1 file changed, 150 insertions(+)
 create mode 100644 meta/classes/testexport.bbclass

diff --git a/meta/classes/testexport.bbclass b/meta/classes/testexport.bbclass
new file mode 100644
index 000..0aac030
--- /dev/null
+++ b/meta/classes/testexport.bbclass
@@ -0,0 +1,150 @@
+# Copyright (C) 2016 Intel Corporation
+#
+# Released under the MIT license (see COPYING.MIT)
+#
+#
+# testexport.bbclass allows to execute runtime test outside OE environment.
+# Most of the tests are commands run on target image over ssh.
+# To use it add testexport to global inherit and call your target image with 
-c testexport
+# You can try it out like this:
+# - First build an image. i.e. core-image-sato
+# - Add INHERIT += "testexport" in local.conf
+# - Then bitbake core-image-sato -c testexport. That will generate the 
directory structure
+#   to execute the runtime tests using runexported.py.
+#
+# For more information on TEST_SUITES check testimage class.
+
+TEST_LOG_DIR ?= "${WORKDIR}/testexport"
+TEST_EXPORT_DIR ?= "${TMPDIR}/testexport/${PN}"
+TEST_TARGET ?= "simpleremote"
+TEST_TARGET_IP ?= ""
+TEST_SERVER_IP ?= ""
+
+TEST_EXPORT_DEPENDS = ""
+TEST_EXPORT_LOCK = "${TMPDIR}/testimage.lock"
+
+python do_testexport() {
+testexport_main(d)
+}
+
+addtask testexport
+do_testimage[nostamp] = "1"
+do_testimage[depends] += "${TEST_EXPORT_DEPENDS}"
+do_testimage[lockfiles] += "${TEST_EXPORT_LOCK}"
+
+def exportTests(d,tc):
+import json
+import shutil
+import pkgutil
+import re
+
+exportpath = d.getVar("TEST_EXPORT_DIR", True)
+
+savedata = {}
+savedata["d"] = {}
+savedata["target"] = {}
+for key in tc.__dict__:
+# special cases
+if key not in ['d', 'target', 'suite']:
+savedata[key] = getattr(tc, key)
+savedata["target"]["ip"] = tc.target.ip or d.getVar("TEST_TARGET_IP", True)
+savedata["target"]["server_ip"] = tc.target.server_ip or 
d.getVar("TEST_SERVER_IP", True)
+
+keys = [ key for key in d.keys() if not key.startswith("_") and not 
key.startswith("BB") \
+and not key.startswith("B_pn") and not key.startswith("do_") and 
not d.getVarFlag(key, "func", True)]
+for key in keys:
+try:
+savedata["d"][key] = d.getVar(key, True)
+except bb.data_smart.ExpansionError:
+# we don't care about those anyway
+pass
+
+json_file = os.path.join(exportpath, "testdata.json")
+with open(json_file, "w") as f:
+json.dump(savedata, f, skipkeys=True, indent=4, sort_keys=True)
+
+# Replace absolute path with relative in the file
+exclude_path = os.path.join(d.getVar("COREBASE", True),'meta','lib','oeqa')
+f1 = open(json_file,'r').read()
+f2 = open(json_file,'w')
+m = f1.replace(exclude_path,'oeqa')
+f2.write(m)
+f2.close()
+
+# now start copying files
+# we'll basically copy everything under meta/lib/oeqa, with these 
exceptions
+#  - oeqa/targetcontrol.py - not needed
+#  - oeqa/selftest - something else
+# That means:
+#   - all tests from oeqa/runtime defined in TEST_SUITES (including from 
other layers)
+#   - the contents of oeqa/utils and oeqa/runtime/files
+#   - oeqa/oetest.py and oeqa/runexport.py (this will get copied to 
exportpath not exportpath/oeqa)
+#   - __init__.py files
+bb.utils.mkdirhier(os.path.join(exportpath, "oeqa/runtime/files"))
+bb.utils.mkdirhier(os.path.join(exportpath, "oeqa/utils"))
+# copy test modules, this should cover tests in other layers too
+bbpath = d.getVar("BBPATH", True).split(':')
+for t in tc.testslist:
+isfolder = False
+if re.search("\w+\.\w+\.test_\S+", t):
+t = '.'.join(t.split('.')[:3])
+mod = pkgutil.get_loader(t)
+# More depth than usual?
+if (t.count('.') > 2):
+for p in bbpath:
+foldername = os.path.join(p, 'lib',  
os.sep.join(t.split('.')).rsplit(os.sep, 1)[0])
+if os.path.isdir(foldername):
+isfolder = True
+target_folder = os.path.join(exportpath, "oeqa", 
"runtime", os.path.basename(foldername))
+if not os.path.exists(target_folder):
+shutil.copytree(foldername, target_folder)
+if not isfolder:
+shutil.copy2(mod.filename, os.path.join(exportpath, 
"oeqa/runtime"))
+# copy __init__.py files
+oeqadir = pkgutil.get_loader("oeqa").filename
+shutil.copy2(os.path.join(oeqadir, 

[OE-core] [PATCH 1/6] oeqa/oetest.py: Add class ExportTestContext

[mariano . lopez]

From: Mariano Lopez 

Adding the class is needed to separate the exported test
from the test image; both test run under different conditions,
i.e. an exported test doesn't require to change the signal
handling.

This change adds clasess ExportTestContext and ImageTestContext,
both of them inherits from RuntimeTestContext. Also refactors
RuntimeTestContext class, to keep the code common in this class.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/oetest.py | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index 3ed5bb8..bef9ac4 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -331,14 +331,13 @@ class TestContext(object):
 
 return runner.run(self.suite)
 
-class ImageTestContext(TestContext):
-def __init__(self, d, target, host_dumper):
-super(ImageTestContext, self).__init__(d)
+class RuntimeTestContext(TestContext):
+def __init__(self, d, target):
+super(RuntimeTestContext, self).__init__(d)
 
 self.tagexp =  d.getVar("TEST_SUITES_TAGS", True)
 
 self.target = target
-self.host_dumper = host_dumper
 
 manifest = os.path.join(d.getVar("DEPLOY_DIR_IMAGE", True),
 d.getVar("IMAGE_LINK_NAME", True) + ".manifest")
@@ -352,15 +351,6 @@ class ImageTestContext(TestContext):
 else:
 self.pkgmanifest = ""
 
-self.sigterm = False
-self.origsigtermhandler = signal.getsignal(signal.SIGTERM)
-signal.signal(signal.SIGTERM, self._sigterm_exception)
-
-def _sigterm_exception(self, signum, stackframe):
-bb.warn("TestImage received SIGTERM, shutting down...")
-self.sigterm = True
-self.target.stop()
-
 def _get_test_namespace(self):
 return "runtime"
 
@@ -382,9 +372,29 @@ class ImageTestContext(TestContext):
 return [t for t in self.d.getVar("TEST_SUITES", True).split() if t != 
"auto"]
 
 def loadTests(self):
-super(ImageTestContext, self).loadTests()
+super(RuntimeTestContext, self).loadTests()
 setattr(oeRuntimeTest, "pscmd", "ps -ef" if 
oeTest.hasPackage("procps") else "ps")
 
+class ImageTestContext(RuntimeTestContext):
+def __init__(self, d, target, host_dumper):
+super(ImageTestContext, self).__init__(d, target)
+
+self.host_dumper = host_dumper
+
+self.sigterm = False
+self.origsigtermhandler = signal.getsignal(signal.SIGTERM)
+signal.signal(signal.SIGTERM, self._sigterm_exception)
+
+def _sigterm_exception(self, signum, stackframe):
+bb.warn("TestImage received SIGTERM, shutting down...")
+self.sigterm = True
+self.target.stop()
+
+class ExportTestContext(RuntimeTestContext):
+def __init__(self, d, target):
+super(ExportTestContext, self).__init__(d, target)
+self.sigterm = None
+
 class SDKTestContext(TestContext):
 def __init__(self, d, sdktestdir, sdkenv, tcname, *args):
 super(SDKTestContext, self).__init__(d)
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/6] testimage.bbclass: Remove exported test

[mariano . lopez]

From: Mariano Lopez 

Exported tests now have their own class, so
the code in testimage is not needed anymore.

Signed-off-by: Mariano Lopez 
---
 meta/classes/testimage.bbclass | 137 +
 1 file changed, 17 insertions(+), 120 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index e77bb11..a2e13df 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -30,7 +30,6 @@
 TEST_LOG_DIR ?= "${WORKDIR}/testimage"
 
 TEST_EXPORT_DIR ?= "${TMPDIR}/testimage/${PN}"
-TEST_EXPORT_ONLY ?= "0"
 
 RPMTESTSUITE = "${@bb.utils.contains('IMAGE_PKGTYPE', 'rpm', 'smart rpm', '', 
d)}"
 MINTESTSUITE = "ping"
@@ -62,8 +61,6 @@ TEST_SUITES ?= "${DEFAULT_TEST_SUITES}"
 
 TEST_QEMUBOOT_TIMEOUT ?= "1000"
 TEST_TARGET ?= "qemu"
-TEST_TARGET_IP ?= ""
-TEST_SERVER_IP ?= ""
 
 TESTIMAGEDEPENDS = ""
 TESTIMAGEDEPENDS_qemuall = "qemu-native:do_populate_sysroot 
qemu-helper-native:do_populate_sysroot"
@@ -108,97 +105,6 @@ do_testimage[nostamp] = "1"
 do_testimage[depends] += "${TESTIMAGEDEPENDS}"
 do_testimage[lockfiles] += "${TESTIMAGELOCK}"
 
-def exportTests(d,tc):
-import json
-import shutil
-import pkgutil
-import re
-
-exportpath = d.getVar("TEST_EXPORT_DIR", True)
-
-savedata = {}
-savedata["d"] = {}
-savedata["target"] = {}
-savedata["host_dumper"] = {}
-for key in tc.__dict__:
-# special cases
-if key not in ['d', 'target', 'host_dumper', 'suite']:
-savedata[key] = getattr(tc, key)
-savedata["target"]["ip"] = tc.target.ip or d.getVar("TEST_TARGET_IP", True)
-savedata["target"]["server_ip"] = tc.target.server_ip or 
d.getVar("TEST_SERVER_IP", True)
-
-keys = [ key for key in d.keys() if not key.startswith("_") and not 
key.startswith("BB") \
-and not key.startswith("B_pn") and not key.startswith("do_") and 
not d.getVarFlag(key, "func", True)]
-for key in keys:
-try:
-savedata["d"][key] = d.getVar(key, True)
-except bb.data_smart.ExpansionError:
-# we don't care about those anyway
-pass
-
-savedata["host_dumper"]["parent_dir"] = tc.host_dumper.parent_dir
-savedata["host_dumper"]["cmds"] = tc.host_dumper.cmds
-
-json_file = os.path.join(exportpath, "testdata.json")
-with open(json_file, "w") as f:
-json.dump(savedata, f, skipkeys=True, indent=4, sort_keys=True)
-
-# Replace absolute path with relative in the file
-exclude_path = os.path.join(d.getVar("COREBASE", True),'meta','lib','oeqa')
-f1 = open(json_file,'r').read()
-f2 = open(json_file,'w')
-m = f1.replace(exclude_path,'oeqa')
-f2.write(m)
-f2.close()
-
-# now start copying files
-# we'll basically copy everything under meta/lib/oeqa, with these 
exceptions
-#  - oeqa/targetcontrol.py - not needed
-#  - oeqa/selftest - something else
-# That means:
-#   - all tests from oeqa/runtime defined in TEST_SUITES (including from 
other layers)
-#   - the contents of oeqa/utils and oeqa/runtime/files
-#   - oeqa/oetest.py and oeqa/runexport.py (this will get copied to 
exportpath not exportpath/oeqa)
-#   - __init__.py files
-bb.utils.mkdirhier(os.path.join(exportpath, "oeqa/runtime/files"))
-bb.utils.mkdirhier(os.path.join(exportpath, "oeqa/utils"))
-# copy test modules, this should cover tests in other layers too
-bbpath = d.getVar("BBPATH", True).split(':')
-for t in tc.testslist:
-isfolder = False
-if re.search("\w+\.\w+\.test_\S+", t):
-t = '.'.join(t.split('.')[:3])
-mod = pkgutil.get_loader(t)
-# More depth than usual?
-if (t.count('.') > 2):
-for p in bbpath:
-foldername = os.path.join(p, 'lib',  
os.sep.join(t.split('.')).rsplit(os.sep, 1)[0])
-if os.path.isdir(foldername):
-isfolder = True
-target_folder = os.path.join(exportpath, "oeqa", 
"runtime", os.path.basename(foldername))
-if not os.path.exists(target_folder):
-shutil.copytree(foldername, target_folder)
-if not isfolder:
-shutil.copy2(mod.filename, os.path.join(exportpath, 
"oeqa/runtime"))
-# copy __init__.py files
-oeqadir = pkgutil.get_loader("oeqa").filename
-shutil.copy2(os.path.join(oeqadir, "__init__.py"), 
os.path.join(exportpath, "oeqa"))
-shutil.copy2(os.path.join(oeqadir, "runtime/__init__.py"), 
os.path.join(exportpath, "oeqa/runtime"))
-# copy oeqa/oetest.py and oeqa/runexported.py
-shutil.copy2(os.path.join(oeqadir, "oetest.py"), os.path.join(exportpath, 
"oeqa"))
-shutil.copy2(os.path.join(oeqadir, "runexported.py"), exportpath)
-# copy oeqa/utils/*.py
-for root, dirs, files in os.walk(os.path.join(oeqadir, "utils")):
-for f in files:
- 

[OE-core] [PATCH 0/6] Decouple testexport from testimage

[mariano . lopez]

From: Mariano Lopez 

Testexport is a feature that gets broken quite often,
this series of patches will decouple testexport from
testimage class in order to make it easier to spot errors,
easier to maintain, and easier to extend.

The following changes since commit f7b520878babbaa7527151f22c031ae160512753:

  poky: Switch to post release name/version (2016-04-29 07:58:46 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib mariano/export
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mariano/export

Mariano Lopez (6):
  oeqa/oetest.py: Add class ExportTestContext
  testexport.bbclass: Split testimage class
  oeqa/runexported.py: Remove host dumper
  testimage.bbclass: Remove exported test
  oetest.py: Add default pscmd to oeTest
  oetest.py: Use the real ExportTestContext in exported tests

 meta/classes/testexport.bbclass | 150 
 meta/classes/testimage.bbclass  | 137 +---
 meta/lib/oeqa/oetest.py |  60 ++--
 meta/lib/oeqa/runexported.py|  21 +-
 4 files changed, 209 insertions(+), 159 deletions(-)
 create mode 100644 meta/classes/testexport.bbclass

-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 2, 2016 at 8:34 PM, Khem Raj  wrote:

>
> > On May 2, 2016, at 1:09 PM, Christopher Larson 
> wrote:
> >
> > From: Christopher Larson 
> >
> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
> default to
> > this in the toolchain, while convenient, actually hides bugs, as a
> failure to
> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how
> we
> > poison the sysroot -- rather than relying on the default, notice right
> away if
> > somoeone isn't obeying the needed flags.
> >
> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
> failure,
> > which is what's often seen with external toolchains. This brings us all
> on the
> > same page, and makes sure a failure to obey LDFLAGS is seen early.
> >
>
>
> Default or gnu linkers is to use sysv for legacy reasons and by passing
> this option
> to configuring the toolchain we want to make sure that components are
> using sane defaults
> even if they have not configured these options.
>

But that's not what we want. We want to know when we're not passing
arguments we need to be passing. For example, the sysroot is poisoned
today, so we *know* when the user is trying to run it without --sysroot=.

if you do not pass the right linker flags from compiler driver and also
> ignore
> the LDFLAGS then you now have a safe pass for the app to build without GNU
> hash
> while I understand it will spread the external toolchain’s pains into
> internal toolchain
> I fail to understand the benefit of doing this otherwise.


Silently ignoring the fact that recipes ignore LDFLAGS is not good default
behavior, and this is precisely what oe-core is doing today. If you know of
a better way to detect that in another QA check, I'm certainly open to
hearing it.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

> On May 2, 2016, at 1:09 PM, Christopher Larson  wrote:
> 
> From: Christopher Larson 
> 
> We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
> this in the toolchain, while convenient, actually hides bugs, as a failure to
> obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> poison the sysroot -- rather than relying on the default, notice right away if
> somoeone isn't obeying the needed flags.
> 
> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> which is what's often seen with external toolchains. This brings us all on the
> same page, and makes sure a failure to obey LDFLAGS is seen early.
> 


Default or gnu linkers is to use sysv for legacy reasons and by passing this 
option
to configuring the toolchain we want to make sure that components are using 
sane defaults
even if they have not configured these options.

if you do not pass the right linker flags from compiler driver and also ignore
the LDFLAGS then you now have a safe pass for the app to build without GNU hash
while I understand it will spread the external toolchain’s pains into internal 
toolchain
I fail to understand the benefit of doing this otherwise.

> Signed-off-by: Christopher Larson 
> ---
> meta/recipes-devtools/gcc/gcc-4.9.inc | 1 -
> meta/recipes-devtools/gcc/gcc-5.3.inc | 1 -
> 2 files changed, 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
> b/meta/recipes-devtools/gcc/gcc-4.9.inc
> index 7e03f31..c187918 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.9.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
> @@ -111,7 +111,6 @@ EXTRA_OECONF_BASE = "\
> --disable-bootstrap \
> --disable-libmudflap \
> --with-system-zlib \
> ---with-linker-hash-style=${LINKER_HASH_STYLE} \
> --enable-linker-build-id \
> --with-ppl=no \
> --with-cloog=no \
> diff --git a/meta/recipes-devtools/gcc/gcc-5.3.inc 
> b/meta/recipes-devtools/gcc/gcc-5.3.inc
> index 9808be1..f2eda18 100644
> --- a/meta/recipes-devtools/gcc/gcc-5.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-5.3.inc
> @@ -112,7 +112,6 @@ EXTRA_OECONF_BASE = "\
> --disable-bootstrap \
> --disable-libmudflap \
> --with-system-zlib \
> ---with-linker-hash-style=${LINKER_HASH_STYLE} \
> --enable-linker-build-id \
> --with-ppl=no \
> --with-cloog=no \
> --
> 2.8.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 3/7] weston-init: Rework do_install to use install -D option

[Otavio Salvador]

The install -D allow for the parent directories to be created in a
single command line, reducing the code and number of fork during the
build.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/wayland/weston-init.bb | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston-init.bb 
b/meta/recipes-graphics/wayland/weston-init.bb
index 653541e..4ad62cf 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -8,11 +8,8 @@ SRC_URI = "file://init \
 S = "${WORKDIR}"
 
 do_install() {
-   install -d ${D}/${sysconfdir}/init.d
-   install -m755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
-
-   install -d ${D}${systemd_system_unitdir}
-   install -m0644 ${WORKDIR}/weston.service ${D}${systemd_system_unitdir}
+   install -Dm755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
+   install -Dm0644 ${WORKDIR}/weston.service 
${D}${systemd_system_unitdir}/weston.service
 }
 
 inherit allarch update-rc.d distro_features_check systemd
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 7/7] xserver-xorg: Add Xwayland initialization support using weston-start

[Otavio Salvador]

The weston-start script now supports loading modules so the Xwayland
support can be loaded optionally. Use this to load Weston accordingly.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc  | 9 +++--
 meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland | 6 ++
 2 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index f4c5469..10f5b69 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -16,7 +16,8 @@ PE = "2"
 INC_PR = "r8"
 
 XORG_PN = "xorg-server"
-SRC_URI = "${XORG_MIRROR}/individual/xserver/${XORG_PN}-${PV}.tar.bz2"
+SRC_URI = "${XORG_MIRROR}/individual/xserver/${XORG_PN}-${PV}.tar.bz2 \
+   file://xwayland"
 SRC_URI += "file://macro_tweak.patch"
 
 S = "${WORKDIR}/${XORG_PN}-${PV}"
@@ -85,7 +86,7 @@ FILES_${PN}-fbdev = "${bindir}/Xfbdev"
 FILES_${PN}-xvfb = "${bindir}/Xvfb"
 FILES_${PN}-utils = "${bindir}/scanpci ${bindir}/pcitweak ${bindir}/ioport 
${bindir}/in[bwl] ${bindir}/out[bwl] ${bindir}/mmap[rw] ${bindir}/gtf 
${bindir}/getconfig ${bindir}/getconfig.pl"
 FILES_${PN}-xephyr = "${bindir}/Xephyr"
-FILES_${PN}-xwayland = "${bindir}/Xwayland"
+FILES_${PN}-xwayland = "${bindir}/Xwayland ${datadir}/weston-start"
 FILES_${PN}-multimedia-modules = "${libdir}/xorg/modules/multimedia/*drv*"
 FILES_${PN}-extension-dri = "${libdir}/xorg/modules/extensions/libdri.so"
 FILES_${PN}-extension-dri2 = "${libdir}/xorg/modules/extensions/libdri2.so"
@@ -146,6 +147,10 @@ PACKAGECONFIG[nettle] = "--with-sha1=libnettle,,nettle"
 PACKAGECONFIG[gcrypt] = "--with-sha1=libgcrypt,,libgcrypt"
 
 do_install_append () {
+   if [ "${@bb.utils.contains('PACKAGECONFIG', 'xwayland', 'yes', 'no', 
d)}" = "yes" ]; then
+  install -Dm 644 ${WORKDIR}/xwayland 
${D}${datadir}/weston-start/xwayland
+   fi
+
# Its assumed base-files creates this for us
rmdir ${D}${localstatedir}/log/
 }
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland
new file mode 100644
index 000..9499f25
--- /dev/null
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+mkdir -p /tmp/.X11-unix
+
+use_launch
+add_weston_argument "--modules=xwayland.so"
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 2/7] weston: Remove XWayland dependencies on PACKAGECONFIG

[Otavio Salvador]

Instead of adding partial dependencies we list the PACKAGECONFIG
options that are required. Those are: X11, Wayland and PAM.

The previous value were redudant with X11 PACKAGECONFIG option and as
it is a requirement, for XWayland, it can be removed to easy
maintenance.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/wayland/weston_1.9.0.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston_1.9.0.bb 
b/meta/recipes-graphics/wayland/weston_1.9.0.bb
index 370c38c..8940410 100644
--- a/meta/recipes-graphics/wayland/weston_1.9.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.9.0.bb
@@ -73,8 +73,8 @@ PACKAGECONFIG[webp] = "--enable-webp,--disable-webp,libwebp"
 PACKAGECONFIG[libunwind] = "--enable-libunwind,--disable-libunwind,libunwind"
 # Weston with systemd-login support
 PACKAGECONFIG[systemd] = 
"--enable-systemd-login,--disable-systemd-login,systemd dbus"
-# Weston with Xwayland support
-PACKAGECONFIG[xwayland] = "--enable-xwayland,--disable-xwayland,libxcb 
libxcursor cairo"
+# Weston with Xwayland support (requires X11, Wayland and PAM)
+PACKAGECONFIG[xwayland] = "--enable-xwayland,--disable-xwayland"
 # colord CMS support
 PACKAGECONFIG[colord] = "--enable-colord,--disable-colord,colord"
 
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 5/7] weston-init: Error out if loading a nested instance

[Otavio Salvador]

The Weston nested instance support is not implemented. This errors out
displaying an informative error message so someone insterested on it
may look at implement this later.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/wayland/weston-init/weston-start | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index eb4b600..ff52ba3 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -14,6 +14,11 @@ if test $# -lt 2; then
exit 1
 fi
 
+if [ -n "$WAYLAND_DISPLAY" ]; then
+   echo "ERROR: A Wayland compositor is already running, nested Weston 
instance is not supported yet."
+   exit 1
+fi
+
 openvt_args=""
 while [ -n "$1" ]; do
openvt_args="$openvt_args $1"
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 4/7] weston-init: Rework init sequence to avoid code duplication

[Otavio Salvador]

The new 'weston-start' script redcues the code duplication for SysV
and SystemD based images.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/wayland/weston-init.bb   |  4 ++-
 meta/recipes-graphics/wayland/weston-init/init |  9 +-
 .../wayland/weston-init/weston-start   | 36 ++
 .../wayland/weston-init/weston.service |  5 +--
 4 files changed, 41 insertions(+), 13 deletions(-)
 create mode 100755 meta/recipes-graphics/wayland/weston-init/weston-start

diff --git a/meta/recipes-graphics/wayland/weston-init.bb 
b/meta/recipes-graphics/wayland/weston-init.bb
index 4ad62cf..3a2251e 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -3,13 +3,15 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
 
 SRC_URI = "file://init \
-   file://weston.service"
+   file://weston.service \
+   file://weston-start"
 
 S = "${WORKDIR}"
 
 do_install() {
install -Dm755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
install -Dm0644 ${WORKDIR}/weston.service 
${D}${systemd_system_unitdir}/weston.service
+   install -Dm755 ${WORKDIR}/weston-start ${D}${bindir}/weston-start
 }
 
 inherit allarch update-rc.d distro_features_check systemd
diff --git a/meta/recipes-graphics/wayland/weston-init/init 
b/meta/recipes-graphics/wayland/weston-init/init
index 2e938f4..5c925f4 100644
--- a/meta/recipes-graphics/wayland/weston-init/init
+++ b/meta/recipes-graphics/wayland/weston-init/init
@@ -31,14 +31,7 @@ case "$1" in
   start)
 . /etc/profile
 
-# This is all a nasty hack
-if test -z "$XDG_RUNTIME_DIR"; then
-export XDG_RUNTIME_DIR=/run/user/root
-mkdir --parents $XDG_RUNTIME_DIR
-chmod 0700 $XDG_RUNTIME_DIR
-fi
-
-openvt -s weston -- $OPTARGS
+weston-start -s -- $OPTARGS
   ;;
 
   stop)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
new file mode 100755
index 000..eb4b600
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -0,0 +1,36 @@
+#!/bin/sh
+# Copyright (C) 2016 O.S. Systems Software LTDA.
+
+export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
+
+usage() {
+cat < -- 
+EOF
+}
+
+if test $# -lt 2; then
+   usage
+   exit 1
+fi
+
+openvt_args=""
+while [ -n "$1" ]; do
+   openvt_args="$openvt_args $1"
+   shift
+
+   if [ "$1" = "--" ]; then
+   shift
+   break
+   fi
+done
+
+weston_args=$*
+
+if test -z "$XDG_RUNTIME_DIR"; then
+export XDG_RUNTIME_DIR=/run/user/`id -u`
+mkdir --parents $XDG_RUNTIME_DIR
+chmod 0700 $XDG_RUNTIME_DIR
+fi
+
+exec openvt "$openvt_args" weston -- $weston_args /var/log/weston.log 2>&1
diff --git a/meta/recipes-graphics/wayland/weston-init/weston.service 
b/meta/recipes-graphics/wayland/weston-init/weston.service
index 4f1f7ff..f61d353 100644
--- a/meta/recipes-graphics/wayland/weston-init/weston.service
+++ b/meta/recipes-graphics/wayland/weston-init/weston.service
@@ -5,10 +5,7 @@ RequiresMountsFor=/run
 [Service]
 User=root
 EnvironmentFile=-/etc/default/weston
-Environment="XDG_RUNTIME_DIR=/run/user/root"
-ExecStartPre=/bin/mkdir -p /run/user/root
-ExecStartPre=/bin/chmod 0700 /run/user/root
-ExecStart=/usr/bin/openvt -v -e /usr/bin/weston -- $OPTARGS
+ExecStart=/usr/bin/weston-start -v -e -- $OPTARGS
 
 [Install]
 WantedBy=multi-user.target
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 6/7] weston-init: Add module support for the weston-start helper

[Otavio Salvador]

To make weston-start more flexible we now support module loading. For
such modules, following functions can be used:

 - add_weston_argument
 - add_openvt_argument
 - use_launch

Signed-off-by: Otavio Salvador 
---

 .../wayland/weston-init/weston-start   | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index ff52ba3..63a459e 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -9,6 +9,24 @@ usage() {
 EOF
 }
 
+## Module support
+modules_dir=/usr/share/weston-start
+
+# Add weston extra argument
+add_weston_argument() {
+   weston_args="$weston_args $1"
+}
+
+# Add openvt extra argument
+add_openvt_argument() {
+   openvt_args="$openvt_args $1"
+}
+
+# Use weston-launch for initialization
+use_launch() {
+   use_weston_launch=1
+}
+
 if test $# -lt 2; then
usage
exit 1
@@ -32,10 +50,29 @@ done
 
 weston_args=$*
 
+# Load and run modules
+if [ -d "$modules_dir" ]; then
+   for m in "$modules_dir"/*; do
+   # Skip backup files
+   if [ "`echo $m | sed -e 's/\~$//'`" != "$m" ]; then
+   continue
+   fi
+
+   # process module
+   . $m
+   done
+fi
+
+if [ "$use_weston_launch" = "1" ]; then
+   weston_init=weston-launch
+else
+   weston_init=weston
+fi
+
 if test -z "$XDG_RUNTIME_DIR"; then
 export XDG_RUNTIME_DIR=/run/user/`id -u`
 mkdir --parents $XDG_RUNTIME_DIR
 chmod 0700 $XDG_RUNTIME_DIR
 fi
 
-exec openvt "$openvt_args" weston -- $weston_args /var/log/weston.log 2>&1
+exec openvt "$openvt_args" "$weston_init" -- $weston_args /var/log/weston.log 
2>&1
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 1/7] weston: Enable XWayland when X11 and Wayland support are available

[Otavio Salvador]

When the DISTRO has X11, Wayland and PAM support enabled, XWayland ought to
be enabled by default.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-graphics/wayland/weston_1.9.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/wayland/weston_1.9.0.bb 
b/meta/recipes-graphics/wayland/weston_1.9.0.bb
index 16a788d..370c38c 100644
--- a/meta/recipes-graphics/wayland/weston_1.9.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.9.0.bb
@@ -40,6 +40,7 @@ EXTRA_OECONF_append_qemux86-64 = "\
"
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms 
fbdev wayland egl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', 
d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland pam', 
'xwayland', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'launch', 
'', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'systemd', '', d)} \
   "
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core PATCH 0/7] Improve Xwayland integration

[Otavio Salvador]

Up to now, to make Xwayland to work it required several manual hacks
and it was difficult to make an image which had support for it out of
box.

This patchset intends to set the base for it. It enables weston-init
to be extended to support Xwayland launch when needed.

There are still some issues to be done:

 - how to make Xwayland fit on the packagegroups?
 - does core-image.bbclass ought to include a xwayland feature?

Yet, this patchset seems good to be reviewed and possibly merged.


Otavio Salvador (7):
  weston: Enable XWayland when X11 and Wayland support are available
  weston: Remove XWayland dependencies on PACKAGECONFIG
  weston-init: Rework do_install to use install -D option
  weston-init: Rework init sequence to avoid code duplication
  weston-init: Error out if loading a nested instance
  weston-init: Add module support for the weston-start helper
  xserver-xorg: Add Xwayland initialization support using weston-start

 meta/recipes-graphics/wayland/weston-init.bb   | 11 ++-
 meta/recipes-graphics/wayland/weston-init/init |  9 +--
 .../wayland/weston-init/weston-start   | 78 ++
 .../wayland/weston-init/weston.service |  5 +-
 meta/recipes-graphics/wayland/weston_1.9.0.bb  |  5 +-
 .../recipes-graphics/xorg-xserver/xserver-xorg.inc |  9 ++-
 .../xorg-xserver/xserver-xorg/xwayland |  6 ++
 7 files changed, 101 insertions(+), 22 deletions(-)
 create mode 100755 meta/recipes-graphics/wayland/weston-init/weston-start
 create mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/xwayland

-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

From: Christopher Larson 

We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
this in the toolchain, while convenient, actually hides bugs, as a failure to
obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
poison the sysroot -- rather than relying on the default, notice right away if
somoeone isn't obeying the needed flags.

This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
which is what's often seen with external toolchains. This brings us all on the
same page, and makes sure a failure to obey LDFLAGS is seen early.

Signed-off-by: Christopher Larson 
---
 meta/recipes-devtools/gcc/gcc-4.9.inc | 1 -
 meta/recipes-devtools/gcc/gcc-5.3.inc | 1 -
 2 files changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 7e03f31..c187918 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -111,7 +111,6 @@ EXTRA_OECONF_BASE = "\
 --disable-bootstrap \
 --disable-libmudflap \
 --with-system-zlib \
---with-linker-hash-style=${LINKER_HASH_STYLE} \
 --enable-linker-build-id \
 --with-ppl=no \
 --with-cloog=no \
diff --git a/meta/recipes-devtools/gcc/gcc-5.3.inc 
b/meta/recipes-devtools/gcc/gcc-5.3.inc
index 9808be1..f2eda18 100644
--- a/meta/recipes-devtools/gcc/gcc-5.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-5.3.inc
@@ -112,7 +112,6 @@ EXTRA_OECONF_BASE = "\
 --disable-bootstrap \
 --disable-libmudflap \
 --with-system-zlib \
---with-linker-hash-style=${LINKER_HASH_STYLE} \
 --enable-linker-build-id \
 --with-ppl=no \
 --with-cloog=no \
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [OE-Core][PATCH] git: update to 2.8.2

[Dan McGregor]

From: Dan McGregor 

Now that krogoth has been released, update git to the latest release.

Signed-off-by: Dan McGregor 
---
 meta/recipes-devtools/git/{git_2.7.4.bb => git_2.8.2.bb} | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/git/{git_2.7.4.bb => git_2.8.2.bb} (39%)

diff --git a/meta/recipes-devtools/git/git_2.7.4.bb 
b/meta/recipes-devtools/git/git_2.8.2.bb
similarity index 39%
rename from meta/recipes-devtools/git/git_2.7.4.bb
rename to meta/recipes-devtools/git/git_2.8.2.bb
index bc72793..b3ce4f8 100644
--- a/meta/recipes-devtools/git/git_2.7.4.bb
+++ b/meta/recipes-devtools/git/git_2.8.2.bb
@@ -5,7 +5,7 @@ EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
  "
 EXTRA_OEMAKE += "NO_GETTEXT=1"
 
-SRC_URI[tarball.md5sum] = "c64012d491e24c7d65cd389f75383d91"
-SRC_URI[tarball.sha256sum] = 
"7104c4f5d948a75b499a954524cb281fe30c6649d8abe20982936f75ec1f275b"
-SRC_URI[manpages.md5sum] = "58020dc13a5801c49f7986fef7027535"
-SRC_URI[manpages.sha256sum] = 
"0dfe1931ad302873470e0280248e3aa50502b5edd00dcc3e9c9173667b6fea6a"
+SRC_URI[tarball.md5sum] = "3022d8ebf64b35b9704d5adf54b256f9"
+SRC_URI[tarball.sha256sum] = 
"a029c37ee2e0bb1efea5c4af827ff5afdb3356ec42fc19c1d40216d99e97e148"
+SRC_URI[manpages.md5sum] = "8c9da11aeb45b4a286ba766e25aaf3ab"
+SRC_URI[manpages.sha256sum] = 
"82d322211aade626d1eb3bcf3b76730bfdd2fcc9c189950fb0a8bdd69c383e2f"
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] git: update to 2.8.2

[Dan McGregor]

From: Dan McGregor 

Now that krogoth has been released, update git to the latest release.

Signed-off-by: Dan McGregor 
---
 meta/recipes-devtools/git/{git_2.7.4.bb => git_2.8.2.bb} | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/git/{git_2.7.4.bb => git_2.8.2.bb} (39%)

diff --git a/meta/recipes-devtools/git/git_2.7.4.bb 
b/meta/recipes-devtools/git/git_2.8.2.bb
similarity index 39%
rename from meta/recipes-devtools/git/git_2.7.4.bb
rename to meta/recipes-devtools/git/git_2.8.2.bb
index bc72793..b3ce4f8 100644
--- a/meta/recipes-devtools/git/git_2.7.4.bb
+++ b/meta/recipes-devtools/git/git_2.8.2.bb
@@ -5,7 +5,7 @@ EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
  "
 EXTRA_OEMAKE += "NO_GETTEXT=1"
 
-SRC_URI[tarball.md5sum] = "c64012d491e24c7d65cd389f75383d91"
-SRC_URI[tarball.sha256sum] = 
"7104c4f5d948a75b499a954524cb281fe30c6649d8abe20982936f75ec1f275b"
-SRC_URI[manpages.md5sum] = "58020dc13a5801c49f7986fef7027535"
-SRC_URI[manpages.sha256sum] = 
"0dfe1931ad302873470e0280248e3aa50502b5edd00dcc3e9c9173667b6fea6a"
+SRC_URI[tarball.md5sum] = "3022d8ebf64b35b9704d5adf54b256f9"
+SRC_URI[tarball.sha256sum] = 
"a029c37ee2e0bb1efea5c4af827ff5afdb3356ec42fc19c1d40216d99e97e148"
+SRC_URI[manpages.md5sum] = "8c9da11aeb45b4a286ba766e25aaf3ab"
+SRC_URI[manpages.sha256sum] = 
"82d322211aade626d1eb3bcf3b76730bfdd2fcc9c189950fb0a8bdd69c383e2f"
-- 
2.8.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] sshcontrol.py: Add methods to copy dirs and delete files

[mariano . lopez]

From: Mariano Lopez 

This patch add new methods to SSHControl class. These methods
include:
- Copy a dir to DUT
- Delete a file in the DUT
- Delete a directory in the DUT (if empty)
- Delete a directory structure in the DUT

[YOCTO #9565]

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/utils/sshcontrol.py | 83 +++
 1 file changed, 83 insertions(+)

diff --git a/meta/lib/oeqa/utils/sshcontrol.py 
b/meta/lib/oeqa/utils/sshcontrol.py
index 1658744..15618cc 100644
--- a/meta/lib/oeqa/utils/sshcontrol.py
+++ b/meta/lib/oeqa/utils/sshcontrol.py
@@ -151,3 +151,86 @@ class SSHControl(object):
 def copy_from(self, remotepath, localpath):
 command = self.scp + ['%s@%s:%s' % (self.user, self.ip, remotepath), 
localpath]
 return self._internal_run(command, ignore_status=False)
+
+def copy_dir_to(self, localpath, remotepath):
+"""
+Copy recursively localpath directory to remotepath in target.
+"""
+
+for root, dirs, files in os.walk(localpath):
+# Create directories in the target as needed
+for d in dirs:
+tmp_dir = os.path.join(root, d).replace(localpath, "")
+new_dir = os.path.join(remotepath, tmp_dir.lstrip("/"))
+cmd = "mkdir -p %s" % new_dir
+self.run(cmd)
+
+# Copy files into the target
+for f in files:
+tmp_file = os.path.join(root, f).replace(localpath, "")
+dst_file = os.path.join(remotepath, tmp_file.lstrip("/"))
+src_file = os.path.join(root, f)
+self.copy_to(src_file, dst_file)
+
+
+def delete_files(self, remotepath, files):
+"""
+Delete files in target's remote path.
+"""
+
+cmd = "rm"
+if not isinstance(files, list):
+files = [files]
+
+for f in files:
+cmd = "%s %s" % (cmd, os.path.join(remotepath, f))
+
+self.run(cmd)
+
+
+def delete_dir(self, remotepath):
+"""
+Delete remotepath directory in target.
+"""
+
+cmd = "rmdir %s" % remotepath
+self.run(cmd)
+
+
+def delete_dir_structure(self, localpath, remotepath):
+"""
+Delete recursively localpath structure directory in target's 
remotepath.
+
+This function is very usefult to delete a package that is installed in
+the DUT and the host running the test has such package extracted in tmp
+directory.
+
+Example:
+pwd: /home/user/tmp
+tree:   .
+└── work
+├── dir1
+│   └── file1
+└── dir2
+
+localpath = "/home/user/tmp" and remotepath = "/home/user"
+
+With the above variables this function will try to delete the
+directory in the DUT in this order:
+/home/user/work/dir1/file1
+/home/user/work/dir1(if dir is empty)
+/home/user/work/dir2(if dir is empty)
+/home/user/work (if dir is empty)
+"""
+
+for root, dirs, files in os.walk(localpath, topdown=False):
+# Delete files first
+tmpdir = os.path.join(root).replace(localpath, "")
+remotedir = os.path.join(remotepath, tmpdir.lstrip("/"))
+self.delete_files(remotedir, files)
+
+# Remove dirs if empty
+for d in dirs:
+tmpdir = os.path.join(root, d).replace(localpath, "")
+remotedir = os.path.join(remotepath, tmpdir.lstrip("/"))
+self.delete_dir(remotepath)
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [for-master][RFC PATCH 0/3] Support template files for wic wks

[Christopher Larson]

On Mon, May 2, 2016 at 7:23 PM, Christopher Larson 
wrote:

> From: Christopher Larson 
>
> This adds support for .wks.in files as WKS_FILE.
>
> These files are treated as the contents of a bitbake variable, so usual
> bitbake variable references are supported. I considered using another
> templating mechanism, for example the one used by yocto-layer, but then
> we'd
> end up largely mapping metadata variables to template fields anyway, which
> is
> a pointless indirection. Let bitbake expand the variables directly instead.
>
> This feature lets us, for example, reference ${APPEND} in --append, and
> avoid
> hardcoding the serial console tty in the wks file, and let the user's
> changes
> to APPEND affect wic the way they do the other image construction
> mechanisms.
>
> The template is read in and set in a variable at parse time, so changes to
> the
> variables referenced by the template will result in rebuilding the image.
>
> It's been suggested that the name should better reflect how its contents
> are
> used, i.e. .bbin or so. I've also considered including something like
> 'bbv' or
> similar, to indicate its contents are that of a bitbake value. I think this
> should be discussed.
>
> I'd love to hear questions or comments on this. I think the value is clear,
> and it's something we need to solve, but I'd like to hear if others agree
> or
> disagree on that, and whether this implementation is appropriate.


One downside to this approach is, afaik,  that it's the first serious
deviation between wic outside and wic as an image type. One alternative
would be to parse the template at parse time to inject vars into WICVARS,
but let wic process the template, but then of course a change to the
template without re-running bitabke wouldn't update WICVARS and the written
env files.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [for-master][RFC PATCH 3/3] image_types.bbclass: support template .wks.in files for wic

[Christopher Larson]

From: Christopher Larson 

These files are treated as the contents of a bitbake variable, so usual
bitbake variable references are supported. I considered using another
templating mechanism, for example the one used by yocto-layer, but then we'd
end up largely mapping metadata variables to template fields anyway, which is
a pointless indirection. Let bitbake expand the variables directly instead.

This feature lets us, for example, reference ${APPEND} in --append, and avoid
hardcoding the serial console tty in the wks file, and let the user's changes
to APPEND affect wic the way they do the other image construction mechanisms.

The template is read in and set in a variable at parse time, so changes to the
variables referenced by the template will result in rebuilding the image.

Signed-off-by: Christopher Larson 
---
 meta/classes/image_types.bbclass | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index eed0373..90b5a46 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -206,6 +206,16 @@ IMAGE_CMD_wic () {
 }
 IMAGE_CMD_wic[vardepsexclude] = "WKS_FULL_PATH WKS_FILES"
 
+python process_wks_template () {
+"""Write out expanded template contents to WKS_FULL_PATH."""
+template_body = d.getVar('_WKS_TEMPLATE', True)
+if template_body:
+wks_file = d.getVar('WKS_FULL_PATH', True)
+with open(wks_file, 'w') as f:
+f.write(template_body)
+}
+do_image_wic[prefuncs] += 'process_wks_template'
+
 # Rebuild when the wks file or vars in WICVARS change
 USING_WIC = "${@bb.utils.contains_any('IMAGE_FSTYPES', 'wic ' + ' 
'.join('wic.%s' % c for c in '${COMPRESSIONTYPES}'.split()), '1', '', d)}"
 WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' % 
os.path.exists('${WKS_FULL_PATH}') if '${USING_WIC}' else ''}"
@@ -298,3 +308,28 @@ IMAGE_TYPES_MASKED ?= ""
 # The WICVARS variable is used to define list of bitbake variables used in wic 
code
 # variables from this list is written to .env file
 WICVARS ?= "BBLAYERS DEPLOY_DIR_IMAGE HDDDIR IMAGE_BASENAME IMAGE_BOOT_FILES 
IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES INITRD ISODIR MACHINE_ARCH 
ROOTFS_SIZE STAGING_DATADIR STAGING_DIR_NATIVE STAGING_LIBDIR TARGET_SYS"
+
+python () {
+"""Read in and set up wks file template for wic."""
+if d.getVar('USING_WIC', True):
+wks_file_u = d.getVar('WKS_FULL_PATH', False)
+wks_file = d.expand(wks_file_u)
+base, ext = os.path.splitext(wks_file)
+if ext == '.in' and os.path.exists(wks_file):
+wks_out_file = os.path.join(d.getVar('WORKDIR', True), 
os.path.basename(base))
+d.setVar('WKS_FULL_PATH', wks_out_file)
+d.setVar('WKS_TEMPLATE_PATH', wks_file_u)
+d.setVar('WKS_FILE_CHECKSUM', '${WKS_TEMPLATE_PATH}:True')
+
+try:
+with open(wks_file, 'r') as f:
+body = f.read()
+except (IOError, OSError) as exc:
+pass
+else:
+# Previously, I used expandWithRefs to get the dependency list
+# and add it to WICVARS, but there's no point re-parsing the
+# file in process_wks_template as well, so just put it in
+# a variable and let the metadata deal with the deps.
+d.setVar('_WKS_TEMPLATE', body)
+}
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [for-master][RFC PATCH 1/3] image.bbclass: append to prefuncs/postfuncs for do_image_*

[Christopher Larson]

From: Christopher Larson 

These are list style variables, so append to them rather than blowing away any
existing value.

Signed-off-by: Christopher Larson 
---
 meta/classes/image.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 4542e95..bcb96aa 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -436,9 +436,9 @@ python () {
 d.setVar('do_image_%s' % t, '\n'.join(cmds))
 d.setVarFlag('do_image_%s' % t, 'func', '1')
 d.setVarFlag('do_image_%s' % t, 'fakeroot', '1')
-d.setVarFlag('do_image_%s' % t, 'prefuncs', debug + 'set_image_size')
-d.setVarFlag('do_image_%s' % t, 'postfuncs', 'create_symlinks')
 d.setVarFlag('do_image_%s' % t, 'subimages', ' '.join(subimages))
+d.appendVarFlag('do_image_%s' % t, 'prefuncs', ' ' + debug + 
'set_image_size')
+d.appendVarFlag('do_image_%s' % t, 'postfuncs', ' create_symlinks')
 d.appendVarFlag('do_image_%s' % t, 'vardeps', ' '.join(vardeps))
 d.appendVarFlag('do_image_%s' % t, 'vardepsexclude', 'DATETIME')
 
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [for-master][RFC PATCH 2/3] image_types.bbclass: add intermediate var for WKS_FILE_CHECKSUM

[Christopher Larson]

From: Christopher Larson 

This is a bit nicer to work with, and easier to override.

Signed-off-by: Christopher Larson 
---
 meta/classes/image_types.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 53af7ca..eed0373 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -208,7 +208,8 @@ IMAGE_CMD_wic[vardepsexclude] = "WKS_FULL_PATH WKS_FILES"
 
 # Rebuild when the wks file or vars in WICVARS change
 USING_WIC = "${@bb.utils.contains_any('IMAGE_FSTYPES', 'wic ' + ' 
'.join('wic.%s' % c for c in '${COMPRESSIONTYPES}'.split()), '1', '', d)}"
-do_image_wic[file-checksums] += "${@'${WKS_FULL_PATH}:%s' % 
os.path.exists('${WKS_FULL_PATH}') if '${USING_WIC}' else ''}"
+WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' % 
os.path.exists('${WKS_FULL_PATH}') if '${USING_WIC}' else ''}"
+do_image_wic[file-checksums] += "${WKS_FILE_CHECKSUM}"
 
 EXTRA_IMAGECMD = ""
 
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [for-master][RFC PATCH 0/3] Support template files for wic wks

[Christopher Larson]

From: Christopher Larson 

This adds support for .wks.in files as WKS_FILE.

These files are treated as the contents of a bitbake variable, so usual
bitbake variable references are supported. I considered using another
templating mechanism, for example the one used by yocto-layer, but then we'd
end up largely mapping metadata variables to template fields anyway, which is
a pointless indirection. Let bitbake expand the variables directly instead.

This feature lets us, for example, reference ${APPEND} in --append, and avoid
hardcoding the serial console tty in the wks file, and let the user's changes
to APPEND affect wic the way they do the other image construction mechanisms.

The template is read in and set in a variable at parse time, so changes to the
variables referenced by the template will result in rebuilding the image.

It's been suggested that the name should better reflect how its contents are
used, i.e. .bbin or so. I've also considered including something like 'bbv' or
similar, to indicate its contents are that of a bitbake value. I think this
should be discussed.

I'd love to hear questions or comments on this. I think the value is clear,
and it's something we need to solve, but I'd like to hear if others agree or
disagree on that, and whether this implementation is appropriate.


The following changes since commit 1a0e56630c5c27d8899dd0979ae0b86bbe227881:

  utils.bbclass: note for deprecated base_contains (2016-04-29 07:53:58 +0100)

are available in the git repository at:

  git://github.com/kergoth/openembedded-core wks.in
  https://github.com/kergoth/openembedded-core/tree/wks.in

Christopher Larson (3):
  image.bbclass: append to prefuncs/postfuncs for do_image_*
  image_types.bbclass: add intermediate var for WKS_FILE_CHECKSUM
  image_types.bbclass: support template .wks.in files for wic

 meta/classes/image.bbclass   |  4 ++--
 meta/classes/image_types.bbclass | 38 +-
 2 files changed, 39 insertions(+), 3 deletions(-)

-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Make runqemu knows nothing about machine

[Randy Witt]

On 04/29/2016 03:09 AM, Robert Yang wrote:



On 04/29/2016 05:45 PM, Richard Purdie wrote:

On Tue, 2016-04-26 at 11:42 +0800, Robert Yang wrote:

Hello,

The qemu-native can boot a lot of machines, but oe-core's runqemu can
only
boot a few of them which are hardcoded into runqemu. I'd like to
change
it little to make it drop the hardcode and can boot more machines.
Here
are some basic thoughts, please feel free to give your comments.

runqemu is a helpful script which can help us boot images easily, but
it
has a lot of hard code for machine + args. I'd like to remove these
from
runqemu, and make it as a frame. The logical is that, who knows
clearly
about whether qemu can boot the machine and how to boot it (args),
the
answer is the machine/bsp developer, so we can:

* Add a var like QEMU_SUPPORTED = "yes/no" in the bsp conf file
(default to no)
* Add a var like QEMU_BOOT_ARGS = "foo" if there are special args.
* Let do_rootfs or do_image_foo write data such as QEMU_BOOT_ARGS to
DEPLOY_DIR_IMAGE/runqemu/ or tmp/deploy/images/runqemu/, we can
treat
the "runqemu/" dir as a database, and anything we need there, for
example,
efi/pcbios, root args, and so on. We won't miss anything since all
the
images which can be boot by runqemu are built by oe-core.
* Then we can easily add supported machine to runqemu from the bsp
itself
without change runqemu.

I will start working on it if there is no objections, and make sure
it won't
break any current supported machines.


I guess we have some decisions to make. Firstly, is that script better
in shell or python at this point? Originally, shell made sense but I'm
starting to wonder if it would be clearer in python.

If we left it as shell, I'd envisaged it going through something like
BBPATH and sourcing files from each of the layers to build up its own
list of supported machines. The trouble is we can't easily get BBPATH
in the shell environment since we can't assume bitbake and we ideally
want it to work outside of our build environment.


Thanks for the reply, my thought is that move part of the implementation
into a class called runqemu.bbclass (or other names), and leave the runqemu
as a shell script, when QEMU_BOOT_SUPPORTED = "1", runqemu.bbclass will
create a:
tmp/deploy/images//runqemu

And the content in runqemu can be: (for example, arm)
QEMU="/path/to/sysroots/x86_64-linux/usr/bin/qemu-system-arm -m 128 -machine
versatilepb  "
TUNE_ARCH="arm"
QEMU_DEFAULT_KERNEL="zImage-qemuarm.bin"
QEMU_DEFAULT_FSTYPE="ext4"
QEMU_MEM="-m 128"
[maybe more]


Would it be better to just have a meta-qemu-config-[whateverarch]-native that 
publishes the config file? Then it could also publish the config in different 
forms such as  json/yaml/ini for users who don't want to use runqemu, but still 
need to know the *required* args. They might want to ignore the rest.



All of these variables can be defined in bsp layer or conf files. I will
add some default values there according to TUNE_ARCH, so that the bsp may
not need do anything to boot from qemu when QEMU_BOOT_SUPPORTED = "1".

// Robert



With the development of devtool, I'm wondering if runqemu should become
another such "command", written in python and working in any of the
environments we'd expect devtool to work (eSDK, main build). If we did
that, we'd have the layers and could easily access BBPATH and search
for additional modules to add support for additional machines.

Thoughts?

Cheers,

Richard





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] busybox: Add support for busybox-init

[Denys Dmytriyenko]

On Tue, Feb 02, 2016 at 03:29:43PM +, Richard Purdie wrote:
> On Tue, 2016-02-02 at 16:00 +0100, Patrick Ohly wrote:
> > On Mon, 2016-02-01 at 08:57 -0800, Khem Raj wrote:
> > > On Mon, Feb 1, 2016 at 12:14 AM, Patrick Ohly <
> > > patrick.o...@intel.com> wrote:
> > > > On Mon, 2016-01-25 at 11:39 -0800, Andre McCurdy wrote:
> > > > > > +if grep "CONFIG_INIT=y" ${B}/.config; then
> > > > > > +install -D -m 0777 ${WORKDIR}/rcS
> > > > > ${D}${sysconfdir}/init.d/rcS
> > > > > > +install -D -m 0777 ${WORKDIR}/rcK
> > > > > ${D}${sysconfdir}/init.d/rcK
> > > > > > +install -D -m 0755 ${WORKDIR}/runlevel
> > > > > ${D}${base_sbindir}/runlevel
> > > > > > +if grep "CONFIG_FEATURE_USE_INITTAB=y"
> > > > > ${B}/.config; then
> > > > > > +install -D -m 0777
> > > > > > ${WORKDIR}/inittab
> > > > > ${D}${sysconfdir}/inittab
> > > > > > +tmp="${SERIAL_CONSOLES}"
> > > > > > +for i in $tmp
> > > > > > +do
> > > > > > +j=`echo ${i} | sed s/\;/\
> > > > > > /g`
> > > > > > +label=`echo ${i} | sed -e
> > > > > > 's/tty//'
> > > > > -e 's/^.*;//' -e 's/;.*//'`
> > > > > > +echo "tty$label::respawn:
> > > > > ${base_sbindir}/getty ${j}" >> ${D}${sysconfdir}/inittab
> > > > > > +done
> > > > > > +fi
> > > > > > +fi
> > > > 
> > > > SERIAL_CONSOLES is typically set differently for different
> > > > machines. But
> > > > busybox is not machine-specific, therefore using SERIAL_CONSOLE
> > > > like
> > > > this prevents sstate/package reuse or worse, causes package
> > > > versioning
> > > > problems.
> > > 
> > > when busybox is used as init system then it becomes machine
> > > specific and we have
> > > a choice to do so which is disabled by default.
> > 
> > In my case, busybox is not the init system and the recipe is
> > therefore
> > not machine specific. But the code above is active and thus
> > introduces a
> > sstate dependency on the machine-specific SERIAL_CONSOLES anyway,
> > even
> > though the code is dead (if check never reaches it).
> > 
> > The code would have to be added conditionally, and only when it is
> > okay
> > to reference ${SERIAL_CONSOLES}.
> 
> I think we should split this init piece out into a separate recipe,
> which busybox can depend on if/as/when needed.

What is the status of this request? Currently busybox is wreaking havoc in our 
multi-machine builds due to SERIAL_CONSOLE reference...

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lib/oe/rootfs: Fix DEBUGFS generation when using opkg

[Alejandro del Castillo]

On 05/02/2016 08:39 AM, Patrick Ohly wrote:
> On Fri, 2016-04-22 at 14:51 +0100, Richard Purdie wrote:
>> When enabling extra DEBUGFS image generation with opkg, errors are seen like:
>>
>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Cannot get the installed 
>> packages list. Command 
>> '/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/bin/opkg -f 
>> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/opkg.conf
>>  -o 
>> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
>>   --force_postinstall --prefer-arch-to-version   status' returned 0 and 
>> stderr:
>> Collected errors:
>>  * file_md5sum_alloc: Failed to open
>> file 
>> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/syslog-startup.conf.busybox:
>>  No such file or directory.
>>  * file_md5sum_alloc: Failed to open
>> file 
>> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/fstab:
>>  No such file or directory.
>>
>> basically for all CONFFILES in the image. This is due to the file
>> rearranging
>> the rootfs generation code does. If we preserve the /etc directory,
>> the avoids the problem.
> 
> It avoids the problem, but it does not address the root cause (IMHO).
> Should opkg really complain about missing configuration files? It is
> perhaps an edge case, but besides editing a configuration file
> *removing* it entirely may also be a valid user modification.
> 
> The usage of opkg here is during image building, but the operation
> itself (opkg status) is not specific to image creation and thus should
> be able to handle arbitrary states of /etc and the config files in
> general.

Opkg status is supposed to give you the state of all your installed packages.
Currently is pretty rough data: it dumps into stdout the internal metadata that
tracks package info and promotes to error any inconsistency, like conffiles not
being present.

Looking at pacakge_manager.py, opkg status is being called on OpkgPkgsList.
Seems to me that if the purpose is to get all installed packages, then "opkg
list-installed" is the correct command. Looking at dpkg (DpkgPkgsList),
"dpkg-query -W" is being called, which I think maps to opkg list-installed, not
to opkg status.

-- 
Cheers,

Alejandro
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bluez5: move btmgmt to common READLINE section

[Nicolas Dechesne]

Upstream in 5.33 btmgmt was moved from experimental to common READLINE section,
in commit e4f0c5582f1fe3451d5588243adba9de1ed68b80, but this was never updated
in the recipe.

Signed-off-by: Nicolas Dechesne 
---
 meta/recipes-connectivity/bluez5/bluez5_5.37.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.37.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.37.bb
index db20f79..d7a9940 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.37.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.37.bb
@@ -13,6 +13,7 @@ NOINST_TOOLS_READLINE ?= " \
 tools/obex-server-tool \
 tools/bluetooth-player \
 tools/obexctl \
+tools/btmgmt \
 "
 
 # noinst programs in Makefile.tools that are conditional on EXPERIMENTAL
@@ -37,7 +38,6 @@ NOINST_TOOLS_EXPERIMENTAL ?= " \
 tools/hwdb \
 tools/hcieventmask \
 tools/hcisecfilter \
-tools/btmgmt \
 tools/btinfo \
 tools/btattach \
 tools/btsnoop \
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] arch-powerpc64.inc: disable the use of qemu usermode on ppc64

[Khem Raj]

> On May 2, 2016, at 3:06 AM, Alexander Kanavin 
>  wrote:
> 
> On 04/29/2016 11:34 PM, Khem Raj wrote:
>> should we replace qemu-ppc with qemu-ppc64 instead of disabling it
> 
> qemu-ppc64 is already used on 64 bit powerpc, the problem is that it always 
> crashes.

Do we need to adjust the emulated machine parameter ?


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 4/6] bmap-tools: generate standalone script

[Ed Bartosh]

Generated standalone bmaptool script that is more convenient
to use than native script. It can be run straight from
its location ./tmp/deploy/tools/bmaptool. The script doesn't
depend on anything except Python.

Signed-off-by: Ed Bartosh 
---
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
index e10f5fd..0f95788 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
@@ -15,10 +15,28 @@ SRC_URI[sha256sum] = 
"cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02b
 
 RDEPENDS_${PN} = "python-core python-compression"
 
-inherit setuptools
+inherit setuptools deploy
 
 BBCLASSEXTEND = "native"
 
 do_install_append_class-native() {
 sed -i -e 's|^#!.*/usr/bin/env python|#! /usr/bin/env nativepython|' 
${D}${bindir}/bmaptool
 }
+
+do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_TOOLS}"
+do_deploy[stamp-extra-info] = ""
+do_deploy_class-native() {
+cp bmaptool __main__.py
+python -m zipfile -c bmaptool.zip bmaptools __main__.py
+echo '#!/usr/bin/env python' | cat - bmaptool.zip > bmaptool-standalone
+install -d ${DEPLOYDIR}
+install -m 0755 bmaptool-standalone ${DEPLOYDIR}/bmaptool-${PV}
+rm -f ${DEPLOYDIR}/bmaptool
+ln -sf ./bmaptool-${PV} ${DEPLOYDIR}/bmaptool
+}
+
+do_deploy() {
+:
+}
+
+addtask deploy before do_package after do_install
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 2/6] image types: add bmap generation option

[Ed Bartosh]

From: "Alexander D. Kanevskiy" 

bmap image conversion type allows to create block map files
for sparse images. Bmap file can be used together with bmap-tools
for efficiently flash images to raw devices (hdd or usb drive)

[YOCTO #9414]

Signed-off-by: Alexander D. Kanevskiy 
Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 53af7ca..19f89f3 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -262,7 +262,7 @@ IMAGE_TYPES = " \
 wic wic.gz wic.bz2 wic.lzma \
 "
 
-COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum md5sum sha1sum sha224sum sha256sum 
sha384sum sha512sum"
+COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum md5sum sha1sum sha224sum sha256sum 
sha384sum sha512sum bmap"
 COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
 COMPRESS_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -275,12 +275,14 @@ COMPRESS_CMD_sha224sum = "sha224sum 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
 COMPRESS_CMD_sha256sum = "sha256sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha256sum"
 COMPRESS_CMD_sha384sum = "sha384sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha384sum"
 COMPRESS_CMD_sha512sum = "sha512sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha512sum"
+COMPRESS_CMD_bmap = "bmaptool create ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
-o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.bmap"
 COMPRESS_DEPENDS_lzma = "xz-native"
 COMPRESS_DEPENDS_gz = ""
 COMPRESS_DEPENDS_bz2 = "pbzip2-native"
 COMPRESS_DEPENDS_xz = "xz-native"
 COMPRESS_DEPENDS_lz4 = "lz4-native"
 COMPRESS_DEPENDS_sum = "mtd-utils-native"
+COMPRESS_DEPENDS_bmap = "bmap-tools-native"
 
 RUNNABLE_IMAGE_TYPES ?= "ext2 ext3 ext4"
 RUNNABLE_MACHINE_PATTERNS ?= "qemu"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 3/6] selftest: add bmap test

[Ed Bartosh]

Added test_bmap to imagefeatures tests.
It tests if bmap file is generated for the images and
if the image is sparse.

[YOCTO #9414]

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/imagefeatures.py | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/meta/lib/oeqa/selftest/imagefeatures.py 
b/meta/lib/oeqa/selftest/imagefeatures.py
index 8a53899..08e382f 100644
--- a/meta/lib/oeqa/selftest/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/imagefeatures.py
@@ -98,3 +98,30 @@ class ImageFeatures(oeSelfTest):
 # Build a core-image-weston
 bitbake('core-image-weston')
 
+def test_bmap(self):
+"""
+Summary: Check bmap support
+Expected:1. core-image-minimal can be build with bmap support
+ 2. core-image-minimal is sparse
+Product: oe-core
+Author:  Ed Bartosh 
+"""
+
+features = 'IMAGE_FSTYPES += " ext4 ext4.bmap"'
+self.write_config(features)
+
+image_name = 'core-image-minimal'
+bitbake(image_name)
+
+deploy_dir = get_bb_var('DEPLOY_DIR_IMAGE')
+link_name = get_bb_var('IMAGE_LINK_NAME', image_name)
+image_path = os.path.join(deploy_dir, "%s.ext4" % link_name)
+bmap_path = "%s.bmap" % image_path
+
+# check if result image and bmap file are in deploy directory
+self.assertTrue(os.path.exists(image_path))
+self.assertTrue(os.path.exists(bmap_path))
+
+# check if result image is sparse
+image_stat = os.stat(image_path)
+self.assertTrue(image_stat.st_size > image_stat.st_blocks * 512)
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 5/6] wic: implement --bmap option

[Ed Bartosh]

This option enables generation of .bmap file for the
result image using native bmaptool.

[YOCTO #9413]

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/creator.py  |  1 +
 scripts/lib/wic/engine.py   | 11 ---
 scripts/lib/wic/imager/direct.py| 23 +++
 scripts/lib/wic/plugins/imager/direct_plugin.py |  3 ++-
 scripts/wic |  3 ++-
 5 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/scripts/lib/wic/creator.py b/scripts/lib/wic/creator.py
index 5231297..6f4af8d 100644
--- a/scripts/lib/wic/creator.py
+++ b/scripts/lib/wic/creator.py
@@ -69,6 +69,7 @@ class Creator(object):
 optparser.add_option('', '--tmpfs', action='store_true', 
dest='enabletmpfs',
  help='Setup tmpdir as tmpfs to accelerate, 
experimental'
   ' feature, use it if you have more than 4G 
memory')
+optparser.add_option('', '--bmap', action='store_true', help='generate 
.bmap')
 return optparser
 
 def postoptparse(self, options):
diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index 76b93e8..9af6eb4 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -145,7 +145,7 @@ def list_source_plugins():
 
 def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
native_sysroot, scripts_path, image_output_dir,
-   compressor, debug):
+   compressor, bmap, debug):
 """Create image
 
 wks_file - user-defined OE kickstart file
@@ -156,6 +156,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, 
kernel_dir,
 scripts_path - absolute path to /scripts dir
 image_output_dir - dirname to create for image
 compressor - compressor utility to compress the image
+bmap - enable generation of .bmap
 
 Normally, the values for the build artifacts values are determined
 by 'wic -e' from the output of the 'bitbake -e' command given an
@@ -186,8 +187,12 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, 
kernel_dir,
 
 crobj = creator.Creator()
 
-crobj.main(["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
-wks_file, image_output_dir, oe_builddir, compressor or ""])
+cmdline = ["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
+wks_file, image_output_dir, oe_builddir, compressor or ""]
+if bmap:
+cmdline.append('--bmap')
+
+crobj.main(cmdline)
 
 print "\nThe image(s) were created using OE kickstart file:\n  %s" % 
wks_file
 
diff --git a/scripts/lib/wic/imager/direct.py b/scripts/lib/wic/imager/direct.py
index 1937042..1b6272e 100644
--- a/scripts/lib/wic/imager/direct.py
+++ b/scripts/lib/wic/imager/direct.py
@@ -34,7 +34,7 @@ from wic.utils.partitionedfs import Image
 from wic.utils.errors import CreatorError, ImageError
 from wic.imager.baseimager import BaseImageCreator
 from wic.plugin import pluginmgr
-from wic.utils.oe.misc import exec_cmd
+from wic.utils.oe.misc import exec_cmd, exec_native_cmd
 
 disk_methods = {
 "do_install_disk":None,
@@ -52,7 +52,8 @@ class DirectImageCreator(BaseImageCreator):
 """
 
 def __init__(self, oe_builddir, image_output_dir, rootfs_dir, bootimg_dir,
- kernel_dir, native_sysroot, compressor, creatoropts=None):
+ kernel_dir, native_sysroot, compressor, creatoropts=None,
+ bmap=False):
 """
 Initialize a DirectImageCreator instance.
 
@@ -74,6 +75,7 @@ class DirectImageCreator(BaseImageCreator):
 self.kernel_dir = kernel_dir
 self.native_sysroot = native_sysroot
 self.compressor = compressor
+self.bmap = bmap
 
 def __get_part_num(self, num, parts):
 """calculate the real partition number, accounting for partitions not
@@ -314,12 +316,17 @@ class DirectImageCreator(BaseImageCreator):
 self.bootimg_dir,
 self.kernel_dir,
 self.native_sysroot)
-# Compress the image
-if self.compressor:
-for disk_name, disk in self.__image.disks.items():
-full_path = self._full_path(self.__imgdir, disk_name, "direct")
-msger.debug("Compressing disk %s with %s" % \
-(disk_name, self.compressor))
+
+for disk_name, disk in self.__image.disks.items():
+full_path = self._full_path(self.__imgdir, disk_name, "direct")
+# Generate .bmap
+if self.bmap:
+msger.debug("Generating bmap file for %s" % disk_name)
+exec_native_cmd("bmaptool create %s -o %s.bmap" % (full_path, 
full_path),
+self.native_sysroot)
+# Compress the 

[OE-core] [PATCH v3 1/6] bmap-tools: initial commit, version 3.2

[Ed Bartosh]

Bmap-tools - tools to generate block map (AKA bmap) and flash images
using bmap. Bmaptool is a generic tool for creating the block map
(bmap) for a file and copying files using the block map.

The idea is that large file containing unused blocks, like raw system
image files, can be copied or flashed a lot faster with bmaptool than
with traditional tools like "dd" or "cp".

[YOCTO #9414]

Signed-off-by: Ed Bartosh 
---
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
new file mode 100644
index 000..e10f5fd
--- /dev/null
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
@@ -0,0 +1,24 @@
+SUMMARY = "Tools to generate block map (AKA bmap) and flash images using bmap"
+DESCRIPTION = "Bmap-tools - tools to generate block map (AKA bmap) and flash 
images using \
+bmap. Bmaptool is a generic tool for creating the block map (bmap) for a file, 
\
+and copying files using the block map. The idea is that large file containing \
+unused blocks, like raw system image files, can be copied or flashed a lot \
+faster with bmaptool than with traditional tools like "dd" or "cp"."
+HOMEPAGE = "http://git.infradead.org/users/dedekind/bmap-tools.git;
+SECTION = "console/utils"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+SRC_URI = "ftp://ftp.infradead.org/pub/${BPN}/${BPN}-${PV}.tgz;
+SRC_URI[md5sum] = "92cdad1cb4dfa0cca7176c8e22752616"
+SRC_URI[sha256sum] = 
"cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02bf2d434"
+
+RDEPENDS_${PN} = "python-core python-compression"
+
+inherit setuptools
+
+BBCLASSEXTEND = "native"
+
+do_install_append_class-native() {
+sed -i -e 's|^#!.*/usr/bin/env python|#! /usr/bin/env nativepython|' 
${D}${bindir}/bmaptool
+}
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 0/6] bmaptool support

[Ed Bartosh]

Hi,

This patchset adds ability to use bmaptool to flash images faster than
using traditional methods. It contains bmap-tools recipe and generation
of .bmap files for the images generated by bitbake and wic.

Bmaptool is a generic tool for creating the block map (bmap) for a file
and and copying files using the block map. The idea is that large file
containing unused blocks, like raw system image files, can be copied or
flashed a lot faster with bmaptool than with traditional tools like
"dd" or "cp".

Here is an example of flashing image using dd and bmaptool showing
around 25% performance gain in flashing time:

> ls -slh
 19M -rw-r--r-- 1 ed ed  26M Apr 26 11:36 
core-image-minimal-qemux86-64-20160426083554.rootfs.ext4
4.0K -rw-r--r-- 1 ed ed 2.7K Apr 26 11:36 
core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap

> time dd if=core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 
> of=/dev/sdb
52302+0 records in
52302+0 records out
26778624 bytes (27 MB) copied, 2.51183 s, 10.7 MB/s

real0m2.515s
user0m0.014s
sys 0m0.329s

> time bmaptool copy core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 
> /dev/sdb
bmaptool: info: discovered bmap file 
'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 6538 blocks of size 4096 (25.5 MiB), mapped 4799 blocks (18.7 
MiB or 73.4%)
bmaptool: info: copying image 
'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4' to block device 
'/dev/sdb' using bmap file 
'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1.8s, copying speed 10.3 MiB/sec

real0m1.909s
user0m0.226s
sys 0m0.052s

The test was repeated 5 times with the same image and the same usb stick device.

Changes in v2: Combined Alexander's and my bmap-tools recipes.
   Got rid of generating standalone script as it breaks build of 
bmap-tools-native.

Changes in v3: Returned back generation of standalone bmaptool script
   Implemented --bmap option for wic
   Added test case to test bmap generation by wic --bmap

The following changes since commit f7b520878babbaa7527151f22c031ae160512753:

  poky: Switch to post release name/version (2016-04-29 07:58:46 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/oe-core/bmap-tools-9414
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/oe-core/bmap-tools-9414

Alexander D. Kanevskiy (1):
  image types: add bmap generation option

Ed Bartosh (5):
  bmap-tools: initial commit, version 3.2
  selftest: add bmap test
  bmap-tools: generate standalone script
  wic: implement --bmap option
  oe-selftest: wic: add test_bmap test case

 meta/classes/image_types.bbclass  |  4 ++-
 meta/lib/oeqa/selftest/imagefeatures.py   | 27 +++
 meta/lib/oeqa/selftest/wic.py |  8 +
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 42 +++
 scripts/lib/wic/creator.py|  1 +
 scripts/lib/wic/engine.py | 11 --
 scripts/lib/wic/imager/direct.py  | 23 -
 scripts/lib/wic/plugins/imager/direct_plugin.py   |  3 +-
 scripts/wic   |  3 +-
 9 files changed, 108 insertions(+), 14 deletions(-)
 create mode 100644 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb

-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [wic][PATCH v2 0/8] make wic images sparse (#9099)

[Philip Balister]

On 04/28/2016 06:58 AM, Ed Bartosh wrote:
> Hi,
> 
> This patchset is a preparation for bmaptool support for wic. Using bmaptool
> makes sense only if images are sparsed and this is what's implemented here.

Minor nit, I find bmaptool makes sense even when images are not sparse.
It does check if existing partitions are mounted and seems a little
faster than dd.

Philip

> 
> Nice side effect of this work is that making images sparse not only makes
> flashing faster. It also makes the process of assembling an image much faster.
> 
> Here is how it works:
> - wic from master branch spends 36 sec to create an image:
> $ time wic create test.wks -e core-image-minimal -o img/
> ...
> real0m36.878s
> user2m0.496s
> sys 0m18.444s
> 
> - sparse-aware wic spends 8 seconds to create the same image:
> $ time wic create test.wks -e core-image-minimal -o img/
> ...
> real0m8.672s
> user0m7.292s
> sys 0m1.212s
> 
> The final image is very sparse, which explains why sparse-aware wic is so 
> fast:
> $ ls -lhs img/build/test-201604281219-sda.direct
> 28M -rw-r--r-- 1 ed users 2.4G Apr 28 12:19 
> img/build/test-201604281219-sda.direct
> 
> bmaptool reports 1.1% of mapped blocks:
> $ PATH=tmp/sysroots/x86_64-linux/usr/bin/ bmaptool create 
> img/build/test-201604281219-sda.direct -o 
> img/build/test-201604281219-sda.direct.bmap
> $ grep 'mapped blocks' img/build/test-201604281219-sda.direct.bmap
> 
> 
> Flashing is also a lot faster with bmaptool comparing to using dd:
> 
> time PATH=./tmp/sysroots/x86_64-linux/usr/bin/ bmaptool copy 
> img/build/test-201604281606-sda.direct /dev/sdb
> bmaptool: info: discovered bmap file 
> 'img/build/test-201604281606-sda.direct.bmap'
> bmaptool: info: block map format version 2.0
> bmaptool: info: 605696 blocks of size 4096 (2.3 GiB), mapped 6986 blocks 
> (27.3 MiB or 1.2%)
> bmaptool: info: copying image 'test-201604281606-sda.direct' to block device 
> '/dev/sdb' using bmap file 'test-201604281606-sda.direct.bmap'
> bmaptool: info: 100% copied
> bmaptool: info: synchronizing '/dev/sdb'
> bmaptool: info: copying time: 1.5s, copying speed 17.9 MiB/sec
> 
> real0m1.621s
> user0m0.225s
> sys 0m0.089s
> 
> time dd if=img/build/test-201604281606-sda.direct of=/dev/sdb bs=4M
> 591+1 records in
> 591+1 records out
> 2480930816 bytes (2.5 GB) copied, 107.483 s, 23.1 MB/s
> 
> real1m47.485s
> user0m0.001s
> sys 0m4.324s
> 
> The following changes since commit 111f44cacf25799dc296b8e300b571d798067fdc:
> 
>   selftest: add bmap test (2016-04-27 12:26:59 +0300)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib ed/wic/sparse-9099
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/wic/sparse-9099
> 
> Ed Bartosh (8):
>   wic: use truncate utility to create sparse files
>   wic: get rid of inheritance Disk->DiskImage
>   wic: get rid of fs_related.makedirs
>   wic: moved DiskImage to direct.py
>   wic: add FIEMAP and SEEK_HOLE / SEEK_DATA APIs
>   wic: add sparse_copy API
>   wic: use sparse_copy to copy partitions
>   wic: use sparse_copy to preserve sparseness
> 
>  scripts/lib/wic/filemap.py| 561 
> ++
>  scripts/lib/wic/imager/direct.py  |  23 +-
>  scripts/lib/wic/partition.py  |  20 +-
>  scripts/lib/wic/plugins/source/rawcopy.py |   7 +-
>  scripts/lib/wic/utils/fs_related.py   |  84 -
>  scripts/lib/wic/utils/partitionedfs.py|   6 +-
>  6 files changed, 592 insertions(+), 109 deletions(-)
>  create mode 100644 scripts/lib/wic/filemap.py
>  delete mode 100644 scripts/lib/wic/utils/fs_related.py
> 
> --
> Regards,
> Ed
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lib/oe/rootfs: Fix DEBUGFS generation when using opkg

[Patrick Ohly]

On Fri, 2016-04-22 at 14:51 +0100, Richard Purdie wrote:
> When enabling extra DEBUGFS image generation with opkg, errors are seen like:
> 
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Cannot get the installed packages 
> list. Command 
> '/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/bin/opkg -f 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/opkg.conf
>  -o 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
>   --force_postinstall --prefer-arch-to-version   status' returned 0 and 
> stderr:
> Collected errors:
>  * file_md5sum_alloc: Failed to open
> file 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/syslog-startup.conf.busybox:
>  No such file or directory.
>  * file_md5sum_alloc: Failed to open
> file 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/fstab:
>  No such file or directory.
> 
> basically for all CONFFILES in the image. This is due to the file
> rearranging
> the rootfs generation code does. If we preserve the /etc directory,
> the avoids the problem.

It avoids the problem, but it does not address the root cause (IMHO).
Should opkg really complain about missing configuration files? It is
perhaps an edge case, but besides editing a configuration file
*removing* it entirely may also be a valid user modification.

The usage of opkg here is during image building, but the operation
itself (opkg status) is not specific to image creation and thus should
be able to handle arbitrary states of /etc and the config files in
general.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] combo-layer: implement "update with history"

[Patrick Ohly]

The core idea is that all commits get imported, including merge
commits, and joined into one big merge commit that imports the changes
from the individual components into the main branch of the combined
repository.

This is done by copying the files in each commit and removing deleted
ones, instead of trying to patch the combined repository.

The advantages of doing updates in this mode are:
- works for arbitrary upstream repos, not just those which
  support conversion into a linear set of patches
- listing history shows that commits where developed
  independently in the different components, instead of
  artificially showing them as if they had been developed
  one after the after (component "" before "", then "ccc", ...)
- bisecting becomes easier: when upstream repos only ensure consistency
  when merging into their "master" branches, then those merge
  commits are good candidates for test builds also in the combined
  repo
- more data mining can be done, for example showing who merged a commit
  and when

Selecting a subset of the files is supported, albeit with a slight
different semantic for wild card matching compared to other code paths
(/ is matched by * and ?). Empty commits get skipped because typically
they are a result of filtering (but that is not checked, so
intentionally empty commits also get skipped).

Other code paths are intentionally left unchanged, to avoid
regressions. However, the downside is that some opportunities for
refactoring (in particular regarding file filtering) were ignored.

Signed-off-by: Patrick Ohly 
---
 scripts/combo-layer | 391 +++-
 1 file changed, 389 insertions(+), 2 deletions(-)

diff --git a/scripts/combo-layer b/scripts/combo-layer
index 9297d59..92525ca 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -28,6 +28,9 @@ import subprocess
 import tempfile
 import ConfigParser
 import re
+import copy
+import pipes
+import shutil
 from collections import OrderedDict
 from string import Template
 
@@ -653,8 +656,7 @@ def action_update(conf, args):
 action_pull(conf, ['arg0'] + components)
 
 if history:
-logger.error("update with history not implemented yet")
-sys.exit(1)
+update_with_history(conf, components, revisions, repos)
 else:
 update_with_patches(conf, components, revisions, repos)
 
@@ -888,6 +890,391 @@ def action_splitpatch(conf, args):
 else:
 logger.info(patch_filename)
 
+def update_with_history(conf, components, revisions, repos):
+'''Update all components with full history.
+
+Works by importing all commits reachable from a component's
+current head revision.  If those commits are rooted in an already
+imported commit, their content gets mixed with the content of the
+combined repo of that commit (new or modified files overwritten,
+removed files removed).
+
+The last commit is an artificial merge commit that merges all the
+updated components into the combined repository.
+
+The HEAD ref only gets updated at the very end. All intermediate work
+happens in a worktree which will get garbage collected by git eventually
+after a failure.
+'''
+# Remember current HEAD and what we need to add to it.
+head = runcmd("git rev-parse HEAD").strip()
+additional_heads = {}
+
+# Track the mapping between original commit and commit in the
+# combined repo. We do not have to distinguish between components,
+# because commit hashes are different anyway. Often we can
+# skip find_revs() entirely (for example, when all new commits
+# are derived from the last imported revision).
+#
+# Using "head" (typically the merge commit) instead of the actual
+# commit for the component leads to a nicer history in the combined
+# repo.
+old2new_revs = {}
+for name in repos:
+repo = conf.repos[name]
+revision = repo['last_revision']
+if revision:
+old2new_revs[revision] = head
+
+def add_p(parents):
+'''Insert -p before each entry.'''
+parameters = []
+for p in parents:
+parameters.append('-p')
+parameters.append(p)
+return parameters
+
+# Do all intermediate work with a separate work dir and index,
+# chosen via env variables (can't use "git worktree", it is too
+# new). This is useful (no changes to current work tree unless the
+# update succeeds) and required (otherwise we end up temporarily
+# removing the combo-layer hooks that we currently use when
+# importing a new component).
+#
+# Not cleaned up after a failure at the moment.
+wdir = os.path.join(os.getcwd(), ".git", "combo-layer")
+windex = wdir + ".index"
+if os.path.isdir(wdir):
+shutil.rmtree(wdir)
+os.mkdir(wdir)
+wenv = copy.deepcopy(os.environ)
+wenv["GIT_WORK_TREE"] = wdir
+

[OE-core] [PATCH 2/3] combo-layer: runcmd() enhancements

[Patrick Ohly]

Allow setting the environment. Due to a subprocess quirk, it must
always be set explicitly (reuses the one from the previous call if not
set, instead of falling back to os.environ).

Embedding nul characters will be useful for parsing git output more
reliably; support dumping such output a bit better.

Signed-off-by: Patrick Ohly 
---
 scripts/combo-layer | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/combo-layer b/scripts/combo-layer
index 41d69f8..9297d59 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -174,7 +174,7 @@ class Configuration(object):
 logger.error("ERROR: patchutils package is missing, please install 
it (e.g. # apt-get install patchutils)")
 sys.exit(1)
 
-def runcmd(cmd,destdir=None,printerr=True,out=None):
+def runcmd(cmd,destdir=None,printerr=True,out=None,env=None):
 """
 execute command, raise CalledProcessError if fail
 return output if succeed
@@ -186,7 +186,7 @@ def runcmd(cmd,destdir=None,printerr=True,out=None):
 else:
 err = os.tmpfile()
 try:
-subprocess.check_call(cmd, stdout=out, stderr=err, cwd=destdir, 
shell=isinstance(cmd, str))
+subprocess.check_call(cmd, stdout=out, stderr=err, cwd=destdir, 
shell=isinstance(cmd, str), env=env or os.environ)
 except subprocess.CalledProcessError,e:
 err.seek(0)
 if printerr:
@@ -195,7 +195,7 @@ def runcmd(cmd,destdir=None,printerr=True,out=None):
 
 err.seek(0)
 output = err.read()
-logger.debug("output: %s" % output )
+logger.debug("output: %s" % output.replace(chr(0), '\\0'))
 return output
 
 def action_init(conf, args):
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] combo-layer import with history

[Patrick Ohly]

In Ostro OS we recently struggled with importing repositories that had
non-linear histories and duplicated patches; traditional "combo-layer
update" fails to import those because it cannot flatten the upstream
changes into a linear set of patches.

This enhanced combo-layer can deal with that by completely
re-implementing the update action such that it copies file trees
around instead of patches.

This adds basically another code path. It could also be maintained
separately, but as it might also be of interest to others, adding this
to OE-core is probably better, even though it makes the code more
complicated.

Probably some serious refactoring is due at some point, but that
should better be done only after defining some good test cases.

The following changes since commit 1a0e56630c5c27d8899dd0979ae0b86bbe227881:

  utils.bbclass: note for deprecated base_contains (2016-04-29 07:53:58 +0100)

are available in the git repository at:

  git://github.com/pohly/openembedded-core combo-layer-update-history
  https://github.com/pohly/openembedded-core/tree/combo-layer-update-history

Patrick Ohly (3):
  combo-layer: dummy "update with history"
  combo-layer: runcmd() enhancements
  combo-layer: implement "update with history"

 scripts/combo-layer | 475 +---
 1 file changed, 449 insertions(+), 26 deletions(-)

-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] combo-layer: dummy "update with history"

[Patrick Ohly]

When setting "history = True" in combo-layer.conf consistently for the
components involved in an update or using "update" together with the
"--history" command line flag, a new mode for updating will be used
that does not rely on exporting/importing patches.

A config setting is used because it should be used consistently by
everyone using the same config, without having to remember to use an
additional command line parameter.

There are no real global settings, so the setting is checked
separately for each component although the setting has to be set
consistently. This restriction could be removed later.

In practice, putting "history" into the "[DEFAULT]" section is the
easiest approach for configuring it.

The actual code changes split up action_update and the
combo-layer.conf handling in preparation for this new mode, without
implementing the mode itself.

Signed-off-by: Patrick Ohly 
---
 scripts/combo-layer | 82 ++---
 1 file changed, 59 insertions(+), 23 deletions(-)

diff --git a/scripts/combo-layer b/scripts/combo-layer
index 9127041..41d69f8 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -73,7 +73,7 @@ class Configuration(object):
 else:
 # Apply special type transformations for some properties.
 # Type matches the RawConfigParser.get*() methods.
-types = {'signoff': 'boolean', 'update': 'boolean'}
+types = {'signoff': 'boolean', 'update': 'boolean', 
'history': 'boolean'}
 if name in types:
 value = getattr(parser, 'get' + types[name])(section, 
name)
 self.repos[repo][name] = value
@@ -610,8 +610,12 @@ def action_pull(conf, args):
 def action_update(conf, args):
 """
 update the component repos
-generate the patch list
-apply the generated patches
+either:
+   generate the patch list
+   apply the generated patches
+or:
+   re-creates the entire component history and merges them
+   into the current branch with a merge commit
 """
 components = [arg.split(':')[0] for arg in args[1:]]
 revisions = {}
@@ -624,10 +628,23 @@ def action_update(conf, args):
 # make sure combo repo is clean
 check_repo_clean(os.getcwd())
 
-import uuid
-patch_dir = "patch-%s" % uuid.uuid4()
-if not os.path.exists(patch_dir):
-os.mkdir(patch_dir)
+# Check whether we keep the component histories. Must be
+# set either via --history command line parameter or consistently
+# in combo-layer.conf. Mixing modes is (currently, and probably
+# permanently because it would be complicated) not supported.
+if conf.history:
+history = True
+else:
+history = None
+for name in repos:
+repo = conf.repos[name]
+repo_history = repo.get('history', True)
+logger.error('%s: %s' % (name, repo_history))
+if history is None:
+history = repo_history
+elif history != repo_history:
+logger.error("'history' property is set inconsistently")
+sys.exit(1)
 
 # Step 1: update the component repos
 if conf.nopull:
@@ -635,6 +652,18 @@ def action_update(conf, args):
 else:
 action_pull(conf, ['arg0'] + components)
 
+if history:
+logger.error("update with history not implemented yet")
+sys.exit(1)
+else:
+update_with_patches(conf, components, revisions, repos)
+
+def update_with_patches(conf, components, revisions, repos):
+import uuid
+patch_dir = "patch-%s" % uuid.uuid4()
+if not os.path.exists(patch_dir):
+os.mkdir(patch_dir)
+
 for name in repos:
 revision = revisions.get(name, None)
 repo = conf.repos[name]
@@ -711,6 +740,21 @@ def action_update(conf, args):
 runcmd("rm -rf %s" % patch_dir)
 
 # Step 7: commit the updated config file if it's being tracked
+commit_conf_file(conf, components)
+
+def conf_commit_msg(conf, components):
+# create the "components" string
+component_str = "all components"
+if len(components) > 0:
+# otherwise tell which components were actually changed
+component_str = ", ".join(components)
+
+# expand the template with known values
+template = Template(conf.commit_msg_template)
+msg = template.substitute(components = component_str)
+return msg
+
+def commit_conf_file(conf, components, commit=True):
 relpath = os.path.relpath(conf.conffile)
 try:
 output = runcmd("git status --porcelain %s" % relpath, printerr=False)
@@ -718,23 +762,15 @@ def action_update(conf, args):
 # Outside the repository
 output = None
 if output:
-logger.info("Committing updated configuration file")
 if output.lstrip().startswith("M"):
-
-  

[OE-core] [PATCH] gobject-introspection.bbclass: disable introspection for -native recipes

[Alexander Kanavin]

It is not necessary for native, adds to the build time, and pulls
in the unneeded qemu-native dependency.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/gobject-introspection.bbclass | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/classes/gobject-introspection.bbclass 
b/meta/classes/gobject-introspection.bbclass
index 2d73e40..d320b5b 100644
--- a/meta/classes/gobject-introspection.bbclass
+++ b/meta/classes/gobject-introspection.bbclass
@@ -3,13 +3,21 @@
 # This sets up autoconf-based recipes to build introspection data (or not),
 # depending on distro and machine features (see gobject-introspection-data 
class).
 inherit gobject-introspection-data
-EXTRA_OECONF_prepend = "${@bb.utils.contains('GI_DATA_ENABLED', 'True', 
'--enable-introspection', '--disable-introspection', d)} "
+EXTRA_OECONF_prepend_class-target = "${@bb.utils.contains('GI_DATA_ENABLED', 
'True', '--enable-introspection', '--disable-introspection', d)} "
+
+# When building native recipes, disable introspection, as it is not necessary,
+# pulls in additional dependencies, and makes build times longer
+EXTRA_OECONF_prepend_class-native = "--disable-introspection "
 
 UNKNOWN_CONFIGURE_WHITELIST_append = " --enable-introspection 
--disable-introspection"
 
 # Generating introspection data depends on a combination of native and target
 # introspection tools, and qemu to run the target tools.
-DEPENDS_append = " gobject-introspection gobject-introspection-native 
qemu-native"
+DEPENDS_append_class-target = " gobject-introspection 
gobject-introspection-native qemu-native"
+
+# Even though introspection is disable on -native, gobject-introspection 
package is still
+# needed for m4 macros.
+DEPENDS_append_class-native = " gobject-introspection-native"
 
 # This is necessary for python scripts to succeed - distutils fails if these
 # are not set
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] moving OpenEmbedded-core to Python 3

[Alexander Kanavin]

On 04/29/2016 11:43 PM, Khem Raj wrote:


Can you clarify the scope, are you addressing the case where target
images would prefer python3
and you are making sure that packages that use python on target are
ready for using it.


There is no way to set a 'preference' for Python 3. Either version of 
Python is pulled into images either through dependencies, or explicit 
inclusion into some package list.


I'm going to move recipes that are dependent on Python 2 to Python 3, 
whenever possible. I'm not porting the upstream code from Python 2 from 
Python 3, just configuring the recipes to use Python 3, when the Python 
code in them has already been ported.



bitbake itself is a separate task but then we do write scriptlets that
are executed as part of
build, are you addressing those too ?


Not sure what you mean here exactly, but if the scriptlets are executed 
by bitbake, then I'm not addressing that.



Thirdly, there is general pythonic code in metadata meant to control
build policies


Again, can you provide an example?


Which of these are you addressing specifically.


Please start using the question mark (?), so I can see more easily what 
is a question when responding.


Thanks,
Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] arch-powerpc64.inc: disable the use of qemu usermode on ppc64

[Alexander Kanavin]

On 04/29/2016 11:34 PM, Khem Raj wrote:

should we replace qemu-ppc with qemu-ppc64 instead of disabling it


qemu-ppc64 is already used on 64 bit powerpc, the problem is that it 
always crashes.


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lib/oe/rootfs: Fix DEBUGFS generation when using opkg

[Anders Darander]

Hi,
* Richard Purdie  [160422 15:52]:

> When enabling extra DEBUGFS image generation with opkg, errors are seen like:

> ERROR: core-image-minimal-1.0-r0 do_rootfs: Cannot get the installed packages 
> list. Command 
> '/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/bin/opkg -f 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/opkg.conf
>  -o 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
>   --force_postinstall --prefer-arch-to-version   status' returned 0 and 
> stderr:
> Collected errors:
>  * file_md5sum_alloc: Failed to open file 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/syslog-startup.conf.busybox:
>  No such file or directory.
>  * file_md5sum_alloc: Failed to open file 
> /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/fstab:
>  No such file or directory.

> basically for all CONFFILES in the image. This is due to the file rearranging
> the rootfs generation code does. If we preserve the /etc directory,
> the avoids the problem.

> We need to tell copyfile to preserve symlinks since some are present in /etc.

Thanks for the patch. It fixes the issue on e.g. core-image-minimal.

Unfortunately, on more complex images, we'll still fail with e.g.:

ERROR: core-image-minimal-1.0-r0 do_rootfs: Cannot get the installed packages 
list. Command 
'/mnt/cs-builds/anders/poky-play/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/opkg
 -f 
/mnt/cs-builds/anders/poky-play/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/opkg.conf
 -o 
/mnt/cs-builds/anders/poky-play/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
 --force_postinstall --prefer-arch-to-version   status' returned 0 and stderr:
Collected errors:
 * file_md5sum_alloc: Failed to open file 
/mnt/cs-builds/anders/poky-play/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs/usr/lib/ssl/openssl.cnf:
 No such file or directory.

I'd guess that all packages that have CONFFILES outside of /etc will
suffer from this...

I've updated #9490 with this info.

Cheers,
Anders
-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/3] bmap-tools: initial commit, version 3.2

[Ed Bartosh]

On Fri, Apr 29, 2016 at 11:38:38AM +0300, Alexander Kanevskiy wrote:
> On Fri, Apr 29, 2016 at 7:55 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
> 
> > On Fri, 29 Apr 2016 01:07:56 Alexander Kanevskiy wrote:
> > > On Wed, Apr 27, 2016 at 12:36 PM, Ed Bartosh  > >
> > >
> > > wrote:
> > > > Bmap-tools - tools to generate block map (AKA bmap) and flash images
> > > > using bmap. Bmaptool is a generic tool for creating the block map
> > > > (bmap) for a file and copying files using the block map.
> > > >
> > > > The idea is that large file containing unused blocks, like raw system
> > > > image files, can be copied or flashed a lot faster with bmaptool than
> > > > with traditional tools like "dd" or "cp".
> > > >
> > > > [YOCTO #9414]
> > > >
> > > > Signed-off-by: Ed Bartosh 
> > >
> > > better to use recipe that would create in deploy/tools standalone version
> > > of the tool.
> > > Otherwise, there is no easy way for user to utilize generated bmap files.
> >
> > You both probably have had notification already, but just to close the
> > loop I
> > found the issue with the do_deploy version, see the comments on bug 9414:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9414
> >
> >
> Thank you Paul for your help! Your fix mentioned in the bug for do_depoly
> is indeed the best solution.
>

OK. I'll add this functionality back in a separate patch.

--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core