Date   

[meta-zephyr][PATCH] qemu-x86: set new -machine value for QEMU

Naveen Saini
 

-machine type=pc-1.3 is deprecated with QEMU 5.1.0

Error:
machine runqemu - ERROR - Failed
to run qemu: qemu-system-i386: unsupported machine type

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/qemu-x86.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index ce79b5b..85b3f0d 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,7 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
-QB_MACHINE = "-machine type=pc-1.3"
+QB_MACHINE = "-machine type=pc-q35-2.10"
QB_OPT_APPEND = "-nographic -no-acpi"
QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"
--
2.17.1


[meta-security][PATCH] tpm2-tss: fix usrmerge udev install path

Ricardo Salveti
 

Update ${base_prefix}/lib to ${nonarch_base_libdir} to fix a package QA
issue when usrmerge is enabled in DISTRO_FEATURES.

QA Issue: tpm2-tss package is not obeying usrmerge distro feature. /lib
should be relocated to /usr. [usrmerge]

Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
---
meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
index b2486e5..cc4f191 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
@@ -17,7 +17,7 @@ PACKAGECONFIG ??= ""
PACKAGECONFIG[oxygen] = ",--disable-doxygen-doc, "
PACKAGECONFIG[fapi] = "--enable-fapi,--disable-fapi,json-c "

-EXTRA_OECONF += "--enable-static --with-udevrulesdir=${base_prefix}/lib/udev/rules.d/"
+EXTRA_OECONF += "--enable-static --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d/"
EXTRA_OECONF_remove = " --disable-static"


@@ -73,6 +73,6 @@ FILES_libtss2-dev = " \
${libdir}/libtss2*so"
FILES_libtss2-staticdev = "${libdir}/libtss*a"

-FILES_${PN} = "${libdir}/udev ${base_prefix}/lib/udev"
+FILES_${PN} = "${libdir}/udev ${nonarch_base_libdir}/udev"

RDEPENDS_libtss2 = "libgcrypt"
--
2.31.1


Re: Statically linked libraries and license manifest

Khem Raj
 

On Thu, May 20, 2021 at 9:18 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?
I see, this is a workaround that will work in this case but may not
work in case where the PN is not empty
but static linking it happening. So I think in cases of static linking
the parent recipe has to reflect that chage

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:
On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

>
>
>
>
>
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----



Re: Statically linked libraries and license manifest

Jasper Orschulko
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:
On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

 >
 >
 >
 >
 >
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----


Re: Statically linked libraries and license manifest

Khem Raj
 

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

>
>
>
>
>
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----


Re: Statically linked libraries and license manifest

Jasper Orschulko
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

 >
 >
 >
 >
 >
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----


[yocto-autobuilder-helper][dunfell] config.json: Set XZ limits to more reasonable values on autobuilder

Steve Sakoman
 

From: Richard Purdie <richard.purdie@linuxfoundation.org>

The autobuilders have 128GB memory, we don't want them using 50% which is
the default, 5% should be enough. Also limit the number of threads down
from 48 to something reasonable. This may be partly causing some of our
performance issues?

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 19b4e74b3960174238acc79fd112f55706bc7385)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.json | 2 ++
1 file changed, 2 insertions(+)

diff --git a/config.json b/config.json
index e77a8fe..b62035b 100644
--- a/config.json
+++ b/config.json
@@ -44,6 +44,8 @@
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
"PARALLEL_MAKE = '-j 16'",
+ "XZ_MEMLIMIT = '5%'",
+ "XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
"BB_TASK_NICE_LEVEL_task-testimage = '0'",
"BB_TASK_IONICE_LEVEL = '2.7'",
--
2.25.1


Re: Problem with YOCTO Dunfell and host Fedora 33

Joel Winarske
 

Hi Zoran,

Your cannelloni recipe is set to autorev, meaning it's not locked to a commit.  So when something changes upstream you have to manage it.

Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling.  Perhaps try to cross compile (not a host build) Canelloni by itself without Yocto involved.  Once that's sorted, then reintroduce yocto.


Joel


On Thu, May 20, 2021, 6:58 AM Zoran <zoran.stojsavljevic@...> wrote:
Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______




Problem with YOCTO Dunfell and host Fedora 33

Zoran
 

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______


[meta-zephyr][PATCH v2 4/4] acrn.conf: drop acrn machine configuration

Naveen Saini
 

zephyr can be build for 'acrn' with following configuration:

MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/acrn.conf | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf

diff --git a/conf/machine/acrn.conf b/conf/machine/acrn.conf
deleted file mode 100644
index c044933..0000000
--- a/conf/machine/acrn.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-#@TYPE: Machine
-#@NAME: acrn
-#@DESCRIPTION: Machine for Zephyr BOARD acrn
-
-require conf/machine/include/qemu.inc
-require conf/machine/include/tune-corei7-common.inc
-ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
-
-ARCH_acrn = "x86"
--
2.17.1


[meta-zephyr][PATCH v2 3/4] intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1


[meta-zephyr][PATCH v2 2/4] intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1


[meta-zephyr][PATCH v2 1/4] zephyr-kernel-src: fix efi generation failure for x86 boards

Naveen Saini
 

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@intel.com>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = " file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..b3b9565 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -1,10 +1,6 @@
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

-# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
-include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
-
inherit cmake

# This file might be included from other places (like other layers) and not
@@ -23,3 +19,7 @@ SRC_URI = "\
file://0001-cmake-add-yocto-toolchain.patch \
"
S = "${WORKDIR}/git"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1


[meta-zephyr][PATCH v2 0/4] Fix efi generation and add x86 MACHINE confs (cover letter)

Naveen Saini
 

(1) zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode).
To achieve this, an python tool[1] has been added to convert zephyr EFL file
into an EFI appliable. But unfortunately at current this does not work with Yocto cross-compilation env.
This patch fix this issue and allow to build zephyr.efi for ehl_crb and up_squared boards.


(2)
Instead of creating machine configuration for each
supported boards, I would like to have common machine configurations for
supported boards. One for 64-bit (intel-x86-64.conf) and one for 32-bit
(intel-x86-32.conf).

User need to specify board value to ZEPHYR_BOARD in local.conf based on
targeted board i.e
ZEPHYR_BOARD = "ehl_crb"

64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb (default)
* acrn
* acrn_ehl_crb

32-bit supported boards:
* up_squared_32
* minnowboard (default)

(3) Dropped acrn MACHINE configuration, which can be build with
MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

---
v2:
Fixed build for Zephyr 2.4.0
Dropped ACRN configuration

Naveen Saini (4):
zephyr-kernel-src: fix efi generation failure for x86 boards
intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS
acrn.conf: drop acrn machine configuration

conf/machine/acrn.conf | 9 ---
conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/include/tune-corei7-common.inc | 3 +
conf/machine/intel-x86-32.conf | 12 +++
conf/machine/intel-x86-64.conf | 14 ++++
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
8 files changed, 122 insertions(+), 13 deletions(-)
delete mode 100644 conf/machine/acrn.conf
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
create mode 100644 conf/machine/intel-x86-64.conf
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

--
2.17.1


Re: hostile freenode takeover

Philip Balister
 

On 5/20/21 4:32 AM, Nicolas Dechesne wrote:
On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <
quentin.schulz@streamunlimited.com> wrote:

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <
Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into
that.

It looks like some open source communities have started to move to
https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring
any insights or recommendations... feel free!

perhaps good time to consider matrix
I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.
I think the question of setting up Matrix for our community is a valid
question, though I think it's orthogonal to the current problem. If
freenode goes away , we need an alternate plan to move *right away* to
another IRC server. If we want to setup addition communications means (such
as Matrix or anything else) that needs to be discussed and it might take
more time.
We have registered #oe and #yocto on libera already, so we can easily
transition irc servers as the situation develops.

Philip




Cheers,
Quentin




Re: hostile freenode takeover

Yocto
 


On 5/20/21 3:32 PM, Nicolas Dechesne wrote:


On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
> <nicolas.dechesne@...> wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Dear all,
> >>
> >> there have been recent reports of a hostile takeover of the freenode
> >> service, as described in
> >> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> >>
> >> The Yocto Project should verify these reports and take the necessary
> >> actions, in order to protect its users.
> >
> >
> > Thanks for your email. We are aware, and have started to look into that.
> >
> > It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
>
> perhaps good time to consider matrix
>

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid question, though I think it's orthogonal to the current problem. If freenode goes away , we need an alternate plan to move *right away* to another IRC server. If we want to setup addition communications means (such as Matrix or anything else) that needs to be discussed and it might take more time.

First let me say, there is nothing wrong with matrix, have used it every day for years

Second

the discussion is now about libre


there's a relay to relay stuff between libera and freenode?!
magic
LiberaRelay (relay@2607:f5a0:0:7::9) has joined #hardenedbsd
[Libera] R​elay (relay@user/relay) has joined #hardenedbsd
xmj: sup ? Libra?? whats dat ?
new irc net, made by freenode staffers that have been booted
freenode went through a hostile takeover
... in case you haven't noticed ;p

https://kline.sh/


 

Cheers,
Quentin




Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.1.rc1)

Sangeeta Jain
 

Hello All,

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

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

No new issue found.


Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Monday, 17 May, 2021 9:47 PM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.3.1.rc1)


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


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


Build hash information:

bitbake: b67476d4758915db7a5d9f58bc903ae7501a1774
meta-arm: 7ca13b4f15cc8f51d6c99b40b7ffafeb47dce28e
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 4d5791d9ff515ba1660234b1987eae4d4e90eeca
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: efce6334bf122a64f63d46c1c04e3dbffe298c51
poky: 05a8aad57ce250b124db16705acec557819905ae



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







Re: hostile freenode takeover

Nicolas Dechesne
 



On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
> <nicolas.dechesne@...> wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Dear all,
> >>
> >> there have been recent reports of a hostile takeover of the freenode
> >> service, as described in
> >> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> >>
> >> The Yocto Project should verify these reports and take the necessary
> >> actions, in order to protect its users.
> >
> >
> > Thanks for your email. We are aware, and have started to look into that.
> >
> > It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
>
> perhaps good time to consider matrix
>

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid question, though I think it's orthogonal to the current problem. If freenode goes away , we need an alternate plan to move *right away* to another IRC server. If we want to setup addition communications means (such as Matrix or anything else) that needs to be discussed and it might take more time. 
 

Cheers,
Quentin


Re: hostile freenode takeover

Quentin Schulz
 

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that.

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
perhaps good time to consider matrix
I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

Cheers,
Quentin


Re: [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file

Naveen Saini
 

Hi Jon,

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Jon Mason
Sent: Tuesday, May 18, 2021 11:10 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing
qemu conf file

Read the generated QEMU conf file, instead of using hard coded values.
This allows for machines not conforming to the hard coded values to work
with testimage.

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
conf/machine/qemu-x86.conf | 1 +
lib/oeqa/utils/qemuzephyrrunner.py | 89 +++++++++++++++++++++++++--
---
2 files changed, 77 insertions(+), 13 deletions(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index d85c22215520..ce79b5b1f510 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,6 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
+QB_MACHINE = "-machine type=pc-1.3"
[Naveen] ruqemu failed with qemu-x86 machine
runqemu - ERROR - Failed to run qemu: qemu-system-i386: -nographic: unsupported machine type

I run in my host :
$ qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-i386 -machine help

Supported machines are:
microvm microvm (i386)
pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-6.0)
pc-i440fx-6.0 Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-5.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.9 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.8 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.7 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.6 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.4 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.12 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.11 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.10 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996)
q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-6.0)
pc-q35-6.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.2 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.2 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-3.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-3.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.9 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.8 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.7 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.6 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.5 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.4 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.12 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.11 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.10 Standard PC (Q35 + ICH9, 2009)
isapc ISA-only PC
none empty machine
x-remote Experimental remote machine



QB_OPT_APPEND = "-nographic -no-acpi"
QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"
diff --git a/lib/oeqa/utils/qemuzephyrrunner.py
b/lib/oeqa/utils/qemuzephyrrunner.py
index e8a1bd4544cf..a1ed30be1ca8 100644
--- a/lib/oeqa/utils/qemuzephyrrunner.py
+++ b/lib/oeqa/utils/qemuzephyrrunner.py
@@ -14,6 +14,7 @@ import select
import bb
import tempfile
import sys
+import configparser
from oeqa.utils.qemurunner import QemuRunner

class QemuZephyrRunner(QemuRunner):
@@ -42,6 +43,72 @@ class QemuZephyrRunner(QemuRunner):
# 5 minutes timeout...
self.endtime = time.time() + 60*5

+ self.qemuboot = False
+ self.d = {'QB_KERNEL_ROOT': '/dev/vda'}
+
+ def get(self, key):
+ if key in self.d:
+ return self.d.get(key)
+ elif os.getenv(key):
+ return os.getenv(key)
+ else:
+ return ''
+
+ def set(self, key, value):
+ self.d[key] = value
+
+ def read_qemuboot(self):
+ if not self.qemuboot:
+ if self.get('DEPLOY_DIR_IMAGE'):
+ deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
+ else:
+ bb.warning("Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is
NULL!")
+ return
+
+ if self.rootfs and not os.path.exists(self.rootfs):
+ # Lazy rootfs
+ machine = self.get('MACHINE')
+ if not machine:
+ machine = os.path.basename(deploy_dir_image)
+ self.qemuboot = "%s/%s-%s.qemuboot.conf" %
(deploy_dir_image,
+ self.rootfs, machine)
+ else:
+ cmd = 'ls -t %s/*.qemuboot.conf' % deploy_dir_image
+ try:
+ qbs = subprocess.check_output(cmd, shell=True).decode('utf-8')
+ except subprocess.CalledProcessError as err:
+ raise RunQemuError(err)
+ if qbs:
+ for qb in qbs.split():
+ # Don't use initramfs when other choices unless fstype is ramfs
+ if '-initramfs-' in os.path.basename(qb) and self.fstype !=
'cpio.gz':
+ continue
+ self.qemuboot = qb
+ break
+ if not self.qemuboot:
+ # Use the first one when no choice
+ self.qemuboot = qbs.split()[0]
+ self.qbconfload = True
+
+ if not self.qemuboot:
+ # If we haven't found a .qemuboot.conf at this point it probably
+ # doesn't exist, continue without
+ return
+
+ if not os.path.exists(self.qemuboot):
+ raise RunQemuError("Failed to find %s (wrong image name or
+ BSP does not support running under qemu?)." % self.qemuboot)
+
+ cf = configparser.ConfigParser()
+ cf.read(self.qemuboot)
+ for k, v in cf.items('config_bsp'):
+ k_upper = k.upper()
+ if v.startswith("../"):
+ v = os.path.abspath(os.path.dirname(self.qemuboot) + "/" + v)
+ elif v == ".":
+ v = os.path.dirname(self.qemuboot)
+ self.set(k_upper, v)
+
+
def create_socket(self):
bb.note("waiting at most %s seconds for qemu pid" %
self.runqemutime)
tries = self.runqemutime
@@ -66,7 +133,6 @@ class QemuZephyrRunner(QemuRunner):

if not os.path.exists(self.tmpdir):
bb.error("Invalid TMPDIR path %s" % self.tmpdir)
- #logger.error("Invalid TMPDIR path %s" % self.tmpdir)
return False
else:
os.environ["OE_TMPDIR"] = self.tmpdir @@ -82,21 +148,18 @@ class
QemuZephyrRunner(QemuRunner):
bb.error("Invalid kernel path: %s" % self.kernel)
return False

- self.qemuparams = '-nographic -serial unix:%s,server' %
(self.socketname)
- qemu_binary = ""
- if 'arm' in self.machine or 'cortex' in self.machine:
- qemu_binary = 'qemu-system-arm'
- qemu_machine_args = '-machine lm3s6965evb'
- elif 'x86' in self.machine:
- qemu_binary = 'qemu-system-i386'
- qemu_machine_args = '-machine type=pc-1.3 -no-acpi -nographic -
cpu qemu32,+nx,+pae'
- elif 'nios2' in self.machine:
- qemu_binary = 'qemu-system-nios2'
- qemu_machine_args = '-machine altera_10m50_zephyr'
- else:
+ self.qemuparams = '-serial unix:%s,server' % (self.socketname)
+
+ self.read_qemuboot()
+ qemu_binary = self.get('QB_SYSTEM_NAME')
+ qemu_machine_args = self.get('QB_MACHINE')
+ if qemu_binary == "" or qemu_machine_args == "":
bb.error("Unsupported QEMU: %s" % self.machine)
return False

+ self.qemuparams += " %s " %self.get('QB_OPT_APPEND')
+ self.qemuparams += " %s " %self.get('QB_CPU')
+
self.origchldhandler = signal.getsignal(signal.SIGCHLD)
signal.signal(signal.SIGCHLD, self.handleSIGCHLD)

--
2.20.1

3521 - 3540 of 57098