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

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

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

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

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

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

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

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

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

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.

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

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

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

Merged.

--

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

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@... <mailto:gmail.com@...>> 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