Date   

Re: NO INTERNET ENVIRONMENT - USING PREMIRROR fails -> gstreamer1.0_1.12.2.bb:do_unpack failed due to a fetch issue

baranarman@...
 

Hi Martin,

I am still stuck with this issue, 
I understood that the autogen.sh is the point where it wants to update the common submodule. 

Even if BB_NO_NETWORK is set it still tries to access the https://anongit.freedesktop.org/git/gstreamer/common.git 
Which I think is quite surprising!

But about the following lines, I don't know how to do the described thing. 
Usually it was failing in do_configure when building without access to this git repo, we were adding "common" git repo to SRC_URI explicitly to make sure that the right revision is always there with the gstreamer sources and managed with bitbake fetcher (so that it's used from downloads directory instead of the fetch from internet every single time gst* recipes are rebuilt for whatever reason).
  1. What should i copy to my local? the content of https://anongit.freedesktop.org/git/gstreamer/common.git ??? shall i copy one file or complete directory
  2. And then in which file shall i add this url? /home/aselsan/imx-yocto-bsp/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.2.bb ? or in a new recipe
  3. And is it enough just to add the path to SRC_URI or shall i also add the file also ?
Regards,


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

Alexander Kanavin
 

Thanks, I have added this to AUH repo too now; I assume there are no changes in the re-sent patchset otherwise?

Alex


On Sun, 16 Aug 2020 at 23:39, 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@...>
---
 - RESEND because I was not subscribed to the ML with this address already,

 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



[yocto-autobuilder-helper] [PATCH] scripts: run-auh: update upgrade-helper name

Quentin Schulz
 

Since https://lists.yoctoproject.org/g/yocto/message/50282 was merged in
autoupgrade-helper git repo, the python script isn't called
upgradehelper.py anymore but upgrade-helper.py for consistency sake.

Let's update the run-auh script so that it's still working.

Signed-off-by: Quentin Schulz <foss@0leil.net>
---
scripts/run-auh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/run-auh b/scripts/run-auh
index 29a8044..7a9ab70 100755
--- a/scripts/run-auh
+++ b/scripts/run-auh
@@ -22,7 +22,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


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

Quentin Schulz
 

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@0leil.net>
---
- RESEND because I was not subscribed to the ML with this address already,

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


[auh] [PATCH RESEND 4/5] README: update mailing list address

Quentin Schulz
 

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

README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index cb9f87e..ed34140 100644
--- a/README
+++ b/README
@@ -110,7 +110,7 @@ The latest version of the code can always be found here:
http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/

Contributions are welcome. Please send patches / pull requests to
-yocto@yoctoproject.org with '[auh]' in the subject also CC the
+yocto@lists.yoctoproject.org with '[auh]' in the subject also CC the
current maintainer: Alex Kanavin <alex.kanavin@gmail.com>.

License
--
2.26.2


[auh] [PATCH RESEND 3/5] upgradehelper.py: merge dict.get() followed by if into dict.get with a default

Quentin Schulz
 

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

upgradehelper.py | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index c2480f1..7ed7af4 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -201,9 +201,7 @@ class Updater(object):
self.uh_dir = os.path.join(build_dir, "upgrade-helper")
if not os.path.exists(self.uh_dir):
os.mkdir(self.uh_dir)
- self.uh_base_work_dir = settings.get('workdir', '')
- if not self.uh_base_work_dir:
- self.uh_base_work_dir = self.uh_dir
+ self.uh_base_work_dir = settings.get('workdir', self.uh_dir)
if self.opts['layer_mode'] == 'yes':
self.uh_base_work_dir = os.path.join(self.uh_base_work_dir,
self.opts['layer_name'])
--
2.26.2


[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

1741 - 1760 of 52010