Date   

Re: #yocto methodology to port from older yocto revisions to current #yocto

Alexander Kanavin
 

I feel that porting from an older Yocto release to a newer one is not the best approach. The delta can be very large, and it can be very painful and time consuming to handle it all at once. By the time you're done, the newer release may be already EOL or close to it. The right approach, in my opinion, is to track upstream master branches and stay as close to their tips as possible, solving any new issues as they happen in a manageable, predictable manner. Then you simply branch off releases when the corresponding branches are created upstream.

Alex


On Mon, 19 Oct 2020 at 13:29, Quentin Schulz <quentin.schulz@...> wrote:
Hi Steve,

On Mon, Oct 19, 2020 at 11:22:41AM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
>
> Hello:
>
> I am currently at Yocto release "Rocko 2.4.1" and I am looking into the effort to port to the latest Yocto release...
>
> We have been using this  rocko platform revision for the last few years in a project, and now want to move to the latest supported release.
>
> Is there a preferred established methodology/guidelines when porting projects from much older established revisions of Yocto?
>

You have a few of the changes highlighted in:
https://docs.yoctoproject.org/ref-manual/migration.html

Obviously, you'd need to do all the changes between Rocko and the
version you're targetting (highly recommend dunfell (3.1) as it's an
LTS).

> Is it considered better to port an established project directly to a new Yocto release, or to slowly migrate the yocto revision to the desired release ?
>

I've done one upgrade only (krogoth 2.1 to thud 2.6) and it was direct,
I'm not sure there's any benefit in doing incremental upgrades?

Good luck :)
Quentin




Re: #yocto methodology to port from older yocto revisions to current #yocto

Quentin Schulz
 

Hi Steve,

On Mon, Oct 19, 2020 at 11:22:41AM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Hello:

I am currently at Yocto release "Rocko 2.4.1" and I am looking into the effort to port to the latest Yocto release...

We have been using this rocko platform revision for the last few years in a project, and now want to move to the latest supported release.

Is there a preferred established methodology/guidelines when porting projects from much older established revisions of Yocto?
You have a few of the changes highlighted in:
https://docs.yoctoproject.org/ref-manual/migration.html

Obviously, you'd need to do all the changes between Rocko and the
version you're targetting (highly recommend dunfell (3.1) as it's an
LTS).

Is it considered better to port an established project directly to a new Yocto release, or to slowly migrate the yocto revision to the desired release ?
I've done one upgrade only (krogoth 2.1 to thud 2.6) and it was direct,
I'm not sure there's any benefit in doing incremental upgrades?

Good luck :)
Quentin


#yocto methodology to port from older yocto revisions to current #yocto

Monsees, Steven C (US)
 

 

Hello:

 

I am currently at Yocto release “Rocko 2.4.1” and I am looking into the effort to port to the latest Yocto release…

 

We have been using this  rocko platform revision for the last few years in a project, and now want to move to the latest supported release.

 

Is there a preferred established methodology/guidelines when porting projects from much older established revisions of Yocto?

 

Is it considered better to port an established project directly to a new Yocto release, or to slowly migrate the yocto revision to the desired release ?

 

Thanks,

Steve


Re: slightly weird use of PACKAGECONFIG in bbappend file?

Richard Purdie
 

On Sun, 2020-10-18 at 14:31 -0400, Robert P. J. Day wrote:
currently updating lots of YP class notes, and writing a short
section on "coding style", and ran across the following oddity(?)
related to PACKAGECONFIG (all on master branches).

i noticed in oe-core, qemu.inc:

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice"

fair enough, that defines a setting for "spice" related to qemu.
however, for reasons that would make no sense to anyone but me, i
ended up at meta-cloud-services/meta-openstack/qemu_5.%.bbappend,
which conditionally requires qemu-openstack.inc, which contains:

/// start

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice,"
PACKAGECONFIG[libseccomp] = "--enable-seccomp,--disable-
seccomp,libseccomp,libseccomp"

PACKAGECONFIG ?= "fdt virtfs libcap-ng"
PACKAGECONFIG_x86 ?= "fdt spice virtfs libcap-ng"
PACKAGECONFIG_x86-64 ?= "fdt spice virtfs libcap-ng"

PACKAGECONFIG_class-native = "fdt"
PACKAGECONFIG_class-nativesdk = "fdt"

/// end

i have no problem with a recipe bbappend file selecting or
deselecting PACKAGECONFIG settings, but it looks just weird for a
bbappend file to define *new* PACKAGECONFIG settings -- that would
seem to be a property restricted to the base .bb recipe file for any
recipe.

so in the above meta-openstack file, the line related to "spice" is
clearly redundant, but the line related to "libseccomp" just looks
weird as that should be defined in the qemu base recipe, no?

or am i misunderstanding something again?
I'm on record as strongly suggesting PACKAGECONFIG entries should be in
the base recipes, there isn't a good reason I'm aware of not to do
that. Obviously the system is very flexible though...

Cheers,

Richard


[meta-cgl][PATCH] resource-agents: use /run instead of /var/run in systemd service file

Chen Qi
 

/var/run has been deprecated by systemd, so use /run instead,
as suggested by systemd.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
...ervice.in-use-run-instead-of-var-run.patch | 31 +++++++++++++++++++
.../resource-agents_4.5.0.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644 meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/0001-ldirectord.service.in-use-run-instead-of-var-run.patch

diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/0001-ldirectord.service.in-use-run-instead-of-var-run.patch b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/0001-ldirectord.service.in-use-run-instead-of-var-run.patch
new file mode 100644
index 0000000..0045cee
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/0001-ldirectord.service.in-use-run-instead-of-var-run.patch
@@ -0,0 +1,31 @@
+From c739aa4fda8bae8e0aa7ed6af29c16392eb13a86 Mon Sep 17 00:00:00 2001
+From: Chen Qi <Qi.Chen@windriver.com>
+Date: Fri, 16 Oct 2020 16:24:24 +0800
+Subject: [PATCH] ldirectord.service.in: use /run instead of /var/run
+
+/var/run has been deprecated by systemd, so use /run instead,
+as suggested by systemd.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+ ldirectord/systemd/ldirectord.service.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ldirectord/systemd/ldirectord.service.in b/ldirectord/systemd/ldirectord.service.in
+index 191f62af..7965b79f 100644
+--- a/ldirectord/systemd/ldirectord.service.in
++++ b/ldirectord/systemd/ldirectord.service.in
+@@ -8,7 +8,7 @@ ExecStartPost=/usr/bin/touch /var/lock/subsys/ldirectord
+ ExecStop=@sbindir@/ldirectord stop
+ ExecStopPost=@RM@ -f /var/lock/subsys/ldirectord
+ ExecReload=@sbindir@/ldirectord reload
+-PIDFile=/var/run/ldirectord.ldirectord.pid
++PIDFile=/run/ldirectord.ldirectord.pid
+ Type=forking
+ KillMode=none
+
+--
+2.17.1
+
diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
index d9440d3..cc3ce89 100644
--- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
@@ -19,6 +19,7 @@ SRC_URI = "git://github.com/ClusterLabs/resource-agents \
file://02-set-OCF_ROOT_DIR-to-libdir-ocf.patch \
file://03-fix-header-defs-lookup.patch \
file://fix-install-sh-not-found.patch \
+ file://0001-ldirectord.service.in-use-run-instead-of-var-run.patch \
"

SRCREV = "fee181320547365d7f8c88cca2b32801412b933d"
--
2.17.1


Re: Yocto - glib-gettextize: not found #yocto

Khem Raj
 


Perhaps add depends on glib-2.0-native 

On Sun, Oct 18, 2020 at 2:00 PM <zidouhzakaria@...> wrote:

I'm trying to compile a recipe based on autotools, but it still fails in do_configure:

glib-gettextize: not found

However, I have glib-2.0 in my DEPENDS which generates the glib-2.0-dev package containing the binary. In glib.inc file :


[...]
    FILES_${PN}-dev += "[...]
                            ${bindir}/glib-gettextize \
[...]


Do you have any ideas ?

Thanks 

 




Re: slightly weird use of PACKAGECONFIG in bbappend file?

Khem Raj
 

On Sun, Oct 18, 2020 at 11:32 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:


currently updating lots of YP class notes, and writing a short
section on "coding style", and ran across the following oddity(?)
related to PACKAGECONFIG (all on master branches).

i noticed in oe-core, qemu.inc:

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice"

fair enough, that defines a setting for "spice" related to qemu.
however, for reasons that would make no sense to anyone but me, i
ended up at meta-cloud-services/meta-openstack/qemu_5.%.bbappend,
which conditionally requires qemu-openstack.inc, which contains:

/// start

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice,"
PACKAGECONFIG[libseccomp] = "--enable-seccomp,--disable-seccomp,libseccomp,libseccomp"

PACKAGECONFIG ?= "fdt virtfs libcap-ng"
PACKAGECONFIG_x86 ?= "fdt spice virtfs libcap-ng"
PACKAGECONFIG_x86-64 ?= "fdt spice virtfs libcap-ng"

PACKAGECONFIG_class-native = "fdt"
PACKAGECONFIG_class-nativesdk = "fdt"

/// end

i have no problem with a recipe bbappend file selecting or
deselecting PACKAGECONFIG settings, but it looks just weird for a
bbappend file to define *new* PACKAGECONFIG settings -- that would
seem to be a property restricted to the base .bb recipe file for any
recipe.

so in the above meta-openstack file, the line related to "spice" is
clearly redundant, but the line related to "libseccomp" just looks
weird as that should be defined in the qemu base recipe, no?

or am i misunderstanding something again?

there is no such hard and fast rule. Should all packageconfig knobs be in
main recipe, perhaps a good practice but not necessary,

rday



Yocto - glib-gettextize: not found #yocto

zidouhzakaria@...
 

I'm trying to compile a recipe based on autotools, but it still fails in do_configure:

glib-gettextize: not found

However, I have glib-2.0 in my DEPENDS which generates the glib-2.0-dev package containing the binary. In glib.inc file :


[...]
    FILES_${PN}-dev += "[...]
                            ${bindir}/glib-gettextize \
[...]


Do you have any ideas ?

Thanks 


slightly weird use of PACKAGECONFIG in bbappend file?

Robert P. J. Day
 

currently updating lots of YP class notes, and writing a short
section on "coding style", and ran across the following oddity(?)
related to PACKAGECONFIG (all on master branches).

i noticed in oe-core, qemu.inc:

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice"

fair enough, that defines a setting for "spice" related to qemu.
however, for reasons that would make no sense to anyone but me, i
ended up at meta-cloud-services/meta-openstack/qemu_5.%.bbappend,
which conditionally requires qemu-openstack.inc, which contains:

/// start

PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice,"
PACKAGECONFIG[libseccomp] = "--enable-seccomp,--disable-seccomp,libseccomp,libseccomp"

PACKAGECONFIG ?= "fdt virtfs libcap-ng"
PACKAGECONFIG_x86 ?= "fdt spice virtfs libcap-ng"
PACKAGECONFIG_x86-64 ?= "fdt spice virtfs libcap-ng"

PACKAGECONFIG_class-native = "fdt"
PACKAGECONFIG_class-nativesdk = "fdt"

/// end

i have no problem with a recipe bbappend file selecting or
deselecting PACKAGECONFIG settings, but it looks just weird for a
bbappend file to define *new* PACKAGECONFIG settings -- that would
seem to be a property restricted to the base .bb recipe file for any
recipe.

so in the above meta-openstack file, the line related to "spice" is
clearly redundant, but the line related to "libseccomp" just looks
weird as that should be defined in the qemu base recipe, no?

or am i misunderstanding something again?

rday


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

NIKHIL PATIL
 

Hi team ,
      I am getting continuously dnf error, How we can resolve these .

      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


Re: Which dts is being compiled?

Bel Hadj Salem Talel
 

Hi,

The kernel compiles every DTS exists in the Makefile which is located with DTS files. (arch/arm/boot/dts/Makefile) or (arch/arm64/boot/dts/[VENDOR]/Makefile)

In order to see what device tree is deployed into your image, please see the value of this variable : KERNEL_DEVICETREE:

$ bitbake -e | grep ^KERNEL_DEVICETREE=

You can specify your machine also : $ bitbake -e | grep ^KERNEL_DEVICETREE_[MACHINE]=

Generally this variable is used in your MACHINE configuration file.

If you want to understand how DTS is used in Yocto , you can take a look at poky/meta/classes/devicetree.bbclass

Best Regards, Talel


Re: Which dts is being compiled?

Zoran
 

Hello David,

Not sure if your question has anything to do with YOCTO (in contrary,
I this is has nothing to do with it). I see kerne's .dtb from U-BOOT
messages while booting the system:

debug: [enable_uboot_overlays=1] ...
debug: [enable_uboot_cape_universal=1] ...
debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ...
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...
<<======= .dtb used
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb ...
loading /boot/dtbs/5.7.4-bone10/am335x-boneblack-uboot-univ.dtb ...
<<======= .dtb loaded
210649 bytes read in 183 ms (1.1 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/BB-SPI0-SC16IS740-00A0.dtbo ...
2291 bytes read in 698 ms (2.9 KiB/s)

You can also stop in U-BOOT monitor and issue: printenv, then search
for dtb variables.

In my case it gives me the following:
...
uboot_base_dtb=am335x-boneblack-uboot.dtb <<======= This one is
probably one which U-BOOT uses for its purposes
uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb <<======= One used
by the kernel
...

Hope this helps.

Best Regards,
Zoran
_______

On Sun, Oct 18, 2020 at 12:16 AM David Novak <david.novak@dajac.com> wrote:

Hi all. I've found the device tree files and I'm fairly certain I know
which one is being used in out image, but I want to be certain.

What process is used by Yocto to determine which top level dts file to
compile?

Thanks,
David






Re: do_fetch error while compiling code

Richard Purdie
 

On Sun, 2020-10-18 at 11:48 +0530, 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 <nikhilvp29=gmail.com@lists.yoctoproject.org> wrote:
Hi Team ,
We are compiling a source code in yocto . but while comiping 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 (xorg.freedesktop.org)... 131.252.210.176, 2610:10:20:722:a800:ff:feda:470f
Connecting to xorg.freedesktop.org (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 (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 ?
The fetch error means it can't download the file. The above link:

(http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2)

works for me so it suggests something is wrong with the networking on
the machine you're trying to build on.

Cheers,

Richard


Re: do_fetch error while compiling code

NIKHIL PATIL
 

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 <nikhilvp29=gmail.com@...> wrote:
Hi Team ,
      We are compiling a source code in yocto . but while comiping 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 (xorg.freedesktop.org)... 131.252.210.176, 2610:10:20:722:a800:ff:feda:470f
Connecting to xorg.freedesktop.org (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 (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 ?




Which dts is being compiled?

David Novak <david.novak@...>
 

Hi all. I've found the device tree files and I'm fairly certain I know which one is being used in out image, but I want to be certain.

What process is used by Yocto to determine which top level dts file to compile?

Thanks,
David


[dunfell 32/32] apparmor: fix QA warning with systemd enabled

Armin Kuster
 

ERROR: apparmor-2.13.4-r0 do_package: QA Issue: apparmor: Files/directories were installed but not shipped in any package:
/usr/lib/systemd
/usr/lib/systemd/system
/usr/lib/systemd/system/apparmor.service

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index c1f038f..ba58fc5 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -190,7 +190,7 @@ SYSTEMD_AUTO_ENABLE ?= "enable"

PACKAGES += "mod-${PN}"

-FILES_${PN} += "/lib/apparmor/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
+FILES_${PN} += "/lib/apparmor/ ${systemd_system_unitdir} ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
FILES_mod-${PN} = "${libdir}/apache2/modules/*"

# Add coreutils and findutils only if sysvinit scripts are in use
--
2.17.1


[dunfell 31/32] apparmor: fix issue with older use of shell in make

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 1 +
...-fix-failure-on-older-versions-of-Ma.patch | 40 +++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 recipes-mac/AppArmor/files/0001-tests-regression-fix-failure-on-older-versions-of-Ma.patch

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 6ba1ea8..c1f038f 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -24,6 +24,7 @@ SRC_URI = " \
file://0001-Makefile.am-suppress-perllocal.pod.patch \
file://run-ptest \
file://0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch \
+ file://0001-tests-regression-fix-failure-on-older-versions-of-Ma.patch \
"

SRCREV = "df0ac742f7a1146181d8734d03334494f2015134"
diff --git a/recipes-mac/AppArmor/files/0001-tests-regression-fix-failure-on-older-versions-of-Ma.patch b/recipes-mac/AppArmor/files/0001-tests-regression-fix-failure-on-older-versions-of-Ma.patch
new file mode 100644
index 0000000..a23d889
--- /dev/null
+++ b/recipes-mac/AppArmor/files/0001-tests-regression-fix-failure-on-older-versions-of-Ma.patch
@@ -0,0 +1,40 @@
+From bf8c4ca570c27cf58e882e03680b40357223e6e7 Mon Sep 17 00:00:00 2001
+From: John Johansen <john.johansen@canonical.com>
+Date: Wed, 30 Sep 2020 13:36:23 -0700
+Subject: [PATCH] tests regression: fix failure on older versions of Make
+
+Older versions of Make will choke on the # character in the $(shell
+expression, treating it as the beginning of a comment. Resulting in
+the following error
+
+make unterminated call to function 'shell': missing ')'. Stop.
+
+MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/639
+Signed-off-by: John Johansen <john.johansen@canonical.com>
+Acked-by: Steve Beattie <steve.beattie@canonical.com>
+(cherry picked from commit 8cf3534a5b11643c5913e5eb74e491f2f014d792)
+
+Upstream-Status: Backport
+[Minor fixup]
+Signed-off-by: Armin Kuster <akuster808@gmail.com>
+---
+ tests/regression/apparmor/Makefile | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tests/regression/apparmor/Makefile b/tests/regression/apparmor/Makefile
+index c3d0cfb7..1d55547c 100644
+--- a/tests/regression/apparmor/Makefile
++++ b/tests/regression/apparmor/Makefile
+@@ -69,7 +69,8 @@ endif # USE_SYSTEM
+
+ CFLAGS += -g -O0 -Wall -Wstrict-prototypes
+
+-USE_SYSCTL:=$(shell echo "#include <sys/sysctl.h>" | cpp -dM >/dev/null 2>/dev/null && echo true)
++SYSCTL_INCLUDE="\#include <sys/sysctl.h>"
++USE_SYSCTL:=$(shell echo $(SYSCTL_INCLUDE) | cpp -dM >/dev/null 2>/dev/null && echo true)
+
+
+ SRC=access.c \
+--
+2.17.1
+
--
2.17.1


[dunfell 30/32] README: updated branch for Dunfell

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
README | 12 ++++++------
meta-integrity/README.md | 8 ++------
meta-security-compliance/README | 8 ++++----
meta-security-isafw/README.md | 4 ++--
meta-tpm/README | 8 ++++----
5 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/README b/README
index f223fee..19b07c7 100644
--- a/README
+++ b/README
@@ -10,27 +10,27 @@ Dependencies
This layer depends on:

URI: git://git.openembedded.org/openembedded-core
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-oe
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-perl
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-python
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-networking
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

@@ -60,7 +60,7 @@ Maintenance
Send pull requests, patches, comments or questions to yocto@lists.yoctoproject.org

When sending single patches, please using something like:
-'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-security][PATCH'
+'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-security][dunfell][PATCH'

These values can be set as defaults for this repository:

diff --git a/meta-integrity/README.md b/meta-integrity/README.md
index 4607948..f08a164 100644
--- a/meta-integrity/README.md
+++ b/meta-integrity/README.md
@@ -10,15 +10,11 @@ Dependencies
This layer depends on:

URI: git://git.openembedded.org/bitbake
- branch: master
+ branch: dunfell

URI: git://git.openembedded.org/openembedded-core
layers: meta
- branch: master
-
- URI: git://github.com/01org/meta-security/meta-integrate
- layers: security-framework
- branch: master
+ branch: dunfell


Patches
diff --git a/meta-security-compliance/README b/meta-security-compliance/README
index 320f856..86a95fb 100644
--- a/meta-security-compliance/README
+++ b/meta-security-compliance/README
@@ -9,16 +9,16 @@ Dependencies
This layer depends on:

URI: git://git.openembedded.org/bitbake
- branch: master
+ branch: 1.48

URI: git://git.openembedded.org/openembedded-core
layers: meta
- branch: master
+ branch: dunfell

or

URI: git://git.yoctoproject.org/poky
- branch: master
+ branch: dunfell



@@ -28,7 +28,7 @@ Maintenance
Send pull requests, patches, comments or questions to yocto@yoctoproject.org

When sending single patches, please using something like:
-'git send-email -1 --to yocto@yoctoproject.org --subject-prefix=meta-security-compliance][PATCH'
+'git send-email -1 --to yocto@yoctoproject.org --subject-prefix=meta-security-compliance][dunfell][PATCH'

Layer Maintainer: Armin Kuster <akuster808@gmail.com>

diff --git a/meta-security-isafw/README.md b/meta-security-isafw/README.md
index 16041cb..48db167 100644
--- a/meta-security-isafw/README.md
+++ b/meta-security-isafw/README.md
@@ -78,12 +78,12 @@ Patches
end pull requests, patches, comments or questions to yocto@lists.yoctoproject.org

When sending single patches, please using something like:
-'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-security-isafw][PATCH'
+'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-security-isafw][dunfell][PATCH'

These values can be set as defaults for this repository:

$ git config sendemail.to yocto@lists.yoctoproject.org
-$ git config format.subjectPrefix meta-security-isafw][PATCH
+$ git config format.subjectPrefix meta-security-isafw][dunfell][PATCH

Now you can just do 'git send-email origin/master' to send all local patches.

diff --git a/meta-tpm/README b/meta-tpm/README
index dd662b3..90e211c 100644
--- a/meta-tpm/README
+++ b/meta-tpm/README
@@ -9,12 +9,12 @@ Dependencies
This layer depends on:

URI: git://git.openembedded.org/openembedded-core
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-oe
- branch: master
+ branch: dunfell
revision: HEAD
prio: default

@@ -41,12 +41,12 @@ Maintenance
Send pull requests, patches, comments or questions to yocto@yoctoproject.org

When sending single patches, please using something like:
-'git send-email -1 --to yocto@yoctoproject.org --subject-prefix=meta-security][PATCH'
+'git send-email -1 --to yocto@yoctoproject.org --subject-prefix=meta-security][dunfell][PATCH'

These values can be set as defaults for this repository:

$ git config sendemail.to yocto@yoctoproject.org
-$ git config format.subjectPrefix meta-security][PATCH
+$ git config format.subjectPrefix meta-security][dunfell][PATCH

Now you can just do 'git send-email origin/master' to send all local patches.

--
2.17.1


[dunfell 29/32] ibmswtpm2: fix QA warning

Armin Kuster
 

ibmswtpm2 doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
index 8054226..a892761 100644
--- a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
+++ b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
@@ -16,6 +16,8 @@ SRC_URI[sha512sum] = "ff0b9e5f0d0070eb572b23641f7a0e70a8bc65cbf4b59dca1778be3bb0

S = "${WORKDIR}/src"

+INSANE_SKIP_${PN} += "ldflags"
+
do_compile () {
make CC='${CC}'
}
@@ -24,4 +26,3 @@ do_install () {
install -d ${D}/${bindir}
install -m 0755 tpm_server ${D}/${bindir}
}
-
--
2.17.1


[dunfell 28/32] layer.conf: use += instead of := to update BBFILES

Armin Kuster
 

From: Sajjad Ahmed <sajjad_ahmed@mentor.com>

Updating BBFILES with := isn't the standard way and can break
parsing under certain conditions, instead use += which is widely used.

Signed-off-by: Sajjad Ahmed <sajjad_ahmed@mentor.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit 63e1cf3ffa26a4e820ec8d882e67e438aa0d23ee)
---
meta-integrity/conf/layer.conf | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index b4edac3..6072e6d 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -2,8 +2,7 @@
BBPATH =. "${LAYERDIR}:"

# We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} \
- ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "integrity"
--
2.17.1

3181 - 3200 of 54255