[yocto] : [meta]: [recipes-bsp]: u-boot: update commit id to the latest one of u-boot upstream

[Meng.Li]

From: Limeng 

Hi Richard,

Could you please help to merge this patch into meta/recipes-bsp/u-boot, branch 
is master?

There are 2 CVE issues fixing in latest u-boot upstream, so
update commit id to involve these fixing patches.


thanks,
Limeng


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

[yocto] [PATCH] u-boot: update commit id to the latest one of u-boot upstream

[Meng.Li]

From: MengLi 

There are 2 CVE issues fixing in latest u-boot upstream, so
update commit id to involve these fixing patches.

Signed-off-by: Meng Li 
---
 meta/recipes-bsp/u-boot/u-boot-common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index 6f4a10b..3648d47 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -8,7 +8,7 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "0157013f4a4945bbdb70bb4d98d680e0845fd784"
+SRCREV = "d01806a8fcbdaedcc67cead56ece572021d97ab7"
 
 SRC_URI = "git://git.denx.de/u-boot.git"
 
-- 
2.7.4

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

Re: [yocto] [poky] Bitbake Issue in Yocto 2.7 M2 rc1:

[Burton, Ross]

On Mon, 28 Jan 2019 at 07:04, pawanKumar  wrote:
> While running bitbake command, I'm facing issue as:
> Error: OE-cores config sanity checker detected a potential misconfiguaration.
> Either fix the cause of this error or at your own risk disable the checker 
> (see sanity.conf)

Above that it would have said what the problem is, can you paste the
entire output?

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

Re: [yocto] [PATCH] u-boot: update commit id to the latest one of u-boot upstream

[Alexander Kanavin]

On Mon, 28 Jan 2019 at 11:20,  wrote:
> There are 2 CVE issues fixing in latest u-boot upstream, so
> update commit id to involve these fixing patches.

We generally don't update commit id's to something random, as that
means picking a source tree in the middle of a development cycle. If
you want to update a component, please use a commit that has a version
tag attached to it.

Also, the patch needs to go to oe-core mailing list.

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

[yocto] Fixing devtool issue with kernel bbhappen do_patch recipe

[Yann CARDAILLAC]

Hi all,

We found a possible bug with boucman_work as mentionned in the IRC.

It seems that when using the SDK there's an issue with the generated file
workspace/appends/linux-yocto_4.18.bbappend (or equivalent depending on
kernel and distro).

In the do_patch rule, if some script are intended to be applied in another
language than python it will fail. I had the case with my BSP (phytec). We
had to change the rule with :

do_patch[noexec] = "1"

so that the rule is not executed which was what was probably intended with
the former :

do_patch() {
:
}

Here's the patch we would use to fix that. It patch the scipt
scripts/lib/devtool/standard.py so that it properly generate the bbappend
file. Please, do not hesitate to give me any feedback on my patch.

Regards,

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Linux Embarqué

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From 3dd03d3a192e088f9db994439cc5511d67333be5 Mon Sep 17 00:00:00 2001
From: ycnakajsph 
Date: Mon, 28 Jan 2019 12:30:03 +0100
Subject: [PATCH] correct do_patch for kernel bbappend in sdk

---
 scripts/lib/devtool/standard.py | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index b7d4d47..ea09bbf 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -849,9 +849,7 @@ def modify(args, config, basepath, workspace):
 if bb.data.inherits_class('kernel', rd):
 f.write('SRCTREECOVEREDTASKS = "do_validate_branches do_kernel_checkout '
 'do_fetch do_unpack do_kernel_configme do_kernel_configcheck"\n')
-f.write('\ndo_patch() {\n'
-':\n'
-'}\n')
+f.write('\ndo_patch[noexec] = "1"\n')
 f.write('\ndo_configure_append() {\n'
 'cp ${B}/.config ${S}/.config.baseline\n'
 'ln -sfT ${B}/.config ${S}/.config.new\n'
-- 
2.7.4

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

[yocto] setting arch of a single package of a recipe

[Joshua DeWeese]

Is it possible, when splitting a recipe into multiple packages, to
change the arch of only one package? (example: setting foopackage-doc
arch to "all") I can't seem to find a way to set PACKAGE_ARCH for a
single package.

I've tried PACKAGE_ARCH_${PN}-doc which didn't work. Grepping for
"PACKAGE_ARCH_" seems to indicate overriding is possible for machine
names at least.

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

[yocto] Help with cleaning/rebuidling

[Edward Wingate]

The first time I did a build, my mosquitto recipe worked.  Then I did
a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
mosquitto', I get this error:

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_copy_aclocals
DEBUG: Python function autotools_copy_aclocals finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
DEBUG: Executing shell function do_configure
CMake Error: The source directory
"/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_configure (log file is located at
/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)

It seems like it doesn't fetch/unpack the source before do_configure.
I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
mosquitto', and they both say all tasks didn't need to be rerun. I
forced it by adding '-f', but that didn't help either.

I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:

=== BEGIN RECIPE ===
SUMMARY = "MQTT 3.1 compliant library"
HOMEPAGE = "https://mosquitto.org";
MAINTAINER = "Robert Lehmann "

LICENSE = "EPL-1.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"

SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
SRC_URI[sha256sum] =
"fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"

DEPENDS = "openssl"
RDEPENDS_${PN} = "util-linux"

inherit cmake

# Specify any options you want to pass to cmake using EXTRA_OECMAKE:
EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
=== END RECIPE ===

Can anyone help with this?

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

[yocto] Yocto Project Unassigned Bugs - Help Needed

[Jolley, Stephen K]

All,



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 294 unassigned 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.7", 
"2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7" and 
then "2.8".



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 
(stephen.k.jol...@intel.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_Bugs


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] SRC URI checksums

[Edward Wingate]

I have a recipe that has a SRC_URI retrieving from a mercurial repo:
SRC_URI = "hg://server/project;module=name;rev=tip"
SRC_URI[md5sum] = "xxx"
SRC_URI[sha256sum] = "yyy"

I changed the SRC_URL to retreive from a specific revision instead of tip:
SRC_URI = "hg://server/project;module=name;rev=1234567890"

I went ahead and did a bitbake, expecting it to complain about the
SRC_URI checksums not matching, and I would go ahead and update the
checksums from the error output.

But it succeeded, building with the correct revision.  I thought the
SRC_URI checksums had to be updated when the SRC_URI changes?

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

Re: [yocto] Yocto Porject

[Scott Rifenbark]

Hi Don,

I can't really advise you on this as I am not a Yocto developer.  However,
I can forward this question to the yocto@yoctoproject.org mail group and,
in particular, to a resource that is looking closely at kernel stuff to
help improve that manual and get it more up-to-date.  That guy is named
Richard Griffiths of Intel.  You should be able to get some help with
this.  Sorry... I wish I was a crack YP developer :)

Thanks,
Scott

On Sun, Jan 27, 2019 at 11:50 AM Don Osmond  wrote:

> Scott
>
> I have been reading your
> https://www.yoctoproject.org/docs/2.4/kernel-dev/kernel-dev.html and it
> has been very helpful.  I have a project where I am needing to get the
> ability to use iptables NAT which does not come in the core image from Digi
> which also uses Yocto.  In my Ubuntu 16.04 LTS development VM, I am able to
> build the base image (bitbake dey-image-qt), menuconfig the kernel config
> (bitbake -c devshell virtual/kernel), compile the kernel (bitbake -C
> compile virtual/kernel).  The results are in the
> /workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc as see in list below:
>
>
>
> dosmond@ubuntu:/workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc$ ls
>
> boot.scr
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.boot.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.recovery.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.manifest
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.tar.bz2
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.testdata.json
>
> dey-image-qt-x11-ccimx6ulsbc.boot.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc.manifest
>
> dey-image-qt-x11-ccimx6ulsbc.recovery.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc.tar.bz2
>
> dey-image-qt-x11-ccimx6ulsbc.testdata.json
>
> dey-image-qt-x11-ccimx6ulsbc.ubifs
>
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.rootfs.cpio.gz.u-boot.tf
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.rootfs.manifest
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.testdata.json
>
> dey-image-recovery-initramfs-ccimx6ulsbc.cpio.gz.u-boot.tf
>
> dey-image-recovery-initramfs-ccimx6ulsbc.manifest
>
> dey-image-recovery-initramfs-ccimx6ulsbc.testdata.json
>
> imx6ul-ccimx6ulsbc.dtb
>
> imx6ul-ccimx6ulsbc-id135.dtb
>
> imx6ul-ccimx6ulsbc-id136.dtb
>
> imx6ul-ccimx6ulsbc-wb.dtb
>
> install_linux_fw_sd.scr
>
> modules--4.9-r0.5-ccimx6ulsbc-20190127182701.tgz
>
> modules-ccimx6ulsbc.tgz
>
> u-boot-ccimx6ulsbc1GB-2017.03-r0.imx
>
> u-boot-ccimx6ulsbc1GB.imx
>
> u-boot-ccimx6ulsbc-2017.03-r0.imx
>
> u-boot-ccimx6ulsbc.imx
>
> u-boot-ccimx6ulsbc.imx-ccimx6ulsbc
>
> u-boot-ccimx6ulsbc.imx-ccimx6ulsbc1GB
>
> u-boot.imx
>
> zImage
>
> zImage--4.9-r0.5-ccimx6ulsbc-20190127182701.bin
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id135-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id136-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-wb-20190127182701.dtb
>
> zImage-ccimx6ulsbc.bin
>
> zImage-imx6ul-ccimx6ulsbc.dtb
>
> zImage-imx6ul-ccimx6ulsbc-id135.dtb
>
> zImage-imx6ul-ccimx6ulsbc-id136.dtb
>
> zImage-imx6ul-ccimx6ulsbc-wb.dtb
>
>
>
> So, what I am having an issue with are the steps to get the latest kernel
> changes a part of the image?  I thought if I ran “bitbake dey-image-qt”
> again that it would.  I think I am missing something.  Anything you can
> share would be greatly appreciated.
>
> Thanks
>
> Don
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] SRC URI checksums

[Lukasz Zemla]

> I have a recipe that has a SRC_URI retrieving from a mercurial repo:
> SRC_URI = "hg://server/project;module=name;rev=tip"
> SRC_URI[md5sum] = "xxx"
> SRC_URI[sha256sum] = "yyy"
> 
> I changed the SRC_URL to retreive from a specific revision instead of tip:
> SRC_URI = "hg://server/project;module=name;rev=1234567890"
> 
> I went ahead and did a bitbake, expecting it to complain about the SRC_URI
> checksums not matching, and I would go ahead and update the checksums
> from the error output.
> 
> But it succeeded, building with the correct revision.  I thought the SRC_URI
> checksums had to be updated when the SRC_URI changes?

Checksums were introduced to ensure data consistency. They are not checked if 
SRC_URI points to repository (svn, git, hg..., it is assumed that  repository 
provides its own mechanism to ensure data correctness).

Best regards,
Lukasz
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] SRC URI checksums

[Burton, Ross]

On Mon, 28 Jan 2019 at 19:23, Lukasz Zemla  wrote:
> Checksums were introduced to ensure data consistency. They are not checked if 
> SRC_URI points to repository (svn, git, hg..., it is assumed that  repository 
> provides its own mechanism to ensure data correctness).

To clarify, the checksums are only used when download tarballs.

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

Re: [yocto] [EXTERNAL] SRC URI checksums

[Edward Wingate]

Thank you.  I must have based the recipe on one that downloaded a
tarball, and didn't notice until now the checksums never had to be
changed.

On Mon, Jan 28, 2019 at 11:25 AM Burton, Ross  wrote:
>
> On Mon, 28 Jan 2019 at 19:23, Lukasz Zemla  wrote:
> > Checksums were introduced to ensure data consistency. They are not checked 
> > if SRC_URI points to repository (svn, git, hg..., it is assumed that  
> > repository provides its own mechanism to ensure data correctness).
>
> To clarify, the checksums are only used when download tarballs.
>
> Ross
> --
> ___
> 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] [meta-raspberrypi] change kernel version from recipe

[Antonio Santagiuliana]

Hi,
which is the right way to change the Kernel version to build  when using
meta-raspberrypi ?
For example I want to change from 4.14.39 to 4.14.52, without changing
anything else in the meta-raspberrypi layer. is it possible ?
Is it just  to define "LINUX_VERSION" in the local.conf file ?
Should I change anything else regarding u-boot related recipes or device
tree or other ?


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

[yocto] Expansion Error during parsing of glibc_2.28 recipe

[Dhanush K.S]

Hello,

I'm trying to upgrade the glibc recipe from version 2.27 to 2.28 in Yocto
Sumo 2.5. Building the recipe for both qemux86 and for arm-cortex-a8
machines throws an Expansion error as below.

WARNING: /source/meta-openembedded/meta-oe/recipes-extended/liblockfile/
liblockfile_1.14.bb: Unable to get checksum for liblockfile SRC_URI entry
0001-Makefile.in-install-nfslock.so-and-nfslock.so.0.patch: file could not
be found   | ETA:  0:00:58
WARNING: /source/poky-sumo-19.0.0/meta/recipes-core/glibc/glibc_2.28.bb:
Exception during build_dependencies for
do_fix_readlib_c##
   | ETA:  0:00:04
WARNING: /source/poky-sumo-19.0.0/meta/recipes-core/glibc/glibc_2.28.bb:
Error during finalise of /source/poky-sumo-19.0.0/meta/recipes-core/glibc/
glibc_2.28.bb
ERROR: ExpansionError during parsing
/source/poky-sumo-19.0.0/meta/recipes-core/glibc/glibc_2.28.bb
Traceback (most recent call last):
  File "/source/poky-sumo-19.0.0/meta/classes/utils.bbclass", line 331, in
all_multilib_tune_values(d=, var='GLIBC_GETLOADER', unique=True, need_split=True,
delim=' '):
 values = []
>value = d.getVar(var) or ""
 if value != "":
  File "/source/poky-sumo-19.0.0/bitbake/lib/bb/data_smart.py", line 608,
in DataSmart.getVar(var='GLIBC_GETLOADER', expand=True,
noweakdefault=False, parsing=False):
 def getVar(self, var, expand=True, noweakdefault=False,
parsing=False):
>return self.getVarFlag(var, "_content", expand, noweakdefault,
parsing)

  File "/source/poky-sumo-19.0.0/bitbake/lib/bb/data_smart.py", line 794,
in DataSmart.getVarFlag(var='GLIBC_GETLOADER', flag='_content',
expand=True, noweakdefault=False, parsing=False):
 cachename = var + "[" + flag + "]"
>value = self.expand(value, cachename)

  File "/source/poky-sumo-19.0.0/bitbake/lib/bb/data_smart.py", line 436,
in DataSmart.expand(s='${@get_linuxloader(d)}', varname='GLIBC_GETLOADER'):
 def expand(self, s, varname = None):
>return self.expandWithRefs(s, varname).value

  File "/source/poky-sumo-19.0.0/bitbake/lib/bb/data_smart.py", line 426,
in DataSmart.expandWithRefs(s='${@get_linuxloader(d)}',
varname='GLIBC_GETLOADER'):
 except Exception as exc:
>raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable GLIBC_GETLOADER,
expression was ${@get_linuxloader(d)} which triggered exception NameError:
name 'get_linuxloader' is not defined

WARNING: /source/poky-sumo-19.0.0/meta/recipes-core/glibc/
glibc-initial_2.28.bb: Exception during build_dependencies for
do_fix_readlib_c
WARNING: /source/poky-sumo-19.0.0/meta/recipes-core/glibc/
glibc-initial_2.28.bb: Error during finalise of
/source/poky-sumo-19.0.0/meta/recipes-core/glibc/glibc-initial_2.28.bb

Using devtool to upgrade the recipe doesn't work as well. Just changes the
recipe name but the SRC_URI remains the same as that of v2.27.

What am I missing here?

Here is my build config.

*Build Configuration:
*>* BB_VERSION   = "1.37.0"
*>* BUILD_SYS= "x86_64-linux"
*>* NATIVELSBSTRING  = "universal-4.8"
*>* TARGET_SYS   = "arm-poky-linux-gnueabi"
*>* MACHINE  = "arm-cortex-a8"
*>* DISTRO   = "poky"
*>* DISTRO_VERSION   = "2.5"
*>* TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
*>* TARGET_FPU   = "hard"*>* meta-poky
*>* meta-yocto-bsp*>* meta-oe  =
"master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2*

*Thanks!*

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

Re: [yocto] Yocto Porject

[Richard A Griffiths]

On Mon, 2019-01-28 at 10:33 -0800, Scott Rifenbark wrote:
> Hi Don, 
> 
> I can't really advise you on this as I am not a Yocto developer. 
> However, I can forward this question to the yocto@yoctoproject.org
> mail group and, in particular, to a resource that is looking closely
> at kernel stuff to help improve that manual and get it more up-to-
> date.  That guy is named Richard Griffiths of Intel.  You should be
> able to get some help with this.  Sorry... I wish I was a crack YP
> developer :)
> 
> Thanks, 
> Scott
> 
> On Sun, Jan 27, 2019 at 11:50 AM Don Osmond 
> wrote:
> > Scott
> > I have been reading your https://www.yoctoproject.org/docs/2.4/kern
> > el-dev/kernel-dev.html and it has been very helpful.  I have a
> > project where I am needing to get the ability to use iptables NAT
> > which does not come in the core image from Digi which also uses
> > Yocto.  In my Ubuntu 16.04 LTS development VM, I am able to build
> > the base image (bitbake dey-image-qt), menuconfig the kernel config
> > (bitbake -c devshell virtual/kernel), compile the kernel (bitbake
> > -C compile virtual/kernel).  The results are in the
> > /workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc as see in list
> > below:
> >  
> > dosmond@ubuntu:/workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc
> > $ ls
> > boot.scr
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.boot.ubifs
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.recovery.ubifs
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.manifest
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.tar.bz2
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.ubifs
> > dey-image-qt-x11-ccimx6ulsbc-20190127164412.testdata.json
> > dey-image-qt-x11-ccimx6ulsbc.boot.ubifs
> > dey-image-qt-x11-ccimx6ulsbc.manifest
> > dey-image-qt-x11-ccimx6ulsbc.recovery.ubifs
> > dey-image-qt-x11-ccimx6ulsbc.tar.bz2
> > dey-image-qt-x11-ccimx6ulsbc.testdata.json
> > dey-image-qt-x11-ccimx6ulsbc.ubifs
> > dey-image-recovery-initramfs-ccimx6ulsbc-
> > 20190127161551.rootfs.cpio.gz.u-boot.tf
> > dey-image-recovery-initramfs-ccimx6ulsbc-
> > 20190127161551.rootfs.manifest
> > dey-image-recovery-initramfs-ccimx6ulsbc-
> > 20190127161551.testdata.json
> > dey-image-recovery-initramfs-ccimx6ulsbc.cpio.gz.u-boot.tf
> > dey-image-recovery-initramfs-ccimx6ulsbc.manifest
> > dey-image-recovery-initramfs-ccimx6ulsbc.testdata.json
> > imx6ul-ccimx6ulsbc.dtb
> > imx6ul-ccimx6ulsbc-id135.dtb
> > imx6ul-ccimx6ulsbc-id136.dtb
> > imx6ul-ccimx6ulsbc-wb.dtb
> > install_linux_fw_sd.scr
> > modules--4.9-r0.5-ccimx6ulsbc-20190127182701.tgz
> > modules-ccimx6ulsbc.tgz
> > u-boot-ccimx6ulsbc1GB-2017.03-r0.imx
> > u-boot-ccimx6ulsbc1GB.imx
> > u-boot-ccimx6ulsbc-2017.03-r0.imx
> > u-boot-ccimx6ulsbc.imx
> > u-boot-ccimx6ulsbc.imx-ccimx6ulsbc
> > u-boot-ccimx6ulsbc.imx-ccimx6ulsbc1GB
> > u-boot.imx
> > zImage
> > zImage--4.9-r0.5-ccimx6ulsbc-20190127182701.bin
> > zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-20190127182701.dtb
> > zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id135-20190127182701.dtb
> > zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id136-20190127182701.dtb
> > zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-wb-20190127182701.dtb
> > zImage-ccimx6ulsbc.bin
> > zImage-imx6ul-ccimx6ulsbc.dtb
> > zImage-imx6ul-ccimx6ulsbc-id135.dtb
> > zImage-imx6ul-ccimx6ulsbc-id136.dtb
> > zImage-imx6ul-ccimx6ulsbc-wb.dtb
> >  
> > So, what I am having an issue with are the steps to get the latest
> > kernel changes a part of the image?  I thought if I ran “bitbake
> > dey-image-qt” again that it would.  I think I am missing
> > something.  Anything you can share would be greatly appreciated.
> > Thanks
> > Don
> > 
Hi Don,
Are you asking how do you save changes to your kernel configuration so
they become part of the kernel recipe? If so, the 
2.2.3 Changing The Configuration section of the Kernel Dev manual gives
an example.
If that is not what you're asking, please clarify and I will do my best
to help.
Regards,
Richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH V2] patchwork: Add a dockerfile for deploy patchwork and patchtest

[Randy MacLeod]

On 1/16/19 12:37 AM, changqing...@windriver.com wrote:

From: Changqing Li 


Ping?

Jose, are you maintaining this repo?
  http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/about/
You were the committer for most of the recent work.

../Randy


Add a dockerfile for easy deploy patchwork and patchtest in
docker

Signed-off-by: Changqing Li 
---
  Dockerfile.pw | 52 +++
  README.pw | 32 ++
  requirements.txt  | 12 ++
  scripts/pw_createsuperuser.sh |  5 +
  scripts/pw_getmail.sh | 11 +
  scripts/pw_migrate.sh |  5 +
  scripts/pw_runwebserver.sh| 12 ++
  7 files changed, 129 insertions(+)
  create mode 100644 Dockerfile.pw
  create mode 100644 README.pw
  create mode 100644 requirements.txt
  create mode 100755 scripts/pw_createsuperuser.sh
  create mode 100755 scripts/pw_getmail.sh
  create mode 100755 scripts/pw_migrate.sh
  create mode 100755 scripts/pw_runwebserver.sh

diff --git a/Dockerfile.pw b/Dockerfile.pw
new file mode 100644
index 000..ae3c1ee
--- /dev/null
+++ b/Dockerfile.pw
@@ -0,0 +1,52 @@
+FROM ubuntu:latest
+MAINTAINER owner 
+
+EXPOSE 8080
+
+ENV PYTHONUNBUFFERED=1 \
+LANG=en_US.UTF-8 \
+LC_ALL=en_US.UTF-8 \
+LC_CTYPE=en_US.UTF-8 \
+PATH="$PATH:/opt/patchwork/git-pw:/opt/patchtest:/opt/patchtest/scripts"
+
+RUN  apt-get update \
+&& apt-get dist-upgrade -y \
+&& apt-get install -y --no-install-recommends \
+autoconf \
+gcc \
+g++ \
+make \
+locales \
+wget \
+curl \
+cron \
+python-pip \
+python-dev \
+python-setuptools \
+python3-pip \
+python3-dev \
+libmysqlclient-dev \
+git-core \
+getmail4 \
+&& sh -c "echo \"en_US.UTF-8 UTF-8\" >> /etc/locale.gen" \
+&& locale-gen en_US.UTF-8 \
+&& update-locale \
+&& pip2 install wheel \
+&& pip3 install wheel \
+&& pip3 install setuptools \
+&& apt-get autoremove --purge -y \
+&& rm -rf /var/lib/apt/lists/* \
+&& apt-get clean
+ADD ./patchwork /opt/patchwork
+ADD ./patchtest /opt/patchtest
+ADD ./patchtest-oe /opt/patchtest-oe
+ADD ./getmailrc /opt/getmail/getmailrc
+RUN  pip2 install -r /opt/patchwork/requirements.txt \
+&& pip3 install -r /opt/patchtest/requirements.txt \
+&& pip3 install  -r /opt/patchtest-oe/requirements.txt \
+&& mkdir -p /opt/getmail \
+&& mkdir -p /opt/pw-logs \
+&& git config --global user.email "patcht...@patchtest.com" \
+&& git config --global user.name "patchtest" \
+&& /opt/patchtest/scripts/create-host-test-folder -t /opt/pw-test \
+&& /opt/patchtest/scripts/create-host-crontab -c /opt/pw-test-cron
diff --git a/README.pw b/README.pw
new file mode 100644
index 000..ffa7af1
--- /dev/null
+++ b/README.pw
@@ -0,0 +1,32 @@
+* Dockerfile.pw deploy patchwork, patchtest, patchtest-oe in docker
+
+* Dockerfile.pw is just an example, you can adjust according to your
+  deploy condition, like not use getmail, but use postfix.
+
+* requirements.txt,  just for refer, you can also rewrite this
+  according to patchwork'doc and accoridng to your deploy condition.
+
+* scripts folder hold the files will be used during deploy with docker.
+
+* Deploy steps:
+
+1. Clone patchwork, patchtest, patchtest-oe first, also put getmailrc used by
+   Dockerfile.pw under the same folder.
+
+2. Build docker image with Dockerfile.pw
+$docker build -t pw -f ./patchwork/Dockerfile.pw .
+
+3. use mariadb as dataserver:
+$ docker pull mariadb
+$ docker run -d --name pw-db -e MYSQL_ROOT_PASSWORD=123456 -e 
MYSQL_DATABASE=pwdb -v /pw/pwdb:/var/lib/mysql mariadb
+
+5. run web server
+docker run -d --name pw-web --link pw-db:pw-db -p 8080:8080 pw 
"/opt/patchwork/scripts/pw_runwebserver.sh"
+
+6. config pw
+docker exec -it pw-web /opt/patchwork/scripts/pw_migrate.sh
+docker exec -it pw-web /opt/patchwork/scripts/pw_createsuperuser.sh
+
+7. run patchwork
+docker run -d --name pw-mail --link pw-db:pw-db pw 
"/opt/patchwork/scripts/pw_getmail.sh"
+
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 000..b8f68f2
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,12 @@
+django==1.8.0
+sqlparse==0.2.4
+celery==3.1.20
+django_filter==0.11.0
+djangorestframework==2.4.8
+drf-nested-routers==0.11.1
+psycopg2>=2.7,<2.8
+mysqlclient
+jsonfield
+enum34
+GitPython
+requests
diff --git a/scripts/pw_createsuperuser.sh b/scripts/pw_createsuperuser.sh
new file mode 100755
index 000..324ce72
--- /dev/null
+++ b/scripts/pw_createsuperuser.sh
@@ -0,0 +1,5 @@
+#!/bin/bash
+
+pw_dir='/opt/patchwork'
+
+(cd $pw_dir; ./manage.py createsuperuser)
diff --git a/scripts/pw_getmail.sh b/scripts/pw_getmail.sh
new file mode 100755
index 000..fadf7c9
--- /dev/null
+++ b/scripts/pw_getmail.sh
@@ -0,0 +1,11 @@
+#!/bin/bash
+
+s

[yocto] [YP Core] Thud moved out of active releases

[Hopp, Denis]

Hello all,

is it intended that the thud release 2.6 documents overview went 
into archived documents? I can't find any news about it and thud is
still promoted as latest release on the frontpage.
(https://www.yoctoproject.org/)
Or is this standard procedure and 2.6.1 will follow shortly?

Greetings


smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Error: pulsar-image-14.0.0-r0 do_rootfs: Could not invoke dnf. Command

[rajshekharsanda]

Iam trying build an image for R-CAR H3 using GENIVI 14 (ROCKO).

*My Native System:*
OS: Ubuntu 16.04
RAM: 64 GB



*The build configuration is:*

BB_VERSION   = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "h3ulcb"
DISTRO   = "poky-ivi-systemd"
DISTRO_VERSION   = "14.0.0"
TUNE_FEATURES= "aarch64 cortexa57-cortexa53"
TARGET_FPU   = ""
SOC_FAMILY   = "rcar-gen3:r8a7795"
meta
meta-poky
meta-yocto-bsp
meta-ivi
meta-ivi-bsp
meta-optee
meta-oe
meta-rcar-gen3
meta-filesystems
meta-multimedia
meta-python
meta-rtlwifi-master  = ":"

*NOTE*: All the above packages are available locally in my native System.


*The error details are as follows:*

when doing bitbake pulsar-image. iam getting the following errors.

ERROR: pulsar-image-14.0.0-r0 do_rootfs: Could not invoke dnf. Command
'/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/recipe-sysroot-native/usr/bin/dnf
-y -c
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs/etc/yum.repos.d
--repofrompath=oe-repo,/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/oe-rootfs-repo
--installroot=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs
--setopt=logdir=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/temp
--nogpgcheck install util-linux libopus0 screen alsa-utils libx264-148
bluez5 dnf node-startup-controller libsdl-1.2-0 connman-client
libgnome-keyring0 libsdl2-2.0-0 rpcbind libc6 perf libdrm2 alsa-lib
libc6-staticdev curl libjansson4 packagegroup-placeholder-component-p1
node-state-manager gstreamer1.0-libav usbutils gstreamer1.0-plugins-ugly
libinput10 wayland-ivi-extension make lame mesa strace libusbg
libgupnp-1.0-4 cmake initscripts rtl8812au libusb-0.1-4 udev alsa-tools
audiomanager node-health-monitor update-rc.d libmediaart-2.0-0
gstreamer1.0-plugins-base weston liba52-0 libfontconfig1 mpeg2dec vala
pkgconfig glibmm libfreeimage3 gstreamer1.0 libcommonapi-dbus3.1.12
packagegroup-abstract-component-p2 libgif7 autoconf wayland dbus-1
gstreamer1.0-omx gstreamer1.0-plugins-good shadow sed
gstreamer1.0-plugins-bad rpm run-postinsts base-passwd gcc libts-1.0-0
dlt-daemon openssh libflacdla-l2 flex wpa-supplicant
packagegroup-specific-component-p2 libfreetype6 libgcc1 connman libsolv0
packagegroup-core-boot-genivi pulseaudio alsa-plugins openssl tzdata
omx-user-module packagegroup-specific-component-p1 binutils libgee-0.8-2
packagegroup-abstract-component-p1 g++ libsdl-ttf-2.0-0 gdb libalacdla-l2
perl systemtap' returned 1:
Added oe-repo repo from
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/oe-rootfs-repo
Last metadata expiration check: 0:00:00 ago on Wed 23 Jan 2019 04:32:09 AM
UTC.
No package alsa-lib available.
Error: Unable to find a match

ERROR: pulsar-image-14.0.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/temp/log.do_rootfs.10547
ERROR: Task
(/home/buildpc/Genivi14/meta-ivi-14/meta-ivi/recipes-yocto-ivi/images/pulsar-image.bb:do_rootfs)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 5089 tasks of which 5088 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

/home/buildpc/Genivi14/meta-ivi-14/meta-ivi/recipes-yocto-ivi/images/pulsar-image.bb:
do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Triggering rebuild on a recipe when MACHINE changes

[Kristupas Savickas]

I have a few recipes that should rebuild when value of MACHINE variable 
changes. How can this be accomplished? I tried using do_compile[vardeps] 
+= "MACHINE", but this didn't seem to have any affect.


--
Pagarbiai,
Linux programuotojas
Kristupas Savickas
+370 633 36795

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