Date   

[yocto-autobuilder2][PATCH] schedulers.py: run performance builds only 2x a day, not 4x

Alexander Kanavin
 

The same builds are included in a-full, so they tend to get queued up
and cause delays in builds completion, as there's only a single worker
allocated to them. Let's run them less frequently to mitigate the delays.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
schedulers.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/schedulers.py b/schedulers.py
index 2e8f3d5..ca63c9f 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -306,11 +306,11 @@ schedulers.append(sched.Nightly(name=3D'nightly-qui=
ck', branch=3D'master', propertie
schedulers.append(sched.Nightly(name=3D'nightly-full', branch=3D'master'=
, properties=3Dparent_default_props('a-full'),
builderNames=3D['a-full'], hour=3D1, minute=3D0, dayOf=
Week=3D6))
=20
-# Run the build performance tests at 3am, 9am, 3pm and 9pm
+# Run the build performance tests at 3am and 3pm
schedulers.append(sched.Nightly(name=3D'nightly-buildperf-ubuntu1604', b=
ranch=3D'master', properties=3Dparent_default_props('buildperf-ubuntu1604=
'),
- builderNames=3D['buildperf-ubuntu1604'], hour=3D[3,9,1=
5,21], minute=3D0))
+ builderNames=3D['buildperf-ubuntu1604'], hour=3D[3,15]=
, minute=3D0))
schedulers.append(sched.Nightly(name=3D'nightly-buildperf-centos7', bran=
ch=3D'master', properties=3Dparent_default_props('buildperf-centos7'),
- builderNames=3D['buildperf-centos7'], hour=3D[3,9,15,2=
1], minute=3D0))
+ builderNames=3D['buildperf-centos7'], hour=3D[3,15], m=
inute=3D0))
=20
# Run the AUH on the 15th of every month
schedulers.append(sched.Nightly(name=3D'nightly-auh', branch=3D'master',=
properties=3Dparent_default_props('auh'),
--=20
2.29.1


Re: Syntax of multiconfig

Khem Raj
 

On Sat, Nov 7, 2020 at 5:53 AM Manuel Wagesreither <ManWag@fastmail.fm> wrote:

Hello all,

I'm trying the become acquainted with the multiconfig feature. I read the relevant chapters in the BitBake User Manual, but some questions I have suggest I did not yet get the whole picture.


1.)
In [1] the following examples are given:

`$ bitbake mc::target mc:target1:target mc:target2:target`

What does the `mc::target` stand for? If I omit the multiconfigname, is the target getting built for all configured multibuildnames?
bitbake mc:target1:target

mc = qualifier keyword used to identify a multiconfig build by bitbake
target1 = name of multiconfig ( e.g. first machine )
target = Firmware image name to be built for this multiconfig



[1] https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#executing-a-multiple-configuration-build
The sample there seems to be wrong, it should just be bitbake
mc:target1:image1 mc:target2:image2


2.)
In [2], the following example is given:

`task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"`
`image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"`

I do not understand why the `from_multiconfig` needs to be given at all. Isn't this redundant information? Per my understanding, when I'm having bitbake bake an image `my-image`, and this image includes a recipe which has such a multiconfig dependency, `from_multiconfig` must be `my-image` as well. So why the need for `from_multiconfig` at all?

I think it wouldn't just add any value, but would actively prevent this recipe/package to be included in images getting built in other configurations.
assuming the default to be current mc target for from_multiconfig is
troublesome when say you build same image but for mc:target2 in such a
case there will be circular dependency. So being explicit enables to
specify m to n dependencies.


So I probably my understanding here is wrong.

[2] https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-enabling-multiple-configuration-build-dependencies


3.)
The links above are using `target_1` and `target_2` for as configuration names. I think this is misleading, as target already refers to the recipe/package or image bitbake is building. How can I contribute to the BitBake documentation?
now documentation has moved to sphinx there is separate mailing list
for docs so git format-patch and send them to
docs@lists.yoctoproject.org

here are archives for this month
https://lists.yoctoproject.org/g/docs/messages?start=11:2020:480

I checked [3] but couldn't see anything referencing the documentation.

[3] https://wiki.yoctoproject.org/wiki/Newcomers#How_to_Contribute


Best regards
Manuel



Re: Trying to compile hping3 from sources #devtool

Khem Raj
 

On Sat, Nov 7, 2020 at 11:57 AM Muralidharan, Vaijayanthi
<vaijayanthi.muralidharan@hpe.com> wrote:

Khem,

Thanks for responding. I am trying to build hping3 from sources. There is only a bb recipe for hping2.
what is your failing recipe called (exact name )

On 11/6/20, 9:42 PM, "Khem Raj" <raj.khem@gmail.com> wrote:

whats the name of your recipe ? secondly hping3 requires libtcl8.6.so
seems to be troublesome because its asking
for devel package not the original library, I wonder why, can you find
out the linker cmdline where ping3 is getting linked ?

On Fri, Nov 6, 2020 at 6:31 PM Vaijayanthi <vaijayanthi@silver-peak.com> wrote:
>
> Hi, I am using devtool add hping3 https://github.com/antirez/hping to add hping3 as part of our custom image. Here is my recipe:
>
> # Recipe created by recipetool
>
> # This is the basis of a recipe and may need further editing in order to be fully functional.
>
> # (Feel free to remove these comments when editing.)
>
>
>
> # WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
>
> # your responsibility to verify that the values are complete and correct.
>
> #
>
> # The following license files were not able to be identified and are
>
> # represented as "Unknown" below, you will need to check them yourself:
>
> # COPYING
>
> LICENSE = "GPLv2"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=3728a6c4c9630a9e796ad4b82dacd887"
>
>
>
> SRC_URI = "git://github.com/antirez/hping;protocol=https"
>
>
>
> # Modify these as desired
>
> PV = "1.0+git${SRCPV}"
>
> SRCREV = "3547c7691742c6eaa31f8402e0ccbb81387c1b99"
>
>
>
> S = "${WORKDIR}/git"
>
>
>
> #DEPENDS = "libpcap"
>
> RDEPENDS_${PN} += " libpcap tcl-lib tcl"
>
>
>
> # NOTE: no Makefile found, unable to determine what needs to be done
>
>
>
> do_configure () {
>
> # Specify any needed configure commands here
>
> CONFIGOSTYPE="LINUX" ./configure
>
> }
>
>
>
> do_compile () {
>
> # Specify compilation commands here
>
> make
>
> }
>
> do_install() {
>
> #install -Dm755 ${B}/libpcap.so.0.8 ${D}${libdir}/libpcap.so.0.8
>
> #ln -sf libpcap.so.0.8 ${D}${libdir}/libpcap.so
>
> #install -Dm755 ${B}/libtcl8.6.so ${D}${libdir}/libtcl8.6.so
>
> #ln -sf libtcl8.6.so ${D}${libdir}/libtcl8.6.so
>
> install -m 0755 -d ${D}${sbindir} ${D}/${mandir} ${D}${docdir}/hping3
>
> install -m 0755 hping3 ${D}/${sbindir}
>
> install -m 0644 docs/hping3.8 ${D}/${mandir}
>
> install -m 0644 docs/HPING2-HOWTO.txt docs/HPING2-IS-OPEN \
>
> docs/MORE-FUN-WITH-IPID docs/SPOOFED_SCAN.txt \
>
> docs/AS-BACKDOOR docs/APD.txt ${D}${docdir}/hping3
>
> }
>
>
>
> #INSANE_SKIP_${PN}-dev = "ldflags"
>
> #INSANE_SKIP_${PN} = "ldflags"
>
> #INSANE_SKIP_${PN} += "file-rdeps dev-deps"
>
>
> How do I add this to my custom bitbake layer? Also, make is complaining about
> ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libpcap.so.0.8()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
> ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libtcl8.6.so()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
> ERROR: hping3-1.0+git999-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
>
> Please let me know what I should I do next to integrate this recipe with my custom meta layer and also, address the make failures.
>
>
>
>
>


Re: Syntax of multiconfig

Manuel Wagesreither
 

Anwering my own post now.

Am Sa, 7. Nov 2020, um 14:53, schrieb Manuel Wagesreither:
3.)
The links above are using `target_1` and `target_2` for as configuration names. I think this is misleading, as target already refers to the recipe/package or image bitbake is building. How can I contribute to the BitBake documentation?

I checked [3] but couldn't see anything referencing the documentation.


I just realized there is 'poky/documentation' which holds the documentation source code. Didn't see that before.


Error when building eSDK for a `docker load`able tarball

Manuel Wagesreither
 

Hello all,

I would like to set up Yocto to build my application and produce
- an tarball fit to get `docker load`ed,
- an image fit to run in qemuarm,
- an image fit to run in qemux86-64,
- an image fit to run in a Raspberry Pi 4,
as well as eSDKs for each of the platforms mentioned.

Creating the tarball and images already works fine, but I'm facing difficulties with the eSDK for the docker-tarball. It fails with the error message noted below. The eSDK build for qemuarm, qemux86-64 and the Raspberry Pi 4 image completes without errors.

For building the tarball I followed the approach presented by Josef a.k.a. The Yocto Jester.

This is my image definition: https://youtu.be/jPbcQEffzJo?t=1028
And this my machine configuration: https://youtu.be/jPbcQEffzJo?t=1338

This is the distro configuration:
```
require conf/distro/poky.conf

DISTRO = "bora"
DISTRO_NAME = "Bora Horza Gobuchul (Poky-based)"
DISTRO_VERSION = "1.0.0"
DISTRO_CODENAME = "dunfell"

# Override these in poky-based distros
POKY_DEFAULT_DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = "packagegroup-core-boot"
POKY_DEFAULT_EXTRA_RRECOMMENDS = ""

# Simply copy these lines from the manual
# DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = ""
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
```
It is a duplicate of to the distro config I use for qemu and Raspberry Pi targets, but has the `DISTRO_FEATURES_append = " systemd"` commented-out. This is because initially, the tarball included some systemd units which I felt there is no need for in a docker container.


This is the error message I get when building an eSDK: (Sorry for the lengthy paste, but I really don't know which part is the important one. The "Shell environment set up for builds" really shows up AFTER the first error message, otherwise I would have skipped it.)
```
ERROR: bora-container-1.0-r0 do_populate_sdk_ext: Failed to generate filtered task list for extensible SDK:

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
ERROR: bitbake failed:
Parsing recipes...done.
Parsing of 2201 .bb files complete (0 cached, 2201 parsed). 3288 targets, 157 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/2.8/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab
Initialising tasks...done.
Sstate summary: Wanted 503 Found 501 Missed 2 Current 0 (99% match, 0% complete)
WARNING: The glibc:do_prepare_recipe_sysroot sig is computed to be e7647c2eecc7480b4072cc50e9a999ccd161d45d6862342de994ae93e8f306e4, but the sig is locked to b6c303c7ead3bc98509abd2db62cef88b1ee8a08a760646963adfa910a0ea78d in SIGGEN_LOCKEDSIGS_t-core2-64
The glibc:do_configure sig is computed to be a32c9df42d2aae537e79f1b94e5b1448e978c8e1ff904bb35cb55e9241d80cb0, but the sig is locked to d4df7745109eca8d320cdfa97a2d9ec4512e71c15ccbbd9dfd96edfb110a8d32 in SIGGEN_LOCKEDSIGS_t-core2-64
The glibc:do_compile sig is computed to be 8061b4dcee2786866c843c636733dbcb7aec747751613fbb0c98cdbcd68e246b, but the sig is locked to 633aa602880e141d7a0f776971199f9f594295107ef9e4384e3dbb35a85c7ebe in SIGGEN_LOCKEDSIGS_t-core2-64

[...]

ERROR: Task linux-dummy.do_fetch attempted to execute unexpectedly
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa, unihash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844, taskhash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete, unihash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b, taskhash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b
This is usually due to missing setscene tasks. Those missing in this build were: {'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete',
'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa'}
ERROR: Task (/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch) failed with exit code 'setscene whitelist'
NOTE: Tasks Summary: Attempted 142 tasks of which 141 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: Logfile of failure stored in: /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/temp/log.do_populate_sdk_ext.8096
ERROR: Task (/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2358 tasks of which 2356 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
```

Thank you!
Best regards,
Manuel


Syntax of multiconfig

Manuel Wagesreither
 

Hello all,

I'm trying the become acquainted with the multiconfig feature. I read the relevant chapters in the BitBake User Manual, but some questions I have suggest I did not yet get the whole picture.


1.)
In [1] the following examples are given:

`$ bitbake mc::target mc:target1:target mc:target2:target`

What does the `mc::target` stand for? If I omit the multiconfigname, is the target getting built for all configured multibuildnames?

[1] https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#executing-a-multiple-configuration-build


2.)
In [2], the following example is given:

`task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"`
`image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"`

I do not understand why the `from_multiconfig` needs to be given at all. Isn't this redundant information? Per my understanding, when I'm having bitbake bake an image `my-image`, and this image includes a recipe which has such a multiconfig dependency, `from_multiconfig` must be `my-image` as well. So why the need for `from_multiconfig` at all?

I think it wouldn't just add any value, but would actively prevent this recipe/package to be included in images getting built in other configurations.

So I probably my understanding here is wrong.

[2] https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-enabling-multiple-configuration-build-dependencies


3.)
The links above are using `target_1` and `target_2` for as configuration names. I think this is misleading, as target already refers to the recipe/package or image bitbake is building. How can I contribute to the BitBake documentation?

I checked [3] but couldn't see anything referencing the documentation.

[3] https://wiki.yoctoproject.org/wiki/Newcomers#How_to_Contribute


Best regards
Manuel


Re: Trying to compile hping3 from sources #devtool

Khem Raj
 

whats the name of your recipe ? secondly hping3 requires libtcl8.6.so
seems to be troublesome because its asking
for devel package not the original library, I wonder why, can you find
out the linker cmdline where ping3 is getting linked ?

On Fri, Nov 6, 2020 at 6:31 PM Vaijayanthi <vaijayanthi@silver-peak.com> wrote:

Hi, I am using devtool add hping3 https://github.com/antirez/hping to add hping3 as part of our custom image. Here is my recipe:

# Recipe created by recipetool

# This is the basis of a recipe and may need further editing in order to be fully functional.

# (Feel free to remove these comments when editing.)



# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is

# your responsibility to verify that the values are complete and correct.

#

# The following license files were not able to be identified and are

# represented as "Unknown" below, you will need to check them yourself:

# COPYING

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=3728a6c4c9630a9e796ad4b82dacd887"



SRC_URI = "git://github.com/antirez/hping;protocol=https"



# Modify these as desired

PV = "1.0+git${SRCPV}"

SRCREV = "3547c7691742c6eaa31f8402e0ccbb81387c1b99"



S = "${WORKDIR}/git"



#DEPENDS = "libpcap"

RDEPENDS_${PN} += " libpcap tcl-lib tcl"



# NOTE: no Makefile found, unable to determine what needs to be done



do_configure () {

# Specify any needed configure commands here

CONFIGOSTYPE="LINUX" ./configure

}



do_compile () {

# Specify compilation commands here

make

}

do_install() {

#install -Dm755 ${B}/libpcap.so.0.8 ${D}${libdir}/libpcap.so.0.8

#ln -sf libpcap.so.0.8 ${D}${libdir}/libpcap.so

#install -Dm755 ${B}/libtcl8.6.so ${D}${libdir}/libtcl8.6.so

#ln -sf libtcl8.6.so ${D}${libdir}/libtcl8.6.so

install -m 0755 -d ${D}${sbindir} ${D}/${mandir} ${D}${docdir}/hping3

install -m 0755 hping3 ${D}/${sbindir}

install -m 0644 docs/hping3.8 ${D}/${mandir}

install -m 0644 docs/HPING2-HOWTO.txt docs/HPING2-IS-OPEN \

docs/MORE-FUN-WITH-IPID docs/SPOOFED_SCAN.txt \

docs/AS-BACKDOOR docs/APD.txt ${D}${docdir}/hping3

}



#INSANE_SKIP_${PN}-dev = "ldflags"

#INSANE_SKIP_${PN} = "ldflags"

#INSANE_SKIP_${PN} += "file-rdeps dev-deps"


How do I add this to my custom bitbake layer? Also, make is complaining about
ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libpcap.so.0.8()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libtcl8.6.so()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
ERROR: hping3-1.0+git999-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Please let me know what I should I do next to integrate this recipe with my custom meta layer and also, address the make failures.





Trying to compile hping3 from sources #devtool

Vaijayanthi
 

Hi, I am using devtool add hping3 https://github.com/antirez/hping to add hping3 as part of our custom image. Here is my recipe:

# Recipe created by recipetool

# This is the basis of a recipe and may need further editing in order to be fully functional.

# (Feel free to remove these comments when editing.)

 

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is

# your responsibility to verify that the values are complete and correct.

#

# The following license files were not able to be identified and are

# represented as "Unknown" below, you will need to check them yourself:

#   COPYING

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=3728a6c4c9630a9e796ad4b82dacd887"

 

SRC_URI = "git://github.com/antirez/hping;protocol=https"

 

# Modify these as desired

PV = "1.0+git${SRCPV}"

SRCREV = "3547c7691742c6eaa31f8402e0ccbb81387c1b99"

 

S = "${WORKDIR}/git"

 

#DEPENDS = "libpcap"

RDEPENDS_${PN} += " libpcap tcl-lib tcl"

 

# NOTE: no Makefile found, unable to determine what needs to be done

 

do_configure () {

    # Specify any needed configure commands here

    CONFIGOSTYPE="LINUX" ./configure

}

 

do_compile () {

    # Specify compilation commands here

    make

}

do_install() {

    #install -Dm755 ${B}/libpcap.so.0.8 ${D}${libdir}/libpcap.so.0.8

    #ln -sf libpcap.so.0.8 ${D}${libdir}/libpcap.so

    #install -Dm755 ${B}/libtcl8.6.so ${D}${libdir}/libtcl8.6.so

    #ln -sf libtcl8.6.so ${D}${libdir}/libtcl8.6.so

    install -m 0755 -d ${D}${sbindir} ${D}/${mandir} ${D}${docdir}/hping3

    install -m 0755 hping3 ${D}/${sbindir}

    install -m 0644 docs/hping3.8 ${D}/${mandir}

    install -m 0644 docs/HPING2-HOWTO.txt docs/HPING2-IS-OPEN \

        docs/MORE-FUN-WITH-IPID docs/SPOOFED_SCAN.txt \

        docs/AS-BACKDOOR docs/APD.txt ${D}${docdir}/hping3

}

 

#INSANE_SKIP_${PN}-dev = "ldflags"

#INSANE_SKIP_${PN} = "ldflags"

#INSANE_SKIP_${PN} += "file-rdeps dev-deps"

 
How do I add this to my custom bitbake layer? Also, make is complaining about
ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libpcap.so.0.8()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue: /usr/sbin/hping3 contained in package hping3 requires libtcl8.6.so()(64bit), but no providers found in RDEPENDS_hping3? [file-rdeps]
ERROR: hping3-1.0+git999-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Please let me know what I should I do next to integrate this recipe with my custom meta layer and also, address the make failures.



Re: I am compiling scikit-learn python package for arm board but I am facing some errors. #python

William Jacob
 

adding BBCLASSEXTEND = "native" in lapack recipe will give me another error ERROR: Nothing PROVIDES 'gcc-runtime-native'

Is there a another way to make lapack native


Re: I am compiling scikit-learn python package for arm board but I am facing some errors. #python

Khem Raj
 

On Fri, Nov 6, 2020 at 2:06 AM <william.jacob@sama.com.sg> wrote:

Hi,
I am compiling scikit-learn python package for arm board but I am facing below errors

william@william:~/sagitta/build-as371$ bitbake python3-scikit-learn
Loading cache: 100% |##########################################################################################################################################################| Time: 0:00:01
Loaded 3665 entries from dependency cache.
Parsing recipes: 100% |########################################################################################################################################################| Time: 0:00:07
Parsing of 2414 .bb files complete (2403 cached, 11 parsed). 3605 targets, 374 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'lapack-native' (but virtual:native:/home/william/sagitta/meta/recipes-devtools/python-scipy/python3-scipy_1.5.2.bb DEPENDS on or otherwise requires it). Close matches:
tclap-native
lua-native
atk-native
ERROR: Required build target 'python3-scikit-learn' has no buildable providers.
Missing or unbuildable dependency chain was: ['python3-scikit-learn', 'python3-scipy-native', 'lapack-native']




It seems lapack is not compiled native because of it I am facing the issue
right, add

BBCLASSEXTEND = "native" in lapack recipe and fix the needed bits to
get it going.

Thanks
William Jacob




I am compiling scikit-learn python package for arm board but I am facing some errors. #python

William Jacob
 

Hi,
I am compiling scikit-learn python package for arm  board but I am facing below errors
 
william@william:~/sagitta/build-as371$ bitbake python3-scikit-learn
Loading cache: 100% |##########################################################################################################################################################| Time: 0:00:01
Loaded 3665 entries from dependency cache.
Parsing recipes: 100% |########################################################################################################################################################| Time: 0:00:07
Parsing of 2414 .bb files complete (2403 cached, 11 parsed). 3605 targets, 374 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'lapack-native' (but virtual:native:/home/william/sagitta/meta/recipes-devtools/python-scipy/python3-scipy_1.5.2.bb DEPENDS on or otherwise requires it). Close matches:
  tclap-native
  lua-native
  atk-native
ERROR: Required build target 'python3-scikit-learn' has no buildable providers.
Missing or unbuildable dependency chain was: ['python3-scikit-learn', 'python3-scipy-native', 'lapack-native']




It seems lapack is not compiled native because of it I am facing the issue
 
Thanks 
William Jacob
 


Re: Why python3 is build native in yocto ??? #python

William Jacob
 

I am sorry , I will explain in detail.

so what I required is that my python3 binary should be present in both recipe-sysroot and recipe-sysroot-native both as I need to build some python packages using python present in the recipe-sysroot directory.Currently my python binary is present only in recipe-sysroot-native directory.

 

If you want more details please let me know


Re: Why python3 is build native in yocto ??? #python

Ross Burton
 

On Fri, 6 Nov 2020 at 08:23, <william.jacob@sama.com.sg> wrote:
I am trying to compile python package for yocto and I found python3 (python3.7) is build native then it cross compiled.I want to know why it is done like this in python.
The python3 build for target doesn't directly depend on python3-native.

Some recipes do depend on python3-native (although by definition there
is a python3 on your host) as they need to run non-standard Python
modules as part of their build. We don't want to assume that you've
installed all of these modules (as the list is ever growing) and we
don't want to assume that you've installed python3-dev on the host (as
we want to have minimal build requirements, and C modules are not
portable between Python versions).

Basically I want python3 binary cross compiled for arm architecture should be available in recipe-sysroot and recipe-sysroot-native directory . Right now it is available only in recipe-sysroot-native.
Please explain what you are actually trying to do. For 99% of python
modules, simply inheriting setuptool3 or even better pypi is
sufficient. If a package has hand-coded Python detection then it gets
a lot more complicated as Python doesn't have great support for
cross-compiling, and most people writing the build scripts don't
consider it at all.

Ross


Re: Why python3 is build native in yocto ??? #python

Josef Holzmayr
 

Howdy!

Am Fr., 6. Nov. 2020 um 09:23 Uhr schrieb <william.jacob@sama.com.sg>:

Hi,
I am trying to compile python package for yocto and I found python3 (python3.7) is build native then it cross compiled.I want to know why it is done like this in python.

Basically I want python3 binary cross compiled for arm architecture should be available in recipe-sysroot and recipe-sysroot-native directory . Right now it is available only in recipe-sysroot-native.
I'm sorry, but I don't really understand the question. You say you
want python3 crosscompiled. This will happen if something that goes
into your image depends/rdepends on it, or if you explicitly add it to
said image via IMAGE_INSTALL. Does this not work for you?

Greetz

Thanks

William Jacob


Why python3 is build native in yocto ??? #python

William Jacob
 

Hi,
I am trying to compile python package for yocto and I found  python3 (python3.7) is  build native then it cross compiled.I want to know why it is done like this in python.

Basically I want python3 binary cross compiled for arm architecture should be available in recipe-sysroot and  recipe-sysroot-native directory . Right now it is available only in recipe-sysroot-native.

 

Thanks 

William Jacob


Re: : how to fix "do not ask to insatll a package providing xxxx"?

Chen Qi
 

It's basically about some package conflict & absence.

You could provide more info such as you bb file, the layers you're using, the result of `grep packagegroup-obmc-apps-network', etc.

Regards,
Chen Qi

On 11/05/2020 09:10 PM, ouyangxuan10@... wrote:
Dear all,

I build a libarary in other project. And add a bb file in yocto to add to my yocto project, but it appear error.

who can tell me how to fix it?

thanks,
Byron



 







What part of do_package automatically scoops up source files?

Sean McKay
 

Hi all,

 

I’m hoping that someone can just answer this off the top of their head – don’t bother if you have to dig much.

We’ve got a C recipe (built with cmake, if that’s relevant) that seems to be otherwise identical to our other C recipes, but for some reason it’s not picking up the source code during the do_package step automagically like our other recipes do.

Anyone happen to know offhand where in the do_package code that gets scooped up so I can focus my attention there and on the variables used therein? (my run.do_package files for those tasks are about 3k lines of python code. And a quick glance through seemed to yield obvious answers that don’t seem to match what’s coming out in log.do_package)

 

We’re on Zeus at the moment.

 

Cheers!

-Sean McKay

 


[meta-zephyr][PATCH ] zephyr: Yocto Image Tests Fix

yock.gen.mah@...
 

From: yockgenm <yock.gen.mah@intel.com>

Fix bug on Image Test, previously the Image Tests was not working due to update on Yocto Image Test Framework.

The fix has rewritten and restructured existing Image Tests code to latest Yocto testimage class requirement to make meta-zephyr able to run Image Tests as expected.

Signed-off-by: yockgenm <yock.gen.mah@intel.com>
---
README.txt | 14 +++++++++-----
lib/oeqa/controllers/__init__.py | 3 ---
lib/oeqa/controllers/zephyrtargetcontrol.py | 24 +++++++++++++-----------
lib/oeqa/runtime/{ => cases}/zephyr.py | 15 ++++++++++++---
lib/oeqa/utils/qemuzephyrrunner.py | 12 ++++++------
5 files changed, 40 insertions(+), 28 deletions(-)
rename lib/oeqa/runtime/{ => cases}/zephyr.py (80%)

diff --git a/README.txt b/README.txt
index a02659a..6463339 100644
--- a/README.txt
+++ b/README.txt
@@ -49,24 +49,28 @@ Building and Running Zephyr Tests
Presently only toolchains for ARM, x86, IAMCU and Nios2 are supported.
(For ARM we use CortexM3 toolchain)

+To run Zephyr Test using Yocto Image Tests, ensure following in local.conf:
+
+ INHERIT += "testimage"
+
You can build and test an individual existing Zephyr test.
This is done by appending the actual test name to the "zephyr-kernel-test",
for example:

- $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-test_sleep
- $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-test_sleep -ctestimage
+ $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-sleep
+ $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-sleep -c testimage

You can also build and run all Zephyr existing tests (as listed in the file
zephyr-kernel-test.inc). For example:

$ MACHINE=qemu-x86 bitbake zephyr-kernel-test-all
- $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-all -ctestimage
+ $ MACHINE=qemu-x86 bitbake zephyr-kernel-test-all -c testimage
or
$ MACHINE=qemu-cortex-m3 bitbake zephyr-kernel-test-all
- $ MACHINE=qemu-cortex-m3 bitbake zephyr-kernel-test-all -ctestimage
+ $ MACHINE=qemu-cortex-m3 bitbake zephyr-kernel-test-all -c testimage
or
$ MACHINE=qemu-nios2 bitbake zephyr-kernel-test-all
- $ MACHINE=qemu-nios2 bitbake zephyr-kernel-test-all -ctestimage
+ $ MACHINE=qemu-nios2 bitbake zephyr-kernel-test-all -c testimage


Contributing
diff --git a/lib/oeqa/controllers/__init__.py b/lib/oeqa/controllers/__init__.py
index 8eda927..e69de29 100644
--- a/lib/oeqa/controllers/__init__.py
+++ b/lib/oeqa/controllers/__init__.py
@@ -1,3 +0,0 @@
-# Enable other layers to have modules in the same named directory
-from pkgutil import extend_path
-__path__ = extend_path(__path__, __name__)
diff --git a/lib/oeqa/controllers/zephyrtargetcontrol.py b/lib/oeqa/controllers/zephyrtargetcontrol.py
index 84ba3be..8e94cb5 100644
--- a/lib/oeqa/controllers/zephyrtargetcontrol.py
+++ b/lib/oeqa/controllers/zephyrtargetcontrol.py
@@ -11,11 +11,16 @@ from oeqa.utils.qemuzephyrrunner import QemuZephyrRunner
supported_fstypes = ['elf']

class QemuTargetZephyr(OETarget):
- def __init__(self, logger, ip, server_ip, target_modules_path,
- timeout=300, user='root',
- port=None, machine='', rootfs='', kernel='', kvm=False,
- dump_dir='', dump_host_cmds='', display='', bootlog='',
- tmpdir='', dir_image='', boottime=60):
+ def __init__(self, logger, ip, server_ip,
+ machine='', rootfs='', tmpdir ='',dir_image ='',display=None,
+ kernel='',boottime=60,bootlog='',kvm=False,slirp=False,
+ dump_dir='',serial_ports=0,ovmf=None,target_modules_path='',powercontrol_cmd='',powercontrol_extra_args='',
+ serialcontrol_cmd=None,serialcontrol_extra_args='',testimage_dump_target='' ):
+
+ timeout = 300
+ user = 'root'
+ port = serial_ports
+ dump_host_cmds = testimage_dump_target

super(QemuTargetZephyr, self).__init__(logger, ip, server_ip, timeout,
user, port)
@@ -42,19 +47,16 @@ class QemuTargetZephyr(OETarget):
deploy_dir_image=dir_image, display=display,
logfile=self.qemulog, boottime=boottime,
use_kvm=kvm, dump_dir=dump_dir,
- dump_host_cmds=dump_host_cmds)
+ dump_host_cmds=dump_host_cmds,
+ logger = logger)


- def start(self, params=None, extra_bootparams=None):
+ def start(self, params=None, runqemuparams=None, extra_bootparams=None):
if self.runner.start(params, extra_bootparams=extra_bootparams):
self.ip = self.runner.ip
self.server_ip = self.runner.server_ip
else:
- self.stop()
raise RuntimeError("FAILED to start qemu - check the task log and the boot log")

- def stop(self):
- self.runner.stop()
-
def serial_readline(self):
return self.runner.serial_readline()
diff --git a/lib/oeqa/runtime/zephyr.py b/lib/oeqa/runtime/cases/zephyr.py
similarity index 80%
rename from lib/oeqa/runtime/zephyr.py
rename to lib/oeqa/runtime/cases/zephyr.py
index 96a119a..8751aba 100644
--- a/lib/oeqa/runtime/zephyr.py
+++ b/lib/oeqa/runtime/cases/zephyr.py
@@ -1,11 +1,20 @@
-import unittest
-from oeqa.oetest import oeRuntimeTest
+#
+# SPDX-License-Identifier: MIT
+#

-class ZephyrTest(oeRuntimeTest):
+from subprocess import Popen, PIPE

+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.oetimeout import OETimeout
+
+class ZephyrTest(OERuntimeTestCase):
+
+ @OETimeout(120)
def test_boot_zephyr(self):
+
success = False
logfile = self.target.qemurunnerlog
+
while True:
line = self.target.serial_readline().decode("utf-8")

diff --git a/lib/oeqa/utils/qemuzephyrrunner.py b/lib/oeqa/utils/qemuzephyrrunner.py
index 9d7badb..0308f1e 100644
--- a/lib/oeqa/utils/qemuzephyrrunner.py
+++ b/lib/oeqa/utils/qemuzephyrrunner.py
@@ -18,10 +18,11 @@ from oeqa.utils.qemurunner import QemuRunner

class QemuZephyrRunner(QemuRunner):

- def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, boottime, dump_dir, dump_host_cmds, use_kvm):
+ def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, boottime, dump_dir, dump_host_cmds, use_kvm, logger):
+
QemuRunner.__init__(self, machine, rootfs, display, tmpdir,
deploy_dir_image, logfile, boottime, None,
- None, use_kvm)
+ None, use_kvm, logger)

# Popen object for runqemu
self.socketfile = tempfile.NamedTemporaryFile()
@@ -59,7 +60,8 @@ class QemuZephyrRunner(QemuRunner):
return False
return True

- def start(self, params=None, extra_bootparams=None):
+ def start(self, params=None,runqemuparams=None, extra_bootparams=None):
+
if not os.path.exists(self.tmpdir):
bb.error("Invalid TMPDIR path %s" % self.tmpdir)
#logger.error("Invalid TMPDIR path %s" % self.tmpdir)
@@ -83,7 +85,7 @@ class QemuZephyrRunner(QemuRunner):
qemu_machine_args = '-machine lm3s6965evb'
elif 'x86' in self.machine:
qemu_binary = 'qemu-system-i386'
- qemu_machine_args = '-machine type=pc-0.14'
+ qemu_machine_args = '-machine type=pc-1.3 -no-acpi -nographic -cpu qemu32,+nx,+pae'
elif 'nios2' in self.machine:
qemu_binary = 'qemu-system-nios2'
qemu_machine_args = '-machine altera_10m50_zephyr'
@@ -155,5 +157,3 @@ class QemuZephyrRunner(QemuRunner):

self.log(line)
return line
-
-
--
2.7.4


Re: Reproducible builds and RPM packages

Anders Montonen
 



On 4 Nov 2020, at 23:23, Randy MacLeod <randy.macleod@...> wrote:

On 2020-11-03 6:16 a.m., Anders Montonen wrote:
Hi,

When going from Zeus to Dunfell, I noticed that all files on the rootfs had timestamps long in the past, which I assume is from reproducible builds now being on by default. While that is a good thing, running “rpm -V” on any installed package now reports that the mtime differs. Is this the intentional behavior?

Hi Anders,

I haven't played with that for a while but I'm pretty sure the answer is yes, it's intentional.

You can read about reproducible builds here:
   https://wiki.yoctoproject.org/wiki/Reproducible_Builds
and compare to the source if needed:
   https://git.openembedded.org/openembedded-core/tree/meta/classes/reproducible_build.bbclass?id=189630ca6cdf7ceb6cf9b8f9d86c58997f505efc&h=dunfell



Just to be clear, I’m referring to the RPM metadata. If you build a package, and then run "rpm -q --qf '[%{FILENAMES} %{FILEMTIMES}\n]' -p package” on the output, the listed timestamps will not match either SOURCE_DATE_EPOCH, or REPRODUCIBLE_TIMESTAMP_ROOTFS. When you build an image, the timestamps in the filesystem will not be consistent with the timestamps in the RPM database, leading to errors if you try to verify an installed package. I would consider this a bug or an oversight.

Regards,
Anders Montonen


Re: #yocto overriding a task in a recipe #yocto

Monsees, Steven C (US)
 

Thanks... that's what I saw this morning...

-----Original Message-----
From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On Behalf Of Khem Raj
Sent: Thursday, November 05, 2020 12:34 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto overriding a task in a recipe

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 11/5/20 4:13 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
If a recipe has a task "do_something() {...stuff...}", and for some reason
I do not want that task to execute its steps, but a different series
of steps, can I over-ride the task from a .bbapend by supplying the
same routine with different steps ("do_something() {...new stuff...}") ?
it depends, if the task is having appends etc. they will still be applied. but main task you can override.

Thanks,

Steve




2561 - 2580 of 53836