Re: [yocto] [PATCH][thud] meta-yocto-bsp: Bump to the latest stable kernel for the BSPs

2019-08-12 Thread Kevin Hao 
On Fri, Apr 19, 2019 at 01:23:35PM +0800, Kevin Hao wrote:
> In order to fix a systemtap bug [1] on arm board, we backport a kernel
> patch from v5.0 kernel to v4.14 & v4.18 kernel, then need to bump the
> kernel version to include this patch. Even this is only an arm specific
> bug, we would like to bump the kernel version for the BSPs at the same
> time. Boot test for all the boards.
> 
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

Hi Armin,

Could you help merge this patch to thud branch?

Thanks,
Kevin

> 
> Signed-off-by: Kevin Hao 
> ---
>  .../recipes-kernel/linux/linux-yocto_4.14.bbappend   | 20 
> ++--
>  .../recipes-kernel/linux/linux-yocto_4.18.bbappend   | 20 
> ++--
>  2 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend 
> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> index 502485a94b15..426757e48c9e 100644
> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
>  KMACHINE_genericx86-64 ?= "common-pc-64"
>  KMACHINE_beaglebone-yocto ?= "beaglebone"
>  
> -SRCREV_machine_genericx86?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
> -SRCREV_machine_genericx86-64 ?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
> -SRCREV_machine_edgerouter ?= "e06bfa18c727bd0e6e10cf26d9f161e4c791f52b"
> -SRCREV_machine_beaglebone-yocto ?= "b8805de77dcf8f59d8368fee4921c146c1300a6a"
> -SRCREV_machine_mpc8315e-rdb ?= "f88e87360b10f8fbd853a7d412982e6620f3f96d"
> +SRCREV_machine_genericx86?= "5252513a39b4b3773debab1f77071d7c430ecb10"
> +SRCREV_machine_genericx86-64 ?= "5252513a39b4b3773debab1f77071d7c430ecb10"
> +SRCREV_machine_edgerouter ?= "d8fb40cd0e99325715c70aed6f361a8318097829"
> +SRCREV_machine_beaglebone-yocto ?= "c67809688bd22cb4cb909bcf1a1045e6337c3229"
> +SRCREV_machine_mpc8315e-rdb ?= "258ee8228e0a512c6dbe2a0dadcd9f030ba45964"
>  
>  COMPATIBLE_MACHINE_genericx86 = "genericx86"
>  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
> @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>  COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
>  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>  
> -LINUX_VERSION_genericx86 = "4.14.76"
> -LINUX_VERSION_genericx86-64 = "4.14.76"
> -LINUX_VERSION_edgerouter = "4.14.71"
> -LINUX_VERSION_beaglebone-yocto = "4.14.71"
> -LINUX_VERSION_mpc8315e-rdb = "4.14.71"
> +LINUX_VERSION_genericx86 = "4.14.98"
> +LINUX_VERSION_genericx86-64 = "4.14.98"
> +LINUX_VERSION_edgerouter = "4.14.98"
> +LINUX_VERSION_beaglebone-yocto = "4.14.98"
> +LINUX_VERSION_mpc8315e-rdb = "4.14.98"
> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend 
> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
> index 7f15843f3a90..11b35cc1c2f8 100644
> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
> @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
>  KMACHINE_genericx86-64 ?= "common-pc-64"
>  KMACHINE_beaglebone-yocto ?= "beaglebone"
>  
> -SRCREV_machine_genericx86?= "db2d813869a0501782469ecdb17e277a501c9f57"
> -SRCREV_machine_genericx86-64 ?= "db2d813869a0501782469ecdb17e277a501c9f57"
> -SRCREV_machine_edgerouter ?= "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
> -SRCREV_machine_beaglebone-yocto ?= "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
> -SRCREV_machine_mpc8315e-rdb ?= "99071a599d8650b069fb8135866fca203f375350"
> +SRCREV_machine_genericx86?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
> +SRCREV_machine_genericx86-64 ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
> +SRCREV_machine_edgerouter ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
> +SRCREV_machine_beaglebone-yocto ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
> +SRCREV_machine_mpc8315e-rdb ?= "0802dc980cbc8bdb156d6fe305e7b88e6b602634"
>  
>  COMPATIBLE_MACHINE_genericx86 = "genericx86"
>  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
> @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>  COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
>  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>  
> -LINUX_VERSION_genericx86 = "4.18.22"
> -LINUX_VERSION_genericx86-64 = "4.18.22"
> -LINUX_VERSION_edgerouter = "4.18.25"
> -LINUX_VERSION_beaglebone-yocto = "4.18.25"
> -LINUX_VERSION_mpc8315e-rdb = "4.18.25"
> +LINUX_VERSION_genericx86 = "4.18.35"
> +LINUX_VERSION_genericx86-64 = "4.18.35"
> +LINUX_VERSION_edgerouter = "4.18.35"
> +LINUX_VERSION_beaglebone-yocto = "4.18.35"
> +LINUX_VERSION_mpc8315e-rdb = "4.18.35"
> -- 
> 2.14.4
> 


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2019-08-12 Thread sjolley.yp.pm 
All,

 

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

 

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

 

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

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 297
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, "2.8", "2.9', "2.99" and "Future", the more pressing/urgent
issues being in "2.8" and then "2.9".

 

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#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] ref-manual: mention PREPROCESS_RELOCATE_DIRS variable

2019-08-12 Thread Martin Jansa 
Signed-off-by: Martin Jansa 
---
 documentation/ref-manual/ref-classes.xml   |  5 -
 documentation/ref-manual/ref-variables.xml | 21 +
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index ece47e757..159efb3b1 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -413,7 +413,10 @@
 cross, and
 cross-canadian recipes to change
 RPATH records within binaries in order to make
-them relocatable.
+them relocatable. To extend the list of directories where it searches
+for binaries to relocate, you can set
+PREPROCESS_RELOCATE_DIRS
+variable in your recipe.
 
 
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index 9470a780a..5ac766658 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -11424,6 +11424,27 @@
 
 
 
+PREPROCESS_RELOCATE_DIRS
+
+PREPROCESS_RELOCATE_DIRS[doc] = "List of extra directories 
where to search for binaries which should be relocatable."
+
+
+
+
+List of extra directories with binaries.
+
+
+
+PREPROCESS_RELOCATE_DIRS is used by
+chrpath.bbclass to allow extending the list where it 
searches
+for binaries. By default it searches in:
+${bindir} ${sbindir} ${base_sbindir} ${base_bindir} 
${libdir} ${base_libdir} ${libexecdir}
+Thus, PREPROCESS_RELOCATE_DIRS 
usually doesn't
+need to be set withing recipes.
+
+
+
+
 PRIORITY
 
 PRIORITY[doc] = "Indicates the importance of a package.  The 
default value is 'optional'.  Other standard values are 'required', 'standard', 
and 'extra'."
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Segmentation fault | bitbake machine-image.bb | core dumped

2019-08-12 Thread jaymin . dabhi 

Hello All,

Facing segmentation fault (core dumped) while doing bitbake.
I am using Yocto Jethro branch.

When I added python3-pip recipe (in local.conf) and started building 
image, segmentation fault occurred.
Although, I am able to bitbake python3-pip individually (i.e. bitbake 
python3-pip).
As per log my assumption is, core dumped is occurring at make_ext4fs 
execution.


Following are the error logs:

ERROR: Function failed: do_makesystem (log file is located at  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059)
ERROR: Logfile of failure stored in:  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059

Log data follows:
| DEBUG: Executing shell function do_makesystem
|  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: 
line 105: 15073 Segmentation fault  (core dumped) make_ext4fs -J -b 
1024 -s -a / -S  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts 
-l 76800  
poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| WARNING:  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 
exit 139 from
|   make_ext4fs -J -b 1024 -s -a / -S  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts 
-l 76800  
poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| ERROR: Function failed: do_makesystem (log file is located at  
poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059)
ERROR: Task 11 ( 
poky/meta-qti-bsp/recipes-products/images/machine-image.bb, 
do_makesystem) failed with exit code '1'



Whether python3-pip recipe is creating an issue or something else? 
(attached the python3-pip recipe file)

Please let me know.
Any suggestions are welcome.

Regards,
JayminSUMMARY = "The PyPA recommended tool for installing Python packages"
sHOMEPAGEsss = "https://pypi.python.org/pypi/pip";
SECTION = "devel/python"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=45665b53032c02b35e29ddab8e61fa91"

SRCNAME = "pip"
DEPENDS += "python3 python3-setuptools-native"

SRC_URI = " \
  http://pypi.python.org/packages/source/p/${SRCNAME}/${SRCNAME}-${PV}.tar.gz \
"
SRC_URI[md5sum] = "6b19e0a934d982a5a4b798e957cb6d45"
SRC_URI[sha256sum] = 
"89f3b626d225e08e7f20d85044afa40f612eb3284484169813dc2d0631f2a556"

S = "${WORKDIR}/${SRCNAME}-${PV}"

inherit distutils3

DISTUTILS_INSTALL_ARGS += 
"--install-lib=${D}${libdir}/${PYTHON_DIR}/site-packages"

do_install_prepend() {
install -d ${D}/${libdir}/${PYTHON_DIR}/site-packages
}

# Use setuptools site.py instead, avoid shared state issue
do_install_append() {
rm ${D}/${libdir}/${PYTHON_DIR}/site-packages/site.py
rm 
${D}/${libdir}/${PYTHON_DIR}/site-packages/__pycache__/site.cpython-34.pyc
}

RDEPENDS_${PN} = "\
  python3-compile \
  python3-io \
  python3-json \
  python3-netserver \
  python3-setuptools \
  python3-unixadmin \
  python3-xmlrpc \
"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto repos for NXP referent platform MCIMXABASEV1 also called SABRE platform?

2019-08-12 Thread Zoran Stojsavljevic 
Hello Khem,

Thank you for the reply.

I would say look at:
https://github.com/ZoranStojsavljevic/imx6-sabre-automotive-bsp

Zoran
___

On Fri, Aug 9, 2019 at 6:51 PM Khem Raj  wrote:

> On Thu, Aug 8, 2019 at 11:20 PM Zoran Stojsavljevic
>  wrote:
> >
> > Hello to all,
> >
> > I am trying to find out some recent yocto repo, which contains YOCTO
> > reference repo for the following NXP board:
> > MCIMXABASEV1 also called SABRE platform.
> >
> > Here is one repo I found reading this document... But this is too
> outdated!
> >
> >
> http://events17.linuxfoundation.org/sites/events/files/slides/AGLAMM_How%20we%20Run%20AGL%20on%20i.MX%20processors_tkobayashi_25FEB16%20rev.D.pdf
> >
> > Does anybody have some other repos/suggestions in mind for such a
> > board? Please, come forward if yes...
> >
>
> I would say look at
>
>
> http://layers.openembedded.org/layerindex/branch/master/machines/?q=sabre&search=1
>
> > Thank you,
> > Zoran
> > ___
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] wic create - bad ownership of directories inside image

2019-08-12 Thread Behnke, Jochen 
Hello, I am using poky 2.6.1 (thud) and create images using the wic utility.Recently I noticed that all directories contained in the created image are owned by UID 1000 and not by root. The files inside the image however are owned by root.The UID 1000 refers to my unprivileged user on the host system. Here is the command I use to create the image “wic create mkefidisk –e core-image-minimal” The images created by bitbake directly (.tar.bz2, .hddimg) are correct so this seems to be a wic related problem. Does anybody have a solution for this? Many thanks in advance, any hint is appreciated.  RegardsJochen __SCHMIDT Technology GmbHFeldbergstrasse 178112 St. Georgen/GermanyTelefon +49 (0) 77 24 / 89 90Fax +49 (0) 77 24 / 89 91 01i...@schmidttechnology.dehttp://www.schmidttechnology.deUSt-Id Nr. DE 811725105 · Registergericht Freiburg HRB 600 755Geschaeftsfuehrung: Oliver Schmidt, Stephan Schmidt-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto