1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Yocto Project Status WW47'20

Stephen Jolley
 

Current Dev Position: YP 3.3 M1 development

Next Deadline: 7th December 2020 YP 3.3 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.1.4 will build later this week.
  • YP 3.3 development in master is continuing as patches are reviewed, tested and merged.
  • We plan to backport the sphinx documentation transition back to our LTS after 3.1.4 is built.
  • A small but important issue was identified related to build reproducibility where the host umask was influencing the build output in relatively minor ways. We plan to run a mixture of umasks on the autobuilder infrastructure in future to avoid this source of reproducibility issues. There are patches for the issues queued for master and will be backported in due course.
  • Support for fedora33 has been resolved but required making pseudo-native host specific and not ‘uninative’ due to differences in the way pseudo builds depending on the presence of headers.
  • Hashserve “passthrough” support has merged allowing hashservers to be chained together, thanks Joshua.
  • Intermittent autobuilder issues continue to occur. 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
  • Further autobuilder improvements have been submitted and accepted into upstream buildbot (field history, triggered build summary stats and work name display in build summary). As these are released and deployed, they will make small but important improvements to the autobuilder usability.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M1 build date 2020/12/07
  • YP 3.3 M1 Release date 2020/12/18
  • YP 3.3 M2 build date 2021/01/18
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13
  • YP 3.2.1 build date 2020/11/16
  • YP 3.2.1 release date 2020/12/4
  • YP 3.1.5 build date 2021/01/11
  • YP 3.1.5 release date 2021/01/22
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

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

 
Re: How to add python application into the build. #python #toolchain

Nicolas Jeker
 

On Tue, 2020-11-24 at 04:33 -0800, vijayrakeshmunganda@... wrote:
Hi,
Hi Vijay

I'm new to the Yocto Project, trying to include my python application
into the build. Can anyone guide me how to write a bitbake recipe .bb
file or any example recipe would be helpful.
Reading and following the section about "Writing a New Recipe" in the
manual is probably a good starting point:

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe

I usually look at related recipes that already exist (in your case some
other python recipe) and try to start with a minimal recipe and fix
build errors/missing dependencies/etc. iteratively.

Thank & Regards,
Vijay.
How to add python application into the build. #python #toolchain

Vijay Rakesh Munganda
 

Hi,

I'm new to the Yocto Project, trying to include my python application into the build. Can anyone guide me how to write a bitbake recipe .bb file or any example recipe would be helpful.

Thank & Regards,
Vijay.
Re: Yocto Project Outreachy interns

Dorinda
 

Thank you all,
I appreciate the opportunity given to me to intern with the Yocto Project. I am excited about this internship and I look forward to working with you on my project.

Sincerely,
Dorinda.

On Nov 24, 2020 08:47, "Nicolas Dechesne" <nicolas.dechesne@...> wrote:
Dear all,

We are very excited to be part of the Outreachy program again for the
December round this year, let me congratulate Ida and Dorinda for
being accepted as interns for the next three months.

I want to give a warm thank you to our mentors as well, Paul, Ross,
Tim. Without mentors there isn't much we can do, so this is very much
appreciated. A big thank you to Microsoft and Arm who are sponsoring
the internships.

Ida and Dorinda will engage on the following topics:

== Enhance Yocto Project License Tracing
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. Along with the
image, a manifest of packages and their corresponding licenses is
prepared, however the accuracy of the license information in the
manifest is dependent on the accuracy of the metadata we have for each
package (i.e. what is in the recipe file). As part of the build, we
have an internal mapping from output files to source files which is
currently used to prepare source packages to aid in debugging, however
with the increasing presence of SPDX headers in source files it could
also be used to allow tracing the license of sources used in building
a package/image to help improve our metadata and future license
manifests.

== Add support for elfutils debug info server"
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. debuginfod (part
of elfutils 0.178 onwards) is a way to share debuginfo files, which
provide debugging symbols for gdb to enable it to debug a running
program on a target device. Users of the Yocto Project would benefit
from integrating support for debuginfod such that binaries in an image
produced by the Yocto Project build system could be debugged more
easily.

Ida and Dorinda, welcome into our open source community, you can count
on everyone's support during your internship!

cheers
nico
Re: Python function caching question

Quentin Schulz
 

Hi Michael,

On Mon, Nov 23, 2020 at 04:49:30PM -0700, Michael Callahan wrote:
I do not want do_compile to run again, it rebuilds the whole image.
What is the best way to always run find_version?
Use an anonymous python function that sets VERSION, e.g.:

python __anonymous() {
d.setVar('VERSION', find_version(d))
}

as anonymous python functions are always executed during parsing.

Then add the following to your recipe:
do_compile[vardepsexclude] += "VERSION"

VERSION will always be set appropriately every time the recipe is parsed
but do_compile will only be rerun when a change in the task has occurred
to the exception of the VERSION variable.

No idea if that works as I don't use those, but that's an hint. Anyway, you
probably want a behavior similar to DATETIME's.

Cheers,
Quentin

On Sun, Nov 22, 2020 at 7:53 PM Khem Raj <raj.khem@...> wrote:

On Sun, Nov 22, 2020 at 6:17 PM Michael Callahan
<coder.callahan@...> wrote:

I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where I
am setting a variable from a computed python function. What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION
perhaps mark the task which is using this variable as nostamp.





--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@..., www.streamunlimited.com
Re: Yocto Project Outreachy interns

Meh Mbeh Ida Delphine <idadelm@...>
 

Thank you all so much for having us. I learned so much about embedded linux and the Yocto Project in a very short while. I can't wait to start working with you and on my project.


Cheers,
Ida.

On Tue, 24 Nov 2020, 8:47 am Nicolas Dechesne, <nicolas.dechesne@...> wrote:
Dear all,

We are very excited to be part of the Outreachy program again for the
December round this year, let me congratulate Ida and Dorinda for
being accepted as interns for the next three months.

I want to give a warm thank you to our mentors as well, Paul, Ross,
Tim. Without mentors there isn't much we can do, so this is very much
appreciated. A big thank you to Microsoft and Arm who are sponsoring
the internships.

Ida and Dorinda will engage on the following topics:

== Enhance Yocto Project License Tracing
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. Along with the
image, a manifest of packages and their corresponding licenses is
prepared, however the accuracy of the license information in the
manifest is dependent on the accuracy of the metadata we have for each
package (i.e. what is in the recipe file). As part of the build, we
have an internal mapping from output files to source files which is
currently used to prepare source packages to aid in debugging, however
with the increasing presence of SPDX headers in source files it could
also be used to allow tracing the license of sources used in building
a package/image to help improve our metadata and future license
manifests.

== Add support for elfutils debug info server"
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. debuginfod (part
of elfutils 0.178 onwards) is a way to share debuginfo files, which
provide debugging symbols for gdb to enable it to debug a running
program on a target device. Users of the Yocto Project would benefit
from integrating support for debuginfod such that binaries in an image
produced by the Yocto Project build system could be debugged more
easily.

Ida and Dorinda, welcome into our open source community, you can count
on everyone's support during your internship!

cheers
nico
Re: Disable systemd-timesyncd.service in image

Damien LEFEVRE
 

Yes SYSTEMD_AUTO_ENABLE_${PN} doesn't apply to systemd recipe core services as they are not installed as separate packages.

But I got it working now.

The default enable/disable service are defined in https://github.com/systemd/systemd/blob/master/presets/90-systemd.preset

So 
do_configure_append() {
    sed -i -e "s/enable systemd-timesyncd.service/disable systemd-timesyncd.service/g" ${S}/presets/90-systemd.preset
}

does the trick

Cheers,
-Damien

On Mon, Nov 23, 2020 at 10:42 PM Konrad Weihmann <kweihmann@...> wrote:
The service is deployed with standard systemd package, which doesn't
have that set as far as I see it (no SYSTEMD_AUTO_ENABLE_${PN} in the
latest recipe revision)

I think, after browsing through the code of systemd - this "autostart"
behavior comes from [1].
So I would say you can disable it with a drop-in file at
/etc/systemd/system/systemd-timesyncd.service.d/disable.conf
[Install]
WantedBy=

which also would be charming in a way that it isn't that invasive in the
build system

[1]
https://github.com/systemd/systemd/blob/5b639090d0b4a49d77ba58bebe180b2a6f8da322/units/systemd-timesyncd.service.in#L55

haven't tested it though, but you might wanna give that a shot, if
Aaron's approach doesn't work.

On 23.11.20 21:21, Joel A Cohen wrote:
> I think you need to set SYSTEMD_AUTO_ENABLE = “disable” (actually any
> value other than “enable”) in your bbappend.
>
> (It looks like SYSTEMD_AUTO_ENABLE_${PN} is intended to work too, but I
> can’t verify it at the moment and reading over systemd.bbclass I’m not
> sure if it works or not)
>
> —Aaron
>
> On Mon, Nov 23, 2020 at 11:51 AM Damien LEFEVRE <lefevre.da@...
> <mailto:lefevre.da@...>> wrote:
>
>     Hi,
>
>     I would like to have systemd-timesyncd.service as part of an image
>     but have it disabled by default.
>
>     Right now it is enabled by default which causes some issues.
>
>     I've tried systemd_%.bbappend
>
>     do_install_append() {
>          rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
>          rm
>     "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
>     }
>
>     but those symlinks are not part of the package.
>
>     I've tried this to remove the link during the package deployment
>     during do_rootfs
>     pkg_postinst_${PN}_append() {
>          #!/bin/sh -e
>          rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
>          rm
>     "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
>     }
>
>     But at this stage the links still don't exist.
>
>     Which package is actually responsible for enabling the default
>     services / creating the symlinks? How can we turn some of them off
>     while keeping them in the image?
>
>     Thanks,
>     -Damien
>
>
>
>
>
>
>

Yocto Project Outreachy interns

Nicolas Dechesne
 

Dear all,

We are very excited to be part of the Outreachy program again for the
December round this year, let me congratulate Ida and Dorinda for
being accepted as interns for the next three months.

I want to give a warm thank you to our mentors as well, Paul, Ross,
Tim. Without mentors there isn't much we can do, so this is very much
appreciated. A big thank you to Microsoft and Arm who are sponsoring
the internships.

Ida and Dorinda will engage on the following topics:

== Enhance Yocto Project License Tracing
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. Along with the
image, a manifest of packages and their corresponding licenses is
prepared, however the accuracy of the license information in the
manifest is dependent on the accuracy of the metadata we have for each
package (i.e. what is in the recipe file). As part of the build, we
have an internal mapping from output files to source files which is
currently used to prepare source packages to aid in debugging, however
with the increasing presence of SPDX headers in source files it could
also be used to allow tracing the license of sources used in building
a package/image to help improve our metadata and future license
manifests.

== Add support for elfutils debug info server"
The Yocto Project build system is typically used to build customised
Linux images from source for embedded applications. debuginfod (part
of elfutils 0.178 onwards) is a way to share debuginfo files, which
provide debugging symbols for gdb to enable it to debug a running
program on a target device. Users of the Yocto Project would benefit
from integrating support for debuginfod such that binaries in an image
produced by the Yocto Project build system could be debugged more
easily.

Ida and Dorinda, welcome into our open source community, you can count
on everyone's support during your internship!

cheers
nico
Re: Python function caching question

Richard Purdie
 

On Sun, 2020-11-22 at 19:16 -0700, Michael Callahan wrote:
I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where
I
am setting a variable from a computed python function. What's the
magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION
If you set BB_DONT_CACHE = "1" in the recipe, it will force the recipe
to reparse each time. That should cause it to rerun find_version and
then change hash when the value changes. Its how SRCREV = "${AUTOREV}"
works behind the scenes.

Cheers,

Richard
Re: Python function caching question

Michael Callahan <coder.callahan@...>
 

I do not want do_compile to run again, it rebuilds the whole image.
What is the best way to always run find_version?

On Sun, Nov 22, 2020 at 7:53 PM Khem Raj <raj.khem@...> wrote:

On Sun, Nov 22, 2020 at 6:17 PM Michael Callahan
<coder.callahan@...> wrote:

I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where I
am setting a variable from a computed python function. What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION
perhaps mark the task which is using this variable as nostamp.
Re: OE/YP equivalent to 'mtree'?

Randy MacLeod
 

On 2020-11-23 2:26 p.m., Robert P. J. Day wrote:
  colleague wants to know if there is something available
in an OE/YP layer equivalent to mtree:
  https://linux.die.net/man/8/mtree
i'm looking at a few possibilities right now but nothing
seems really equivalent. thoughts?
It don't see anything in the layer index:
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=mtree

but the source has a configure file:
(Ubuntu: apt-get source mtree-netbsd)
so they should write a recipe and send it to meta-oe.

../Randy

rday

--
# Randy MacLeod
# Wind River Linux
Re: Disable systemd-timesyncd.service in image

Konrad Weihmann <kweihmann@...>
 

The service is deployed with standard systemd package, which doesn't have that set as far as I see it (no SYSTEMD_AUTO_ENABLE_${PN} in the latest recipe revision)

I think, after browsing through the code of systemd - this "autostart" behavior comes from [1].
So I would say you can disable it with a drop-in file at
/etc/systemd/system/systemd-timesyncd.service.d/disable.conf
[Install]
WantedBy=

which also would be charming in a way that it isn't that invasive in the build system

[1] https://github.com/systemd/systemd/blob/5b639090d0b4a49d77ba58bebe180b2a6f8da322/units/systemd-timesyncd.service.in#L55

haven't tested it though, but you might wanna give that a shot, if Aaron's approach doesn't work.

On 23.11.20 21:21, Joel A Cohen wrote:
I think you need to set SYSTEMD_AUTO_ENABLE = “disable” (actually any value other than “enable”) in your bbappend.
(It looks like SYSTEMD_AUTO_ENABLE_${PN} is intended to work too, but I can’t verify it at the moment and reading over systemd.bbclass I’m not sure if it works or not)
—Aaron
On Mon, Nov 23, 2020 at 11:51 AM Damien LEFEVRE <lefevre.da@... <mailto:lefevre.da@...>> wrote:
Hi,
I would like to have systemd-timesyncd.service as part of an image
but have it disabled by default.
Right now it is enabled by default which causes some issues.
I've tried systemd_%.bbappend
do_install_append() {
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm
"$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}
but those symlinks are not part of the package.
I've tried this to remove the link during the package deployment
during do_rootfs
pkg_postinst_${PN}_append() {
    #!/bin/sh -e
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm
"$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}
But at this stage the links still don't exist.
Which package is actually responsible for enabling the default
services / creating the symlinks? How can we turn some of them off
while keeping them in the image?
Thanks,
-Damien
Re: Disable systemd-timesyncd.service in image

Joel A Cohen
 

I think you need to set SYSTEMD_AUTO_ENABLE = “disable” (actually any value other than “enable”) in your bbappend.

(It looks like SYSTEMD_AUTO_ENABLE_${PN} is intended to work too, but I can’t verify it at the moment and reading over systemd.bbclass I’m not sure if it works or not)

—Aaron

On Mon, Nov 23, 2020 at 11:51 AM Damien LEFEVRE <lefevre.da@...> wrote:
Hi,

I would like to have systemd-timesyncd.service as part of an image but have it disabled by default.

Right now it is enabled by default which causes some issues.

I've tried systemd_%.bbappend

do_install_append() { 
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}

but those symlinks are not part of the package.

I've tried this to remove the link during the package deployment during do_rootfs
pkg_postinst_${PN}_append() {
    #!/bin/sh -e
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}

But at this stage the links still don't exist.

Which package is actually responsible for enabling the default services / creating the symlinks? How can we turn some of them off while keeping them in the image?

Thanks,
-Damien
Disable systemd-timesyncd.service in image

Damien LEFEVRE
 

Hi,

I would like to have systemd-timesyncd.service as part of an image but have it disabled by default.

Right now it is enabled by default which causes some issues.

I've tried systemd_%.bbappend

do_install_append() { 
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}

but those symlinks are not part of the package.

I've tried this to remove the link during the package deployment during do_rootfs
pkg_postinst_${PN}_append() {
    #!/bin/sh -e
    rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
    rm "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}

But at this stage the links still don't exist.

Which package is actually responsible for enabling the default services / creating the symlinks? How can we turn some of them off while keeping them in the image?

Thanks,
-Damien
OE/YP equivalent to 'mtree'?

Robert P. J. Day
 

colleague wants to know if there is something available
in an OE/YP layer equivalent to mtree:

https://linux.die.net/man/8/mtree

i'm looking at a few possibilities right now but nothing
seems really equivalent. thoughts?

rday
Re: strange meta-security bbappend file with two percent signs

Armin Kuster
 

On 11/21/20 1:56 PM, Robert P. J. Day wrote:
while the bitbake user manual insists:

"The use of the ” % ” character is limited in that it only works
directly in front of the .bbappend portion of the append file’s name.
You cannot use the wildcard character in any other location of the
name."

i just ran across this in the meta-security layer:

recipes-kernel/linux/linux-%_5.%.bbappend

what is one supposed to make of that?
please send a patch to make to correct the situation.

-armin



rday
Re: Hardware video decode on RPi3

Rudolf J Streif
 

Thanks, Khem.

On 11/22/20 11:15 PM, Khem Raj wrote:
On Thu, Nov 19, 2020 at 7:38 PM Rudolf J Streif
<rudolf.streif@...> wrote:
I am trying to play back mp4 video (venerable Big Buck Bunny at this
time) on RPi3.

I added gstreamer1.0, gstreamer1.0-omx and the plugins to the image.

libgstomx.so is installed in usr/lib/gstreamer-1.0 on target.

However, gst-inspect-1.0 | grep omx does not return any results.

Consequently,

gst-launch-1.0 filesrc
location="/home/root/kiosk/kiosk/videos/bunny.mp4" ! qtdemux ! h264parse
! omxh264dec ! kmssink
WARNING: erroneous pipeline: no element "omxh264dec"

I guess I am missing something somewhere but I don't know what.
are you using userland for graphics or vc4 ?
Yes, I am. I actually discovered what the problem was: I built my system for 64-bit but Broadcom's proprietary libraries are 32-bit. I switched the system to 32-bit and now gst-inspect shows omx support.

Unfortunately, decoding is still not working. This works:

gst-launch-1.0  -v videotestsrc ! omxh264enc ! h264parse ! avdec_h264 ! autovideosink

However, this does not:

gst-launch-1.0  -v videotestsrc ! omxh264enc ! h264parse ! omxh264dec ! autovideosink

I also tried with kmssink with the same results.

I am using EGLFS backend. It appears to me that there is something off with the omxh264dec decoder plugin passing the decoded buffers on to the output sink. Unfortunately, I have not been able to figure out what that could be.

Ultimately, this would go into a Qt application. I have never had any issues with EGLFS and Qt hence I would be reluctant to switch the backend to Wayland/Weston or X11. But of course I also don't know if omxh264dec would work with either one of those backends.

Thanks,
Rudi


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

?
OpenPGP_0x8D8CA82927339B75.asc
?
OpenPGP_signature

Re: Packagegroup Understanding

Charlie Davies
 

Ok - I understand now.

Thanks for the explanation.

Charlie
Re: Packagegroup Understanding

Nicolas Dechesne
 

On Mon, Nov 23, 2020 at 11:51 AM Charlie Davies
<charles.davies@...> wrote:

Hi All,

I am seeing some behaviour when creating my own packagegroups which I do not quite understand.

Using the example from the mega-manual:

DESCRIPTION = "My Custom Package Groups"

inherit packagegroup

PACKAGES = "\
packagegroup-custom-apps \
packagegroup-custom-tools \
"

RDEPENDS_packagegroup-custom-apps = "\
dropbear \
portmap \
psplash"

RDEPENDS_packagegroup-custom-tools = "\
oprofile \
oprofileui-server \
lttng-control \
lttng-viewer"

If I then include packagegroup-custom-apps in my image I am also seeing the packages in packagegroup-custom-tools being built (but not included in the image) while building my image.

Is this behaviour correct? I would not expect the packages in packagegroup-custom-tools to be built if the packagegroup-custom-tools is not included in the image.
This is correct. When at least one (binary) package is needed from a
recipe, then the recipe is built, and all the resulting packages are
built.
So when you include packagegroup-custom-apps in your image, you
request the whole packagegroup recipe to be built, which in turn will
build all binary packages (hence all packagegroups and their
dependencies).


Many Thanks,

Charlie
Packagegroup Understanding

Charlie Davies
 

Hi All,

I am seeing some behaviour when creating my own packagegroups which I do not quite understand.

Using the example from the mega-manual:

DESCRIPTION = "My Custom Package Groups"
 
      inherit packagegroup
 
      PACKAGES = "\
          packagegroup-custom-apps \
          packagegroup-custom-tools \
          "
 
      RDEPENDS_packagegroup-custom-apps = "\
          dropbear \
          portmap \
          psplash"
 
      RDEPENDS_packagegroup-custom-tools = "\
          oprofile \
          oprofileui-server \
          lttng-control \
          lttng-viewer"

If I then include packagegroup-custom-apps in my image I am also seeing the packages in packagegroup-custom-tools being built (but not included in the image) while building my image.

Is this behaviour correct? I would not expect the packages in packagegroup-custom-tools to be built if the packagegroup-custom-tools is not included in the image.

Many Thanks,

Charlie
6221 - 6240 of 57741