[OE-core] [PATCH v3 2/2] systemd.bbclass: update command to check systemctl available

2020-12-01 Thread kai
From: Kai Kang 

When use a core image with systemd as docker image, it fails to
install/remove package which calls systemctl in post scripts.
It fails to run systemctl in a container:

bash-5.0# systemctl
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

So replace the criterion command 'type systemctl' with 'systemctl' in
package post scripts to check whether systemctl available.

Signed-off-by: Kai Kang 
---
 meta/classes/systemd.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 9e8a82c9f1..9ec465c759 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -23,7 +23,7 @@ python __anonymous() {
 }
 
 systemd_postinst() {
-if type systemctl >/dev/null 2>/dev/null; then
+if systemctl >/dev/null 2>/dev/null; then
OPTS=""
 
if [ -n "$D" ]; then
@@ -48,7 +48,7 @@ fi
 }
 
 systemd_prerm() {
-if type systemctl >/dev/null 2>/dev/null; then
+if systemctl >/dev/null 2>/dev/null; then
if [ -z "$D" ]; then
systemctl stop ${SYSTEMD_SERVICE_ESCAPED}
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145171): 
https://lists.openembedded.org/g/openembedded-core/message/145171
Mute This Topic: https://lists.openembedded.org/mt/78651238/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 v3 1/2] systemd-systemctl-native: capable to call without argument

2020-12-01 Thread kai
From: Kai Kang 

In systemd.bbclass, it will replace criterion command 'type systemctl'
with 'systemctl' without any argument to judge whether command systemctl
is available. The change is to fix install/remove package error in
container when command systemctl exists but not callable.

Make native systemctl wrapper prints help mesages if called without any
argument to follow the update.

Signed-off-by: Kai Kang 
---
 meta/recipes-core/systemd/systemd-systemctl/systemctl | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index 990de1ab39..de733e255b 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -282,7 +282,7 @@ def main():
 sys.exit("Python 3.4 or greater is required")
 
 parser = argparse.ArgumentParser()
-parser.add_argument('command', nargs=1, choices=['enable', 'mask',
+parser.add_argument('command', nargs='?', choices=['enable', 'mask',
  'preset-all'])
 parser.add_argument('service', nargs=argparse.REMAINDER)
 parser.add_argument('--root')
@@ -300,7 +300,11 @@ def main():
 locations.append(BASE_LIBDIR / "systemd")
 locations.append(LIBDIR / "systemd")
 
-command = args.command[0]
+command = args.command
+if not command:
+parser.print_help()
+return 0
+
 if command == "mask":
 for service in args.service:
 SystemdUnit(root, service).mask()
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145170): 
https://lists.openembedded.org/g/openembedded-core/message/145170
Mute This Topic: https://lists.openembedded.org/mt/78651237/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 v3 0/2] Update the criterion whether command systemctl available in systemd.bbclass

2020-12-01 Thread kai
From: Kai Kang 

v3:
* update commit messages to make more clearer

Kai Kang (2):
  systemd-systemctl-native: capable to call without argument
  systemd.bbclass: update command to check systemctl available

 meta/classes/systemd.bbclass  | 4 ++--
 meta/recipes-core/systemd/systemd-systemctl/systemctl | 8 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145169): 
https://lists.openembedded.org/g/openembedded-core/message/145169
Mute This Topic: https://lists.openembedded.org/mt/78651236/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 2/2] connman: set service to conflict with systemd-networkd

2020-12-01 Thread Yi Zhao


On 12/1/20 5:02 AM, Jack Mitchell wrote:

On 02/11/2020 09:20, Yi Zhao wrote:

Do not run systemd-networkd and connman simultaneously. These two
network managers may conflict with each other.

Signed-off-by: Yi Zhao 
---
  ...stop-systemd-networkd-when-using-con.patch | 29 +++
  .../connman/connman_1.38.bb   |  1 +
  2 files changed, 30 insertions(+)
  create mode 100644 
meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch

diff --git 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
 
b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
new file mode 100644
index 00..dd012750a4
--- /dev/null
+++ 
b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
@@ -0,0 +1,29 @@
+From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
+From: Yi Zhao 
+Date: Fri, 30 Oct 2020 13:48:45 +0800
+Subject: [PATCH] connman.service: stop systemd-networkd when using connman
+
+Stop systemd-networkd service when we use connman as network manager.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Yi Zhao 
+---
+ src/connman.service.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/connman.service.in b/src/connman.service.in
+index 79e75d6..014eafe 100644
+--- a/src/connman.service.in
 b/src/connman.service.in
+@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
+ After=dbus.service network-pre.target systemd-sysusers.service
+ Before=network.target multi-user.target shutdown.target
+ Wants=network.target
++Conflicts=systemd-networkd.service systemd-networkd.socket
+ Conflicts=systemd-resolved.service
+
+ [Service]
+--
+2.17.1
+
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
b/meta/recipes-connectivity/connman/connman_1.38.bb
index 027c41e9af..45c2934dec 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.38.bb
@@ -3,6 +3,7 @@ require connman.inc
  SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
 
file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \
 
file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
+   
file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
 file://connman \
 file://no-version-scripts.patch \
 "


Hi Yi,

This breaks our usecase where we have been using connman and
systemd-networkd in tandem for a long time. IMO this should be reverted
as if the two applications are conflicting then the correct fix is that
they should be configured so that they don't both try to configure the
same interfaces. As systemd-networkd doesn't ship with any rules by
default it shouldn't be doing anything to interfere?



Currently, A systemd-networkd configuration file 80-wired.network from 
systemd-conf package is also installed by default on HW BSPs. Comman is 
the default network-manager in Yocto. It will manage the wired interface 
automatically. But with this configuration file, the systemd-networkd 
will also try to manage the wired interface as connman does. They may 
conflict with each other.In addition to revert this patch, I think we 
should consider whether to install this configuration file by default. 
Maybe it’s better to install it as an example and users can enable it as 
needed.


Thanks,
Yi




With this patch I can no-longer run both services as it's a hard
conflict with no option to either revert locally, or bbappend this patch
out.

Regards,
Jack.




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145168): 
https://lists.openembedded.org/g/openembedded-core/message/145168
Mute This Topic: https://lists.openembedded.org/mt/77977444/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] meta/lib/oeqa/manual/oe-core.json: updated test test_bitbake_devshell

2020-12-01 Thread Sangeeta Jain
From: sangeeta jain 

updated command used for cross compilation to include ${CONFIGUREOPTS}
to ensure right arguments are passed for cross compiling on any host.

Signed-off-by: sangeeta jain 
---
 meta/lib/oeqa/manual/oe-core.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/manual/oe-core.json 
b/meta/lib/oeqa/manual/oe-core.json
index fb47c5e..4ad524d 100644
--- a/meta/lib/oeqa/manual/oe-core.json
+++ b/meta/lib/oeqa/manual/oe-core.json
@@ -80,7 +80,7 @@
   "expected_results": ""
 },
 "7": {
-  "action": "Run command:./configure && make ",
+  "action": "Run command:./configure ${CONFIGUREOPTS} && make ",
   "expected_results": "Verify that \"matchbox-desktop\" binary file 
was created successfully under \"src/\" directory "
 },
 "8": {
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145167): 
https://lists.openembedded.org/g/openembedded-core/message/145167
Mute This Topic: https://lists.openembedded.org/mt/78650804/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] menuconfig,mconf-cfg: Allow specification of ncurses location

2020-12-01 Thread Bruce Ashfield
On Tue, Dec 1, 2020 at 7:42 PM Scott Branden 
wrote:

> Hi Bruce,
>
> On 2020-12-01 11:01 a.m., Bruce Ashfield wrote:
> > On Tue, Dec 1, 2020 at 12:19 PM Scott Branden
> >  wrote:
> >> Hi Masahiro,
> >>
> >> On 2020-12-01 4:25 a.m., Masahiro Yamada wrote:
> >>> On Sat, Nov 28, 2020 at 9:45 AM Scott Branden
> >>>  wrote:
>  From: Bruce Ashfield 
> 
>  In some cross build environments such as the Yocto Project build
>  environment it provides an ncurses library that is compiled
>  differently than the host's version.  This causes display corruption
>  problems when the host's curses includes are used instead of the
>  includes from the provided compiler are overridden.  There is a second
>  case where there is no curses libraries at all on the host system and
>  menuconfig will just fail entirely.
> 
>  The solution is simply to allow an override variable in
>  check-lxdialog.sh for environments such as the Yocto Project.  Adding
>  a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
>  compiling and linking against the right headers and libraries.
> 
>  Signed-off-by: Jason Wessel 
>  cc: Michal Marek 
>  cc: linux-kbu...@vger.kernel.org
>  Signed-off-by: Bruce Ashfield 
>  Signed-off-by: Scott Branden 
>  ---
> >>> Some people solve the cross-compiling in Yocto
> >>> by using pkg-config.
> >>>
> >>>
> >>> For example,
> >>>
> >>> commit 067c650c456e758f933aaf87a202f841d34be269
> >>> Author: Pavel Modilaynen 
> >>> Date:   Fri Jul 12 13:52:19 2019 +0200
> >>>
> >>> dtc: Use pkg-config to locate libyaml
> >>>
> >>> Using Makefile's wildcard with absolute path to detect
> >>> the presence of libyaml results in false-positive
> >>> detection when cross-compiling e.g. in yocto environment.
> >>>
> >>>
> >>>
> >>> mconf-cfg.sh already allows the path flexibility with pkg-config.
> >>> Why do you want yet another hook?
> >> I hope the yocto community can provide more details on this patch.
> >> The yocto environment isolates the build environment from the host
> tools.
> >> Running menuconfig with the upstream kernel does not work on the latest
> yocto without this patch.
> > Sorry for not commenting on the origin patch, gmail buried it within
> > some other threads, but luckily this one popped up.
> >
> > It is true that we've been carrying this for several years to deal with
> > the fact that the native sysroot is not searched by the pkg-config
> > called by mconf-cfg.sh (since it is separate from host and target
> > pkg-config).
> >
> > As it turns out, in the past few weeks, we have come up with a way
> > to inject those native sysroot components into pkg-config without
> > the need for any changes to the scripts.
> >
> > Scott: if you try again the the latest oe-core, and are still seeing
> > the problem with the mainline kernel, ping me, and we can see if
> > the pkg-config fix isn't holding for you, at that point, yes, we may
> > still need a hook like this to solve the problem.
> Try reverting this kernel patch from linux-yocto and menuconfig will fail.
>

s/this/your/ ?

I'm continuing to carry it, since that tree is part of more than just yocto
builds so
it is needed for other reasons as well.



> menuconfig actually did work with the upstream kernel until the yocto
> change below was introduced:
> "cml1.bbclass: Handle ncurses-native being available via pkg-config"
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=ce447d70df386ca55ce1672478b245851556374e
>
>
That's the one I was referring to.

You need to take that up with the submitter of that change, since it has
broken
your workflow.

My change will indeed fix (mask) it, but considering that commit claims to
solve
the same problem, it should be root caused on the oe core mailing list.

Bruce



> > Cheers,
> >
> > Bruce
> >
> >
> >
>   scripts/kconfig/mconf-cfg.sh | 8 
>   1 file changed, 8 insertions(+)
>   mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
> 
>  diff --git a/scripts/kconfig/mconf-cfg.sh
> b/scripts/kconfig/mconf-cfg.sh
>  old mode 100755
>  new mode 100644
>  index aa68ec95620d..32448bc198a5
>  --- a/scripts/kconfig/mconf-cfg.sh
>  +++ b/scripts/kconfig/mconf-cfg.sh
>  @@ -4,6 +4,14 @@
>   PKG="ncursesw"
>   PKG2="ncurses"
> 
>  +if [ "$CROSS_CURSES_LIB" != "" ]; then
>  +echo libs=\'$CROSS_CURSES_LIB\'
>  +if [ x"$CROSS_CURSES_INC" != x ]; then
>  +   echo cflags=\'$CROSS_CURSES_INC\'
>  +fi
>  +exit 0
>  +fi
>  +
>   if [ -n "$(command -v pkg-config)" ]; then
>  if pkg-config --exists $PKG; then
>  echo cflags=\"$(pkg-config --cflags $PKG)\"
>  --
>  2.17.1
> 
> >
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=

[OE-core] [gatesgarth][PATCH 00/21] pull request (cover letter only)

2020-12-01 Thread Anuj Mittal
Please merge these changes in gatesgarth.

Thanks,

Anuj

The following changes since commit 12bee66a42a7c2a38789ddb37cb098bcbf0b3841:

  qemu: fix CVE-2020-24352 (2020-11-20 23:02:39 +0800)

are available in the Git repository at:

  git://push.openembedded.org/openembedded-core-contrib stable/gatesgarth-next

Alexander Kanavin (1):
  lttng-modules: update 2.12.2 -> 2.12.3

Anuj Mittal (2):
  glib-2.0: RDEPEND on dbusmock only when GI_DATA_ENABLED is True
  distutils-common-base: fix LINKSHARED expansion

Bruce Ashfield (4):
  linux-yocto/5.4: perf: Alias SYS_futex with SYS_futex_time64 on 32-bit
arches with 64bit time_t
  linux-yocto/5.8: perf: Alias SYS_futex with SYS_futex_time64 on 32-bit
arches with 64bit time_t
  linux-yocto/5.8: ext4/tipc warning fixups
  linux-yocto/5.4: update to v5.4.78

Fedor Ross (2):
  sysvinit: remove bashism to be compatible with dash
  eudev: remove bashism to be compatible with dash

He Zhe (1):
  lttng-modules: Backport a patch to fix btrfs build failure

INC@Cisco) (1):
  kernel-devsrc: improve reproducibility for arm64

Khem Raj (1):
  binutils: Fix linker errors on chromium/ffmpeg on aarch64

Richard Purdie (2):
  fs-perms: Ensure /usr/src/debug/ file modes are correct
  e2fsprogs: Fix a ptest permissions determinism issue

Ross Burton (5):
  cve-check: show real PN/PV
  python3: add CVE-2007-4559 to whitelist
  sqlite3: add CVE-2015-3717 to whitelist
  gstreamer1.0-rtsp-server: set CVE_PRODUCT
  gstreamer1.0-plugins-base: set CVE_PRODUCT

Stacy Gaikovaia (1):
  valgrind: helgrind: Intercept libc functions

Vyacheslav Yurkov (1):
  license_image.bbclass: use canonical name for license files

 meta/classes/cve-check.bbclass|   9 +-
 meta/classes/distutils-common-base.bbclass|   2 +-
 meta/classes/license_image.bbclass|   3 +-
 meta/classes/package.bbclass  |   2 +-
 meta/conf/abi_version.conf|   2 +-
 meta/files/fs-perms-persistent-log.txt|   2 +-
 meta/files/fs-perms.txt   |   2 +-
 meta/recipes-core/glib-2.0/glib.inc   |   2 +-
 meta/recipes-core/sysvinit/sysvinit/rc|   2 +-
 meta/recipes-core/udev/eudev/init |   2 +-
 .../binutils/binutils-2.35.inc|   1 +
 ...n-error-on-conditional-branch-to-an-.patch | 135 +++
 .../e2fsprogs/e2fsprogs_1.45.6.bb |   2 +
 meta/recipes-devtools/python/python3_3.8.5.bb |   2 +
 ...01-helgrind-Intercept-libc-functions.patch |  54 ++
 .../valgrind/valgrind_3.16.1.bb   |   1 +
 meta/recipes-kernel/linux/kernel-devsrc.bb|   4 +
 .../linux/linux-yocto-rt_5.4.bb   |   6 +-
 .../linux/linux-yocto-rt_5.8.bb   |   2 +-
 .../linux/linux-yocto-tiny_5.4.bb |   8 +-
 .../linux/linux-yocto-tiny_5.8.bb |   4 +-
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  |  22 +-
 meta/recipes-kernel/linux/linux-yocto_5.8.bb  |  18 +-
 ...ndency-issue-when-building-in-tree-w.patch |  54 --
 ...oints-output-proper-root-owner-for-t.patch | 318 ++
 ...ce.h-into-the-mmu-sub-directory-v5.9.patch |  41 -
 ...Make-kvm_mmu_page-definition-and-acc.patch |  39 -
 ...he-length-of-per-inode-prealloc-list.patch |  84 --
 ...e-via-a-block-bitmap-read-is-prefetc.patch |  63 --
 ...al-of-smp_-read_barrier_depends-v5.9.patch | 391 
 ...teback-Drop-I_DIRTY_TIME_EXPIRE-v5.9.patch |  59 --
 ...x-sync-livelock-due-to-b_dirty_time-.patch | 117 ---
 ...es-for-ext4_discard_preallocations-a.patch |  52 -
 .../0010-Fix-system-call-filter-table.patch   | 918 --
 ...ules_2.12.2.bb => lttng-modules_2.12.3.bb} |  13 +-
 .../gstreamer1.0-plugins-base_1.16.3.bb   |   2 +
 .../gstreamer1.0-rtsp-server_1.16.3.bb|   2 +
 meta/recipes-support/sqlite/sqlite3_3.33.0.bb |   2 +
 38 files changed, 571 insertions(+), 1871 deletions(-)
 create mode 100644 
meta/recipes-devtools/binutils/binutils/0001-aarch64-Return-an-error-on-conditional-branch-to-an-.patch
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-helgrind-Intercept-libc-functions.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Kconfig-fix-dependency-issue-when-building-in-tree-w.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-btrfs-tracepoints-output-proper-root-owner-for-t.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-Move-mmutrace.h-into-the-mmu-sub-directory-v5.9.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-fix-KVM-x86-mmu-Make-kvm_mmu_page-definition-and-acc.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-fix-ext4-limit-the-length-of-per-inode-prealloc-list.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-fix-ext4-indicate-via-a-block-bitmap-read-is-prefetc.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-fix-removal-of-smp_-read_barrier_depends-v5.9.patch
 delete mode 100644 
meta/recipes-

Re: [OE-core] [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location

2020-12-01 Thread Scott Branden via lists.openembedded.org
Hi Bruce,

On 2020-12-01 11:01 a.m., Bruce Ashfield wrote:
> On Tue, Dec 1, 2020 at 12:19 PM Scott Branden
>  wrote:
>> Hi Masahiro,
>>
>> On 2020-12-01 4:25 a.m., Masahiro Yamada wrote:
>>> On Sat, Nov 28, 2020 at 9:45 AM Scott Branden
>>>  wrote:
 From: Bruce Ashfield 

 In some cross build environments such as the Yocto Project build
 environment it provides an ncurses library that is compiled
 differently than the host's version.  This causes display corruption
 problems when the host's curses includes are used instead of the
 includes from the provided compiler are overridden.  There is a second
 case where there is no curses libraries at all on the host system and
 menuconfig will just fail entirely.

 The solution is simply to allow an override variable in
 check-lxdialog.sh for environments such as the Yocto Project.  Adding
 a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
 compiling and linking against the right headers and libraries.

 Signed-off-by: Jason Wessel 
 cc: Michal Marek 
 cc: linux-kbu...@vger.kernel.org
 Signed-off-by: Bruce Ashfield 
 Signed-off-by: Scott Branden 
 ---
>>> Some people solve the cross-compiling in Yocto
>>> by using pkg-config.
>>>
>>>
>>> For example,
>>>
>>> commit 067c650c456e758f933aaf87a202f841d34be269
>>> Author: Pavel Modilaynen 
>>> Date:   Fri Jul 12 13:52:19 2019 +0200
>>>
>>> dtc: Use pkg-config to locate libyaml
>>>
>>> Using Makefile's wildcard with absolute path to detect
>>> the presence of libyaml results in false-positive
>>> detection when cross-compiling e.g. in yocto environment.
>>>
>>>
>>>
>>> mconf-cfg.sh already allows the path flexibility with pkg-config.
>>> Why do you want yet another hook?
>> I hope the yocto community can provide more details on this patch.
>> The yocto environment isolates the build environment from the host tools.
>> Running menuconfig with the upstream kernel does not work on the latest 
>> yocto without this patch.
> Sorry for not commenting on the origin patch, gmail buried it within
> some other threads, but luckily this one popped up.
>
> It is true that we've been carrying this for several years to deal with
> the fact that the native sysroot is not searched by the pkg-config
> called by mconf-cfg.sh (since it is separate from host and target
> pkg-config).
>
> As it turns out, in the past few weeks, we have come up with a way
> to inject those native sysroot components into pkg-config without
> the need for any changes to the scripts.
>
> Scott: if you try again the the latest oe-core, and are still seeing
> the problem with the mainline kernel, ping me, and we can see if
> the pkg-config fix isn't holding for you, at that point, yes, we may
> still need a hook like this to solve the problem.
Try reverting this kernel patch from linux-yocto and menuconfig will fail.

menuconfig actually did work with the upstream kernel until the yocto change 
below was introduced:
"cml1.bbclass: Handle ncurses-native being available via pkg-config"
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=ce447d70df386ca55ce1672478b245851556374e

> Cheers,
>
> Bruce
>
>
>
  scripts/kconfig/mconf-cfg.sh | 8 
  1 file changed, 8 insertions(+)
  mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh

 diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
 old mode 100755
 new mode 100644
 index aa68ec95620d..32448bc198a5
 --- a/scripts/kconfig/mconf-cfg.sh
 +++ b/scripts/kconfig/mconf-cfg.sh
 @@ -4,6 +4,14 @@
  PKG="ncursesw"
  PKG2="ncurses"

 +if [ "$CROSS_CURSES_LIB" != "" ]; then
 +echo libs=\'$CROSS_CURSES_LIB\'
 +if [ x"$CROSS_CURSES_INC" != x ]; then
 +   echo cflags=\'$CROSS_CURSES_INC\'
 +fi
 +exit 0
 +fi
 +
  if [ -n "$(command -v pkg-config)" ]; then
 if pkg-config --exists $PKG; then
 echo cflags=\"$(pkg-config --cflags $PKG)\"
 --
 2.17.1

>



smime.p7s
Description: S/MIME Cryptographic Signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145164): 
https://lists.openembedded.org/g/openembedded-core/message/145164
Mute This Topic: https://lists.openembedded.org/mt/78639179/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 4/6] reproducible_build: clamp the rootfs tarball mtime to the epoch

2020-12-01 Thread Jate Sujjavanich
I have started using the following code to set the mtimes of files written
after the build timestamp. It assumes that SOURCE_DATE_EPOCH of packages
are never in the future.

# Set to empty to allow custom function below to run
REPRODUCIBLE_TIMESTAMP_ROOTFS ?= ""

# Use DATETIME of build as SOURCE_DATE_EPOCH for image
export SOURCE_DATE_EPOCH = "${@int( time.mktime( time.strptime('${DATETIME}',
'%Y%m%d%H%M%S') ) ) }"

reproducible_final_image_task () {
if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
# Use commit time of tuxzilla root in usual Syntux build
REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/../" log -1 --pretty=%ct
2>/dev/null`
if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y ${@bb.utils.which(d.getVar("BBPATH"),
"conf/bitbake.conf")}`
fi
fi
# Set mtime of all files to a reproducible value
bbnote "reproducible_final_image_task: mtime set to
$REPRODUCIBLE_TIMESTAMP_ROOTFS"
# Files with mtime after build stamp should be part of rootfs creation
DAYS_SINCE_BUILD=`python3 -c "import time; print((time.time() -
${SOURCE_DATE_EPOCH}) / 86400)"`
find ${IMAGE_ROOTFS} -mtime -$DAYS_SINCE_BUILD -exec touch -h --date=@
$REPRODUCIBLE_TIMESTAMP_ROOTFS {} \;
fi
}


On Tue, Dec 1, 2020 at 12:16 PM Ross Burton  wrote:

> On Tue, 1 Dec 2020 at 15:45, Richard Purdie
>  wrote:
> > I'm not convinced this is correct as it could mess up the timestamps of
> > stamps set in other recipes?
> >
> > It's also tar specific and should really be across all image types?
>
> Yes, it most likely should be done at rootfs time instead.
>
> Ross
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145163): 
https://lists.openembedded.org/g/openembedded-core/message/145163
Mute This Topic: https://lists.openembedded.org/mt/78635762/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 04/16] roofs_*.bbclass: fix missing vardeps for do_rootfs

2020-12-01 Thread Steve Sakoman
On Tue, Dec 1, 2020 at 8:59 AM Robert P. J. Day  wrote:
>
>
>   "roofs_*.bbclass"

Typos come along for free with a cherry-pick ;-)

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145162): 
https://lists.openembedded.org/g/openembedded-core/message/145162
Mute This Topic: https://lists.openembedded.org/mt/78641407/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] menuconfig,mconf-cfg: Allow specification of ncurses location

2020-12-01 Thread Bruce Ashfield
On Tue, Dec 1, 2020 at 12:19 PM Scott Branden
 wrote:
>
> Hi Masahiro,
>
> On 2020-12-01 4:25 a.m., Masahiro Yamada wrote:
> > On Sat, Nov 28, 2020 at 9:45 AM Scott Branden
> >  wrote:
> >> From: Bruce Ashfield 
> >>
> >> In some cross build environments such as the Yocto Project build
> >> environment it provides an ncurses library that is compiled
> >> differently than the host's version.  This causes display corruption
> >> problems when the host's curses includes are used instead of the
> >> includes from the provided compiler are overridden.  There is a second
> >> case where there is no curses libraries at all on the host system and
> >> menuconfig will just fail entirely.
> >>
> >> The solution is simply to allow an override variable in
> >> check-lxdialog.sh for environments such as the Yocto Project.  Adding
> >> a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
> >> compiling and linking against the right headers and libraries.
> >>
> >> Signed-off-by: Jason Wessel 
> >> cc: Michal Marek 
> >> cc: linux-kbu...@vger.kernel.org
> >> Signed-off-by: Bruce Ashfield 
> >> Signed-off-by: Scott Branden 
> >> ---
> >
> > Some people solve the cross-compiling in Yocto
> > by using pkg-config.
> >
> >
> > For example,
> >
> > commit 067c650c456e758f933aaf87a202f841d34be269
> > Author: Pavel Modilaynen 
> > Date:   Fri Jul 12 13:52:19 2019 +0200
> >
> > dtc: Use pkg-config to locate libyaml
> >
> > Using Makefile's wildcard with absolute path to detect
> > the presence of libyaml results in false-positive
> > detection when cross-compiling e.g. in yocto environment.
> >
> >
> >
> > mconf-cfg.sh already allows the path flexibility with pkg-config.
> > Why do you want yet another hook?
> I hope the yocto community can provide more details on this patch.
> The yocto environment isolates the build environment from the host tools.
> Running menuconfig with the upstream kernel does not work on the latest yocto 
> without this patch.

Sorry for not commenting on the origin patch, gmail buried it within
some other threads, but luckily this one popped up.

It is true that we've been carrying this for several years to deal with
the fact that the native sysroot is not searched by the pkg-config
called by mconf-cfg.sh (since it is separate from host and target
pkg-config).

As it turns out, in the past few weeks, we have come up with a way
to inject those native sysroot components into pkg-config without
the need for any changes to the scripts.

Scott: if you try again the the latest oe-core, and are still seeing
the problem with the mainline kernel, ping me, and we can see if
the pkg-config fix isn't holding for you, at that point, yes, we may
still need a hook like this to solve the problem.

Cheers,

Bruce



> >>  scripts/kconfig/mconf-cfg.sh | 8 
> >>  1 file changed, 8 insertions(+)
> >>  mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
> >>
> >> diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
> >> old mode 100755
> >> new mode 100644
> >> index aa68ec95620d..32448bc198a5
> >> --- a/scripts/kconfig/mconf-cfg.sh
> >> +++ b/scripts/kconfig/mconf-cfg.sh
> >> @@ -4,6 +4,14 @@
> >>  PKG="ncursesw"
> >>  PKG2="ncurses"
> >>
> >> +if [ "$CROSS_CURSES_LIB" != "" ]; then
> >> +echo libs=\'$CROSS_CURSES_LIB\'
> >> +if [ x"$CROSS_CURSES_INC" != x ]; then
> >> +   echo cflags=\'$CROSS_CURSES_INC\'
> >> +fi
> >> +exit 0
> >> +fi
> >> +
> >>  if [ -n "$(command -v pkg-config)" ]; then
> >> if pkg-config --exists $PKG; then
> >> echo cflags=\"$(pkg-config --cflags $PKG)\"
> >> --
> >> 2.17.1
> >>
> >
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145161): 
https://lists.openembedded.org/g/openembedded-core/message/145161
Mute This Topic: https://lists.openembedded.org/mt/78639179/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 04/16] roofs_*.bbclass: fix missing vardeps for do_rootfs

2020-12-01 Thread Robert P. J. Day

  "roofs_*.bbclass"

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145160): 
https://lists.openembedded.org/g/openembedded-core/message/145160
Mute This Topic: https://lists.openembedded.org/mt/78641407/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 16/16] e2fsprogs: Fix a ptest permissions determinism issue

2020-12-01 Thread Steve Sakoman
From: Richard Purdie 

When comparing builds built with different host umasks, this file jumped out.
The umask from do_compile was influencing ${D} and as cp was used to add the
file it wasn't deterministic. Fix the file mode to ensure determinism.

Signed-off-by: Richard Purdie 
(cherry picked from commit 37f37f4a52de3711973b372160f23672b61ff6ad)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
index 4f7cafeac9..439928e433 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
@@ -128,6 +128,8 @@ do_compile_ptest() {
 }
 
 do_install_ptest() {
+   # This file's permissions depends on the host umask so be deterministic
+   chmod 0644 ${B}/tests/test_data.tmp
cp -R --no-dereference --preserve=mode,links -v ${B}/tests 
${D}${PTEST_PATH}/test
cp -R --no-dereference --preserve=mode,links -v ${S}/tests/* 
${D}${PTEST_PATH}/test
sed -e 's!../e2fsck/e2fsck!e2fsck!g' \
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145159): 
https://lists.openembedded.org/g/openembedded-core/message/145159
Mute This Topic: https://lists.openembedded.org/mt/78641431/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/16] fs-perms: Ensure /usr/src/debug/ file modes are correct

2020-12-01 Thread Steve Sakoman
From: Richard Purdie 

If files are copied into /usr/src/debug directly from WORKDIR (e.g. makedevs)
we'd get the permissions from the checkout which would depend on the host umask.

Avoid this and be deterministic by setting the file modes consistently. Core
code copies the files in so we're responsible for the permissions.

Unfortunately to force this change to apply we need to invalidate both
the package tasks and the hash equivalance mappings since file mode
'corruption' already made it into the output hashes (both input options
were mapped to the output hashes).

Signed-off-by: Richard Purdie 
(cherry picked from commit 1f958bcd6c9cd12ec76d80586cba15f4d6ed17a7)
Signed-off-by: Steve Sakoman 
---
 meta/classes/package.bbclass   | 2 +-
 meta/conf/abi_version.conf | 2 +-
 meta/files/fs-perms-persistent-log.txt | 2 +-
 meta/files/fs-perms.txt| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cc64ddffc3..7c252dd46b 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2225,7 +2225,7 @@ python do_package () {
 # cache.  This is useful if an item this class depends on changes in a
 # way that the output of this class changes.  rpmdeps is a good example
 # as any change to rpmdeps requires this to be rerun.
-# PACKAGE_BBCLASS_VERSION = "2"
+# PACKAGE_BBCLASS_VERSION = "4"
 
 # Init cachedpath
 global cpath
diff --git a/meta/conf/abi_version.conf b/meta/conf/abi_version.conf
index 2bdc55695b..0a3fb307c8 100644
--- a/meta/conf/abi_version.conf
+++ b/meta/conf/abi_version.conf
@@ -12,4 +12,4 @@ OELAYOUT_ABI = "12"
 # a reset of the equivalence, for example when reproducibility issues break the
 # existing match data. Distros can also append to this value for the same 
effect.
 #
-HASHEQUIV_HASH_VERSION  = "1"
+HASHEQUIV_HASH_VERSION  = "4"
diff --git a/meta/files/fs-perms-persistent-log.txt 
b/meta/files/fs-perms-persistent-log.txt
index 3a7cf3ab94..518c1be3c9 100644
--- a/meta/files/fs-perms-persistent-log.txt
+++ b/meta/files/fs-perms-persistent-log.txt
@@ -41,7 +41,7 @@ ${includedir} 0755rootroottrue0644
rootroot
 ${oldincludedir}   0755rootroottrue0644rootroot
 
 # Cleanup debug src
-/usr/src/debug 0755rootroottrue-   rootroot
+/usr/src/debug 0755rootroottrue0644rootroot
 
 # Items from base-files
 # Links
diff --git a/meta/files/fs-perms.txt b/meta/files/fs-perms.txt
index c8c3ac5dbe..daa4aed840 100644
--- a/meta/files/fs-perms.txt
+++ b/meta/files/fs-perms.txt
@@ -41,7 +41,7 @@ ${includedir} 0755rootroottrue0644
rootroot
 ${oldincludedir}   0755rootroottrue0644rootroot
 
 # Cleanup debug src
-/usr/src/debug 0755rootroottrue-   rootroot
+/usr/src/debug 0755rootroottrue0644rootroot
 
 # Items from base-files
 # Links
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145158): 
https://lists.openembedded.org/g/openembedded-core/message/145158
Mute This Topic: https://lists.openembedded.org/mt/78641430/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 14/16] eudev: remove bashism to be compatible with dash

2020-12-01 Thread Steve Sakoman
From: Fedor Ross 

Remove 'echo -e' and replace it with 'printf'. In bash the builtin
'echo' has an option for interpreting backslash escapes. In a shell like
dash the builtin 'echo' interprets backslash escapes by default.
Therefor the 'echo' in dash doesn't have the '-e' option. When using
'printf' instead it is safe to use it either with bash or dash.

Signed-off-by: Fedor Ross 
Signed-off-by: Richard Purdie 
(cherry picked from commit c747acca33f84879a1ebd0ef972c07f4d5dff8b7)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/udev/eudev/init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/udev/eudev/init 
b/meta/recipes-core/udev/eudev/init
index 0455ade258..c60dbbf6d5 100644
--- a/meta/recipes-core/udev/eudev/init
+++ b/meta/recipes-core/udev/eudev/init
@@ -52,7 +52,7 @@ case "$1" in
 kill_udevd > "/dev/null" 2>&1
 
 # trigger the sorted events
-[ -e /proc/sys/kernel/hotplug ] && echo -e '\000' >/proc/sys/kernel/hotplug
+[ -e /proc/sys/kernel/hotplug ] && printf '\0\n' >/proc/sys/kernel/hotplug
 @UDEVD@ -d
 
 udevadm control --env=STARTUP=1
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145156): 
https://lists.openembedded.org/g/openembedded-core/message/145156
Mute This Topic: https://lists.openembedded.org/mt/78641427/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/16] distutils-common-base: fix LINKSHARED expansion

2020-12-01 Thread Steve Sakoman
From: Anuj Mittal 

Add the missing $ so SECURITY_CFLAGS actually gets expanded.

Signed-off-by: Anuj Mittal 
Signed-off-by: Richard Purdie 
(cherry picked from commit 6ed2f892ebb0b4e30a3bf167eac68027ea378a2d)
Signed-off-by: Steve Sakoman 
---
 meta/classes/distutils-common-base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/distutils-common-base.bbclass 
b/meta/classes/distutils-common-base.bbclass
index 94b5fd426d..43a38e5a3a 100644
--- a/meta/classes/distutils-common-base.bbclass
+++ b/meta/classes/distutils-common-base.bbclass
@@ -11,7 +11,7 @@ export LDCXXSHARED  = "${CXX} -shared"
 export CCSHARED  = "-fPIC -DPIC"
 # LINKFORSHARED are the flags passed to the $(CC) command that links
 # the python executable
-export LINKFORSHARED = "{SECURITY_CFLAGS} -Xlinker -export-dynamic"
+export LINKFORSHARED = "${SECURITY_CFLAGS} -Xlinker -export-dynamic"
 
 FILES_${PN} += "${libdir}/* ${libdir}/${PYTHON_DIR}/*"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145157): 
https://lists.openembedded.org/g/openembedded-core/message/145157
Mute This Topic: https://lists.openembedded.org/mt/78641428/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/16] sysvinit: remove bashism to be compatible with dash

2020-12-01 Thread Steve Sakoman
From: Fedor Ross 

Replace the equality operator '==' with '=' inside of '[]' to be
compatible with bash and dash.

Signed-off-by: Fedor Ross 
Signed-off-by: Richard Purdie 
(cherry picked from commit b7f0ec6eafb35117eaf4eeef281162080f0ca79a)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/sysvinit/sysvinit/rc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit/rc 
b/meta/recipes-core/sysvinit/sysvinit/rc
index fd1fdd26ba..d0d3149821 100755
--- a/meta/recipes-core/sysvinit/sysvinit/rc
+++ b/meta/recipes-core/sysvinit/sysvinit/rc
@@ -63,7 +63,7 @@ startup() {
   stty onlcr 0>&1
 
   # Limit stack size for startup scripts
-  [ "$STACK_SIZE" == "" ] || ulimit -S -s $STACK_SIZE
+  [ "$STACK_SIZE" = "" ] || ulimit -S -s $STACK_SIZE
 
   # Now find out what the current and what the previous runlevel are.
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145155): 
https://lists.openembedded.org/g/openembedded-core/message/145155
Mute This Topic: https://lists.openembedded.org/mt/78641426/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/16] gstreamer1.0-plugins-base: set CVE_PRODUCT

2020-12-01 Thread Steve Sakoman
From: Ross Burton 

There are CVEs with the 'gst-plugins-base' product, so set that.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit ec0f0e5995ab498f50ad51ceb361784247614982)
Signed-off-by: Steve Sakoman 
---
 .../gstreamer/gstreamer1.0-plugins-base_1.16.3.bb   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.3.bb
index a4f4772c1c..9daaf7587e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.3.bb
@@ -97,3 +97,5 @@ def get_opengl_cmdline_list(switch_name, options, d):
 return '-D' + switch_name + '=' + ','.join(selected_options)
 else:
 return ''
+
+CVE_PRODUCT += "gst-plugins-base"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145154): 
https://lists.openembedded.org/g/openembedded-core/message/145154
Mute This Topic: https://lists.openembedded.org/mt/78641423/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/16] gstreamer1.0-rtsp-server: set CVE_PRODUCT

2020-12-01 Thread Steve Sakoman
From: Ross Burton 

There are CVEs with the 'gst-rtsp-server' product, so set that.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit eb5cbdead78d092733e783b09528b208efccac3d)
Signed-off-by: Steve Sakoman 
---
 .../gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb| 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb
index 5f1b1d44fa..ed51a5693e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb
@@ -29,3 +29,5 @@ GIR_MESON_DISABLE_FLAG = "disabled"
 
 # Starting with 1.8.0 gst-rtsp-server includes dependency-less plugins as well
 require gstreamer1.0-plugins-packaging.inc
+
+CVE_PRODUCT += "gst-rtsp-server"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145153): 
https://lists.openembedded.org/g/openembedded-core/message/145153
Mute This Topic: https://lists.openembedded.org/mt/78641420/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/16] sqlite3: add CVE-2015-3717 to whitelist

2020-12-01 Thread Steve Sakoman
As per https://groups.google.com/g/sqlite-dev/c/U7OjAbZO6LA this issue
is believed to be either iOS specific, or fixed in 3.8.9.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
 (cherry-picked from d11a2157befcfe40517140988dd26bf0ed7240b6)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-support/sqlite/sqlite3_3.31.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb 
b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
index c289affd60..877e80f5a3 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
@@ -19,3 +19,5 @@ SRC_URI[sha256sum] = 
"62284efebc05a76f909c580ffa5c008a7d22a1287285d68b7825a2b6b5
 
 # -19242 is only an issue in specific development branch commits
 CVE_CHECK_WHITELIST += "CVE-2019-19242"
+# This is believed to be iOS specific 
(https://groups.google.com/g/sqlite-dev/c/U7OjAbZO6LA)
+CVE_CHECK_WHITELIST += "CVE-2015-3717"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145152): 
https://lists.openembedded.org/g/openembedded-core/message/145152
Mute This Topic: https://lists.openembedded.org/mt/78641419/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 08/16] python3: add CVE-2007-4559 to whitelist

2020-12-01 Thread Steve Sakoman
From: Ross Burton 

This issue describes expected behaviour, do not use tarfile with
untrusted data.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit f4c22e83f2e68ff157da5ea1303acc2931d63f5f)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/python/python3_3.8.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3_3.8.2.bb 
b/meta/recipes-devtools/python/python3_3.8.2.bb
index 1d0b4cdb77..b4cce88e87 100644
--- a/meta/recipes-devtools/python/python3_3.8.2.bb
+++ b/meta/recipes-devtools/python/python3_3.8.2.bb
@@ -52,6 +52,8 @@ UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
 
 CVE_PRODUCT = "python"
 
+# Upstream consider this expected behaviour
+CVE_CHECK_WHITELIST += "CVE-2007-4559"
 # This is not exploitable when glibc has CVE-2016-10739 fixed.
 CVE_CHECK_WHITELIST += "CVE-2019-18348"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145151): 
https://lists.openembedded.org/g/openembedded-core/message/145151
Mute This Topic: https://lists.openembedded.org/mt/78641418/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/16] cve-check: show real PN/PV

2020-12-01 Thread Steve Sakoman
From: Ross Burton 

The output currently shows the remapped product and version fields,
which may not be the actual recipe name/version. As this report is about
recipes, use the real values.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit 18827d7f40db4a4f92680bd59ca655cca373ad65)
Signed-off-by: Steve Sakoman 
---
 meta/classes/cve-check.bbclass | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 17f64a8a9c..669da6c8e9 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -205,6 +205,9 @@ def check_cves(d, patched_cves):
 """
 from distutils.version import LooseVersion
 
+pn = d.getVar("PN")
+real_pv = d.getVar("PV")
+
 cves_unpatched = []
 # CVE_PRODUCT can contain more than one product (eg. curl/libcurl)
 products = d.getVar("CVE_PRODUCT").split()
@@ -214,7 +217,7 @@ def check_cves(d, patched_cves):
 pv = d.getVar("CVE_VERSION").split("+git")[0]
 
 # If the recipe has been whitlisted we return empty lists
-if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split():
+if pn in d.getVar("CVE_CHECK_PN_WHITELIST").split():
 bb.note("Recipe has been whitelisted, skipping check")
 return ([], [], [])
 
@@ -283,12 +286,12 @@ def check_cves(d, patched_cves):
 vulnerable = vulnerable_start or vulnerable_end
 
 if vulnerable:
-bb.note("%s-%s is vulnerable to %s" % (product, pv, cve))
+bb.note("%s-%s is vulnerable to %s" % (pn, real_pv, cve))
 cves_unpatched.append(cve)
 break
 
 if not vulnerable:
-bb.note("%s-%s is not vulnerable to %s" % (product, pv, cve))
+bb.note("%s-%s is not vulnerable to %s" % (pn, real_pv, cve))
 # TODO: not patched but not vulnerable
 patched_cves.add(cve)
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145150): 
https://lists.openembedded.org/g/openembedded-core/message/145150
Mute This Topic: https://lists.openembedded.org/mt/78641417/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 06/16] license_image.bbclass: use canonical name for license files

2020-12-01 Thread Steve Sakoman
From: Vyacheslav Yurkov 

When copying license files to the image rootfs, i.e to
/usr/share/common-licenses, a canonical name of a license should be
used, otherwise duplicated files end up in common-licenses directory.

For example, GPL-2.0 license according to conf/license.conf can be
referenced in recipes as GPL-2, GPLv2, and GPLv2.0. If a license name is
used directly, we end up with three files in the rootfs with the same
content. If a canonical name used instead, then each license gets copied
only once.

Signed-off-by: Vyacheslav Yurkov 
Signed-off-by: Richard Purdie 
(cherry picked from commit 670fe71dd18ea675f35581db4a61fda137f8bf00)
Signed-off-by: Steve Sakoman 
---
 meta/classes/license_image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index a8c72da3cb..acd8126f68 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -125,7 +125,6 @@ def write_license_files(d, license_manifest, pkg_dic, 
rootfs=True):
 
 licenses = os.listdir(pkg_license_dir)
 for lic in licenses:
-rootfs_license = os.path.join(rootfs_license_dir, lic)
 pkg_license = os.path.join(pkg_license_dir, lic)
 pkg_rootfs_license = os.path.join(pkg_rootfs_license_dir, 
lic)
 
@@ -144,6 +143,8 @@ def write_license_files(d, license_manifest, pkg_dic, 
rootfs=True):
 bad_licenses) == False:
 continue
 
+# Make sure we use only canonical name for the license 
file
+rootfs_license = os.path.join(rootfs_license_dir, 
"generic_%s" % generic_lic)
 if not os.path.exists(rootfs_license):
 oe.path.copyhardlink(pkg_license, rootfs_license)
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145149): 
https://lists.openembedded.org/g/openembedded-core/message/145149
Mute This Topic: https://lists.openembedded.org/mt/78641412/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/16] linux-firmware: rdepend on license for all nvidia packages

2020-12-01 Thread Steve Sakoman
From: Max Krummenacher 

Fixes commit 0671d04978 ("linux-firmware: package nvidia firmware")

Signed-off-by: Max Krummenacher 
Signed-off-by: Richard Purdie 
(cherry picked from commit 59789dea33629a96f0fe5646eb684aa131e167bf)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb
index 045f2647e0..93b9d5308a 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb
@@ -501,6 +501,7 @@ FILES_${PN}-nvidia-license = 
"${nonarch_base_libdir}/firmware/LICENCE.nvidia"
 
 RDEPENDS_${PN}-nvidia-gpu += "${PN}-nvidia-license"
 RDEPENDS_${PN}-nvidia-tegra += "${PN}-nvidia-license"
+RDEPENDS_${PN}-nvidia-tegra-k1 += "${PN}-nvidia-license"
 
 # For rtl
 LICENSE_${PN}-rtl8188 = "Firmware-rtlwifi_firmware"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145148): 
https://lists.openembedded.org/g/openembedded-core/message/145148
Mute This Topic: https://lists.openembedded.org/mt/78641408/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/16] roofs_*.bbclass: fix missing vardeps for do_rootfs

2020-12-01 Thread Steve Sakoman
From: Loic Domaigne 

As per lib/oe/rootfs.py and lib/oe/package_manager/???/__init__.py
the PACKAGE_FEED baseurl is defined as the joined paths of:
URIS/BASE_PATHS/ARCHS

Therefore, the do_rootfs task should depend furthermore on
PACKAGE_FEED_{BASE_PATHS,ARCHS} to properly retrigger a build if
the value changes.

Signed-off-by: Loic Domaigne (ljd) 
Signed-off-by: Richard Purdie 
(cherry picked from commit e5329464f5ebad909c4c9bd27a718bbd8f4cc221)
Signed-off-by: Steve Sakoman 
---
 meta/classes/rootfs_deb.bbclass | 2 +-
 meta/classes/rootfs_ipk.bbclass | 2 +-
 meta/classes/rootfs_rpm.bbclass | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/rootfs_deb.bbclass b/meta/classes/rootfs_deb.bbclass
index 2b93796a76..ef616da229 100644
--- a/meta/classes/rootfs_deb.bbclass
+++ b/meta/classes/rootfs_deb.bbclass
@@ -7,7 +7,7 @@ ROOTFS_PKGMANAGE = "dpkg apt"
 do_rootfs[depends] += "dpkg-native:do_populate_sysroot 
apt-native:do_populate_sysroot"
 do_populate_sdk[depends] += "dpkg-native:do_populate_sysroot 
apt-native:do_populate_sysroot bzip2-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_deb do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS 
PACKAGE_FEED_ARCHS"
 
 do_rootfs[lockfiles] += "${DEPLOY_DIR_DEB}/deb.lock"
 do_populate_sdk[lockfiles] += "${DEPLOY_DIR_DEB}/deb.lock"
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index e73d2bfdae..f1e0219732 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -11,7 +11,7 @@ ROOTFS_PKGMANAGE = "opkg ${EXTRAOPKGCONFIG}"
 do_rootfs[depends] += "opkg-native:do_populate_sysroot 
opkg-utils-native:do_populate_sysroot"
 do_populate_sdk[depends] += "opkg-native:do_populate_sysroot 
opkg-utils-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_ipk do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS 
PACKAGE_FEED_ARCHS"
 
 do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
 do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 51f89ea990..ae0f541c49 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -24,7 +24,7 @@ do_rootfs[depends] += "${RPMROOTFSDEPENDS}"
 do_populate_sdk[depends] += "${RPMROOTFSDEPENDS}"
 
 do_rootfs[recrdeptask] += "do_package_write_rpm do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS 
PACKAGE_FEED_ARCHS"
 
 python () {
 if d.getVar('BUILD_IMAGES_FROM_FEEDS'):
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145147): 
https://lists.openembedded.org/g/openembedded-core/message/145147
Mute This Topic: https://lists.openembedded.org/mt/78641407/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/16] kernel: Set proper LD in KERNEL_KCONFIG_COMMAND

2020-12-01 Thread Steve Sakoman
From: Wonmin Jung 

With 'ld-is-gold' and linux kernel 5.4 or later, menuconfig
task for kernel recipes will fail with:

$ bitbake -c menuconfig virtual/kernel
...
scripts/kconfig/mconf  Kconfig
scripts/Kconfig.include:43:  gold linker 'x86_64-poky-linux-ld' not supported
/OE/build/tmp/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:29:
 recipe for target 'menuconfig' failed
make[2]: *** [menuconfig] Error 1
/OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:606:
 recipe for target 'menuconfig' failed
make[1]: *** [menuconfig] Error 2
/OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:185:
 recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Command failed.

This is because that the KERNEL_LD variable already set in
kernel-arch.bbclass isn't used by do_menuconfig function of
cml1.bbclass.

To fix this issue specify LD variable while calling the kernel
menuconfig command through KERNEL_KCONFIG_COMMAND.

Signed-off-by: Wonmin Jung 
Signed-off-by: Richard Purdie 
(cherry picked from commit 1faf66ce0b1f8f5165277161e07e25e672370c3f)
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 700ba0ad8d..29afd791e9 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -569,7 +569,7 @@ addtask savedefconfig after do_configure
 
 inherit cml1
 
-KCONFIG_CONFIG_COMMAND_append = " HOSTLDFLAGS='${BUILD_LDFLAGS}'"
+KCONFIG_CONFIG_COMMAND_append = " LD='${KERNEL_LD}' 
HOSTLDFLAGS='${BUILD_LDFLAGS}'"
 
 EXPORT_FUNCTIONS do_compile do_install do_configure
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145146): 
https://lists.openembedded.org/g/openembedded-core/message/145146
Mute This Topic: https://lists.openembedded.org/mt/78641404/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/16] kernel: relocate copy of module.lds to module compilation task

2020-12-01 Thread Steve Sakoman
From: Bruce Ashfield 

There were two copies of this patch floating around, and the merged
variant has the copy in the wrong place.

module.lds is only created during modules_prepare, and that target is
not invoked during our main build of the kernel. We aren't about to
change the kernel build (there's no need), so we move the copy into
the compile_kernelmodules task. After that runs, we have module.lds
availble to copy.

This has been tested against clean kernel + out of tree module
builds, and the dependencies are correct that the file is copied
before the out of tree module build starts.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 
(cherry picked from commit 7d94f9209ebaaf59ea001239a889dd7f928a0e7c)
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 58c9f171dc..700ba0ad8d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -358,6 +358,10 @@ do_compile_kernelmodules() {
# other kernel modules and will look at this
# file to do symbol lookups
cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
+   # 5.10+ kernels have module.lds that we need to copy for 
external module builds
+   if [ -e "${B}/scripts/module.lds" ]; then
+   install -Dm 0644 ${B}/scripts/module.lds 
${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
+   fi
else
bbnote "no modules to compile"
fi
@@ -465,7 +469,6 @@ do_shared_workdir () {
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
[ -e Module.symvers ] && cp Module.symvers $kerneldir/
-   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
$kerneldir/scripts/module.lds
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release 
$kerneldir/include/config/kernel.release
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145145): 
https://lists.openembedded.org/g/openembedded-core/message/145145
Mute This Topic: https://lists.openembedded.org/mt/78641402/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/16] kernel: provide module.lds for out of tree builds in v5.10+

2020-12-01 Thread Steve Sakoman
From: Bruce Ashfield 

The upstream commit 596b0474d3d [kbuild: preprocess module linker
script], adds a dependency on module.lds for external module
building.

Since module.lds is generated as part of 'modules_prepare', we
must make it available with the other kernel artifacts in the
kernel shared workdir, otherwise out of tree builds fail.

This fixes errors like:

| make[4]: *** No rule to make target 'scripts/module.lds', needed by

'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
Stop.
| make[4]: *** Waiting for unfinished jobs

We also ensure that kernel-devsrc has a copy to support on
target module builds that are often prepared with 'make scripts
prepare'. Those targets won't regenerate it, so the build fails.
If 'make modules_prepare' is used, the file will be regenerated
and overwrite our copy (as expected).

Signed-off-by: Pan, Kris 
Signed-off-by: Lili Li 
Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 
(cherry picked from commit 0fc66a0b64953aae38d0124b57615fffaec8de52)
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass| 1 +
 meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9e3c34ad48..58c9f171dc 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -465,6 +465,7 @@ do_shared_workdir () {
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
[ -e Module.symvers ] && cp Module.symvers $kerneldir/
+   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
$kerneldir/scripts/module.lds
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release 
$kerneldir/include/config/kernel.release
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 5940cc90ea..951e7635cc 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -86,6 +86,12 @@ do_install() {
# be dealt with.
# cp -a scripts $kerneldir/build
 
+   # although module.lds can be regenerated on target via 'make 
modules_prepare'
+   # there are several places where 'makes scripts prepare' is done, and 
that won't
+   # regenerate the file. So we copy it onto the target as a migration to 
using
+   # modules_prepare
+   cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
+
 if [ -d arch/${ARCH}/scripts ]; then
cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
fi
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145144): 
https://lists.openembedded.org/g/openembedded-core/message/145144
Mute This Topic: https://lists.openembedded.org/mt/78641399/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/16] Patch review

2020-12-01 Thread Steve Sakoman
Please review this next set of patches for dunfell and have comments back by
end of day Thursday.

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1638

The following changes since commit b885888df67eb5cdb3b82f4f0a07369a449e223b:

  build-appliance-image: Update to dunfell head revision (2020-11-25 23:25:31 
+)

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

Anuj Mittal (1):
  distutils-common-base: fix LINKSHARED expansion

Bruce Ashfield (2):
  kernel: provide module.lds for out of tree builds in v5.10+
  kernel: relocate copy of module.lds to module compilation task

Fedor Ross (2):
  sysvinit: remove bashism to be compatible with dash
  eudev: remove bashism to be compatible with dash

Loic Domaigne (1):
  roofs_*.bbclass: fix missing vardeps for do_rootfs

Max Krummenacher (1):
  linux-firmware: rdepend on license for all nvidia packages

Richard Purdie (2):
  fs-perms: Ensure /usr/src/debug/ file modes are correct
  e2fsprogs: Fix a ptest permissions determinism issue

Ross Burton (4):
  cve-check: show real PN/PV
  python3: add CVE-2007-4559 to whitelist
  gstreamer1.0-rtsp-server: set CVE_PRODUCT
  gstreamer1.0-plugins-base: set CVE_PRODUCT

Steve Sakoman (1):
  sqlite3: add CVE-2015-3717 to whitelist

Vyacheslav Yurkov (1):
  license_image.bbclass: use canonical name for license files

Wonmin Jung (1):
  kernel: Set proper LD in KERNEL_KCONFIG_COMMAND

 meta/classes/cve-check.bbclass   | 9 ++---
 meta/classes/distutils-common-base.bbclass   | 2 +-
 meta/classes/kernel.bbclass  | 6 +-
 meta/classes/license_image.bbclass   | 3 ++-
 meta/classes/package.bbclass | 2 +-
 meta/classes/rootfs_deb.bbclass  | 2 +-
 meta/classes/rootfs_ipk.bbclass  | 2 +-
 meta/classes/rootfs_rpm.bbclass  | 2 +-
 meta/conf/abi_version.conf   | 2 +-
 meta/files/fs-perms-persistent-log.txt   | 2 +-
 meta/files/fs-perms.txt  | 2 +-
 meta/recipes-core/sysvinit/sysvinit/rc   | 2 +-
 meta/recipes-core/udev/eudev/init| 2 +-
 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb  | 2 ++
 meta/recipes-devtools/python/python3_3.8.2.bb| 2 ++
 .../linux-firmware/linux-firmware_20201022.bb| 1 +
 meta/recipes-kernel/linux/kernel-devsrc.bb   | 6 ++
 .../gstreamer/gstreamer1.0-plugins-base_1.16.3.bb| 2 ++
 .../gstreamer/gstreamer1.0-rtsp-server_1.16.3.bb | 2 ++
 meta/recipes-support/sqlite/sqlite3_3.31.1.bb| 2 ++
 20 files changed, 40 insertions(+), 15 deletions(-)

-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145143): 
https://lists.openembedded.org/g/openembedded-core/message/145143
Mute This Topic: https://lists.openembedded.org/mt/78641398/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCHv3 5/5] wic: Pass canonicalized paths in PSEUDO_IGNORE_PATHS

2020-12-01 Thread Peter Kjellerstedt
Signed-off-by: Peter Kjellerstedt 
---
 scripts/lib/wic/partition.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index ebe250b00d..323a9580cc 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -207,11 +207,15 @@ class Partition():
 
 p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % native_sysroot)
 if (pseudo_dir):
+# Canonicalize the ignore paths. This corresponds to
+# calling oe.path.canonicalize(), which is used in bitbake.conf.
+ignore_paths = [rootfs] + (get_bitbake_var("PSEUDO_IGNORE_PATHS") 
or "").split(",")
+ignore_paths = ",".join(os.path.realpath(path) for path in 
ignore_paths if "$" not in path)
 pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
 pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % pseudo_dir
 pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
 pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
-pseudo += "export PSEUDO_IGNORE_PATHS=%s;" % (rootfs + "," + 
(get_bitbake_var("PSEUDO_IGNORE_PATHS") or ""))
+pseudo += "export PSEUDO_IGNORE_PATHS=%s;" % ignore_paths
 pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
 else:
 pseudo = None

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145142): 
https://lists.openembedded.org/g/openembedded-core/message/145142
Mute This Topic: https://lists.openembedded.org/mt/78640456/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCHv3 4/5] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

2020-12-01 Thread Peter Kjellerstedt
Use oe.path.canonicalize() to canonicalize the paths in
PSEUDO_IGNORE_PATHS before passing them to pseudo. This is needed since
pseudo will compare them to paths that are canonicalized.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/bitbake.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9742fe4fe2..a353dc5d6b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -691,9 +691,9 @@ export PSEUDO_DISABLED = "1"
 #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
 #export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
 #export PSEUDO_LIBDIR = "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
-FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native} 
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib 
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} PSEUDO_DISABLED=1"
+FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native} 
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib 
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))} 
PSEUDO_DISABLED=1"
 FAKEROOTCMD = "${PSEUDO_SYSROOT}${bindir_native}/pseudo"
-FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD} 
PSEUDO_NOSYMLINKEXP=1 PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} 
PSEUDO_DISABLED=0"
+FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD} 
PSEUDO_NOSYMLINKEXP=1 
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))} 
PSEUDO_DISABLED=0"
 FAKEROOTNOENV = "PSEUDO_UNLOAD=1"
 FAKEROOTDIRS = "${PSEUDO_LOCALSTATEDIR}"
 PREFERRED_PROVIDER_virtual/fakeroot-native ?= "pseudo-native"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145140): 
https://lists.openembedded.org/g/openembedded-core/message/145140
Mute This Topic: https://lists.openembedded.org/mt/78640453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCHv3 1/5] pseudo: Simplify pseudo_client_ignore_path_chroot()

2020-12-01 Thread Peter Kjellerstedt
This also plugs a memory leak in pseudo_client_ignore_path_chroot().

Signed-off-by: Peter Kjellerstedt 
---
 ...ssen-indentation-of-pseudo_client_ig.patch | 69 +++
 ...mplify-pseudo_client_ignore_path_chr.patch | 50 ++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  2 +
 3 files changed, 121 insertions(+)
 create mode 100644 
meta/recipes-devtools/pseudo/files/0002-pseudo_client-Lessen-indentation-of-pseudo_client_ig.patch
 create mode 100644 
meta/recipes-devtools/pseudo/files/0003-pseudo_client-Simplify-pseudo_client_ignore_path_chr.patch

diff --git 
a/meta/recipes-devtools/pseudo/files/0002-pseudo_client-Lessen-indentation-of-pseudo_client_ig.patch
 
b/meta/recipes-devtools/pseudo/files/0002-pseudo_client-Lessen-indentation-of-pseudo_client_ig.patch
new file mode 100644
index 00..e4a5356f5c
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0002-pseudo_client-Lessen-indentation-of-pseudo_client_ig.patch
@@ -0,0 +1,69 @@
+From 28c760542eecd7c5b35ea88aa2b14d62afbda961 Mon Sep 17 00:00:00 2001
+From: Peter Kjellerstedt 
+Date: Sat, 21 Nov 2020 17:22:38 +0100
+Subject: [PATCH] pseudo_client: Lessen indentation of
+ pseudo_client_ignore_path_chroot()
+
+Change-Id: I739b18efb7a95ce2d2d907d0faf7df539ab9af1c
+---
+ pseudo_client.c | 45 +
+ 1 file changed, 25 insertions(+), 20 deletions(-)
+
+diff --git a/pseudo_client.c b/pseudo_client.c
+index 116d926..a8bc3dc 100644
+--- a/pseudo_client.c
 b/pseudo_client.c
+@@ -1527,28 +1527,33 @@ int pseudo_client_ignore_fd(int fd) {
+ 
+ int pseudo_client_ignore_path_chroot(const char *path, int ignore_chroot) {
+   char *env;
+-  if (path) {
+-  if (ignore_chroot && pseudo_chroot && strncmp(path, 
pseudo_chroot, pseudo_chroot_len) == 0)
+-  return 0;
+-  env = pseudo_get_value("PSEUDO_IGNORE_PATHS");
+-  if (env) {
+-  char *p = env;
+-  while (*p) {
+-  char *next = strchr(p, ',');
+-  if (!next)
+-  next = strchr(p, '\0');
+-  if ((next - p) && !strncmp(path, p, next - p)) {
+-  pseudo_debug(PDBGF_PATH | 
PDBGF_VERBOSE, "ignoring path: '%s'\n", path);
+-  return 1;
+-  }
+-  if (next && *next != '\0')
+-  p = next+1;
+-  else
+-  break;
+-  }
+-  free(env);
++
++  if (!path)
++  return 0;
++
++  if (ignore_chroot && pseudo_chroot && strncmp(path, pseudo_chroot, 
pseudo_chroot_len) == 0)
++  return 0;
++
++  env = pseudo_get_value("PSEUDO_IGNORE_PATHS");
++  if (!env)
++  return 0;
++
++  char *p = env;
++  while (*p) {
++  char *next = strchr(p, ',');
++  if (!next)
++  next = strchr(p, '\0');
++  if ((next - p) && !strncmp(path, p, next - p)) {
++  pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE, "ignoring 
path: '%s'\n", path);
++  return 1;
+   }
++  if (next && *next != '\0')
++  p = next+1;
++  else
++  break;
+   }
++  free(env);
++
+   return 0;
+ }
+ 
diff --git 
a/meta/recipes-devtools/pseudo/files/0003-pseudo_client-Simplify-pseudo_client_ignore_path_chr.patch
 
b/meta/recipes-devtools/pseudo/files/0003-pseudo_client-Simplify-pseudo_client_ignore_path_chr.patch
new file mode 100644
index 00..a657a27f28
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0003-pseudo_client-Simplify-pseudo_client_ignore_path_chr.patch
@@ -0,0 +1,50 @@
+From a1d61d68777373a50ae23b9dd83b428abe2f748d Mon Sep 17 00:00:00 2001
+From: Peter Kjellerstedt 
+Date: Sat, 21 Nov 2020 17:30:33 +0100
+Subject: [PATCH] pseudo_client: Simplify pseudo_client_ignore_path_chroot()
+
+This also plugs a memory leak by making sure env is freed.
+
+Change-Id: Ia8635fd2c6b1e85919e4743713a85e0b52c28fac
+---
+ pseudo_client.c | 21 ++---
+ 1 file changed, 10 insertions(+), 11 deletions(-)
+
+diff --git a/pseudo_client.c b/pseudo_client.c
+index a8bc3dc..7dc0345 100644
+--- a/pseudo_client.c
 b/pseudo_client.c
+@@ -1538,23 +1538,22 @@ int pseudo_client_ignore_path_chroot(const char *path, 
int ignore_chroot) {
+   if (!env)
+   return 0;
+ 
++  int ret = 0;
+   char *p = env;
+-  while (*p) {
++  while (p) {
+   char *next = strchr(p, ',');
+-  if (!next)
+-  next = strchr(p, '\0');
+-  if ((next - p) && !strncmp(path, p, next - p)) {
+-  pseudo_debug(PDBGF_PATH | PDB

[OE-core] [PATCHv3 2/5] bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS

2020-12-01 Thread Peter Kjellerstedt
Instead of ignoring ${COREBASE}/meta in PSEUDO_IGNORE_PATHS (which may
or may not ignore all layers depending on how they are named and placed
under ${COREBASE}), ignore all layers.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0d38eac094..9742fe4fe2 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -685,7 +685,7 @@ SRC_URI = ""
 PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
 PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
 PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
-PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${COREBASE}/meta,${CCACHE_DIR}"
+PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${@','.join(d.getVar('BBLAYERS').split())},${CCACHE_DIR}"
 
 export PSEUDO_DISABLED = "1"
 #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145141): 
https://lists.openembedded.org/g/openembedded-core/message/145141
Mute This Topic: https://lists.openembedded.org/mt/78640454/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCHv3 3/5] lib/oe/path: Add canonicalize()

2020-12-01 Thread Peter Kjellerstedt
oe.path.canonicalize() is used to canonicalize paths (i.e., remove
symbolic links and "..", and make them absolute). It takes a string
with paths separated by commas, and returns the canonicalized path in
the same format.

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

diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
index 082972457b..504342e267 100644
--- a/meta/lib/oe/path.py
+++ b/meta/lib/oe/path.py
@@ -320,3 +320,15 @@ def which_wild(pathname, path=None, mode=os.F_OK, *, 
reverse=False, candidates=F
 
 return files
 
+def canonicalize(paths, sep=','):
+"""Given a string with paths (separated by commas by default), expand
+each path using os.path.realpath() and return the resulting paths as a
+string (separated using the same separator a the original string).
+"""
+# Ignore paths containing "$" as they are assumed to be unexpanded bitbake
+# variables. Normally they would be ignored, e.g., when passing the paths
+# through the shell they would expand to empty strings. However, when they
+# are passed through os.path.realpath(), it will cause them to be prefixed
+# with the absolute path to the current directory and thus not be empty
+# anymore.
+return sep.join(os.path.realpath(path) for path in (paths or 
'').split(sep) if "$" not in path)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145138): 
https://lists.openembedded.org/g/openembedded-core/message/145138
Mute This Topic: https://lists.openembedded.org/mt/78640450/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCHv3 0/5] Support symbolic links in paths in PSEUDO_IGNORE_PATHS

2020-12-01 Thread Peter Kjellerstedt
The changes in this patch series aim to rectify a problem with pseudo
and its support for ignoring paths. When pseudo compares a path to the
paths specified in PSEUDO_IGNORE_PATHS, it uses a path that has been
canonicalized. However, it does not canonicalize the paths in
PSEUDO_IGNORE_PATHS itself and unless they are canonicalized, they
will not match as intended. Thus the paths in PSEUDO_IGNORE_PATHS
needs to be canonicalized. These patches do that by adding a new
function oe.path.canonicalize(), which is then used when passing 
${PSEUDO_IGNORE_PATHS} to pseudo.

There is also one patch that adds two patches to pseudo to clean up
pseudo_client_ignore_path_chroot(), and they also plug a memory leak.
The patches were brought about as I initially intended to do the
canonicalization in pseudo itself in this function.

I have not tested the change to wic as we do not use it, though I do
not expect it to be problematic.

PATCHv2: 
  * Removed some unrelated changes in the second patch.
PATCHv3: 
  * Handle an edge case in pseudo_client_ignore_path_chroot() in case
PSEUDO_IGNORE_PATHS contains ",," or leading/trailing commas.
  * Introduce oe.path.canonicalize() and use it instead of adding
PSEUDO_IGNORE_REAL_PATHS as was previously done.
  * Add similar code to wic.

//Peter

The following changes since commit 0ac99625bf2c8a19d4ee746dc13e9c6b2e1956e2:

  python3-numpy: Add ptest (2020-11-30 14:42:22 +)

are available in the Git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/pseudo-ignore

Peter Kjellerstedt (5):
  pseudo: Simplify pseudo_client_ignore_path_chroot()
  bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
  lib/oe/path: Add canonicalize()
  bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS
  wic: Pass canonicalized paths in PSEUDO_IGNORE_PATHS

 meta/conf/bitbake.conf|  6 +-
 meta/lib/oe/path.py   | 12 
 ...ssen-indentation-of-pseudo_client_ig.patch | 69 +++
 ...mplify-pseudo_client_ignore_path_chr.patch | 50 ++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  2 +
 scripts/lib/wic/partition.py  |  6 +-
 6 files changed, 141 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/pseudo/files/0002-pseudo_client-Lessen-indentation-of-pseudo_client_ig.patch
 create mode 100644 
meta/recipes-devtools/pseudo/files/0003-pseudo_client-Simplify-pseudo_client_ignore_path_chr.patch


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145137): 
https://lists.openembedded.org/g/openembedded-core/message/145137
Mute This Topic: https://lists.openembedded.org/mt/78640449/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] menuconfig,mconf-cfg: Allow specification of ncurses location

2020-12-01 Thread Scott Branden via lists.openembedded.org
Hi Masahiro,

On 2020-12-01 4:25 a.m., Masahiro Yamada wrote:
> On Sat, Nov 28, 2020 at 9:45 AM Scott Branden
>  wrote:
>> From: Bruce Ashfield 
>>
>> In some cross build environments such as the Yocto Project build
>> environment it provides an ncurses library that is compiled
>> differently than the host's version.  This causes display corruption
>> problems when the host's curses includes are used instead of the
>> includes from the provided compiler are overridden.  There is a second
>> case where there is no curses libraries at all on the host system and
>> menuconfig will just fail entirely.
>>
>> The solution is simply to allow an override variable in
>> check-lxdialog.sh for environments such as the Yocto Project.  Adding
>> a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
>> compiling and linking against the right headers and libraries.
>>
>> Signed-off-by: Jason Wessel 
>> cc: Michal Marek 
>> cc: linux-kbu...@vger.kernel.org
>> Signed-off-by: Bruce Ashfield 
>> Signed-off-by: Scott Branden 
>> ---
>
> Some people solve the cross-compiling in Yocto
> by using pkg-config.
>
>
> For example,
>
> commit 067c650c456e758f933aaf87a202f841d34be269
> Author: Pavel Modilaynen 
> Date:   Fri Jul 12 13:52:19 2019 +0200
>
> dtc: Use pkg-config to locate libyaml
>
> Using Makefile's wildcard with absolute path to detect
> the presence of libyaml results in false-positive
> detection when cross-compiling e.g. in yocto environment.
>
>
>
> mconf-cfg.sh already allows the path flexibility with pkg-config.
> Why do you want yet another hook?
I hope the yocto community can provide more details on this patch.
The yocto environment isolates the build environment from the host tools.
Running menuconfig with the upstream kernel does not work on the latest yocto 
without this patch.
>>  scripts/kconfig/mconf-cfg.sh | 8 
>>  1 file changed, 8 insertions(+)
>>  mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
>>
>> diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
>> old mode 100755
>> new mode 100644
>> index aa68ec95620d..32448bc198a5
>> --- a/scripts/kconfig/mconf-cfg.sh
>> +++ b/scripts/kconfig/mconf-cfg.sh
>> @@ -4,6 +4,14 @@
>>  PKG="ncursesw"
>>  PKG2="ncurses"
>>
>> +if [ "$CROSS_CURSES_LIB" != "" ]; then
>> +echo libs=\'$CROSS_CURSES_LIB\'
>> +if [ x"$CROSS_CURSES_INC" != x ]; then
>> +   echo cflags=\'$CROSS_CURSES_INC\'
>> +fi
>> +exit 0
>> +fi
>> +
>>  if [ -n "$(command -v pkg-config)" ]; then
>> if pkg-config --exists $PKG; then
>> echo cflags=\"$(pkg-config --cflags $PKG)\"
>> --
>> 2.17.1
>>
>



smime.p7s
Description: S/MIME Cryptographic Signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145136): 
https://lists.openembedded.org/g/openembedded-core/message/145136
Mute This Topic: https://lists.openembedded.org/mt/78639179/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 4/6] reproducible_build: clamp the rootfs tarball mtime to the epoch

2020-12-01 Thread Ross Burton
On Tue, 1 Dec 2020 at 15:45, Richard Purdie
 wrote:
> I'm not convinced this is correct as it could mess up the timestamps of
> stamps set in other recipes?
>
> It's also tar specific and should really be across all image types?

Yes, it most likely should be done at rootfs time instead.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145135): 
https://lists.openembedded.org/g/openembedded-core/message/145135
Mute This Topic: https://lists.openembedded.org/mt/78635762/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 1/1] classes/kernel*: allow disabling symlink creation

2020-12-01 Thread Paul Eggleton
On Wednesday, 2 December 2020 05:22:43 NZDT Martin Jansa wrote:
> I see, I was just worried that this case will block me pushing the last bit
> of [YOCTO #12937] which changes symlinks to hardlinks:
> https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifact
> s
> 
> Which makes the use case you're fixing worse (as even less systems will
> correctly handle hardlinks), so I support the idea to disable having the
> links. My current work around is to just remove the unnecessary files when
> rsyncing to file-server.
> 
> But the main issue which I'm seeing with my current implementation (and
> with webos_deploy this is based on) is that we need the version-less
> artifacts to be available, because e.g. image recipe searching kernel
> artifact when there is DATETIME or SRCPV in the kernel artifact-name won't
> be able to find it, because the image might be built at different DATETIME
> and doesn't know anything about kernel SRCREV/SRCPV. To resolve this, the
> build is using the version-less artifacts (always the latest one).
> 
> I guess your implementation might fail in such DATETIME cases as well.
> 
> With separate variable to disable the links we can somehow work around this
> or at least warn user that without the version-less filenames, the
> VERSION_SUFFIX variable needs to be stable (as no PV/SRCPV/DATATIME in it).

That is a good point and we have the same problem here - what I'm planning to
do is to set a bunch of the other variables such that there are no versioned
artifacts - i.e. the real files effectively appear in place of the symlinks and
the versioned ones disappear. It seems to work in my tests so far. With my
patchset this is what I set:

 snip 
IMAGE_LINK_NAME = ""
IMAGE_VERSION_SUFFIX = ""
IMAGE_NAME_SUFFIX = ""
IMAGE_MANIFEST_distroname = 
"${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.manifest"

KERNEL_ARTIFACT_NAME = "${MACHINE}"
KERNEL_ARTIFACT_LINK_NAME = ""
 snip 

I have found that I still need the plain type named kernel artifacts (e.g. 
vmlinux),
and since these don't actually use the link name variable I have changed those 
to
be written out even if the link name is blank (v2 patchset still in testing). 
We could
introduce another variable to disable those but I hadn't planned to do that
for the moment.

Cheers,
Paul




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145134): 
https://lists.openembedded.org/g/openembedded-core/message/145134
Mute This Topic: https://lists.openembedded.org/mt/78513443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Sinan Kaya
On 12/1/2020 10:07 AM, Richard Purdie wrote:
> On Tue, 2020-12-01 at 09:39 -0500, Sinan Kaya wrote:
>> On 12/1/2020 9:30 AM, Otavio Salvador wrote:
>> I am starting to get a little worried about the direction these
>> patches
>> are heading in. How much of the system are we going to split into
>> individual package per binaries?
> I am wondering why this is a concern for you? If we keep the old
> package rdepends on the new ones I see no problem in allowing this
> granular packaging.
 Taking this to a conclusion its heading towards, most recipes
 generating more than one binary would end up with this splitting code.
 I don't like having large blocks of python in each recipe and heading
 that way means we should probably change approach somehow.

 My worry is that simpler recipes are easier to maintain, test and
 upgrade.
>>> Maybe Sinan could try to rework this and move the python code to a
>>> class reducing code duplication?
>>
>> The problem I'm trying to solve is I only need ps file out of this
>> entire package. Everything else in this package is useless for me. I'm
>> sure no-one wants dead code in their system especially if they are size
>> constrained.
>>
>> Ideal solution would be to have --with/without-foo support upstream
>> that we can configure with PACKAGECONFIG.
>>
>> I'm happy to look at other options if there is an alternative.
> 
> The question is how many other packages are you going to need just one
> thing out of?
> 
> You might want ps, someone else might want something different. We've
> had this problem a lot with util-linux and e2fsprogs so we split those
> in the end as the patches were getting painful.
> 
> If this is a widespread issue we might want to have a generic class,
> kind of like lib_package but for splitting the binaries into individual
> packages.
> 
> I just need an idea of how big this problem is going to be as I don't
> want to iterate over half the recipes in oe-core over the next 9
> months! :)

I see. In terms of my project requirements, the only package that I'm
planning to go after like this is sudo.

We should not open the path for subpackages across the board. We need to
prefer PACKAGECONFIG as the right option.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145133): 
https://lists.openembedded.org/g/openembedded-core/message/145133
Mute This Topic: https://lists.openembedded.org/mt/78625996/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 1/1] classes/kernel*: allow disabling symlink creation

2020-12-01 Thread Martin Jansa
Hi Paul,

I see, I was just worried that this case will block me pushing the last bit
of [YOCTO #12937] which changes symlinks to hardlinks:
https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts

Which makes the use case you're fixing worse (as even less systems will
correctly handle hardlinks), so I support the idea to disable having the
links. My current work around is to just remove the unnecessary files when
rsyncing to file-server.

But the main issue which I'm seeing with my current implementation (and
with webos_deploy this is based on) is that we need the version-less
artifacts to be available, because e.g. image recipe searching kernel
artifact when there is DATETIME or SRCPV in the kernel artifact-name won't
be able to find it, because the image might be built at different DATETIME
and doesn't know anything about kernel SRCREV/SRCPV. To resolve this, the
build is using the version-less artifacts (always the latest one).

I guess your implementation might fail in such DATETIME cases as well.

With separate variable to disable the links we can somehow work around this
or at least warn user that without the version-less filenames, the
VERSION_SUFFIX variable needs to be stable (as no PV/SRCPV/DATATIME in it).

Cheers,

On Tue, Dec 1, 2020 at 5:13 PM Paul Eggleton <
bluelightn...@bluelightning.org> wrote:

> Hi Martin
>
> (replying all this time)
>
> On Tuesday, 1 December 2020 15:40:36 NZDT you wrote:
> > Can we use a separate variable controlling this behavior other than
> > *_LINK_NAME variables being set to empty?
> >
> > Then we could easily extend it to stop creating the links also for image
> > artifacts as well.
>
> Well, I didn't call it out explicitly but I was just mirroring the image
> artifacts behaviour - we set those to "" as well and there are checks
> there
> already to make that disable the symlink in that case.
>
> Paul
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145132): 
https://lists.openembedded.org/g/openembedded-core/message/145132
Mute This Topic: https://lists.openembedded.org/mt/78513443/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 1/1] classes/kernel*: allow disabling symlink creation

2020-12-01 Thread Paul Eggleton
Hi Martin

(replying all this time)

On Tuesday, 1 December 2020 15:40:36 NZDT you wrote:
> Can we use a separate variable controlling this behavior other than
> *_LINK_NAME variables being set to empty?
>
> Then we could easily extend it to stop creating the links also for image
> artifacts as well.

Well, I didn't call it out explicitly but I was just mirroring the image 
artifacts behaviour - we set those to "" as well and there are checks there 
already to make that disable the symlink in that case.

Paul



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145131): 
https://lists.openembedded.org/g/openembedded-core/message/145131
Mute This Topic: https://lists.openembedded.org/mt/78513443/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 4/6] reproducible_build: clamp the rootfs tarball mtime to the epoch

2020-12-01 Thread Richard Purdie
On Tue, 2020-12-01 at 15:23 +, Ross Burton wrote:
> To handle files being written to the rootfs outside of the package
> manager,
> clamp the mtimes to the epoch.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/reproducible_build.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/classes/reproducible_build.bbclass
> b/meta/classes/reproducible_build.bbclass
> index 2f3bd90b073..28a25fb492d 100644
> --- a/meta/classes/reproducible_build.bbclass
> +++ b/meta/classes/reproducible_build.bbclass
> @@ -116,3 +116,6 @@ python () {
>  if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
>  d.appendVarFlag("do_unpack", "postfuncs", "
> create_source_date_epoch_stamp")
>  }
> +
> +# Clamp the mtimes of the tarball image filesystem type
> +IMAGE_CMD_tar_append = " --clamp-mtime --
> mtime=@${SOURCE_DATE_EPOCH}"
> 

I'm not convinced this is correct as it could mess up the timestamps of
stamps set in other recipes? 

It's also tar specific and should really be across all image types?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145130): 
https://lists.openembedded.org/g/openembedded-core/message/145130
Mute This Topic: https://lists.openembedded.org/mt/78635762/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 Status WW48'20

2020-12-01 Thread Stephen Jolley
Current Dev Position: YP 3.3 M1 development

Next Deadline: 7th December 2020 YP 3.3 M1 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday Dec. 3rd at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday Dec. 1st at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday Dec. 8th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.1.4 has been through QA and is now under review for release.
*   YP 3.3 M1 is due to be built next week
*   YP 3.3 development in master is continuing as patches are reviewed,
tested and merged.
*   A number of python3 modules have moved to OE-Core, specifically
around allowing pytest to operate there as a number of other recipes depend
upon it and this seemed the most logical solution.
*   Various improvements have been made to the buildbot UI on the
autobuilder and these have now been deployed on our live instance. The
helper changes to improve the log separation and make the differences
between builds clearer has also merged for master.
*   Intermittent autobuilder issues continue to occur. You can see the
list of failures we're continuing to see by searching for the "AB-INT" tag
in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.3. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.3_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.3 Milestone Dates:

*   YP 3.3 M1 build date 2020/12/07
*   YP 3.3 M1 Release date 2020/12/18
*   YP 3.3 M2 build date 2021/01/18
*   YP 3.3 M2 Release date 2021/01/29
*   YP 3.3 M3 build date 2021/03/01
*   YP 3.3 M3 Release date 2021/03/12
*   YP 3.3 M4 build date 2021/04/05
*   YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

*   YP 3.1.4 is just out of QA
*   YP 3.2.1 build date 2020/11/16
*   YP 3.2.1 release date 2020/12/4
*   YP 3.1.5 build date 2021/01/11
*   YP 3.1.5 release date 2021/01/22
*   YP 3.2.2 build date 2021/02/08
*   YP 3.2.2 release date 2021/02/19
*   YP 3.1.6 build date 2021/02/22
*   YP 3.1.6 release date 2021/03/05
*   YP 3.1.7 build date 2021/03/22
*   YP 3.1.7 release date 2021/04/02

 

Tracking Metrics:

*   WDD 2527 (last week 2532) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1283 (last week 1279)
*   Patches in the Pending State: 496 (39%) [last week 497 (39%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

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 (#145129): 
https://lists.openembedded.org/g/openembedded-core/message/145129
Mute This Topic: https://lists.openembedded.org/mt/78636248/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] sysvinit: Add bootlogd patch restoring console detection

2020-12-01 Thread Jate Sujjavanich
The bootlogd program will skip any non-standard serial ports specified
in the kernel parameters, so restore the detection of the device
underlying /dev/console. This allows the serial console on some embedded
systems to work again.

Signed-off-by: Jate Sujjavanich 
---
 ...ogd-c--Restore-dev-console-detection.patch | 101 ++
 meta/recipes-core/sysvinit/sysvinit_2.97.bb   |   1 +
 2 files changed, 102 insertions(+)
 create mode 100644 
meta/recipes-core/sysvinit/sysvinit/0001-bootlogd-c--Restore-dev-console-detection.patch

diff --git 
a/meta/recipes-core/sysvinit/sysvinit/0001-bootlogd-c--Restore-dev-console-detection.patch
 
b/meta/recipes-core/sysvinit/sysvinit/0001-bootlogd-c--Restore-dev-console-detection.patch
new file mode 100644
index 00..14b5d84c78
--- /dev/null
+++ 
b/meta/recipes-core/sysvinit/sysvinit/0001-bootlogd-c--Restore-dev-console-detection.patch
@@ -0,0 +1,101 @@
+From: Jate Sujjavanich 
+Date: Thu, 29 Oct 2020 12:31:43 -0400
+Subject: [PATCH] bootlogd.c: Restore /dev/console detection
+
+Restore function that detected /dev/console's underlying tty device. This
+causes bootlogd to add the kernel's choice for /dev/console to its output list.
+
+This also helps if the kernel's default console is not in the defcons list and
+bootlogd ignores console= definition in kernel parameters. This is frequently
+the case for embedded systems which have their own names for serial drivers.
+
+Upstream-status: Inappropriate, embedded
+
+Signed-off-by: Jate Sujjavanich 
+---
+ src/bootlogd.c | 29 -
+ 1 file changed, 20 insertions(+), 9 deletions(-)
+
+diff --git a/src/bootlogd.c b/src/bootlogd.c
+index 8b07903..909d3e5 100644
+--- a/src/bootlogd.c
 b/src/bootlogd.c
+@@ -110,10 +110,6 @@ void handler(int sig)
+ /*
+  *Scan /dev and find the device name.
+  */
+-/*
+-This function does not appear to be called anymore. Commenting it
+-out for now, can probably be removed entirely in the future.
+-
+ static int findtty(char *res, const char *startdir, int rlen, dev_t dev)
+ {
+   DIR *dir;
+@@ -169,8 +165,6 @@ static int findtty(char *res, const char *startdir, int 
rlen, dev_t dev)
+   chdir(olddir);
+   return r;
+ }
+-*/
+-
+ 
+ 
+ /*
+@@ -250,7 +244,7 @@ int isconsole(char *s, char *res, int rlen)
+ int consolenames(struct real_cons *cons, int max_consoles)
+ {
+ #ifdef TIOCGDEV
+-  /* This appears to be unused.  unsigned int kdev; */
++  unsigned intkdev;
+ #endif
+   struct stat st, st2;
+   charbuf[KERNEL_COMMAND_LENGTH];
+@@ -260,6 +254,23 @@ int consolenames(struct real_cons *cons, int max_consoles)
+   int fd;
+   int considx, num_consoles = 0;
+ 
++#ifdef TIOCGDEV
++# ifndef  ENOIOCTLCMD
++#  define ENOIOCTLCMD 515
++# endif
++  if (ioctl(0, TIOCGDEV, &kdev) == 0) {
++  int r = findtty(cons[0].name, "/dev", sizeof(cons[0].name), 
(dev_t)kdev);
++  if (0 != r)
++  fprintf(stderr, "bootlogd: cannot find console device "
++  "%d:%d under /dev\n", major(kdev), minor(kdev));
++  else {
++  num_consoles++; fprintf(stderr, "bootlogd: %s", 
cons[0].name);
++  }
++  } else
++  if (errno != ENOIOCTLCMD)
++  fprintf(stderr, "bootlogd: ioctl of /dev/console 
error\n");
++#endif
++
+ #ifdef __linux__
+   /*
+*  Read /proc/cmdline.
+@@ -311,12 +322,12 @@ int consolenames(struct real_cons *cons, int 
max_consoles)
+   goto dontuse;
+   }
+   }
+-  
+   num_consoles++;
+   if (num_consoles >= max_consoles) {
+   break;
+   }
+   }
++  
+ dontuse:
+   p--;
+   }
+@@ -329,7 +340,7 @@ dontuse:
+*  guess the default console.
+*/
+   for (n = 0; defcons[n]; n++)
+-  if (isconsole(defcons[n], cons[0].name, sizeof(cons[0].name))) 
++  if (isconsole(defcons[n], cons[0].name, sizeof(cons[0].name)))
+   return 1;
+ 
+   fprintf(stderr, "bootlogd: cannot deduce real console device\n");
+-- 
+2.7.4
+
diff --git a/meta/recipes-core/sysvinit/sysvinit_2.97.bb 
b/meta/recipes-core/sysvinit/sysvinit_2.97.bb
index 98916f7f19..6187295405 100644
--- a/meta/recipes-core/sysvinit/sysvinit_2.97.bb
+++ b/meta/recipes-core/sysvinit/sysvinit_2.97.bb
@@ -20,6 +20,7 @@ SRC_URI = 
"${SAVANNAH_GNU_MIRROR}/sysvinit/sysvinit-${PV}.tar.xz \
file://rcS \
file://bootlogd.init \
file://01_bootlogd \
+   file://0001-bootlogd-c--Restore-dev-console-detection.patch \
"
 SRC_URI[sha256sum] = 
"2d5996857519bfd8634d2e1debabb3238fb38440f65fbfdc46420ee8bdf251

[OE-core] [PATCH 5/6] package_manager/ipk: neaten OPKGLIBDIR logic

2020-12-01 Thread Ross Burton
oe.path.join handles path components starting with / for us.

Signed-off-by: Ross Burton 
---
 meta/lib/oe/package_manager/ipk/__init__.py | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py
index 416ed23d474..2753b139ed1 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -172,12 +172,7 @@ class OpkgPM(OpkgDpkgPM):
 if prepare_index:
 create_packages_dir(self.d, self.deploy_dir, 
d.getVar("DEPLOY_DIR_IPK"), "package_write_ipk", filterbydependencies)
 
-opkg_lib_dir = self.d.getVar('OPKGLIBDIR')
-if opkg_lib_dir[0] == "/":
-opkg_lib_dir = opkg_lib_dir[1:]
-
-self.opkg_dir = os.path.join(target_rootfs, opkg_lib_dir, "opkg")
-
+self.opkg_dir = oe.path.join(target_rootfs, 
self.d.getVar('OPKGLIBDIR'), "opkg")
 bb.utils.mkdirhier(self.opkg_dir)
 
 self.saved_opkg_dir = self.d.expand('${T}/saved/%s' % self.task_name)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145126): 
https://lists.openembedded.org/g/openembedded-core/message/145126
Mute This Topic: https://lists.openembedded.org/mt/78635763/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 6/6] package_manager/ipk: improve remove_packaging_data

2020-12-01 Thread Ross Burton
/var/cache/opkg wasn't being deleted, and /var/lib/opkg doesn't need
to exist as there are no lockfiles that write into it after this step.

Signed-off-by: Ross Burton 
---
 meta/lib/oe/package_manager/ipk/__init__.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py
index 2753b139ed1..da488c1c7f0 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -403,9 +403,9 @@ class OpkgPM(OpkgDpkgPM):
 bb.fatal(result)
 
 def remove_packaging_data(self):
+cachedir = oe.path.join(self.target_rootfs, 
self.d.getVar("localstatedir"), "cache", "opkg")
 bb.utils.remove(self.opkg_dir, True)
-# create the directory back, it's needed by PM lock
-bb.utils.mkdirhier(self.opkg_dir)
+bb.utils.remove(cachedir, True)
 
 def remove_lists(self):
 if not self.from_feeds:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145127): 
https://lists.openembedded.org/g/openembedded-core/message/145127
Mute This Topic: https://lists.openembedded.org/mt/78635764/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 4/6] reproducible_build: clamp the rootfs tarball mtime to the epoch

2020-12-01 Thread Ross Burton
To handle files being written to the rootfs outside of the package manager,
clamp the mtimes to the epoch.

Signed-off-by: Ross Burton 
---
 meta/classes/reproducible_build.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index 2f3bd90b073..28a25fb492d 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -116,3 +116,6 @@ python () {
 if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
 d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
 }
+
+# Clamp the mtimes of the tarball image filesystem type
+IMAGE_CMD_tar_append = " --clamp-mtime --mtime=@${SOURCE_DATE_EPOCH}"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145125): 
https://lists.openembedded.org/g/openembedded-core/message/145125
Mute This Topic: https://lists.openembedded.org/mt/78635762/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 2/6] image_types: remove obsolete tar comment

2020-12-01 Thread Ross Burton
We now depend on tar 1.28, so talking about older tar versions is just
confusing.

Signed-off-by: Ross Burton 
---
 meta/classes/image_types.bbclass | 10 --
 1 file changed, 10 deletions(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 66884af8e09..3ec321765d9 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -108,16 +108,6 @@ IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME
 IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
 
-# By default, tar from the host is used, which can be quite old. If
-# you need special parameters (like --xattrs) which are only supported
-# by GNU tar upstream >= 1.27, then override that default:
-# IMAGE_CMD_TAR = "tar --xattrs --xattrs-include=*"
-# do_image_tar[depends] += "tar-replacement-native:do_populate_sysroot"
-# EXTRANATIVEPATH += "tar-native"
-#
-# The GNU documentation does not specify whether --xattrs-include is necessary.
-# In practice, it turned out to be not needed when creating archives and
-# required when extracting, but it seems prudent to use it in both cases.
 IMAGE_CMD_TAR ?= "tar"
 # ignore return code 1 "file changed as we read it" as other tasks(e.g. 
do_image_wic) may be hardlinking rootfs
 IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --numeric-owner -cf 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [ 
$? -eq 1 ]"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145123): 
https://lists.openembedded.org/g/openembedded-core/message/145123
Mute This Topic: https://lists.openembedded.org/mt/78635760/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 3/6] image_types: sort tarball file listings

2020-12-01 Thread Ross Burton
Help rootfs tarballs be reproducible by sorting the file listing.

Signed-off-by: Ross Burton 
---
 meta/classes/image_types.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 3ec321765d9..286009057e3 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -110,7 +110,7 @@ IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAM
 
 IMAGE_CMD_TAR ?= "tar"
 # ignore return code 1 "file changed as we read it" as other tasks(e.g. 
do_image_wic) may be hardlinking rootfs
-IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --numeric-owner -cf 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [ 
$? -eq 1 ]"
+IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --sort=name --numeric-owner -cf 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [ 
$? -eq 1 ]"
 
 do_image_cpio[cleandirs] += "${WORKDIR}/cpio_append"
 IMAGE_CMD_cpio () {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145124): 
https://lists.openembedded.org/g/openembedded-core/message/145124
Mute This Topic: https://lists.openembedded.org/mt/78635761/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 1/6] ldconfig-native: don't write auxiliary cache

2020-12-01 Thread Ross Burton
The auxiliary cache written by ldconfig is only useful for speeding up
future runs of ldconfig, and as it contains inode numbers as the keys
in a dictionary it is entirely pointless to generate on the build host.

Signed-off-by: Ross Burton 
---
 .../ldconfig-native-2.12.1/no-aux-cache.patch | 19 +++
 .../glibc/ldconfig-native_2.12.1.bb   |  1 +
 2 files changed, 20 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/ldconfig-native-2.12.1/no-aux-cache.patch

diff --git a/meta/recipes-core/glibc/ldconfig-native-2.12.1/no-aux-cache.patch 
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/no-aux-cache.patch
new file mode 100644
index 000..c6765ba00d2
--- /dev/null
+++ b/meta/recipes-core/glibc/ldconfig-native-2.12.1/no-aux-cache.patch
@@ -0,0 +1,19 @@
+The ldconfig auxiliary cache is a dictionary where the keys include inode, so
+there is no point in writing these files on the build host. 
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
+
+diff --git a/ldconfig.c b/ldconfig.c
+index 2c4eb57..2d6dc92 100644
+--- a/ldconfig.c
 b/ldconfig.c
+@@ -1399,8 +1399,6 @@ main (int argc, char **argv)
+   if (opt_build_cache)
+ {
+   save_cache (cache_file);
+-  if (aux_cache_file)
+-save_aux_cache (aux_cache_file);
+ }
+ 
+   return 0;
diff --git a/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb 
b/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
index 93c0b186714..919d11417d3 100644
--- a/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
+++ b/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb
@@ -14,6 +14,7 @@ SRC_URI = "file://ldconfig-native-2.12.1.tar.bz2 \
file://ldconfig-default-to-all-multilib-dirs.patch \
file://endian-ness_handling_fix.patch \
file://add-64-bit-flag-for-ELF64-entries.patch \
+   file://no-aux-cache.patch \
 "
 
 PR = "r2"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145122): 
https://lists.openembedded.org/g/openembedded-core/message/145122
Mute This Topic: https://lists.openembedded.org/mt/78635759/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Richard Purdie
On Tue, 2020-12-01 at 09:39 -0500, Sinan Kaya wrote:
> On 12/1/2020 9:30 AM, Otavio Salvador wrote:
> > > > > I am starting to get a little worried about the direction these
> > > > > patches
> > > > > are heading in. How much of the system are we going to split into
> > > > > individual package per binaries?
> > > > I am wondering why this is a concern for you? If we keep the old
> > > > package rdepends on the new ones I see no problem in allowing this
> > > > granular packaging.
> > > Taking this to a conclusion its heading towards, most recipes
> > > generating more than one binary would end up with this splitting code.
> > > I don't like having large blocks of python in each recipe and heading
> > > that way means we should probably change approach somehow.
> > > 
> > > My worry is that simpler recipes are easier to maintain, test and
> > > upgrade.
> > Maybe Sinan could try to rework this and move the python code to a
> > class reducing code duplication?
> 
> The problem I'm trying to solve is I only need ps file out of this
> entire package. Everything else in this package is useless for me. I'm
> sure no-one wants dead code in their system especially if they are size
> constrained.
> 
> Ideal solution would be to have --with/without-foo support upstream
> that we can configure with PACKAGECONFIG.
> 
> I'm happy to look at other options if there is an alternative.

The question is how many other packages are you going to need just one
thing out of?

You might want ps, someone else might want something different. We've
had this problem a lot with util-linux and e2fsprogs so we split those
in the end as the patches were getting painful.

If this is a widespread issue we might want to have a generic class,
kind of like lib_package but for splitting the binaries into individual
packages.

I just need an idea of how big this problem is going to be as I don't
want to iterate over half the recipes in oe-core over the next 9
months! :)

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145121): 
https://lists.openembedded.org/g/openembedded-core/message/145121
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Sinan Kaya
On 12/1/2020 9:30 AM, Otavio Salvador wrote:
 I am starting to get a little worried about the direction these
 patches
 are heading in. How much of the system are we going to split into
 individual package per binaries?
>>> I am wondering why this is a concern for you? If we keep the old
>>> package rdepends on the new ones I see no problem in allowing this
>>> granular packaging.
>> Taking this to a conclusion its heading towards, most recipes
>> generating more than one binary would end up with this splitting code.
>> I don't like having large blocks of python in each recipe and heading
>> that way means we should probably change approach somehow.
>>
>> My worry is that simpler recipes are easier to maintain, test and
>> upgrade.
> Maybe Sinan could try to rework this and move the python code to a
> class reducing code duplication?

The problem I'm trying to solve is I only need ps file out of this
entire package. Everything else in this package is useless for me. I'm
sure no-one wants dead code in their system especially if they are size
constrained.

Ideal solution would be to have --with/without-foo support upstream
that we can configure with PACKAGECONFIG.

I'm happy to look at other options if there is an alternative.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145120): 
https://lists.openembedded.org/g/openembedded-core/message/145120
Mute This Topic: https://lists.openembedded.org/mt/78625996/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] Revert "connman: set service to conflict with systemd-networkd"

2020-12-01 Thread Jack Mitchell
Without further examples of how this is failing revert as using both
together is a valid use case, for example connman handling Wifi/AP
and systemd-networkd handling more complex routing such as for
containers and ethernet switches.

This reverts commit 5303420ead25817f5caec276b79eec7ee797271a.
---
 ...stop-systemd-networkd-when-using-con.patch | 29 ---
 .../connman/connman_1.38.bb   |  1 -
 2 files changed, 30 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch

diff --git 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
 
b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
deleted file mode 100644
index dd012750a4..00
--- 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
-From: Yi Zhao 
-Date: Fri, 30 Oct 2020 13:48:45 +0800
-Subject: [PATCH] connman.service: stop systemd-networkd when using connman
-
-Stop systemd-networkd service when we use connman as network manager.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Yi Zhao 

- src/connman.service.in | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/connman.service.in b/src/connman.service.in
-index 79e75d6..014eafe 100644
 a/src/connman.service.in
-+++ b/src/connman.service.in
-@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
- After=dbus.service network-pre.target systemd-sysusers.service
- Before=network.target multi-user.target shutdown.target
- Wants=network.target
-+Conflicts=systemd-networkd.service systemd-networkd.socket
- Conflicts=systemd-resolved.service
- 
- [Service]
--- 
-2.17.1
-
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
b/meta/recipes-connectivity/connman/connman_1.38.bb
index 45c2934dec..027c41e9af 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.38.bb
@@ -3,7 +3,6 @@ require connman.inc
 SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \

file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \

file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
-   
file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
file://connman \
file://no-version-scripts.patch \
"
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145119): 
https://lists.openembedded.org/g/openembedded-core/message/145119
Mute This Topic: https://lists.openembedded.org/mt/78634667/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Otavio Salvador
Em ter., 1 de dez. de 2020 às 11:15, Richard Purdie
 escreveu:
> On Tue, 2020-12-01 at 08:29 -0300, Otavio Salvador wrote:
> > Hello Richard,
> >
> > Em ter., 1 de dez. de 2020 às 07:37, Richard Purdie
> >  escreveu:
> > > On Tue, 2020-12-01 at 03:43 +, Sinan Kaya wrote:
> > ...
> > > I am starting to get a little worried about the direction these
> > > patches
> > > are heading in. How much of the system are we going to split into
> > > individual package per binaries?
> >
> > I am wondering why this is a concern for you? If we keep the old
> > package rdepends on the new ones I see no problem in allowing this
> > granular packaging.
>
> Taking this to a conclusion its heading towards, most recipes
> generating more than one binary would end up with this splitting code.
> I don't like having large blocks of python in each recipe and heading
> that way means we should probably change approach somehow.
>
> My worry is that simpler recipes are easier to maintain, test and
> upgrade.

Maybe Sinan could try to rework this and move the python code to a
class reducing code duplication?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145118): 
https://lists.openembedded.org/g/openembedded-core/message/145118
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Richard Purdie
On Tue, 2020-12-01 at 08:29 -0300, Otavio Salvador wrote:
> Hello Richard,
> 
> Em ter., 1 de dez. de 2020 às 07:37, Richard Purdie
>  escreveu:
> > On Tue, 2020-12-01 at 03:43 +, Sinan Kaya wrote:
> ...
> > I am starting to get a little worried about the direction these
> > patches
> > are heading in. How much of the system are we going to split into
> > individual package per binaries?
> 
> I am wondering why this is a concern for you? If we keep the old
> package rdepends on the new ones I see no problem in allowing this
> granular packaging.

Taking this to a conclusion its heading towards, most recipes
generating more than one binary would end up with this splitting code.
I don't like having large blocks of python in each recipe and heading
that way means we should probably change approach somehow.

My worry is that simpler recipes are easier to maintain, test and
upgrade.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145117): 
https://lists.openembedded.org/g/openembedded-core/message/145117
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [dunfell][PATCH] go: update to 1.14.12

2020-12-01 Thread Lee Chee Yang
From: Lee Chee Yang 

update minor version to 1.14.12

go1.14.8 includes security fixes to the net/http/cgi and net/http/fcgi packages.
go1.14.9 includes fixes to the compiler, linker, runtime, documentation, and 
the net/http and testing packages.
go1.14.10 includes fixes to the compiler, runtime, and the plugin and testing 
packages.
go1.14.11 includes fixes to the runtime, and the net/http and time packages.
go1.14.12 includes security fixes to the cmd/go and math/big packages.

Release notes:
https://golang.org/doc/devel/release.html#go1.14.minor

updates include fix for
CVE-2020-24553
CVE-2020-28362
CVE-2020-28366
CVE-2020-28367

Also backport patch to fix below CGO_LDFLAGS error

| Building std for target, linux/amd64.
| go build runtime/cgo: invalid flag in go:cgo_ldflag: -Wl,-O1

Signed-off-by: Lee Chee Yang 
---
 meta/recipes-devtools/go/go-1.14.inc  |  5 +-
 ...t-CGO_LDFLAGS-to-appear-in-go-ldflag.patch | 98 +++
 2 files changed, 101 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/go/go-1.14/0010-cmd-go-permit-CGO_LDFLAGS-to-appear-in-go-ldflag.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index 8f8ed89de8..02c40f4e25 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -1,7 +1,7 @@
 require go-common.inc
 
 GO_BASEVERSION = "1.14"
-GO_MINOR = ".7"
+GO_MINOR = ".12"
 PV .= "${GO_MINOR}"
 FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
 
@@ -16,6 +16,7 @@ SRC_URI += "\
 file://0006-cmd-dist-separate-host-and-target-builds.patch \
 file://0007-cmd-go-make-GOROOT-precious-by-default.patch \
 file://0008-use-GOBUILDMODE-to-set-buildmode.patch \
+file://0010-cmd-go-permit-CGO_LDFLAGS-to-appear-in-go-ldflag.patch \
 "
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
-SRC_URI[main.sha256sum] = 
"064392433563660c73186991c0a315787688e7c38a561e26647686f89b6c30e3"
+SRC_URI[main.sha256sum] = 
"b34f4b7ad799eab4c1a52bdef253602ce957125a512f5a1b28dce43c6841b971"
diff --git 
a/meta/recipes-devtools/go/go-1.14/0010-cmd-go-permit-CGO_LDFLAGS-to-appear-in-go-ldflag.patch
 
b/meta/recipes-devtools/go/go-1.14/0010-cmd-go-permit-CGO_LDFLAGS-to-appear-in-go-ldflag.patch
new file mode 100644
index 00..85bf39c752
--- /dev/null
+++ 
b/meta/recipes-devtools/go/go-1.14/0010-cmd-go-permit-CGO_LDFLAGS-to-appear-in-go-ldflag.patch
@@ -0,0 +1,98 @@
+From 782cf560db4c919790fdb476d1bbe18e5ddf5ffd Mon Sep 17 00:00:00 2001
+From: Ian Lance Taylor 
+Date: Fri, 13 Nov 2020 11:05:37 -0800
+Subject: [PATCH] cmd/go: permit CGO_LDFLAGS to appear in //go:ldflag
+
+Fixes #42565
+
+Change-Id: If7cf39905d124dbd54dfac6a53ee38270498efed
+Reviewed-on: https://go-review.googlesource.com/c/go/+/269818
+Trust: Ian Lance Taylor 
+Run-TryBot: Ian Lance Taylor 
+TryBot-Result: Go Bot 
+Reviewed-by: Jay Conrod 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/782cf560db4c919790fdb476d1bbe18e5ddf5ffd]
+Signed-off-by: Lee Chee Yang 
+---
+ src/cmd/go/internal/work/exec.go  | 15 +
+ src/cmd/go/testdata/script/ldflag.txt | 44 +++
+ 2 files changed, 59 insertions(+)
+ create mode 100644 src/cmd/go/testdata/script/ldflag.txt
+
+diff --git a/src/cmd/go/internal/work/exec.go 
b/src/cmd/go/internal/work/exec.go
+index 2c40a4bf001e..157ac4cafc70 100644
+--- a/src/cmd/go/internal/work/exec.go
 b/src/cmd/go/internal/work/exec.go
+@@ -2883,6 +2883,21 @@ func (b *Builder) cgo(a *Action, cgoExe, objdir string, 
pcCFLAGS, pcLDFLAGS, cgo
+   idx = bytes.Index(src, []byte(cgoLdflag))
+   }
+   }
++
++  // We expect to find the contents of cgoLDFLAGS in flags.
++  if len(cgoLDFLAGS) > 0 {
++  outer:
++  for i := range flags {
++  for j, f := range cgoLDFLAGS {
++  if f != flags[i+j] {
++  continue outer
++  }
++  }
++  flags = append(flags[:i], 
flags[i+len(cgoLDFLAGS):]...)
++  break
++  }
++  }
++
+   if err := checkLinkerFlags("LDFLAGS", "go:cgo_ldflag", flags); 
err != nil {
+   return nil, nil, err
+   }
+diff --git a/src/cmd/go/testdata/script/ldflag.txt 
b/src/cmd/go/testdata/script/ldflag.txt
+new file mode 100644
+index ..6ceb33bb70e7
+--- /dev/null
 b/src/cmd/go/testdata/script/ldflag.txt
+@@ -0,0 +1,44 @@
++# Issue #42565
++
++[!cgo] skip
++
++# We can't build package bad, which uses #cgo LDFLAGS.
++cd bad
++! go build
++stderr no-such-warning
++
++# We can build package ok with the same flags in CGO_LDFLAGS.
++env CGO_LDFLAGS=-Wno-such-warning -Wno-u

Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Otavio Salvador
Hello Richard,

Em ter., 1 de dez. de 2020 às 07:37, Richard Purdie
 escreveu:
> On Tue, 2020-12-01 at 03:43 +, Sinan Kaya wrote:
...
> I am starting to get a little worried about the direction these patches
> are heading in. How much of the system are we going to split into
> individual package per binaries?

I am wondering why this is a concern for you? If we keep the old
package rdepends on the new ones I see no problem in allowing this
granular packaging.



-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145115): 
https://lists.openembedded.org/g/openembedded-core/message/145115
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-12-01 Thread Richard Purdie
On Tue, 2020-12-01 at 03:43 +, Sinan Kaya wrote:
> This change allows you to pull individual binaries into the
> target without including the entire suite.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  meta/recipes-extended/procps/procps_3.3.16.bb | 51 +--
>  1 file changed, 48 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb 
> b/meta/recipes-extended/procps/procps_3.3.16.bb
> index 2810ebd285a..1b62ae33f5c 100644
> --- a/meta/recipes-extended/procps/procps_3.3.16.bb
> +++ b/meta/recipes-extended/procps/procps_3.3.16.bb
> @@ -50,15 +50,13 @@ do_install_append () {
>  
>  CONFFILES_${PN} = "${sysconfdir}/sysctl.conf"
>  
> -bindir_progs = "free pkill pmap pgrep pwdx skill snice top uptime w"
> +bindir_progs = "free pkill pmap pgrep pwdx skill slabtop snice tload top 
> uptime vmstat w"
>  base_bindir_progs += "kill pidof ps watch"
>  base_sbindir_progs += "sysctl"
>  
>  ALTERNATIVE_PRIORITY = "200"
>  ALTERNATIVE_PRIORITY[pidof] = "150"
>  
> -ALTERNATIVE_${PN} = "${bindir_progs} ${base_bindir_progs} 
> ${base_sbindir_progs}"
> -
>  ALTERNATIVE_${PN}-doc = "kill.1 uptime.1"
>  ALTERNATIVE_LINK_NAME[kill.1] = "${mandir}/man1/kill.1"
>  ALTERNATIVE_LINK_NAME[uptime.1] = "${mandir}/man1/uptime.1"
> @@ -69,8 +67,55 @@ python __anonymous() {
>  
>  for prog in d.getVar('base_sbindir_progs').split():
>  d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % 
> (d.getVar('base_sbindir'), prog))
> +
> +for prog in d.getVar('bindir_progs').split():
> +d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % 
> (d.getVar('bindir'), prog))
>  }
>  
>  # 'ps' isn't suitable for use as a security tool so whitelist this CVE.
>  # https://bugzilla.redhat.com/show_bug.cgi?id=1575473#c3
>  CVE_CHECK_WHITELIST += "CVE-2018-1121"
> +
> +python __anonymous () {
> +packages = []
> +for prog in d.getVar('bindir_progs').split():
> +pkg = "procps-%s" % prog.replace("_", "-")
> +packages.append(pkg)
> +d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
> +d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
> +if not d.getVar("FILES_%s" % pkg):
> +d.setVar("FILES_%s" % pkg, "${bindir}/%s*" % prog)
> +for prog in d.getVar('base_sbindir_progs').split():
> +pkg = "procps-%s" % prog.replace("_", "-")
> +packages.append(pkg)
> +d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
> +d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
> +if not d.getVar("FILES_%s" % pkg):
> +d.setVar("FILES_%s" % pkg, "${base_sbindir}/%s*" % prog)
> +for prog in d.getVar('base_bindir_progs').split():
> +pkg = "procps-%s" % prog.replace("_", "-")
> +packages.append(pkg)
> +d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
> +d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
> +if not d.getVar("FILES_%s" % pkg):
> +d.setVar("FILES_%s" % pkg, "${base_bindir}/%s*" % prog)
> +pkg = "procps-man"
> +packages.append(pkg)
> +if not d.getVar("FILES_%s" % pkg):
> +d.setVar("FILES_%s" % pkg, "${mandir}/*")
> +pkg = "procps-lib"
> +packages.append(pkg)
> +if not d.getVar("FILES_%s" % pkg):
> +d.setVar("FILES_%s" % pkg, "${libdir}/*")
> +pkg = "procps-sysctl"
> +d.appendVar("FILES_%s" % pkg, " ${sysconfdir}/sysctl.conf")
> +
> +d.setVar("PROCPS_PACKAGES", " ".join(packages))
> +}
> +# "procps" is a metapackage which pulls in all procps binaries
> +PACKAGES += "${PROCPS_PACKAGES}"
> +PROVIDES += "${PROCPS_PACKAGES}"
> +FILES_${PN} = ""
> +ALLOW_EMPTY_${PN} = "1"
> +RRECOMMENDS_${PN} += "${PROCPS_PACKAGES}"

I am starting to get a little worried about the direction these patches
are heading in. How much of the system are we going to split into
individual package per binaries?

At some point the packages stop becoming useful and you have to
consider whather package management is the best way to build these
rootfs since I doubt you're enabling package management in the end
result anyway given the size gains you're aiming for?

I'd like to understand and discuss the end goal here before we merge
too many large chunks of custom python like the above?

An alternative may be to create a library function which can be
optionally enabled for recipes as this code and the other code you sent
does look similar, at least superficially...

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145114): 
https://lists.openembedded.org/g/openembedded-core/message/145114
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] #include[yocto] [meta-mingw] Build win sdk with qt compilation errors.

2020-12-01 Thread shuai cao
Hi , Everyone
I'm generating win sdk with yocto and I get nativesdk-qtbase compilation errors.

tmp-glibc-glibc/work/x86_64- nativesdk-mingw32-niic_sdk- 
mingw32/nativesdk-qtbase/5.11. 3+gitAUTOINC+08de243eaa-r0/ 
git/qmake/library/ioutils.cpp: 208:19: error: cannot convert 'LPWSTR' {aka 
'wchar_t*'} to 'LPSTR' {aka 'char*'}
|                    (LPWSTR)&string,
|                    ^~~
Makefile:211: recipe for target 'ioutils.o' failed

I need to generate a sdk with a qt environment.
Can you tell me how to handle this problem?

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145113): 
https://lists.openembedded.org/g/openembedded-core/message/145113
Mute This Topic: https://lists.openembedded.org/mt/78629736/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-mingw

2020-12-01 Thread shuai cao
Hi , Everyone
I'm generating win sdk with yocto and I get nativesdk-qtbase compilation errors.

tmp-glibc-glibc/work/x86_64- nativesdk-mingw32-niic_sdk- 
mingw32/nativesdk-qtbase/5.11. 3+gitAUTOINC+08de243eaa-r0/ 
git/qmake/library/ioutils.cpp: 208:19: error: cannot convert 'LPWSTR' {aka 
'wchar_t*'} to 'LPSTR' {aka 'char*'}
|                    (LPWSTR)&string,
|                    ^~~
Makefile:211: recipe for target 'ioutils.o' failed

I need to generate a sdk with a qt environment.
Can you tell me how to handle this problem?

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145112): 
https://lists.openembedded.org/g/openembedded-core/message/145112
Mute This Topic: https://lists.openembedded.org/mt/78629715/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] QA notification for completed autobuilder build (yocto-3.1.4.rc1)

2020-12-01 Thread Sangeeta Jain
Hello all,

This is the full report for yocto-3.1.4.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects. 

new issue found 

BUG id:14138 - [QA 3.1.4 RC1] failure in oe-core manual test: 
test_bitbake_devshell
   
Bugs verified:

BUG id:14071 - [QA 3.1.3 RC1] failure in ptest : perl.t/re/pat 
   Verified Fixed.

Existing bugs observed in this release:

BUG id:14055 - [QA 3.2 M3 RC1] failure in oe-core manual test: 
test_dependency_explorer_is_launched
  
=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14138
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14071
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14055

Thanks,
Sangeeta

> -Original Message-
> From: Pokybuild User 
> Sent: Thursday, 26 November, 2020 12:14 PM
> To: yo...@lists.yoctoproject.org
> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> ; Yeoh, Ee Peng ; Chan,
> Aaron Chun Yew ;
> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
> sjolley.yp...@gmail.com; Jain, Sangeeta ;
> st...@sakoman.com
> Subject: QA notification for completed autobuilder build (yocto-3.1.4.rc1)
> 
> 
> A build flagged for QA (yocto-3.1.4.rc1) was completed on the autobuilder and 
> is
> available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.1.4.rc1
> 
> 
> Build hash information:
> 
> bitbake: 89fc9450abefd682266efcbfa031d1ef115ff1a7
> meta-arm: e18ee052f75da60655fb434ff24a463a8fb36781
> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> meta-intel: 541c7256c1b6acba35d1116a1483b6594d189e3a
> meta-kernel: f9d30c65d08c9cef20d6487a7aff0fff40acc823
> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
> oecore: b885888df67eb5cdb3b82f4f0a07369a449e223b
> poky: 424296bf9bb4bae27febf91bce0118df09ce5fa1
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145111): 
https://lists.openembedded.org/g/openembedded-core/message/145111
Mute This Topic: https://lists.openembedded.org/mt/78542149/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-