Date   

[meta-rockchip][PATCH] rockchip-defaults: remove xf86-input-keyboard

Trevor Woerner
 

xf86-input-keyboard was removed from openembedded-core at its commit:
f1d7c33b64 (xf86-input-keyboard: remove the recipe, 2022-07-20). Therefore
remove it from the XSERVER definition.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index ca94249..3ce2e24 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -15,7 +15,6 @@ XSERVER = " \
xf86-video-modesetting \
xf86-input-evdev \
xf86-input-mouse \
- xf86-input-keyboard \
"

# misc
--
2.36.0.rc2.17.g4027e30c53


Re: [yocto-autobuilder-helper][langdale] config.json: don't run the meta-agl-core test

Steve Sakoman
 

On Fri, Nov 18, 2022 at 5:08 AM Alexander Kanavin
<alex.kanavin@...> wrote:

Does this mean that master should be excluded too?
No, master is supported.

Steve

On Fri, 18 Nov 2022 at 15:28, Steve Sakoman <steve@...> wrote:

langdale isn't currently supported on any branch of meta-agl

Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 17 -----------------
1 file changed, 17 deletions(-)

diff --git a/config.json b/config.json
index da87a2d..27283c9 100644
--- a/config.json
+++ b/config.json
@@ -403,23 +403,6 @@
"SANITYTARGETS" : "core-image-sato:do_testsdk"
}
},
- "meta-agl-core" : {
- "NEEDREPOS" : ["poky", "meta-agl"],
- "ADDLAYER" : [
- "${BUILDDIR}/../meta-agl/meta-agl-core"
- ],
- "DISTRO" : "poky-agl",
- "BUILDINFO" : true,
- "BUILDHISTORY" : true,
- "PACKAGE_CLASSES" : "package_rpm",
- "extravars" : [
- "AGL_FEATURES = 'aglcore'"
- ],
- "step1" : {
- "MACHINE": "qemux86-64",
- "BBTARGETS": "agl-image-core-autobuilder"
- }
- },
"meta-aws" : {
"NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
"ADDLAYER" : [
--
2.25.1




Re: [yocto-autobuilder-helper][langdale] config.json: don't run the meta-agl-core test

Alexander Kanavin
 

Does this mean that master should be excluded too?

Alex

On Fri, 18 Nov 2022 at 15:28, Steve Sakoman <steve@...> wrote:

langdale isn't currently supported on any branch of meta-agl

Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 17 -----------------
1 file changed, 17 deletions(-)

diff --git a/config.json b/config.json
index da87a2d..27283c9 100644
--- a/config.json
+++ b/config.json
@@ -403,23 +403,6 @@
"SANITYTARGETS" : "core-image-sato:do_testsdk"
}
},
- "meta-agl-core" : {
- "NEEDREPOS" : ["poky", "meta-agl"],
- "ADDLAYER" : [
- "${BUILDDIR}/../meta-agl/meta-agl-core"
- ],
- "DISTRO" : "poky-agl",
- "BUILDINFO" : true,
- "BUILDHISTORY" : true,
- "PACKAGE_CLASSES" : "package_rpm",
- "extravars" : [
- "AGL_FEATURES = 'aglcore'"
- ],
- "step1" : {
- "MACHINE": "qemux86-64",
- "BBTARGETS": "agl-image-core-autobuilder"
- }
- },
"meta-aws" : {
"NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
"ADDLAYER" : [
--
2.25.1




[yocto-autobuilder-helper][langdale] config.json: don't run the meta-agl-core test

Steve Sakoman
 

langdale isn't currently supported on any branch of meta-agl

Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 17 -----------------
1 file changed, 17 deletions(-)

diff --git a/config.json b/config.json
index da87a2d..27283c9 100644
--- a/config.json
+++ b/config.json
@@ -403,23 +403,6 @@
"SANITYTARGETS" : "core-image-sato:do_testsdk"
}
},
- "meta-agl-core" : {
- "NEEDREPOS" : ["poky", "meta-agl"],
- "ADDLAYER" : [
- "${BUILDDIR}/../meta-agl/meta-agl-core"
- ],
- "DISTRO" : "poky-agl",
- "BUILDINFO" : true,
- "BUILDHISTORY" : true,
- "PACKAGE_CLASSES" : "package_rpm",
- "extravars" : [
- "AGL_FEATURES = 'aglcore'"
- ],
- "step1" : {
- "MACHINE": "qemux86-64",
- "BBTARGETS": "agl-image-core-autobuilder"
- }
- },
"meta-aws" : {
"NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
"ADDLAYER" : [
--
2.25.1


Re: source-less python

Josef Holzmayr
 

It can always be added if is is found useful and robust. We tend to be careful about taking things into core layers as long as those two concerns, plus the maintenance commitment are not clear. Technical debt is a real problem.


On Thu, Nov 17, 2022 at 2:05 PM Yishai Jaffe <yishai1999@...> wrote:
Seems like a shame not to add this feature for everyone to use... 

Yishai Jaffe

On Thu, Nov 17, 2022, 2:34 PM Alexander Kanavin <alex.kanavin@...> wrote:
 Making your own! You can have it added to the layer index for better publicity.

Alex

On Thu, 17 Nov 2022 at 13:27, Yishai Jaffe <yishai1999@...> wrote:
>
> What layer would you suggest?
>
> Yishai Jaffe
>
> On Thu, Nov 17, 2022, 2:21 PM Alexander Kanavin <alex.kanavin@...> wrote:
>>
>> You can start by placing it in a separate layer?
>>
>> Alex
>>
>> On Thu, 17 Nov 2022 at 13:04, Yishai Jaffe <yishai1999@...> wrote:
>> >
>> > I assume by core you mean openembedded-core/poky, yes?
>> >
>> > So where would you add it to?
>> >
>> > Seems to me like a very useful feature that many people would use if they knew the option exists.
>> >
>> > Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?
>> >
>> > Yishai Jaffe
>> >
>> > On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:
>> >>
>> >> I just wonder if this should really be in core. The standards for core
>> >> are high: it needs to be both testable and tested, and there's only so
>> >> many possible options and tweaks where things can regress that we can
>> >> take. On the other hand, there has not been much demand for it.
>> >>
>> >> Alex
>> >>
>> >> On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:
>> >> >
>> >> > Hi Alexander,
>> >> >
>> >> > After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:
>> >> >
>> >> > Normal compilation:
>> >> > tar.bz2 - 6.6MB
>> >> > squashfs-xz - 6.1MB
>> >> >
>> >> > With my pyc-only patch:
>> >> > tar.bz2 - 5.8MB
>> >> > squashfs-xz - 5.2MB
>> >> >
>> >> > So that's about a 15% decrease in size.
>> >> > Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.
>> >> >
>> >> >
>> >> > Yishai Jaffe
>> >> >
>> >> >
>> >> > On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:
>> >> >>
>> >> >> Generally we slim down python installations by not installing all of
>> >> >> the standard library, and rather having precise dependencies for
>> >> >> specific modules. Can you illustrate the kind of space savings that
>> >> >> can be gained in actual numbers?
>> >> >>
>> >> >> Another issue is that this should be supported upstream and in the
>> >> >> wider python community. Is it?
>> >> >>
>> >> >> Alex
>> >> >>
>> >> >> On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:
>> >> >> >
>> >> >> >
>> >> >> > Hello,
>> >> >> > Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)
>> >> >> >
>> >> >> > These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Federico
>> >> >> >
>> >> >> > Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
>> >> >> >> I know that in buildroot it is supported.
>> >> >> >> Was this discussed and decided against? Is this an open issue?
>> >> >> >> I have a working patch that implements this. I can submit it for review.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Yishai Jaffe
>> >> >> >> Yishai Jaffe
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >




Re: Image dependent variables/files in included recipes

Josef Holzmayr
 

For the record - Yocto chant #1:

Recipe data is local - configuration data is global.

On Thu, Nov 17, 2022 at 4:30 PM Quentin Schulz via lists.yoctoproject.org <quentin.schulz=theobroma-systems.com@...> wrote:

Hi Maik,

On 11/17/22 16:22, Maik Vermeulen wrote:
> Hi,
>
> Depending on the image that's being built, e.g. development vs. production,
> we would like to be able to include different user passwords and firewall
> settings.
>
> We know this can be achieved by just having two different recipes that do
> the same thing, but with different variables or included files. However, we
> were wondering if there is a neater way?
>
> We saw this post:
> https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!OOPJP91ZZw!k-UkKru_mKI6U4p8UgDfH_VEh1-qar1kiQuqcmnyrETRAnubF79KykqR7VGaRu47i1Ws7n8CAagOJBqEFBB3goTxmBkgn8-qL3X383IHnKva$
> which seems to do what we want, because one recipe can install
> recipe-development, and the other can install recipe-production, while the
> recipe itself can then implement what needs to happen for either.
> However, other recipes included in the images can also depend on recipe,
> and they shouldn't depend on one specifically. They should accept that
> either recipe-development or recipe-production is included. Currently we
> see that both the generic recipe and the specific recipe used by the image
> are built and overwrite each other.
>
> What would be a neat way to achieve two variants of a recipe, and having
> different contents and settings in them?
> Or, can we solve that other included recipes depend on one of the variants,
> instead of on the generic one.
>

Development vs production is solved by using different distros.

You can then have the same recipe but with different files (see
(DISTRO)OVERRIDES mechanism for SRC_URI file:// files, c.f.
https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf)
and/or different variables via FOO:dev-distro or FOO:append:dev-distro
for example.

You could also have different recipes both PROVIDES'ing the same virtual
recipe and then have PREFERRED_PROVIDER_my-recipe = "my-recipe-dev" in
your dev-distro.conf file.

Two distros is usually overkill when you have very small and
non-invasive differences between your dev and prod images (e.g. an
additional package, or a lone package that needs to be slightly
different). In that scenario, a "drity" solution is to have two recipes
and have the final image pick the appropriate package. But this quickly
does not scale well once you have recipes/packages depending on those or
if you have more than two flavors to support.

The best practice is to use two distros.

Cheers,
Quentin




Re: Image dependent variables/files in included recipes

Quentin Schulz
 

Hi Maik,

On 11/17/22 16:22, Maik Vermeulen wrote:
Hi,
Depending on the image that's being built, e.g. development vs. production,
we would like to be able to include different user passwords and firewall
settings.
We know this can be achieved by just having two different recipes that do
the same thing, but with different variables or included files. However, we
were wondering if there is a neater way?
We saw this post:
https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!OOPJP91ZZw!k-UkKru_mKI6U4p8UgDfH_VEh1-qar1kiQuqcmnyrETRAnubF79KykqR7VGaRu47i1Ws7n8CAagOJBqEFBB3goTxmBkgn8-qL3X383IHnKva$
which seems to do what we want, because one recipe can install
recipe-development, and the other can install recipe-production, while the
recipe itself can then implement what needs to happen for either.
However, other recipes included in the images can also depend on recipe,
and they shouldn't depend on one specifically. They should accept that
either recipe-development or recipe-production is included. Currently we
see that both the generic recipe and the specific recipe used by the image
are built and overwrite each other.
What would be a neat way to achieve two variants of a recipe, and having
different contents and settings in them?
Or, can we solve that other included recipes depend on one of the variants,
instead of on the generic one.
Development vs production is solved by using different distros.

You can then have the same recipe but with different files (see (DISTRO)OVERRIDES mechanism for SRC_URI file:// files, c.f. https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf) and/or different variables via FOO:dev-distro or FOO:append:dev-distro for example.

You could also have different recipes both PROVIDES'ing the same virtual recipe and then have PREFERRED_PROVIDER_my-recipe = "my-recipe-dev" in your dev-distro.conf file.

Two distros is usually overkill when you have very small and non-invasive differences between your dev and prod images (e.g. an additional package, or a lone package that needs to be slightly different). In that scenario, a "drity" solution is to have two recipes and have the final image pick the appropriate package. But this quickly does not scale well once you have recipes/packages depending on those or if you have more than two flavors to support.

The best practice is to use two distros.

Cheers,
Quentin


Re: Image dependent variables/files in included recipes

Alexander Kanavin
 

You have to define an additional distribution I'm afraid. It can share almost everything with the existing distro, but set PREFERRED_PROVIDER differently.

Alex


On Thu, 17 Nov 2022 at 16:22, Maik Vermeulen <maik.vermeulen@...> wrote:
Hi,

Depending on the image that's being built, e.g. development vs. production, we would like to be able to include different user passwords and firewall settings.

We know this can be achieved by just having two different recipes that do the same thing, but with different variables or included files. However, we were wondering if there is a neater way?

We saw this post:
which seems to do what we want, because one recipe can install recipe-development, and the other can install recipe-production, while the recipe itself can then implement what needs to happen for either.
However, other recipes included in the images can also depend on recipe, and they shouldn't depend on one specifically. They should accept that either recipe-development or recipe-production is included. Currently we see that both the generic recipe and the specific recipe used by the image are built and overwrite each other.

What would be a neat way to achieve two variants of a recipe, and having different contents and settings in them?
Or, can we solve that other included recipes depend on one of the variants, instead of on the generic one.

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear






Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 




Image dependent variables/files in included recipes

Maik Vermeulen
 

Hi,

Depending on the image that's being built, e.g. development vs. production, we would like to be able to include different user passwords and firewall settings.

We know this can be achieved by just having two different recipes that do the same thing, but with different variables or included files. However, we were wondering if there is a neater way?

We saw this post:
which seems to do what we want, because one recipe can install recipe-development, and the other can install recipe-production, while the recipe itself can then implement what needs to happen for either.
However, other recipes included in the images can also depend on recipe, and they shouldn't depend on one specifically. They should accept that either recipe-development or recipe-production is included. Currently we see that both the generic recipe and the specific recipe used by the image are built and overwrite each other.

What would be a neat way to achieve two variants of a recipe, and having different contents and settings in them?
Or, can we solve that other included recipes depend on one of the variants, instead of on the generic one.

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear






Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 


Re: source-less python

Yishai Jaffe
 

Seems like a shame not to add this feature for everyone to use... 

Yishai Jaffe

On Thu, Nov 17, 2022, 2:34 PM Alexander Kanavin <alex.kanavin@...> wrote:
 Making your own! You can have it added to the layer index for better publicity.

Alex

On Thu, 17 Nov 2022 at 13:27, Yishai Jaffe <yishai1999@...> wrote:
>
> What layer would you suggest?
>
> Yishai Jaffe
>
> On Thu, Nov 17, 2022, 2:21 PM Alexander Kanavin <alex.kanavin@...> wrote:
>>
>> You can start by placing it in a separate layer?
>>
>> Alex
>>
>> On Thu, 17 Nov 2022 at 13:04, Yishai Jaffe <yishai1999@...> wrote:
>> >
>> > I assume by core you mean openembedded-core/poky, yes?
>> >
>> > So where would you add it to?
>> >
>> > Seems to me like a very useful feature that many people would use if they knew the option exists.
>> >
>> > Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?
>> >
>> > Yishai Jaffe
>> >
>> > On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:
>> >>
>> >> I just wonder if this should really be in core. The standards for core
>> >> are high: it needs to be both testable and tested, and there's only so
>> >> many possible options and tweaks where things can regress that we can
>> >> take. On the other hand, there has not been much demand for it.
>> >>
>> >> Alex
>> >>
>> >> On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:
>> >> >
>> >> > Hi Alexander,
>> >> >
>> >> > After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:
>> >> >
>> >> > Normal compilation:
>> >> > tar.bz2 - 6.6MB
>> >> > squashfs-xz - 6.1MB
>> >> >
>> >> > With my pyc-only patch:
>> >> > tar.bz2 - 5.8MB
>> >> > squashfs-xz - 5.2MB
>> >> >
>> >> > So that's about a 15% decrease in size.
>> >> > Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.
>> >> >
>> >> >
>> >> > Yishai Jaffe
>> >> >
>> >> >
>> >> > On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:
>> >> >>
>> >> >> Generally we slim down python installations by not installing all of
>> >> >> the standard library, and rather having precise dependencies for
>> >> >> specific modules. Can you illustrate the kind of space savings that
>> >> >> can be gained in actual numbers?
>> >> >>
>> >> >> Another issue is that this should be supported upstream and in the
>> >> >> wider python community. Is it?
>> >> >>
>> >> >> Alex
>> >> >>
>> >> >> On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:
>> >> >> >
>> >> >> >
>> >> >> > Hello,
>> >> >> > Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)
>> >> >> >
>> >> >> > These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Federico
>> >> >> >
>> >> >> > Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
>> >> >> >> I know that in buildroot it is supported.
>> >> >> >> Was this discussed and decided against? Is this an open issue?
>> >> >> >> I have a working patch that implements this. I can submit it for review.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Yishai Jaffe
>> >> >> >> Yishai Jaffe
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >


Re: source-less python

Alexander Kanavin
 

Making your own! You can have it added to the layer index for better publicity.

Alex

On Thu, 17 Nov 2022 at 13:27, Yishai Jaffe <yishai1999@...> wrote:

What layer would you suggest?

Yishai Jaffe

On Thu, Nov 17, 2022, 2:21 PM Alexander Kanavin <alex.kanavin@...> wrote:

You can start by placing it in a separate layer?

Alex

On Thu, 17 Nov 2022 at 13:04, Yishai Jaffe <yishai1999@...> wrote:

I assume by core you mean openembedded-core/poky, yes?

So where would you add it to?

Seems to me like a very useful feature that many people would use if they knew the option exists.

Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?

Yishai Jaffe

On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:

I just wonder if this should really be in core. The standards for core
are high: it needs to be both testable and tested, and there's only so
many possible options and tweaks where things can regress that we can
take. On the other hand, there has not been much demand for it.

Alex

On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:

Hi Alexander,

After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:

Normal compilation:
tar.bz2 - 6.6MB
squashfs-xz - 6.1MB

With my pyc-only patch:
tar.bz2 - 5.8MB
squashfs-xz - 5.2MB

So that's about a 15% decrease in size.
Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.


Yishai Jaffe


On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:

Generally we slim down python installations by not installing all of
the standard library, and rather having precise dependencies for
specific modules. Can you illustrate the kind of space savings that
can be gained in actual numbers?

Another issue is that this should be supported upstream and in the
wider python community. Is it?

Alex

On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:


Hello,
Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)

These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.

Cheers,
Federico

Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:

Hi,
I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
I know that in buildroot it is supported.
Was this discussed and decided against? Is this an open issue?
I have a working patch that implements this. I can submit it for review.

Thanks,
Yishai Jaffe
Yishai Jaffe




Re: source-less python

Yishai Jaffe
 

What layer would you suggest?

Yishai Jaffe

On Thu, Nov 17, 2022, 2:21 PM Alexander Kanavin <alex.kanavin@...> wrote:
You can start by placing it in a separate layer?

Alex

On Thu, 17 Nov 2022 at 13:04, Yishai Jaffe <yishai1999@...> wrote:
>
> I assume by core you mean openembedded-core/poky, yes?
>
> So where would you add it to?
>
> Seems to me like a very useful feature that many people would use if they knew the option exists.
>
> Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?
>
> Yishai Jaffe
>
> On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:
>>
>> I just wonder if this should really be in core. The standards for core
>> are high: it needs to be both testable and tested, and there's only so
>> many possible options and tweaks where things can regress that we can
>> take. On the other hand, there has not been much demand for it.
>>
>> Alex
>>
>> On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:
>> >
>> > Hi Alexander,
>> >
>> > After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:
>> >
>> > Normal compilation:
>> > tar.bz2 - 6.6MB
>> > squashfs-xz - 6.1MB
>> >
>> > With my pyc-only patch:
>> > tar.bz2 - 5.8MB
>> > squashfs-xz - 5.2MB
>> >
>> > So that's about a 15% decrease in size.
>> > Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.
>> >
>> >
>> > Yishai Jaffe
>> >
>> >
>> > On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:
>> >>
>> >> Generally we slim down python installations by not installing all of
>> >> the standard library, and rather having precise dependencies for
>> >> specific modules. Can you illustrate the kind of space savings that
>> >> can be gained in actual numbers?
>> >>
>> >> Another issue is that this should be supported upstream and in the
>> >> wider python community. Is it?
>> >>
>> >> Alex
>> >>
>> >> On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:
>> >> >
>> >> >
>> >> > Hello,
>> >> > Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)
>> >> >
>> >> > These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.
>> >> >
>> >> > Cheers,
>> >> > Federico
>> >> >
>> >> > Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:
>> >> >>
>> >> >> Hi,
>> >> >> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
>> >> >> I know that in buildroot it is supported.
>> >> >> Was this discussed and decided against? Is this an open issue?
>> >> >> I have a working patch that implements this. I can submit it for review.
>> >> >>
>> >> >> Thanks,
>> >> >> Yishai Jaffe
>> >> >> Yishai Jaffe
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >


Re: source-less python

Alexander Kanavin
 

You can start by placing it in a separate layer?

Alex

On Thu, 17 Nov 2022 at 13:04, Yishai Jaffe <yishai1999@...> wrote:

I assume by core you mean openembedded-core/poky, yes?

So where would you add it to?

Seems to me like a very useful feature that many people would use if they knew the option exists.

Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?

Yishai Jaffe

On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:

I just wonder if this should really be in core. The standards for core
are high: it needs to be both testable and tested, and there's only so
many possible options and tweaks where things can regress that we can
take. On the other hand, there has not been much demand for it.

Alex

On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:

Hi Alexander,

After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:

Normal compilation:
tar.bz2 - 6.6MB
squashfs-xz - 6.1MB

With my pyc-only patch:
tar.bz2 - 5.8MB
squashfs-xz - 5.2MB

So that's about a 15% decrease in size.
Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.


Yishai Jaffe


On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:

Generally we slim down python installations by not installing all of
the standard library, and rather having precise dependencies for
specific modules. Can you illustrate the kind of space savings that
can be gained in actual numbers?

Another issue is that this should be supported upstream and in the
wider python community. Is it?

Alex

On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:


Hello,
Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)

These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.

Cheers,
Federico

Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:

Hi,
I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
I know that in buildroot it is supported.
Was this discussed and decided against? Is this an open issue?
I have a working patch that implements this. I can submit it for review.

Thanks,
Yishai Jaffe
Yishai Jaffe




Re: source-less python

Yishai Jaffe
 

I assume by core you mean openembedded-core/poky, yes?

So where would you add it to?

Seems to me like a very useful feature that many people would use if they knew the option exists.

Also, I noticed that in the recipe for python there is a variable named INCLUDE_PYC which does exactly what you think it would. This looks to me like someone did think about the whole python size subject but didn't exactly go through with it all the way. You can decide if to include pyc files but not the opposite. Also, this feature which does exist only applies to the python recipe but not to all other non-base python module recipes. Maybe this can be added to setuptools3 bbclass?

Yishai Jaffe

On Thu, Nov 17, 2022, 1:24 PM Alexander Kanavin <alex.kanavin@...> wrote:
I just wonder if this should really be in core. The standards for core
are high: it needs to be both testable and tested, and there's only so
many possible options and tweaks where things can regress that we can
take. On the other hand, there has not been much demand for it.

Alex

On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:
>
> Hi Alexander,
>
> After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:
>
> Normal compilation:
> tar.bz2 - 6.6MB
> squashfs-xz - 6.1MB
>
> With my pyc-only patch:
> tar.bz2 - 5.8MB
> squashfs-xz - 5.2MB
>
> So that's about a 15% decrease in size.
> Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.
>
>
> Yishai Jaffe
>
>
> On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:
>>
>> Generally we slim down python installations by not installing all of
>> the standard library, and rather having precise dependencies for
>> specific modules. Can you illustrate the kind of space savings that
>> can be gained in actual numbers?
>>
>> Another issue is that this should be supported upstream and in the
>> wider python community. Is it?
>>
>> Alex
>>
>> On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:
>> >
>> >
>> > Hello,
>> > Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)
>> >
>> > These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.
>> >
>> > Cheers,
>> > Federico
>> >
>> > Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:
>> >>
>> >> Hi,
>> >> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
>> >> I know that in buildroot it is supported.
>> >> Was this discussed and decided against? Is this an open issue?
>> >> I have a working patch that implements this. I can submit it for review.
>> >>
>> >> Thanks,
>> >> Yishai Jaffe
>> >> Yishai Jaffe
>> >>
>> >>
>> >>
>> >
>> >
>> >


Re: source-less python

Alexander Kanavin
 

I just wonder if this should really be in core. The standards for core
are high: it needs to be both testable and tested, and there's only so
many possible options and tweaks where things can regress that we can
take. On the other hand, there has not been much demand for it.

Alex

On Thu, 17 Nov 2022 at 12:13, Yishai Jaffe <yishai1999@...> wrote:

Hi Alexander,

After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:

Normal compilation:
tar.bz2 - 6.6MB
squashfs-xz - 6.1MB

With my pyc-only patch:
tar.bz2 - 5.8MB
squashfs-xz - 5.2MB

So that's about a 15% decrease in size.
Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.


Yishai Jaffe


On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:

Generally we slim down python installations by not installing all of
the standard library, and rather having precise dependencies for
specific modules. Can you illustrate the kind of space savings that
can be gained in actual numbers?

Another issue is that this should be supported upstream and in the
wider python community. Is it?

Alex

On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:


Hello,
Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)

These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.

Cheers,
Federico

Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:

Hi,
I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
I know that in buildroot it is supported.
Was this discussed and decided against? Is this an open issue?
I have a working patch that implements this. I can submit it for review.

Thanks,
Yishai Jaffe
Yishai Jaffe




Re: source-less python

Yishai Jaffe
 

Hi Alexander,

After some research, these are the numbers I came up with for compiling core-image-minimal with python3-core:

Normal compilation:
tar.bz2 - 6.6MB
squashfs-xz - 6.1MB

With my pyc-only patch:
tar.bz2 - 5.8MB
squashfs-xz - 5.2MB

So that's about a 15% decrease in size.
Again, this is for an image only with python3-core. Logically that would mean that if you had an image with more python packages it would be even a bigger percentage.


Yishai Jaffe


On Sun, Nov 13, 2022 at 5:12 PM Alexander Kanavin <alex.kanavin@...> wrote:
Generally we slim down python installations by not installing all of
the standard library, and rather having precise dependencies for
specific modules. Can you illustrate the kind of space savings that
can be gained in actual numbers?

Another issue is that this should be supported upstream and in the
wider python community. Is it?

Alex

On Sun, 13 Nov 2022 at 14:25, Federico Pellegrin <fede@...> wrote:
>
>
> Hello,
> Just as a small reference since I raised some doubts and questions in Buildroot community on this: there has been also some troubles to understand the correctness or not there (as I found some packages with problems due to this source-less management) and this then sparked, besides discussions in the Buildroot mailing list (roughly end of July / beginning of August if someone interested searching there), also an issue to the Python community, which albeit some discussion I think never arrived to a concrete conclusion. This is the issue: https://github.com/python/cpython/issues/95827 (see also the linked one maybe)
>
> These are just my 2 cents to this discussion, then of course the Python experts will probably chime in and describe the official/discussed position of Yocto regarding to this, but just felt like mentioning that although Buildroot is somehow offering this right now (and likely mostly works as well!), it's not really a so clean and/or agreed solution.
>
> Cheers,
> Federico
>
> Il giorno dom 13 nov 2022 alle ore 13:55 Yishai Jaffe <yishai1999@...> ha scritto:
>>
>> Hi,
>> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
>> I know that in buildroot it is supported.
>> Was this discussed and decided against? Is this an open issue?
>> I have a working patch that implements this. I can submit it for review.
>>
>> Thanks,
>> Yishai Jaffe
>> Yishai Jaffe
>>
>>
>>
>
>
>


Re: sstate mirror file name length issue #dunfell

Markus Held
 

On 15/11/2022 15:01, Richard Purdie wrote:
On Tue, 2022-11-15 at 04:09 -0800, Markus Held wrote:
Hello,

I try to use yocto SSTATE_MIRROR with a custom distribution (RDK:
https://developer.rdkcentral.com/) and enabled yocto multilib
support.
The sstate directory is created by my build server and published with
nginx to the developer machines.

Environment:
Bitbake 1.46.0 / Yocto Dunfell 3.1
TUNE_PKGARCH = “cortexa53t2hf-neon-fp-armv8”
MULTILIBS = "multilib:lib32"
TARGET_VENDOR="-rdk"
TARGET_OS="linux"

When a developer configures the sstate mirror in his local.conf:

   SSTATE_MIRRORS ?= " file://.* http://<build server>/sstate-
cache/PATH;downloadfilename=PATH "

the build gets stuck on various _setscene tasks and does not
continue. I did some debugging and the issue is related the with file
name length of the sstate files. When the developer machine tries to
download a file from the mirror, bitbake fetch wants to create a
local lock file with name "<file name>.lock". Example of a sstate
lock file that fails for me:

   sstate:lib32-dibbler:cortexa53t2hf-neon-fp-armv8-rdkmllib32-linux-
gnueabi:1.0.1+1.0.2RC1+gitc4b0ed52e751da7823dd9a36e91f93a6310e5525:r0
:cortexa53t2hf-neon-fp-
armv8:3:169be56e277b6922d1cca3f23f6d56033812941a438f09a477cd96999d7d0
801_package_qa.tgz.siginfo.lock

This lock file cannot be created on a ext file system due the file
name length > 255. This causes the _setscene task to get stuck
indefinitely. It seems like most Linux file systems only support file
names up to 255 bytes.

Is there a way to configure or limit the file name length of the
sstate cache files? Or a way to avoid the issue with the .lock file?
There were changes in bitbake:

https://git.yoctoproject.org/poky/commit/bitbake/lib/bb/utils.py?id=273b124bf6acd77b074fde2421be331721a68c11
https://git.yoctoproject.org/poky/commit/bitbake/lib/bb/utils.py?id=09e826cfb021731c1b139046665d2d9fa24baa88

There were also sstate class changes:

https://git.yoctoproject.org/poky/commit/meta/classes/sstate.bbclass?id=b8025e972081b70960ffcbcbe43a7118041556a1
https://git.yoctoproject.org/poky/commit/meta/classes/sstate.bbclass?id=ed4bdd0f9149ba24fac375fd3af8bb2a06423105
https://git.yoctoproject.org/poky/commit/meta/classes/sstate.bbclass?id=4c6efbf03530b6f60cde59cdef61aa14538753a3

Cheers,

Richard
Thanks, I applied the patches locally and it fixed the issue for me.

Markus


Re: Error while bitbake #dunfell

Shruti gandotra
 

Thanks, I'll check it out. 


On Tue, 15 Nov 2022, 11:33 pm Khem Raj, <raj.khem@...> wrote:


On Mon, Nov 14, 2022 at 9:46 PM Shruti gandotra <shruti10gandotra@...> wrote:
I am trying to build rcar-image-minimal for RCar S4, while bitbake I'm getting do_rootfs: The postinstall intercept hook 'update_pixbuf_cache' failed error. I tried using cleanall and cleansstate but I'm still getting the same error. 
Can anyone help me with issue?

Look into the logs in the rootfs build area and it might reveal the underlying problem perhaps some missing library or qemu user mode crash could be the reason 




Re: QA notification for completed autobuilder build (yocto-4.1.1.rc1)

Jing Hui Tham
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-4.1.1.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. ADL
4. TGL NUC 11
5. Edgerouter
6. Beaglebone

ETA for completion next Monday, November 21.

Best regards,
Jing Hui

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Pokybuild User
Sent: Tuesday, 15 November, 2022 7:00 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-
4.1.1.rc1)


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


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


Build hash information:

bitbake: 138dd7883ee2c521900b29985b6d24a23d96563c
meta-agl: e5dd276442a8c9268a8818a638b07ee96383b657
meta-arm: ff9b6f29bf4a6e3fcead5c1025a413cffee7bc53
meta-aws: 8537180c8645455ee2b57c696389df21fc17f63a
meta-intel: f70cf173dc40131e5ed3955a4a459fff3aa010ed
meta-mingw: b0067202db8573df3d23d199f82987cebe1bee2c
meta-openembedded: c5668905a6d8a78fb72c2cbf8b20e91e686ceb86
meta-virtualization: 8857b36ebfec3d548755755b009adc491ef320ab
oecore: 9237ffc4feee2dd6ff5bdd672072509ef9e82f6d
poky: d3cda9a3e0837eb2ac5482f5f2bd8e55e874feff



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



Re: Ownership issue during do_image

Frederic Martinsons <frederic.martinsons@...>
 

Yes I do, I build under docker (ubuntu 20.04), I didn't mention that in my original post , sorry. Do you think it is related to my issue ?

On Tue, Nov 15, 2022 at 09:06 PM, Tim Orling wrote:

Are you building with a docker/podman container?

On Tue, Nov 15, 2022 at 9:24 AM Frederic Martinsons < frederic.martinsons@...> wrote:

Hello list,

Doesn't ring a bell to anybody ? Even the slightest clue will help me to continue to track down this weird behavior , nobody have ever problem of files/directories rights during image generation ?