Date   

[auh] [PATCH RESEND 2/5] upgrade-helper.conf: update comments and default values

Quentin Schulz
 

A few comments were misleading or incomplete and some defaults were incorrect.

Signed-off-by: Quentin Schulz <foss@0leil.net>
---
- RESEND because I was not subscribed to the ML with this address already,
- please ignore, resent only for archive purposes on the ML, this patch
has been merged already

upgrade-helper.conf | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/upgrade-helper.conf b/upgrade-helper.conf
index e926300..5696564 100644
--- a/upgrade-helper.conf
+++ b/upgrade-helper.conf
@@ -9,7 +9,7 @@
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
-# variable as required.
+# variable as required. For boolean settings, anything not 'yes' is treated as 'no'.

[maintainer_override]
# e-mail message for recipe upgrades will go to john.doe instead of jane.doe, etc
@@ -22,10 +22,12 @@
# If you are running AUH locally, you do not need to set this up, as AUH
# saves everything to BUILDDIR/upgrade-helper/<timestamp>, and does not attempt
# to send email messages (unless explicitly asked with -e command line option).
+# If no port is specified, port 25 is assumed.
#smtp=smtp.my-server.com:25

-# from whom should the e-mails be sent.
-#from=upgrade.helper@my-server.com
+# from whom should the e-mails be sent (mandatory if --send-emails is passed).
+# Also sets the email address of the author of automated commits.
+#from=uh@not.set

# If enabled, emails for all recipe upgrades will go to john.doe,
# except when recipes are owned by specific maintainer_override entries above.
@@ -34,7 +36,8 @@
# who should be CCd with all upgrade emails (optional)
#cc_recipients=john.doe@doe.com

-# who should get the status mail with statistics, at the end (optional)
+# who should get the status mail with statistics, at the end (mandatory if
+# --send-emails is passed)
#status_recipients=john.doe@doe.com

# Only recipes belonging to maintainers in whitelist will be attempted
@@ -43,7 +46,8 @@
# will attempt when it is run with 'all' option.
#maintainers_whitelist=jane.doe@doe.com john.doe@doe.com johhny.bravo@bravo.com

-# recipes in blacklist will be skipped
+# recipes in blacklist will be skipped (applies only when 'all' or no recipe is
+# passed; does not apply when layer_mode is enabled).
#blacklist=python glibc gcc

# specify the directory where work (patches) will be saved
@@ -55,11 +59,11 @@

# clean sstate directory before upgrading
# Generally not necessary, as bitbake can handle this automatically.
-#clean_sstate=yes
+#clean_sstate=no

# clean tmp directory before upgrading
# Generally not necessary as bitbake can handle this automatically.
-#clean_tmp=yes
+#clean_tmp=no

# Machines to test build with.
# Append _libc-name to test with alternative C library implementations
@@ -71,11 +75,15 @@
# AUH has a reasonable default for this, so you do not need to set your own,
# at least initially.
#
-#machines=qemux86 qemux86_musl qemux86-64 qemuarm qemumips qemuppc
+# Does not apply when layer_mode is enabled.
+#machines=qemux86 qemux86-64 qemuarm qemumips qemuppc qemux86_musl

# Enables buildhistory feature; this is useful as it produces information
# about what has changed in the resulting packages, compared to previous version
-#buildhistory=yes
+#
+# Requires 'buildhistory' to be present in INHERIT and BUILDHISTORY_COMMIT to be set
+# in your conf/local.conf.
+#buildhistory=no

# When AUH has built an upgraded recipe it then creates a commit with the upgrade.
# This setting specifies whether to also revert the commit. Possible values are:
@@ -92,16 +100,21 @@

# If enabled, build and boots a test image, and runs integration tests on it
# If upgraded packages have ptest support those are run as well
-#testimage=no
#
+# Requires 'testimage' in INHERIT in your conf/local.conf and 'ptest' in your
+# distro's DISTRO_FEATURES.
+#testimage=no
+
# This can be used to change the name of the test image.
#
-#testimage_name=image-custom # defaults to core-image-sato
+#testimage_name=core-image-sato

# This can be used to upgrade recipes in a specific layer,
# for example meta-intel, instead of upgrading oe-core recipes.
#
-#layer_mode=False
+# When layer_mode is enabled, layer_name, layer_dir and layer_machines are
+# mandatory. 'blacklist' setting does not apply when in layer_mode.
+#layer_mode=no
#layer_name=meta-intel
#layer_dir=DIR/meta-intel
#layer_machines=intel-core2-32 intel-corei7-64 intel-quark
--
2.26.2


[auh] [PATCH RESEND 1/5] modules: statistics: handle recipes without maintainers

Quentin Schulz
 

Even though a recipe might not have a MAINTAINER set, one still might want to
upgrade it.

This makes it possible to upgrade said kind of recipes and still keep the stats
meaningful by displaying one for all maintainerless recipes.

Signed-off-by: Quentin Schulz <foss@0leil.net>
---
- RESEND because I was not subscribed to the ML with this address already,
- please ignore, resent only for archive purposes on the ML, this patch
has been merged already

modules/statistics.py | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/modules/statistics.py b/modules/statistics.py
index 323d042..77db151 100644
--- a/modules/statistics.py
+++ b/modules/statistics.py
@@ -71,8 +71,10 @@ class Statistics(object):
stat_msg += " * " + status + ": " + str(list_len) + "\n"

for pkg, new_ver, maintainer in self.upgrade_stats[status]:
- stat_msg += " " + pkg + ", " + new_ver + ", " + \
- maintainer + "\n"
+ stat_msg += " " + pkg + ", " + new_ver
+ if maintainer:
+ stat_msg += ", " + maintainer
+ stat_msg += "\n"

if self.total_attempted == 0:
percent_succeded = 0
@@ -93,7 +95,7 @@ class Statistics(object):
for m in self.maintainers:
attempted = self.succeeded[m] + self.failed[m]
stat_msg += " %s: attempted=%d succeeded=%d(%.2f%%) failed=%d(%.2f%%)\n" % \
- (m.split("@")[0], attempted, self.succeeded[m],
+ (m.split("@")[0] if m else "Maintainerless", attempted, self.succeeded[m],
self.succeeded[m] * 100.0 / attempted,
self.failed[m],
self.failed[m] * 100.0 / attempted)
--
2.26.2


Re: [auh] [PATCH 5/5] consistent naming for upgradehelper.py

Alexander Kanavin
 

Then I can take this patch.

I will add the first four patches now, thanks!

Alex


On Sat, 15 Aug 2020 at 21:55, Quentin Schulz <foss@...> wrote:
Rename upgradehelper.py into upgrade-helper.py since the conf file and the git
repo are named with a dash to separate "upgrade" and "helper".

The documentation in the README and upgradehelper.py were also already using
upgrade-helper.py instead of upgradehelper.py.

For all those reasons, let's be consistent and rename the python script.

Signed-off-by: Quentin Schulz <foss@...>
---
 upgradehelper.py => upgrade-helper.py | 0
 weeklyjob.sh                          | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename upgradehelper.py => upgrade-helper.py (100%)

diff --git a/upgradehelper.py b/upgrade-helper.py
similarity index 100%
rename from upgradehelper.py
rename to upgrade-helper.py
diff --git a/weeklyjob.sh b/weeklyjob.sh
index 412685e..94598a2 100755
--- a/weeklyjob.sh
+++ b/weeklyjob.sh
@@ -20,7 +20,7 @@ git fetch origin
 git checkout -B tmp-auh-upgrades origin/master

 source $poky_dir/oe-init-build-env $build_dir
-$auh_dir/upgradehelper.py -e all
+$auh_dir/upgrade-helper.py -e all

 # clean up to avoid the disk filling up
 rm -rf $build_dir/tmp/
--
2.26.2


Re: QA notification for completed autobuilder build (yocto-3.0.4.rc1)

Richard Purdie
 

On Sat, 2020-08-15 at 05:06 +0000, Poky Build User wrote:
A build flagged for QA (yocto-3.0.4.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.0.4.rc1


Build hash information:

bitbake: fd279f857c98d492f43cc62d9ebae18ce6412b6e
meta-arm: 38de27d05f104f989adfed5c5363464dd600b316
meta-gplv2: 0f4eecc000f66d114ad258fa31aed66afa292166
meta-intel: ce6f8ddd2d7f42a9fe530d30332b0d9695e4904b
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
oecore: 9cad716656b427e625a470a820b8b29b1ec9f976
poky: f2eb22a8783f1eecf99bd4042695bab920eed00e
Looks like there were 4 failures in this build:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/2309

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1247
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1249

https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/2302

Two are from vulkan-tools where time.clock() was removed from python
3.8.

I think one is a known virtgl failure. We should perhaps just abort
that test on the problematic host?

The other set of failures are timeout issues on centos7-ty-1 which look
like known intermittent failures, particularly on that host.

I don't think any of there are 3.0.4 regressions and therefore
shouldn't stop the release IMO. We do need to release note the vulkan-
tools issue with py 3.8.

Cheers,

Richard


[ANNOUNCEMENT]Milestone 2 for Yocto Project 3.2 (yocto-3.2_M2) now available

Vineela
 

Hello,

We are pleased to announce the second milestone release for Yocto Project 3.2 (yocto-3.2_M2) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M2

bitbake: 91b809a0902ffd42be4edf7f0a7d25e6d354d822
meta-arm: 5ceb140f37195c1837b377828d13de3f9a351ffd
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 31840bc6cf6e1d86ef911ea214da2169a3c885ca
meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
meta-mingw: c8a0d13a5525fb4acc6da9793ad102b4fc5c141b
oecore: cdbd47dd7e1657b91b65a0940b7cbf119764240f
poky: 20e9df57217c5f37817653d2c3d492f2d4d37623

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M2/testreport.txt

Thank you for everyone's contributions to this release.

Sincerely

Vineela Tummalapalli,
Yocto Project Build and Release
vineela.tummalapalli@intel.com


Re: luajit build issue for rpi3

Marek Belisko
 

OK nevermind. It seems to be builder issue. When re-installed
everything works fine. Sorry for noise.

On Sat, Aug 8, 2020 at 5:16 PM Belisko Marek <marek.belisko@gmail.com> wrote:

Hi,

I'm trying to build luajit for rpi machine and getting strange error
on build machine:

gcc -m32 -o host/minilua host/minilua.o -lm
/home/builder/teamcity/work/2bf058ae8f7d2c6d/.build-rpi3/tmp/hosttools/ld:
skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when
searching for -lgcc
/home/builder/teamcity/work/2bf058ae8f7d2c6d/.build-rpi3/tmp/hosttools/ld:
cannot find -lgcc
/home/builder/teamcity/work/2bf058ae8f7d2c6d/.build-rpi3/tmp/hosttools/ld:
skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when
searching for -lgcc
/home/builder/teamcity/work/2bf058ae8f7d2c6d/.build-rpi3/tmp/hosttools/ld:
cannot find -lgcc
collect2: error: ld returned 1 exit status
Makefile:605: recipe for target 'host/minilua' failed
make[1]: *** [host/minilua] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory
'/home/builder/teamcity/work/2bf058ae8f7d2c6d/.build-rpi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/luajit/2.0.5+gitAUTOINC+02b521981a-r0/git/src'


IIRC luajit built some host tools using i386. I installed
libc6-dev.i386 as stated in luajit but it doesn't help. Also it looks
like it's looking in the host directory for libgcc? Any ideas what
can be wrong?

Thanks and BR,

marek


--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Re: [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Chandana kalluri
 

Okay, sending now.

 

Thanks,

Chandana

 

From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 12, 2020 3:29 PM
To: Chandana Kalluri <ckalluri@...>
Cc: yocto@...
Subject: Re: [yocto] [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

 

Right, I agree with that. Then the patch is fine, but please send it to the correct list: openembedded-core@...

 

Alex

 

 

On Thu, 13 Aug 2020 at 00:19, Chandana Kalluri <ckalluri@...> wrote:

I agree its possible for virgl and qemu to not be tested with other libgl providers other than mesa.

But I also think mesa shouldn’t be hardcoded within the two recipes and should use virtual/libgl so as to provide the users with the flexibility to specify something other than mesa.

If the recipes fail for using something other than mesa, it’s still the users choice .

 

Thanks,

Chandana

 

From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 12, 2020 2:32 PM
To: Chandana Kalluri <ckalluri@...>
Cc: yocto@...; Chandana Kalluri <ckalluri@...>
Subject: Re: [yocto] [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

 

Virgl is not verified with anything else than mesa, and will almost certainly fail. And so does qemu.

 

I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG, so that mesa is not pulled in at all.

 

Alex

 

On Wed, 12 Aug 2020 at 23:02, Chandana kalluri <ckalluri@...> wrote:

If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails.  Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@...>
---
 meta/recipes-devtools/qemu/qemu.inc                        | 2 +-
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
 PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
 PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
 PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
 PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
 PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
 PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
 SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
            file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4


Re: [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Alexander Kanavin
 

Right, I agree with that. Then the patch is fine, but please send it to the correct list: openembedded-core@...

Alex


On Thu, 13 Aug 2020 at 00:19, Chandana Kalluri <ckalluri@...> wrote:

I agree its possible for virgl and qemu to not be tested with other libgl providers other than mesa.

But I also think mesa shouldn’t be hardcoded within the two recipes and should use virtual/libgl so as to provide the users with the flexibility to specify something other than mesa.

If the recipes fail for using something other than mesa, it’s still the users choice .

 

Thanks,

Chandana

 

From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 12, 2020 2:32 PM
To: Chandana Kalluri <ckalluri@...>
Cc: yocto@...; Chandana Kalluri <ckalluri@...>
Subject: Re: [yocto] [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

 

Virgl is not verified with anything else than mesa, and will almost certainly fail. And so does qemu.

 

I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG, so that mesa is not pulled in at all.

 

Alex

 

On Wed, 12 Aug 2020 at 23:02, Chandana kalluri <ckalluri@...> wrote:

If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails.  Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@...>
---
 meta/recipes-devtools/qemu/qemu.inc                        | 2 +-
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
 PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
 PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
 PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
 PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
 PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
 PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
 SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
            file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4


Re: [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Chandana kalluri
 

I agree its possible for virgl and qemu to not be tested with other libgl providers other than mesa.

But I also think mesa shouldn’t be hardcoded within the two recipes and should use virtual/libgl so as to provide the users with the flexibility to specify something other than mesa.

If the recipes fail for using something other than mesa, it’s still the users choice .

 

Thanks,

Chandana

 

From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 12, 2020 2:32 PM
To: Chandana Kalluri <ckalluri@...>
Cc: yocto@...; Chandana Kalluri <ckalluri@...>
Subject: Re: [yocto] [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

 

Virgl is not verified with anything else than mesa, and will almost certainly fail. And so does qemu.

 

I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG, so that mesa is not pulled in at all.

 

Alex

 

On Wed, 12 Aug 2020 at 23:02, Chandana kalluri <ckalluri@...> wrote:

If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails.  Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@...>
---
 meta/recipes-devtools/qemu/qemu.inc                        | 2 +-
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
 PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
 PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
 PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
 PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
 PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
 PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
 SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
            file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4


Re: [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Mark Hatle
 

On 8/12/20 4:32 PM, Alexander Kanavin wrote:
Virgl is not verified with anything else than mesa, and will almost certainly
fail. And so does qemu.
It's not up to OE/YP to verify alternatives, it's up to the people providing the
alternatives.

The question is, is this a MESA dependency or a virtual/gl dependency. If it's
the former, then mesa is correct. But everything I've seen (recently) it's a
virtual/gl dependency and mesa was just specified.

I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG,
so that mesa is not pulled in at all.
QEMU has video emulation and I thought GLX was added for optimization purposes.
Has this changed in QEMU 5?

--Mark

Alex

On Wed, 12 Aug 2020 at 23:02, Chandana kalluri <ckalluri@xilinx.com
<mailto:ckalluri@xilinx.com>> wrote:

If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails.  Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com
<mailto:chandana.kalluri@xilinx.com>>
---
 meta/recipes-devtools/qemu/qemu.inc                        | 2 +-
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
<http://virglrenderer_0.8.2.bb> | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] =
"--enable-nettle,--disable-nettle,nettle"
 PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
 PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
 PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
 PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
 PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
 PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
<http://virglrenderer_0.8.2.bb>
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
<http://virglrenderer_0.8.2.bb>
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
<http://virglrenderer_0.8.2.bb>
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
<http://virglrenderer_0.8.2.bb>
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
 SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer
<http://anongit.freedesktop.org/virglrenderer> \
           
file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4





Re: [poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Alexander Kanavin
 

Virgl is not verified with anything else than mesa, and will almost certainly fail. And so does qemu.

I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG, so that mesa is not pulled in at all.

Alex


On Wed, 12 Aug 2020 at 23:02, Chandana kalluri <ckalluri@...> wrote:
If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails.  Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@...>
---
 meta/recipes-devtools/qemu/qemu.inc                        | 2 +-
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
 PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
 PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
 PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
 PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
 PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
 PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
 SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
            file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4



how to combine out-of-tree kernel module with EXTERNALSRC kernel source?

Robert P. J. Day
 

currently have a perfectly functioning zeus-based layer with a
small number of out-of-tree kernel modules which build just fine
with:

$ bitbake kernel-module-fubar

against the stock linux-yocto (5.2) kernel provided by zeus.

was just asked how to build those same out-of-tree modules
against an external kernel identified by (i'm guessing)
EXTERNALSRC. i don't need to build the kernel itself, just
configure it to the point (a la "make modules_prepare") so
that i can build modules against it.

specifying an external source for the kernel seems easy
enough, but i don't see how to then get the modules to
build against that. a quick google showed me:

https://wiki.koansoftware.com/index.php/Building_Software_from_an_External_Source

"Depending on the type of build (eg, 'inherit module' for out
of tree Linux kernel modules) you may or may not need to set
EXTERNALSRC_BUILD."

that explanation seems a bit on the vague side ... is there
an explanation of this somewhere? i can't modify recipes, i
need to do this exclusively through local.conf.

thoughts? this seems like a useful enough operation that
surely others have done it before now.

rday


[poky][master][PATCH] qemu.inc: Use virtual/libgl instead of mesa

Chandana kalluri
 

If there are multiple providers of virtual/libgl and mesa is not the default
provider, the recipe compilation fails. Use virtual/libgl to pick the default
provider.

Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
---
meta/recipes-devtools/qemu/qemu.inc | 2 +-
meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index b1c822b..dada4b8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -163,7 +163,7 @@ PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
PACKAGECONFIG[alsa] = "--audio-drv-list='oss alsa',,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,mesa"
+PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b1262..5282119 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm mesa libepoxy"
+DEPENDS = "libdrm virtual/libgl libepoxy"
SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \
--
2.7.4


Re: cmake-based project with system lib dependency

Quentin Schulz
 

Hi Sergey,

On Tue, Aug 11, 2020 at 08:36:33PM +0300, Sergey Ivanov wrote:
Hi there.
I want to configure the cmake-based project with dependency on library
libuuid.
The latter is located under util-linux and populated in my
build/tmp/deploy/images/qemuarm/core-image-minimal-dev-qemuarm.manifest:

util-linux-dev armv7vet2hf_neon 2.35.1 (here should be header as well and
static library)
...
util-linux-uuidd armv7vet2hf_neon 2.35.1 (i believe the only library)
...
My bb file is:

SUMMARY = "Recipe to build the 'helloworld-cpp-direct-compile' in cpp"
SECTION = "common_templates"

SRC_URI = "file://CMakeLists.txt \
file://foo.cpp \
file://foo.h "
DEPENDS = "util-linux"

(DEPENDS is for build time dependencies and you add the recipe providing
the sources for it, RDEPENDS_${PN} is for runtime dependencies and you
add packages to it (it is common to have the same name for the recipe and
the main package built by it)).

inherit pkgconfig cmake

S = "${WORKDIR}"
OECMAKE_GENERATOR = "Unix Makefiles"
# project version seems to not be propagated properly
EXTRA_OECMAKE="-DCMAKE_PROJECT_VERSION=${PV}"


while my CMake file has:

pkg_check_modules(uuid REQUIRED IMPORTED_TARGET "uuid >= 2.25")


Now I obtain the error from cmake:
-- Checking for module 'uuid >= 2.25'
-- No package 'uuid' found
CMake Error at
recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:467

What philosophy of yocto to make it work? In other words where 'stage' is
supposed to be located so pkgconfig will find library?
I can suggest watching/listening to Live Coding sessions done by Josef
available on Yocto project's Youtube channel:
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

It should help you get started and understand the basics.

Kind regards,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


Yocto Technical Team Minutes, Engineering Sync, for August 11 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for August 11 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Bruce Ashfield, Jan-Simon
Möller, Tim Orling, Jeremey Puhlmann, Paul Barker, Mark Morton, Alejandro
H, Randy MacLeod, Michael Halstead, Richard Purdie, Trevor Gamblin,
(callin), Ross Burton, Peter Kjellerstedt, Steve Sakoman

== notes ==
- 3.2-M2 out of QA, in final release process, looks good
- now in 3.2-M3, last milestone for features
- 3.2-M4, in september, only for bug fixes
- 3.0.4 (last Zeus) should be built and out this week (if all goes well),
this is the “stutter step”, then we go to 6 months
- some more AB failures added to the list
- some 3.2 bugs that don’t have owners

== general ==
RP: some “old” AB failures have reappeared, perhaps a lock file issue in
bitbake
RP: there is a package data one that might be debuggable and reproducible

RP: relatively quiet week, a couple bitbake patches (<something?>, colourizing
output)

MarkM: what’s the next step for sphinx?
RP: a list was made of the areas to work on (from Nico), we just need people
to sign up
RP: the one I’m going to look at is how to get the versioning to work on the
website

PaulB: meta-kernel layer, seems to be some issues with naming
Ross: we have been using meta-kernel, i can see an argument to rename to
meta-mainline-kernel, perhaps, since meta-kernel is a bit generic
RP: my concern is that meta-kernel doesn’t convey what it does
PaulB: my intention was to make it a common place for common kernels (e.g.
Linaro kernel can be used on a bunch of ARM boards). also my hope was to
support back to kernels that aren’t “current” (e.g. 4.4). so it’s
not just a “mainline” layer
RP: i believe there’s a way to get the mainline kernel with linux-yocto
PaulB: i need to be able to flick customers between, e.g. a 4.4 and a mainline
quickly
TrevorW: the magic to get mainline with linux-yocto is to set
PREFERRED_PROVIDER to linux-yocto-dev
RP: it’s a tricky situation, Bruce does a lot of work, sometimes work that
doesn’t show up on the mailing list, I think collaborating with him
would be a good approach. linux-yocto was created to reduce fragmentation.
sometimes understanding linux-yocto can be tricky.
PaulB: maybe just carrying any differences that we need relative to
linux-yocto might be better. some of my customers just want a raw mainline
(with no other patches) since they also support e.g. Debian
Timo: one of the things i do over and over is explaining linux-yocto to people
and how to use it
TrevorW: it was my intent to explain scc files and kernel patches with the
last talk i gave at devday, if there are suggestions please let me know.
hopefully those videos get published
Armin: one can use kernel branch overrides to use the v5.4/base (of
linux-yocto.git)
RP: maybe we need more docs or information
PaulB: meta-kernel was meant to be lightweight, it doesn’t get as much
testing as linux-yocto, it wasn’t meant to step on anyone’s toes
Timo: maybe this is an opportunity to take a look at the kernel development
manual and make sure it is up to date
RP: maybe we could put a barebones kernel mainline recipe for the versions
that are in each release (i’m not saying that’s a good idea, i’m
just throwing out ideas), or maybe add more testing on AB for the
variations of kernels that area already in each release (e.g. the -rt
kernel)
PaulB: this all sounds good
TrevorW: a suggestion: rename recipes-kernel/linux to
recipes-kernel/linux-yocto and then create a recipes-kernel/linux-mainline
for PaulB’s work?
RP: that would only make sense under the assumption that this would be merged
in oe-core
PaulB: we’re a ways off from that conversation, if ever
PaulB: i don’t think this is something that’s going to get resolved for
M3, but maybe sometime after


cmake-based project with system lib dependency

Sergey Ivanov <icegood1980@...>
 

Hi there.
I want to configure the cmake-based project with dependency on library libuuid.
The latter is located under util-linux and populated in my
build/tmp/deploy/images/qemuarm/core-image-minimal-dev-qemuarm.manifest:

util-linux-dev armv7vet2hf_neon 2.35.1 (here should be header as well and static library)
...
util-linux-uuidd armv7vet2hf_neon 2.35.1 (i believe the only library)
...
My bb file is:

SUMMARY = "Recipe to build the 'helloworld-cpp-direct-compile' in cpp"
SECTION = "common_templates"

SRC_URI = "file://CMakeLists.txt \
           file://foo.cpp \
           file://foo.h "

inherit pkgconfig cmake

S = "${WORKDIR}"
OECMAKE_GENERATOR = "Unix Makefiles"
# project version seems to not be propagated properly
EXTRA_OECMAKE="-DCMAKE_PROJECT_VERSION=${PV}"


while my CMake file has:

pkg_check_modules(uuid REQUIRED IMPORTED_TARGET "uuid >= 2.25")


Now I obtain the error from cmake:
-- Checking for module 'uuid >= 2.25'
--   No package 'uuid' found
CMake Error at recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:467

What philosophy of yocto to make it work? In other words where 'stage' is supposed to be located so pkgconfig will find library?

--
Kind regards,
Sergey Ivanov


Yocto Project Status WW32'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M3

Next Deadline: YP 3.2 M3 build date 2020/8/31

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2 M2 is out of QA and going through release approval
  • We’re now in M3 which is the last milestone for new feature development for this release
  • YP 3.0.4 is due to be built this week and will be the last point release for zeus as we migrate over to our new LTS policy and cadence.
  • A number of new intermittent autobuilder failures were seen this week and logged in bugzilla including one showing signs of another bitbake lockfile race issue.
  • You can see the rest of the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M2 should release soon.
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.3 build date 2020/9/14
  • YP 3.1.3 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: libtool: library search path "/usr/lib" is unsafe for cross-compilation

Ross Burton
 

It's probably because the configure.ac or similar hard-codes a search
in /usr for some libraries and find them there. This is *entirely* a
bug in the clamav configure.ac and you'll have to inspect it to
determine what library it is looking for, whether it can be turned
off, or whether it should be added as a build dependency in the
recipe.

Ross

On Tue, 11 Aug 2020 at 11:07, Charlie Davies
<charles.davies@whitetree.xyz> wrote:

Hi,

Are there any ideas as to why the issue above is happening?

Thanks,

Charlie


Re: libtool: library search path "/usr/lib" is unsafe for cross-compilation

Charlie Davies
 

Hi,

Are there any ideas as to why the issue above is happening?

Thanks,

Charlie


[meta-security][PATCH] sssd: Avoid nss function conflicts with glibc nss.h

hongxu
 

glibc 2.32 will define these varibles [1] which results in conflicts
with these static function names, backport a fix from upstream

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=499a92df8b9fc64a054cf3b7f728f8967fc1da7d

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
...s-Collision-with-external-nss-symbol.patch | 77 +++++++++++++++++++
recipes-security/sssd/sssd_1.16.4.bb | 1 +
2 files changed, 78 insertions(+)
create mode 100644 recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch

diff --git a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
new file mode 100644
index 0000000..9c2bbec
--- /dev/null
+++ b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
@@ -0,0 +1,77 @@
+From a069e4186a3cb482226005d4bc73c6fb3dd35c79 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek@redhat.com>
+Date: Thu, 27 Feb 2020 06:50:40 +0100
+Subject: [PATCH] nss: Collision with external nss symbol
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+One of our internal static function names started
+to collide with external nss symbol. Additional
+sss_ suffix was added to avoid the collision.
+
+This is needed to unblock Fedora Rawhide's
+SSSD build.
+
+Reviewed-by: Pavel Březina <pbrezina@redhat.com>
+
+Upstream-Status: Backport [https://github.com/SSSD/sssd.git]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ src/responder/nss/nss_cmd.c | 18 ++++++++++--------
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/src/responder/nss/nss_cmd.c b/src/responder/nss/nss_cmd.c
+index 25e663e..a4d4cfc 100644
+--- a/src/responder/nss/nss_cmd.c
++++ b/src/responder/nss/nss_cmd.c
+@@ -728,11 +728,13 @@ done:
+ talloc_free(cmd_ctx);
+ }
+
+-static void nss_setnetgrent_done(struct tevent_req *subreq);
++static void sss_nss_setnetgrent_done(struct tevent_req *subreq);
+
+-static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
+- enum cache_req_type type,
+- nss_protocol_fill_packet_fn fill_fn)
++/* This function's name started to collide with external nss symbol,
++ * so it has additional sss_* prefix unlike other functions here. */
++static errno_t sss_nss_setnetgrent(struct cli_ctx *cli_ctx,
++ enum cache_req_type type,
++ nss_protocol_fill_packet_fn fill_fn)
+ {
+ struct nss_ctx *nss_ctx;
+ struct nss_state_ctx *state_ctx;
+@@ -774,7 +776,7 @@ static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
+ goto done;
+ }
+
+- tevent_req_set_callback(subreq, nss_setnetgrent_done, cmd_ctx);
++ tevent_req_set_callback(subreq, sss_nss_setnetgrent_done, cmd_ctx);
+
+ ret = EOK;
+
+@@ -787,7 +789,7 @@ done:
+ return EOK;
+ }
+
+-static void nss_setnetgrent_done(struct tevent_req *subreq)
++static void sss_nss_setnetgrent_done(struct tevent_req *subreq)
+ {
+ struct nss_cmd_ctx *cmd_ctx;
+ errno_t ret;
+@@ -1037,8 +1039,8 @@ static errno_t nss_cmd_initgroups_ex(struct cli_ctx *cli_ctx)
+
+ static errno_t nss_cmd_setnetgrent(struct cli_ctx *cli_ctx)
+ {
+- return nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
+- nss_protocol_fill_setnetgrent);
++ return sss_nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
++ nss_protocol_fill_setnetgrent);
+ }
+
+ static errno_t nss_cmd_getnetgrent(struct cli_ctx *cli_ctx)
+--
+2.21.0
+
diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
index 2c3c803..d66c027 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -17,6 +17,7 @@ SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
file://sssd.conf \
file://volatiles.99_sssd \
file://fix-ldblibdir.patch \
+ file://0001-nss-Collision-with-external-nss-symbol.patch \
"

SRC_URI[md5sum] = "757bbb6f15409d8d075f4f06cb678d50"
--
2.21.0

5681 - 5700 of 55944