yocto@lists.yoctoproject.org

Re: Private: Re: [yocto] network-manager #yocto #nmcli

Quentin Schulz

#51126

Please keep the mailing list in copy so everyone can benefit from your
progress/the solution, thanks!

On Tue, Oct 20, 2020 at 02:55:26AM -0700, Zoltan Kerenyi Nagy wrote:
I'll do this, thanks.

Interestingly there is a line in the recipe file, which suggests that nmtui will be included.
-with-nmtui=yes \This is an option at build time (i.e. for the **recipe**). It just
configures the piece of SW you're trying to build.

A bitbaked recipe's outcome is **packages**. In **most** cases, the main
package is named after the recipe (which is usually a source of
confusion for people). However, to slim down the main package, most
recipes split their output into multiple packages.

In your case, networkmanager is configured to be compiled with nmtui
support. However, the recipe is asked to put the resulting
binaries/conf files/libs into a separate package (called
networkmanager-nmtui).

When you're installing networmanager, you're not installing the whole
outcome of networkmanager recipe (nor the recipe itself) but the main
package that is the outcome of said recipe. It might not contain all you
want, hence the need for installing other packages for enabling all
features you want/need.

Hope this helps,
Quentin

[meta-zephyr][PATCH] layer.conf: add layer dependency on meta-python

Ross Burton

#51125

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 4ecd6a2..f9de654 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -13,6 +13,6 @@ BBFILE_PRIORITY_zephyr =3D "6"
 # cause compatibility issues with other layers
 LAYERVERSION_zephyr =3D "1"
=20
-LAYERDEPENDS_zephyr =3D "core"
+LAYERDEPENDS_zephyr =3D "core meta-python"
=20
 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

#51124

Hi Martin,

On 20.10.20 11:00, Martin Hundebøll wrote:
Hi Stefano,

On 19/10/2020 18.23, Stefano Babic wrote:
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 rootfsI 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.Yeah, this is also what I often end up doing. I often need a way to
bundle several artifacts together, i.e. bootloader, rootfs, sdk, etc.

With that in mind, I would also very much like a way to make image
artifacts available in WORKDIR without pulling from DEPLOY_DIR_IMAGE -
it just feels wrong to use files from the output folder as input in recipe.
...but as Enrico already said (and I agree with him), this is quite a
"hacking" way to do it. Anyway, I would prefer a clean way in this
direction instead of generating a wic just to extract artifacts (but
again, this is just another way to reach the goal, probably it is just a
question of taste). This could be maybe reachable introducing a more
"base" class for image (or one inheriting just from image ) and make
sure that no packages are implicitely (ok, this means to force
RDEPENDS..) installed.

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
=====================================================================

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

Martin Hundeb?ll

#51123

Hi Stefano,

On 19/10/2020 18.23, Stefano Babic wrote:
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 rootfsI 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.Yeah, this is also what I often end up doing. I often need a way to bundle several artifacts together, i.e. bootloader, rootfs, sdk, etc.

With that in mind, I would also very much like a way to make image artifacts available in WORKDIR without pulling from DEPLOY_DIR_IMAGE - it just feels wrong to use files from the output folder as input in recipe.

// Martin

Re: network-manager #nmcli #yocto

Quentin Schulz

#51122

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

#51121

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

#51120

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

#51119

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

#51118

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

Velumani, Yuvaraj

#51117

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

#51116

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

https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=fedepell/bug14083

Cheers,

F.

Show quoted text

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

#51115

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

#51114

Merged.

Show quoted text

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

#51113

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:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/classes/image-oci.bbclass?h=master

..Ch:W..

Show quoted text

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

#51112

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

#51111

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

#51110

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

#51109

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

#51108

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

#51107

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@...