Date   

deploy GPG keys into images

Damien LEFEVRE
 

Hi,

I've put GnuPG in my image, and I'd like to deploy a set to public and private keys into the system images.

How can I do that from recipes?

Thanks,
-Damien


Missing another DTB file in images directory

JH
 

Hi,

I have two device tree source files, imx6ulz.dts and imx6ulz-kobs.dts,
I defined machine configure file with KERNEL_DEVICETREE = "imx6ulz.dtb
imx6ulz-kobs.dtb", I can see both imx6ulz.dtb imx6ulz-kobs.dtb in
build directory, but there is only one imx6ulz.dtb in the images
directory, missed imx6ulz-kobs.dtb, how can I package imx6ulz-kobs.dtb
to the images directory?

Thank you.

Kind regards,

- jh


--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs


M+ & H bugs with Milestone Movements WW20

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW20 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6437

Document how to set up the Yocto Project for production work

randy.macleod@...

mark.morton@...

3.99

3.2 M2

 

11899

broken 'bitbake --status-only' and 'bitbake -m'

randy.macleod@...

unassigned@...

3.99

3.2 M1

 

12023

bitbake-layers show-layers doesn't show layer if it doesn't append itself to BBFILE_COLLECTIONS

randy.macleod@...

unassigned@...

3.99

3.2 M1

 

12290

cross recipe kernel module dependency generation stopped working

randy.macleod@...

unassigned@...

3.99

3.2 M1

 

13788

zeus-nut] selftest failure PackageTests.test_gdb_hardlink

randy.macleod@...

randy.macleod@...

3.0.3

3.0.4

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW18!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

chee.yang.lee@...

1

jean-marie.lemetayer@...

1

richard.purdie@...

1

JPEWhacker@...

1

Grand Total

4

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW20 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 115 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

30

david.reyna@...

19

bluelightning@...

16

akuster808@...

14

bruce.ashfield@...

11

kai.kang@...

9

Qi.Chen@...

9

ross@...

8

trevor.gamblin@...

8

mark.morton@...

8

randy.macleod@...

7

JPEWhacker@...

7

timothy.t.orling@...

6

changqing.li@...

6

michael@...

5

raj.khem@...

4

pbarker@...

4

mingli.yu@...

4

rpjday@...

4

alex.kanavin@...

4

yi.zhao@...

3

akuster@...

3

hongxu.jia@...

3

kexin.hao@...

3

jon.mason@...

3

alejandro@...

2

ycnakajsph@...

2

mark.hatle@...

2

jaewon@...

2

mostthingsweb@...

2

seebs@...

2

jpuhlman@...

2

chee.yang.lee@...

2

kergoth@...

2

amber.n.elliot@...

1

matthew.zeng@...

1

maxime.roussinbelanger@...

1

naveen.kumar.saini@...

1

dl9pf@...

1

yang.wang@...

1

mshah@...

1

sakib.sajal@...

1

limon.anibal@...

1

zhe.he@...

1

kai.ruhnau@...

1

bunk@...

1

Martin.Jansa@...

1

liu.ming50@...

1

jason.wessel@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

 

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

 

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

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 338 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) 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_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Extended SDK installation fails during git fetch of kernel source hosted on private repo

Andrea Galbusera
 

Hi!

I had a similar issue in my backlog for ages... Finally hit it again
while updating some SDKs and found this thread from more than two
years ago. In my case, fetching during the SDK install script run was
triggered by at least one recipe which was setting SRCREV with
AUTOREV. Although using AUTOREV in generating SDKs is probably
debatable, I found your comments here a good starting point for
further investigation. Looking at the git history since then, it
reveals a recent commit [1] which is reworking (possibly with
different motivations) the way SDK install script is "cleaning" some
env variables at invocation.

I tested backporting this commit to an old pyro based project where I
was seeing SDK install failures with AUTOREV recipes and it solved the
original error.

I could find no issue in Bugzilla for this specific face of the
problem, even though the above commit descries itself as a rework of
the fix for [1]. I'm reporting to the list for the records, in case
someone else would happen to hit issues with using the ssh agent while
installing their SDKs.

Regards,

[1] https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6d78b84029d0717354bf39e5c355fba1c14d8347
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8698

On Thu, Sep 6, 2018 at 12:18 PM Gabriele Favalessa
<gabriele@...> wrote:

An update (and a workaround.)

What's happening is that during the execution of the install script for the extended SDK, the env of the original shell is ignored. If your SDK refers to private git repos (on github for example) and you normally authenticate to github using ssh and ssh-agent, the SSH_AUTH_SOCK env variables needed won't be set by the time git is invoked. The workaround is configuring the authentication to github in .ssh/config and avoid the ssh-agent. (Yes, I checked and SSH_AUTH_SOCK is exported by the shell :)

But the underlying problem is that env of the shell is ignored during install, so potentially other useful variables could be ignored. Is that intentional? Is there a way to prevent it?

Gabriele

On Wed, Aug 29, 2018 at 3:55 PM Gabriele Favalessa <gabriele@...> wrote:

Hi,

I'm trying to install on ubuntu 17.04 an Extensible SDK that I have built, and it stops with an error:

-------------------------------------------------------
sdk@sdk:~$ ./acme-linux-glibc-x86_64-acme-image-datalogger-cortexa7hf-neon-toolchain-ext-2.5.1.sh -D

+ sh -c . buildtools/environment-setup* > /home/sdk/acme-linux_sdk/preparing_build_system.log && cd /home/sdk/acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && . /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env /home/sdk/acme-linux_sdk >> /home/sdk/acme-linux_sdk/preparing_build_system.log && python /home/sdk/acme-linux_sdk/ext-sdk-prepare.py /home/sdk/acme-linux_sdk/preparing_build_system.log 'acme-image-datalogger meta-extsdk-toolchain:do_populate_sysroot'
WARNING: /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb: Exception during build_dependencies for AUTOREV
WARNING: /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb: Error during finalise of /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb
ERROR: ExpansionError during parsing /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export GIT_SSL_CAINFO="/home/sdk/acme-linux_sdk/buildtools/sysroots/x86_64-acmesdk-linux/etc/ssl/certs/ca-certificates.crt"; export PATH="/home/sdk/acme-linux_sdk/layers/poky/scripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin/arm-acme-linux-gnueabi:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot/usr/bin/crossscripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/bin:/home/sdk/acme-linux_sdk/layers/poky/bitbake/bin:/home/sdk/acme-linux_sdk/tmp/hosttools"; export HOME="/home/sdk"; git -c core.fsyncobjectfiles=0 ls-remote ssh://git@.../Acme/linux-imx.git failed with exit code 128, output:
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


ERROR: SDK preparation failed: error log written to /home/sdk/acme-linux_sdk/preparing_build_system.log
-------------------------------------------------------

I tested the failing git command `git -c ls-remote ssh://git@.../Acme/linux-imx.git` directly from the command line and it succeeds without errors. I do have the ssh key in ssh-agent, so that's not surprise.

It looks like during the SDK installation the ssh key is needed but for some reason the ssh-agent is not reachable (maybe the SSH_* env variables are not propagated by the script?)

Is it unavoidable for the SDK to fetch from git during the installation? If it is unavoidable, how can I make the script fetch from a private github repo, given that the ssh-agent seems to be ignored?

Just out of curiosity, I copy&pasted the failing command in the shell, and this time it ran without errors (again confirming that the ssh key is present.)

-------------------------------------------------------
sdk@sdk:~$ sh -c . buildtools/environment-setup* > /home/sdk/acme-linux_sdk/preparing_build_system.log && cd /home/sdk/
acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && . /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env
/home/sdk/acme-linux_sdk >> /home/sdk/acme-linux_sdk/preparing_build_system.log && python /home/sdk/acme-linux_sdk/ext-
sdk-prepare.py /home/sdk/acme-linux_sdk/preparing_build_system.log 'acme-image-datalogger meta-extsdk-toolchain:do_popu
late_sysroot'
Loading cache: 100% |###################################################################################| Time: 0:00:00
Parsing recipes: 100% |#################################################################################| Time: 0:01:32
Initialising tasks: 100% |##############################################################################| Time: 0:00:02
Checking sstate mirror object availability: 100% |######################################################| Time: 0:00:00
Loading cache: 100% |###################################################################################| Time: 0:00:00
Parsing recipes: 100% |#################################################################################| Time: 0:00:07
Initialising tasks: 100% |##############################################################################| Time: 0:00:00
-------------------------------------------------------

However the resulting SDK installation seems to be broken anyway (probably there are other steps after the one I re-run manually that where not executed because the toplevel script stopped with an error):

-------------------------------------------------------
sdk@sdk:~/acme-linux_sdk$ source environment-setup-cortexa7hf-neon-acme-linux-gnueabi
SDK environment now set up; additionally you may now run devtool to perform development tasks.
Run devtool --help for further details.
ERROR: this SDK was not fully installed and needs reinstalling
-------------------------------------------------------

Thanks

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


Re: [WIC] Grow last partition up to disk size

Mike Looijmans
 

On 30-04-2020 20:23, Khem Raj via lists.yoctoproject.org wrote:


On 4/30/20 11:16 AM, Marek Belisko wrote:
Hi Rudolf,

On Thu, Apr 30, 2020 at 7:39 PM Rudolf J Streif
<rudolf.streif@...> wrote:

I was looking for a way in a wks file to have wic grow the last
partition to fill up the remainder of the disk. Of course wic does not
know how large the disk is but that could be a parameter.

The alternative way is to use fixed-size and do the math manually but
that would not allow wic to grow a partition based on content.
You can use https://manpages.debian.org/testing/systemd/systemd-growfs.8.en.html
which grow partition to the end.
can it grow a mounted partition ? since that will be the case when growing rootfs partition.

Yes, a mounted ext4 partition can be resized. Some tools will try to keep you from doing that though, had to patch parted to stop whining about mounted partitions in "scripted" mode that to make it work though.

https://github.com/topic-embedded-products/topic-platform/tree/zeus/meta-topic-platform/recipes-extended/parted

Here's the recipe that re-partitions the SD or eMMC on first boot after programming a (small) wic image:

https://github.com/topic-embedded-products/topic-platform/tree/zeus/meta-topic-platform/recipes-topic/expand-wic-partition


Re: [PATCH yocto-autobuilder-helper] scripts: add a pair of scripts to set up and run Auto Upgrade Helper

Nicolas Dechesne
 



On Sun, May 17, 2020 at 5:21 PM Alexander Kanavin <alex.kanavin@...> wrote:
This allows automating its setup and execution on all autobuilder worker machines;
previously there was a static setup on a dedicated machine, which wasn't
great from maintenance perspective.

To use:

scripts/setup-auh target_dir
scripts/run-auh target_dir

(run-auh can be run several times in a directory that
was previously set up)

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
 scripts/auh-config/local.conf.append   |  3 +++
 scripts/auh-config/upgrade-helper.conf | 33 ++++++++++++++++++++++++++
 scripts/run-auh                        | 32 +++++++++++++++++++++++++
 scripts/setup-auh                      | 26 ++++++++++++++++++++
 4 files changed, 94 insertions(+)
 create mode 100644 scripts/auh-config/local.conf.append
 create mode 100644 scripts/auh-config/upgrade-helper.conf
 create mode 100755 scripts/run-auh
 create mode 100755 scripts/setup-auh

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
new file mode 100644
index 0000000..9628737
--- /dev/null
+++ b/scripts/auh-config/local.conf.append
@@ -0,0 +1,3 @@
+
+INHERIT += "buildhistory"
+LICENSE_FLAGS_WHITELIST = "commercial"
diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
new file mode 100644
index 0000000..fbf5d8a
--- /dev/null
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -0,0 +1,33 @@
+[maintainer_override]
+# mails for recipe upgrades will go to john.doe instead of jane.doe, etc
+#ross.burton@...=anibal.limon@...

unrelated.. but I just spotted this ^. I am cc'ing Anibal new email address. it's in a few other places.
 

+
+[settings]
+# recipes in blacklist will be skipped
+blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-image
+#blacklist=python python3 glibc gcc linux-libc-headers linux-yocto-rt linux-yocto linux-yocto-dev linux-yocto-tiny qt4-x11-free qt4-embedded qt4-x11-free qt4e-demo-image gnome-common gnome-desktop3 gnome-desktop-testing adt-installer build-appliance-image
+# only recipes belonging to maintainers in whitelist will be attempted
+#maintainers_whitelist=anibal.limon@...
+# SMTP server
+smtp=smtp1.yoctoproject.org:25
+# from whom should the mails arrive
+from=auh@...
+# who should get the status mail with statistics, at the end
+status_recipients=openembedded-core@...
+# clean sstate directory before upgrading
+#clean_sstate=yes
+# clean tmp directory before upgrading
+#clean_tmp=yes
+# machines to test build with
+#machines=qemux86 qemux86-64 qemuarm qemumips qemuppc
+#machines=qemux86
+
+buildhistory=yes
+#testimage=yes
+#testimage_name=core-image-minimal
+
+#workdir=/home/auh/work/
+#publish_work_url=https://logs.yoctoproject.org/auh/
+
+commit_revert_policy=all
+
diff --git a/scripts/run-auh b/scripts/run-auh
new file mode 100755
index 0000000..29a8044
--- /dev/null
+++ b/scripts/run-auh
@@ -0,0 +1,32 @@
+#!/bin/bash
+# Run Auto Upgrade Helper in a directory set up by setup_auh.
+#
+# Called with $1 - the directory where the setup was created
+
+if [ -z $1 ]; then
+  echo "Use: $0 auh_setup_dir"
+  exit 1
+fi
+
+full_dir=$(readlink -e $1)
+
+auh_dir=$full_dir/auto-upgrade-helper
+poky_dir=$full_dir/poky
+build_dir=$full_dir/build
+sstate_dir=$full_dir/build/sstate-cache
+
+pushd $poky_dir
+
+# Base the upgrades on poky master
+git fetch origin
+git checkout -B tmp-auh-upgrades origin/master
+
+source $poky_dir/oe-init-build-env $build_dir
+$auh_dir/upgradehelper.py -e all
+
+# clean up to avoid the disk filling up
+rm -rf $build_dir/tmp/
+rm -rf $build_dir/workspace/sources/*
+find $sstate_dir -atime +10 -delete
+
+popd
diff --git a/scripts/setup-auh b/scripts/setup-auh
new file mode 100755
index 0000000..23f3d44
--- /dev/null
+++ b/scripts/setup-auh
@@ -0,0 +1,26 @@
+#!/bin/bash
+# Initialize Auto Upgrade Helper in a directory.
+#
+# Called with $1 - the directory to place the setup
+CONFIG_DIR=`dirname $0`/auh-config
+
+if [ -z $1 ]; then
+  echo "Use: $0 target_dir"
+  exit 1
+fi
+
+mkdir -p $1
+pushd $1
+
+git clone git://git.yoctoproject.org/poky
+pushd poky
+git config user.email auh@...
+git config user.name "Auto Upgrade Helper"
+popd
+git clone git://git.yoctoproject.org/auto-upgrade-helper
+source poky/oe-init-build-env build
+mkdir -p upgrade-helper
+popd
+
+cp $CONFIG_DIR/upgrade-helper.conf $1/build/upgrade-helper
+cat $CONFIG_DIR/local.conf.append >> $1/build/conf/local.conf
--
2.26.2



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

Sangeeta Jain
 

Hello All,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.0.3.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, May 21.

Thanks,
Sangeeta

-----Original Message-----
From: Poky Build User <pokybuild@...>
Sent: Friday, 15 May, 2020 3:24 PM
To: yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>;
Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>;
richard.purdie@...; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: QA notification for completed autobuilder build (yocto-3.0.3.rc2)


A build flagged for QA (yocto-3.0.3.rc2) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.0.3.rc2


Build hash information:

bitbake: 6836184ef5220488a1127413c7d2e523fc37e2e9
meta-gplv2: 0f4eecc000f66d114ad258fa31aed66afa292166
meta-intel: 49a0bfe118bfba37e9c02ff6d2af039c4c20b2ff
meta-mingw: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
oecore: 9bab7c1a29a58ba7f97e253e4e0ac167b77d0e65
poky: eac84e73e8d94610173c3bb3b6c6d74b58e44f60



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



[PATCH yocto-autobuilder-helper] scripts: add a pair of scripts to set up and run Auto Upgrade Helper

Alexander Kanavin
 

This allows automating its setup and execution on all autobuilder worker machines;
previously there was a static setup on a dedicated machine, which wasn't
great from maintenance perspective.

To use:

scripts/setup-auh target_dir
scripts/run-auh target_dir

(run-auh can be run several times in a directory that
was previously set up)

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/auh-config/local.conf.append | 3 +++
scripts/auh-config/upgrade-helper.conf | 33 ++++++++++++++++++++++++++
scripts/run-auh | 32 +++++++++++++++++++++++++
scripts/setup-auh | 26 ++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 scripts/auh-config/local.conf.append
create mode 100644 scripts/auh-config/upgrade-helper.conf
create mode 100755 scripts/run-auh
create mode 100755 scripts/setup-auh

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
new file mode 100644
index 0000000..9628737
--- /dev/null
+++ b/scripts/auh-config/local.conf.append
@@ -0,0 +1,3 @@
+
+INHERIT += "buildhistory"
+LICENSE_FLAGS_WHITELIST = "commercial"
diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
new file mode 100644
index 0000000..fbf5d8a
--- /dev/null
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -0,0 +1,33 @@
+[maintainer_override]
+# mails for recipe upgrades will go to john.doe instead of jane.doe, etc
+#ross.burton@...=anibal.limon@...
+
+[settings]
+# recipes in blacklist will be skipped
+blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-image
+#blacklist=python python3 glibc gcc linux-libc-headers linux-yocto-rt linux-yocto linux-yocto-dev linux-yocto-tiny qt4-x11-free qt4-embedded qt4-x11-free qt4e-demo-image gnome-common gnome-desktop3 gnome-desktop-testing adt-installer build-appliance-image
+# only recipes belonging to maintainers in whitelist will be attempted
+#maintainers_whitelist=anibal.limon@...
+# SMTP server
+smtp=smtp1.yoctoproject.org:25
+# from whom should the mails arrive
+from=auh@...
+# who should get the status mail with statistics, at the end
+status_recipients=openembedded-core@...
+# clean sstate directory before upgrading
+#clean_sstate=yes
+# clean tmp directory before upgrading
+#clean_tmp=yes
+# machines to test build with
+#machines=qemux86 qemux86-64 qemuarm qemumips qemuppc
+#machines=qemux86
+
+buildhistory=yes
+#testimage=yes
+#testimage_name=core-image-minimal
+
+#workdir=/home/auh/work/
+#publish_work_url=https://logs.yoctoproject.org/auh/
+
+commit_revert_policy=all
+
diff --git a/scripts/run-auh b/scripts/run-auh
new file mode 100755
index 0000000..29a8044
--- /dev/null
+++ b/scripts/run-auh
@@ -0,0 +1,32 @@
+#!/bin/bash
+# Run Auto Upgrade Helper in a directory set up by setup_auh.
+#
+# Called with $1 - the directory where the setup was created
+
+if [ -z $1 ]; then
+ echo "Use: $0 auh_setup_dir"
+ exit 1
+fi
+
+full_dir=$(readlink -e $1)
+
+auh_dir=$full_dir/auto-upgrade-helper
+poky_dir=$full_dir/poky
+build_dir=$full_dir/build
+sstate_dir=$full_dir/build/sstate-cache
+
+pushd $poky_dir
+
+# Base the upgrades on poky master
+git fetch origin
+git checkout -B tmp-auh-upgrades origin/master
+
+source $poky_dir/oe-init-build-env $build_dir
+$auh_dir/upgradehelper.py -e all
+
+# clean up to avoid the disk filling up
+rm -rf $build_dir/tmp/
+rm -rf $build_dir/workspace/sources/*
+find $sstate_dir -atime +10 -delete
+
+popd
diff --git a/scripts/setup-auh b/scripts/setup-auh
new file mode 100755
index 0000000..23f3d44
--- /dev/null
+++ b/scripts/setup-auh
@@ -0,0 +1,26 @@
+#!/bin/bash
+# Initialize Auto Upgrade Helper in a directory.
+#
+# Called with $1 - the directory to place the setup
+CONFIG_DIR=`dirname $0`/auh-config
+
+if [ -z $1 ]; then
+ echo "Use: $0 target_dir"
+ exit 1
+fi
+
+mkdir -p $1
+pushd $1
+
+git clone git://git.yoctoproject.org/poky
+pushd poky
+git config user.email auh@...
+git config user.name "Auto Upgrade Helper"
+popd
+git clone git://git.yoctoproject.org/auto-upgrade-helper
+source poky/oe-init-build-env build
+mkdir -p upgrade-helper
+popd
+
+cp $CONFIG_DIR/upgrade-helper.conf $1/build/upgrade-helper
+cat $CONFIG_DIR/local.conf.append >> $1/build/conf/local.conf
--
2.26.2


Re: [oe] OpenEmbedded Happy Hour

Ankur Tyagi <ankur.tyagi85@...>
 

See you all from down under !

Cheers
Ankur

On Sun, May 17, 2020, 2:27 AM Marco Cavallini [KOAN] <m.cavallini@...> wrote:
On 15/05/20 17:56, Philip Balister wrote:
> I've made a wiki page to track these:
>
> https://www.openembedded.org/wiki/Happy_Hours
>
> Then next one is scheduled for 2100 UTC on May 27. This is late evening
> for Europe and morning for New Zealand, so hopefully we see some
> different faces. The meeting info is on the wiki page.
>
> There is no set agenda, so bring some projects to talk about with the
> community.
>
>
> Philip
>

https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27&iso=20200527T21&p1=%3A&ah=1

--
Marco



Re: What is the recommended method for debugging applications with Yocto

Patrick Doyle <wpdster@...>
 

Thanks folks, IMAGE_GEN_DEBUGFS was exactly what I was looking for.

--wpd


numerous superfluous PYPI_PACKAGE assignments in meta-python?

Robert P. J. Day
 

in aid of docs, currently poring over python-based recipes to
document how one builds python recipe files, and noticed that numerous
recipe files contain an assignment of the form:

python3-smbus2_0.3.0.bb:PYPI_PACKAGE = "smbus2"

which seems superfluous given that pypi.bbclass contains:

def pypi_package(d):
bpn = d.getVar('BPN')
if bpn.startswith('python-'):
return bpn[7:]
elif bpn.startswith('python3-'):
return bpn[8:]
return bpn

PYPI_PACKAGE ?= "${@pypi_package(d)}"

clearly harmless but, in the above example, unnecessary, no?

there are, of course, numerous recipes that require an assignment of
that form as the actual PyPI package name is some annoying variation,
such as:

python3-sqlalchemy_1.3.12.bb:PYPI_PACKAGE = "SQLAlchemy"
python3-websocket-client_0.56.0.bb:PYPI_PACKAGE = "websocket_client"
python-django-south.inc:PYPI_PACKAGE = "South"

and so on, i just want to be able to write that as long as the recipe
file name *exactly* matches the PyPI package name, that assignment is
unnecessary. (i'm a minimalist.)

rday

p.s. on that note, i was curious about the recipe file
python3-twitter_3.8.0.bb, which contained the line:

PYPI_PACKAGE = "tweepy"

under the circumstances, why not have just named the recipe file
python3-tweepy...?


Re: Package libgcc-lic cannot be installed into the image because it has incompatible license(s): GPL-3.0

Khem Raj
 

On Sat, May 16, 2020 at 7:12 AM Matthias Schoepfer
<matthias.schoepfer@...> wrote:

Hi Khem!

On 5/15/20 4:46 PM, Khem Raj wrote:
On 5/15/20 2:32 AM, Matthias Schoepfer via lists.yoctoproject.org wrote:
Hi!

I am trying to migrate to dunfell. Out customer does not want GPLv3
or anything like that on the firmware.

So - same as in zeus - we have a line:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
AGPL-3.0"

during do_rootfs, the process fails with:

do_rootfs: Package libgcc-lic cannot be installed into the image
because it has incompatible license(s): GPL-3.0

The package basically consists of the license information for libgcc,
libgcc is allowed due to the linking exception.

Even, when I try to allow this package with something like this:

INCOMPATIBLE_LICENSE_pn-libgcc-lic = ""
INCOMPATIBLE_LICENSE_pn-libgcc = ""

which has worked in the past to have an in house debug image with the
gdbserver on it, it still fails.

Am I the first to experience this? Am I doing something wrong?

We do

COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

as well, if that info is needed.

Any help would be appreciated.
Can you try adding

LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"

in meta/recipes-devtools/gcc/libgcc.inc

and see if it helps ?
It did help, thank you very much! I needed to repeat this for libgcrypt
and libidn2. It does look like a bug though, does it not?
if it happens on master too then send the patch to openembedded-core
mailing list


Regards,


Matthias


Best practice for kernel module development

Alexandru Ionita
 

Hello!

I'm totally new to yocto and mainly new to linux development as a whole. Thus, please excuse me if my concerns that I raise here are inadequate.

== Context ==
We are developing a quite simple kernel driver that will make use of the GPIO. For a better reproducibility of the development infrastructure, we would like to be able to build this module against an SDK that is provided by the yocto build.

== Setup ==
While the yocto documentation provides a way to build the kernel module during the yocto build, according to this documentation: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules, we were thinking to make use of the SDK to decouple the development phase of the module from the yocto build. In order to achieve this, the SDK requires the kernel to be configured according to the machine configuration. We expected to be able to have yocto export in the SDK the kernel headers already compiled according to the target environment. However, we couldn't achieve this objective (maybe we're missing something!!). The farthest we could go is to have yocto export the kernel sources into the SDK (according to this SO post https://stackoverflow.com/a/31261404/676344), but then, configuring it was not documented.

== Conclusion ==
We would like to know what is the best practice, from a development and continuous integration perspective, to be able to develop a kernel module.

Your advice is highly appreciated.

Thank you,
Alexandru


Re: Package libgcc-lic cannot be installed into the image because it has incompatible license(s): GPL-3.0

Matthias Schoepfer
 

Hi Khem!

On 5/15/20 4:46 PM, Khem Raj wrote:
On 5/15/20 2:32 AM, Matthias Schoepfer via lists.yoctoproject.org wrote:
Hi!

I am trying to migrate to dunfell. Out customer does not want GPLv3 or anything like that on the firmware.

So - same as in zeus - we have a line:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"

during do_rootfs, the process fails with:

do_rootfs: Package libgcc-lic cannot be installed into the image because it has incompatible license(s): GPL-3.0

The package basically consists of the license information for libgcc, libgcc is allowed due to the linking exception.

Even, when I try to allow this package with something like this:

INCOMPATIBLE_LICENSE_pn-libgcc-lic = ""
INCOMPATIBLE_LICENSE_pn-libgcc = ""

which has worked in the past to have an in house debug image with the gdbserver on it, it still fails.

Am I the first to experience this? Am I doing something wrong?

We do

COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

as well, if that info is needed.

Any help would be appreciated.
Can you try adding

LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"

in meta/recipes-devtools/gcc/libgcc.inc

and see if it helps ?
It did help, thank you very much! I needed to repeat this for libgcrypt and libidn2. It does look like a bug though, does it not?


Regards,


  Matthias


Re: [OE-core] OpenEmbedded Happy Hour

Daniel D?az <daniel.diaz@...>
 

Hello!

On Fri, 15 May 2020 at 10:56, Philip Balister <philip@...> wrote:
I've made a wiki page to track these:
https://www.openembedded.org/wiki/Happy_Hours
Then next one is scheduled for 2100 UTC on May 27.
Ah, just in time to watch live SpaceX's launch:
https://blogs.nasa.gov/commercialcrew/

Greetings!

Daniel Díaz
daniel.diaz@...


OpenEmbedded Happy Hour

Philip Balister
 

I've made a wiki page to track these:

https://www.openembedded.org/wiki/Happy_Hours

Then next one is scheduled for 2100 UTC on May 27. This is late evening
for Europe and morning for New Zealand, so hopefully we see some
different faces. The meeting info is on the wiki page.

There is no set agenda, so bring some projects to talk about with the
community.


Philip


Re: What is the recommended method for debugging applications with Yocto

Andreas Müller
 

On Fri, May 15, 2020 at 5:36 PM Khem Raj <raj.khem@...> wrote:

On 5/15/20 8:25 AM, Patrick Doyle wrote:
I know I can do

$ bitbake base-image -cpopulate_sdk

and distribute the resulting SDK to developers (myself included).

But suppose I've just built and deployed an image and want to debug a
core file generated by one of the applications.

I don't see .debug directories anywhere in $TMP, so when I try to tell
gdb to use the sysroot from the application, that works, but I don't
get debugging symbols libc, nor do I get stack traces (on my MIPS
target).
(I guess it's possible that I would have found the .debug directories
if I had performed a complete build from scratch without the benefit
of the sstate-cache, but I rely upon the sstate-cache and routinely
start with a blank $TMP)

So, I can populate the sdk, and end up with a pile of .debug directories:

$ find . -name .debug -type d
./tmp/work/sundial-poky-linux-musl/base-image/1.0-r0/sdk/image/opt/irobot-mt/0.2/sysroots/mips32r2-24kec-nf-poky-linux-musl/usr/lib/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug
./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/packages-split/musl-utils-dbg/usr/bin/.debug
./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/package/usr/bin/.debug

Which sysroot directory is the best one at which I can point gdb for
getting debug symbols?

If I build this with an autobuilder and want to archive the sysroot
for use by gdb later, which one should I archive?

I could archive the generated SDK, but that will require that I (or
others) install the SDK just to debug a core file, which seems a
little heavy to me. But I can do that, if that's "the Yocto way".

I wonder if there is a lighter weight mechanism for accessing the
debugging symbols during development, and for archiving said symbols
for post-development support.

Any ideas? Best practices? Recommended approaches?
I would think of using IMAGE_GEN_DEBUGFS set to 1 which should generate
a debug archive of image

see following for detailed steps

https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_9_1/page/fvn1520619692704.html

https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging

Thanks

--wpd
I created [1] in meta-mortsgna. It is not recommended (bit of a hack /
nobody but me and my colleagues use it) but it

* works on the fly: Once enabled building the recipe you want to debug
is good enough
* not bound to SDK or image which tends to last
* no manual copying necessary

[1] https://github.com/schnitzeltony/meta-mortsgna/blob/master/classes/instant-sysroot-target.bbclass

Andreas

8381 - 8400 of 57813