[OE-core] ✗ patchtest: failure for Log colorizer

[Patchwork]

== Series Details ==

Series: Log colorizer
Revision: 1
URL   : https://patchwork.openembedded.org/series/25352/
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 Errors in your Python code were encountered [test_pylint] 
  Suggested fixCorrect the lines introduced by your patch
  Output   Please, fix the listed issues:
   meta/lib/oe/log_colorizer.py does not exist



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 (#141023): 
https://lists.openembedded.org/g/openembedded-core/message/141023
Mute This Topic: https://lists.openembedded.org/mt/75836716/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH 3/3] log-colorizer.bbclass: add new class

[Chris Laplante via lists.openembedded.org]

This bbclass turns on compiler color diagnostics to make it easier to
visually interpret compiler errors and warnings. It can be used
per-recipe or globally (via INHERIT in local.conf).

You can set the LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT variable to turn
off color output - this is intended for usage in a CI environment.

log.do_compile and log.do_configure task logs will contain the colorized
output. Non-colorized versions (log.do_.nocolor) and explicitly
colorized versions (log.do_.color) are created as well, regardless
of LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT.

Signed-off-by: Chris Laplante 
---
 meta/classes/log-colorizer.bbclass | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 meta/classes/log-colorizer.bbclass

diff --git a/meta/classes/log-colorizer.bbclass 
b/meta/classes/log-colorizer.bbclass
new file mode 100644
index 00..4271957e28
--- /dev/null
+++ b/meta/classes/log-colorizer.bbclass
@@ -0,0 +1,49 @@
+# Copyright (C) 2020  Agilent Technologies, Inc.
+# Author: Chris Laplante 
+#
+# Released under the MIT license (see COPYING.MIT)
+
+LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT ?= ""
+LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT[doc] = "If set, then console output 
from the colorized tasks will be stripped of ANSI escape codes."
+
+LOG_COLORIZER_TASKS ?= " \
+configure \
+compile \
+"
+
+BB_SIGNATURE_EXCLUDE_FLAGS += "originalprogress"
+
+CFLAGS += "-fdiagnostics-color"
+
+python log_colorizer_eventhandler() {
+def is_task_enabled(task):
+return task in (d.getVar("__BBTASKS") or []) and "noexec" not in 
d.getVarFlags(task)
+
+for task in set((d.getVar("LOG_COLORIZER_TASKS") or "").split()):
+if not task.startswith("do_"):
+task = "do_{0}".format(task)
+
+if not is_task_enabled(task):
+continue
+
+ph = d.getVarFlag(task, "progress")
+if ph:
+# Stash away the original progress handler
+d.setVarFlag(task, "originalprogress", ph)
+
+d.setVarFlag(task, "progress", 
"custom:oe.log_colorizer.LogColorizerProxyProgressHandler")
+}
+
+addhandler log_colorizer_eventhandler
+log_colorizer_eventhandler[eventmask] = " \
+bb.event.RecipeTaskPreProcess \
+"
+
+python __anonymous() {
+if bb.data.inherits_class("cmake", d):
+# Inject environment variable to ensure CMake/Ninja gives colorized 
output
+func = d.getVar("cmake_do_compile", False)
+if "export CLICOLOR_FORCE=1" not in [line.strip() for line in 
func.split("\n")]:
+func = "\texport CLICOLOR_FORCE=1\n" + func
+d.setVar("cmake_do_compile", func)
+}
--
2.17.1

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

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

[OE-core] [meta-oe][PATCH 2/3] base.bbclass: make oe.log_colorizer available in global context

[Chris Laplante via lists.openembedded.org]

Signed-off-by: Chris Laplante 
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4c681cc870..5a969b207a 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -12,7 +12,7 @@ inherit logging

 OE_EXTRA_IMPORTS ?= ""

-OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license 
${OE_EXTRA_IMPORTS}"
+OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.log_colorizer 
${OE_EXTRA_IMPORTS}"
 OE_IMPORTS[type] = "list"

 PACKAGECONFIG_CONFARGS ??= ""
--
2.17.1

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

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

[OE-core] [meta-oe][PATCH 1/3] lib/oe/log_colorizer.py: add LogColorizerProxyProgressHandler

[Chris Laplante via lists.openembedded.org]

This progress handler intercepts log output, stripping any ANSII color
escape codes. Then the stripped output is fed to the underlying progress
handler which will render the progress bar as usual.

Signed-off-by: Chris Laplante 
---
 meta/lib/oe/log_colorizer.py | 86 
 1 file changed, 86 insertions(+)
 create mode 100644 meta/lib/oe/log_colorizer.py

diff --git a/meta/lib/oe/log_colorizer.py b/meta/lib/oe/log_colorizer.py
new file mode 100644
index 00..10021ef880
--- /dev/null
+++ b/meta/lib/oe/log_colorizer.py
@@ -0,0 +1,86 @@
+# Copyright (C) 2020  Agilent Technologies, Inc.
+# Author: Chris Laplante 
+#
+# Released under the MIT license (see COPYING.MIT)
+
+from bb.progress import ProgressHandler
+from bb.build import create_progress_handler
+import contextlib
+import re
+import os.path
+
+# from https://stackoverflow.com/a/14693789/221061
+ansi_escape = re.compile(r'\x1B\[[0-?]*[ -/]*[@-~]')
+
+
+class LogColorizerProxyProgressHandler(ProgressHandler):
+"""
+This is a proxy progress handler. It intercepts log output, stripping any
+ANSII color escape codes. Then the stripped output is fed to the task's
+original progress handler which will render the progress bar as usual.
+"""
+def __init__(self, d, outfile=None, otherargs=None):
+self._task = d.getVar("BB_RUNTASK")
+self._color_log = None
+self._nocolor_log = None
+self._exit_stack = None
+self._original_ph = None
+
+self._suppress_color_output = not not 
d.getVar("LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT")
+
+self._tempdir = d.getVar("T")
+logfmt = (d.getVar('BB_LOGFMT') or 'log.{task}.{pid}')
+self._logbasename = logfmt.format(task=self._task, pid=os.getpid())
+
+# Setup courtesy symlinks
+for suffix in [".nocolor", ".color"]:
+loglink = os.path.join(self._tempdir, 
'log.{0}{1}'.format(self._task, suffix))
+logfn = os.path.join(self._tempdir, self._logbasename + suffix)
+if loglink:
+bb.utils.remove(loglink)
+
+try:
+os.symlink(self._logbasename + suffix, loglink)
+except OSError:
+pass
+
+super().__init__(d, outfile)
+
+def __enter__(self):
+with contextlib.ExitStack() as es:
+self._color_log = 
es.enter_context(open(os.path.join(self._tempdir, self._logbasename) + 
".color", "w"))
+self._nocolor_log = 
es.enter_context(open(os.path.join(self._tempdir, self._logbasename) + 
".nocolor", "w"))
+
+# Reconstitute the original progress handler. We will feed 
stripped output to it so
+# that the progress bar still shows up for the task.
+original_ph = self._data.getVarFlag(self._task, "originalprogress")
+if original_ph:
+# We don't want task output showing up on the screen twice, so 
we'll just have
+# the original progress handler write to /dev/null.
+# Note the progress handler itself is responsible for closing 
the devnull handler.
+devnull = open("/dev/null", "w")
+self._original_ph = 
es.enter_context(create_progress_handler(self._task, original_ph, devnull, 
self._data))
+
+self._exit_stack = es.pop_all()
+super().__enter__()
+
+def __exit__(self, *exc_info):
+if self._exit_stack:
+self._exit_stack.__exit__(*exc_info)
+super().__exit__(*exc_info)
+
+def write(self, string):
+# Filter out ANSI escape sequences using the regular expression
+filtered = ansi_escape.sub('', string)
+
+if self._color_log:
+self._color_log.write(string)
+
+if self._nocolor_log:
+self._nocolor_log.write(filtered)
+
+if self._original_ph:
+# Pass-through to the original progress handler so we get our 
progress bar
+self._original_ph.write(filtered)
+
+super().write(filtered if self._suppress_color_output else string)
--
2.17.1

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

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

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

[Chris Laplante via lists.openembedded.org]

This patch series turns on color compiler diagnostics. It is especially
useful when doing edit-compile-test development work with devtool.

It is based on one I've been using internally for about a
year now.

Limitation: Note that the *.nocolor and *.color logs will only contain the
 output of the task itself, not any prefuncs or postfuncs. This is
 because the color filtering is implemented using progress handlers,
 which don't see prefunc or postfunc output.

Chris Laplante (3):
  lib/oe/log_colorizer.py: add LogColorizerProxyProgressHandler
  base.bbclass: make oe.log_colorizer available in global context
  log-colorizer.bbclass: add new class

 meta/classes/base.bbclass  |  2 +-
 meta/classes/log-colorizer.bbclass | 49 +
 meta/lib/oe/log_colorizer.py   | 86 ++
 3 files changed, 136 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/log-colorizer.bbclass
 create mode 100644 meta/lib/oe/log_colorizer.py

--
2.17.1

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

View/Reply Online (#141019): 
https://lists.openembedded.org/g/openembedded-core/message/141019
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] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 336
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues
being in "3.1" and then "3.2".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

View/Reply Online (#141018): 
https://lists.openembedded.org/g/openembedded-core/message/141018
Mute This Topic: https://lists.openembedded.org/mt/75834765/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 v2 2/2] buildtools-tarball: eliminate overwtiting OPENSSL_CONF

[Richard Purdie]

On Fri, 2020-07-24 at 07:26 +0200, Jens Rehsack wrote:
> Remove overwriting of OPENSSL_CONF from buildtools-tarball.bb to clarify
> whether nativesdk-openssl installs wrong content or buildtools-tarball:
> (nativesdk-openssl) tmp/sysroots/x86_64/usr/lib/ssl-1.1/openssl.cnf
> (buildtools-tarball) 
> buildtools/sysroots/x86_64-pokysdk-linux/etc/ssl/openssl.cnf
> 
> Signed-off-by: Jens Rehsack 
> ---
>  meta/recipes-core/meta/buildtools-tarball.bb | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb 
> b/meta/recipes-core/meta/buildtools-tarball.bb
> index d0f8dd7d7c..02e662b5cc 100644
> --- a/meta/recipes-core/meta/buildtools-tarball.bb
> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
> @@ -75,7 +75,6 @@ create_sdk_files_append () {
>  
>   echo 'export 
> GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' 
> >>$script
>   echo 'export 
> SSL_CERT_FILE="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' 
> >>$script
> - echo 'export 
> OPENSSL_CONF="${SDKPATHNATIVE}${sysconfdir}/ssl/openssl.cnf"' >>$script
>  
>   if [ "${SDKMACHINE}" = "i686" ]; then
>   echo 'export NO32LIBS="0"' >>$script

I did look at this further. I don't see anywhere in buildtools-tarball
that the code you add in toolchain-scripts.bbclass is actually run, it
doesn't make it into the buildtools tarball.

Note the code does:

 rm -f ${SDK_OUTPUT}/${SDKPATH}/environment-setup-*
 [...]

 # Generate new (mini) sdk-environment-setup file
 script=${1:-${SDK_OUTPUT}/${SDKPATH}/environment-setup-${SDK_SYS}}
 touch $script

so your patch definitely breaks buildtools. I therefore don't plan to
merge it.

You are right that we could add something here to source the
environment.d files within OECORE_NATIVE_SYSROOT but you'd need to add
that to the buildtools environment script itself.

Cheers,

Richard

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

View/Reply Online (#141017): 
https://lists.openembedded.org/g/openembedded-core/message/141017
Mute This Topic: https://lists.openembedded.org/mt/75761298/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] gcc: Fix mangled patch

[Richard Purdie]

To quote Zhuang :
"""
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
using the original proposed sort.
"""

This fixes the gcc patch as proposed as it does appear its been
broken over time.

Signed-off-by: Richard Purdie 
---
 .../0012-gcc-Fix-argument-list-too-long-error.patch | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/gcc/gcc-10.1/0012-gcc-Fix-argument-list-too-long-error.patch
 
b/meta/recipes-devtools/gcc/gcc-10.1/0012-gcc-Fix-argument-list-too-long-error.patch
index acbd75f139e..88e1715b5cc 100644
--- 
a/meta/recipes-devtools/gcc/gcc-10.1/0012-gcc-Fix-argument-list-too-long-error.patch
+++ 
b/meta/recipes-devtools/gcc/gcc-10.1/0012-gcc-Fix-argument-list-too-long-error.patch
@@ -17,6 +17,10 @@ $(sort list) doesn't need this.
 Signed-off-by: Robert Yang 
 Signed-off-by: Khem Raj 
 
+RP: gcc then added *.h and *.def additions to this list, breaking the original
+fix. Add the sort to the original gcc code, leaving the tr+sort to fix the 
original
+issue but include the new files too as reported by Zhuang 

+
 Upstream-Status: Pending
 ---
  gcc/Makefile.in | 2 +-
@@ -31,7 +35,7 @@ index a67d2cc18d6..480c9366418 100644
  # files. All other files are flattened to a single directory.
$(mkinstalldirs) $(DESTDIR)$(plugin_includedir)
 -  headers=`echo $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def) | tr ' 
' '\012' | sort -u`; \
-+  headers="$(sort $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def))"; \
++  headers=`echo $(sort $(PLUGIN_HEADERS)) $$(cd $(srcdir); echo *.h 
*.def) | tr ' ' '\012' | sort -u`; \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/&/g'`; \
for file in $$headers; do \
  if [ -f $$file ] ; then \
-- 
2.25.1

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

View/Reply Online (#141016): 
https://lists.openembedded.org/g/openembedded-core/message/141016
Mute This Topic: https://lists.openembedded.org/mt/75833104/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?

[Andre McCurdy]

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?

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

So what's the conclusion? That CPU's without NEON are so rare that OE
doesn't need to care about them?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141015): 
https://lists.openembedded.org/g/openembedded-core/message/141015
Mute This Topic: https://lists.openembedded.org/mt/75658822/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] re2c: update to 2.0

[Oleksandr Kravchuk]

On 27/07/2020 21:22, Richard Purdie wrote:

On Sun, 2020-07-26 at 21:42 +0200, Oleksandr Kravchuk wrote:

Signed-off-by: Oleksandr Kravchuk 
---
  meta/recipes-support/re2c/{re2c_1.3.bb => re2c_2.0.bb} | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)
  rename meta/recipes-support/re2c/{re2c_1.3.bb => re2c_2.0.bb} (74%)

diff --git a/meta/recipes-support/re2c/re2c_1.3.bb 
b/meta/recipes-support/re2c/re2c_2.0.bb
similarity index 74%
rename from meta/recipes-support/re2c/re2c_1.3.bb
rename to meta/recipes-support/re2c/re2c_2.0.bb
index e9053acdf6..b73b024072 100644
--- a/meta/recipes-support/re2c/re2c_1.3.bb
+++ b/meta/recipes-support/re2c/re2c_2.0.bb
@@ -5,10 +5,8 @@ SECTION = "devel"
  LICENSE = "PD"
  LIC_FILES_CHKSUM = "file://LICENSE;md5=64eca4d8a3b67f9dc7656094731a2c8d"
  
-SRC_URI = "https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz \

-   file://CVE-2020-11958.patch \
-"
-SRC_URI[sha256sum] = 
"f37f25ff760e90088e7d03d1232002c2c2672646d5844fdf8e0d51a5cd75a503"
+SRC_URI = 
"https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz";
+SRC_URI[sha256sum] = 
"89a9d7ee14be10e3779ea7b2c8ea4a964afce6e76b8dbcd5479940681db46d20"
  UPSTREAM_CHECK_URI = "https://github.com/skvadrik/re2c/releases";
  
  BBCLASSEXTEND = "native nativesdk"

The above patch wasn't git rm'd. I fixed it as I merged it.

Cheers,

Richard


Thank you, Richard.

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

View/Reply Online (#141014): 
https://lists.openembedded.org/g/openembedded-core/message/141014
Mute This Topic: https://lists.openembedded.org/mt/75809311/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] re2c: update to 2.0

[Richard Purdie]

On Sun, 2020-07-26 at 21:42 +0200, Oleksandr Kravchuk wrote:
> Signed-off-by: Oleksandr Kravchuk 
> ---
>  meta/recipes-support/re2c/{re2c_1.3.bb => re2c_2.0.bb} | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>  rename meta/recipes-support/re2c/{re2c_1.3.bb => re2c_2.0.bb} (74%)
> 
> diff --git a/meta/recipes-support/re2c/re2c_1.3.bb 
> b/meta/recipes-support/re2c/re2c_2.0.bb
> similarity index 74%
> rename from meta/recipes-support/re2c/re2c_1.3.bb
> rename to meta/recipes-support/re2c/re2c_2.0.bb
> index e9053acdf6..b73b024072 100644
> --- a/meta/recipes-support/re2c/re2c_1.3.bb
> +++ b/meta/recipes-support/re2c/re2c_2.0.bb
> @@ -5,10 +5,8 @@ SECTION = "devel"
>  LICENSE = "PD"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=64eca4d8a3b67f9dc7656094731a2c8d"
>  
> -SRC_URI = 
> "https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz 
> \
> -   file://CVE-2020-11958.patch \
> -"
> -SRC_URI[sha256sum] = 
> "f37f25ff760e90088e7d03d1232002c2c2672646d5844fdf8e0d51a5cd75a503"
> +SRC_URI = 
> "https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz";
> +SRC_URI[sha256sum] = 
> "89a9d7ee14be10e3779ea7b2c8ea4a964afce6e76b8dbcd5479940681db46d20"
>  UPSTREAM_CHECK_URI = "https://github.com/skvadrik/re2c/releases";
>  
>  BBCLASSEXTEND = "native nativesdk"

The above patch wasn't git rm'd. I fixed it as I merged it.

Cheers,

Richard

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

View/Reply Online (#141013): 
https://lists.openembedded.org/g/openembedded-core/message/141013
Mute This Topic: https://lists.openembedded.org/mt/75809311/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] git: update 2.28.0

[Oleksandr Kravchuk]

Signed-off-by: Oleksandr Kravchuk 
---
 meta/recipes-devtools/git/{git_2.27.0.bb => git_2.28.0.bb} | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/git/{git_2.27.0.bb => git_2.28.0.bb} (51%)

diff --git a/meta/recipes-devtools/git/git_2.27.0.bb 
b/meta/recipes-devtools/git/git_2.28.0.bb
similarity index 51%
rename from meta/recipes-devtools/git/git_2.27.0.bb
rename to meta/recipes-devtools/git/git_2.28.0.bb
index 8022659ad7..e90787d060 100644
--- a/meta/recipes-devtools/git/git_2.27.0.bb
+++ b/meta/recipes-devtools/git/git_2.28.0.bb
@@ -5,6 +5,5 @@ EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
  "
 EXTRA_OEMAKE += "NO_GETTEXT=1"
 
-SRC_URI[tarball.sha256sum] = 
"77ded85cbe42b1ffdc2578b460a1ef5d23bcbc6683eabcafbb0d394dffe2e787"
-SRC_URI[manpages.sha256sum] = 
"414e4b17133e54d846f6bfa2479f9757c50e16c013eb76167a492ae5409b8947"
-
+SRC_URI[tarball.sha256sum] = 
"f914c60a874d466c1e18467c864a910dd4ea22281ba6d4d58077cb0c3f115170"
+SRC_URI[manpages.sha256sum] = 
"3cfca28a88d5b8112ea42322b797a500a14d0acddea391aed0462aff1ab11bf7"
-- 
2.25.1

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

View/Reply Online (#141012): 
https://lists.openembedded.org/g/openembedded-core/message/141012
Mute This Topic: https://lists.openembedded.org/mt/75830234/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] python3-numpy: Stop shipping manual config files

[Adrian Bunk]

On Tue, Jul 21, 2020 at 12:28:15PM +0200, Frieder Schrempf wrote:
> Hi Armin, Anuj, Adrian,

Hi Frieder,

> On 27.10.19 18:36, Adrian Bunk wrote:
> > Automatic generation seems to work fine,
> > and does not become outdated.
> > 
> > Signed-off-by: Adrian Bunk 
> 
> Can you confirm this will also work on zeus, or does zeus miss some other
> patches this depends on?
>...

I am not aware of any reason why it shouldn't work in zeus,
it entered master shortly after zeus was branched.

> Thanks,
> Frieder

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

View/Reply Online (#141010): 
https://lists.openembedded.org/g/openembedded-core/message/141010
Mute This Topic: https://lists.openembedded.org/mt/72386853/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

[Ruslan Babayev]

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 (#141011): 
https://lists.openembedded.org/g/openembedded-core/message/141011
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] [PATCH v2] cve-update: handle baseMetricV2 as optional

[Konrad Weihmann]

Hi all,

please consider this patch to be backported to dunfell/zeus and warrior.
Master-rev: bbefe04a622e166d95093d5127c316de91b27d20

Thanks
Konrad

On 26.07.20 16:10, Konrad Weihmann wrote:

Currently in NVD DB an item popped up, which hasn't set baseMetricV2.
Let the parser handle it as an optional item.
In case use baseMetricV2 before baseMetricV3

Signed-off-by: Konrad Weihmann 
---
  meta/recipes-core/meta/cve-update-db-native.bb | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/meta/cve-update-db-native.bb 
b/meta/recipes-core/meta/cve-update-db-native.bb
index f27ade40db..32d6dbdffc 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -176,15 +176,20 @@ def update_db(c, jsondata):
  if not elt['impact']:
  continue
  
+accessVector = None

  cveId = elt['cve']['CVE_data_meta']['ID']
  cveDesc = elt['cve']['description']['description_data'][0]['value']
  date = elt['lastModifiedDate']
-accessVector = elt['impact']['baseMetricV2']['cvssV2']['accessVector']
-cvssv2 = elt['impact']['baseMetricV2']['cvssV2']['baseScore']
-
  try:
+accessVector = 
elt['impact']['baseMetricV2']['cvssV2']['accessVector']
+cvssv2 = elt['impact']['baseMetricV2']['cvssV2']['baseScore']
+except KeyError:
+cvssv2 = 0.0
+try:
+accessVector = accessVector or 
elt['impact']['baseMetricV3']['cvssV3']['attackVector']
  cvssv3 = elt['impact']['baseMetricV3']['cvssV3']['baseScore']
-except:
+except KeyError:
+accessVector = accessVector or "UNKNOWN"
  cvssv3 = 0.0
  
  c.execute("insert or replace into NVD values (?, ?, ?, ?, ?, ?)",





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

View/Reply Online (#141009): 
https://lists.openembedded.org/g/openembedded-core/message/141009
Mute This Topic: https://lists.openembedded.org/mt/75802993/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][dunfell 14/18] core: glib-2.0: fix requested libmount/mkostemp/selinux not being linked in

[Steve Sakoman]

On Mon, Jul 27, 2020 at 6:14 AM Andreas Müller  wrote:

> If I am not mistaken, the patch
> "meson.bbclass: avoid unexpected operating-system names"
> made it into dunfell so this patch does not change anything (it should
> do no harm either)

You are correct!  I didn't parse the commit message properly when I
took this patch.

I'll drop this patch from the final pull request.

Thanks for reviewing it, I really appreciate your help!

Steve


> Andreas
> > To fix just the glib issue, instances of host_system == 'linux' are patched
> > locally.
> >
> > The patch is marked as Upstream-Status: Inappropriate as it is rendered
> > unnecessary for OE releases newer than Dunfell.
> >
> > Signed-off-by: Ahmad Fatoum 
> > Signed-off-by: Steve Sakoman 
> > ---
> >  ...ot-hardcode-linux-as-the-host-system.patch | 49 +++
> >  meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb |  1 +
> >  2 files changed, 50 insertions(+)
> >  create mode 100644 
> > meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> >
> > diff --git 
> > a/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> >  
> > b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> > new file mode 100644
> > index 00..616bbd8a7d
> > --- /dev/null
> > +++ 
> > b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> > @@ -0,0 +1,49 @@
> > +From a300a09661124451d4783d4be66e3993262dc9be Mon Sep 17 00:00:00 2001
> > +From: Ahmad Fatoum 
> > +Date: Thu, 9 Jul 2020 13:00:16 +0200
> > +Subject: [PATCH] meson.build: do not hardcode 'linux' as the host system
> > +
> > +OE build system can set this to other values that include 'linux',
> > +e.g. 'linux-gnueabi'. This led to glib always being built without
> > +libmount, mkostemp and selinux support.
> > +
> > +Upstream-Status: Inappropriate [other]
> > +Signed-off-by: Ahmad Fatoum 
> > +---
> > + meson.build | 6 +++---
> > + 1 file changed, 3 insertions(+), 3 deletions(-)
> > +
> > +diff --git a/meson.build b/meson.build
> > +index 3a47a7cc4b98..af09dfc853e5 100644
> > +--- a/meson.build
> >  b/meson.build
> > +@@ -632,7 +632,7 @@ else
> > + endif
> > + message('Checking whether to use statfs or statvfs .. ' + 
> > stat_func_to_use)
> > +
> > +-if host_system == 'linux'
> > ++if host_system.contains('linux')
> > +   if cc.has_function('mkostemp',
> > +  prefix: '''#define _GNU_SOURCE
> > + #include ''')
> > +@@ -1857,7 +1857,7 @@ glib_conf.set_quoted('GLIB_LOCALE_DIR', 
> > join_paths(glib_datadir, 'locale'))
> > + # libmount is only used by gio, but we need to fetch the libs to generate 
> > the
> > + # pkg-config file below
> > + libmount_dep = []
> > +-if host_system == 'linux' and get_option('libmount')
> > ++if host_system.contains('linux') and get_option('libmount')
> > +   libmount_dep = [dependency('mount', version : '>=2.23', required : 
> > true)]
> > +   glib_conf.set('HAVE_LIBMOUNT', 1)
> > + endif
> > +@@ -1867,7 +1867,7 @@ if host_system == 'windows'
> > + endif
> > +
> > + selinux_dep = []
> > +-if host_system == 'linux'
> > ++if host_system.contains('linux')
> > +   selinux_dep = dependency('libselinux', required: get_option('selinux'))
> > +
> > +   glib_conf.set('HAVE_SELINUX', selinux_dep.found())
> > +--
> > +2.27.0
> > +
> > diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb 
> > b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> > index d496235003..fd7f5ee920 100644
> > --- a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> > +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> > @@ -19,6 +19,7 @@ SRC_URI = 
> > "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
> > 
> > file://0011-GMainContext-Fix-GSource-iterator-if-iteration-can-m.patch \
> > 
> > file://0012-GMainContext-Fix-memory-leaks-and-memory-corruption-.patch \
> > 
> > file://0013-GMainContext-Move-mutex-unlocking-in-destructor-righ.patch \
> > +   
> > file://0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch \
> > "
> >
> >  SRC_URI_append_class-native = " file://relocate-modules.patch"
> > --
> > 2.17.1
> >
> > 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141008): 
https://lists.openembedded.org/g/openembedded-core/message/141008
Mute This Topic: https://lists.openembedded.org/mt/75824515/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][dunfell 14/18] core: glib-2.0: fix requested libmount/mkostemp/selinux not being linked in

[Andreas Müller]

On Mon, Jul 27, 2020 at 5:10 PM Steve Sakoman  wrote:
>
> From: Ahmad Fatoum 
>
> Since 010202076760 ("meson.bbclass: avoid unexpected operating-system
> names"), meson is no longer used with a cross file that appends the used
> libc to the operating system name, e.g. linux-gnueabi.
>
> Prior to that commit, the host_system == 'linux' checks in glib's meson
> failed, which led to glib being compiled without libmount, mkostemp and
> selinux even if explicitly requested.
>
> As the aforementioned commit affects all recipes built by glib, it might
> not be a candidate for backporting to current stable branches.
If I am not mistaken, the patch
"meson.bbclass: avoid unexpected operating-system names"
made it into dunfell so this patch does not change anything (it should
do no harm either)

Andreas
> To fix just the glib issue, instances of host_system == 'linux' are patched
> locally.
>
> The patch is marked as Upstream-Status: Inappropriate as it is rendered
> unnecessary for OE releases newer than Dunfell.
>
> Signed-off-by: Ahmad Fatoum 
> Signed-off-by: Steve Sakoman 
> ---
>  ...ot-hardcode-linux-as-the-host-system.patch | 49 +++
>  meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb |  1 +
>  2 files changed, 50 insertions(+)
>  create mode 100644 
> meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
>
> diff --git 
> a/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
>  
> b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> new file mode 100644
> index 00..616bbd8a7d
> --- /dev/null
> +++ 
> b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
> @@ -0,0 +1,49 @@
> +From a300a09661124451d4783d4be66e3993262dc9be Mon Sep 17 00:00:00 2001
> +From: Ahmad Fatoum 
> +Date: Thu, 9 Jul 2020 13:00:16 +0200
> +Subject: [PATCH] meson.build: do not hardcode 'linux' as the host system
> +
> +OE build system can set this to other values that include 'linux',
> +e.g. 'linux-gnueabi'. This led to glib always being built without
> +libmount, mkostemp and selinux support.
> +
> +Upstream-Status: Inappropriate [other]
> +Signed-off-by: Ahmad Fatoum 
> +---
> + meson.build | 6 +++---
> + 1 file changed, 3 insertions(+), 3 deletions(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 3a47a7cc4b98..af09dfc853e5 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -632,7 +632,7 @@ else
> + endif
> + message('Checking whether to use statfs or statvfs .. ' + stat_func_to_use)
> +
> +-if host_system == 'linux'
> ++if host_system.contains('linux')
> +   if cc.has_function('mkostemp',
> +  prefix: '''#define _GNU_SOURCE
> + #include ''')
> +@@ -1857,7 +1857,7 @@ glib_conf.set_quoted('GLIB_LOCALE_DIR', 
> join_paths(glib_datadir, 'locale'))
> + # libmount is only used by gio, but we need to fetch the libs to generate 
> the
> + # pkg-config file below
> + libmount_dep = []
> +-if host_system == 'linux' and get_option('libmount')
> ++if host_system.contains('linux') and get_option('libmount')
> +   libmount_dep = [dependency('mount', version : '>=2.23', required : true)]
> +   glib_conf.set('HAVE_LIBMOUNT', 1)
> + endif
> +@@ -1867,7 +1867,7 @@ if host_system == 'windows'
> + endif
> +
> + selinux_dep = []
> +-if host_system == 'linux'
> ++if host_system.contains('linux')
> +   selinux_dep = dependency('libselinux', required: get_option('selinux'))
> +
> +   glib_conf.set('HAVE_SELINUX', selinux_dep.found())
> +--
> +2.27.0
> +
> diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb 
> b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> index d496235003..fd7f5ee920 100644
> --- a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
> @@ -19,6 +19,7 @@ SRC_URI = 
> "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
> 
> file://0011-GMainContext-Fix-GSource-iterator-if-iteration-can-m.patch \
> 
> file://0012-GMainContext-Fix-memory-leaks-and-memory-corruption-.patch \
> 
> file://0013-GMainContext-Move-mutex-unlocking-in-destructor-righ.patch \
> +   
> file://0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch \
> "
>
>  SRC_URI_append_class-native = " file://relocate-modules.patch"
> --
> 2.17.1
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141007): 
https://lists.openembedded.org/g/openembedded-core/message/141007
Mute This Topic: https://lists.openembedded.org/mt/75824515/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] [v2][PATCH] cve-check: print warning if file is missing

[Richard Purdie]

On Mon, 2020-07-27 at 09:05 -0700, akuster808 wrote:
> 
> On 7/27/20 7:47 AM, Richard Purdie wrote:
> > On Mon, 2020-07-27 at 06:57 -0700, akuster808 wrote:
> > > On 7/27/20 2:39 AM, Richard Purdie wrote:
> > > > On Sun, 2020-07-26 at 19:52 -0700, akuster wrote:
> > > > > If the "tmp/cve_check" file was not create as in the case for
> > > > > -c
> > > > > populate_sdk, just print a
> > > > > warning instead of dumping a trace back
> > > > > 
> > > > > ---
> > > > > v2] lets include the missing part of the patch
> > > > > 
> > > > > Signed-off-by: Armin Kuster 
> > > > > ---
> > > > >  meta/classes/cve-check.bbclass | 4 
> > > > >  1 file changed, 4 insertions(+)
> > > > > 
> > > > > diff --git a/meta/classes/cve-check.bbclass
> > > > > b/meta/classes/cve-
> > > > > check.bbclass
> > > > > index 0889e7544aa..b16da9890af 100644
> > > > > --- a/meta/classes/cve-check.bbclass
> > > > > +++ b/meta/classes/cve-check.bbclass
> > > > > @@ -55,6 +55,10 @@ python cve_save_summary_handler () {
> > > > >  
> > > > >  cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
> > > > >  
> > > > > +if not os.path.isfile(cve_tmp_file):
> > > > > +bb.warn("File Not found: %s" % cve_tmp_file)
> > > > > +return
> > > > > +
> > > > A warning is something the user really needs to fix or take
> > > > some
> > > > action
> > > > about. Is this a warning?
> > > Its actually an error in certail conditions. Do we want this to
> > > be
> > > silent or fail on 'populate_sdk'?
> > What are the "certain conditions"?
> 
> populate_sdk
> 
> > Should it not detect those conditions and error if they occur?
> if INHERIT += "cve-check' is included and -c populate_sdk, the file
> is
> not generated.
> 
> > Showing a warning and asking the user to guess is not a good user
> > experience. I have no idea whether I should worry about the warning
> > above or not for example, so I doubt anyone else does either.
> 
> I am fine with not sending any warning.

That sounds like the correct solution to me in this case or maybe a
bb.note() which won't be shown on the console but probably will be in
the logs.

Cheers,

Richard

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

View/Reply Online (#141006): 
https://lists.openembedded.org/g/openembedded-core/message/141006
Mute This Topic: https://lists.openembedded.org/mt/75815509/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 v2 1/2] toolchain-scripts.bbclass: also recognize ${SDK_SYS} env setups

[Richard Purdie]

On Fri, 2020-07-24 at 07:26 +0200, Jens Rehsack wrote:
> Instead of recognizing only environment-setup scripts in
> ${STAGING_DIR_TARGET} or ${STAGING_DIR_NATIVE}, respectively - lurk also into
> ${SDKPATH}/buildtools/sysroots/${SDK_SYS} where nativesdk-openssl installs
> setup files.
> 
> Signed-off-by: Jens Rehsack 
> ---
>  meta/classes/toolchain-scripts.bbclass | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/toolchain-scripts.bbclass 
> b/meta/classes/toolchain-scripts.bbclass
> index db1d3215ef..e3959e21e8 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -119,6 +119,11 @@ if [ -d "\$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; 
> then
>   . \$envfile
>  done
>  fi
> +if [ -d "${SDKPATH}/buildtools/sysroots/${SDK_SYS}/environment-setup.d" ]; 
> then
> +for envfile in 
> ${SDKPATH}/buildtools/sysroots/${SDK_SYS}/environment-setup.d/*.sh; do
> + . \$envfile
> +done
> +fi
>  EOF
>  }

I finally got around to looking at this, sorry about the delay. Whilst
this fixes the issue and doesn't harm anything, I think its incorrect.
I suspect that $OECORE_NATIVE_SYSROOT should be pointing at
${SDKPATH}/buildtools/sysroots/${SDK_SYS}.

Could you see where $OECORE_NATIVE_SYSROOT is pointing and see if we
perhaps can't fix that instead?

Cheers,

Richard



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

View/Reply Online (#141005): 
https://lists.openembedded.org/g/openembedded-core/message/141005
Mute This Topic: https://lists.openembedded.org/mt/75761296/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] [v2][PATCH] cve-check: print warning if file is missing

[akuster]

On 7/27/20 7:47 AM, Richard Purdie wrote:
> On Mon, 2020-07-27 at 06:57 -0700, akuster808 wrote:
>> On 7/27/20 2:39 AM, Richard Purdie wrote:
>>> On Sun, 2020-07-26 at 19:52 -0700, akuster wrote:
 If the "tmp/cve_check" file was not create as in the case for -c
 populate_sdk, just print a
 warning instead of dumping a trace back

 ---
 v2] lets include the missing part of the patch

 Signed-off-by: Armin Kuster 
 ---
  meta/classes/cve-check.bbclass | 4 
  1 file changed, 4 insertions(+)

 diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
 check.bbclass
 index 0889e7544aa..b16da9890af 100644
 --- a/meta/classes/cve-check.bbclass
 +++ b/meta/classes/cve-check.bbclass
 @@ -55,6 +55,10 @@ python cve_save_summary_handler () {
  
  cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
  
 +if not os.path.isfile(cve_tmp_file):
 +bb.warn("File Not found: %s" % cve_tmp_file)
 +return
 +
>>> A warning is something the user really needs to fix or take some
>>> action
>>> about. Is this a warning?
>> Its actually an error in certail conditions. Do we want this to be
>> silent or fail on 'populate_sdk'?
> What are the "certain conditions"?

populate_sdk

>
> Should it not detect those conditions and error if they occur?
if INHERIT += "cve-check' is included and -c populate_sdk, the file is
not generated.

>
> Showing a warning and asking the user to guess is not a good user
> experience. I have no idea whether I should worry about the warning
> above or not for example, so I doubt anyone else does either.

I am fine with not sending any warning.

- armin
>
> Cheers,
>
> Richard
>

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

View/Reply Online (#141004): 
https://lists.openembedded.org/g/openembedded-core/message/141004
Mute This Topic: https://lists.openembedded.org/mt/75815509/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 17/18] buildhistory: use pid for temporary txt file name

[Steve Sakoman]

From: Lee Chee Yang 

buildhistory create .txt file bh_installed_pkgs.txt and
bh_installed_pkgs_deps.txt while listing down installed package.
These file is later removed in buildhistory_get_installed().

when multiple process runs in parellal there are chances to race for
the file where one process created the file while another task remove
the file right after it.

using different file name for each process should avoid the race. So
add PID to the file name to make it unique.

[yocto #13709]

Signed-off-by: Lee Chee Yang 
Signed-off-by: Richard Purdie 
(cherry picked from commit 214d236d93700abffa2d586cc744a00455818fa4)
Signed-off-by: Steve Sakoman 
---
 meta/classes/buildhistory.bbclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index eb7295570d..156324d339 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -426,8 +426,8 @@ def buildhistory_list_installed(d, rootfs_type="image"):
 from oe.sdk import sdk_list_installed_packages
 from oe.utils import format_pkg_list
 
-process_list = [('file', 'bh_installed_pkgs.txt'),\
-('deps', 'bh_installed_pkgs_deps.txt')]
+process_list = [('file', 'bh_installed_pkgs_%s.txt' % os.getpid()),\
+('deps', 'bh_installed_pkgs_deps_%s.txt' % os.getpid())]
 
 if rootfs_type == "image":
 pkgs = image_list_installed_packages(d)
@@ -457,9 +457,10 @@ buildhistory_get_installed() {
 
# Get list of installed packages
pkgcache="$1/installed-packages.tmp"
-   cat ${WORKDIR}/bh_installed_pkgs.txt | sort > $pkgcache && rm 
${WORKDIR}/bh_installed_pkgs.txt
+   cat ${WORKDIR}/bh_installed_pkgs_${PID}.txt | sort > $pkgcache && rm 
${WORKDIR}/bh_installed_pkgs_${PID}.txt
 
cat $pkgcache | awk '{ print $1 }' > $1/installed-package-names.txt
+
if [ -s $pkgcache ] ; then
cat $pkgcache | awk '{ print $2 }' | xargs -n1 basename > 
$1/installed-packages.txt
else
@@ -468,8 +469,8 @@ buildhistory_get_installed() {
 
# Produce dependency graph
# First, quote each name to handle characters that cause issues for dot
-   sed 's:\([^| ]*\):"\1":g' ${WORKDIR}/bh_installed_pkgs_deps.txt > 
$1/depends.tmp &&
-   rm ${WORKDIR}/bh_installed_pkgs_deps.txt
+   sed 's:\([^| ]*\):"\1":g' ${WORKDIR}/bh_installed_pkgs_deps_${PID}.txt 
> $1/depends.tmp &&
+   rm ${WORKDIR}/bh_installed_pkgs_deps_${PID}.txt
# Remove lines with rpmlib(...) and config(...) dependencies, change the
# delimiter from pipe to "->", set the style for recommend lines and
# turn versioned dependencies into edge labels.
-- 
2.17.1

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

View/Reply Online (#141002): 
https://lists.openembedded.org/g/openembedded-core/message/141002
Mute This Topic: https://lists.openembedded.org/mt/75824519/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 18/18] glibc: Secruity fix for CVE-2020-6096

[Steve Sakoman]

From: Armin Kuster 

Source: glibc.org
MR: 104799
Type: Security Fix
Disposition: Backport from  beea361050728138b82c57dda0c4810402d342b9
ChangeID: 29df826fb697fdd2742c3bace33388bda962c5f1
Description:

Signed-off-by: Armin Kuster 
Signed-off-by: Richard Purdie 
(cherry picked from commit ffa4fa35e1f6132b19788166a2b87517d9e17d95)
Signed-off-by: Steve Sakoman 
---
 .../glibc/glibc/CVE-2020-6096.patch   | 112 ++
 .../glibc/glibc/CVE-2020-6096_2.patch | 194 ++
 meta/recipes-core/glibc/glibc_2.31.bb |   2 +
 3 files changed, 308 insertions(+)
 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

diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-6096.patch 
b/meta/recipes-core/glibc/glibc/CVE-2020-6096.patch
new file mode 100644
index 00..9c26f76432
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2020-6096.patch
@@ -0,0 +1,112 @@
+From beea361050728138b82c57dda0c4810402d342b9 Mon Sep 17 00:00:00 2001
+From: Alexander Anisimov 
+Date: Wed, 8 Jul 2020 14:18:31 +0200
+Subject: [PATCH] arm: CVE-2020-6096: Fix multiarch memcpy for negative length
+ [BZ #25620]
+
+Unsigned branch instructions could be used for r2 to fix the wrong
+behavior when a negative length is passed to memcpy.
+This commit fixes the armv7 version.
+
+Upstream-Status: Backport
+CVE: CVE-2020-6096 patch #1
+Signed-off-by: Armin Kuster 
+
+---
+ sysdeps/arm/armv7/multiarch/memcpy_impl.S | 22 +++---
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/sysdeps/arm/armv7/multiarch/memcpy_impl.S 
b/sysdeps/arm/armv7/multiarch/memcpy_impl.S
+index bf4ac7077f..379bb56fc9 100644
+--- a/sysdeps/arm/armv7/multiarch/memcpy_impl.S
 b/sysdeps/arm/armv7/multiarch/memcpy_impl.S
+@@ -268,7 +268,7 @@ ENTRY(memcpy)
+ 
+   mov dst, dstin  /* Preserve dstin, we need to return it.  */
+   cmp count, #64
+-  bge .Lcpy_not_short
++  bhs .Lcpy_not_short
+   /* Deal with small copies quickly by dropping straight into the
+  exit block.  */
+ 
+@@ -351,10 +351,10 @@ ENTRY(memcpy)
+ 
+ 1:
+   substmp2, count, #64/* Use tmp2 for count.  */
+-  blt .Ltail63aligned
++  blo .Ltail63aligned
+ 
+   cmp tmp2, #512
+-  bge .Lcpy_body_long
++  bhs .Lcpy_body_long
+ 
+ .Lcpy_body_medium:/* Count in tmp2.  */
+ #ifdef USE_VFP
+@@ -378,7 +378,7 @@ ENTRY(memcpy)
+   add src, src, #64
+   vstrd1, [dst, #56]
+   add dst, dst, #64
+-  bge 1b
++  bhs 1b
+   tst tmp2, #0x3f
+   beq .Ldone
+ 
+@@ -412,7 +412,7 @@ ENTRY(memcpy)
+   ldrdA_l, A_h, [src, #64]!
+   strdA_l, A_h, [dst, #64]!
+   substmp2, tmp2, #64
+-  bge 1b
++  bhs 1b
+   tst tmp2, #0x3f
+   bne 1f
+   ldr tmp2,[sp], #FRAME_SIZE
+@@ -482,7 +482,7 @@ ENTRY(memcpy)
+   add src, src, #32
+ 
+   substmp2, tmp2, #prefetch_lines * 64 * 2
+-  blt 2f
++  blo 2f
+ 1:
+   cpy_line_vfpd3, 0
+   cpy_line_vfpd4, 64
+@@ -494,7 +494,7 @@ ENTRY(memcpy)
+   add dst, dst, #2 * 64
+   add src, src, #2 * 64
+   substmp2, tmp2, #prefetch_lines * 64
+-  bge 1b
++  bhs 1b
+ 
+ 2:
+   cpy_tail_vfpd3, 0
+@@ -615,8 +615,8 @@ ENTRY(memcpy)
+ 1:
+   pld [src, #(3 * 64)]
+   subscount, count, #64
+-  ldrmi   tmp2, [sp], #FRAME_SIZE
+-  bmi .Ltail63unaligned
++  ldrlo   tmp2, [sp], #FRAME_SIZE
++  blo .Ltail63unaligned
+   pld [src, #(4 * 64)]
+ 
+ #ifdef USE_NEON
+@@ -633,7 +633,7 @@ ENTRY(memcpy)
+   neon_load_multi d0-d3, src
+   neon_load_multi d4-d7, src
+   subscount, count, #64
+-  bmi 2f
++  blo 2f
+ 1:
+   pld [src, #(4 * 64)]
+   neon_store_multi d0-d3, dst
+@@ -641,7 +641,7 @@ ENTRY(memcpy)
+   neon_store_multi d4-d7, dst
+   neon_load_multi d4-d7, src
+   subscount, count, #64
+-  bpl 1b
++  bhs 1b
+ 2:
+   neon_store_multi d0-d3, dst
+   neon_store_multi d4-d7, dst
+-- 
+2.17.1
+
diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-6096_2.patch 
b/meta/recipes-core/glibc/glibc/CVE-2020-6096_2.patch
new file mode 100644
index 00..905e44c8e3
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2020-6096_2.patch
@@ -0,0 +1,194 @@
+From 79a4fa341b8a89cb03f84564fd72abaa1a2db394 Mon Sep 17 00:00:00 2001
+From: Evgeny Eremin 
+Date: Wed, 8 Jul 2020 14:18:19 +0200
+Subject: [PATCH] arm: CVE-2020-6096: fix memcpy and memmove for negative
+ length [BZ #25620]
+
+Unsigned branch instructions could be used for r2 to fix the wrong
+behavior when a negative length is passed to memcpy and memmove.
+This commit fixes the generic arm implementation of memcpy amd memmove.
+
+Upstream-Status: Backport
+CVE: C

[OE-core][dunfell 14/18] core: glib-2.0: fix requested libmount/mkostemp/selinux not being linked in

[Steve Sakoman]

From: Ahmad Fatoum 

Since 010202076760 ("meson.bbclass: avoid unexpected operating-system
names"), meson is no longer used with a cross file that appends the used
libc to the operating system name, e.g. linux-gnueabi.

Prior to that commit, the host_system == 'linux' checks in glib's meson
failed, which led to glib being compiled without libmount, mkostemp and
selinux even if explicitly requested.

As the aforementioned commit affects all recipes built by glib, it might
not be a candidate for backporting to current stable branches. To fix
just the glib issue, instances of host_system == 'linux' are patched
locally.

The patch is marked as Upstream-Status: Inappropriate as it is rendered
unnecessary for OE releases newer than Dunfell.

Signed-off-by: Ahmad Fatoum 
Signed-off-by: Steve Sakoman 
---
 ...ot-hardcode-linux-as-the-host-system.patch | 49 +++
 meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb |  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch

diff --git 
a/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
 
b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
new file mode 100644
index 00..616bbd8a7d
--- /dev/null
+++ 
b/meta/recipes-core/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch
@@ -0,0 +1,49 @@
+From a300a09661124451d4783d4be66e3993262dc9be Mon Sep 17 00:00:00 2001
+From: Ahmad Fatoum 
+Date: Thu, 9 Jul 2020 13:00:16 +0200
+Subject: [PATCH] meson.build: do not hardcode 'linux' as the host system
+
+OE build system can set this to other values that include 'linux',
+e.g. 'linux-gnueabi'. This led to glib always being built without
+libmount, mkostemp and selinux support.
+
+Upstream-Status: Inappropriate [other]
+Signed-off-by: Ahmad Fatoum 
+---
+ meson.build | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 3a47a7cc4b98..af09dfc853e5 100644
+--- a/meson.build
 b/meson.build
+@@ -632,7 +632,7 @@ else
+ endif
+ message('Checking whether to use statfs or statvfs .. ' + stat_func_to_use)
+ 
+-if host_system == 'linux'
++if host_system.contains('linux')
+   if cc.has_function('mkostemp',
+  prefix: '''#define _GNU_SOURCE
+ #include ''')
+@@ -1857,7 +1857,7 @@ glib_conf.set_quoted('GLIB_LOCALE_DIR', 
join_paths(glib_datadir, 'locale'))
+ # libmount is only used by gio, but we need to fetch the libs to generate the
+ # pkg-config file below
+ libmount_dep = []
+-if host_system == 'linux' and get_option('libmount')
++if host_system.contains('linux') and get_option('libmount')
+   libmount_dep = [dependency('mount', version : '>=2.23', required : true)]
+   glib_conf.set('HAVE_LIBMOUNT', 1)
+ endif
+@@ -1867,7 +1867,7 @@ if host_system == 'windows'
+ endif
+ 
+ selinux_dep = []
+-if host_system == 'linux'
++if host_system.contains('linux')
+   selinux_dep = dependency('libselinux', required: get_option('selinux'))
+ 
+   glib_conf.set('HAVE_SELINUX', selinux_dep.found())
+-- 
+2.27.0
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
index d496235003..fd7f5ee920 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.62.4.bb
@@ -19,6 +19,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\

file://0011-GMainContext-Fix-GSource-iterator-if-iteration-can-m.patch \

file://0012-GMainContext-Fix-memory-leaks-and-memory-corruption-.patch \

file://0013-GMainContext-Move-mutex-unlocking-in-destructor-righ.patch \
+   
file://0020-meson.build-do-not-hardcode-linux-as-the-host-system.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.17.1

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

View/Reply Online (#140999): 
https://lists.openembedded.org/g/openembedded-core/message/140999
Mute This Topic: https://lists.openembedded.org/mt/75824515/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 13/18] startup-notification: add time_t type mismatch patch from upstream

[Steve Sakoman]

From: Ross Burton 

Backport a patch to fix issues where sizeof(time_t) != sizeof(long).

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit f9c3a6d74765e636a8038fe3aaa5dfc8b550590a)
Signed-off-by: Steve Sakoman 
---
 .../startup-notification-0.12/time_t.patch| 108 ++
 .../startup-notification_0.12.bb  |   1 +
 2 files changed, 109 insertions(+)
 create mode 100644 
meta/recipes-graphics/startup-notification/startup-notification-0.12/time_t.patch

diff --git 
a/meta/recipes-graphics/startup-notification/startup-notification-0.12/time_t.patch
 
b/meta/recipes-graphics/startup-notification/startup-notification-0.12/time_t.patch
new file mode 100644
index 00..e5dff007d4
--- /dev/null
+++ 
b/meta/recipes-graphics/startup-notification/startup-notification-0.12/time_t.patch
@@ -0,0 +1,108 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From a7e49fefde18ea8d5bada8096d32f23bcfb5a6dc Mon Sep 17 00:00:00 2001
+From: "Federico G. Schwindt" 
+Date: Mon, 17 Feb 2014 15:48:12 +0100
+Subject: [PATCH 1/3] Fix crash on 32bit architectures where time_t is 64 bit
+
+This is an ABI change on platforms where sizeof(time_t) doesn't equal
+sizeof(long). For most platforms this change shouldn't make a difference
+at present. OpenBSD recently switched to 64bit time_t on all architectures
+to avoid time_t overflow in 2038 on 32bit machines.
+
+This fix extends to consumers of startup-notification, for instance
+the window manager of XFCE, which is how I got involved in this.
+See http://mail.xfce.org/pipermail/xfce4-dev/2014-February/030611.html
+and follow-ups. The XFCE devs pointed out that my patch to fix a
+crash in XFCE's window manager depends on this startup-notification patch.
+
+Signed-off-by: Julien Danjou 
+---
+ libsn/sn-monitor.c | 8 
+ libsn/sn-monitor.h | 8 
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/libsn/sn-monitor.c b/libsn/sn-monitor.c
+index 2a9ad16..f419bc1 100644
+--- a/libsn/sn-monitor.c
 b/libsn/sn-monitor.c
+@@ -364,8 +364,8 @@ sn_startup_sequence_get_screen (SnStartupSequence 
*sequence)
+  **/
+ void
+ sn_startup_sequence_get_initiated_time (SnStartupSequence *sequence,
+-long  *tv_sec,
+-long  *tv_usec)
++time_t*tv_sec,
++suseconds_t   *tv_usec)
+ {
+   if (tv_sec)
+ *tv_sec = sequence->initiation_time.tv_sec;
+@@ -386,8 +386,8 @@ sn_startup_sequence_get_initiated_time (SnStartupSequence 
*sequence,
+  **/
+ void
+ sn_startup_sequence_get_last_active_time (SnStartupSequence *sequence,
+-  long  *tv_sec,
+-  long  *tv_usec)
++  time_t*tv_sec,
++  suseconds_t   *tv_usec)
+ {
+   /* for now the same as get_initiated_time */
+   if (tv_sec)
+diff --git a/libsn/sn-monitor.h b/libsn/sn-monitor.h
+index b58581f..2f639df 100644
+--- a/libsn/sn-monitor.h
 b/libsn/sn-monitor.h
+@@ -77,11 +77,11 @@ const char* sn_startup_sequence_get_application_id
(SnStartupSequence *se
+ int sn_startup_sequence_get_screen(SnStartupSequence 
*sequence);
+ 
+ voidsn_startup_sequence_get_initiated_time(SnStartupSequence 
*sequence,
+-   long  
*tv_sec,
+-   long  
*tv_usec);
++   time_t
*tv_sec,
++   suseconds_t   
*tv_usec);
+ voidsn_startup_sequence_get_last_active_time  (SnStartupSequence 
*sequence,
+-   long  
*tv_sec,
+-   long  
*tv_usec);
++   time_t
*tv_sec,
++   suseconds_t   
*tv_usec);
+ 
+ voidsn_startup_sequence_complete  (SnStartupSequence 
*sequence);
+ 
+-- 
+2.26.2
+
+From ea9f7e4cc6fd8c08d175ed7774ed2c5bd11c8ef0 Mon Sep 17 00:00:00 2001
+From: Colin Walters 
+Date: Mon, 17 Feb 2014 14:37:09 -0500
+Subject: [PATCH 2/3] Add include of  for previous patch
+
+Unfortunately while the standard says that  is the
+correct header to get suseconds_t, at least with glibc, that requires
+-DXOPEN_SOURCE.  Which is problematic for a public header, because
+then all *users* of startup-notification will be required to define
+that.
+
+Poking around a bit, it looks like at least with glibc, 
+will gi

[OE-core][dunfell 16/18] gtk-immodules-cache.bbclass: fix post install scriptlet error

[Steve Sakoman]

From: Changqing Li 

package libgtk-3.0 don't install dir /usr/lib/gtk-3.0/3.0.0/ by default.
when install package gtk-immodule-xim, it is possible met below error:

/var/tmp/rpm-tmp.tlfoeo: line 17: /usr/lib/gtk-3.0/3.0.0/immodules.cache: No 
such file or directory
warning: %post(gtk-immodule-xim-2.24.32-r0.0.cortexa72) scriptlet failed, exit 
status 1

fix by create the dir when try to write to 
/usr/lib/gtk-3.0/3.0.0/immodules.cache

Signed-off-by: Changqing Li 
Signed-off-by: Richard Purdie 
(cherry picked from commit c689e120961d9d20386c8b822d71d778d4e6df7b)
Signed-off-by: Steve Sakoman 
---
 meta/classes/gtk-immodules-cache.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/gtk-immodules-cache.bbclass 
b/meta/classes/gtk-immodules-cache.bbclass
index 9bb0af8b26..8e783fb493 100644
--- a/meta/classes/gtk-immodules-cache.bbclass
+++ b/meta/classes/gtk-immodules-cache.bbclass
@@ -22,6 +22,7 @@ else
 gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
 fi
 if [ ! -z `which gtk-query-immodules-3.0` ]; then
+mkdir -p ${libdir}/gtk-3.0/3.0.0
 gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
 fi
 fi
-- 
2.17.1

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

View/Reply Online (#141001): 
https://lists.openembedded.org/g/openembedded-core/message/141001
Mute This Topic: https://lists.openembedded.org/mt/75824517/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 10/18] classes/cmake: Fix host detection

[Steve Sakoman]

From: Joshua Watt 

Fixes the class to use HOST_OS and HOST_ARCH to set the cmake SYSTEM
variables. The HOST variables should be used instead of
TARGET_OS/TARGET_ARCH because we want to control how cmake compiles for
where the package is going to run (the host), not what it will be
generating output for (the target). The distinction is only really
relevant when building canadian cross recipes.

Also fix up the host OS detection to account for MinGW by setting
CMAKE_SYSTEM_NAME to "Windows". This eliminates the need for meta-mingw
to patch this in all the cmake recipes it builds.

Signed-off-by: Joshua Watt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 01245db2893e39ffb5d4a00e4689f048d0698974)
Signed-off-by: Steve Sakoman 
---
 meta/classes/cmake.bbclass | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 94ed8061bb..8243f7ce8c 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -70,15 +70,22 @@ CMAKE_BUILD_PARALLEL_LEVEL_task-install = 
"${@oe.utils.parallel_make(d, True)}"
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
 
+def map_host_os_to_system_name(host_os):
+if host_os.startswith('mingw'):
+return 'Windows'
+if host_os.startswith('linux'):
+return 'Linux'
+return host_os
+
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
 # conversions should happen here.
-def map_target_arch_to_uname_arch(target_arch):
-if target_arch == "powerpc":
+def map_host_arch_to_uname_arch(host_arch):
+if host_arch == "powerpc":
 return "ppc"
-if target_arch == "powerpc64":
+if host_arch == "powerpc64":
 return "ppc64"
-return target_arch
+return host_arch
 
 cmake_do_generate_toolchain_file() {
if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
@@ -88,8 +95,8 @@ cmake_do_generate_toolchain_file() {
 # CMake system name must be something like "Linux".
 # This is important for cross-compiling.
 $cmake_crosscompiling
-set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 
's/^\(Linux\).*/\1/'` )
-set( CMAKE_SYSTEM_PROCESSOR 
${@map_target_arch_to_uname_arch(d.getVar('TARGET_ARCH'))} )
+set( CMAKE_SYSTEM_NAME ${@map_host_os_to_system_name(d.getVar('HOST_OS'))} )
+set( CMAKE_SYSTEM_PROCESSOR 
${@map_host_arch_to_uname_arch(d.getVar('HOST_ARCH'))} )
 set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
 set( CMAKE_C_COMPILER_LAUNCHER ${OECMAKE_C_COMPILER_LAUNCHER} )
-- 
2.17.1

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

View/Reply Online (#140995): 
https://lists.openembedded.org/g/openembedded-core/message/140995
Mute This Topic: https://lists.openembedded.org/mt/75824507/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 05/18] linux-firmware: add ibt-20 package

[Steve Sakoman]

From: Kurt Kiefer 

Add the firmware packaging for Intel Bluetooth AX200, also known
as Intel CyclonePeak (CcP).

Signed-off-by: Kurt Kiefer 
Signed-off-by: Richard Purdie 
(cherry picked from commit a701625a95ccb15a9db1a50a02143ba1ac8e6f1d)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
index 2b5963c0c8..bf25ff8b70 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
@@ -281,6 +281,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-ibt-license ${PN}-ibt \
  ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 
${PN}-ibt-hw-37-8 \
  ${PN}-ibt-17 \
+ ${PN}-ibt-20 \
  ${PN}-ibt-misc \
  ${PN}-i915-license ${PN}-i915 \
  ${PN}-ice-license ${PN}-ice \
@@ -806,6 +807,7 @@ LICENSE_${PN}-ibt-hw-37-8 = "Firmware-ibt_firmware"
 LICENSE_${PN}-ibt-11-5= "Firmware-ibt_firmware"
 LICENSE_${PN}-ibt-12-16   = "Firmware-ibt_firmware"
 LICENSE_${PN}-ibt-17 = "Firmware-ibt_firmware"
+LICENSE_${PN}-ibt-20 = "Firmware-ibt_firmware"
 LICENSE_${PN}-ibt-misc= "Firmware-ibt_firmware"
 
 FILES_${PN}-ibt-license = 
"${nonarch_base_libdir}/firmware/LICENCE.ibt_firmware"
@@ -814,6 +816,7 @@ FILES_${PN}-ibt-hw-37-8 = 
"${nonarch_base_libdir}/firmware/intel/ibt-hw-37.8*.bs
 FILES_${PN}-ibt-11-5= "${nonarch_base_libdir}/firmware/intel/ibt-11-5.sfi 
${nonarch_base_libdir}/firmware/intel/ibt-11-5.ddc"
 FILES_${PN}-ibt-12-16   = "${nonarch_base_libdir}/firmware/intel/ibt-12-16.sfi 
${nonarch_base_libdir}/firmware/intel/ibt-12-16.ddc"
 FILES_${PN}-ibt-17 = "${nonarch_base_libdir}/firmware/intel/ibt-17-*.sfi 
${nonarch_base_libdir}/firmware/intel/ibt-17-*.ddc"
+FILES_${PN}-ibt-20 = "${nonarch_base_libdir}/firmware/intel/ibt-20-*.sfi 
${nonarch_base_libdir}/firmware/intel/ibt-20-*.ddc"
 FILES_${PN}-ibt-misc= "${nonarch_base_libdir}/firmware/intel/ibt-*"
 
 RDEPENDS_${PN}-ibt-hw-37-7 = "${PN}-ibt-license"
@@ -821,6 +824,7 @@ RDEPENDS_${PN}-ibt-hw-37.8 = "${PN}-ibt-license"
 RDEPENDS_${PN}-ibt-11-5= "${PN}-ibt-license"
 RDEPENDS_${PN}-ibt-12-16   = "${PN}-ibt-license"
 RDEPENDS_${PN}-ibt-17 = "${PN}-ibt-license"
+RDEPENDS_${PN}-ibt-20 = "${PN}-ibt-license"
 RDEPENDS_${PN}-ibt-misc= "${PN}-ibt-license"
 
 ALLOW_EMPTY_${PN}-ibt= "1"
-- 
2.17.1

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

View/Reply Online (#140990): 
https://lists.openembedded.org/g/openembedded-core/message/140990
Mute This Topic: https://lists.openembedded.org/mt/75824501/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 12/18] image.bbclass: improve wording when image size exceeds the specified limit

[Steve Sakoman]

From: Daniel Ammann 

Signed-off-by: Daniel Ammann 
Signed-off-by: Richard Purdie 
(cherry picked from commit fcaab9d686a4afe53a4693f3b30634215d682389)
Signed-off-by: Steve Sakoman 
---
 meta/classes/image.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 07aa1f1fa5..6620a9e9c3 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -551,14 +551,14 @@ def get_rootfs_size(d):
 if rootfs_maxsize:
 rootfs_maxsize_int = int(rootfs_maxsize)
 if base_size > rootfs_maxsize_int:
-bb.fatal("The rootfs size %d(K) overrides IMAGE_ROOTFS_MAXSIZE: 
%d(K)" % \
+bb.fatal("The rootfs size %d(K) exceeds IMAGE_ROOTFS_MAXSIZE: 
%d(K)" % \
 (base_size, rootfs_maxsize_int))
 
 # Check the initramfs size against INITRAMFS_MAXSIZE (if set)
 if image_fstypes == initramfs_fstypes != ''  and initramfs_maxsize:
 initramfs_maxsize_int = int(initramfs_maxsize)
 if base_size > initramfs_maxsize_int:
-bb.error("The initramfs size %d(K) overrides INITRAMFS_MAXSIZE: 
%d(K)" % \
+bb.error("The initramfs size %d(K) exceeds INITRAMFS_MAXSIZE: 
%d(K)" % \
 (base_size, initramfs_maxsize_int))
 bb.error("You can set INITRAMFS_MAXSIZE a larger value. Usually, 
it should")
 bb.fatal("be less than 1/2 of ram size, or you may fail to boot 
it.\n")
-- 
2.17.1

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

View/Reply Online (#140997): 
https://lists.openembedded.org/g/openembedded-core/message/140997
Mute This Topic: https://lists.openembedded.org/mt/75824511/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 07/18] linux-yocto/5.4: update to v5.4.51

[Steve Sakoman]

From: Bruce Ashfield 

Updating linux-yocto/5.4 to the latest korg -stable release that comprises
the following commits:

1c54d3c15afa Linux 5.4.51
8ba1913cd6ba efi: Make it possible to disable efivar_ssdt entirely
43986c32ee00 dm zoned: assign max_io_len correctly
215e562251bb x86/resctrl: Fix memory bandwidth counter width for AMD
d827fe702e07 mm, compaction: make capture control handling safe wrt 
interrupts
64a94c550c44 mm, compaction: fully assume capture is not NULL in 
compact_zone_order()
2a9278ac9c55 irqchip/gic: Atomically update affinity
7ba23593cbc5 dma-buf: Move dma_buf_release() from fops to dentry_ops
4ae695a05516 drm/amdgpu/atomfirmware: fix vram_info fetching for renoir
2b8c0876bf71 drm/amdgpu: use %u rather than %d for sclk/mclk
94de85d16b0c drm/amd/display: Only revalidate bandwidth on medium and fast 
updates
032343ed6927 MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
2e859b14da39 MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names
71a20b798da3 cifs: Fix the target file was deleted when rename failed.
49dae9bed7dd SMB3: Honor 'handletimeout' flag for multiuser mounts
7ab27439fec7 SMB3: Honor lease disabling for multiuser mounts
0d5824aea7a0 SMB3: Honor persistent/resilient handle flags for multiuser 
mounts
d56787683c61 SMB3: Honor 'seal' flag for multiuser mounts
e0ed5a36fb3a Revert "ALSA: usb-audio: Improve frames size computation"
fe05e114d0fd nfsd: apply umask on fs without ACL support
4ee7f1d2f1c9 spi: spi-fsl-dspi: Fix external abort on interrupt in resume 
or exit paths
9d60af5c3bb3 i2c: mlxcpld: check correct size of maximum RECV_LEN packet
b460fc9d0525 i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
a632f91f7a9c samples/vfs: avoid warning in statx override
cd62eeb31512 nvme: fix a crash in nvme_mpath_add_disk
c64141c68f72 nvme: fix identify error status silent ignore
7d3f489e61b6 SMB3: Honor 'posix' flag for multiuser mounts
8964c93436ad virtio-blk: free vblk-vqs in error path of virtblk_probe()
f795a88eade5 drm: sun4i: hdmi: Remove extra HPD polling
c84138b3c162 nfsd: fix nfsdfs inode reference count leak
2571e1735602 nfsd4: fix nfsdfs reference count loop
31ec38ec9cd5 thermal/drivers/rcar_gen3: Fix undefined temperature if 
negative
a65bde001008 thermal/drivers/mediatek: Fix bank number settings on mt8183
c9426817eac7 hwmon: (acpi_power_meter) Fix potential memory leak in 
acpi_power_meter_add()
3e7bd7e10639 hwmon: (max6697) Make sure the OVERT mask is set correctly
0465f54c5cc4 cxgb4: fix SGE queue dump destination buffer context
6bcb00d08361 cxgb4: use correct type for all-mask IP address comparison
f68bda772639 cxgb4: fix endian conversions for L4 ports in filters
180fbf10a26d cxgb4: parse TC-U32 key values and masks natively
0dc4dd433b94 cxgb4: use unaligned conversion for fetching timestamp
8a1b8e64204e RDMA/counter: Query a counter before release
53e9b62672f7 rxrpc: Fix afs large storage transmission performance drop
60d7de28e0ca drm/msm/dpu: fix error return code in dpu_encoder_init
cc0f67835302 crypto: af_alg - fix use-after-free in af_alg_accept() due to 
bh_lock_sock()
5d6b46a94dbb tpm: Fix TIS locality timeout problems
563e9491f0a3 selftests: tpm: Use /bin/sh instead of /bin/bash
1f98a9ed5799 kgdb: Avoid suspicious RCU usage warning
e6b2e3b5e16e nvme-multipath: fix bogus request queue reference put
5e9523d7e8cd nvme-multipath: fix deadlock due to head->lock
ad69fbe1d262 nvme-multipath: fix deadlock between ana_work and scan_work
c4f007d3dbdd nvme-multipath: set bdi capabilities once
8f4aa3a6de24 s390/debug: avoid kernel warning on too large number of pages
517326aaf41e tools lib traceevent: Handle __attribute__((user)) in field 
names
6f3b8c269d88 tools lib traceevent: Add append() function helper for 
appending strings
3dca0a299ff4 usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
0ff5b1b50d5c rxrpc: Fix race between incoming ACK parser and retransmitter
fe688b144c14 mm/slub: fix stack overruns with SLUB_STATS
f459e8fc7c69 mm/slub.c: fix corrupted freechain in deactivate_slab()
542d541c1edd sched/debug: Make sd->flags sysctl read-only
ab9ee18f4646 usbnet: smsc95xx: Fix use-after-free after removal
58ab86e58b55 EDAC/amd64: Read back the scrub rate PCI register on F15h
d0e533584a05 mm: fix swap cache node allocation mask
1c4404efcf2c io_uring: make sure async workqueue is canceled on exit

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 
(cherry picked from commit 60ee8b2bc14af7bf5b69d00c5d6293f09125407c)
Signed-off-by: Steve Sakoman 
---
 .../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 +--
 3 files changed, 18 insertions(+), 18

[OE-core][dunfell 06/18] openssl: openssl-bin requires openssl-conf to run

[Steve Sakoman]

From: Robert Yang 

Fixed:
$ dnf install openssl-bin
$ openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 365 
-nodes -batch
Can't open /usr/lib/ssl-1.1/openssl.cnf for reading, No such file or directory

Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie 
(cherry picked from commit e93cd3b83a255294c9ab728adc7e237eb1321dab)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 47ed6b7640..815955837b 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -204,6 +204,8 @@ CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 RRECOMMENDS_libcrypto += "openssl-conf"
 RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"
 
+RDEPENDS_${PN}-bin += "openssl-conf"
+
 BBCLASSEXTEND = "native nativesdk"
 
 CVE_PRODUCT = "openssl:openssl"
-- 
2.17.1

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

View/Reply Online (#140991): 
https://lists.openembedded.org/g/openembedded-core/message/140991
Mute This Topic: https://lists.openembedded.org/mt/75824502/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 02/18] wic/filemap: Drop the unused get_unmapped_ranges()

[Steve Sakoman]

From: Kevin Hao 

This method is not used by any code, so drop it.

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
(cherry picked from commit 6513fd9302b9989f97fc9d95e76e06ad5d266774)
Signed-off-by: Steve Sakoman 
---
 scripts/lib/wic/filemap.py | 38 ++
 1 file changed, 2 insertions(+), 36 deletions(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index 8cfed5afa8..f8c6e09d01 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -155,15 +155,6 @@ class _FilemapBase(object):
 
 raise Error("the method is not implemented")
 
-def get_unmapped_ranges(self, start, count): # pylint: disable=W0613,R0201
-"""
-This method has has to be implemented by child classes. Just like
-'get_mapped_ranges()', but yields unmapped block ranges instead
-(holes).
-"""
-
-raise Error("the method is not implemented")
-
 
 # The 'SEEK_HOLE' and 'SEEK_DATA' options of the file seek system call
 _SEEK_DATA = 3
@@ -258,9 +249,8 @@ class FilemapSeek(_FilemapBase):
 
 def _get_ranges(self, start, count, whence1, whence2):
 """
-This function implements 'get_mapped_ranges()' and
-'get_unmapped_ranges()' depending on what is passed in the 'whence1'
-and 'whence2' arguments.
+This function implements 'get_mapped_ranges()' depending
+on what is passed in the 'whence1' and 'whence2' arguments.
 """
 
 assert whence1 != whence2
@@ -290,12 +280,6 @@ class FilemapSeek(_FilemapBase):
 % (start, count, start + count - 1))
 return self._get_ranges(start, count, _SEEK_DATA, _SEEK_HOLE)
 
-def get_unmapped_ranges(self, start, count):
-"""Refer the '_FilemapBase' class for the documentation."""
-self._log.debug("FilemapSeek: get_unmapped_ranges(%d,  %d(%d))"
-% (start, count, start + count - 1))
-return self._get_ranges(start, count, _SEEK_HOLE, _SEEK_DATA)
-
 
 # Below goes the FIEMAP ioctl implementation, which is not very readable
 # because it deals with the rather complex FIEMAP ioctl. To understand the
@@ -485,24 +469,6 @@ class FilemapFiemap(_FilemapBase):
 % (first_prev, last_prev))
 yield (first_prev, last_prev)
 
-def get_unmapped_ranges(self, start, count):
-"""Refer the '_FilemapBase' class for the documentation."""
-self._log.debug("FilemapFiemap: get_unmapped_ranges(%d,  %d(%d))"
-% (start, count, start + count - 1))
-hole_first = start
-for first, last in self._do_get_mapped_ranges(start, count):
-if first > hole_first:
-self._log.debug("FilemapFiemap: yielding range (%d, %d)"
-% (hole_first, first - 1))
-yield (hole_first, first - 1)
-
-hole_first = last + 1
-
-if hole_first < start + count:
-self._log.debug("FilemapFiemap: yielding range (%d, %d)"
-% (hole_first, start + count - 1))
-yield (hole_first, start + count - 1)
-
 def filemap(image, log=None):
 """
 Create and return an instance of a Filemap class - 'FilemapFiemap' or
-- 
2.17.1

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

View/Reply Online (#140987): 
https://lists.openembedded.org/g/openembedded-core/message/140987
Mute This Topic: https://lists.openembedded.org/mt/75824494/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 04/18] rpm: fix nativesdk's default var location

[Steve Sakoman]

From: Chen Qi 

For now, the nativesdk-rpm's %_var in /usr/lib/rpm/macros is
'/var'. This is causing error when running `rpm -qplv A.rpm'.

   error: cannot open Packages index using db5 - Permission denied (13)
   error: cannot open Packages database in /var/lib/rpm

The rpm in SDK should be using its own database. So we should remove
this configure option, letting the SDK's native sysroot prefix to be
there in %_var. In fact, '%_usr' in macros has already got the prefix.
After this change, we have in the macros file lines like below.

"""
%_usr   
/opt/windriver/wrlinux/20.29/sysroots/x86_64-wrlinuxsdk-linux/usr
%_usrsrc%{_usr}/src
%_var   
/opt/windriver/wrlinux/20.29/sysroots/x86_64-wrlinuxsdk-linux/var
"""

Signed-off-by: Chen Qi 
Signed-off-by: Richard Purdie 
(cherry picked from commit 13e17930062cb3f816516ba7dbeb70d6da7174dd)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/rpm/rpm_4.14.2.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb 
b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
index 17255dc87a..4029217d08 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
@@ -70,7 +70,7 @@ EXTRA_OECONF_append_libc-musl = " --disable-nls"
 # Disable dbus for native, so that rpm doesn't attempt to inhibit shutdown via 
session dbus even when plugins support is enabled.
 # Also disable plugins by default for native.
 EXTRA_OECONF_append_class-native = " --sysconfdir=/etc --localstatedir=/var 
--disable-plugins"
-EXTRA_OECONF_append_class-nativesdk = " --sysconfdir=/etc --localstatedir=/var 
--disable-plugins"
+EXTRA_OECONF_append_class-nativesdk = " --sysconfdir=/etc --disable-plugins"
 
 BBCLASSEXTEND = "native nativesdk"
 
-- 
2.17.1

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

View/Reply Online (#140989): 
https://lists.openembedded.org/g/openembedded-core/message/140989
Mute This Topic: https://lists.openembedded.org/mt/75824498/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 01/18] wic/filemap: Drop the unused block_is_unmapped()

[Steve Sakoman]

From: Kevin Hao 

This method is not used by any code, so drop it.

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
(cherry picked from commit fb62a15349597ee026c67a0bb0a6ca2cc9bfe420)
Signed-off-by: Steve Sakoman 
---
 scripts/lib/wic/filemap.py | 17 -
 1 file changed, 17 deletions(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index c53147c2f1..8cfed5afa8 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -142,15 +142,6 @@ class _FilemapBase(object):
 
 raise Error("the method is not implemented")
 
-def block_is_unmapped(self, block): # pylint: disable=W0613,R0201
-"""
-This method has has to be implemented by child classes. It returns
-'True' if block number 'block' of the image file is not mapped (hole)
-and 'False' otherwise.
-"""
-
-raise Error("the method is not implemented")
-
 def get_mapped_ranges(self, start, count): # pylint: disable=W0613,R0201
 """
 This method has has to be implemented by child classes. This is a
@@ -265,10 +256,6 @@ class FilemapSeek(_FilemapBase):
 % (block, result))
 return result
 
-def block_is_unmapped(self, block):
-"""Refer the '_FilemapBase' class for the documentation."""
-return not self.block_is_mapped(block)
-
 def _get_ranges(self, start, count, whence1, whence2):
 """
 This function implements 'get_mapped_ranges()' and
@@ -422,10 +409,6 @@ class FilemapFiemap(_FilemapBase):
 % (block, result))
 return result
 
-def block_is_unmapped(self, block):
-"""Refer the '_FilemapBase' class for the documentation."""
-return not self.block_is_mapped(block)
-
 def _unpack_fiemap_extent(self, index):
 """
 Unpack a 'struct fiemap_extent' structure object number 'index' from
-- 
2.17.1

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

View/Reply Online (#140986): 
https://lists.openembedded.org/g/openembedded-core/message/140986
Mute This Topic: https://lists.openembedded.org/mt/75824492/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 09/18] oeqa/qemurunner: Add priority/nice information for running processes

[Steve Sakoman]

From: Richard Purdie 

We're seeing failures due to system load. In theory we've set process
nice levels which should compensate for this. Add debugging so we can
find out if they're being correctly applied.

Signed-off-by: Richard Purdie 
(cherry picked from commit 1e4e345bba8216b9b5623682206a7dae7cad261c)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/utils/qemurunner.py | 2 +-
 meta/lib/oeqa/utils/qemutinyrunner.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 01cbf52b8b..519aa9aa1e 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -264,7 +264,7 @@ class QemuRunner:
 % (self.runqemu.poll(), os.path.isfile(self.qemu_pidfile), 
str(qemu_pid), os.path.exists("/proc/" + str(qemu_pid
 
 # Dump all processes to help us to figure out what is going on...
-ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], 
stdout=subprocess.PIPE).communicate()[0]
+ps = subprocess.Popen(['ps', 'axww', '-o', 
'pid,ppid,pri,ni,command '], stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8")
 self.logger.debug("Running processes:\n%s" % processes)
 self._dump_host()
diff --git a/meta/lib/oeqa/utils/qemutinyrunner.py 
b/meta/lib/oeqa/utils/qemutinyrunner.py
index 364005bd2d..5c92941c0a 100644
--- a/meta/lib/oeqa/utils/qemutinyrunner.py
+++ b/meta/lib/oeqa/utils/qemutinyrunner.py
@@ -138,7 +138,7 @@ class QemuTinyRunner(QemuRunner):
 #
 # Walk the process tree from the process specified looking for a 
qemu-system. Return its [pid'cmd]
 #
-ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command'], 
stdout=subprocess.PIPE).communicate()[0]
+ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,pri,ni,command'], 
stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8").split('\n')
 nfields = len(processes[0].split()) - 1
 pids = {}
-- 
2.17.1

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

View/Reply Online (#140994): 
https://lists.openembedded.org/g/openembedded-core/message/140994
Mute This Topic: https://lists.openembedded.org/mt/75824506/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 15/18] busybox: make hwclock compatible with glibc 2.31

[Steve Sakoman]

From: Sakib Sajal 

settimeofday(2) has been deprecated as of glibc 2.31
which hwclock makes use of. This patch makes hwclock
compatible with glibc v2.31
See patch for more details:
  busybox/0001-hwclock-make-glibc-2.31-compatible.patch

Fixes [YOCTO #13981]

Signed-off-by: Sakib Sajal 
Signed-off-by: Steve Sakoman 
---
 ...1-hwclock-make-glibc-2.31-compatible.patch | 83 +++
 meta/recipes-core/busybox/busybox_1.31.1.bb   |  1 +
 2 files changed, 84 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-hwclock-make-glibc-2.31-compatible.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-hwclock-make-glibc-2.31-compatible.patch
 
b/meta/recipes-core/busybox/busybox/0001-hwclock-make-glibc-2.31-compatible.patch
new file mode 100644
index 00..0a141cebd5
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-hwclock-make-glibc-2.31-compatible.patch
@@ -0,0 +1,83 @@
+From 19a6baf0b79346deb383bbd2b5b825d59add7d5d Mon Sep 17 00:00:00 2001
+From: Sakib Sajal 
+Date: Fri, 17 Jul 2020 17:27:21 +
+Subject: [PATCH] hwclock: make glibc 2.31 compatible
+
+NEWS for glibc version 2.31
+===
+
+Deprecated and removed features, and other changes affecting compatibility:
+
+* The settimeofday function can still be used to set a system-wide
+  time zone when the operating system supports it.  This is because
+  the Linux kernel reused the API, on some architectures, to describe
+  a system-wide time-zone-like offset between the software clock
+  maintained by the kernel, and the "RTC" clock that keeps time when
+  the system is shut down.
+
+  However, to reduce the odds of this offset being set by accident,
+  settimeofday can no longer be used to set the time and the offset
+  simultaneously.  If both of its two arguments are non-null, the call
+  will fail (setting errno to EINVAL).
+
+  Callers attempting to set this offset should also be prepared for
+  the call to fail and set errno to ENOSYS; this already happens on
+  the Hurd and on some Linux architectures.  The Linux kernel
+  maintainers are discussing a more principled replacement for the
+  reused API.  After a replacement becomes available, we will change
+  settimeofday to fail with ENOSYS on all platforms when its 'tzp'
+  argument is not a null pointer.
+
+  settimeofday itself is obsolescent according to POSIX.  Programs
+  that set the system time should use clock_settime and/or the adjtime
+  family of functions instead.  We may cease to make settimeofday
+  available to newly linked binaries after there is a replacement for
+  Linux's time-zone-like offset API.
+
+hwclock had two calls to settimeofday, in functions to_sys_clock and
+set_system_clock_timezone, where both the arguments to settimeofday
+were valid (non-null).
+Therefore, split the call, once for timezone and once for timeval.
+
+Fixes #12756
+
+Upstream-Status: Pending
+
+Signed-off-by: Sakib Sajal 
+---
+ util-linux/hwclock.c | 12 
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/util-linux/hwclock.c b/util-linux/hwclock.c
+index 29f5102..088ab3b 100644
+--- a/util-linux/hwclock.c
 b/util-linux/hwclock.c
+@@ -131,8 +131,10 @@ static void to_sys_clock(const char **pp_rtcname, int utc)
+ 
+   tv.tv_sec = read_rtc(pp_rtcname, NULL, utc);
+   tv.tv_usec = 0;
+-  if (settimeofday(&tv, &tz))
+-  bb_perror_msg_and_die("settimeofday");
++  if (settimeofday(NULL, &tz))
++  bb_perror_msg_and_die("settimeofday: timezone");
++  if (settimeofday(&tv, NULL))
++  bb_perror_msg_and_die("settimeofday: timeval");
+ }
+ 
+ static void from_sys_clock(const char **pp_rtcname, int utc)
+@@ -283,8 +285,10 @@ static void set_system_clock_timezone(int utc)
+   gettimeofday(&tv, NULL);
+   if (!utc)
+   tv.tv_sec += tz.tz_minuteswest * 60;
+-  if (settimeofday(&tv, &tz))
+-  bb_perror_msg_and_die("settimeofday");
++  if (settimeofday(NULL, &tz))
++  bb_perror_msg_and_die("settimeofday: timezone");
++  if (settimeofday(&tv, NULL))
++  bb_perror_msg_and_die("settimeofday: timeval");
+ }
+ 
+ //usage:#define hwclock_trivial_usage
+-- 
+2.27.0
+
diff --git a/meta/recipes-core/busybox/busybox_1.31.1.bb 
b/meta/recipes-core/busybox/busybox_1.31.1.bb
index a6b47027af..7563368287 100644
--- a/meta/recipes-core/busybox/busybox_1.31.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.31.1.bb
@@ -49,6 +49,7 @@ SRC_URI = 
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://0001-Remove-stime-function-calls.patch \

file://0001-sysctl-ignore-EIO-of-stable_secret-below-proc-sys-ne.patch \
file://busybox-CVE-2018-1000500.patch \
+   file://0001-hwclock-make-glibc-2.31-compatible.patch \
 "
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
-- 
2.17.1

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

View/R

[OE-core][dunfell 08/18] linux-yocto-rt/5.4: fix mmdrop stress test issues

[Steve Sakoman]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.4:

508b4e6ada7f sched: Remove unexpected mmdrop on RT

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 
(cherry picked from commit 8500665cb8da792bb92a484e286f3935cf85e2b2)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
index 22a0dc997e..caa5b4ef53 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "a1e1e3cbe42d8a08de5a3e3daaa2b389e352fe77"
+SRCREV_machine ?= "508b4e6ada7f78b3ef5a9dbdd182d13dffe00123"
 SRCREV_meta ?= "caafbdfe382bf22a4786d871af097acd49d0867a"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
-- 
2.17.1

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

View/Reply Online (#140993): 
https://lists.openembedded.org/g/openembedded-core/message/140993
Mute This Topic: https://lists.openembedded.org/mt/75824505/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/18] Patch review

[Steve Sakoman]

Please review this next set of patches for dunfell and have comments back
by end of day Wednesday.

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-nut
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut

Ahmad Fatoum (1):
  core: glib-2.0: fix requested libmount/mkostemp/selinux not being
linked in

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 +
 ...ot-hardcode-linux-as-the-host-system.patch |  49 +
 meta/recipes-core/glib-2.0/glib-2.0_2.62.4.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 +++
 23 files changed, 630 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/glib-2.0/glib-2.0/0020-meson.build-do-not-hardcode-linux-as-the-host-system.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 (#140985): 
https://lists.openembedded.org/g/openembedded-core/message/140985
Mute This Topic: https://lists.openembedded.org/mt/75824491/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 03/18] wic/filemap: Fall back to standard copy when no way to get the block map

[Steve Sakoman]

From: Kevin Hao 

For some filesystems, such as aufs which may be used by docker container,
don't support either the SEEK_DATA/HOLE or FIEMAP to get the block
map. So add a FileNobmap class to fall back to standard copy when there
is no way to get the block map.

[Yocto #12988]

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
(cherry picked from commit 7934ed49179242f15b413c0275040a3bb6b68876)
Signed-off-by: Steve Sakoman 
---
 scripts/lib/wic/filemap.py | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index f8c6e09d01..4d9da28172 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -469,6 +469,29 @@ class FilemapFiemap(_FilemapBase):
 % (first_prev, last_prev))
 yield (first_prev, last_prev)
 
+class FilemapNobmap(_FilemapBase):
+"""
+This class is used when both the 'SEEK_DATA/HOLE' and FIEMAP are not
+supported by the filesystem or kernel.
+"""
+
+def __init__(self, image, log=None):
+"""Refer the '_FilemapBase' class for the documentation."""
+
+# Call the base class constructor first
+_FilemapBase.__init__(self, image, log)
+self._log.debug("FilemapNobmap: initializing")
+
+def block_is_mapped(self, block):
+"""Refer the '_FilemapBase' class for the documentation."""
+return True
+
+def get_mapped_ranges(self, start, count):
+"""Refer the '_FilemapBase' class for the documentation."""
+self._log.debug("FilemapNobmap: get_mapped_ranges(%d,  %d(%d))"
+% (start, count, start + count - 1))
+yield (start, start + count -1)
+
 def filemap(image, log=None):
 """
 Create and return an instance of a Filemap class - 'FilemapFiemap' or
@@ -482,7 +505,10 @@ def filemap(image, log=None):
 try:
 return FilemapFiemap(image, log)
 except ErrorNotSupp:
-return FilemapSeek(image, log)
+try:
+return FilemapSeek(image, log)
+except ErrorNotSupp:
+return FilemapNobmap(image, log)
 
 def sparse_copy(src_fname, dst_fname, skip=0, seek=0,
 length=0, api=None):
-- 
2.17.1

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

View/Reply Online (#140988): 
https://lists.openembedded.org/g/openembedded-core/message/140988
Mute This Topic: https://lists.openembedded.org/mt/75824496/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 11/18] classes/package: Use HOST_OS for runtime dependencies

[Steve Sakoman]

From: Joshua Watt 

The code was using TARGET_OS to try and detect what type of OS the
packages would be running on, but this is incorrect. TARGET_OS is the OS
for which the package will generate output (e.g. GCC output target or
GDB debugging target). The OS where the package will run is the HOST_OS.
Note that HOST_OS only differs from TARGET_OS when doing a
canadian cross compile, and even then in our case only when doing so for
a non-Linux host (e.g. MinGW).

Fix the code to use HOST_OS instead.

Signed-off-by: Joshua Watt 
Signed-off-by: Richard Purdie 
(cherry picked from commit f284c5b2df220b520b025a59874e04ef4becd829)
Signed-off-by: Steve Sakoman 
---
 meta/classes/package.bbclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index d4c6a90e84..099d0459f3 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -950,7 +950,7 @@ python split_and_strip_files () {
 
 dvar = d.getVar('PKGD')
 pn = d.getVar('PN')
-targetos = d.getVar('TARGET_OS')
+hostos = d.getVar('HOST_OS')
 
 oldcwd = os.getcwd()
 os.chdir(dvar)
@@ -1105,7 +1105,7 @@ python split_and_strip_files () {
 if (d.getVar('INHIBIT_PACKAGE_DEBUG_SPLIT') != '1'):
 results = oe.utils.multiprocess_launch(splitdebuginfo, list(elffiles), 
d, extraargs=(dvar, debugdir, debuglibdir, debugappend, debugsrcdir, d))
 
-if debugsrcdir and not targetos.startswith("mingw"):
+if debugsrcdir and not hostos.startswith("mingw"):
 if (d.getVar('PACKAGE_DEBUG_STATIC_SPLIT') == '1'):
 results = oe.utils.multiprocess_launch(splitstaticdebuginfo, 
staticlibs, d, extraargs=(dvar, debugstaticdir, debugstaticlibdir, 
debugstaticappend, debugsrcdir, d))
 else:
@@ -1667,7 +1667,7 @@ python package_do_shlibs() {
 else:
 shlib_pkgs = packages.split()
 
-targetos = d.getVar('TARGET_OS')
+hostos = d.getVar('HOST_OS')
 
 workdir = d.getVar('WORKDIR')
 
@@ -1818,9 +1818,9 @@ python package_do_shlibs() {
 soname = None
 if cpath.islink(file):
 continue
-if targetos == "darwin" or targetos == "darwin8":
+if hostos == "darwin" or hostos == "darwin8":
 darwin_so(file, needed, sonames, renames, pkgver)
-elif targetos.startswith("mingw"):
+elif hostos.startswith("mingw"):
 mingw_dll(file, needed, sonames, renames, pkgver)
 elif os.access(file, os.X_OK) or lib_re.match(file):
 linuxlist.append(file)
-- 
2.17.1

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

View/Reply Online (#140996): 
https://lists.openembedded.org/g/openembedded-core/message/140996
Mute This Topic: https://lists.openembedded.org/mt/75824508/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] [v2][PATCH] cve-check: print warning if file is missing

[Richard Purdie]

On Mon, 2020-07-27 at 06:57 -0700, akuster808 wrote:
> 
> On 7/27/20 2:39 AM, Richard Purdie wrote:
> > On Sun, 2020-07-26 at 19:52 -0700, akuster wrote:
> > > If the "tmp/cve_check" file was not create as in the case for -c
> > > populate_sdk, just print a
> > > warning instead of dumping a trace back
> > > 
> > > ---
> > > v2] lets include the missing part of the patch
> > > 
> > > Signed-off-by: Armin Kuster 
> > > ---
> > >  meta/classes/cve-check.bbclass | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
> > > check.bbclass
> > > index 0889e7544aa..b16da9890af 100644
> > > --- a/meta/classes/cve-check.bbclass
> > > +++ b/meta/classes/cve-check.bbclass
> > > @@ -55,6 +55,10 @@ python cve_save_summary_handler () {
> > >  
> > >  cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
> > >  
> > > +if not os.path.isfile(cve_tmp_file):
> > > +bb.warn("File Not found: %s" % cve_tmp_file)
> > > +return
> > > +
> > A warning is something the user really needs to fix or take some
> > action
> > about. Is this a warning?
> Its actually an error in certail conditions. Do we want this to be
> silent or fail on 'populate_sdk'?

What are the "certain conditions"?

Should it not detect those conditions and error if they occur?

Showing a warning and asking the user to guess is not a good user
experience. I have no idea whether I should worry about the warning
above or not for example, so I doubt anyone else does either.

Cheers,

Richard

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

View/Reply Online (#140984): 
https://lists.openembedded.org/g/openembedded-core/message/140984
Mute This Topic: https://lists.openembedded.org/mt/75815509/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] [bitbake-devel] [yocto] Stable Warrior branch

[akuster]

Adrian,

On 7/21/20 1:53 AM, Richard Purdie wrote:
> On Tue, 2020-07-14 at 16:56 +0300, Adrian Bunk wrote:
>> On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
>>> Hello,
>>>
>>> The Warrior branch of Poky has had its last official dot release.
>>> It
>>> will be moving to Community support and EOL within 6 weeks if no
>>> one
>>> steps up.
>>> If someone is interested in taking on the responsibilities of
>>> maintaining the "Warrior" branch moving forward, please email this
>>> list.
>> I have an interest in keeping warrior branch alive in poky and meta-
>> oe,
>> and I'll take this responsibility since noone else seems to be
>> interested.

Are you still interested?

-armin
>>> Please look at the
>>> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what
>>> will
>>> be expected.
>> I have some ideas, but not yet a fixed plan how I will set this up.
> Ok. FWIW we are struggling a little with keeping the older releases
> building on the autobuilder as the workers change. We do have plans for
> handling this with buildtools but its not rolled out on the older
> autobuilder-helper branches.
>
> I do have work in progress working with Jeremy for thud
> (contrib/rpurdie/thud), much of which should apply to warrior too
> (contrib/rpurdie/warrior is a guess). I just really want to highlight
> that there may be some initial work to get these older branches to the
> point where they continue to work on the infrastructure.
>
> I think we may have to accept backporting a lot of patches in helper to
> bring things more into sync with master/dunfell to make all this easier
> to maintain/get working.
>
> Cheers,
>
> Richard
>

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

View/Reply Online (#140983): 
https://lists.openembedded.org/g/openembedded-core/message/140983
Mute This Topic: https://lists.openembedded.org/mt/75699866/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] [v2][PATCH] cve-check: print warning if file is missing

[akuster]

On 7/27/20 2:39 AM, Richard Purdie wrote:
> On Sun, 2020-07-26 at 19:52 -0700, akuster wrote:
>> If the "tmp/cve_check" file was not create as in the case for -c
>> populate_sdk, just print a
>> warning instead of dumping a trace back
>>
>> ---
>> v2] lets include the missing part of the patch
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  meta/classes/cve-check.bbclass | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
>> check.bbclass
>> index 0889e7544aa..b16da9890af 100644
>> --- a/meta/classes/cve-check.bbclass
>> +++ b/meta/classes/cve-check.bbclass
>> @@ -55,6 +55,10 @@ python cve_save_summary_handler () {
>>  
>>  cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
>>  
>> +if not os.path.isfile(cve_tmp_file):
>> +bb.warn("File Not found: %s" % cve_tmp_file)
>> +return
>> +
> A warning is something the user really needs to fix or take some action
> about. Is this a warning?
Its actually an error in certail conditions. Do we want this to be
silent or fail on 'populate_sdk'?
>
> Cheers,
>
> Richard
>
>
>


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

View/Reply Online (#140982): 
https://lists.openembedded.org/g/openembedded-core/message/140982
Mute This Topic: https://lists.openembedded.org/mt/75815509/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 v6] Add package managers as a plugin

[Richard Purdie]

On Fri, 2020-07-24 at 16:42 +0200, Fredrik Gustafsson wrote:
> OE-core today has three different package managers, the well-known formats deb
> and rpm is supported as well as ipkg that is good for embedded devices.
> 
> When building and having a good cache hit, a significant amount of time is
> spent in the phase of generating a rootfs, which is really about the
> performance of the package manager. To save build time and also get a
> package manager that is suitanle for use on targets where flash memory is a
> concern, support for apk is suggested.
> 
> However, it might or might not be what's wanted for OE-core since it increases
> the test matrix. Therefore I will refactor the package management code to
> allow a layer to add a new package manager without editing the meta layer.
> 
> This refactor will be divided into multiple patch series to be easier to 
> review,
> this series will only move code but keep existing functionality.
> 
> Changes since v5:
> * Moved code in package_manager/rpm/package_manager.py to 
> package_manager/rpm/__init__.py
> * Fixed places that used package_managers instead of package_manager
> * Added missing imports in a function.

My first try at building this series failed to even parse on the
autobuilder. The second attempt has failed due to further bugs in these
changes. This is using a significant amount of my time and the
auobuilder's time to debug the series and makes me wonder how much
testing its had.

The changes do at least look like the right direction to change this
code in though. I've a bunch of fixes in master-next to try and make
the series work.

You mentioned being away for several weeks. If I merge this, where do
we stand if any other issues arise? Not sure I like the idea of waiting
several weeks to merge this either :(.

Cheers,

Richard



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

View/Reply Online (#140981): 
https://lists.openembedded.org/g/openembedded-core/message/140981
Mute This Topic: https://lists.openembedded.org/mt/75767459/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] llvm: upgrade 9.0.1 -> 10.0.1

[Trevor Gamblin]

Signed-off-by: Trevor Gamblin 
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 meta/recipes-devtools/llvm/llvm_git.bb  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 054985c6a4..caa5729512 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -26,7 +26,7 @@ QEMUVERSION ?= "5.0%"
 GOVERSION ?= "1.14%"
 # This can not use wildcards like 8.0.% since it is also used in mesa to denote
 # llvm version being used, so always bump it with llvm recipe version bump
-LLVMVERSION ?= "9.0.1"
+LLVMVERSION ?= "10.0.1"
 
 PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "${GCCVERSION}"
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb 
b/meta/recipes-devtools/llvm/llvm_git.bb
index d24ed761bf..4c2d490315 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -19,7 +19,7 @@ inherit cmake pkgconfig
 
 PROVIDES += "llvm${PV}"
 
-MAJOR_VERSION = "9"
+MAJOR_VERSION = "10"
 MINOR_VERSION = "0"
 PATCH_VERSION = "1"
 
@@ -29,7 +29,7 @@ LLVM_RELEASE = "${PV}"
 LLVM_DIR = "llvm${LLVM_RELEASE}"
 
 BRANCH = "release/${MAJOR_VERSION}.x"
-SRCREV = "c1a0a213378a458fbea1a5c77b315c7dce08fd05"
+SRCREV = "ef32c611aa214dea855364efd7ba451ec5ec3f74"
 SRC_URI = "git://github.com/llvm/llvm-project.git;branch=${BRANCH} \

file://0006-llvm-TargetLibraryInfo-Undefine-libc-functions-if-th.patch;striplevel=2
 \
file://0007-llvm-allow-env-override-of-exe-path.patch;striplevel=2 \
-- 
2.26.2

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

View/Reply Online (#140980): 
https://lists.openembedded.org/g/openembedded-core/message/140980
Mute This Topic: https://lists.openembedded.org/mt/75821511/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

[Richard Purdie]

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

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

View/Reply Online (#140979): 
https://lists.openembedded.org/g/openembedded-core/message/140979
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] meson: use the more specific cpu arch in cross file

[Ross Burton]

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 (#140978): 
https://lists.openembedded.org/g/openembedded-core/message/140978
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] [PATCH] adwaita-icon-theme: has a dependancy to gtk3+ add check

[Richard Purdie]

On Sun, 2020-07-26 at 11:21 -0700, akuster wrote:
> fixes:
> 
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'gtk+3' (but /.../poky/meta/recipes-
> gnome/gnome/adwaita-icon-theme_3.36.1.bb DEPENDS on or otherwise
> requires it)
> gtk+3 was skipped: one of 'wayland x11' needs to be in
> DISTRO_FEATURES
> 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-gnome/gnome/adwaita-icon-theme_3.36.1.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

There is a patch in master-next which I think supersedes this?

Cheers,

Richard

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

View/Reply Online (#140977): 
https://lists.openembedded.org/g/openembedded-core/message/140977
Mute This Topic: https://lists.openembedded.org/mt/75807632/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] [v2][PATCH] cve-check: print warning if file is missing

[Richard Purdie]

On Sun, 2020-07-26 at 19:52 -0700, akuster wrote:
> If the "tmp/cve_check" file was not create as in the case for -c
> populate_sdk, just print a
> warning instead of dumping a trace back
> 
> ---
> v2] lets include the missing part of the patch
> 
> Signed-off-by: Armin Kuster 
> ---
>  meta/classes/cve-check.bbclass | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
> check.bbclass
> index 0889e7544aa..b16da9890af 100644
> --- a/meta/classes/cve-check.bbclass
> +++ b/meta/classes/cve-check.bbclass
> @@ -55,6 +55,10 @@ python cve_save_summary_handler () {
>  
>  cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
>  
> +if not os.path.isfile(cve_tmp_file):
> +bb.warn("File Not found: %s" % cve_tmp_file)
> +return
> +

A warning is something the user really needs to fix or take some action
about. Is this a warning?

Cheers,

Richard



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

View/Reply Online (#140976): 
https://lists.openembedded.org/g/openembedded-core/message/140976
Mute This Topic: https://lists.openembedded.org/mt/75815509/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] json-c: update to 0.15

[Oleksandr Kravchuk]

Remove upstreamed patch.

Signed-off-by: Oleksandr Kravchuk 
---
 .../json-c/json-c/CVE-2020-12762.patch| 160 --
 .../json-c/{json-c_0.14.bb => json-c_0.15.bb} |   6 +-
 2 files changed, 2 insertions(+), 164 deletions(-)
 delete mode 100644 meta/recipes-devtools/json-c/json-c/CVE-2020-12762.patch
 rename meta/recipes-devtools/json-c/{json-c_0.14.bb => json-c_0.15.bb} (80%)

diff --git a/meta/recipes-devtools/json-c/json-c/CVE-2020-12762.patch 
b/meta/recipes-devtools/json-c/json-c/CVE-2020-12762.patch
deleted file mode 100644
index a45cfb61bc..00
--- a/meta/recipes-devtools/json-c/json-c/CVE-2020-12762.patch
+++ /dev/null
@@ -1,160 +0,0 @@
-From 099016b7e8d70a6d5dd814e788bba08d33d48426 Mon Sep 17 00:00:00 2001
-From: Tobias Stoeckmann 
-Date: Mon, 4 May 2020 19:41:16 +0200
-Subject: [PATCH 1/3] Protect array_list_del_idx against size_t overflow.
-
-If the assignment of stop overflows due to idx and count being
-larger than SIZE_T_MAX in sum, out of boundary access could happen.
-
-It takes invalid usage of this function for this to happen, but
-I decided to add this check so array_list_del_idx is as safe against
-bad usage as the other arraylist functions.
-
-Upstream-Status: Backport 
[https://github.com/json-c/json-c/commit/31243e4d1204ef78be34b0fcae73221eee6b83be]
-CVE: CVE-2020-12762
-Signed-off-by: Chee Yang Lee 
-

- arraylist.c | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/arraylist.c b/arraylist.c
-index 12ad8af6d3..e5524aca75 100644
 a/arraylist.c
-+++ b/arraylist.c
-@@ -136,6 +136,9 @@ int array_list_del_idx(struct array_list *arr, size_t idx, 
size_t count)
- {
-   size_t i, stop;
- 
-+  /* Avoid overflow in calculation with large indices. */
-+  if (idx > SIZE_T_MAX - count)
-+  return -1;
-   stop = idx + count;
-   if (idx >= arr->length || stop > arr->length)
-   return -1;
-
-From 77d935b7ae7871a1940cd827e850e6063044ec45 Mon Sep 17 00:00:00 2001
-From: Tobias Stoeckmann 
-Date: Mon, 4 May 2020 19:46:45 +0200
-Subject: [PATCH 2/3] Prevent division by zero in linkhash.
-
-If a linkhash with a size of zero is created, then modulo operations
-are prone to division by zero operations.
-
-Purely protective measure against bad usage.

- linkhash.c | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/linkhash.c b/linkhash.c
-index 7ea58c0abf..f05cc38030 100644
 a/linkhash.c
-+++ b/linkhash.c
-@@ -12,6 +12,7 @@
- 
- #include "config.h"
- 
-+#include 
- #include 
- #include 
- #include 
-@@ -499,6 +500,8 @@ struct lh_table *lh_table_new(int size, lh_entry_free_fn 
*free_fn, lh_hash_fn *h
-   int i;
-   struct lh_table *t;
- 
-+  /* Allocate space for elements to avoid divisions by zero. */
-+  assert(size > 0);
-   t = (struct lh_table *)calloc(1, sizeof(struct lh_table));
-   if (!t)
-   return NULL;
-
-From d07b91014986900a3a75f306d302e13e005e9d67 Mon Sep 17 00:00:00 2001
-From: Tobias Stoeckmann 
-Date: Mon, 4 May 2020 19:47:25 +0200
-Subject: [PATCH 3/3] Fix integer overflows.
-
-The data structures linkhash and printbuf are limited to 2 GB in size
-due to a signed integer being used to track their current size.
-
-If too much data is added, then size variable can overflow, which is
-an undefined behaviour in C programming language.
-
-Assuming that a signed int overflow just leads to a negative value,
-like it happens on many sytems (Linux i686/amd64 with gcc), then
-printbuf is vulnerable to an out of boundary write on 64 bit systems.

- linkhash.c |  7 +--
- printbuf.c | 19 ---
- 2 files changed, 21 insertions(+), 5 deletions(-)
-
-diff --git a/linkhash.c b/linkhash.c
-index f05cc38030..51e90b13a2 100644
 a/linkhash.c
-+++ b/linkhash.c
-@@ -580,9 +580,12 @@ int lh_table_insert_w_hash(struct lh_table *t, const void 
*k, const void *v, con
- {
-   unsigned long n;
- 
--  if (t->count >= t->size * LH_LOAD_FACTOR)
--  if (lh_table_resize(t, t->size * 2) != 0)
-+  if (t->count >= t->size * LH_LOAD_FACTOR) {
-+  /* Avoid signed integer overflow with large tables. */
-+  int new_size = INT_MAX / 2 < t->size ? t->size * 2 : INT_MAX;
-+  if (t->size == INT_MAX || lh_table_resize(t, new_size) != 0)
-   return -1;
-+  }
- 
-   n = h % t->size;
- 
-diff --git a/printbuf.c b/printbuf.c
-index 976c12dde5..00822fac4f 100644
 a/printbuf.c
-+++ b/printbuf.c
-@@ -15,6 +15,7 @@
- 
- #include "config.h"
- 
-+#include 
- #include 
- #include 
- #include 
-@@ -65,10 +66,16 @@ static int printbuf_extend(struct printbuf *p, int 
min_size)
- 
-   if (p->size >= min_size)
-   return 0;
--
--  new_size = p->size * 2;
--  if (new_size < min_size + 8)
-+  /* Prevent signed integer overflows with large buffers. */
-+  if (min_size > INT_MAX - 8)
-+  return -1;
-+  if (p->size > INT_MAX / 2)
-   new_size