Re: [yocto] TI AM62x based EV charger platform with Pionix UI s/w Image build problem. #apt #bitbake #distro #poky

[Federico Pellegrin]

Hi,
nodejs is very, *very*, heavy to build due to it's complex C++ code. I
would suggest you to limit the number of parallel builds supported: this
may slow down other (lighter) builds but will avoid going out of memory for
heavy ones such as node.

This can be done by putting in your local configuration
(build/conf/local.conf or replace "build" with your build directory)
directives like:

BB_NUMBER_THREADS = '4'
PARALLEL_MAKE = '-j 4'

(this limits to 4, you can play on this depending on number of cores and
amount of RAM of course)

hth,
Federico


Il giorno mar 28 nov 2023 alle ore 07:00  ha scritto:

> Hi team,
>
>
> we are trying to build TI AM62x EVSE SDK referring to
> https://github.com/PionixPublic/ti-am62x-evse-sdk  we have tried building
> in virtual machine and now we are trying to build in Linux  host pc with
> 500gb of storage and 16gb ram but still bitbake runs till 99 percentage
>   and last module Nodejs takes forever to run system experiences a freeze.
> Tried multiple times running the bitbake but still problem remains same .
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61765): https://lists.yoctoproject.org/g/yocto/message/61765
Mute This Topic: https://lists.yoctoproject.org/mt/102846254/21656
Mute #distro:https://lists.yoctoproject.org/g/yocto/mutehashtag/distro
Mute #poky:https://lists.yoctoproject.org/g/yocto/mutehashtag/poky
Mute #apt:https://lists.yoctoproject.org/g/yocto/mutehashtag/apt
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] install: cannot create directory: File exists

[Federico Pellegrin]

Hi,

Il giorno gio 16 nov 2023 alle ore 07:26 MOHAMMED HASSAN <
hassanchatta...@gmail.com> ha scritto:

> *| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/package-lock.json’:
> File exists*
>
>
>
>
> *| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/package.json’:
> File exists| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/udp.js’:
> File exists| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/watchdog.js’:
> File exists| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/wifi.js’:
> File exists| install: cannot create directory
> ‘/Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/Edge/wifi.js~’:
> File exists*
> | WARNING: exit code 1 from a shell command.install -d
> ${WORKDIR}/Edge/* ${D}${bindir}/Edge/*
> install -d ${D}${bindir}/Edge/node_modules
>


man install:

   -d, --directory
  treat all arguments as directory names; create all components
of
  the specified directories

So you are trying to install all normal files (Edge/*) as directories (as
you use -d). This then, as per error message message, will fail.

Maybe you meant -D (to create previous dirs)? Or just had it copied by
mistake.

Cheers,
Federico

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61707): https://lists.yoctoproject.org/g/yocto/message/61707
Mute This Topic: https://lists.yoctoproject.org/mt/102622725/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Recipe to install third-party RPM #bitbake

[Federico Pellegrin]

Hello David,
There is nothing really special compared to "usual" recipes or whatever you
use RPM or another packager.

In short:
1) You should create (likely in a layer of yours) the recipe for your
"third-party" package. You should put in this package the right
dependencies (using either DEPENDS or RDEPENDS, depending if it is build or
runtime dependency) and of course any other parts needed to build/install
it.
2) Of course should your new package depend on packages that are not
already in Yocto, you should create as well recipes for those. If they are
already in Yocto, you will just refer to them.
3) You should do (in your layer) an image recipe or extend the
core-image-base, adding your new recipe. You don't really need to add all
the dependencies there but just your final package, the dependencies will
be automatically (depending on the definitions in recipes) be pulled in.
4) the fact that is a RPM (or deb, or ipk) is just a detail, things will
work in image generation the same way. What will change is then of course
possibly how you manage those packages at runtime (ie. updates or the like).

I guess most of the things shortly mentioned above are then well documented
here:
https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles

Hope that helps,
Federico



Il giorno gio 8 dic 2022 alle ore 17:56  ha scritto:

> Hello,
> I need to deploy a third-party package as part of my Yocto image.  I am
> not sure how to build a recipe that will automate the installation of this
> RPM and dependencies.  If any of these dependent packages are not already
> included in the core-image-base image, I'll have to put together recipes
> for those as well and add them to the main recipe for the package (the RPM
> I want to install).  I have a basic idea of what needs to be done but am
> fuzzy on the detail.  I'll need to create a recipe that points to my RPM
> file via SRC_URI, but I am not sure what commands need to be included to
> make sure the RPM is seen as a package I can add via my local.conf.  The
> goal is to have the package installed in the final image such that the
> software is running as if the RPM was installed manually at the command
> prompt on the target board.   I've done a lot of googling, but the few
> posts I could find contain bits of information that aren't that useful to a
> Yocto newbie.  Note that I am using latest version of Kirkstone.
>
> Thanks!
>
> David
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58769): https://lists.yoctoproject.org/g/yocto/message/58769
Mute This Topic: https://lists.yoctoproject.org/mt/95542036/21656
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] open ssh dunfell unable to login

[Federico Pellegrin]

Hi Michael,
Sorry for the maybe obvious remark (and cannot find the original post if
maybe you gave more details) but: did you enable in openssh daemon
configuration to allow for root login?

By default that is not permitted, in /etc/ssh/sshd_config you have:

#PermitRootLogin prohibit-password

(it is usually commented, but shows the default)
Which you should in case replace with:

PermitRootLogin yes

This can be also managed on yocto level with the feature "debug-tweaks" or
"allow-root-login".

Cheers,
Federico


Il giorno gio 8 dic 2022 alle ore 15:21 Michael Nazzareno Trimarchi <
mich...@amarulasolutions.com> ha scritto:

> Hi
>
> On Mon, Nov 14, 2022 at 5:47 PM Michael Nazzareno Trimarchi
>  wrote:
> >
> > Hi all
> >
> > testing the openssh-server and I set root password but I'm enable to
> login
> >
> > server side
> > /usr/sbin/sshd -d -D
> >
>
> I basically solve it with dropbear instead of openssh. Has anybody
> found the same problem on dunfell?
>
> Michael
>
> > debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1q 5 Jul 2022
> > debug1: private host key #0: ssh-rsa
> > SHA256:1endrZLJnyyoE2x+MfLB3JIpEqgzCrORriOhvSSN2HM
> > debug1: private host key #1: ecdsa-sha2-nistp256
> > SHA256:1Ivo0c/GWF22iwwEAc0D+E79qSH/0eTxDH0pldsfuk4
> > debug1: private host key #2: ssh-ed25519
> > SHA256:CEHX4ATsgGL4De/rJlyNmwqqCk0Ewf1r4jU4spHTP88
> > debug1: rexec_argv[0]='/usr/sbin/sshd'
> > debug1: rexec_argv[1]='-d'
> > debug1: rexec_argv[2]='-D'
> > debug1: Set /proc/self/oom_score_adj from 0 to -1000
> > debug1: Bind to port 22 on 0.0.0.0.
> > Server listening on 0.0.0.0 port 22.
> > debug1: Bind to port 22 on ::.
> > Server listening on :: port 22.
> > debug1: Server will not fork when running in debugging mode.
> > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
> > debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1q 5 Jul 2022
> > debug1: private host key #0: ssh-rsa
> > SHA256:1endrZLJnyyoE2x+MfLB3JIpEqgzCrORriOhvSSN2HM
> > debug1: private host key #1: ecdsa-sha2-nistp256
> > SHA256:1Ivo0c/GWF22iwwEAc0D+E79qSH/0eTxDH0pldsfuk4
> > debug1: private host key #2: ssh-ed25519
> > SHA256:CEHX4ATsgGL4De/rJlyNmwqqCk0Ewf1r4jU4spHTP88
> > debug1: inetd sockets after dupping: 3, 3
> > Connection from 192.168.1.8 port 59662 on 192.168.1.3 port 22 rdomain ""
> > debug1: Local version string SSH-2.0-OpenSSH_8.2
> > debug1: Remote protocol version 2.0, remote software version
> > OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
> > debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 pat OpenSSH* compat
> 0x0400
> > debug1: permanently_set_uid: 997/997 [preauth]
> > debug1: list_hostkey_types:
> > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
> > [preauth]
> > debug1: SSH2_MSG_KEXINIT sent [preauth]
> > debug1: SSH2_MSG_KEXINIT received [preauth]
> > debug1: kex: algorithm: curve25519-sha256 [preauth]
> > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
> > debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC:
> >  compression: none [preauth]
> > debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC:
> >  compression: none [preauth]
> > debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
> > debug1: rekey out after 134217728 blocks [preauth]
> > debug1: SSH2_MSG_NEWKEYS sent [preauth]
> > debug1: Sending SSH2_MSG_EXT_INFO [preauth]
> > debug1: expecting SSH2_MSG_NEWKEYS [preauth]
> > debug1: SSH2_MSG_NEWKEYS received [preauth]
> > debug1: rekey in after 134217728 blocks [preauth]
> > debug1: KEX done [preauth]
> > debug1: userauth-request for user root service ssh-connection method
> > none [preauth]
> > debug1: attempt 0 failures 0 [preauth]
> > debug1: monitor_read_log: child log fd closed
> > debug1: do_cleanup
> > debug1: Killing privsep child 873
> >
> > Client side
> > ssh -vvv -o PreferredAuthentications=password root@192.168.1.3
> >
> > OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020
> > debug1: Reading configuration data /home/suniel/.ssh/config
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 19: include
> > /etc/ssh/ssh_config.d/*.conf matched no files
> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
> > debug2: resolve_canonicalize: hostname 192.168.1.3 is address
> > debug2: ssh_connect_direct
> > debug1: Connecting to 192.168.1.3 [192.168.1.3] port 22.
> > debug1: Connection established.
> > debug1: identity file /home/suniel/.ssh/id_rsa type 0
> > debug1: identity file /home/suniel/.ssh/id_rsa-cert type -1
> > debug1: identity file /home/suniel/.ssh/id_dsa type -1
> > debug1: identity file /home/suniel/.ssh/id_dsa-cert type -1
> > debug1: identity file /home/suniel/.ssh/id_ecdsa type -1
> > debug1: identity file /home/suniel/.ssh/id_ecdsa-cert type -1
> > debug1: identity file /home/suniel/.ssh/id_ecdsa_sk type -1
> > debug1: identity file /home/suniel/.ssh/id_ecdsa_sk-cert type -1
> > debug1: identity file /home/suniel/.ssh/id_ed25519 type -1
> > debug1: identity file 

Re: [yocto] source-less python

[Federico Pellegrin]

Hello Alex,

Il giorno dom 13 nov 2022 alle ore 16:12 Alexander Kanavin <
alex.kana...@gmail.com> ha scritto:

> Generally we slim down python installations by not installing all of
> the standard library, and rather having precise dependencies for
> specific modules. Can you illustrate the kind of space savings that
> can be gained in actual numbers?
>

Just to go with some concrete numbers from a Buildroot example I have under
my hands, with just very basic Python 3.10 support (so no additional
modules, just what gets in with only BR2_PACKAGE_PYTHON3=y) the difference
of size you have between using PYC only (BR2_PACKAGE_PYTHON3_PYC_ONLY=y)
and source only (BR2_PACKAGE_PYTHON3_PY_ONLY=y) of the generated
/usr/lib/python3.10 is 14Mb vs 17Mb. So roughly a 20% ?

Besides the space savings, using the PYC only brings also a speedup in
startup of course.

But strictly on space savings: one should also take into account that the
difference we see is not counting the fact that very often then one has a
compressed filesystem underneath. This is especially true when you have
space constrained embedded devices where you'd like to save space, but not
necessarily that -20% is effective, once you take into account the
filesystem compression.

(please note: not the original thread initiator asking to support this in
Yocto, just chimed in soon after as dealed with this in different context
;-) )


>
> Another issue is that this should be supported upstream and in the
> wider python community. Is it?
>

That is the problem IMO: if you look at the linked github issue I posted
last, I don't think there is a full agreement. So while things mostly work
(and pretty well), there are some edge cases for sure (ie trivially
handling pyc compiled scripts or modules that could be executed as scripts
as well as modules). (here is some discussion:
http://lists.busybox.net/pipermail/buildroot/2022-August/648686.html )

Cheers,
Federico





>
> Alex
>
> On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin 
> wrote:
> >
> >
> > Hello,
> > Just as a small reference since I raised some doubts and questions in
> Buildroot community on this: there has been also some troubles to
> understand the correctness or not there (as I found some packages with
> problems due to this source-less management) and this then sparked, besides
> discussions in the Buildroot mailing list (roughly end of July / beginning
> of August if someone interested searching there), also an issue to the
> Python community, which albeit some discussion I think never arrived to a
> concrete conclusion. This is the issue:
> https://github.com/python/cpython/issues/95827 (see also the linked one
> maybe)
> >
> > These are just my 2 cents to this discussion, then of course the Python
> experts will probably chime in and describe the official/discussed position
> of Yocto regarding to this, but just felt like mentioning that although
> Buildroot is somehow offering this right now (and likely mostly works as
> well!), it's not really a so clean and/or agreed solution.
> >
> > Cheers,
> > Federico
> >
> > Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <
> yishai1...@gmail.com> ha scritto:
> >>
> >> Hi,
> >> I was wondering if there has been talk about support for source-less
> python on an image. Installing py and pyc files doubles the size of python
> on the rootfs. I can imagine this being implemented as an image feature.
> >> I know that in buildroot it is supported.
> >> Was this discussed and decided against? Is this an open issue?
> >> I have a working patch that implements this. I can submit it for review.
> >>
> >> Thanks,
> >> Yishai Jaffe
> >> Yishai Jaffe
> >>
> >>
> >>
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58553): https://lists.yoctoproject.org/g/yocto/message/58553
Mute This Topic: https://lists.yoctoproject.org/mt/94997538/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] source-less python

[Federico Pellegrin]

Hello,
Just as a small reference since I raised some doubts and questions in
Buildroot community on this: there has been also some troubles to
understand the correctness or not there (as I found some packages with
problems due to this source-less management) and this then sparked, besides
discussions in the Buildroot mailing list (roughly end of July / beginning
of August if someone interested searching there), also an issue to the
Python community, which albeit some discussion I think never arrived to a
concrete conclusion. This is the issue:
https://github.com/python/cpython/issues/95827 (see also the linked one
maybe)

These are just my 2 cents to this discussion, then of course the Python
experts will probably chime in and describe the official/discussed position
of Yocto regarding to this, but just felt like mentioning that although
Buildroot is somehow offering this right now (and likely mostly works as
well!), it's not really a so clean and/or agreed solution.

Cheers,
Federico

Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe 
ha scritto:

> Hi,
> I was wondering if there has been talk about support for source-less
> python on an image. Installing py and pyc files doubles the size of python
> on the rootfs. I can imagine this being implemented as an image feature.
> I know that in buildroot it is supported.
> Was this discussed and decided against? Is this an open issue?
> I have a working patch that implements this. I can submit it for review.
>
> Thanks,
> Yishai Jaffe
> Yishai Jaffe
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58549): https://lists.yoctoproject.org/g/yocto/message/58549
Mute This Topic: https://lists.yoctoproject.org/mt/94997538/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Apply Rt-Patch in raspberry yocto image #patch #rpi #yocto #bitbake #dunfell #kernel

[Federico Pellegrin]

Hi,
After applying the patch to the source, I suppose you built the kernel (and
is just missing in your email) ? If not that is a quite important step
missing ;)

Besides that:
1) preempt-rt patch is often very kernel version specific, while I see your
two version don't exactly match: didn't it report any error? (would be
lucky, but possible)
2) You would need also to configure the kernel to enable then the
PREEMPT-RT and so on (this of course between applying the patch and
rebuilding the kernel)
3) And of course then install the new generated image instead of the old
one in a fashion of your choice

Cheers,
Federico

Il giorno ven 14 ott 2022 alle ore 07:41 Nikita Gupta <
nikitagupta2...@gmail.com> ha scritto:

> Hello All
>
> I want to apply similar kernel version rt-patch in my rpi-basic-image for
> my raspberrypi4-64 machine. So, I tried to apply rt-patch for a standard
> rasbian image (5.15.61-v8+) but not got success. i did the following things.
>
>   1. I downloaded required kernel sources from the kernel building
> instructions (Raspberry Pi Documentation - The Linux kernel)
> 
>   2. I downloaded
> https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.15/older/patch-5.15.65-rt49.patch.gz
> 
>cd linux
>   3. zcat patch-5.15.65-rt49.patch.gz | patch -p1
>But after rebooting my pi i am not able to see the patched kernel.
> I was about to do the same process with my rpi-basic-image. Can anyone tell
> me what things I am doing wrong?
> Or please tell me the standard way of rt-patching the kernel through yocto
> .
>
> Any reply would be highly appreicated. Thanks in Advance.
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58336): https://lists.yoctoproject.org/g/yocto/message/58336
Mute This Topic: https://lists.yoctoproject.org/mt/94321336/21656
Mute #patch:https://lists.yoctoproject.org/g/yocto/mutehashtag/patch
Mute #rpi:https://lists.yoctoproject.org/g/yocto/mutehashtag/rpi
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [OE-core] gpg signing and stale gpg-agent

[Federico Pellegrin]

Hi all,
I've been working with signing packages via gpg (specificall RPM, but that
shouldn't really matter) lately and things mostly work fine (modulo that
small patch from some 2 weeks ago now in master).

I have just one more possibly minor issue I wanted to get possibly an
opinion from the expert folk if possible!


Little background: to keep things isolated and not system dependant the GPG
related files are kept in a separate directory. This is then specified via
GPG_PATH (which then de facto is passed to various gpg tools as --homedir).
The keys are then kept there and just as a detail that is then an encrypted
FS which is just mounted/umounted when needed.

When gpg is run it will spawn a gpg-agent to deal with keys and this is
fine. The problem I have is that after bitbake finished the gpg-agent will
still be left running there and in my specific case this means that the
directory (pointed by GPG_PATH) will figure as in use and therefore cannot
be umounted. Of course if I kill by hand the gpg-agent then I can just
proceed and so on.

So the first question is: is it 'nice' that after the bitbake execution we
possibly leave as a matter of fact running stuff from Yocto around the
system?


As I wanted to come to pose a question also having done a bit of homework I
tried to understand how I could fix this and right now I arrived at
something like:

-

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index aa9bb49f2c..d6d1fd9e6c 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -58,6 +58,12 @@ class LocalSigner(object):
 for i in range(0, len(files), sign_chunk):
 subprocess.check_output(shlex.split(cmd + '
'.join(files[i:i+sign_chunk])), stderr=subprocess.STDOUT)

+gpg_conf_bin = bb.utils.which(os.getenv('PATH'), "gpgconf")
+if gpg_conf_bin and self.gpg_path:
+cmd = [ gpg_conf_bin ] + ["--homedir", self.gpg_path,
"--kill", "gpg-agent"]
+subprocess.check_output(cmd, stderr=subprocess.STDOUT)
+
+
 def detach_sign(self, input_file, keyid, passphrase_file,
passphrase=None, armor=True, output_suffix=None, use_sha256=False):
 """Create a detached signature of a file"""

-

(note: I kill only if the homedir is defined, this is TBD, it's just a PoC)
So basically after the loop that does all the chunk-wise signing I ask
gpgconf to stop the gpgagent and this actually seem to work pretty fine.
But I'm not convinced this is the best as maybe it is stopped and restarted
more than needed (TBC).

My desire was to make sure to do it just once, for example hooking on an
"atexit" but that seemed to be called a bit randomly and not always (which
is a bit puzzling for me, but maybe clear for the experts, as I saw atexit
is also used in a couple of other places as cleanup).

So in short:
1) Do you think we should implement a clean-up of the gpg-agent or should
we just live with it?
2) If yes should we do it always or just under some conditions? (ie.
GPG_PATH is passed, not if using the user's default one?)
3) What would be the best way to get some cleanup code reliably called and
just once? (if not the PoC above)

Many thanks in advance,
Federico

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57428): https://lists.yoctoproject.org/g/yocto/message/57428
Mute This Topic: https://lists.yoctoproject.org/mt/92083583/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [poky][PATCH] signing-keys: add RDEPENDS to signing-keys from specific provider

[Federico Pellegrin]

Specific provider (ie. RPM or IPK) does "provide" just itself as a
package to the system. This will cause the "-dev" package, which
refers to the generic signing-keys and not the provider specific,
to miss the dependency.

Error case (RPM) when populating sdk:

Error:
 Problem: conflicting requests
  - nothing provides signing-keys = 1.0-r0 needed by 
signing-keys-dev-1.0-r0.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Examining signing-keys-rpm packages in PROVIDES we have indeed:
signing-keys-rpm = 1.0-r0

But in signing-keys-dev: in REQUIRES:
signing-keys-1.0-r0

This MR will fix the situation bringing the specific provider
PROVIDES to include also the generic package (RPM example):
signing-keys
signing-keys-rpm = 1.0-r0

Likely another way could be also to change the requirement for
dev or just allow empty packages as well.

Signed-off-by: Federico Pellegrin 
---
 meta/recipes-core/meta/signing-keys.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/meta/signing-keys.bb 
b/meta/recipes-core/meta/signing-keys.bb
index 03463f95f56..d0602cf82af 100644
--- a/meta/recipes-core/meta/signing-keys.bb
+++ b/meta/recipes-core/meta/signing-keys.bb
@@ -18,6 +18,10 @@ FILES:${PN}-rpm = "${sysconfdir}/pki/rpm-gpg"
 FILES:${PN}-ipk = "${sysconfdir}/pki/ipk-gpg"
 FILES:${PN}-packagefeed = "${sysconfdir}/pki/packagefeed-gpg"
 
+RPROVIDES:${PN}-rpm += "${PN}"
+RPROVIDES:${PN}-ipk += "${PN}"
+RPROVIDES:${PN}-packagefeed += "${PN}"
+
 python do_get_public_keys () {
 from oe.gpg_sign import get_signer
 
-- 
2.35.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57342): https://lists.yoctoproject.org/g/yocto/message/57342
Mute This Topic: https://lists.yoctoproject.org/mt/91836405/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH] Remove outdated meta-rust dependency text in README

[Federico Pellegrin]

Hi Armin,
Sorry if it was unclear or if I misunderstood something.

As far as I could see and tried as I had to build it yesterday, I can now
build suricata without adding meta-rust as the rust support (compilers etc)
is now already in oe-core, ie:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/rust
and
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/cargo
Some relevant discussion: https://github.com/meta-rust/meta-rust/pull/364

The note in README may still just apply to versions < honister I believe
(ie. dunfell is the only not EOL-ed). For more recent versions it may just
potentially create confusion IMO.

Cheers,
Federico

Il giorno dom 5 giu 2022 alle ore 00:58 akuster808 
ha scritto:

>
>
> On 6/3/22 23:31, Federico Pellegrin wrote:
> > Since ~16 months the base of meta-rust was merged into meta-oe,
> > down to honister as far as I can see, and therefore the indications
> > to use meta-rust are really not needed and may just create extra
> > work and possibly problems to users.
> > ---
> >   README | 12 
> >   1 file changed, 12 deletions(-)
> >
> > diff --git a/README b/README
> > index 081669f..a9b3600 100644
> > --- a/README
> > +++ b/README
> > @@ -62,18 +62,6 @@ other layers needed. e.g.:
> >   /path/to/meta-openembedded/meta-networking \
> >   /path/to/layer/meta-security "
>
> thanks for the patch.
>
> did I miss some rust changes in
>
> https://git.yoctoproject.org/meta-security/commit/?h=master-next=edf8b109e77f6d3f2740e09bdc89f0aaf2885dc4
> ?
>
> - armin
> >
> > -Optional Rust dependancy
> > -==
> > -If you want to use the latest Suricata that needs rust, you will need
> to clone
> > -
> > -  URI: https://github.com/meta-rust/meta-rust.git
> > -  branch: master
> > -
> > -  BBLAYERS += "/path/to/layer/meta-rust"
> > -
> > -This will activate the dynamic-layer mechanism and pull in the newer
> suricata
> > -
> > -
> >
> >   Maintenance
> >   ==
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57268): https://lists.yoctoproject.org/g/yocto/message/57268
Mute This Topic: https://lists.yoctoproject.org/mt/91536693/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH] Remove outdated meta-rust dependency text in README

[Federico Pellegrin]

Since ~16 months the base of meta-rust was merged into meta-oe,
down to honister as far as I can see, and therefore the indications
to use meta-rust are really not needed and may just create extra
work and possibly problems to users.
---
 README | 12 
 1 file changed, 12 deletions(-)

diff --git a/README b/README
index 081669f..a9b3600 100644
--- a/README
+++ b/README
@@ -62,18 +62,6 @@ other layers needed. e.g.:
 /path/to/meta-openembedded/meta-networking \
 /path/to/layer/meta-security "
 
-Optional Rust dependancy
-==
-If you want to use the latest Suricata that needs rust, you will need to clone
-
-  URI: https://github.com/meta-rust/meta-rust.git
-  branch: master
-
-  BBLAYERS += "/path/to/layer/meta-rust"
-
-This will activate the dynamic-layer mechanism and pull in the newer suricata
-
-
 
 Maintenance
 ==
-- 
2.34.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57258): https://lists.yoctoproject.org/g/yocto/message/57258
Mute This Topic: https://lists.yoctoproject.org/mt/91536693/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Fedora 36 / uninative GLIBCXX 3.4.30

[Federico Pellegrin]

Hello,
Thanks for the feedback!

Indeed the check is only on the "ldd --version" output which doesn't
account for the libstdc++ and that explains it. As compared to Ubuntu
22.04, Fedora 36 actually has also GCC 12.0.1 as default compiler.

As Martin mentions not sure if there is an easy portable way. He mentions
objdump which is for sure effective but maybe complicated and I feel like
relies on the filename being guessed (well should be known, the main link
at least) and feels a bit overcomplicated (if we need to go that low level
in case I'd suggest just to just use "strings" and grep there instead).

Would relying just on the filename be too shaky? I can see here
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html in point 3 of
"History" that it would seem quite well defined. Actually I guess if we
would just compare the system libstdc++.so.X.Y.Z (which we may be easily
able to get it from the libstdc++.so link) to uninative one  maybe would be
enough to determine it is newer? Hardcoding the path to libstdc++.so (as
ie. /usr/lib64/libstdc++.so) is probably not nice (ie. for custom
toolchains), so maybe we can ask g++ (-print-search-dirs, libraries
section) and look in those?
Then not sure if there are some distros/installs that do the insane-isy
thing of just installing directly the .so stripping the versions from the
name, hopefully not.

I'm not sure using anything from g++ -dumpspecs would be viable if as
Martin mentions you may have (ie. ubuntu-2204) a version with new stdc++
but older g++.

Cheers,
Federico


Il giorno dom 3 apr 2022 alle ore 16:52 Martin Jansa 
ha scritto:

> FWIW: the same is happening now with ubuntu-22.04 where libstdc++6 package
> is now built from gcc-12 sources (even when gcc itself still defaults to
> gcc-11).
>
> I was trying to add the check in uninative.bbclass, but haven't found easy
> portable way to detect the version from libstdc++.so.6 (other than parsing
> objdump -x /full/path/to/libstdc++.so.6 output).
>
> On Sun, Apr 3, 2022 at 12:44 PM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> On Sun, 2022-04-03 at 09:12 +0200, Federico Pellegrin wrote:
>> > I've been playing around building a Yocto imagine based on
>> kirkstone/master on
>> > the just released Fedora 36 beta test image. (just to give a few bits
>> more
>> > details: builds a MX8X image, works perfectly fine with Fedora 34 and
>> 35 since
>> > quite some time)
>> >
>> > The first and most obvious thing I've found out is that it is based on
>> a newer
>> > version of glibcxx (3.4.30) when the very latest uninative available
>> (as far
>> > as I could see, apologies if I'm wrong) is on 3.4.29, so at some point
>> this
>> > will break the build (when pzstd is called).
>> >
>> > Of course for the time being I just disabled uninative and the build is
>> going
>> > on (will report of course should I find something else). I'm not sure
>> (still
>> > checking this) if that should have happened automatically, but there was
>> > actually no warning in that sense (maybe because is GLIBCXX and not
>> GLIBC
>> > itself?)
>> > But the question is: should I try to contribute that tarball (I will
>> search
>> > for details, but if there is any good reference more than welcome!) or
>> is it
>> > something that is likely done by the core team?
>> >
>> > Of course FC36 is still a test distro so there is no surprise it broke,
>> but as
>> > we are close to Kirkstone release and possibly other distros will get
>> the same
>> > upgrade, I guess it could be great if we may fix this before that
>> deadline.
>>
>> Thanks for reporting it. I think to generate the newer version we need
>> gcc 12
>> which is still in pre-release. We generate the uninative tarball using
>> our own
>> builds on the autobuilder so until we have gcc 12 recipes there, we can't
>> generate that.
>>
>> Once gcc 12 is out, we will release a new uninative (assuming we can
>> update our
>> recipes).
>>
>> I'd like to think the checks in uninative would have noticed the
>> mismatch, we do
>> have some code there to detect libc version but perhaps not the CXX
>> pieces so
>> I'd welcome help in adding something for that.
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56653): https://lists.yoctoproject.org/g/yocto/message/56653
Mute This Topic: https://lists.yoctoproject.org/mt/90215476/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Fedora 36 / uninative GLIBCXX 3.4.30

[Federico Pellegrin]

Hello,
I've been playing around building a Yocto imagine based on kirkstone/master
on the just released Fedora 36 beta test image. (just to give a few bits
more details: builds a MX8X image, works perfectly fine with Fedora 34 and
35 since quite some time)

The first and most obvious thing I've found out is that it is based on a
newer version of glibcxx (3.4.30) when the very latest uninative available
(as far as I could see, apologies if I'm wrong) is on 3.4.29, so at some
point this will break the build (when pzstd is called).

Of course for the time being I just disabled uninative and the build is
going on (will report of course should I find something else). I'm not sure
(still checking this) if that should have happened automatically, but there
was actually no warning in that sense (maybe because is GLIBCXX and not
GLIBC itself?)
But the question is: should I try to contribute that tarball (I will search
for details, but if there is any good reference more than welcome!) or is
it something that is likely done by the core team?

Of course FC36 is still a test distro so there is no surprise it broke, but
as we are close to Kirkstone release and possibly other distros will get
the same upgrade, I guess it could be great if we may fix this before that
deadline.

Many thanks!
Federico

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56647): https://lists.yoctoproject.org/g/yocto/message/56647
Mute This Topic: https://lists.yoctoproject.org/mt/90215476/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Federico Pellegrin]

Hi Jupiter,
I cannot help you on the specific chip you ask, but responding to the
second part of your question I have quite good experience with Microchip
WILC1000/3000 on SDIO which, after a part separate repo and then staging,
is now in mailine from quite some time:
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/microchip/wilc1000
I had also some mixed experience (seemed to be arch releated) otherwise
also with SDIO/SPI of SiLabs which is currently in mainline staging:
https://github.com/torvalds/linux/tree/master/drivers/staging/wfx
These chips are at least currently still on the market (modulo shortage
problems), not sure about their projected lifespan (I guess something hard
to foresee).

Cheers,
Federico


Il giorno mar 29 mar 2022 alle ore 08:16 JH  ha
scritto:

> Hi,
>
> I could not understand why so many large WiFi chip vendors retreat to
> stop maintaining WiFi SDIO chips to mainline Linux kernel, and to
> settle it's chip support to out of the tree, use its own SDK and
> proprietary kernel tree to source.codeaurora.org or private repository
> which are not compatible to mainline stable kernel, the kernel
> configures are also different.
>
> I looked at the following link, the mwifiex and mwifiex_sdio support
> the Marvell (NXP) 88W88 chipset, but only kernel 4.19 was able to
> build and to run, kernel 5 cannot support 88W88 chipset, any more.
> Same to Qualcomm, the old Atheros WiFi modules are supported, the
> QCA-9377-3 chipset is in source.codeaurora.org only supported by old
> kernel 4.9.
>
> Given the OE/Yocto poky kernel build is based on a mainline stable
> kernel repository, how can I build kernel 5 for 88W88 chipset or
> QCA-9377-3 from source.codeaurora.org or private repository? Or which
> WiFi vendors are still well maintaining the WiFi chips for kernel 5,
> the only sensible solution is to switch WiFi SDIO chips? Appreciate
> your advice and comments.
>
> https://wireless.wiki.kernel.org/en/users/drivers
>
> Thank you very much.
>
> Kind regards,
>
> jupiter
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56575): https://lists.yoctoproject.org/g/yocto/message/56575
Mute This Topic: https://lists.yoctoproject.org/mt/90103003/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] The "/etc/resolv.conf" file becomes empty after each restart #yocto

[Federico Pellegrin]

Hello,
Some more details would be needed (ie. you have systemd?), but this could
be a good point to start: https://wiki.archlinux.org/title/Systemd-resolved

(ie. see a bit down, like:
https://wiki.archlinux.org/title/Systemd-resolved#Manually )

Cheers,
Federico

Il giorno gio 13 gen 2022 alle ore 09:17 sateesh m 
ha scritto:

> Hi,
>
>I assume it shouldn't be empty resov. conf. Manually I am updating
> nameserver always. but when I reboot my machine it's empty. So for this, I
> want to make permanent my nameserver always. I have added packages support
> IMAGE_INSTALL_append = " resolvconf"  but I am not able to fix this
> solution. Can anybody know this issue please guide me. How always will be
> automatically set without manual effort?
>
>
> --
> Regards,
> Sateesh
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55833): https://lists.yoctoproject.org/g/yocto/message/55833
Mute This Topic: https://lists.yoctoproject.org/mt/88392943/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] util-linux and --enable-raw with recent kernels

[Federico Pellegrin]

Thanks Khem!
Indeed I checked on master but got cheated by the web git interface and I
was looking at an older commit :-/
Glad it is the right way to go and already solved on master!

Cheers,
Federico

Il giorno mar 12 ott 2021 alle ore 18:55 Khem Raj  ha
scritto:

>
>
> On 10/12/21 9:27 AM, Federico Pellegrin wrote:
> >
> > Hello,
> > Running on a quite recent kernel (5.14.10 from Fedora 34) I've came
> > across a problem when building util-linux (2.35.2) native, namely in the
> > configure phase:
> >
> > configure: error: raw selected, but required raw.h header file not
> available
> >
>
> you might want to use latest master, fix that you might find useful is
>
>
> https://git.openembedded.org/openembedded-core/commit/?id=7f577c10913104860121f682b9b3754870c4db23
>
> > After a bit or research I believe it is due to:
> >
> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1820154.html
> > <
> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1820154.html
> >
> >
> > Which is related to the change in the recent kernels here:
> >
> https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093#diff-10d697dff14540ee1eb6539dcc53b2b88844b6187c1995c0698ba0936754304a
> > <
> https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093#diff-10d697dff14540ee1eb6539dcc53b2b88844b6187c1995c0698ba0936754304a
> >
> > where the raw.h file was indeed removed.
> >
> > As per first link it may not be obvious to fix, and don't see an
> > upstream fix for it, but from the Yocto perspective my current
> > workaround is basically just to remove "--enable-raw" from the
> > EXTRA_OECONF to disable the raw feature.
> >
> > While the whole image seemed to build fine with this, I'm not very sure
> > if that configuration option had a precise use (which maybe it's being
> > skipping in my specific build) or not, so I wanted to ask the experts if
> > there is any opinion on this and/or should I do a merge request that
> > removes it to handle this problem, at least until there is a better
> > solution upstream in util-linux?
> >
> > Many thanks,
> > Federico
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55045): https://lists.yoctoproject.org/g/yocto/message/55045
Mute This Topic: https://lists.yoctoproject.org/mt/86266370/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] util-linux and --enable-raw with recent kernels

[Federico Pellegrin]

Hello,
Running on a quite recent kernel (5.14.10 from Fedora 34) I've came across
a problem when building util-linux (2.35.2) native, namely in the configure
phase:

configure: error: raw selected, but required raw.h header file not available

After a bit or research I believe it is due to:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1820154.html

Which is related to the change in the recent kernels here:
https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093#diff-10d697dff14540ee1eb6539dcc53b2b88844b6187c1995c0698ba0936754304a
where the raw.h file was indeed removed.

As per first link it may not be obvious to fix, and don't see an upstream
fix for it, but from the Yocto perspective my current workaround is
basically just to remove "--enable-raw" from the EXTRA_OECONF to disable
the raw feature.

While the whole image seemed to build fine with this, I'm not very sure if
that configuration option had a precise use (which maybe it's being
skipping in my specific build) or not, so I wanted to ask the experts if
there is any opinion on this and/or should I do a merge request that
removes it to handle this problem, at least until there is a better
solution upstream in util-linux?

Many thanks,
Federico

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55041): https://lists.yoctoproject.org/g/yocto/message/55041
Mute This Topic: https://lists.yoctoproject.org/mt/86266370/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [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  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  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
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55025): https://lists.yoctoproject.org/g/yocto/message/55025
Mute This Topic: https://lists.yoctoproject.org/mt/86230049/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [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  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
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55013): https://lists.yoctoproject.org/g/yocto/message/55013
Mute This Topic: https://lists.yoctoproject.org/mt/86230049/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] googletest shared library

[Federico Pellegrin]

nternal/custom/gmock-matchers.h
>   /usr/local/include/gmock/internal/custom/gmock-generated-actions.h
>   /usr/local/include/gmock/internal/custom/README.md
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> googletest: 69 installed and not shipped files. [installed-vs-shipped]
> ERROR: googletest-1.10.0-r0 do_package: Fatal QA errors found, failing
> task.
>
>
> --
> *From:* Federico Pellegrin 
> *Sent:* Thursday, September 23, 2021 10:27:39 AM
> *To:* Lijun Chen
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] googletest shared library
>
>
> Hi,
> To skip the QA you can use:
>
> INSANE_SKIP_${PN} += "dev-elf"
>
> (or any QA part you'd like to skip, ie. dev-elf or dev-so ...)
>
> Cheers,
> Federico
>
>
>
> Il giorno gio 23 set 2021 alle ore 15:33 Lijun Chen <
> lijc...@blackberry.com> ha scritto:
>
>> Hi,
>>
>>
>> If I switch to the default setting of the googletest recipe, the header
>> files are included in the SDK image. However, the libgtest libraries are
>> static.
>>
>> Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the
>> SDK.
>>
>>
>> Is there a way to change the library to dynamic and keep the header
>> files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip
>> the do_package_qa part to avoid the QA issue due to un-versioned library?
>>
>>
>> Thanks,
>>
>> Lijun
>>
>>
>> --
>> *From:* yocto@lists.yoctoproject.org  on
>> behalf of Lijun Chen 
>> *Sent:* Wednesday, September 22, 2021 1:45 PM
>> *To:* Khem Raj; yocto@lists.yoctoproject.org
>> *Subject:* Re: [yocto] googletest shared library
>>
>>
>> Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are
>> still not showing up.
>>
>> Thanks,
>> --
>> *From:* Khem Raj 
>> *Sent:* Wednesday, September 22, 2021 11:28:05 AM
>> *To:* Lijun Chen; yocto@lists.yoctoproject.org
>> *Subject:* Re: [yocto] googletest shared library
>>
>> The .h files will be in dev pkg in this case googletest-dev
>> what happens if you add googletest to TOOLCHAIN_TARGET_TASK
>>
>> On 9/22/21 6:18 AM, Lijun Chen wrote:
>> > Hi,
>> >
>> >
>> > Now I included googletest to the IMAGE_INSTALL in my image file, and
>> > built both board image and SDK image. I can see libgtest.so is
>> available
>> > in both images. However, gtest/gtest.h is a not present in SDK. How do
>> I
>> > add the header files to the SDK image? Looks the following lines affect
>> > that?
>> >
>> > SOLIBS = ".so"
>> > FILES_SOLIBSDEV = ""
>> >
>> > Thanks,
>> > Lijun
>> >
>> > 
>> > *From:* yocto@lists.yoctoproject.org  on
>> > behalf of Lijun Chen 
>> > *Sent:* Tuesday, September 21, 2021 3:50 PM
>> > *To:* Konrad Weihmann; yocto@lists.yoctoproject.org
>> > *Subject:* Re: [yocto] googletest shared library
>> >
>> > Thanks Konrad. That worked.
>> >
>> > 
>> > *From:* Konrad Weihmann 
>> > *Sent:* Tuesday, September 21, 2021 10:26:19 AM
>> > *To:* Lijun Chen; yocto@lists.yoctoproject.org
>> > *Subject:* Re: [yocto] googletest shared library
>> >
>> > On 21.09.21 16:18, Lijun Chen wrote:
>> >> Hi,
>> >>
>> >> I would like to include libgtest.so into my Yocto image. I added
>> >> googletest to IMAGE_INSTALL and added the following line to
>> >> sources/meta-openembedded/meta-oe/recipes-test/googletest/
>> googletest_git.bb
>> <https://urldefense.com/v3/__http://googletest_git.bb__;!!COg3wY07Hnb7!7O_HT4lxGD2NMUNxv3WxuozghHtiiLg6jEedfRQlWFKmZAkTPU49ug2kIHlR9kH4xg$>
>> :
>> >>
>> >> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
>> >>
>> >>
>> >> The shared libraries were built successfully. However, there are
>> errors
>> >> in do_package_qc as following:
>> >>
>> >>
>> >> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
>> >> googletest-dev contains n

Re: [yocto] googletest shared library

[Federico Pellegrin]

Hi,
To skip the QA you can use:

INSANE_SKIP_${PN} += "dev-elf"

(or any QA part you'd like to skip, ie. dev-elf or dev-so ...)

Cheers,
Federico



Il giorno gio 23 set 2021 alle ore 15:33 Lijun Chen 
ha scritto:

> Hi,
>
>
> If I switch to the default setting of the googletest recipe, the header
> files are included in the SDK image. However, the libgtest libraries are
> static.
>
> Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the
> SDK.
>
>
> Is there a way to change the library to dynamic and keep the header files?
> i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the
> do_package_qa part to avoid the QA issue due to un-versioned library?
>
>
> Thanks,
>
> Lijun
>
>
> --
> *From:* yocto@lists.yoctoproject.org  on
> behalf of Lijun Chen 
> *Sent:* Wednesday, September 22, 2021 1:45 PM
> *To:* Khem Raj; yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] googletest shared library
>
>
> Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are
> still not showing up.
>
> Thanks,
> --
> *From:* Khem Raj 
> *Sent:* Wednesday, September 22, 2021 11:28:05 AM
> *To:* Lijun Chen; yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] googletest shared library
>
> The .h files will be in dev pkg in this case googletest-dev
> what happens if you add googletest to TOOLCHAIN_TARGET_TASK
>
> On 9/22/21 6:18 AM, Lijun Chen wrote:
> > Hi,
> >
> >
> > Now I included googletest to the IMAGE_INSTALL in my image file, and
> > built both board image and SDK image. I can see libgtest.so is available
> > in both images. However, gtest/gtest.h is a not present in SDK. How do I
> > add the header files to the SDK image? Looks the following lines affect
> > that?
> >
> > SOLIBS = ".so"
> > FILES_SOLIBSDEV = ""
> >
> > Thanks,
> > Lijun
> >
> > 
> > *From:* yocto@lists.yoctoproject.org  on
> > behalf of Lijun Chen 
> > *Sent:* Tuesday, September 21, 2021 3:50 PM
> > *To:* Konrad Weihmann; yocto@lists.yoctoproject.org
> > *Subject:* Re: [yocto] googletest shared library
> >
> > Thanks Konrad. That worked.
> >
> > 
> > *From:* Konrad Weihmann 
> > *Sent:* Tuesday, September 21, 2021 10:26:19 AM
> > *To:* Lijun Chen; yocto@lists.yoctoproject.org
> > *Subject:* Re: [yocto] googletest shared library
> >
> > On 21.09.21 16:18, Lijun Chen wrote:
> >> Hi,
> >>
> >> I would like to include libgtest.so into my Yocto image. I added
> >> googletest to IMAGE_INSTALL and added the following line to
> >> sources/meta-openembedded/meta-oe/recipes-test/googletest/
> googletest_git.bb:
> >>
> >> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
> >>
> >>
> >> The shared libraries were built successfully. However, there are errors
> >> in do_package_qc as following:
> >>
> >>
> >> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
> >> googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
> >> -dev package googletest-dev contains non-symlink .so
> >> '/usr/lib/libgtest_main.so'
> >> -dev package googletest-dev contains non-symlink .so
> >> '/usr/lib/libgmock_main.so'
> >> -dev package googletest-dev contains non-symlink .so
> >> '/usr/lib/libgtest.so' [dev-elf]
> >> ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
> >> Please consider fixing them.
> >
> >
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
> > <
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>
>
> >
> > (and the next lines) might give you a hint what to do in this case.
> > Although one could also consider that's something that needs to be fixed
> > in the installation script of googletest, as versioned libraries are the
> > expected default
> >
> >>
> >>
> >> Any idea to fix this?
> >>
> >>
> >> Thanks,
> >>
> >> Lijun
> >>
> >>
> >> 
> >> This transmission (including any attachments) may contain confidential
> >> information, privileged material (including material protected by the
> >> solicitor-client or other applicable privileges), or constitute
> >> non-public information. Any use of this information by anyone other
> than
> >> the intended recipient is prohibited. If you have received this
> >> transmission in error, please immediately reply to the sender and
> delete
> >> this information from your system. Use, dissemination, distribution, or
> >> reproduction of this transmission by unintended recipients is not
> >> authorized and may be unlawful.
> >>
> >>
> >>
> >>
> > 

[yocto] [meta-security][PATCH] aircrack-ng: update to 1.6

[Federico Pellegrin]

Signed-off-by: Federico Pellegrin 
---
 .../{aircrack-ng_1.3.bb => aircrack-ng_1.6.bb}| 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
 rename recipes-security/aircrack-ng/{aircrack-ng_1.3.bb => aircrack-ng_1.6.bb} 
(82%)

diff --git a/recipes-security/aircrack-ng/aircrack-ng_1.3.bb 
b/recipes-security/aircrack-ng/aircrack-ng_1.6.bb
similarity index 82%
rename from recipes-security/aircrack-ng/aircrack-ng_1.3.bb
rename to recipes-security/aircrack-ng/aircrack-ng_1.6.bb
index d739227..8d3b531 100644
--- a/recipes-security/aircrack-ng/aircrack-ng_1.3.bb
+++ b/recipes-security/aircrack-ng/aircrack-ng_1.6.bb
@@ -9,8 +9,8 @@ DEPENDS = "libnl openssl sqlite3 libpcre libpcap"
 
 SRC_URI = "http://download.aircrack-ng.org/${BP}.tar.gz;
 
-SRC_URI[md5sum] = "c7c5b076dee0c25ee580b0f56f455623"
-SRC_URI[sha256sum] = 
"8ae08a7c28741f6ace2769267112053366550e7f746477081188ad38410383ca"
+SRC_URI[md5sum] = "22ddc85549b51ed0da0931d01ef215e5"
+SRC_URI[sha256sum] = 
"4f0bfd486efc6ea7229f7fbc54340ff8b2094a0d73e9f617e0a39f878999a247"
 
 inherit autotools-brokensep pkgconfig
 
@@ -29,6 +29,8 @@ do_install () {
 make DESTDIR=${D} ${OEMAKE_EXTRA} ext_scripts=true install
 }
 
-FILES_${PN} += "/usr/local/"
+FILES_${PN} += "${libdir}/*.so"
+FILES_SOLIBSDEV = ""
+INSANE_SKIP_${PN} += "dev-so"
 
 RDEPENDS_${PN} = "libpcap"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53883): https://lists.yoctoproject.org/g/yocto/message/53883
Mute This Topic: https://lists.yoctoproject.org/mt/83573954/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto][meta-gplv2][PATCH] gnutls: add possibility to build with cryptodev support

[Federico Pellegrin]

Add possibility, via PACKAGECONFIG variable, to enable cryptodev
(hardware crypto acceleration) for gnutls in a very similar way
as it is already present for openssl.

Signed-off-by: Federico Pellegrin 
---
 meta/recipes-support/gnutls/gnutls_3.7.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/gnutls/gnutls_3.7.1.bb 
b/meta/recipes-support/gnutls/gnutls_3.7.1.bb
index 350d0a018bd..6674542a77d 100644
--- a/meta/recipes-support/gnutls/gnutls_3.7.1.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.7.1.bb
@@ -36,6 +36,7 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
 PACKAGECONFIG[libtasn1] = 
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
 PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
 PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
+PACKAGECONFIG[cryptodev-linux] = 
"--enable-cryptodev,,cryptodev-linux,cryptodev-module"
 
 EXTRA_OECONF = " \
 --enable-doc \
-- 
2.26.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53336): https://lists.yoctoproject.org/g/yocto/message/53336
Mute This Topic: https://lists.yoctoproject.org/mt/82477731/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] U-Boot sama5d3 xplained issue

[Federico Pellegrin]

Hi David,
If you change it directly, changes may not be taken into account for the
rebuild. And if the package build gets retriggered, then the whole
repository is deleted (including your local changes), redownloaded,
repatched and so on. So while it may by chance work by modifying locally in
certain conditions, it will most likely not.

I would see two ways:
1) Create a patch that does your changes and add it to the recipe (most
likely now in a custom layer) as a patch
2) Fork the repository, add all your customizations there, and point the
recipe (again most likely now in a custom layer) to that one.

Cheers,
F.



Il giorno ven 27 nov 2020 alle ore 01:35 David Novak 
ha scritto:

> We changed the file directly.
>
> Since it's a custom file, I don't think it is being downloaded. What is
> the easiest way to determine if it's being downloaded?
>
> Thanks,
> David
>
>
>
> On 11/23/2020 2:16 AM, Federico Pellegrin wrote:
>
>
> Hi,
> I think it would be interesting information to know "how" you change the
> value inside "u-boot-at91/sama5d3_xplained_nandflash_config".
>
> As every time you rebuild it may be redownloaded, you should do this via a
> patch to append to the recipe.
>
> Are you doing this? Or just changing it locally?
>
> If you give some more info probably we can better help!
>
> Cheers,
> Federico
>
> Il giorno lun 23 nov 2020 alle ore 08:06 Khem Raj  ha
> scritto:
>
>> perhaps asking it on https://github.com/linux4sam/u-boot-at91 via
>> github issues might be helpful too.
>>
>> On Sat, Nov 21, 2020 at 4:26 AM David Novak 
>> wrote:
>> >
>> > I'm working on this project with Pratham. Let me provide a few more
>> details.
>> >
>> > We've defined
>> >
>> > UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"
>> >
>> > Inside
>> >
>> > u-boot-at91/sama5d3_xplained_nandflash_config
>> >
>> > we change CONFIG_BOOTDELAY, but it has no effect on the newly built
>> image. The boot delay remains the same as it was before we changed it.
>> >
>> > Based on the UBOOT_MACHINE, can we be certain we are changing the
>> correct file?
>> >
>> > How do we get the build process to include our changes?
>> >
>> > Thanks,
>> > David
>> >
>> >
>> >
>> > On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:
>> >
>> > Hello everyone,
>> >
>> > System: sama5d3_xplained board
>> >
>> > I have a question regarding the configuration and build of u-boot.
>> > We have a build that was implemented earlier. I am trying to make some
>> changes to it.
>> >
>> > Change 1: Change the auto boot delay to 1 second.
>> > Change 2: Add an auto boot command to set a gpio.
>> >
>> > I am aware of the environment variables:  CONFIG_BOOTDELAY and
>> CONFIG_BOOTCOMMAND (needed for the changes above.)
>> > I tried modifying the  " configs/sama5d3_xplained_nandflash_defconfig "
>> >
>> > Question 1: Do I need to create an *.config file using the make
>> menuconfig?
>> >
>> > Question 2: How do I create the u-boot.bin . Does this  depend on the
>> Linux build?
>> > I know that there is an environment variable:
>> CONFIG_BOOTARGS that needs to be populated.
>> >
>> > --
>> > Pratham Ovalekar
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51581): https://lists.yoctoproject.org/g/yocto/message/51581
Mute This Topic: https://lists.yoctoproject.org/mt/78377165/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] U-Boot sama5d3 xplained issue

[Federico Pellegrin]

Hi,
I think it would be interesting information to know "how" you change the
value inside "u-boot-at91/sama5d3_xplained_nandflash_config".

As every time you rebuild it may be redownloaded, you should do this via a
patch to append to the recipe.

Are you doing this? Or just changing it locally?

If you give some more info probably we can better help!

Cheers,
Federico

Il giorno lun 23 nov 2020 alle ore 08:06 Khem Raj  ha
scritto:

> perhaps asking it on https://github.com/linux4sam/u-boot-at91 via
> github issues might be helpful too.
>
> On Sat, Nov 21, 2020 at 4:26 AM David Novak  wrote:
> >
> > I'm working on this project with Pratham. Let me provide a few more
> details.
> >
> > We've defined
> >
> > UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"
> >
> > Inside
> >
> > u-boot-at91/sama5d3_xplained_nandflash_config
> >
> > we change CONFIG_BOOTDELAY, but it has no effect on the newly built
> image. The boot delay remains the same as it was before we changed it.
> >
> > Based on the UBOOT_MACHINE, can we be certain we are changing the
> correct file?
> >
> > How do we get the build process to include our changes?
> >
> > Thanks,
> > David
> >
> >
> >
> > On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:
> >
> > Hello everyone,
> >
> > System: sama5d3_xplained board
> >
> > I have a question regarding the configuration and build of u-boot.
> > We have a build that was implemented earlier. I am trying to make some
> changes to it.
> >
> > Change 1: Change the auto boot delay to 1 second.
> > Change 2: Add an auto boot command to set a gpio.
> >
> > I am aware of the environment variables:  CONFIG_BOOTDELAY and
> CONFIG_BOOTCOMMAND (needed for the changes above.)
> > I tried modifying the  " configs/sama5d3_xplained_nandflash_defconfig "
> >
> > Question 1: Do I need to create an *.config file using the make
> menuconfig?
> >
> > Question 2: How do I create the u-boot.bin . Does this  depend on the
> Linux build?
> > I know that there is an environment variable:
> CONFIG_BOOTARGS that needs to be populated.
> >
> > --
> > Pratham Ovalekar
> >
> >
> >
> >
> >
> >
> >
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51524): https://lists.yoctoproject.org/g/yocto/message/51524
Mute This Topic: https://lists.yoctoproject.org/mt/78377165/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-