date:20221205

2022-12-05 Thread Sandeep Gundlupet Raju via lists.openembedded.org

texrels are generated while compiling on x86/clang because pic/pie flags
that are passed via bitbake do not make it everywhere evenly.
--enable-pie is default way of getting it enabled in bluez5
PIE is enabled by default which ensures that textrels are not generated

Signed-off-by: Khem Raj 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index a8eaba1dd6..976297127d 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -65,6 +65,7 @@ EXTRA_OECONF = "\
   --enable-test \
   --enable-datafiles \
   --enable-library \
+  --enable-pie  \
   --without-zsh-completion-dir \
 "
 
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174314): 
https://lists.openembedded.org/g/openembedded-core/message/174314
Mute This Topic: https://lists.openembedded.org/mt/95488068/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][master,langdale][PATCH] libdrm: Remove libdrm-kms package

I resent the patch and shows up in list now. May be a glitch in 
thunderbird not sure.


On 12/5/2022 6:28 AM, Ross Burton wrote:

It doesn’t look like this patch was ever sent to the list, at least 
https://lists.openembedded.org/g/openembedded-core/search?p=%2C%2C%2C20%2C0%2C0%2C0=libdrm-kms
 doesn’t show it.

Can you post it please?

Ross


On 2 Dec 2022, at 18:24, Sandeep Gundlupet Raju via lists.openembedded.org 
 wrote:

Hi Alex, Richard,

Any updates on reviewing this patch?

Thanks,

Sandeep

On 11/3/2022 2:09 PM, Gundlupet Raju, Sandeep wrote:

Hello,

Any updates on reviewing this patch?

Thanks,

Sandeep

On 10/27/2022 8:17 PM, Sandeep Gundlupet Raju wrote:

libkms library is deprecated in 2.4.111 version. Hence remove
libdrm-kms package.

Signed-off-by: Sandeep Gundlupet Raju 
---
   meta/recipes-graphics/drm/libdrm_2.4.113.bb | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.113.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
index 959ef68032..613d3430ce 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.113.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
@@ -39,7 +39,7 @@ PACKAGECONFIG[manpages] = 
"-Dman-pages=enabled,-Dman-pages=disabled,libxslt-nati
 ALLOW_EMPTY:${PN}-drivers = "1"
   PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap 
\
- ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno ${PN}-amdgpu \
+ ${PN}-intel ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu \
${PN}-etnaviv"
 RRECOMMENDS:${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap 
${PN}-intel \
@@ -52,7 +52,6 @@ FILES:${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
   FILES:${PN}-omap = "${libdir}/libdrm_omap.so.*"
   FILES:${PN}-intel = "${libdir}/libdrm_intel.so.*"
   FILES:${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
-FILES:${PN}-kms = "${libdir}/libkms*.so.*"
   FILES:${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
   FILES:${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.* 
${datadir}/${PN}/amdgpu.ids"
   FILES:${PN}-etnaviv = "${libdir}/libdrm_etnaviv.so.*"




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174313): 
https://lists.openembedded.org/g/openembedded-core/message/174313
Mute This Topic: https://lists.openembedded.org/mt/95412279/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] gstreamer-vaapi: rename USE_X11 variable

Am Mo, 5. Dez 2022 um 22:30:38 + schrieb Richard Purdie 
:

FWIW I do agree with Alex, we can't afford to carry a patch like this
ourselves and we should discuss it with upstream as it is presumably
something they'd want to fix. If they reject it for some reason, that
is a different discussion.


I agree on this point as well. I marked the patch as inappropriate 
because I see some more problems here, such as options that should be 
boolean and are defined as strings, or the uppercase variables in 
general, most of which at least are common enough to possibly cause 
unwanted magic. This patch feels like replacing one hack with another. 
True, there would be something to discuss.

I'd have to be in the right mood for this. At least today I'm not.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174312): 
https://lists.openembedded.org/g/openembedded-core/message/174312
Mute This Topic: https://lists.openembedded.org/mt/95477995/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] Y2038 proposal

2022-12-05 Thread Sandeep Gundlupet Raju via lists.openembedded.org

On Fri, 2022-12-02 at 16:54 +0800, Matt Johnston wrote:
> Your email prompted me to check my own software (Dropbear) and it showed a
> few y2038 issues to fix. Those bugs wouldn't be noticed from a quick test -
> it "only" prevented auth and idle timeouts from occurring.
> 
> gcc and clang are able to flag truncated conversions for 64-bit time_t with 
> -Wconversion, but that's very noisy. Comparing that against a 32-bit time_t
> build, however, gives a pretty clean list of code that needs attention.
> 
> As an experiment I've built OpenBMC with and without 64-bit time_t,
> https://github.com/mkj/yocto-y2038 has the results and a description. There
> are a mix of false positives (particularly tv_usec/tv_nsec), but also some
> real-looking things. As an example, busybox using a uint32_t to copy a dhcpd
> lease expiry.
> 
> I'm not sure the best way to use these logs - they need manual review.
> Expanding the list of packages should be easy, but there will be more that
> need manual intervention to get rid of -Werror.

That is really interesting data as it confirmed there are real world
issues which changing the compiler flags is going to break. Thanks for
sharing.

What you describe is relatively easy for a maintainer to do as a one
off check but not really something we can do at scale for all the
software we build. It worries me :/. I guess the one upside is that
whilst it did break some functionality, it didn't actually crash the
runtime if I understand what happened correctly.

I'm not sure this should stop our plan to switch the flags but it is
certainly something to think about and be aware of.

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174311): 
https://lists.openembedded.org/g/openembedded-core/message/174311
Mute This Topic: https://lists.openembedded.org/mt/95354043/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][langdale][master][PATCH] libdrm: Remove libdrm-kms package

libkms library is deprecated in 2.4.111 version. Hence remove
libdrm-kms package.

Signed-off-by: Sandeep Gundlupet Raju 
---
 meta/recipes-graphics/drm/libdrm_2.4.113.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.113.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
index 959ef68032..613d3430ce 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.113.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
@@ -39,7 +39,7 @@ PACKAGECONFIG[manpages] = 
"-Dman-pages=enabled,-Dman-pages=disabled,libxslt-nati
 
 ALLOW_EMPTY:${PN}-drivers = "1"
 PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap \
- ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno ${PN}-amdgpu \
+ ${PN}-intel ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu \
  ${PN}-etnaviv"
 
 RRECOMMENDS:${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap ${PN}-intel 
\
@@ -52,7 +52,6 @@ FILES:${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
 FILES:${PN}-omap = "${libdir}/libdrm_omap.so.*"
 FILES:${PN}-intel = "${libdir}/libdrm_intel.so.*"
 FILES:${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
-FILES:${PN}-kms = "${libdir}/libkms*.so.*"
 FILES:${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
 FILES:${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.* ${datadir}/${PN}/amdgpu.ids"
 FILES:${PN}-etnaviv = "${libdir}/libdrm_etnaviv.so.*"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174310): 
https://lists.openembedded.org/g/openembedded-core/message/174310
Mute This Topic: https://lists.openembedded.org/mt/95481524/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][master] go: Update reproducibility patch to fix panic errors

On Mon, 2022-12-05 at 13:49 -0600, Ryan Eatmon via
lists.openembedded.org wrote:
> This might have gotten lost in the fun of the YPS and the many 
> discussions around the previous versions of then patch.  Was there any 
> more feedback or changes that folks want me to make for this patch, or 
> is it good to go?  Just curious if there was more that you needed from me?

I've merged it but I am worried there is a deeper problem here we could
really do with solving properly. We should probably at least have an
open bug about resolving the issue the patch addresses in a better way.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174309): 
https://lists.openembedded.org/g/openembedded-core/message/174309
Mute This Topic: https://lists.openembedded.org/mt/95334740/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] gstreamer-vaapi: rename USE_X11 variable

2022-12-05 Thread Alexandre Belloni via lists.openembedded.org

On Mon, 2022-12-05 at 21:13 +0100, Markus Volk wrote:
> Rename USE_X11 to HAVE_X11 to avoid naming conflict with eglplatform.h
> 
> Signed-off-by: Markus Volk 
> ---
>  .../0001-replace-USE_X11-by-HAVE_X11.patch| 319 ++
>  .../gstreamer/gstreamer1.0-vaapi_1.20.4.bb|   9 +-
>  2 files changed, 324 insertions(+), 4 deletions(-)
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> 
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> new file mode 100644
> index 00..8cb17a8a0b
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> @@ -0,0 +1,319 @@
> +From ff9c63505183f7620b68d7d848ad6b16a7497c75 Mon Sep 17 00:00:00 2001
> +From: Markus Volk 
> +Date: Mon, 5 Dec 2022 20:56:43 +0100
> +Subject: [PATCH] replace USE_X11 by HAVE_X11
> +
> +currently used variable collides with eglplatform.h
> +
> +Signed-off-by: Markus Volk 
> +
> +Patch-Status: Inappropriate
> +---
> + ChangeLog|  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay.c |  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay_egl.c |  4 ++--
> + gst-libs/gst/vaapi/meson.build   |  4 ++--
> + gst/vaapi/gstvaapipluginutil.c   | 12 ++--
> + gst/vaapi/gstvaapisink.c |  4 ++--
> + gst/vaapi/gstvaapivideocontext.c |  4 ++--
> + meson.build  | 10 +-
> + tests/examples/meson.build   |  2 +-
> + tests/internal/output.c  |  4 ++--
> + tests/internal/test-display.c|  4 ++--
> + tests/internal/test-windows.c|  4 ++--
> + 12 files changed, 28 insertions(+), 28 deletions(-)
> +

FWIW I do agree with Alex, we can't afford to carry a patch like this
ourselves and we should discuss it with upstream as it is presumably
something they'd want to fix. If they reject it for some reason, that
is a different discussion.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174308): 
https://lists.openembedded.org/g/openembedded-core/message/174308
Mute This Topic: https://lists.openembedded.org/mt/95477995/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] gstreamer-vaapi: rename USE_X11 variable

On 05/12/2022 21:13:30+0100, Markus Volk wrote:
> Rename USE_X11 to HAVE_X11 to avoid naming conflict with eglplatform.h
> 
> Signed-off-by: Markus Volk 
> ---
>  .../0001-replace-USE_X11-by-HAVE_X11.patch| 319 ++
>  .../gstreamer/gstreamer1.0-vaapi_1.20.4.bb|   9 +-
>  2 files changed, 324 insertions(+), 4 deletions(-)
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> 
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> new file mode 100644
> index 00..8cb17a8a0b
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> @@ -0,0 +1,319 @@
> +From ff9c63505183f7620b68d7d848ad6b16a7497c75 Mon Sep 17 00:00:00 2001
> +From: Markus Volk 
> +Date: Mon, 5 Dec 2022 20:56:43 +0100
> +Subject: [PATCH] replace USE_X11 by HAVE_X11
> +
> +currently used variable collides with eglplatform.h
> +
> +Signed-off-by: Markus Volk 
> +
> +Patch-Status: Inappropriate
The proper tag is Upstream-Status. This is checked and the build is
going to fail

> +---
> + ChangeLog|  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay.c |  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay_egl.c |  4 ++--
> + gst-libs/gst/vaapi/meson.build   |  4 ++--
> + gst/vaapi/gstvaapipluginutil.c   | 12 ++--
> + gst/vaapi/gstvaapisink.c |  4 ++--
> + gst/vaapi/gstvaapivideocontext.c |  4 ++--
> + meson.build  | 10 +-
> + tests/examples/meson.build   |  2 +-
> + tests/internal/output.c  |  4 ++--
> + tests/internal/test-display.c|  4 ++--
> + tests/internal/test-windows.c|  4 ++--
> + 12 files changed, 28 insertions(+), 28 deletions(-)
> +
> +diff --git a/ChangeLog b/ChangeLog
> +index 0f769dd..1c54803 100644
> +--- a/ChangeLog
>  b/ChangeLog
> +@@ -5905,7 +5905,7 @@
> + 2019-03-30 18:29:31 +0100  Danilo Spinella 
> + 
> + * gst/vaapi/gstvaapipluginutil.c:
> +-  vaapipluginutil: Fix #endif for USE_X11
> ++  vaapipluginutil: Fix #endif for HAVE_X11
> + 
> + 2019-03-29 18:29:51 +0100  Víctor Manuel Jáquez Leal 
> + 
> +diff --git a/gst-libs/gst/vaapi/gstvaapidisplay.c 
> b/gst-libs/gst/vaapi/gstvaapidisplay.c
> +index 5bf4b13..324330e 100644
> +--- a/gst-libs/gst/vaapi/gstvaapidisplay.c
>  b/gst-libs/gst/vaapi/gstvaapidisplay.c
> +@@ -115,7 +115,7 @@ gst_vaapi_display_type_get_type (void)
> +   static const GEnumValue display_types[] = {
> + {GST_VAAPI_DISPLAY_TYPE_ANY,
> + "Auto detection", "any"},
> +-#if USE_X11
> ++#if HAVE_X11
> + {GST_VAAPI_DISPLAY_TYPE_X11,
> + "VA/X11 display", "x11"},
> + #endif
> +diff --git a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c 
> b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> +index fcffecd..06ac70b 100644
> +--- a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
>  b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> +@@ -28,7 +28,7 @@
> + #include "gstvaapiwindow_priv.h"
> + #include "gstvaapitexture_egl.h"
> + 
> +-#if USE_X11
> ++#if HAVE_X11
> + #include "gstvaapidisplay_x11.h"
> + #endif
> + #if USE_WAYLAND
> +@@ -110,7 +110,7 @@ gst_vaapi_display_egl_bind_display (GstVaapiDisplay * 
> base_display,
> +   native_egl_display = params->gl_display;
> + 
> +   if (!native_vaapi_display) {
> +-#if USE_X11
> ++#if HAVE_X11
> + if (params->display_type == GST_VAAPI_DISPLAY_TYPE_ANY
> + || params->display_type == GST_VAAPI_DISPLAY_TYPE_X11
> + || params->display_type == GST_VAAPI_DISPLAY_TYPE_EGL)
> +diff --git a/gst-libs/gst/vaapi/meson.build b/gst-libs/gst/vaapi/meson.build
> +index 2e15063..26bface 100644
> +--- a/gst-libs/gst/vaapi/meson.build
>  b/gst-libs/gst/vaapi/meson.build
> +@@ -126,7 +126,7 @@ if USE_DRM
> + ]
> + endif
> + 
> +-if USE_X11
> ++if HAVE_X11
> +   gstlibvaapi_sources += [
> +   'gstvaapidisplay_x11.c',
> +   'gstvaapiutils_x11.c',
> +@@ -224,7 +224,7 @@ endif
> + if USE_WAYLAND
> +   gstlibvaapi_deps  += [libva_wayland_dep, gstglwayland_dep, 
> wayland_client_dep, wayland_protocols_dep]
> + endif
> +-if USE_X11
> ++if HAVE_X11
> +   gstlibvaapi_deps  += [libva_x11_dep, x11_dep, xrandr_dep, gstglx11_dep]
> + endif
> + 
> +diff --git a/gst/vaapi/gstvaapipluginutil.c b/gst/vaapi/gstvaapipluginutil.c
> +index 0c47b75..8bc4419 100644
> +--- a/gst/vaapi/gstvaapipluginutil.c
>  b/gst/vaapi/gstvaapipluginutil.c
> +@@ -29,7 +29,7 @@
> + #if USE_DRM
> + # include 
> + #endif
> +-#if USE_X11
> ++#if HAVE_X11
> + # include 
> + #endif
> + #if USE_GLX
> +@@ -80,7 +80,7 @@ static const DisplayMap g_display_map[] = {
> +(GstVaapiDisplayCreateFromHandleFunc)
> +gst_vaapi_display_glx_new_with_display},
> + #endif
> +-#if USE_X11
> ++#if HAVE_X11
> +   {"x11",
> +

Re: [OE-core] [PATCH v3][master] go: Update reproducibility patch to fix panic errors

2022-12-05 Thread Alexandre Belloni via lists.openembedded.org

Hello,

On 05/12/2022 13:49:48-0600, Ryan Eatmon via lists.openembedded.org wrote:
> 
> This might have gotten lost in the fun of the YPS and the many discussions
> around the previous versions of then patch.  Was there any more feedback or
> changes that folks want me to make for this patch, or is it good to go?
> Just curious if there was more that you needed from me?
> 

It passed successfully on the autobuilders, it is now up to Richard to
merge.

> 
> On 11/29/2022 8:12, Ryan Eatmon via lists.openembedded.org wrote:
> > Based on a discussion on the mailing list [1], there are panic
> > errors that occur on a few platforms caused by the patch.  We
> > cannot simply remove the original patch due to the
> > reproducibility issues that it addresses, so this patch on the
> > original patch fixes the cause of the panic errors.
> > 
> > The previous version of this patch was a little too aggressive
> > in cleaning up the environment.  Some of the variables impacted
> > by the filerCompilerFlags() function require at least one value
> > to remain in the array.  In this case, the values for ccExe,
> > cxxExe, and fcExe require a value or later code that access
> > them result in a panic related to accessing a value out of range.
> > 
> > This updated patch adds a flag that requires keeping the first
> > value so that at least one thing remains and the assignments
> > for the Exes set that flag to true.  The first item in the
> > array should be the executable name, so leaving it should be
> > safe.
> > 
> > I have run the oe-selftest and everything passed in my setup.
> > 
> > There is a bug report [2] filed for the issue that this patch
> > addresses.
> > 
> > [YOCTO #14976]
> > 
> > [1] https://lists.openembedded.org/g/openembedded-core/topic/94022663
> > [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976
> > 
> > Signed-off-by: Ryan Eatmon 
> > ---
> > v3: Added [YOCTO #14976] to commit message.
> > v2: Added more background and bug report link to commit message.
> > 
> >   ...ent-based-hash-generation-less-pedan.patch | 30 ++-
> >   1 file changed, 16 insertions(+), 14 deletions(-)
> > 
> > diff --git 
> > a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
> >  
> > b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
> > index 17fa9d9831..43be5cd2e8 100644
> > --- 
> > a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
> > +++ 
> > b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
> > @@ -74,7 +74,7 @@ index c88b315..a06455c 100644
> >   + cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p, 
> > true)
> >   - ccExe := b.ccExe()
> > -+  ccExe := filterCompilerFlags(b.ccExe())
> > ++  ccExe := filterCompilerFlags(b.ccExe(), true)
> > fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags, 
> > ldflags)
> > // Include the C compiler tool ID so that if the C
> > // compiler changes we rebuild the package.
> > @@ -83,7 +83,7 @@ index c88b315..a06455c 100644
> > }
> > if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
> >   - cxxExe := b.cxxExe()
> > -+  cxxExe := filterCompilerFlags(b.cxxExe())
> > ++  cxxExe := filterCompilerFlags(b.cxxExe(), true)
> > fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
> > if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err == 
> > nil {
> > fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
> > @@ -91,7 +91,7 @@ index c88b315..a06455c 100644
> > }
> > if len(p.FFiles) > 0 {
> >   - fcExe := b.fcExe()
> > -+  fcExe := filterCompilerFlags(b.fcExe())
> > ++  fcExe := filterCompilerFlags(b.fcExe(), true)
> > fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
> > if fcID, err := b.gccToolID(fcExe[0], "f95"); err == 
> > nil {
> > fmt.Fprintf(h, "FC ID=%q\n", fcID)
> > @@ -104,20 +104,22 @@ index c88b315..a06455c 100644
> > }
> > // Configuration specific to compiler toolchain.
> > -@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
> > +@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
> > return args
> >}
> >   +var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
> >   +
> > -+func filterCompilerFlags(flags []string) []string {
> > ++func filterCompilerFlags(flags []string, keepfirst bool) []string {
> >   + var newflags []string
> > ++   var realkeepfirst bool = keepfirst
> >   + if !filterFlags {
> >   + return flags
> >   + }
> >   + for _, flag := range flags {
> > -+  if strings.HasPrefix(flag, "-m") {
> > ++  if strings.HasPrefix(flag, "-m") || realkeepfirst {
> >   +

Re: [OE-core][kirkstone][master][PATCH] externalsrc: fix lookup for .gitmodules

2022-12-05 Thread Peter Marko

> There’s been a series of commits now “fixing” the lookup logic, can you write 
> a small test case to exercise this path?
> 
> Ross

Test implemented under 
https://lists.openembedded.org/g/openembedded-core/message/174304.
I did it as a separate patch from this one as it is my first test and it may 
need several iterations to get right.
But if necessary, I'll send a v2 which will be a series of those two patches.

Peter

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174305): 
https://lists.openembedded.org/g/openembedded-core/message/174305
Mute This Topic: https://lists.openembedded.org/mt/95382667/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/selftest/externalsrc: add test for srctree_hash_files

2022-12-05 Thread Peter Marko

Signed-off-by: Peter Marko 
---
 meta/lib/oeqa/selftest/cases/externalsrc.py | 44 +
 1 file changed, 44 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/cases/externalsrc.py

diff --git a/meta/lib/oeqa/selftest/cases/externalsrc.py 
b/meta/lib/oeqa/selftest/cases/externalsrc.py
new file mode 100644
index 00..1d800dc82c
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/externalsrc.py
@@ -0,0 +1,44 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import os
+import shutil
+import tempfile
+
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import get_bb_var, runCmd
+
+class ExternalSrc(OESelftestTestCase):
+# test that srctree_hash_files does not crash
+# we should be actually checking do_compile[file-checksums] but oeqa 
currently does not support it
+# so we check only that a recipe with externalsrc can be parsed
+def test_externalsrc_srctree_hash_files(self):
+test_recipe = "git-submodule-test"
+git_url = "git://git.yoctoproject.org/git-submodule-test"
+externalsrc_dir = 
tempfile.TemporaryDirectory(prefix="externalsrc").name
+
+self.write_config(
+"""
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-%s = "%s"
+""" % (test_recipe, externalsrc_dir)
+)
+
+# test with git without submodules
+runCmd('git clone %s %s' % (git_url, externalsrc_dir))
+os.unlink(externalsrc_dir + "/.gitmodules")
+open(".gitmodules", 'w').close()  # local file .gitmodules in cwd 
should not affect externalsrc parsing
+self.assertEqual(get_bb_var("S", test_recipe), externalsrc_dir, msg = 
"S does not equal to EXTERNALSRC")
+os.unlink(".gitmodules")
+
+# test with git with submodules
+runCmd('git checkout .gitmodules', cwd=externalsrc_dir)
+runCmd('git submodule update --init --recursive', cwd=externalsrc_dir)
+self.assertEqual(get_bb_var("S", test_recipe), externalsrc_dir, msg = 
"S does not equal to EXTERNALSRC")
+
+# test without git
+shutil.rmtree(os.path.join(externalsrc_dir, ".git"))
+self.assertEqual(get_bb_var("S", test_recipe), externalsrc_dir, msg = 
"S does not equal to EXTERNALSRC")
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174304): 
https://lists.openembedded.org/g/openembedded-core/message/174304
Mute This Topic: https://lists.openembedded.org/mt/95479820/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] gstreamer-vaapi: rename USE_X11 variable

This is totally appropriate for upstream submission, please do so.

Alex

On Mon 5. Dec 2022 at 21.13, Markus Volk  wrote:

> Rename USE_X11 to HAVE_X11 to avoid naming conflict with eglplatform.h
>
> Signed-off-by: Markus Volk 
> ---
>  .../0001-replace-USE_X11-by-HAVE_X11.patch| 319 ++
>  .../gstreamer/gstreamer1.0-vaapi_1.20.4.bb|   9 +-
>  2 files changed, 324 insertions(+), 4 deletions(-)
>  create mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
>
> diff --git
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> new file mode 100644
> index 00..8cb17a8a0b
> --- /dev/null
> +++
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
> @@ -0,0 +1,319 @@
> +From ff9c63505183f7620b68d7d848ad6b16a7497c75 Mon Sep 17 00:00:00 2001
> +From: Markus Volk 
> +Date: Mon, 5 Dec 2022 20:56:43 +0100
> +Subject: [PATCH] replace USE_X11 by HAVE_X11
> +
> +currently used variable collides with eglplatform.h
> +
> +Signed-off-by: Markus Volk 
> +
> +Patch-Status: Inappropriate
> +---
> + ChangeLog|  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay.c |  2 +-
> + gst-libs/gst/vaapi/gstvaapidisplay_egl.c |  4 ++--
> + gst-libs/gst/vaapi/meson.build   |  4 ++--
> + gst/vaapi/gstvaapipluginutil.c   | 12 ++--
> + gst/vaapi/gstvaapisink.c |  4 ++--
> + gst/vaapi/gstvaapivideocontext.c |  4 ++--
> + meson.build  | 10 +-
> + tests/examples/meson.build   |  2 +-
> + tests/internal/output.c  |  4 ++--
> + tests/internal/test-display.c|  4 ++--
> + tests/internal/test-windows.c|  4 ++--
> + 12 files changed, 28 insertions(+), 28 deletions(-)
> +
> +diff --git a/ChangeLog b/ChangeLog
> +index 0f769dd..1c54803 100644
> +--- a/ChangeLog
>  b/ChangeLog
> +@@ -5905,7 +5905,7 @@
> + 2019-03-30 18:29:31 +0100  Danilo Spinella 
> +
> +   * gst/vaapi/gstvaapipluginutil.c:
> +-vaapipluginutil: Fix #endif for USE_X11
> ++vaapipluginutil: Fix #endif for HAVE_X11
> +
> + 2019-03-29 18:29:51 +0100  Víctor Manuel Jáquez Leal  >
> +
> +diff --git a/gst-libs/gst/vaapi/gstvaapidisplay.c
> b/gst-libs/gst/vaapi/gstvaapidisplay.c
> +index 5bf4b13..324330e 100644
> +--- a/gst-libs/gst/vaapi/gstvaapidisplay.c
>  b/gst-libs/gst/vaapi/gstvaapidisplay.c
> +@@ -115,7 +115,7 @@ gst_vaapi_display_type_get_type (void)
> +   static const GEnumValue display_types[] = {
> + {GST_VAAPI_DISPLAY_TYPE_ANY,
> + "Auto detection", "any"},
> +-#if USE_X11
> ++#if HAVE_X11
> + {GST_VAAPI_DISPLAY_TYPE_X11,
> + "VA/X11 display", "x11"},
> + #endif
> +diff --git a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> +index fcffecd..06ac70b 100644
> +--- a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
>  b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> +@@ -28,7 +28,7 @@
> + #include "gstvaapiwindow_priv.h"
> + #include "gstvaapitexture_egl.h"
> +
> +-#if USE_X11
> ++#if HAVE_X11
> + #include "gstvaapidisplay_x11.h"
> + #endif
> + #if USE_WAYLAND
> +@@ -110,7 +110,7 @@ gst_vaapi_display_egl_bind_display (GstVaapiDisplay *
> base_display,
> +   native_egl_display = params->gl_display;
> +
> +   if (!native_vaapi_display) {
> +-#if USE_X11
> ++#if HAVE_X11
> + if (params->display_type == GST_VAAPI_DISPLAY_TYPE_ANY
> + || params->display_type == GST_VAAPI_DISPLAY_TYPE_X11
> + || params->display_type == GST_VAAPI_DISPLAY_TYPE_EGL)
> +diff --git a/gst-libs/gst/vaapi/meson.build
> b/gst-libs/gst/vaapi/meson.build
> +index 2e15063..26bface 100644
> +--- a/gst-libs/gst/vaapi/meson.build
>  b/gst-libs/gst/vaapi/meson.build
> +@@ -126,7 +126,7 @@ if USE_DRM
> + ]
> + endif
> +
> +-if USE_X11
> ++if HAVE_X11
> +   gstlibvaapi_sources += [
> +   'gstvaapidisplay_x11.c',
> +   'gstvaapiutils_x11.c',
> +@@ -224,7 +224,7 @@ endif
> + if USE_WAYLAND
> +   gstlibvaapi_deps  += [libva_wayland_dep, gstglwayland_dep,
> wayland_client_dep, wayland_protocols_dep]
> + endif
> +-if USE_X11
> ++if HAVE_X11
> +   gstlibvaapi_deps  += [libva_x11_dep, x11_dep, xrandr_dep, gstglx11_dep]
> + endif
> +
> +diff --git a/gst/vaapi/gstvaapipluginutil.c
> b/gst/vaapi/gstvaapipluginutil.c
> +index 0c47b75..8bc4419 100644
> +--- a/gst/vaapi/gstvaapipluginutil.c
>  b/gst/vaapi/gstvaapipluginutil.c
> +@@ -29,7 +29,7 @@
> + #if USE_DRM
> + # include 
> + #endif
> +-#if USE_X11
> ++#if HAVE_X11
> + # include 
> + #endif
> + #if USE_GLX
> +@@ -80,7 +80,7 @@ static const DisplayMap g_display_map[] = {
> +(GstVaapiDisplayCreateFromHandleFunc)
> +gst_vaapi_display_glx_new_with_display},
> + #endif
> +-#if USE_X11
> ++#if HAVE_X11
> +   {"x11",
> +

[oe-core][PATCH] gstreamer-vaapi: rename USE_X11 variable

2022-12-05 Thread Ryan Eatmon via lists.openembedded.org

Rename USE_X11 to HAVE_X11 to avoid naming conflict with eglplatform.h

Signed-off-by: Markus Volk 
---
 .../0001-replace-USE_X11-by-HAVE_X11.patch| 319 ++
 .../gstreamer/gstreamer1.0-vaapi_1.20.4.bb|   9 +-
 2 files changed, 324 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
new file mode 100644
index 00..8cb17a8a0b
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-replace-USE_X11-by-HAVE_X11.patch
@@ -0,0 +1,319 @@
+From ff9c63505183f7620b68d7d848ad6b16a7497c75 Mon Sep 17 00:00:00 2001
+From: Markus Volk 
+Date: Mon, 5 Dec 2022 20:56:43 +0100
+Subject: [PATCH] replace USE_X11 by HAVE_X11
+
+currently used variable collides with eglplatform.h
+
+Signed-off-by: Markus Volk 
+
+Patch-Status: Inappropriate
+---
+ ChangeLog|  2 +-
+ gst-libs/gst/vaapi/gstvaapidisplay.c |  2 +-
+ gst-libs/gst/vaapi/gstvaapidisplay_egl.c |  4 ++--
+ gst-libs/gst/vaapi/meson.build   |  4 ++--
+ gst/vaapi/gstvaapipluginutil.c   | 12 ++--
+ gst/vaapi/gstvaapisink.c |  4 ++--
+ gst/vaapi/gstvaapivideocontext.c |  4 ++--
+ meson.build  | 10 +-
+ tests/examples/meson.build   |  2 +-
+ tests/internal/output.c  |  4 ++--
+ tests/internal/test-display.c|  4 ++--
+ tests/internal/test-windows.c|  4 ++--
+ 12 files changed, 28 insertions(+), 28 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 0f769dd..1c54803 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -5905,7 +5905,7 @@
+ 2019-03-30 18:29:31 +0100  Danilo Spinella 
+ 
+   * gst/vaapi/gstvaapipluginutil.c:
+-vaapipluginutil: Fix #endif for USE_X11
++vaapipluginutil: Fix #endif for HAVE_X11
+ 
+ 2019-03-29 18:29:51 +0100  Víctor Manuel Jáquez Leal 
+ 
+diff --git a/gst-libs/gst/vaapi/gstvaapidisplay.c 
b/gst-libs/gst/vaapi/gstvaapidisplay.c
+index 5bf4b13..324330e 100644
+--- a/gst-libs/gst/vaapi/gstvaapidisplay.c
 b/gst-libs/gst/vaapi/gstvaapidisplay.c
+@@ -115,7 +115,7 @@ gst_vaapi_display_type_get_type (void)
+   static const GEnumValue display_types[] = {
+ {GST_VAAPI_DISPLAY_TYPE_ANY,
+ "Auto detection", "any"},
+-#if USE_X11
++#if HAVE_X11
+ {GST_VAAPI_DISPLAY_TYPE_X11,
+ "VA/X11 display", "x11"},
+ #endif
+diff --git a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c 
b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
+index fcffecd..06ac70b 100644
+--- a/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
 b/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
+@@ -28,7 +28,7 @@
+ #include "gstvaapiwindow_priv.h"
+ #include "gstvaapitexture_egl.h"
+ 
+-#if USE_X11
++#if HAVE_X11
+ #include "gstvaapidisplay_x11.h"
+ #endif
+ #if USE_WAYLAND
+@@ -110,7 +110,7 @@ gst_vaapi_display_egl_bind_display (GstVaapiDisplay * 
base_display,
+   native_egl_display = params->gl_display;
+ 
+   if (!native_vaapi_display) {
+-#if USE_X11
++#if HAVE_X11
+ if (params->display_type == GST_VAAPI_DISPLAY_TYPE_ANY
+ || params->display_type == GST_VAAPI_DISPLAY_TYPE_X11
+ || params->display_type == GST_VAAPI_DISPLAY_TYPE_EGL)
+diff --git a/gst-libs/gst/vaapi/meson.build b/gst-libs/gst/vaapi/meson.build
+index 2e15063..26bface 100644
+--- a/gst-libs/gst/vaapi/meson.build
 b/gst-libs/gst/vaapi/meson.build
+@@ -126,7 +126,7 @@ if USE_DRM
+ ]
+ endif
+ 
+-if USE_X11
++if HAVE_X11
+   gstlibvaapi_sources += [
+   'gstvaapidisplay_x11.c',
+   'gstvaapiutils_x11.c',
+@@ -224,7 +224,7 @@ endif
+ if USE_WAYLAND
+   gstlibvaapi_deps  += [libva_wayland_dep, gstglwayland_dep, 
wayland_client_dep, wayland_protocols_dep]
+ endif
+-if USE_X11
++if HAVE_X11
+   gstlibvaapi_deps  += [libva_x11_dep, x11_dep, xrandr_dep, gstglx11_dep]
+ endif
+ 
+diff --git a/gst/vaapi/gstvaapipluginutil.c b/gst/vaapi/gstvaapipluginutil.c
+index 0c47b75..8bc4419 100644
+--- a/gst/vaapi/gstvaapipluginutil.c
 b/gst/vaapi/gstvaapipluginutil.c
+@@ -29,7 +29,7 @@
+ #if USE_DRM
+ # include 
+ #endif
+-#if USE_X11
++#if HAVE_X11
+ # include 
+ #endif
+ #if USE_GLX
+@@ -80,7 +80,7 @@ static const DisplayMap g_display_map[] = {
+(GstVaapiDisplayCreateFromHandleFunc)
+gst_vaapi_display_glx_new_with_display},
+ #endif
+-#if USE_X11
++#if HAVE_X11
+   {"x11",
+GST_VAAPI_DISPLAY_TYPE_X11,
+gst_vaapi_display_x11_new,
+@@ -140,7 +140,7 @@ gst_vaapi_get_display_type_from_gl (GstGLDisplayType 
gl_display_type,
+ GstGLPlatform gl_platform)
+ {
+   switch (gl_display_type) {
+-#if USE_X11
++#if HAVE_X11
+ case GST_GL_DISPLAY_TYPE_X11:{
+ #if USE_GLX
+   if (gl_platform == GST_GL_PLATFORM_GLX)
+@@ -178,7 +178,7 @@

Re: [OE-core] [PATCH v3][master] go: Update reproducibility patch to fix panic errors



This might have gotten lost in the fun of the YPS and the many 
discussions around the previous versions of then patch.  Was there any 
more feedback or changes that folks want me to make for this patch, or 
is it good to go?  Just curious if there was more that you needed from me?



On 11/29/2022 8:12, Ryan Eatmon via lists.openembedded.org wrote:

Based on a discussion on the mailing list [1], there are panic
errors that occur on a few platforms caused by the patch.  We
cannot simply remove the original patch due to the
reproducibility issues that it addresses, so this patch on the
original patch fixes the cause of the panic errors.

The previous version of this patch was a little too aggressive
in cleaning up the environment.  Some of the variables impacted
by the filerCompilerFlags() function require at least one value
to remain in the array.  In this case, the values for ccExe,
cxxExe, and fcExe require a value or later code that access
them result in a panic related to accessing a value out of range.

This updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true.  The first item in the
array should be the executable name, so leaving it should be
safe.

I have run the oe-selftest and everything passed in my setup.

There is a bug report [2] filed for the issue that this patch
addresses.

[YOCTO #14976]

[1] https://lists.openembedded.org/g/openembedded-core/topic/94022663
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976

Signed-off-by: Ryan Eatmon 
---
v3: Added [YOCTO #14976] to commit message.
v2: Added more background and bug report link to commit message.

  ...ent-based-hash-generation-less-pedan.patch | 30 ++-
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git 
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
 
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
--- 
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++ 
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
  + cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p, 
true)
   
  -		ccExe := b.ccExe()

-+  ccExe := filterCompilerFlags(b.ccExe())
++  ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags, 
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
  - cxxExe := b.cxxExe()
-+  cxxExe := filterCompilerFlags(b.cxxExe())
++  cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err == 
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
  - fcExe := b.fcExe()
-+  fcExe := filterCompilerFlags(b.fcExe())
++  fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err == 
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
   
   	// Configuration specific to compiler toolchain.

-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
   }
   
  +var filterFlags = os.Getenv("CGO_PEDANTIC") == ""

  +
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
  + var newflags []string
++   var realkeepfirst bool = keepfirst
  + if !filterFlags {
  + return flags
  + }
  + for _, flag := range flags {
-+  if strings.HasPrefix(flag, "-m") {
++  if strings.HasPrefix(flag, "-m") || realkeepfirst {
  + newflags = append(newflags, flag)
++   realkeepfirst = false
  + }
  + }
  + return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
   
   	if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS, checkCompilerFlags); err != nil {

-@@ -2724,6 +2741,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags, 
cflags, cxxflags, fflags, l
+@@ -2724,6

[OE-core][hardknott][PATCH] binutils-cross-canadian: Add lib*.a files to the staticdev package

2022-12-05 Thread Shruthi Ravichandran

This fixes the following QA issue when building an SDK for
x86_64-mingw32 machines.

ERROR: binutils-cross-canadian-x86-64-2.36.1-r0 do_package_qa: QA Issue: non 
-staticdev package contains static .a library: binutils-cross-canadian-x86-64 
path 
'/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-w64-mingw32/usr/lib/x86_64-nilrt-linux/bfd-plugins/libdep.dll.a'
 [staticdev]

Signed-off-by: Shruthi Ravichandran 
---
 meta/recipes-devtools/binutils/binutils-cross-canadian.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc 
b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
index e98f31f9c3..c38936db42 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
@@ -30,3 +30,5 @@ do_install () {
 }
 
 BBCLASSEXTEND = ""
+
+FILES_${PN}-staticdev:append = " ${libdir}/bfd-plugins/lib*.a"
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174300): 
https://lists.openembedded.org/g/openembedded-core/message/174300
Mute This Topic: https://lists.openembedded.org/mt/95476990/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: update 22.2.3 -> 22.3.0

Am Mo, 5. Dez 2022 um 20:17:53 +0100 schrieb Alexander Kanavin 
:

We don't use the monorepo, we use source tarballs and in them vaapi
continues to be provided separately:


I see. Their meson.build is quite broken :(


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174299): 
https://lists.openembedded.org/g/openembedded-core/message/174299
Mute This Topic: https://lists.openembedded.org/mt/95388063/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: update 22.2.3 -> 22.3.0

We don't use the monorepo, we use source tarballs and in them vaapi
continues to be provided separately:
https://gstreamer.freedesktop.org/src/gstreamer-vaapi/

Alex

On Mon, 5 Dec 2022 at 20:04, Markus Volk  wrote:
>
> Wouldn't it be best if we just removed the gstreamer-1.0-vaapi recipe. Gitlab 
> repo says:
>
> ARCHIVED REPOSITORY: Hardware-accelerated video decoding, encoding and 
> processing on Intel graphics through VA-API
>
> This code has been moved to the GStreamer mono repo, please submit new issues 
> and merge requests there!
>
> Like I understand it, the code has been merged into gstreamer1.0 and can be 
> enabled by
>
> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/meson_options.txt#L13
>
>
> Am Mo, 5. Dez 2022 um 09:23:21 -0800 schrieb Khem Raj :
>
> On Mon, Dec 5, 2022 at 6:32 AM Alexandre Belloni via lists.openembedded.org 
>  wrote:
>
> Hello, This caused: | FAILED: 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o | 
> x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse 
> -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security 
> --sysroot=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot
>  -Igst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p -Igst-libs/gst/vaapi 
> -I../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi -I. 
> -I../gstreamer-vaapi-1.20.4 -Igst-libs -I../gstreamer-vaapi-1.20.4/gst-libs 
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/gstreamer-1.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/glib-2.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/glib-2.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/orc-0.4
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/gstreamer-1.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/libdrm
>  -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
> -fvisibility=hidden -fno-strict-aliasing -O2 -pipe -g 
> -feliminate-unused-debug-types 
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot-native=
>  -fPIC -pthread -DHAVE_CONFIG_H -DGST_USE_UNSTABLE_API 
> '-DGST_VAAPI_VERSION_ID="1.20.4"' -MD -MQ 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -MF 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o.d -o 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -c 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c | In file 
> included from 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
>  | from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.h:26, | from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c:24: | 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10:
>  fatal error: X11/Xlib.h: No such file or directory | 109 | #include 
>  | | ^~~~
>
> for no-x11 builds gstreamer1.0-vaapi needs to pass -UUSE_X11 maybe, the code 
> where we were tweaking. 
> https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/mesa/mesa.inc#n38
>  is removed from upstream.
>
> |

Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0

On Mon, Dec 5, 2022 at 11:04 AM Markus Volk  wrote:
>
> Wouldn't it be best if we just removed the gstreamer-1.0-vaapi recipe. Gitlab 
> repo says:
>
> ARCHIVED REPOSITORY: Hardware-accelerated video decoding, encoding and 
> processing on Intel graphics through VA-API
>
> This code has been moved to the GStreamer mono repo, please submit new issues 
> and merge requests there!
>
> Like I understand it, the code has been merged into gstreamer1.0 and can be 
> enabled by
>
> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/meson_options.txt#L13
>

yes I think that would be preferred.

>
> Am Mo, 5. Dez 2022 um 09:23:21 -0800 schrieb Khem Raj :
>
> On Mon, Dec 5, 2022 at 6:32 AM Alexandre Belloni via lists.openembedded.org 
>  wrote:
>
> Hello, This caused: | FAILED: 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o | 
> x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse 
> -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security 
> --sysroot=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot
>  -Igst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p -Igst-libs/gst/vaapi 
> -I../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi -I. 
> -I../gstreamer-vaapi-1.20.4 -Igst-libs -I../gstreamer-vaapi-1.20.4/gst-libs 
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/gstreamer-1.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/glib-2.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/glib-2.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/orc-0.4
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/gstreamer-1.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/libdrm
>  -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
> -fvisibility=hidden -fno-strict-aliasing -O2 -pipe -g 
> -feliminate-unused-debug-types 
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot-native=
>  -fPIC -pthread -DHAVE_CONFIG_H -DGST_USE_UNSTABLE_API 
> '-DGST_VAAPI_VERSION_ID="1.20.4"' -MD -MQ 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -MF 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o.d -o 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -c 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c | In file 
> included from 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
>  | from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.h:26, | from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c:24: | 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10:
>  fatal error: X11/Xlib.h: No such file or directory | 109 | #include 
>  | | ^~~~
>
> for no-x11 builds gstreamer1.0-vaapi needs to pass -UUSE_X11 maybe, the code 
> where we were tweaking. 
> https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/mesa/mesa.inc#n38
>  is removed from upstream.
>
> | compilation terminated. | ninja: build stopped: subcommand failed. | 
> WARNING: 
>

Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0

Wouldn't it be best if we just removed the gstreamer-1.0-vaapi recipe. 
Gitlab repo says:


*ARCHIVED REPOSITORY*: Hardware-accelerated video decoding, encoding 
and processing on Intel graphics through VA-API


*This code has been moved to the GStreamer mono repo 
, please submit new 
issues and merge requests there!*


Like I understand it, the code has been merged into gstreamer1.0 and 
can be enabled by





Am Mo, 5. Dez 2022 um 09:23:21 -0800 schrieb Khem Raj 
:

On Mon, Dec 5, 2022 at 6:32 AM Alexandre Belloni via
lists.openembedded.org
> wrote:


 Hello,

 This caused:

 | FAILED: 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o
 | x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 
-mfpmath=sse -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 
-Wformat -Wformat-security -Werror=format-security 
--sysroot=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot 
-Igst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p -Igst-libs/gst/vaapi 
-I../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi -I. 
-I../gstreamer-vaapi-1.20.4 -Igst-libs 
-I../gstreamer-vaapi-1.20.4/gst-libs 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/gstreamer-1.0 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/glib-2.0 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/glib-2.0/include 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/orc-0.4 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/gstreamer-1.0/include 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/libdrm 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
-Winvalid-pch -fvisibility=hidden -fno-strict-aliasing -O2 -pipe -g 
-feliminate-unused-debug-types 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot= 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot= 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot-native= 
-fPIC -pthread -DHAVE_CONFIG_H -DGST_USE_UNSTABLE_API 
'-DGST_VAAPI_VERSION_ID="1.20.4"' -MD -MQ 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o 
-MF 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o.d 
-o gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o 
-c ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
 | In file included from 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
 |  from 
../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.h:26,
 |  from 
../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c:24:
 | 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10: 
fatal error: X11/Xlib.h: No such file or directory

 |   109 | #include 
 |   |  ^~~~


for no-x11 builds gstreamer1.0-vaapi needs to pass -UUSE_X11 maybe,
the code where we were tweaking.



is removed from upstream.


 | compilation terminated.
 | ninja: build stopped: subcommand failed.
 | WARNING:

Re: [OE-core] GCC Patch Tracking

On Mon, Dec 5, 2022 at 5:48 AM Randy MacLeod
 wrote:
>
> Let's keep the discussion on the list to give everyone a chance to know 
> what's going on and to contribute.
> Oh and please use in-line email instead of attachments when possible.
>
> Also add Khem who is the author of many of these patches. Hopefully he can
> help us clean-up the status and advise about which 'Pending' patches are
> candidates to send upstream.
>
> On 2022-12-05 08:06, Shinde, Yash wrote:
>
> Hi Richard,
>
> PFA  document for GCC patch analysis. There were about 28 patches in GCC 
> sources out of which 3 patches are with the upstream status of ‘Submitted’ 
> and other 10 are ‘Pending’.  I had analysed the current status of these 
> patches by checking them with the GCC patch list and archive list and 
> documented the same in the attached document.
>
> Out of the 3 patches with ‘submitted’ as the status,
>
> - The 1st patch is submitted but changes are not reflected in the upstream. 
> (hardcoded-paths.patch)
>
> - The 2nd patch is not found in the upstream 
> (0014-Don-t-search-host-directory-during-relink-if-inst_pr.patch), was not 
> found in patch list or archive list and
>
> - For the 3rd patch 1 hunk taken to upstream and can be marked as 
> 'backported' and the other hunk is not taken to upstream yet. 
> (prefix-map-realpath.patch)

Did you check upstream master branch of gcc ?

>
> All the patch links are given in the doc.
>
>
> GCC 12.2 Patch Analysis
>
> hardcoded-paths.patch:Upstream-Status: Submitted 
> [https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html]
> ->Patch is submitted but changes not reflected in upstream
>
>
>
> 0014-Don-t-search-host-directory-during-relink-if-inst_pr.patch:Upstream-Status:
>  Submitted
> ->not yet submitted to upstream but link provided here- 
> http://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html
>
> prefix-map-realpath.patch:Upstream-Status: Submitted 
> [https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599885.html]
> ->1 of the 2 hunks of patch send to upstream and other is not included. Link- 
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg294480.html
>
> 0013-Ensure-target-gcc-headers-can-be-included.patch:Upstream-Status: Pending
> ->not yet submitted to upstream
>
> 0005-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch:Upstream-Status:
>  Pending
> ->not yet submitted to upstream
>
> 0004-Pass-CXXFLAGS_FOR_BUILD-in-a-couple-of-places-to-avo.patch:Upstream-Status:
>  Pending [should be submittable]
> ->not yet submitted to upstream
>
> 0002-gcc-poison-system-directories.patch:Upstream-Status: Pending
> ->not yet submitted to upstream
>
> 0009-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch:Upstream-Status: 
> Pending
> ->not yet submitted to upstream
>
> 0017-Search-target-sysroot-gcc-version-specific-dirs-with.patch:Upstream-Status:
>  Pending
> ->not yet submitted to upstream
>
> 0008-libtool.patch:Upstream-Status: Pending
> ->not yet submitted to upstream
>
> 0020-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch:Upstream-Status:
>  Pending
> ->not yet submitted to upstream
>
> 0018-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch:Upstream-Status:
>  Pending
> ->not yet submitted to upstream
>
> 0006-cpp-honor-sysroot.patch:Upstream-Status: Pending
> ->not yet submitted to upstream
>
>
>
>
> For the patches with ‘pending’ as the status, they are pending from quite 
> some time. Should we contact the author of the patch or the community for 
> these patches?
>
> Please guide me on how to proceed further in GCC patch analysis and what are 
> the next steps.
>
> Let's see what Khem has to say about his collection of 'Pending' patches.
>
>
> Thanks Yash,
>
> ../Randy
>
>
> Regards,
> Yash Shinde
>
>
>
>
>
>
> --
> # Randy MacLeod
> # Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174295): 
https://lists.openembedded.org/g/openembedded-core/message/174295
Mute This Topic: https://lists.openembedded.org/mt/95468728/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: update 22.2.3 -> 22.3.0

2022-12-05 Thread Alexandre Belloni via lists.openembedded.org

On Mon, Dec 5, 2022 at 6:32 AM Alexandre Belloni via
lists.openembedded.org
 wrote:
>
> Hello,
>
> This caused:
>
> | FAILED: gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o
> | x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse 
> -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security 
> --sysroot=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot
>  -Igst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p -Igst-libs/gst/vaapi 
> -I../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi -I. 
> -I../gstreamer-vaapi-1.20.4 -Igst-libs -I../gstreamer-vaapi-1.20.4/gst-libs 
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/gstreamer-1.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/glib-2.0
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/glib-2.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/orc-0.4
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/gstreamer-1.0/include
>  
> -I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/libdrm
>  -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
> -fvisibility=hidden -fno-strict-aliasing -O2 -pipe -g 
> -feliminate-unused-debug-types 
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot-native=
>  -fPIC -pthread -DHAVE_CONFIG_H -DGST_USE_UNSTABLE_API 
> '-DGST_VAAPI_VERSION_ID="1.20.4"' -MD -MQ 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -MF 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o.d -o 
> gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -c 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
> | In file included from 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
> |  from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.h:26,
> |  from 
> ../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c:24:
> | 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10:
>  fatal error: X11/Xlib.h: No such file or directory
> |   109 | #include 
> |   |  ^~~~

for no-x11 builds gstreamer1.0-vaapi needs to pass -UUSE_X11 maybe,
the code where we were tweaking.

https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/mesa/mesa.inc#n38

is removed from upstream.

> | compilation terminated.
> | ninja: build stopped: subcommand failed.
> | WARNING: 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472:153
>  exit 1 from 'ninja -v -j 16 -l 52'
> | WARNING: Backtrace (BB generated script):
> |   #1: meson_do_compile, 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472,
>  line 153
> |   #2: do_compile, 
> /home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472,
>  line 148
> |   #3: main, 
>

Re: [OE-core] GCC Patch Tracking

2022-12-05 Thread Randy MacLeod

Add the list and Khem in case anyone is interested in Richard's comments
below.

../Randy

On 2022-12-05 08:47, Richard Purdie wrote:

Hi Yash,

On Mon, 2022-12-05 at 13:06 +, Shinde, Yash wrote:

PFA document for GCC patch analysis. There were about 28 patches in
GCC sources out of which 3 patches are with the upstream status of
‘Submitted’ and other 10 are ‘Pending’. I had analysed the current
status of these patches by checking them with the GCC patch list and
archive list and documented the same in the attached document.

Out of the 3 patches with ‘submitted’ as the status,
- The 1st patch is submitted but changes are not reflected in the
upstream. (hardcoded-paths.patch)

We should remind them about this one.

- The 2nd patch is not found in the upstream (0014-Don-t-search-host-
directory-during-relink-if-inst_pr.patch), was not found in patch
list or archive list and

This one is tricky since it is a libtool change. Was the change
accepted by libtool? If it was, we might be able to then persuade gcc
that they need it. It would mean updating gcc's libtool and I don't
know how they do that though.

- For the 3rd patch 1 hunk taken to upstream and can be marked as
'backported' and the other hunk is not taken to upstream yet.
(prefix-map-realpath.patch)
All the patch links are given in the doc.

I thought both pieces of this had merged?

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=11543b27fe16d81ca5483ecb98ec7a5b2426e0c0
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e5c15eb183f17e806ad6b58c9497321ded87866f

We should update the patch to mention it is now a Backport with those
two links?

For the patches with ‘pending’ as the status, they are pending from
quite some time. Should we contact the author of the patch or the
community for these patches?

Please guide me on how to proceed further in GCC patch analysis and
what are the next steps.

For the Pending patches I'll add my comments below.

0013-Ensure-target-gcc-headers-can-be-included.patch

These headers are being installed under a prefix in the sysroot. We
need to check if that prefix is as a result of our own changes or
something upstream does. If upsptream uses the prefix, we should talk
to them about whether we can expect sysroot layout like this to work.

0005-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch
-

I suspect this is inappropriate for upstream and should be marked as such.

0004-Pass-CXXFLAGS_FOR_BUILD-in-a-couple-of-places-to-avo.patch
---

Looks like it could be submitted/discussed upstream

0002-gcc-poison-system-directories.patch

Mark inappropriate?

0009-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch

Looks like it could be submitted/discussed upstream

0017-Search-target-sysroot-gcc-version-specific-dirs-with.patch
---

Looks like it should be discussed upstream?

0008-libtool.patch
--

Would probably need to go to libtool first.

0020-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch
---

Check whether we still need it? (i686 musl?)

0018-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch
---

Check whether we still need it? (musl related?)

0006-cpp-honor-sysroot.patch

reproduce original issue, if still present submit upsteam, or drop

So in summary, there are a few issues we probably reproduce and discuss
with upstream.

Cheers,

Richard

--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174293):
https://lists.openembedded.org/g/openembedded-core/message/174293
Mute This Topic: https://lists.openembedded.org/mt/95468728/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] lib/buildstats: fix parsing of trees with reduced_proc_pressure directories

2022-12-05 Thread Ross Burton

The /proc/pressure support in buildstats is creating directories in the
buildstats tree called reduced_proc_pressure, which confuses the parsing
logic as that cannot be parsed as a name-epoc-version-revision tuple.

Explicitly skip this directory to solve the problem.

Signed-off-by: Ross Burton 
---
 scripts/lib/buildstats.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/buildstats.py b/scripts/lib/buildstats.py
index c69b5bf4d75..3b76286ba57 100644
--- a/scripts/lib/buildstats.py
+++ b/scripts/lib/buildstats.py
@@ -8,7 +8,7 @@ import json
 import logging
 import os
 import re
-from collections import namedtuple,OrderedDict
+from collections import namedtuple
 from statistics import mean
 
 
@@ -238,7 +238,7 @@ class BuildStats(dict):
 subdirs = os.listdir(path)
 for dirname in subdirs:
 recipe_dir = os.path.join(path, dirname)
-if not os.path.isdir(recipe_dir):
+if dirname == "reduced_proc_pressure" or not 
os.path.isdir(recipe_dir):
 continue
 name, epoch, version, revision = cls.split_nevr(dirname)
 bsrecipe = BSRecipe(name, epoch, version, revision)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174292): 
https://lists.openembedded.org/g/openembedded-core/message/174292
Mute This Topic: https://lists.openembedded.org/mt/95470205/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] kernel.bbclass: remove empty module directories to prevent QA issues

2022-12-05 Thread Ovidiu Panait

From: Ovidiu Panait 

Currently, allyesconfig test runs for x86_64 fail with:
ERROR: linux-yocto-5.19.17+gitAUTOINC+0cba9aa404_aaf4490d18-r0 do_package:
QA Issue: linux-yocto: Files/directories were installed but not shipped in any
package:
  /lib/modules/5.19.17/kernel/drivers/nvdimm

With CONFIG_NVDIMM_TEST_BUILD=m, an empty nvdimm directory is created during
modules_install, which triggers the QA issue.

Extend kernel_do_install() to also remove inner empty directories that might
get created by modules_install.

Signed-off-by: Ovidiu Panait 
---
 meta/classes-recipe/kernel.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index 3f6b40907f..553e17bb4e 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -450,8 +450,8 @@ kernel_do_install() {
oe_runmake DEPMOD=echo 
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
-   # If the kernel/ directory is empty remove it to prevent QA 
issues
-   rmdir --ignore-fail-on-non-empty 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel"
+   # Remove empty module directories to prevent QA issues
+   find 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
-delete
else
bbnote "no modules to install"
fi
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174291): 
https://lists.openembedded.org/g/openembedded-core/message/174291
Mute This Topic: https://lists.openembedded.org/mt/95470162/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] [dunfell][PATCHv2] xserver-xorg: backport fixes for CVE-2022-3550, CVE-2022-3551 and CVE-2022-3553

2022-12-05 Thread Steve Sakoman

On Sun, Dec 4, 2022 at 8:40 AM Minjae Kim  wrote:
>
> 
> xkb: proof GetCountedString against request length attacks
> Upstream-Status: Backport 
> [https://cgit.freedesktop.org/xorg/xserver/commit/?id=11beef0b7f1ed290348e45618e5fa0d2bffcb72e]
>
> 
> xkb: fix some possible memleaks in XkbGetKbdByName
> Upstream-Status: Backport 
> [https://cgit.freedesktop.org/xorg/xserver/commit/?id=18f91b950e22c2a342a4fbc55e9ddf7534a707d2]
>
> 
> xquartz: Fix a possible crash when editing the Application
> menu due to mutaing immutable arrays
> Upstream-Status: 
> Backport[https://cgit.freedesktop.org/xorg/xserver/commit/?id=dfd057996b26420309c324ec844a5ba6dd07eda3]
>
> Signed-off-by:Minjae Kim 
> ---
>  .../xserver-xorg/CVE-2022-3550.patch  | 40 
>  .../xserver-xorg/CVE-2022-3551.patch  | 64 +++
>  .../xserver-xorg/CVE-2022-3553.patch  | 49 ++
>  .../xorg-xserver/xserver-xorg_1.20.14.bb  |  3 +
>  4 files changed, 156 insertions(+)
>  create mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3550.patch
>  create mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3551.patch
>  create mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3553.patch
>
> diff --git 
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3550.patch 
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3550.patch
> new file mode 100644
> index 00..9674b548d9
> --- /dev/null
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3550.patch
> @@ -0,0 +1,40 @@
> +From d2dcbdc67c96c84dff301505072b0b7b022f1a14 Mon Sep 17 00:00:00 2001
> +From: Peter Hutterer 
> +Date: Sun, 4 Dec 2022 17:40:21 +
> +Subject: [PATCH 1/3] xkb: proof GetCountedString against request length
> + attacks
> +
> +GetCountedString did a check for the whole string to be within the
> +request buffer but not for the initial 2 bytes that contain the length
> +field. A swapped client could send a malformed request to trigger a
> +swaps() on those bytes, writing into random memory.
> +
> +Signed-off-by: Peter Hutterer 
> +
> +Ustream-Status: Backport
> +[https://cgit.freedesktop.org/xorg/xserver/commit/?id=11beef0b7f1ed290348e45618e5fa0d2bffcb72e]

The above line can go on the same line as Upstream-Status (same
comment for the other two patches)

> +Signed-off-by:Minjae Kim 

MIssing CVE: tag

I'll fix these issues, so no need for V3, but please keep in mind for
future submissions.

Thanks for helping with CVE reduction!

Steve

> +---
> + xkb/xkb.c | 5 +
> + 1 file changed, 5 insertions(+)
> +
> +diff --git a/xkb/xkb.c b/xkb/xkb.c
> +index 68c59df..bf8aaa3 100644
> +--- a/xkb/xkb.c
>  b/xkb/xkb.c
> +@@ -5138,6 +5138,11 @@ _GetCountedString(char **wire_inout, ClientPtr 
> client, char **str)
> + CARD16 len;
> +
> + wire = *wire_inout;
> ++
> ++if (client->req_len <
> ++bytes_to_int32(wire + 2 - (char *) client->requestBuffer))
> ++  return BadValue;
> ++
> + len = *(CARD16 *) wire;
> + if (client->swapped) {
> + swaps();
> +--
> +2.17.1
> +
> diff --git 
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3551.patch 
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3551.patch
> new file mode 100644
> index 00..c1313b5ad6
> --- /dev/null
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-3551.patch
> @@ -0,0 +1,64 @@
> +From d3787290f56165f5656ddd2123dbf676a32d0a68 Mon Sep 17 00:00:00 2001
> +From: Peter Hutterer 
> +Date: Sun, 4 Dec 2022 17:44:00 +
> +Subject: [PATCH 2/3] xkb: fix some possible memleaks in XkbGetKbdByName
> +
> +GetComponentByName returns an allocated string, so let's free that if we
> +fail somewhere.
> +
> +Signed-off-by: Peter Hutterer 
> +
> +Upstream-Status: Backport
> +[https://cgit.freedesktop.org/xorg/xserver/commit/?id=18f91b950e22c2a342a4fbc55e9ddf7534a707d2]
> +
> +Signed-off-by:Minjae Kim 
> +---
> + xkb/xkb.c | 26 +++---
> + 1 file changed, 19 insertions(+), 7 deletions(-)
> +
> +diff --git a/xkb/xkb.c b/xkb/xkb.c
> +index bf8aaa3..f79d306 100644
> +--- a/xkb/xkb.c
>  b/xkb/xkb.c
> +@@ -5908,19 +5908,31 @@ ProcXkbGetKbdByName(ClientPtr client)
> + xkb = dev->key->xkbInfo->desc;
> + status = Success;
> + str = (unsigned char *) [1];
> +-if (GetComponentSpec(, TRUE, ))  /* keymap, unsupported */
> +-return BadMatch;
> ++{
> ++char *keymap = GetComponentSpec(, TRUE, );  /* keymap, 
> unsupported */
> ++if (keymap) {
> ++free(keymap);
> ++return BadMatch;
> ++}
> ++}
> + names.keycodes = GetComponentSpec(, TRUE, );
> + names.types = GetComponentSpec(, TRUE, );
> + names.compat = GetComponentSpec(, TRUE, );
> + names.symbols = GetComponentSpec(, TRUE, );
> + names.geometry = GetComponentSpec(, TRUE, );
> +-if (status != Success)
> +-return status;
> +-len = str -

Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0

Hello,

This caused:

| FAILED: gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse 
-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=format-security 
--sysroot=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot
 -Igst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p -Igst-libs/gst/vaapi 
-I../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi -I. -I../gstreamer-vaapi-1.20.4 
-Igst-libs -I../gstreamer-vaapi-1.20.4/gst-libs 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/gstreamer-1.0
 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/glib-2.0
 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/glib-2.0/include
 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/orc-0.4
 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/lib/gstreamer-1.0/include
 
-I/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/libdrm
 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-fvisibility=hidden -fno-strict-aliasing -O2 -pipe -g 
-feliminate-unused-debug-types 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/gstreamer-vaapi-1.20.4=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/build=/usr/src/debug/gstreamer1.0-vaapi/1.20.4-r0
 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
 
-fmacro-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot=
 
-fdebug-prefix-map=/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot-native=
 -fPIC -pthread -DHAVE_CONFIG_H -DGST_USE_UNSTABLE_API 
'-DGST_VAAPI_VERSION_ID="1.20.4"' -MD -MQ 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -MF 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o.d -o 
gst-libs/gst/vaapi/libgstlibvaapi-1.0.a.p/gstvaapidisplay_egl.c.o -c 
../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c
| In file included from 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
|  from 
../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.h:26,
|  from 
../gstreamer-vaapi-1.20.4/gst-libs/gst/vaapi/gstvaapidisplay_egl.c:24:
| 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10:
 fatal error: X11/Xlib.h: No such file or directory
|   109 | #include 
|   |  ^~~~
| compilation terminated.
| ninja: build stopped: subcommand failed.
| WARNING: 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472:153
 exit 1 from 'ninja -v -j 16 -l 52'
| WARNING: Backtrace (BB generated script):
|   #1: meson_do_compile, 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472,
 line 153
|   #2: do_compile, 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472,
 line 148
|   #3: main, 
/home/pokybuild/yocto-worker/no-x11/build/build/tmp/work/core2-64-poky-linux/gstreamer1.0-vaapi/1.20.4-r0/temp/run.do_compile.281472,
 line 157
NOTE: recipe gstreamer1.0-vaapi-1.20.4-r0: task do_compile: Failed
ERROR: Task 
(/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.20.4.bb:do_compile)
 failed with exit code '1'


https://autobuilder.yoctoproject.org/typhoon/#builders/40/builds/6280/steps/11/logs/stdio

On 01/12/2022 18:39:42+0100, Markus

Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0

2022-12-05 Thread Otavio Salvador

Em seg., 5 de dez. de 2022 às 02:52, Markus Volk 
escreveu:

> Am So, 4. Dez 2022 um 09:23:49 -0800 schrieb Khem Raj  >:
>
> Not sure if this is related but I think its somewhere in egl headers
> provided by mesa.
>
>
> This is related to an update of the egl headers in Mesa, just as you
> thought:
> https://github.com/meta-qt5/meta-qt5/pull/491
>

It looks fine for me. @Martin Jansa  could you
check the PR above and merge if fine with it?

-- 
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 (#174288): 
https://lists.openembedded.org/g/openembedded-core/message/174288
Mute This Topic: https://lists.openembedded.org/mt/95388063/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] GCC Patch Tracking

2022-12-05 Thread Randy MacLeod

Let's keep the discussion on the list to give everyone a chance to know 
what's going on and to contribute.

Oh and please use in-line email instead of attachments when possible.

Also add Khem who is the author of many of these patches. Hopefully he can
help us clean-up the status and advise about which 'Pending' patches are
candidates to send upstream.

On 2022-12-05 08:06, Shinde, Yash wrote:


Hi Richard,

PFA  document for GCC patch analysis. There were about 28 patches in 
GCC sources out of which 3 patches are with the upstream status of 
‘Submitted’ and other 10 are ‘Pending’.  I had analysed the current 
status of these patches by checking them with the GCC patch list and 
archive list and documented the same in the attached document.


Out of the 3 patches with ‘submitted’ as the status,

- The 1st patch is submitted but changes are not reflected in the 
upstream. (hardcoded-paths.patch)


- The 2nd patch is not found in the upstream 
(0014-Don-t-search-host-directory-during-relink-if-inst_pr.patch), was 
not found in patch list or archive list and


- For the 3rd patch 1 hunk taken to upstream and can be marked as 
'backported' and the other hunk is not taken to upstream yet. 
(prefix-map-realpath.patch)


All the patch links are given in the doc.




GCC 12.2 Patch Analysis

hardcoded-paths.patch:Upstream-Status: Submitted 
[https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html]

->Patch is submitted but changes not reflected in upstream





0014-Don-t-search-host-directory-during-relink-if-inst_pr.patch:Upstream-Status: 
Submitted
->not yet submitted to upstream but link provided here- 
http://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html


prefix-map-realpath.patch:Upstream-Status: Submitted 
[https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599885.html]
->1 of the 2 hunks of patch send to upstream and other is not 
included. Link- 
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg294480.html


0013-Ensure-target-gcc-headers-can-be-included.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0005-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0004-Pass-CXXFLAGS_FOR_BUILD-in-a-couple-of-places-to-avo.patch:Upstream-Status: 
Pending [should be submittable]

->not yet submitted to upstream

0002-gcc-poison-system-directories.patch:Upstream-Status: Pending
->not yet submitted to upstream

0009-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0017-Search-target-sysroot-gcc-version-specific-dirs-with.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0008-libtool.patch:Upstream-Status: Pending
->not yet submitted to upstream

0020-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0018-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch:Upstream-Status: 
Pending

->not yet submitted to upstream

0006-cpp-honor-sysroot.patch:Upstream-Status: Pending
->not yet submitted to upstream






For the patches with ‘pending’ as the status, they are pending from 
quite some time. Should we contact the author of the patch or the 
community for these patches?


Please guide me on how to proceed further in GCC patch analysis and 
what are the next steps.



Let's see what Khem has to say about his collection of 'Pending' patches.


Thanks Yash,

../Randy



Regards,
Yash Shinde



--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174287): 
https://lists.openembedded.org/g/openembedded-core/message/174287
Mute This Topic: https://lists.openembedded.org/mt/95468728/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][kirkstone][master][PATCH] externalsrc: fix lookup for .gitmodules

2022-12-05 Thread Ross Burton

On 1 Dec 2022, at 14:04, Peter Marko via lists.openembedded.org 
 wrote:
> 
> Commit 0533edac277080e1bd130c14df0cbac61ba01a0c broke
> bitbake parsing when bitbake is executed from directory with existing 
> .gitmodules
> and the recipe in externalsrc does not have .gitmodules
> 
> The check needs to search for .gitmodules in sources path, not cwd.
> 
> iParsing recipes...ERROR: ExpansionError during parsing 
> ...
> bb.data_smart.ExpansionError: Failure expanding variable 
> do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which 
> triggered exception CalledProcessError: Command '['git', 'config', '--file', 
> '.gitmodules', '--get-regexp', 'path']' returned non-zero exit status 1.

There’s been a series of commits now “fixing” the lookup logic, can you write a 
small test case to exercise this path?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174286): 
https://lists.openembedded.org/g/openembedded-core/message/174286
Mute This Topic: https://lists.openembedded.org/mt/95382667/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][master,langdale][PATCH] libdrm: Remove libdrm-kms package

2022-12-05 Thread Ross Burton

It doesn’t look like this patch was ever sent to the list, at least 
https://lists.openembedded.org/g/openembedded-core/search?p=%2C%2C%2C20%2C0%2C0%2C0=libdrm-kms
 doesn’t show it.

Can you post it please?

Ross

> On 2 Dec 2022, at 18:24, Sandeep Gundlupet Raju via lists.openembedded.org 
>  wrote:
> 
> Hi Alex, Richard,
> 
> Any updates on reviewing this patch?
> 
> Thanks,
> 
> Sandeep
> 
> On 11/3/2022 2:09 PM, Gundlupet Raju, Sandeep wrote:
>> Hello,
>> 
>> Any updates on reviewing this patch?
>> 
>> Thanks,
>> 
>> Sandeep
>> 
>> On 10/27/2022 8:17 PM, Sandeep Gundlupet Raju wrote:
>>> libkms library is deprecated in 2.4.111 version. Hence remove
>>> libdrm-kms package.
>>> 
>>> Signed-off-by: Sandeep Gundlupet Raju 
>>> ---
>>>   meta/recipes-graphics/drm/libdrm_2.4.113.bb | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>> 
>>> diff --git a/meta/recipes-graphics/drm/libdrm_2.4.113.bb 
>>> b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
>>> index 959ef68032..613d3430ce 100644
>>> --- a/meta/recipes-graphics/drm/libdrm_2.4.113.bb
>>> +++ b/meta/recipes-graphics/drm/libdrm_2.4.113.bb
>>> @@ -39,7 +39,7 @@ PACKAGECONFIG[manpages] = 
>>> "-Dman-pages=enabled,-Dman-pages=disabled,libxslt-nati
>>> ALLOW_EMPTY:${PN}-drivers = "1"
>>>   PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau 
>>> ${PN}-omap \
>>> - ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno 
>>> ${PN}-amdgpu \
>>> + ${PN}-intel ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu \
>>>${PN}-etnaviv"
>>> RRECOMMENDS:${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap 
>>> ${PN}-intel \
>>> @@ -52,7 +52,6 @@ FILES:${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
>>>   FILES:${PN}-omap = "${libdir}/libdrm_omap.so.*"
>>>   FILES:${PN}-intel = "${libdir}/libdrm_intel.so.*"
>>>   FILES:${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
>>> -FILES:${PN}-kms = "${libdir}/libkms*.so.*"
>>>   FILES:${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
>>>   FILES:${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.* 
>>> ${datadir}/${PN}/amdgpu.ids"
>>>   FILES:${PN}-etnaviv = "${libdir}/libdrm_etnaviv.so.*"
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174285): 
https://lists.openembedded.org/g/openembedded-core/message/174285
Mute This Topic: https://lists.openembedded.org/mt/95412279/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

2022-12-05 Thread Ola x Nilsson


On Mon, Dec 05 2022, Richard Purdie wrote:

> On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:
>> On Wed, Nov 30 2022, Richard Purdie wrote:
>> 
>> > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:
>> > > On 30/11/2022 16:46:17+, Ross Burton wrote:
>> > > > On 30 Nov 2022, at 14:20, Richard Purdie via
>> > > > lists.yoctoproject.org
>> > > >  wrote:
>> > > > > > > * Could we optionally disable some of the glibc 32 bit function 
>> > > > > > > calls
>> > > > > > > to ensure they're not being used? 
>> > > > > > 
>> > > > > > Could you be more specific here? Would you like to disable some
>> > > > > > syscalls?
>> > > > > 
>> > > > > I'm meaning disabling the 32 bit glibc time functions.
>> > > > 
>> > > > Some time ago I filed
>> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
>> > > > has a nice sanity check where it warns if non-LFS glibc functions
>> > > > are used.  I imagine the same logic could be used to check for 32-
>> > > > bit time_t use.
>> > 
>> > That sounds interesting and something we should probably look into for
>> > both issues...
>> 
>> I have a working sanity checker that checks for any glibc functions
>> affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
>> The INSANE_SKIP functionality needs some more polish but I'd be happy to
>> contribute it.
>> 
>> Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
>> in the checker.
>> 
>> I have not run any world builds with this checker, I've focused on the
>> recipes we actually use so far so we could get to a testable system.  My
>> biggest worry at the moment is rust, I know to little to know if it is
>> an actual problem and how to fix it.
>> 
>> I would like to be part of any "y2038 team" for Yocto.
>
> That does sound useful, perhaps sharing it as an RFC patch might be a
> good place to start? We might be able to run one of the autobuilder
> world targets against it, see how it looks for our core recipes?

That works for me.  I've started preparing a patch for oe-core.

-- 
Ola x Nilsson

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174284): 
https://lists.openembedded.org/g/openembedded-core/message/174284
Mute This Topic: https://lists.openembedded.org/mt/95361986/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:
> On Wed, Nov 30 2022, Richard Purdie wrote:
> 
> > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:
> > > On 30/11/2022 16:46:17+, Ross Burton wrote:
> > > > On 30 Nov 2022, at 14:20, Richard Purdie via
> > > > lists.yoctoproject.org
> > > >  wrote:
> > > > > > > * Could we optionally disable some of the glibc 32 bit function 
> > > > > > > calls
> > > > > > > to ensure they're not being used? 
> > > > > > 
> > > > > > Could you be more specific here? Would you like to disable some
> > > > > > syscalls?
> > > > > 
> > > > > I'm meaning disabling the 32 bit glibc time functions.
> > > > 
> > > > Some time ago I filed
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
> > > > has a nice sanity check where it warns if non-LFS glibc functions
> > > > are used.  I imagine the same logic could be used to check for 32-
> > > > bit time_t use.
> > 
> > That sounds interesting and something we should probably look into for
> > both issues...
> 
> I have a working sanity checker that checks for any glibc functions
> affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
> The INSANE_SKIP functionality needs some more polish but I'd be happy to
> contribute it.
> 
> Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
> in the checker.
> 
> I have not run any world builds with this checker, I've focused on the
> recipes we actually use so far so we could get to a testable system.  My
> biggest worry at the moment is rust, I know to little to know if it is
> an actual problem and how to fix it.
> 
> I would like to be part of any "y2038 team" for Yocto.

That does sound useful, perhaps sharing it as an RFC patch might be a
good place to start? We might be able to run one of the autobuilder
world targets against it, see how it looks for our core recipes?

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174283): 
https://lists.openembedded.org/g/openembedded-core/message/174283
Mute This Topic: https://lists.openembedded.org/mt/95361986/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

2022-12-05 Thread Ola x Nilsson

On Wed, Nov 30 2022, Richard Purdie wrote:

> On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:
>> On 30/11/2022 16:46:17+, Ross Burton wrote:
>> > On 30 Nov 2022, at 14:20, Richard Purdie via
>> > lists.yoctoproject.org
>> >  wrote:
>> > > > > * Could we optionally disable some of the glibc 32 bit function calls
>> > > > > to ensure they're not being used? 
>> > > > 
>> > > > Could you be more specific here? Would you like to disable some
>> > > > syscalls?
>> > > 
>> > > I'm meaning disabling the 32 bit glibc time functions.
>> > 
>> > Some time ago I filed
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
>> > has a nice sanity check where it warns if non-LFS glibc functions
>> > are used.  I imagine the same logic could be used to check for 32-
>> > bit time_t use.
>
> That sounds interesting and something we should probably look into for
> both issues...

I have a working sanity checker that checks for any glibc functions
affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
The INSANE_SKIP functionality needs some more polish but I'd be happy to
contribute it.

Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
in the checker.

I have not run any world builds with this checker, I've focused on the
recipes we actually use so far so we could get to a testable system.  My
biggest worry at the moment is rust, I know to little to know if it is
an actual problem and how to fix it.

I would like to be part of any "y2038 team" for Yocto.

-- 
Ola x Nilsson

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174282): 
https://lists.openembedded.org/g/openembedded-core/message/174282
Mute This Topic: https://lists.openembedded.org/mt/95361986/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 1/2] xorg-driver-common: add opengl to REQUIRED_DISTRO_FEATURES

Both of these patches seem very wrong. X11 definitely does not require
opengl. I just confirmed it by building xf86-input-synaptics without
opengl in DISTRO_FEATURES.

Can you show how the issue can be reproduced on plain poky? It seems
like your local config or distro or BSP layer does something which
triggers this.

Alex



On Mon, 5 Dec 2022 at 10:51, Yu, Mingli  wrote:
>
> From: Mingli Yu 
>
> xf86-input-synaptics depends on virtual/xserver which needs opengl
> DISTRO_FEATURES, so add opengl distro check also for xf86-input-synaptics.
>
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-graphics/xorg-driver/xorg-driver-common.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc 
> b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> index 8b3f19426b..3fc54af3e4 100644
> --- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> +++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> @@ -17,7 +17,7 @@ XORGBUILDCLASS ??= "autotools"
>  inherit ${XORGBUILDCLASS} pkgconfig features_check
>
>  # depends on virtual/xserver
> -REQUIRED_DISTRO_FEATURES = "x11"
> +REQUIRED_DISTRO_FEATURES = "x11 opengl"
>
>  # FIXME: We don't want to include the libtool archives (*.la) from modules
>  # directory, as they serve no useful purpose. Upstream should fix Makefile.am
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174281): 
https://lists.openembedded.org/g/openembedded-core/message/174281
Mute This Topic: https://lists.openembedded.org/mt/95465698/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] packagegroup-core-x11-xserver: add opengl to REQUIRED_DISTRO_FEATURES

2022-12-05 Thread Yu, Mingli

From: Mingli Yu 

Fixes:
  ERROR: Nothing RPROVIDES 'xf86-video-vesa' (but 
/build/layers/oe-core/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb
 RDEPENDS on or otherwise requires it)
  xf86-video-vesa was skipped: missing required distro feature 'opengl' (not in 
DISTRO_FEATURES)
  NOTE: Runtime target 'xf86-video-vesa' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['xf86-video-vesa']
  ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
  Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 
'packagegroup-core-x11-xserver', 'xf86-video-vesa']

Signed-off-by: Mingli Yu 
---
 .../packagegroups/packagegroup-core-x11-base.bb | 2 +-
 .../packagegroups/packagegroup-core-x11-xserver.bb  | 2 +-
 meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb| 2 +-
 meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb 
b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
index 0185c93354..042b8cb30e 100644
--- a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
+++ b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
@@ -4,7 +4,7 @@ PR = "r1"
 
 inherit packagegroup features_check
 # rdepends on matchbox-wm
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 RDEPENDS:${PN} = "\
 packagegroup-core-x11-xserver \
diff --git 
a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb 
b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb
index 3bb308fbba..32cecfb8a1 100644
--- a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb
+++ b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb
@@ -9,7 +9,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit packagegroup features_check
 # rdepends on XSERVER
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 XSERVER ?= "xserver-xorg xf86-video-fbdev"
 XSERVERCODECS ?= ""
diff --git a/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb 
b/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb
index 9ca058b38b..341a76a02b 100644
--- a/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb
+++ b/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb
@@ -5,7 +5,7 @@
 PR = "r40"
 
 inherit packagegroup features_check
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 PACKAGES = "${PN} ${PN}-utils"
 
diff --git a/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb 
b/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
index 6866a4d738..aa850ce955 100644
--- a/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
+++ b/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
@@ -10,7 +10,7 @@ PR = "r33"
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit packagegroup features_check
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 PACKAGES = "${PN} ${PN}-base ${PN}-apps ${PN}-games"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174280): 
https://lists.openembedded.org/g/openembedded-core/message/174280
Mute This Topic: https://lists.openembedded.org/mt/95465699/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] xorg-driver-common: add opengl to REQUIRED_DISTRO_FEATURES

2022-12-05 Thread Yu, Mingli

From: Mingli Yu 

xf86-input-synaptics depends on virtual/xserver which needs opengl
DISTRO_FEATURES, so add opengl distro check also for xf86-input-synaptics.

Signed-off-by: Mingli Yu 
---
 meta/recipes-graphics/xorg-driver/xorg-driver-common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc 
b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
index 8b3f19426b..3fc54af3e4 100644
--- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
+++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
@@ -17,7 +17,7 @@ XORGBUILDCLASS ??= "autotools"
 inherit ${XORGBUILDCLASS} pkgconfig features_check
 
 # depends on virtual/xserver
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 # FIXME: We don't want to include the libtool archives (*.la) from modules
 # directory, as they serve no useful purpose. Upstream should fix Makefile.am
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174279): 
https://lists.openembedded.org/g/openembedded-core/message/174279
Mute This Topic: https://lists.openembedded.org/mt/95465698/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] gnu-config: upgrade to latest revision