date:20160518

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

2016-05-18 Thread Khem Raj


> On May 18, 2016, at 10:38 PM, Robert Yang  wrote:
> 
> 
> 
> On 05/19/2016 01:28 PM, Khem Raj wrote:
>> 
>>> On May 18, 2016, at 8:16 PM, Gary Thomas  wrote:
>>> 
>>> On 2016-05-18 22:07, Khem Raj wrote:
 On Wed, May 18, 2016 at 2:03 AM, Robert Yang  
 wrote:
> * It doesn't build on armv4:
> {standard input}: Assembler messages:
> {standard input}:52: Error: selected processor does not support `blx 
> llint_throw_stack_overflow_error' in ARM mode
> {standard input}:126: Error: selected processor does not support `bkpt 
> #0' in ARM mode
> {standard input}:128: Error: selected processor does not support `blx r0' 
> in ARM mode
> {standard input}:134: Error: selected processor does not support `bkpt 
> #0' in ARM mode
> {standard input}:185: Error: selected processor does not support `blx 
> llint_throw_stack_overflow_error' in ARM mode
> {standard input}:256: Error: selected processor does not support `blx r4' 
> in ARM mode
> {standard input}:310: Error: selected processor does not support `movw 
> r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
> {standard input}:311: Error: selected processor does not support `movt 
> r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
> {standard input}:315: Error: selected processor does not support `movw 
> r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
> {standard input}:316: Error: selected processor does not support `movt 
> r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
> [snip]
> 
> * It can build on armv7a, but doesn't work on runtime, cause
>   displaying problems or ephiphany hang.
> 
> [YOCTO #9474]
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
> b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
> index bdbcbea..23ead72 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
> @@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
>  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
>  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "
> 
> -# ARM JIT code does not build on ARMv5/6 anymore, apparently they test 
> only on v7 onwards
> +# ARM JIT code does not build on ARMv4/5/6 anymore
>  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
>  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
> +EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
> +
> +# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
> +# displaying problems or ephiphany hang.
> +EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "
 
 this should work fine with thumb2 e.g. so this is a little broad brush
 here to diable it across
 all armv7
>>> 
>>> Why do you think that changing the instruction set (to thumb2) would
>>> make the JIT work any better?
>> 
>> Assembler implementation for JIT has always worked better with thumb2.
>> 
>>> 
>>> If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
>>> the platform that inspired the original bug report.
>> 
>> 
>> Try adding
>> 
>> ARM_INSTRUCTION_SET_armv7a = “thumb"
>> ARM_INSTRUCTION_SET_armv7ve = “thumb"
>> 
>> in the webkitgtk recipe and see if it helps
> 
> 
> Hi,
> 
> To be clear, webkitgtk can build on armv7a, but doesn't work on
> runtime, cause displaying problems or ephiphany hang.

We are talking runtime here.


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] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

2016-05-18 Thread Robert Yang




On 05/19/2016 01:28 PM, Khem Raj wrote:



On May 18, 2016, at 8:16 PM, Gary Thomas  wrote:

On 2016-05-18 22:07, Khem Raj wrote:

On Wed, May 18, 2016 at 2:03 AM, Robert Yang  wrote:

* It doesn't build on armv4:
{standard input}: Assembler messages:
{standard input}:52: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:126: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:128: Error: selected processor does not support `blx r0' in 
ARM mode
{standard input}:134: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:185: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:256: Error: selected processor does not support `blx r4' in 
ARM mode
{standard input}:310: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:311: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:315: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
{standard input}:316: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
[snip]

* It can build on armv7a, but doesn't work on runtime, cause
   displaying problems or ephiphany hang.

[YOCTO #9474]

Signed-off-by: Robert Yang 
---
  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
index bdbcbea..23ead72 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
@@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "

-# ARM JIT code does not build on ARMv5/6 anymore, apparently they test only on 
v7 onwards
+# ARM JIT code does not build on ARMv4/5/6 anymore
  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
+EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
+
+# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
+# displaying problems or ephiphany hang.
+EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "


this should work fine with thumb2 e.g. so this is a little broad brush
here to diable it across
all armv7


Why do you think that changing the instruction set (to thumb2) would
make the JIT work any better?


Assembler implementation for JIT has always worked better with thumb2.



If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
the platform that inspired the original bug report.



Try adding

ARM_INSTRUCTION_SET_armv7a = “thumb"
ARM_INSTRUCTION_SET_armv7ve = “thumb"

in the webkitgtk recipe and see if it helps



Hi,

To be clear, webkitgtk can build on armv7a, but doesn't work on
runtime, cause displaying problems or ephiphany hang.

// Robert










  # binutils 2.25.1 has a bug on aarch64:
  # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
--
2.7.4

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



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

2016-05-18 Thread Khem Raj


> On May 18, 2016, at 8:16 PM, Gary Thomas  wrote:
> 
> On 2016-05-18 22:07, Khem Raj wrote:
>> On Wed, May 18, 2016 at 2:03 AM, Robert Yang  
>> wrote:
>>> * It doesn't build on armv4:
>>> {standard input}: Assembler messages:
>>> {standard input}:52: Error: selected processor does not support `blx 
>>> llint_throw_stack_overflow_error' in ARM mode
>>> {standard input}:126: Error: selected processor does not support `bkpt #0' 
>>> in ARM mode
>>> {standard input}:128: Error: selected processor does not support `blx r0' 
>>> in ARM mode
>>> {standard input}:134: Error: selected processor does not support `bkpt #0' 
>>> in ARM mode
>>> {standard input}:185: Error: selected processor does not support `blx 
>>> llint_throw_stack_overflow_error' in ARM mode
>>> {standard input}:256: Error: selected processor does not support `blx r4' 
>>> in ARM mode
>>> {standard input}:310: Error: selected processor does not support `movw 
>>> r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
>>> {standard input}:311: Error: selected processor does not support `movt 
>>> r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
>>> {standard input}:315: Error: selected processor does not support `movw 
>>> r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
>>> {standard input}:316: Error: selected processor does not support `movt 
>>> r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
>>> [snip]
>>> 
>>> * It can build on armv7a, but doesn't work on runtime, cause
>>>   displaying problems or ephiphany hang.
>>> 
>>> [YOCTO #9474]
>>> 
>>> Signed-off-by: Robert Yang 
>>> ---
>>>  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
>>> b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
>>> index bdbcbea..23ead72 100644
>>> --- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
>>> +++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
>>> @@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
>>>  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
>>>  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "
>>> 
>>> -# ARM JIT code does not build on ARMv5/6 anymore, apparently they test 
>>> only on v7 onwards
>>> +# ARM JIT code does not build on ARMv4/5/6 anymore
>>>  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
>>>  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
>>> +EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
>>> +
>>> +# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
>>> +# displaying problems or ephiphany hang.
>>> +EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "
>> 
>> this should work fine with thumb2 e.g. so this is a little broad brush
>> here to diable it across
>> all armv7
> 
> Why do you think that changing the instruction set (to thumb2) would
> make the JIT work any better?

Assembler implementation for JIT has always worked better with thumb2.

> 
> If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
> the platform that inspired the original bug report.


Try adding

ARM_INSTRUCTION_SET_armv7a = “thumb"
ARM_INSTRUCTION_SET_armv7ve = “thumb"

in the webkitgtk recipe and see if it helps

> 
>> 
>>> 
>>>  # binutils 2.25.1 has a bug on aarch64:
>>>  # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
>>> --
>>> 2.7.4
>>> 
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

2016-05-18 Thread Tristan Van Berkom

On Thu, 2016-05-19 at 05:16 +0200, Gary Thomas wrote:
[...]
> Why do you think that changing the instruction set (to thumb2) would
> make the JIT work any better?
> 
> If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
> the platform that inspired the original bug report.

FWIW, I ran into this issue as well the first time I tried building
webkitgtk with a compiler tuned for armv7a.

I did not try many variations but was able to build with a machine
configuration with DEFAULTTUNE set to armv7ahf-neon (hard float with
neon simd).

This link seems to also provide some more information on what
configurations can be used to build webkitgtk on arm:
    http://patchwork.openembedded.org/patch/105081/

Cheers,
    -Tristan

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

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

2016-05-18 Thread Gary Thomas


On 2016-05-18 22:07, Khem Raj wrote:

On Wed, May 18, 2016 at 2:03 AM, Robert Yang  wrote:

* It doesn't build on armv4:
{standard input}: Assembler messages:
{standard input}:52: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:126: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:128: Error: selected processor does not support `blx r0' in 
ARM mode
{standard input}:134: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:185: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:256: Error: selected processor does not support `blx r4' in 
ARM mode
{standard input}:310: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:311: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:315: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
{standard input}:316: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
[snip]

* It can build on armv7a, but doesn't work on runtime, cause
   displaying problems or ephiphany hang.

[YOCTO #9474]

Signed-off-by: Robert Yang 
---
  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
index bdbcbea..23ead72 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
@@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "

-# ARM JIT code does not build on ARMv5/6 anymore, apparently they test only on 
v7 onwards
+# ARM JIT code does not build on ARMv4/5/6 anymore
  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
+EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
+
+# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
+# displaying problems or ephiphany hang.
+EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "


this should work fine with thumb2 e.g. so this is a little broad brush
here to diable it across
all armv7


Why do you think that changing the instruction set (to thumb2) would
make the JIT work any better?

If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
the platform that inspired the original bug report.





  # binutils 2.25.1 has a bug on aarch64:
  # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
--
2.7.4

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



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] PRServer's problem

2016-05-18 Thread Robert Yang

On 05/19/2016 10:33 AM, Robert Yang wrote:

Hi Martin,

I found this patch in the bug:

http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/sstatesig.py?id=336a7897e39b9e42dcfcba9e2520ea96b0c6a8d6

And this patch causes another inconsistent:

PACKAGE_CLASSES = "package_ipk"

1) After make some changes in opkg-utils-native, foo.do_package_write_ipk
will re-run, but PR doesn't bump, this is because PR is bumped in
do_package, and do_package doesn't depend on opkg-utils-native, but
do_package_write_ipk does, so do_package_write_ipk will rerun but no
PR is bumped.

2) Another more funny problem is, after make some changes in rpm-native
(PACKAGE_CLASSES = "package_ipk"), both foo.do_package and
foo.do_package_write_ipk will run and PR is bumped. This is because
do_package depends on rpm-native (for FILERDEPENDS), so do_package
re-runs and PR bumps, thus caused do_package_write_ipk re-runs.

Revert the patch will fix both 1) and 2).

For 2), the only one uses FILERDEPENDS is do_package_qa, maybe we need
move the generation of FILERDEPENDS there. This is another bug.

// Robert

Too many PR bumps and rebuildings are caused by this patch. I'm
not very sure about what this patch tries to fix, it seems that
it is trying to fix problems when 32bit and 64bit uses the same
sstate cache? Would you please provide a simple reproducer, please?

Things will become much better after revert this patch. Be less
stricter or more is a hard problem, if we still need the patch,
can we leave such a choice to the end user? We can add some vars
like DROP_NATIVE_SIG ? = "0/1". This would be good to the end user
who uses stable release like jethro or krogoth to make their
distributions, and PR Service really matters here. Even if they
switch the build between 32 and 64 builds (This is unlikely to
happen for production environment) and got problems, they still
can fix the problem by rebuilding, this is still much better than
current status: run a "smart/opkg/apt-get upgrade" on the target,
*all* of the packages are downloaded and installed again after a
CVE patch applies on native recipes like pseudo-native or rpm-native,
but in fact, nothing is changed on the target this is really a bad
experience.

// Robert

On 05/18/2016 06:15 PM, Martin Jansa wrote:

On Wed, May 18, 2016 at 05:31:09PM +0800, Robert Yang wrote:

On 05/18/2016 05:20 PM, Martin Jansa wrote:

On Wed, May 18, 2016 at 04:03:58PM +0800, Robert Yang wrote:

Hi Martin,

On 05/18/2016 03:39 PM, Martin Jansa wrote:

See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970

Just using recipe checksum wont work, because the main reason for PR bumps
is to
automatically upgrade the packages when one of the dependencies changes .so
version, which you won't detect from recipe checksum of the app which is just
using the library.

For the development branch like master, yes, that would happen. But for
the stable release like jethro and krogoth, it is unlikely that would
happen, and if if does, the user can manually bump the impacted recipe's
PR to fix the problem. The current problem is that when *all* recipes'
PR are bumped, there is no way to fix the problem.

You can still stop using PR service and start doing manual PR bumps, but

We can't stop PR service and start doing manual PR bumps since we need keep
update to date with upstream, the changes from upstream don't do the manual
PR, and I don't think that we have to if they can be done automatically.

it's quite annoying if you need to bump a lot of recipes you don't
control :).

What's your opinion about only consider RDEPENDS for PR service's checksum,
please ?

I would like to have separate handler as described in that bug, option
c).

Not only because of unnecessary EXTENDPRAUTO bumps, but also unnecessary
rebuilds.

On Wed, May 18, 2016 at 8:09 AM, Robert Yang > wrote:

The PRServer bumps PR according to do_package's task hash, that
causes it bumps *all* packages' PR when recipes like pseudo-native
and rpm-native is changed. It is a very bad user experience when we
run "smart/opkg upgrade" on running target, for example, when we apply
a CVE patch to pseudo-native or rpm-native, or do some slight changes
in their do_compile, "smart/opkg upgrade" will download/install *all*
the packages since all of the packages' PR are bumped.

Here are some rough suggestions to fix this problem, and please feel
free to give your suggestions.
1) Do not use do_package's task for bumping PR, the easiest way
is simulate manually bump PR -- only bump PR when the recipe
itself's checksum is changed.

2) Add a new task for PRServer, redefine its task hash for bumping
PR, for example, this task hash only considers RDEPENDS (no
DEPENDS), and drop any native dependencies.

I prefer the first way, and an alternative way maybe add a var so that

Re: [OE-core] PRServer's problem

2016-05-18 Thread Robert Yang



Hi Martin,

I found this patch in the bug:

http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/sstatesig.py?id=336a7897e39b9e42dcfcba9e2520ea96b0c6a8d6

Too many PR bumps and rebuildings are caused by this patch. I'm
not very sure about what this patch tries to fix, it seems that
it is trying to fix problems when 32bit and 64bit uses the same
sstate cache? Would you please provide a simple reproducer, please?

Things will become much better after revert this patch. Be less
stricter or more is a hard problem, if we still need the patch,
can we leave such a choice to the end user? We can add some vars
like DROP_NATIVE_SIG ? = "0/1". This would be good to the end user
who uses stable release like jethro or krogoth to make their
distributions, and PR Service really matters here. Even if they
switch the build between 32 and 64 builds (This is unlikely to
happen for production environment) and got problems, they still
can fix the problem by rebuilding, this is still much better than
current status: run a "smart/opkg/apt-get upgrade" on the target,
*all* of the packages are downloaded and installed again after a
CVE patch applies on native recipes like pseudo-native or rpm-native,
but in fact, nothing is changed on the target this is really a bad
experience.

// Robert

On 05/18/2016 06:15 PM, Martin Jansa wrote:

On Wed, May 18, 2016 at 05:31:09PM +0800, Robert Yang wrote:



On 05/18/2016 05:20 PM, Martin Jansa wrote:

On Wed, May 18, 2016 at 04:03:58PM +0800, Robert Yang wrote:

Hi Martin,

On 05/18/2016 03:39 PM, Martin Jansa wrote:

See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970

Just using recipe checksum wont work, because the main reason for PR bumps is to
automatically upgrade the packages when one of the dependencies changes .so
version, which you won't detect from recipe checksum of the app which is just
using the library.


For the development branch like master, yes, that would happen. But for
the stable release like jethro and krogoth, it is unlikely that would
happen, and if if does, the user can manually bump the impacted recipe's
PR to fix the problem. The current problem is that when *all* recipes'
PR are bumped, there is no way to fix the problem.


You can still stop using PR service and start doing manual PR bumps, but


We can't stop PR service and start doing manual PR bumps since we need keep
update to date with upstream, the changes from upstream don't do the manual
PR, and I don't think that we have to if they can be done automatically.


it's quite annoying if you need to bump a lot of recipes you don't
control :).


What's your opinion about only consider RDEPENDS for PR service's checksum,
please ?


I would like to have separate handler as described in that bug, option
c).

Not only because of unnecessary EXTENDPRAUTO bumps, but also unnecessary 
rebuilds.


On Wed, May 18, 2016 at 8:09 AM, Robert Yang > wrote:

  The PRServer bumps PR according to do_package's task hash, that
  causes it bumps *all* packages' PR when recipes like pseudo-native
  and rpm-native is changed. It is a very bad user experience when we
  run "smart/opkg upgrade" on running target, for example, when we apply
  a CVE patch to pseudo-native or rpm-native, or do some slight changes
  in their do_compile, "smart/opkg upgrade" will download/install *all*
  the packages since all of the packages' PR are bumped.

  Here are some rough suggestions to fix this problem, and please feel
  free to give your suggestions.
  1) Do not use do_package's task for bumping PR, the easiest way
  is simulate manually bump PR -- only bump PR when the recipe
  itself's checksum is changed.

  2) Add a new task for PRServer, redefine its task hash for bumping
  PR, for example, this task hash only considers RDEPENDS (no
  DEPENDS), and drop any native dependencies.

  I prefer the first way, and an alternative way maybe add a var so that
  the user can configure it:
  PR_CHECKSUM = "${BB_TASKHASH}" (current way)
  Or
  PR_CHECKSUM = ""

  --
  Thanks

  Robert
  --
  ___
  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 7/7] rootfs.py: Unify _log_check_warn() and _log_check_error()

2016-05-18 Thread Peter Kjellerstedt

Use a common _log_check_common() function (based on the old
_log_check_warn() function) to implement the logic for both
_log_check_warn() and _log_check_error().

The main benefit of this is that now all error messages will be
reported again, not just the first one found. Additionally the output
will now look the same for both error and warning messages.

This removes the context for the error messages. However, since there
was no indication in the output that some of the lines were context,
they were more confusing than helping.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 52 ++-
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 479e4cc..f5c465f 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -40,7 +40,7 @@ class Rootfs(object):
 def _log_check(self):
 pass
 
-def _log_check_warn(self):
+def _log_check_common(self, type, match):
 # Ignore any lines containing log_check to avoid recursion, and ignore
 # lines beginning with a + since sh -x may emit code which isn't
 # actually executed, but may contain error messages
@@ -48,7 +48,7 @@ class Rootfs(object):
 if hasattr(self, 'log_check_expected_regexes'):
 excludes.extend(self.log_check_expected_regexes)
 excludes = [re.compile(x) for x in excludes]
-r = re.compile('^(warn|Warn|WARNING:)')
+r = re.compile(match)
 log_path = self.d.expand("${T}/log.do_rootfs")
 messages = []
 with open(log_path, 'r') as log:
@@ -65,45 +65,21 @@ class Rootfs(object):
 messages.append('[log_check] %s' % line)
 if messages:
 if len(messages) == 1:
-msg = 'a warning message'
+msg = '1 %s message' % type
 else:
-msg = '%d warning messages' % len(messages)
-bb.warn('[log_check] %s: found %s in the logfile:\n%s'
-% (self.d.getVar('PN', True), msg, ''.join(messages)))
-
-def _log_check_error(self):
-# Ignore any lines containing log_check to avoid recursion, and ignore
-# lines beginning with a + since sh -x may emit code which isn't
-# actually executed, but may contain error messages
-excludes = [ 'log_check', r'^\+' ]
-if hasattr(self, 'log_check_expected_regexes'):
-excludes.extend(self.log_check_expected_regexes)
-excludes = [re.compile(x) for x in excludes]
-r = re.compile(self.log_check_regex)
-log_path = self.d.expand("${T}/log.do_rootfs")
-with open(log_path, 'r') as log:
-found_error = 0
-message = "\n"
-for line in log:
-for ee in excludes:
-m = ee.search(line)
-if m:
-break
-if m:
-continue
-
-m = r.search(line)
-if m:
-found_error = 1
-bb.warn('[log_check] %s: found an error message in the 
logfile (keyword \'%s\'):\n[log_check] %s'
-   % (self.d.getVar('PN', True), m.group(), 
line))
+msg = '%d %s messages' % (len(messages), type)
+msg = '[log_check] %s: found %s in the logfile:\n%s' % \
+(self.d.getVar('PN', True), msg, ''.join(messages))
+if type == 'error':
+bb.fatal(msg)
+else:
+bb.warn(msg)
 
-if found_error >= 1 and found_error <= 5:
-message += line + '\n'
-found_error += 1
+def _log_check_warn(self):
+self._log_check_common('warning', '^(warn|Warn|WARNING:)')
 
-if found_error == 6:
-bb.fatal(message)
+def _log_check_error(self):
+self._log_check_common('error', self.log_check_regex)
 
 def _insert_feed_uris(self):
 if bb.utils.contains("IMAGE_FEATURES", "package-management",
-- 
2.1.0

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

[OE-core] [PATCH 1/7] Revert "rootfs.py: add more info to the warning message"

2016-05-18 Thread Peter Kjellerstedt

The reverted commit added a warning with the log line that triggered
the log check for error messages before the warning that states that
an error has been found in the log. However, the error line is output
by the call to bb.fatal() that follows immediately after the original
warning, which makes it redundant. Additionaly, having two warnings
contradicts the intent of commit 8dfdd329 where the log warnings were
tidied up.

This reverts commit f9cf31525fc885e1a0f65bd55654631257f87078.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 95fd3ab..f6fb06c 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -75,7 +75,6 @@ class Rootfs(object):
 m = r.search(line)
 if m:
 found_error = 1
-bb.warn('[log_check] In line: [%s]' % line)
 bb.warn('[log_check] %s: found an error message in the 
logfile (keyword \'%s\'):\n[log_check] %s'
% (self.d.getVar('PN', True), m.group(), 
line))
 
-- 
2.1.0

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

[OE-core] [PATCH 0/7] Improvements for the rootfs log check

2016-05-18 Thread Peter Kjellerstedt

This is a set of improvements to the log check code in
meta/lib/oe/rootfs.py. It started out with me wanting to reduce the
spam I got when there were many warnings in the log, and ended up with
quite a lot of refactoring. I also activated the fix to bug 7789 along
the way...

I have only tested this with rpm builds, but I expect it to work for
deb and ipk builds as well...

//Peter

The following changes since commit 7707cf6562e6a477ea953743a2d9aba682d90949:

  sdk-manual: Fixed three broken links to sections within manual. (2016-05-17 
21:35:00 +0100)

are available in the git repository at:

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

Peter Kjellerstedt (7):
  Revert "rootfs.py: add more info to the warning message"
  rootfs.py: Remove _log_check_error() from the RpmRootfs class
  rootfs.py: Simplify the regular expression used in _log_check_warn()
  rootfs.py: Use one way to exclude lines in _log_check_error()
  rootfs.py: Exclude lines in _log_check_warn() as well
  rootfs.py: Reduce spam from _log_check_warn()
  rootfs.py: Unify _log_check_warn() and _log_check_error()

 meta/lib/oe/rootfs.py | 93 +--
 1 file changed, 31 insertions(+), 62 deletions(-)

-- 
2.1.0

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

[OE-core] [PATCH 4/7] rootfs.py: Use one way to exclude lines in _log_check_error()

2016-05-18 Thread Peter Kjellerstedt

Before there were three different ways to exclude a line from being
searched for error messages in _log_check_error(). Now there is only
one: an array of regular expressions. This should make it easy to add
more excludes if nedded.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index a92aa22..63ca22f 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -54,26 +54,25 @@ class Rootfs(object):
% (self.d.getVar('PN', True), m.group(), 
line))
 
 def _log_check_error(self):
+# Ignore any lines containing log_check to avoid recursion, and ignore
+# lines beginning with a + since sh -x may emit code which isn't
+# actually executed, but may contain error messages
+excludes = [ 'log_check', r'^\+' ]
+if hasattr(self, 'log_check_expected_errors_regexes'):
+excludes.extend(self.log_check_expected_errors_regexes)
+excludes = [re.compile(x) for x in excludes]
 r = re.compile(self.log_check_regex)
 log_path = self.d.expand("${T}/log.do_rootfs")
 with open(log_path, 'r') as log:
 found_error = 0
 message = "\n"
 for line in log:
-if 'log_check' in line:
-continue
-# sh -x may emit code which isn't actually executed
-if line.startswith('+'):
-continue
-
-if hasattr(self, 'log_check_expected_errors_regexes'):
-m = None
-for ee in self.log_check_expected_errors_regexes:
-m = re.search(ee, line)
-if m:
-break
+for ee in excludes:
+m = ee.search(line)
 if m:
-continue
+break
+if m:
+continue
 
 m = r.search(line)
 if m:
-- 
2.1.0

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

[OE-core] [PATCH 6/7] rootfs.py: Reduce spam from _log_check_warn()

2016-05-18 Thread Peter Kjellerstedt

For each warning found in the log, _log_check_warn() would output a
line stating that it had found a warning, then the actual warning and
finally an empty line. This is quite excessive when there are many
warnings in the log.

With this change the output is instead a line stating how many
warnings were found, followed by the warnings. This makes the output
much more compact and actually much more readable.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 741399a..479e4cc 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -50,6 +50,7 @@ class Rootfs(object):
 excludes = [re.compile(x) for x in excludes]
 r = re.compile('^(warn|Warn|WARNING:)')
 log_path = self.d.expand("${T}/log.do_rootfs")
+messages = []
 with open(log_path, 'r') as log:
 for line in log:
 for ee in excludes:
@@ -61,8 +62,14 @@ class Rootfs(object):
 
 m = r.search(line)
 if m:
-bb.warn('[log_check] %s: found a warning message in the 
logfile (keyword \'%s\'):\n[log_check] %s'
-   % (self.d.getVar('PN', True), m.group(), 
line))
+messages.append('[log_check] %s' % line)
+if messages:
+if len(messages) == 1:
+msg = 'a warning message'
+else:
+msg = '%d warning messages' % len(messages)
+bb.warn('[log_check] %s: found %s in the logfile:\n%s'
+% (self.d.getVar('PN', True), msg, ''.join(messages)))
 
 def _log_check_error(self):
 # Ignore any lines containing log_check to avoid recursion, and ignore
-- 
2.1.0

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

[OE-core] [PATCH 3/7] rootfs.py: Simplify the regular expression used in _log_check_warn()

2016-05-18 Thread Peter Kjellerstedt

In commit 0387d095 lines with "NOTE:" in them were excluded from the
log check for warnings. However, those lines were only there in the
first place since the regular expression that is used to find warning
messages explicitly included those lines...

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 0a2753e..a92aa22 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -41,11 +41,11 @@ class Rootfs(object):
 pass
 
 def _log_check_warn(self):
-r = re.compile('^(warn|Warn|NOTE: warn|NOTE: Warn|WARNING:)')
+r = re.compile('^(warn|Warn|WARNING:)')
 log_path = self.d.expand("${T}/log.do_rootfs")
 with open(log_path, 'r') as log:
 for line in log:
-if 'log_check' in line or 'NOTE:' in line:
+if 'log_check' in line:
 continue
 
 m = r.search(line)
-- 
2.1.0

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

[OE-core] [PATCH 5/7] rootfs.py: Exclude lines in _log_check_warn() as well

2016-05-18 Thread Peter Kjellerstedt

This will make _log_check_warn() exclude the same lines as
_log_check_error() does.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/rootfs.py | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 63ca22f..741399a 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -41,11 +41,22 @@ class Rootfs(object):
 pass
 
 def _log_check_warn(self):
+# Ignore any lines containing log_check to avoid recursion, and ignore
+# lines beginning with a + since sh -x may emit code which isn't
+# actually executed, but may contain error messages
+excludes = [ 'log_check', r'^\+' ]
+if hasattr(self, 'log_check_expected_regexes'):
+excludes.extend(self.log_check_expected_regexes)
+excludes = [re.compile(x) for x in excludes]
 r = re.compile('^(warn|Warn|WARNING:)')
 log_path = self.d.expand("${T}/log.do_rootfs")
 with open(log_path, 'r') as log:
 for line in log:
-if 'log_check' in line:
+for ee in excludes:
+m = ee.search(line)
+if m:
+break
+if m:
 continue
 
 m = r.search(line)
@@ -58,8 +69,8 @@ class Rootfs(object):
 # lines beginning with a + since sh -x may emit code which isn't
 # actually executed, but may contain error messages
 excludes = [ 'log_check', r'^\+' ]
-if hasattr(self, 'log_check_expected_errors_regexes'):
-excludes.extend(self.log_check_expected_errors_regexes)
+if hasattr(self, 'log_check_expected_regexes'):
+excludes.extend(self.log_check_expected_regexes)
 excludes = [re.compile(x) for x in excludes]
 r = re.compile(self.log_check_regex)
 log_path = self.d.expand("${T}/log.do_rootfs")
@@ -597,7 +608,7 @@ class DpkgRootfs(DpkgOpkgRootfs):
 def __init__(self, d, manifest_dir):
 super(DpkgRootfs, self).__init__(d)
 self.log_check_regex = '^E:'
-self.log_check_expected_errors_regexes = \
+self.log_check_expected_regexes = \
 [
 "^E: Unmet dependencies."
 ]
-- 
2.1.0

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

[OE-core] [PATCH] glibc: Add missing patch hunk back

2016-05-18 Thread Richard Purdie

This hunk of patch went missing during the glibc upgrade to 2.24
and without it, uninative-tarball doesn't work properly. This adds
it back so we can spin a new version of uninative.

Signed-off-by: Richard Purdie 

diff --git 
a/meta/recipes-core/glibc/glibc/0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch
 
b/meta/recipes-core/glibc/glibc/0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch
index 23b9fcb..2e7971c 100644
--- 
a/meta/recipes-core/glibc/glibc/0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch
+++ 
b/meta/recipes-core/glibc/glibc/0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch
@@ -121,6 +121,18 @@ index eb2f900..505804e 100644
  #ifndef add_system_dir
  # define add_system_dir(dir) add_dir (dir)
  #endif
+diff --git a/iconv/gconv_conf.c b/iconv/gconv_conf.c
+--- a/iconv/gconv_conf.c
 b/iconv/gconv_conf.c
+@@ -36,7 +36,7 @@
+ 
+ 
+ /* This is the default path where we look for module lists.  */
+-static const char default_gconv_path[] = GCONV_PATH;
++static char default_gconv_path[4096] __attribute__ ((section 
(".gccrelocprefix"))) = GCONV_PATH;
+ 
+ /* The path elements, as determined by the __gconv_get_path function.
+All path elements end in a slash.  */
 -- 
 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] acl.inc, run-ptest: improve ptest functionality on limited rootfs

2016-05-18 Thread Peter Seebach

ACL's ptest has a handful of failure modes which can be triggered by
a restrictive or small system. First, the ptest requires that daemon
be in the bin group, which run-ptest attempts to do using gpasswd,
but gpasswd is part of shadow, and oe-core removes shadow when it
doesn't think shadow will be needed. Even if, say, a package has
RDEPENDS on it. Whoops. So we manually sed the group file. This
will probably work.

Second, the filesystem used for the test has to support ACLs,
so we create a dummy ext3 filesystem and use that.

Third, the root/permissions test relies on the assumption that
"mkdir d" produces a directory which non-root users can access,
but in a secure product which defaults to umask 077, this doesn't
work. (That fix has been separately reported to upstream acl
through their bug report form.)

(This may prevent the test from running without mkfs.ext3, but it
allows the test to run on targets where root doesn't have ACL
support. Tradeoffs, tradeoffs everywhere.)

Signed-off-by: Peter Seebach 
---
 meta/recipes-support/attr/acl.inc  |1 +
 meta/recipes-support/attr/acl/run-ptest|   67 ++--
 .../attr/acl/test-fix-directory-permissions.patch  |   24 +++
 3 files changed, 87 insertions(+), 5 deletions(-)
 create mode 100644 
meta/recipes-support/attr/acl/test-fix-directory-permissions.patch

diff --git a/meta/recipes-support/attr/acl.inc 
b/meta/recipes-support/attr/acl.inc
index 198fb4f..aebebfd 100644
--- a/meta/recipes-support/attr/acl.inc
+++ b/meta/recipes-support/attr/acl.inc
@@ -14,6 +14,7 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/acl/${BP}.src.tar.gz \
file://acl-fix-the-order-of-expected-output-of-getfacl.patch \
file://test-fix-insufficient-quoting-of.patch \
file://test-fixups-on-SELinux-machines-for-root-testcases.patch \
+   file://test-fix-directory-permissions.patch \
 "
 
 require ea-acl.inc
diff --git a/meta/recipes-support/attr/acl/run-ptest 
b/meta/recipes-support/attr/acl/run-ptest
index 3b31cc9..a56946d 100644
--- a/meta/recipes-support/attr/acl/run-ptest
+++ b/meta/recipes-support/attr/acl/run-ptest
@@ -1,7 +1,64 @@
 #!/bin/sh
+#
+#This script is used to run acl test suites
 
-gpasswd -a daemon bin
-make -C test -k tests root-tests |sed \
- -e 's|^\[.*\] \(.*\) -- ok$|PASS: \1|' \
- -e 's|^\[.*\] \(.*\) -- failed|FAIL: \1|'
-gpasswd -d daemon bin
+#umask 077
+
+EXT3_IMAGE=ext3.img
+EXT3_MOUNT_POINT=/mnt/ext3
+
+trap 'rm -f ${EXT3_IMAGE}' EXIT
+
+dd if=/dev/zero of=${EXT3_IMAGE} bs=1M count=1
+if [ "$?" -eq 0 ]; then
+   echo "PASS: dump ext3.img"
+else
+   echo "FAIL: dump ext3.img"
+   exit 1
+fi
+
+mkfs.ext3 -F ${EXT3_IMAGE}
+if [ "$?" -eq 0 ]; then
+   echo "PASS: mkfs.ext3 -F ext3.img"
+else
+   echo "FAIL: mkfs.ext3 -F ext3.img"
+   exit 1
+fi
+
+if [ -d $EXT3_MOUNT_POINT ]; then
+   echo "mount point exist"
+else
+   mkdir -p $EXT3_MOUNT_POINT
+fi
+
+
+mount -o loop,rw,acl  ${EXT3_IMAGE} $EXT3_MOUNT_POINT
+if [ "$?" -eq 0 ]; then
+   echo "PASS: mount ext3.img"
+else
+   echo "FAIL: mount ext3.img"
+   exit 1
+fi
+
+cp -rf ./test/ $EXT3_MOUNT_POINT
+
+cd $EXT3_MOUNT_POINT/test/
+
+if sed -e 's!^bin:x:2:$!bin:x:2:daemon!' < /etc/group > gtmp
+then   if  cp /etc/group group.orig;
+   thencp gtmp /etc/group
+   make  -k tests root-tests | sed \
+   -e 's|^\[.*\] \(.*\) -- ok$|PASS: \1|' \
+   -e 's|^\[.*\] \(.*\) -- failed|FAIL: \1|'
+   cp group.orig /etc/group
+   elseecho "FAIL: couldn't save original group file."
+   exit 1
+   fi
+else   echo "FAIL: couldn't create modified group file."
+   exit 1
+fi
+
+cd -
+umount $EXT3_MOUNT_POINT
+rm -rf $EXT3_MOUNT_POINT
+rm $EXT3_IMAGE
diff --git a/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch 
b/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch
new file mode 100644
index 000..cd4510c
--- /dev/null
+++ b/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch
@@ -0,0 +1,24 @@
+commit c45bae84817a70fef6c2b661a07a492a0d23ae85
+Author: Peter Seebach 
+Date:   Wed May 11 15:16:06 2016 -0500
+
+Fix permissions on temporary directory
+
+The temporary directory's permissions have to allow other users to
+view the directory. A default umask of 022 is common, but not mandatory,
+and secure systems may have more restrictive defaults.
+
+Signed-off-by: Peter Seebach 
+
+diff --git a/test/root/permissions.test b/test/root/permissions.test
+index 42615f5..098b52a 100644
+--- a/test/root/permissions.test
 b/test/root/permissions.test
+@@ -16,6 +16,7 @@ Cry immediately if we are not running as root.
+ First, set up a temporary directory and create a regular file with
+ defined permissions.
+ 
++  $ umask 022
+   $ mkdir d
+   $

90 matches

Mail list logo