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

Hi Nikhil,


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

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

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

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

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

Let me and the list know how it goes.

Welcome to Yocto and good luck,

../Randy

--
# Randy MacLeod
# Wind River Linux

Hi Stefano,

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

Hi Enrico,

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

Hi,

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

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

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

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

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

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


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

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

I had the same use case as you, and I could use something like

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

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

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

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

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

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

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


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

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

Or did I miss something that already exists for this?

I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.

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

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

A syntax could look like

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

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

Best regards,
Stefano

Thanks Stefano and best regards

Enrico

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

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

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

Hi Enrico,

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

Hi,

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

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

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

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

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

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


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

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

I had the same use case as you, and I could use something like

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

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

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


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

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

Or did I miss something that already exists for this?

I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.

Best regards,
Stefano

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

Hi,

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

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

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

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

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

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


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

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

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


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

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

Or did I miss something that already exists for this?



Thanks in advance and best regards

Enrico

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

Hi Robert,

On Mon, Oct 19, 2020 at 09:06:39AM -0400, Robert P. J. Day wrote:

Another question regarding recipe/coding style (based on actual
examples I run across in existing code bases).

In one vendor's layer, in file "lighttpd_1.4.%.bbappend", I read:

RDEPENDS_${PN} += " \
lighttpd-module-alias \
lighttpd-module-auth \
lighttpd-module-cgi \
lighttpd-module-compress \
lighttpd-module-evasive \
lighttpd-module-evhost \
... sizable snip of many ore modules ...

There's little question that this is being used to incorporate a
number of optional modules into the final image, but I'm assuming
that this is really not the recommended way to do it.

The YP reference manual defines RDEPENDS as identifying "other
packages that must be installed in order for the package to function
correctly," which suggests that it's the base recipe that should
define actual runtime dependencies.

I would have thought that the natural way to do the above would
be to either use IMAGE_INSTALL_append or (my preference) define
a packagegroup that includes all those packages, then simply
include the packagegroup.

In short, am I reasonable in assuming that bbappend files should
not (ab)use RDEPENDS in the above way?

I'd say they either should be added to IMAGE_INSTALL one by one, or
being put into a packagegroup or even use RRECOMMENDS instead of
RDEPENDS. To me, it feels wrong too, if it's really not a need, they
should not be in RDEPENDS.

Quentin

Another question regarding recipe/coding style (based on actual
examples I run across in existing code bases).

In one vendor's layer, in file "lighttpd_1.4.%.bbappend", I read:

RDEPENDS_${PN} += " \
lighttpd-module-alias \
lighttpd-module-auth \
lighttpd-module-cgi \
lighttpd-module-compress \
lighttpd-module-evasive \
lighttpd-module-evhost \
... sizable snip of many ore modules ...

There's little question that this is being used to incorporate a
number of optional modules into the final image, but I'm assuming
that this is really not the recommended way to do it.

The YP reference manual defines RDEPENDS as identifying "other
packages that must be installed in order for the package to function
correctly," which suggests that it's the base recipe that should
define actual runtime dependencies.

I would have thought that the natural way to do the above would
be to either use IMAGE_INSTALL_append or (my preference) define
a packagegroup that includes all those packages, then simply
include the packagegroup.

In short, am I reasonable in assuming that bbappend files should
not (ab)use RDEPENDS in the above way?

rday

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

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

/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