Date   

Re: network-manager #nmcli #yocto

Quentin Schulz
 

Hi,

On Tue, Oct 20, 2020 at 01:48:37AM -0700, Zoltan Kerenyi Nagy wrote:
Hi All,

My board is a Barix Ipam400, and I'd like to add 4G conenction to it via a USB and 4G Dongle. The dongle is a Huewei E3372 stick.
I'd spent some time with wvdial and usbmodeswitch with no success. Then I tried the stick in my laptop with network-manager, it was working like a charm
Then I've found this ( https://github.com/openembedded/meta-openembedded/tree/master/meta-networking/recipes-connectivity/networkmanager/networkmanager ) source, since the original recipe file would not compile.

Ive bitbaked network.manager loaded to the hardware however there is no nmcli and nmtoi included.
You need to bitbake networkmanager but install networkmanager-nmcli
and/or networkmanager-nmtui, c.f.
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.22.14.bb?h=master#n89

I'd probably triple check all the PACKAGECONFIG you need are set:
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.22.14.bb?h=master#n65

Since you want 4G, it might be a good idea to have modemmanager enabled?
I've never used networmanager so can't help much more than that.

Quentin


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Martin Hundeb?ll
 

Hi Enrico,

On 19/10/2020 17.43, Enrico J?rns wrote:
Hi,
as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)
Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:
p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B
where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.
No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?
We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.
To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):
part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.
BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).
But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?
I've often needed similar functionality.

Sometimes I wonder if one could make a recipe/class that depends on the rootfs contents, installs some packages, and packages the resulting differences - maybe using the --exclude option to tar?

// Martin


network-manager #nmcli #yocto

Zoltan Kerenyi Nagy
 

Hi All,

My board is a Barix Ipam400, and I'd like to add 4G conenction to it via a USB and 4G Dongle. The dongle is a Huewei E3372 stick.
I'd spent some time with wvdial and usbmodeswitch with no success. Then I tried the stick in my laptop with network-manager, it was working like a charm
Then I've found this source, since the original recipe file would not compile.

Ive bitbaked network.manager loaded to the hardware however there is no nmcli and nmtoi included.

Do you have any idea how to proceed from here? There is no gui on the target hardware and I need both the eth0 and the 4G interface preferable set via command line.


[meta-oe][PATCH 1/1] anthy: add GPLv2 to LICENSE and add LIC_FILES_CHKSUM

Taisei Nakano
 

Add GPLv2 into LICENSE, since this software includes alt-cannadic/COPYING which indicates GPLv2.

Signed-off-by: Taisei Nakano <taisei.nakano@miraclelinux.com>
---
meta-oe/recipes-support/anthy/anthy_9100h.bb | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/anthy/anthy_9100h.bb b/meta-oe/recipes-support/anthy/anthy_9100h.bb
index a65d324ea..9d78c3457 100644
--- a/meta-oe/recipes-support/anthy/anthy_9100h.bb
+++ b/meta-oe/recipes-support/anthy/anthy_9100h.bb
@@ -2,8 +2,10 @@ DESCRIPTION="Anthy is a system for Japanese input method. It converts Hiragana t
AUTHOR = "Anthy Developers <anthy-dev@lists.sourceforge.jp>"
HOMEPAGE = "http://anthy.sourceforge.jp"

-LICENSE = "LGPLv2.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=11f384074d8e93e263b5664ef08a411a"
+LICENSE = "LGPLv2.1 & GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=11f384074d8e93e263b5664ef08a411a \
+ file://alt-cannadic/COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b \
+"

SRC_URI = "http://osdn.dl.sourceforge.jp/anthy/37536/anthy-9100h.tar.gz \
file://not_build_elc.patch \
--
2.17.1


[meta-oe][PATCH 0/1] add GPLv2 to anthy's license

Taisei Nakano
 

Hello all,
I have checked the license of Anthy package. I found the LGPLv2.1 in
COPYING and GPLv2 in alt-cannadic/COPYING.
However the recipe LICENSE description is LGPLv2.1.
I would like to correct the description as follow. Could you help me how
to commit?

Taisei Nakano (1):
anthy: add GPLv2 to LICENSE and add LIC_FILES_CHKSUM

meta-oe/recipes-support/anthy/anthy_9100h.bb | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--
2.17.1


meta-flutter build

yuvaraj.velumani@...
 

Hello, 

I have downloaded meta-flutter from https://github.com/jwinarske/meta-flutter.
I tried to build the recipes using the below commands, 
$ source poky/oe-init-build-env build
build$ bitbake flutter-engine

But it give me the following error
ERROR: Task
(/poky/meta-flutter/recipes-graphics/flutter-engine/flutter-engine_git.bb:do_patch) failed with exit code '1'
KeyError: 'meta-flutter'

I also tried building depo-tools manually (bitbake depot-tools), it give me License issue.

depot-tools was skipped: it has an incompatible license: GPLv3

Regards,
Yuvaraj


Re: [PATCH 1/1] openssl: Add c_rehash to misc package and add perl runtime dependency

Federico Pellegrin
 


Sorry, new to the process, adding the pull URL here:


Cheers,
F.


Il giorno mar 20 ott 2020 alle ore 05:27 Federico Pellegrin <fede@...> ha scritto:

c_rehash implemented in perl is back (in history was moved to shell for
some time), so handle it inside the -misc package so just that one will
carry the heavy runtime dependency on perl and not the whole openssl
package. Note: in misc there were already before a few perl files
(tsget.pl and CA.pl) so the added perl dependency will fix those too.

[YOCTO #14083]

Signed-off-by: Federico Pellegrin <fede@...>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 815955837b..66d8851426 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -195,13 +195,14 @@ FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf \
                       ${libdir}/ssl-1.1/openssl.cnf* \
                       "
 FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
+FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
 FILES_${PN} =+ "${libdir}/ssl-1.1/*"
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
 
 CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 
 RRECOMMENDS_libcrypto += "openssl-conf"
+RDEPENDS_${PN}-misc = "perl"
 RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"
 
 RDEPENDS_${PN}-bin += "openssl-conf"
--
2.26.2




[PATCH 1/1] openssl: Add c_rehash to misc package and add perl runtime dependency

Federico Pellegrin
 


c_rehash implemented in perl is back (in history was moved to shell for
some time), so handle it inside the -misc package so just that one will
carry the heavy runtime dependency on perl and not the whole openssl
package. Note: in misc there were already before a few perl files
(tsget.pl and CA.pl) so the added perl dependency will fix those too.

[YOCTO #14083]

Signed-off-by: Federico Pellegrin <fede@...>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 815955837b..66d8851426 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -195,13 +195,14 @@ FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf \
                       ${libdir}/ssl-1.1/openssl.cnf* \
                       "
 FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
+FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
 FILES_${PN} =+ "${libdir}/ssl-1.1/*"
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
 
 CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 
 RRECOMMENDS_libcrypto += "openssl-conf"
+RDEPENDS_${PN}-misc = "perl"
 RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"
 
 RDEPENDS_${PN}-bin += "openssl-conf"
--
2.26.2


Re: [PATCH][meta-zephyr] layer.conf: add compatibility with Gatesgarth

Naveen Saini
 

Merged.

-----Original Message-----
From: Ross Burton <ross.burton@arm.com>
Sent: Tuesday, October 20, 2020 1:22 AM
To: yocto@lists.yoctoproject.org
Cc: Saini, Naveen Kumar <naveen.kumar.saini@intel.com>
Subject: [PATCH][meta-zephyr] layer.conf: add compatibility with Gatesgarth

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf index 1d41b3f..4ecd6a2 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,4 +15,4 @@ LAYERVERSION_zephyr = "1"

LAYERDEPENDS_zephyr = "core"

-LAYERSERIES_COMPAT_zephyr = "dunfell"
+LAYERSERIES_COMPAT_zephyr = "dunfell gatesgarth"
--
2.25.1


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Chuck Wolber
 

I do not know if this precisely answers your question, but creating bbclass functionality to create a different type of image may be the way to go.

What you are suggesting sounds similar to this:


..Ch:W..


On Mon, Oct 19, 2020 at 12:00 PM Enrico J?rns <ejo@...> wrote:
Hi Stefano,

Am Montag, den 19.10.2020, 18:23 +0200 schrieb Stefano Babic:
> Hi Enrico,
>
> On 19.10.20 17:43, Enrico J?rns wrote:
> > Hi,
> >
> > as I did not have much success with my question in the OR irc, let's
> > try it here in a more verbose way. ;)
> >
> > Imagine I have an A+B redundant boot system, with additional bootloader
> > and separate home or application file system. Thus my layout would be
> > like:
> >
> > p1: bootloader
> > p2: rootfs A
> > p3: rootfs B
> > p4: appfs A
> > p5: appfs B
> >
> > where rootfs A + appfs A form a logical unit with respect to the image-
> > based update handling.
> >
> > No my question is: How do I generate the images required for the
> > bootloader partition and/or the appfs partition with the OE standard
> > image generation mechanisms?
> >
> > We have a working solution with the 'genimage' tool for quite some
> > time, but I wonder if that could be done with the more tightly
> > integrated wic, too.
> >
> >
> > To my understanding, the way of creating something like a bootloader
> > image or an application file system is by using wic's image split
> > capabilities and doing (non-redundant example):
> >
> > part /boot --source rootfs (or some plugin)
> > part / ... --source rootfs
> > part /app  --source rootfs
>
> I had the same use case as you, and I could use something like
>
> part /app --source rawcopy --sourceparams="file=..."
>
> and the file points to the image I want to put on the partition.

my intention was a bit different I think. I actually wanted to generate
the /app out of the rootfs image. But then re-use the resulting image.

To be honest I am less interested in the resulting disk image but in
the intermediate artifacts.

I've heard some older discussions on how to generate a separate /home
partition and a separate /data partition and it always turned out that
generating the single monolithic rootfs first and splitting it on a
per-folder base later is a straight-forward approach for most
scenarios.

Trying to get yocto to build images that do not contain things like
base-files, etc. was always painful and never meant to be supported
afaik.

> > This will create multiple file system images out of the prior monolitic
> > rootfs one. It also does all necessary changes for mounting, like
> > modifying the rootfs /etc/fstab etc.
> > Thus, using these generated images in my update scenario would be the
> > way to go for me.
> >
> >
> > BUT, currently I do not see any straight-forward way of how to use
> > them. One could add them to what the image_wic* image fstypes generate,
> > but this will violate the default rule that each image fstype generates
> > exactly one image.
> > And the generated images are a little hard to reference as one cannot
> > give them names (which is probably a negligable issue) and they do not
> > have a fstype extension.
> > The more sever issue is that I would also like to have archives (like
> > tar.bz2) of the content of /app or /boot as I can use them quite good
> > for installing to partitions whose size and other parameters I do not
> > know very beforehand (also applicable to UBI volumes).
> >
> > But, at the moment there does not seem to be a designated way of doing
> > something like I intended. I wonder how others solve the generation of
> > non-rootfs images with YP/OE?
> >
> > Or did I miss something that already exists for this?
>
> I have not a straightforward solution. I inherited just "image" and I
> cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
> superfluous. Maybe forcing packagegroup-core-boot can be an option.

Yes, this would be the 'hacky' solution to the problem. Actually, I
would prefer finding a solution that is supported out-of-the-box and
compatible with how OE sees the generation of images.

Thus re-using the wic fs artifacts appears to be one possible straight-
forward solution to me. The only thing is that I actually would not
even need the disk image itself probably.

A syntax could look like

part / --source rootfs output=my-rootfs-without-appfs.ext4 --fstype=ext4
part /app --source rootfs output=my-appfs.tar.bz --fstype=tar.bz2
part /home --source rootfs output=my-homefs.ext4 --fstype=ext4

Another option could be to introduce some kind of syntax in the file
system generation classes. But I have neither a clue on how to do that
without violating the current behavior of creating only one image per
image type nor a good idea yet on how to name the artifacts.

> Best regards,
> Stefano

Thanks Stefano and best regards

Enrico

>
--
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |






--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: dnf error coming while compiling core-image-sato image.

Randy MacLeod
 

On 2020-10-18 6:41 a.m., NIKHIL PATIL wrote:
Hi team ,
      I am getting continuously dnf error, How we can resolve these .
Hi Nikhil,

What exact steps did you take before getting this error and
what build host are you using?

Are you able to build core-image-minimal using oe-core/master
and the default local.conf for qemux86-64?

../Randy

core-image-sato-1.0-r0 do_rootfs: Could not invoke dnf. Command '/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/yum.repos.d --repofrompath=oe-repo,/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo --installroot=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs --setopt=logdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/temp -x packagegroup-core-apl-extra --nogpgcheck install autoconf-archive dnf gstreamer1.0-vaapi iqvlinux jhi kernel-modules libtcti-device0 libtcti-device-dev libtcti-device-staticdev libtcti-socket0 libtcti-socket-dev libtcti-socket-staticdev libsapi0 libsapi-dev libsapi-staticdev libva mesa-glxinfo libmraa1 nodejs packagegroup-base-extended packagegroup-core-audio-essential packagegroup-core-boot packagegroup-core-buildessential-extended packagegroup-core-graphics-essential packagegroup-core-ssh-dropbear packagegroup-core-tools-testapps packagegroup-core-x11-base packagegroup-core-x11-sato psplash rpm run-postinsts swig tpm2-abrmd usb-modeswitch usb-modeswitch-data va-intel wayland weston weston-examples xinit-env xserver-xorg locale-base-en-us locale-base-en-gb' returned 1:
Added oe-repo repo from /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo

--
# Randy MacLeod
# Wind River Linux


Re: do_fetch error while compiling code

Randy MacLeod
 

On 2020-10-18 2:18 a.m., NIKHIL PATIL wrote:
hi ,
    We totally stuck here , if anyone knows please let us know.
On Sat, Oct 17, 2020 at 3:43 PM NIKHIL PATIL via lists.yoctoproject.org <http://lists.yoctoproject.org> <nikhilvp29=gmail.com@lists.yoctoproject.org <mailto:gmail.com@lists.yoctoproject.org>> wrote:
Hi Team ,
      We are compiling a source code in yocto . but while
compiling we are getting following error . we are not able to find
solution for these .
ERROR: Task
(/data/pradeep/inti_dmsv/yocto_build/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb:do_fetch)
failed with exit code '1'
ERROR: libxcursor-1_1.1.15-r0 do_fetch: Fetcher failure: Fetch
command export PSEUDO_DISABLED=1; export
PATH="/data/pradeep/inti_dmsv/yocto_build/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/data/pradeep/inti_dmsv/yocto_build/scripts:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot/usr/bin/crossscripts:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot-native/usr/sbin:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot-native/usr/bin:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot-native/sbin:/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/recipe-sysroot-native/bin:/data/pradeep/inti_dmsv/yocto_build/bitbake/bin:/data/pradeep/inti_dmsv/yocto_build/build/tmp/hosttools";
export HOME="/home/pradeep"; /usr/bin/env wget -t 2 -T 30
--passive-ftp --no-check-certificate -P
/data/pradeep/inti_dmsv/yocto_build/build/downloads
'http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2'
--progress=dot -v failed with exit code 4, output:
--2020-10-17 09:20:20--
http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2
Resolving xorg.freedesktop.org <http://xorg.freedesktop.org>
(xorg.freedesktop.org <http://xorg.freedesktop.org>)...
131.252.210.176, 2610:10:20:722:a800:ff:feda:470f
Connecting to xorg.freedesktop.org <http://xorg.freedesktop.org>
(xorg.freedesktop.org
<http://xorg.freedesktop.org>)|131.252.210.176|:80... connected.
HTTP request sent, awaiting response... Read error (Connection timed
out) in headers.
Retrying.
--2020-10-17 09:20:52--  (try: 2)
http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2
Connecting to xorg.freedesktop.org <http://xorg.freedesktop.org>
(xorg.freedesktop.org
<http://xorg.freedesktop.org>)|131.252.210.176|:80... connected.
HTTP request sent, awaiting response... Read error (Connection timed
out) in headers.
Giving up.
ERROR: libxcursor-1_1.1.15-r0 do_fetch: Fetcher failure for URL:
'http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2'.
Unable to fetch URL from any source.
ERROR: libxcursor-1_1.1.15-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in:
/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/corei7-64-poky-linux/libxcursor/1_1.1.15-r0/temp/log.do_fetch.19859
ERROR: Task
(/data/pradeep/inti_dmsv/yocto_build/meta/recipes-graphics/xorg-lib/libxcursor_1.1.15.bb:do_fetch)
failed with exit code '1'
*what will be the solution for these ?*
Hi Nikhil,


$cd /tmp; wget http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2

works for me so it's not the upstream web server at least at this
instant.

Can you run this wget command manually to download the tarball?
Do you have a system or corporate firewall causing problems?
If so fix that or do the download somewhere else and bring the sources
to the build machine after clearing that with the people who are
responsible for your workplace's security.

I haven't used this and I don't know if it's up to date by you might
read:
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy

If this doesn't work for you there are commercial solutions that provide
support for Yocto and also deliver all the sources that you'll need.

Let me and the list know how it goes.

Welcome to Yocto and good luck,

../Randy


--
# Randy MacLeod
# Wind River Linux


M+ & H bugs with Milestone Movements WW42

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

14018

efibootpartition.GenericEFITest.test_boot_efi selftest failed

randy.macleod@...

unassigned@...

3.2 M4

3.3 M1

 

14028

Autobuilder buildtools run fails with "Qemu ended unexpectedly"

randy.macleod@...

unassigned@...

3.2 M4

3.3 M1

 

14067

clutter-gst qemu gtkdoc failure

randy.macleod@...

unassigned@...

3.2 M4

3.3 M1

 

14066

bitbake core-image-base -c populate_sdk fails when image contains bash, core-utils and package_deb is used

randy.macleod@...

unassigned@...

3.2 M4

3.3 M1

 

14084

[poky] netbase 3.1 tarball not availabe

randy.macleod@...

steve@...

3.3 M1

3.1.4

 

14087

Replace out of date mailman links with links to groups.io

randy.macleod@...

akuster808@...

3.3 M1

3.1.4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW42

Stephen Jolley
 

All,

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

Who

Count

JPEWhacker@...

1

randy.macleod@...

1

sangeeta.jain@...

1

michael@...

1

david.reyna@...

1

Grand Total

5

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 & 3.3

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

32

david.reyna@...

23

ross@...

21

akuster808@...

19

bluelightning@...

19

bruce.ashfield@...

19

sakib.sajal@...

11

timothy.t.orling@...

11

JPEWhacker@...

11

mark.morton@...

11

kai.kang@...

9

trevor.gamblin@...

9

Qi.Chen@...

7

stacy.gaikovaia@...

5

mingli.yu@...

4

raj.khem@...

4

rpjday@...

4

randy.macleod@...

4

mostthingsweb@...

4

idadelm@...

4

hongxu.jia@...

3

yi.zhao@...

3

jeanmarie.lemetayer@...

2

mark.hatle@...

2

chee.yang.lee@...

2

kergoth@...

2

jpuhlman@...

2

ydirson@...

2

matthewzmd@...

2

alejandro@...

2

michael@...

2

jaewon@...

2

jon.mason@...

2

apoorvsangal@...

1

anuj.mittal@...

1

matt.ranostay@...

1

changqing.li@...

1

saul.wold@...

1

ankur.tyagi85@...

1

fede@...

1

dl9pf@...

1

aehs29@...

1

liu.ming50@...

1

Martin.Jansa@...

1

kexin.hao@...

1

shantanoo_desai@...

1

maxime.roussinbelanger@...

1

jason.wessel@...

1

liezhi.yang@...

1

joe.slater@...

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  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

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 337 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Enrico Jörns
 

Hi Stefano,

Am Montag, den 19.10.2020, 18:23 +0200 schrieb Stefano Babic:
Hi Enrico,

On 19.10.20 17:43, Enrico J?rns wrote:
Hi,

as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)

Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:

p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B

where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.

No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?

We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.


To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):

part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
I had the same use case as you, and I could use something like

part /app --source rawcopy --sourceparams="file=..."

and the file points to the image I want to put on the partition.
my intention was a bit different I think. I actually wanted to generate
the /app out of the rootfs image. But then re-use the resulting image.

To be honest I am less interested in the resulting disk image but in
the intermediate artifacts.

I've heard some older discussions on how to generate a separate /home
partition and a separate /data partition and it always turned out that
generating the single monolithic rootfs first and splitting it on a
per-folder base later is a straight-forward approach for most
scenarios.

Trying to get yocto to build images that do not contain things like
base-files, etc. was always painful and never meant to be supported
afaik.

This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.


BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).

But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?

Or did I miss something that already exists for this?
I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.
Yes, this would be the 'hacky' solution to the problem. Actually, I
would prefer finding a solution that is supported out-of-the-box and
compatible with how OE sees the generation of images.

Thus re-using the wic fs artifacts appears to be one possible straight-
forward solution to me. The only thing is that I actually would not
even need the disk image itself probably.

A syntax could look like

part / --source rootfs output=my-rootfs-without-appfs.ext4 --fstype=ext4
part /app --source rootfs output=my-appfs.tar.bz --fstype=tar.bz2
part /home --source rootfs output=my-homefs.ext4 --fstype=ext4

Another option could be to introduce some kind of syntax in the file
system generation classes. But I have neither a clue on how to do that
without violating the current behavior of creating only one image per
image type nor a good idea yet on how to name the artifacts.

Best regards,
Stefano
Thanks Stefano and best regards

Enrico

--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |


[PATCH][meta-zephyr] layer.conf: add compatibility with Gatesgarth

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 1d41b3f..4ecd6a2 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,4 +15,4 @@ LAYERVERSION_zephyr =3D "1"
=20
LAYERDEPENDS_zephyr =3D "core"
=20
-LAYERSERIES_COMPAT_zephyr =3D "dunfell"
+LAYERSERIES_COMPAT_zephyr =3D "dunfell gatesgarth"
--=20
2.25.1


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Stefano Babic
 

Hi Enrico,

On 19.10.20 17:43, Enrico J?rns wrote:
Hi,

as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)

Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:

p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B

where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.

No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?

We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.


To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):

part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
I had the same use case as you, and I could use something like

part /app --source rawcopy --sourceparams="file=..."

and the file points to the image I want to put on the partition.


This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.


BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).

But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?

Or did I miss something that already exists for this?
I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================


Generating non-rootfs file system images as update artifacts for multi-partition image updates

Enrico Jörns
 

Hi,

as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)

Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:

p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B

where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.

No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?

We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.


To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):

part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs

This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.


BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).

But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?

Or did I miss something that already exists for this?



Thanks in advance and best regards

Enrico

--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |

2421 - 2440 of 53518