Re: [OE-core] [PATCH 2/3] boost: don't specify gcc version

On Tue, 6 Oct 2020 at 17:14, Khem Raj wrote: > does it probe the version from cross compiler now and not the host compiler ? I shall triple check :) Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#143068): https://lists.openembedded.org/g/op

[OE-core] [PATCH 7/7] linux-yocto/5.8: update to v5.8.13

From: Bruce Ashfield Updating linux-yocto/5.8 to the latest korg -stable release that comprises the following commits: cdcec6869074 Linux 5.8.13 510c51ff61e3 clocksource/drivers/timer-ti-dm: Do reset before enable af56dabe31d1 dm: fix bio splitting and its bio completion order for re

[OE-core] [PATCH 5/7] linux-yocto/5.8: update to v5.8.12

From: Bruce Ashfield Updating linux-yocto/5.8 to the latest korg -stable release that comprises the following commits: 0c52d2a4d9e9 Linux 5.8.12 973f3e32fefe net/mlx5e: Fix endianness when calculating pedit mask first bit 1fa560ecd2ca net/mlx5e: Use synchronize_rcu to sync with NAPI

[OE-core] [PATCH 4/7] linux-yocto/5.4: update to v5.4.68

From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: 5d087e3578cf Linux 5.4.68 071f42defada iommu/amd: Use cmpxchg_double() when updating 128-bit IRTE a5bc1c7a9a6d mm: memcg: fix memcg reclaim soft lockup 7f23aa7ca

[OE-core] [PATCH 2/7] linux-yocto/5.4: update to v5.4.67

From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: a4bea6a4f1e0 Linux 5.4.67 ef6458fdbb5c dax: Fix compilation for CONFIG_DAX && !CONFIG_FS_DAX d6712eefc77e dm: Call proper helper to determine dax support 6b02d05

[OE-core] [PATCH 1/7] linux-yocto/5.4: fix kprobes build warning

From: Bruce Ashfield Integrating the following commit(s) to linux-yocto/5.4: 178189d65780 kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE Signed-off-by: Bruce Ashfield --- .../recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +- .../linux/linux-yocto-tiny_5.4.bb |

[OE-core] [PATCH 0/7] linux-yocto: consolidated pull request

From: Bruce Ashfield Richard, Here's the set of -stable commits that I've had queued. I ran through a-quick on the AB and it came back green: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1197 Cheers, Bruce The following changes since commit 520e95902f12feac2850e0c24167

[OE-core] [PATCH 3/7] linux-yocto/5.8: update to v5.8.11

From: Bruce Ashfield Updating linux-yocto/5.8 to the latest korg -stable release that comprises the following commits: 16b1d77227fe Linux 5.8.11 aac156c89083 nvme-loop: set ctrl state connecting after init f9aa4d81fa77 mm: memcg: fix memcg reclaim soft lockup e37b4e9e1fc9 dax: Fi

[OE-core] [PATCH 6/7] linux-yocto/5.4: update to v5.4.69

From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: a9518c1aec5b Linux 5.4.69 9fb8e10b0519 ata: sata_mv, avoid trigerrable BUG_ON e11c83520cd0 ata: make qc_prep return ata_completion_errors b6e503c0a0ff ata: defin

Re: [OE-core] [PATCH] llvm: fix llvm-config to work again with multilib

does something like this not work fully ? https://github.com/kraj/meta-clang/blob/master/recipes-devtools/clang/clang/0007-llvm-allow-env-override-of-exe-path.patch On Tue, Oct 6, 2020 at 11:16 AM Yann Dirson wrote: > > Oh right that one is targeting dunfell and I did not check, will reroll > >

Re: [OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS

Hi Richard, I have tried with the latest version of Zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) and the problem is not solved yet. Do you need more information on my side? Regards, Adrian On 25.08.2020 17:16, Adrian Fiergolski wrote: > Hi Richard, > > Thank you for your reply. > > On 25.08.

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 7:02 AM Marek Vasut wrote: > > On 10/6/20 6:51 PM, Steve Sakoman wrote: > > On Tue, Oct 6, 2020 at 6:48 AM Marek Vasut wrote: > >> > >> On 10/6/20 6:44 PM, Bruce Ashfield wrote: > >>> On Tue, Oct 6, 2020 at 12:42 PM Steve Sakoman wrote: > > On Tue, Oct 6, 2020 at

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On 10/6/20 6:51 PM, Steve Sakoman wrote: > On Tue, Oct 6, 2020 at 6:48 AM Marek Vasut wrote: >> >> On 10/6/20 6:44 PM, Bruce Ashfield wrote: >>> On Tue, Oct 6, 2020 at 12:42 PM Steve Sakoman wrote: On Tue, Oct 6, 2020 at 6:39 AM Bruce Ashfield wrote: > > On Tue, Oct 6, 20

Re: [OE-core] [PATCH 1/4] staging: Ensure cleaned dependencies are added

> > Is this patch something that should be backported to zeus and friends? > > Its fixing a very rare problem that I only ran into whilst doing "interesting" > things most people don't probably do. > > If people were running into those issues I'd backport but for master it was > more a correctnes

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 6:48 AM Marek Vasut wrote: > > On 10/6/20 6:44 PM, Bruce Ashfield wrote: > > On Tue, Oct 6, 2020 at 12:42 PM Steve Sakoman wrote: > >> > >> On Tue, Oct 6, 2020 at 6:39 AM Bruce Ashfield > >> wrote: > >>> > >>> On Tue, Oct 6, 2020 at 12:30 PM Steve Sakoman wrote: > >

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On 10/6/20 6:44 PM, Bruce Ashfield wrote: > On Tue, Oct 6, 2020 at 12:42 PM Steve Sakoman wrote: >> >> On Tue, Oct 6, 2020 at 6:39 AM Bruce Ashfield >> wrote: >>> >>> On Tue, Oct 6, 2020 at 12:30 PM Steve Sakoman wrote: On Tue, Oct 6, 2020 at 2:11 AM Marek Vasut wrote: > > Up

Re: [OE-core] [PATCH 1/4] staging: Ensure cleaned dependencies are added

On Tue, 2020-10-06 at 16:07 +, chris.lapla...@agilent.com wrote: > Hi Richard, > > > Most recipe-sysroot dependencies are handled by these prefuncs. > > "configure" > > is special with a decidated task, prepare_recipe_sysroot which runs > > beforehand. > > > > do_prepare_recipe_sysroot does n

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 12:42 PM Steve Sakoman wrote: > > On Tue, Oct 6, 2020 at 6:39 AM Bruce Ashfield > wrote: > > > > On Tue, Oct 6, 2020 at 12:30 PM Steve Sakoman wrote: > > > > > > On Tue, Oct 6, 2020 at 2:11 AM Marek Vasut wrote: > > > > > > > > Update to latest available. > > > > > > Hav

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 6:39 AM Bruce Ashfield wrote: > > On Tue, Oct 6, 2020 at 12:30 PM Steve Sakoman wrote: > > > > On Tue, Oct 6, 2020 at 2:11 AM Marek Vasut wrote: > > > > > > Update to latest available. > > > > Have you tested these patches with kernel versions 5.4.62+ ? > > > > IIRC, Bruce

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 12:30 PM Steve Sakoman wrote: > > On Tue, Oct 6, 2020 at 2:11 AM Marek Vasut wrote: > > > > Update to latest available. > > Have you tested these patches with kernel versions 5.4.62+ ? > > IIRC, Bruce said that the 2.11.x tree did not have the necessary > patches to build w

Re: [OE-core] [PATCH 1/3] [dunfell] lttng-modules: update to 2.11.6

On Tue, Oct 6, 2020 at 2:11 AM Marek Vasut wrote: > > Update to latest available. Have you tested these patches with kernel versions 5.4.62+ ? IIRC, Bruce said that the 2.11.x tree did not have the necessary patches to build with recent 5.4 kernels. See his patch "lttng-modules: backport writeb

Re: [OE-core] [PATCH 2/3] boost: don't specify gcc version

On Tue, Oct 6, 2020 at 4:14 AM Ross Burton wrote: > > From: Ross Burton > > There's no need to specify an ancient GCC version here as Boost will > probe it. > > Signed-off-by: Ross Burton > --- > meta/recipes-support/boost/boost.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > di

Re: [OE-core] [PATCH 1/4] staging: Ensure cleaned dependencies are added

Hi Richard, > Most recipe-sysroot dependencies are handled by these prefuncs. "configure" > is special with a decidated task, prepare_recipe_sysroot which runs > beforehand. > > do_prepare_recipe_sysroot does not have to be run before/after > fetch/unpack/patch, they're independent tasks. If fetc

Re: [OE-core] [PATCH] llvm: fix llvm-config to work again with multilib

in master we have llvm 10 but the patch seems to be accessing llvm9.0.1 dir, that seems incorrect to me. On Tue, Oct 6, 2020 at 3:41 AM Yann Dirson wrote: > > From: Yann Dirson > > Newer llvm versions have changed the logic for finding libraries, > which prevents Mesa from building with PACKAGEC

Re: [OE-core] [PATCH] Revert "kernel.bbclass: make dependency on lzop-native conditional"

On 20-10-06 15:27, Richard Purdie wrote: > On Tue, 2020-10-06 at 16:26 +0200, Marco Felsch wrote: > > On 20-10-06 14:27, Richard Purdie wrote: > > > On Mon, 2020-10-05 at 16:18 +0200, Marco Felsch wrote: > > > > This reverts commit 1217ddf070261c5fe523729b2a833bd38f1e4ccd. > > > > > > > > This com

[OE-core] Yocto Project Status WW40'20

Current Dev Position: YP 3.2 M4 Next Deadline: YP 3.2 M4 Feature Freeze - Now Next Team Meetings: * Bug Triage meeting Thursday Oct. 8TH at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday Oct. 6th at 8am PDT (

Re: [OE-core] [PATCH] Revert "kernel.bbclass: make dependency on lzop-native conditional"

On Tue, 2020-10-06 at 16:26 +0200, Marco Felsch wrote: > On 20-10-06 14:27, Richard Purdie wrote: > > On Mon, 2020-10-05 at 16:18 +0200, Marco Felsch wrote: > > > This reverts commit 1217ddf070261c5fe523729b2a833bd38f1e4ccd. > > > > > > This commit breaks compiling if no initramfs is used because

Re: [OE-core] [PATCH] Revert "kernel.bbclass: make dependency on lzop-native conditional"

On 20-10-06 14:27, Richard Purdie wrote: > On Mon, 2020-10-05 at 16:18 +0200, Marco Felsch wrote: > > This reverts commit 1217ddf070261c5fe523729b2a833bd38f1e4ccd. > > > > This commit breaks compiling if no initramfs is used because the > > kernel image can be compressed too using lzo. > > Can we

Re: [OE-core] [PATCH] Revert "kernel.bbclass: make dependency on lzop-native conditional"

On Mon, 2020-10-05 at 16:18 +0200, Marco Felsch wrote: > This reverts commit 1217ddf070261c5fe523729b2a833bd38f1e4ccd. > > This commit breaks compiling if no initramfs is used because the > kernel image can be compressed too using lzo. Can we detect if the kernel is due to be compressed with lzo

[OE-core] [PATCH 3/3] [dunfell] lttng-ust: update to 2.11.1

Update to latest available. Signed-off-by: Marek Vasut Cc: Alexander Kanavin Cc: Richard Purdie --- .../lttng/{lttng-ust_2.11.1.bb => lttng-ust_2.11.2.bb}| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-kernel/lttng/{lttng-ust_2.11.1.bb => lttng-ust_2.11.2

[OE-core] [PATCH 2/3] [dunfell] lttng-tools: update to 2.11.5

Update to latest available. Signed-off-by: Marek Vasut Cc: Alexander Kanavin Cc: Richard Purdie --- .../lttng/{lttng-tools_2.11.2.bb => lttng-tools_2.11.5.bb}| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-kernel/lttng/{lttng-tools_2.11.2.bb => lttng-tools_2

[OE-core] [PATCH] [dunfell] stress-ng: Upgrade 0.11.01 -> 0.11.17

Upgrade to the latest upstream version. This fixes at least one build error, in which build fails due to undefined FS_IOC_GETFLAGS. See commit d7b4301d ("stress-efivar: only exercise FS_IOC_*FLAGS if they are defined") in stress-ng for details. Signed-off-by: Marek Vasut Cc: Alexander Kanavin Cc

[OE-core] [PATCH 3/3] boost: consolidate and update library list

Add some new libraries to the list (fiber, headers, type_erasure). Move context/coroutine to the list instead of using overrides as it builds everywhere I can test it. Remove the mips16e override for wave as Boost fails so dramatically with mips16e enabled that this isn't even close to a fix. Som

[OE-core] [PATCH 2/3] boost: don't specify gcc version

From: Ross Burton There's no need to specify an ancient GCC version here as Boost will probe it. Signed-off-by: Ross Burton --- meta/recipes-support/boost/boost.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-support/

[OE-core] [PATCH 1/3] boost: build a standalone boost.build

Boost is a huge unirepo made from multiple submodules. To bootstrap it we need boost.build (previously bjam) which is also available as a solo repository. This smaller repository can unpack/build/package faster than the Boost unirepo can unpack. Rename the recipe to the current name of Boost.Build

[OE-core] [PATCH] llvm: fix llvm-config to work again with multilib

From: Yann Dirson Newer llvm versions have changed the logic for finding libraries, which prevents Mesa from building with PACKAGECONFIG[gallium-llvm]: See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937 This patch comes from meta-amd, which exhibits one such situation. Signed-off-by: