Hi,
>> ${COREBASE}/scripts contains a "git" wrapper disabling fakeroot/pseudo.
>> This patch allows CMake to find ${COREBASE}/scripts/git instead of
>> ${HOSTTOOLS_DIR}/git. This is needed for git invocations during do_install,
>> since do_install is a fakeroot task, and otherwise all git commands
ub-package of it which
was not even installed into the recipe-sysroot), causing the dependant's
recipe-sysroot to be repopulated during do_install and thus causing the
CMake project to be reconfigured during do_install.
Signed-off-by: Daniel Klauer
---
meta/classes-recipe/cmake.bbclass
it from
this or are at least not affected negatively by it. The only exception
I've noticed was uboot-sign.bbclass, which was however fixed by the
previous patch.
Signed-off-by: Daniel Klauer
---
meta/classes/deploy.bbclass| 1 +
meta/classes/kernel.bbclass| 2 --
me
OYDIR}"
in the future, without deleting the files produced by concat_dtb.
As before, care is taken to not interfere with the kernel's do_deploy
definition, since concat_dtb was only needed for u-boot.
Signed-off-by: Daniel Klauer
---
meta/classes/uboot-sign.bbclass | 11 ++-
1
Ping - any chance of getting this merged? (refering to
https://patchwork.openembedded.org/series/19533/)
I think it would still be useful, especially for meta-freescale, which
uses do_deploy() in many recipes.
If not, then I can update the meta-freescale pull request that triggered
this patch (ht
The debug output showed the wrong variable.
Signed-off-by: Daniel Klauer
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 7fa4ff20bd..f4633da3d5 100644
--- a/meta/classes
th poky, putting the following in local.conf:
UBOOT_SIGN_ENABLE = "1"
KERNEL_CLASSES = " kernel-fitimage "
KERNEL_IMAGETYPE = "fitImage"
and then doing
bitbake core-image-minimal
bitbake u-boot
It built successfully and concat_dtb was still called.
Sig
> That commit message isn't correct.
>
> It removes cleandirs for the prefunc at the start of the prefunc and
> cleandirs for the main function at the start of that main function.
Oh ok, so the prefuncs/postfuncs can have their own [cleandirs], that's
interesting.
How about the following (trying
uilds successfully, the kernel and uboot recipes' temp/run.do_deploy
scripts look good (kernel's do_deploy is not broken, and uboot's do_deploy
still calls concat_dtb).
Signed-off-by: Daniel Klauer
---
meta/classes/uboot-sign.bbclass | 11 ++-
1 file changed, 6 inserti
tal build of do_deploy only.
3. after removing the modifications again.
The foo-${PN} files existed in tmp/deploy/images/qemux86-64 after step 2,
and not anymore after step 3, as expected. Thus the cleandirs still works.
Signed-off-by: Daniel Klauer
---
meta/classes/deploy.bbclass| 1 +
m
c53d1b2a24a2b93c5ea5268fa Mon Sep 17 00:00:00 2001
From: Daniel Klauer
Date: Mon, 26 Aug 2019 11:01:00 +0200
Subject: [PATCH] boost: Update to 1.71.0-beta1
Some notes:
- bjam bootstrap scripts were changed, and the patch for that had to be
adjusted. tools/build/src/engine/build.sh now supports
The debug output didn't match the calculation - it showed a wrong value.
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 682858dc95..25b0ead9bf 100644
--- a/meta/classes/image.bbclass
+
On 25.07.19 23:57, Richard Purdie wrote:
> We definitely should sort to make things deterministic. Since I don't
> want to forget this I've added a patch into my testing queue.
OK, thanks! It would be great to have the patch backported to warrior
too, so I just re-sent your patch for [warrior] for
From: Richard Purdie
Its possible in cases with multiple shlib providers we were not being
deterministic. Add in a couple of sorted() calls to fix the shlibs and
pkgconfig cases with this potential issue.
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 2 +-
meta/lib/oe/packag
Hi oe-core devs,
looking at package.bbclass and in particular the read_shlib_providers()
function (although, without having fully understood it):
For scanning the SHLIBSDIRS, it uses os.listdir() but seemingly without
sorting. There is a comment saying "the last one found wins". Couldn't
this cau
15 matches
Mail list logo
