Date   

Re: Best way to mask bbappends based on Poky version to have a layer support multiple versions of Poky?

Matt Campbell
 

Thanks for the info. I think both of those will run into issues where the bbappend won't apply to the original recipe as that is fully done by path and file name and both of these methods mangle those. Please correct me if I'm wrong as there might be some cheese down that tunnel for me.

I've been thinking more about this over the weekend and have rethought the problem a bit. I think what I really want is to be able to conditionally skip a bbappend in recipe using python rather than having to do this centralized in the layer.conf with BBMASK. There are two reasons for this:

1) This puts the logic that skips the bbappend in the file itself which makes it more obvious what is going on when browsing/maintaining meta-data. The BBMASK method is centralized, but is hidden when you are just working with the metadata.
2) This allows for arbitrary and more complex logic for skipping bbappends.

I'm not super familiar with the internals of bitbake, but I think what I want is something similar to the bb.parse.SkipRecipe() exception. For example

file: test_%.bbappend
python() {
    # Skip based on poky version
    if d.getVar("DISTRO_CODENAME") != 'zeus':
        raise bb.parse.SkipBbappend("This bbappend only supports Zeus. Skipping this bbappend")

    # Skip based on package version
    if d.getVar("PV") != '1.0':
        raise bb.parse.SkipBbappend("This bbappend only supports version 1.0 of test. Skipping bbappend")
}

1) Does this seem like a good solution to the problem of dangling appends in layers that want to support two versions of Poky?
2) Any thoughts on how to go about implementing this?

~Matt

On Thu, Mar 26, 2020 at 4:09 PM Konrad Weihmann <kweihmann@...> wrote:

Hi,

I'll get your point.
Maybe this could be a solution to your problem https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-BBVERSIONS.
Instead of having different bbappends have one and pick the right steps inside of the append.

If that is not working for you, you could also fake the behavior of BBFILES_DYNAMIC with putting the bbappend into separate subfolder, which than are
referenced by something like this

BBFILES += "${LAYERDIR}/dynamic-recipes/${BB_VERSION}/*.bbappend"

Regards
Konrad

On 26.03.20 20:56, Matt Campbell wrote:
I didn't know about  BB_DANGLINGAPPENDS_WARNONLY. That would mask the problem, but doesn't feel like a great solution. Either way I do appreciate you sharing that.

Further implementation and discussion with our team brought up another possible solution. We could wildcard all bbappends (_%.bbappend) and use some anonymous python inside our bbappend files that will error out if the package version isn't in a supported list. We could also easily roll this up into a bbclass to prevent the need to duplicate this everywhere.

python () {
    package_version = d.getVar("PV")
    if  package_version is not in ['3.14", "3.15"]:
        bb.error("This bbappend file isn't compatible with the version {}. You will need to add support to this bbappend for that version.".format(package_version))
}

This still seems more like we are fighting bitbake rather than working with it. Does anyone have any thoughts or suggestions on this?

Other upstreams seem to maintain different branches for different Poky releases. That is a road we would rather avoid if possible. Our goal is to be able to have an extra CI build against the version of Poky under development so we can continuously fix the upgrade issues as they come up rather than as a landslide when we upgrade. Making a separate branch for this would mean we would need to merge all active development into each branch to get the benefits of a poky next canary build plan. That said, I'd love to hear about a solution that lets us have our cake and eat it too.

~Matt

On Thu, Mar 26, 2020 at 9:55 AM Robert P. J. Day <rpjday@...> wrote:
On Thu, 26 Mar 2020, Matt Campbell wrote:

> HI All,

> We have a layer where we want to concurrently support two releases
> of Poky. There is an issue when we have bbappnds against recipes
> that have different versions in the two poky releases. for instance,
> imagine recipe foo that is version 1.0 in Zeus and 1.2 in Dunfell.
> If we had a bbappend in our layer `foo_1.0.bbappend` and tried to
> use our layer with Dunfell, bitbake will error out saying that
> `foo_1.0.bbappend` has no base recipe.

  not sure if this really solves the underlying issue, but you can
always turn those errors into warnings with:

  BB_DANGLINGAPPENDS_WARNONLY = "1"

in your local.conf, although i'm still skeptical as to whether that's
really the problem you're trying to solve.

rday


--
Matthew Campbell
Senior Embedded Systems Engineer

iZotope, Inc.


    


--
Matthew Campbell
Senior Embedded Systems Engineer

iZotope, Inc.


Re: Image size reduction

Mikko Rapeli
 

On Mon, Mar 30, 2020 at 03:00:05AM +0000, Ajam Ali wrote:
Hi khemraj,

Please suggest the way to reduce the image size. Your earlier suggestion is not that much helpful.
Actually suggestion to use buildhistory is the first critical step because without
this you can't easily see where the size comes from. buildhistory provides
for example the list of installed binary packages ordered by size for every image
built. Then it enables you to easily check the dependencies of variour packages
and detect, e.g. who brings perl or python to the image.

Cheers,

-Mikko


Re: Fw: Reducing rootfs size in yocto

Mikko Rapeli
 

Hi,

Generic approaches for reducing yocto target image size where buildhistory
is an important source of information:

* review and minimize distro features, enable only what you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-distro

* review and minimize image recipe, install only those image features and packages
which you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image

* review the needed binary packages: traverse the tree of dependencies what you need,
review every single recipe and change PACKAGECONFIG or build flags to remove
features which you do not need. This it may be possible to remove large set
of dependencies from images, e.g. language bindings, debug tools. In some cases
one just needs a single binary executable or shared library but it is bundled
in a larger binary package with more complex dependencies. For these cases
add a bbappend to custom layers to change the packaging to only include what
you need.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGECONFIG

* change compiler flags from default O2 to Os optimization. This can work for
some recipes which are not prerformance critical or to the whole build. Note
that many SW components break this in their own build scripts by adding
O2 or even O3 by default. Check from buildhistory that binary sizes go smaller
after switch from O2 to Os and review every important recipe which did not.
You may be able to save up to 15% in rootfs size this way, but all depends
on the details of SW components and image contents.
see poky/meta/conf/bitbake.conf

I've followed this for multiple products and found out that poky is nice to work with
but BSP layers add or depend on all kinds of extra things that products do not need.
Thus I have ended by BBMASK'ing away large parts of BSP layer recipes in distro
configs. This with multiple x86 and ARM BSP layers from various SoC vendors.

Also, RTFM :)

https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-a-tiny-system

Hope this helps,

-Mikko


[PATCH] Add localhost to noproxy list.

Li, Xiaoming
 

Signed-off-by: Li Xiaoming <lixm.fnst@cn.fujitsu.com>
---
classes/fossology-rest.bbclass | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/classes/fossology-rest.bbclass b/classes/fossology-rest.bbclass
index 48e16f3..000eefe 100644
--- a/classes/fossology-rest.bbclass
+++ b/classes/fossology-rest.bbclass
@@ -25,6 +25,8 @@ HOSTTOOLS_NONFATAL += "curl"

CREATOR_TOOL = "fossology-rest.bbclass in meta-spdxscanner"

+NO_PROXY = "localhost, 127.0.0.1"
+
# If ${S} isn't actually the top-level source directory, set SPDX_S to point at
# the real top-level directory.
SPDX_S ?= "${S}"
@@ -159,7 +161,7 @@ def get_folder_id_by_name(d, folder_name):

rest_api_cmd = "curl -k -s -S -X GET " + server_url + "/api/v1/folders" \
+ " -H \"Authorization: Bearer " + token + "\"" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("Invoke rest_api_cmd = " + rest_api_cmd )
try:
all_folder = subprocess.check_output(rest_api_cmd, stderr=subprocess.STDOUT, shell=True)
@@ -200,7 +202,7 @@ def create_folder(d, folder_name):
+ " -H \'parentFolder: 1\'" \
+ " -H \'folderName: " + folder_name + "\'" \
+ " -H \"Authorization: Bearer " + token + "\"" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("Invoke rest_api_cmd = " + rest_api_cmd)
try:
add_folder = subprocess.check_output(rest_api_cmd, stderr=subprocess.STDOUT, shell=True)
@@ -251,7 +253,7 @@ def has_upload(d, tar_file, folder_id):

rest_api_cmd = "curl -k -s -S -X GET " + server_url + "/api/v1/uploads" \
+ " -H \"Authorization: Bearer " + token + "\"" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("Invoke rest_api_cmd = " + rest_api_cmd )

try:
@@ -302,7 +304,7 @@ def upload(d, tar_file, folder):
+ " -H \'public: public\'" \
+ " -H \'Content-Type: multipart/form-data\'" \
+ " -F \'fileInput=@\"" + tar_file + "\";type=application/octet-stream\'" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("Upload : Invoke rest_api_cmd = " + rest_api_cmd )
while i < 10:
time.sleep(delaytime)
@@ -343,7 +345,7 @@ def analysis(d, folder_id, upload_id):
+ " -H \"Authorization: Bearer " + token + "\"" \
+ " -H \'Content-Type: application/json\'" \
+ " --data \'{\"analysis\": {\"bucket\": true,\"copyright_email_author\": true,\"ecc\": true, \"keyword\": true,\"mime\": true,\"monk\": true,\"nomos\": true,\"package\": true},\"decider\": {\"nomos_monk\": true,\"bulk_reused\": true,\"new_scanner\": true}}\'" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("Analysis : Invoke rest_api_cmd = " + rest_api_cmd )
while i < 10:
try:
@@ -389,7 +391,7 @@ def trigger(d, folder_id, upload_id):
+ " -H \"Authorization: Bearer " + token + "\"" \
+ " -H \"uploadId: " + str(upload_id) + "\"" \
+ " -H \'reportFormat: spdx2tv\'" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("trigger : Invoke rest_api_cmd = " + rest_api_cmd )
while i < 10:
time.sleep(delaytime)
@@ -431,7 +433,7 @@ def get_spdx(d, report_id, spdx_file):
rest_api_cmd = "curl -k -s -S -X GET " + server_url + "/api/v1/report/" + report_id \
+ " -H \'accept: text/plain\'" \
+ " -H \"Authorization: Bearer " + token + "\"" \
- + " --noproxy 127.0.0.1"
+ + " --noproxy " + NO_PROXY
bb.note("get_spdx : Invoke rest_api_cmd = " + rest_api_cmd )
while i < 10:
time.sleep(delaytime)
--
2.17.1


Re: Fw: Reducing rootfs size in yocto

Ajam Ali
 

Hi,

-dev version of boost is a supporting package which is getting installed by default
not by me using local.conf.

Thanks,
Ajam Ali


From: yocto@... <yocto@...> on behalf of Oliver Westermann via Lists.Yoctoproject.Org <oliver.westermann=cognex.com@...>
Sent: Sunday, March 29, 2020 8:16 PM
To: yocto@... <yocto@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] Fw: Reducing rootfs size in yocto
 

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Do you need the -dev version of boost on the device?
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


Add a customised shell script to be invked after board bootso #yocto

Raghu Icecraft Software Trainings
 

Hello,
I have written a shell script to change the password for my root user.
I want to execute this script file after board boots
So i created .bb file as follows:
 
 
SUMMARY = "Initscript for enabling root pwd"

LICENSE = "GPLv2"
#LIC_FILES_CHKSUM = "file://${WORKDIR}/root_vpd;md5=bc4963ad2e7baa1c3bdfc9031d8453f0"


PR = "r0"

SRC_URI = "file://root_vpd"
S = "${WORKDIR}"

do_install() {
    install -d ${D}${sysconfdir}
    install -d ${D}${sysconfdir}/init.d
    install -m 0755 root_vpd ${D}${sysconfdir}/init.d
}

inherit update-rc.d allarch

INITSCRIPT_NAME = "root-vpd"
INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
 
 
 
and i copied the script file in the sam efolder 
BUt when i do bitbake of above recipew i get this error :
 
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1992 .bb files complete (1982 cached, 10 parsed). 4688 targets, 384 skipped, 1 masked, 0 errors.
ERROR: Nothing PROVIDES  pwd.bb
 
 

 
--
Thanks,
raghu


Novice question on makefile in yocto environment

Raghu Icecraft Software Trainings
 

Hi,

  I have some general idea on makefile in C, C++ environment.
Related to my Yocto project having a very tough time in getting my makefile ready on shape after almost every development change.

Is there any specific Troubleshooting based guidance available some where ?
I have also tried looking for old posts in this group.
Please suggest if I have to post this question, somewhere else.


Re: Image size reduction

Ajam Ali
 

Hi khemraj, 

Please suggest the way to reduce the image size. Your earlier suggestion is not that much helpful. 

Thanks, 
Ajam Ali

Sent from Outlook Mobile


From: Khem Raj <raj.khem@...>
Sent: Monday, March 30, 2020 2:44:21 AM
To: Ajam Ali <AjamA@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] Image size reduction
 
[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

On Sun, Mar 29, 2020 at 9:29 AM Ajam Ali <ajama@...> wrote:
>
> Hi All,
>
> Actually my current image size is 3.9GB because of heavy size packages required by my project and without project required packages my image size in Yocto is 800MB.
>
> I want to reduce the image size as maximum as possible.
> Please suggest the best possible way so that I could reduce the maximum possible size(desirable below 1.5 GB).

Add INHERIT += "buildhistory" to local.conf and then do a build

Start looking at the buildhistory folder especially the size file
images/<machine>/glibc/<image-name>/installed-package-sizes.txt

>
>
> Thanks in advance,
> Ajam Ali
>
>
> Sent from Outlook Mobile
> ::DISCLAIMER::
> ________________________________
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
> ________________________________
>


Re: Image size reduction

Khem Raj
 

On Sun, Mar 29, 2020 at 9:29 AM Ajam Ali <ajama@hcl.com> wrote:

Hi All,

Actually my current image size is 3.9GB because of heavy size packages required by my project and without project required packages my image size in Yocto is 800MB.

I want to reduce the image size as maximum as possible.
Please suggest the best possible way so that I could reduce the maximum possible size(desirable below 1.5 GB).
Add INHERIT += "buildhistory" to local.conf and then do a build

Start looking at the buildhistory folder especially the size file
images/<machine>/glibc/<image-name>/installed-package-sizes.txt



Thanks in advance,
Ajam Ali


Sent from Outlook Mobile
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________


Re: Files get sporadically lost for native packages

Konrad Weihmann
 

some updates on the issue.
I did some further investigation and it turns out that only python cache files are affected - not only when the manifest is created but also when files are being staged.

Here is a dump from one of my runs

2020-03-29T03:09:17.3893569Z ERROR: simple-c-1.0-r0 do_prepare_recipe_sysroot: Error executing a python function in exec_python_func() autogenerated:
2020-03-29T03:09:17.3893931Z
2020-03-29T03:09:17.3894095Z The stack trace of python calls that resulted in this exception/failure was:
2020-03-29T03:09:17.3894483Z File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
2020-03-29T03:09:17.3894608Z      0001:
2020-03-29T03:09:17.3894727Z  *** 0002:extend_recipe_sysroot(d)
2020-03-29T03:09:17.3894837Z      0003:
2020-03-29T03:09:17.3895143Z File: '/opt/build/poky/meta/classes/staging.bbclass', lineno: 570, function: extend_recipe_sysroot
2020-03-29T03:09:17.3895282Z      0566:                    if "/bin/" in l or "/sbin/" in l:
2020-03-29T03:09:17.3895415Z      0567:                        # defer /*bin/* files until last in case they need libs
2020-03-29T03:09:17.3895535Z      0568:                        binfiles[l] = (targetdir, dest)
2020-03-29T03:09:17.3895652Z      0569:                    else:
2020-03-29T03:09:17.3895780Z  *** 0570:                        staging_copyfile(l, targetdir, dest, postinsts, seendirs)
2020-03-29T03:09:17.3895901Z      0571:
2020-03-29T03:09:17.3896183Z      0572:    # Handle deferred binfiles
2020-03-29T03:09:17.3896313Z      0573:    for l in binfiles:
2020-03-29T03:09:17.3896429Z      0574:        (targetdir, dest) = binfiles[l]
2020-03-29T03:09:17.3896763Z File: '/opt/build/poky/meta/classes/staging.bbclass', lineno: 152, function: staging_copyfile
2020-03-29T03:09:17.3896904Z      0148:        os.symlink(linkto, dest)
2020-03-29T03:09:17.3897018Z      0149:        #bb.warn(c)
2020-03-29T03:09:17.3897129Z      0150:    else:
2020-03-29T03:09:17.3897233Z      0151:        try:
2020-03-29T03:09:17.3897341Z  *** 0152:            os.link(c, dest)
2020-03-29T03:09:17.3897455Z      0153:        except OSError as err:
2020-03-29T03:09:17.3897571Z      0154:            if err.errno == errno.EXDEV:
2020-03-29T03:09:17.3897691Z      0155:                bb.utils.copyfile(c, dest)
2020-03-29T03:09:17.3897807Z      0156:            else:
2020-03-29T03:09:17.3898436Z Exception: FileNotFoundError: [Errno 2] No such file or directory: '/opt/build/build/tmp/sysroots-components/x86_64/python3-vulture-native/usr/lib/python3.8/site-packages/vulture/whitelists/__pycache__/unittest_whitelist.cpython-38.pyc' -> '/opt/build/build/tmp/work/core2-32-scatest-linux/simple-c/1.0-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/vulture/whitelists/__pycache__/unittest_whitelist.cpython-38.pyc'
2020-03-29T03:09:17.3898588Z
2020-03-29T03:09:17.3898936Z ERROR: Logfile of failure stored in: /opt/build/build/tmp/work/core2-32-scatest-linux/simple-c/1.0-r0/temp/log.do_prepare_recipe_sysroot.122175
2020-03-29T03:09:17.3899233Z NOTE: recipe simple-c-1.0-r0: task do_prepare_recipe_sysroot: Failed
2020-03-29T03:09:17.3936565Z ERROR: Task (/opt/build/meta-sca/recipes-sca-test/code-from-elsewhere/simple-c.bb:do_prepare_recipe_sysroot) failed with exit code '1'
2020-03-29T03:09:17.3956520Z NOTE: Running task 3920 of 5451 (/opt/build/poky/meta/recipes-devtools/python/python3-git_3.0.5.bb:do_fetch)

After reading a bit about pyc-files(https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode),
I suspect some of the files being invalidated, although I still haven't figured out how that is done.
After forcefully removing all cache files from all native packages, it seems to work - but still I think it just hides the general issue causing this.

Current summary:

- a lot of native python packages are required by multiple recipes (via DEPENDS)
- this effect is only visible under heavy load (on a 16+ core machine: never happened so far, 8 core: happens occasionally, 2 core: happens nearly every time)
- only python cache files (.pyc) are affected
- error occurs at random packages in do_prepare_recipe_sysroot
- some pyc files set in the package manifest are not present in the filesystem

On 28.03.20 13:26, Konrad Weihmann wrote:

Hi,

I'm facing the following error message sporadically on all branches I tried so far (master, zeus, warrior and thud)

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:extend_recipe_sysroot(d)
     0003:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot
     0547:                    dest = newmanifest[l]
     0548:                    if l.endswith("/"):
     0549:                        staging_copydir(l, targetdir, dest, seendirs)
     0550:                        continue
 *** 0551:                    staging_copyfile(l, targetdir, dest, postinsts, seendirs)
     0552:
     0553:    bb.note("Installed into sysroot: %s" % str(msg_adding))
     0554:    bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
     0555:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 152, function: staging_copyfile
     0148:        os.symlink(linkto, dest)
     0149:        #bb.warn(c)
     0150:    else:
     0151:        try:
 *** 0152:            os.link(c, dest)
     0153:        except OSError as err:
     0154:            if err.errno == errno.EXDEV:
     0155:                bb.utils.copyfile(c, dest)
     0156:            else:
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc' -> '/build/poky/build/tmp/work/qemux86_64-mine-linux/core-image-minimal-mine/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'

I already had a look at the manifest

cat manifest-x86_64-python3-msgcheck-native.populate_sysroot
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/python3-msgcheck-native
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/

which states the file should be there, but when doing

find /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share

the file isn't there.

This happens to random python packages compiled as native (sometimes even for python-native itself), but (afaik) not for cross or target packages (I'm pretty sure because of the different packaging applied).
So I digged a little into the code classes/sstate.bbclass:sstate_install, which seems to create the sysroot-component dir and the manifest.
There is a gap between the manifest creation (line 285) and the hardlinking (line till 311).

Now my question is there any place where a file potentially could get lost? - at first glance there shouldn't be one - I have to admit that I don't fully understand all this subprocess magic in lib/oe/path.py:copyhardlinktree.
What I do to fix the issue is reopening the manifest and double check for missing files and remove them from the manifest, but this
feels wrong - so any advise is welcome...

Hope that someone more familiar with the topic could have a look.

Thanks

Konrad



    


Image size reduction

Ajam Ali
 

Hi All, 

Actually my current image size is 3.9GB because of heavy size packages required by my project and without project required packages my image size in Yocto is 800MB.

I want to reduce the image size as maximum as possible.
Please suggest the best possible way so that I could reduce the maximum possible size(desirable below 1.5 GB). 


Thanks in advance,
Ajam Ali


Sent from Outlook Mobile
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


[meta-security][PATCH] buck-security: fix runtime issue with missing per module

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-scanners/buck-security/buck-security_0.7.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-scanners/buck-security/buck-security_0.7.bb b/recipes-scanners/buck-security/buck-security_0.7.bb
index f6cbe3c..179eeda 100644
--- a/recipes-scanners/buck-security/buck-security_0.7.bb
+++ b/recipes-scanners/buck-security/buck-security_0.7.bb
@@ -32,13 +32,13 @@ RDEPENDS_${PN} = "coreutils gnupg net-tools perl perl-module-data-dumper \
perl-module-file-basename perl-module-file-spec perl-module-getopt-long \
perl-module-lib perl-module-posix perl-module-term-ansicolor \
perl-module-time-localtime pinentry perl-module-pod-usage \
- perl-module-pod-text \
+ perl-module-pod-text perl-module-file-glob \
"

RDEPENDS_${PN}_class-native = "coreutils net-tools perl perl-module-data-dumper \
perl-module-file-basename perl-module-file-spec perl-module-getopt-long \
perl-module-lib perl-module-posix perl-module-term-ansicolor \
- perl-module-time-localtime \
+ perl-module-time-localtime perl-module-file-glob\
"


--
2.17.1


Re: Fw: Reducing rootfs size in yocto

Oliver Westermann
 

Do you need the -dev version of boost on the device?


Re: patching an .inc file?

Derek Dresser
 

Thanks again.

The ordering in the bblayers.conf file resolved the issue, but I needed to put my layer above the "meta" layer in the list.

I do understand that this is a temporary solution until the zeus branch of the meta later adds support for the new tools.  I'll be keeping an eye out for that.

Thanks for your help.


Re: patching an .inc file?

Konrad Weihmann
 

Hi Derek,

or maybe I'm mistaken about the layer priority and it's the order within the bblayer.conf that does determine that (I tend to forget which one applies to what stage).

Maybe you could try to move your layer to the end of the bblayer.conf list (actually that was the case when I tested it yesterday) and see if that is working for you.

As pointed out in the other reply - only do this as a matter of last resort and if there is no other possibility left.

On 29.03.20 15:38, Derek Dresser wrote:
Konrad,
Thanks for the reply.  I understand this is temporary until the overridden file is updated.  I appreciate you pointing out using layer priority as an option.  Unfortunately, I can't seem to get this to work using priority.  I'm afraid I might be missing something.  I will try to illustrate with an example.

Here are my layers, note "meta-acadia" is priority 16.  This is where the override file is.  My understanding is a higher priority takes precedence.  I did try setting my layer priority to 4, but had the same results.

pokyuser@9cf512f73142:/yocto-src/poky$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /yocto-src/poky/meta                      5
meta-poky             /yocto-src/poky/meta-poky                 5
meta-yocto-bsp        /yocto-src/poky/meta-yocto-bsp            5
meta-oe               /yocto-src/poky/meta-openembedded/meta-oe  6
meta-perl             /yocto-src/poky/meta-openembedded/meta-perl  6
meta-python           /yocto-src/poky/meta-openembedded/meta-python  7
meta-networking       /yocto-src/poky/meta-openembedded/meta-networking  5
meta-filesystems      /yocto-src/poky/meta-openembedded/meta-filesystems  6
meta-security         /yocto-src/poky/meta-security             8
meta-xilinx-bsp       /yocto-src/poky/meta-xilinx/meta-xilinx-bsp  5
meta-xilinx-standalone  /yocto-src/poky/meta-xilinx/meta-xilinx-standalone  5
meta-acadia           /yocto-src/poky/meta-acadia               16
meta-idexx-distro     /yocto-src/poky/meta-company-distro         6
meta-neural-network   /yocto-src/poky/meta-neural-network       7
meta-selinux          /yocto-src/poky/meta-selinux              5
meta-cgl-common       /yocto-src/poky/meta-cgl/meta-cgl-common  7

and the override file diff (same path within my layer)

pokyuser@9cf512f73142:/yocto-src/poky$ diff meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta-acadia/conf/machine/include/microblaze/feature-microblaze-versions.inc
46a47
> TUNEVALID[v11.0] = "MicroBlaze version 11.0"
62a64
> TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

here's the error

    Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

However, if I copy my override file into the "meta" layer, I can build without errors.

pokyuser@9cf512f73142:/yocto-src/poky$ cp meta-acadia/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Is there something else I'm missing to make the priorty override work?

Thank you.



    


Re: patching an .inc file?

Derek Dresser
 

Konrad,
Thanks for the reply.  I understand this is temporary until the overridden file is updated.  I appreciate you pointing out using layer priority as an option.  Unfortunately, I can't seem to get this to work using priority.  I'm afraid I might be missing something.  I will try to illustrate with an example.

Here are my layers, note "meta-acadia" is priority 16.  This is where the override file is.  My understanding is a higher priority takes precedence.  I did try setting my layer priority to 4, but had the same results.

pokyuser@9cf512f73142:/yocto-src/poky$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /yocto-src/poky/meta                      5
meta-poky             /yocto-src/poky/meta-poky                 5
meta-yocto-bsp        /yocto-src/poky/meta-yocto-bsp            5
meta-oe               /yocto-src/poky/meta-openembedded/meta-oe  6
meta-perl             /yocto-src/poky/meta-openembedded/meta-perl  6
meta-python           /yocto-src/poky/meta-openembedded/meta-python  7
meta-networking       /yocto-src/poky/meta-openembedded/meta-networking  5
meta-filesystems      /yocto-src/poky/meta-openembedded/meta-filesystems  6
meta-security         /yocto-src/poky/meta-security             8
meta-xilinx-bsp       /yocto-src/poky/meta-xilinx/meta-xilinx-bsp  5
meta-xilinx-standalone  /yocto-src/poky/meta-xilinx/meta-xilinx-standalone  5
meta-acadia           /yocto-src/poky/meta-acadia               16
meta-idexx-distro     /yocto-src/poky/meta-company-distro         6
meta-neural-network   /yocto-src/poky/meta-neural-network       7
meta-selinux          /yocto-src/poky/meta-selinux              5
meta-cgl-common       /yocto-src/poky/meta-cgl/meta-cgl-common  7

and the override file diff (same path within my layer)

pokyuser@9cf512f73142:/yocto-src/poky$ diff meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta-acadia/conf/machine/include/microblaze/feature-microblaze-versions.inc
46a47
> TUNEVALID[v11.0] = "MicroBlaze version 11.0"
62a64
> TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

here's the error

    Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

However, if I copy my override file into the "meta" layer, I can build without errors.

pokyuser@9cf512f73142:/yocto-src/poky$ cp meta-acadia/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Is there something else I'm missing to make the priorty override work?

Thank you.


Re: patching an .inc file?

Alejandro Hernandez Samaniego
 

Hey Derek,

I would advise against this, inc files aren't supposed to be appended to, priorities would work, adding TUNEVALID on your machine conf is also possible, but I'd say those are both temporary solutions, you might also just wait a little bit until they release their 2020.x releases already compatible with Zeus.

Alejandro


On Sat, 28 Mar 2020 at 15:00, Konrad Weihmann <kweihmann@...> wrote:

What you could do is to override the file in a layer with higher priority.
Just create the same file under the same path (e.g. <your-layer>/conf/machine/include/microblaze/feature-microblaze-versions.inc) and apply the changes there - this should help for now.

But be aware that this way could lead to trouble in case the overridden file does change on an update - so use with caution.
Unfortunately you can't BBMASK the original inc file, you have to rely on layer prio.

On 28.03.20 22:42, Derek Dresser wrote:
Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


    


Re: patching an .inc file?

Konrad Weihmann
 

What you could do is to override the file in a layer with higher priority.
Just create the same file under the same path (e.g. <your-layer>/conf/machine/include/microblaze/feature-microblaze-versions.inc) and apply the changes there - this should help for now.

But be aware that this way could lead to trouble in case the overridden file does change on an update - so use with caution.
Unfortunately you can't BBMASK the original inc file, you have to rely on layer prio.

On 28.03.20 22:42, Derek Dresser wrote:
Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


    


patching an .inc file?

Derek Dresser
 

Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


Re: Compressing btrfs image

Konrad Weihmann
 

AFAIK there is no way to mount something without root credentials.

fakeroot/pseudo is intercepting some calls before they will reach the kernel, but mounting isn't a supported option - it just makes all child processes think they running under uid 0.

What you could do is try to find an option (https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs) which does what you want directly while creating the image.

These options should go then to a variable called EXTRA_IMAGECMD.


On 28.03.20 16:30, Edson Seabra wrote:
Hi all.

I'm trying to compress a btrfs rootfs

I added  in "image_types.bbclass:IMAGE_CMD_btrfs ()"  two commands:

1) mount the btrfs image after mkfs.btrfs
2) btrfs filesystem defrag + compress option

But the command mount fails:

mount: /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/temp_btrfs: failed to setup loop device for /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/nodegrid-genericx86-64-20200328134151.rootfs.btrfs.

I saw in image.bbclass the creation of do_image_btrfs task with flag 'fakeroot'.

====== image.bbclass ====
        task = "do_image_%s" % t.replace("-", "_").replace(".", "_")

        d.setVar(task, '\n'.join(cmds))
        d.setVarFlag(task, 'func', '1')
        d.setVarFlag(task, 'fakeroot', '1')
=======================

would the fakeroot flag allow do_image_btrfs execute commands that requires root privilege ?

If not what would be the way to execute the mount command ?

I tried "pseudo mount" but it failed same way...

Thanks in advance.

Edson.

Edson Seabra

Principal Engineer

M +1 510 579 0843

1506169147061_OutlookEmoji-1505330244060_ZPELogo_Email.png1e6c5898-d340-4c90-8c28-e559c26bc7d1.png
46757 Fremont Blvd., Fremont, CA 94538
zpesystems.com | Request a Nodegrid Demo



      

4901 - 4920 of 53882