[OE-core] [PATCH] buildstats-plot.sh: Show spaces and underscores correctly in titles/keys
Spaces were previously converted to dashes, and underscores caused the
next character in the title/key to be printed using subscript due to the
enhanced string support in gnuplot.
Signed-off-by: Peter Kjellerstedt
---
scripts/contrib/bb-perf/buildstats-plot.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/bb-perf/buildstats-plot.sh
b/scripts/contrib/bb-perf/buildstats-plot.sh
index 80fd30960c..45c27d0b97 100755
--- a/scripts/contrib/bb-perf/buildstats-plot.sh
+++ b/scripts/contrib/bb-perf/buildstats-plot.sh
@@ -120,7 +120,7 @@ OUTBUILDSTATS="$PWD/buildstats.log"
$CD/buildstats.sh -b "$BS_DIR" -s "$STATS" -t "$TASKS" $RECIPE $ACCUMULATE -H
> $OUTBUILDSTATS
# Get headers
-HEADERS=$(cat $OUTBUILDSTATS | sed -n -e '1s/ /-/g' -e '1s/:/ /gp')
+HEADERS=$(cat $OUTBUILDSTATS | sed -n -e 's/\(.*\)/"\1"/' -e '1s/ /
/g' -e 's/_/_/g' -e '1s/:/" "/gp')
echo -e "set boxwidth 0.9 relative"
echo -e "set style data histograms"
@@ -129,7 +129,7 @@ echo -e "set xtics rotate by 45 right"
# Get output data
if [ -z "$SUM" ]; then
-cat $OUTBUILDSTATS | sed -e '1d' | sort -k3 -n -r | head -$N >
$OUTDATA_FILE
+cat $OUTBUILDSTATS | sed -e '1d' -e 's/_/_/g' | sort -k3 -n -r | head
-$N > $OUTDATA_FILE
# include task at recipe column
sed -i -e "1i\
${HEADERS}" $OUTDATA_FILE
--
2.21.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136689):
https://lists.openembedded.org/g/openembedded-core/message/136689
Mute This Topic: https://lists.openembedded.org/mt/72536863/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] security_flags.inc: fix flags missing from SDK toolchain
On Wed, 2020-03-25 at 01:33 +, Tom Hochstein wrote: > > -Original Message- > > From: Richard Purdie > > Sent: Tuesday, March 24, 2020 5:58 PM > > To: Antoine Manache ; Tom Hochstein < > > tom.hochst...@nxp.com> > > Cc: openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core][PATCH] security_flags.inc: fix flags missing > > from SDK toolchain > > > > I've therefore taken Tom's version with some tweaks to the commit > > message. > > Thanks. Can we get this on zeus? Do I need to cherry-pick and submit > the patch? Yes, please post it and then the stable maintainers can review it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136690): https://lists.openembedded.org/g/openembedded-core/message/136690 Mute This Topic: https://lists.openembedded.org/mt/72521987/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] cve-update-db-native: prevent fatal error cause by network
From: Lee Chee Yang
prevent cve-check from fatal error cause by network issue.
[YOCTO #13680]
Signed-off-by: Lee Chee Yang
---
meta/recipes-core/meta/cve-update-db-native.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 575254a..95a0dfc 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -59,7 +59,13 @@ python do_populate_cve_db() {
json_url = year_url + ".json.gz"
# Retrieve meta last modified date
-response = urllib.request.urlopen(meta_url)
+try:
+response = urllib.request.urlopen(meta_url)
+except urllib.error.URLError as e:
+cve_f.write('Warning: CVE db update error, Unable to fetch CVE
data.\n\n')
+bb.warn("Failed to fetch CVE data (%s)" % e.reason)
+return
+
if response:
for l in response.read().decode("utf-8").splitlines():
key, value = l.split(":", 1)
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136691):
https://lists.openembedded.org/g/openembedded-core/message/136691
Mute This Topic: https://lists.openembedded.org/mt/72538430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][zeus][PATCH] security_flags.inc: fix flags missing from SDK toolchain
The security flags were missing from the SDK toolchain
because they were added specifically to class-target.
Add them to class-cross-canadian as well (since the SDK environment
file is created from cross-canadian target flags).
Signed-off-by: Tom Hochstein
Signed-off-by: Antoine Manache
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index aaf04e9e59..568d03693c 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -57,6 +57,8 @@ SECURITY_STRINGFORMAT_pn-gcc = ""
TARGET_CC_ARCH_append_class-target = " ${SECURITY_CFLAGS}"
TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_CC_ARCH_append_class-cross-canadian = " ${SECURITY_CFLAGS}"
+TARGET_LDFLAGS_append_class-cross-canadian = " ${SECURITY_LDFLAGS}"
SECURITY_STACK_PROTECTOR_pn-gcc-runtime = ""
SECURITY_STACK_PROTECTOR_pn-glibc = ""
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136692):
https://lists.openembedded.org/g/openembedded-core/message/136692
Mute This Topic: https://lists.openembedded.org/mt/72540579/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] u-boot-tools: Split out inc file
Spilts out the inc file for u-boot-tools so that BSPs can include it for
their forked version of the tools, just like u-boot.inc.
As an example, this recipe [1] builds mkimage u-boot as part of the
u-boot recipe itself. This is incorrect because u-boot is a target
recipe, which means that the uninative loader transformations do not get
applied when the recipe is restored from sstate, breaking the mkimage
command breaks. The correct solution is to have a u-boot-tools-imx
recipe that pulls in their custom u-boot source; this inc file makes
that much easier to maintain.
[1]:
https://github.com/Freescale/meta-freescale/blob/aa27fc62095cfd6c147c8f6865296ddc29bf0fa6/recipes-bsp/u-boot/u-boot-imx_2019.04.bb
Signed-off-by: Joshua Watt
---
meta/recipes-bsp/u-boot/u-boot-tools.inc | 66 ++
.../u-boot/u-boot-tools_2020.01.bb| 67 +--
2 files changed, 67 insertions(+), 66 deletions(-)
create mode 100644 meta/recipes-bsp/u-boot/u-boot-tools.inc
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools.inc
b/meta/recipes-bsp/u-boot/u-boot-tools.inc
new file mode 100644
index 00..8ae290acc6
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot-tools.inc
@@ -0,0 +1,66 @@
+SUMMARY = "U-Boot bootloader tools"
+DEPENDS += "openssl"
+
+PROVIDES = "${MLPREFIX}u-boot-mkimage ${MLPREFIX}u-boot-mkenvimage"
+PROVIDES_class-native = "u-boot-mkimage-native u-boot-mkenvimage-native"
+
+PACKAGES += "${PN}-mkimage ${PN}-mkenvimage"
+
+# Required for backward compatibility with "u-boot-mkimage-xxx.bb"
+RPROVIDES_${PN}-mkimage = "u-boot-mkimage"
+RREPLACES_${PN}-mkimage = "u-boot-mkimage"
+RCONFLICTS_${PN}-mkimage = "u-boot-mkimage"
+
+EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
+EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1'
+EXTRA_OEMAKE_class-nativesdk = 'CROSS_COMPILE="${HOST_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
+
+SED_CONFIG_EFI = '-e "s/CONFIG_EFI_LOADER=.*/# CONFIG_EFI_LOADER is not set/"'
+SED_CONFIG_EFI_x86 = ''
+SED_CONFIG_EFI_x86-64 = ''
+SED_CONFIG_EFI_arm = ''
+SED_CONFIG_EFI_armeb = ''
+SED_CONFIG_EFI_aarch64 = ''
+
+do_compile () {
+ oe_runmake -C ${S} sandbox_defconfig O=${B}
+
+ # Disable CONFIG_CMD_LICENSE, license.h is not used by tools and
+ # generating it requires bin2header tool, which for target build
+ # is built with target tools and thus cannot be executed on host.
+ sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/"
${SED_CONFIG_EFI} ${B}/.config
+
+ oe_runmake -C ${S} cross_tools NO_SDL=1 O=${B}
+}
+
+do_install () {
+ install -d ${D}${bindir}
+
+ # mkimage
+ install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
+ ln -sf uboot-mkimage ${D}${bindir}/mkimage
+
+ # mkenvimage
+ install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
+ ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
+
+ # dumpimage
+ install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
+ ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
+
+ # fit_check_sign
+ install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-fit_check_sign
+ ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
+}
+
+ALLOW_EMPTY_${PN} = "1"
+FILES_${PN} = ""
+FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage
${bindir}/uboot-dumpimage ${bindir}/dumpimage ${bindir}/uboot-fit_check_sign
${bindir}/fit_check_sign"
+FILES_${PN}-mkenvimage = "${bindir}/uboot-mkenvimage ${bindir}/mkenvimage"
+
+RDEPENDS_${PN}-mkimage += "dtc"
+RDEPENDS_${PN} += "${PN}-mkimage ${PN}-mkenvimage"
+RDEPENDS_${PN}_class-native = ""
+
+BBCLASSEXTEND = "native nativesdk"
+
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
index 414ee333ff..7eaf721ca8 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
@@ -1,67 +1,2 @@
require u-boot-common.inc
-
-SUMMARY = "U-Boot bootloader tools"
-DEPENDS += "openssl"
-
-PROVIDES = "${MLPREFIX}u-boot-mkimage ${MLPREFIX}u-boot-mkenvimage"
-PROVIDES_class-native = "u-boot-mkimage-native u-boot-mkenvimage-native"
-
-PACKAGES += "${PN}-mkimage ${PN}-mkenvimage"
-
-# Required for backward compatibility with "u-boot-mkimage-xxx.bb"
-RPROVIDES_${PN}-mkimage = "u-boot-mkimage"
-RREPLACES_${PN}-mkimage = "u-boot-mkimage"
-RCONFLICTS_${PN}-mkimage = "u-boot-mkimage"
-
-EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
-EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
HOSTCC="${BUILD_CC} ${BUIL
Re: [OE-core] [oe] [bitbake-devel] Mailing list platform change March 20th
On Fri, Mar 20, 2020 at 05:44:36PM -0700, Michael Halstead wrote: > The migration to Groups.io is nearly complete. All functionality is ready > to use and you can send e-mail now. Archives are in place except for the > most recent from the Openembedded-commits list. Those are continuing to > import. > > There is no need to update your address book as the list addresses have not > changed. > > If you encounter any issues please visit > https://www.openembedded.org/wiki/GroupsMigration for the latest > information. If your concern isn't addressed e-mail me directly. Hi, thanks Michael! Can you please check if git hooks sending e-mail notifications still work or need some change (possibly related to this)? There were new commits recently in couple repositories, but last e-mail from git hook I see from Mar 19th. Cheers, signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136694): https://lists.openembedded.org/g/openembedded-core/message/136694 Mute This Topic: https://lists.openembedded.org/mt/72542409/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] safe to get rid of refs to CVSDIR, SVNDIR, GITDIR?
On Mon, 2020-03-23 at 08:19 -0400, rpj...@crashcourse.ca wrote:
> cleaning up docs, and just noticed this from several months back:
>
> commit 4ff058226cfc3e7d5bf9a873d1de4475f65ef2f2
> Author: Andre McCurdy
> Date: Fri Aug 23 13:51:32 2019 -0700
>
> bitbake.conf: drop FETCHCMD, GITDIR, etc fetcher over-rides
>
> This completes cleanup originally proposed in 2012:
>
>
> http://lists.openembedded.org/pipermail/openembedded-core/2012-July/064224.html
>
> Current versions of bitbake have "sane" default fetcher commands
> so it's no longer necessary for bitbake.conf to over-ride them.
>
> Signed-off-by: Andre McCurdy
> Signed-off-by: Richard Purdie >
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1311e6b5fd..a0a7f4911e 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -360,12 +360,6 @@ CACHE = "${TMPDIR}/cache${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('M
> # The persistent cache should be shared by all builds
> PERSISTENT_DIR = "${TOPDIR}/cache"
> LOG_DIR = "${TMPDIR}/log"
> -CO_DIR = "${DL_DIR}"
> -CVSDIR = "${CO_DIR}/cvs"
> -SVNDIR = "${CO_DIR}/svn"
> -GITDIR = "${CO_DIR}/git2"
> -BZRDIR = "${CO_DIR}/bzr"
> -HGDIR = "${CO_DIR}/hg"
>
>
> so is it safe to remove the remnants of references to those
> variables? all that's left is [doc] references to CVSDIR, SVNDIR and
> GITDIR, and this from meta/lib/oe/recipeutils.py:
>
> def get_recipe_upgrade_status(recipes=None):
> pkgs_list = []
> data_copy_list = []
> copy_vars = ('SRC_URI',
> 'PV',
> 'GITDIR', <---
> 'DL_DIR',
> 'PN',
> 'CACHE',
>
> all of that safe to delete? any others that can go with it? (i didn't
> notice any.)
Yes, well spotted, I've queued two patches for this.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136697):
https://lists.openembedded.org/g/openembedded-core/message/136697
Mute This Topic: https://lists.openembedded.org/mt/72489984/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] documentation.conf: Drop obsolete variable docs
These fetcher *DIR variables were dropped a while back, drop the docs that reference them (thanks Robert Day). Signed-off-by: Richard Purdie --- meta/conf/documentation.conf | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf index 0b21d1f63ec..44d69197bf2 100644 --- a/meta/conf/documentation.conf +++ b/meta/conf/documentation.conf @@ -118,7 +118,6 @@ CONFLICT_DISTRO_FEATURES[doc] = "When a recipe inherits the features_check class CORE_IMAGE_EXTRA_INSTALL[doc] = "Specifies the list of packages to be added to the image. You should only set this variable in the conf/local.conf file in the Build Directory." COREBASE[doc] = "Specifies the parent directory of the OpenEmbedded Core Metadata layer (i.e. meta)." CONF_VERSION[doc] = "Tracks the version of local.conf. Increased each time build/conf/ changes incompatibly." -CVSDIR[doc] = "The directory where cvs checkouts will be stored in." #D @@ -178,7 +177,6 @@ FULL_OPTIMIZATION[doc]= "The options to pass in TARGET_CFLAGS and CFLAGS when co #G -GITDIR[doc] = "The directory where Git clones will be stored." GROUPADD_PARAM[doc] = "When a recipe inherits the useradd class, this variable specifies for a package what parameters should be passed to the groupadd command if you wish to add a group to the system when the package is installed." GROUPMEMS_PARAM[doc] = "When a recipe inherits the useradd class, this variable specifies for a package what parameters should be passed to the groupmems command if you wish to modify the members of a group when the package is installed." GRUB_GFXSERIAL[doc] = "Configures the GNU GRand Unified Bootloader (GRUB) to have graphics and serial in the boot menu." @@ -393,7 +391,6 @@ STAGING_KERNEL_DIR[doc] = "The directory with kernel headers that are required t STAMP[doc] = "Specifies the base path used to create recipe stamp files. The path to an actual stamp file is constructed by evaluating this string and then appending additional information." STAMPS_DIR[doc] = "Specifies the base directory in which the OpenEmbedded build system places stamps." SUMMARY[doc] = "The short (80 characters or less) summary of the binary package for packaging systems such as opkg, rpm or dpkg. By default, SUMMARY is used to define the DESCRIPTION variable if DESCRIPTION is not set in the recipe." -SVNDIR[doc] = "The directory where Subversion checkouts will be stored." SYSLINUX_DEFAULT_CONSOLE[doc] = "Specifies the kernel boot default console." SYSLINUX_OPTS[doc] = "Lists additional options to add to the syslinux file." SYSLINUX_SERIAL[doc] = "Specifies the alternate serial port or turns it off." -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136696): https://lists.openembedded.org/g/openembedded-core/message/136696 Mute This Topic: https://lists.openembedded.org/mt/72544382/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] oe/recipeutils: Drop obsolete GITDIR reference
The fetcher GITDIR variable wase dropped a while back, drop the
obsolete reference to it (thanks Robert Day).
Signed-off-by: Richard Purdie
---
meta/lib/oe/recipeutils.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index f53c2b71267..732420e46ff 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1061,7 +1061,6 @@ def get_recipe_upgrade_status(recipes=None):
data_copy_list = []
copy_vars = ('SRC_URI',
'PV',
- 'GITDIR',
'DL_DIR',
'PN',
'CACHE',
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136695):
https://lists.openembedded.org/g/openembedded-core/message/136695
Mute This Topic: https://lists.openembedded.org/mt/72544381/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
Trying to build mesa-gl without X11 enabled, results in numerous errors
about being incorrectly configured, such as:
ERROR: Problem encountered: building dri drivers require at least one
windowing system or classic osmesa
After consulting with the author of this recipe, it was clear that it
was only intended for the X11 use-case, so requring X11 should avoid the
error message above.
Signed-off-by: Mark Hatle
---
meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
index d4b1c1c454..5674c6b1fe 100644
--- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
@@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
S = "${WORKDIR}/mesa-${PV}"
-PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
-PACKAGECONFIG_class-target = "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
'x11', d)}"
+REQUIRED_DISTRO_FEATURE = "x11"
+
+PACKAGECONFIG ??= "opengl dri x11"
+PACKAGECONFIG_class-target = "opengl dri x11"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136698):
https://lists.openembedded.org/g/openembedded-core/message/136698
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
On Wed, Mar 25, 2020 at 01:14:47PM -0500, Mark Hatle wrote:
> Trying to build mesa-gl without X11 enabled, results in numerous errors
> about being incorrectly configured, such as:
>
> ERROR: Problem encountered: building dri drivers require at least one
> windowing system or classic osmesa
>
> After consulting with the author of this recipe, it was clear that it
> was only intended for the X11 use-case, so requring X11 should avoid the
> error message above.
Hmm. That's not good. There are embedded devices that provide EGL/GLES support
through own stack, but fall back on MESA for full desktop GL support. That's
been working to some extent even with Wayland and w/o X11. With your change
that won't be possible any more...
--
Denys
> Signed-off-by: Mark Hatle
> ---
> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> index d4b1c1c454..5674c6b1fe 100644
> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>
> S = "${WORKDIR}/mesa-${PV}"
>
> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11',
> d)}"
> -PACKAGECONFIG_class-target = "opengl dri
> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> +REQUIRED_DISTRO_FEATURE = "x11"
> +
> +PACKAGECONFIG ??= "opengl dri x11"
> +PACKAGECONFIG_class-target = "opengl dri x11"
> --
> 2.17.1
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136699):
https://lists.openembedded.org/g/openembedded-core/message/136699
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
> On Wed, Mar 25, 2020 at 01:14:47PM -0500, Mark Hatle wrote:
>> Trying to build mesa-gl without X11 enabled, results in numerous errors
>> about being incorrectly configured, such as:
>>
>> ERROR: Problem encountered: building dri drivers require at least one
>> windowing system or classic osmesa
>>
>> After consulting with the author of this recipe, it was clear that it
>> was only intended for the X11 use-case, so requring X11 should avoid the
>> error message above.
>
> Hmm. That's not good. There are embedded devices that provide EGL/GLES
> support
> through own stack, but fall back on MESA for full desktop GL support.
> That's
> been working to some extent even with Wayland and w/o X11. With your
> change
> that won't be possible any more...
Have you tried any of these? This hasn't been working since Zeus with an
external libmali and non-X11 configuration. It returns the error listed
in the commit message "ERROR: Problem encountered: building dri drivers
require at least one windowing system or classic osmesa" during
configuration.
Ross and I talked about it and he said this was specific to X11
implementation and wasn't meant to work for other implementations.
(fbdev/QT/etc.)
If Wayland is supposed to work, then someone needs to go in and adjust the
configuration to also support Wayland. I don't have any Wayland systems
to even know what the right configuration COULD be.
The specific configuration I'm running has "OpenGL" in the DISTRO_FEATURE,
but does NOT have X11 or Wayland".
DISTRO_FEATURES_append = " opengl"
DISTRO_FEATURES_remove = "x11 wayland"
--Mark
> --
> Denys
>
>
>> Signed-off-by: Mark Hatle
>> ---
>> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> index d4b1c1c454..5674c6b1fe 100644
>> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>>
>> S = "${WORKDIR}/mesa-${PV}"
>>
>> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
>> 'x11', d)}"
>> -PACKAGECONFIG_class-target = "opengl dri
>> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>> +REQUIRED_DISTRO_FEATURE = "x11"
>> +
>> +PACKAGECONFIG ??= "opengl dri x11"
>> +PACKAGECONFIG_class-target = "opengl dri x11"
>> --
>> 2.17.1
>>
>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136700):
https://lists.openembedded.org/g/openembedded-core/message/136700
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
>> On Wed, Mar 25, 2020 at 01:14:47PM -0500, Mark Hatle wrote:
>>> Trying to build mesa-gl without X11 enabled, results in numerous errors
>>> about being incorrectly configured, such as:
>>>
>>> ERROR: Problem encountered: building dri drivers require at least one
>>> windowing system or classic osmesa
>>>
>>> After consulting with the author of this recipe, it was clear that it
>>> was only intended for the X11 use-case, so requring X11 should avoid
>>> the
>>> error message above.
>>
>> Hmm. That's not good. There are embedded devices that provide EGL/GLES
>> support
>> through own stack, but fall back on MESA for full desktop GL support.
>> That's
>> been working to some extent even with Wayland and w/o X11. With your
>> change
>> that won't be possible any more...
>
>
> Have you tried any of these? This hasn't been working since Zeus with an
> external libmali and non-X11 configuration. It returns the error listed
> in the commit message "ERROR: Problem encountered: building dri drivers
> require at least one windowing system or classic osmesa" during
> configuration.
>
> Ross and I talked about it and he said this was specific to X11
> implementation and wasn't meant to work for other implementations.
> (fbdev/QT/etc.)
>
> If Wayland is supposed to work, then someone needs to go in and adjust the
> configuration to also support Wayland. I don't have any Wayland systems
> to even know what the right configuration COULD be.
>
> The specific configuration I'm running has "OpenGL" in the DISTRO_FEATURE,
> but does NOT have X11 or Wayland".
>
> DISTRO_FEATURES_append = " opengl"
> DISTRO_FEATURES_remove = "x11 wayland"
This can be further refined to:
conf/local.conf:
PREFERRED_PROVIDER_virtual/libgl = "mesa-gl"
PREFERRED_PROVIDER_virtual/mesa = "mesa-gl"
DISTRO_FEATURES_append = " opengl"
DISTRO_FEATURES_remove = "x11"
bitbake mesa-gl
Error is the same:
meson.build:455:4: ERROR: Problem encountered: building dri drivers
require at least one windowing system or classic osmesa
> --Mark
>
>> --
>> Denys
>>
>>
>>> Signed-off-by: Mark Hatle
>>> ---
>>> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>>> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>>> index d4b1c1c454..5674c6b1fe 100644
>>> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>>> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>>> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>>>
>>> S = "${WORKDIR}/mesa-${PV}"
>>>
>>> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
>>> 'x11', d)}"
>>> -PACKAGECONFIG_class-target = "opengl dri
>>> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>>> +REQUIRED_DISTRO_FEATURE = "x11"
>>> +
>>> +PACKAGECONFIG ??= "opengl dri x11"
>>> +PACKAGECONFIG_class-target = "opengl dri x11"
>>> --
>>> 2.17.1
>>>
>>
>>>
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136701):
https://lists.openembedded.org/g/openembedded-core/message/136701
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
To be honest, I would just take the entire recipe out. It's causing trouble
during updates, isn't being tested neither for builds nor at runtime, and
is supposed to provide some specific configuration which as this discussion
makes clear, nobody seems to quite understand.
Alex
On Wed, 25 Mar 2020 at 19:42, Mark Hatle
wrote:
> > On Wed, Mar 25, 2020 at 01:14:47PM -0500, Mark Hatle wrote:
> >> Trying to build mesa-gl without X11 enabled, results in numerous errors
> >> about being incorrectly configured, such as:
> >>
> >> ERROR: Problem encountered: building dri drivers require at least one
> >> windowing system or classic osmesa
> >>
> >> After consulting with the author of this recipe, it was clear that it
> >> was only intended for the X11 use-case, so requring X11 should avoid the
> >> error message above.
> >
> > Hmm. That's not good. There are embedded devices that provide EGL/GLES
> > support
> > through own stack, but fall back on MESA for full desktop GL support.
> > That's
> > been working to some extent even with Wayland and w/o X11. With your
> > change
> > that won't be possible any more...
>
>
> Have you tried any of these? This hasn't been working since Zeus with an
> external libmali and non-X11 configuration. It returns the error listed
> in the commit message "ERROR: Problem encountered: building dri drivers
> require at least one windowing system or classic osmesa" during
> configuration.
>
> Ross and I talked about it and he said this was specific to X11
> implementation and wasn't meant to work for other implementations.
> (fbdev/QT/etc.)
>
> If Wayland is supposed to work, then someone needs to go in and adjust the
> configuration to also support Wayland. I don't have any Wayland systems
> to even know what the right configuration COULD be.
>
> The specific configuration I'm running has "OpenGL" in the DISTRO_FEATURE,
> but does NOT have X11 or Wayland".
>
> DISTRO_FEATURES_append = " opengl"
> DISTRO_FEATURES_remove = "x11 wayland"
>
> --Mark
>
> > --
> > Denys
> >
> >
> >> Signed-off-by: Mark Hatle
> >> ---
> >> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> index d4b1c1c454..5674c6b1fe 100644
> >> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
> >>
> >> S = "${WORKDIR}/mesa-${PV}"
> >>
> >> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
> >> 'x11', d)}"
> >> -PACKAGECONFIG_class-target = "opengl dri
> >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> >> +REQUIRED_DISTRO_FEATURE = "x11"
> >> +
> >> +PACKAGECONFIG ??= "opengl dri x11"
> >> +PACKAGECONFIG_class-target = "opengl dri x11"
> >> --
> >> 2.17.1
> >>
> >
> >>
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136702):
https://lists.openembedded.org/g/openembedded-core/message/136702
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
> To be honest, I would just take the entire recipe out. It's causing
> trouble
> during updates, isn't being tested neither for builds nor at runtime, and
> is supposed to provide some specific configuration which as this
> discussion
> makes clear, nobody seems to quite understand.
With the abomination that is libmali (and similar), it is still needed.
It's the only way to support GL on a primarily GLES compatible system.
The problem is the way they do this seems to be a custom version of
libdrm, which then conflicts with the mesa version. Thus the issues.
I'm happy to continue testing my particular needs now and the future (thus
the patch against master.)
What we absolutely don't want is a different version of this for every
system that has a custom graphics chip in it. That would be a far larger
nightmare than what is currently implemented. The key to this is to come
to an agreement on what should work and how it should be configured. As
of right now, the only working configuration I can find is X11.
--Mark
> Alex
>
> On Wed, 25 Mar 2020 at 19:42, Mark Hatle
> wrote:
>
>> > On Wed, Mar 25, 2020 at 01:14:47PM -0500, Mark Hatle wrote:
>> >> Trying to build mesa-gl without X11 enabled, results in numerous
>> errors
>> >> about being incorrectly configured, such as:
>> >>
>> >> ERROR: Problem encountered: building dri drivers require at least
>> one
>> >> windowing system or classic osmesa
>> >>
>> >> After consulting with the author of this recipe, it was clear that it
>> >> was only intended for the X11 use-case, so requring X11 should avoid
>> the
>> >> error message above.
>> >
>> > Hmm. That's not good. There are embedded devices that provide EGL/GLES
>> > support
>> > through own stack, but fall back on MESA for full desktop GL support.
>> > That's
>> > been working to some extent even with Wayland and w/o X11. With your
>> > change
>> > that won't be possible any more...
>>
>>
>> Have you tried any of these? This hasn't been working since Zeus with
>> an
>> external libmali and non-X11 configuration. It returns the error listed
>> in the commit message "ERROR: Problem encountered: building dri drivers
>> require at least one windowing system or classic osmesa" during
>> configuration.
>>
>> Ross and I talked about it and he said this was specific to X11
>> implementation and wasn't meant to work for other implementations.
>> (fbdev/QT/etc.)
>>
>> If Wayland is supposed to work, then someone needs to go in and adjust
>> the
>> configuration to also support Wayland. I don't have any Wayland systems
>> to even know what the right configuration COULD be.
>>
>> The specific configuration I'm running has "OpenGL" in the
>> DISTRO_FEATURE,
>> but does NOT have X11 or Wayland".
>>
>> DISTRO_FEATURES_append = " opengl"
>> DISTRO_FEATURES_remove = "x11 wayland"
>>
>> --Mark
>>
>> > --
>> > Denys
>> >
>> >
>> >> Signed-off-by: Mark Hatle
>> >> ---
>> >> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> >> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> >> index d4b1c1c454..5674c6b1fe 100644
>> >> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> >> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> >> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>> >>
>> >> S = "${WORKDIR}/mesa-${PV}"
>> >>
>> >> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
>> >> 'x11', d)}"
>> >> -PACKAGECONFIG_class-target = "opengl dri
>> >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>> >> +REQUIRED_DISTRO_FEATURE = "x11"
>> >> +
>> >> +PACKAGECONFIG ??= "opengl dri x11"
>> >> +PACKAGECONFIG_class-target = "opengl dri x11"
>> >> --
>> >> 2.17.1
>> >>
>> >
>> >>
>> >
>>
>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136703):
https://lists.openembedded.org/g/openembedded-core/message/136703
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
On Wed, Mar 25, 2020 at 7:15 PM Mark Hatle
wrote:
>
> Trying to build mesa-gl without X11 enabled, results in numerous errors
> about being incorrectly configured, such as:
>
> ERROR: Problem encountered: building dri drivers require at least one
> windowing system or classic osmesa
I believe I was fighting similar issue in meta-freescale layer for
imx8mm derivative [1], where the status of GPU support was not know at
the time. What I did back then is set the default configuration to
osmesa and used swrast in order to be able to use mesa on that
derivative. After that, when GPU support has been added into Mesa -
those modifications were reverted.
I guess turning to swrast in case if someone would decide _not_ to use
X11 - is not a bad option here, rather than enforcing the X11 for
distros which are using this recipe. Any thoughts?
>
> After consulting with the author of this recipe, it was clear that it
> was only intended for the X11 use-case, so requring X11 should avoid the
> error message above.
>
> Signed-off-by: Mark Hatle
> ---
> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> index d4b1c1c454..5674c6b1fe 100644
> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>
> S = "${WORKDIR}/mesa-${PV}"
>
> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11',
> d)}"
> -PACKAGECONFIG_class-target = "opengl dri
> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> +REQUIRED_DISTRO_FEATURE = "x11"
> +
> +PACKAGECONFIG ??= "opengl dri x11"
> +PACKAGECONFIG_class-target = "opengl dri x11"
> --
> 2.17.1
>
>
--
Regards,
Andrey.
[1]:
https://github.com/Freescale/meta-freescale/commit/9a2210d9ec707531436dc4b56ce655c0bf50a8a8
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136704):
https://lists.openembedded.org/g/openembedded-core/message/136704
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
> On Wed, Mar 25, 2020 at 7:15 PM Mark Hatle
> wrote:
>>
>> Trying to build mesa-gl without X11 enabled, results in numerous errors
>> about being incorrectly configured, such as:
>>
>> ERROR: Problem encountered: building dri drivers require at least one
>> windowing system or classic osmesa
>
> I believe I was fighting similar issue in meta-freescale layer for
> imx8mm derivative [1], where the status of GPU support was not know at
> the time. What I did back then is set the default configuration to
> osmesa and used swrast in order to be able to use mesa on that
> derivative. After that, when GPU support has been added into Mesa -
> those modifications were reverted.
Do you have a pointer to that anywhere? I'm curious if any of it might
still apply.. but I know nothing about mesa and what configurations are
even possible.
> I guess turning to swrast in case if someone would decide _not_ to use
> X11 - is not a bad option here, rather than enforcing the X11 for
> distros which are using this recipe. Any thoughts?
I don't know any any reasons we couldn't do this.. but like I said.. I'm a
newbie when it comes to mesa.
--Mark
>>
>> After consulting with the author of this recipe, it was clear that it
>> was only intended for the X11 use-case, so requring X11 should avoid the
>> error message above.
>>
>> Signed-off-by: Mark Hatle
>> ---
>> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> index d4b1c1c454..5674c6b1fe 100644
>> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
>> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
>>
>> S = "${WORKDIR}/mesa-${PV}"
>>
>> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
>> 'x11', d)}"
>> -PACKAGECONFIG_class-target = "opengl dri
>> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>> +REQUIRED_DISTRO_FEATURE = "x11"
>> +
>> +PACKAGECONFIG ??= "opengl dri x11"
>> +PACKAGECONFIG_class-target = "opengl dri x11"
>> --
>> 2.17.1
>>
>>
>
> --
> Regards,
> Andrey.
>
> [1]:
> https://github.com/Freescale/meta-freescale/commit/9a2210d9ec707531436dc4b56ce655c0bf50a8a8
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136705):
https://lists.openembedded.org/g/openembedded-core/message/136705
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
On Wed, Mar 25, 2020 at 9:36 PM Mark Hatle
wrote:
>
> > On Wed, Mar 25, 2020 at 7:15 PM Mark Hatle
> > wrote:
> >>
> >> Trying to build mesa-gl without X11 enabled, results in numerous errors
> >> about being incorrectly configured, such as:
> >>
> >> ERROR: Problem encountered: building dri drivers require at least one
> >> windowing system or classic osmesa
> >
> > I believe I was fighting similar issue in meta-freescale layer for
> > imx8mm derivative [1], where the status of GPU support was not know at
> > the time. What I did back then is set the default configuration to
> > osmesa and used swrast in order to be able to use mesa on that
> > derivative. After that, when GPU support has been added into Mesa -
> > those modifications were reverted.
>
> Do you have a pointer to that anywhere? I'm curious if any of it might
> still apply.. but I know nothing about mesa and what configurations are
> even possible.
I've included the link to my commit in meta-freescale layer, where the
PACKAGECONFIG is set to use 'classic' OSMesa and adds swrast to
DRIDRIVERS. This should turn the rendering to be performed in the SW,
effectively working for all backends (at the obvious performance
penalty). It took me quite some digging to figure this combination
out, as I also cannot claim myself an expert in mesa...
>
> > I guess turning to swrast in case if someone would decide _not_ to use
> > X11 - is not a bad option here, rather than enforcing the X11 for
> > distros which are using this recipe. Any thoughts?
>
> I don't know any any reasons we couldn't do this.. but like I said.. I'm a
> newbie when it comes to mesa.
Maybe something like this could be used (warning: untested):
PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', 'osmesa',d)}"
DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'', ' swrast',d)}"
>
> --Mark
>
> >>
> >> After consulting with the author of this recipe, it was clear that it
> >> was only intended for the X11 use-case, so requring X11 should avoid the
> >> error message above.
> >>
> >> Signed-off-by: Mark Hatle
> >> ---
> >> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> index d4b1c1c454..5674c6b1fe 100644
> >> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> >> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
> >>
> >> S = "${WORKDIR}/mesa-${PV}"
> >>
> >> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
> >> 'x11', d)}"
> >> -PACKAGECONFIG_class-target = "opengl dri
> >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> >> +REQUIRED_DISTRO_FEATURE = "x11"
> >> +
> >> +PACKAGECONFIG ??= "opengl dri x11"
> >> +PACKAGECONFIG_class-target = "opengl dri x11"
> >> --
> >> 2.17.1
> >>
> >>
> >
> > --
> > Regards,
> > Andrey.
> >
> > [1]:
> > https://github.com/Freescale/meta-freescale/commit/9a2210d9ec707531436dc4b56ce655c0bf50a8a8
> >
> >
>
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136706):
https://lists.openembedded.org/g/openembedded-core/message/136706
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
On Wed, Mar 25, 2020 at 10:37:55PM +0100, Andrey Zhizhikin wrote:
> On Wed, Mar 25, 2020 at 9:36 PM Mark Hatle
> wrote:
> >
> > > On Wed, Mar 25, 2020 at 7:15 PM Mark Hatle
> > > wrote:
> > >>
> > >> Trying to build mesa-gl without X11 enabled, results in numerous errors
> > >> about being incorrectly configured, such as:
> > >>
> > >> ERROR: Problem encountered: building dri drivers require at least one
> > >> windowing system or classic osmesa
> > >
> > > I believe I was fighting similar issue in meta-freescale layer for
> > > imx8mm derivative [1], where the status of GPU support was not know at
> > > the time. What I did back then is set the default configuration to
> > > osmesa and used swrast in order to be able to use mesa on that
> > > derivative. After that, when GPU support has been added into Mesa -
> > > those modifications were reverted.
> >
> > Do you have a pointer to that anywhere? I'm curious if any of it might
> > still apply.. but I know nothing about mesa and what configurations are
> > even possible.
>
> I've included the link to my commit in meta-freescale layer, where the
> PACKAGECONFIG is set to use 'classic' OSMesa and adds swrast to
> DRIDRIVERS. This should turn the rendering to be performed in the SW,
> effectively working for all backends (at the obvious performance
> penalty). It took me quite some digging to figure this combination
> out, as I also cannot claim myself an expert in mesa...
FWIW, we also expect SW rendering for GL, while SGX/RGX cores in our SoCs
accelerate EGL/GLES.
But, like Mark, I also don't know much about Mesa. Similar to what he
mentioned about Mali, we used to require a custom libdrm years ago. But
since then, everything has been upstreamed into main libdrm-omap driver.
--
Denys
> > > I guess turning to swrast in case if someone would decide _not_ to use
> > > X11 - is not a bad option here, rather than enforcing the X11 for
> > > distros which are using this recipe. Any thoughts?
> >
> > I don't know any any reasons we couldn't do this.. but like I said.. I'm a
> > newbie when it comes to mesa.
>
> Maybe something like this could be used (warning: untested):
> PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES',
> 'x11', 'x11', 'osmesa',d)}"
> DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> '', ' swrast',d)}"
>
> >
> > --Mark
> >
> > >>
> > >> After consulting with the author of this recipe, it was clear that it
> > >> was only intended for the X11 use-case, so requring X11 should avoid the
> > >> error message above.
> > >>
> > >> Signed-off-by: Mark Hatle
> > >> ---
> > >> meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 --
> > >> 1 file changed, 4 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> index d4b1c1c454..5674c6b1fe 100644
> > >> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
> > >>
> > >> S = "${WORKDIR}/mesa-${PV}"
> > >>
> > >> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
> > >> 'x11', d)}"
> > >> -PACKAGECONFIG_class-target = "opengl dri
> > >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> > >> +REQUIRED_DISTRO_FEATURE = "x11"
> > >> +
> > >> +PACKAGECONFIG ??= "opengl dri x11"
> > >> +PACKAGECONFIG_class-target = "opengl dri x11"
> > >> --
> > >> 2.17.1
> > >>
> > >>
> > >
> > > --
> > > Regards,
> > > Andrey.
> > >
> > > [1]:
> > > https://github.com/Freescale/meta-freescale/commit/9a2210d9ec707531436dc4b56ce655c0bf50a8a8
> > >
> > >
> >
>
>
> --
> Regards,
> Andrey.
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136707):
https://lists.openembedded.org/g/openembedded-core/message/136707
Mute This Topic: https://lists.openembedded.org/mt/72547327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
On Wed, Mar 25, 2020 at 3:15 PM Mark Hatle wrote: > > Trying to build mesa-gl without X11 enabled, results in numerous errors > about being incorrectly configured, such as: > > ERROR: Problem encountered: building dri drivers require at least one > windowing system or classic osmesa > > After consulting with the author of this recipe, it was clear that it > was only intended for the X11 use-case, so requring X11 should avoid the > error message above. > > Signed-off-by: Mark Hatle This is wrong. We ought to add osmesa as fallback and not hard-require X11 -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136708): https://lists.openembedded.org/g/openembedded-core/message/136708 Mute This Topic: https://lists.openembedded.org/mt/72547327/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] oeqa: default runtime json results for testexport
Set the json result output dir in the oeqe runtime context to create
testresults.json file by default for exported runtime test runs.
Use current datetime for the json result property name (not DATETIME
from build) to allow multiple result entries.
Signed-off-by: Stefan Kral
---
meta/lib/oeqa/core/context.py| 10 ++
meta/lib/oeqa/runtime/context.py | 1 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py
index b9a28ce319..4705d608ac 100644
--- a/meta/lib/oeqa/core/context.py
+++ b/meta/lib/oeqa/core/context.py
@@ -100,24 +100,26 @@ class OETestContextExecutor(object):
name = 'core'
help = 'core test component example'
description = 'executes core test suite example'
+datetime = time.strftime("%Y%m%d%H%M%S")
default_cases = [os.path.join(os.path.abspath(os.path.dirname(__file__)),
'cases/example')]
default_test_data = os.path.join(default_cases[0], 'data.json')
default_tests = None
+default_json_result_dir = None
def register_commands(self, logger, subparsers):
self.parser = subparsers.add_parser(self.name, help=self.help,
description=self.description, group='components')
-self.default_output_log = '%s-results-%s.log' % (self.name,
-time.strftime("%Y%m%d%H%M%S"))
+self.default_output_log = '%s-results-%s.log' % (self.name,
self.datetime)
self.parser.add_argument('--output-log', action='store',
default=self.default_output_log,
help="results output log, default: %s" %
self.default_output_log)
self.parser.add_argument('--json-result-dir', action='store',
-help="json result output dir, create testresults.json here if
set")
+default=self.default_json_result_dir,
+help="json result output dir, default: %s" %
self.default_json_result_dir)
group = self.parser.add_mutually_exclusive_group()
group.add_argument('--run-tests', action='store', nargs='+',
@@ -195,7 +197,7 @@ class OETestContextExecutor(object):
def _get_result_id(self, configuration):
return '%s_%s_%s_%s' % (configuration['TEST_TYPE'],
configuration['IMAGE_BASENAME'],
-configuration['MACHINE'],
configuration['DATETIME'])
+configuration['MACHINE'], self.datetime)
def _pre_run(self):
pass
diff --git a/meta/lib/oeqa/runtime/context.py b/meta/lib/oeqa/runtime/context.py
index 101434a595..3826f27642 100644
--- a/meta/lib/oeqa/runtime/context.py
+++ b/meta/lib/oeqa/runtime/context.py
@@ -47,6 +47,7 @@ class OERuntimeTestContextExecutor(OETestContextExecutor):
default_data = None
default_test_data = 'data/testdata.json'
default_tests = ''
+default_json_result_dir = '%s-results' % name
default_target_type = 'simpleremote'
default_manifest = 'data/manifest'
--
2.17.2 (Apple Git-113)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136709):
https://lists.openembedded.org/g/openembedded-core/message/136709
Mute This Topic: https://lists.openembedded.org/mt/72553650/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [v2 PATCH] mesa-gl: Allow mesa-gl to build without X11 enabled.
Trying to build mesa-gl without X11 enabled, results in numerous errors
about being incorrectly configured, such as:
ERROR: Problem encountered: building dri drivers require at least one
windowing system or classic osmesa
A rendering engine must be available, so per the error we enable osmesa
if X11 is not available. Once 'osmesa' is enabled we also need to make
sure that swrast for DRI is also available.
Signed-off-by: Mark Hatle
---
meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
index d4b1c1c454..c7897cdaf3 100644
--- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
@@ -6,5 +6,10 @@ PROVIDES = "virtual/libgl virtual/mesa"
S = "${WORKDIR}/mesa-${PV}"
-PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
-PACKAGECONFIG_class-target = "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
'x11', d)}"
+# At least one DRI rendering engine is required to build mesa.
+# When no X11 is available, use osmesa for the rendering engine.
+PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'x11', 'osmesa', d)}"
+PACKAGECONFIG_class-target = "opengl dri
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}"
+
+# When NOT using X11, we need to make sure we have swrast available.
+DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
',swrast', d)}"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136711):
https://lists.openembedded.org/g/openembedded-core/message/136711
Mute This Topic: https://lists.openembedded.org/mt/72556698/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] libpng: Fix CVE-2019-6129
This patch has not yet been merged upstream and upstream has disputed the
security impact of this CVE. So I am not sure if we should take this.
https://github.com/glennrp/libpng/issues/269
Has any distro taken this?
Thanks,
Anuj
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Sakib Sajal
> Sent: Tuesday, March 24, 2020 05:51 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v3] libpng: Fix CVE-2019-6129
>
> Fix memory leak in png_create_info_struct.
>
> Upstream-Status: Submitted [https://github.com/glennrp/libpng/pull/293]
> CVE: CVE-2019-6129
>
> Signed-off-by: Sakib Sajal
> ---
> .../libpng/0001-Repair-of-CVE-2019-6129.patch | 28 +++
> .../libpng/libpng_1.6.37.bb | 5 +++-
> 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644
> meta/recipes-
> multimedia/libpng/libpng/0001-Repair-of-CVE-2019-6129.patch
>
> diff --git a/meta/recipes-multimedia/libpng/libpng/0001-Repair-of-CVE-2019-
> 6129.patch b/meta/recipes-multimedia/libpng/libpng/0001-Repair-of-CVE-2019-
> 6129.patch
> new file mode 100644
> index 00..641e771c17
> --- /dev/null
> +++ b/meta/recipes-multimedia/libpng/libpng/0001-Repair-of-CVE-2019-6129
> +++ .patch
> @@ -0,0 +1,28 @@
> +From c8205147753e6684accb73d79f932d0c028fcc80 Mon Sep 17 00:00:00 2001
> +From: tangyaofang
> +Date: Mon, 10 Jun 2019 11:30:15 +0800
> +Subject: [PATCH] Repair of CVE-2019-6129
> +
> +CVE: CVE-2019-6129
> +Upstream-Status: Submitted [https://github.com/glennrp/libpng/pull/293]
> +Signed-off-by: Sakib Sajal
> +---
> + contrib/tools/pngcp.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/contrib/tools/pngcp.c b/contrib/tools/pngcp.c index
> +16d4e7f4d..a02d5b7ff 100644
> +--- a/contrib/tools/pngcp.c
> b/contrib/tools/pngcp.c
> +@@ -506,7 +506,7 @@ static void
> + display_clean_read(struct display *dp) {
> +if (dp->read_pp != NULL)
> +- png_destroy_read_struct(&dp->read_pp, NULL, NULL);
> ++ png_destroy_read_struct(&dp->read_pp, (dp->ip!=NULL ? &dp->ip :
> ++ NULL), NULL);
> +
> +if (dp->fp != NULL)
> +{
> +--
> +2.20.1
> +
> diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.37.bb b/meta/recipes-
> multimedia/libpng/libpng_1.6.37.bb
> index 8c53d11642..f33b942cd7 100644
> --- a/meta/recipes-multimedia/libpng/libpng_1.6.37.bb
> +++ b/meta/recipes-multimedia/libpng/libpng_1.6.37.bb
> @@ -7,7 +7,10 @@ DEPENDS = "zlib"
>
> LIBV = "16"
>
> -SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}${LIBV}/${BP}.tar.xz"
> +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}${LIBV}/${BP}.tar.xz
> \
> + file://0001-Repair-of-CVE-2019-6129.patch \
> + "
> +
> SRC_URI[md5sum] = "015e8e15db1eecde5f2eb9eb5b6e59e9"
> SRC_URI[sha256sum] =
> "505e70834d35383537b6491e7ae8641f1a4bed1876dbfe361201fc80868d88ca"
>
> --
> 2.24.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136712):
https://lists.openembedded.org/g/openembedded-core/message/136712
Mute This Topic: https://lists.openembedded.org/mt/72504278/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] scripts/install-buildtools: add helper script to install buildtools
For distros such as CentOS-7 where the default buildtools are too
old we need to make it easy for users to install a pre-built SDK
with all of "build-essentials" included.
Other uses may include building older Yocto Project releases with
a distro where buildtools are too new.
For convenience, the standard buildtools installation is also
supported.
NOTE: extended buildtools is the default, e.g.
--with-extended-buildtools is on by default
Example usage (extended buildtools from milestone):
(1) using --url and --filename
$ install-buildtools \
--url
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M2/buildtools
\
--filename
x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200122.sh
(2) using --base-url, --release, --installer-version and --build-date
$ install-buildtools \
--base-url http://downloads.yoctoproject.org/releases/yocto \
--release yocto-3.1_M2 \
--install-version 3.0+snapshot
--build-date 202000122
Example usage (standard buildtools from release):
(3) using --url and --filename
$ install-buildtools --without-extended-buildtools \
--url
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.2/buildtools \
--filename x86_64-buildtools-nativesdk-standalone-3.0.2.sh
(4) using --base-url, --release and --installer-version
$ install-buildtools --without-extended-buildtools \
--base-url http://downloads.yoctoproject.org/releases/yocto \
--release yocto-3.0.2 \
--install-version 3.0.2
[YOCTO #13832]
Signed-off-by: Tim Orling
---
scripts/install-buildtools | 270 +
1 file changed, 270 insertions(+)
create mode 100755 scripts/install-buildtools
diff --git a/scripts/install-buildtools b/scripts/install-buildtools
new file mode 100755
index 00..0947e9c4d6
--- /dev/null
+++ b/scripts/install-buildtools
@@ -0,0 +1,270 @@
+#!/usr/bin/env python3
+
+# Buildtools and buildtools extended installer helper script
+#
+# Copyright (C) 2017-2020 Intel Corporation
+#
+# SPDX-License-Identifier: MIT
+#
+# NOTE: --with-extended-buildtools is on by default
+#
+# Example usage (extended buildtools from milestone):
+#(1) using --url and --filename
+#$ install-buildtools \
+# --url
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M2/buildtools
\
+# --filename
x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200122.sh
+#(2) using --base-url, --release, --installer-version and --build-date
+#$ install-buildtools \
+# --base-url http://downloads.yoctoproject.org/releases/yocto \
+# --release yocto-3.1_M2 \
+# --install-version 3.0+snapshot
+# --build-date 202000122
+#
+# Example usage (standard buildtools from release):
+#(3) using --url and --filename
+#$ install-buildtools --without-extended-buildtools \
+# --url
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.2/buildtools \
+# --filename x86_64-buildtools-nativesdk-standalone-3.0.2.sh
+#(4) using --base-url, --release and --installer-version
+#$ install-buildtools --without-extended-buildtools \
+# --base-url http://downloads.yoctoproject.org/releases/yocto \
+# --release yocto-3.0.2 \
+# --install-version 3.0.2
+#
+
+import argparse
+import logging
+import os
+import re
+import shutil
+import stat
+import subprocess
+import sys
+import tempfile
+from urllib.parse import quote
+
+scripts_path = os.path.dirname(os.path.realpath(__file__))
+lib_path = scripts_path + '/lib'
+sys.path = sys.path + [lib_path]
+import scriptutils
+import scriptpath
+
+# Figure out where is the bitbake/lib/bb since we need bb.utils.md5_file
+bitbakepath = scriptpath.add_bitbake_lib_path()
+if not bitbakepath:
+sys.stderr.write("Unable to find bitbake by searching parent directory "
+ "of this script or PATH\n")
+sys.exit(1)
+
+PROGNAME = 'install-buildtools'
+logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
+
+DEFAULT_BASE_URL: str = 'http://downloads.yoctoproject.org/releases/yocto'
+DEFAULT_RELEASE: str = 'yocto-3.1_M2'
+DEFAULT_INSTALLER_VERSION: str = '3.0+snapshot'
+DEFAULT_BUILDDATE: str = "20200122"
+
+
+def main():
+global DEFAULT_BASE_URL
+global DEFAULT_RELEASE
+global DEFAULT_INSTALLER_VERSION
+global DEFAULT_BUILDDATE
+filename: str = ""
+release: str = ""
+buildtools_url: str = ""
+
+parser = argparse.ArgumentParser(
+description="Buildtools installation helper",
+add_help=False)
+parser.add_argument('-u', '--url',
+help='URL from where to fetch buildtools SDK
installer, not '
+ 'including filename (optional)\n'
+ 'Requires --filename.',
+action='store')
+parser.add_argu
[OE-core] [PATCH] vala.bbclass: add libdir to XDG_DATA_DIRS
From: Changqing Li
Otherwise .gir files installed in the sysroot will not be found when
multilib is in use.
for vapigen, it need to find .vapi and .gir files under XDG_DATA_DIRS,
for gobject-introspection, multilib configurations use libdir rather
than datadir
Signed-off-by: Changqing Li
---
meta/classes/vala.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/vala.bbclass b/meta/classes/vala.bbclass
index 615eb37..bcaf68c 100644
--- a/meta/classes/vala.bbclass
+++ b/meta/classes/vala.bbclass
@@ -8,7 +8,7 @@ DEPENDS_append = " vala-native ${VALADEPENDS}"
# Our patched version of Vala looks in STAGING_DATADIR for .vapi files
export STAGING_DATADIR
# Upstream Vala >= 0.11 looks in XDG_DATA_DIRS for .vapi files
-export XDG_DATA_DIRS = "${STAGING_DATADIR}"
+export XDG_DATA_DIRS = "${STAGING_DATADIR}:${STAGING_LIBDIR}"
# Package additional files
FILES_${PN}-dev += "\
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136714):
https://lists.openembedded.org/g/openembedded-core/message/136714
Mute This Topic: https://lists.openembedded.org/mt/72558433/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][zeus][PATCH] glib-2.0: fix CVE-2020-6750
GSocketClient in GNOME GLib through 2.62.4 may occasionally connect directly
to a target address instead of connecting via a proxy server when configured
to do so, because the proxy_addr field is mishandled. This bug is
timing-dependent
and may occur only sporadically depending on network delays. The greatest
security
relevance is in use cases where a proxy is used to help with privacy/anonymity,
even though there is no technical barrier to a direct connection.
Signed-off-by: Haiqing Bai
---
.../glib-2.0/glib-2.0/CVE-2020-6750.patch | 741 ++
meta/recipes-core/glib-2.0/glib-2.0_2.60.7.bb | 1 +
2 files changed, 742 insertions(+)
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-6750.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-6750.patch
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-6750.patch
new file mode 100644
index 00..6db3934978
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-6750.patch
@@ -0,0 +1,741 @@
+From 747f2c646f5a86ac58ad59be08036e81388e971d Mon Sep 17 00:00:00 2001
+From: Patrick Griffis
+Date: Thu, 23 Jan 2020 19:58:41 -0800
+Subject: [PATCH] Refactor g_socket_client_connect_async()
+
+This is a fairly large refactoring. The highlights are:
+
+- Removing in-progress connections/addresses from
GSocketClientAsyncConnectData:
+
+ This caused issues where multiple ConnectionAttempt's would step over
eachother
+ and modify shared state causing bugs like accidentally bypassing a set proxy.
+
+ Fixes #1871
+ Fixes #1989
+ Fixes #1902
+
+- Cancelling address enumeration on error/completion
+
+- Queuing successful TCP connections and doing application layer work serially:
+
+ This is more in the spirit of Happy Eyeballs but it also greatly simplifies
+ the flow of connection handling so fewer tasks are happening in parallel
+ when they don't need to be.
+
+ The behavior also should more closely match that of
g_socket_client_connect().
+
+- Better track the state of address enumeration:
+
+ Previously we were over eager to treat enumeration finishing as an error.
+
+ Fixes #1872
+ See also #1982
+
+- Add more detailed documentation and logging.
+
+Closes #1995
+
+CVE: CVE-2020-6750
+
+Upstream-Status: Backport [ https://gitlab.gnome.org/GNOME/glib.git;
+commit=2722620e3291b930a3a228100d7c0e07b69534e3 ]
+
+Signed-off-by: Haiqing Bai
+---
+ gio/gsocketclient.c | 459
+ 1 file changed, 296 insertions(+), 163 deletions(-)
+
+diff --git a/gio/gsocketclient.c b/gio/gsocketclient.c
+index 81767c0..b1d5f6c 100644
+--- a/gio/gsocketclient.c
b/gio/gsocketclient.c
+@@ -1332,13 +1332,15 @@ typedef struct
+
+ GSocketConnectable *connectable;
+ GSocketAddressEnumerator *enumerator;
+- GProxyAddress *proxy_addr;
+- GSocket *socket;
+- GIOStream *connection;
++ GCancellable *enumeration_cancellable;
+
+ GSList *connection_attempts;
++ GSList *successful_connections;
+ GError *last_error;
+
++ gboolean enumerated_at_least_once;
++ gboolean enumeration_completed;
++ gboolean connection_in_progress;
+ gboolean completed;
+ } GSocketClientAsyncConnectData;
+
+@@ -1350,10 +1352,9 @@ g_socket_client_async_connect_data_free
(GSocketClientAsyncConnectData *data)
+ data->task = NULL;
+ g_clear_object (&data->connectable);
+ g_clear_object (&data->enumerator);
+- g_clear_object (&data->proxy_addr);
+- g_clear_object (&data->socket);
+- g_clear_object (&data->connection);
++ g_clear_object (&data->enumeration_cancellable);
+ g_slist_free_full (data->connection_attempts, connection_attempt_unref);
++ g_slist_free_full (data->successful_connections, connection_attempt_unref);
+
+ g_clear_error (&data->last_error);
+
+@@ -1365,6 +1366,7 @@ typedef struct
+ GSocketAddress *address;
+ GSocket *socket;
+ GIOStream *connection;
++ GProxyAddress *proxy_addr;
+ GSocketClientAsyncConnectData *data; /* unowned */
+ GSource *timeout_source;
+ GCancellable *cancellable;
+@@ -1396,6 +1398,7 @@ connection_attempt_unref (gpointer pointer)
+ g_clear_object (&attempt->socket);
+ g_clear_object (&attempt->connection);
+ g_clear_object (&attempt->cancellable);
++ g_clear_object (&attempt->proxy_addr);
+ if (attempt->timeout_source)
+ {
+ g_source_destroy (attempt->timeout_source);
+@@ -1413,37 +1416,59 @@ connection_attempt_remove (ConnectionAttempt *attempt)
+ }
+
+ static void
+-g_socket_client_async_connect_complete (GSocketClientAsyncConnectData *data)
++cancel_all_attempts (GSocketClientAsyncConnectData *data)
+ {
+- g_assert (data->connection);
++ GSList *l;
+
+- if (!G_IS_SOCKET_CONNECTION (data->connection))
++ for (l = data->connection_attempts; l; l = g_slist_next (l))
+ {
+- GSocketConnection *wrapper_connection;
+-
+- wrapper_connection = g_tcp_wrapper_connection_new (data->connection,
data->socket);
+- g_object_unref (data->connection);
+- data->connec
[OE-core] [PATCH] glibc: Backport patch to fix ifuncs on risc-v and gcc10 builds
ifunc patch is needed to address a glibc ptests failure on riscv
long double double patch is backported to let 2.31 build with gcc10
Signed-off-by: Khem Raj
---
.../0030-Improve-IFUNC-check-BZ-25506.patch | 47 +
...-with-GCC-10-when-long-double-double.patch | 170 ++
meta/recipes-core/glibc/glibc_2.31.bb | 2 +
3 files changed, 219 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
create mode 100644
meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
diff --git
a/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
b/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
new file mode 100644
index 00..1cb398d2bc
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
@@ -0,0 +1,47 @@
+From 87a698a21646b7ee620923ef5ffa9735471a8ddd Mon Sep 17 00:00:00 2001
+From: Fangrui Song
+Date: Tue, 4 Feb 2020 21:55:44 -0800
+Subject: [PATCH] Improve IFUNC check [BZ #25506]
+
+GNU ld's RISCV port does not support IFUNC. ld -no-pie produces no
+relocation and the test passed incorrectly. Be more rigid by testing
+IRELATIVE explicitly.
+
+Upstream-Status: Backport
[https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=87a698a21646b7ee620923ef5ffa9735471a8ddd]
+Tested-by: Aurelien Jarno
+Reviewed-by: Adhemerval Zanella
+Signed-off-by: Khem Raj
+---
+ configure| 2 +-
+ configure.ac | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure b/configure
+index b959d2d988..3b98ec312f 100755
+--- a/configure
b/configure
+@@ -4035,7 +4035,7 @@ if ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS \
+ -o conftest conftest.S 1>&5 2>&5; then
+ # Do a link to see if the backend supports IFUNC relocs.
+ $READELF -r conftest 1>&5
+- LC_ALL=C $READELF -r conftest | grep 'no relocations' >/dev/null || {
++ LC_ALL=C $READELF -Wr conftest | grep -q 'IRELATIVE\|R_SPARC_JMP_IREL' && {
+ libc_cv_ld_gnu_indirect_function=yes
+ }
+ fi
+diff --git a/configure.ac b/configure.ac
+index 49b900c1ed..e20034f301 100644
+--- a/configure.ac
b/configure.ac
+@@ -649,7 +649,7 @@ if ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS \
+ -o conftest conftest.S 1>&AS_MESSAGE_LOG_FD 2>&AS_MESSAGE_LOG_FD;
then
+ # Do a link to see if the backend supports IFUNC relocs.
+ $READELF -r conftest 1>&AS_MESSAGE_LOG_FD
+- LC_ALL=C $READELF -r conftest | grep 'no relocations' >/dev/null || {
++ LC_ALL=C $READELF -Wr conftest | grep -q 'IRELATIVE\|R_SPARC_JMP_IREL' && {
+ libc_cv_ld_gnu_indirect_function=yes
+ }
+ fi
+--
+2.25.1
+
diff --git
a/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
b/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
new file mode 100644
index 00..72622961ad
--- /dev/null
+++
b/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
@@ -0,0 +1,170 @@
+From 49348beafe9ba150c9bd48595b3f372299bddbb0 Mon Sep 17 00:00:00 2001
+From: Joseph Myers
+Date: Tue, 17 Mar 2020 22:57:42 +
+Subject: [PATCH] Fix build with GCC 10 when long double = double.
+
+On platforms where long double has the same ABI as double, glibc
+defines long double functions as aliases for the corresponding double
+functions. The declarations of those functions in are
+disabled to avoid problems with aliases having incompatible types, but
+GCC 10 now gives errors for incompatible types when the long double
+function is known to GCC as a built-in function, not just when there
+is an incompatible header declaration.
+
+This patch fixes those errors by using appropriate
+-fno-builtin- options to compile the double functions. The
+list of CFLAGS-* settings is an appropriately adapted version of that
+in sysdeps/ieee754/ldbl-opt/Makefile used there for building nldbl-*.c
+files; in particular, the options are used even if GCC does not
+currently have a built-in function of a given function, so that adding
+such a built-in function in future will not break the glibc build.
+Thus, various of the CFLAGS-* settings are only for future-proofing
+and may not currently be needed (and it's possible some could be
+irrelevant for other reasons).
+
+Tested with build-many-glibcs.py for arm-linux-gnueabi (compilers and
+glibcs builds), where it fixes the build that previously failed.
+
+Upstream-Status: Backport
[https://sourceware.org/git/?p=glibc.git;a=commit;h=49348beafe9ba150c9bd48595b3f372299bddbb0]
+Signed-off-by: Khem Raj
+
+---
+ math/Makefile | 122 ++
+ 1 file changed, 122 insertions(+)
+
+diff --git a/math/Makefile b/math/Makefile
+index 84a8b94c74..0a5a40430e 100644
+--- a/math/Makefile
b/math/Makefile
+@@ -650,6 +650,128 @@ ifneq ($(long-double-fcts),yes)
+ # We won't compile the `long double' code at all. Tell the `double' code
+ # to define aliase
