Date   

[meta-raspberrypi][PATCH] libwpe: Migrate build workaround from oe-core

Andrei Gherzan
 

This was removed from oe-core[1] so we pull in the change here where it
should have been in the first place.

Fixes: https://github.com/agherzan/meta-raspberrypi/issues/893

[1] https://lists.openembedded.org/g/openembedded-core/topic/84653556

Signed-off-by: Andrei Gherzan <andrei@...>
---
recipes-sato/libwpe_%.bbappend | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-sato/libwpe_%.bbappend

diff --git a/recipes-sato/libwpe_%.bbappend b/recipes-sato/libwpe_%.bbappend
new file mode 100644
index 0000000..fe1e59b
--- /dev/null
+++ b/recipes-sato/libwpe_%.bbappend
@@ -0,0 +1,2 @@
+# Workaround build issue with RPi userland EGL libraries.
+CFLAGS:append:rpi = " ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
--
2.33.0


Re: [meta-selinux][PATCH] openssh: don't overwrite sshd_config unconditionally

akash hadke
 

Hi,

Is there any update for this patch?


Re: Cross-compile custom ROS2 package for Yocto #bitbake

bojankoce
 

Hello, Matthias.

It seems the issue was around naming. Now it works fine even without FILES:${PN} at the end of .bb file.
I am now good to move forward.

Thank you very much for your assistance. It is really appreciated.

Sincerely,
Bojan.


[meta-mingw] [PATCH] dtc: update for recipe changes in oe-core

Ross Burton <ross@...>
 

The tools now build for MinGW so we don't need to disable them, but
as ncurses still fails we should continue to remove the bash RDEPENDS.

Signed-off-by: Ross Burton <ross.burton@...>
---
recipes-core/dtc/dtc_%.bbappend | 15 ---------------
1 file changed, 15 deletions(-)

diff --git a/recipes-core/dtc/dtc_%.bbappend b/recipes-core/dtc/dtc_%.bba=
ppend
index 2d27a0a..b71c46b 100644
--- a/recipes-core/dtc/dtc_%.bbappend
+++ b/recipes-core/dtc/dtc_%.bbappend
@@ -1,16 +1 @@
-
-do_configure:append:mingw32 () {
- # don't try to build the other dtc components when installing libs
- sed -i 's/install-lib: all/install-lib: libfdt/g' ${S}/Makefile
-}
-
-do_compile:mingw32 () {
- oe_runmake libfdt
-}
-
-do_install:mingw32 () {
- oe_runmake install-lib install-includes
-}
-
RDEPENDS:${PN}-misc:remove:mingw32 =3D "bash"
-
--=20
2.25.1


Re: Cross-compile custom ROS2 package for Yocto #bitbake

Matthias Schoepfer
 

Hi Bojan,

you do not need the additional FILES:${PN} if your package is properly named (i.e. cmake project name same as recipe same as package). I have no clue why the executable is not found, did you source the environment before?!

Regards,

    Matthias

On 11/10/21 8:37 PM, bojankoce wrote:
In addition to the above changes, I also included instructions inside conf/local.conf file to install my first ROS2 package:
IMAGE_INSTALL_append=" ros-core my-first-yocto-pkg"

After that, I was able to bitbake the complete Yocto image, put it on the SD card, and boot the Yocto on my devkit. After sourcing ros2_setup.sh script, I entered:

ros2 pkg list
command to list all available ROS2 packages on the system.

my_first_yocto_pkg package was on the list so I was happy and excited!

I wanted to do the final touch and launch the talker node from the packet with:

ros2 run my_first_yocto_pkg talker

However, I got the info that No executable is found! What the heck!

Do you have any idea what I did wrong in the whole process?

Appreciate your efforts!

Sincerely,
Bojan.



Re: Yocto suddenly creating directories with 700 instead 755.

Manuel Wagesreither
 

Am Fr, 12. Nov 2021, um 11:35, schrieb Richard Purdie:
On Thu, 2021-11-11 at 18:28 -0500, Stephen John Smoogen wrote:
On Thu, 11 Nov 2021 at 11:10, Manuel Wagesreither <ManWag@...> wrote:

Hello all,

sorry, wall of text incoming.

tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default mode determined? What can cause it suddenly (that is, without updating metalayers or similar) to change from 755 to 700?
when I did this to myself recently, I had changed the shells default
umask value to 077 which caused exactly what you are listing. I would
check to see if the users or system wide umask was changed recently by
an update.
I'd note there were a number of fixes for umask issues in master/honister:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f4fb74465787b50030d7fed5e0b293774ccb371b
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=522607e704876c67ed093bac47dde9238709ccae
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=58c97902933cced2981dfc7480fc0a458b4fb900
Thanks a lot. I will read through the links and commits provided and see if that helps us.

We are currently using poky on dunfell as it were on early September: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=bdd30be1a3815f70062d8febca91eaf042a77c3d.

Regards,
Manuel


Re: Yocto suddenly creating directories with 700 instead 755.

Richard Purdie
 

On Thu, 2021-11-11 at 18:28 -0500, Stephen John Smoogen wrote:
On Thu, 11 Nov 2021 at 11:10, Manuel Wagesreither <ManWag@...> wrote:

Hello all,

sorry, wall of text incoming.

tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default mode determined? What can cause it suddenly (that is, without updating metalayers or similar) to change from 755 to 700?
when I did this to myself recently, I had changed the shells default
umask value to 077 which caused exactly what you are listing. I would
check to see if the users or system wide umask was changed recently by
an update.
I'd note there were a number of fixes for umask issues in master/honister:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f4fb74465787b50030d7fed5e0b293774ccb371b
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=522607e704876c67ed093bac47dde9238709ccae
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=58c97902933cced2981dfc7480fc0a458b4fb900

Cheers,

Richard


Re: Yocto suddenly creating directories with 700 instead 755.

Stephen John Smoogen
 

On Thu, 11 Nov 2021 at 11:10, Manuel Wagesreither <ManWag@...> wrote:

Hello all,

sorry, wall of text incoming.

tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default mode determined? What can cause it suddenly (that is, without updating metalayers or similar) to change from 755 to 700?
when I did this to myself recently, I had changed the shells default
umask value to 077 which caused exactly what you are listing. I would
check to see if the users or system wide umask was changed recently by
an update.




--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren


Re: Yocto suddenly creating directories with 700 instead 755.

Richard Purdie
 

On Thu, 2021-11-11 at 17:10 +0100, Manuel Wagesreither wrote:
tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default
mode determined? What can cause it suddenly (that is, without updating
metalayers or similar) to change from 755 to 700?
You don't mention which version of the project this is with which may be
important and relevant as we've fixed things related to these kinds of issues.

Bottom line is that file mode you see on disk will be determined by the umask
bitbake is being run under. The file modes on disk are not the file modes used
though since pseudo emulates modes as well as users like root.

The 134 exit code is usually pseudo aborting and there should be information in
the rootfs logs about which files it had concerns over, likely inode mismatches.
Also see the WORKDIR/pseudo/pseudo.log. This has it's own wiki page:

https://wiki.yoctoproject.org/wiki/Pseudo_Abort

I'd also add that the core directories have permissions determined by:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/files/fs-perms.txt

and code in package.bbclass should be ensuring those directories always have
consistent permission bits.

This brings me back to which release/version of the metadata is this?

Cheers,

Richard


[meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
--
2.30.2


Minutes: Yocto Project Weekly Triage Meeting 11/11/2021

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alexandre, Armin, Bruce, Randy, Richard, Ross, Saul, Stephen, Steve, Tim, Trevor

ARs:

N/A


Notes:

N/A

Medium+ 3.5 Unassigned Enhancements/Bugs: 73 (Last week 79)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (No change)

AB Bugs: 62 (No change)


Yocto suddenly creating directories with 700 instead 755.

Manuel Wagesreither
 

Hello all,

sorry, wall of text incoming.

tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default mode determined? What can cause it suddenly (that is, without updating metalayers or similar) to change from 755 to 700?


full version:

our CI is throwing "Transaction check errors" of the following form:

```
file /etc conflicts between attempted installs of redactedone-appconfig-1.0-r0.aarch64 and modemmanager-1.12.12-r0.aarch64
file /etc conflicts between attempted installs of tegra-configs-udev-32.4.3-r0.armv8a_tegra and redactedone-appconfig-1.0-r0.aarch64
file /usr conflicts between attempted installs of redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr/bin conflicts between attempted installs of redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr conflicts between attempted installs of iptables-dev-1.8.4-r0.aarch64 and redactedtwo-scripts-1.0-r0.aarch64
file /usr/bin conflicts between attempted installs of systemd-1:244.5-r0.aarch64 and redactedtwo-scripts-1.0-r0.aarch64
```

I examined/unpacked the .rpms in tmp/work/deploy/rpm/aarch64 and really, they do differ in the mode bits for /etc, /usr and /usr/bin. While these dirs have a mode of 755 in poky/oe packages, they have a mode of 700 in our packages. The puzzling thing is that this issue has arised only recently with a totally independent change in some recipe not mentioned above. The change consisted of changing the URI of a tarball we fetch from AWS S3 and using sha256 instead md5 for checksumming the file.

At first, this issue appeared somewhat reproducible, but I think that was just coincedence. Perhaps there is some cache poisoning at play here. Now builds are also failling which don't have this "bad" commit. Tests are still going on. I'm now testing if deleting the tmp dir changes anything.

So this mail is rather about: Do you know anything which can point me into the right direction? The recipes in question all install the directories with `install -d ${D}/somedir`. I changed some recipes to have `-m 0755` as well, and one build did indeed succeed then, but then builds started to fail with the same symptoms but other packages being the culprit, that is, having the dirs with 700.

I heard the default mode of files/dirs in unix is set with umask, but I have no idea how to check if/how Yocto is fiddling with that.

Also, sometimes we have these errors: They seem to go away with cleaning the tmp dir, while the errors above persist. But the sample size is very small so that might be a wrong lead.

```
INFO - NOTE: Running task 12010 of 12044 (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs)
INFO - NOTE: recipe our-image-1.0-r0: task do_rootfs: Started
ERROR - ERROR: Task (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs) failed with exit code '134'
INFO - NOTE: Tasks Summary: Attempted 12034 tasks of which 12001 didn't need to be rerun and 1 failed.
INFO -
INFO - Summary: 1 task failed:
INFO - /opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs
ERROR - Command "/opt/buildagent/work/77acccee8c88a2cf/build$ /opt/buildagent/work/77acccee8c88a2cf/poky/bitbake/bin/bitbake -c build our-image" failed
--- Error summary ---
ERROR: Task (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs) failed with exit code '134'
```
Google said exit code 134 means the process received a SIGABRT, but... I'm quite sure no-one sent one.


Thank you all,
regards,
Manuel


Re: User configuration & host contamination

Jeffrey Simons
 

Hi Manuel,

Subject: Re: [yocto] User configuration & host contamination

Hi Jeffrey,

Does the recipe which builds the application DEPEND on the recipe which sets up the user? This is what I would try. If I understand
things correctly, Yocto/Bitbake provides every recipe a pristine environment unnaffected from other recipes going into the same image.
For example, if you want to link your application against some libraries provided by other recipes, you need to add them to DEPENDS.
That populates your build environment with that other recipes output. I'm not sure this applies to user accounts as well, but I guess it's worth a try.

Please note I probably used the termins "recipe" and "package" incorrectly.

Hope this helps,
Manuel
Thank you for your reply and suggestion.
I already have a dependency on the user-configuration script, see the below snippet from my recipe.

# Compile-time dependencies for testapp
DEPENDS = "user-configuration"

# Run-time dependencies for testapp
RDEPENDS_${PN} += "rsyslog \

Unfortunately that did not work, I have seen some suggestions on stack-overflow where they added the user multiple times per recipe by using extrauseradd (I believe).
That seems a bit weird to me to add every time the same user, also the drawback is that if the user changes then I have to adjust all recipes that rely on that specific user.
What I did today to circumvent the issue is to assign the user by reference of UID and GID, but I'm not sure if this is the intended Yocto way. As you stated before
Yocto presents you with a pristine environment with all information present, so I would expect that my user is there. Perhaps I did not include the user-configuration
correctly?
I did include the user-configuration by adding it into our distribution description, see the next coding snippet.

#
# Usernames that will be used within the distro.
# Can be changed when desired, each recipe must use this user for the application.
#
TEST_USER = "testuser"
TEST_USER_UID = "1200"

DISTRO_EXTRA_RDEPENDS += "user-configuration"

Can you or any one else clarify if this is the correct way or not?

Thank you in advance.

Jeffrey Simons

Software Engineer
Royal Boon Edam International B.V.


[meta-zephyr][PATCH] zephyr-kernel-test: remove unnecessary "+="

Jon Mason
 

bitbake is now warning when "+=" is used with "remove", as it is not a
recommended combination. Change the commented out versions that have
this combination to prevent anyone from using it.

Signed-off-by: Jon Mason <jon.mason@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index c7ccf9e05742..77f45a737407 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -14,16 +14,16 @@ ZEPHYRTESTS:remove:qemu-x86 = "common device interrupt poll queue sleep"
ZEPHYRTESTS:remove:stm32mp157c-dk2 = "common device poll queue sleep"

# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
-#ZEPHYRTESTS:remove:arm += ""
+#ZEPHYRTESTS:remove:arm = ""

# test_critical never finishes in an unpatched QEMU either
-#ZEPHYRTESTS:remove:arm += ""
+#ZEPHYRTESTS:remove:arm = ""

#Remove ARM specific tests
-#ZEPHYRTESTS:remove:x86 += ""
+#ZEPHYRTESTS:remove:x86 = ""

#Remove tests not intended for Nios2
-#ZEPHYRTESTS:remove:nios2 += ""
+#ZEPHYRTESTS:remove:nios2 = ""

# List of all available kernel tests
ZEPHYRTESTS = " \
--
2.20.1


Re: User configuration & host contamination

Manuel Wagesreither
 

Hi Jeffrey,

Am Do, 4. Nov 2021, um 11:00, schrieb Jeffrey Simons:
Hi all,

I'm having some difficulty with setting up users and the respective
application user assignments. I have a generic recipe which inherits
useradd and sets a user, this
works great for my purpose without one exception. I can't assign the
user in my other recipe where the application is build.

Snippet from my user add (based on the useradd-example):
USERADD_PARAM_${PN} = "--uid 1200 \
--home-dir /home/user1 \
--groups dialout \
--user-group \
--password '********' \
--shell /bin/bash user1"

Snippet from my application which wants to assign the user1:
do_install () {
chown -R user1 ${D}/usr/local/bin/test_app/
}
It fails with the message:
"WARNING: test_app-1.0-12-r0 do_package_qa: QA Issue: test_app:
/usr/local/bin/test_app/some_script.py is owned by uid 1000, which is
the same as the user running bitbake. This may be due to host
contamination"

Any pointers/thoughts in how I can resolve this issue?
Does the recipe which builds the application DEPEND on the recipe which sets up the user? This is what I would try. If I understand things correctly, Yocto/Bitbake provides every recipe a pristine environment unnaffected from other recipes going into the same image. For example, if you want to link your application against some libraries provided by other recipes, you need to add them to DEPENDS. That populates your build environment with that other recipes output. I'm not sure this applies to user accounts as well, but I guess it's worth a try.

Please note I probably used the termins "recipe" and "package" incorrectly.

Hope this helps,
Manuel


Re: QA notification for completed autobuilder build (yocto-3.3.4.rc1)

Teoh, Jay Shen
 

Hi all,

This is the full report for yocto-3.3.4.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

new issue found

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622

Thanks,
Jay

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Richard Purdie
Sent: Friday, 5 November, 2021 6:58 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3.4.rc1)

A build flagged for QA (yocto-3.3.4.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.4.rc1


Build hash information:

bitbake: 0fe1a9e2d2e33f80d807cefc7a23df4a5f760c74
meta-agl: d997986f27e239400cf01e0cdef942cee278ea66
meta-arm: 71686ac05c34e53950268bfe0d52c3624e78c190
meta-aws: cad1c714434fe0adc566006e1e1626b4657bcf40
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 76495b60dd915846d2f84d03b9c9cfbb548e9dc0
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: d378e4293d18e374f5d1494a88bfc3caee4d02df
oecore: 0ca080a23c2770a15138f702d4c879bbd90ca360
poky: c40ac16d79026169639f47be76a3f7b9d8b5178e



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


Re: Unable to parse /home/PATH/meta-swupdate/recipes-support/swupdate/swupdate_git.bb #swupdate

Quentin Schulz
 

Hi Vishal,

On November 11, 2021 5:42:44 AM GMT+01:00, vishal.rana118@... wrote:
Hi Team,

I am new with Yocto and SWupdate framework. I am trying to integrate SWupdate framework in our existing yocto code.
I am using *SUMO version*. while trying to build kernel image I am getting below error.
*MACHINE=imx6s-comg-mtech DISTRO=fsl-imx-fb EULA=1 source setup-environment build-mtech*
*bitbake linux-comg-mtech-4.14.78.local*

////////////////////////////////////////////////////////Error log/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ERROR: Unable to parse /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb
Traceback (most recent call last):
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 117, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', data=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
with data.inchistory.include(fn):
                return h['handle'](fn, data, include)
raise ParseError("not a BitBake file", fn)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 154, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
if ext != ".bbclass" and include == 0:
        return ast.multi_finalize(fn, d)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/ast.py", line 391, in multi_finalize(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
logger.debug(1, "Appending .bbappend file %s to %s", append, fn)
        bb.parse.BBHandler.handle(append, d, True)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 132, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=True):

    abs_fn = resolve_file(fn, d)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 141, in resolve_file(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
if not os.path.isfile(fn):
        raise IOError(errno.ENOENT, "file %s not found" % fn)
FileNotFoundError: [Errno 2] file /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d not found
What's the exact filename of files in the home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/ directory?

I suspect that you have a swupdate_%d.bbappend which isn't valid in bitbake. It should be swupdate_%.bbappend.

Cheers
Quentin

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Not able to understand the root cause of this because without adding "meta-swupdate" layer I am able to build the code.
Please help me to resolve this issue.

Regards,
Vishal Rana


[meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Marek Belisko
 

Hello,

I'm trying to integrate mender for tinker-board-s using meta-rockchip
dunfell branch. When added meta-mender which add few patches to
u-boot I'm seeing u-boot compilation issues like:

Error: SPL image is too large (size 0x11000 than 0x8000)
| Error: Bad parameters for image type

Error is clear to me but patches which mender adds are related mostly
to the environment so I'm not sure how SPL can increase size. Any
ideas on how to resolve this issue?

Thanks and regards,

marek


--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Unable to parse /home/PATH/meta-swupdate/recipes-support/swupdate/swupdate_git.bb #swupdate

vishal.rana118@...
 

Hi Team,

I am new with Yocto and SWupdate framework. I am trying to integrate SWupdate framework in our existing yocto code.
I am using SUMO version. while trying to build kernel image I am getting below error.
MACHINE=imx6s-comg-mtech DISTRO=fsl-imx-fb EULA=1 source setup-environment build-mtech
bitbake linux-comg-mtech-4.14.78.local

////////////////////////////////////////////////////////Error log/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ERROR: Unable to parse /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb
Traceback (most recent call last):
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 117, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', data=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
                 with data.inchistory.include(fn):
    >                return h['handle'](fn, data, include)
         raise ParseError("not a BitBake file", fn)
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 154, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
         if ext != ".bbclass" and include == 0:
    >        return ast.multi_finalize(fn, d)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/ast.py", line 391, in multi_finalize(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
             logger.debug(1, "Appending .bbappend file %s to %s", append, fn)
    >        bb.parse.BBHandler.handle(append, d, True)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 132, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=True):
     
    >    abs_fn = resolve_file(fn, d)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 141, in resolve_file(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
         if not os.path.isfile(fn):
    >        raise IOError(errno.ENOENT, "file %s not found" % fn)
     
FileNotFoundError: [Errno 2] file /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d not found
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Not able to understand the root cause of this because without adding "meta-swupdate" layer I am able to build the code.
Please help me to resolve this issue.





Regards,
Vishal Rana


Re: __DATE__ and __TIME__ in dunfell builds #dunfell

Peter Bergin
 

On 2021-11-10 21:44, chiefsleepyeye@... wrote:
I have a weird thing going on with __DATE__ and __TIME__ when building my app in the yocto environment.  I'm building for "genericx86-64" and I'm using __DATE__ and __TIME__ in my source to show what the build date/time of my app is at run time.  But... __DATE__ is always "Apr  5 2011" and __TIME__ is always "23:00:00".  And, yes, the current time on the build machine is not that.  Anyone else experience this and/or know how to fix it?  Oh, host is Ubuntu 20.04.3 LTS.

In your build you have reproducible build enabled. https://docs.yoctoproject.org/3.4/test-manual/reproducible-builds.html. You should be able to disable this function with help of the variable BUILD_REPRODUCIBLE_BINARIES. Reproducible builds are now enableb by default in Yocto.

/Peter

2101 - 2120 of 57386