Actually, I found the upstream patch I backported, which you're probably
better off using (same diff though).
https://lore.kernel.org/patchwork/patch/773330/
On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org
wrote:
> I'm not sure if this is your issue, but I had a similar
I'm not sure if this is your issue, but I had a similar issue ilog2 and the
disassembler and fixed it by backporting this patch.
No guarantees, but perhaps it will help.
--Aaron
On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin
wrote:
> Thanks a lot for the advice! However, I can't seem to
Applied, thanks!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52163): https://lists.yoctoproject.org/g/yocto/message/52163
Mute This Topic: https://lists.yoctoproject.org/mt/80121196/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Thanks a lot for the advice! However, I can't seem to find a `const` that I
can simply remove. To give more context, here is the log output around such
an error (it seems like it is often surrounded by this log2.h warning, by
the way):
| In file included from
>
I need some help in understanding why the SDK EXT is failing to build under
zeus...
Can someone explain why the extended sdk build fails and how I might resolve ?
sbcb-defaultfs kernel builds and boots correctly...
SDK builds under zeus for sbcb-defaultfs :
bitbake sbcb-defaultfs-full -c
thanks for the hint :-)
it did it however I run in other problems:
My goal is to cross-compile executable scripts into binaries using shc
tool: https://github.com/neurobin/shc
the SHC tool converts the scripts into C files, inherits the CC, CFLAGS and
LDFLAGS from environment and compiles them
On Fri, 2021-01-29 at 13:48 -0600, Andrew Geissler wrote:
>
> > On Jan 29, 2021, at 10:54 AM, Richard Purdie
> > wrote:
> >
> > On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
> > > > What was SDKMACHINE set to before?
> > >
> > > Hey Richard, thanks for the quick response.
> > >
The issue here is that you are overwriting the DEPENDS after the inherit.
Two ways to solve this problem
Either use
DEPENDS = "python3-astropy-helpers"
PYPI_PACKAGE = "astropy"
inherit pypi
or
PYPI_PACKAGE = "astropy"
inherit pypi
DEPENDS += "python3-astropy-helpers"
python3-setuptools
I'm attempting to make a simple bitbake recipe for python3-astropy that
inherits from pypi and setuptools3. The very simple recipe is attached.
When I build I'm getting this error:
>
>
>
> | import pkg_resources
>
>
>
> | ModuleNotFoundError: No module named 'pkg_resources'
>
>
>
>
On 2021-01-29 3:11 p.m., Randy MacLeod wrote:
Did you figure this out?
Oops, I see that Khem has replied to a later email.
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52156):
On 2021-01-04 3:43 a.m., safouane maaloul wrote:
Bonjour, j'essaye d'ajouter le aom plugin au niveau de la
gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je
commence à faire lebuild. J'avais un problème de lisence. Je l'ai
résolu. Et maintenant j'ai un problème "no such file or
> On Jan 29, 2021, at 10:54 AM, Richard Purdie
> wrote:
>
> On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
>>> What was SDKMACHINE set to before?
>>
>> Hey Richard, thanks for the quick response.
>>
>> We did not have it set. It looks like this recent commit is what
>> changed
On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
> > What was SDKMACHINE set to before?
>
> Hey Richard, thanks for the quick response.
>
> We did not have it set. It looks like this recent commit is what
> changed things on us:
>
> commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
>
> What was SDKMACHINE set to before?
Hey Richard, thanks for the quick response.
We did not have it set. It looks like this recent commit is what changed things
on us:
commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton
Date: Tue Dec 22 17:23:14 2020 +
bitbake.conf:
On Fri, 2021-01-29 at 06:38 -0800, Andrew Geissler wrote:
> Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our
> CI.
>
> Our latest rebase of poky master
> (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/) has
> started failing to compile on our ppc64le machines
From: Matt Hoosier
Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS records.
Network access is not allowed at that point in the
From: Mauro Queirós
Function "contains_lfs" was only looking at the master branch when searching
for LFS
content. LFS may be configured in specific branches only, so we need to use the
correct branch.
(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)
Signed-off-by: Mauro Queiros
From: Mauro Queirós
Git-LFS objects were being fetched even when lfs=0 was not set.
This patch disables LFS smudging when lfs=0. That way, only the LFS pointers
are downloaded during checkout.
(Bitbake rev: 646d86df7de774255246a3d7051c308e43eb257d)
Signed-off-by: Mauro Queiros
Signed-off-by:
Sorry, third patch needs to be backported from master for git lfs to work
nicely on dunfell. Will send a v2.
-Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52147): https://lists.yoctoproject.org/g/yocto/message/52147
Mute This Topic:
Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our CI.
Our latest rebase of poky master (
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/ ) has started
failing to compile on our ppc64le machines with the below error.
I can workaround it by setting
From: Matt Hoosier
Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS records.
Network access is not allowed at that point in the
From: Mauro Queirós
Function "contains_lfs" was only looking at the master branch when searching
for LFS
content. LFS may be configured in specific branches only, so we need to use the
correct branch.
(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)
Signed-off-by: Mauro Queiros
On Thu, 2021-01-28 at 16:18 +0100, Marek Belisko wrote:
> Hi,
>
> I have repo where I'm using lfs. I've added to my SRC_URI =
> "git://.. ;lfs=1" and the project is fetched but the issue is that
> lfs files are shown as references only (content is not fetched).
> I briefly checked git fetcher
Signed-off-by: Richard Purdie
---
README | 6 ++
1 file changed, 6 insertions(+)
diff --git a/README b/README
index c17f74a..af3ace9 100644
--- a/README
+++ b/README
@@ -15,3 +15,9 @@ Layer Maintainer: Joshua Watt
Please send changes to the yocto mailing list with [meta-mingw] in the
Signed-off-by: Richard Purdie
---
.../libiconv/libiconv/autoconf270.patch | 17 +
recipes-support/libiconv/libiconv_1.15.bb | 3 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 recipes-support/libiconv/libiconv/autoconf270.patch
diff --git
Signed-off-by: Richard Purdie
---
.../grep/grep-2.5.1a/autoconf270.patch| 27 +++
recipes-extended/grep/grep_2.5.1a.bb | 1 +
2 files changed, 28 insertions(+)
create mode 100644 recipes-extended/grep/grep-2.5.1a/autoconf270.patch
diff --git
Signed-off-by: Richard Purdie
---
.../diffutils/diffutils-2.8.1/autoconf270.patch | 17 +
recipes-extended/diffutils/diffutils_2.8.1.bb | 1 +
2 files changed, 18 insertions(+)
create mode 100644 recipes-extended/diffutils/diffutils-2.8.1/autoconf270.patch
diff --git
Signed-off-by: Richard Purdie
---
.../bash/bash-3.2.57/autoconf270.patch | 17 +
recipes-extended/bash/bash_3.2.57.bb| 1 +
2 files changed, 18 insertions(+)
create mode 100644 recipes-extended/bash/bash-3.2.57/autoconf270.patch
diff --git
On Wed, Jan 27, 2021 at 8:01 PM Martin Townsend wrote:
>
> On Wed, Jan 27, 2021 at 6:21 PM Martin Townsend
> wrote:
> >
> > Hi,
> >
> > I'm trying to get an initramfs working so I can load firmware early
> > enough in the boot. So I've created an initramfs with the firmware
> > files and a
29 matches
Mail list logo
