Date   

Re: Per recipes simple smoke tests

Khem Raj
 

Hi Samuel

Please look at insane.bbclass and perhaps a new check can be added there ?

On Tue, Jul 13, 2021 at 12:42 AM Samuel Dolt <samuel.dolt@foxtron.ch> wrote:

Hi everyone,

I was asked to add some basic tests to an internal recipe in order to improve our CI system.

The purpose would be to produce an error if some check doesn't pass like
- a file is not present
- the generated file is of size 0
- the generated file is bigger than x bytes

I'm thinking to add the functionality to a class, in order to be able to use these tests in more than one recipe. Something like that: https://gist.github.com/samdolt/cf1c557f73f4f2098a19ba7ad6bc092f

Does something like that already exists? And if not, would it be useful to have this contributed upstream? Maybe as an addition to insane.bbclass?

Cheers,
Samuel


Re: [meta-spdxscanner] Question about meta-spdxscanner

Marco Cavallini
 

On 13/07/21 10:57, leimaohui@fujitsu.com wrote:
Hi Marco
.snip.
By the way, why not try fossology? It is really good that you can browse the compliance information on fossology server after you get spdx files by bitbake of YP.
Best regards
Lei

Hi Lei,
I tried the latest meta-spdxscanner with a Docker version cof Fossology but the entire process fails with errors on the Yocto bitbake side.

I'd like to have a minimal proof of work of this toolkit.
Would you mind sharing the version and the configuration you are using successfully (for both meta-spdxscanner and Fossology)?

Thank you
--
Marco


Yocto Project Status WW28`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • An issue with eSDK being host specific due to pseudo-native host dependencies has been resolved and this should resolve a number of bugs being reported by the community around use of the eSDK.
  • The prserv rewrite is still pending on resolving the issues with python asyncio.
  • We are continuing to make progress on the intermittent autobuilder failures. A race was identified in the qemu networking lock handling and there were some reproducibility fixes. Tweaks have been made to the autobuilder configuration such as avoiding key generation in more cases which it is believed may have been running into entropy shortages on the hosts, or just hitting CPU load issues. Some ptest improvements have also been made.
  • Despite this progress, we continue to see intermittent issues, particularly ptest ones. Help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others and current test cases are very slow to work with.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


M+ & H bugs with Milestone Movements WW27

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11906

rpmbuild: Can not build packages on qemu target

randy.macleod@...

unassigned@...

3.4 M1

3.4 M3

 

13934

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

randy.macleod@...

unassigned@...

3.4 M1

3.4 M3

 

14123

License manifest loss when switching MACHINE

randy.macleod@...

unassigned@...

3.4

3.4 M3

 

14120

pkg_postinst_ontarget_${PN}

randy.macleod@...

unassigned@...

3.4 M1

3.4 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW28!

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

3

akuster808@...

2

ross@...

2

thomas.perrot@...

1

mshah@...

1

Grand Total

9

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

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

Who

Count

ross@...

31

richard.purdie@...

29

michael.opdenacker@...

26

david.reyna@...

22

bruce.ashfield@...

18

bluelightning@...

12

sakib.sajal@...

11

timothy.t.orling@...

11

JPEWhacker@...

11

akuster808@...

11

trevor.gamblin@...

11

randy.macleod@...

10

tony.tascioglu@...

9

kai.kang@...

7

raj.khem@...

5

Qi.Chen@...

5

yi.zhao@...

5

mingli.yu@...

5

chee.yang.lee@...

5

hongxu.jia@...

4

mostthingsweb@...

3

jaewon@...

2

ydirson@...

2

yf3yu@...

2

mshah@...

2

alexandre.belloni@...

2

alejandro@...

2

mister_rs@...

1

florian.amstutz@...

1

devendra.tewari@...

1

pokylinux@...

1

shachar@...

1

Martin.Jansa@...

1

john.kaldas.enpj@...

1

douglas.royds@...

1

diego.sueiro@...

1

tonyb@...

1

mhalstead@...

1

kergoth@...

1

stacygaikovaia@...

1

nicolas.dechesne@...

1

yoctoproject@...

1

jon.mason@...

1

naveen.kumar.saini@...

1

kexin.hao@...

1

alex.kanavin@...

1

jeanmarie.lemetayer@...

1

liezhi.yang@...

1

aehs29@...

1

mark.hatle@...

1

matthewzmd@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 360 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@...

 


[yocto-autobuilder-helper] [PATCH] config.json: Use pregen-hostkeys on all qemu targets

Richard Purdie
 

Rather than just ppc/mips, use the pregen-hostkeys on all the qemu targets
since this is using a lot of time on the autobuilders when we don't really
need to. This should avoid some of the testing failures seen on qemuarm
recently.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
config.json | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/config.json b/config.json
index 4f6044e..1c52d60 100644
--- a/config.json
+++ b/config.json
@@ -71,6 +71,9 @@
"arch-qemu" : {
"BUILDINFO" : true,
"BUILDHISTORY" : true,
+ "extravars" : [
+ "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+ ],
"step1" : {
"BBTARGETS" : "core-image-sato core-image-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-minimal:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_testsdk"
@@ -91,6 +94,9 @@
"DISTRO" : "poky-altcfg",
"BUILDINFO" : true,
"BUILDHISTORY" : true,
+ "extravars" : [
+ "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+ ],
"step1" : {
"BBTARGETS" : "core-image-full-cmdline core-image-sato core-image-sato-sdk",
"SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
@@ -383,16 +389,10 @@
},
"qemumips" : {
"MACHINE" : "qemumips",
- "extravars" : [
- "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
- ],
"TEMPLATE" : "arch-qemu"
},
"qemumips-alt" : {
"MACHINE" : "qemumips",
- "extravars" : [
- "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
- ],
"TEMPLATE" : "altcfg-qemu"
},
"edgerouter" : {
@@ -409,16 +409,10 @@
},
"qemuppc" : {
"MACHINE" : "qemuppc",
- "extravars" : [
- "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
- ],
"TEMPLATE" : "arch-qemu"
},
"qemuppc-alt" : {
"MACHINE" : "qemuppc",
- "extravars" : [
- "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
- ],
"TEMPLATE" : "altcfg-qemu"
},
"qemux86" : {
--
2.30.2


Re: [meta-spdxscanner] Question about meta-spdxscanner

Marco Cavallini
 

On 13/07/21 10:57, leimaohui@fujitsu.com wrote:
Hi Marco

I see that meta-spdxscanner has been moved to http://git.yoctoproject.org,
and doesn't maintained on github
Yes, you can contact me or contribute to meta-spdxscanner to this ML.

I'd like to have advice from you to understand if is it possible to test it without
any external service and discover what kind of artefacts are generated into
deploy/spdx.
I have not maintained scancode-tk for long time. And recently there are somebody else asked me about scancode-tk.
Yes, I planned to make scancode-tk.bbclass work without external service. But there are always issues because environment.
The problem of scancode-tk.bbclass that scancode must work with specify a version of python(latest requires 3.6), but you know that for YP or your host, it is hard to meet the requirement.
I found the newest version of scancode-tk support running in docker. So I plan to make scancode-tk.bbclass work with scancode command by docker next.
Of course, if you have good ideas, please tell me, or contribute to meta-spdxscanner directlly.
By the way, why not try fossology? It is really good that you can browse the compliance information on fossology server after you get spdx files by bitbake of YP.
Best regards
Lei

Hi Lei,
thank you for answering.

Considering the problems I encounter with scancode-tk and that the artifacts it produces are simple text files that need further analysis, I was just deciding to migrate to Fossology with "fossology-rest".
The only drawback is having to install the server, but I don't think it will be a problem.

Thanks again, I will contact you again if you have any problems with this mode.

Best,
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


Re: [meta-spdxscanner] Question about meta-spdxscanner

leimaohui
 

Hi Marco

I see that meta-spdxscanner has been moved to http://git.yoctoproject.org,
and doesn't maintained on github
Yes, you can contact me or contribute to meta-spdxscanner to this ML.

I'd like to have advice from you to understand if is it possible to test it without
any external service and discover what kind of artefacts are generated into
deploy/spdx.
I have not maintained scancode-tk for long time. And recently there are somebody else asked me about scancode-tk.
Yes, I planned to make scancode-tk.bbclass work without external service. But there are always issues because environment.
The problem of scancode-tk.bbclass that scancode must work with specify a version of python(latest requires 3.6), but you know that for YP or your host, it is hard to meet the requirement.
I found the newest version of scancode-tk support running in docker. So I plan to make scancode-tk.bbclass work with scancode command by docker next.
Of course, if you have good ideas, please tell me, or contribute to meta-spdxscanner directlly.

By the way, why not try fossology? It is really good that you can browse the compliance information on fossology server after you get spdx files by bitbake of YP.

Best regards
Lei


-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Marco Cavallini
Sent: Monday, July 12, 2021 9:09 PM
To: yocto@lists.yoctoproject.org
Cc: Lei, Maohui <leimaohui@fujitsu.com>
Subject: [yocto] [meta-spdxscanner] Question about meta-spdxscanner

Hello,
I see that meta-spdxscanner has been moved to http://git.yoctoproject.org,
and doesn't maintained on github
anymore.https://github.com/dl9pf/meta-spdxscanner/issues/21

Therefore the only way to get in contact to developers is writing to this ML

I am trying to understand how meta-spdxscanner works.
I'd like to test it without any external service (no Fossology) therefore I am
trying the INHERIT += "scancode-tk" approach.

I am testing it with a dunfell version and I noticed a lot of errors so I switched to
master and the bitbake build started but again I am facing to a problem

ERROR: bash-completion-2.10-r0 do_get_report: Could not invoke scancode
Command

I'd like to have advice from you to understand if is it possible to test it without
any external service and discover what kind of artefacts are generated into
deploy/spdx.

Thank you

--
Marco


Per recipes simple smoke tests

Samuel Dolt
 

Hi everyone,

I was asked to add some basic tests to an internal recipe in order to improve our CI system.

The purpose would be to produce an error if some check doesn't pass like
- a file is not present
- the generated file is of size 0
- the generated file is bigger than x bytes

I'm thinking to add the functionality to a class, in order to be able to use these tests in more than one recipe. Something like that: https://gist.github.com/samdolt/cf1c557f73f4f2098a19ba7ad6bc092f

Does something like that already exists? And if not, would it be useful to have this contributed upstream? Maybe as an addition to insane.bbclass?

Cheers,
Samuel


Re: #yocto Preferred development workflow #yocto

Chuck Wolber
 

We have many recipes appended to IMAGE_INSTALL in our image recipes and it works just fine.

From your description, it sounds like you could go either way. I personally prefer to keep my image recipes as clean as possible, so I push as much as I can to individual recipes. This helps with debugging later on as your project (inevitably) gets more complex.

Also... Experience has shown that the following form is a lot more readable:

IMAGE_INSTALL  = "recipe_1"
IMAGE_INSTALL += "recipe_2"
IMAGE_INSTALL += "recipe_3"
IMAGE_INSTALL += "recipe_4"
IMAGE_INSTALL += "recipe_5"

Than this:

IMAGE_INSTALL = "\
         recipe_1 \
         recipe_2 \
         recipe_3 \
         recipe_4 \
         recipe_5"

When your repository grows large, a recursive grep for recipe_2 will make a lot more sense if "IMAGE_INSTALL += "recipe_2"" is returned instead of "recipe_2 \". The latter form gives no clue as to how recipe_2 is being referenced.


..Ch:W..


On Mon, Jul 12, 2021 at 9:36 PM ivin.lim via lists.yoctoproject.org <ivin.lim=aei.com@...> wrote:
sorry about that, right now the config files are placed in the files directory of the recipe which builds the module. 

Sample snippets of the recipe concerning this config file, I removed the rest of lines.
SRC_URI = " \
file://config.json \
    "

do_install_append() {
install -m 0644 ${WORKDIR}/config.json ${D}/etc/directory/
}


If I were to have the config files placed on a separate recipe, would that mean making multiple of these recipes depending on the number of projects? 
I did thought also of adding it in the image recipe but probably this wouldn't look well if more things get added.


Thanks






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


Re: #yocto Preferred development workflow #yocto

ivin.lim@...
 

sorry about that, right now the config files are placed in the files directory of the recipe which builds the module. 

Sample snippets of the recipe concerning this config file, I removed the rest of lines.
SRC_URI = " \
file://config.json \
    "

do_install_append() {
install -m 0644 ${WORKDIR}/config.json ${D}/etc/directory/
}


If I were to have the config files placed on a separate recipe, would that mean making multiple of these recipes depending on the number of projects? 
I did thought also of adding it in the image recipe but probably this wouldn't look well if more things get added.


Thanks


Re: #yocto Preferred development workflow #yocto

Chuck Wolber
 

You left a few details out about how the configuration files are managed. Ideally you could just make bitbake recipes for the config files themselves. This way you can create an image recipe for each project and use the IMAGE_INSTALL variable to append whatever configs and modules you want on a per-project basis.

..Ch:W..


On Mon, Jul 12, 2021 at 8:40 PM ivin.lim via lists.yoctoproject.org <ivin.lim=aei.com@...> wrote:
Hi everyone,

I'm curious on a good approach when dealing with multiple projects

I've just started out  yocto and have already  created our own meta-layer which contains our modules. Now these modules would sometimes have config files and this could vary when each project that we have would use these recipes. I'm thinking of a way to control this. And I don't think having one branch per project is a good style. Right now the best way I can think of is creating seperate "project layers" (ex. meta-project1, meta-project2) and from there create those .bbappends which would point to the project-specific conf files. 

But I was wondering if there is a better way of handling it. Thanks.

Cheers.




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


#yocto Preferred development workflow #yocto

ivin.lim@...
 

Hi everyone,

I'm curious on a good approach when dealing with multiple projects

I've just started out  yocto and have already  created our own meta-layer which contains our modules. Now these modules would sometimes have config files and this could vary when each project that we have would use these recipes. I'm thinking of a way to control this. And I don't think having one branch per project is a good style. Right now the best way I can think of is creating seperate "project layers" (ex. meta-project1, meta-project2) and from there create those .bbappends which would point to the project-specific conf files. 

But I was wondering if there is a better way of handling it. Thanks.

Cheers.


Re: [layerindex-web][PATCH] models.py: extend max_length of name in YPCompatibleVersions to 100

Changqing Li
 

add Paul Eggleton

On 7/13/21 10:44 AM, Changqing Li wrote:
From: Changqing Li <changqing.li@...>

Now, YPCompatibleVersions's name is only designed for using version like
2.0 3.0, the max_length is 25. but we mostly use Codename for layer
compatibility, eg: LAYERSERIES_COMPAT_dpdk = "dunfell gatesgarth
hardknott", in this case, it's not enough to save the compatible
version. so extend it to 100.

Signed-off-by: Changqing Li <changqing.li@...>
---
 .../migrations/0045_yp_compatible_extend.py   | 24 +++++++++++++++++++
 layerindex/models.py                          |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 layerindex/migrations/0045_yp_compatible_extend.py

diff --git a/layerindex/migrations/0045_yp_compatible_extend.py b/layerindex/migrations/0045_yp_compatible_extend.py
new file mode 100644
index 0000000..3544b4b
--- /dev/null
+++ b/layerindex/migrations/0045_yp_compatible_extend.py
@@ -0,0 +1,24 @@
+# Generated by Django 2.2 on 2021-07-13 02:43
+
+from django.db import migrations, models
+import django.db.models.deletion
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('layerindex', '0044_extendedprovides'),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name='classicrecipe',
+            name='cover_layerbranch',
+            field=models.ForeignKey(blank=True, limit_choices_to={'branch__name': 'master'}, null=True, on_delete=django.db.models.deletion.SET_NULL, to='layerindex.LayerBranch', verbose_name='Covering layer'),
+        ),
+        migrations.AlterField(
+            model_name='ypcompatibleversion',
+            name='name',
+            field=models.CharField(help_text='Name of this Yocto Project compatible version (e.g. "2.0")', max_length=100, unique=True, verbose_name='Yocto Project Version'),
+        ),
+    ]
diff --git a/layerindex/models.py b/layerindex/models.py
index 329cc33..2317740 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -217,7 +217,7 @@ class LayerRecipeExtraURL(models.Model):
 
 
 class YPCompatibleVersion(models.Model):
-    name = models.CharField('Yocto Project Version', max_length=25, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")')
+    name = models.CharField('Yocto Project Version', max_length=100, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")')
     description = models.TextField(blank=True)
     image_url = models.CharField('Image URL', max_length=300, blank=True)
     link_url = models.CharField('Link URL', max_length=100, blank=True)




[layerindex-web][PATCH] models.py: extend max_length of name in YPCompatibleVersions to 100

Changqing Li
 

From: Changqing Li <changqing.li@windriver.com>

Now, YPCompatibleVersions's name is only designed for using version like
2.0 3.0, the max_length is 25. but we mostly use Codename for layer
compatibility, eg: LAYERSERIES_COMPAT_dpdk = "dunfell gatesgarth
hardknott", in this case, it's not enough to save the compatible
version. so extend it to 100.

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
.../migrations/0045_yp_compatible_extend.py | 24 +++++++++++++++++++
layerindex/models.py | 2 +-
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 layerindex/migrations/0045_yp_compatible_extend.py

diff --git a/layerindex/migrations/0045_yp_compatible_extend.py b/layerindex/migrations/0045_yp_compatible_extend.py
new file mode 100644
index 0000000..3544b4b
--- /dev/null
+++ b/layerindex/migrations/0045_yp_compatible_extend.py
@@ -0,0 +1,24 @@
+# Generated by Django 2.2 on 2021-07-13 02:43
+
+from django.db import migrations, models
+import django.db.models.deletion
+
+
+class Migration(migrations.Migration):
+
+ dependencies = [
+ ('layerindex', '0044_extendedprovides'),
+ ]
+
+ operations = [
+ migrations.AlterField(
+ model_name='classicrecipe',
+ name='cover_layerbranch',
+ field=models.ForeignKey(blank=True, limit_choices_to={'branch__name': 'master'}, null=True, on_delete=django.db.models.deletion.SET_NULL, to='layerindex.LayerBranch', verbose_name='Covering layer'),
+ ),
+ migrations.AlterField(
+ model_name='ypcompatibleversion',
+ name='name',
+ field=models.CharField(help_text='Name of this Yocto Project compatible version (e.g. "2.0")', max_length=100, unique=True, verbose_name='Yocto Project Version'),
+ ),
+ ]
diff --git a/layerindex/models.py b/layerindex/models.py
index 329cc33..2317740 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -217,7 +217,7 @@ class LayerRecipeExtraURL(models.Model):


class YPCompatibleVersion(models.Model):
- name = models.CharField('Yocto Project Version', max_length=25, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")')
+ name = models.CharField('Yocto Project Version', max_length=100, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")')
description = models.TextField(blank=True)
image_url = models.CharField('Image URL', max_length=300, blank=True)
link_url = models.CharField('Link URL', max_length=100, blank=True)
--
2.17.1


wic automount of a data partition #zeus

Gary Huband
 

I'm using Zeus.  I'm trying to create and mount a data partition using wic.  My wks file is

part u-boot --source rawcopy --sourceparams="file=u-boot.imx" --ondisk mmc --no-table --align 1
part /boot --source bootimg-partition --ondisk mmc --fstype=vfat --label bootA --active --align 4096 --size 20
part / --source rootfs --ondisk mmc --fstype=ext4 --label rootfsA --align 4096 --size 4096
part /boot --source bootimg-partition --ondisk mmc --fstype=vfat --label bootB --size 20
part / --source rootfs --ondisk mmc --fstype=ext4 --label rootfsB --align 4096 --size 4096
part /data --ondisk mmc --fstype=ext4 --fsoptions="defaults" --label data --align 4096 --size 2048
part --ondisk mmc --fstype=ext4 --label recovery --align 4096 --size 1024

This creates the data on partition 6 but does not mount create the /data directory nor mount the partition.
If I manually create /data and manually modify the /etc/fstab file everything works.

Any suggestions for fixing the wks file?

Thanks

Gary


Re: [yocto-autobuilder-helper][PATCH] config.json: track system load with PARALLEL_MAKE

Trevor Gamblin
 


On 2021-07-12 12:04 p.m., Alexander Kanavin wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

I seem to vaguely remember that -l is not actually taking a percentage, but an absolute value that is specific to the amount of CPU cores a system has. Have you verified your assumption?
You are right that it's not actually a percentage and is instead tied to the number of cores. I'll correct the patch body to reflect this when I inevitably send a v2. With the latest testing on the AB, my suspicion that "-l 100" is too generous for most machines is being confirmed...

Alex

On Mon, 12 Jul 2021 at 14:11, Trevor Gamblin <trevor.gamblin@...> wrote:
This adds the "-l" option to PARALLEL_MAKE in config.json with an
initial testing value of 100 (100% system load). This option is supported
by both Make and Ninja. However, we also require the "--debug=j" option
to be passed to Make in order for the latter to report perceived system
load in the do_compile logs, and since this option is not supported by
Ninja, also add EXTRA_OEMAKE to the EXTRAVARS so that we can determine if
the target load percentage needs to be adjusted.

Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
---
 config.json | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index f54081b..7fc89ea 100644
--- a/config.json
+++ b/config.json
@@ -44,7 +44,7 @@
             "PREMIRRORS = ''",
             "BB_GENERATE_MIRROR_TARBALLS = '1'",
             "BB_NUMBER_THREADS = '16'",
-            "PARALLEL_MAKE = '-j 16'",
+            "PARALLEL_MAKE = '-j 16 -l 100'",
             "XZ_MEMLIMIT = '5%'",
             "XZ_THREADS = '8'",
             "BB_TASK_NICE_LEVEL = '5'",
@@ -61,7 +61,8 @@
             "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
             "BB_HEARTBEAT_EVENT = '60'",
             "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
-            "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh 100'"
+            "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh 100'",
+            "EXTRA_OEMAKE = ' --debug=j'"
         ]
     },
     "templates" : {
--
2.31.1





Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (7/13) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 9am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 

3061 - 3080 of 57143