Date   

Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Armin Kuster
 



On 4/15/20 3:25 PM, Paul Eggleton wrote:
Release notes draft attached, including a dedication to Scott (wasn't sure where to put that so I've just left it at the top) and contributors list. Let me know if you notice anything missing/incorrect. 
Thanks for pulling this together.

I've also sent out the 3.1 migration guide for the reference manual, Richard has just merged the changes:
I see the review window is down to an hour before merging. Is code review by twitter the next new thing ; )

 I responded the patches on the docs list.

- armin


  http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=c31ddaba1f3181c577fdaa3ce519a42b6f8f2d9a

Publishing to the website is still TBD, but some review there would be great as well.

Cheers,
Paul


    


Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Paul Eggleton
 

Release notes draft attached, including a dedication to Scott (wasn't sure where to put that so I've just left it at the top) and contributors list. Let me know if you notice anything missing/incorrect.

I've also sent out the 3.1 migration guide for the reference manual, Richard has just merged the changes:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=c31ddaba1f3181c577fdaa3ce519a42b6f8f2d9a

Publishing to the website is still TBD, but some review there would be great as well.

Cheers,
Paul


Re: Guidance Downgrading Python2 in Zeus #python

Sean McKay
 

FYI, we’re doing the same internally (vendor supplied FIPS supported openssl 1.0.2), and the layer Armin suggests worked for us on zeus with minimal additional tweaking.

 

Good luck!

-Sean

 

From: yocto@... <yocto@...> On Behalf Of akuster
Sent: Wednesday, April 15, 2020 9:23 AM
To: MikeB <mabnhdev@...>; yocto@...
Subject: Re: [yocto] Guidance Downgrading Python2 in Zeus #python

 

 

On 4/15/20 9:16 AM, MikeB wrote:

I'm working on a set of platforms that have a FIPs certified OpenSSL.  We are at version 1.0.2l.

I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).

We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).

I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).

I know how to downgrade simple recipes, but python is far from simple.

Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?


Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/

- armin


Thanks, Mike

 

 


Re: Guidance Downgrading Python2 in Zeus #python

Armin Kuster
 



On 4/15/20 9:16 AM, MikeB wrote:
I'm working on a set of platforms that have a FIPs certified OpenSSL.  We are at version 1.0.2l.

I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).

We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).

I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).

I know how to downgrade simple recipes, but python is far from simple.

Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?

Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/

- armin

Thanks, Mike

    


Re: Guidance Downgrading Python2 in Zeus #python

Alexander Kanavin
 

I think python2 *recipe* requires openssl 1.1, but python2 itself will work just fine with openssl 1.0. So you only need to adjust the dependency, there are several ways to do that.

Alex


On Wed, 15 Apr 2020 at 18:16, MikeB <mabnhdev@...> wrote:
I'm working on a set of platforms that have a FIPs certified OpenSSL.  We are at version 1.0.2l.

I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).

We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).

I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).

I know how to downgrade simple recipes, but python is far from simple.

Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?

Thanks, Mike


Guidance Downgrading Python2 in Zeus #python

MikeB
 

I'm working on a set of platforms that have a FIPs certified OpenSSL.  We are at version 1.0.2l.

I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).

We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).

I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).

I know how to downgrade simple recipes, but python is far from simple.

Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?

Thanks, Mike


Re: Image size reduction

Randy MacLeod
 

On 2020-04-14 11:51 a.m., Ajam Ali wrote:
Hi Randy,
In my image most of the size is consumed by heavy size packages.
So i have given this task of image size reduction to application team.
If i will remove the dependencies then may be some feature get disabled which could be needed.
Till now i am able to remove only python3 from dependencies.
Thanks for the summary Ajam.
../Randy


Thanks,
Ajam Ali
------------------------------------------------------------------------
*From:* Randy MacLeod <randy.macleod@...>
*Sent:* Monday, April 13, 2020 11:18 PM
*To:* Ajam Ali <AjamA@...>; yocto@... <yocto@...>; gley-yocto@m.gmane-mx.org <gley-yocto@m.gmane-mx.org>
*Subject:* Re: [yocto] Image size reduction
**[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]
On 2020-04-04 12:27 p.m., Ajam Ali wrote:
Hi All,

Thanks for your suggestions. I am working on your suggestions.
I will let you know if it did not work for me.
Ajam,
It would be useful if you could reply either way.
If there's still a problem then perhaps someone can help.
If you are able to resolve the issue, then a brief summary
of what you did could help the next person who has a similar
issue.
Thanks,
../Randy



Regards,
Ajam Ali


------------------------------------------------------------------------
*From:* yocto@... <mailto:yocto@...> <yocto@...> <mailto:yocto@...> on behalf of Gmane Admin via lists.yoctoproject.org <gley-yocto=m.gmane-mx.org@...> <mailto:gley-yocto=m.gmane-mx.org@...>
*Sent:* Saturday, April 4, 2020 9:36 PM
*To:* yocto@... <mailto:yocto@...> <yocto@...> <mailto:yocto@...>
*Subject:* Re: [yocto] Image size reduction
[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Op 29-03-2020 om 18:28 schreef Ajam Ali:
Hi All,

Actually my current image size is 3.9GB because of heavy size packages
required by my project and without project required packages my image
size in Yocto is 800MB.
So your project adds 3.1GB right

I want to reduce the image size as maximum as possible.
3.1GB is huge. Compare to f.i. Libreoffice (installed 0.5GB or so).
Either your own code has a lot of fat, or you are pulling in lots of
packages you don't really need. But is there no way to advise you
without knowing more.

Please suggest the best possible way so that I could reduce the maximum
possible size(desirable below 1.5 GB).


Thanks in advance,
Ajam Ali


Sent from Outlook Mobile <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fblhgte&;data=02%7C01%7Cajama%40hcl.com%7Cf719cb14fe674f86f02408d7d8b236b0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637216132261322392&amp;sdata=8in2t%2B6mXtrsRwa7GmgGQDl69uRzL7g4smj%2Ba3QG9gU%3D&amp;reserved=0
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fblhgte&data=02%7C01%7Cajama%40hcl.com%7C128e3933213f473fc34a08d7dfd2da33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637223969041569087&sdata=gY%2FoAEw1u9iOH8l9146xlNknKSslGAhehsRsWa83%2F10%3D&reserved=0>>
::DISCLAIMER::
------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
may contain viruses in transmission. The e mail and its contents (with
or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior
written consent of authorized representative of HCL is strictly
prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.
------------------------------------------------------------------------




--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Vineela
 

Hello Richard,

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Richard Purdie
Sent: Tuesday, April 14, 2020 2:12 PM
To: Jain, Sangeeta <sangeeta.jain@...>; yocto@...; Tummalapalli, Vineela <vineela.tummalapalli@...>; Paul Eggleton <bluelightning@...>
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv <apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>; akuster808@...; sjolley.yp.pm@...
Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc2)

Hi Sangeeta/Vineela,

On Sat, 2020-04-11 at 07:26 +0000, Jain, Sangeeta wrote:
This is the full report for yocto-3.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/t
ree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Note: Few failures are observed. These are setup issue since running
tests remotely, not real yocto issue.
Thanks for the QA run!

The TSC met today and this was one of the topics discussed. We would have time for another build and QA run but none of the queued changes or open bugs appear to be significant enough to warrant that.

We'd therefore like to proceed to release rc2 which will be slightly ahead of schedule and aim to have a prompt point release thereafter with the inevitable fixes as people start using it.

Paul (cc'd) is working on the release notes which is a ton of work and much appreciated, thanks Paul.

Vineela: Could you prepare the release so we're ready when we have the release notes please?
[Vineela]: Thank you for the update. Yes I'm preparing the release. After we get release notes, I have to get the testreport and release notes reviewed and approved by TSC. Once reviewed and approved, will get the tagging done and will be ready for the release announcement.
---
We're also pleased to say we do have an LTS maintainer lined up and that should be announced soon.

Cheers,

Richard


Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Richard Purdie
 

Hi Sangeeta/Vineela,

On Sat, 2020-04-11 at 07:26 +0000, Jain, Sangeeta wrote:
This is the full report for yocto-3.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Note: Few failures are observed. These are setup issue since running
tests remotely, not real yocto issue.
Thanks for the QA run!

The TSC met today and this was one of the topics discussed. We would
have time for another build and QA run but none of the queued changes
or open bugs appear to be significant enough to warrant that.

We'd therefore like to proceed to release rc2 which will be slightly
ahead of schedule and aim to have a prompt point release thereafter
with the inevitable fixes as people start using it.

Paul (cc'd) is working on the release notes which is a ton of work and
much appreciated, thanks Paul.

Vineela: Could you prepare the release so we're ready when we have the
release notes please?

We're also pleased to say we do have an LTS maintainer lined up and
that should be announced soon.

Cheers,

Richard


Re: [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

Bruce Ashfield
 

On Tue, Apr 14, 2020 at 12:02 PM Joshua Watt <JPEWhacker@...> wrote:


On 4/14/20 10:48 AM, Khem Raj wrote:
On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt <JPEWhacker@...> wrote:
Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend
I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs

[1] https://github.com/superna9999/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb
My goal here was to minimize the maintenance required for this BSP layer
to get newer kernels. Using the linux-yocto kernel in OE-core is quite
simple (as this patch shows) and allows us to piggyback off of Bruce's
work to keep everything up to date. While it is possible that OE-core
accidentally breaks something in this layer with a kernel update, it
seems likely this would be pretty rare and would probably require less
overall work than maintaining our own kernel recipes, particularly for
the set of boards in this BSP which have really good and stable support
in the kernel.
You replied faster than I could, so I turfed my answer! See below.


I think it should be possible to easily track the upstream vanilla
kernel branches in the linux-yocto recipe, and Bruce has done some work
to make this easier, but I think there might need to be little more work
in that area before it's completely ready to go.
Everything is good go to go, and I can point out what has been in place
for a while: linux-yocto master is tracking mainline maser. No changes
and linux-yocto v<x.y>/base tracks -stable, no changes.

If you want to pick up the bare minimum of boot fixes, or some of the
filesystem features v<x.y>/standard/base.
Any significant bsp or board changes are always isolated in their own branch.

As Joshua said, chasing a bunch of different versions (even if they are
all pointing to the same upstream, (linux-yocto included)) does mean
that there is variance, duplicated sanity and the need to chuck patches
around. i.e. you'll get all the CVEs (that could be outside of
-stable), -stable,
etc, at the same pace as other boards. I don't see that as a bad thing, but
of course, opinions vary :D

If it makes things even easier, I could create a linux-yocto-mainline
(recipe name off the top of my head) and it would just be the linux-yocto
recipe pointing KBRANCH to master, or v<x.y>/base, no other changes.
I'm sensitive to creating too many kernel recipes since it then becomes
more confusing to pick the right thing .. but doing it the way I mention means
that the breakage/QA/update follows the linux-yocto jumps and is very little
extra effort.

Cheers,

Bruce


diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc

-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings

# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"

# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-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 <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- 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 c812872d7f9d..65a9b9e5b8a6
---- 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.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
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


Re: [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

Joshua Watt
 

On 4/14/20 10:48 AM, Khem Raj wrote:
On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt <JPEWhacker@...> wrote:
Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend
I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs

[1] https://github.com/superna9999/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb
My goal here was to minimize the maintenance required for this BSP layer to get newer kernels. Using the linux-yocto kernel in OE-core is quite simple (as this patch shows) and allows us to piggyback off of Bruce's work to keep everything up to date. While it is possible that OE-core accidentally breaks something in this layer with a kernel update, it seems likely this would be pretty rare and would probably require less overall work than maintaining our own kernel recipes, particularly for the set of boards in this BSP which have really good and stable support in the kernel.


I think it should be possible to easily track the upstream vanilla kernel branches in the linux-yocto recipe, and Bruce has done some work to make this easier, but I think there might need to be little more work in that area before it's completely ready to go.

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc

-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings

# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"

# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-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 <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- 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 c812872d7f9d..65a9b9e5b8a6
---- 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.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
2.17.1


Re: Files get sporadically lost for native packages

Michael Halstead
 

During a recent data center move mail permissions were not carried over correctly. I've sorted this now and bugzilla e-mail should start arriving shortly. If you don't receive e-mail as expected please make another attempt. If problems persist reach out to me directly for support.

Thank you,
Michael Halstead
SysAdmin / Yocto Project

On Mon, Apr 13, 2020 at 11:17 AM Alexander Kanavin <alex.kanavin@...> wrote:
Adding Michael (lack of confirmtation email from bugzilla).

Alex

On Mon, 13 Apr 2020 at 19:59, Konrad Weihmann <kweihmann@...> wrote:
Hi Randy,

I'm trying all day to create an account at bugzilla to file the issue,
but somehow I don't get any confirmation mail  (although I tried several
mail accounts today, and no it didn't got stuck in spam;-)) - guess
that's not how it is supposed to be, right :-)? - I don't know where to
address such a problem, so take this reply as FYI.

Best
Konrad

On 03.04.20 21:28, Randy MacLeod wrote:
> On 2020-04-02 4:44 a.m., Konrad Weihmann wrote:
>>
>> To answer your others questions... see below
>>
>> On 02.04.20 05:42, Randy MacLeod wrote:
>>> On 2020-03-28 8:26 a.m., Konrad Weihmann wrote:
>>>> Hi,
>>>>
>>>> I'm facing the following error message sporadically on all branches
>>>> I tried so far (master, zeus, warrior and thud)
>>>>
>>>> The stack trace of python calls that resulted in this
>>>> exception/failure was:
>>>> File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
>>>>       0001:
>>>>   *** 0002:extend_recipe_sysroot(d)
>>>>       0003:
>>>> File: '/build/poky/meta/classes/staging.bbclass', lineno: 551,
>>>> function: extend_recipe_sysroot
>>>>       0547:                    dest = newmanifest[l]
>>>>       0548:                    if l.endswith("/"):
>>>>       0549:                        staging_copydir(l, targetdir,
>>>> dest, seendirs)
>>>>       0550:                        continue
>>>>   *** 0551:                    staging_copyfile(l, targetdir, dest,
>>>> postinsts, seendirs)
>>>>       0552:
>>>>       0553:    bb.note("Installed into sysroot: %s" % str(msg_adding))
>>>>       0554:    bb.note("Skipping as already exists in sysroot: %s" %
>>>> str(msg_exists))
>>>>       0555:
>>>> File: '/build/poky/meta/classes/staging.bbclass', lineno: 152,
>>>> function: staging_copyfile
>>>>       0148:        os.symlink(linkto, dest)
>>>>       0149:        #bb.warn(c)
>>>>       0150:    else:
>>>>       0151:        try:
>>>>   *** 0152:            os.link(c, dest)
>>>>       0153:        except OSError as err:
>>>>       0154:            if err.errno == errno.EXDEV:
>>>>       0155:                bb.utils.copyfile(c, dest)
>>>>       0156:            else:
>>>> Exception: FileNotFoundError: [Errno 2] No such file or directory:
>>>> '/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'
>>>> ->
>>>> '/build/poky/build/tmp/work/qemux86_64-mine-linux/core-image-minimal-mine/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'
>>>>
>>>> I already had a look at the manifest
>>>>
>>>> cat manifest-x86_64-python3-msgcheck-native.populate_sysroot
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/python3-msgcheck-native
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>>
>>>>
>>>> which states the file should be there, but when doing
>>>>
>>>> find
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share
>>>>
>>>>
>>>> the file isn't there.
>>>>
>>>> This happens to random python packages compiled as native (sometimes
>>>> even for python-native itself), but (afaik) not for cross or target
>>>> packages (I'm pretty sure because of the different packaging applied).
>>>> So I digged a little into the code
>>>> classes/sstate.bbclass:sstate_install, which seems to create the
>>>> sysroot-component dir and the manifest.
>>>> There is a gap between the manifest creation (line 285) and the
>>>> hardlinking (line till 311).
>>>>
>>>> Now my question is there any place where a file potentially could
>>>> get lost? - at first glance there shouldn't be one - I have to admit
>>>> that I don't fully understand all this subprocess magic in
>>>> lib/oe/path.py:copyhardlinktree.
>>>> What I do to fix the issue is reopening the manifest and double
>>>> check for missing files and remove them from the manifest, but this
>>>> feels wrong - so any advise is welcome...
>>>>
>>>> Hope that someone more familiar with the topic could have a look.
>>>
>>> Hi Konrad,
>>>
>>> I'm not really familiar with that code but it's being run buy 1000s of
>>> builder around the world so let's try to eliminate a few possibilities.
>>>
>>> When did you start having this problem?
>> Since the start of the test distribution I'm working on. But also for
>> plain poky builds if I forcefully inject all of the python-native
>> site-packages via local.conf (DEPENDS_class-native += "..."), without
>> actually using them in the recipe scope
>>> How often do you think it's happening: 1 in 3 builds, 1 in 10?
>> See the other mail - looks like it heavily depends on the host
>>> Tell us about your machine: OS,version, disk, CPUs, ram
>> See the other mail
>>> Do you do anything special in your conf dir? Send local.conf perhaps.
>> No custom modification (just for testing the DEPENDS-injection)
>>> Do you have any local bbappends or commits on top of poky or
>>> in other layers?
>> No
>>> Have you tried to simplify the build to eliminate problems
>>> potentially caused by other layers?
>> I did - see above
>>> Are you able to reproduce the problem on more than one build machine?
>> See the other mail
>>> Are you able to reproduce the problem on a different Linux distro?
>> Not really - Debian 9 was fine all other Hosts are Ubuntu based
>>> Are there other builds or users on the machine that may be causing
>>> extra load?
>> No the hosts are just being poorly equipped - at least the ones that
>> produce this issue
>
>
> Hi Konrad,
>
> Thanks for the detailed and complete replies.
>
> I don't think I've seen this error and we do 100s of builds
> per day using local many-core systems running Ubuntu-18.04
> but with the builds in docker containers using a variety of
> OS distributions.
>
> My first *wild* guess is that the problem might go away on the Azure
> systems if you allocate more memory. That might be an easy
> test to do so that we can confirm that it happens more frequently
> when there is a memory constraint. Can you do that test?
>
> I've also BCCed someone who might know someone who
> would be interested in fixing Azure + Yocto bugs. Let's see
> if they can help. :)
>
> It would also be helpful if you created a defect in:
>
> https://bugzilla.yoctoproject.org/
>
> and hopefully add a patch in that defect including the -native recipes that
> are required to make the problem happen.
>
> Thanks,
>
> ../Randy
>
>
>>>
>>>
>>> ../Randy
>>>
>>>>
>>>> Thanks
>>>>
>>>> Konrad
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>


Re: Image size reduction

Ajam Ali
 

Hi Randy,

In my image most of the size is consumed by heavy size packages.
So i have given this task of image size reduction to application team.
If i will remove the dependencies then may be some feature get disabled which could be needed.
Till now i am able to remove only python3 from dependencies.







Thanks,
Ajam Ali


From: Randy MacLeod <randy.macleod@...>
Sent: Monday, April 13, 2020 11:18 PM
To: Ajam Ali <AjamA@...>; yocto@... <yocto@...>; gley-yocto@m.gmane-mx.org <gley-yocto@m.gmane-mx.org>
Subject: Re: [yocto] Image size reduction
 

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

On 2020-04-04 12:27 p.m., Ajam Ali wrote:
Hi All,

Thanks for your suggestions. I am working on your suggestions.
I will let you know if it did not work for me.

Ajam,


It would be useful if you could reply either way.


If there's still a problem then perhaps someone can help.


If you are able to resolve the issue, then a brief summary

of what you did could help the next person who has a similar

issue.


Thanks,

../Randy



Regards,
Ajam Ali



From: yocto@... <yocto@...> on behalf of Gmane Admin via lists.yoctoproject.org <gley-yocto=m.gmane-mx.org@...>
Sent: Saturday, April 4, 2020 9:36 PM
To: yocto@... <yocto@...>
Subject: Re: [yocto] Image size reduction
 
[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Op 29-03-2020 om 18:28 schreef Ajam Ali:
> Hi All,
>
> Actually my current image size is 3.9GB because of heavy size packages
> required by my project and without project required packages my image
> size in Yocto is 800MB.

So your project adds 3.1GB right

> I want to reduce the image size as maximum as possible.

3.1GB is huge. Compare to f.i. Libreoffice (installed 0.5GB or so).
Either your own code has a lot of fat, or you are pulling in lots of
packages you don't really need. But is there no way to advise you
without knowing more.

> Please suggest the best possible way so that I could reduce the maximum
> possible size(desirable below 1.5 GB).
>
>
> Thanks in advance,
> Ajam Ali
>
>
> Sent from Outlook Mobile <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fblhgte&amp;data=02%7C01%7Cajama%40hcl.com%7Cf719cb14fe674f86f02408d7d8b236b0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637216132261322392&amp;sdata=8in2t%2B6mXtrsRwa7GmgGQDl69uRzL7g4smj%2Ba3QG9gU%3D&amp;reserved=0>
> ::DISCLAIMER::
> ------------------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> may contain viruses in transmission. The e mail and its contents (with
> or without referred errors) shall therefore not attach any liability on
> the originator or HCL or its affiliates. Views or opinions, if any,
> presented in this email are solely those of the author and may not
> necessarily reflect the views or opinions of HCL or its affiliates. Any
> form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of HCL is strictly
> prohibited. If you have received this email in error please delete it
> and notify the sender immediately. Before opening any email and/or
> attachments, please check them for viruses and other defects.
> ------------------------------------------------------------------------
>
>
>





-- 
# Randy MacLeod
# Wind River Linux


Re: [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

Khem Raj
 

On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt <JPEWhacker@...> wrote:

Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend
I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs

[1] https://github.com/superna9999/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc

-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings

# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"

# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-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 <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- 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 c812872d7f9d..65a9b9e5b8a6
---- 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.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
2.17.1


Yocto Project Status WW15'20

Stephen Jolley
 

Current Dev Position: YP 3.1 Review for release

Next Deadline: YP 3.1 release date  2020/4/24

 

Next Team Meetings:

 

Key Status/Updates:

  • 3.1 rc2 has been through QA and is now being reviewed for release
  • 3.1 rc1 was abandoned prior to QA due to concerns about some recent changes
  • YP 3.1 has been announced as an LTS release: https://www.yoctoproject.org/yocto-project-long-term-support-announced/
  • We’re continue to work on bug fixing since if we do need to rebuild, those fixes can be potentially included
  • We are now considering planning for 3.2, there is a planning document at https://docs.google.com/document/d/100bTV-etO0joh6rAkcr7smlZ9iuENG_8BtaXs_vb54c/edit?usp=sharing
  • The planning process for 3.2 is likely to be more lightweight than in the past as the project simply doesn’t have the engineering resources that used to be available for new feature work at this time. We will continue to work on the items left over from previous releases in priority order, as well as trying to reduce the number of open bugs.

 

YP 3.1 Dates:

  • YP 3.1 In review for release
  • YP 3.1 Release date 2020/4/24

 

YP 3.2 Milestone Dates:

  • YP 3.2 M1 build date 2020/6/16
  • YP 3.2 M1 Release date 2020/6/26
  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.3 build date 2020/5/4
  • YP 3.0.3 release date 2020/5/15
  • YP 2.7.4 build date 2020/5/18
  • YP 2.7.4 release date 2020/5/29
  • YP 3.1.1 build date 2020/6/29
  • YP 3.1.1 release date 2020/7/10
  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

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.pm@...

 


[meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

Joshua Watt
 

Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc

-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings

# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"

# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-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 <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- 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 c812872d7f9d..65a9b9e5b8a6
---- 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.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
2.17.1


[meta-security][PATCH] samhain-server: add volatile file for systemd

Yi Zhao
 

Add volatile file to create /var/log/yule when using systemd. Also
remove unused /var/log directory in do_install.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../samhain/files/samhain-server-volatiles.conf | 1 +
recipes-ids/samhain/samhain-server.bb | 16 ++++++++++++----
recipes-ids/samhain/samhain.inc | 2 ++
3 files changed, 15 insertions(+), 4 deletions(-)
create mode 100644 recipes-ids/samhain/files/samhain-server-volatiles.conf

diff --git a/recipes-ids/samhain/files/samhain-server-volatiles.conf b/recipes-ids/samhain/files/samhain-server-volatiles.conf
new file mode 100644
index 0000000..f2ea390
--- /dev/null
+++ b/recipes-ids/samhain/files/samhain-server-volatiles.conf
@@ -0,0 +1 @@
+d /var/log/yule 0775 daemon daemon -
diff --git a/recipes-ids/samhain/samhain-server.bb b/recipes-ids/samhain/samhain-server.bb
index d304912..e7a3aa6 100644
--- a/recipes-ids/samhain/samhain-server.bb
+++ b/recipes-ids/samhain/samhain-server.bb
@@ -4,14 +4,22 @@ require samhain.inc

DEPENDS = "gmp"

-SRC_URI += "file://samhain-server-volatiles"
+SRC_URI += "file://samhain-server-volatiles \
+ file://samhain-server-volatiles.conf \
+ "

TARGET_CC_ARCH += "${LDFLAGS}"

do_install_append() {
- install -d ${D}${sysconfdir}/default/volatiles
- install -m 0644 ${WORKDIR}/samhain-server-volatiles \
- ${D}${sysconfdir}/default/volatiles/samhain-server
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${sysconfdir}/tmpfiles.d
+ install -m 0644 ${WORKDIR}/samhain-server-volatiles.conf \
+ ${D}${sysconfdir}/tmpfiles.d/samhain-server.conf
+ else
+ install -d ${D}${sysconfdir}/default/volatiles
+ install -m 0644 ${WORKDIR}/samhain-server-volatiles \
+ ${D}${sysconfdir}/default/volatiles/samhain-server
+ fi

install -m 700 samhain-install.sh init/samhain.startLinux \
init/samhain.startLSB ${D}/var/lib/samhain
diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index 91eb697..0a5e432 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -159,6 +159,8 @@ do_install_append () {
if [ -d ${D}${localstatedir}/run ]; then
rmdir ${D}${localstatedir}/run
fi
+
+ rm -rf ${D}${localstatedir}/log
}

FILES_${PN} += "${systemd_system_unitdir}"
--
2.17.1


[meta-selinux][PATCH 14/16] selinux-sandbox: upgrade to 3.0 (20191204)

Yi Zhao
 

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-sandbox_2.9.bb | 7 -------
recipes-security/selinux/selinux-sandbox_3.0.bb | 7 +++++++
2 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-sandbox_2.9.bb
create mode 100644 recipes-security/selinux/selinux-sandbox_3.0.bb

diff --git a/recipes-security/selinux/selinux-sandbox_2.9.bb b/recipes-security/selinux/selinux-sandbox_2.9.bb
deleted file mode 100644
index b1dd462..0000000
--- a/recipes-security/selinux/selinux-sandbox_2.9.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20190315.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "3482b8fa6648160e97ba48ad26f84e7d"
-SRC_URI[sha256sum] = "01915f57f08642751dea550a87f82a6f2fcec754be48dcfa28266c14bd044262"
diff --git a/recipes-security/selinux/selinux-sandbox_3.0.bb b/recipes-security/selinux/selinux-sandbox_3.0.bb
new file mode 100644
index 0000000..a60f52c
--- /dev/null
+++ b/recipes-security/selinux/selinux-sandbox_3.0.bb
@@ -0,0 +1,7 @@
+require selinux_20191204.inc
+require ${BPN}.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+SRC_URI[md5sum] = "81447c46bf4cae9a5fa38c5fb8dc923e"
+SRC_URI[sha256sum] = "66fb4ea3a9e3d1e6004f13666b8390be751dd226a8496b995ed0332788758d0a"
--
2.17.1


[meta-selinux][PATCH 16/16] semodule-utils: upgrade to 3.0 (20191204)

Yi Zhao
 

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/semodule-utils_2.9.bb | 7 -------
recipes-security/selinux/semodule-utils_3.0.bb | 7 +++++++
2 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 recipes-security/selinux/semodule-utils_2.9.bb
create mode 100644 recipes-security/selinux/semodule-utils_3.0.bb

diff --git a/recipes-security/selinux/semodule-utils_2.9.bb b/recipes-security/selinux/semodule-utils_2.9.bb
deleted file mode 100644
index a9c0fbd..0000000
--- a/recipes-security/selinux/semodule-utils_2.9.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20190315.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "9e7e6afe33459cae2de5360e97f1e702"
-SRC_URI[sha256sum] = "8083679ee634570f6e9a18632f2c2862b9134fa308b689b2e1952a369ae5d907"
diff --git a/recipes-security/selinux/semodule-utils_3.0.bb b/recipes-security/selinux/semodule-utils_3.0.bb
new file mode 100644
index 0000000..bccc707
--- /dev/null
+++ b/recipes-security/selinux/semodule-utils_3.0.bb
@@ -0,0 +1,7 @@
+require selinux_20191204.inc
+require ${BPN}.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+SRC_URI[md5sum] = "58b0e4b85695dad6aff70c69f7a417fd"
+SRC_URI[sha256sum] = "14ee2db21f36766ffbbb65770f8e7236d21675db9f0f5d40f50974711da598cf"
--
2.17.1


[meta-selinux][PATCH 15/16] selinux-gui: upgrade to 3.0 (20191204)

Yi Zhao
 

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-gui_2.9.bb | 7 -------
recipes-security/selinux/selinux-gui_3.0.bb | 7 +++++++
2 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-gui_2.9.bb
create mode 100644 recipes-security/selinux/selinux-gui_3.0.bb

diff --git a/recipes-security/selinux/selinux-gui_2.9.bb b/recipes-security/selinux/selinux-gui_2.9.bb
deleted file mode 100644
index 0bb051c..0000000
--- a/recipes-security/selinux/selinux-gui_2.9.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20190315.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "1bfe5eeb861f8563a7b397ab8530ab52"
-SRC_URI[sha256sum] = "bbd9e1799cc0c22d64c815c3033a54393f6f84947ff2841a4df60ded5eee0510"
diff --git a/recipes-security/selinux/selinux-gui_3.0.bb b/recipes-security/selinux/selinux-gui_3.0.bb
new file mode 100644
index 0000000..e937836
--- /dev/null
+++ b/recipes-security/selinux/selinux-gui_3.0.bb
@@ -0,0 +1,7 @@
+require selinux_20191204.inc
+require ${BPN}.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+SRC_URI[md5sum] = "988a564eccc01feb8cc6fa49630efc6d"
+SRC_URI[sha256sum] = "e9e9b599950a30857b0954bf10853ea50efb7de68a5ae756a27b8d03ccc44348"
--
2.17.1

8261 - 8280 of 57419