[yocto] [PATCH 2/2] oeqa/systemd_boot: Drop OETestID

[Armin Kuster]

From: Richard Purdie 

Matching changes in OE-Core. drop OETestID.

Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
 meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py 
b/meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py
index dfd739a..0a3a2cd 100644
--- a/meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py
+++ b/meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py
@@ -1,14 +1,11 @@
 import os
 
 from oeqa.selftest.case import OESelftestTestCase
-from oeqa.core.decorator.oeid import OETestID
 from oeqa.core.decorator.depends import OETestDepends
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
 
 class Systemdboot(OESelftestTestCase):
 
-@OETestID(1445)
-@OETestID(1528)
 def test_efi_systemdboot_images_can_be_built(self):
 """
 Summary: Check if systemd-boot images can be built correctly
-- 
2.7.4

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

[yocto] [PATCH 1/2] linux-yocto: update genericx86* SRCREV for 4.19

[Armin Kuster]

From: Naveen Saini 

Bump to kernel release v4.19.19

Signed-off-by: Naveen Saini 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend
index 8e708cb..6025230 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend
@@ -8,8 +8,8 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
-SRCREV_machine_genericx86-64 ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_genericx86?= "11e0e616ed095bb8012e1b4a231254c9656a0193"
+SRCREV_machine_genericx86-64 ?= "11e0e616ed095bb8012e1b4a231254c9656a0193"
 SRCREV_machine_edgerouter ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
 SRCREV_machine_beaglebone-yocto ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
 SRCREV_machine_mpc8315e-rdb ?= "8b60f968823256f5d2889c4520d70299ca21411b"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.19.14"
-LINUX_VERSION_genericx86-64 = "4.19.14"
+LINUX_VERSION_genericx86 = "4.19.19"
+LINUX_VERSION_genericx86-64 = "4.19.19"
 LINUX_VERSION_edgerouter = "4.19.14"
 LINUX_VERSION_beaglebone-yocto = "4.19.14"
 LINUX_VERSION_mpc8315e-rdb = "4.19.14"
-- 
2.7.4

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

[yocto] [PATCH 0/2] meta-yocto warrior-next patch review

[Armin Kuster]

From: Armin Kuster 

please review these change for the next meta-yocto warrior update

The following changes since commit 299b4150c66520985415fcc91119d563f7ba663c:

  poky.conf: Bump version for 2.7 warrior release (2019-04-12 13:50:29 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib meta-yocto/stable/warrior-nmut
  http://git.yoctoproject.org/cgit.cgi//log/?h=meta-yocto/stable/warrior-nmut

Naveen Saini (1):
  linux-yocto: update genericx86* SRCREV for 4.19

Richard Purdie (1):
  oeqa/systemd_boot: Drop OETestID

 meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py| 3 ---
 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend | 8 
 2 files changed, 4 insertions(+), 7 deletions(-)

-- 
2.7.4

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

Re: [yocto] Yocto Project Upcoming Conferences and Developer Days

[akuster]

On 5/13/19 1:09 PM, Joshua Watt wrote:
> On Mon, May 6, 2019 at 12:43 PM Volosincu, Andreea S
>  wrote:
>> Hi Joshua,
>>
>>
>>
>> The event will be listed on the co-located events page and there will be a 
>> cost associated with it. Please check this page in a couple of days - 
>> https://events.linuxfoundation.org/events/elc-north-america-2019/program/co-located-events/
>>
>>
>>
>> You will be able to add this to your ELC registration.
> Thanks. I'm hopefully not being too annoying, but us there an ETA on
> when the registration will be open? The early registration deadline
> for the ELC is May 20th, which is basically 5 working days, and I will
> need a few days to push the paperwork though, so it's getting a little
> close for my comfort :)
Add on events can be added later or purchased on-site.  I have done in
the past so I would reg for early bird now.
>
> If it isn't going to be available soon, I do have a few questions:
> 1. Is it possible to register for the Dev Day after you have
> registered for the ELC?
> 2. Is there a rough (preferably upper limit) estimate for the cost?
Good question. This is weird year for things so I can't comment on the
new norm.

- Armin
>
>
>>
>> Thanks!
>>
>> Andreea
>>
>>
>>
>> From: Joshua Watt [mailto:jpewhac...@gmail.com]
>> Sent: Monday, May 6, 2019 8:07 AM
>> To: Volosincu, Andreea S ; 
>> yocto-advoc...@yoctoproject.org; Yocto list discussion 
>> 
>> Subject: Re: [yocto] Yocto Project Upcoming Conferences and Developer Days
>>
>>
>>
>> On Fri, 2019-05-03 at 18:01 +, Volosincu, Andreea S wrote:
>>
>> Greetings,
>>
>>
>>
>> Yocto Project is pleased to announce the plans for the upcoming Embedded 
>> Linux Conferences in NA and Europe.
>>
>>
>>
>> Here is a snapshot of our schedule:
>>
>>
>>
>> ELC NA – Wednesday, August 21 - 23, 2019, Hilton San Diego Bayfront, San 
>> Diego, CA
>>
>>Yocto Project is a sponsor. We’ll see you on the show 
>> floor
>>
>>
>>
>> ELC NA Dev Day – Tuesday, August 20, 2019 - 8:00AM - 6:00PM
>>
>> Set-up: 1 Meeting Room - Classroom Seating ( 60 people)
>>
>> Level: Intermediate – Advanced. Participants will receive beginner material 
>> (videos and presentations) as pre-requisites
>>
>> Includes: Morning Break, Buffet Lunch, Beer & Wine Reception with light 
>> appetizers
>>
>>
>>
>> Is there any registration cost for this event, and how does one register?
>>
>>
>>
>>
>>
>>
>>
>> ELCE – Monday, October 28 -30, 2019, Lyon Convention Centre, Lyon, France
>>
>>   Yocto Project is a sponsor. We’ll see you on the show floor
>>
>>
>>
>> ELCE Yocto Project Summit – Dates & Times:
>>
>> Thursday, October 31, 2019 - 8:00AM - 6:00PM
>>
>>November 1, 2019 - 8:00 am - 6:00PM
>>
>> Set-up:
>>
>> Day 1: 1 Meeting Room - Theater Seating for 100 for Yocto Project talks
>>
>> Day 2: 2 Meeting Rooms - Mixed Classroom/Theater seating for 60 & Classroom 
>> seating for 40 (for maintainers and users)
>>
>> Includes:
>>
>> Morning Break for 2 days
>>
>> Buffet Lunch for 2 days
>>
>> Beer & Wine Reception with light appetizers for 1 day
>>
>>
>>
>> The goal for the second day of the summit is to build and bring the 
>> community together. We are interested to hear your opinions and ideas on how 
>> that day and those rooms should be used for. Please send your ideas to 
>> Andreea Volosincu and Philip Balister.
>>
>>
>>
>> We will call out an Advocacy meeting in a couple of weeks to go over plans 
>> and vote on the ideas for the second day of the summit.
>>
>>
>>
>> Thanks!
>>
>> Andreea
>>
>> Yocto Project Advocacy Lead
>>
>> --
>>
>> Joshua Watt 

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

Re: [yocto] Yocto Project Upcoming Conferences and Developer Days

[Joshua Watt]

On Mon, May 6, 2019 at 12:43 PM Volosincu, Andreea S
 wrote:
>
> Hi Joshua,
>
>
>
> The event will be listed on the co-located events page and there will be a 
> cost associated with it. Please check this page in a couple of days - 
> https://events.linuxfoundation.org/events/elc-north-america-2019/program/co-located-events/
>
>
>
> You will be able to add this to your ELC registration.

Thanks. I'm hopefully not being too annoying, but us there an ETA on
when the registration will be open? The early registration deadline
for the ELC is May 20th, which is basically 5 working days, and I will
need a few days to push the paperwork though, so it's getting a little
close for my comfort :)

If it isn't going to be available soon, I do have a few questions:
1. Is it possible to register for the Dev Day after you have
registered for the ELC?
2. Is there a rough (preferably upper limit) estimate for the cost?


>
>
> Thanks!
>
> Andreea
>
>
>
> From: Joshua Watt [mailto:jpewhac...@gmail.com]
> Sent: Monday, May 6, 2019 8:07 AM
> To: Volosincu, Andreea S ; 
> yocto-advoc...@yoctoproject.org; Yocto list discussion 
> 
> Subject: Re: [yocto] Yocto Project Upcoming Conferences and Developer Days
>
>
>
> On Fri, 2019-05-03 at 18:01 +, Volosincu, Andreea S wrote:
>
> Greetings,
>
>
>
> Yocto Project is pleased to announce the plans for the upcoming Embedded 
> Linux Conferences in NA and Europe.
>
>
>
> Here is a snapshot of our schedule:
>
>
>
> ELC NA – Wednesday, August 21 - 23, 2019, Hilton San Diego Bayfront, San 
> Diego, CA
>
>Yocto Project is a sponsor. We’ll see you on the show floor
>
>
>
> ELC NA Dev Day – Tuesday, August 20, 2019 - 8:00AM - 6:00PM
>
> Set-up: 1 Meeting Room - Classroom Seating ( 60 people)
>
> Level: Intermediate – Advanced. Participants will receive beginner material 
> (videos and presentations) as pre-requisites
>
> Includes: Morning Break, Buffet Lunch, Beer & Wine Reception with light 
> appetizers
>
>
>
> Is there any registration cost for this event, and how does one register?
>
>
>
>
>
>
>
> ELCE – Monday, October 28 -30, 2019, Lyon Convention Centre, Lyon, France
>
>   Yocto Project is a sponsor. We’ll see you on the show floor
>
>
>
> ELCE Yocto Project Summit – Dates & Times:
>
> Thursday, October 31, 2019 - 8:00AM - 6:00PM
>
>November 1, 2019 - 8:00 am - 6:00PM
>
> Set-up:
>
> Day 1: 1 Meeting Room - Theater Seating for 100 for Yocto Project talks
>
> Day 2: 2 Meeting Rooms - Mixed Classroom/Theater seating for 60 & Classroom 
> seating for 40 (for maintainers and users)
>
> Includes:
>
> Morning Break for 2 days
>
> Buffet Lunch for 2 days
>
> Beer & Wine Reception with light appetizers for 1 day
>
>
>
> The goal for the second day of the summit is to build and bring the community 
> together. We are interested to hear your opinions and ideas on how that day 
> and those rooms should be used for. Please send your ideas to Andreea 
> Volosincu and Philip Balister.
>
>
>
> We will call out an Advocacy meeting in a couple of weeks to go over plans 
> and vote on the ideas for the second day of the summit.
>
>
>
> Thanks!
>
> Andreea
>
> Yocto Project Advocacy Lead
>
> --
>
> Joshua Watt 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debugging dev-deps

[Khem Raj]

also read through
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries

This might be helpful especially  section under Non-versioned Libraries

On Mon, May 13, 2019 at 10:56 AM Burton, Ross  wrote:
>
> On Mon, 13 May 2019 at 09:54, Matthias Schoepfer
>  wrote:
> > I am trying to write a recipe for a rather tricky component (that has
> > plugins and stuff). Anyhow, I cannot get bitbake not to complain that
> >  rdepends on -dev. And if I INSANE_SKIP it,
> > the -dev package will get installed. But I cannot figure out which file
> > is responsible. I tried to ldd all installed files in , but
> > could not get any results. Any hints on how to debug this further?!
>
> The problem is probably that the plugins are being shipped as
> /usr/lib/libpluginfoo.so, and so have the same names as development
> library symlinks which get packaged into PN-dev automatically.
> Alternatively unversioned libraries will also have the same issue.
>
> Look at what files go into what package (using oe-pkgdata-util), and
> ensure that PN-dev only contains headers and the link-time symlinks.
> For example libfoo.so -> libfoo.so.1, libfoo.so should be in PN-dev
> and libfoo.so.1 should be in PN.
>
> 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

Re: [yocto] Debugging dev-deps

[Burton, Ross]

On Mon, 13 May 2019 at 09:54, Matthias Schoepfer
 wrote:
> I am trying to write a recipe for a rather tricky component (that has
> plugins and stuff). Anyhow, I cannot get bitbake not to complain that
>  rdepends on -dev. And if I INSANE_SKIP it,
> the -dev package will get installed. But I cannot figure out which file
> is responsible. I tried to ldd all installed files in , but
> could not get any results. Any hints on how to debug this further?!

The problem is probably that the plugins are being shipped as
/usr/lib/libpluginfoo.so, and so have the same names as development
library symlinks which get packaged into PN-dev automatically.
Alternatively unversioned libraries will also have the same issue.

Look at what files go into what package (using oe-pkgdata-util), and
ensure that PN-dev only contains headers and the link-time symlinks.
For example libfoo.so -> libfoo.so.1, libfoo.so should be in PN-dev
and libfoo.so.1 should be in PN.

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

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

Hello Bruce, Chris,

Thank you both for the replies.

Usually, the kernel header files/kernel source code for the used
kernels are put under: /usr/src/kernels/`uname -r`/

But this, my best guess, is an implementation detail (probably each
distro has its own rule/merit).

Since YOCTO is just one of many areas I work on... I expected the
routine. But, hey... ;-)
___

In my opinion it would be nice to have this all by default implemented
outside of SDK. Included by default in rootfs. But this is only my
desperate wish (I am, after all, old, very lazy person)!

I figured it out in BBB related Embedded Debian (there are few tricks
to be done) today (aside that my HOST EFI grub2 failed very badly
(some bad sectors on my SSD), so I had some emergency to figure out
how to recover it - all done).

So, in embedded Debian I am able to build it on BBB target out of the
tree (few steps must be done to accomplish that).

I'll try what you both suggested to me for YOCTO (I still need some time):

> 1. Build using a bb recipe.
> Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
> You just need to add meta-skeleton to your bblaysers.conf and then
>  bitbake hello-mod

Please, stay tuned!

Thank you once again,
Zoran
___

On Sun, May 12, 2019 at 3:15 PM Chris Simmonds  wrote:
>
> Hi Zoran,
>
> There are two ways to do this
>
> 1. Build using a bb recipe.
> Take a look at meta-skeleton/recipes-kernel/hello-mod for an example.
> You just need to add meta-skeleton to your bblaysers.conf and then
>   bitbake hello-mod
>
>
> 2. Build from the SDK:
> First, add the kernel source to the SDK by adding this to conf/local/conf
>   TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
>
> Then build the SDK
>   bitbake -c populate_sdk [your image recipe]
>
> Once the SDK is installed, generate the kernel headers:
>   sudo -i
>   . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
>   cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi
>   cd /usr/src/kernel
>   make oldconfig scripts
>   exit
>
> Finally, build your module using a Makefile like this
>
>   obj-m := hello-mod.o
>   all:
> make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd)
>
>
> HTH,
> Chris
>
> On 12/05/2019 11:53, Zoran Stojsavljevic wrote:
> > Hello to the YOCTO community,
> >
> > I am using (to build the target for Beagle Bone Black) the following script:
> > https://github.com/ZoranStojsavljevic/bbb-yocto
> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh
> >
> > The latest kernel I am using from the following repo:
> > https://github.com/jumpnow/meta-bbb
> >
> > Is kernel 5.0.14 .
> >
> > Here is the snippet of the boot traces:
> > Starting kernel ...
> >
> > [0.00] Booting Linux on physical CPU 0x0
> > [0.00] Linux version 5.0.14-jumpnow (oe-user@oe-host) (gcc
> > version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019
> > [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> > cr=10c5387d
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> > instruction cache
> > [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> > [0.00] Memory policy: Data cache writeback
> > [0.00] cma: Reserved 16 MiB at 0x9f00
> > [0.00] CPU: All CPU(s) started in SVC mode.
> > [0.00] AM335X ES2.1 (sgx neon)
> > [0.00] random: get_random_bytes called from
> > start_kernel+0xa4/0x460 with crng_init=0
> > [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 130048
> > [0.00] Kernel command line: console=ttyO0,115200n8
> > root=/dev/ram0 ip=dhcp
> >
> > According to the documentation, the following:
> > 2.10.1. Building Out-of-Tree Modules on the Target
> > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html
> >
> > I tried to find /usr/src/kernels/5.0.14... Directory, since I see
> > from the build that kernel-dev and kernel-devsrc are included:
> > [user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel
> > core-image-kernel-dev :1.0-r0
> > kernel-devsrc :1.0-r0
> > kernel-selftest   :1.0-r0
> >
> > THE PROBLEM: But I could not find ob BBB target /usr/src/kernels
> > directory at all!?
> >
> > Two questions here?
> > [1] Do you have any advice on this problem (what I am missing here)?
> > [2] Alternative to [1]: how I can use cross compiler from
> > .../build/tmp to build Out-of-Tree Module for the BBB target on the
> > host?
> >
> > Thank you,
> > Zoran
> > ___
> >
>
>
> --
> Chris Simmonds, trainer and consultant at 2net
> http://www.2net.co.uk
> Author of "Mastering Embedded Linux Programming"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Debugging dev-deps

[Matthias Schoepfer]

Hi!

I am trying to write a recipe for a rather tricky component (that has 
plugins and stuff). Anyhow, I cannot get bitbake not to complain that 
 rdepends on -dev. And if I INSANE_SKIP it, 
the -dev package will get installed. But I cannot figure out which file 
is responsible. I tried to ldd all installed files in , but 
could not get any results. Any hints on how to debug this further?!


Thanks and regards,

  Matthias

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

[yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alexander Kanavin]

When build directory is deeply nested, the shebang limit of 127
characters is hit, which leads to doltlibtool failing to execute.

Signed-off-by: Alexander Kanavin 
---
 recipes-mono/mono/mono-5.xx.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
index c36374c..dec2475 100644
--- a/recipes-mono/mono/mono-5.xx.inc
+++ b/recipes-mono/mono/mono-5.xx.inc
@@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
 
 # Workaround for observed race in `make install`
 PARALLEL_MAKEINST=""
+
+# Otherwise the full path to bash is written to the first line of doltlibtool 
script
+# which causes build failures with deeply nested build directories
+CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
-- 
2.17.1

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

Re: [yocto] Using a native tool from another recipe

[Khem Raj]

You need to either build bpkg as a native recipe or install and make it
available as a hosttool from build machine distribution itself

On Mon, May 13, 2019 at 6:07 AM Gabriele Zampieri 
wrote:

> Hi all,
>
> I need to add a couple of tools to my build system (build2 and odb). The
> second one depends on the first. Following a snippet of the build2 recipe:
>
> 
> DEPENDS = "openssl-native"
> SRC_URI = "https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz
> "
> SRC_URI[sha256sum] =
> "42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
>
> S = "${WORKDIR}/build2-toolchain-${PV}"
>
> # build.sh located inside the tarball cannot be used to configure, compile
> and
> # install in different steps. This task is misleading, but I didn't find
> any
> # other way to make it works
> do_compile_prepend() {
> ./build.sh --timeout 600 --sudo false \
> --make ${MAKE} ${PARALLEL_MAKE} \
> --trust yes \
> --install-dir ${prefix} g++
> }
>
> FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
> FILES_${PN} = "${D}${prefix}/*"
>
> BBCLASSEXTEND = "native nativesdk"
>
> 
>
> Then the odb-compiler recipe
>
>
> 
> SECTION = "devtools"
> DEPENDS = "build2-native"
> CONFIG_NAME = "odb-gcc-X"
> do_configure() {
> cd ${B}
> bpkg create -d ${CONFIG_NAME} cc\
> config.cxx=g++  \
> config.cc.coptions=-O3  \
> config.bin.rpath=/usr/lib   \
> config.install.root=/usr\
> config.install.sudo=false
>
> }
> BBCLASSEXTEND = "native nativesdk"
>
> 
>
> When I try to build odb-compiler, bitbake complete the build2-native
> recipe, but fails on do_configure due to 'bpkg command not found'.
>
> Are my recipes correct?
>
> Thanks,
> Gabriele
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build error on dockerode using YP-Core warrior 2.7

[Khem Raj]

On Mon, May 13, 2019 at 7:19 AM Edson Seabra 
wrote:

> Hi,
>
>
> Thanks Khem Raj.
>
>
> As this package name is generate internally by poky/yocto I did this patch
> to make it build:
>
>
> *edson@ubuntu-16*:*oe*$ git diff package.py
>
> *diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py*
>
> *index 6e83f01f14..3503313621 100644*
>
> *--- a/meta/lib/oe/package.py*
>
> *+++ b/meta/lib/oe/package.py*
>
> @@ -298,7 +298,7 @@ def npm_split_package_dirs(pkgdir):
>
>  for pathitem in relpth.split('/'):
>
>  if pathitem == 'node_modules':
>
>  continue
>
> -pkgitems.append(pathitem)
>
> +pkgitems.append(pathitem.lower())
>
>  pkgname = '-'.join(pkgitems).replace('_', '-')
>
>  pkgname = pkgname.replace('@', '')
>
>  pkgfile = os.path.join(root, dn, 'package.json')
>
>
> I do not feel confident to submit it. I would suggest a poky/yocto
> maintainer to step in.
>

Just change the concerned recipe name this patch is a bit too much

>
> Regards,
> Edson.
>
> --
> *From:* Khem Raj 
> *Sent:* Sunday, May 12, 2019 4:50 AM
> *To:* Edson Seabra
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Build error on dockerode using YP-Core warrior 2.7
>
> Use all lowercase in recipe name you seem to have mixed it with uppercase
>
> On Sat, May 11, 2019 at 5:58 PM Edson Seabra 
> wrote:
>
> Hi,
>
>
> I created the recipe for dockerode 2.5.8 using the command recipetool:
>
>
> recipetool create "npm://registry.npmjs.org;name=dockerode;version=2.5.8"
>
>
> The recipe creates a lot of ipk's package and fails on dockerode-JSONStream
> ipk.
>
>
> I can build dokerode with YP-Coce morty, almost sure I did with YP-Core
> thud.
>
>
> Any hint about how to find what  is this issue will be appreciated.
>
>
> NOTE. Other recipes, using npm.bbclass, build normally.
>
>
> If any additional information is needed just let me know...
>
>
>  here is the output of bitbake dockerode ==
>
> Build Configuration:
>
> BB_VERSION   = "1.42.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "universal"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> MACHINE  = "genericx86-64"
>
> DISTRO   = "node-poky"
>
> DISTRO_VERSION   = "2.7"
>
> TUNE_FEATURES= "m64 core2"
>
> TARGET_FPU   = ""
>
> IMAGE_LINGUAS= "en-us en-gb"
>
> MACHINE_FEATURES = "screen keyboard pci usbhost ext4 x86 acpi pcbios
> rtc"
>
> IMAGE_FSTYPES= "hddimg"
>
> DISTRO_FEATURES  = "argp pam largefile xattr nfs pci x11 ipv4 ipv6
> libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets
> libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt
> libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl
> libc-libm libc-locales libc-locale-code libc-memusage libc-nis
> libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
> libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
> libc-posix-regexp-glibc libc-posix-wchar-io multiarch sysvinit opengl
> pulseaudio wifi virtualization"
>
> IMAGE_FEATURES   = "package-management read-only-rootfs tools-debug"
>
> meta-nodegrid
>
> meta-kernel  = "trunk:11630-11620"
>
> meta-zpe = "trunk:11630-11629"
>
> meta-oe  = "trunk:11630-11620"
>
> meta-graphics= "trunk:11630-11172"
>
> meta-networking  = "trunk:11630-11560"
>
> meta-python  = "trunk:11630-11620"
>
> meta-selinux = "master:b1dac7e2b26f869c991c6492aa7fa18eaa4b47f6"
>
> meta-virtualization  = "trunk:11630-11620"
>
> meta-tpm2= "trunk:11630-11090"
>
> meta-java= "master:2fc78571483465ca2fc69d6bd77632acd35e0770"
>
> meta
>
> meta-poky
>
> meta-yocto-bsp   = "warrior:1b425a8450872f915c30bd0a35b0b0df92172b70"
>
>
> Initialising tasks: 100%
> || Time: 0:00:02
>
> Sstate summary: Wanted 33 Found 27 Missed 6 Current 365 (81% match, 98%
> complete)
>
> *NOTE*: Executing SetScene Tasks
>
> *NOTE*: Executing RunQueue Tasks
>
> *WARNING*: dockerode-2.5.8-r0 do_populate_lic: dockerode: No generic
> license file exists for: Unknown in any provider
>
> *ERROR*: dockerode-2.5.8-r0 do_package_write_ipk: Fatal errors occurred
> in subprocesses:
>
> Command
> 

Re: [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[AshishKumar Mishra]

Thanks Ralph for informative reply .
Will check once again after deleting the file you suggested .

Ashish


On Mon, May 13, 2019, 7:05 PM Ralph Siemsen 
wrote:

> Hi Ashish,
>
> On Mon, May 13, 2019 at 5:57 AM AshishKumar Mishra <
> ashish.emailaddr...@gmail.com> wrote:
>
>> So , time shown by "uname -a" is retains older value even though
>> i had compiled the linux multiple times .
>>
>
> This is normal behaviour, even when building the kernel directly (eg. not
> using Yocto). It is a bit surprising at first, but it all comes down to
> dependencies in the Makefile for the kernel.
>
> The version string displayed by "uname -a" comes from init/version.c in
> the kernel source tree. Specifically the symbol UTS_VERSION, which is
> defined in include/generated/compile.h. This file is produced when you
> first build, and remains thereafter, unless you do "make clean" or
> equivalent.
>
> Currently , only way i am able to bypass this behavior is to do bitbake -c
>> cleanall linux-yocto
>> before every compilation.
>>
>
> You can delete the include/generated/compile.h file in your kernel build
> directory. Upon rebuild of kernel, the file will be re-created with the
> current date/time.
>
> Regards
> Ralph
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [Yocto-bsp] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[AshishKumar Mishra]

Thanks Ralph for informative reply .
Will check once again after deleting the file you suggested .

Ashish


On Mon, May 13, 2019, 7:05 PM Ralph Siemsen 
wrote:

> Hi Ashish,
>
> On Mon, May 13, 2019 at 5:57 AM AshishKumar Mishra <
> ashish.emailaddr...@gmail.com> wrote:
>
>> So , time shown by "uname -a" is retains older value even though
>> i had compiled the linux multiple times .
>>
>
> This is normal behaviour, even when building the kernel directly (eg. not
> using Yocto). It is a bit surprising at first, but it all comes down to
> dependencies in the Makefile for the kernel.
>
> The version string displayed by "uname -a" comes from init/version.c in
> the kernel source tree. Specifically the symbol UTS_VERSION, which is
> defined in include/generated/compile.h. This file is produced when you
> first build, and remains thereafter, unless you do "make clean" or
> equivalent.
>
> Currently , only way i am able to bypass this behavior is to do bitbake -c
>> cleanall linux-yocto
>> before every compilation.
>>
>
> You can delete the include/generated/compile.h file in your kernel build
> directory. Upon rebuild of kernel, the file will be re-created with the
> current date/time.
>
> Regards
> Ralph
>
-- 
___
yocto-bsp mailing list
yocto-bsp@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto-bsp

Re: [linux-yocto] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[AshishKumar Mishra]

Thanks Ralph for informative reply .
Will check once again after deleting the file you suggested .

Ashish


On Mon, May 13, 2019, 7:05 PM Ralph Siemsen 
wrote:

> Hi Ashish,
>
> On Mon, May 13, 2019 at 5:57 AM AshishKumar Mishra <
> ashish.emailaddr...@gmail.com> wrote:
>
>> So , time shown by "uname -a" is retains older value even though
>> i had compiled the linux multiple times .
>>
>
> This is normal behaviour, even when building the kernel directly (eg. not
> using Yocto). It is a bit surprising at first, but it all comes down to
> dependencies in the Makefile for the kernel.
>
> The version string displayed by "uname -a" comes from init/version.c in
> the kernel source tree. Specifically the symbol UTS_VERSION, which is
> defined in include/generated/compile.h. This file is produced when you
> first build, and remains thereafter, unless you do "make clean" or
> equivalent.
>
> Currently , only way i am able to bypass this behavior is to do bitbake -c
>> cleanall linux-yocto
>> before every compilation.
>>
>
> You can delete the include/generated/compile.h file in your kernel build
> directory. Upon rebuild of kernel, the file will be re-created with the
> current date/time.
>
> Regards
> Ralph
>
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Join Us – May 13th, 2019 – Live Coding with Yocto Project

[Nicolas Dechesne]

Dear all,

CORRECTION: the next Twitch session will take place *tomorrow* on May
14th, not May 13th. We are sorry about the inconvenience , we had a
glitch in the date! The time and content of the session remain
unchanged.

cheers
nico

On Fri, May 10, 2019 at 6:59 AM Volosincu, Andreea S
 wrote:
>
> Hello Everybody,
>
>
>
> The next live coding session is approaching quickly.
>
>
>
> When: May 13th, 2019, 5:00 PM CET
>
> Where: Yocto Project Twitch channel - https://www.twitch.tv/yocto_project
>
> What: Yocto Project developer, Josef Holzmayr, will show you how to create a 
> simple layer, derive a customized image and go through a devtool example
>
>
>
> Live Coding with Yocto Project is a live streaming series for Linux 
> developers who want to learn how to build Linux distros quickly and easily 
> using the Yocto Project tools. The show is hosted by Yocto Project 
> developers. We talk, explore devtools and write code along the way.
>
>
>
> Add it to your calendar – 
> https://calendar.google.com/calendar/ical/d7umm3pdhorsnnjbe1cvbgfhlk%40group.calendar.google.com/public/basic.ics
>
>
>
> See you soon!
>
> Yocto Project Advocacy Team
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[Ralph Siemsen]

Hi Ashish,

On Mon, May 13, 2019 at 5:57 AM AshishKumar Mishra <
ashish.emailaddr...@gmail.com> wrote:

> So , time shown by "uname -a" is retains older value even though
> i had compiled the linux multiple times .
>

This is normal behaviour, even when building the kernel directly (eg. not
using Yocto). It is a bit surprising at first, but it all comes down to
dependencies in the Makefile for the kernel.

The version string displayed by "uname -a" comes from init/version.c in the
kernel source tree. Specifically the symbol UTS_VERSION, which is defined
in include/generated/compile.h. This file is produced when you first build,
and remains thereafter, unless you do "make clean" or equivalent.

Currently , only way i am able to bypass this behavior is to do bitbake -c
> cleanall linux-yocto
> before every compilation.
>

You can delete the include/generated/compile.h file in your kernel build
directory. Upon rebuild of kernel, the file will be re-created with the
current date/time.

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

Re: [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[Ralph Siemsen]

Hi Ashish,

On Mon, May 13, 2019 at 5:57 AM AshishKumar Mishra <
ashish.emailaddr...@gmail.com> wrote:

> So , time shown by "uname -a" is retains older value even though
> i had compiled the linux multiple times .
>

This is normal behaviour, even when building the kernel directly (eg. not
using Yocto). It is a bit surprising at first, but it all comes down to
dependencies in the Makefile for the kernel.

The version string displayed by "uname -a" comes from init/version.c in the
kernel source tree. Specifically the symbol UTS_VERSION, which is defined
in include/generated/compile.h. This file is produced when you first build,
and remains thereafter, unless you do "make clean" or equivalent.

Currently , only way i am able to bypass this behavior is to do bitbake -c
> cleanall linux-yocto
> before every compilation.
>

You can delete the include/generated/compile.h file in your kernel build
directory. Upon rebuild of kernel, the file will be re-created with the
current date/time.

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

Re: [yocto] [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[Renato Caldas]

On 13/05/19 11:41, AshishKumar Mishra wrote:
Yes , i checked the value & increased it 64K ( got pointer from 
https://hub.docker.com/r/wolverine2k/yocto-build-env/)


It got the same error again today .
Currently i have increased the value from 64K to 512K.
But raised the query to check if i am doing any thing wrong here or 
missing any caution.


Like if at 512K if we get the error again , not sure if increasing the 
value is the only value.


Thanks
Ashish


Please don't top post (see mailing list guidelines).




On Mon, May 13, 2019 at 3:47 PM Richard Purdie 
> wrote:


On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
 > Can team members please let me know the solution & what is causing
 > the below mentioned error ?
 > ( I am having around 128GB of disk space still left , hence don't
 > think that space is the issue here )
 >
 > ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp)
: bitbake -vn virtual/kernel
 > ERROR: No space left on device or exceeds
fs.inotify.max_user_watches?
 > ERROR: To check max_user_watches: sysctl -n
fs.inotify.max_user_watches.
 > ERROR: To modify max_user_watches: sysctl -n -w
fs.inotify.max_user_watches=.
 > ERROR: Root privilege is required to modify max_user_watches.
 > ERROR: Command execution failed: Traceback (most recent call last):

Did you try what it says above and check the max_user_watches value?

Also, did you check you had enough free inodes on the filesystem?


Richard gave you the answer, you're probably running out of inodes. See 
it for yourself:


$ df --inodes

How to fix it depends on your filesystem (google is your friend), but 
the cause is usually a lot of small files. Happens to me a lot.


Cheers,
  Renato



Cheers,

Richard




--
Renato Caldas
Calgera, Unipessoal Lda.
Email: ren...@calgera.com
Tel: +351 967 709 735
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] File synchronization on ubifs/xfs

[Sebastian Brand]

> An application like "sed" does a rename after write, but that's totally
> unrelated to your issue. Sed does that because it cannot write to the file
> it's also reading from.

It might be the reason behind the rename, but you can also argue that
it is expected that a program that edits a file either leaves it as it was
or changed, but not empty, if the system crashes. (But you can also argue that
a power fail is undefined behavior.)

> If someone were to patch sed to insert an "fsync"
> before the rename, people would get very very angry at that person for making
> their build servers horrendously slow and draining their laptop batteries or
> something to that effect.

On ext3 (with mode data=ordered) it would indeed make the systems horrendously
slow. But on other file systems the impact should be much more reasonable.

> In the sed case, the proper thing to do is to direct sed's output to another
> file and then take care of syncing and renaming yourself.

That would be the preferable solution. If sed was not already heavily used to
update configuration files, and if many developers didn't "know" that sed -i
can be used for power-fail safe file updates.


The reason why I though that it might be interesting for other people using
Yocto is that this is a problem for many file systems that are used in
embedded systems. And it becomes a problem as soon as there is someone
that thinks that "sed -i" is safe on their system, since it is safe on ext4.
And for me it was more reasonable to implement a busybox feature than the
alternative solutions.


Cheers,
Sebastian

From: Mike Looijmans 
Sent: Monday, May 13, 2019 1:39 PM
To: Sebastian Brand; yocto@yoctoproject.org
Subject: Re: [yocto] File synchronization on ubifs/xfs

An application like "sed" does a rename after write, but that's totally
unrelated to your issue. Sed does that because it cannot write to the file
it's also reading from. If someone were to patch sed to insert an "fsync"
before the rename, people would get very very angry at that person for making
their build servers horrendously slow and draining their laptop batteries or
something to that effect.

When they tell you to fix "the application", they mean YOUR application, not
all the programs in the world that happen to call rename.

In the sed case, the proper thing to do is to direct sed's output to another
file and then take care of syncing and renaming yourself.



On 15-04-19 14:31, Sebastian Brand wrote:
> Hi all,
>
> I stumbled into an file synchronization problem, and I am curious if there 
> are more people using  Yocto and ubifs/xfs/similar that have an interest of 
> "fsync before rename"?
>
> When trying to atomically update a file a common flow is "create copy, edit 
> copy, rename copy->original", but this does for some file systems not 
> guarantee that the file is not empty after a power fail. A more correct flow 
> is "create copy, edit copy, fsync copy, rename copy->original", at least 
> according to file system developers. This has been discussed a lot and the 
> general status seems to be that many file system developers think that 
> applications that does not fsync before rename are broken, and many 
> application developers think that fsync is implied at rename and this needs 
> to be fixed in the file systems. (I am (trying to) not picking a side, and 
> just trying to solve my problems :) )
>
> Since some file systems common in embedded systems (UBIFS, XFS) does not 
> implement automatic fsync before rename, this becomes a bit of a problem if 
> applications in Yocto does not sync "correctly". One of these applications is 
> sed (in-place edit), and I am currently working on a patch to add fsync 
> before rename (as a feature). Busybox are not interested in the feature (as 
> they are of the opinion that this should be solved in the file system), but I 
> am curious if there is any interest in these kind of features in Yocto?
>
> Regards,
> Sebastian
>

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

[yocto] Using a native tool from another recipe

[Gabriele Zampieri]

Hi all,

I need to add a couple of tools to my build system (build2 and odb). The
second one depends on the first. Following a snippet of the build2 recipe:

DEPENDS = "openssl-native"
SRC_URI = "https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz;
SRC_URI[sha256sum] =
"42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"

S = "${WORKDIR}/build2-toolchain-${PV}"

# build.sh located inside the tarball cannot be used to configure, compile
and
# install in different steps. This task is misleading, but I didn't find any
# other way to make it works
do_compile_prepend() {
./build.sh --timeout 600 --sudo false \
--make ${MAKE} ${PARALLEL_MAKE} \
--trust yes \
--install-dir ${prefix} g++
}

FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
FILES_${PN} = "${D}${prefix}/*"

BBCLASSEXTEND = "native nativesdk"


Then the odb-compiler recipe


SECTION = "devtools"
DEPENDS = "build2-native"
CONFIG_NAME = "odb-gcc-X"
do_configure() {
cd ${B}
bpkg create -d ${CONFIG_NAME} cc\
config.cxx=g++  \
config.cc.coptions=-O3  \
config.bin.rpath=/usr/lib   \
config.install.root=/usr\
config.install.sudo=false

}
BBCLASSEXTEND = "native nativesdk"


When I try to build odb-compiler, bitbake complete the build2-native
recipe, but fails on do_configure due to 'bpkg command not found'.

Are my recipes correct?

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

Re: [yocto] long time for starting sshd (wait for crng init done ?)

[star]

> Gesendet: Montag, 13. Mai 2019 um 13:45 Uhr
> Von: mikko.rap...@bmw.de
> An: s...@gmx.li
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] long time for starting sshd (wait for crng init done ?)
>
> Hi,
>
> On Mon, May 13, 2019 at 01:07:45PM +0200, s...@gmx.li wrote:
> > >From yocto 2.5 to 2.7 I noticed a change in booting. The kernel stops for 
> > >around 85 seconds.
> > It seems to me that starting sshd takes time until crng init is done.
> > In 2.5 it doesn't wait for that. How can I avoid that?
> > Maybe I have to add that I use a recipe that adds keys as rootfs is usually 
> > r/o.
>
> Depends on your HW platform, kernel version etc, but one possible solution
> is installing rng-tools binary package which starts rngd at boot.
>
> See 
> http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282021.html
>
> -Mikko

With that in fact to boot time decreases. It stop for a 10..20s after "failed 
to init entropy", but this is far less than w/o it.
Nevertheless, I didn't have stops at all in 2.5, as cnrg init finished only 
after booting (login message) and boot time is important.

run-parts: /etc/network/if-pre-up.d/nfsroot: exit status 1
Starting random number generator daemon
Initalizing available sources

Failed to init entropy source hwrng

Enabling JITTER rng support

Initalizing entropy source jitter

.
random: crng init done
Starting OpenBSD Secure Shell server: sshd


>
> > Another think I have observed (which is not clear to me): I don't get a 
> > message from system message bus anymore. ???
> >
> > Instead of it udevd complains about "specific group 'kvm' unknown. Looking 
> > into source there are  mentioned:
> > # The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
> > So, can I safely ignore that (use ARM).
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] long time for starting sshd (wait for crng init done ?)

[Mark Hatle]

On 5/13/19 2:07 PM, s...@gmx.li wrote:
> From yocto 2.5 to 2.7 I noticed a change in booting. The kernel stops for 
> around 85 seconds.
> It seems to me that starting sshd takes time until crng init is done.
> In 2.5 it doesn't wait for that. How can I avoid that?
> Maybe I have to add that I use a recipe that adds keys as rootfs is usually 
> r/o.
> 
> Another think I have observed (which is not clear to me): I don't get a 
> message from system message bus anymore. ???
> 
> Instead of it udevd complains about "specific group 'kvm' unknown. Looking 
> into source there are  mentioned:
> # The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
> So, can I safely ignore that (use ARM).
> 
> 

There was recently a discussion on this in the oe-core mailing list (Search for
"[OE-core] [PATCH 2/2] openssh: usable sshd depends on rngd from rng-tools", be
sure to read the whole thread.)  Assuming you are using certain cryptography
resources, the system is waiting for enough entropy for a good random number 
set.

Often you may need to enable rngd, or up the quality of the kernel hardware
random number generators, as many are set very low.  (Often the hardware random
number generator you have is of sufficient quality that the quality level can be
increased to generate random numbers more quickly.)

Be aware of the ramifications if you make these changes to your system -- as
faster entropy generation does not necessarily equal quality.  There are
numerous incorrect assumptions about entropy and the kernel for these.  Above
all else, do not use /dev/urandom as an entropy source for /dev/random.  That is
simply not safe to do.

What you do NOT want to do is figure out that you are booting 10k boards in a
factory and they all end up getting exactly the same random numbers and thus
identical keys.  (Yes this has happened in the past!)

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

Re: [yocto] long time for starting sshd (wait for crng init done ?)

[Mikko.Rapeli]

Hi,

On Mon, May 13, 2019 at 01:07:45PM +0200, s...@gmx.li wrote:
> >From yocto 2.5 to 2.7 I noticed a change in booting. The kernel stops for 
> >around 85 seconds.
> It seems to me that starting sshd takes time until crng init is done.
> In 2.5 it doesn't wait for that. How can I avoid that?
> Maybe I have to add that I use a recipe that adds keys as rootfs is usually 
> r/o.

Depends on your HW platform, kernel version etc, but one possible solution
is installing rng-tools binary package which starts rngd at boot.

See 
http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282021.html

-Mikko

> Another think I have observed (which is not clear to me): I don't get a 
> message from system message bus anymore. ???
> 
> Instead of it udevd complains about "specific group 'kvm' unknown. Looking 
> into source there are  mentioned:
> # The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
> So, can I safely ignore that (use ARM).
> 
> 
> -- 
> ___
> 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] long time for starting sshd (wait for crng init done ?)

[star]

>From yocto 2.5 to 2.7 I noticed a change in booting. The kernel stops for 
>around 85 seconds.
It seems to me that starting sshd takes time until crng init is done.
In 2.5 it doesn't wait for that. How can I avoid that?
Maybe I have to add that I use a recipe that adds keys as rootfs is usually r/o.

Another think I have observed (which is not clear to me): I don't get a message 
from system message bus anymore. ???

Instead of it udevd complains about "specific group 'kvm' unknown. Looking into 
source there are  mentioned:
# The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
So, can I safely ignore that (use ARM).


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

Re: [yocto] [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[AshishKumar Mishra]

Yes , i checked the value & increased it 64K ( got pointer from
https://hub.docker.com/r/wolverine2k/yocto-build-env/)

It got the same error again today .
Currently i have increased the value from 64K to 512K.
But raised the query to check if i am doing any thing wrong here or missing
any caution.

Like if at 512K if we get the error again , not sure if increasing the
value is the only value.

Thanks
Ashish


On Mon, May 13, 2019 at 3:47 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
> > Can team members please let me know the solution & what is causing
> > the below mentioned error ?
> > ( I am having around 128GB of disk space still left , hence don't
> > think that space is the issue here )
> >
> > ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) :
> bitbake -vn virtual/kernel
> > ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
> > ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
> > ERROR: To modify max_user_watches: sysctl -n -w
> fs.inotify.max_user_watches=.
> > ERROR: Root privilege is required to modify max_user_watches.
> > ERROR: Command execution failed: Traceback (most recent call last):
>
> Did you try what it says above and check the max_user_watches value?
>
> Also, did you check you had enough free inodes on the filesystem?
>
> Cheers,
>
> Richard
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[Richard Purdie]

On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
> Can team members please let me know the solution & what is causing
> the below mentioned error ?
> ( I am having around 128GB of disk space still left , hence don't
> think that space is the issue here )
> 
> ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake 
> -vn virtual/kernel
> ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
> ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
> ERROR: To modify max_user_watches: sysctl -n -w 
> fs.inotify.max_user_watches=.
> ERROR: Root privilege is required to modify max_user_watches.
> ERROR: Command execution failed: Traceback (most recent call last):

Did you try what it says above and check the max_user_watches value?

Also, did you check you had enough free inodes on the filesystem?

Cheers,

Richard

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

Re: [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[Richard Purdie]

On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
> Can team members please let me know the solution & what is causing
> the below mentioned error ?
> ( I am having around 128GB of disk space still left , hence don't
> think that space is the issue here )
> 
> ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake 
> -vn virtual/kernel
> ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
> ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
> ERROR: To modify max_user_watches: sysctl -n -w 
> fs.inotify.max_user_watches=.
> ERROR: Root privilege is required to modify max_user_watches.
> ERROR: Command execution failed: Traceback (most recent call last):

Did you try what it says above and check the max_user_watches value?

Also, did you check you had enough free inodes on the filesystem?

Cheers,

Richard

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

[Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[AshishKumar Mishra]

Hi Members ,

Can team members please let me know the solution & what is causing the
below mentioned error ?
( I am having around 128GB of disk space still left , hence don't think
that space is the issue here )

~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake
-vn virtual/kernel
ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
ERROR: To modify max_user_watches: sysctl -n -w
fs.inotify.max_user_watches=.
ERROR: Root privilege is required to modify max_user_watches.
ERROR: Command execution failed: Traceback (most recent call last):

  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/command.py",
line 113, in runAsyncCommand
self.cooker.updateCache()
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/cooker.py",
line 1541, in updateCache
self.add_filewatch([[dirent]], dirs=True)
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/cooker.py",
line 287, in add_filewatch
watcher.add_watch(f, self.watchmask, quiet=False)
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/pyinotify.py",
line 1924, in add_watch
raise WatchManagerError(err, ret_)
pyinotify.WatchManagerError: add_watch: cannot watch
/home/ashish/Documents/linux-foundation-projects/yocto/poky/meta/recipes-devtools/mtd
WD=-1, Errno=No space left on device (ENOSPC)


Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

~/Documents/linux-foundation-projects/yocto/poky/build (self-bsp) :
~/Documents/linux-foundation-projects/yocto/poky/build (self-bsp) : df -h
/home/ashish/
Filesystem  Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  433G  284G  127G  70% /


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

[yocto] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[AshishKumar Mishra]

Hi Members ,

Can team members please let me know the solution & what is causing the
below mentioned error ?
( I am having around 128GB of disk space still left , hence don't think
that space is the issue here )

~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake
-vn virtual/kernel
ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
ERROR: To modify max_user_watches: sysctl -n -w
fs.inotify.max_user_watches=.
ERROR: Root privilege is required to modify max_user_watches.
ERROR: Command execution failed: Traceback (most recent call last):

  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/command.py",
line 113, in runAsyncCommand
self.cooker.updateCache()
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/cooker.py",
line 1541, in updateCache
self.add_filewatch([[dirent]], dirs=True)
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/bb/cooker.py",
line 287, in add_filewatch
watcher.add_watch(f, self.watchmask, quiet=False)
  File
"/home/ashish/Documents/linux-foundation-projects/yocto/poky/bitbake/lib/pyinotify.py",
line 1924, in add_watch
raise WatchManagerError(err, ret_)
pyinotify.WatchManagerError: add_watch: cannot watch
/home/ashish/Documents/linux-foundation-projects/yocto/poky/meta/recipes-devtools/mtd
WD=-1, Errno=No space left on device (ENOSPC)


Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

~/Documents/linux-foundation-projects/yocto/poky/build (self-bsp) :
~/Documents/linux-foundation-projects/yocto/poky/build (self-bsp) : df -h
/home/ashish/
Filesystem  Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  433G  284G  127G  70% /


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

[yocto] openjdk-8-native fetch server error 500

[Renato Caldas]

Hi,

I've been having trouble building openjdk-8-native over the weekend. 
Fetching is failing with 500 Internal Server Error.


I assumed it was just a weekend fluke, but it's still failing today:

--2019-05-13 09:45:27-- 
http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/34ee52bc68a4.tar.bz2

Resolving hg.openjdk.java.net (hg.openjdk.java.net)... 137.254.56.63
Connecting to hg.openjdk.java.net 
(hg.openjdk.java.net)|137.254.56.63|:80... connected.

HTTP request sent, awaiting response... 500 Internal Server Error
2019-05-13 09:45:30 ERROR 500: Internal Server Error.

ERROR: openjdk-8-native-172b11-r0 do_fetch: Fetcher failure for URL: 
'http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/34ee52bc68a4.tar.bz2;downloadfilename=openjdk8-172b11-langtools-34ee52bc68a4.tar.bz2;name=langtools;unpack=false'. 
Unable to fetch URL from any source.


Any advice on how to proceed?

Thanks,
--
Renato Caldas
Calgera, Unipessoal Lda.
Tel: +351 967 709 735
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[AshishKumar Mishra]

Yes .
But this difference we expect in some minutes.


But what i am observing is ( attached snapshot ) :-
1) First Compilation around ( 4:10)
   bitbake cleanall + bitbake core-image-minimal
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 4:30


2) Second Compilation around ( 5:00)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 5:25


2) Second Compilation around ( 5:00)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 5:25

3) Third Compilation around ( 5:45)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 6:05



So , time shown by "uname -a" is retains older value even though
i had compiled the linux multiple times .

Currently , only way i am able to bypass this behavior is to do bitbake -c
cleanall linux-yocto
before every compilation.

Thanks
Ashish
















On Fri, May 10, 2019 at 10:23 PM Khem Raj  wrote:

>
>
> On 5/10/19 12:10 AM, AshishKumar Mishra wrote:
> > HI Anuj ,
> >
> > I was building minimal image using $ bitbake core-image-minimal haven't
> > tried full-cmdline.
> >
> > Not able to track why kernel "uname" has older  timestamp rather than
> > the one from build/deploy/image
> > as seen by "ls -al 
> >
> > Am i missing any command or sequence here
> >
> >
>
> uname will show the time when it was built, which might be different
> time then the one when it was copied over to deploy.
>
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[AshishKumar Mishra]

Yes .
But this difference we expect in some minutes.


But what i am observing is ( attached snapshot ) :-
1) First Compilation around ( 4:10)
   bitbake cleanall + bitbake core-image-minimal
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 4:30


2) Second Compilation around ( 5:00)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 5:25


2) Second Compilation around ( 5:00)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 5:25

3) Third Compilation around ( 5:45)
   bitbake -c menuconfig virtual/kernel + bitbake -C deploy linux-yocto
 uname-a: Time shown is
4:24
 timestamp of files in deploy/images/: Time shown is around 6:05



So , time shown by "uname -a" is retains older value even though
i had compiled the linux multiple times .

Currently , only way i am able to bypass this behavior is to do bitbake -c
cleanall linux-yocto
before every compilation.

Thanks
Ashish
















On Fri, May 10, 2019 at 10:23 PM Khem Raj  wrote:

>
>
> On 5/10/19 12:10 AM, AshishKumar Mishra wrote:
> > HI Anuj ,
> >
> > I was building minimal image using $ bitbake core-image-minimal haven't
> > tried full-cmdline.
> >
> > Not able to track why kernel "uname" has older  timestamp rather than
> > the one from build/deploy/image
> > as seen by "ls -al 
> >
> > Am i missing any command or sequence here
> >
> >
>
> uname will show the time when it was built, which might be different
> time then the one when it was copied over to deploy.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] patchwork

[Mark Hatle]

On 5/13/19 10:46 AM, Adrian Bunk wrote:
> On Mon, May 13, 2019 at 10:32:48AM +0300, Mark Hatle wrote:
>> On 5/12/19 9:04 PM, akuster808 wrote:
>>> ok, so no Admins. This is unexceptionable.
>>>
>>> OE TSC and Board, I believe its your time to get involved.
>>
>> I've not used patchwork before, do you know who originally configured it?  
>> Was
>> it Paul Eggleton, or Richard, or?  If I have an idea who was originally
>> responsible, I'm pretty sure we can figure out a handoff plan to someone 
>> else.
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/

No I mean who set it up for OE (or the YP) to use.  I don't even know at this
point whose infrastructure the component runs on.  If I had that I'd know to
start with either Tom or Michael.

--Mark

>> --Mark
> 
> cu
> Adrian
> 

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

Re: [yocto] [OE-core] patchwork

[Adrian Bunk]

On Mon, May 13, 2019 at 10:32:48AM +0300, Mark Hatle wrote:
> On 5/12/19 9:04 PM, akuster808 wrote:
> > ok, so no Admins. This is unexceptionable.
> > 
> > OE TSC and Board, I believe its your time to get involved.
> 
> I've not used patchwork before, do you know who originally configured it?  Was
> it Paul Eggleton, or Richard, or?  If I have an idea who was originally
> responsible, I'm pretty sure we can figure out a handoff plan to someone else.

http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/

> --Mark

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [yocto] patchwork

[Zoran Stojsavljevic]

Off Topic @: The same chaos as with German Govt. (KVR and Finanzamt).

Zoran
___

On Sun, May 12, 2019 at 8:05 PM akuster808  wrote:
>
> ok, so no Admins. This is unexceptionable.
>
> OE TSC and Board, I believe its your time to get involved.
>
> regards,
> Armin
>
> On 5/3/19 10:18 AM, akuster808 wrote:
> > Hello OE folk,
> >
> > My apologies for cross posting.
> >
> > Who is the Admin for Patchwork?
> >
> > I would like additional privileges to manage the "Yocto Project Layers"
> > queue.
> >
> > Also, I would like additional  privileges to add new branches for any
> > oe, meta-oe queues & yp layers.
> >
> > kind regards,
> > Armin
> >
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] patchwork

[Mark Hatle]

On 5/12/19 9:04 PM, akuster808 wrote:
> ok, so no Admins. This is unexceptionable.
> 
> OE TSC and Board, I believe its your time to get involved.

I've not used patchwork before, do you know who originally configured it?  Was
it Paul Eggleton, or Richard, or?  If I have an idea who was originally
responsible, I'm pretty sure we can figure out a handoff plan to someone else.

--Mark

> regards,
> Armin
> 
> On 5/3/19 10:18 AM, akuster808 wrote:
>> Hello OE folk,
>>
>> My apologies for cross posting.
>>
>> Who is the Admin for Patchwork?
>>
>> I would like additional privileges to manage the "Yocto Project Layers"
>> queue.
>>
>> Also, I would like additional  privileges to add new branches for any
>> oe, meta-oe queues & yp layers.
>>
>> kind regards,
>> Armin
>>
> 

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