[yocto] [meta-security][PATCH 3/3] sleuthkit: update to 4.1.3

[Armin Kuster]

cleanup QA issues with perl
refresh patch

Signed-off-by: Armin Kuster 
---
 .../{afflib_3.6.6.bb => afflib_3.7.16.bb} | 20 +--
 .../afflib/files/configure_rm_ms_flags.patch  |  8 ++---
 .../sleuth/files/fix_host_poison.patch| 33 ---
 ...{sleuthkit_4.1.3.bb => sleuthkit_4.6.0.bb} | 16 ++---
 4 files changed, 37 insertions(+), 40 deletions(-)
 rename recipes-forensic/afflib/{afflib_3.6.6.bb => afflib_3.7.16.bb} (54%)
 rename recipes-forensic/sleuth/{sleuthkit_4.1.3.bb => sleuthkit_4.6.0.bb} (73%)

diff --git a/recipes-forensic/afflib/afflib_3.6.6.bb 
b/recipes-forensic/afflib/afflib_3.7.16.bb
similarity index 54%
rename from recipes-forensic/afflib/afflib_3.6.6.bb
rename to recipes-forensic/afflib/afflib_3.7.16.bb
index a826d1d..013f524 100644
--- a/recipes-forensic/afflib/afflib_3.6.6.bb
+++ b/recipes-forensic/afflib/afflib_3.7.16.bb
@@ -1,21 +1,17 @@
 SUMMARY = "The Advanced Forensic Format (AFF) is on-disk format for storing 
computer forensic information."
 HOMEPAGE = "http://www.afflib.org/";
 LICENSE = " BSD-4-Clause  & CPL-1.0"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d1b2c6d0d6908f45d143ef6380727828"
+LIC_FILES_CHKSUM = "file://COPYING;md5=dddf949f1763ecf9b73a96b87b8e6fce"
 
-DEPENDS = " zlib ncurses readline openssl libgcrypt"
+DEPENDS = "zlib ncurses readline openssl libgcrypt"
 
-SRC_URI = 
"http://archive.ubuntu.com/ubuntu/pool/universe/a/${BPN}/${BPN}_${PV}.orig.tar.gz;name=orig
 \
-
http://archive.ubuntu.com/ubuntu/pool/universe/a/${BPN}/${BPN}_${PV}-1.1.diff.gz;name=dpatch
 \
-file://configure_rm_ms_flags.patch \
-"
+SRC_URI = 
"http://archive.ubuntu.com/ubuntu/pool/universe/a/${BPN}/${BPN}_${PV}.orig.tar.gz
 \
+   file://configure_rm_ms_flags.patch "
 
-SRC_URI[orig.md5sum] = "b7ff4d2945882018eb1536cad182ad01"
-SRC_URI[orig.sha256sum] = 
"19cacfd558dc00e11975e820e3c4383b52aabbd5ca081d27bb7994a035d2f4ad"
-SRC_URI[dpatch.md5sum] = "171e871024545b487589e6c85290576f"
-SRC_URI[dpatch.sha256sum] = 
"db632e254ee51a1e4328cd4449d414eff4795053d4e36bfa8e0020fcb4085cdd"
+SRC_URI[md5sum] = "776f09e1c98a63e1e7a16a52f56146fe"
+SRC_URI[sha256sum] = 
"9c0522941a24a3aafa027e510c6add5ca9f4defd2d859da3e0b536ad11b6bf72"
 
-inherit autotools-brokensep pkgconfig
+inherit autotools pkgconfig
 
 CPPFLAGS = "-I${STAGING_INCDIR}"
 LDFLAGS = "-L${STAGING_LIBDIR}"
@@ -28,3 +24,5 @@ PACKAGECONFIG[python] = "--enable-python=yes, 
--enable-python=no, python"
 
 EXTRA_OECONF += "--enable-s3=no CPPFLAGS=-I${STAGING_INCDIR} 
LDFLAGS=-L${STAGING_LIBDIR}"
 EXTRA_OEMAKE += "CPPFLAGS='${CPPFLAGS}' LDFLAGS='-L${STAGING_LIBDIR} 
-I${STAGING_INCDIR}'"
+
+S = "${WORKDIR}/AFFLIBv3-${PV}"
diff --git a/recipes-forensic/afflib/files/configure_rm_ms_flags.patch 
b/recipes-forensic/afflib/files/configure_rm_ms_flags.patch
index ac33500..e6b3e1e 100644
--- a/recipes-forensic/afflib/files/configure_rm_ms_flags.patch
+++ b/recipes-forensic/afflib/files/configure_rm_ms_flags.patch
@@ -4,11 +4,11 @@ remove ms lib options when cross compiling
 
 Signed-Off-By: Armin Kuster 
 
-Index: configure.ac
+Index: AFFLIBv3-3.7.16/configure.ac
 ===
 a.orig/configure.ac
-+++ a/configure.ac
-@@ -47,7 +47,6 @@ if test x"${cross_compiling}" = "xno" ;
+--- AFFLIBv3-3.7.16.orig/configure.ac
 AFFLIBv3-3.7.16/configure.ac
+@@ -46,7 +46,6 @@ if test x"${cross_compiling}" = "xno" ;
AC_MSG_NOTICE([ LDFLAGS = ${LDFLAGS} ])
  else
AC_MSG_NOTICE([Cross Compiling --- will not update CPPFALGS or LDFLAGS with 
/usr/local, /opt/local or /sw])
diff --git a/recipes-forensic/sleuth/files/fix_host_poison.patch 
b/recipes-forensic/sleuth/files/fix_host_poison.patch
index 03b1fb9..1972f3e 100644
--- a/recipes-forensic/sleuth/files/fix_host_poison.patch
+++ b/recipes-forensic/sleuth/files/fix_host_poison.patch
@@ -1,23 +1,16 @@
-Upstream-Status: Inappropriate [configuration]
-
-Don't use host include or lib paths in *FLAGS
-
-Signed-off-by: Armin Kuster 
-
-Index: configure.ac
+Index: sleuthkit-sleuthkit-4.6.0/configure.ac
 ===
 a/configure.ac
-+++ b/configure.ac
-@@ -84,12 +84,6 @@ AX_PTHREAD([
- LDFLAGS="$LDFLAGS $PTHREAD_CFLAGS"
- CC="$PTHREAD_CC"],[])
- 
--dnl Not all compilers include /usr/local in the include and link path
--if test -d /usr/local/include; then
+--- sleuthkit-sleuthkit-4.6.0.orig/configure.ac
 sleuthkit-sleuthkit-4.6.0/configure.ac
+@@ -95,11 +95,6 @@ case "$host" in
+   dnl Adding the native /usr/local is wrong for cross-compiling
+   ;;
+ *)
+-  dnl Not all compilers include /usr/local in the include and link path
+-  if test -d /usr/local/include; then
 -CPPFLAGS="$CPPFLAGS -I/usr/local/include"
 -LDFLAGS="$LDFLAGS -L/usr/local/lib"
--fi
--
- dnl Add enable/disable option
- AC_ARG_ENABLE([java],
- [AS_HELP_STRING([--disable-java], [Do not build the java bindings or jar 
file])])
+-  fi
+   ;;
+ esac
+ 
diff --git a/re

[yocto] [meta-security][PATCH 2/3] suricata: update 4.0.5

[Armin Kuster]

Fix rules make. Don't allow the makefile to download the rules. Use
fetcher

add install configs and remove manual intall of those files

Signed-off-by: Armin Kuster 
---
 .../{suricata_4.0.0.bb => suricata_4.0.5.bb}  | 24 ---
 1 file changed, 15 insertions(+), 9 deletions(-)
 rename recipes-security/suricata/{suricata_4.0.0.bb => suricata_4.0.5.bb} (85%)

diff --git a/recipes-security/suricata/suricata_4.0.0.bb 
b/recipes-security/suricata/suricata_4.0.5.bb
similarity index 85%
rename from recipes-security/suricata/suricata_4.0.0.bb
rename to recipes-security/suricata/suricata_4.0.5.bb
index 6efa351..6ccf3d2 100644
--- a/recipes-security/suricata/suricata_4.0.0.bb
+++ b/recipes-security/suricata/suricata_4.0.5.bb
@@ -4,17 +4,23 @@ require suricata.inc
 
 LIC_FILES_CHKSUM = 
"file://LICENSE;beginline=1;endline=2;md5=c70d8d3310941dcdfcd1e02800a1f548"
 
+SRC_URI += 
"https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz;name=rules";
+
 SRC_URI += " \
file://volatiles.03_suricata \
file://suricata.yaml \
file://suricata.service \
"
 
+SRC_URI[rules.md5sum] = "7e8b570d318c98bff65f2ddc457122cb"
+SRC_URI[rules.sha256sum] = 
"229e3035804c2b816092c6eea09e35f9db0ea421758551a7a740cdd9c15e3feb"
+
 inherit autotools-brokensep pkgconfig python-dir systemd 
 
 CFLAGS += "-D_DEFAULT_SOURCE"
 
-CACHED_CONFIGUREVARS = "ac_cv_header_htp_htp_h=yes 
ac_cv_lib_htp_htp_conn_create=yes "
+CACHED_CONFIGUREVARS = "ac_cv_header_htp_htp_h=yes 
ac_cv_lib_htp_htp_conn_create=yes \
+ac_cv_path_HAVE_WGET=no ac_cv_path_HAVE_CURL=no "
 
 EXTRA_OECONF += " --disable-debug \
 --enable-non-bundled-htp \
@@ -41,19 +47,20 @@ export logdir = "${localstatedir}/log"
 
 do_install_append () {
 
+install -d ${D}${sysconfdir}/suricata
+
+oe_runmake install-conf DESTDIR=${D}
+
+# mimic move of downloaded rules to e_sysconfrulesdir
+cp -rf  ${WORKDIR}/rules ${D}${sysconfdir}/suricata
+
 oe_runmake install-rules DESTDIR=${D}
 
-install -d ${D}${sysconfdir}/suricata
 install -d ${D}${sysconfdir}/suricata ${D}${sysconfdir}/default/volatiles
-install -m 644 classification.config ${D}${sysconfdir}/suricata
-install -m 644 reference.config ${D}${sysconfdir}/suricata
-install -m 644 ${WORKDIR}/suricata.yaml ${D}${sysconfdir}/suricata
 install -m 0644 ${WORKDIR}/volatiles.03_suricata  
${D}${sysconfdir}/default/volatiles/volatiles.03_suricata
 
 install -m 0644 ${S}/threshold.config ${D}${sysconfdir}/suricata
 
-install -d ${D}${logdir}/suricata
-
 install -d ${D}${systemd_unitdir}/system
 sed  -e s:/etc:${sysconfdir}:g \
  -e s:/var/run:/run:g \
@@ -62,7 +69,6 @@ do_install_append () {
  -e s:/bin/kill:${base_bindir}/kill:g \
  -e s:/usr/lib:${libdir}:g \
  ${WORKDIR}/suricata.service > 
${D}${systemd_unitdir}/system/suricata.service
-
 }
 
 pkg_postinst_ontarget_${PN} () {
@@ -74,7 +80,7 @@ fi
 SYSTEMD_PACKAGES = "${PN}"
 
 PACKAGES =+ "${PN}-socketcontrol"
-FILES_${PN} += "${logdir}/suricata ${systemd_unitdir}"
+FILES_${PN} += "${systemd_unitdir} /run"
 FILES_${PN}-socketcontrol = "${bindir}/suricatasc ${PYTHON_SITEPACKAGES_DIR}"
 
 CONFFILES_${PN} = "${sysconfdir}/suricata/suricata.yaml"
-- 
2.17.1

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

[yocto] [meta-security][PATCH 1/3] libhtp: update to 0.5.27

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 .../suricata/{libhtp_0.5.25.bb => libhtp_0.5.27.bb} | 0
 recipes-security/suricata/suricata.inc  | 6 +++---
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename recipes-security/suricata/{libhtp_0.5.25.bb => libhtp_0.5.27.bb} (100%)

diff --git a/recipes-security/suricata/libhtp_0.5.25.bb 
b/recipes-security/suricata/libhtp_0.5.27.bb
similarity index 100%
rename from recipes-security/suricata/libhtp_0.5.25.bb
rename to recipes-security/suricata/libhtp_0.5.27.bb
diff --git a/recipes-security/suricata/suricata.inc 
b/recipes-security/suricata/suricata.inc
index a2d36eb..1f42121 100644
--- a/recipes-security/suricata/suricata.inc
+++ b/recipes-security/suricata/suricata.inc
@@ -2,8 +2,8 @@ HOMEPAGE = "http://suricata-ids.org/";
 SECTION = "security Monitor/Admin"
 LICENSE = "GPLv2"
 
-VER = "4.0.0"
+VER = "4.0.5"
 SRC_URI = 
"http://www.openinfosecfoundation.org/download/suricata-${VER}.tar.gz";
 
-SRC_URI[md5sum] = "41fb91b4cbc6705b353e4bdd02c3df4b"
-SRC_URI[sha256sum] = 
"6b8b183a8409829ca92c71854cc1abed45f04ccfb7f14c08211f4edf571fa577"
+SRC_URI[md5sum] = "ea0cb823d6a86568152f75ade6de442f"
+SRC_URI[sha256sum] = 
"74dacb4359d57fbd3452e384eeeb1dd77b6ae00f02e9994ad5a7b461d5f4c6c2"
-- 
2.17.1

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

Re: [yocto] Yocto userbase in numbers?

[Andre McCurdy]

On Thu, Aug 9, 2018 at 2:42 PM, akuster808  wrote:
> On 08/09/2018 10:19 AM, Frazer, Will wrote:
>
> I was asked recently what a ballpark figure for the number of systems
> running distributions built with yocto might be and I could not find
> anything.
>
> I realise it’s almost impossible to tell since technically everyone builds a
> different distro, but I don’t suppose anyone has come across any estimates
> anywhere ?
>
> The Yocto Project does not have the ability to track which distributions are
> created from the OpenEmbedded build framework nor who uses Poky as a
> starting point.

Actually poky users probably do leave quite a detailed trail each time
they build anything due to the default PREMIRRORS in the poky distro
config. The downloads.yoctoproject.org logs could probably reveal a
lot...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto userbase in numbers?

[akuster808]

On 08/09/2018 10:19 AM, Frazer, Will wrote:
>
> I was asked recently what a ballpark figure for the number of systems
> running distributions built with yocto might be and I could not find
> anything.
>
>  
>
> I realise it’s almost impossible to tell since technically everyone
> builds a different distro, but I don’t suppose anyone has come across
> any estimates anywhere ?
>

The Yocto Project does not have the ability to track which distributions
are created from the OpenEmbedded build framework nor who uses Poky as a
starting point. Even if we did, I believe we would violate someone's
privacy if we distributed that information outside the Yocto Project.

Kind regards,
Armin

>  
>
> Thanks,
>
> Will
>
>  
>
>  
>
>
>

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

Re: [yocto] Yocto userbase in numbers?

[Richard Purdie]

On Thu, 2018-08-09 at 17:19 +, Frazer, Will wrote:
> I was asked recently what a ballpark figure for the number of systems
> running distributions built with yocto might be and I could not find
> anything.
>  
> I realise it’s almost impossible to tell since technically everyone
> builds a different distro, but I don’t suppose anyone has come across
> any estimates anywhere ?

Its really hard to know. Someone did try to write a list of the
companies using the project based on mailing list questions, bugzilla
and job adverts and the list was over 700 companies and growing. Some
of the companies are large and have significant numbers of devices in
the field.

Even if you just look at the fields the project is used in based on the
project's members like Comcast, the automotive industry (e.g.
Automotive Grade Linux), several major OS vendors (Windriver, Mentor
Graphics, Montavista, ENEA) and in TVs (LG), the deployment of the
project is significant. How many devices any of those companies ship
based on Yocto Project derived Linux would be an interesting number to
try and work out. Its very much an iceberg, you only see part of it...

Cheers,

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

Re: [yocto] uBoot, kernel and device tree files

[Michal Vokáč]

Hi Srini,

On 8.8.2018 20:51, Srinivasan, Raja wrote:

All

We are using rocko.on variscite var-som-mx6.

In order to increase the security of our system (during a system upgrade), we 
are looking to merge uImage (kernel image) and the device tree file into 1 
file. Currently these are 2 different files and are worried that a file copy 
operation might get aborted.


I understand that what you want to achive by combining the files is
"relyability" and not "security". Those are totaly different things.


My research so far indicates mkuboot can be used to merge these. but having 
trouble making this work.

Need some ideas.

Any pointers appreciated. srini


I am aware of at least two options to combine kernel images and device
tree files.

Option 1) Append DTB directly to the kernel image

This is the simplest option. Just use cat to concatenate the files
and enable the CONFIG_ARM_APPENDED_DTB kernel option.
Read the help for the option, it is quite informative.

In this case you do not need to change anything in your boot loader.
Just load and boot the combined image as usual and kernel will do
the rest.

Option 2) Use FIT images

I strongly recommend this option over the first one.
FIT images are something like containers that can contain multiple kernel
images, multiple device tree blobs, multiple initram file systems.
Part of the FIT image then describes what combinations of those files
can be used to boot.

If your concern is not just reliability but also security than FIT images
are also better. You can put hashes/signatures of all the files into the
description of the files and use the hashes in the bootloader to verify
the images (I never used that.)

In this option you need to change your boot command.

Hope this helps,
Michal
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] rpmdeps buffer overflow

[Marc Ferland]

Hi,

I'm creating a recipe for a precompiled SDK. This SDK contains various
precompiled libraries and executables. When I get to the packaging
step bitbake aborts with the following error:

ERROR: pylon-5.0.12-r0 do_package: Error executing a python function
in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:package_do_filedeps(d)
 0003:
File: '/vagrant/yocto/poky/meta/classes/package.bbclass', lineno:
1484, function: package_do_filedeps
 1480:continue
 1481:for files in chunks(pkgfiles[pkg], 100):
 1482:pkglist.append((pkg, files, rpmdeps, pkgdest))
 1483:
 *** 1484:processed = oe.utils.multiprocess_exec( pkglist,
oe.package.filedeprunner)
 1485:
 1486:provides_files = {}
 1487:requires_files = {}
 1488:
File: '/vagrant/yocto/poky/meta/lib/oe/utils.py', lineno: 240,
function: multiprocess_exec
 0236:mapresult = pool.map_async(function, commands,
error_callback=failures)
 0237:
 0238:pool.close()
 0239:pool.join()
 *** 0240:results = mapresult.get()
 0241:except KeyboardInterrupt:
 0242:pool.terminate()
 0243:pool.join()
 0244:raise
File: '/usr/lib/python3.6/multiprocessing/pool.py', lineno: 644, function: get
 0640:raise TimeoutError
 0641:if self._success:
 0642:return self._value
 0643:else:
 *** 0644:raise self._value
 0645:
 0646:def _set(self, i, obj):
 0647:self._success, self._value = obj
 0648:if self._callback and self._success:
Exception: subprocess.CalledProcessError: Command
'['/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps',
'--alldeps', 
'/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/lib64/libpylon_TL_bcon-5.0.12.so',

REMOVED FOR BREVITY

'/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/platforms/libqxcb.so']'
died with .

Subprocess output:
*** buffer overflow detected ***:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
terminated

ERROR: pylon-5.0.12-r0 do_package: Function failed: package_do_filedeps
ERROR: Logfile of failure stored in:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/temp/log.do_package.30101
ERROR: Task 
(/vagrant/yocto/meta-telops/recipes-basler/pylon5/pylon_5.0.12.bb:do_package)
failed with exit code '1'

Digging a little deeper, it looks like certain files cause rpmdeps to
blowup. For example, issuing:

rpmdeps --alldeps
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2

I get the expected:
  0 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2
P libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit)
P libQt5Core.so.5(Qt_5)(64bit)
P libQt5Core.so.5(Qt_5.0)(64bit)
P libQt5Core.so.5(Qt_5.0)(64bit)


But running rpmdeps on one of their proprietary lib:
rpmdeps --alldeps
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libPylonQtBase.so.1.0.0
*** buffer overflow detected ***:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
terminated
Aborted (core dumped)

Any idea of what might be causing this?

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

[yocto] Yocto userbase in numbers?

[Frazer, Will]

I was asked recently what a ballpark figure for the number of systems running 
distributions built with yocto might be and I could not find anything.

I realise it's almost impossible to tell since technically everyone builds a 
different distro, but I don't suppose anyone has come across any estimates 
anywhere ?

Thanks,
Will


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

Re: [yocto] uBoot, kernel and device tree files

[Philip Balister]

On 08/08/2018 11:51 AM, Srinivasan, Raja wrote:
> All
> 
> We are using rocko.on variscite var-som-mx6.
> 
> In order to increase the security of our system (during a system upgrade), we 
> are looking to merge uImage (kernel image) and the device tree file into 1 
> file. Currently these are 2 different files and are worried that a file copy 
> operation might get aborted.
> 
> My research so far indicates mkuboot can be used to merge these. but having 
> trouble making this work.
> 
> Need some ideas.

Read about fit images.

Philip

> 
> Any pointers appreciated. srini
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email message and any attachments are 
> confidential and may be privileged and are meant to be read by the intended 
> recipient only. If you are not the intended recipient, please notify sender 
> immediately and destroy all copies of this message and any attachments 
> without reading or disclosing their contents. Thank you
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Weekly Triage Meeting

[Jolley, Stephen K]

Attendees: Armin, Stephen, Randy, Richard, Joshua, Tim

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

We discuss YP 2.6 M2 QA results and agreed to move toward release.

AR: Paul – Review and update 
12102
AR: Randy – Add comment to bug 
12806
AR: Randy – Close 7344
AR: Randy – Discuss 
6838, 
7596, 
5648 with David if 
these still valid.
AR: Stephen – Check with Tracy about bug 
7476 and if we need to 
find a new owner.
AR: Richard – Discuss with Ross bug 
4479

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:  (208) 244-4460
• Email:stephen.k.jol...@intel.com


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

[yocto] custom splash screen using psplash

[Yuvarajesh Valleru]

Hallo,

I would like to overwrite the poky psplash splash screen [1] with my 
custom splash screen.


I copied the psplash_git.bb recipe from 
openembedded-core/meta/recipes-core/psplash/ to my custom layer and 
changed psplash_poky_img.h to mycustom_image_img.h in mycustom_recipe/files/


But during the boot the Custom splash screen displays along with a 
progress bar from poky splash screen. (I noticed that the psplash.c 
source file also contains progress-bar.h file included)


Is it possible to remove or overwrite the complete poky splash screen 
files with mycustom_splashscreen?


Thank you,

Best Regards;
Rajesh

[1] 
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/psplash/psplash_git.bb


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

[yocto] Device Tree Source is not correctly specified in fitImage signing process

[samir mouhoune]

Hi All,
I am trying to generate a signed fitImage for IMX6 (nitrogen6x) som  using PYRO 
2.3 branch. 
I my setup I had the following configs: 
KERNEL_DEVICETREE = "imx6q-sabrelite.dtb \                        
imx6q-nitrogen6x.dtb imx6dl-nitrogen6x.dtb \"    KERNEL_IMAGETYPE = 
"fitImage"KERNEL_CLASSES += "kernel-fitimage"
PREFERRED_PROVIDER_u-boot = 
"u-boot-boundary"PREFERRED_PROVIDER_virtual/bootloader ?= 
"u-boot-boundary"PREFERRED_PROVIDER_virtual/kernel ??= "linux-boundary"
UBOOT_SIGN_ENABLE = "1"UBOOT_SIGN_KEYDIR = 
"/data_local/imx6/keys"UBOOT_SIGN_KEYNAME = "ubootkey.key"UBOOT_MKIMAGE_DTCOPTS 
= "-I dts -O dtb -p 2000"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " \    kernel-image \    kernel-devicetree 
\"...

In uboot:  in include/configs/nitrogen6x.h  I added #define 
CONFIG_OF_CONTROL#define CONFIG_OF_SEPARATE

At the compilation I am getting The following error:    Device Tree Source is 
not correctly specified.
   Please define 'CONFIG_DEFAULT_DEVICE_TREE'   or build with 
'DEVICE_TREE=' argument

Any idea about the root cause?.  Idon't understand why I am getting this error. 
 In my config   I already set
KERNEL_DEVICETREE = "imx6q-sabrelite.dtb \                        
imx6q-nitrogen6x.dtb imx6dl-nitrogen6x.dtb \"
Thank you in advance for your support


Cordialement, Best Regards,Samir MOUHOUNE
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] uBoot, kernel and device tree files

[Mathieu Alexandre-Tétreault]

Hello Srini,

I think what you are looking for is the fitimage, it will allow you to bundle 
the kernel and devicetree together in a single file and it also allows you add 
a signature.

This process is well integrated in yocto, from what I remember activating the 
fitimage is relatively easy:
   - in your machine.conf
   - declare KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPE = 
"fitimage"
   - in your u-boot defconfig (configs/yourboard_defconfig
   - enable CONFIG_FIT=y
   - in your config include/configs/your_board.h change the script to boot your 
fitimage

I hope this helps,

Regards,

Mathieu

> -Message d'origine-
> De : yocto-boun...@yoctoproject.org 
> De la part de Srinivasan, Raja
> Envoyé : August 8, 2018 2:51 PM
> À : yocto@yoctoproject.org
> Objet : [yocto] uBoot, kernel and device tree files
> 
> All
> 
> 
> 
> We are using rocko.on variscite var-som-mx6.
> 
> In order to increase the security of our system (during a system upgrade), we
> are looking to merge uImage (kernel image) and the device tree file into 1
> file. Currently these are 2 different files and are worried that a file copy
> operation might get aborted.
> 
> My research so far indicates mkuboot can be used to merge these. but
> having trouble making this work.
> 
> Need some ideas.
> 
> 
> 
> Any pointers appreciated. srini
> 
> 
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email message and any attachments are
> confidential and may be privileged and are meant to be read by the intended
> recipient only. If you are not the intended recipient, please notify sender
> immediately and destroy all copies of this message and any attachments
> without reading or disclosing their contents. Thank you
> 
> 
> 

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

Re: [yocto] HELP!

[Bas Mevissen]

On 2018-08-09 14:39, Dhanush K.S wrote:

Hello,

I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to
Yocto 2.5.

After cloning the Poky repository, I was confused with which tag to
checkout with.



With a fresh release like Sumo, it is better to stay at the HEAD of the 
sumo branch for some time. Updates here should not break things, but fix 
bugs instead.
When it stabilizes or when you are making a release, you can use a 
certain commit or release tag.



Could you please help me understand the difference between the tags
"SUMO-19.0.0" and "YOCTO-2.5"



Both tags point to the same commit (da3625c52e), so choose one.


As far as I understand, both mean the same since "2.5" is the
DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.

But is still the same with the checkout tags as well?

Many thanks in advance!

Mit freundlichen Grüßen / Best Regards,
Dhanush Keshava Reddy Soppahalli
Mob: +4915216144064


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

Re: [yocto] uBoot, kernel and device tree files

[Srinivasan, Raja]

Mathieu

Appreciate the suggestion. Will give it a shot. Thanks, srini

-Original Message-
From: Mathieu Alexandre-Tétreault [mailto:alexandr...@amotus.ca]
Sent: Thursday, August 9, 2018 8:45 AM
To: Srinivasan, Raja ; yocto@yoctoproject.org
Subject: RE: uBoot, kernel and device tree files

Hello Srini,

I think what you are looking for is the fitimage, it will allow you to bundle 
the kernel and devicetree together in a single file and it also allows you add 
a signature.

This process is well integrated in yocto, from what I remember activating the 
fitimage is relatively easy:
   - in your machine.conf
   - declare KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPE = 
"fitimage"
   - in your u-boot defconfig (configs/yourboard_defconfig
   - enable CONFIG_FIT=y
   - in your config include/configs/your_board.h change the script to boot your 
fitimage

I hope this helps,

Regards,

Mathieu

> -Message d'origine-
> De : yocto-boun...@yoctoproject.org 
> De la part de Srinivasan, Raja Envoyé : August 8, 2018 2:51 PM À :
> yocto@yoctoproject.org Objet : [yocto] uBoot, kernel and device tree
> files
>
> All
>
>
>
> We are using rocko.on variscite var-som-mx6.
>
> In order to increase the security of our system (during a system
> upgrade), we are looking to merge uImage (kernel image) and the device
> tree file into 1 file. Currently these are 2 different files and are
> worried that a file copy operation might get aborted.
>
> My research so far indicates mkuboot can be used to merge these. but
> having trouble making this work.
>
> Need some ideas.
>
>
>
> Any pointers appreciated. srini
>
>
>
>
>
>
> 
>
>
> CONFIDENTIALITY NOTICE: This email message and any attachments are
> confidential and may be privileged and are meant to be read by the
> intended recipient only. If you are not the intended recipient, please
> notify sender immediately and destroy all copies of this message and
> any attachments without reading or disclosing their contents. Thank
> you
>
>
>




CONFIDENTIALITY NOTICE: This email message and any attachments are confidential 
and may be privileged and are meant to be read by the intended recipient only. 
If you are not the intended recipient, please notify sender immediately and 
destroy all copies of this message and any attachments without reading or 
disclosing their contents. Thank you
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] uBoot, kernel and device tree files

[Srinivasan, Raja]

Appreciate the suggestions. I will try them out. thanks, srini

-Original Message-
From: Michal Vokáč [mailto:michal.vo...@ysoft.com]
Sent: Thursday, August 9, 2018 4:41 AM
To: Srinivasan, Raja 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] uBoot, kernel and device tree files

Hi Srini,

On 8.8.2018 20:51, Srinivasan, Raja wrote:
> All
>
> We are using rocko.on variscite var-som-mx6.
>
> In order to increase the security of our system (during a system upgrade), we 
> are looking to merge uImage (kernel image) and the device tree file into 1 
> file. Currently these are 2 different files and are worried that a file copy 
> operation might get aborted.

I understand that what you want to achive by combining the files is 
"relyability" and not "security". Those are totaly different things.

> My research so far indicates mkuboot can be used to merge these. but having 
> trouble making this work.
>
> Need some ideas.
>
> Any pointers appreciated. srini

I am aware of at least two options to combine kernel images and device tree 
files.

Option 1) Append DTB directly to the kernel image

This is the simplest option. Just use cat to concatenate the files and enable 
the CONFIG_ARM_APPENDED_DTB kernel option.
Read the help for the option, it is quite informative.

In this case you do not need to change anything in your boot loader.
Just load and boot the combined image as usual and kernel will do the rest.

Option 2) Use FIT images

I strongly recommend this option over the first one.
FIT images are something like containers that can contain multiple kernel 
images, multiple device tree blobs, multiple initram file systems.
Part of the FIT image then describes what combinations of those files can be 
used to boot.

If your concern is not just reliability but also security than FIT images are 
also better. You can put hashes/signatures of all the files into the 
description of the files and use the hashes in the bootloader to verify the 
images (I never used that.)

In this option you need to change your boot command.

Hope this helps,
Michal




CONFIDENTIALITY NOTICE: This email message and any attachments are confidential 
and may be privileged and are meant to be read by the intended recipient only. 
If you are not the intended recipient, please notify sender immediately and 
destroy all copies of this message and any attachments without reading or 
disclosing their contents. Thank you
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HELP!

[Alexander Kanavin]

You don't need to check out a specific tag. Just switch to the latest
commit in the branch you want (e.g. sumo).

Alex

2018-08-09 14:39 GMT+02:00 Dhanush K.S :
> Hello,
>
> I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
> 2.5.
>
> After cloning the Poky repository, I was confused with which tag to checkout
> with.
>
> Could you please help me understand the difference between the tags
> "sumo-19.0.0" and "yocto-2.5"
>
> As far as I understand, both mean the same since "2.5" is the DISTRO_VERSION
> and "sumo" is the DISTRO_CODENAME.
>
> But is still the same with the checkout tags as well?
>
> Many thanks in advance!
>
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064
>
> --
> ___
> 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] HELP!

[Dhanush K.S]

Hello,

I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
2.5.

After cloning the Poky repository, I was confused with which tag to
checkout with.

Could you please help me understand the difference between the tags
*"sumo-19.0.0"
*and *"yocto-2.5"*

As far as I understand, both mean the same since "2.5" is the
DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.

But is still the same with the checkout tags as well?

Many thanks in advance!

Mit freundlichen Grüßen / Best Regards,
Dhanush Keshava Reddy Soppahalli
Mob: +4915216144064
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.6 M2 RC1

[Yeoh, Ee Peng]

Hi Richard,

There are 23 tests were not executed. 
13 of these tests were related to SDK automated tests (part of it belong to 
galculator test).
6 of these tests (selftest/cases/distrodata.py), where it was configured to be 
skipped by Autobuilder (we will removed these tests from planned tests starting 
new cycle).
2 of these tests (runtime/cases/oe_syslog.py), were skipped due to tests can't 
run with sysklogd installed.
1 of the runtime/xorg tests running on qemuarm64 were not executed by the 
testimage. 

For the eSDK automated tests issue, we had filed for bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12875

Please let me know if any more question.

Thanks,
Yeoh Ee Peng 

-Original Message-
From: richard.pur...@linuxfoundation.org 
[mailto:richard.pur...@linuxfoundation.org] 
Sent: Thursday, August 9, 2018 4:29 PM
To: Yeoh, Ee Peng ; 'yocto@yoctoproject.org' 
; Jolley, Stephen K ; 
Eggleton, Paul 
Cc: Sangal, Apoorv ; Kirkiris, Nectar 

Subject: Re: QA cycle report for 2.6 M2 RC1

On Thu, 2018-08-09 at 05:57 +, Yeoh, Ee Peng wrote:
> === Summary 
>  
> All planned tests were executed except a few SDK automated tests were 
> skipped in Autobuilder (testrun# 9830-9836, 9796-9797).  Team found 
> that these SDK automated tests were running successfully in core- 
> image-sato-sdk image but not the existing core-image-sato used by 
> Autobuilder, investigating why these automated tests were skipped in 
> core-image-sato and no message available in testsdk logfile to explain 
> why it was skipped.

I think Ross just sent a patch for this, assuming it was the galculator test?

>   Team also found that eSDK devtool automated testcase(s) were skipped 
> unexpectedly due to the unknown error on testcase dependency logic, 
> temporary removing the dependency logic and successfully executed the 
> devtool tests.

We should probably have a bug to track and resolve this issue as it hasn't been 
resolved yet as far as I know. I believe its a problem introduced by the 
parallelism changes. We may have to rework the dependency logic.

> New Bugs
> [1] Bug 12866 - [2.6 M2 rc1] wic test_fix_size failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12866
>  
> [2] Bug 12864 - [2.6 M2 rc1] buildhistorydifftest failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12864
>  
> [3] Bug 12869 - [2.6 M2 rc1] libxml test cases failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12869

The good news is that these have all already been fixed in master and are 
understood issues with good resolutions. I don't believe any of them are enough 
to warrant an rc2. My recommendation is we release rc1 subject to my question 
below.

Why does the QA report not show 100% of tests were completed in all cases?

We do need to take the list of bugs in the QA report itself and see if we can 
resolve some of them for the final release, Stephen, your help in 
driving/tracking that would be appreciated.

Cheers,

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

Re: [yocto] QA cycle report for 2.6 M2 RC1

[richard . purdie]

On Thu, 2018-08-09 at 05:57 +, Yeoh, Ee Peng wrote:
> === Summary 
>  
> All planned tests were executed except a few SDK automated tests were
> skipped in Autobuilder (testrun# 9830-9836, 9796-9797).  Team found
> that these SDK automated tests were running successfully in core-
> image-sato-sdk image but not the existing core-image-sato used by
> Autobuilder, investigating why these automated tests were skipped in
> core-image-sato and no message available in testsdk logfile to
> explain why it was skipped.

I think Ross just sent a patch for this, assuming it was the galculator
test?

>   Team also found that eSDK devtool automated testcase(s) were
> skipped unexpectedly due to the unknown error on testcase dependency
> logic, temporary removing the dependency logic and successfully
> executed the devtool tests.

We should probably have a bug to track and resolve this issue as it
hasn't been resolved yet as far as I know. I believe its a problem
introduced by the parallelism changes. We may have to rework the
dependency logic.

> New Bugs
> [1] Bug 12866 - [2.6 M2 rc1] wic test_fix_size failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12866
>  
> [2] Bug 12864 - [2.6 M2 rc1] buildhistorydifftest failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12864
>  
> [3] Bug 12869 - [2.6 M2 rc1] libxml test cases failed
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12869

The good news is that these have all already been fixed in master and
are understood issues with good resolutions. I don't believe any of
them are enough to warrant an rc2. My recommendation is we release rc1
subject to my question below.

Why does the QA report not show 100% of tests were completed in all
cases?

We do need to take the list of bugs in the QA report itself and see if
we can resolve some of them for the final release, Stephen, your help
in driving/tracking that would be appreciated.

Cheers,

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