Date   

Re: [ANNOUNCEMENT] Yocto Project 3.2.1 (gatesgarth-24.0.1) is Released

Anuj Mittal
 

On Tue, 2020-12-15 at 23:07 +0000, Peter Kjellerstedt wrote:
Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: gatesgarth
Tag: yocto-3.2.1
The yocto-3.2.1 and gatesgarth-24.0.1 tags for meta-gplv2 have been
incorrectly
set on the dunfell branch rather than the gatesgarth branch. The Git
revision
and tar balls below are correct though. Since the tags are signed I
do now want
to modify them myself, so please correct them as soon as possible.
Vineela isn't working this week I think so she might not be able to
help but it looks like the commit tagged is on gatesgarth ...

https://git.yoctoproject.org/clean/cgit.cgi/meta-gplv2/log/?h=gatesgarth

$ git branch -a --contains yocto-3.2.1
* master
remotes/origin/HEAD -> origin/master
remotes/origin/gatesgarth
remotes/origin/master
remotes/origin/master-next

Thanks,

Anuj


Re: [ANNOUNCEMENT] Yocto Project 3.2.1 (gatesgarth-24.0.1) is Released

Peter Kjellerstedt
 

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Peter Kjellerstedt
Sent: den 16 december 2020 00:08
To: Vineela <vineela.tummalapalli@...>
Cc: 'yocto@...' <yocto@...>
Subject: Re: [yocto] [ANNOUNCEMENT] Yocto Project 3.2.1 (gatesgarth-
24.0.1) is Released

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Vineela
Sent: den 15 december 2020 22:13
To: 'yocto-announce@...' <yocto-
announce@...>; 'yocto@...'
<yocto@...>; 'yocto-request@...'
<yocto-
request@...>
Subject: [yocto] [ANNOUNCEMENT] Yocto Project 3.2.1 (gatesgarth-24.0.1)
is Released

Hello,

We are pleased to announce the Yocto Project 3.2.1 (gatesgarth-24.0.1)
Release is now available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.1/poky-
gatesgarth-24.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.2.1/poky-gatesgarth-
24.0.1.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-
3.2.1/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-
3.2.1/testreport.txt

Thank you for everyone's contributions to this release.

Vineela Tummalapalli
Yocto Project Build and Release
vineela.tummalapalli@...


--------------------------
yocto-3.2.1 Release Notes
--------------------------

--------------------------
Repositories/Downloads
--------------------------
[cut]

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: gatesgarth
Tag: yocto-3.2.1
The yocto-3.2.1 and gatesgarth-24.0.1 tags for meta-gplv2 have been
incorrectly set on the dunfell branch rather than the gatesgarth
branch. The Git revision and tar balls below are correct though.
Since the tags are signed I do not want to modify them myself, so
please correct them as soon as possible.

Git Revision: 6e8e969590a22a729db1ff342de57f2fd5d02d43
Release Artefact: meta-gplv2-gatesgarth-24.0.1
sha: f43941fee62bccb5dee55809ab8c65d60eae82cf06cd05f3b150e93efaff86b6
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.1/meta-gplv2-gatesgarth-24.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.2.1/meta-gplv2-gatesgarth-24.0.1.tar.bz2
//Peter
*ping* The tags in meta-gplv2 are still incorrect.

//Peter


Automatic addition of trailing slashes on layers.openembedded.org

 

Hi folks,

Working on the docs recently we noticed that there is no automatic
addition of a trailing slash on layers.openembedded.org when it's
needed:

https://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core
- shows "Page not found".

https://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/
- shows the layer correctly.

Is this something that can easily be fixed?

--
Paul Barker
Konsulko Group


M+ & H bugs with Milestone Movements WW51

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW51 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.3 M1

3.3 M2

 

11385

poky-container: clarify that meta-data should be checked out using native tools that run the host and not with tools in container

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

12060

It is possible to specify a PACKAGE and a PKG_ rename that conflict

kai.kang@...

kai.kang@...

3.3 M1

3.3 M2

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.kang@...

kai.kang@...

3.3 M1

3.3 M2

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.3 M1

3.3 M2

 

13008

toaster testing

david.reyna@...

david.reyna@...

3.3 M1

3.3 M3

 

13109

Implement CPE to package to Release mapping

david.reyna@...

david.reyna@...

3.3 M1

3.3 M3

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.3 M1

3.3 M2

 

13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed

Qi.Chen@...

Qi.Chen@...

3.3 M1

3.3 M3

 

13311

xargs: fdleak.c:396: complain_about_leaky_fds: Assertion `no_leaks' failed.

randy.macleod@...

mingli.yu@...

3.4

3.3 M3

 

13411

ptest-perl.bbclass run-ptest is too greedy for SKIP

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

13425

Add bblock and bbunlock helper tools

randy.macleod@...

newcomer@...

3.3 M1

3.3 M2

 

13674

master dnf failures on qemumips

randy.macleod@...

mingli.yu@...

3.4

3.3 M3

 

13690

runqemu with slirp, forwarded host ports are not available on host

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

13722

Debugging With the GNU Project Debugger enhancements

randy.macleod@...

newcomer@...

3.3 M1

3.3 M2

 

13768

base-files do_package fatal error in subprocess

randy.macleod@...

mingli.yu@...

3.4

3.3 M2

 

13930

Port the CROPS toaster-container selenium tests to the Autobuilder

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

13934

Apparent duplication of libtirpc package causes failure in "bitbake linux-yocto -c menuconfig"

hongxu.jia@...

hongxu.jia@...

3.1.5

3.3 M4

 

13938

devtool modify virtual/kernel fails when EXTRAVERSION field is empty in Makefile

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

14020

environment-setup script in multilib eSDK doesn't work for multilib variant

liezhi.yang@...

liezhi.yang@...

3.3 M1

3.3 M2

 

14026

documentation how to use systemd is inconsistent

randy.macleod@...

mark.morton@...

3.3 M1

3.3 M2

 

14051

[QA 3.2 M3 RC1] failure in ptest : valgrind.drd and valgrind.helgrind

randy.macleod@...

anuj.mittal@...

3.3 M1

3.3 M2

 

14085

Toaster UI should know when bitbake crashed

david.reyna@...

david.reyna@...

3.3 M1

3.3 M2

 

14098

absolute path in TEMPLATECONF should be rejected or warned, makes ext-sdk uninstallable

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

14093

master] a-quick python warning

timothy.t.orling@...

timothy.t.orling@...

3.3 M1

3.3 M2

 

14118

systemd services not enabled when using package feed

kai.kang@...

kai.kang@...

3.3 M1

3.3 M2

 

14126

resolvconf incompatible with busybox flock

randy.macleod@...

newcomer@...

3.3 M1

3.3 M2

 

14150

devtool: modify: fails for gstreamer1.0-plugins-good

timothy.t.orling@...

unassigned@...

3.3 M2

0.0.0

 

14151

devtool build fails for python3

timothy.t.orling@...

unassigned@...

3.3 M2

0.0.0

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW51!

Stephen Jolley
 

All,

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

Who

Count

mhalstead@...

3

richard.purdie@...

1

jay.shen.teoh@...

1

Grand Total

5

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

36

ross@...

27

david.reyna@...

21

bluelightning@...

19

bruce.ashfield@...

14

timothy.t.orling@...

12

mark.morton@...

11

JPEWhacker@...

11

kai.kang@...

10

sakib.sajal@...

10

akuster808@...

10

trevor.gamblin@...

9

Qi.Chen@...

6

hongxu.jia@...

4

raj.khem@...

4

idadelm@...

4

randy.macleod@...

4

yi.zhao@...

4

mingli.yu@...

4

mostthingsweb@...

3

chee.yang.lee@...

3

alejandro@...

3

jon.mason@...

2

matthewzmd@...

2

jeanmarie.lemetayer@...

2

pokylinux@...

2

saul.wold@...

2

anuj.mittal@...

2

ydirson@...

2

jaewon@...

2

matt.ranostay@...

1

apoorvsangal@...

1

joe.slater@...

1

akuster@...

1

mhalstead@...

1

kexin.hao@...

1

aehs29@...

1

dl9pf@...

1

kergoth@...

1

liezhi.yang@...

1

mark.hatle@...

1

maxime.roussinbelanger@...

1

shachar@...

1

Martin.Jansa@...

1

kamensky@...

1

Grand Total

260

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


[auh][PATCH] upgrade-helper.py: handle unassigned recipes correctly

Alexander Kanavin
 

Attempting to send to unassigned@... bounces immediately,
which means the CC recipients (such as oe-core list) won't get the email
either.

Instead, send to cc directly.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
upgrade-helper.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/upgrade-helper.py b/upgrade-helper.py
index 7ed7af4..eb3935e 100755
--- a/upgrade-helper.py
+++ b/upgrade-helper.py
@@ -320,7 +320,10 @@ class Updater(object):
=20
cc_addr =3D None
if "cc_recipients" in settings:
- cc_addr =3D settings["cc_recipients"].split()
+ if 'unassigned' in to_addr:
+ to_addr =3D settings["cc_recipients"].split()
+ else:
+ cc_addr =3D settings["cc_recipients"].split()
=20
newversion =3D pkg_ctx['NPV'] if not pkg_ctx['NPV'].endswith("ne=
w-commits-available") else pkg_ctx['NSRCREV']
subject =3D "[AUH] " + pkg_ctx['PN'] + ": upgrading to " + newve=
rsion
--=20
2.29.2


Re: hostapd_free_hapd_data: Interface wlan0 wasn't started #linux #kernel #dunfell

Shamil Khan
 

Hi VR,

Please make sure that the interface name in hostapd.conf matches with the wireless interface name of your target. 
By default it is set to wlan0, but it could be different in your target (for ex, wlp2s0...).

Best regards,
Shamil


Re: Using U-boot in Yocto

Zoran
 

Hello Jonas,

Do not forget that you can also build and use U-Boot completely out of
a YOCTO tree.

I do things like that, not using the YOCTO U-Boot build.

(As a matter of fact, I do not use the kernel as well, only rootfs for
the testing purposes)

But it depends what and how your business/project management model
looks like, I should say.

Zoran
_______

On Sun, Dec 20, 2020 at 3:10 PM Jonas Vautherin
<jonas.vautherin@...> wrote:

Oh, for some reason I had not found the docs. Thanks a lot, that looks really good!

On Sun, Dec 20, 2020 at 2:13 PM Paul Barker <pbarker@...> wrote:

On Sun, 20 Dec 2020 at 09:02, Jonas Vautherin <jonas.vautherin@...> wrote:

Hello!

I am new to Yocto, and hope that this is the right way to ask for help :-).

I would like to have a way to flash my RPi over USB using `fastboot`, and it seems to me that one way to do that is to enable a "fastboot mode" in U-boot. Therefore, I am trying to use U-boot in my Yocto image.

There seems to be a recipe for it, hence I just added the package to my `-image.bb` file:

```
IMAGE_INSTALL += "u-boot"
```

However, I am not really used to bootloaders, and I am not sure it is booting with it. How can I check if my system is booting with U-boot? It does not seem like it's appearing in `dmesg` (which I presume is only starting with the kernel). Do I need to observe that with a serial connection to my RPi, or is there a log saved somewhere on the system?

Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64" (Raspberry Pi 4 Model B).
The IMAGE_INSTALL variable is used for packages to install into the
rootfs. Typically bootloaders need some special handling and simply
adding them to IMAGE_INSTALL either doesn't work or isn't sufficient
to enable booting via the chosen bootloader.

For Raspberry Pi we made this simple by adding the RPI_USE_U_BOOT
variable which you can set in your distro config or in local.conf. See
https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
for more details.

The layer documentation for meta-raspberrypi is actually pretty good,
you can find it at
https://meta-raspberrypi.readthedocs.io/en/latest/index.html.

Thanks,

--
Paul Barker
Konsulko Group



python scikit-learn ppackage

Marek Belisko
 

Hi,

I'm trying to add to my project python package for sciki-learn which
requires some cross compilation (using cython). I was trying to make
it but it's not straightforward as all python libs are searched in
native and not target sysroots. Is there some other way to force
python to look on target-sysroots instead of native one? I used
PYTHONPATH but it seems it's not taking effect. I was also pointed to
python tool crossenv but I'm not sure if it's the way to go. Ideas?

Thanks and regards,

marek

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

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


Re: Can a single recipe .bb file be used to generate both Python2 and Python3 packages?

Robert P. J. Day
 

On Sun, 20 Dec 2020, Rob Prowel wrote:

On 12/20/20 8:46 AM, Robert P. J. Day wrote:

I asked if that is what she was thinking of, but she was adamant
that she remembers a single recipe .bb file that could do this.
Is there such a thing? I suspect one could hack something up,
but is such an approach considered standard? Or even doable?
Doable? Yes...Smart to do? IMHO, absolutely not.

With the recipe class methods that accomplish each stage of the
build you can customize them any way you want, but at the expense of
maintaining clear intent and keeping it maintainable.

Your initial approach of using common includes and a heirarchical
inheritance for separate recipes makes more sense.
i suspected as much, i just wanted to confirm there was no
super-clever way to do this.

rday


Re: Can a single recipe .bb file be used to generate both Python2 and Python3 packages?

Rob Prowel <rprowel@...>
 

On 12/20/20 8:46 AM, Robert P. J. Day wrote:

I asked if that is what she was thinking of, but she was adamant
that she remembers a single recipe .bb file that could do this.
Is there such a thing? I suspect one could hack something up,
but is such an approach considered standard? Or even doable?
Doable? Yes...Smart to do? IMHO, absolutely not.

With the recipe class methods that accomplish each stage of the build you can customize them any way you want, but at the expense of maintaining clear intent and keeping it maintainable.

Your initial approach of using common includes and a heirarchical inheritance for separate recipes makes more sense.


Re: Using U-boot in Yocto

Jonas Vautherin
 

Oh, for some reason I had not found the docs. Thanks a lot, that looks really good!


On Sun, Dec 20, 2020 at 2:13 PM Paul Barker <pbarker@...> wrote:
On Sun, 20 Dec 2020 at 09:02, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> Hello!
>
> I am new to Yocto, and hope that this is the right way to ask for help :-).
>
> I would like to have a way to flash my RPi over USB using `fastboot`, and it seems to me that one way to do that is to enable a "fastboot mode" in U-boot. Therefore, I am trying to use U-boot in my Yocto image.
>
> There seems to be a recipe for it, hence I just added the package to my `-image.bb` file:
>
> ```
> IMAGE_INSTALL += "u-boot"
> ```
>
> However, I am not really used to bootloaders, and I am not sure it is booting with it. How can I check if my system is booting with U-boot? It does not seem like it's appearing in `dmesg` (which I presume is only starting with the kernel). Do I need to observe that with a serial connection to my RPi, or is there a log saved somewhere on the system?
>
> Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64" (Raspberry Pi 4 Model B).

The IMAGE_INSTALL variable is used for packages to install into the
rootfs. Typically bootloaders need some special handling and simply
adding them to IMAGE_INSTALL either doesn't work or isn't sufficient
to enable booting via the chosen bootloader.

For Raspberry Pi we made this simple by adding the RPI_USE_U_BOOT
variable which you can set in your distro config or in local.conf. See
https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
for more details.

The layer documentation for meta-raspberrypi is actually pretty good,
you can find it at
https://meta-raspberrypi.readthedocs.io/en/latest/index.html.

Thanks,

--
Paul Barker
Konsulko Group


Can a single recipe .bb file be used to generate both Python2 and Python3 packages?

Robert P. J. Day
 

Strange request earlier this week -- I was asked how *one* Python
recipe file could be used to generate both Python2 and Python3
packages to be installed in the final image.

I had never heard of such a thing, but the colleague asking this
was convinced she had seen this before somewhere (but couldn't
remember where).

My immediate response was that the standard approach was to define
two recipe files -- say, python-fubar.bb and python3-fubar.bb --
where the entire difference was "inherit setuptools" in the former
and "inherit setuptools3" in the latter.

I mentioned that it used to be common to have just that, and for
both recipes to then include all the common content in the file
"python-fubar.inc" (I do see how a couple folks are cleaning all
that up since, if there is now only the Python3 version being
supported, it's pointless to still have a ".inc" file).

I asked if that is what she was thinking of, but she was adamant
that she remembers a single recipe .bb file that could do this.
Is there such a thing? I suspect one could hack something up,
but is such an approach considered standard? Or even doable?

rday


Re: Using U-boot in Yocto

 

On Sun, 20 Dec 2020 at 09:02, Jonas Vautherin <jonas.vautherin@...> wrote:

Hello!

I am new to Yocto, and hope that this is the right way to ask for help :-).

I would like to have a way to flash my RPi over USB using `fastboot`, and it seems to me that one way to do that is to enable a "fastboot mode" in U-boot. Therefore, I am trying to use U-boot in my Yocto image.

There seems to be a recipe for it, hence I just added the package to my `-image.bb` file:

```
IMAGE_INSTALL += "u-boot"
```

However, I am not really used to bootloaders, and I am not sure it is booting with it. How can I check if my system is booting with U-boot? It does not seem like it's appearing in `dmesg` (which I presume is only starting with the kernel). Do I need to observe that with a serial connection to my RPi, or is there a log saved somewhere on the system?

Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64" (Raspberry Pi 4 Model B).
The IMAGE_INSTALL variable is used for packages to install into the
rootfs. Typically bootloaders need some special handling and simply
adding them to IMAGE_INSTALL either doesn't work or isn't sufficient
to enable booting via the chosen bootloader.

For Raspberry Pi we made this simple by adding the RPI_USE_U_BOOT
variable which you can set in your distro config or in local.conf. See
https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
for more details.

The layer documentation for meta-raspberrypi is actually pretty good,
you can find it at
https://meta-raspberrypi.readthedocs.io/en/latest/index.html.

Thanks,

--
Paul Barker
Konsulko Group


Using U-boot in Yocto

Jonas Vautherin
 

Hello!

I am new to Yocto, and hope that this is the right way to ask for help :-).

I would like to have a way to flash my RPi over USB using `fastboot`, and it seems to me that one way to do that is to enable a "fastboot mode" in U-boot. Therefore, I am trying to use U-boot in my Yocto image.

There seems to be a recipe for it, hence I just added the package to my `-image.bb` file:

```
IMAGE_INSTALL += "u-boot"
```

However, I am not really used to bootloaders, and I am not sure it is booting with it. How can I check if my system is booting with U-boot? It does not seem like it's appearing in `dmesg` (which I presume is only starting with the kernel). Do I need to observe that with a serial connection to my RPi, or is there a log saved somewhere on the system?

Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64" (Raspberry Pi 4 Model B).

Cheers,


How to add pacemaker and corosync with yocto for aspberrypi with all it's dependencies #dunfell #raspberrypi #yocto

@prashant2314
 

Hello Team,

I need to use High availability cluster in my project. I'm generating OS for Rpi using Ycot. I'm using dunfell poky version 3.1.3.

I'm adding ntp tzdata pacemaker haveged and crmsh command in my local.conf file, where crmsh command is giving error while doing bitbake saying unable to python-setuptools-native, doing web I got I can remove this dependency.

After that crmsh got installed properly and yocto build got completed. But when I'm flashing Image then while using crm status command crmsh is giving error in start, like this -
"
Fatal error:
    No module named 'doctest'

Failed to start crmsh! This is likely due to a broken
installation or a missing dependency.

If you are using a packaged version of crmsh, please try
reinstalling the package. Also check your PYTHONPATH and
make sure that the crmsh module is reachable.

Please file an issue describing your installation at
https://github.com/Clusterlabs/crmsh/issues/ .
"

And corosync is also failing to start.

Please assist me add these commands properly with yocto for raspberrypi.

Reagrds.


Re: Is curated SPDX data sharing a thing?

Richard Purdie
 

On Fri, 2020-12-18 at 16:51 -0500, Jérôme Carretero wrote:
On Fri, 18 Dec 2020 20:34:01 +0000
"Richard Purdie" <richard.purdie@...> wrote:

The challenge is that Yocto Project lets you build your own custom
software, which means you also end up in your own BoM situation. We
generally therefore provide tooling that can help you generate the
information you need but there usually isn't "one size fits all".
Of course different choices can be made regarding obligations (where
licenses are shown, how sources are distributed) but it in the same
way that today ${LICENSE_DIRECTORY}/${P}/recipeinfo contains a
LICENSE key which is very useful figuring out obligations, SPDX could
be used to have more information and more trust.
Its going to take someone to stand up and provide the first "version"
of that and I'm not sure anyone wants to step up and be that
person/organisation...

In most of my experience, a product mostly contains F/LOSS code from
major Yocto/OE layers, maybe a couple of other 3rd party libraries, a
couple of patches here and there, and a few 100kSLOC of "original"
code;
the BoM consists... in an image manifest file.

A huge portion of the SPDX data could be reused, to get an
almost-complete better BoM.
It does depend on which data we're talking about. You also have the
issue that its fine to generate this tons of data but at some point you
have to interpret what it means too...

I would mention the meta-spdxscanner layer as having
support/integration for some of the more recent scanning and
document
generation tools.
Yeah, I used it. I can see that it mostly works except for the fact
that you either spend a lifetime doing source code analysis, or just
a few years because you trust the agreement of multiple robots on the
license verdict, which only leaves you the ambiguous files to process
(and that's time-consuming work).
I watched and helped our older LICENSE field work and I can say its a
thankless task which its very hard to get people to do. I fear that the
SPDX scans you refer to are so complex it will be hard to do this
consistently across the codebase. I'm actually hoping things may go a
slightly different route such as ultimately a majority of code having
license identifiers in it (we've tried to ensure YP code has them).

I'm sure there are services provided, particularly by some of the
member OSVs but as I mention above, its hard to have a one size
fits
all since you can patch or reconfigure the sources at will.
SPDX data contains package and also source file info (based on
hashes),
so if a patch is applied, an analysis would only need to concern
modified files. Provided a development history and a baseline SPDX
available, it would significantly reduce the amount of work one would
face.
Sure, how do we get people to build such a baseline though?

We are hoping to have better tools integration where the build
process
may be able to generation better SBoM and SPDX information
directly.
Unfortunately its an area its hard to find people willing to
contribute.
It's certainly easy to verify after do_patch (or after do_compile in
some cases) that sources correspond to existing SPDX files, or to
lookup SPDX files in an external database based on hashes of sources,
but automatically generating SPDX:

- is very time-consuming and I don't see it as something that one
would
even do eg. in continuous integration;
- is not perfect; I don't think the build process could automatically
generate more than "candidate SPDX" information except maybe for a
couple of really-clean packages where the developers care about
that.
There are certainly ways it could be done, if there are people who
agree on a common objective and are willing/able to contribute time to
it.

Is there is a more focused discussion list on that topic or here is
OK?
I may have a lot of questions/ideas but don't want to cause off-topic
noise.
We did set one up so there is
https://lists.yoctoproject.org/g/licensing/topics but it hasn't really
taken off (yet?)...

Cheers,

Richard


Re: Is curated SPDX data sharing a thing?

Jérôme Carretero
 

On Fri, 18 Dec 2020 20:34:01 +0000
"Richard Purdie" <richard.purdie@...> wrote:

The challenge is that Yocto Project lets you build your own custom
software, which means you also end up in your own BoM situation. We
generally therefore provide tooling that can help you generate the
information you need but there usually isn't "one size fits all".
Of course different choices can be made regarding obligations (where
licenses are shown, how sources are distributed) but it in the same way
that today ${LICENSE_DIRECTORY}/${P}/recipeinfo contains a LICENSE key
which is very useful figuring out obligations, SPDX could be used to
have more information and more trust.

In most of my experience, a product mostly contains F/LOSS code from
major Yocto/OE layers, maybe a couple of other 3rd party libraries, a
couple of patches here and there, and a few 100kSLOC of "original" code;
the BoM consists... in an image manifest file.

A huge portion of the SPDX data could be reused, to get an
almost-complete better BoM.

I would mention the meta-spdxscanner layer as having
support/integration for some of the more recent scanning and document
generation tools.
Yeah, I used it. I can see that it mostly works except for the fact
that you either spend a lifetime doing source code analysis, or just a
few years because you trust the agreement of multiple robots on the
license verdict, which only leaves you the ambiguous files to process
(and that's time-consuming work).

I'm sure there are services provided, particularly by some of the
member OSVs but as I mention above, its hard to have a one size fits
all since you can patch or reconfigure the sources at will.
SPDX data contains package and also source file info (based on hashes),
so if a patch is applied, an analysis would only need to concern
modified files. Provided a development history and a baseline SPDX
available, it would significantly reduce the amount of work one would
face.

We are hoping to have better tools integration where the build process
may be able to generation better SBoM and SPDX information directly.
Unfortunately its an area its hard to find people willing to
contribute.
It's certainly easy to verify after do_patch (or after do_compile in
some cases) that sources correspond to existing SPDX files, or to
lookup SPDX files in an external database based on hashes of sources,
but automatically generating SPDX:

- is very time-consuming and I don't see it as something that one would
even do eg. in continuous integration;
- is not perfect; I don't think the build process could automatically
generate more than "candidate SPDX" information except maybe for a
couple of really-clean packages where the developers care about that.

Is there is a more focused discussion list on that topic or here is OK?
I may have a lot of questions/ideas but don't want to cause off-topic
noise.


Best,

--
Jérôme

6001 - 6020 of 57804