[oe-core][PATCHv9 3/4] gcr: add recipe for gcr-4, needed to build with gtk4

gcr-3 recipe is still needed for gnome projects that stick to gtk+3, rename to gcr3. Signed-off-by: Markus Volk --- ...ectly-handle-disabled-ssh_agent-opti.patch | 49 ...build-fix-one-parallel-build-failure.patch | 0 ...1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch | 0

[oe-core][PATCHv9 2/4] gtk4: import recipe from meta-gnome

Signed-off-by: Markus Volk --- meta/recipes-gnome/gtk+/gtk4_4.8.2.bb | 130 ++ 1 file changed, 130 insertions(+) create mode 100644 meta/recipes-gnome/gtk+/gtk4_4.8.2.bb diff --git a/meta/recipes-gnome/gtk+/gtk4_4.8.2.bb b/meta/recipes-gnome/gtk+/gtk4_4.8.2.bb new file

[oe-core][PATCHv9 4/4] Add entries for the newly added recipes to maintainers.inc

Signed-off-by: Markus Volk --- meta/conf/distro/include/maintainers.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 03db94824d..1bd0993eec 100644 --- a/meta/conf/distro/include/maintainers.inc

[oe-core][PATCHv9 1/4] graphene: import from meta-oe

Signed-off-by: Markus Volk --- .../graphene/graphene_1.10.8.bb | 22 +++ 1 file changed, 22 insertions(+) create mode 100644 meta/recipes-graphics/graphene/graphene_1.10.8.bb diff --git a/meta/recipes-graphics/graphene/graphene_1.10.8.bb

[OE-core][PATCH] psplash: consider the situation of psplash not exist for systemd

In current psplash framework, the psplash might not exist at all. For example, in case DSITRO is set to nodistro, the psplash does not exist. In our psplash recipe, we have: SPLASH_IMAGES = "file://psplash-poky-img.h;outsuffix=default" This variable is parsed to if psplash-poky-img.h exists, a

[OE-core][PATCH] bc: extend to nativesdk

bc is needed for compiling kernel modules, more specifially whenr running `make scripts prepare'. In linux-yocto.inc, we have bc-native in DEPENDS. But we will need nativesdk-bc in case we compile a kernel module inside SDK. Signed-off-by: Chen Qi --- meta/recipes-extended/bc/bc_1.07.1.bb | 2

[OE-core] [RFC] How to run yocto compliance against openembedded-core layer

Hi, There comes below error when run yocto compliance against openembedded-core layer. Any hints? 1, mkdir -p /yocto 2, cd /yocto && git clone git://git.yoctoproject.org/poky 3, cd /yocto/poky && . oe-init-build-env build 4, yocto-check-layer-wrapper ../meta [snip] INFO: Detected layers: ERROR:

Re: [OE-core] OpenEmbedded Layer Index is not updating

On Wed., Nov. 30, 2022, 19:14 Livius, wrote: > As i see in OpenEmbedded Layer Index website > > automatic layer updates stoped to works for all layers. Please fix it. > Hi Lucius, Please open a bug in bugzilla. If you have some

[OE-core] OpenEmbedded Layer Index is not updating

As i see in OpenEmbedded Layer Index website ( https://layers.openembedded.org/layerindex/branch/master/layers/ ) automatic layer updates stoped to works for all layers. Please fix it. https://layers.openembedded.org/layerindex/layerupdate/9393191/

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

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > 2. There are ptest available [2] to validate if the Y2038 problem works > correctly. > > 3. Support for running ptests mentioned in point 2. is already > available in the poky repository [3]. I just ran these tests in (32 bit) qemux86 on top

Re: [oe-core][PATCHv8 4/4] gcr: add recipe for gcr-4, needed to build with gtk4

I would also request that you (Markus) run: devtool check-upgrade-status and verify that their upstream version check works properly. Alex On Wed, 30 Nov 2022 at 21:57, Alexandre Belloni via lists.openembedded.org wrote: > > Last missing things: > > The following recipes do not have a

Re: [oe-core][PATCHv8 3/4] gtk4: import recipe from meta-gnome

Hello, This one popped up: | Program gi-docgen found: NO | | ../gtk-4.6.7/docs/reference/meson.build:4:0: ERROR: Program 'gi-docgen' not found or not executable https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/3817/steps/11/logs/stdio On 30/11/2022 06:34:49+0100, Markus

Re: [oe-core][PATCHv8 4/4] gcr: add recipe for gcr-4, needed to build with gtk4

Last missing things: The following recipes do not have a maintainer assigned to them. Please add an entry to meta/conf/distro/include/maintainers.inc file. gcr3 (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-gnome/gcr/gcr3_3.40.0.bb) gtk4

Re: [OE-core] OpenEmbedded Happy Hour November 30

Well, historically we used to have the OpenEmbedded Happy Hour after the sessions on the second day of the Yocto Project Summit and ask people to re-join a different Zoom room to socialize. This time around there's a dedicated YP Summit social time reserved, so to avoid switchig Zooms, we

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

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

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

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

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

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

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

On Wed, Nov 30, 2022 at 12:08 AM Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a.

[OE-core] [PATCH] classes: make TOOLCHAIN more permissive for kernel

Currently TOOLCHAIN is strictly set to gcc in kernel-arch.bbclass. And this prevents any TOOLCHAIN changes for any kernel recipe. This change makes TOOLCHAIN configurable as usual. Signed-off-by: Alexey Smirnov --- meta/classes-recipe/kernel-arch.bbclass | 2 +- 1 file changed, 1 insertion(+),

Re: [OE-core] [PATCH] musl: Update to latest on tip of trunk

On Wed, Nov 30, 2022 at 6:48 AM Alexandre Belloni wrote: > > Hello, > > This broke a few recipes: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/6247/steps/12/logs/stdio > > I guess this is dues to the LFS64 changes yes indeed. I have some WIP on yoe/mut branch. Lets wait

Re: [oe-core][PATCHv8 4/4] gcr: add recipe for gcr-4, needed to build with gtk4

Am Mi, 30. Nov 2022 um 16:52:34 +0100 schrieb Alexandre Belloni via lists.openembedded.org : | Run-time dependency gcr-3 found: NO (tried pkgconfig) Sent a patch for it -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174021):

[oe-core][PATCHv2] epiphany: use gcr3

Signed-off-by: Markus Volk --- meta/recipes-gnome/epiphany/epiphany_42.4.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/epiphany/epiphany_42.4.bb b/meta/recipes-gnome/epiphany/epiphany_42.4.bb index afaaefc46f..0cbe1c9c58 100644 ---

Re: [oe-core][PATCHv8 4/4] gcr: add recipe for gcr-4, needed to build with gtk4

Hello, This one broke: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/6249/steps/11/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6164/steps/11/logs/stdio | Run-time dependency gcr-3 found: NO (tried pkgconfig) | |

[OE-core] [PATCH] Enable nativesdk for gperf, gi-docgen, unifdef, ruby and 3 python recipes

I'm building a SDK (bitbake task: populate_sdk) for WPE/WebKit development and I need the tools below to be extended with the class nativesdk. They work fine on the SDK after this change. Signed-off-by: Carlos Alberto Lopez Perez --- meta/recipes-devtools/python/python3-markdown_3.4.1.bb| 2

Re: [OE-core][PATCH 1/2] ffmpeg: fix for CVE-2022-3964

On 30/11/2022 14:00:48+, Narpat Mali wrote: > A vulnerability classified as problematic has been found in ffmpeg. This > affects an unknown part of the file > libavcodec/rpzaenc.c of the component QuickTime RPZA Video Encoder. The > manipulation of the argument y_size > leads to

Re: [OE-core] [PATCH] musl: Update to latest on tip of trunk

Hello, This broke a few recipes: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/6247/steps/12/logs/stdio I guess this is dues to the LFS64 changes On 28/11/2022 11:18:04-0800, Khem Raj wrote: > Brings following changes > > * 8f925945 fix return value of

[OE-core][langdale 00/37] Pull request (cover letter only)

The following changes since commit e0dc0f4a153f75d14d50d5bc91edb93fac93cd25: wic: make ext2/3/4 images reproducible (2022-11-19 03:59:47 -1000) are available in the Git repository at: https://git.openembedded.org/openembedded-core-contrib stable/langdale-next

[OE-core][kirkstone 00/31] Pull request (cover letter only)

The following changes since commit da2c64b3158c58eb0a484d3acbdf0419df2d34e8: wic: make ext2/3/4 images reproducible (2022-11-17 07:23:06 -1000) are available in the Git repository at: https://git.openembedded.org/openembedded-core-contrib stable/kirkstone-next

Re: [OE-core] [PATCH v4] mesa: enable glvnd support

Nevermind see this was just merge in :) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174013): https://lists.openembedded.org/g/openembedded-core/message/174013 Mute This Topic: https://lists.openembedded.org/mt/95264122/21656 Group Owner:

Re: [OE-core] [PATCH v4] mesa: enable glvnd support

Hello, Is the consensuses that we still don't want PREFERRED_PROVIDER_virtual/libglx ?= "mesa" or ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)} -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174012):

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

On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote: > > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > > wrote: > > > > We’d welcome a proposal/series on how to move forward with the > > > > Y2038 work for 32 bit

Re: [OE-core][PATCH 1/2] ffmpeg: fix for CVE-2022-3964

Hi Ross, As suggested, have sent both the patches again with CVE tag in patch header. Best Regards, Narpat From: Ross Burton Sent: 29 November 2022 19:12 To: Mali, Narpat Cc:

[OE-core][PATCH 2/2] ffmpeg: fix for CVE-2022-3965

A vulnerability classified as problematic was found in ffmpeg. This vulnerability affects the function smc_encode_stream of the file libavcodec/smcenc.c of the component QuickTime Graphics Video Encoder. The manipulation of the argument y_size leads to out-of-bounds read. The attack can be

[OE-core][PATCH 1/2] ffmpeg: fix for CVE-2022-3964

A vulnerability classified as problematic has been found in ffmpeg. This affects an unknown part of the file libavcodec/rpzaenc.c of the component QuickTime RPZA Video Encoder. The manipulation of the argument y_size leads to out-of-bounds read. It is possible to initiate the attack remotely.

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

Hi Richard, > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the > > > Y2038 work for 32 bit platforms. > > > > I have the following proposal: > > > >

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

On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a.

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

On Wed, 2022-11-30 at 13:07 +0100, Alexander Kanavin wrote: > On Wed, 30 Nov 2022 at 12:40, Richard Purdie > wrote: > > > To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 > > and qemuarm64 where we have KVM available. We do run image, sdk and > > eSDK tests on our supported

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

On Wed, 30 Nov 2022 13:07:27 +0100 "Alexander Kanavin" wrote: > On Wed, 30 Nov 2022 at 12:40, Richard Purdie > wrote: > > > To be clear, we don't run ptests on 32 bit targets, only on > > qemux86-64 and qemuarm64 where we have KVM available. We do run > > image, sdk and eSDK tests on our

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

On Wed, 30 Nov 2022 at 12:40, Richard Purdie wrote: > To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 > and qemuarm64 where we have KVM available. We do run image, sdk and > eSDK tests on our supported qemu targets, 32 and 64 bit. I think kvm does allow 32 bit guest on a

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

On Wed, 2022-11-30 at 12:02 +0100, Alexandre Belloni via lists.openembedded.org wrote: > On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > > for 32

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

On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a.

Re: [OE-core][PATCH v2] tzdata: update to 2022f

Hi, Any update for this patch? On Tue, Nov 15, 2022 at 6:21 PM pdoshi via lists.openembedded.org wrote: > From: Priyal Doshi > > Signed-off-by: Priyal Doshi > --- > meta/recipes-extended/timezone/timezone.inc | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

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

On Wed, 30 Nov 2022 at 10:40, Lukasz Majewski wrote: > It would be even better if the meta-y2038 could be dropped and _all_ > its functionality could be merged to poky. > > That would be _awesome_. > > Please just be aware that this meta layer has some fixes for some > packages (for Y2038 ready

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

Hi Alexander, > On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > > Please find a few comments: > > > > 1. There is already provided meta-y2038 [1] to test if 32 bit > > systems correctly support Y2038 problem. It uses qemu machines from > > OE/Yocto > > > > 2. There are ptest available [2]

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

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > Please find a few comments: > > 1. There is already provided meta-y2038 [1] to test if 32 bit systems > correctly support Y2038 problem. It uses qemu machines from OE/Yocto > > 2. There are ptest available [2] to validate if the Y2038 problem

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

Hi Alexander, > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > wrote: > > We’d welcome a proposal/series on how to move forward with the > > Y2038 work for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is

[OE-core] Y2038 proposal

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > We’d welcome a proposal/series on how to move forward with the Y2038 work for > 32 bit platforms. I have the following proposal: 1. A branch is made where: a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. b. qemu is always