Date   

#yocto #bitbake #gatesgarth #qca9377 #qca9377 #yocto #bitbake #gatesgarth

jovanalukovic0@...
 

Hi,
I am trying to include qca9377 module in my image (yocto-gatesgarth). I am using command  bitbake imx-image-full, and i added two lines in my local.conf file: MACHINE_FEATURES += " qca9377"
IMAGE_INSTALL_append += " kernel-module-qca9377", but i get constantly the same mistake:
ERROR: kernel-module-qca9377-3.1-r0 do_compile: oe_runmake failed
ERROR: kernel-module-qca9377-3.1-r0 do_compile: Execution of '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/temp/run.do_compile.25256' failed with exit code 1:
make -C /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source M=/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git modules WLAN_ROOT=/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git MODNAME?=wlan CONFIG_QCA_WIFI_ISOC=0 CONFIG_QCA_WIFI_2_0=1 CONFIG_QCA_CLD_WLAN=m WLAN_OPEN_SOURCE=1  
make[1]: Entering directory '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source'
make[2]: Entering directory '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-build-artifacts'
and this is just a part of whole group of mistakes. There are a lot of mistakes, for examples:
cc1: some warnings being treated as errors
| /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source/scripts/Makefile.build:279: recipe for target '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_oemdata.o' failed
| make[3]: *** [/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_oemdata.o] Error 1
| /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source/scripts/Makefile.build:279: recipe for target '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_early_suspend.o' failed.
Do you have eny ideas what can i do? Do i miss something for my compiling?

Best regards and thanks a lot!


#bitbake Can't use 'bitbake -g <image-name> -u taskdep #bitbake

keydi
 

Hi,
Myself had to ask web search engine for usage of Task Dependency Explorer taskexp as I didn't succeed on search in Yocto materials.
Hence, the way I try to use taskexp might be not right.

In the fashion as I try to start Task Dependency Explorer it does not work.
Invocation completes with error in __init__.py  -> require_version figures out lack of Gtk namespace.
Which is build-area Gtk is missed? Image, distribution, yet another? 
Which way of fixing should I aim to resolve error?

  File "/mnt/..../meta/poky/bitbake/lib/bb/ui/taskexp.py", line 22, in <module>
    gi.require_version('Gtk', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 130, in require_version
    raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available

Best Regards
keydi
 


Re: [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default

Richard Purdie
 

On Fri, 2021-04-16 at 09:28 +0100, Richard Purdie via lists.yoctoproject.org wrote:
On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
add the variables required to collect data to "defaults"
so that data is collected on all builds.

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 config.json | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index c43d231..cd82047 100644
--- a/config.json
+++ b/config.json
@@ -55,7 +55,10 @@
             "SDK_INCLUDE_TOOLCHAIN = '1'",
             "BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K STOPTASKS,${DL_DIR},1G STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M ABORT,/tmp,10M,1K'",
             "BB_HASHSERVE = 'typhoon.yocto.io:8686'",
- "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'"
+ "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
+ "BB_HEARTBEAT_EVENT = '10'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
         ]
     },
     "templates" : {
I merged 2-4 of this series, unfortunately this resulted in a few issues overnight:

https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1393

which is due to the non-executable script which there is a patch for, it just
wasn't in master due to the release. I've fixed that by merging the patches.

The bigger issue is the performance metrics which this broke:

https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/4427
https://autobuilder.yoctoproject.org/typhoon/#/builders/92/builds/4453

We're going to need to disable these events on the performance metrics
targets...
There is also another issue as BB_HEARTBEAT_EVENT defaults to 1, the change to 10 
changes the default timings for buildstats and other pieces of code. In particular
I suspect this is breaking:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1993

and again in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2014

in the disk monitoring selftest...

Cheers,

Richard


Re: [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default

Richard Purdie
 

On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
add the variables required to collect data to "defaults"
so that data is collected on all builds.

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 config.json | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index c43d231..cd82047 100644
--- a/config.json
+++ b/config.json
@@ -55,7 +55,10 @@
             "SDK_INCLUDE_TOOLCHAIN = '1'",
             "BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K STOPTASKS,${DL_DIR},1G STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M ABORT,/tmp,10M,1K'",
             "BB_HASHSERVE = 'typhoon.yocto.io:8686'",
- "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'"
+ "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
+ "BB_HEARTBEAT_EVENT = '10'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
         ]
     },
     "templates" : {
I merged 2-4 of this series, unfortunately this resulted in a few issues overnight:

https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1393

which is due to the non-executable script which there is a patch for, it just
wasn't in master due to the release. I've fixed that by merging the patches.

The bigger issue is the performance metrics which this broke:

https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/4427
https://autobuilder.yoctoproject.org/typhoon/#/builders/92/builds/4453

We're going to need to disable these events on the performance metrics
targets...

Cheers,

Richard


Re: Building image from Root

Mike Looijmans
 

You can use both by changing the directory for downloads and sstate-cache. Put these in your local.conf:

SSTATE_DIR = "/opt/sstate-cache"
DL_DIR = "/opt/downloads"

(You change "/opt" to some other location. Make sure you have write access to those directories)

Move the contents of the build/sstate-cache and downloads to the new directories.

You really should consider adding extra storage. It's the easiest way out. OpenEmbedded/Yocto is insensitive to disk speed, so if you have some old rotating disk in the attic, put that in your PC.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

On 15-04-2021 17:34, Murugesh M via lists.yoctoproject.org wrote:
Hi

I am new to Yocto project and have little experience in Linux.

In my computer, Root folder is having free space of 65 GB and Home is having 45 GB free space.

Shall I get the poky in root folder and do the complete Yocto build image process from Root directory itself?

Please suggest.

Thanks.

--
Mike Looijmans


Re: Building image from Root

Khem Raj
 

try adding

INHERIT += "rm_work"

to local.conf and see if that helps

On Thu, Apr 15, 2021 at 11:11 PM Murugesh M <murugesh.pappu@gmail.com> wrote:

I had proceeded the Build image process with Home directory and got stuck with low disk space.
Now, the build image process is stopped almost near to last stage.

Please provide me any suggestion to come out of this problem.


Re: Building image from Root

Murugesh M
 

I had proceeded the Build image process with Home directory and got stuck with low disk space.
Now, the build image process is stopped almost near to last stage.

Please provide me any suggestion to come out of this problem.


Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template

Randy MacLeod
 

On 2021-04-15 1:55 p.m., Randy MacLeod wrote:
On 2021-04-15 11:55 a.m., Richard Purdie wrote:
On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:
On 2021-04-15 9:52 a.m., Richard Purdie wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]

On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
collect-data template can run arbitrary commands/scripts
on a regular basis and logs the output in a file.

See oe-core for more details:
      edb7098e9e buildstats.bbclass: add functionality to collect build system stats

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
   config.json | 7 +++++++
   1 file changed, 7 insertions(+)

diff --git a/config.json b/config.json
index 5bfa240..c43d231 100644
--- a/config.json
+++ b/config.json
@@ -87,6 +87,13 @@
                   "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
               }
           },
+     "collect-data" : {
+            "extravars" : [
+                "BB_HEARTBEAT_EVENT = '10'",
+                "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+                "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
+            ]
+        },
Is the template used anywhere? I can't remember if we support nesting templates in which
case this is useful, or not?
We were using it for testing on the YP AB and thought it would be
useful if at some point the monitoring was dropped from the
default config.
I think we can just add it later if needed.
Richard,

I think that the web server for:
https://autobuilder.yocto.io/pub/non-release/
runs every 30 seconds via cron so if you are happy with
this crude dd trigger once things have soaked in master-next
and we want to gather some data overnight, could you merge to master?


I ran a simpler test with fewer io stressors from:
$ stress -hdd N
and have attached a graph with up to 3000! stressors that
we looked at this morning and another with up to 35 stressors.

It's a crude indicators but once we get beyond 18-20 io stressors
on the system I tested (48 cores, 128 GB RAM, 12 TB magnetic disk)
dd time become erratic.

Running qemu from tmpfs has clearly helped.
Let's gather some data and decide if we want to spend more time
learning how to monitor the system to tune how we are using it.

../Randy

../Randy

Cheers,

Richard
The template is not used anywhere, yet, the initial patchset enables the
data collection by default.

I have left the template in case the data collection is removed from
defaults and need to be used on a case by case basis.

I am not entirely sure if nesting templates work. I have not seen any
examples of it, neither did i try it myself. If nesting does work, the
template should be useful.
I had a quick look at the code and sadly, it doesn't appear I implemented
nesting so this wouldn't be that useful as things stand.

Cheers,

Richard





--
# Randy MacLeod
# Wind River Linux


Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template

Randy MacLeod
 

On 2021-04-15 11:55 a.m., Richard Purdie wrote:
On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:
On 2021-04-15 9:52 a.m., Richard Purdie wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]

On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
collect-data template can run arbitrary commands/scripts
on a regular basis and logs the output in a file.

See oe-core for more details:
     edb7098e9e buildstats.bbclass: add functionality to collect build system stats

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
  config.json | 7 +++++++
  1 file changed, 7 insertions(+)

diff --git a/config.json b/config.json
index 5bfa240..c43d231 100644
--- a/config.json
+++ b/config.json
@@ -87,6 +87,13 @@
                  "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
              }
          },
+ "collect-data" : {
+ "extravars" : [
+ "BB_HEARTBEAT_EVENT = '10'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
+ ]
+ },
Is the template used anywhere? I can't remember if we support nesting templates in which
case this is useful, or not?
We were using it for testing on the YP AB and thought it would be
useful if at some point the monitoring was dropped from the
default config.

I think we can just add it later if needed.

../Randy

Cheers,

Richard
The template is not used anywhere, yet, the initial patchset enables the
data collection by default.

I have left the template in case the data collection is removed from
defaults and need to be used on a case by case basis.

I am not entirely sure if nesting templates work. I have not seen any
examples of it, neither did i try it myself. If nesting does work, the
template should be useful.
I had a quick look at the code and sadly, it doesn't appear I implemented
nesting so this wouldn't be that useful as things stand.
Cheers,
Richard

--
# Randy MacLeod
# Wind River Linux


Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template

Richard Purdie
 

On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:
On 2021-04-15 9:52 a.m., Richard Purdie wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]

On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
collect-data template can run arbitrary commands/scripts
on a regular basis and logs the output in a file.

See oe-core for more details:
     edb7098e9e buildstats.bbclass: add functionality to collect build system stats

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
  config.json | 7 +++++++
  1 file changed, 7 insertions(+)

diff --git a/config.json b/config.json
index 5bfa240..c43d231 100644
--- a/config.json
+++ b/config.json
@@ -87,6 +87,13 @@
                  "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
              }
          },
+ "collect-data" : {
+ "extravars" : [
+ "BB_HEARTBEAT_EVENT = '10'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
+ ]
+ },
Is the template used anywhere? I can't remember if we support nesting templates in which
case this is useful, or not?

Cheers,

Richard
The template is not used anywhere, yet, the initial patchset enables the
data collection by default.

I have left the template in case the data collection is removed from
defaults and need to be used on a case by case basis.

I am not entirely sure if nesting templates work. I have not seen any
examples of it, neither did i try it myself. If nesting does work, the
template should be useful.
I had a quick look at the code and sadly, it doesn't appear I implemented 
nesting so this wouldn't be that useful as things stand.

Cheers,

Richard


Building image from Root

Murugesh M
 

Hi

I am new to Yocto project and have little experience in Linux.

In my computer, Root folder is having free space of 65 GB and Home is having 45 GB free space.

Shall I get the poky in root folder and do the complete Yocto build image process from Root directory itself?

Please suggest.

Thanks.


Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template

Richard Purdie
 

On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
collect-data template can run arbitrary commands/scripts
on a regular basis and logs the output in a file.

See oe-core for more details:
    edb7098e9e buildstats.bbclass: add functionality to collect build system stats

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 config.json | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/config.json b/config.json
index 5bfa240..c43d231 100644
--- a/config.json
+++ b/config.json
@@ -87,6 +87,13 @@
                 "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
             }
         },
+ "collect-data" : {
+ "extravars" : [
+ "BB_HEARTBEAT_EVENT = '10'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
+ ]
+ },
Is the template used anywhere? I can't remember if we support nesting templates in which 
case this is useful, or not?

Cheers,

Richard


what to include in a "hardware bringup image"?

Robert P. J. Day
 

for a current project (and subsequent projects), i want to define a
hardware bringup image; that is, a really basic image chock-full of
low-level utilities for debugging initial board bringup. this means
precious little unnecessary userspace crud that has no value in that
context. (at the moment, the target is aarch64 but, naturally, the
ideal image would be maximally applicable no matter the target.)

i'm thinking of recipes that allow probing/configuration of memory
and busses and that sort of thing. off the top of my head:

* pciutils
* usbutils
* libgpiod
* phytool (or other MDIO probe/debug tools)
* devmem2
* spidev-test/spitools
* i2c-tools

the list can go on and on, and i just ran across this which i had
never seen before:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/c-periphery/c-periphery_2.3.1.bb?h=master

suggestions? i suspect numerous folks on this list have already done
something like this.

rday


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

Purushottam choudhary
 

Hi,

Could you please let me know if there is any update on this change?

Thanks & Regards,
Purushottam


From: Purushottam Choudhary <purushottam.choudhary@...>
Sent: Tuesday, March 16, 2021 3:03 PM
To: yocto@... <yocto@...>
Cc: Nisha Parrakat <Nisha.Parrakat@...>
Subject: [yocto][meta-selinux][PATCH] openssh: don't overwrite sshd_config unconditionally
 
The current implementation was overwriting the sshd_config and sshd
assuming PAM is needed by default.

openssh should use the default sshd_config packaged with the component
if no distro specific needs are present and not overwrite the full
sshd_config file.

1. If PAM is enabled as a distro then enable the UsePAM option in sshd_config.
2. Moved the file sshd to pam directory so that when pam is enabled,
   then replace the default from poky by installing the same.

Signed-off-by: Purushottam Choudhary <purushottam.choudhary@...>
---
 recipes-connectivity/openssh/files/{ => pam}/sshd |   0
 recipes-connectivity/openssh/files/sshd_config    | 118 ----------------------
 recipes-connectivity/openssh/openssh_%.bbappend   |  14 +++
 3 files changed, 14 insertions(+), 118 deletions(-)
 rename recipes-connectivity/openssh/files/{ => pam}/sshd (100%)
 delete mode 100644 recipes-connectivity/openssh/files/sshd_config

diff --git a/recipes-connectivity/openssh/files/sshd b/recipes-connectivity/openssh/files/pam/sshd
similarity index 100%
rename from recipes-connectivity/openssh/files/sshd
rename to recipes-connectivity/openssh/files/pam/sshd
diff --git a/recipes-connectivity/openssh/files/sshd_config b/recipes-connectivity/openssh/files/sshd_config
deleted file mode 100644
index 1c33ad0..0000000
--- a/recipes-connectivity/openssh/files/sshd_config
+++ /dev/null
@@ -1,118 +0,0 @@
-#      $OpenBSD: sshd_config,v 1.102 2018/02/16 02:32:40 djm Exp $
-
-# This is the sshd server system-wide configuration file.  See
-# sshd_config(5) for more information.
-
-# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
-
-# The strategy used for options in the default sshd_config shipped with
-# OpenSSH is to specify options with their default value where
-# possible, but leave them commented.  Uncommented options override the
-# default value.
-
-#Port 22
-#AddressFamily any
-#ListenAddress 0.0.0.0
-#ListenAddress ::
-
-#HostKey /etc/ssh/ssh_host_rsa_key
-#HostKey /etc/ssh/ssh_host_ecdsa_key
-#HostKey /etc/ssh/ssh_host_ed25519_key
-
-# Ciphers and keying
-#RekeyLimit default none
-
-# Logging
-#SyslogFacility AUTH
-#LogLevel INFO
-
-# Authentication:
-
-#LoginGraceTime 2m
-#PermitRootLogin prohibit-password
-#StrictModes yes
-#MaxAuthTries 6
-#MaxSessions 10
-
-#PubkeyAuthentication yes
-
-# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
-# but this is overridden so installations will only check .ssh/authorized_keys
-#AuthorizedKeysFile    .ssh/authorized_keys
-
-#AuthorizedPrincipalsFile none
-
-#AuthorizedKeysCommand none
-#AuthorizedKeysCommandUser nobody
-
-# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
-#HostbasedAuthentication no
-# Change to yes if you don't trust ~/.ssh/known_hosts for
-# HostbasedAuthentication
-#IgnoreUserKnownHosts no
-# Don't read the user's ~/.rhosts and ~/.shosts files
-#IgnoreRhosts yes
-
-# To disable tunneled clear text passwords, change to no here!
-#PasswordAuthentication yes
-#PermitEmptyPasswords no
-
-# Change to yes to enable challenge-response passwords (beware issues with
-# some PAM modules and threads)
-ChallengeResponseAuthentication no
-
-# Kerberos options
-#KerberosAuthentication no
-#KerberosOrLocalPasswd yes
-#KerberosTicketCleanup yes
-#KerberosGetAFSToken no
-
-# GSSAPI options
-#GSSAPIAuthentication no
-#GSSAPICleanupCredentials yes
-
-# Set this to 'yes' to enable PAM authentication, account processing,
-# and session processing. If this is enabled, PAM authentication will
-# be allowed through the ChallengeResponseAuthentication and
-# PasswordAuthentication.  Depending on your PAM configuration,
-# PAM authentication via ChallengeResponseAuthentication may bypass
-# the setting of "PermitRootLogin without-password".
-# If you just want the PAM account and session checks to run without
-# PAM authentication, then enable this but set PasswordAuthentication
-# and ChallengeResponseAuthentication to 'no'.
-UsePAM yes
-
-#AllowAgentForwarding yes
-#AllowTcpForwarding yes
-#GatewayPorts no
-#X11Forwarding no
-#X11DisplayOffset 10
-#X11UseLocalhost yes
-#PermitTTY yes
-#PrintMotd yes
-#PrintLastLog yes
-#TCPKeepAlive yes
-#UseLogin no
-#PermitUserEnvironment no
-Compression no
-ClientAliveInterval 15
-ClientAliveCountMax 4
-#UseDNS no
-#PidFile /var/run/sshd.pid
-#MaxStartups 10:30:100
-#PermitTunnel no
-#ChrootDirectory none
-#VersionAddendum none
-
-# no default banner path
-#Banner none
-
-# override default of no subsystems
-Subsystem      sftp    /usr/libexec/sftp-server
-
-# Example of overriding settings on a per-user basis
-#Match User anoncvs
-#      X11Forwarding no
-#      AllowTcpForwarding no
-#      PermitTTY no
-#      ForceCommand cvs server
diff --git a/recipes-connectivity/openssh/openssh_%.bbappend b/recipes-connectivity/openssh/openssh_%.bbappend
index 7719d3b..b541c3e 100644
--- a/recipes-connectivity/openssh/openssh_%.bbappend
+++ b/recipes-connectivity/openssh/openssh_%.bbappend
@@ -1 +1,15 @@
 require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', '${BPN}_selinux.inc', '', d)}
+
+# if pam feature is enabled in the distro then take sshd from the pam directory.
+FILESEXTRAPATHS_prepend := "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${THISDIR}/files/pam:', ' ', d)}"
+
+do_install_append(){
+
+    if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+        # Make sure UsePAM entry is in the sshd_config file.
+        # If entry not present then append it.
+        grep -q 'UsePAM' "${D}/etc/ssh/sshd_config" && \
+        sed -i 's/.*UsePAM.*/UsePAM yes/' "${D}/etc/ssh/sshd_config" || \
+        echo 'UsePAM yes' >> "${D}/etc/ssh/sshd_config"
+    fi
+}
--
2.7.4

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.


[meta-intel-fpga] [PATCH] layer.conf: add layer compatibility to hardknott

Meng Li
 

From: Meng Li <Meng.Li@windriver.com>

Signed-off-by: Meng Li <Meng.Li@windriver.com>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 756e7f4..4b45db9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,6 +9,6 @@ BBFILE_PATTERN_meta-intel-fpga := "^${LAYERDIR}/"

# Increase the layer priority
BBFILE_PRIORITY_meta-intel-fpga = "6"
-LAYERSERIES_COMPAT_meta-intel-fpga = "dunfell gatesgarth"
+LAYERSERIES_COMPAT_meta-intel-fpga = "dunfell gatesgarth hardknott"

BBDEBUG = "yes"
--
2.17.1


Re: #golang: go fetches dependencies in compile phase

Robert Berger
 

Hi,

My comments are inline.

On 12/04/2021 14:47, Juergen Landwehr wrote:
Hi Robert,
thanks for your thoughts.
I see your point and the last thing I want is "NOT reproducable builds".
But dependency management in go is not that arbitrary as it may seem.
... if everybody does what they are supposed to - which is not the case.

Dependencies and their version is stored in "go.mod". To ensure reproducable builds, hashes for each dependency and version are stored in "go.sum". Both files are in git and together with a local golang proxy, this should ensure reproducable builds, right?
This does not sound too bad. This would also mean, that if the outside repo dies you can still build and that you know what's on your proxy.

To ensure that licences are valid and did not change over time, we developed a little tool, that goes through all dependencies and creates the following output, which we insert into our recipe:
LICENSE = "Apache-2.0 & MIT & MIT & BSD-2-Clause & BSD-3-Clause & ...
Here you

1) Totally lost which License comes from which module and I hope 2 times MIT is just a typo.

Of course if you are really serious about licensing you should use a tool like fossology, upload all your sources there and inspect them.
You will be surprised.

There are a couple of tools out there which scan your sources and some which claim to do stuff with golang as well.

2) Do you check if the licenses are compatible?

MIT and Apache are compatible:

some googling:

"Both the Apache License and the MIT license are permissive, so incorporating MIT licensed code into your Apache licensed project is certainly allowed. Just be sure to attribute the original author for the parts your incorporated and include a copy of the MIT License terms, as required by the license."

Apache and BSD should also be OK:

some googling:

"In both of them you must:

Include copyright

But in Apache, unlike BSD you must:

Include License
State Changes
Include Notice
"

LIC_FILES_CHKSUM = " \
file://${S}/src/${GO_IMPORT}/vendor/github.com/coreos/go-oidc/LICENSE;md5=d2794c0df5b907fdace235a619d80314 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/locales/LICENSE;md5=3ccbda375ee345400ad1da85ba522301 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/universal-translator/LICENSE;md5=2e2b21ef8f61057977d27c727c84bef1 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/godbus/dbus/v5/LICENSE;md5=09042bd5c6c96a2b9e45ddf1bc517eed \
file://${S}/src/${GO_IMPORT}/vendor/github.com/golang/gddo/LICENSE;md5=4c728948788b1a02f33ae4e906546eef \
...
This is a manual step and whenever dependencies change we have to create this list again and add it to the recipe, but it contains all the required license information and makes them visible in the recipe.
really all?

You search through every single file of a go module and it's dependencies? Or just the license text, if there is one?

It might pollute the recipe a bit, but luckily we do not have thousands of dependencies like some npm projects. So I think it is still manageable. And is it much less work, than defining a recipe for each dependency.
So we would
* guarantee reproducable builds
* use the programming language (in our case golang) to handle dependency management
* ensure that licenses are visible and correct
I mean it is not perfect and still a compromise, but it should work without breaking reproducable builds or causing license issues?
What do you think?
Regards,
Jürgen
PS: Thanks for the link. I was not aware of this discussion (it is quite a bit to read:))
Regards,

Robert


Re: Cannot execute nodejs

Alessandro Tagliapietra
 

I was able to solve it by forcing recompiling nodejs with `bitbake -f -c compile nodejs`

Not sure what happened there

--
Alessandro Tagliapietra



On Wed, Apr 14, 2021 at 11:51 AM Alessandro Tagliapietra <tagliapietra.alessandro@...> wrote:
Hi everyone,

I've installed nodejs and node-red  by using meta-oe and meta-iot-cloud, with

IMAGE_INSTALL_append = " nodejs node-red bash"

it was initially working but then I've got some pseudo aborts that fixed automatically and then I saw that:
 - /usr/bin/node doesn't have the +x flag
 - the file is 1.1G big (however the image is 200MB)
 - trying to run it says "cannot execute binary file: Exec format error"

any idea why?

Target is core-image-minimal with machine qemuarm.
I've checked the source of the file with `oe-pkgdata-util find-path` it came from the nodejs recipe. I've also tried bitbake -c clean nodejs and nothing changed



Cannot execute nodejs

Alessandro Tagliapietra
 

Hi everyone,

I've installed nodejs and node-red  by using meta-oe and meta-iot-cloud, with

IMAGE_INSTALL_append = " nodejs node-red bash"

it was initially working but then I've got some pseudo aborts that fixed automatically and then I saw that:
 - /usr/bin/node doesn't have the +x flag
 - the file is 1.1G big (however the image is 200MB)
 - trying to run it says "cannot execute binary file: Exec format error"

any idea why?

Target is core-image-minimal with machine qemuarm.
I've checked the source of the file with `oe-pkgdata-util find-path` it came from the nodejs recipe. I've also tried bitbake -c clean nodejs and nothing changed


#yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool #yocto #sdk

Monsees, Steven C (US)
 

 

Working with zeus 3.0.4, extended SDK…

 

Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ?

 

Thanks…

 

When I add in native-python3 support

 

#

# Additional SDK Setup variables

#

 

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

 

SDK_EXTRA_TOOLS = "  \

     nativesdk-python3-pprint \

     nativesdk-python3-pickle \

     nativesdk-python3-shell \

     nativesdk-python3-modules \

     nativesdk-python3-distutils \

     nativesdk-python3-xml \

     nativesdk-python3-compile \

     nativesdk-python3-six \

     nativesdk-cmake \

     "

 

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

 

I see the following error with devtool:

 

13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

13:08 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: Success

 

If I remove the “native-python” components, the issue goes away:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    "

 

14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

14:11 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

NOTE: Starting bitbake server...

usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]

               [--color COLOR] [-h]

               <subcommand> ...

 

OpenEmbedded development tool

 

options:

  --basepath BASEPATH   Base directory of SDK / build directory

  --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it

                        from the metadata

  -d, --debug           Enable debug output

  -q, --quiet           Print only errors

  --color COLOR         Colorize output (where COLOR is auto, always, never)

  -h, --help            show this help message and exit

 

subcommands:

  Beginning work on a recipe:

    add                   Add a new recipe

    modify                Modify the source for an existing recipe

    upgrade               Upgrade an existing recipe

  Getting information:

    status                Show workspace status

    search                Search available recipes

    latest-version        Report the latest version of an existing recipe

    check-upgrade-status  Report upgradability for multiple (or all) recipes

  Working on a recipe in the workspace:

    build                 Build a recipe

    rename                Rename a recipe file in the workspace

    edit-recipe           Edit a recipe file

    find-recipe           Find a recipe file

    configure-help        Get help on configure script options

    update-recipe         Apply changes from external source tree to recipe

    reset                 Remove a recipe from your workspace

    finish                Finish working on a recipe in your workspace

  Testing changes on target:

    deploy-target         Deploy recipe output files to live target machine

    undeploy-target       Undeploy recipe output files in live target machine

    package               Build packages for a recipe

    build-image           Build image including workspace recipe packages

    runqemu               Run QEMU on the specified image

  Advanced:

    build-sdk             Build a derivative SDK of this one

    extract               Extract the source for an existing recipe

    sync                  Synchronize the source tree for an existing recipe

    export                Export workspace into a tar archive

    import                Import exported tar archive into workspace

    menuconfig            Alter build-time configuration for a recipe

  SDK maintenance:

    sdk-update            Update SDK components

    sdk-install           Install additional SDK components

Use devtool <subcommand> --help to get help on a specific command

14:11 smonsees@yix490016 /disk0/scratch/smonsees>

 

 


Yocto Technical Team Minutes, Engineering Sync, for April 13, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for April 13, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Alexandre Belloni, Jere Viikari, Richard
Purdie, Scott Murray, Peter Kjellerstedt, Armin Kuster, Saul Wold, Steve
Sakoman, Randy MacLeod, Trevor Gamblin, Ross Burton, Bruce Ashfield, Paul
Barker, sakib.sajal@WR, Tim Orling, Joshua Watt, Alejandro H

== notes ==
- 3.3-rc2 had a clean QA, waiting on TSC approval and release notes update
- 3.3-rc1 was abandoned due to build issue
- 3.1.7 building as we speak
- prserv rework and git fetcher work underway

== general ==
RP: relatively quiet week, couple of issues here and there bitbake setscene
(covered vs not-covered)
Ross: interesting cycle, lots of good work
RP: agreed, community effort
RP: i think the next release won’t be as quiet, there are a number of things
that we need to shake up


Randy: Sakib and I have some filters enabled to capture stats when AB issues
occur. ready to be enabled. tested locally but our cluster isn’t pushed
as hard as the real AB


JPEW: next release in Oct?
RP: yes, see report sent by S Jolley
JPEW: then the release after that is the LTS?
RP: yes, Spring 2022.
RP: however, we need to get buy-in from members. the first was an experiment,
it seems good
JPEW: LTS works for me. seems like lots of BSP vendors focused on LTS which
made it easy to build across a large range of MACHINEs
Randy: yocto LTS or kernel LTS?
JPEW: yocto LTS, we’re stuck with vendor kernels for the most part
RP: informal survey wrt LTS: general feeling that it was liked among member
companies
RP: can we “prove” the value of LTS with data? perhaps CVE fixes?
Saul: lots of problems collecting data (e.g. we don’t even know how people
are using it)
AlexB: premirrors for poky?
RP: true, but there are guidelines wrt the use of that data
RP: to be a true comparison we’d have to compare LTS to a non-LTS, but
non-LTS don’t occur over the same time-span, so a comparison might be
hard. maybe CVE commits
SS: I do have data since June of CVE adds/removes etc. but the data can get
confusing
RP: what if we looked at the data wrt each point release
SS: it’s possible, it’ll take time. we could also try to increase the
number of dot releases


TrevorW: i don’t think Dunfell is y2038 safe
AlexB: i *know* it’s not safe, need kernel and glibc
TrevorW: okay, is this something that we’re going to worry about for dunfell
RP: i’ve been getting private emails on this topic (not sure why they’re
private) so it is something we should look at. i recommend we start a wiki
page. some people say we need a 5.10 kernel to be compatible
AlexB: i think 5.5 is good enough
PaulB: i think some people are saying 5.10 because it is an LTS kernel (?)
AlexB: time_t from 32 to 64 bits
JPEW: should be easy to test in qemu
AlexB: there are lots of places that need fixing, lots and lots just in
oe-core, nevermind meta-oe
RP: we can break the ABI in our builds
TrevorW: is this something we want to do in dunfell
RP: if there are easy fixes okay, but probably not in the context of dunfell.
i’m happy to see dunfell fixed, but a wholesale kernel upgrade might be
out of scope
AlexB: the 5.4 kernel is probably fine, the biggest issue is the glibc, and i
doubt it’ll get backported


TimO: python parsing
RP: there are some classes that are python nightmares. parsing in
bitbake context has a lot of overhead whereas parsing outside of
bitbake reduces the memory overhead. so there are pros and cons.
package.bbclass and patch.bbclass and a lot of the code in utils needs to
be moved/re-arranged. there might be compatibility issues, the question is
how to balance compatibility vs cleanup


Randy: we’ve seen issues where VMs with 46GB run out of memory. some people
say it’s an underlying issue with cmake or meson. but is this an
underlying issue, or is it something bitbake should handle?
RP: tricky question. it’s hard to tell how much load a job is going to
generate. shared job pool between make and bbthreads might be a viable way
to improve things. but there are limits to what bitbake can do. throttling
down the number of thread used by, for example, c++ builds or webkit are
useful. perhaps a global include file that puts limits
JPEW: it’d be nice to specify parallel make without having to specify the
“-j”, makes it clumsy to update in a script when you have to keep
parsing out the -j and then putting it back in again
RP: probably need a 2nd variable. parallel-make is really old, regressing
gracefully is the trick
Randy: handling things like ninja is hard
JPEW: ninja is meant to be simple
RossB: i think there’s a samurai update to ninja that has more options
JPEW: there is an open issue to add job server support to ninja
RP: which sounds like they don’t want to
ScottM: there was a patch suggested, which was rejected. we could add it
ourselves, but then we’d have to support it
RP: i wonder if samurai supports it
RossB: not quite, but there are bits and pieces, so maybe they’d take the
patch
RP: maybe check bugzilla, i’m sure i documented this somewhere


TimO: ptest output consistency. switching output formats might be too late,
there are already so many tools etc. would that be a true statement?
RP: we can *add* a new output format, just don’t throw away the old ones. it
would have to be opt-in but we don’t want a flag day

741 - 760 of 53861