[OE-core] [dunfell][PATCH 2/2] linux-firmware: package firmware for Lontium lt9611uxc bridge

2020-12-21 Thread Dmitry Baryshkov
Package firmware for Lontium lt9611uxc DSI to HDMI bridge, found e.g. on
Qualcomm RB5 platform.

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Richard Purdie 
(cherry picked from commit 4d16922943ffa6003d611c367b934d199c549c4c)
---
 .../linux-firmware/linux-firmware_20201218.bb  | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
index bc9daa2d4e7e..700a79b118a7 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
@@ -31,6 +31,7 @@ LICENSE = "\
 & Firmware-iwlwifi_firmware \
 & Firmware-IntcSST2 \
 & Firmware-kaweth \
+& Firmware-Lontium \
 & Firmware-Marvell \
 & Firmware-moxa \
 & Firmware-myri10ge_firmware \
@@ -94,6 +95,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 file://LICENCE.it913x;md5=1fbf727bfb6a949810c4dbfa7e6ce4f8 
\
 
file://LICENCE.iwlwifi_firmware;md5=3fd842911ea93c29cd32679aa23e1c88 \
 file://LICENCE.kaweth;md5=b1d876e562f4b3b8d391ad8395dfe03f 
\
+
file://LICENSE.Lontium;md5=4ec8dc582ff7295f39e2ca6a7b0be2b6 \
 
file://LICENCE.Marvell;md5=28b6ed8bd04ba105af6e4dcd6e997772 \
 
file://LICENCE.mediatek;md5=7c1976b63217d76ce47d0a11d8a79cf2 \
 file://LICENCE.moxa;md5=1086614767d8ccf744a923289d3d4261 \
@@ -161,6 +163,7 @@ NO_GENERIC_LICENSE[Firmware-IntcSST2] = "LICENCE.IntcSST2"
 NO_GENERIC_LICENSE[Firmware-it913x] = "LICENCE.it913x"
 NO_GENERIC_LICENSE[Firmware-iwlwifi_firmware] = "LICENCE.iwlwifi_firmware"
 NO_GENERIC_LICENSE[Firmware-kaweth] = "LICENCE.kaweth"
+NO_GENERIC_LICENSE[Firmware-Lontium] = "LICENSE.Lontium"
 NO_GENERIC_LICENSE[Firmware-Marvell] = "LICENCE.Marvell"
 NO_GENERIC_LICENSE[Firmware-mediatek] = "LICENCE.mediatek"
 NO_GENERIC_LICENSE[Firmware-moxa] = "LICENCE.moxa"
@@ -298,6 +301,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 
${PN}-qcom-adreno-a630 \
  ${PN}-qcom-sdm845-audio ${PN}-qcom-sdm845-compute 
${PN}-qcom-sdm845-modem \
  ${PN}-amlogic-vdec-license ${PN}-amlogic-vdec \
+ ${PN}-lt9611uxc ${PN}-lontium-license \
  ${PN}-whence-license \
  ${PN}-license \
  "
@@ -402,6 +406,12 @@ FILES_${PN}-radeon = " \
 
 RDEPENDS_${PN}-radeon += "${PN}-radeon-license"
 
+# For lontium
+LICENSE_${PN}-lt9611uxc = "Firmware-Lontium"
+
+FILES_${PN}-lontium-license = "${nonarch_base_libdir}/firmware/LICENSE.Lontium"
+FILES_${PN}-lt9611uxc = "${nonarch_base_libdir}/firmware/lt9611uxc_fw.bin"
+
 # For marvell
 LICENSE_${PN}-pcie8897 = "Firmware-Marvell"
 LICENSE_${PN}-pcie8997 = "Firmware-Marvell"
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146013): 
https://lists.openembedded.org/g/openembedded-core/message/146013
Mute This Topic: https://lists.openembedded.org/mt/79122988/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 1/2] linux-firmware: upgrade 20201118 -> 20201218

2020-12-21 Thread Dmitry Baryshkov
License-Update: firmware versions/filenames
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Richard Purdie 
(cherry picked from commit c88129ffef320c16722f40426b0d4560274dca4e)
---
 ...{linux-firmware_20201118.bb => linux-firmware_20201218.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/linux-firmware/{linux-firmware_20201118.bb => 
linux-firmware_20201218.bb} (99%)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
index baac26c51053..bc9daa2d4e7e 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
@@ -126,7 +126,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 
\
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 
\
 
file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=ef221e03fc58f4d34a132b801dfa1d68 \
+file://WHENCE;md5=03f0fad70b8b557b56084e3090198021 \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -198,7 +198,7 @@ PE = "1"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz"
 
-SRC_URI[sha256sum] = 
"863d5a31da725b856a917280d1e3014929b3bc3d4e6e5faecf530c13afb7e2b9"
+SRC_URI[sha256sum] = 
"a1cc1ff72c739f312b095df589e9fd639fc81c3f8f7966377ea35222dc94c04b"
 
 inherit allarch
 
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146012): 
https://lists.openembedded.org/g/openembedded-core/message/146012
Mute This Topic: https://lists.openembedded.org/mt/79122987/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] apr-util: Only specify --with-dbm=gdbm if gdbm support is enabled

2020-12-21 Thread Peter Kjellerstedt
Support for gdbm was made optional in 3260ad9e, but it was still being
used unconditionally.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-support/apr/apr-util_1.6.1.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/apr/apr-util_1.6.1.bb 
b/meta/recipes-support/apr/apr-util_1.6.1.bb
index 0dd8f025e8..f7d827a1d8 100644
--- a/meta/recipes-support/apr/apr-util_1.6.1.bb
+++ b/meta/recipes-support/apr/apr-util_1.6.1.bb
@@ -19,10 +19,9 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
 SRC_URI[md5sum] = "bd502b9a8670a8012c4d90c31a84955f"
 SRC_URI[sha256sum] = 
"b65e40713da57d004123b6319828be7f1273fbc6490e145874ee1177e112c459"
 
-EXTRA_OECONF = "--with-apr=${STAGING_BINDIR_CROSS}/apr-1-config \ 
+EXTRA_OECONF = "--with-apr=${STAGING_BINDIR_CROSS}/apr-1-config \
--without-odbc \
--without-pgsql \
-   --with-dbm=gdbm \
--without-sqlite2 \
--with-expat=${STAGING_DIR_HOST}${prefix}"
 
@@ -69,7 +68,7 @@ PACKAGECONFIG ??= "crypto gdbm"
 PACKAGECONFIG[ldap] = "--with-ldap,--without-ldap,openldap"
 PACKAGECONFIG[crypto] = "--with-openssl=${STAGING_DIR_HOST}${prefix} 
--with-crypto,--without-crypto,openssl"
 PACKAGECONFIG[sqlite3] = 
"--with-sqlite3=${STAGING_DIR_HOST}${prefix},--without-sqlite3,sqlite3"
-PACKAGECONFIG[gdbm] = 
"--with-gdbm=${STAGING_DIR_HOST}${prefix},--without-gdbm,gdbm"
+PACKAGECONFIG[gdbm] = "--with-dbm=gdbm 
--with-gdbm=${STAGING_DIR_HOST}${prefix},--without-gdbm,gdbm"
 
 #files ${libdir}/apr-util-1/*.so are not symlinks but loadable modules thus 
they are packaged in ${PN}
 FILES_${PN} += "${libdir}/apr-util-1/apr*${SOLIBS} 
${libdir}/apr-util-1/apr*${SOLIBSDEV}"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146014): 
https://lists.openembedded.org/g/openembedded-core/message/146014
Mute This Topic: https://lists.openembedded.org/mt/79123128/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 0/4] pulseaudio: Autotools to Meson

2020-12-21 Thread Andrey Zhizhikin
Hello Tanu,

On Sun, Dec 20, 2020 at 5:09 PM Khem Raj  wrote:
>
> On Sun, Dec 20, 2020 at 6:26 AM Tanu Kaskinen  wrote:
> >
> > On Sat, 2020-12-19 at 12:36 -0800, Khem Raj wrote:
> > > On Sat, Dec 19, 2020 at 9:24 AM Khem Raj  wrote:
> > > > On Thu, Dec 17, 2020 at 11:28 AM Tanu Kaskinen  wrote:
> > > > > The PulseAudio project plans to drop Autotools support in 15.0, so 
> > > > > let's
> > > > > switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which is
> > > > > some old cruft that sounds like it has something to do Libtool, so 
> > > > > it's
> > > > > perhaps relevant for the goal of dropping Autotools. The next two
> > > > > patches disable features that aren't available with Meson. The last
> > > > > patch does the build system switch.
> > > > >
> > > > > Tanu Kaskinen (4):
> > > > >   pulseaudio: Remove OE_LT_RPATH_ALLOW
> > > > >   pulseaudio: disable EsounD support
> > > > >   pulseaudio: disable GConf support
> > > > >   pulseaudio: switch build system from Autotools to Meson

I'm seeing a build failure after this upgrade, thought you might
advise here what could be wrong.

Following is produced at the end of do_compile taks:

| sed: can't read src/client.conf: No such file or directory
| WARNING: exit code 2 from a shell command.
|
ERROR: Task 
(/development/yocto-master/yocto-build-appliance/meta/recipes-multimedia/pulseaudio/pulseaudio_14.0.bb:do_compile)
failed with exit code '1'

Have you experienced the same error, and what can be missing here?

> > > >
> > > > I am seeing build failures with this patch series while using clang
> > > > for compiler see.
> > > >
> > > > https://errors.yoctoproject.org/Errors/Details/539474/
> > > >
> > >
> > > It turns out that new meson checks are a bit different and if
> > > -Qunused-arguments is used with clang then the test for neon passes
> > > because its a simple compile time check in meson, So a workaround that
> > > I have done is to remove using -Qunused-arguments on clang
> > > cmdline and then it works ok.
> >
> > Ok, so the Neon check in Meson is somehow too lax if it passes with
> > -Qunused-arguments. Thanks for the initial debugging! I can look into
> > the issue, but I can't promise to do it quickly. I see these patches
> > are in master already - should the last patch be reverted for now? Or
> > can your workaround be applied to master (or meta-clang, if that's
> > where clang workarounds belong)?
> >
>
> I think its ok, I have added the relevant workaround in meta-clang for
> now. there was another
> issue I ran into non x86 builds with clang, which I have sent a patch
> for. Please review it and see
> if its worth upstreaming into PA and help it upstream if you can.
>
> > --
> > Tanu
> >
>
> 
>


-- 
Regards,
Andrey.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146015): 
https://lists.openembedded.org/g/openembedded-core/message/146015
Mute This Topic: https://lists.openembedded.org/mt/79044755/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 0/4] pulseaudio: Autotools to Meson

2020-12-21 Thread Tanu Kaskinen
On Mon, 2020-12-21 at 14:03 +0100, Andrey Zhizhikin wrote:
> Hello Tanu,
> 
> On Sun, Dec 20, 2020 at 5:09 PM Khem Raj  wrote:
> > On Sun, Dec 20, 2020 at 6:26 AM Tanu Kaskinen  wrote:
> > > On Sat, 2020-12-19 at 12:36 -0800, Khem Raj wrote:
> > > > On Sat, Dec 19, 2020 at 9:24 AM Khem Raj  wrote:
> > > > > On Thu, Dec 17, 2020 at 11:28 AM Tanu Kaskinen  wrote:
> > > > > > The PulseAudio project plans to drop Autotools support in 15.0, so 
> > > > > > let's
> > > > > > switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which is
> > > > > > some old cruft that sounds like it has something to do Libtool, so 
> > > > > > it's
> > > > > > perhaps relevant for the goal of dropping Autotools. The next two
> > > > > > patches disable features that aren't available with Meson. The last
> > > > > > patch does the build system switch.
> > > > > > 
> > > > > > Tanu Kaskinen (4):
> > > > > >   pulseaudio: Remove OE_LT_RPATH_ALLOW
> > > > > >   pulseaudio: disable EsounD support
> > > > > >   pulseaudio: disable GConf support
> > > > > >   pulseaudio: switch build system from Autotools to Meson
> 
> I'm seeing a build failure after this upgrade, thought you might
> advise here what could be wrong.
> 
> Following is produced at the end of do_compile taks:
> 
> > sed: can't read src/client.conf: No such file or directory
> > WARNING: exit code 2 from a shell command.
> > 
> ERROR: Task 
> (/development/yocto-master/yocto-build-appliance/meta/recipes-multimedia/pulseaudio/pulseaudio_14.0.bb:do_compile)
> failed with exit code '1'
> 
> Have you experienced the same error, and what can be missing here?

I can reproduce the error when enabling the autospawn-for-root
PACKAGECONFIG. client.conf is generated from client.conf.in, and the
generated file's location has changed. Replacing "src/client.conf" with
"src/pulse/client.conf" in pulseaudio.inc seems to fix this issue.

-- 
Tanu


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



[OE-core] Process for backports

2020-12-21 Thread Peter Kjellerstedt
I thought the process for backporting changes in OE-Core was:

master -> gatesgarth -> dunfell -> ...

However, I just noticed that the latest Gatesgarth release (24.0.1) 
is still at 2020b of timezone, whereas Dunfell (23.0.4) has 2020d.
Am I missing something here, or is this just a miss in communication?

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146017): 
https://lists.openembedded.org/g/openembedded-core/message/146017
Mute This Topic: https://lists.openembedded.org/mt/79125184/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] pulseaudio: Fix build with clang for non-x86 target

2020-12-21 Thread Tanu Kaskinen
On Sun, 2020-12-20 at 08:05 -0800, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> Cc: Tanu Kaskinen 
> ---
>  .../0001-meson-Check-for-__get_cpuid.patch| 82 +++
>  .../pulseaudio/pulseaudio_14.0.bb |  1 +
>  2 files changed, 83 insertions(+)
>  create mode 100644 
> meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> 
> diff --git 
> a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
>  
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> new file mode 100644
> index 00..c9d8abcbf2
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> @@ -0,0 +1,82 @@
> +From 9d0dc8aedd08d77797f90fa6075a59613f18bf0d Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sun, 20 Dec 2020 07:56:07 -0800
> +Subject: [PATCH] meson: Check for __get_cpuid
> +
> +checking for presence of cpuid.h header alone is not sufficient in some case 
> to use
> +cpuid related functions. e.g. when using clang which is built for
> +multiple targets will have cpuid.h header as part of compiler headers in
> +distribution but one maybe compiling pulseaudion for non-x86 target. The
> +current check in meson succeeds and then compile fails later because
> +cpuid.h is x86-specific header. Therefore checking for symbol that is
> +needed makes this robust, so even if header exist it will try to ensure
> +the given symbol can be used
> +
> +Fixes
> +src/pulsecore/core-util.c:113:
> +| 
> /mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/pulseaudio/14.0-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/cpuid.h:11:2:
>  error: this header is for x86 only
> +| #error this header is for x86 only
> +|  ^
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj 
> +Cc: Tanu Kaskinen 
> +---
> + meson.build   | 5 -
> + src/pulsecore/core-util.c | 2 +-
> + src/pulsecore/cpu-x86.c   | 2 +-
> + 3 files changed, 6 insertions(+), 3 deletions(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 2589627..5f5127e 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -185,7 +185,6 @@ endif
> + check_headers = [
> +   'arpa/inet.h',
> +   'byteswap.h',
> +-  'cpuid.h',
> +   'dlfcn.h',
> +   'execinfo.h',
> +   'grp.h',
> +@@ -243,6 +242,10 @@ if cc.has_header_symbol('pthread.h', 
> 'PTHREAD_PRIO_INHERIT')
> +   cdata.set('HAVE_PTHREAD_PRIO_INHERIT', 1)
> + endif
> + 
> ++if cc.has_header_symbol('cpuid.h', '__get_cpuid')
> ++  cdata.set('HAVE_GET_CPUID', 1)
> ++endif
> ++
> + # Functions
> + 
> + check_functions = [
> +diff --git a/src/pulsecore/core-util.c b/src/pulsecore/core-util.c
> +index 601b1d1..6f34e7c 100644
> +--- a/src/pulsecore/core-util.c
>  b/src/pulsecore/core-util.c
> +@@ -109,7 +109,7 @@
> + #include 
> + #endif
> + 
> +-#ifdef HAVE_CPUID_H
> ++#ifdef HAVE_GET_CPUID
> + #include 
> + #endif
> + 
> +diff --git a/src/pulsecore/cpu-x86.c b/src/pulsecore/cpu-x86.c
> +index 4e59e14..86595d4 100644
> +--- a/src/pulsecore/cpu-x86.c
>  b/src/pulsecore/cpu-x86.c
> +@@ -24,7 +24,7 @@
> + 
> + #include 
> + 
> +-#ifdef HAVE_CPUID_H
> ++#ifdef HAVE_GET_CPUID

There are more instances of HAVE_CPUID_H in core-util.c and cpu-x86.c,
they all need to be replaced with HAVE_GET_CPUID. Could you update the
patch?

When upstreaming, I think this change needs to be ported to the
Autotools build system too as long as it exists in PulseAudio, but I
can take care of that.

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146018): 
https://lists.openembedded.org/g/openembedded-core/message/146018
Mute This Topic: https://lists.openembedded.org/mt/79105751/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] cups: Mark CVE-2008-1033 as a non-issue

2020-12-21 Thread Richard Purdie
It only applies to MacOS.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/cups/cups.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index 91e73d75e43..e7a704134c6 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -20,6 +20,8 @@ SRC_URI = 
"https://github.com/apple/cups/releases/download/v${PV}/${BP}-source.t
 UPSTREAM_CHECK_URI = "https://github.com/apple/cups/releases";
 UPSTREAM_CHECK_REGEX = "cups-(?P\d+\.\d+(\.\d+)?)-source.tar"
 
+# Issue only applies to MacOS
+CVE_CHECK_WHITELIST += "CVE-2008-1033"
 # Issue affects pdfdistiller plugin used with but not part of cups
 CVE_CHECK_WHITELIST += "CVE-2009-0032"
 # This is an Ubuntu only issue.
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146019): 
https://lists.openembedded.org/g/openembedded-core/message/146019
Mute This Topic: https://lists.openembedded.org/mt/79125565/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] pulseaudio: fix client.conf location

2020-12-21 Thread Tanu Kaskinen
The location of the generated client.conf changed when switching from
Autotools to Meson.

Fixes this error when enabling autospawn-for-root:

sed: can't read src/client.conf: No such file or directory

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index cf4be7ed40..e40b8c1c40 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -133,7 +133,7 @@ set_cfg_value () {
 
 do_compile_append () {
if ${@bb.utils.contains('PACKAGECONFIG', 'autospawn-for-root', 'true', 
'false', d)}; then
-   set_cfg_value src/client.conf allow-autospawn-for-root yes
+   set_cfg_value src/pulse/client.conf allow-autospawn-for-root yes
fi
 }
 
-- 
2.20.1


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



Re: [OE-core] [yocto-security] OE-core CVE metrics for master on Sun 20 Dec 2020 07:15:01 AM HST

2020-12-21 Thread Richard Purdie
On Sun, 2020-12-20 at 07:24 -1000, Steve Sakoman wrote:
Branch: master
> CVE-2007-3387: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-3387 *
CVE-2007-4045: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4045 *
> CVE-2008-1033: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-1033 *
CVE-2008-1374: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-1374 *
> CVE-2009-0032: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0032 *
CVE-2010-3702: cups
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3702 *

In case anyone else is looking, I've marked two of these at
inappropriate in OE and asked the CPE have version restrictions added
for the other four.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146021): 
https://lists.openembedded.org/g/openembedded-core/message/146021
Mute This Topic: https://lists.openembedded.org/mt/79125623/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 0/4] pulseaudio: Autotools to Meson

2020-12-21 Thread Andrey Zhizhikin
Hello Tanu,

On Mon, Dec 21, 2020 at 2:25 PM Tanu Kaskinen  wrote:
>
> On Mon, 2020-12-21 at 14:03 +0100, Andrey Zhizhikin wrote:
> > Hello Tanu,
> >
> > On Sun, Dec 20, 2020 at 5:09 PM Khem Raj  wrote:
> > > On Sun, Dec 20, 2020 at 6:26 AM Tanu Kaskinen  wrote:
> > > > On Sat, 2020-12-19 at 12:36 -0800, Khem Raj wrote:
> > > > > On Sat, Dec 19, 2020 at 9:24 AM Khem Raj  wrote:
> > > > > > On Thu, Dec 17, 2020 at 11:28 AM Tanu Kaskinen  wrote:
> > > > > > > The PulseAudio project plans to drop Autotools support in 15.0, 
> > > > > > > so let's
> > > > > > > switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which 
> > > > > > > is
> > > > > > > some old cruft that sounds like it has something to do Libtool, 
> > > > > > > so it's
> > > > > > > perhaps relevant for the goal of dropping Autotools. The next two
> > > > > > > patches disable features that aren't available with Meson. The 
> > > > > > > last
> > > > > > > patch does the build system switch.
> > > > > > >
> > > > > > > Tanu Kaskinen (4):
> > > > > > >   pulseaudio: Remove OE_LT_RPATH_ALLOW
> > > > > > >   pulseaudio: disable EsounD support
> > > > > > >   pulseaudio: disable GConf support
> > > > > > >   pulseaudio: switch build system from Autotools to Meson
> >
> > I'm seeing a build failure after this upgrade, thought you might
> > advise here what could be wrong.
> >
> > Following is produced at the end of do_compile taks:
> >
> > > sed: can't read src/client.conf: No such file or directory
> > > WARNING: exit code 2 from a shell command.
> > >
> > ERROR: Task 
> > (/development/yocto-master/yocto-build-appliance/meta/recipes-multimedia/pulseaudio/pulseaudio_14.0.bb:do_compile)
> > failed with exit code '1'
> >
> > Have you experienced the same error, and what can be missing here?
>
> I can reproduce the error when enabling the autospawn-for-root
> PACKAGECONFIG. client.conf is generated from client.conf.in, and the
> generated file's location has changed. Replacing "src/client.conf" with
> "src/pulse/client.conf" in pulseaudio.inc seems to fix this issue.

Thanks, that solved the compilation issue!

>
> --
> Tanu
>


-- 
Regards,
Andrey.

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

2020-12-21 Thread Richard Purdie
On Mon, 2020-12-21 at 13:30 +, Peter Kjellerstedt wrote:
> I thought the process for backporting changes in OE-Core was:
> 
> master -> gatesgarth -> dunfell -> ...
> 
> However, I just noticed that the latest Gatesgarth release (24.0.1) 
> is still at 2020b of timezone, whereas Dunfell (23.0.4) has 2020d.
> Am I missing something here, or is this just a miss in communication?

We're working through what the processes mean in practise and there are
a few issues:

* Steve doesn't have the bandwidth to handle Gatesgarth and Dunfell
* Blocking Dunfell on Gatesgarth isn't fair to Steve or running the LTS

The intent is to keep both roughly in sync but I've not made it a
"hard" stop as it was just going to cause things to grind to a halt and
help nobody.

If people spot things like this please flag them up and we'll get them
resolved.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146023): 
https://lists.openembedded.org/g/openembedded-core/message/146023
Mute This Topic: https://lists.openembedded.org/mt/79125184/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 00/28] Patch review - pseudo file mode corruption fix series

2020-12-21 Thread Martin Jansa
Just curious, is this PR on hold or rejected completely?

I don't have strong opinion either way, I was just wondering about this one
when other newer PRs were already merged.

On Thu, Dec 3, 2020 at 4:08 PM Steve Sakoman  wrote:

> Issues with undetected file mode corruption in pseudo have been identified.
>
> Fixes have been merged into master and gatesgarth over the past couple of
> months and
> things seem to have stabilized enough that we can consider backporting
> these fixes
> to dunfell.
>
> This is a somewhat more invasive change than normal. Specifically the user
> will
> be required to clean TMPDIR after this merge. It may also expose issues
> with
> other layers, though master and gategarth have probably helped to pave the
> way for
> this change.
>
> Personally I think that this fixes a serious enough issue that we should
> consider
> this series for dunfell.
>
> Please have comments back by Monday morning.
>
> The following changes since commit
> 071806feb195961e59069f778c9ae8f27a739d9a:
>
>   e2fsprogs: Fix a ptest permissions determinism issue (2020-11-30
> 12:05:57 -1000)
>
> are available in the Git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
>
> http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut
>
> Jacob Kroon (1):
>   bitbake.conf: Remove TERM from default BB_HASHBASE_WHITELIST
>
> Joe Slater (1):
>   pseudo: fix renaming to self
>
> Martin Jansa (1):
>   base.bbclass: use os.path.normpath instead of just comparing WORKDIR
> and S as strings
>
> Mingli Yu (2):
>   tcl: adapt to potential pseudo changes
>   bitbake.conf: Exclude ${CCACHE_DIR} from pseudo database
>
> Ricardo Ribalda Delgado (3):
>   wic: Fix permissions when using exclude or include path
>   wic: Fix multi images .wks with bitbake
>   wic: Avoid creating invalid pseudo directory
>
> Richard Purdie (19):
>   pseudo: Switch to oe-core branch in git repo
>   pseudo: merge in fixes for setfacl issue
>   pseudo: Update to add OFC fcntl lock updates
>   pseudo: Ignore mismatched inodes from the db
>   pseudo: Add support for ignoring paths from the pseudo DB
>   pseudo: Abort on mismatch patch
>   psuedo: Add tracking of linked files for fds
>   pseudo: Fix xattr segfault
>   pseudo: Add may unlink patch
>   pseudo: Add pathfix patch
>   base/bitbake.conf: Enable pseudo path filtering
>   wic: Handle new PSEUDO_IGNORE_PATHS variable
>   pseudo: Fix statx function usage
>   bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
>   abi_version,sanity: Tell users TMPDIR must be clean after pseudo
> changes
>   pseudo: Update to account for patches merged on branch
>   pseudo: Upgrade to include mkostemp64 wrapper
>   oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
>   uninative: Don't use single sstate for pseudo-native
>
> Ross Burton (1):
>   devtool: remove unused variable
>
>  meta/classes/archiver.bbclass |   2 +-
>  meta/classes/base.bbclass |   6 +
>  meta/classes/image_types_wic.bbclass  |  12 +-
>  meta/classes/populate_sdk_base.bbclass|   2 +
>  meta/classes/sanity.bbclass   |   3 +
>  meta/classes/sstate.bbclass   |   4 +
>  meta/conf/abi_version.conf|   2 +-
>  meta/conf/bitbake.conf|  13 +-
>  meta/lib/oe/sstatesig.py  |   4 +-
>  meta/lib/oeqa/selftest/cases/runtime_test.py  |   1 +
>  .../pseudo/files/0001-Add-statx.patch | 106 --
>  ...001-maketables-wrappers-use-Python-3.patch |  34 -
>  ...ixup-remove-files-that-do-not-exist-.patch |  49 ---
>  .../0001-pseudo_ipc.h-Fix-enum-typedef.patch  |  31 
>  ...1-realpath.c-Remove-trailing-slashes.patch |  57 
>  ...xattr-adjust-for-attr-2.4.48-release.patch |  48 --
>  .../pseudo/files/moreretries.patch|  19 ---
>  .../pseudo/files/seccomp.patch| 137 --
>  .../pseudo/files/toomanyfiles.patch   |  71 -
>  .../pseudo/files/xattr_version.patch  |  54 ---
>  meta/recipes-devtools/pseudo/pseudo_git.bb|  14 +-
>  meta/recipes-devtools/tcltk/tcl_8.6.10.bb |   1 +
>  scripts/lib/devtool/standard.py   |   1 -
>  scripts/lib/wic/partition.py  |  23 +--
>  scripts/lib/wic/plugins/source/rootfs.py  |  37 -
>  scripts/postinst-intercepts/update_font_cache |   2 +
>  26 files changed, 89 insertions(+), 644 deletions(-)
>  delete mode 100644 meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
>  delete mode 100644
> meta/recipes-devtools/pseudo/files/0001-maketables-wrappers-use-Python-3.patch
>  delete mode 100644
> meta/recipes-devtools/pseudo/files/0001-pseudo-On-a-DB-fixup-remove-files-that-do-not-exist-.patch
>  delete mode 100644
> meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch
>  delete mode 100644
> meta/recipes-devtools/pseud

Re: [OE-core][dunfell 00/28] Patch review - pseudo file mode corruption fix series

2020-12-21 Thread Steve Sakoman
On Mon, Dec 21, 2020 at 4:33 AM Martin Jansa  wrote:
>
> Just curious, is this PR on hold or rejected completely?
>
> I don't have strong opinion either way, I was just wondering about this one 
> when other newer PRs were already merged.

This series is still actively being tested. I've been waiting for a
couple of related patches from master to hit before sending a v2.

If there are still no objections at that point I'll send a merge request.

Steve

> On Thu, Dec 3, 2020 at 4:08 PM Steve Sakoman  wrote:
>>
>> Issues with undetected file mode corruption in pseudo have been identified.
>>
>> Fixes have been merged into master and gatesgarth over the past couple of 
>> months and
>> things seem to have stabilized enough that we can consider backporting these 
>> fixes
>> to dunfell.
>>
>> This is a somewhat more invasive change than normal. Specifically the user 
>> will
>> be required to clean TMPDIR after this merge. It may also expose issues with
>> other layers, though master and gategarth have probably helped to pave the 
>> way for
>> this change.
>>
>> Personally I think that this fixes a serious enough issue that we should 
>> consider
>> this series for dunfell.
>>
>> Please have comments back by Monday morning.
>>
>> The following changes since commit 071806feb195961e59069f778c9ae8f27a739d9a:
>>
>>   e2fsprogs: Fix a ptest permissions determinism issue (2020-11-30 12:05:57 
>> -1000)
>>
>> are available in the Git repository at:
>>
>>   git://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
>>   
>> http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut
>>
>> Jacob Kroon (1):
>>   bitbake.conf: Remove TERM from default BB_HASHBASE_WHITELIST
>>
>> Joe Slater (1):
>>   pseudo: fix renaming to self
>>
>> Martin Jansa (1):
>>   base.bbclass: use os.path.normpath instead of just comparing WORKDIR
>> and S as strings
>>
>> Mingli Yu (2):
>>   tcl: adapt to potential pseudo changes
>>   bitbake.conf: Exclude ${CCACHE_DIR} from pseudo database
>>
>> Ricardo Ribalda Delgado (3):
>>   wic: Fix permissions when using exclude or include path
>>   wic: Fix multi images .wks with bitbake
>>   wic: Avoid creating invalid pseudo directory
>>
>> Richard Purdie (19):
>>   pseudo: Switch to oe-core branch in git repo
>>   pseudo: merge in fixes for setfacl issue
>>   pseudo: Update to add OFC fcntl lock updates
>>   pseudo: Ignore mismatched inodes from the db
>>   pseudo: Add support for ignoring paths from the pseudo DB
>>   pseudo: Abort on mismatch patch
>>   psuedo: Add tracking of linked files for fds
>>   pseudo: Fix xattr segfault
>>   pseudo: Add may unlink patch
>>   pseudo: Add pathfix patch
>>   base/bitbake.conf: Enable pseudo path filtering
>>   wic: Handle new PSEUDO_IGNORE_PATHS variable
>>   pseudo: Fix statx function usage
>>   bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
>>   abi_version,sanity: Tell users TMPDIR must be clean after pseudo
>> changes
>>   pseudo: Update to account for patches merged on branch
>>   pseudo: Upgrade to include mkostemp64 wrapper
>>   oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
>>   uninative: Don't use single sstate for pseudo-native
>>
>> Ross Burton (1):
>>   devtool: remove unused variable
>>
>>  meta/classes/archiver.bbclass |   2 +-
>>  meta/classes/base.bbclass |   6 +
>>  meta/classes/image_types_wic.bbclass  |  12 +-
>>  meta/classes/populate_sdk_base.bbclass|   2 +
>>  meta/classes/sanity.bbclass   |   3 +
>>  meta/classes/sstate.bbclass   |   4 +
>>  meta/conf/abi_version.conf|   2 +-
>>  meta/conf/bitbake.conf|  13 +-
>>  meta/lib/oe/sstatesig.py  |   4 +-
>>  meta/lib/oeqa/selftest/cases/runtime_test.py  |   1 +
>>  .../pseudo/files/0001-Add-statx.patch | 106 --
>>  ...001-maketables-wrappers-use-Python-3.patch |  34 -
>>  ...ixup-remove-files-that-do-not-exist-.patch |  49 ---
>>  .../0001-pseudo_ipc.h-Fix-enum-typedef.patch  |  31 
>>  ...1-realpath.c-Remove-trailing-slashes.patch |  57 
>>  ...xattr-adjust-for-attr-2.4.48-release.patch |  48 --
>>  .../pseudo/files/moreretries.patch|  19 ---
>>  .../pseudo/files/seccomp.patch| 137 --
>>  .../pseudo/files/toomanyfiles.patch   |  71 -
>>  .../pseudo/files/xattr_version.patch  |  54 ---
>>  meta/recipes-devtools/pseudo/pseudo_git.bb|  14 +-
>>  meta/recipes-devtools/tcltk/tcl_8.6.10.bb |   1 +
>>  scripts/lib/devtool/standard.py   |   1 -
>>  scripts/lib/wic/partition.py  |  23 +--
>>  scripts/lib/wic/plugins/source/rootfs.py  |  37 -
>>  scripts/postinst-intercepts/update_font_cache |   2 +
>>  26 files changed, 89 insertions(+), 644 deletions(-)
>>  delete mode 100644 meta/recipes-devtools/pseudo/files/0001-

[OE-core] [PATCH] groff: Fix reproducibility issue

2020-12-21 Thread Richard Purdie
groff chooses a default papersize depending on the value from /etc/papersize
and failing that, the search domain in /etc/resolv.conf based on the comment
in configure:

"""
"""

Oddly, my system sets to "a4" in /etc/papersize which means it defaults to
"letter" since its != "A4".

These defaults ripple through to cause the output of man-db to change depending
on which default value was selected.

To resolve this, set a default of "A4" since that covers the larger population
of the two default values.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/groff/groff_1.22.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/groff/groff_1.22.4.bb 
b/meta/recipes-extended/groff/groff_1.22.4.bb
index e3984783496..0867452ce7b 100644
--- a/meta/recipes-extended/groff/groff_1.22.4.bb
+++ b/meta/recipes-extended/groff/groff_1.22.4.bb
@@ -28,7 +28,7 @@ MULTILIB_SCRIPTS = "${PN}:${bindir}/gpinyin 
${PN}:${bindir}/groffer ${PN}:${bind
 EXTRA_OECONF = "--without-x --without-doc"
 PARALLEL_MAKE = ""
 
-CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
ac_cv_path_BASH_PROG='no'"
+CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
ac_cv_path_BASH_PROG='no' PAGE=A4"
 
 do_install_append() {
# Some distros have both /bin/perl and /usr/bin/perl, but we set perl 
location
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146026): 
https://lists.openembedded.org/g/openembedded-core/message/146026
Mute This Topic: https://lists.openembedded.org/mt/79130441/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] groff: Fix reproducibility issue

2020-12-21 Thread Richard Purdie
groff chooses a default papersize depending on the value from /etc/papersize
and failing that, the search domain in /etc/resolv.conf based on the comment
in configure:

"""
If the top-level domain is two letters and it's not 'us' or 'ca'
then they probably use A4 paper.
"""

Oddly, my system sets to "a4" in /etc/papersize which means it defaults to
"letter" since its != "A4".

These defaults ripple through to cause the output of man-db to change depending
on which default value was selected.

To resolve this, set a default of "A4" since that covers the larger population
of the two default values.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/groff/groff_1.22.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/groff/groff_1.22.4.bb 
b/meta/recipes-extended/groff/groff_1.22.4.bb
index e3984783496..0867452ce7b 100644
--- a/meta/recipes-extended/groff/groff_1.22.4.bb
+++ b/meta/recipes-extended/groff/groff_1.22.4.bb
@@ -28,7 +28,7 @@ MULTILIB_SCRIPTS = "${PN}:${bindir}/gpinyin 
${PN}:${bindir}/groffer ${PN}:${bind
 EXTRA_OECONF = "--without-x --without-doc"
 PARALLEL_MAKE = ""
 
-CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
ac_cv_path_BASH_PROG='no'"
+CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
ac_cv_path_BASH_PROG='no' PAGE=A4"
 
 do_install_append() {
# Some distros have both /bin/perl and /usr/bin/perl, but we set perl 
location
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146027): 
https://lists.openembedded.org/g/openembedded-core/message/146027
Mute This Topic: https://lists.openembedded.org/mt/79130441/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] How to set the password Hashing Algorithm for root user to SHA256 or SHA512

2020-12-21 Thread Sourabh Banerjee

On 2020-12-20 10:16, Khem Raj wrote:

On Sat, Dec 19, 2020 at 11:58 AM Sourabh Banerjee
 wrote:


[Edited Message Follows]

The image I generated seems to use MD5 for root password hashing.
I understood this from the /etc/shadow file in the image., the file 
has following line:


root:$1$b7X30f8f$au21weqL.9.ExM4N84AtA0:18614:0:9:7:::

Is there an OE config I can change to change password hashing from MD5 
to SHA256?




somewhere you must be setting the password something like this in 
local.conf


EXTRA_USERS_PARAMS += "\
useradd admin; \
usermod -p 'XX' admin; \
"

Now how you generate the password could be done separately via

something like ( for setting password to me 'test' )

python3 -c 'import crypt; print(crypt.crypt("test",
crypt.mksalt(crypt.METHOD_SHA256)))'

Replace XX with the output of the above cmd

aside from this its perhaps better to use sha512 than sha256


I am using Thud version.

--
Regards,
Sourabh





Thanks Khem! I will try this and get back.


--
Regards,
Sourabh

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146028): 
https://lists.openembedded.org/g/openembedded-core/message/146028
Mute This Topic: https://lists.openembedded.org/mt/79070438/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] groff: Fix reproducibility issue

2020-12-21 Thread Steve Sakoman
On Mon, Dec 21, 2020 at 7:32 AM Richard Purdie
 wrote:
>
> groff chooses a default papersize depending on the value from /etc/papersize
> and failing that, the search domain in /etc/resolv.conf based on the comment
> in configure:
>
> """
> If the top-level domain is two letters and it's not 'us' or 'ca'
> then they probably use A4 paper.
> """
>
> Oddly, my system sets to "a4" in /etc/papersize which means it defaults to
> "letter" since its != "A4".
>
> These defaults ripple through to cause the output of man-db to change 
> depending
> on which default value was selected.

Nice catch!  I just ran into the man-db reproducibility error this
morning while testing dunfell world reproducibility.  Now I can remove
man-db from the exclusion list :-)

Steve

> To resolve this, set a default of "A4" since that covers the larger population
> of the two default values.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-extended/groff/groff_1.22.4.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/groff/groff_1.22.4.bb 
> b/meta/recipes-extended/groff/groff_1.22.4.bb
> index e3984783496..0867452ce7b 100644
> --- a/meta/recipes-extended/groff/groff_1.22.4.bb
> +++ b/meta/recipes-extended/groff/groff_1.22.4.bb
> @@ -28,7 +28,7 @@ MULTILIB_SCRIPTS = "${PN}:${bindir}/gpinyin 
> ${PN}:${bindir}/groffer ${PN}:${bind
>  EXTRA_OECONF = "--without-x --without-doc"
>  PARALLEL_MAKE = ""
>
> -CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
> ac_cv_path_BASH_PROG='no'"
> +CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl' 
> ac_cv_path_BASH_PROG='no' PAGE=A4"
>
>  do_install_append() {
> # Some distros have both /bin/perl and /usr/bin/perl, but we set perl 
> location
> --
> 2.27.0
>
>
> 
>

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

2020-12-21 Thread Peter Kjellerstedt
> -Original Message-
> From: Richard Purdie 
> Sent: den 21 december 2020 15:10
> To: Peter Kjellerstedt ; OE Core
> (openembedded-core@lists.openembedded.org)  c...@lists.openembedded.org>
> Cc: Anuj Mittal ; Steve Sakoman
> 
> Subject: Re: [OE-core] Process for backports
> 
> On Mon, 2020-12-21 at 13:30 +, Peter Kjellerstedt wrote:
> > I thought the process for backporting changes in OE-Core was:
> >
> > master -> gatesgarth -> dunfell -> ...
> >
> > However, I just noticed that the latest Gatesgarth release (24.0.1)
> > is still at 2020b of timezone, whereas Dunfell (23.0.4) has 2020d.
> > Am I missing something here, or is this just a miss in communication?
> 
> We're working through what the processes mean in practise and there are
> a few issues:
> 
> * Steve doesn't have the bandwidth to handle Gatesgarth and Dunfell
> * Blocking Dunfell on Gatesgarth isn't fair to Steve or running the LTS
>
> The intent is to keep both roughly in sync but I've not made it a
> "hard" stop as it was just going to cause things to grind to a halt and
> help nobody.
> 
> If people spot things like this please flag them up and we'll get them
> resolved.

Consider timezone flagged. ;)
 
> Cheers,
> 
> Richard

//Peter


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



Re: [OE-core] [yocto-security] [PATCH] openssl: drop support for deprecated algorithms

2020-12-21 Thread Mark Hatle


On 12/19/20 12:04 PM, Konrad Weihmann wrote:
> 
> 
> On 19.12.20 18:58, Richard Purdie wrote:
>> On Sat, 2020-12-19 at 18:53 +0100, Konrad Weihmann wrote:
>>> On 19.12.20 18:36, Richard Purdie wrote:
PACKAGECONFIG[cryptodev-linux] = 
 "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
 +PACKAGECONFIG[no-tls1] = "no-tls1"
 +PACKAGECONFIG[no-tls1_1] = "no-tls1_1"

B = "${WORKDIR}/build"
do_configure[cleandirs] = "${B}"
 @@ -52,6 +54,10 @@ EXTRA_OECONF_class-nativesdk = 
 "--with-rand-seed=os,devrandom"
CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin 
 -DENGINESDIR=/not/builtin"
CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
 -DENGINESDIR=/not/builtin"

 +# Disable deprecated crypto algorithms
 +# Retained for compatibilty - des (curl), dh (python-ssl), dsa (rpm)
 +DEPRECATED_CRYPTO_FLAGS = " no-ssl no-idea no-psk no-rc2 no-rc4 no-rc5 
 no-md2 no-md4 no-srp no-camellia no-bf no-mdc2 no-scrypt no-seed 
 no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
 +
>>>   From my perspective this breaks backward compatibility, so I would
>>> rather have them all that as optional PACKAGECONFIG fields (which also
>>> does make it easier for ppl, still relying on one of those algorithms,
>>> for whatever reason, to re-enable them) - with the current approach all
>>> one could do is to override it with a bbappend - and tbh letting ppl
>>> have bbappends for this recipe, doesn't sound like the best idea in the
>>> long run to "enforce" any kind of "security" or "hardening"
>>
>> Having it as a variable does mean you could customise the variable and
>> doesn't mean it has to be done with a bbappend, it can be set from a
>> distro config too.
>>
>> I'm not sure turning each one into a packageconfig is going to be more
>> helpful compared to this in practise...
> 
> I'm not sure I follow, as this is a "hard" assign - if it would (in 
> theory) a ??= assignment, yes then it would be fine. Still that leaves 
> us with a not commonly known variable, while PACKAGECONFIG is more 
> widely accepted in 3rd party layers/distros from my experience.

In the past I had done something similar w/ PACKAGECONFIG, and then had a
comment in the recipe that indicated that certain items were not recommended
with a link to the OpenSSL documentation where it explained that.

It might also be a reasonable idea (security wise, maybe not OE wise) to display
a bb.warn if one of the 'unsafe' crypto algorithms is enabled.

As for someone mentioning that it's unclear if we should be maintaining a list,
in the past there was a list in the OpenSSL documentation.  I would certainly
rely on that list as what should and should not be enabled by default (with
exceptions as appropriate.)

--Mark

>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> 
>>

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



Re: [OE-core] [yocto-security] [PATCH] openssl: drop support for deprecated algorithms

2020-12-21 Thread Andre McCurdy
On Sat, Dec 19, 2020 at 4:08 PM Richard Purdie
 wrote:
>
> On Sat, 2020-12-19 at 19:04 +0100, Konrad Weihmann wrote:
> >
> > On 19.12.20 18:58, Richard Purdie wrote:
> > > On Sat, 2020-12-19 at 18:53 +0100, Konrad Weihmann wrote:
> > > > On 19.12.20 18:36, Richard Purdie wrote:
> > > > >PACKAGECONFIG[cryptodev-linux] = 
> > > > > "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
> > > > > +PACKAGECONFIG[no-tls1] = "no-tls1"
> > > > > +PACKAGECONFIG[no-tls1_1] = "no-tls1_1"
> > > > >
> > > > >B = "${WORKDIR}/build"
> > > > >do_configure[cleandirs] = "${B}"
> > > > > @@ -52,6 +54,10 @@ EXTRA_OECONF_class-nativesdk = 
> > > > > "--with-rand-seed=os,devrandom"
> > > > >CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin 
> > > > > -DENGINESDIR=/not/builtin"
> > > > >CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
> > > > > -DENGINESDIR=/not/builtin"
> > > > >
> > > > > +# Disable deprecated crypto algorithms
> > > > > +# Retained for compatibilty - des (curl), dh (python-ssl), dsa (rpm)
> > > > > +DEPRECATED_CRYPTO_FLAGS = " no-ssl no-idea no-psk no-rc2 no-rc4 
> > > > > no-rc5 no-md2 no-md4 no-srp no-camellia no-bf no-mdc2 no-scrypt 
> > > > > no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
> > > > > +
> > > >   From my perspective this breaks backward compatibility, so I would
> > > > rather have them all that as optional PACKAGECONFIG fields (which also
> > > > does make it easier for ppl, still relying on one of those algorithms,
> > > > for whatever reason, to re-enable them) - with the current approach all
> > > > one could do is to override it with a bbappend - and tbh letting ppl
> > > > have bbappends for this recipe, doesn't sound like the best idea in the
> > > > long run to "enforce" any kind of "security" or "hardening"
> > >
> > > Having it as a variable does mean you could customise the variable and
> > > doesn't mean it has to be done with a bbappend, it can be set from a
> > > distro config too.
> > >
> > > I'm not sure turning each one into a packageconfig is going to be more
> > > helpful compared to this in practise...
> >
> > I'm not sure I follow, as this is a "hard" assign - if it would (in
> > theory) a ??= assignment, yes then it would be fine. Still that leaves
> > us with a not commonly known variable, while PACKAGECONFIG is more
> > widely accepted in 3rd party layers/distros from my experience.
>
> You could do various things to this from a distro config, e.g.:
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl = "xxx"
>
> or
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_ = "xxx"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_append = " extra-disable"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_remove = "add-me-back"
>
> so I'd say that its not a particularly "hard" assignment?
>
> We could make it a ??= but I'm not sure it would change much practcial
> use as it would almost always be with an override of some sort?
>
> Whilst PACKAGECONFIG is more well known,the variable name here may
> actually improve readability...

Does it? It just looks like an extension of a definition of
PACKAGECONFIG but with the logic all reversed (e.g. instead of adding
FOO to PACKAGECONFIG to enable support for something we now have to
add no-FOO to the new custom variable to disable something). Inverting
the logic of all the options makes it closer to the semantics expected
by the openssl configure scripts, but makes it further from the
semantics expected by someone using OE to configure a package (who is
presumably used to the "add FOO to PACKAGECONFIG to enable something"
convention).

Converting all these options to individual PACKAGECONFIG options but
not adding them to the default value PACKAGECONFIG seems like the
better approach. Users who need to enable a particular algorithm can
then add it to PACKAGECONFIG in the usual way.

In general, disabling old or unused algorithms by default is a good
change though.

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



[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2020-12-21 Thread Stephen Jolley
All,

 

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

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146033): 
https://lists.openembedded.org/g/openembedded-core/message/146033
Mute This Topic: https://lists.openembedded.org/mt/79139598/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] run-postinsts: fix setting pi_dir

2020-12-21 Thread Trevor Woerner
The pi_dir variable isn't being set properly; it gets set to the value of the
*previous* package manager. Given the order of "rpm deb ipk", if the script
determines that the package manager is "ipk", pi_dir remains set at
SYSCONFDIR/deb-postinsts.

Signed-off-by: Trevor Woerner 
---
 meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts 
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index f84a7e18c8..c10fd11e9d 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -20,14 +20,12 @@ for pm in $backend_list; do
"deb")
if [ -s "#LOCALSTATEDIR#/lib/dpkg/status" ]; then
pm_installed=true
-   break
fi
;;
 
"ipk")
if [ -s "#LOCALSTATEDIR#/lib/opkg/status" ]; then
pm_installed=true
-   break
fi
;;
esac
-- 
2.30.0.rc0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146034): 
https://lists.openembedded.org/g/openembedded-core/message/146034
Mute This Topic: https://lists.openembedded.org/mt/79144452/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/2] sysvinit/rc: show text progress

2020-12-21 Thread Trevor Woerner
In addition to the progress bar, show which startup routine is running by
using the "MSG" facility of psplash.

Signed-off-by: Trevor Woerner 
---
 meta/recipes-core/sysvinit/sysvinit/rc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit/rc 
b/meta/recipes-core/sysvinit/sysvinit/rc
index d0d3149821..6995930ee9 100755
--- a/meta/recipes-core/sysvinit/sysvinit/rc
+++ b/meta/recipes-core/sysvinit/sysvinit/rc
@@ -27,6 +27,7 @@ startup_progress() {
 fi
 #echo "PROGRESS is $progress $runlevel $first_step + ($step of $num_steps) 
$step_change $progress_size"
 if type psplash-write >/dev/null 2>&1; then
+PSPLASH_FIFO_DIR=/mnt/.psplash psplash-write "MSG $(basename $1 .sh | 
cut -c 4-)" || true
 PSPLASH_FIFO_DIR=/mnt/.psplash psplash-write "PROGRESS $progress" || 
true
 fi
 }
@@ -53,7 +54,7 @@ startup() {
"$@"
;;
   esac
-  startup_progress
+  startup_progress "$1"
 }
 
   # Ignore CTRL-C only in this shell, so we can interrupt subprocesses.
-- 
2.30.0.rc0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146035): 
https://lists.openembedded.org/g/openembedded-core/message/146035
Mute This Topic: https://lists.openembedded.org/mt/79144527/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/2] sysvinit/rc: show text progress

2020-12-21 Thread Trevor Woerner
Oops, there is no 2/2, this is a singular patch.
Should I resend?

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