Re: [OE-core] [PATCH] meson: use the more specific cpu arch in cross file

2020-07-29 Thread Ruslan Babayev 
Currently we have both cpu_family and cpu set to TARGET_ARCH which is
wrong. As mentioned before cpu is more specific. E.g where
cpu_family='x86-64' cpu='nehalem'.

Projects using Meson can query for the host_machine.cpu() and expect a more
specific CPU type.
Here's one example:
https://github.com/DPDK/dpdk/blob/74f4d6424da1297bd6e83dcb7bd8ca8c59dd/config/meson.build#L69




On Wed, Jul 29, 2020 at 9:55 PM Khem Raj  wrote:

>
>
> On 7/25/20 6:56 PM, Ruslan Babayev wrote:
> > 'cpu' unlike 'cpu_family' must be a more specific subtype for the CPU.
> >
>
> since mcpu/march should provide the right values already, do we need
> this additional logic in meson? dont we get needed settings to meson
> already?
>
> perhaps you can describe some missing cases this would address will help
> understand the usecase
>
> > Signed-off-by: Ruslan Babayev 
> > ---
> >   meta/classes/meson.bbclass | 14 --
> >   .../meson/nativesdk-meson_0.53.2.bb| 12 +++-
> >   2 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> > index ff52d20e56..0caa7a37c2 100644
> > --- a/meta/classes/meson.bbclass
> > +++ b/meta/classes/meson.bbclass
> > @@ -62,6 +62,16 @@ def meson_cpu_family(var, d):
> >   else:
> >   return arch
> >
> > +def meson_cpu(prefix, d):
> > +import re
> > +arch = d.getVar(prefix + "_ARCH")
> > +tune_ccargs = d.getVar("TUNE_CCARGS")
> > +m = re.search(r"(?<=-march=)\w+|(?<=-mcpu=)\w+", tune_ccargs)
> > +if m:
> > +return m.group(0)
> > +else:
> > +return arch
> > +
> >   # Map our OS values to what Meson expects:
> >   # https://mesonbuild.com/Reference-tables.html#operating-system-names
> >   def meson_operating_system(var, d):
> > @@ -110,13 +120,13 @@ gtkdoc_exe_wrapper = '${B}/gtkdoc-qemuwrapper'
> >   [host_machine]
> >   system = '${@meson_operating_system('HOST_OS', d)}'
> >   cpu_family = '${@meson_cpu_family('HOST_ARCH', d)}'
> > -cpu = '${HOST_ARCH}'
> > +cpu = '${@meson_cpu('HOST', d)}'
> >   endian = '${@meson_endian('HOST', d)}'
> >
> >   [target_machine]
> >   system = '${@meson_operating_system('TARGET_OS', d)}'
> >   cpu_family = '${@meson_cpu_family('TARGET_ARCH', d)}'
> > -cpu = '${TARGET_ARCH}'
> > +cpu = '${@meson_cpu('TARGET', d)}'
> >   endian = '${@meson_endian('TARGET', d)}'
> >   EOF
> >   }
> > diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
> b/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
> > index 67add2c25e..021bff0992 100644
> > --- a/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
> > +++ b/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
> > @@ -6,6 +6,16 @@ inherit siteinfo
> >   SRC_URI += "file://meson-setup.py \
> >   file://meson-wrapper"
> >
> > +def meson_cpu(var, d):
> > +import re
> > +arch = d.getVar(var)
> > +tune_ccargs = d.getVar("TUNE_CCARGS")
> > +m = re.search(r"(?<=-march=)\w+|(?<=-mcpu=)\w+", tune_ccargs)
> > +if m:
> > +return m.group(0)
> > +else:
> > +return arch
> > +
> >   def meson_endian(prefix, d):
> >   arch, os = d.getVar(prefix + "_ARCH"), d.getVar(prefix + "_OS")
> >   sitedata = siteinfo_data_for_machine(arch, os, d)
> > @@ -44,7 +54,7 @@ cpp_link_args = @LDFLAGS
> >   [host_machine]
> >   system = '${SDK_OS}'
> >   cpu_family = '${SDK_ARCH}'
> > -cpu = '${SDK_ARCH}'
> > +cpu = '${@meson_cpu("SDK_ARCH", d)}'
> >   endian = '${@meson_endian("SDK", d)}'
> >   EOF
> >
> >
> >
> > 
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141116): 
https://lists.openembedded.org/g/openembedded-core/message/141116
Mute This Topic: https://lists.openembedded.org/mt/75796683/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] systemd-getty-generator present but undesired

2020-07-29 Thread Khem Raj 



On 7/28/20 6:33 AM, Mike Looijmans wrote:
I had a hard time getting a serial attached bluetooth device to work, 
untilI discovered that systemd is running a "getty" on that port (which 
happens tobe "ttyS0").


The cause is that "systemd-getty-generator" detects that the port comes 
online (runtime, it's inside an FGPA) and then dynamically adds a 
service for it and starts a getty on it.


So when I went to solve that, I found that OE already attempted to solve 
that. There's a "systemd-getty-generator" PACKAGECONFIG that suggests 
that it should not be installed by default, but it gets installed 
anyway, even though this config is not set.


Is this something that needs fixing in OE?

Any better pointers at preventing systemd starting a getty on ttyS0?



you need to add serial-getty-generator to systemd PACKAGECONFIG to 
ignore the oe provided serial getty recipe.


I think it also has to do with SERIAL_CONSOLES setting for machine, 
perhaps it contains ttyS0 in your case.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141115): 
https://lists.openembedded.org/g/openembedded-core/message/141115
Mute This Topic: https://lists.openembedded.org/mt/75843935/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] meson: use the more specific cpu arch in cross file

2020-07-29 Thread Khem Raj 



On 7/25/20 6:56 PM, Ruslan Babayev wrote:

'cpu' unlike 'cpu_family' must be a more specific subtype for the CPU.



since mcpu/march should provide the right values already, do we need 
this additional logic in meson? dont we get needed settings to meson

already?

perhaps you can describe some missing cases this would address will help 
understand the usecase



Signed-off-by: Ruslan Babayev 
---
  meta/classes/meson.bbclass | 14 --
  .../meson/nativesdk-meson_0.53.2.bb| 12 +++-
  2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index ff52d20e56..0caa7a37c2 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -62,6 +62,16 @@ def meson_cpu_family(var, d):
  else:
  return arch
  
+def meson_cpu(prefix, d):

+import re
+arch = d.getVar(prefix + "_ARCH")
+tune_ccargs = d.getVar("TUNE_CCARGS")
+m = re.search(r"(?<=-march=)\w+|(?<=-mcpu=)\w+", tune_ccargs)
+if m:
+return m.group(0)
+else:
+return arch
+
  # Map our OS values to what Meson expects:
  # https://mesonbuild.com/Reference-tables.html#operating-system-names
  def meson_operating_system(var, d):
@@ -110,13 +120,13 @@ gtkdoc_exe_wrapper = '${B}/gtkdoc-qemuwrapper'
  [host_machine]
  system = '${@meson_operating_system('HOST_OS', d)}'
  cpu_family = '${@meson_cpu_family('HOST_ARCH', d)}'
-cpu = '${HOST_ARCH}'
+cpu = '${@meson_cpu('HOST', d)}'
  endian = '${@meson_endian('HOST', d)}'
  
  [target_machine]

  system = '${@meson_operating_system('TARGET_OS', d)}'
  cpu_family = '${@meson_cpu_family('TARGET_ARCH', d)}'
-cpu = '${TARGET_ARCH}'
+cpu = '${@meson_cpu('TARGET', d)}'
  endian = '${@meson_endian('TARGET', d)}'
  EOF
  }
diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb 
b/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
index 67add2c25e..021bff0992 100644
--- a/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
+++ b/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb
@@ -6,6 +6,16 @@ inherit siteinfo
  SRC_URI += "file://meson-setup.py \
  file://meson-wrapper"
  
+def meson_cpu(var, d):

+import re
+arch = d.getVar(var)
+tune_ccargs = d.getVar("TUNE_CCARGS")
+m = re.search(r"(?<=-march=)\w+|(?<=-mcpu=)\w+", tune_ccargs)
+if m:
+return m.group(0)
+else:
+return arch
+
  def meson_endian(prefix, d):
  arch, os = d.getVar(prefix + "_ARCH"), d.getVar(prefix + "_OS")
  sitedata = siteinfo_data_for_machine(arch, os, d)
@@ -44,7 +54,7 @@ cpp_link_args = @LDFLAGS
  [host_machine]
  system = '${SDK_OS}'
  cpu_family = '${SDK_ARCH}'
-cpu = '${SDK_ARCH}'
+cpu = '${@meson_cpu("SDK_ARCH", d)}'
  endian = '${@meson_endian("SDK", d)}'
  EOF
  





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141114): 
https://lists.openembedded.org/g/openembedded-core/message/141114
Mute This Topic: https://lists.openembedded.org/mt/75796683/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 

Khem Raj  writes:

> On Wed, Jul 29, 2020 at 8:27 PM Mingde (Matthew) Zeng
>  wrote:
>>
>>
>> Khem Raj  writes:
>>
>> > on master-next I am also seeing
>> >
>> > step1b: WARNING: ltp-20200515-r0 do_patch: QA Issue: Patch log
>> > indicates that patches do not apply cleanly. [patch-fuzz]
>> >
>> > I wonder if its related to this as well.
>>
>> My bad.
>>
>> Just a couple days ago ltp master introduced a commit directly effected the 
>> line above my change, resulting the diff to look slightly different.
>>
>> I could send a patch on top of this commit, or is it possible to revert this 
>> merged commit altogether and I will send a new patch, to keep the git log 
>> clean. Whichever preferred by YP.
>>
>
> its not in master yet so please send a v2.

Done.

>
>>
>> Matthew
>>
>> >
>> > On Wed, Jul 29, 2020 at 6:43 AM Richard Purdie
>> >  wrote:
>> >>
>> >> On Wed, 2020-07-29 at 09:41 -0400, Mingde (Matthew) Zeng wrote:
>> >> > Richard Purdie  writes:
>> >> >
>> >> > > On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
>> >> > > > Fixes [YOCTO #13802]
>> >> > >
>> >> > > Thanks, we can reference the bug but I don't think we can yet claim
>> >> > > it
>> >> > > fixes it.
>> >> >
>> >> > Sure, would something like the following work?
>> >> >
>> >> > Reference [YOCTO #13802]
>> >>
>> >> Simply "[YOCTO #13802]" is fine (I'll tweak the commit message as I
>> >> merge).
>> >>
>> >> > > The missing log issue happened again:
>> >> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
>> >> > > so I think there are multiple issues at play here.
>> >> >
>> >> > Can you attach this build's log.do_testimage so I can have a further
>> >> > look?
>> >>
>> >> Sorry, that build directory has been reused in this case :( Next time
>> >> that happens I'll try and spot/grab it.
>> >>
>> >> > > Is there any way to have the logging logged to disk straight away
>> >> > > rather than stuck internally in oeqa's logging buffers? That way we
>> >> > > could see which tests had run before a hang?
>> >> > >
>> >> > > Also, could we make the scp failure non-fatal, maybe a warning so
>> >> > > that
>> >> > > when it fails we can look at the rest of the logs?
>> >> >
>> >> > I'll further investigate this idea.
>> >>
>> >> Thanks!
>> >>
>> >> Cheers,
>> >>
>> >> Richard
>> >>
>> >> 
>>
>>
>> --
>> Mingde (Matthew) Zeng


--
Mingde (Matthew) Zeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141113): 
https://lists.openembedded.org/g/openembedded-core/message/141113
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCHv3] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 
[YOCTO #13802]

Remove the OOM tests, since they might cause oeqa ssh
connection lost.

Signed-off-by: Mingde (Matthew) Zeng 
---
 ...001-Remove-OOM-tests-from-runtest-mm.patch | 34 +++
 meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch 
b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
new file mode 100644
index 00..529065d979
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
@@ -0,0 +1,34 @@
+From 13ef88cdccfe3f58c53d57806866b91e310eb272 Mon Sep 17 00:00:00 2001
+From: "Mingde (Matthew) Zeng" 
+Date: Wed, 29 Jul 2020 08:47:09 -0400
+Subject: [PATCH] Remove OOM tests from runtest/mm
+
+Disable OOM tests, as they might cause oeqa ssh connection lost
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Mingde (Matthew) Zeng 
+
+---
+ runtest/mm | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/runtest/mm b/runtest/mm
+index a09f39c1e..76fa82754 100644
+--- a/runtest/mm
 b/runtest/mm
+@@ -73,12 +73,6 @@ ksm06 ksm06
+ ksm06_1 ksm06 -n 10
+ ksm06_2 ksm06 -n 1
+
+-oom01 oom01
+-oom02 oom02
+-oom03 oom03
+-oom04 oom04
+-oom05 oom05
+-
+ swapping01 swapping01 -i 5
+
+ thp01 thp01 -I 120
+--
+2.27.0
+
diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index ece3acf0f9..0c7044d044 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -37,6 +37,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0001-ptrace01-Fix-missing-format-string.patch \

file://0001-sigwaitinfo-Do-not-run-invalid-undefined-test-cases.patch \

file://0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch \
+   file://0001-Remove-OOM-tests-from-runtest-mm.patch \
"

 S = "${WORKDIR}/git"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141112): 
https://lists.openembedded.org/g/openembedded-core/message/141112
Mute This Topic: https://lists.openembedded.org/mt/75880209/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 00/17] Pull request (cover letter only)

2020-07-29 Thread Steve Sakoman 
The following changes since commit ea886d57db917a41a0d106a15e1e96c72d6407b0:

  kernel-yocto: account for extracted defconfig in elements check (2020-07-23 
04:07:37 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next

Armin Kuster (1):
  glibc: Secruity fix for CVE-2020-6096

Bruce Ashfield (2):
  linux-yocto/5.4: update to v5.4.51
  linux-yocto-rt/5.4: fix mmdrop stress test issues

Changqing Li (1):
  gtk-immodules-cache.bbclass: fix post install scriptlet error

Chen Qi (1):
  rpm: fix nativesdk's default var location

Daniel Ammann (1):
  image.bbclass: improve wording when image size exceeds the specified
limit

Joshua Watt (2):
  classes/cmake: Fix host detection
  classes/package: Use HOST_OS for runtime dependencies

Kevin Hao (3):
  wic/filemap: Drop the unused block_is_unmapped()
  wic/filemap: Drop the unused get_unmapped_ranges()
  wic/filemap: Fall back to standard copy when no way to get the block
map

Kurt Kiefer (1):
  linux-firmware: add ibt-20 package

Lee Chee Yang (1):
  buildhistory: use pid for temporary txt file name

Richard Purdie (1):
  oeqa/qemurunner: Add priority/nice information for running processes

Robert Yang (1):
  openssl: openssl-bin requires openssl-conf to run

Ross Burton (1):
  startup-notification: add time_t type mismatch patch from upstream

Sakib Sajal (1):
  busybox: make hwclock compatible with glibc 2.31

 meta/classes/buildhistory.bbclass |  11 +-
 meta/classes/cmake.bbclass|  19 +-
 meta/classes/gtk-immodules-cache.bbclass  |   1 +
 meta/classes/image.bbclass|   4 +-
 meta/classes/package.bbclass  |  10 +-
 meta/lib/oeqa/utils/qemurunner.py |   2 +-
 meta/lib/oeqa/utils/qemutinyrunner.py |   2 +-
 .../openssl/openssl_1.1.1g.bb |   2 +
 ...1-hwclock-make-glibc-2.31-compatible.patch |  83 
 meta/recipes-core/busybox/busybox_1.31.1.bb   |   1 +
 .../glibc/glibc/CVE-2020-6096.patch   | 112 ++
 .../glibc/glibc/CVE-2020-6096_2.patch | 194 ++
 meta/recipes-core/glibc/glibc_2.31.bb |   2 +
 meta/recipes-devtools/rpm/rpm_4.14.2.1.bb |   2 +-
 .../startup-notification-0.12/time_t.patch| 108 ++
 .../startup-notification_0.12.bb  |   1 +
 .../linux-firmware/linux-firmware_20200619.bb |   4 +
 .../linux/linux-yocto-rt_5.4.bb   |   6 +-
 .../linux/linux-yocto-tiny_5.4.bb |   8 +-
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  |  22 +-
 scripts/lib/wic/filemap.py|  75 +++
 21 files changed, 580 insertions(+), 89 deletions(-)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-hwclock-make-glibc-2.31-compatible.patch
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-6096.patch
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-6096_2.patch
 create mode 100644 
meta/recipes-graphics/startup-notification/startup-notification-0.12/time_t.patch

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14): 
https://lists.openembedded.org/g/openembedded-core/message/14
Mute This Topic: https://lists.openembedded.org/mt/75880133/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Khem Raj 
On Wed, Jul 29, 2020 at 8:27 PM Mingde (Matthew) Zeng
 wrote:
>
>
> Khem Raj  writes:
>
> > on master-next I am also seeing
> >
> > step1b: WARNING: ltp-20200515-r0 do_patch: QA Issue: Patch log
> > indicates that patches do not apply cleanly. [patch-fuzz]
> >
> > I wonder if its related to this as well.
>
> My bad.
>
> Just a couple days ago ltp master introduced a commit directly effected the 
> line above my change, resulting the diff to look slightly different.
>
> I could send a patch on top of this commit, or is it possible to revert this 
> merged commit altogether and I will send a new patch, to keep the git log 
> clean. Whichever preferred by YP.
>

its not in master yet so please send a v2.

>
> Matthew
>
> >
> > On Wed, Jul 29, 2020 at 6:43 AM Richard Purdie
> >  wrote:
> >>
> >> On Wed, 2020-07-29 at 09:41 -0400, Mingde (Matthew) Zeng wrote:
> >> > Richard Purdie  writes:
> >> >
> >> > > On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
> >> > > > Fixes [YOCTO #13802]
> >> > >
> >> > > Thanks, we can reference the bug but I don't think we can yet claim
> >> > > it
> >> > > fixes it.
> >> >
> >> > Sure, would something like the following work?
> >> >
> >> > Reference [YOCTO #13802]
> >>
> >> Simply "[YOCTO #13802]" is fine (I'll tweak the commit message as I
> >> merge).
> >>
> >> > > The missing log issue happened again:
> >> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
> >> > > so I think there are multiple issues at play here.
> >> >
> >> > Can you attach this build's log.do_testimage so I can have a further
> >> > look?
> >>
> >> Sorry, that build directory has been reused in this case :( Next time
> >> that happens I'll try and spot/grab it.
> >>
> >> > > Is there any way to have the logging logged to disk straight away
> >> > > rather than stuck internally in oeqa's logging buffers? That way we
> >> > > could see which tests had run before a hang?
> >> > >
> >> > > Also, could we make the scp failure non-fatal, maybe a warning so
> >> > > that
> >> > > when it fails we can look at the rest of the logs?
> >> >
> >> > I'll further investigate this idea.
> >>
> >> Thanks!
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >> 
>
>
> --
> Mingde (Matthew) Zeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141110): 
https://lists.openembedded.org/g/openembedded-core/message/141110
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 

Khem Raj  writes:

> on master-next I am also seeing
>
> step1b: WARNING: ltp-20200515-r0 do_patch: QA Issue: Patch log
> indicates that patches do not apply cleanly. [patch-fuzz]
>
> I wonder if its related to this as well.

My bad.

Just a couple days ago ltp master introduced a commit directly effected the 
line above my change, resulting the diff to look slightly different.

I could send a patch on top of this commit, or is it possible to revert this 
merged commit altogether and I will send a new patch, to keep the git log 
clean. Whichever preferred by YP.


Matthew

>
> On Wed, Jul 29, 2020 at 6:43 AM Richard Purdie
>  wrote:
>>
>> On Wed, 2020-07-29 at 09:41 -0400, Mingde (Matthew) Zeng wrote:
>> > Richard Purdie  writes:
>> >
>> > > On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
>> > > > Fixes [YOCTO #13802]
>> > >
>> > > Thanks, we can reference the bug but I don't think we can yet claim
>> > > it
>> > > fixes it.
>> >
>> > Sure, would something like the following work?
>> >
>> > Reference [YOCTO #13802]
>>
>> Simply "[YOCTO #13802]" is fine (I'll tweak the commit message as I
>> merge).
>>
>> > > The missing log issue happened again:
>> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
>> > > so I think there are multiple issues at play here.
>> >
>> > Can you attach this build's log.do_testimage so I can have a further
>> > look?
>>
>> Sorry, that build directory has been reused in this case :( Next time
>> that happens I'll try and spot/grab it.
>>
>> > > Is there any way to have the logging logged to disk straight away
>> > > rather than stuck internally in oeqa's logging buffers? That way we
>> > > could see which tests had run before a hang?
>> > >
>> > > Also, could we make the scp failure non-fatal, maybe a warning so
>> > > that
>> > > when it fails we can look at the rest of the logs?
>> >
>> > I'll further investigate this idea.
>>
>> Thanks!
>>
>> Cheers,
>>
>> Richard
>>
>> 


--
Mingde (Matthew) Zeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141109): 
https://lists.openembedded.org/g/openembedded-core/message/141109
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.1.2.rc1)

2020-07-29 Thread Sangeeta Jain 
Thanks,
sangeeta

> -Original Message-
> From: akuster808 
> Sent: Thursday, 30 July, 2020 7:51 AM
> To: Jain, Sangeeta ; yo...@lists.yoctoproject.org;
> openembedded-core 
> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> ; Yeoh, Ee Peng ; Chan,
> Aaron Chun Yew ;
> richard.pur...@linuxfoundation.org; sjolley.yp...@gmail.com;
> st...@sakoman.com
> Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-
> 3.1.2.rc1)
> 
> 
> 
> On 7/28/20 11:22 PM, Jain, Sangeeta wrote:
> > Hi All,
> >
> > This is the QA report for yocto-3.1.2.rc1:
> > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/t
> > ree/?h=intel-yocto-testresults
> 
> Is QA still having to perform the Manual test remotely?

We can access hardware now.
 
> 
> -armin
> >
> > === Summary 
> > No high milestone defects.
> > No new defects are found in this cycle.
> >
> > Thanks,
> > Sangeeta
> >

> >> -Original Message-
> >> From: yo...@lists.yoctoproject.org  On
> >> Behalf Of Pokybuild User
> >> Sent: Friday, 24 July, 2020 3:58 PM
> >> To: yo...@lists.yoctoproject.org
> >> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> >> ; Yeoh, Ee Peng ;
> >> Chan, Aaron Chun Yew ;
> >> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
> >> sjolley.yp...@gmail.com; Jain, Sangeeta ;
> >> st...@sakoman.com
> >> Subject: [yocto] QA notification for completed autobuilder build
> >> (yocto-
> >> 3.1.2.rc1)
> >>
> >>
> >> A build flagged for QA (yocto-3.1.2.rc1) was completed on the
> >> autobuilder and is available at:
> >>
> >>
> >> https://autobuilder.yocto.io/pub/releases/yocto-3.1.2.rc1
> >>
> >>
> >> Build hash information:
> >>
> >> bitbake: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57
> >> meta-arm: 4812a66527e88ebdc5351d5dbd63765abe4abf62
> >> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> >> meta-intel: 77831443738885d33bfa3a738fe6c4f0361e4892
> >> meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
> >> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
> >> oecore: ea886d57db917a41a0d106a15e1e96c72d6407b0
> >> poky: 569b1f5d67c57de957e243997c53ec2f81dc8dfe
> >>
> >>
> >>
> >> This is an automated message from the Yocto Project Autobuilder
> >> Git: git://git.yoctoproject.org/yocto-autobuilder2
> >> Email: richard.pur...@linuxfoundation.org
> >>
> >>
> >>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141108): 
https://lists.openembedded.org/g/openembedded-core/message/141108
Mute This Topic: https://lists.openembedded.org/mt/75860151/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [poky][zeus][PATCH] libpcre: Add fix for CVE-2020-14155

2020-07-29 Thread Anuj Mittal 
On Wed, 2020-07-29 at 18:25 +0530, saloni wrote:
> From: Rahul Taya 
> 
> Added below patch in libpcre
> CVE-2020-14155.patch
> 
> This patch fixes below error:
> PCRE could allow a remote attacker to execute arbitrary
> code on the system, caused by an integer overflow in
> libpcre via a large number after (?C substring.
> By sending a request with a large number, an attacker
> can execute arbitrary code on the system or
> cause the application to crash.
> 
> Upstream-Status: Pending
> 
> Tested-by: Rahul Taya 
> Signed-off-by: Saloni Jain 
> ---
>  .../libpcre/libpcre/CVE-2020-14155.patch   | 40
> ++
>  meta/recipes-support/libpcre/libpcre_8.44.bb   |  3 +-

zeus has libpcre version 8.43. Also it looks like this specific fix is
already is 8.44.

So please test and send again for proper version & branch.

Thanks,

Anuj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141107): 
https://lists.openembedded.org/g/openembedded-core/message/141107
Mute This Topic: https://lists.openembedded.org/mt/75863890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.1.2.rc1)

2020-07-29 Thread akuster 


On 7/28/20 11:22 PM, Jain, Sangeeta wrote:
> Hi All,
>
> This is the QA report for yocto-3.1.2.rc1:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

Is QA still having to perform the Manual test remotely?

-armin
>
> === Summary 
> No high milestone defects.  
> No new defects are found in this cycle.
>
> Thanks,
> Sangeeta
>
>> -Original Message-
>> From: yo...@lists.yoctoproject.org  On Behalf
>> Of Pokybuild User
>> Sent: Friday, 24 July, 2020 3:58 PM
>> To: yo...@lists.yoctoproject.org
>> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>> ; Yeoh, Ee Peng ; Chan,
>> Aaron Chun Yew ;
>> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
>> sjolley.yp...@gmail.com; Jain, Sangeeta ;
>> st...@sakoman.com
>> Subject: [yocto] QA notification for completed autobuilder build (yocto-
>> 3.1.2.rc1)
>>
>>
>> A build flagged for QA (yocto-3.1.2.rc1) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>> https://autobuilder.yocto.io/pub/releases/yocto-3.1.2.rc1
>>
>>
>> Build hash information:
>>
>> bitbake: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57
>> meta-arm: 4812a66527e88ebdc5351d5dbd63765abe4abf62
>> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
>> meta-intel: 77831443738885d33bfa3a738fe6c4f0361e4892
>> meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
>> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
>> oecore: ea886d57db917a41a0d106a15e1e96c72d6407b0
>> poky: 569b1f5d67c57de957e243997c53ec2f81dc8dfe
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141106): 
https://lists.openembedded.org/g/openembedded-core/message/141106
Mute This Topic: https://lists.openembedded.org/mt/75860151/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Khem Raj 
on master-next I am also seeing

step1b: WARNING: ltp-20200515-r0 do_patch: QA Issue: Patch log
indicates that patches do not apply cleanly. [patch-fuzz]

I wonder if its related to this as well.

On Wed, Jul 29, 2020 at 6:43 AM Richard Purdie
 wrote:
>
> On Wed, 2020-07-29 at 09:41 -0400, Mingde (Matthew) Zeng wrote:
> > Richard Purdie  writes:
> >
> > > On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
> > > > Fixes [YOCTO #13802]
> > >
> > > Thanks, we can reference the bug but I don't think we can yet claim
> > > it
> > > fixes it.
> >
> > Sure, would something like the following work?
> >
> > Reference [YOCTO #13802]
>
> Simply "[YOCTO #13802]" is fine (I'll tweak the commit message as I
> merge).
>
> > > The missing log issue happened again:
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
> > > so I think there are multiple issues at play here.
> >
> > Can you attach this build's log.do_testimage so I can have a further
> > look?
>
> Sorry, that build directory has been reused in this case :( Next time
> that happens I'll try and spot/grab it.
>
> > > Is there any way to have the logging logged to disk straight away
> > > rather than stuck internally in oeqa's logging buffers? That way we
> > > could see which tests had run before a hang?
> > >
> > > Also, could we make the scp failure non-fatal, maybe a warning so
> > > that
> > > when it fails we can look at the rest of the logs?
> >
> > I'll further investigate this idea.
>
> Thanks!
>
> Cheers,
>
> Richard
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141105): 
https://lists.openembedded.org/g/openembedded-core/message/141105
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-29 Thread Andre McCurdy 
On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen  wrote:
>
> On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj  wrote:
> > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen  wrote:
> > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > If a recipe provides NEON optimizations, should those be 
> > > > > > > explicitly
> > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the 
> > > > > > > software is
> > > > > > > able to detect NEON availability at runtime?
> > > > > > >
> > > > > > > I'm currently converting the pulseaudio recipe from Autotools to 
> > > > > > > Meson,
> > > > > > > and the old Autotools build system supports disabling NEON
> > > > > > > optimizations but the Meson build system doesn't. So I'm 
> > > > > > > wondering if I
> > > > > > > should add the missing feature to the Meson build system, or just 
> > > > > > > let
> > > > > > > the runtime detection do its work.
> > > > > > >
> > > > > > > Is there ever need for disabling NEON optimizations if the CPU
> > > > > > > indicates NEON support? I guess it could be useful for testing 
> > > > > > > the "no
> > > > > > > NEON" case (I today found out that dropping "neon" from 
> > > > > > > TUNE_FEATURES
> > > > > > > doesn't remove NEON support from the qemuarm machine), but 
> > > > > > > otherwise it
> > > > > > > seems unnecessary, unless there are CPUs that advertise NEON 
> > > > > > > support
> > > > > > > but don't actually support it.
> > > > > > >
> > > > > >
> > > > > > I think the issue will result in a compiler error perhaps when neon 
> > > > > > is
> > > > > > disabled via
> > > > > > compiler command line which would be the case when neon is not in 
> > > > > > TUNE_FEATURES
> > > > > > the compiler might warn or error out when it finds neon instructions
> > > > > > being compiled via inline
> > > > > > assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> > > > > > some such and see if
> > > > > > compiler/assembler complains during build, if not then perhaps its 
> > > > > > fine.
> > > > >
> > > > > If the last -mfpu is something else than neon, then including
> > > > > arm_neon.h will succeed but compiling neon code will fail.
> > > > >
> > > > > I did some experiments, and what I found was that when I remove neon
> > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
> > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to
> > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon
> > > > > code gets built without errors.
> > > > >
> > > > > The configure check in PulseAudio only checks that the compiler 
> > > > > accepts
> > > > > -mfpu=neon and #include , it doesn't try to compile any
> > > > > actual neon code. This means that if the user adds -mfpu=vfp (or other
> > > > > non-neon) to CFLAGS rather than CC, configure will pass but building
> > > > > will fail. Is this something to guard against? A default qemuarm build
> > > > > doesn't do this, so I don't know if this ever happens in OE.
> > > > >
> > > > > I don't know yet how Meson behaves, I'll continue testing...
> > > >
> > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
> > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
> > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
> > > > enabled in any case.
> > > >
> > > > So, Meson seems pretty safe, although I guess it would be nice not to
> > > > override the user's -mfpu setting. I think this isn't a big problem is
> > > > practice, since runtime detection works.
> > > >
> > > > I haven't tested with a compiler that truly can't build Neon code,
> > > > because I don't know how to do that.
> >
> > Presumably set a -mcpu=XXX to something which can never support NEON?
>
> No success so far...
>
> I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio
> recipe, but Neon got still enabled. GCC warned that -march=armv7ve
> conflicted with the chosen -mcpu (which makes sense, since "ve" in
> "armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't
> have virtualization support, and all cores that have virtualization
> support have mandatory Neon support).

Is that true? If so then the various armv7ve specific tuning files
(tune-cortexa15.inc, etc) could all be simplified by removing the
option to disable NEON support.

> Then I tried adding -march=armv7a to the pulseaudio CFLAGS, but then
> the build failed, because Meson failed some C++ linker check ("Unable
> to determine dynamic linker").
>
> Then I tried to remove armv7ve and add cortexa9 to TUNE_FEATURES, but
> GCC didn't like that at all, nothing built any more.
>
> I'm still in the process of trying different combinations. Maybe it
> would

Re: [OE-core] [PATCH] meson: use the more specific cpu arch in cross file

2020-07-29 Thread Ruslan Babayev 
Hi Ross,

What do you think of the patch? Any objections to merging it? Do you have
any feedback?

Thanks,
Ruslan

On Mon, Jul 27, 2020 at 12:03 PM Ruslan Babayev  wrote:

> Hi Ross,
>
> According to https://mesonbuild.com/Cross-compilation.html
>
> There are two different values for the CPU. The first one is cpu_family.
> It is a general type of the CPU. This should have a value from the CPU
> Family table .
> *Note* that meson does not add el to end cpu_family value for little
> endian systems. Big endian and little endian mips are both just mips,
> with the endian field set approriately.
>
> The second value is cpu which is a more specific subtype for the CPU.
> Typical values for a x86 CPU family might include i386 or i586 and for arm
>  family armv5 or armv7hl. Note that CPU type strings are very system
> dependent. You might get a different value if you check its value on the
> same machine but with different operating systems.
> At the moment both 'cpu_family' and 'cpu' are being set to TARGET_ARCH
> (like x86_64) in meson cross file.
>
> TUNE_CCARSG usually contains the exact subfamily either as -march= or
> -mcpu=
>
> The meson_cpu function will use regex to search for -march and if that's
> missing for -mcpu value. If both flags are missing it defaults to
> TARGET_ARCH.
>
> Ruslan
>
>
> On Mon, Jul 27, 2020 at 3:52 AM Ross Burton  wrote:
>
>> On Sun, 26 Jul 2020 at 02:56, Ruslan Babayev  wrote:
>> > 'cpu' unlike 'cpu_family' must be a more specific subtype for the CPU.
>>
>> Can you elaborate here some more?
>>
>> Ross
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141103): 
https://lists.openembedded.org/g/openembedded-core/message/141103
Mute This Topic: https://lists.openembedded.org/mt/75796683/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH 0/3] Log colorizer

2020-07-29 Thread Chris Laplante via lists.openembedded.org 
Hi Richard,

> This looks interesting. Could we add something to the manual about how to
> use it and maybe a test for it as well please?


Halfway through writing the tests, and I realized 
LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT doesn’t quite work. I wrote a test 
recipe with a do_compile that purposely fails with a compile error, to check 
whether color diagnostics work.

But I'm getting color text printed out after "Log data follows: " which is 
knotty's response to the bb.build.TaskFailed. 

This is because of some code of _exec_task in build.py. 


581 try:
582 for func in (prefuncs or '').split():
583 exec_func(func, localdata)
584 exec_func(task, localdata)
585 for func in (postfuncs or '').split():
586 exec_func(func, localdata)
587 except bb.BBHandledException:
588 event.fire(TaskFailed(task, fn, logfn, localdata, True), 
localdata)
589 return 1
590 except Exception as exc:
591 if quieterr:
592 event.fire(TaskFailedSilent(task, fn, logfn, localdata), 
localdata)
593 else:
594 errprinted = errchk.triggered
595 logger.error(str(exc))
596 event.fire(TaskFailed(task, fn, logfn, localdata, 
errprinted), localdata)
597 return 1


The color output is coming from line 595. The CommandFailed exception from 
bb.process.run carries with it the stdout of the process, which in this case 
has color text. 

I think at this point, I question whether I should just integrate with bit 
BitBake bake directly. If I were to do that, I could also fix the limitation of 
.color and .nocolor logs not having output from pre/postfuncs. I propose this:

log-colorizer.bbclass:
1. Responsible for setting up CFLAGS
2. Responsible for passing the appropriate flags/environment variables 
depending on build system in use (for example, the little bit of code I have 
targeting CMake).

BitBake:
1. Ensure progress handlers only see filtered output. At the BitBake 
level I can just do this directly and not mess around with proxy progress 
handlers.
2. Create a "--suppress-color" flag that filters out ANSI escape 
sequences from the console and the task log 
3. Maintain the .nocolor and .color versions of the logs. Though I'm 
not sure how I'd keep LOG_COLORIZER_TASKS-like functionality (which only writes 
.nocolor/.color logs for tasks we actually expect to produce color output). 
Maybe I should do it automatically based on whether any escape sequences are 
detected.

The user would still be responsible for INHERIT'ing log-colorizer globally or 
per-recipe. 

What do you think?

Thanks,
Chris
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141102): 
https://lists.openembedded.org/g/openembedded-core/message/141102
Mute This Topic: https://lists.openembedded.org/mt/75836416/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] qemumips: Use 34Kf CPU emulation

2020-07-29 Thread Khem Raj 
On Wed, Jul 29, 2020 at 3:13 AM Richard Purdie
 wrote:
>
> On Wed, 2020-07-29 at 10:56 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Tue, 2020-07-28 at 19:28 -0700, Khem Raj wrote:
> > > Few years ago we switched to using mips32r2 tunings for qemumips
> > > however
> > > the default CPU emulation still remained 24Kf which is not optimal
> > > for
> > > mips32r2 ISA for qemu [1], therefore switch to recommended 32Kf for
> > > CPU
> > > emulation when running qemu in system mode
> > >
> > > Boot time to console is ~1s faster with this setting, hopefully
> > > this
> > > should speed up qemumips in general
> > >
> > > [1]
> > > https://www.qemu.org/docs/master/system/target-mips.html#preferred-cpu-models-for-mips-hosts
> > >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/conf/machine/qemumips.conf | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/conf/machine/qemumips.conf
> > > b/meta/conf/machine/qemumips.conf
> > > index 31ad754483..4617c3c7b6 100644
> > > --- a/meta/conf/machine/qemumips.conf
> > > +++ b/meta/conf/machine/qemumips.conf
> > > @@ -12,3 +12,5 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
> > >  SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
> > >
> > >  QB_SYSTEM_NAME = "qemu-system-mips"
> > > +
> > > +QB_CPU = "-cpu 34Kf"
> >
> > Thanks!
> >
> > I did run some tests locally, timing core-image-sato -c testimage
> > before and after this change. It took 999s before, 1018s after but
> > the difference looks like noise rather than any speedup or slowdown.
>
> Another try at "after" got 986s so who knows :)
>

Yeah I saw that first boot was slower but reboots were always 1s
faster, but hopefully it
will help with irregular timeouts on tests which is what we are looking for.

> Cheers,
>
> Richard
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141101): 
https://lists.openembedded.org/g/openembedded-core/message/141101
Mute This Topic: https://lists.openembedded.org/mt/75857901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [poky][zeus][PATCH] libpcre: Add fix for CVE-2020-14155

2020-07-29 Thread Khem Raj 
On Wed, Jul 29, 2020 at 5:56 AM Saloni Jain  wrote:
>
> From: Rahul Taya 
>
> Added below patch in libpcre
> CVE-2020-14155.patch
>
> This patch fixes below error:
> PCRE could allow a remote attacker to execute arbitrary
> code on the system, caused by an integer overflow in
> libpcre via a large number after (?C substring.
> By sending a request with a large number, an attacker
> can execute arbitrary code on the system or
> cause the application to crash.
>
> Upstream-Status: Pending

you don't need this here. its needed in package patch header which you
already have
secondly do we need this on master and dunfell ?

>
> Tested-by: Rahul Taya 
> Signed-off-by: Saloni Jain 
> ---
>  .../libpcre/libpcre/CVE-2020-14155.patch   | 40 
> ++
>  meta/recipes-support/libpcre/libpcre_8.44.bb   |  3 +-
>  2 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch
>
> diff --git a/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch 
> b/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch
> new file mode 100644
> index 000..d6cb9bf
> --- /dev/null
> +++ b/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch
> @@ -0,0 +1,40 @@
> +--- pcre-8.43/pcre_compile.c2020-07-05 22:26:25.310501521 +0530
>  pcre-8.43/pcre_compile1.c   2020-07-05 22:30:22.254489562 +0530
> +
> +CVE: CVE-2020-14155
> +Upstream-Status: Backport 
> [https://vcs.pcre.org/pcre/code/trunk/pcre_compile.c?view=patch&r1=1761&r2=1760&pathrev=1761]
> +
> +@@ -6,7 +6,7 @@
> + and semantics are as close as possible to those of the Perl 5 language.
> +
> +Written by Philip Hazel
> +-   Copyright (c) 1997-2018 University of Cambridge
> ++   Copyright (c) 1997-2020 University of Cambridge
> +
> + 
> -
> + Redistribution and use in source and binary forms, with or without
> +@@ -7130,17 +7130,19 @@
> +   int n = 0;
> +   ptr++;
> +   while(IS_DIGIT(*ptr))
> ++   {
> + n = n * 10 + *ptr++ - CHAR_0;
> ++if (n > 255)
> ++   {
> ++   *errorcodeptr = ERR38;
> ++   goto FAILED;
> ++   }
> ++}
> +   if (*ptr != CHAR_RIGHT_PARENTHESIS)
> + {
> + *errorcodeptr = ERR39;
> + goto FAILED;
> + }
> +-  if (n > 255)
> +-{
> +-*errorcodeptr = ERR38;
> +-goto FAILED;
> +-}
> +   *code++ = n;
> +   PUT(code, 0, (int)(ptr - cd->start_pattern + 1)); /* Pattern 
> offset */
> +   PUT(code, LINK_SIZE, 0);  /* Default 
> length */
> diff --git a/meta/recipes-support/libpcre/libpcre_8.44.bb 
> b/meta/recipes-support/libpcre/libpcre_8.44.bb
> index e5471e8..81b38bb 100644
> --- a/meta/recipes-support/libpcre/libpcre_8.44.bb
> +++ b/meta/recipes-support/libpcre/libpcre_8.44.bb
> @@ -11,7 +11,8 @@ SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre-${PV}.tar.bz2 
> \
> file://fix-pcre-name-collision.patch \
> file://run-ptest \
> file://Makefile \
> -   "
> +   file://CVE-2020-14155.patch \
> +"
>
>  SRC_URI[md5sum] = "cf7326204cc46c755b5b2608033d9d24"
>  SRC_URI[sha256sum] = 
> "19108658b23b3ec5058edc9f66ac545ea19f9537234be1ec62b714c84399366d"
> --
> 2.7.4
>
> This message contains information that may be privileged or confidential and 
> is the property of the KPIT Technologies Ltd. It is intended only for the 
> person to whom it is addressed. If you are not the intended recipient, you 
> are not authorized to read, print, retain copy, disseminate, distribute, or 
> use this message or any part thereof. If you receive this message in error, 
> please notify the sender immediately and delete all copies of this message. 
> KPIT Technologies Ltd. does not accept any liability for virus infected mails.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141100): 
https://lists.openembedded.org/g/openembedded-core/message/141100
Mute This Topic: https://lists.openembedded.org/mt/75863890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] kernel-fitimage: build configuration for image tree when dtb is not present

2020-07-29 Thread Usama Arif 



On 28/07/2020 11:19, Usama Arif wrote:



On 27/07/2020 11:56, Richard Purdie wrote:

On Mon, 2020-07-20 at 18:21 +0100, Usama Arif wrote:

On 20/07/2020 08:41, Richard Purdie via lists.openembedded.org wrote:

On Fri, 2020-07-17 at 15:19 +0100, Usama Arif wrote:

This patch adds support for adding default config node even
when dtb is not part of the FIT image. The conf options are
therefore changed to point to kernel ID rather than dtb
ID when dtb does not exist.

Signed-off-by: Usama Arif 
---
   meta/classes/kernel-fitimage.bbclass | 14 --
   1 file changed, 12 insertions(+), 2 deletions(-)


I keep asking someone to start providing tests for kernel-fitimage
but nobody does. Its near impossible to tell whether this is a good
change or one that could cause someone else problems as we have
little documented behaviour and no tests.

Could someone please start looking at adding some (and
documentation)?


There are different components that can be added to a FIT image.
This include kernel, ramdisk, dtb, etc. However, it is not necessary
for any individual component to be part of the FIT image. In reality,
you can have 0-N (0 to N) kernels and/or 0-N ramdisks and/or 0-N
dtbs.

However, kernel-fitimage.bbclass currently only supports limited
usescases: adding 1 (no more or less) kernel with 1-N dtbs and 0-1
ramdisks.

Before support was added for multiple dtbs, the configuration of FIT
image without any dtbs was supported.

This patchset adds back the original support to kernel-
fitimage.bbclass
for building a FIT image when no dtbs are present. i.e. adds support
for
1 kernel with 0-N dtbs. It doesnot affect the existing usecases, but
adds back support for a usecase (0 dtb) that originally existed and
was
removed as a mistake.

I have submitted a v2 of this patch which better documents the code I
have submitted so that hopefully its not blocked on the testing and
documentation of the entire kernel-fitimage. It also always creates a
configuration for FIT image.

I guess i have spent some time debugging kernel-fitimage so am happy
to help with the documentation. I guess you would like a high level
description of kernel-fitimage at the top of this file as a seperate
patch?

I havent worked with the test framework for oe-core so not sure how
helpful i could be on that. I tried to look for example test cases
that
would test any of the existing meta/classes/kernel*.bbclass but
couldnt
find any.

Hopefully the extra documentation in v2 and the explanation would be
useful in understanding and progressing this patch.


Sorry for the delayed reply. Thanks for adding the extra info, it does
help.

By documentation, I mean that kernel-fitimage.bbclass has no
information in the reference manual:

https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-kernel-fitimage 



generated from:
http://git.yoctoproject.org/cgit.cgi/yocto-docs/tree/documentation/ref-manual/ref-classes.xml 



and also there is also no header at the start of the class saying what
it does or how to use it.

Could we add something to these locations to give more information
about the class?

For testing, have a look at
meta/lib/oeqa/selftest/cases/imagefeatures.py. Its testing target image
rootfs settings but I believe the concept is similar to how you'd test
something like the kernel-fitimage class.

You can run these tests individually with "oe-selftest -r
imagefeatures" to run that file or "oe-selftest -r
imagefeatures.ImageFeatures.test_bmap" as an example of a specific
test.

Cheers,

Richard



Hi,

Thanks for the reply. I will submit the documentation and the tests in 
the next couple of days.


Regards,
Usama


Hi,

Thanks for the pointers on the documentation and testcase. I have 
submitted patches for documentation 
(https://lists.yoctoproject.org/g/docs/message/319) and testcase 
(https://lists.openembedded.org/g/openembedded-core/message/141097). 
These assume that the 1 kernel, 1 RAM disk and no dtb case that the v2 
version of this patch solves will be supported and the testcase will 
only pass when the usecase is supported. I hope that the v2 of this 
patch can now progress.


Thanks,
Usama
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141099): 
https://lists.openembedded.org/g/openembedded-core/message/141099
Mute This Topic: https://lists.openembedded.org/mt/75612723/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] oeqa/selftest/imagefeatures: Add testcase for fitImage

2020-07-29 Thread Usama Arif 



On 29/07/2020 15:41, Usama Arif wrote:

This testcase generates the Image Tree Source and
the corresponding fitImage containing a kernel and
a ramdisk. It then checks if the these files exist
and if the right fields are present in the right
order in the Image Tree Source.

Tested with: oe-selftest -r  imagefeatures.ImageFeatures.test_fit_image

Signed-off-by: Usama Arif 
Cc: Richard Purdie 
---
  meta/lib/oeqa/selftest/cases/imagefeatures.py | 74 +++
  1 file changed, 74 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index dea519e6df..f7a2533746 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -263,6 +263,80 @@ PNBLACKLIST[busybox] = "Don't build this"
  
  bitbake("--graphviz core-image-sato")
  
+def test_fit_image(self):

+"""
+Summary: Check if FIT image and Image Tree Source (its) are built
+ and the Image Tree Source has the correct fields.
+Expected:1. fitImage and fitImage-its can be built
+ 2. The type, load address, entrypoint address and
+ default values of kernel and ramdisk are as expected
+ in the Image Tree Source. Not all the fields are tested,
+ only the key fields that wont vary between different
+ architectures.
+Product: oe-core
+Author:  Usama Arif 
+"""
+config = """
+# Enable creation of fitImage
+KERNEL_IMAGETYPE = "Image"
+KERNEL_IMAGETYPES += " fitImage "
+KERNEL_CLASSES = " kernel-fitimage "
+
+# RAM disk variables including load address and entrypoint for kernel and RAM 
disk
+IMAGE_FSTYPES += "cpio.gz"
+INITRAMFS_IMAGE = "core-image-minimal"
+UBOOT_RD_LOADADDRESS = "0x8800"
+UBOOT_RD_ENTRYPOINT = "0x8800"
+UBOOT_LOADADDRESS = "0x8008"
+UBOOT_ENTRYPOINT = "0x8008"
+"""
+self.write_config(config)
+
+# fitImage is created as part of linux recipe
+bitbake("virtual/kernel")
+
+image_type = "core-image-minimal"
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+machine = get_bb_var('MACHINE')
+fitimage_its_path = os.path.join(deploy_dir_image,
+"fitImage-its-%s-%s-%s" % (image_type, machine, machine))
+fitimage_path = os.path.join(deploy_dir_image,
+"fitImage-%s-%s-%s" % (image_type, machine, machine))
+
+self.assertTrue(os.path.exists(fitimage_its_path),
+"%s image tree source doesn't exist" % (fitimage_its_path))
+self.assertTrue(os.path.exists(fitimage_path),
+"%s FIT image doesn't exist" % (fitimage_path))
+
+# Check that the type, load address, entrypoint address and default
+# values for kernel and ramdisk in Image Tree Source are as expected.
+# The order of fields in the below array is important. Not all the
+# fields are tested, only the key fields that wont vary between
+# different architectures.
+its_field_check = ['type = "kernel";',
+'load = <0x8008>;',
+'entry = <0x8008>;',
+'type = "ramdisk";',
+'load = <0x8800>;',
+'entry = <0x8800>;',
+'default = "conf@1";',
+'kernel = "kernel@1";',
+'ramdisk = "ramdisk@1";'
+]
+
+with open(fitimage_its_path) as its_file:
+field_index = 0
+for line in its_file:
+if field_index == len(its_field_check):
+break
+if its_field_check[field_index] in line:
+field_index +=1
+
+if field_index != len(its_field_check): # if its equal, the test passed
+self.assertTrue(field_index == len(its_field_check),
+"Fields in Image Tree Source File %s did not match, error in 
finding %s"
+% (fitimage_its_path, its_field_check[field_index]))
+
  def test_image_gen_debugfs(self):
  """
  Summary: Check debugfs generation




Hi

This test assumes that the case for a single kernel and single
RAM disk with no dtb is supported by kernel-fitimage.bbclass.
https://lists.openembedded.org/g/openembedded-core/message/140810 adds
support for this combination of usecase and the test wont pass without 
the usecase being supported.


Thanks,
Usama
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141098): 
https://lists.openembedded.org/g/openembedded-core/message/141098
Mute This Topic: https://lists.openembedded.org/mt/75865813/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] oeqa/selftest/imagefeatures: Add testcase for fitImage

2020-07-29 Thread Usama Arif 
This testcase generates the Image Tree Source and
the corresponding fitImage containing a kernel and
a ramdisk. It then checks if the these files exist
and if the right fields are present in the right
order in the Image Tree Source.

Tested with: oe-selftest -r  imagefeatures.ImageFeatures.test_fit_image

Signed-off-by: Usama Arif 
Cc: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/imagefeatures.py | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index dea519e6df..f7a2533746 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -263,6 +263,80 @@ PNBLACKLIST[busybox] = "Don't build this"
 
 bitbake("--graphviz core-image-sato")
 
+def test_fit_image(self):
+"""
+Summary: Check if FIT image and Image Tree Source (its) are built
+ and the Image Tree Source has the correct fields.
+Expected:1. fitImage and fitImage-its can be built
+ 2. The type, load address, entrypoint address and
+ default values of kernel and ramdisk are as expected
+ in the Image Tree Source. Not all the fields are tested,
+ only the key fields that wont vary between different
+ architectures.
+Product: oe-core
+Author:  Usama Arif 
+"""
+config = """
+# Enable creation of fitImage
+KERNEL_IMAGETYPE = "Image"
+KERNEL_IMAGETYPES += " fitImage "
+KERNEL_CLASSES = " kernel-fitimage "
+
+# RAM disk variables including load address and entrypoint for kernel and RAM 
disk
+IMAGE_FSTYPES += "cpio.gz"
+INITRAMFS_IMAGE = "core-image-minimal"
+UBOOT_RD_LOADADDRESS = "0x8800"
+UBOOT_RD_ENTRYPOINT = "0x8800"
+UBOOT_LOADADDRESS = "0x8008"
+UBOOT_ENTRYPOINT = "0x8008"
+"""
+self.write_config(config)
+
+# fitImage is created as part of linux recipe
+bitbake("virtual/kernel")
+
+image_type = "core-image-minimal"
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+machine = get_bb_var('MACHINE')
+fitimage_its_path = os.path.join(deploy_dir_image,
+"fitImage-its-%s-%s-%s" % (image_type, machine, machine))
+fitimage_path = os.path.join(deploy_dir_image,
+"fitImage-%s-%s-%s" % (image_type, machine, machine))
+
+self.assertTrue(os.path.exists(fitimage_its_path),
+"%s image tree source doesn't exist" % (fitimage_its_path))
+self.assertTrue(os.path.exists(fitimage_path),
+"%s FIT image doesn't exist" % (fitimage_path))
+
+# Check that the type, load address, entrypoint address and default
+# values for kernel and ramdisk in Image Tree Source are as expected.
+# The order of fields in the below array is important. Not all the
+# fields are tested, only the key fields that wont vary between
+# different architectures.
+its_field_check = ['type = "kernel";',
+'load = <0x8008>;',
+'entry = <0x8008>;',
+'type = "ramdisk";',
+'load = <0x8800>;',
+'entry = <0x8800>;',
+'default = "conf@1";',
+'kernel = "kernel@1";',
+'ramdisk = "ramdisk@1";'
+]
+
+with open(fitimage_its_path) as its_file:
+field_index = 0
+for line in its_file:
+if field_index == len(its_field_check):
+break
+if its_field_check[field_index] in line:
+field_index +=1
+
+if field_index != len(its_field_check): # if its equal, the test passed
+self.assertTrue(field_index == len(its_field_check),
+"Fields in Image Tree Source File %s did not match, error in 
finding %s"
+% (fitimage_its_path, its_field_check[field_index]))
+
 def test_image_gen_debugfs(self):
 """
 Summary: Check debugfs generation
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141097): 
https://lists.openembedded.org/g/openembedded-core/message/141097
Mute This Topic: https://lists.openembedded.org/mt/75865813/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH 0/3] Log colorizer

2020-07-29 Thread Chris Laplante via lists.openembedded.org 
Hi Richard,

> You can run these tests individually with "oe-selftest -r imagefeatures" to 
> run
> that file or "oe-selftest -r imagefeatures.ImageFeatures.test_bmap" as an
> example of a specific test.

I'm developing the tests for log colorizer and I had a question about 
oe-selftest. Is there a way to re-run the tests without having to delete the 
build-st directory and start from scratch? It would save me time.  

$ oe-selftest -r log_colorizer.LogColorizerTests.test_log_colorizer_basic 
2020-07-29 10:26:55,619 - oe-selftest - INFO - Adding layer libraries:
2020-07-29 10:26:55,620 - oe-selftest - INFO -  
/home/laplante/repos/oe-core/meta/lib
2020-07-29 10:26:55,620 - oe-selftest - INFO -  
/home/laplante/repos/oe-core/meta-selftest/lib
2020-07-29 10:26:55,620 - oe-selftest - INFO - Running bitbake -e to test the 
configuration is valid/parsable
2020-07-29 10:26:57,190 - oe-selftest - ERROR - Build directory 
/home/laplante/repos/oe-core/build-st already exists, aborting

Thanks,
Chris 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141096): 
https://lists.openembedded.org/g/openembedded-core/message/141096
Mute This Topic: https://lists.openembedded.org/mt/75836416/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for boost: backport fix to make async_pipes work with asio

2020-07-29 Thread Patchwork 
== Series Details ==

Series: boost: backport fix to make async_pipes work with asio
Revision: 1
URL   : https://patchwork.openembedded.org/series/25388/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-support/boost/boost/0001-added-typedef-executor_type.patch)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141095): 
https://lists.openembedded.org/g/openembedded-core/message/141095
Mute This Topic: https://lists.openembedded.org/mt/75865081/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-29 Thread Tanu Kaskinen 
On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> On Sun, Jul 26, 2020 at 7:01 AM Khem Raj  wrote:
> > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen  wrote:
> > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > If a recipe provides NEON optimizations, should those be explicitly
> > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software 
> > > > > > is
> > > > > > able to detect NEON availability at runtime?
> > > > > > 
> > > > > > I'm currently converting the pulseaudio recipe from Autotools to 
> > > > > > Meson,
> > > > > > and the old Autotools build system supports disabling NEON
> > > > > > optimizations but the Meson build system doesn't. So I'm wondering 
> > > > > > if I
> > > > > > should add the missing feature to the Meson build system, or just 
> > > > > > let
> > > > > > the runtime detection do its work.
> > > > > > 
> > > > > > Is there ever need for disabling NEON optimizations if the CPU
> > > > > > indicates NEON support? I guess it could be useful for testing the 
> > > > > > "no
> > > > > > NEON" case (I today found out that dropping "neon" from 
> > > > > > TUNE_FEATURES
> > > > > > doesn't remove NEON support from the qemuarm machine), but 
> > > > > > otherwise it
> > > > > > seems unnecessary, unless there are CPUs that advertise NEON support
> > > > > > but don't actually support it.
> > > > > > 
> > > > > 
> > > > > I think the issue will result in a compiler error perhaps when neon is
> > > > > disabled via
> > > > > compiler command line which would be the case when neon is not in 
> > > > > TUNE_FEATURES
> > > > > the compiler might warn or error out when it finds neon instructions
> > > > > being compiled via inline
> > > > > assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> > > > > some such and see if
> > > > > compiler/assembler complains during build, if not then perhaps its 
> > > > > fine.
> > > > 
> > > > If the last -mfpu is something else than neon, then including
> > > > arm_neon.h will succeed but compiling neon code will fail.
> > > > 
> > > > I did some experiments, and what I found was that when I remove neon
> > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
> > > > early in the compiler command line. PulseAudio adds -mfpu=neon to
> > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon
> > > > code gets built without errors.
> > > > 
> > > > The configure check in PulseAudio only checks that the compiler accepts
> > > > -mfpu=neon and #include , it doesn't try to compile any
> > > > actual neon code. This means that if the user adds -mfpu=vfp (or other
> > > > non-neon) to CFLAGS rather than CC, configure will pass but building
> > > > will fail. Is this something to guard against? A default qemuarm build
> > > > doesn't do this, so I don't know if this ever happens in OE.
> > > > 
> > > > I don't know yet how Meson behaves, I'll continue testing...
> > > 
> > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
> > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
> > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
> > > enabled in any case.
> > > 
> > > So, Meson seems pretty safe, although I guess it would be nice not to
> > > override the user's -mfpu setting. I think this isn't a big problem is
> > > practice, since runtime detection works.
> > > 
> > > I haven't tested with a compiler that truly can't build Neon code,
> > > because I don't know how to do that.
> 
> Presumably set a -mcpu=XXX to something which can never support NEON?

No success so far...

I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio
recipe, but Neon got still enabled. GCC warned that -march=armv7ve
conflicted with the chosen -mcpu (which makes sense, since "ve" in
"armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't
have virtualization support, and all cores that have virtualization
support have mandatory Neon support).

Then I tried adding -march=armv7a to the pulseaudio CFLAGS, but then
the build failed, because Meson failed some C++ linker check ("Unable
to determine dynamic linker").

Then I tried to remove armv7ve and add cortexa9 to TUNE_FEATURES, but
GCC didn't like that at all, nothing built any more.

I'm still in the process of trying different combinations. Maybe it
would be better to try to use someting older than Cortex-A9, since A9
has optional Neon support. If you're familiar with tweaking the target
CPU with qemuarm, suggestions are welcome. (If I sound like I know
something about Arm CPUs, that's only because I've looked up things
from Wikipedia today.)

> > Right. Cpu implementations without neon do exist
> >  But they are perhaps rare enough and may not use the package too so 
> > chances are slim th

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Richard Purdie 
On Wed, 2020-07-29 at 09:41 -0400, Mingde (Matthew) Zeng wrote:
> Richard Purdie  writes:
> 
> > On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
> > > Fixes [YOCTO #13802]
> > 
> > Thanks, we can reference the bug but I don't think we can yet claim
> > it
> > fixes it.
> 
> Sure, would something like the following work?
> 
> Reference [YOCTO #13802]

Simply "[YOCTO #13802]" is fine (I'll tweak the commit message as I
merge).

> > The missing log issue happened again:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
> > so I think there are multiple issues at play here.
> 
> Can you attach this build's log.do_testimage so I can have a further
> look?

Sorry, that build directory has been reused in this case :( Next time
that happens I'll try and spot/grab it.

> > Is there any way to have the logging logged to disk straight away
> > rather than stuck internally in oeqa's logging buffers? That way we
> > could see which tests had run before a hang?
> > 
> > Also, could we make the scp failure non-fatal, maybe a warning so
> > that
> > when it fails we can look at the rest of the logs?
> 
> I'll further investigate this idea.

Thanks!

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141093): 
https://lists.openembedded.org/g/openembedded-core/message/141093
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 

Richard Purdie  writes:

> On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
>> Fixes [YOCTO #13802]
>
> Thanks, we can reference the bug but I don't think we can yet claim it
> fixes it.

Sure, would something like the following work?

Reference [YOCTO #13802]

>
> The missing log issue happened again:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
> so I think there are multiple issues at play here.

Can you attach this build's log.do_testimage so I can have a further look?

>
> Is there any way to have the logging logged to disk straight away
> rather than stuck internally in oeqa's logging buffers? That way we
> could see which tests had run before a hang?
>
> Also, could we make the scp failure non-fatal, maybe a warning so that
> when it fails we can look at the rest of the logs?

I'll further investigate this idea.

Matthew

>
> Cheers,
>
> Richard
>
>> Remove the OOM tests, since they might cause oeqa ssh
>> connection lost.
>>
>> Signed-off-by: Mingde (Matthew) Zeng 
>> ---
>>  ...001-Remove-OOM-tests-from-runtest-mm.patch | 33
>> +++
>>  meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
>>  2 files changed, 34 insertions(+)
>>  create mode 100644 meta/recipes-extended/ltp/ltp/0001-Remove-OOM-
>> tests-from-runtest-mm.patch
>>
>> diff --git a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-
>> from-runtest-mm.patch b/meta/recipes-extended/ltp/ltp/0001-Remove-
>> OOM-tests-from-runtest-mm.patch
>> new file mode 100644
>> index 00..2d8262be78
>> --- /dev/null
>> +++ b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-
>> runtest-mm.patch
>> @@ -0,0 +1,33 @@
>> +From 373b21dcf7a2879c27cc3dbeac5d83f5d45d22ae Mon Sep 17 00:00:00
>> 2001
>> +From: "Mingde (Matthew) Zeng" 
>> +Date: Wed, 29 Jul 2020 08:47:09 -0400
>> +Subject: [PATCH] Remove OOM tests from runtest/mm
>> +
>> +Disable OOM tests, as they might cause oeqa ssh connection lost
>> +
>> +Upstream-Status: Inappropriate [oe-core specific]
>> +Signed-off-by: Mingde (Matthew) Zeng 
>> +---
>> + runtest/mm | 6 --
>> + 1 file changed, 6 deletions(-)
>> +
>> +diff --git a/runtest/mm b/runtest/mm
>> +index 4701a14bd..2f9888ec6 100644
>> +--- a/runtest/mm
>>  b/runtest/mm
>> +@@ -75,12 +75,6 @@ ksm06_2 ksm06 -n 1
>> +
>> + cpuset01 cpuset01
>> +
>> +-oom01 oom01
>> +-oom02 oom02
>> +-oom03 oom03
>> +-oom04 oom04
>> +-oom05 oom05
>> +-
>> + swapping01 swapping01 -i 5
>> +
>> + thp01 thp01 -I 120
>> +--
>> +2.27.0
>> +
>> diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb
>> b/meta/recipes-extended/ltp/ltp_20200515.bb
>> index ece3acf0f9..0c7044d044 100644
>> --- a/meta/recipes-extended/ltp/ltp_20200515.bb
>> +++ b/meta/recipes-extended/ltp/ltp_20200515.bb
>> @@ -37,6 +37,7 @@ SRC_URI = "git://github.com/linux-test-
>> project/ltp.git \
>> file://0001-ptrace01-Fix-missing-format-string.patch \
>> file://0001-sigwaitinfo-Do-not-run-invalid-undefined-
>> test-cases.patch \
>> file://0001-syscalls-copy_file_range02-Expect-EFBIG-in-
>> subcase-m.patch \
>> +   file://0001-Remove-OOM-tests-from-runtest-mm.patch \
>> "
>>
>>  S = "${WORKDIR}/git"
>> --
>> 2.27.0
>> 


--
Mingde (Matthew) Zeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141092): 
https://lists.openembedded.org/g/openembedded-core/message/141092
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH] boost: backport fix to make async_pipes work with asio

2020-07-29 Thread Viktor Rosendahl 
From: Viktor Rosendahl 

async_pipe is missing the executor_type type, which is expected by
asio in /usr/include/boost/asio/impl/read.hpp. Without this, it's
not possible to even compile code that uses constructs such as:

boost::asio::io_service foo;
boost::process::async_pipe foopipe{ boost::process::async_pipe(foo) };

This is only relevant for Dunfell because master has already moved to
boost-1.73.0 in which this bug has been fixed. The bug is also not
present in Zeus, which uses boost-1.71.0.

Signed-off-by: Viktor Rosendahl 
---
 .../0001-added-typedef-executor_type.patch| 53 +++
 meta/recipes-support/boost/boost_1.72.0.bb|  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-support/boost/boost/0001-added-typedef-executor_type.patch

diff --git 
a/meta/recipes-support/boost/boost/0001-added-typedef-executor_type.patch 
b/meta/recipes-support/boost/boost/0001-added-typedef-executor_type.patch
new file mode 100644
index 00..83d3749e15
--- /dev/null
+++ b/meta/recipes-support/boost/boost/0001-added-typedef-executor_type.patch
@@ -0,0 +1,53 @@
+From 6a4d2ff72114ef47c7afaf92e1042aca3dfa41b0 Mon Sep 17 00:00:00 2001
+From: Klemens David Morgenstern 
+Date: Fri, 22 Nov 2019 14:03:22 +0800
+Subject: [PATCH] added typedef executor_type;
+
+Upstream-Status: Backport 
[https://github.com/boostorg/process/commit/6a4d2ff72114ef47c7afaf92e1042aca3dfa41b0]
+
+---
+ include/boost/process/async_pipe.hpp| 2 ++
+ include/boost/process/detail/posix/async_pipe.hpp   | 1 +
+ include/boost/process/detail/windows/async_pipe.hpp | 1 +
+ 3 files changed, 4 insertions(+)
+
+diff --git a/include/boost/process/async_pipe.hpp 
b/include/boost/process/async_pipe.hpp
+index 101fe1d..a562432 100644
+--- a/boost/process/async_pipe.hpp
 b/boost/process/async_pipe.hpp
+@@ -47,6 +47,8 @@ public:
+  */
+ typedef platform_specific handle_type;
+ 
++typedef typename handle_type::executor_type executor_type;
++
+ /** Construct a new async_pipe, does automatically open the pipe.
+  * Initializes source and sink with the same io_context.
+  * @note Windows creates a named pipe here, where the name is 
automatically generated.
+diff --git a/include/boost/process/detail/posix/async_pipe.hpp 
b/include/boost/process/detail/posix/async_pipe.hpp
+index 725a078..a82c057 100644
+--- a/boost/process/detail/posix/async_pipe.hpp
 b/boost/process/detail/posix/async_pipe.hpp
+@@ -23,6 +23,7 @@ class async_pipe
+ public:
+ typedef int native_handle_type;
+ typedef ::boost::asio::posix::stream_descriptor handle_type;
++typedef typename handle_type::executor_type executor_type;
+ 
+ inline async_pipe(boost::asio::io_context & ios) : async_pipe(ios, ios) {}
+ 
+diff --git a/include/boost/process/detail/windows/async_pipe.hpp 
b/include/boost/process/detail/windows/async_pipe.hpp
+index 06d5f2d..0b447f9 100644
+--- a/boost/process/detail/windows/async_pipe.hpp
 b/boost/process/detail/windows/async_pipe.hpp
+@@ -48,6 +48,7 @@ class async_pipe
+ public:
+ typedef ::boost::winapi::HANDLE_ native_handle_type;
+ typedef ::boost::asio::windows::stream_handle   handle_type;
++typedef typename handle_type::executor_type executor_type;
+ 
+ async_pipe(boost::asio::io_context & ios) : async_pipe(ios, ios, 
make_pipe_name(), true) {}
+ async_pipe(boost::asio::io_context & ios_source, boost::asio::io_context 
& ios_sink)
+-- 
+2.17.1
+
diff --git a/meta/recipes-support/boost/boost_1.72.0.bb 
b/meta/recipes-support/boost/boost_1.72.0.bb
index 0b7badbc76..51c84bc935 100644
--- a/meta/recipes-support/boost/boost_1.72.0.bb
+++ b/meta/recipes-support/boost/boost_1.72.0.bb
@@ -8,4 +8,5 @@ SRC_URI += "file://arm-intrinsics.patch \

file://0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch \
file://0001-dont-setup-compiler-flags-m32-m64.patch \
file://0001-revert-cease-dependence-on-range.patch \
+   file://0001-added-typedef-executor_type.patch \
"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141091): 
https://lists.openembedded.org/g/openembedded-core/message/141091
Mute This Topic: https://lists.openembedded.org/mt/75864498/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Richard Purdie 
On Wed, 2020-07-29 at 09:09 -0400, Matthew wrote:
> Fixes [YOCTO #13802]

Thanks, we can reference the bug but I don't think we can yet claim it
fixes it.

The missing log issue happened again:
https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/908
so I think there are multiple issues at play here.

Is there any way to have the logging logged to disk straight away
rather than stuck internally in oeqa's logging buffers? That way we
could see which tests had run before a hang?

Also, could we make the scp failure non-fatal, maybe a warning so that
when it fails we can look at the rest of the logs?

Cheers,

Richard

> Remove the OOM tests, since they might cause oeqa ssh
> connection lost.
> 
> Signed-off-by: Mingde (Matthew) Zeng 
> ---
>  ...001-Remove-OOM-tests-from-runtest-mm.patch | 33
> +++
>  meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 meta/recipes-extended/ltp/ltp/0001-Remove-OOM-
> tests-from-runtest-mm.patch
> 
> diff --git a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-
> from-runtest-mm.patch b/meta/recipes-extended/ltp/ltp/0001-Remove-
> OOM-tests-from-runtest-mm.patch
> new file mode 100644
> index 00..2d8262be78
> --- /dev/null
> +++ b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-
> runtest-mm.patch
> @@ -0,0 +1,33 @@
> +From 373b21dcf7a2879c27cc3dbeac5d83f5d45d22ae Mon Sep 17 00:00:00
> 2001
> +From: "Mingde (Matthew) Zeng" 
> +Date: Wed, 29 Jul 2020 08:47:09 -0400
> +Subject: [PATCH] Remove OOM tests from runtest/mm
> +
> +Disable OOM tests, as they might cause oeqa ssh connection lost
> +
> +Upstream-Status: Inappropriate [oe-core specific]
> +Signed-off-by: Mingde (Matthew) Zeng 
> +---
> + runtest/mm | 6 --
> + 1 file changed, 6 deletions(-)
> +
> +diff --git a/runtest/mm b/runtest/mm
> +index 4701a14bd..2f9888ec6 100644
> +--- a/runtest/mm
>  b/runtest/mm
> +@@ -75,12 +75,6 @@ ksm06_2 ksm06 -n 1
> +
> + cpuset01 cpuset01
> +
> +-oom01 oom01
> +-oom02 oom02
> +-oom03 oom03
> +-oom04 oom04
> +-oom05 oom05
> +-
> + swapping01 swapping01 -i 5
> +
> + thp01 thp01 -I 120
> +--
> +2.27.0
> +
> diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb
> b/meta/recipes-extended/ltp/ltp_20200515.bb
> index ece3acf0f9..0c7044d044 100644
> --- a/meta/recipes-extended/ltp/ltp_20200515.bb
> +++ b/meta/recipes-extended/ltp/ltp_20200515.bb
> @@ -37,6 +37,7 @@ SRC_URI = "git://github.com/linux-test-
> project/ltp.git \
> file://0001-ptrace01-Fix-missing-format-string.patch \
> file://0001-sigwaitinfo-Do-not-run-invalid-undefined-
> test-cases.patch \
> file://0001-syscalls-copy_file_range02-Expect-EFBIG-in-
> subcase-m.patch \
> +   file://0001-Remove-OOM-tests-from-runtest-mm.patch \
> "
> 
>  S = "${WORKDIR}/git"
> --
> 2.27.0
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141090): 
https://lists.openembedded.org/g/openembedded-core/message/141090
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCHv2] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 
Fixes [YOCTO #13802]

Remove the OOM tests, since they might cause oeqa ssh
connection lost.

Signed-off-by: Mingde (Matthew) Zeng 
---
 ...001-Remove-OOM-tests-from-runtest-mm.patch | 33 +++
 meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch 
b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
new file mode 100644
index 00..2d8262be78
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
@@ -0,0 +1,33 @@
+From 373b21dcf7a2879c27cc3dbeac5d83f5d45d22ae Mon Sep 17 00:00:00 2001
+From: "Mingde (Matthew) Zeng" 
+Date: Wed, 29 Jul 2020 08:47:09 -0400
+Subject: [PATCH] Remove OOM tests from runtest/mm
+
+Disable OOM tests, as they might cause oeqa ssh connection lost
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Mingde (Matthew) Zeng 
+---
+ runtest/mm | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/runtest/mm b/runtest/mm
+index 4701a14bd..2f9888ec6 100644
+--- a/runtest/mm
 b/runtest/mm
+@@ -75,12 +75,6 @@ ksm06_2 ksm06 -n 1
+
+ cpuset01 cpuset01
+
+-oom01 oom01
+-oom02 oom02
+-oom03 oom03
+-oom04 oom04
+-oom05 oom05
+-
+ swapping01 swapping01 -i 5
+
+ thp01 thp01 -I 120
+--
+2.27.0
+
diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index ece3acf0f9..0c7044d044 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -37,6 +37,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0001-ptrace01-Fix-missing-format-string.patch \

file://0001-sigwaitinfo-Do-not-run-invalid-undefined-test-cases.patch \

file://0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch \
+   file://0001-Remove-OOM-tests-from-runtest-mm.patch \
"

 S = "${WORKDIR}/git"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141089): 
https://lists.openembedded.org/g/openembedded-core/message/141089
Mute This Topic: https://lists.openembedded.org/mt/75864108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for libpcre: Add fix for CVE-2020-14155

2020-07-29 Thread Patchwork 
== Series Details ==

Series: libpcre: Add fix for CVE-2020-14155
Revision: 1
URL   : https://patchwork.openembedded.org/series/25384/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  zeus (currently at f5b90eeed7)

* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141088): 
https://lists.openembedded.org/g/openembedded-core/message/141088
Mute This Topic: https://lists.openembedded.org/mt/75863992/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 

Error, please ignore.

Matthew  writes:

> Fixes [YOCTO #13802]
>
> Temporarily remove the OOM tests, since they might cause oeqa ssh
> connection lost.
>
> Let's wait for a week or two to see if the error stops occuring.
>
> Signed-off-by: Mingde (Matthew) Zeng 
> ---
>  ...001-Remove-OOM-tests-from-runtest-mm.patch | 33 +++
>  1 file changed, 33 insertions(+)
>  create mode 100644 
> meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch 
> b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
> new file mode 100644
> index 00..3a58986288
> --- /dev/null
> +++ 
> b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
> @@ -0,0 +1,33 @@
> +From e49c4bc6e8b5c1d6f3e9763751e1fb656788709b Mon Sep 17 00:00:00 2001
> +From: "Mingde (Matthew) Zeng" 
> +Date: Wed, 29 Jul 2020 08:47:09 -0400
> +Subject: [PATCH] Remove OOM tests from runtest/mm
> +
> +Disable OOM tests, as they might cause oeqa ssh connection lost
> +
> +Upstream-Status: Inappropriate [oe-core specific]
> +Signed-off-by: Mingde (Matthew) Zeng 
> +---
> + runtest/mm | 6 --
> + 1 file changed, 6 deletions(-)
> +
> +diff --git a/runtest/mm b/runtest/mm
> +index 4701a14bd..2f9888ec6 100644
> +--- a/runtest/mm
>  b/runtest/mm
> +@@ -75,12 +75,6 @@ ksm06_2 ksm06 -n 1
> +
> + cpuset01 cpuset01
> +
> +-oom01 oom01
> +-oom02 oom02
> +-oom03 oom03
> +-oom04 oom04
> +-oom05 oom05
> +-
> + swapping01 swapping01 -i 5
> +
> + thp01 thp01 -I 120
> +--
> +2.27.0
> +


--
Mingde (Matthew) Zeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141087): 
https://lists.openembedded.org/g/openembedded-core/message/141087
Mute This Topic: https://lists.openembedded.org/mt/75863878/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] recipes-devtools/gcc: gcc-Fix-argument-list-too-long-error.patch is buggy

2020-07-29 Thread Richard Purdie 
On Sun, 2020-07-26 at 08:20 -0700, qiuguang@alibaba-inc.com wrote:
> A few days ago, I tried to compile a gcc plugin with the toolchain from poky 
> sdk.
> It failed with errors about missing header files such as backend.h etc.
> 
> After investigation, I found that the problem was brought by a gcc patch:
> 0012-gcc-Fix-argument-list-too-long-error.patch (which is considered derived 
> from the original patch)
> 
> - headers=`echo $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def) | tr ' ' 
> '\012' | sort -u`; \
> + headers="$(sort $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def))"; \
> 
> It changes the commands of install-plugin, making the sorting taken effect 
> before the shell globs.
> Thus results in the header files under gcc $(srcdir) being not installed.
> 
> By checking log.do_install, we can find that the `headers=' statement to run 
> is incorrect and will not work as expected:
> headers="$(cd *.def) *.h 
> ../../../../../../../work-shared/gcc-10.1.0-r0/gcc-10.1.0/gcc/../include/ansidecl.h
>  ...
> 
> As the patch says,
> "The PLUGIN_HEADERS is too long before sort, so the "echo" can't handle it, 
> ..."
> my suggestion is that we can simply take care of PLUGIN_HEADERS:
> 
> - headers=`echo $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def) | tr ' ' 
> '\012' | sort -u`; \
> + headers=`echo $(sort $(PLUGIN_HEADERS)) $$(cd $(srcdir); echo *.h *.def) | 
> tr ' ' '\012' | sort -u`; \

Thanks for the report, I've submitted and later merged a patch to fix it.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141085): 
https://lists.openembedded.org/g/openembedded-core/message/141085
Mute This Topic: https://lists.openembedded.org/mt/75804103/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [poky][zeus][PATCH] libpcre: Add fix for CVE-2020-14155

2020-07-29 Thread saloni 
From: Rahul Taya 

Added below patch in libpcre
CVE-2020-14155.patch

This patch fixes below error:
PCRE could allow a remote attacker to execute arbitrary
code on the system, caused by an integer overflow in
libpcre via a large number after (?C substring.
By sending a request with a large number, an attacker
can execute arbitrary code on the system or
cause the application to crash.

Upstream-Status: Pending

Tested-by: Rahul Taya 
Signed-off-by: Saloni Jain 
---
 .../libpcre/libpcre/CVE-2020-14155.patch   | 40 ++
 meta/recipes-support/libpcre/libpcre_8.44.bb   |  3 +-
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch

diff --git a/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch 
b/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch
new file mode 100644
index 000..d6cb9bf
--- /dev/null
+++ b/meta/recipes-support/libpcre/libpcre/CVE-2020-14155.patch
@@ -0,0 +1,40 @@
+--- pcre-8.43/pcre_compile.c2020-07-05 22:26:25.310501521 +0530
 pcre-8.43/pcre_compile1.c   2020-07-05 22:30:22.254489562 +0530
+
+CVE: CVE-2020-14155
+Upstream-Status: Backport 
[https://vcs.pcre.org/pcre/code/trunk/pcre_compile.c?view=patch&r1=1761&r2=1760&pathrev=1761]
+
+@@ -6,7 +6,7 @@
+ and semantics are as close as possible to those of the Perl 5 language.
+
+Written by Philip Hazel
+-   Copyright (c) 1997-2018 University of Cambridge
++   Copyright (c) 1997-2020 University of Cambridge
+
+ -
+ Redistribution and use in source and binary forms, with or without
+@@ -7130,17 +7130,19 @@
+   int n = 0;
+   ptr++;
+   while(IS_DIGIT(*ptr))
++   {
+ n = n * 10 + *ptr++ - CHAR_0;
++if (n > 255)
++   {
++   *errorcodeptr = ERR38;
++   goto FAILED;
++   }
++}
+   if (*ptr != CHAR_RIGHT_PARENTHESIS)
+ {
+ *errorcodeptr = ERR39;
+ goto FAILED;
+ }
+-  if (n > 255)
+-{
+-*errorcodeptr = ERR38;
+-goto FAILED;
+-}
+   *code++ = n;
+   PUT(code, 0, (int)(ptr - cd->start_pattern + 1)); /* Pattern offset 
*/
+   PUT(code, LINK_SIZE, 0);  /* Default length 
*/
diff --git a/meta/recipes-support/libpcre/libpcre_8.44.bb 
b/meta/recipes-support/libpcre/libpcre_8.44.bb
index e5471e8..81b38bb 100644
--- a/meta/recipes-support/libpcre/libpcre_8.44.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.44.bb
@@ -11,7 +11,8 @@ SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre-${PV}.tar.bz2 \
file://fix-pcre-name-collision.patch \
file://run-ptest \
file://Makefile \
-   "
+   file://CVE-2020-14155.patch \
+"

 SRC_URI[md5sum] = "cf7326204cc46c755b5b2608033d9d24"
 SRC_URI[sha256sum] = 
"19108658b23b3ec5058edc9f66ac545ea19f9537234be1ec62b714c84399366d"
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141086): 
https://lists.openembedded.org/g/openembedded-core/message/141086
Mute This Topic: https://lists.openembedded.org/mt/75863890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] ltp: remove OOM tests from runtest/mm

2020-07-29 Thread Matthew 
Fixes [YOCTO #13802]

Temporarily remove the OOM tests, since they might cause oeqa ssh
connection lost.

Let's wait for a week or two to see if the error stops occuring.

Signed-off-by: Mingde (Matthew) Zeng 
---
 ...001-Remove-OOM-tests-from-runtest-mm.patch | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch 
b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
new file mode 100644
index 00..3a58986288
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp/0001-Remove-OOM-tests-from-runtest-mm.patch
@@ -0,0 +1,33 @@
+From e49c4bc6e8b5c1d6f3e9763751e1fb656788709b Mon Sep 17 00:00:00 2001
+From: "Mingde (Matthew) Zeng" 
+Date: Wed, 29 Jul 2020 08:47:09 -0400
+Subject: [PATCH] Remove OOM tests from runtest/mm
+
+Disable OOM tests, as they might cause oeqa ssh connection lost
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Mingde (Matthew) Zeng 
+---
+ runtest/mm | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/runtest/mm b/runtest/mm
+index 4701a14bd..2f9888ec6 100644
+--- a/runtest/mm
 b/runtest/mm
+@@ -75,12 +75,6 @@ ksm06_2 ksm06 -n 1
+ 
+ cpuset01 cpuset01
+ 
+-oom01 oom01
+-oom02 oom02
+-oom03 oom03
+-oom04 oom04
+-oom05 oom05
+-
+ swapping01 swapping01 -i 5
+ 
+ thp01 thp01 -I 120
+-- 
+2.27.0
+
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141084): 
https://lists.openembedded.org/g/openembedded-core/message/141084
Mute This Topic: https://lists.openembedded.org/mt/75863878/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] archiver.bbclass and GIT repositories

2020-07-29 Thread Christian Eggers 
On Wednesday, 29 July 2020, 11:42:25 CEST, Paul Barker wrote:
> On Tue, 28 Jul 2020 at 13:56, Christian Eggers  wrote:
> > ...
> > So I have three questions:
> > 1. Is it possible to archive the git project in a way, that the GIT
> > history
> > can be examined later?
> > 2. If this is not possible, I would have to put my changes in an
> > "external" patch file alongside the bitbake recipe, right?
> > 3. Is there any value archiving the .git directory at all?
>
> What configuration are you using to enable the archiver? There may be
> ways to fix this by changing the configuration.
I use the archive as described here:
https://www.yoctoproject.org/docs/3.1.1/dev-manual/dev-manual.html#providing-the-source-code

>From my local.conf:
...
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
...


>
> Also, which Yocto Project version/branch are you using?
I use Yocto 3.1.1.

regards
Christian




 
[http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] 


Get all the latest information from www.arri.com, 
Facebook, 
Twitter, Instagram 
and YouTube.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141083): 
https://lists.openembedded.org/g/openembedded-core/message/141083
Mute This Topic: https://lists.openembedded.org/mt/75843071/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] qemumips: Use 34Kf CPU emulation

2020-07-29 Thread Richard Purdie 
On Wed, 2020-07-29 at 10:56 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Tue, 2020-07-28 at 19:28 -0700, Khem Raj wrote:
> > Few years ago we switched to using mips32r2 tunings for qemumips
> > however
> > the default CPU emulation still remained 24Kf which is not optimal
> > for
> > mips32r2 ISA for qemu [1], therefore switch to recommended 32Kf for
> > CPU
> > emulation when running qemu in system mode
> > 
> > Boot time to console is ~1s faster with this setting, hopefully
> > this
> > should speed up qemumips in general
> > 
> > [1] 
> > https://www.qemu.org/docs/master/system/target-mips.html#preferred-cpu-models-for-mips-hosts
> > 
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/machine/qemumips.conf | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/conf/machine/qemumips.conf
> > b/meta/conf/machine/qemumips.conf
> > index 31ad754483..4617c3c7b6 100644
> > --- a/meta/conf/machine/qemumips.conf
> > +++ b/meta/conf/machine/qemumips.conf
> > @@ -12,3 +12,5 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
> >  SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
> >  
> >  QB_SYSTEM_NAME = "qemu-system-mips"
> > +
> > +QB_CPU = "-cpu 34Kf"
> 
> Thanks!
> 
> I did run some tests locally, timing core-image-sato -c testimage
> before and after this change. It took 999s before, 1018s after but
> the difference looks like noise rather than any speedup or slowdown.

Another try at "after" got 986s so who knows :)

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141082): 
https://lists.openembedded.org/g/openembedded-core/message/141082
Mute This Topic: https://lists.openembedded.org/mt/75857901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] qemumips: Use 34Kf CPU emulation

2020-07-29 Thread Richard Purdie 
On Tue, 2020-07-28 at 19:28 -0700, Khem Raj wrote:
> Few years ago we switched to using mips32r2 tunings for qemumips however
> the default CPU emulation still remained 24Kf which is not optimal for
> mips32r2 ISA for qemu [1], therefore switch to recommended 32Kf for CPU
> emulation when running qemu in system mode
> 
> Boot time to console is ~1s faster with this setting, hopefully this
> should speed up qemumips in general
> 
> [1] 
> https://www.qemu.org/docs/master/system/target-mips.html#preferred-cpu-models-for-mips-hosts
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/machine/qemumips.conf | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/conf/machine/qemumips.conf b/meta/conf/machine/qemumips.conf
> index 31ad754483..4617c3c7b6 100644
> --- a/meta/conf/machine/qemumips.conf
> +++ b/meta/conf/machine/qemumips.conf
> @@ -12,3 +12,5 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
>  SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
>  
>  QB_SYSTEM_NAME = "qemu-system-mips"
> +
> +QB_CPU = "-cpu 34Kf"

Thanks!

I did run some tests locally, timing core-image-sato -c testimage
before and after this change. It took 999s before, 1018s after but the
difference looks like noise rather than any speedup or slowdown.

Its certainly worth a try to see if it helps the intermittent failures
though.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141081): 
https://lists.openembedded.org/g/openembedded-core/message/141081
Mute This Topic: https://lists.openembedded.org/mt/75857901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] archiver.bbclass and GIT repositories

2020-07-29 Thread Paul Barker 
On Tue, 28 Jul 2020 at 13:56, Christian Eggers  wrote:
>
> In my project, the linux kernel (together with dozens of our changes) is kept
> in a company internal GIT repository. The GPLv2 requires the following:
>
> > 2a) You must cause the modified files to carry prominent notices stating
> > that you changed the files and the date of any change.
>
> My idea is, that the GIT history (and diff) should be sufficient for 
> documenting
> our changes to the linux source code.
>
> But when I unpack the .tar.gz file which was deploy by archiver.bbclass,
> I get the following:
>
> # tar -xf my-linux-kernel.tar.gz
> # cd /git
> # git log
>
> > error: object directory 
> > /srv/gitlab-runner/downloads/[..]/yocto/git2/[xxx].git/objects does not 
> > exist; check .git/objects/info/alternates
> > fatal: bad object HEAD
>
> Note: The project has been built on another machine.
>
> From the bitbake user manual, 4.3.5, Git Fetcher:
> > "This bare clone is then cloned into the work directory during the unpack
> > stage when a specific tree is checked out. This is done using alternates and
> > by reference to minimize the amount of duplicate data on the disk and make
> > the unpack process fast."
>
> It looks like the .git directory within the tar archive doesn't contain
> the necessary information required for using the "git" command on
> the extracted "working copy". If I understood the bitbake doc correctly,
> the working copy is cloned "by reference" from a "bare" clone which
> resided outside the archived directory (in the downloads dir).
>
> So I have three questions:
> 1. Is it possible to archive the git project in a way, that the GIT history
> can be examined later?
> 2. If this is not possible, I would have to put my changes in an
> "external" patch file alongside the bitbake recipe, right?
> 3. Is there any value archiving the .git directory at all?

What configuration are you using to enable the archiver? There may be
ways to fix this by changing the configuration.

Also, which Yocto Project version/branch are you using?

Thanks,

-- 
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141080): 
https://lists.openembedded.org/g/openembedded-core/message/141080
Mute This Topic: https://lists.openembedded.org/mt/75843071/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] ltp.py: remove mm from ltp_groups

2020-07-29 Thread Richard Purdie 
On Tue, 2020-07-28 at 16:43 -0400, Matthew wrote:
> Fixes [YOCTO #13802]
> 
> Temporary disable mm test for a while, since it calls the OOM tests.
> See ltp-git/runtest/mm:
> oom01 oom01
> oom02 oom02
> oom03 oom03
> oom04 oom04
> oom05 oom05
> 
> Let's wait for a week or two to see if the error stops occuring.
> 
> Signed-off-by: Mingde (Matthew) Zeng 
> ---
>  meta/lib/oeqa/runtime/cases/ltp.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oeqa/runtime/cases/ltp.py 
> b/meta/lib/oeqa/runtime/cases/ltp.py
> index cfac29c153..9ac7bb15f6 100644
> --- a/meta/lib/oeqa/runtime/cases/ltp.py
> +++ b/meta/lib/oeqa/runtime/cases/ltp.py
> @@ -57,7 +57,7 @@ class LtpTestBase(OERuntimeTestCase):
>  
>  class LtpTest(LtpTestBase):
>  
> -ltp_groups = ["math", "syscalls", "dio", "io", "mm", "ipc", "sched", 
> "nptl", "pty", "containers", "controllers", "filecaps", "cap_bounds", 
> "fcntl-locktests", "connectors", "commands", "net.ipv6_lib", 
> "input","fs_perms_simple"]
> +ltp_groups = ["math", "syscalls", "dio", "io", "ipc", "sched", "nptl", 
> "pty", "containers", "controllers", "filecaps", "cap_bounds", 
> "fcntl-locktests", "connectors", "commands", "net.ipv6_lib", 
> "input","fs_perms_simple"]

Since there are a load of other tests in runtest/mm, shouldn't we just
patching out the oom ones?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141079): 
https://lists.openembedded.org/g/openembedded-core/message/141079
Mute This Topic: https://lists.openembedded.org/mt/75852805/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] sdk package_arch and yum

2020-07-29 Thread Richard Purdie 
On Wed, 2020-07-29 at 14:33 +1200, Douglas via lists.openembedded.org
wrote:
> I was unable to install my nativesdk packages on CentOS using yum, as
> the package architecture was set to "x86_64_nativesdk". My web-
> digging revealed no work-around I could use for yum.

This is not what the nativesdk packages are intended for. They're there
to allow standalone SDKs to be built or standalone toolsets like
buildtools tarball.

They contain special handling to allow them to be relocated. They're
simply not designed to work with the host's package manager.

> dnf (available in CentOS 8, I believe) supports a --forcearch option,
> and also provides an ignorearch configuration option, though this
> seems an unsatisfactory work-around.
> 
> For the experiment, I forced the sdk package_arch to simply "x86_64",
> and yum cheerfully installed the resulting rpm packages:
> 
> > PACKAGE_ARCH_class-nativesdk = "${SDK_ARCH}"
> > SDK_PACKAGE_ARCHS = "all any noarch ${SDK_ARCH}"
> 
> I have no familiarity with yum. Am I missing something?
> 
> If not, I will propose a patch to create packages with PACKAGE_ARCH =
> x86_64 in the nativesdk case, but I wanted a sanity check before I
> did this work.
> 
> For the record, apt did install the corresponding .deb files,
> cheerfully ignoring the architecture.

Whilst you may be able to force them to install, I'd be very surprised
if the result was usable.

The patch is inappropriate as nativesdk is not designed to work this
way and if you do drop the nativesdk prefix, they'll have a namespace
collision with target packages.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141078): 
https://lists.openembedded.org/g/openembedded-core/message/141078
Mute This Topic: https://lists.openembedded.org/mt/75857943/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] libwpe: update to 1.7.1

2020-07-29 Thread Oleksandr Kravchuk 
Signed-off-by: Oleksandr Kravchuk 
---
 meta/recipes-sato/webkit/{libwpe_1.6.0.bb => libwpe_1.7.1.bb} | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-sato/webkit/{libwpe_1.6.0.bb => libwpe_1.7.1.bb} (82%)

diff --git a/meta/recipes-sato/webkit/libwpe_1.6.0.bb 
b/meta/recipes-sato/webkit/libwpe_1.7.1.bb
similarity index 82%
rename from meta/recipes-sato/webkit/libwpe_1.6.0.bb
rename to meta/recipes-sato/webkit/libwpe_1.7.1.bb
index 09c74089c9..e25d9404a0 100644
--- a/meta/recipes-sato/webkit/libwpe_1.6.0.bb
+++ b/meta/recipes-sato/webkit/libwpe_1.7.1.bb
@@ -13,6 +13,5 @@ inherit cmake features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
 
-SRC_URI[md5sum] = "6e8a2c279dcc3617db5ec7ac4c03d628"
 SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz";
-SRC_URI[sha256sum] = 
"3587c6b8a807f4bb76b268ba74ca82c6b395b90235db41ad8252224456193c90"
+SRC_URI[sha256sum] = 
"a784b7fa0c658b28071100f6f6749b0d85bbcddd82de028e07672ce13982d340"
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141077): 
https://lists.openembedded.org/g/openembedded-core/message/141077
Mute This Topic: https://lists.openembedded.org/mt/75861193/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] nativesdk-rpm: adjust RPM_CONFIGDIR paths dynamically

2020-07-29 Thread hongxu 
While installing/extracting SDK to a non-default dir(not /opt),
run rpm failed:
$ python3 -c "import rpm"
|error: Unable to open /opt/windriver/wrlinux-graphics/20.31/sysroots/
x86_64-wrlinuxsdk-linux/usr/lib/rpm/rpmrc for reading: No such file or
directory.

This patch adds a flexible way to configure RPM_CONFIGDIR in SDK.

Signed-off-by: Hongxu Jia 
---
 meta/recipes-devtools/rpm/files/environment.d-rpm.sh | 1 +
 meta/recipes-devtools/rpm/rpm_4.15.1.bb  | 5 +
 2 files changed, 6 insertions(+)
 create mode 100644 meta/recipes-devtools/rpm/files/environment.d-rpm.sh

diff --git a/meta/recipes-devtools/rpm/files/environment.d-rpm.sh 
b/meta/recipes-devtools/rpm/files/environment.d-rpm.sh
new file mode 100644
index 00..9b669a18d1
--- /dev/null
+++ b/meta/recipes-devtools/rpm/files/environment.d-rpm.sh
@@ -0,0 +1 @@
+export RPM_CONFIGDIR="$OECORE_NATIVE_SYSROOT/usr/lib/rpm"
diff --git a/meta/recipes-devtools/rpm/rpm_4.15.1.bb 
b/meta/recipes-devtools/rpm/rpm_4.15.1.bb
index b5a0ac9382..c9258632d2 100644
--- a/meta/recipes-devtools/rpm/rpm_4.15.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.15.1.bb
@@ -25,6 +25,7 @@ LICENSE = "GPL-2.0"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c0bf017c0fd1920e6158a333acabfd4a"
 
 SRC_URI = "git://github.com/rpm-software-management/rpm;branch=rpm-4.15.x \
+   file://environment.d-rpm.sh \

file://0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch \
file://0001-Do-not-read-config-files-from-HOME.patch \

file://0001-When-cross-installing-execute-package-scriptlets-wit.patch \
@@ -112,6 +113,9 @@ do_install_append_class-nativesdk() {
 done
 
 rm -rf ${D}/var
+
+mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
+install -m 644 ${WORKDIR}/environment.d-rpm.sh 
${D}${SDKPATHNATIVE}/environment-setup.d/rpm.sh
 }
 
 # Rpm's make install creates var/tmp which clashes with base-files packaging
@@ -129,6 +133,7 @@ do_install_append () {
 
 FILES_${PN} += "${libdir}/rpm-plugins/*.so \
"
+FILES_${PN}_append_class-nativesdk = " 
${SDKPATHNATIVE}/environment-setup.d/rpm.sh"
 
 FILES_${PN}-dev += "${libdir}/rpm-plugins/*.la \
 "
-- 
2.21.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141076): 
https://lists.openembedded.org/g/openembedded-core/message/141076
Mute This Topic: https://lists.openembedded.org/mt/75861006/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] pbzip2: extend for nativesdk

2020-07-29 Thread Yi Zhao 
Make pzip2 available in nativesdk to speedup file compression.

Signed-off-by: Yi Zhao 
---
 meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb 
b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
index e321cd2b27..d24035b677 100644
--- a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
+++ b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
@@ -28,4 +28,4 @@ do_install() {
 install -m 0755 pbzip2 ${D}${bindir}/
 }
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141075): 
https://lists.openembedded.org/g/openembedded-core/message/141075
Mute This Topic: https://lists.openembedded.org/mt/75860506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-