Date   

Re: Error while installing Python modules using pip3 in yocto zeus #zeus

Poornesh G
 

Greetings !

I am working on Rockpis Board with Yocto Zeus for development . When I am trying to install  Python modules "backports.zoneinfo" using pip3 I am facing the below error . Kindly requesting any suggestions to resolve.

Error Log:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Building wheels for collected packages: backports.zoneinfo
  Building wheel for backports.zoneinfo (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/bin/python3 /usr/lib/python3.7/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpj158xpon
       cwd: /tmp/pip-install-e1zrr5gk/backports-zoneinfo_fe1585f6e0ef47be9df309ad556bbecf
  Complete output (39 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-aarch64-3.7
  creating build/lib.linux-aarch64-3.7/backports
  copying src/backports/__init__.py -> build/lib.linux-aarch64-3.7/backports
  creating build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/_zoneinfo.py -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/_version.py -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/_tzpath.py -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/_common.py -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/__init__.py -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  running egg_info
  writing src/backports.zoneinfo.egg-info/PKG-INFO
  writing dependency_links to src/backports.zoneinfo.egg-info/dependency_links.txt
  writing requirements to src/backports.zoneinfo.egg-info/requires.txt
  writing top-level names to src/backports.zoneinfo.egg-info/top_level.txt
  reading manifest file 'src/backports.zoneinfo.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  warning: no files found matching '*.png' under directory 'docs'
  warning: no files found matching '*.svg' under directory 'docs'
  no previously-included directories found matching 'docs/_build'
  no previously-included directories found matching 'docs/_output'
  adding license file 'LICENSE'
  adding license file 'licenses/LICENSE_APACHE'
  writing manifest file 'src/backports.zoneinfo.egg-info/SOURCES.txt'
  copying src/backports/zoneinfo/__init__.pyi -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  copying src/backports/zoneinfo/py.typed -> build/lib.linux-aarch64-3.7/backports/zoneinfo
  running build_ext
  building 'backports.zoneinfo._czoneinfo' extension
  creating build/temp.linux-aarch64-3.7
  creating build/temp.linux-aarch64-3.7/lib
  aarch64-poky-linux-gcc -mcpu=cortex-a35+crc+crypto -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wno-unused-result -Wsign-compare -DNDEBUG -g -O3 -Wa9
  lib/zoneinfo_module.c:1:10: fatal error: Python.h: No such file or directory
      1 | #include "Python.h"
        |          ^~~~~~~~~~
  compilation terminated.
  error: command 'aarch64-poky-linux-gcc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for backports.zoneinfo
Failed to build backports.zoneinfo
ERROR: Could not build wheels for backports.zoneinfo which use PEP 517 and cannot be installed directly

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks in Advance


Re: [OE-core] How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?

Federico Pellegrin
 


Hi Jupiter,
To centralize, agreed that you are using systemd, one way I could see is setting the variables in systemd-system.conf using the DefaultEnvironment directive, see: https://freedesktop.org/software/systemd/man/systemd-system.conf.html

This states:

----
DefaultEnvironment=

Configures environment variables passed to all executed processes. Takes a space-separated list of variable assignments. See environ(7) for details about environment variables.

Simple "%"-specifier expansion is supported, see below for a list of supported specifiers.

Example:

DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"

Sets three variables "VAR1", "VAR2", "VAR3".

----

This should have you variables management in each. Otherwise as you mention one can put in each script with either Environment to have them explicitly enumerated or with EnvironmentFile to read from a file, which may also fit your centralization hopes (but still require one line per startup script at least) and could be further sourced by non-systemd components as well if needed. (https://www.freedesktop.org/software/systemd/man/systemd.exec.html under Environment section)

HTH,
Federico


Il giorno lun 11 ott 2021 alle ore 11:05 Jupiter <jupiter.hce@...> ha scritto:
Hi Federico,

Thanks for your response.

> /etc/profile and similar are interactive shell (/bash) concepts, not really
> system startup ones. So indeed: just on a login (be it local, ssh and so
> on) they are executed.

Understood, here is what I try to figure out. I use several systemd
services to start my tasks, each task is not just a system process, I
found it also has a system environment similar in user login from
/etcprofile, /home/user/.profile, my question is where is a system
environment file that each systemd service runs from?

I also thought that /etc/profile.d files should be automatically
invoked for each user login, but a systemd service does not run
/etc/profile.d files.

> If you want to execute something else without the need for logging it, you
> should look elsewhere, depending on your system manager: if systemd you
> should create a service and enable it, if sysvinit a init.d script.

Understood, that was what I did originally, I have to run the setup
system environment in each service ExecStart script, that is why I am
looking for a global environment setup file to avoid duplication of
putting my environment scripts in each ExecStart execution file.

Thank you.

Kind regards,

- jupiter

> HTH,
> Federico
>
>
> Il giorno lun 11 ott 2021 alle ore 06:30 JH <jupiter.hce@...> ha
> scritto:
>
>> Hi,
>>
>> The Yocto uses /etc/profile for root login, but there is no root
>> physical login in an embedded device so the /etc/profile is never
>> called, I added a shell script to /etc/profile.d, it was not called
>> either. Both /etc/profile and scripts in /etc/profile.d can only be
>> invoked when I physically log into the debug console, that is
>> impractical. Appreciate your advice, how do you resolve that kind of
>> problem?
>>
>> Thank you.
>>
>> Kind regards,
>>
>> - jupiter
>>
>>
>>
>>
>


--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs


Re: building the kernel's usbipd daemon

Bruce Ashfield
 

On Mon, Oct 11, 2021 at 6:16 PM chuck kamas via lists.yoctoproject.org
<chuckkamas=yahoo.com@...> wrote:

Hi all,


I've googled most of the day, but to no avail. How does one compile and
add to the image the daemon usbipd? Is there a bitbake file already for
this? The code is part of the kernel found in the kernel tree:

KERNEL_SRC_PATH/tools/usb/usbip/src

and is invoked from the KERNEL_SRC_PATH/tools directory by calling

make usb


from:
https://wiki.st.com/stm32mpu/wiki/How_to_build_Linux_kernel_user_space_tools

PC $> cd <Linux_kernel_source_path>/tools
PC $> make <tool>


I would think that there is a preexisting recipe.
There isn't one that I've ever heard of, and the layerindex
(http://layers.openembedded.org/) confirms that nothing registered
with it provides that recipe.

So if you need it, you'd have to create a recipe .. and submit it to
somewhere like meta-openembedded if appropriate.

Have a look at the perf recipe for one of the ways we build tools out
of the kernel source. Something similar will work in this case.

Bruce


thanks,

Chuck





--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Enhancements/Bugs closed WW40!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

2

mhalstead@...

1

ross@...

1

Grand Total

4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW41 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 13 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

michael.opdenacker@...

34

ross@...

30

david.reyna@...

22

randy.macleod@...

16

trevor.gamblin@...

14

bruce.ashfield@...

11

richard.purdie@...

10

timothy.t.orling@...

9

kai.kang@...

7

bluelightning@...

6

mhalstead@...

5

kiran.surendran@...

4

JPEWhacker@...

4

Qi.Chen@...

4

hongxu.jia@...

3

chee.yang.lee@...

3

thomas.perrot@...

2

akuster808@...

2

mingli.yu@...

2

mshah@...

2

saul.wold@...

2

raj.khem@...

1

tony.tascioglu@...

1

yi.zhao@...

1

sangeeta.jain@...

1

jay.shen.teoh@...

1

pokylinux@...

1

alexandre.belloni@...

1

alejandro@...

1

yf3yu@...

1

open.source@...

1

weaverjs@...

1

jaewon@...

1

fransmeulenbroeks@...

1

kergoth@...

1

mickael.laventure+yocto@...

1

ydirson@...

1

devendra.tewari@...

1

jeanmarie.lemetayer@...

1

diego.sueiro@...

1

aehs29@...

1

sakib.sajal@...

1

matthewzmd@...

1

douglas.royds@...

1

paul.gortmaker@...

1

paul@...

1

alex.kanavin@...

1

vinay.m.engg@...

1

shachar@...

1

pgowda.cve@...

1

mister_rs@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 395 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


building the kernel's usbipd daemon

chuck kamas
 

Hi all,


I've googled most of the day, but to no avail. How does one compile and add to the image the daemon usbipd? Is there a bitbake file already for this? The code is part of the kernel found in the kernel tree:

KERNEL_SRC_PATH/tools/usb/usbip/src

and is invoked from the KERNEL_SRC_PATH/tools directory by calling

make usb


from: https://wiki.st.com/stm32mpu/wiki/How_to_build_Linux_kernel_user_space_tools

PC $> cd <Linux_kernel_source_path>/tools
PC $> make <tool>


I would think that there is a preexisting recipe.

thanks,

Chuck


Re: Yocto build error

Khem Raj
 

On Sun, Oct 10, 2021 at 6:45 PM JH <jupiter.hce@...> wrote:

Hi,

I have following errors:

No GNU_HASH in the ELF binary
/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/solar/1.0.0-0/packages-split/wifi_signal,
didn't pass LDFLAGS? [ldflags]

So I add --hash-style=gnu to my Makefile:

LD_FLAGS += --hash-style=gnu
LDFLAGS = LD_FLAGS

But that does not work:

arm-oe-linux-gnueabi-gcc: error: unrecognized command line option
'--hash-style=gnu'

What is wrong about the error if the --hash-style=gnu is not the right fix?
So it seems your makefile is not respecting the LDFLAGS coming from
the environment during linking.
perhaps you should fix that in your linking rules. hardcoding hash
style like this is not portable.

Thank you.

Kind regards.

JH



QA notification for completed autobuilder build (yocto-3.4.rc1)

Richard Purdie
 

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


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


Build hash information:

bitbake: c78ebac71ec976fdf27ea24767057882870f5c60
meta-agl: 228ecc1dec390138c44299d1c244acda9ad75ce1
meta-arm: 98193f3b6167e07cbb794e96b80d78ca1779ea4f
meta-aws: 27bca81c4d3f0138fda583f9ea98df6152332333
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 90170cf85fe35b4e8dc00eee50053c0205276b63
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: f2152d79043601eacb70da1a3ab36f5ac56f3e28
oecore: bb1dea6806f084364b6017db2567f438e805aef0
poky: f6d1126fff213460dc6954a5d5fc168606d76b66



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


[meta-zephyr][PATCH 2/2] zephyr-kernel/2.5.0: drop recipe

Naveen Saini
 

As v2.7.0 is being added, drop this version support

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
...phyr-2.5.0-cmake-add-yocto-toolchain.patch | 63 -------------------
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 17 -----
2 files changed, 80 deletions(-)
delete mode 100644 recipes-kernel/zephyr-kernel/files/0001-zephyr-2.5.0-cmake-add-yocto-toolchain.patch
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc

diff --git a/recipes-kernel/zephyr-kernel/files/0001-zephyr-2.5.0-cmake-add-yocto-toolchain.patch b/recipes-kernel/zephyr-kernel/files/0001-zephyr-2.5.0-cmake-add-yocto-toolchain.patch
deleted file mode 100644
index caab16f..0000000
--- a/recipes-kernel/zephyr-kernel/files/0001-zephyr-2.5.0-cmake-add-yocto-toolchain.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-From 511745625637da0effca13c5489a392e15d32271 Mon Sep 17 00:00:00 2001
-From: Naveen Saini <naveen.kumar.saini@...>
-Date: Tue, 31 Mar 2020 13:22:17 +0800
-Subject: [PATCH] cmake: add yocto toolchain
-
-Upstream status: inappropriate [OE specific]
-
-Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
----
- cmake/compiler/gcc/target.cmake | 7 -------
- cmake/toolchain/yocto/generic.cmake | 13 +++++++++++++
- cmake/toolchain/yocto/target.cmake | 1 +
- 3 files changed, 14 insertions(+), 7 deletions(-)
- create mode 100644 cmake/toolchain/yocto/generic.cmake
- create mode 100644 cmake/toolchain/yocto/target.cmake
-
-diff --git a/cmake/compiler/gcc/target.cmake b/cmake/compiler/gcc/target.cmake
-index 401cc28db8..5a026f4559 100644
---- a/cmake/compiler/gcc/target.cmake
-+++ b/cmake/compiler/gcc/target.cmake
-@@ -66,13 +66,6 @@ if(NOT no_libgcc)
- OUTPUT_STRIP_TRAILING_WHITESPACE
- )
-
-- assert_exists(LIBGCC_FILE_NAME)
--
-- get_filename_component(LIBGCC_DIR ${LIBGCC_FILE_NAME} DIRECTORY)
--
-- assert_exists(LIBGCC_DIR)
--
-- LIST(APPEND LIB_INCLUDE_DIR "-L\"${LIBGCC_DIR}\"")
- LIST(APPEND TOOLCHAIN_LIBS gcc)
- endif()
-
-diff --git a/cmake/toolchain/yocto/generic.cmake b/cmake/toolchain/yocto/generic.cmake
-new file mode 100644
-index 0000000000..45e5777e2a
---- /dev/null
-+++ b/cmake/toolchain/yocto/generic.cmake
-@@ -0,0 +1,13 @@
-+set(COMPILER gcc)
-+set(LINKER ld)
-+set(BINTOOLS gnu)
-+
-+set(ZEPHYR_SYSROOT ${ZEPHYR_SYSROOT})
-+set(SYSROOT_DIR ${ZEPHYR_SYSROOT})
-+set(LIBC_LIBRARY_DIR "\"${SYSROOT_DIR}\"/")
-+set(LIBC_INCLUDE_DIR ${SYSROOT_DIR}/include)
-+LIST(APPEND TOOLCHAIN_LIBS gcc)
-+
-+LIST(APPEND LIB_INCLUDE_DIR "-L\"${STAGING_LIBDIR}\"")
-+
-+set(TOOLCHAIN_LIBS gcc)
-diff --git a/cmake/toolchain/yocto/target.cmake b/cmake/toolchain/yocto/target.cmake
-new file mode 100644
-index 0000000000..9881313609
---- /dev/null
-+++ b/cmake/toolchain/yocto/target.cmake
-@@ -0,0 +1 @@
-+# SPDX-License-Identifier: Apache-2.0
---
-2.17.1
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
deleted file mode 100644
index be75362..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ /dev/null
@@ -1,17 +0,0 @@
-SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "fe7c2efca800a0cf1bccf23aefe08b3c4beb88bf"
-SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
-SRCREV_nordic = "f3434da6446380fcdd426dbe2866af21d0d549b6"
-SRCREV_stm32 = "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635"
-SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
-SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
-SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
-SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-SRCREV_mbedtls = "24d84ecff195fb15c889d9046e44e4804d626c67"
-
-ZEPHYR_BRANCH = "main"
-PV = "2.5.0+git${SRCPV}"
-
-SRC_URI:append = " file://0001-zephyr-2.5.0-cmake-add-yocto-toolchain.patch \
- file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
- "
--
2.17.1


[meta-zephyr][PATCH 1/2] zephyr-kernel/2.7.0: add recipe

Naveen Saini
 

https://github.com/zephyrproject-rtos/zephyr/commits/v2.7-branch

Keeping the default PREFERRED_VERSION to 2.6.1 for now.

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.../zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
new file mode 100644
index 0000000..e3424d2
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -0,0 +1,17 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "8a97c83040c0257d98c329dde55ae10e68544688"
+SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
+SRCREV_nordic = "a6e5299041f152da5ae0ab17b2e44e088bb96d6d"
+SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
+SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "5d706547ebcb0a85e11412bcd88e80e2af98c74d"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
+
+ZEPHYR_BRANCH = "v2.7-branch"
+PV = "2.7.0+git${SRCPV}"
+
+SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
+ file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
--
2.17.1


Re: [OE-core] How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?

JH
 

Hi Federico,

Thanks for your response.

/etc/profile and similar are interactive shell (/bash) concepts, not really
system startup ones. So indeed: just on a login (be it local, ssh and so
on) they are executed.
Understood, here is what I try to figure out. I use several systemd
services to start my tasks, each task is not just a system process, I
found it also has a system environment similar in user login from
/etcprofile, /home/user/.profile, my question is where is a system
environment file that each systemd service runs from?

I also thought that /etc/profile.d files should be automatically
invoked for each user login, but a systemd service does not run
/etc/profile.d files.

If you want to execute something else without the need for logging it, you
should look elsewhere, depending on your system manager: if systemd you
should create a service and enable it, if sysvinit a init.d script.
Understood, that was what I did originally, I have to run the setup
system environment in each service ExecStart script, that is why I am
looking for a global environment setup file to avoid duplication of
putting my environment scripts in each ExecStart execution file.

Thank you.

Kind regards,

- jupiter

HTH,
Federico


Il giorno lun 11 ott 2021 alle ore 06:30 JH <jupiter.hce@...> ha
scritto:

Hi,

The Yocto uses /etc/profile for root login, but there is no root
physical login in an embedded device so the /etc/profile is never
called, I added a shell script to /etc/profile.d, it was not called
either. Both /etc/profile and scripts in /etc/profile.d can only be
invoked when I physically log into the debug console, that is
impractical. Appreciate your advice, how do you resolve that kind of
problem?

Thank you.

Kind regards,

- jupiter




--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs


Re: Yocto build error

Alexander Kanavin
 

You need to show the full command line that produces the error.

Alex


On Mon, 11 Oct 2021 at 03:45, JH <jupiter.hce@...> wrote:
Hi,

I have following errors:

No GNU_HASH in the ELF binary
/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/solar/1.0.0-0/packages-split/wifi_signal,
didn't pass LDFLAGS? [ldflags]

So I add --hash-style=gnu to my Makefile:

LD_FLAGS += --hash-style=gnu
LDFLAGS = LD_FLAGS

But that does not work:

arm-oe-linux-gnueabi-gcc: error: unrecognized command line option
'--hash-style=gnu'

What is wrong about the error if the  --hash-style=gnu is not the right fix?

Thank you.

Kind regards.

JH




Re: [OE-core] How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?

Federico Pellegrin
 


Hi Jupiter,
/etc/profile and similar are interactive shell (/bash) concepts, not really system startup ones. So indeed: just on a login (be it local, ssh and so on) they are executed.

If you want to execute something else without the need for logging it, you should look elsewhere, depending on your system manager: if systemd you should create a service and enable it, if sysvinit a init.d script.

HTH,
Federico


Il giorno lun 11 ott 2021 alle ore 06:30 JH <jupiter.hce@...> ha scritto:
Hi,

The Yocto uses /etc/profile for root login, but there is no root
physical login in an embedded device so the /etc/profile is never
called, I added a shell script to /etc/profile.d, it was not called
either. Both /etc/profile and scripts in /etc/profile.d can only be
invoked when I physically log into the debug console, that is
impractical. Appreciate your advice, how do you resolve that kind of
problem?

Thank you.

Kind regards,

- jupiter




Re: [OE-core] How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?

Chuck Wolber
 

On Sun, Oct 10, 2021 at 9:30 PM JH <jupiter.hce@...> wrote:
The Yocto uses /etc/profile for root login, but there is no root
physical login in an embedded device so the /etc/profile is never
called, I added a shell script to /etc/profile.d, it was not called
either. Both /etc/profile and scripts in /etc/profile.d can only be
invoked when I physically log into the debug console, that is
impractical. Appreciate your advice, how do you resolve that kind of
problem?

What problem are you attempting to solve by running a script from /etc/profile.d?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?

JH
 

Hi,

The Yocto uses /etc/profile for root login, but there is no root
physical login in an embedded device so the /etc/profile is never
called, I added a shell script to /etc/profile.d, it was not called
either. Both /etc/profile and scripts in /etc/profile.d can only be
invoked when I physically log into the debug console, that is
impractical. Appreciate your advice, how do you resolve that kind of
problem?

Thank you.

Kind regards,

- jupiter


Yocto build error

JH
 

Hi,

I have following errors:

No GNU_HASH in the ELF binary
/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/solar/1.0.0-0/packages-split/wifi_signal,
didn't pass LDFLAGS? [ldflags]

So I add --hash-style=gnu to my Makefile:

LD_FLAGS += --hash-style=gnu
LDFLAGS = LD_FLAGS

But that does not work:

arm-oe-linux-gnueabi-gcc: error: unrecognized command line option
'--hash-style=gnu'

What is wrong about the error if the --hash-style=gnu is not the right fix?

Thank you.

Kind regards.

JH


Re: LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

mrkozmic@...
 

Bruce,
It's an honor to get help from the author himself!

I'm starting to understand why they have this:

do_configure_prepend() {
     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
}

Since do_kernel_configme() creates the .config file in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-yocto.bbclass?h=dunfell#n399
(I can't figure out why it fails to merge in our defconfig)

Then the ${WORKDIR}/defconfig is not used by kernel_do_configure() https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n595
So they do the copy of defconfig in do_configure_prepend(). 

Anyway,  do_kernel_configme() has already been run hence no CONFIG_LOCALVERSION is written to .config


I could just do this:
do_configure_prepend() {
     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
     echo "CONFIG_LOCALVERSION=\"${LINUX_VERSION_EXTENSION}\"" >> "${B}/.config"
}

 

BUT
Your hint make me notice that they did: KCONFIG_MODE="--allnoconfig" which breaks the config merging.
After changing it to alldefconfig and removing do_configure_prepend it all works!

Thank you!
 

 

 


Re: LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

mrkozmic@...
 

Bruce, I just realized that I replied only to you and not to the group. Hope it is ok that I post your answer here. 
 

On Sat, Oct 9, 2021 at 6:19 AM <mrkozmic@...> wrote:
>
> Bruce,
>
> Here .config is written in the kernel_configme task: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.yoctoproject.org%2Fcgit%2Fcgit.cgi%2Fpoky%2Ftree%2Fmeta%2Fclasses%2Fkernel-yocto.bbclass%3Fh%3Ddunfell%23n409&amp;data=04%7C01%7C%7C7757b810abc444e512cc08d98b32ecb1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637693873092757103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FURpcXvzhAKEpN%2BHHmmMpshn3CJNHJxUvFkktaGCf80%3D&amp;reserved=0
>

Yes, I'm the one that wrote all of the fragment handling and
processing, so unless something else is being injected into the tasks,
I know how it should work :)

> My kernel recipe (not written by me) is made up of several files. I found this:
> do_configure_prepend() {
>     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
> }
> Which makes sense why it does not work. So I removed these lines and I see why someone put them there. My defconfig is not put into the .config file by the merge_config.sh script.
> It looks like the script does everything correctly, but the resulting .config is always the default, nothing is included from my defconfig.

Considering that linux-yocto has had support for using an in-tree
defconfig for a long time, indeed, that is a strange thing for someone
to write!

Is KBUILD_DEFCONFIG defined in your recipe ? If so, the kernel-yocto
bbclass will do a similar copy and use that as the baseline.

>
> The final .config is generated in merge_config.sh by
> make LD="$LD" KCONFIG_ALLCONFIG=$TMP_FILE $OUTPUT_ARG $ALLTARGET
> I have checked, and the $TMP_FILE is the same as my defconfig. The log from merge_script.sh lists all CONFIG_* that where requested, but not included in the final .config, they all come from my defconfig.
>
> Looks like make does not care about KCONFIG_ALLCONFIG=$TMP_FILE

No, that wouldn't be the case.

Just because you have something in a defconfig, or a configuration
fragment, doesn't mean that it ends up in the final .config. They are
still subject to the dependencies, defaults, selects, etc, of the
Kconfig files within the kernel tree as the configuration phase of the
kernel is executed.

If you have a defconfig in your workdir, the mode of merge config is
set to "-n", which is an allnoconfig, and then what you have in your
defconfig will be applied based on those conditions. If your defconfig
is based on a savedefconfig (which many of them are now, in particular
in tree ones).  If you want to use defaults  and then apply your
defconfig, you need to specify KCONFIG_MODE="alldefconfig" in your
kernel recipe (maybe you are already doing that, but it is worth
mentioning).

But given that KBUILD_DEFCONFIG copy that you found, clearly there are
some custom things happening, so I really can't say for sure.
 
 
Bruce

>



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: #zeus meta-intel #zeus

Anuj Mittal
 

On Fri, 2021-10-08 at 16:10 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:

Sorry for my ignorance, but I am missing your point, what exactly
does the recipe provide when built, intel-opencl-icd ?, will it pull
in igc ?
It will pull in igc. There's a separate recipe for igc in meta-intel.
compute-runtime will provide intel-opencl-icd but the package name is
different.

You can try building the recipe.

Thanks,

Anuj


-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 12:01 PM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros. 
For further information on how to spot phishing, access
“Cybersecurity OneSpace Page” and report phishing by clicking the
button “Report Phishing” on the Outlook toolbar.


Sorry, I didn't understand the question. If you want to know which
version of OpenCL is supported, please see the README for version
that you're building. Also see:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj

On Fri, 2021-10-08 at 15:30 +0000, Monsees, Steven C (US) wrote:

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support
?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are
requested
to click on a link, decrypt/open an attachment, or enable macros. 
For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should
basically
build opencl (Neo) with all the required dependencies… I did not
think Yocto had support for OpenCL, and was looking to build Neo
under the SDK.
 
(1)   Is this true, does meta-intell under zeus now support
building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is
no
longer maintained so the version there is old and not tested now
but
it should still build.

(2)   Of so, what would be the proper way to pull this into my
yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj


2801 - 2820 of 57790