Date   

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 395 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.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

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@...

 


OpenEmbedded Happy Hour October 27 9pm/2100 UTC

Denys Dmytriyenko
 

All,

Our next OpenEmbedded Happy Hour is on October 27 for Asia/Pacific timezones @
2100/9pm UTC (5pm ET / 2pm PT):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+October+27&iso=20211027T21

--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


[PATCH yocto-autobuilder-helper] auh: update the from address to valid domain

Michael Halstead
 

The auh.yoctoproject.org domain is no longer used and cannot be
validated.

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
scripts/auh-config/upgrade-helper.conf | 2 +-
scripts/setup-auh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
index 5284b4a..6255f3f 100644
--- a/scripts/auh-config/upgrade-helper.conf
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -11,7 +11,7 @@ blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-imag
# SMTP server
smtp=mail.yoctoproject.org:25
# from whom should the mails arrive
-from=auh@auh.yoctoproject.org
+from=auh@yoctoproject.org
# who should get the status mail with statistics, at the end
status_recipients=openembedded-core@lists.openembedded.org
# who should be CCd with upgrade emails
diff --git a/scripts/setup-auh b/scripts/setup-auh
index 23f3d44..5f49e38 100755
--- a/scripts/setup-auh
+++ b/scripts/setup-auh
@@ -14,7 +14,7 @@ pushd $1

git clone git://git.yoctoproject.org/poky
pushd poky
-git config user.email auh@auh.yoctoproject.org
+git config user.email auh@yoctoproject.org
git config user.name "Auto Upgrade Helper"
popd
git clone git://git.yoctoproject.org/auto-upgrade-helper
--
2.31.1


Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Khem Raj
 

On Mon, Oct 25, 2021 at 10:30 AM Steve Sakoman <steve@sakoman.com> wrote:

On Mon, Oct 25, 2021 at 7:00 AM Khem Raj <raj.khem@gmail.com> wrote:

On Mon, Oct 25, 2021 at 9:46 AM Steve Sakoman <steve@sakoman.com> wrote:

On Mon, Oct 25, 2021 at 6:09 AM Khem Raj <raj.khem@gmail.com> wrote:



On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on
builders, Additionally some packages like bison started to fail
intermittently which seemed like a parallel build issue but never got to
see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB
Which branch did you test this with? I had some issues when I
originally added it to dunfell but after the last patch series I am
getting green a-full and meta-oe builds on the autobuilder.
it was dunfell primarily
In that case you might want to try again with the current dunfell
head. It was a couple of weeks of pain, but I think I've eliminated
all of the issues with using this patch.
OK, I think it will be a while before I can get to tip if dunfell though.


Steve



And master has been running with this for q
Steve


"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",






Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Steve Sakoman
 

On Mon, Oct 25, 2021 at 7:00 AM Khem Raj <raj.khem@gmail.com> wrote:

On Mon, Oct 25, 2021 at 9:46 AM Steve Sakoman <steve@sakoman.com> wrote:

On Mon, Oct 25, 2021 at 6:09 AM Khem Raj <raj.khem@gmail.com> wrote:



On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on
builders, Additionally some packages like bison started to fail
intermittently which seemed like a parallel build issue but never got to
see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB
Which branch did you test this with? I had some issues when I
originally added it to dunfell but after the last patch series I am
getting green a-full and meta-oe builds on the autobuilder.
it was dunfell primarily
In that case you might want to try again with the current dunfell
head. It was a couple of weeks of pain, but I think I've eliminated
all of the issues with using this patch.

Steve



And master has been running with this for q
Steve


"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",






Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Khem Raj
 

On Mon, Oct 25, 2021 at 9:46 AM Steve Sakoman <steve@sakoman.com> wrote:

On Mon, Oct 25, 2021 at 6:09 AM Khem Raj <raj.khem@gmail.com> wrote:



On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on
builders, Additionally some packages like bison started to fail
intermittently which seemed like a parallel build issue but never got to
see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB
Which branch did you test this with? I had some issues when I
originally added it to dunfell but after the last patch series I am
getting green a-full and meta-oe builds on the autobuilder.
it was dunfell primarily


And master has been running with this for q
Steve


"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",






Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Steve Sakoman
 

On Mon, Oct 25, 2021 at 6:46 AM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Mon, Oct 25, 2021 at 6:09 AM Khem Raj <raj.khem@gmail.com> wrote:



On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on
builders, Additionally some packages like bison started to fail
intermittently which seemed like a parallel build issue but never got to
see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB
Which branch did you test this with? I had some issues when I
originally added it to dunfell but after the last patch series I am
getting green a-full and meta-oe builds on the autobuilder.

And master has been running with this for q
Accidentally hit send :-)

I intended to say that master has been running with this for quite
some time now.

Steve


"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",







Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Steve Sakoman
 

On Mon, Oct 25, 2021 at 6:09 AM Khem Raj <raj.khem@gmail.com> wrote:



On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on
builders, Additionally some packages like bison started to fail
intermittently which seemed like a parallel build issue but never got to
see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB
Which branch did you test this with? I had some issues when I
originally added it to dunfell but after the last patch series I am
getting green a-full and meta-oe builds on the autobuilder.

And master has been running with this for q
Steve


"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",






Re: [hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Khem Raj
 

On 10/25/21 7:07 AM, Anuj Mittal wrote:
From: Trevor Gamblin <trevor.gamblin@windriver.com>
Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.
Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.
Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
We have seen a lot of hung builds when we used this option internally on builders, Additionally some packages like bison started to fail intermittently which seemed like a parallel build issue but never got to see why it would happen only with -l enabled.

So this change would need some testing before we make it permanent into AB

"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",


Re: dunfell: pkgconfig-native build fails in existing Yocto BSP

Matthias Klein
 

Hello Richard,

Thanks for the quick help!

Best regards,
Matthias


[hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Anuj Mittal
 

From: Trevor Gamblin <trevor.gamblin@windriver.com>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
--
2.31.1


Re: How to iherit class based on a conditional variable? #sysvinit #systemd

Alexander Kanavin
 

It's fine to inherit both classes and install both files without even checking DISTRO_FEATURES. There's behind the scenes magic that will do the right thing depending on what init manager is chosen in the distro config.

Alex


On Mon, 25 Oct 2021 at 14:38, Bel Hadj Salem Talel <bhstalel@...> wrote:
Hello,

I have a recipe that installs a simple bash script to run on startup.
As you all know, there is systemd and sysvinit.
I need to add support for both init managers.

I can do :
SRC_URI_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://script.service', 'file://script.sh', d)}"

and I can do the same in all the tasks.

The problem is, that I need to inherit either systemd or update-rc.d

Is it possible to inherit them all, or how can I inherit something conditionally ?

Thanks,
Talel




Re: bbappend usage

Alexander Kanavin
 

There is no one-size-fits-all answer to this. It helps if you provide specifics: what components and what portions of them and why.

Alex


On Mon, 25 Oct 2021 at 15:26, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am looking to selectively remove portions of 1or 2 components I will not be using from my running image

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Leon Woestenberg
Sent: Monday, October 25, 2021 9:12 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] bbappend usage

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
>
>
>
> Hello:
>
>
>
> If I am building an image “image-ABC”, and it is composed of a number
> recipes, and for some of these recipes I may NOT want to install their
> final components within my image…
>
>
>
> Which is the best place to modify the build with bbappend ?
>
>
>
> Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?
>
>
>
> Looking for the proper Yocto way…
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
>




Re: bbappend usage

Monsees, Steven C (US)
 

I am looking to selectively remove portions of 1or 2 components I will not be using from my running image

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Leon Woestenberg
Sent: Monday, October 25, 2021 9:12 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] bbappend usage

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



Hello:



If I am building an image “image-ABC”, and it is composed of a number
recipes, and for some of these recipes I may NOT want to install their
final components within my image…



Which is the best place to modify the build with bbappend ?



Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?



Looking for the proper Yocto way…



Thanks,

Steve








Re: bbappend usage

Monsees, Steven C (US)
 

No, you got it wromg... I have a buildable image which has all the components necessary, I want to remove some overhead installed by some components that I will not be within my running application...

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Robert P. J. Day
Sent: Monday, October 25, 2021 9:10 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] bbappend usage

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

If I am building an image “image-ABC”, and it is composed of a number
recipes, and for some of these recipes I may NOT want to install their
final components within my image…

Which is the best place to modify the build with bbappend ?

Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?,
or would I modify the image recipe (do_install_append-image_ABC) I am
leaning this way to avoid cases where the component recipes might have
bbappends in place already ?
i would think start with defining a minimal image, then define other images based on that one which add more recipes. this has nothing to do with redefining the recipes, it just means defining more than one image.

rday


Re: bbappend usage

Konrad Weihmann <kweihmann@...>
 

The super yoctoish way would be to alter the packaging of the recipe to your needs.

Let's assume recipe-a consists of the files

foo
bar

and it would package both files into recipe-a pkg.

In the actual image you only install packages into a file system, so if you don't want bar to be installed into your final image, it'd be best to package bar into a separate package.

PACKAGES_BEFORE_PN = "${PN}-bar"
FILES:${PN}-bar = "bar"

in this case the recipe would produce

recipe-a (containing just foo)
recipe-a-bar (containing just bar)

You could install now (via IMAGE_INSTALL in your image recipe) just add recipe-a and only foo would be put into the final image.

While a potential other image (IMAGE_INSTALL += "recipe-a-bar recipe-a")
would contain both.

But if you'd go down that road you have to make sure that runtime dependencies between the packages are met (using REDEPENDS:* statements), as otherwise it could turn into very hard to debug issues.
So I would propose to **not** do that via bbappends, but forks of the recipes you want to repackage.

Another option (as likely mentioned already) is to use

rem_stuff() {
rm ${IMAGE_ROOTFS}/<file you want to delete>
}

ROOTFS_POSTPROCESS_COMMAND += "rem_stuff;"

in your image recipe

On 25.10.21 14:55, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Hello:
If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…
Which is the best place to modify the build with bbappend ?
Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?
Looking for the proper Yocto way…
Thanks,
Steve


Re: bbappend usage

Leon Woestenberg
 

Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not
want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:




Hello:



If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…



Which is the best place to modify the build with bbappend ?



Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?



Looking for the proper Yocto way…



Thanks,

Steve








Re: bbappend usage

Robert P. J. Day
 

On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

If I am building an image “image-ABC”, and it is composed of a
number recipes, and for some of these recipes I may NOT want to
install their final components within my image…

Which is the best place to modify the build with bbappend ?

Would I modify a recipe’s do_install (do_install_append-recipe_xyz)
?, or would I modify the image recipe (do_install_append-image_ABC)
I am leaning this way to avoid cases where the component recipes
might have bbappends in place already ?
i would think start with defining a minimal image, then define other
images based on that one which add more recipes. this has nothing to
do with redefining the recipes, it just means defining more than one
image.

rday


bbappend usage

Monsees, Steven C (US)
 

 

Hello:

 

If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…

 

Which is the best place to modify the build with bbappend ?

 

Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?

 

Looking for the proper Yocto way…

 

Thanks,

Steve

 

 


How to iherit class based on a conditional variable? #sysvinit #systemd

Bel Hadj Salem Talel <bhstalel@...>
 

Hello,

I have a recipe that installs a simple bash script to run on startup.
As you all know, there is systemd and sysvinit.
I need to add support for both init managers.

I can do :
SRC_URI_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://script.service', 'file://script.sh', d)}"

and I can do the same in all the tasks.

The problem is, that I need to inherit either systemd or update-rc.d

Is it possible to inherit them all, or how can I inherit something conditionally ?

Thanks,
Talel

1981 - 2000 of 57098