Date   

[meta-cgl][PATCH 2/3] ocfs2-tools: add UPSTREAM_CHECK_GITTAGREGEX

Yi Zhao
 

Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version.

Before the patch:
$ devtool latest-version ocfs2-tools
INFO: Current version: 1.8.6
INFO: Latest version: 2
INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6

After the patch:
$ devtool latest-version ocfs2-tools
INFO: Current version: 1.8.6
INFO: Latest version: 1.8.7
INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6

Signed-off-by: Yi Zhao <yi.zhao@...>
---
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
index 7c32c54..28ef4b0 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
@@ -22,6 +22,9 @@ SRC_URI = "git://github.com/markfasheh/ocfs2-tools;branch=master;protocol=https
file://0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch \
"
SRCREV = "4d76ceb4aa7aaa1fd595368089e99575d708f719"
+
+UPSTREAM_CHECK_GITTAGREGEX = "ocfs2-tools-(?P<pver>\d+(\.\d+)+)"
+
S = "${WORKDIR}/git"

inherit autotools-brokensep pkgconfig systemd
--
2.25.1


[meta-cgl][PATCH 1/3] resource-agents: add UPSTREAM_CHECK_GITTAGREGEX

Yi Zhao
 

Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version.

Before the patch:
$ devtool latest-version resource-agents
INFO: Current version: 4.5.0
INFO: Latest version: 10
INFO: Latest version's commit: 5cf93783eafa22e8b82d50834bfb76b9e8434783

After the patch:
$ devtool latest-version resource-agents
INFO: Current version: 4.5.0
INFO: Latest version: 4.10.0
INFO: Latest version's commit: fd0720f73a06042ad0a5475a3398096b2912cf5f

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../cluster-resource-agents/resource-agents_4.5.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
index 00ddd22..c8b2fbd 100644
--- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
@@ -24,6 +24,8 @@ SRC_URI = "git://github.com/ClusterLabs/resource-agents;branch=main;protocol=htt

SRCREV = "fee181320547365d7f8c88cca2b32801412b933d"

+UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)"
+
S="${WORKDIR}/git"

LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
--
2.25.1


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Wed, Dec 29, 2021 at 6:15 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote:



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.
You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2
Sorry Khem, I'm not quite following you. I tried the following patch
(https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you
meant however my build configuration still shows the tune set to
mips32r2 https://pastebin.com/izP9thVW

What am I missing?
Nevermind, I scraped the last patch, recreated my BUILD_DIR, set
MACHINE = "qemumips" and added DEFAULTTUNE = "mips" in my local.conf.
Now the build configuration correct https://pastebin.com/pkkRVL58 and
I'm now waiting for the toolchain to finish so I can attempt to build
realtek's u-boot.





Regards,
Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote:



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.
You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2
Sorry Khem, I'm not quite following you. I tried the following patch
(https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you
meant however my build configuration still shows the tune set to
mips32r2 https://pastebin.com/izP9thVW

What am I missing?





Regards,
Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

Khem Raj
 



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:
On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:
>
> Hi,
>
> > On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:
> >
> > I generated an internal mips toolchain built against musl and I tried
> > to compile u-boot but unfortunately, I'm getting "opcode not
> > supported" error messages. https://pastebin.com/QdcLxy69
> > If instead I use the realtek provided prebuilt toolchain then u-boot
> > compiles successfully. https://pastebin.com/zcQ5kc20
> >
> > I'm thinking that Realtek's toolchain has patches specific to their
> > SoC that have not been pushed upstream. Could this be the reason I'm
> > unable to compile uboot?
>
> I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.

You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2


>
> Regards,
> Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.
You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?


Regards,
Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

Anders Montonen
 

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.

Regards,
Anders Montonen


Re: [meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option

Andreas Müller
 

On Thu, Dec 9, 2021 at 6:37 AM Khem Raj <raj.khem@...> wrote:



On Wed, Dec 8, 2021 at 7:03 PM Yu, Mingli <mingli.yu@...> wrote:

From: Mingli Yu <mingli.yu@...>

After the commit [1] introduced in openembedded-core layer,
some configure options is't carried over include xshmfence
option, so remove the xshmfence configure option to silence
the below warning.
WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue: xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig]

That’s ok to remove it but more importantly does it work now without this option
Looked into xserver's meson.build: As soon as dri3 is added - which
we do - libxshmfence turns into a mandatory dependency. So this patch
is correct.
Somehow libxshmfence is added to sysroot - maybe we should add it
explicitly to dri3 PACKAGECONFIG in oe-core to be more explicit.

Slightly off-topic but we are on xserver on Raspi: Has anybody tested
xserver recently? I see nasty issues on raspi4-64 / XFCE (haven't
tried other desktops yet):

* As soon as a window is opened, screen turns black for 1-2 seconds.
Have not yet found helpful in logs yet.
* There are two mouse devices detected with name 'vc4'. What?

Cheers

Andreas


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Tue, Dec 28, 2021 at 10:09 PM Khem Raj <raj.khem@...> wrote:



On 12/28/21 2:53 PM, davis roman wrote:
Hi all,

I'm working on a project utilizing a Realtek RTS3916N mips SoC and as
part of Realtek's bsp offering, they provide their own fork of
buildroot packaged with their prebuilt binary toolchain.
I would much rather use yocto instead however Realtek made it clear
that no yocto support is available from their end and they have no
plans to provide it in the future.

In theory, I have Realtek's u-boot and kernel source so it should be
possible to build an image so long as poky is instructed to use an
external toolchain. This is where I hit my first road block because
Realtek only supports uClibc and I know the yocto community moved way
from uClibc, in favor of musl, since the Morty release. As a result, I
decided to use Krogoth-15.0.0 (knowing it's EOL) only because it
supports uClibc.

Now that I had picked a specific version of poky, I continued forward
with the EXTERNAL_TOOLCHAIN feature. The documentation references the
meta-sourcery layer as the typical use case. Using a sourcery
toolchain tarball ( 2014.05) I was able to build qemuarm/glibc
therefore as far as I can tell the EXTERNAL_TOOLCHAIN feature works as
documented.

Unfortunately, the issue I have now arises when I use the Realtek
toolchain. meta-sourcery informs me that building against uClibc is
not allowed as it has been blacklisted. Only glibc appears to be
supported.

I have looked around to see what other projects are similar and the
closest I can find is the creator CI20 however due to the Realtek
toolchain being based on uClibc, I haven't been able to find anything
suitable for my usecase.

I would greatly appreciate any suggestions regarding how to proceed
forward with yocto integration, using a mips uClibc based toolchain.
We have dropped uclibc support long time ago so any effort to support
uClibc based system will be a bit of work and we have also dropped stale
patches from metadata so even if you are able to get external toolchain
bolted in, you will unfurl next set of problems for yourself So I don't
have a better answer for you here, other than drop the idea of using
uclibc if you want to use modern yocto baseline. We did support it long
time ago so if you like you can use thise EOLed releases but there wont
be much support for it here on community mailing lists.
Thanks Khem for confirming my suspicions.

Is there any other course of action that I can try?
Since you have bootloader and kernel available to you, it might be less
work to put together a BSP layer and machine definition for this SOC
easily and it could be forward looking but there could be some
portability issues w.r.t. toolchain etc. which are manageable
here you will use internal mips toolchain to build your system and you
can use musl instead of uclibc to build the system or glibc is other
supported option.
I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?


Thank you,

Davis





Re: unparsed line #yocto

Michael Ho
 

It looks like you have a dunfell yocto setup which doesn't support that new recipe syntax. Maybe you need to check out the dunfell branch of those meta layers to get them to be compatible.

Michael

On Tue, 28 Dec 2021, 7:12 pm Kevin Kettinger, <kkettinger@...> wrote:
Hello,

after including the meta-qt5 and meta-boot2qt layer from https://code.qt.io/cgit/yocto, and adding them to my bblayers.conf, bitbake breaks directly while parsing the recipes:
---------------------------------------------
ERROR: ParseError at /home/yocto/projects/faseroptik-dunfell/build/../layers/meta-qt5/classes/cmake_qt5.bbclass:4: unparsed line: 'DEPENDS:prepend = "${QTBASEDEPENDS} "'                                                                                                                                    | ETA:  --:--:--

Summary: There was 1 ERROR message shown, returning a non-zero exit code.
---------------------------------------------

If i restart bitbake, the offending file changes now and then, but just for completion, here is the file:
---------------------------------------------
inherit cmake
inherit qmake5_paths

DEPENDS:prepend = "${QTBASEDEPENDS} "
QTBASEDEPENDS = "qtbase qtbase-native"
QTBASEDEPENDS:class-native = "qtbase-native"
QTBASEDEPENDS:class-nativesdk = "nativesdk-qtbase qtbase-native"

EXTRA_OECMAKE:prepend = " \
    -DOE_QMAKE_PATH_PREFIX=${OE_QMAKE_PATH_PREFIX} \
    -DOE_QMAKE_PATH_HEADERS=${OE_QMAKE_PATH_HEADERS} \
    -DOE_QMAKE_PATH_LIBS=${OE_QMAKE_PATH_LIBS} \
    -DOE_QMAKE_PATH_ARCHDATA=${OE_QMAKE_PATH_ARCHDATA} \
    -DOE_QMAKE_PATH_DATA=${OE_QMAKE_PATH_DATA} \
    -DOE_QMAKE_PATH_BINS=${OE_QMAKE_PATH_BINS} \
    -DOE_QMAKE_PATH_LIBEXECS=${OE_QMAKE_PATH_LIBEXECS} \
    -DOE_QMAKE_PATH_PLUGINS=${OE_QMAKE_PATH_PLUGINS} \
    -DOE_QMAKE_PATH_QML=${OE_QMAKE_PATH_QML} \
    -DOE_QMAKE_PATH_TRANSLATIONS=${OE_QMAKE_PATH_TRANSLATIONS} \
    -DOE_QMAKE_PATH_DOCS=${OE_QMAKE_PATH_DOCS} \
    -DOE_QMAKE_PATH_SETTINGS=${OE_QMAKE_PATH_SETTINGS} \
    -DOE_QMAKE_PATH_EXAMPLES=${OE_QMAKE_PATH_EXAMPLES} \
    -DOE_QMAKE_PATH_TESTS=${OE_QMAKE_PATH_TESTS} \
    -DOE_QMAKE_PATH_HOST_PREFIX=${OE_QMAKE_PATH_HOST_PREFIX} \
    -DOE_QMAKE_PATH_HOST_BINS=${OE_QMAKE_PATH_HOST_BINS} \
    -DOE_QMAKE_PATH_HOST_DATA=${OE_QMAKE_PATH_HOST_DATA} \
    -DOE_QMAKE_PATH_HOST_LIBS=${OE_QMAKE_PATH_HOST_LIBS} \
    -DOE_QMAKE_PATH_EXTERNAL_HOST_BINS=${OE_QMAKE_PATH_EXTERNAL_HOST_BINS} \
    -DOE_QMAKE_PATH_QT_HEADERS=${OE_QMAKE_PATH_QT_HEADERS} \
    -DOE_QMAKE_PATH_QT_ARCHDATA=${OE_QMAKE_PATH_QT_ARCHDATA} \
    -DOE_QMAKE_PATH_QT_DATA=${OE_QMAKE_PATH_QT_DATA} \
    -DOE_QMAKE_PATH_QT_BINS=${OE_QMAKE_PATH_QT_BINS} \
    -DOE_QMAKE_PATH_QT_TRANSLATIONS=${OE_QMAKE_PATH_QT_TRANSLATIONS} \
    -DOE_QMAKE_PATH_QT_DOCS=${OE_QMAKE_PATH_QT_DOCS} \
    -DOE_QMAKE_PATH_QT_SETTINGS=${OE_QMAKE_PATH_QT_SETTINGS} \
    -DOE_QMAKE_PATH_QT_EXAMPLES=${OE_QMAKE_PATH_QT_EXAMPLES} \
    -DOE_QMAKE_PATH_QT_TESTS=${OE_QMAKE_PATH_QT_TESTS} \
"
---------------------------------------------

The exact same layer with the exact same commit & files is working fine on the original boot2qt environment, but not on my environment.

My bblayers.conf looks like this:
---------------------------------------------
LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${TOPDIR}/../layers/meta-toradex-nxp \
  ${TOPDIR}/../layers/meta-freescale \
  ${TOPDIR}/../layers/meta-freescale-3rdparty \
  ${TOPDIR}/../layers/meta-toradex-tegra \
  ${TOPDIR}/../layers/meta-toradex-bsp-common \
  ${TOPDIR}/../layers/meta-openembedded/meta-oe \
  ${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
  ${TOPDIR}/../layers/meta-openembedded/meta-gnome \
  ${TOPDIR}/../layers/meta-openembedded/meta-xfce \
  ${TOPDIR}/../layers/meta-openembedded/meta-initramfs \
  ${TOPDIR}/../layers/meta-openembedded/meta-networking \
  ${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
  ${TOPDIR}/../layers/meta-openembedded/meta-python \
  ${TOPDIR}/../layers/meta-freescale-distro \
  ${TOPDIR}/../layers/meta-toradex-demos \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt-distro \
  ${TOPDIR}/../layers/meta-qt5 \
  ${TOPDIR}/../layers/meta-toradex-distro \
  ${TOPDIR}/../layers/meta-yocto/meta-poky \
  ${TOPDIR}/../layers/openembedded-core/meta \
  ${TOPDIR}/../layers/meta-mender/meta-mender-core \
  ${TOPDIR}/../layers/meta-mender-community/meta-mender-toradex-nxp \
  ${TOPDIR}/../layers/meta-mender/meta-mender-demo \
  "
---------------------------------------------

On the working boot2qt environment poky 3.1.11 is used, i'm using poky 3.1.8.

Is there anything i can do to track this issue down? bitbake -v doesn't report more infos.

I appreciate any help here, thank you.

Best regards,
Kevin



Re: /bin/sh: 1: bison: not found while compiling own kernel module with poky-dunfell #bitbake

Markus Volk
 

hello,

try to add 'bison-native' to DEPENDS.

Am 29.12.21 um 07:16 schrieb prashantsingh@...:

hello team,
I'm trying to build my own kernel module with yocto for raspberry-pi kernel, but it's giving me error that "bison not found", as-

DEBUG: Executing shell function do_compile
NOTE: make -j 12 KERNEL_SRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source KSRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts KERNEL_PATH=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source KERNEL_VERSION=5.4.72-v7 CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork -marm -fuse-ld=bfd -fmacro-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot-native=  -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source=/usr/src/kernel LD=arm-poky-linux-gnueabi-ld.bfd   AR=arm-poky-linux-gnueabi-ar  O=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
make -C /home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts SUBDIRS=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0 modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'
  GEN     Makefile
  YACC    scripts/kconfig/parser.tab.[ch]
/bin/sh: 1: bison: not found
make[4]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Error 127
make[3]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:590: syncconfig] Error 2
make[2]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:696: include/config/auto.conf.cmd] Error 2
make[1]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:179: sub-make] Error 2
make[1]: Leaving directory '/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'
make: *** [Makefile:19: default] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.


Here is my bb file for the same-

SUMMARY = "WAN IC asix kernel module"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=014e508ee78ef83e5007b9cb3834f0e9"

DEPENDS = "virtual/kernel bc bison"

inherit module

PR = "r0"
PV = "1.0"

SRC_URI = "file://Makefile \
          file://asix.c \
          file://asix.h \
          file://axusbnet.c \
          file://axusbnet.h \
          file://command.h \
          file://debug.txt \
          file://eeprom_data.tar.bz2 \
          file://ioctl.c \
          file://ioctl.h \
          file://ioctl_readme \
          file://readme \
          file://readme \
          file://LICENSE \
"

S = "${WORKDIR}"

export TARGET_SYS
EXTRA_OEMAKE += "KSRC=${STAGING_KERNEL_BUILDDIR}"

do_compile_append() {
        ${CC} ioctl.c -o ioctl
}

do_install_prepend() {
        export DESTDIR="${D}"
}




# The inherit of module.bbclass will automatically name module packages with
# "kernel-module-" prefix as required by the oe-core build environment.



Same kernel module with poky zeus and rpi kernel 4.19 got compiled successfully, but here I'm getting issue with poky dunfell with Rpi kernel 5.4

Please help me resolve this issue.

Thanks.



/bin/sh: 1: bison: not found while compiling own kernel module with poky-dunfell #bitbake

@prashant2314
 

hello team,
I'm trying to build my own kernel module with yocto for raspberry-pi kernel, but it's giving me error that "bison not found", as-

DEBUG: Executing shell function do_compile
NOTE: make -j 12 KERNEL_SRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source KSRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts KERNEL_PATH=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source KERNEL_VERSION=5.4.72-v7 CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork -marm -fuse-ld=bfd -fmacro-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot-native=  -fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source=/usr/src/kernel LD=arm-poky-linux-gnueabi-ld.bfd   AR=arm-poky-linux-gnueabi-ar  O=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
make -C /home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts SUBDIRS=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0 modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'
  GEN     Makefile
  YACC    scripts/kconfig/parser.tab.[ch]
/bin/sh: 1: bison: not found
make[4]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Error 127
make[3]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:590: syncconfig] Error 2
make[2]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:696: include/config/auto.conf.cmd] Error 2
make[1]: *** [/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:179: sub-make] Error 2
make[1]: Leaving directory '/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'
make: *** [Makefile:19: default] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.


Here is my bb file for the same-

SUMMARY = "WAN IC asix kernel module"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=014e508ee78ef83e5007b9cb3834f0e9"

DEPENDS = "virtual/kernel bc bison"

inherit module

PR = "r0"
PV = "1.0"

SRC_URI = "file://Makefile \
          file://asix.c \
          file://asix.h \
          file://axusbnet.c \
          file://axusbnet.h \
          file://command.h \
          file://debug.txt \
          file://eeprom_data.tar.bz2 \
          file://ioctl.c \
          file://ioctl.h \
          file://ioctl_readme \
          file://readme \
          file://readme \
          file://LICENSE \
"

S = "${WORKDIR}"

export TARGET_SYS
EXTRA_OEMAKE += "KSRC=${STAGING_KERNEL_BUILDDIR}"

do_compile_append() {
        ${CC} ioctl.c -o ioctl
}

do_install_prepend() {
        export DESTDIR="${D}"
}




# The inherit of module.bbclass will automatically name module packages with
# "kernel-module-" prefix as required by the oe-core build environment.



Same kernel module with poky zeus and rpi kernel 4.19 got compiled successfully, but here I'm getting issue with poky dunfell with Rpi kernel 5.4

Please help me resolve this issue.

Thanks.


[meta-cgl-common][PATCH] pacemaker: use main branch

Yu, Mingli
 

From: Mingli Yu <mingli.yu@...>

Use the main branch to fix do_fetch error.

Signed-off-by: Mingli Yu <mingli.yu@...>
---
meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
index f9a0bf7..3bff2ba 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
@@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=000212f361a81b100d9d0f0435040663"

DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native"

-SRC_URI = "git://github.com/ClusterLabs/${BPN}.git;branch=master;protocol=https \
+SRC_URI = "git://github.com/ClusterLabs/${BPN}.git;branch=main;protocol=https \
file://0001-Fix-python3-usage.patch \
file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch \
file://volatiles \
--
2.17.1


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

Khem Raj
 

On 12/28/21 2:53 PM, davis roman wrote:
Hi all,
I'm working on a project utilizing a Realtek RTS3916N mips SoC and as
part of Realtek's bsp offering, they provide their own fork of
buildroot packaged with their prebuilt binary toolchain.
I would much rather use yocto instead however Realtek made it clear
that no yocto support is available from their end and they have no
plans to provide it in the future.
In theory, I have Realtek's u-boot and kernel source so it should be
possible to build an image so long as poky is instructed to use an
external toolchain. This is where I hit my first road block because
Realtek only supports uClibc and I know the yocto community moved way
from uClibc, in favor of musl, since the Morty release. As a result, I
decided to use Krogoth-15.0.0 (knowing it's EOL) only because it
supports uClibc.
Now that I had picked a specific version of poky, I continued forward
with the EXTERNAL_TOOLCHAIN feature. The documentation references the
meta-sourcery layer as the typical use case. Using a sourcery
toolchain tarball ( 2014.05) I was able to build qemuarm/glibc
therefore as far as I can tell the EXTERNAL_TOOLCHAIN feature works as
documented.
Unfortunately, the issue I have now arises when I use the Realtek
toolchain. meta-sourcery informs me that building against uClibc is
not allowed as it has been blacklisted. Only glibc appears to be
supported.
I have looked around to see what other projects are similar and the
closest I can find is the creator CI20 however due to the Realtek
toolchain being based on uClibc, I haven't been able to find anything
suitable for my usecase.
I would greatly appreciate any suggestions regarding how to proceed
forward with yocto integration, using a mips uClibc based toolchain.
We have dropped uclibc support long time ago so any effort to support uClibc based system will be a bit of work and we have also dropped stale patches from metadata so even if you are able to get external toolchain bolted in, you will unfurl next set of problems for yourself So I don't have a better answer for you here, other than drop the idea of using uclibc if you want to use modern yocto baseline. We did support it long time ago so if you like you can use thise EOLed releases but there wont be much support for it here on community mailing lists.

Is there any other course of action that I can try?
Since you have bootloader and kernel available to you, it might be less work to put together a BSP layer and machine definition for this SOC easily and it could be forward looking but there could be some portability issues w.r.t. toolchain etc. which are manageable
here you will use internal mips toolchain to build your system and you can use musl instead of uclibc to build the system or glibc is other supported option.

Thank you,
Davis


building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

Hi all,

I'm working on a project utilizing a Realtek RTS3916N mips SoC and as
part of Realtek's bsp offering, they provide their own fork of
buildroot packaged with their prebuilt binary toolchain.
I would much rather use yocto instead however Realtek made it clear
that no yocto support is available from their end and they have no
plans to provide it in the future.

In theory, I have Realtek's u-boot and kernel source so it should be
possible to build an image so long as poky is instructed to use an
external toolchain. This is where I hit my first road block because
Realtek only supports uClibc and I know the yocto community moved way
from uClibc, in favor of musl, since the Morty release. As a result, I
decided to use Krogoth-15.0.0 (knowing it's EOL) only because it
supports uClibc.

Now that I had picked a specific version of poky, I continued forward
with the EXTERNAL_TOOLCHAIN feature. The documentation references the
meta-sourcery layer as the typical use case. Using a sourcery
toolchain tarball ( 2014.05) I was able to build qemuarm/glibc
therefore as far as I can tell the EXTERNAL_TOOLCHAIN feature works as
documented.

Unfortunately, the issue I have now arises when I use the Realtek
toolchain. meta-sourcery informs me that building against uClibc is
not allowed as it has been blacklisted. Only glibc appears to be
supported.

I have looked around to see what other projects are similar and the
closest I can find is the creator CI20 however due to the Realtek
toolchain being based on uClibc, I haven't been able to find anything
suitable for my usecase.

I would greatly appreciate any suggestions regarding how to proceed
forward with yocto integration, using a mips uClibc based toolchain.

Is there any other course of action that I can try?

Thank you,

Davis


[meta-security][PATCH 2/2] meta-tpm: drop strongswan bbappends

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
...rmi-Only-build-if-libcharon-is-built.patch | 38 -------------------
.../strongswan/strongswan-tpm.inc | 12 ------
.../strongswan/strongswan_5.%.bbappend | 1 -
3 files changed, 51 deletions(-)
delete mode 100644 meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/files/0001-xfrmi-Only-build-if-libcharon-is-built.patch
delete mode 100644 meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-tpm.inc
delete mode 100644 meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend

diff --git a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/files/0001-xfrmi-Only-build-if-libcharon-is-built.patch b/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/files/0001-xfrmi-Only-build-if-libcharon-is-built.patch
deleted file mode 100644
index 8250282..0000000
--- a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/files/0001-xfrmi-Only-build-if-libcharon-is-built.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From db772305c6baa01f6c6750be74733e4bfc1d6106 Mon Sep 17 00:00:00 2001
-From: Tobias Brunner <tobias@...>
-Date: Tue, 14 Apr 2020 10:44:19 +0200
-Subject: [PATCH] xfrmi: Only build if libcharon is built
-
-The kernel-netlink plugin is only built if libcharon is.
-
-Closes strongswan/strongswan#167.
-
-Upstream-Status: Backport
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- src/Makefile.am | 7 +++----
- 1 file changed, 3 insertions(+), 4 deletions(-)
-
-Index: strongswan-5.8.4/src/Makefile.am
-===================================================================
---- strongswan-5.8.4.orig/src/Makefile.am
-+++ strongswan-5.8.4/src/Makefile.am
-@@ -42,6 +42,9 @@ endif
-
- if USE_LIBCHARON
- SUBDIRS += libcharon
-+if USE_KERNEL_NETLINK
-+ SUBDIRS += xfrmi
-+endif
- endif
-
- if USE_FILE_CONFIG
-@@ -143,7 +146,3 @@ endif
- if USE_TPM
- SUBDIRS += tpm_extendpcr
- endif
--
--if USE_KERNEL_NETLINK
-- SUBDIRS += xfrmi
--endif
diff --git a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-tpm.inc b/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-tpm.inc
deleted file mode 100644
index 497474f..0000000
--- a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-tpm.inc
+++ /dev/null
@@ -1,12 +0,0 @@
-FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
-
-DEPENDS = "libtspi"
-
-SRC_URI:append = " file://0001-xfrmi-Only-build-if-libcharon-is-built.patch"
-
-PACKAGECONFIG += "aikgen tpm"
-
-PACKAGECONFIG[tpm] = "--enable-tpm,--disable-tpm,,"
-PACKAGECONFIG[aikgen] = "--enable-aikgen,--disable-aikgen,,"
-
-EXTRA_OECONF += "--with-linux-headers=${STAGING_KERNEL_DIR}"
diff --git a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend b/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend
deleted file mode 100644
index 34757bb..0000000
--- a/meta-tpm/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'tpm', 'strongswan-tpm.inc', '', d)}
--
2.25.1


[meta-security][PATCH 1/2] meta-integrity: drop strongswan bbappends

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../strongswan/strongswan-ima.inc | 61 -------------------
.../strongswan/strongswan_5.%.bbappend | 1 -
2 files changed, 62 deletions(-)
delete mode 100644 meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-ima.inc
delete mode 100644 meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend

diff --git a/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-ima.inc b/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-ima.inc
deleted file mode 100644
index 807075c..0000000
--- a/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan-ima.inc
+++ /dev/null
@@ -1,61 +0,0 @@
-FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
-
-DEPENDS = "libtspi"
-
-SRC_URI:append = " file://0001-xfrmi-Only-build-if-libcharon-is-built.patch"
-
-PACKAGECONFIG += " \
- aikgen \
- tpm \
-"
-
-PACKAGECONFIG[tpm] = "--enable-tpm,--disable-tpm,,"
-PACKAGECONFIG[aikgen] = "--enable-aikgen,--disable-aikgen,,"
-
-PACKAGECONFIG_ima += "\
- imc-test \
- imv-test \
- imc-scanner \
- imv-scanner \
- imc-os \
- imv-os \
- imc-attestation \
- imv-attestation \
- tnc-ifmap \
- tnc-imc \
- tnc-imv \
- tnc-pdp \
- tnccs-11 \
- tnccs-20 \
- tnccs-dynamic \
- "
-
-EXTRA_OECONF += "--with-linux-headers=${STAGING_KERNEL_DIR}"
-
-PACKAGECONFIG[imc-test] = "--enable-imc-test,--disable-imc-test,,"
-PACKAGECONFIG[imc-scanner] = "--enable-imc-scanner,--disable-imc-scanner,,"
-PACKAGECONFIG[imc-os] = "--enable-imc-os,--disable-imc-os,,"
-PACKAGECONFIG[imc-attestation] = "--enable-imc-attestation,--disable-imc-attestation,,"
-PACKAGECONFIG[imc-swima] = "--enable-imc-swima, --disable-imc-swima,,"
-PACKAGECONFIG[imc-hcd] = "--enable-imc-hcd, --disable-imc-hcd,,"
-PACKAGECONFIG[tnc-imc] = "--enable-tnc-imc,--disable-tnc-imc,,"
-
-PACKAGECONFIG[imv-test] = "--enable-imv-test,--disable-imv-test,,"
-PACKAGECONFIG[imv-scanner] = "--enable-imv-scanner,--disable-imv-scanner,,"
-PACKAGECONFIG[imv-os] = "--enable-imv-os,--disable-imv-os,,"
-PACKAGECONFIG[imv-attestation] = "--enable-imv-attestation,--disable-imv-attestation,,"
-PACKAGECONFIG[imv-swima] = "--enable-imv-swima, --disable-imv-swima,,"
-PACKAGECONFIG[imv-hcd] = "--enable-imv-hcd, --disable-imv-hcd,,"
-PACKAGECONFIG[tnc-imv] = "--enable-tnc-imv,--disable-tnc-imv,,"
-
-PACKAGECONFIG[tnc-ifmap] = "--enable-tnc-ifmap,--disable-tnc-ifmap,libxml2,"
-PACKAGECONFIG[tnc-pdp] = "--enable-tnc-pdp,--disable-tnc-pdp,,"
-
-PACKAGECONFIG[tnccs-11] = "--enable-tnccs-11,--disable-tnccs-11,libxml2,"
-PACKAGECONFIG[tnccs-20] = "--enable-tnccs-20,--disable-tnccs-20,,"
-PACKAGECONFIG[tnccs-dynamic] = "--enable-tnccs-dynamic,--disable-tnccs-dynamic,,"
-
-#FILES_${PN} += "${libdir}/ipsec/imcvs/*.so ${datadir}/regid.2004-03.org.strongswan"
-#FILES_${PN}-dbg += "${libdir}/ipsec/imcvs/.debug"
-#FILES_${PN}-dev += "${libdir}/ipsec/imcvs/*.la"
-#FILES_${PN}-staticdev += "${libdir}/ipsec/imcvs/*.a"
diff --git a/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend b/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend
deleted file mode 100644
index 4669fd2..0000000
--- a/meta-integrity/dynamic-layers/meta-networking/recipes-support/strongswan/strongswan_5.%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'imp', 'strongswan-ima.inc', '', d)}
--
2.25.1


Re: unparsed line #yocto

Kevin Kettinger
 

Thank you, after updating from 1.46.8 to 1.46.11 in the bitake repository (https://github.com/openembedded/bitbake) it is now parsing the recipes just fine.


Re: unparsed line #yocto

Martin Jansa
 

Upgrade bitbake to support new overrides syntax, see https://github.com/ros/meta-ros/pull/902


On Tue, Dec 28, 2021 at 7:12 PM Kevin Kettinger <kkettinger@...> wrote:
Hello,

after including the meta-qt5 and meta-boot2qt layer from https://code.qt.io/cgit/yocto, and adding them to my bblayers.conf, bitbake breaks directly while parsing the recipes:
---------------------------------------------
ERROR: ParseError at /home/yocto/projects/faseroptik-dunfell/build/../layers/meta-qt5/classes/cmake_qt5.bbclass:4: unparsed line: 'DEPENDS:prepend = "${QTBASEDEPENDS} "'                                                                                                                                    | ETA:  --:--:--

Summary: There was 1 ERROR message shown, returning a non-zero exit code.
---------------------------------------------

If i restart bitbake, the offending file changes now and then, but just for completion, here is the file:
---------------------------------------------
inherit cmake
inherit qmake5_paths

DEPENDS:prepend = "${QTBASEDEPENDS} "
QTBASEDEPENDS = "qtbase qtbase-native"
QTBASEDEPENDS:class-native = "qtbase-native"
QTBASEDEPENDS:class-nativesdk = "nativesdk-qtbase qtbase-native"

EXTRA_OECMAKE:prepend = " \
    -DOE_QMAKE_PATH_PREFIX=${OE_QMAKE_PATH_PREFIX} \
    -DOE_QMAKE_PATH_HEADERS=${OE_QMAKE_PATH_HEADERS} \
    -DOE_QMAKE_PATH_LIBS=${OE_QMAKE_PATH_LIBS} \
    -DOE_QMAKE_PATH_ARCHDATA=${OE_QMAKE_PATH_ARCHDATA} \
    -DOE_QMAKE_PATH_DATA=${OE_QMAKE_PATH_DATA} \
    -DOE_QMAKE_PATH_BINS=${OE_QMAKE_PATH_BINS} \
    -DOE_QMAKE_PATH_LIBEXECS=${OE_QMAKE_PATH_LIBEXECS} \
    -DOE_QMAKE_PATH_PLUGINS=${OE_QMAKE_PATH_PLUGINS} \
    -DOE_QMAKE_PATH_QML=${OE_QMAKE_PATH_QML} \
    -DOE_QMAKE_PATH_TRANSLATIONS=${OE_QMAKE_PATH_TRANSLATIONS} \
    -DOE_QMAKE_PATH_DOCS=${OE_QMAKE_PATH_DOCS} \
    -DOE_QMAKE_PATH_SETTINGS=${OE_QMAKE_PATH_SETTINGS} \
    -DOE_QMAKE_PATH_EXAMPLES=${OE_QMAKE_PATH_EXAMPLES} \
    -DOE_QMAKE_PATH_TESTS=${OE_QMAKE_PATH_TESTS} \
    -DOE_QMAKE_PATH_HOST_PREFIX=${OE_QMAKE_PATH_HOST_PREFIX} \
    -DOE_QMAKE_PATH_HOST_BINS=${OE_QMAKE_PATH_HOST_BINS} \
    -DOE_QMAKE_PATH_HOST_DATA=${OE_QMAKE_PATH_HOST_DATA} \
    -DOE_QMAKE_PATH_HOST_LIBS=${OE_QMAKE_PATH_HOST_LIBS} \
    -DOE_QMAKE_PATH_EXTERNAL_HOST_BINS=${OE_QMAKE_PATH_EXTERNAL_HOST_BINS} \
    -DOE_QMAKE_PATH_QT_HEADERS=${OE_QMAKE_PATH_QT_HEADERS} \
    -DOE_QMAKE_PATH_QT_ARCHDATA=${OE_QMAKE_PATH_QT_ARCHDATA} \
    -DOE_QMAKE_PATH_QT_DATA=${OE_QMAKE_PATH_QT_DATA} \
    -DOE_QMAKE_PATH_QT_BINS=${OE_QMAKE_PATH_QT_BINS} \
    -DOE_QMAKE_PATH_QT_TRANSLATIONS=${OE_QMAKE_PATH_QT_TRANSLATIONS} \
    -DOE_QMAKE_PATH_QT_DOCS=${OE_QMAKE_PATH_QT_DOCS} \
    -DOE_QMAKE_PATH_QT_SETTINGS=${OE_QMAKE_PATH_QT_SETTINGS} \
    -DOE_QMAKE_PATH_QT_EXAMPLES=${OE_QMAKE_PATH_QT_EXAMPLES} \
    -DOE_QMAKE_PATH_QT_TESTS=${OE_QMAKE_PATH_QT_TESTS} \
"
---------------------------------------------

The exact same layer with the exact same commit & files is working fine on the original boot2qt environment, but not on my environment.

My bblayers.conf looks like this:
---------------------------------------------
LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${TOPDIR}/../layers/meta-toradex-nxp \
  ${TOPDIR}/../layers/meta-freescale \
  ${TOPDIR}/../layers/meta-freescale-3rdparty \
  ${TOPDIR}/../layers/meta-toradex-tegra \
  ${TOPDIR}/../layers/meta-toradex-bsp-common \
  ${TOPDIR}/../layers/meta-openembedded/meta-oe \
  ${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
  ${TOPDIR}/../layers/meta-openembedded/meta-gnome \
  ${TOPDIR}/../layers/meta-openembedded/meta-xfce \
  ${TOPDIR}/../layers/meta-openembedded/meta-initramfs \
  ${TOPDIR}/../layers/meta-openembedded/meta-networking \
  ${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
  ${TOPDIR}/../layers/meta-openembedded/meta-python \
  ${TOPDIR}/../layers/meta-freescale-distro \
  ${TOPDIR}/../layers/meta-toradex-demos \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt-distro \
  ${TOPDIR}/../layers/meta-qt5 \
  ${TOPDIR}/../layers/meta-toradex-distro \
  ${TOPDIR}/../layers/meta-yocto/meta-poky \
  ${TOPDIR}/../layers/openembedded-core/meta \
  ${TOPDIR}/../layers/meta-mender/meta-mender-core \
  ${TOPDIR}/../layers/meta-mender-community/meta-mender-toradex-nxp \
  ${TOPDIR}/../layers/meta-mender/meta-mender-demo \
  "
---------------------------------------------

On the working boot2qt environment poky 3.1.11 is used, i'm using poky 3.1.8.

Is there anything i can do to track this issue down? bitbake -v doesn't report more infos.

I appreciate any help here, thank you.

Best regards,
Kevin



unparsed line #yocto

Kevin Kettinger
 

Hello,

after including the meta-qt5 and meta-boot2qt layer from https://code.qt.io/cgit/yocto, and adding them to my bblayers.conf, bitbake breaks directly while parsing the recipes:
---------------------------------------------
ERROR: ParseError at /home/yocto/projects/faseroptik-dunfell/build/../layers/meta-qt5/classes/cmake_qt5.bbclass:4: unparsed line: 'DEPENDS:prepend = "${QTBASEDEPENDS} "'                                                                                                                                    | ETA:  --:--:--

Summary: There was 1 ERROR message shown, returning a non-zero exit code.
---------------------------------------------

If i restart bitbake, the offending file changes now and then, but just for completion, here is the file:
---------------------------------------------
inherit cmake
inherit qmake5_paths

DEPENDS:prepend = "${QTBASEDEPENDS} "
QTBASEDEPENDS = "qtbase qtbase-native"
QTBASEDEPENDS:class-native = "qtbase-native"
QTBASEDEPENDS:class-nativesdk = "nativesdk-qtbase qtbase-native"

EXTRA_OECMAKE:prepend = " \
    -DOE_QMAKE_PATH_PREFIX=${OE_QMAKE_PATH_PREFIX} \
    -DOE_QMAKE_PATH_HEADERS=${OE_QMAKE_PATH_HEADERS} \
    -DOE_QMAKE_PATH_LIBS=${OE_QMAKE_PATH_LIBS} \
    -DOE_QMAKE_PATH_ARCHDATA=${OE_QMAKE_PATH_ARCHDATA} \
    -DOE_QMAKE_PATH_DATA=${OE_QMAKE_PATH_DATA} \
    -DOE_QMAKE_PATH_BINS=${OE_QMAKE_PATH_BINS} \
    -DOE_QMAKE_PATH_LIBEXECS=${OE_QMAKE_PATH_LIBEXECS} \
    -DOE_QMAKE_PATH_PLUGINS=${OE_QMAKE_PATH_PLUGINS} \
    -DOE_QMAKE_PATH_QML=${OE_QMAKE_PATH_QML} \
    -DOE_QMAKE_PATH_TRANSLATIONS=${OE_QMAKE_PATH_TRANSLATIONS} \
    -DOE_QMAKE_PATH_DOCS=${OE_QMAKE_PATH_DOCS} \
    -DOE_QMAKE_PATH_SETTINGS=${OE_QMAKE_PATH_SETTINGS} \
    -DOE_QMAKE_PATH_EXAMPLES=${OE_QMAKE_PATH_EXAMPLES} \
    -DOE_QMAKE_PATH_TESTS=${OE_QMAKE_PATH_TESTS} \
    -DOE_QMAKE_PATH_HOST_PREFIX=${OE_QMAKE_PATH_HOST_PREFIX} \
    -DOE_QMAKE_PATH_HOST_BINS=${OE_QMAKE_PATH_HOST_BINS} \
    -DOE_QMAKE_PATH_HOST_DATA=${OE_QMAKE_PATH_HOST_DATA} \
    -DOE_QMAKE_PATH_HOST_LIBS=${OE_QMAKE_PATH_HOST_LIBS} \
    -DOE_QMAKE_PATH_EXTERNAL_HOST_BINS=${OE_QMAKE_PATH_EXTERNAL_HOST_BINS} \
    -DOE_QMAKE_PATH_QT_HEADERS=${OE_QMAKE_PATH_QT_HEADERS} \
    -DOE_QMAKE_PATH_QT_ARCHDATA=${OE_QMAKE_PATH_QT_ARCHDATA} \
    -DOE_QMAKE_PATH_QT_DATA=${OE_QMAKE_PATH_QT_DATA} \
    -DOE_QMAKE_PATH_QT_BINS=${OE_QMAKE_PATH_QT_BINS} \
    -DOE_QMAKE_PATH_QT_TRANSLATIONS=${OE_QMAKE_PATH_QT_TRANSLATIONS} \
    -DOE_QMAKE_PATH_QT_DOCS=${OE_QMAKE_PATH_QT_DOCS} \
    -DOE_QMAKE_PATH_QT_SETTINGS=${OE_QMAKE_PATH_QT_SETTINGS} \
    -DOE_QMAKE_PATH_QT_EXAMPLES=${OE_QMAKE_PATH_QT_EXAMPLES} \
    -DOE_QMAKE_PATH_QT_TESTS=${OE_QMAKE_PATH_QT_TESTS} \
"
---------------------------------------------

The exact same layer with the exact same commit & files is working fine on the original boot2qt environment, but not on my environment.

My bblayers.conf looks like this:
---------------------------------------------
LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${TOPDIR}/../layers/meta-toradex-nxp \
  ${TOPDIR}/../layers/meta-freescale \
  ${TOPDIR}/../layers/meta-freescale-3rdparty \
  ${TOPDIR}/../layers/meta-toradex-tegra \
  ${TOPDIR}/../layers/meta-toradex-bsp-common \
  ${TOPDIR}/../layers/meta-openembedded/meta-oe \
  ${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
  ${TOPDIR}/../layers/meta-openembedded/meta-gnome \
  ${TOPDIR}/../layers/meta-openembedded/meta-xfce \
  ${TOPDIR}/../layers/meta-openembedded/meta-initramfs \
  ${TOPDIR}/../layers/meta-openembedded/meta-networking \
  ${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
  ${TOPDIR}/../layers/meta-openembedded/meta-python \
  ${TOPDIR}/../layers/meta-freescale-distro \
  ${TOPDIR}/../layers/meta-toradex-demos \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt \
  ${TOPDIR}/../layers/meta-boot2qt/meta-boot2qt-distro \
  ${TOPDIR}/../layers/meta-qt5 \
  ${TOPDIR}/../layers/meta-toradex-distro \
  ${TOPDIR}/../layers/meta-yocto/meta-poky \
  ${TOPDIR}/../layers/openembedded-core/meta \
  ${TOPDIR}/../layers/meta-mender/meta-mender-core \
  ${TOPDIR}/../layers/meta-mender-community/meta-mender-toradex-nxp \
  ${TOPDIR}/../layers/meta-mender/meta-mender-demo \
  "
---------------------------------------------

On the working boot2qt environment poky 3.1.11 is used, i'm using poky 3.1.8.

Is there anything i can do to track this issue down? bitbake -v doesn't report more infos.

I appreciate any help here, thank you.

Best regards,
Kevin

2141 - 2160 of 57790