On 10/10/2024 15:17, Richard Purdie wrote:
On Thu, 2024-10-10 at 13:25 +0800, Phil Reid via lists.openembedded.org
wrote:
Changes to the logic of is_work_shared where made in
commit: 5fbb4ca8da4f4f1ea426275c45634802dcb5a575
"archiver.bbclass: Improve work-shared checking"
The re
k dir, and the build subsequently fails.
Restore the previous logic while also mainting the referenced commits intent
to consider all recipes that use work-shared. Logic is now
inherits(gcc-source) or inherits(kernel) or srcin(work-shared)
Signed-off-by: Phil Reid
---
meta/classes/archiver.
ot;
KCONF_BSP_AUDIT_LEVEL = "1"
COMPATIBLE_MACHINE = "^(qemux86-64|cyclone5)$"
# Functionality flags
KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}"
KERNEL_PACKAGE_NAME = "kernel-tst"
KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig"
K
G'day José,
On 27/09/2024 16:51, Jose Quaresma wrote:
Phil Reid via lists.openembedded.org <http://lists.openembedded.org>
mailto:electromag.com...@lists.openembedded.org>> escreveu (sexta, 27/09/2024 à(s)
01:59):
G'day All,
Just started migrating our laye
ject.org/wiki/Patchtest. Thank
you!
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au
23 Junction Parade, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 71
end up in work-shared.
But something somewhere expects the kernel-source folder to be in work-shared
and ends up deleting the kernel-source folder
After do_patch the kernel-source still contains the source files.
The git checkout folder has gone by this step.
Then during do_unpack_and_patch th
couple of extra packages I'm after.
--
Regards
Phil Reid
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169902):
https://lists.openembedded.org/g/openembedded-core/message/169902
Mute This Topic: https://lists.openembedded.org/mt/93264443/21656
Group
On 14/07/2022 6:13 am, Richard Purdie wrote:
On Tue, 2022-07-12 at 13:23 +0800, Phil Reid wrote:
On 8/07/2022 9:05 pm, Richard Purdie wrote:
On Tue, 2022-07-05 at 21:01 -0700, mfum...@electromag.com.au wrote:
Hello there,
It isn't due to EOVERFLOW but make_file_type function in li
bexec/arm-emit-linux-gnueabi/gcc/arm-emit-linux-gnueabi/12.1.0/ld:
error:
/home/preid/dev/v2022.05/tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/gcc-runtime/12.1.0-r0/dummylib/libstdc++.so:
file is empty
collect2: error: ld returned 1 exit status
configure:15761: $? = 1
--
Regards
Phil Reid
G'day All,
We're just updating from honister to kirkstone branch and run into
an issue with libstdc++. We're targeting a 32 bit arm device.
is_empty throws with "filesystem error: cannot check if file is empty: Operation not
supported"
when called on an empty directory.
tracing this status is
= "0" in the emit-image-init recipe but that
had no effect.
Any suggestions appreciated.
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au
23 Junction Parade, Midland WA 6056, A
On 26/02/2021 07:56, Phil Reid wrote:
On 25/02/2021 18:29, Richard Purdie wrote:
On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
G'day,
Not really sure where to look for this. But started to get random build failures
with the pseudo client.
Failures are contained to populate_sdk
On 25/02/2021 18:29, Richard Purdie wrote:
On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
G'day,
Not really sure where to look for this. But started to get random build failures
with the pseudo client.
Failures are contained to populate_sdk
Not always the same file reported in th
t-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp
-rw-r--r--. 4 cb cb 2100 Feb 24 09:59
tmp-glibc/sysroots-components/cortexa9t2hf-neon/boost/usr/include/boost/flyweight/detail/recursive_l
On 17/02/2020 17:55, Richard Purdie wrote:
On Mon, 2020-02-17 at 07:44 +0100, Andrey Zhizhikin wrote:
On Mon, Feb 17, 2020 at 4:26 AM Phil Reid
wrote:
Hi All,
I recently started get the following failure with bash after
"b348e31c93f0 bash: Fix CVE-2019-18276"
was applied to
/glob.tests
patching file tests/glob6.sub
patching file tests/glob7.sub
Patch bash-CVE-2019-18276.patch does not apply (enforce with -f)
DEBUG: Python function patch_do_patch finished
DEBUG: Python function do_patch finished
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Development of
vides-dummy-1.0-r0.9.sdk-provides-dummy-target
* - do not ask to install a package providing target-sdk-provides-dummy-dev
* Solution 2:
* - do not ask to install a package providing busybox-dev
Not sure what is request busybox-dev to be istalled in the sdk.
Any thoughts?
--
Regards
Phil
d=8939
But told we need to update the recipes on a recipe by recipe.
I'm still learning bitbake, yocto and angstron relationships.
So far I at a loss on where to look.
eg: getting a problem with glib-2.22 which I can only find references to in
openembedded-core.
But they sug
itbake. This may be due to host contamination [host-user-contaminated]
perl-5.22.0: perl: /perl-dbg/usr/src/debug/perl/5.22.0-r0/perl-5.22.0/ext/re/re_exec.c is owned by uid 1000, which is the same as the user running bitbake. This
may be due to host contamination [host-user-contam
Andreas
I'm seeing similar warnings as well.
I'm building from /home which I believe is susposed to be exempt from this test.
Not sure how to fix / avoid the problem.
--
Regards
Phil Reid
--
___
Openembedded-core mailing list
Openemb
20 matches
Mail list logo
