Date   

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

Randy MacLeod
 

On 2020-10-20 9:06 a.m., NIKHIL PATIL wrote:
I changed in local.conf (ostree related stuffs ), and put it for compilation , that time i got these error
Hi Nikhil,

We encourage people to avoid top-posting so that discussions are
easier to read:

https://wiki.yoctoproject.org/wiki/Community_Guidelines#Mailing_List_Guidelines

Your description doesn't enable anyone else to reproduce what you are
doing. What git repos (oe-core/poky/bitbake/...) are you using and
what commit is at the HEAD of each?

You have no doubt sourced the oe-init-build-env file, otherwise bitbake
wouldn't work. Can you do that again and send either your full
conf/local.conf file or the lines that you added.


You might read:
https://wiki.yoctoproject.org/wiki/Bug_reporting_and_Information_levels
It's aimed at people opening bugs in the YP Bugzilla but the same rules
apply to email asking for help.

On Tue, Oct 20, 2020 at 6:49 AM Randy MacLeod <randy.macleod@... <mailto:randy.macleod@...>> wrote:
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?
Please confirm that you are able to build core-image-minimal so
that people understand your level of experience when trying to help you.

../Randy

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

--
# Randy MacLeod
# Wind River Linux


Re: network-manager #nmcli #yocto

Quentin Schulz
 

On Tue, Oct 20, 2020 at 06:51:33AM -0700, Zoltan Kerenyi Nagy wrote:
* I hope this is gona be public *
It is, you just answered the wrong mail so my answer isn't in the body
of this mail.

I did a diff between your recommended file, and mine, there is no diff, since it's from the same source.
I understand that I had to install network-manager-nmcli, but how? In the do_install_append() function??
You don't need to change anything in the networkmanager recipe. You need
to add networkmanager-nmcli to the packages installed in your image and
that is done in your image recipe by usually adding it to IMAGE_INSTALL.

I can recommend the videos from our YoctoProject Youtube channel to get
started on Yocto: https://www.youtube.com/watch?v=ThTl4FItfMI&list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

We also have great docs at: https://docs.yoctoproject.org.

Cheers,
Quentin


Re: network-manager #nmcli #yocto

Zoltan Kerenyi Nagy
 

* I hope this is gona be public *

I did a diff between your recommended file, and mine, there is no diff, since it's from the same source.
I understand that I had to install network-manager-nmcli, but how? In the do_install_append() function??


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

NIKHIL PATIL <nikhilvp29@...>
 

I changed in local.conf (ostree related stuffs ), and put it for compilation , that time i got these error 


On Tue, Oct 20, 2020 at 6:49 AM Randy MacLeod <randy.macleod@...> wrote:
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: [meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

Ross Burton <ross@...>
 

Please do review this one carefully, it continues to build for me and
solves a build failure when using meta-zephyr but not DISTRO=zephyr
(instead, a custom DISTRO and a MACHINE that sets TCLIBC=newlib) but
obviously it is rooting around the build depends and I didn't test the
SDK pieces.

Ross

On Tue, 20 Oct 2020 at 13:43, Ross Burton via lists.yoctoproject.org
<ross=burtonini.com@...> wrote:

Instead of setting TCLIBC=baremetal and then adding newlib in various places,
just set TCLIBC=newlib directly.

This also means we can use the standard DEPENDS instead of reinventing them.

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/distro/zephyr.conf | 7 +------
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 44448af..a98da32 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -5,16 +5,11 @@ DISTRO_VERSION = "1.0"

TARGET_VENDOR = "-yocto"

-TCLIBC = "baremetal"
-TCLIBCAPPEND = ""
+TCLIBC = "newlib"

TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"

-PREFERRED_PROVIDER_virtual/libc = "newlib"
-PREFERRED_PROVIDER_virtual/libiconv = "newlib"
-
-TOOLCHAIN_TARGET_TASK += " newlib"
INHERIT += "siteinfo-zephyr"

INHERIT += "uninative"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7fa4b25..b947472 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -19,9 +19,6 @@ EXTRA_OECMAKE_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
export ZEPHYR_BASE="${S}"


-# We always need a toolchain to cross-compile.
-INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
DEPENDS += " python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

--
2.25.1




[meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

Ross Burton <ross@...>
 

Instead of setting TCLIBC=3Dbaremetal and then adding newlib in various p=
laces,
just set TCLIBC=3Dnewlib directly.

This also means we can use the standard DEPENDS instead of reinventing th=
em.

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/distro/zephyr.conf | 7 +------
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 44448af..a98da32 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -5,16 +5,11 @@ DISTRO_VERSION =3D "1.0"
=20
TARGET_VENDOR =3D "-yocto"
=20
-TCLIBC =3D "baremetal"
-TCLIBCAPPEND =3D ""
+TCLIBC =3D "newlib"
=20
TEST_TARGET =3D "QemuTargetZephyr"
TEST_SUITES =3D "zephyr"
=20
-PREFERRED_PROVIDER_virtual/libc =3D "newlib"
-PREFERRED_PROVIDER_virtual/libiconv =3D "newlib"
-
-TOOLCHAIN_TARGET_TASK +=3D " newlib"
INHERIT +=3D "siteinfo-zephyr"
=20
INHERIT +=3D "uninative"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/reci=
pes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7fa4b25..b947472 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -19,9 +19,6 @@ EXTRA_OECMAKE_append_arm =3D " -DZEPHYR_MODULES=3D${S}/=
modules/cmsis"
export ZEPHYR_BASE=3D"${S}"
=20
=20
-# We always need a toolchain to cross-compile.
-INHIBIT_DEFAULT_DEPS =3D "1"
-DEPENDS +=3D "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} g=
perf-native"
DEPENDS +=3D " python3-pyelftools-native python3-pyyaml-native python3-p=
ykwalify-native"
CROSS_COMPILE =3D "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"
=20
--=20
2.25.1


[meta-zephyr][PATCH] README: add patch submission details

Ross Burton <ross@...>
 

---
README.txt | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/README.txt b/README.txt
index be1ea39..a02659a 100644
--- a/README.txt
+++ b/README.txt
@@ -69,4 +69,15 @@ or
$ MACHINE=3Dqemu-nios2 bitbake zephyr-kernel-test-all -ctestimage
=20
=20
+Contributing
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+Patches for meta-zephyr should be sent to the yocto@...=
rg
+mailing list. See https://lists.yoctoproject.org/g/yocto for subscripti=
on
+details and the list archive. Please add [meta-zephyr] to the subject s=
o
+the patches are identifable.
+
+Git can be configured to send mails appropriately when using git send-em=
ail:
+
+$ git config --local sendemail.to yocto@...
+$ git config --local format.subjectPrefix meta-zephy][PATCH
--=20
2.25.1


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

Quentin Schulz
 

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

Signed-off-by: Ross Burton <ross.burton@...>
---
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
 

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


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

Martin Hundeb?ll
 

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

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@...>
---
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@...>"
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@...>
Sent: Tuesday, October 20, 2020 1:22 AM
To: yocto@...
Cc: Saini, Naveen Kumar <naveen.kumar.saini@...>
Subject: [PATCH][meta-zephyr] layer.conf: add compatibility with Gatesgarth

Signed-off-by: Ross Burton <ross.burton@...>
---
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

6701 - 6720 of 57809