User:MichaelHalstead

From Yocto Project
Jump to: navigation, search

Testing watchlists again and again and again and again and again

IDPStatusSeverityProductSummary (347 tasks)  
11914*
11914 Just realized that this is ross/mut so it may be invalid. Leaving as it is, so decision on its status is done at triage
HighIN PROGRESS REVIEWnormalAutomated Runtime Testinggpg: signing failed due to lack of memory on nightly-oe-selftest 
11452*
11452

Hi all - finally catching up to this

Adding a flag to the OE layer index indicating the PASS level from RP's new script is by far the sanest thing to do. It would then be easy to derive a YP-specific layer index. Note that this does not necessarily reflect YP Compatible status, though, as YP Compatible is a branding program, not a technical compatibility program.

I can predict issues within the OE community around adding a YP flag to an OE index. However, Philip's blessing goes a long way toward alleviating that.

For the YP website we are currently planning to scrub the list of BSPs from the layer index by comparing it to a list of official "YP Compatible" (branding program) BSPs.

I'd be happy to work on any initiative on this going forward.
HighNEWenhancementLayer IndexCreate a layers.yoctoproject.org site 
11877*
11877 has use in networking stacks, although I am not very excited about new ABIs
HighNEWenhancementOE-CoreAdd aarch64 ilp32 framework[1]
11898*
11898

(In reply to comment #1) > Created attachment 3947 [details] > unit test version of knotty to demonstrate defect > > Attached is a simple replicator of the server timeout using knotty (to avoid > the extra steps of setting up Toaster). > > 1) Place the attached "knotty_11898.py" into "bitbake/lib/bb/ui" > > 2) Observe the simple server query added under "bb.event.ParseProgress": > > if isinstance(event, bb.event.ParseProgress): > > ### TRY TO GET VALUE FROM BB SERVER ### > print("vvv BEFORE SERVER.RUNCOMMAND() vvv") > tmp_dir = server.runCommand(["getVariable", "TMPDIR"])[0] > print("^^^ AFTER SERVER.RUNCOMMAND() ^^^") > > This is an example of a simple query that Toaster has been making for years > in processing the bb events. > > 3) Run these commands: > > [poky]$ . ./oe-init-build-env > [build]$ rm -rf cache/* tmp/ sstate-control/ > [build]$ bitbake -u knotty_11898 quilt-native > NOTE: Starting bitbake server... > WARNING: Host distribution "ubuntu-14.04" has not been validated with this > version of the build system; you may possibly experience unexpected > failures. It is recommended that you use a tested distribution. > vvv BEFORE SERVER.RUNCOMMAND() vvv | ETA: > --:--:-- > Timeout while waiting for a reply from the bitbake server > [build]$ > > > NOTE: I did not need to do the "rm -rf ..." to replicate this error, but you > may need to.

Thanks David, this really does help illustrate the problem. The issue appears to be multiple nested commands. I'll see what I can figure out about what is going on but this should speed things up.
HighNEWmajorBitBakebitbake server timeout on first 'server.runCommand' call after build starts 
11903*
11903 I should add, the "starting bitbake server pid ..." that we have currently is a kind of separation, it's just not as easily visible/parsable as something like "----#### bitbake server startup ####----" (or something more appropriate).
HighNEWnormalBitBakeServer log needs separation between instances 
11929*
11929 Its trying to connect two UIs to one server which isn't supported. I agree the error should be better.
HighNEWnormalBitBakepreparing tinfoil twice with config_only=False is failing 
11140*
11140 The fix is now implemented in OE-Patchwork. Thanks to Michael for the quick response.
HighRESOLVEDmajorPatchwork/Patchtestpatchwork: Web UI throws an error instead of series view when user is not authenticated 
11467*HighRESOLVEDenhancementIoT Reference OS Kitintegrate a system update solution 
11469*
11469 IoT RefKit should include enablers for using core functionality of both Wayland/Weston and X11/OpenGL for graphics output.
HighRESOLVEDenhancementIoT Reference OS KitGraphics support for IoT Reference Kit 
11707*
11707

This is a workaround to avoid filesystem corruption

http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/commit/?h=master-next&id=beda622775cbdce6315afc0a46aa6c3f7e5cbb9d

The commit message describes in detail the problem and findings.

the commit is in master-next so will be merged into master as soon as the testing finishes.
HighRESOLVEDnormalPatchwork/Patchtestopenembedded-core share folder between host and guest get corrupted 
11834*HighRESOLVEDnormalBitBakeif you have a bad layer in bblayers, bitbake server connection hangs 
11848*HighRESOLVEDenhancementAutoBuilderRun checkpkg oe-selftest separately from nightly/nightly-oe-selftest on a weekly basis 
11913*HighRESOLVEDnormalAutomated Runtime Testingmusl image launch with runqemu did not reach the login banner 
11924*
11924 We have bug #11848 in place to move this test out of the default oe-selftest invocations on the Yocto Autobuilder. The reason we're doing that is that we constantly see these kind of failures which appear to be transient, or at least don't fail consistently (the set of failing recipes is inconsistent).
HighRESOLVEDnormalAutomated Runtime Testingtest_checkpkg (distrodata.Distrodata) failing in several packages 
11475*
11475 Implement an interactive, graphics-based demo for a simple rock-paper-scissors demo. Use a camera (RealSense camera or a normal web camera) to detect the hand sign {rock, paper, scissors} that the user does. Match that against a random play made by the computer. Indicate on the screen how the platform has identified the hand sign (for example using a bounding box).
LowIN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS KitRock-paper-scissors demo based on RefKit computer vision profile 
11922LowIN PROGRESS IMPLEMENTATIONnormalOE-Corelibgmp: improve binary reproducibility 
11142*
11142

Several of the tests in oe-selftest invoke bitbake with recipe targets, in many cases building relatively complex recipes with non-trivial dependency chains.

For several tests fetching and building isn't strictly necessary and the needs of the test could be as easily met with an artificial recipe in meta-selftest which uses a local file as its source, one immediate example which prompted this report is oescripts.TestScripts.test_cleanup_workdir

We should review the targets bitbake is invoked with in oe-selftest and aim to:

  • use artificial recipes, with a local file source, where possible
  • reduce reliance on recipes being present in oe-core, i.e. where practical oe-selftest should use recipes contained in meta-selftest to ensure the results are easily repeatable and independent of unrelated changes to oe-core i.e. the recent (at time of reporting) removal of GPLv2 recipes.
LowNEWenhancementAutomated Build TestingUse artificial recipes for oe-selftest where possible to reduce work 
11480*
11480 Initial version of the recipe now exists (https://github.com/ipuustin/intel-iot-refkit/commit/2163bc0343e9aa5540b8ebcbb85638e1767412da). The performance numbers on IoT platforms don't look too good.
LowNEWenhancementIoT Reference OS KitIntegrate YOLO to Refkit 
11499*
11499 Check what is missing from computer vision profile to enable Speaker Recognition demo and integrate those. At minimum also include documentation for demo setup, possibly also add audio and classification front ends in Python.
LowNEWenhancementIoT Reference OS KitSpeaker recognition neural network demo 
11670*
11670

When we use BBCLASSEXTEND, we create "variants" (a term used in a number of different places) of the recipe, however in the file path namespace they end up as "virtual:...". This probably wouldn't be so bad except that "virtual/..." is a commonly used naming convention for virtual targets and is completely unrelated to this, which could be confusing.

We could simply rename the virtual: prefix - it's mostly internal to bitbake, although it is printed out on the console and in logs.
LowNEWenhancementBitBakeImprove terminology around BBCLASSEXTEND 
11918*
11918 "bushbug" reports CFLAGS used to build the bash image. The flags contain hardcoded path to the host build environment, via the "-fdebug-prefix-map=", hence two builds in two different folders will be binary different. Fix this by removing all "-fdebug-prefix-map" flags. (brought in via DEBUG_PREFIX_MAP).
LowNEWnormalOE-Corebash: improve reproducibility 
11919*
11919

libcrypto needs some patching to achieve binary reproducibility.

Note (in the attached diffoscope output) that the host environment ends up in the .rodata section. Hopefully stripping the embedded string "compiler: i586-poky-linux-gcc ..." of all host build references will fix all binary reproducibility issues.
LowNEWnormalOE-Corelibcrypto: improve binary reproducibility 
11920*
11920

libperl5 package contains references to the host build system, via ccflags in /usr/lib/perl/config.sh and /usr/lib/perl/5.24.1/Config_heavy.pl.

The fix should be simply to filter out DEBUG_PREFIX_MAP from the above mentioned files somewhere in do_install.
LowNEWnormalOE-Corelibperl5: improve binary reproducibility 
11921*
11921 Also it seems the individual .o files were linked in different order.
LowNEWnormalOE-Corelibstdc++-staticdev_7.1.0: improve reproducibility 
11304*
11304

I needed a solution for OSTree, so I wrote one. See https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/lib/oeqa/selftest/systemupdate/systemupdatebase.py

We do not need this in OE-core. If there is interest in moving it there, we can still do that later. Therefore I consider this issue resolved.
LowRESOLVEDnormalTest Plans/SuiteCreate automated testcases for system update 
11463*
11463 The PR got merged to master.
LowRESOLVEDenhancementIoT Reference OS KitRefKit: Python version alignment 
11916*LowRESOLVEDenhancementOE-Coree2fsprogs-doc: improve reproducible build 
10050*
10050

For us , we need this function to generate logs for this case:

One oe runner static *Total* case includes many real cases , so to the runner, it just only generate one result for those many real cases in the log file, which doesn't reflect the real results.
MediumACCEPTEDenhancementAutomated Runtime Testingoeqa runner generate wrong test results in log file when running dynamic test cases 
11346*
11346

Cal,

Can we change the name of this layer to "meta-alexapi" as it is really a build layer for the AlexaPi github repo. Then my team can add a layer that will add additional functionality for a demo (or demos). This way someone can just use AlexaPi for their own demos without having to use our demo layer. Does that make sense to you?
MediumACCEPTEDenhancementDemosCreate demo that shows Amazon Alexa voice activated personal assistant in action 
11455*
11455 Dropping priority as this is no longer a blocker for the buildset rationalisation in bug #11454
MediumACCEPTEDenhancementAutoBuilderImplement script to support running two versions of AB on YP infrastructure 
11544*
11544 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
MediumACCEPTEDenhancementBSPsRMC: Add debug option 
11548*
11548

I have add a web page for the statistic of the packages' pending, submitted, accept status, we can see the web page here:

   https://dengkedu.github.io/pkg-statistic.html
I will update it when every time I deal with a package.
MediumACCEPTEDenhancementOE-CoreReduce local Pending patches 
11663*
11663 I bet this is because you're using arch...
MediumACCEPTEDnormalOE-CoreBuild QA RPATH warning in perl-native build (HiRes.so) 
11739*
11739

STATUS: PASSED BUILD: 2.4 M1 ENVIRONMENT: corei7-64_MMAX64 Build Configuration: BB_VERSION = "1.34.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux-musl" MACHINE = "intel-corei7-64" DISTRO = "poky-tiny" DISTRO_VERSION = "2.3" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "master:98099349e358a9caaec8ec81f0d4abe588909cfe" meta-intel = "master:cebe15d153ab982f80f3f86fea38a0978dfc1f28"

STEPS TO REPRODUCE:

1. Clone Poky 2. Clone meta-intel layer 3. Bitbake-layers add-layr “../meta-intel” 4. source environment 5. local.conf a. DISTRO = "poky-tiny" b. MACHINE = “Intel-core-i7-64” 6. Bitbake core-image-tiny-initramfs



EXPECTED OUTCOME: When image was built correctly the WIC image should be created under tmp/deploy/images/intel-cori7-64 Burn WIC image to USB an boot it to Minnow 64

ACTUAL OUTCOME: output: cp: cannot stat '.../core-image-tiny-initramfs-intel-corei7-64.cpio.gz': No such file or directory ERROR: Function failed: do_image_wic

Log attached.
MediumACCEPTEDnormalBSPsdo_image_wic fails on core-image-tiny-initramfs 
11770*
11770

Preliminary notes: Managed to reproduce all listed problems.

For qemux86/x264 upgrading the recipe for the latest stable version did not fix the problem.

http://git.videolan.org/?p=x264.git;a=shortlog;h=refs/heads/stable
MediumACCEPTEDnormalOE-Coretexrels found for x264/libproxy/python3-pycairo for poky-lsb 
11880*
11880 Accepting this. But it is unlikely that I'll have cycles for it this release. putting to m4, since this would be a stabilization fix.
MediumACCEPTEDnormalOE-Corekernel-devsrc: multiple System.map files present in kernel-build-artifacts 
11510*
11510

This will broken up into three bugs:

This one: Will create a new manifest file (JSON), on which all packages specify what modules and files they require, this is basically just a replacement of the manifest we use at the moment with a more organized one, since it will include a script to "convert" the new manifest to the old one so bitbake can still parse it the same way.

Second bug/enchancement: This one will handle the part on which packages are parsed, this should be done via python, by reading the JSON manifest file directly, and modifying bitbake's dictionary on the go.

Up to this point, the manifest replacement will be complete, but other than it being more organized and having got rid of the script to create it (confusing), it will still have the same other problems stated above.

Third bug/enhancement:

This one will create a test which may be run on top of testimage, that will check every python package to see specifically which modules it needs, and will create a manifest file (JSON) automatically which can be used to replace the current file, this can be run either on every release or when adding a new package if one is lazy enough to not check the modules the new package needs to work.
MediumIN PROGRESS DESIGNenhancementOE-CoreImprove the way we handle python's packaging (autopackaging) 
11694*
11694

Once we merge the new python manifest file using a JSON format, it should be parsed automatically by bitbake, as opposed to having a script which translates from JSON to bash.

This poses a few complications since parsing times are different from bash to python, and bitbake won't know which python packages exists until it reads the JSON file, which may lead to some unusual behavior.

Up to this point, the manifest replacement will be complete, and we should be able to get rid of the script thats being used to create the manifest everytime.
MediumIN PROGRESS DESIGNenhancementOE-CorePython JSON manifest should be parsed directly by bitbake 
11695*
11695

(In reply to comment #1) > Not sure why this needs to use testimage. If we assume that native python > is the same version as target python then we can introspect the native > python when that is built.

Completely agreed, should be possible to do it that way.
MediumIN PROGRESS DESIGNenhancementOE-CoreAdd task to create python manifest(s) automatically 
10535*
10535 Our current workflow does not require this functionality, so move it to Future.
MediumIN PROGRESS IMPLEMENTATIONenhancementCROPSBuild container for Maven/Tycho build for Eclipse CROPS Plugin 
11494*
11494 All component in refkit gateway profile is compliance with secure boot requirement. Except gnupg dependency in flatpak. refkit_license_check.py script in oe-selftest also complete but cannot upstream until the gnupg dependency is fix.
MediumIN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS KitGPLv3 free gateway profile 
11537*
11537

RMC should provide an option to return the fingerprint of the current board in MD5 format.

Example:

./rmc --fp

will return b2c1a220edd348efb0108e8c98e9a28d .
MediumIN PROGRESS IMPLEMENTATIONnormalBSPsRMC: Get board fingerprint 
11596*
11596

bzip2-ptest requires Makefile. This file contains numerous references to the host build system (see the attached diffoscope output). These are harmless and also unneeded, as the ptest runs this:

$ make -k runtest

and the "runtest" target in the Makefile is:

runtest: ./bzip2 -1 < sample1.ref > sample1.rb2 ./bzip2 -2 < sample2.ref > sample2.rb2 ./bzip2 -3 < sample3.ref > sample3.rb2 ./bzip2 -d < sample1.bz2 > sample1.tst ./bzip2 -d < sample2.bz2 > sample2.tst ./bzip2 -ds < sample3.bz2 > sample3.tst @if cmp sample1.bz2 sample1.rb2; then echo "PASS: sample1 compress";\ else echo "FAIL: sample1 compress"; fi @if cmp sample2.bz2 sample2.rb2; then echo "PASS: sample2 compress";\ else echo "FAIL: sample2 compress"; fi @if cmp sample3.bz2 sample3.rb2; then echo "PASS: sample3 compress";\ else echo "FAIL: sample3 compress"; fi @if cmp sample1.tst sample1.ref; then echo "PASS: sample1 decompress";\ else echo "FAIL: sample1 decompress"; fi @if cmp sample2.tst sample2.ref; then echo "PASS: sample2 decompress";\ else echo "FAIL: sample2 decompress"; fi @if cmp sample3.tst sample3.ref; then echo "PASS: sample3 decompress";\ else echo "FAIL: sample3 decompress"; fi


The references to the host build system prevent the bzip2-ptest package from being binary reproducible.

One option is to sanitize all host references, the other (probably better) is to create/install only the relevant part of the Makefile
MediumIN PROGRESS IMPLEMENTATIONenhancementOE-Corebzip2-ptest: improve reproducible build 
11756*
11756

(In reply to comment #1) > Probably related and might be fixed at the same time, so let me just add it > here: invoking "oe-selftest -r foobar" success instead of failing with an > error about "foobar" not being found. > > $ oe-selftest -r foobar > 2017-07-10 14:56:47,643 - oe-selftest - INFO - Adding layer libraries: > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/meta-intel-iot-security/meta-security-smack/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/meta-intel-iot-security/meta-integrity/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/meta-security-tools/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/intel-iot-refkit//meta-refkit/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/intel-iot-refkit/openembedded-core/meta/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/intel-iot-refkit/openembedded-core/meta-selftest/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/intel-iot-refkit//meta-refkit-core/lib > 2017-07-10 14:56:47,643 - oe-selftest - INFO - > /fast/work/intel-iot-refkit//meta-iotqa/lib > 2017-07-10 14:56:47,644 - oe-selftest - INFO - > /fast/work/intel-iot-refkit/meta-security-isafw/lib > 2017-07-10 14:56:47,644 - oe-selftest - INFO - /fast/work/meta-swupd/lib > 2017-07-10 14:56:47,644 - oe-selftest - INFO - > /fast/work/meta-intel-iot-security/meta-security-framework/lib > 2017-07-10 14:56:47,648 - oe-selftest - INFO - Running: bitbake -p > 2017-07-10 14:56:49,818 - oe-selftest - INFO - Loading cache...done. > 2017-07-10 14:56:51,009 - oe-selftest - INFO - Loaded 3538 entries from > dependency cache. > 2017-07-10 14:56:52,109 - oe-selftest - INFO - Parsing recipes...done. > 2017-07-10 14:56:52,518 - oe-selftest - INFO - Parsing of 2626 .bb files > complete (2622 cached, 4 parsed). 3542 targets, 419 skipped, 0 masked, 0 > errors. > 2017-07-10 14:56:52,623 - oe-selftest - INFO - > 2017-07-10 14:56:52,623 - oe-selftest - INFO - > ---------------------------------------------------------------------- > 2017-07-10 14:56:52,623 - oe-selftest - INFO - Ran 0 tests in 0.001s > 2017-07-10 14:56:52,623 - oe-selftest - INFO - > 2017-07-10 14:56:52,624 - oe-selftest - INFO - OK > 2017-07-10 14:56:52,624 - oe-selftest - INFO - RESULTS: > 2017-07-10 14:56:52,624 - oe-selftest - INFO - SUMMARY: > 2017-07-10 14:56:52,624 - oe-selftest - INFO - oe-selftest () - Ran 0 tests > in 0.002s > 2017-07-10 14:56:52,624 - oe-selftest - INFO - oe-selftest - OK - All > required tests passed

Hi Patrick,

We have a separate bug for this, see,

https://bugzilla.yoctoproject.org/show_bug.cgi?id=11645

Anibal
MediumIN PROGRESS IMPLEMENTATIONnormalAutomated Build Testingoe-selftest: --run-tests ignores test order 
11769*
11769

I checked some older SDKs installed on my machine, so this one is OK (buid with MACHINE="qemuarm":

Distro: poky Distro Version: 2.2+snapshot-20170225 Metadata Revision: 3c83b56309ab419f8cda72c0711479f60f61439a Timestamp: 20170225001909

It has: export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "

Then I have one: Distro: poky Distro Version: 2.3 Metadata Revision: f2b91c6e00c5a6de8ef0ac51f9f07e53d1ca9d43 Timestamp: 20170504192226

which is broken (I did not notice this at the time): export CXXFLAGS="${BUILDSDK_CXXFLAGS}"

I also checked the official yocto releases: http://downloads.yoctoproject.org/releases/yocto/

Distro: poky Distro Version: 2.3.1 Metadata Revision: c2ef32ae58737463cf19aab7446d6a30ad81754f Timestamp: 20170712013505

and the bug is there as well, so it is in 2.3

Distro: poky Distro Version: 2.3 Metadata Revision: 381897c64069ea43d595380a3ae913bcc79cf7e1 Timestamp: 20170501163737 export CXXFLAGS="${BUILDSDK_CXXFLAGS}"


This one (2.2.1) is OK: Distro: poky Distro Version: 2.2.1 Metadata Revision: 6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f Timestamp: 20170208201852 export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "


I only randomly checked some SDKs (extended & standard), but I think it is fairly safe to state that 2.2 is OK and 2.3 is broken.
MediumIN PROGRESS IMPLEMENTATIONnormalOE-CoreSDK environment-setup CXXFLAGS wrong 
11612*MediumIN PROGRESS REVIEWnormalAutomated Build TestingQA Bitbake: Create tests for multiconfig support 
11656*
11656

libtool contains two instances of host build references:

1. LTCFLAGS:

LTCFLAGS="·​-​O2·​-​pipe·​-​g·​-​feliminate-​unused-​debug-​types·​-​fdebug-​prefix-​map=/​tmp/​ramdisk/​build-​repro-​no-​dpkg-​2017-​06-​12/​work/​i586-​poky-​linux/​libtool/​2.​4.​6-​r0=/​usr/​src/​debug/​libtool/​2.​4.​6-​r0·​-​fdebug-​prefix-​map=-​native=·​-​fdebug-​prefix-​map==·​-​ffile-​prefix-​map=/​tmp/​ramdisk/​build-​repro-​no-​dpkg-​2017-​06-​12/​work/​i586-​poky-​linux/​libtool/​2.​4.​6-​r0/​libtool-​2.​4.​6=/​libtool-​2.​4.​6/​·​·​-​ffile-​prefix-​map=/​tmp/​ramdisk/​build-​repro-​no-​dpkg-​2017-​06-​12/​work/​i586-​poky-​linux/​libtool/​2.​4.​6-​r0/​libtool-​2.​4.​6=/​libtool-​2.​4.​6/​

2: lt_truncate_bin="/​tmp/​ramdisk/​build-​repro-​no-​dpkg-​2017-​06-​12/​hosttools/​dd·​bs=4096·​count=1"

These not only prevent binary reproducibility, but I would assume prevent proper functionality as well. I believe the remedy would be to set them as:

LTCFLAGS="·​-​O2·​-​pipe·​-​g·​-​feliminate-​unused-​debug-​types

lt_truncate_bin="dd·​bs=4096·​count=1"
MediumIN PROGRESS REVIEWnormalOE-Corelibtool contains build host references 
11706*
11706

the way oe-setup-rpmrepo searches for createrepo_c does not work with RSS. It should probably just use/leverage oe-run-native.

Docs: we need to document how to use the repo from the target side as well.
MediumIN PROGRESS REVIEWnormalOE-Coreoe-setup-rpmrepo no longer works with RSS 
11740*
11740 I have attached additional files with output from dmesg and lsmod on a core-image-sato-sdk-genericx86-64.wic image (2.4 M1 rc1) running on a Minnowboard Turbot 64 bit.
MediumIN PROGRESS REVIEWenhancementBSPsDAFT: Enable BeagleBone OTG Ethernet interface on genericx86 images. 
11915*
11915

When Toaster removes a package from a custom image, it must also always remove the advised reverse-dependent recipes. Similarly, when adding a package it must always add its advised the packages it depends on.

Toaster normally waited until a new custom image was built before creating the custom layer and the recipe. However, a different build can fail because the recipe has already been added to the project, so

the image's default recipe must be created when the image is created.
MediumIN PROGRESS REVIEWnormalToasterToaster: custom image updates and original creation 
11938*
11938

Toaster needs the ability to allow custom extensions to execute when Toaster is started and stopped.

One example is for starting and stopping password servers to enable access to protected git repositories.
MediumIN PROGRESS REVIEWenhancementToasterAdd ability to do custom actions when Toaster is started and stopped 
11894*
11894

As far as I can tell the BASEDEPENDS seem to be correct, so I am not sure what exactly is triggering the dependency failure. My test was building build-appliance-image not with rm_work.

I tried to duplicate it with INHIBIT_DEFAULT_DEPS, but it failed in other ways, not related to iwlwifi
MediumNEEDINFOnormalBSPsiwlwifi fails to build 
8919*
8919 This is low priority for 2.3 and there is no window time to work on this area during 2.3.
MediumNEWenhancementOE-CoreCode coverage: add ability to create coverage-based test exclusion reports 
8921*
8921

(In reply to comment #3) > As this issue got assigned to me I'd like to know why do we need this and is > this functionality can be implemented using python-coverage?

I moved to 2.4 and for some reason it got assigned to you.

For your question, oe-selftest is already using python-coverage (version 4.x), so we can produce data. The main task here is the analysis of this data. No plans to do the later during 2.3
MediumNEWenhancementOE-CoreCode coverage: add ability to create missing 'coverage area' reports 
9769*
9769 Will achieve this same request via buildsets that run on a specific set of workers.
MediumNEWenhancementAutoBuilder[Autobuilider] Ability to select the worker for a forced build 
10308*
10308

As noted in the mailing list.

The problem is that apparently a previous change activated some normally deactivated code to allow signature by-pass.

The previous code was implemented in reverse, i.e. signature/digest validation was always deactivated instead of always activated.

This permits a corrupted package to avoid validation and install.


As noted on the mailing list by Hongxu, the fix for this issue would be to correct the validation arguments, so the default is enabled, and the --no* options disable the default.


Alternatively we disable the previous patch and go back to the community setting avoiding this chunk of code.
MediumNEWnormalOE-Corerpm installs bad signature package with option --nodigest --nosignature failed 
10537*
10537 adding scott
MediumNEWenhancementCROPSUse "new project template" framework to create sample Make project 
10538*
10538 adding scott and giving to chin huat.
MediumNEWenhancementCROPSUse "new project template" framework to create sample Automake project 
10540MediumNEWenhancementCROPSUse "new project template" framework to create sample CMake project 
10552MediumNEWenhancementCROPSDevtool add from existing Eclipse project within the Eclipse CROPS plugin 
10553*
10553 This is intended to support the recipes brought in by devtool.
MediumNEWenhancementCROPSContext sensitive recipe syntax support within the Eclipse CROPS plugin 
10555*
10555 Moving to M3
MediumNEWenhancementCROPSDevtool upgrade from existing recipe into an Eclipse project within the Eclipse CROPS plugin 
10847*
10847

(In reply to comment #3) > Yes, this makes sense. Thanks. > > However, I'm still a bit concerned with the potential complexity of this > setup. Would it be better to use serial interface? What exactly setting, > running and maintaining dhcp infrastructure would give us? Would it mean > that to run test suite on my machine I'd need to also setup dhcpd > infrastructure? Agreed, as I was filing this bug and finding out the implications of it, I realized the complexity of it.

I commented on bug 10833 that adapting the serial interface procedure to the automation would be a way to solve such problem.

Still, dynamic IP addresses for test targets would be a consolidated solution that might be worth looking for future releases.
MediumNEWenhancementAutomated Runtime Testingtestimage: add the ability to test dynamic IP addr targets 
11145*
11145

It would make sense to be able to optionally start a PRServer with the controller when the autobuilder is configured for a single shared PRServer running on the controller, a setup we'd like to switch to on the project's autobuilder clusters.

Currently we automatically start a shared local PRServer (with an up-to-date clone of bitbake) on each worker when PRSERV_HOST is set to localhost.
MediumNEWenhancementAutoBuilderOptionally start shared PRServer with controller 
11211*
11211

The NAS storage is performing very well in testing. All clients are now using nfs 4.2. Does this resolve the issue?

If not my research indicates that git will always be very slow when working over nfs unless we cache stat data longer. We have seen intermittent build failures in the past when allowing caching of stat data. I don't recall exactly why but I think some processes use that data to avoid race conditions.
MediumNEWmajorAutoBuilderGit clones to NAS are very slow and have significant impact on build times 
11235*
11235

The buildset configuration parser is very unforgiving of syntax errors such as a stray comma[1]. Said stray comma results in a long Traceback which doesn't provide many clues for fixing the problem short of digging into the code, i.e. (from[2]):

Traceback (most recent call last):

 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1187, in unwindGenerator
   return _inlineCallbacks(None, gen, Deferred())
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1045, in _inlineCallbacks
   result = g.send(result)
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py", line 169, in upgradeMaster
   master_cfg = loadConfig(config, configFile)
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py", line 53, in loadConfig
   config['basedir'], configFileName)

--- <exception caught here> ---

 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/config.py", line 149, in loadConfig
   exec f in localDict
 File "/media/data/yocto-autobuilder/yocto-controller/controller.cfg", line 94, in <module>
   yocto_buildsets.createBuildsets()
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 65, in createBuildsets
   self.parseBuildSet(buildset)
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 102, in parseBuildSet
   self.parseRepos(buildset)
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 127, in parseRepos
   if layer.iterkeys().next() not in self.repos:

exceptions.AttributeError: 'list' object has no attribute 'iterkeys' Errors loading configuration:

 error while parsing config file: 'list' object has no attribute 'iterkeys' (traceback in logfile)

The yocto-autobuilder will be friendlier to administrators if it can help them diagnose such issues more easily by providing more informative reporting of failures, such as pointing to the specific file and line that caused the parser failure.

For extra convenience we could:

  • make the parser more lenient of stray punctuation (like setLenient() in Android's JsonReader[3])
  • switch to using a pure data format, such as JSON, rather than parsing Python AST's. If we were to switch to JSON a user could use their editor of choice's built in linter to detect such issues at editing time.


1. http://git.yoctoproject.org/clean/cgit.cgi/yocto-autobuilder/commit/?id=239eeaa1e2cf3a985e75f8b75dedfe704a7d6991 2. https://lists.yoctoproject.org/pipermail/yocto/2017-March/035274.html

3. https://developer.android.com/reference/android/util/JsonReader.html#setLenient(boolean)
MediumNEWenhancementAutoBuilderImprove configuration parser - better error reporting and more lenient 
11257*
11257

Buildbot writes observed logs (most commonly stdout and stderr) to the status UI. However, we've noticed that often times we know the build is past a certain step but the logs we can see through the autobuilder status UI haven't been updated to reflect the latest output from bitbake.

We'd like to have the log output synced more frequently, particularly for things like oe-selftest.

It may be that syncing on a timer (i.e. every minute) would be more useful for our needs than syncing on a chunk size (i.e. every 4kb) — assuming that's what currently happens.
MediumNEWenhancementAutoBuilderSync autobuilder log output more frequently 
11261*
11261

We use the wikilog plugin to write autobuilder failures to a page on the Yocto Project wiki, grouped by the triggering build:

https://wiki.yoctoproject.org/wiki/BuildLog

This page is growing very large, which makes it slower to load and intimidating to view for those who want to help manage it.

We should implement log rotation of the wiki page in wikilog so that it only shows either n recent entries, or entries from the past y days.
MediumNEWenhancementAutoBuilderImplement log rotation for Wikilog 
11348*MediumNEWenhancementDemosCreate demo showing Yocto built FPGA image in action 
11358*
11358

Coverage report shows some of the covered lines of wic code as uncovered.

Here is an example:

$ oe-selftest -r wic --coverage $ coverage3 report -m |grep filemap.py /home/ed/git/yocto/poky/scripts/lib/wic/filemap.py 248 99 52 11 55% 79-80, 87-88, 93-94, 102-103, 108-109, 125-126, 138, 147, 160, 169, 183-194, 207-210, 226-249, 253-261, 265, 274-293, 297-299, 303-305, 376, 390-403, 422, 470, 502-516, 530-531, 543, 547-550, 553, 557, 73->76, 78->79, 118->exit, 375->376, 469->470, 542->543, 542->562, 546->547, 546->549, 556->542, 556->557

lines 207-210 belong to FilemapSeek.__init__, which is definitely called in test_sparse_copy test case. The same happens with a lot of other lines of code from this module.

It looks like coverage doesn't work properly for direct API calls. It works only for indirect calls, i.e. when the API is called from the tool/program that's executed in test cases.
MediumNEWnormalAutomated Build Testingoe-selftest: coverage report shows incorrect info 
11364*
11364 I am starting with 5 days for the design phase, and will expand and/or split this task into sub-units as appropriate.
MediumNEWenhancementToasterProvide a wizard-based project creation option 
11371*
11371

1) Add support to point to custom layer index servers.

 * The existing OE Layer Index server should remain the default
 * There should be an easy way to customize the Toaster instance to point to an alternate custom layer index server, for example by adding an entry in "custom.xlm" fixture file.

2) Also add support to point to a layer index summary file, for installations where it is not feasible to gain access or to host a layer index server.

 * The layer index API path should be able to be a file path.
* The format of the file should be in JSON, and should follow the schema of the normal index server content.
MediumNEWenhancementToastersupport custom layer index servers, file-based layer index 
11388*
11388 Push to future release.
MediumNEWenhancementDemosCreate a demo using build performance visualization tool to show build speed improvements 
11397*
11397 A bit deeper analysis of buildstats: show the top blocking tasks of bitbake builds. That is, the tasks that are running longest alone, blocking any other task from running.
MediumNEWenhancementOE-Coreoe-build-perf-report: show blocking tasks 
11398*
11398 Make the timeline (i.e. x-axis) of the charts in the html report changeable, e.g. buttons for showing the last 10, 25, 50, 100 and 'all' tested data points.
MediumNEWenhancementOE-Coreoe-build-perf-report: interactive timeline selection in the html report 
11406*
11406

I've occasionally encountered inexplicable build errors and reconfiguration problems. Generally it is from getting a recipe or command incorrect (e.g., wrong URL), attempting to reset the recipe in the workspace and redoing it. The desire is to make the environment pristine for just the recipe desired (or all if -a) without blowing away the entire eSDK (or chasing all the caches to selectively remove), reinstall and rebuild. If it was only a couple locations to remove, I'd have been fine. As I started writing a script to clean the caches and various other locations, I thought it be better if it was included in devtool, itself.

Use cases: Working through steps to refine a demo example workflow for a team. Similarly, reworking steps (and correcting errors in steps) for documentation on examples relevant to a team project. (both variants being where I've encountered these problems).

The very nicety of the cache can come back to haunt you when you don't expect it (e.g., wrong URL, but same filename in URL).

I appreciate not wanting users to shoot themselves in the foot, but there are uses for the -f (even with rm, cp, mv, ln, et al.) The parameter shouldn't be a normal use case (as -f in most cases isn't normal), but one for the exceptional cases.

I would argue that requiring the user to explicitly state they wish to shoot their foot off is acceptable as you can point back to the command issued and state you accepted the terms and consequences thereof.
MediumNEWenhancementOE-CoreAdd --dist-clean, --force, or some other flag to 'devtool reset' to clean all recipe cruft 
11407*
11407

FWIW I have fixed an aspect of this which is handling of URLs that return an HTML page:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=047d37633b2d451ee4f53c635d3f48b9b0732e44

The underlying issue of a previously downloaded file with the same name is still present however.
MediumNEWnormalOE-Coredevtool should warn user of prior download after reset 
11423*
11423 Is this a superset of bug 11421?
MediumNEWnormalCROPSeSDK automated testcases don't run on Crops-eSDK 
11445*
11445

Here is an example of wks file with a lot of partitions:

$ cat test.wks part ext2 --fstype ext2 --source rootfs part ext3 --fstype ext3 --source rootfs part ext4 --fstype ext4 --source rootfs part squash --fstype squashfs --source rootfs part btrfs --fstype btrfs --size 40M --source rootfs part swap --fstype swap --size 1M

part emptyvfat --fstype vfat --size 1M part emptymsdos --fstype msdos --size 1M part emptyext2 --fstype ext2 --size 1M part emptyext3 --fstype ext3 --size 1M part emptyext4 --fstype ext4 --size 1M part emptybtrfs --fstype btrfs --size 100M

You can generate wic image from this file this way:

$ wic create test.wks -e core-image-minimal INFO: Creating image(s)...

WARNING: bootloader config not specified, using defaults

INFO: The new image(s) can be found here:

 ./test-201705041111-sda.direct

The following build artifacts were used to create the image(s):

 ROOTFS_DIR["ext2"]:           /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
 ROOTFS_DIR["ext3"]:           /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
 ROOTFS_DIR["ext4"]:           /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
 ROOTFS_DIR["squash"]:         /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
 ROOTFS_DIR["btrfs"]:          /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs
 BOOTIMG_DIR:                  /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
 KERNEL_DIR:                   /home/ed/git/yocto/poky/build/tmp/deploy/images/qemux86-64
 NATIVE_SYSROOT:               /home/ed/git/yocto/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native

INFO: The image(s) were created using OE kickstart file:

 test.wks


and list partitions this way:

$ /sbin/fdisk -l ./test-201705041111-sda.direct

Disk ./test-201705041111-sda.direct: 233.3 MiB, 244604928 bytes, 477744 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x10118df4

Device Boot Start End Sectors Size Id Type ./test-201705041111-sda.direct1 1 49130 49130 24M 83 Linux ./test-201705041111-sda.direct2 49131 98260 49130 24M 83 Linux ./test-201705041111-sda.direct3 98261 147390 49130 24M 83 Linux ./test-201705041111-sda.direct4 147391 477743 330353 161.3M f W95 Ext'd (LBA) ./test-201705041111-sda.direct5 147392 154151 6760 3.3M 83 Linux ./test-201705041111-sda.direct6 154153 260648 106496 52M 83 Linux ./test-201705041111-sda.direct7 260650 262697 2048 1M 82 Linux swap / Solaris ./test-201705041111-sda.direct8 262699 264746 2048 1M c W95 FAT32 (LBA) ./test-201705041111-sda.direct9 264748 266795 2048 1M 6 FAT16 ./test-201705041111-sda.direct10 266797 268844 2048 1M 83 Linux ./test-201705041111-sda.direct11 268846 270893 2048 1M 83 Linux ./test-201705041111-sda.direct12 270895 272942 2048 1M 83 Linux

./test-201705041111-sda.direct13 272944 477743 204800 100M 83 Linux
MediumNEWenhancementOE-Corewic: allow wic to support additional partition (e.g. 4th partition) 
11458*
11458

The charts in the html report generated by oe-build-perf-report already have "tooltips": a splash window with additional details is shown when hovering mouse cursor over data points. This window could be made much more informative by adding more data, e.g. all the same statistics that are shown for the latest commit on the right side of the chart plus some additional info: - commit number - commit sha1 - number of test runs - mean - +/- - min/max

- standard deviation
MediumNEWenhancementOE-Coreoe-build-perf-report: improve tooltips of html report 
11479*
11479

First video analysis component to be integrated is Motion (https://motion-project.github.io/). Initial version of the recipe is here:

https://github.com/ipuustin/intel-iot-refkit/commit/f80dc1e02b40eeb45eff84a8466d54fd37ad2388
MediumNEWenhancementIoT Reference OS KitComputer vision video analysis support 
11487*
11487

The recipe reporting system needs to track meta-intel.

The implementation should cover the posibility to add other layers.
MediumNEWenhancementRecipe Reporting System (RRS)RRS: Add support for meta-intel 
11531*
11531 When running in non-secure boot context, RMC should be able to add the fingerprint of the current board to the data store. The fingerprint generation function will be shared between EFI and userspace contexts.
MediumNEWenhancementBSPsRMC: [EFI] Add register board with data store functionality (non-secure boot) 
11532*
11532

Parse CONFIG file and store RMC.efi log to file if

LOG=/path/to/log is found.
MediumNEWenhancementBSPsRMC: [EFI] Add log option 
11533*
11533 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
MediumNEWenhancementBSPsRMC: [EFI] Add debug option 
11534*
11534

Parse the tasks file and process the tasks defined in it. The only supported task at present is CP (copy a file from the datastore to a target location).

Example TASKS file:

FP=123456789ABCDEFG

  CP SRC_FILE TARGET_FILE


If the board fingerprint is 123456789ABCDEFG execute task "CP SRC_FILE TARGET_FILE".
MediumNEWenhancementBSPsRMC: [EFI] Process tasks in TASKS file 
11535*
11535

When running in secure boot mode, RMC.efi has to verify the integrity of the data store. This involves generating and MD5 hash over the contents of the data store and comparing it to the MD5 has stored in the RMC.efi PE header (last field in data directories).

https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg

If the system is running in secure boot mode and the two hashes do not match the boot process should be terminated with an appropriate message to the user.
MediumNEWenhancementBSPsRMC: [EFI] Verify data store integrity (secure boot) 
11538*
11538

This should be something like (-b for bless):

./rmc -b -d data_store_dir -f RMC.efi
MediumNEWenhancementBSPsRMC: Bless data store 
11539*
11539

Verity that the MD5 hash stored in the RMC.efi PE header matches the MD5 hash generated over contents of the data store.

Example:

./rmc -v -d data_store_dir -f RMC.efi
MediumNEWenhancementBSPsRMC: Verify RMC.efi is properly blessed 
11540*
11540

Print the contents of an existing fingerprint file - both the SMBIOS strings stored in the file and the MD5 hash corresponding to these strings.

Example:

./rmc -p -f FILE.fp
MediumNEWenhancementBSPsRMC: Print fingerprint file contents 
11543*
11543 RMC should be able to add the fingerprint of the current board to the data store. The fingerprint generation function will be shared between EFI and userspace contexts.
MediumNEWenhancementBSPsRMC: Register board with data store 
11545*
11545

Parse CONFIG file and store RMC log to file if

LOG=/path/to/log is found.
MediumNEWenhancementBSPsRMC: Add log option 
11546*
11546

It would be useful to have configurable thresholds for measurement results. Both absolute and relative thresholds should be supported. If the result (mean) would exceed the threshold it would be noted in the report. HTML report coloring would probably be adjusted so that only results exceeding the threshold would be colored red/green.

Exceeding a threshold would also be reflected in the return value of the script. This way, the script could be used in bisecting possible regressions.
MediumNEWenhancementOE-Coreoe-build-perf-report: implement thresholds for measurement results 
11601*
11601 There are cases where series contain patches (.patch) but these are not referenced in the corresponding recipe so a (patchtest) check is is needed.
MediumNEWenhancementPatchwork/Patchtestcheck new patches are indicated in the SRC_URI 
11602*
11602

The image with acl-ptest contains this file:/usr/lib/acl/ptest/include/builddefs

The file references the host build path on several occasion (see the attachment), hence the file ("builddefs") should be sanitized. This is needed not only for binary reproducibility, but to actually pass the test.
MediumNEWnormalOE-Coreacl-ptest references host build path 
11629*
11629 Add a T&T article for a Yocto Poky image that can be booted on a de10-nano on the HPS arm SOC. This is so we can detail how to build and run a Poky image in addition to the default Angstrom one that is the current default.
MediumNEWenhancementDemosdocument in tips and tricks how to bring up a de10-nano altera HPS with Yocto Poky 
11642*
11642 Work on GDC DAFT instance to support all the DUT's used on BSP QA cycles and execute automated tests.
MediumNEWenhancementAutomated Runtime TestingUse DAFT to execute BSP's automated test on QA cycles. 
11666*
11666 /usr/lib/attr/ptest/include/builddefs contains various references to the host build system. This breaks binary reproducibility but possibly the ptest as well.
MediumNEWnormalOE-Coreattr-ptest references host build path 
11667*
11667

usr/lib/flex/ptest/Makefile needs to be sanitized.

Please see the attached file.
MediumNEWnormalOE-Coreflex-ptest references host build path 
11668*
11668

./usr/lib/zlib/ptest/Makefile contains some references to the build host system that should be removed.

Please see the attached file.
MediumNEWnormalOE-Corelibz-ptest contains build host references 
11674*
11674

"The cpio utility was standardized in POSIX.1-1988, but it was omitted from POSIX.1-2001 because of its file size (and other) limitations. For example, the GNU version offers various output format options, such as "bin" (default, and obsolete) and "ustar", having a file size limitations of 2,147,483,647 bytes (2 GB) and 8,589,934,591 bytes (8 GB), respectively.[3]"

Very much looks like file size is the problem. If we're not using ustar format we should, and if possible we should verify the size.
MediumNEWnormalOE-Corecore-image-sato-sdk-ptest build error for cpio image 
11704*
11704 adding markus and randy
MediumNEWenhancementBitBakeAdd other resource monitoring options to conf/local.conf STOPTASKS/ABORT 
11711*
11711

(In reply to comment #0) > The shortlog's prefix indicates several things besides indicating that it is > a patch: revision, targeted branch, patch number and total patches. This > info needs to be present in a standard format, thus making it easier to > parse it. Create a tests to check for the latter.

To be more precise, the only check required is the targeted branch format if present.

On the mailing lists. At least for pyro/morty, these are the flavors seen

   48:./7014.1.mbox:5:Subject: [1/3,pyro] piglit: depend on virtual/egl
    49:./7014.1.mbox:51:Subject: [2/3,pyro] piglit: add patch for lack of gbm_bo_map
    51:./7014.1.mbox:143:Subject: [3/3,pyro] piglit: add patches for unbuildable surfaceless Mesa test
   119:./7008.3.mbox:5:Subject: [pyro] bitbake.conf: Add sdl-config to HOSTTOOLS if using host SDL
   121:./6991.4.mbox:5:Subject: [pyro] archiver: Escape recipe name in regex
   190:./7118.1.mbox:5:Subject: [1/3,v2,pyro] piglit: depend on virtual/egl
   191:./7118.1.mbox:53:Subject: [2/3,v2,pyro] piglit: add patch for lack of gbm_bo_map
   210:./7129.1.mbox:5:Subject: [master, pyro] image-vm: Avoid use of fold,
   335:./6060.2.mbox:5:Subject: [master,pyro] bitbake.conf: Add whoami to HOSTTOOLS
   434:./7165.2.mbox:5:Subject: [pyro] busybox: add backported patch to support iproute 'scope'
   437:./7166.2.mbox:5:Subject: [pyro] openssh: allow to override OpenSSL HostKeys when
   520:./6623.3.mbox:5:Subject: [pyro] automake: Backport perl 5.22 fix
   886:./7349.1.mbox:5:Subject: [pyro] autogen-native: Set POSIX_SHELL to /bin/sh


    36:./7010.1.mbox:5:Subject: [morty,1/1] perf: add perf-feature for systemtap
    92:./6194.2.mbox:5:Subject: [morty] eudev: set LGPL-2.1+ for libudev package
   120:./6991.3.mbox:5:Subject: [morty] archiver: Escape recipe name in regex
   199:./6623.2.mbox:5:Subject: [morty] automake: Backport perl 5.22 fix
   202:./7122.1.mbox:5:Subject: [morty] gcc-6.2: backport fix of check for empty string in ubsan.c
   204:./7124.1.mbox:5:Subject: [morty] elfutils: fix building elfutils-native with GCC7
   264:./7141.1.mbox:5:Subject: [morty] linux-yocto/4.8: update to 4.8.24
   799:./6194.3.mbox:5:Subject: [morty] eudev: set LGPL-2.1+ for libudev package
   942:./7398.1.mbox:5:Subject: (morty) automake: fix Perl regex
   945:./7399.1.mbox:5:Subject: (morty) gcc: fix ubsan empty string check
   947:./7400.1.mbox:5:Subject: (morty) elfutils: fix fallthrough warnings and printf overflow
   956:./6627.6.mbox:5:Subject: [v2,morty] rpm: Fix the Bug of SRPM String error
   961:./7405.1.mbox:5:Subject: [v2] (morty) Arch Linux build fixes
   978:./7416.1.mbox:5:Subject: [v2] (morty) rpm: Fix the Bug of SRPM String error
  1005:./7416.2.mbox:5:Subject: [v3] (morty) rpm: Fix the Bug of SRPM String error
at least we should document a standard way and check closing brackets instead of parenthesis.
MediumNEWnormalPatchwork/Patchtestcheck proper prefix on subject 
11726*
11726

(In reply to comment #1) > Did the keyboard work after the X system finished initializing? > > Can you try a different keyboard?

Keyboard and Mouse are responsive, it doesn't seem to affect the functioning.
MediumNEWnormalBSPs[Testimage]Multiple errors present in dmesg_ouput.log 
11752*
11752

There is some preliminar work tracked at branch [1]. This work just focuses on querying the local test data, so no tinfoil usage at all for the moment.

[1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=lsandov1/selftest-use-td

No performance gains seen with the latter so far, so taken approach may be wrong.
MediumNEWenhancementAutomated Runtime Testingselftest test cases should use the test data and/or tinfoil instead of bitbake 
11753*
11753

For patchtest, it would be quite useful to have a new key-value of the current head at time of submission, i.e. head-at-submission-time:f0d128ea0dfc2c403ff53a1ac1db3521854b63d5, in the stored mbox:

From patchwork Thu Jun 29 16:40:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [v4,1/4] export: new plugin to export the devtool workspace From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> X-Patchwork-Id: 141371 head-at-submission-time:f0d128ea0dfc2c403ff53a1ac1db3521854b63d5 Message-Id: <6bc25ed3eb36791b66c9d187ba145ee34afa6c54.1498754105.git.leonardo.sandoval.gonzalez@linux.intel.com> To: openembedded-core@lists.openembedded.org Date: Thu, 29 Jun 2017 09:40:49 -0700

with this key-value info, patchtest can easily move to a base commit and test the corresponding mbox/patch and (in theory) allowing all tests to be executed because patch merge is possible.
MediumNEWenhancementPatchwork/Patchtestpatchwork should track the HEAD commit id in stored patches 
11773*
11773

Tried to give coreduo as cpu for qemuparams in runqemu, this happened:

[humberto@localhost build]$ runqemu qemux86-64 qemuparams="-cpu coreduo" runqemu - INFO - Assuming MACHINE = qemux86-64 runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e... runqemu - INFO - MACHINE: qemux86-64 runqemu - INFO - DEPLOY_DIR_IMAGE: /home/humberto/poky/build/tmp/deploy/images/qemux86-64 runqemu - INFO - Running ls -t /home/humberto/poky/build/tmp/deploy/images/qemux86-64/*.qemuboot.conf... runqemu - INFO - CONFFILE: /home/humberto/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.qemuboot.conf runqemu - INFO - Continuing with the following parameters:

KERNEL: [tmp/deploy/images/qemux86-64/bzImage--4.10.17+git0+4b89f331d4_6648a34e00-r0-qemux86-64-20170629102456.bin] MACHINE: [qemux86-64] FSTYPE: [ext4] ROOTFS: [tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.rootfs.ext4] CONFFILE: [/home/humberto/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.qemuboot.conf]

runqemu - INFO - Running /usr/sbin/ip link... runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running ldd tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64... runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci -cpu coreduo -cpu core2duo -m 256 -serial mon:vc -serial null -kernel tmp/deploy/images/qemux86-64/bzImage--4.10.17+git0+4b89f331d4_6648a34e00-r0-qemux86-64-20170629102456.bin -append 'root=/dev/vda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 '

runqemu - INFO - Releasing lockfile for tap device 'tap0'


As it can be seen at the end, the cpu value given was used but overwritten also by the default value ("-cpu coreduo -cpu core2duo"). From the target terminal we can see that the default core2duo cpu is used instead of the coreduo given as param:

root@qemux86-64:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping : 11 cpu MHz : 2394.450 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss syscall nx lm constant_tsc rep_good nopl pni monitor ssse3 cx16 hypervisor lahf_lm bugs : bogomips : 4788.90 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual

power management:
MediumNEWnormalOE-Corerunqemu: value given to qemuparams is automatically overwritten 
11786*
11786

Option --coverage-include is not giving proper information about the coverage on test cases, this scenario represents the devtool suite which should be giving specific coverage for scripts/lib/devtool scripts


===== STEPS =====.
1- checkout pyro 2- source oe-init-build-env 3- under build execute following

  $ echo "SANITY_TESTED_DISTROS = " >> conf/local.conf
  $ oe-selftest -r devtool --coverage --coverage-include /home/jgperezc/sandbox/poky/scripts/lib/devtool/*

EXPECTED RESULTS coverage should be specified correctly

ACTUAL RESULT

data_file = /home/jgperezc/sandbox/poky/build-devtool-update/.coverage.20170713T104349 branch = True source =

   /home/jgperezc/sandbox/poky/meta
   /home/jgperezc/sandbox/poky/meta-poky
   /home/jgperezc/sandbox/poky/meta-yocto-bsp
   /home/jgperezc/sandbox/poky/meta-selftest
   /home/jgperezc/sandbox/poky/scripts
   /home/jgperezc/sandbox/poky/bitbake

include =

   /home/jgperezc/sandbox/poky/scripts/lib/devtool/build_image.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/build.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/build_sdk.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/deploy.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/__init__.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/package.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/__pycache__
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/runqemu.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/sdk.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/search.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/standard.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/upgrade.py
   /home/jgperezc/sandbox/poky/scripts/lib/devtool/utilcmds.py

2017-07-13 11:31:14,032 - selftest - INFO - Coverage Report 2017-07-13 11:31:14,032 - selftest - INFO - =============== 2017-07-13 11:31:14,068 - selftest - WARNING - No data to report.


Ran 38 tests in 2845.013s


NOTE: if --coverage --coverage-include is not given to the command the coverage report is showed correctly but without giving information about /home/jgperezc/sandbox/poky/scripts/lib/devtool/* log attached
MediumNEWnormalAutomated Build Testing[pyro]oe-selftest: coverage-include not giving correct information 
11789*
11789

Rather than building images and then testing them with a BuildImage step followed by a RunSanityTests we might save some effort by folding the two into one step.

i.e. bitbake core-image-sato:testimage

instead of

bitbake core-image-sato && bitbake core-image-sato:testimage

This would require inheriting testimage-auto, rather than testimage, and would also likely require enhancements for SDK testing that would need backporting.
MediumNEWenhancementAutoBuilderImage build and sanity test in one bitbake invocation 
11793*
11793 There is not create_opkg_index nor create_dpkg_index for oe-testimage-repo. This is needed to test opkg, dpkg and fully complete automation of package management testing features.
MediumNEWnormalAutomated Runtime Testingcreate opkg and dpkg index 
11801MediumNEWnormalOE-Corerpmbuild fails randomly when try to build a spec file 
11805*
11805

This would mean having the testsuite create, compile, and preferably boot-test each combination of architecture/kernel version/kernel type/branch type, along with important machine options.

Master Bug 6926
MediumNEWenhancementAutomated Build TestingCreate yocto-bsp/yocto-kernel tools tests 
11806*
11806

Create tes for creating/adding/removing kernel configuration and patches using the yocto-kernel tool.

Master Bug 6926
MediumNEWenhancementAutomated Build TestingCreate test for yocto-kernel tool 
11808*
11808 Moving this to medium pending the resolution of bug 11183.
MediumNEWminorOE-Corecve-check does not match previous SW versions 
11868*
11868 We shouldn't/don't need a bug per distro here...
MediumNEWenhancementOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1 opensuse422 
11871*
11871 This entry is for QA to add a new testcase found on the oe-selftest suite to Testopia, assign a testcase number. hence this does not report a failure.
MediumNEWenhancementOE-Coredistrodata.Distrodata.test_checkpkg - Testcase -1: ubuntu1604 
11872*
11872

Update and add the ID to the TCs in testopia:ubuntu1604

Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "2.3" TUNE_FEATURES = "m64 core2" meta-selftest = "heads/master:8e15e9b6e478f6368034519b2a8fd3c7ea71d23b"


===========================================================================
2017-07-26 16:14:04,299 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_list_not_found - Testcase -1: PASSED 2017-07-26 16:14:04,299 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_list_okay - Testcase -1: PASSED 2017-07-26 16:14:04,299 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_log - Testcase -1: PASSED 2017-07-26 16:14:04,299 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_log_split - Testcase -1: PASSED 2017-07-26 16:14:04,299 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_no_shell - Testcase -1: PASSED 2017-07-26 16:14:04,300 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_output - Testcase -1: PASSED 2017-07-26 16:14:04,300 - oe-selftest - INFO - RESULTS - runcmd.RunCmdTests.test_output_split - Testcase -1: PASSED
=============================================================================
NOTES:

All the complete list in the attachment
MediumNEWnormalAutomated Build TestingUpdate and add the ID to the TCs in testopia:ubuntu1604 
11873*
11873

These TCs need to be added to testopia, to the oeqa / selftest testrun and the script needs to be modified to add the IDs.

Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal-4.8" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "2.3" TUNE_FEATURES = "m64 core2" meta-selftest = "heads/master:8e15e9b6e478f6368034519b2a8fd3c7ea71d23b"


2017-07-26 12:00:02,700 - oe-selftest - INFO - RESULTS - distrodata.Distrodata.test_checkpkg - Testcase -1: FAILED

2017-07-26 12:00:02,735 - oe-selftest - INFO - RESULTS - wic.Wic.test_mkfs_extraopts - Testcase -1: FAILED
MediumNEWnormalAutomated Build TestingThese TCs need to be added to testopia Distrodata.test_checkpkg and Wic.test_mkfs_extraopts 
11881*
11881

meta-freescale includes a class (machine-overrides-extender) to make it easy for a BSP maintainer to create, and a BSP user to switch between, multiple *sets* of configurations for a given MACHINE.

Why would a BSP want to do that? Because in some cases there are multiple choices for the user. For example: for the kernel, the user could choose either the vendor kernel or the upstream kernel. However, sometimes these decisions are "locked" together: i.e. if you want to use the vendor's binary blob for (say) graphics, then you have to use their vendor kernel as well. It's not possible for a user to choose, say, the graphics binary blob but want to use the upstream kernel too. Therefore the BSP ends up with "sets" of configurations which need to be taken collectively instead of piecemeal.

I would like to see this functionality added to oe-core so all BSPs could take advantage of this feature without having to duplicate this class per BSP.

The class can be found here: https://github.com/Freescale/meta-freescale/blob/master/classes/machine-overrides-extender.bbclass

An example of its use can be found here:

https://github.com/Freescale/meta-freescale/blob/master/conf/machine/include/imx-base.inc
MediumNEWenhancementBSPsadd infrastructure to allow BSPs to switch between *set* of configurations 
11889*
11889

STATUS: PASSED BUILD: 2.4 M2: rc2-8e15e9b6e478f6368034519b2a8fd3c7ea71d23b ENVIRONMENT: Debian 4.3.0-0.bpo.1-amd64 STEPS TO REPRODUCE:

       1. git checkout 8e15e9b6e478f6368034519b2a8fd3c7ea71d23b
       
       2.  Start Toaster.

3. Click on new project button.

4. Enter a project name, select a release and click on create project.

5. Build an image (bitbake core-image-minimal)

ACTUAL OUTCOME:

The build process stuck in 0%


NOTES:

On 2.4 m2 rc2 release toaster component was missing commits and hence it was failing in compilation. It was indicated to not Test toaster in poky 8e15e9b6e478f6368034519b2a8fd3c7ea71d23b but rather to test in master release. When doing so, the build finish successfully and toaster testcases were able to execute correctly

This bug is just to track this tweak and to be included in the QA cycle report for 2.4 m2 rc2 as a note or known issue for users.
MediumNEWnormalToaster[toaster] Toaster did not build on 2.4 m2 rc2 release 
11890*
11890

It would be a lot faster if pure python (ie no C) modules could just be installed into the sysroot without having to build python3-native.

If we export PYTHONPATH=$SYSROOT/$libdir/python3/site-packages/ then Python will look in the right place.

The hard bit will be changing distutils3-base so that it doesn't unconditionally inherit python3native.
MediumNEWenhancementOE-CoreAllow installation of pure Python modules without building python3-native 
11891*
11891

In a wic-using core-image-sato, bmaptools-native is the only recipe in the build that depends on python-native. If bmaptools can be ported to Python 3 then we won't need to build python-native at all!

Upstream bug: https://github.com/01org/bmap-tools/issues/14
MediumNEWenhancementOE-CorePort bmaptools to Python 3 
11908*
11908

For those tests that check signature generation of two builds, it would be useful (for debugging purposes) to show more info on the stamps difference. One approach would be to generalized what is proposed on the series [1]

[1] http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140553.html
MediumNEWenhancementOE-Coreinclude more info when signatures do not match on the SstateTest unit tests 
11936*
11936 since many of us run the terminal in order to type ifconfig in order to ssh into the device, it might be helpful if we just displayed the ip address at the top of the screen and maybe even in the motd on minimal.
MediumNEWenhancementSatosato display should show ip address if available 
11937*
11937

STATUS: FAILED BUILD: 2.4 M2: rc2-0d32b245e44574a612b9b48789498a78d80e9098 ENVIRONMENT: corei7-64_lsb_CherryHill meta-yocto-bsp = "HEAD:9ed748a542b520c1cb763d981969233c0f5efd4e"

Image downloaded from: http://yocto-ab-master.jf.intel.com/pub/releases/yocto-2.4_M2.rc2/machines/intel-corei7-64-lsb/core-image-lsb-sdk-intel-corei7-64.hddimg

Image corei7-64-lsb is failing on CherryHill giving the following error:

NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) NOTE: ----------------------------------------------------------------------

Central error: [ 5.156200] [drm:valleyview_update_wm] *ERROR* timed out waiting for Punit DDR DVFS request

[ 4.895551] intel_telemetry: version 1.0.0 loaded [ 4.895595] oprofile: using NMI interrupt. [ 4.895639] u32 classifier [ 4.895641] Actions configured [ 4.896265] NET: Registered protocol family 10 [ 4.897199] sit: IPv6 over IPv4 tunneling driver [ 4.897701] NET: Registered protocol family 17 [ 4.897873] NET: Registered protocol family 36 [ 4.897916] Key type dns_resolver registered [ 4.900970] Btrfs loaded [ 5.156200] [drm:valleyview_update_wm] *ERROR* timed out waiting for Punit DDR DVFS request [ 5.231355] usb 1-1: new high-speed USB device number 2 using xhci_hcd [ 5.263495] Console: switching to colour frame buffer device 240x67 [ 5.428188] usb-storage 1-1:1.0: USB Mass Storage device detected [ 5.428412] scsi host0: usb-storage 1-1:1.0 [ 5.580553] usb 1-2: new high-speed USB device number 3 using xhci_hcd [ 5.792362] hub 1-2:1.0: USB hub found [ 5.798631] hub 1-2:1.0: 4 ports detected [ 5.895561] console [netcon0] enabled [ 5.902034] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 5.911342] netconsole: network logging started



EXPECTED OUTCOME:

No errors or fails should be present in logs
MediumNEWnormalBSPs[Testcase 1059] Parselogs is failing corei7-64-lsb on Cherry Hill giving error: *ERROR* timed out waiting for Punit DDR DVFS request 
10224*
10224 Not sure about the terminal codec , considering the reproducibility is very low , I am to OK to close this as 'Won't fix'.
MediumRESOLVEDnormalAutomated Runtime Testingoeqa/utils/sshcontrol.py:SSHProcess decode stdout data fail 
10632*
10632 commit 4f2baebf362d71351db044c0646f9bc6e8a39c49
MediumRESOLVEDenhancementToasterAdd distro selection support 
10947*
10947 this is not a priority for now
MediumRESOLVEDnormalToasterReintegrate fully functional and corrected toaster automation testcases from toaster_automation_tests.py 
11027*
11027

Change pushed to production in commit:

0a48d51f84f3ab14a93cb932b39e1235789c4ae3
MediumRESOLVEDenhancementPatchwork/Patchtestpatchwork: Notify if status-change-through-email was attempted without required privileges 
11200*
11200

Change pushed to production in commit:

0866a65ab53102f14c5fd3e7da4c23ade3bf1d7d
MediumRESOLVEDnormalPatchwork/Patchtestpatchwork: Bundle paging links drop "archive" query parameter 
11229*
11229

This should not really be fixed in RMC. RMC uses whatever processor type is reported by smbios to generate a board fingerprint. Qemu modifies the processor type field in each of its releases. Therefore to support multiple qemu releases with the same rmc.db record, we should use a common machine type by passing "-machine" parameter when qemu is started.

https://lists.yoctoproject.org/pipermail/meta-intel/2017-March/004702.html
MediumRESOLVEDnormalBSPsDifferent major versions of QEMU produce different RMC fingerprints 
11244*
11244 Closed in agreement with the previous comments from Jaska. The feature already has two test cases to validate the pulseaudio modules are loaded, currently located on https://github.com/intel/intel-iot-refkit/blob/master/meta-iotqa/lib/oeqa/runtime/multimedia/audio/pulseaudio.py
MediumRESOLVEDenhancementIoT Reference OS Kit TestingQA: Validate Reference kit has BT audio support on gateway profile 
11246*
11246

Closed in agreement with the previous comments from Patrick. The image installer feature already has three test cases to validate basic installation scenarios. Tests are currently located on https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/lib/oeqa/selftest/image-installer.py

As stated by Patrick, QA still needs to determine the best way to track the development of additional tests that may be added later.
MediumRESOLVEDenhancementIoT Reference OS Kit TestingQA: Validate Reference kit supports image installer 
11251*
11251

Hi Jair,

According to https://bugzilla.yoctoproject.org/show_bug.cgi?id=11083, the solution to achieve GPLv3 free computer vision profile is to drop Python 2 from the image.

I am closing this as there is not test case needed as it only involve dropping Python 2 from image.
MediumRESOLVEDenhancementIoT Reference OS Kit TestingQA: Validate updated components for GPLv3 free Computer Vision profile 
11255*MediumRESOLVEDenhancementIoT Reference OS Kit TestingQA: Clean up and enablement of single-node Bluetooth test cases on meta-iotqa 
11286*MediumRESOLVEDenhancementOE-Corerunqemu should validate the rootfs type it is trying to use and print clear message if unsupported. 
11294*
11294

The requested functionality is provided in commit:

f7c2ec9f8719ee37bdca866c881ca5d853f9aefc
MediumRESOLVEDenhancementOE-Corecreate-pull-request: add in-reply-to option to ensure patch/series threads don't break 
11320*
11320 Won't apply to RMC2.
MediumRESOLVEDenhancementBSPsRMC: Extend grub-efi to process RMC database file from ESP 
11321*
11321 Does not apply to RMC2.
MediumRESOLVEDenhancementBSPsRMC: grub-efi - append KBOOTPARAM to linux boot entry's cmdline 
11338*
11338 Won't apply to RMC2. Data store will be a directory tree.
MediumRESOLVEDenhancementBSPsRMC: records cannot be added to and removed from an existing RMC database 
11347*
11347 Bruce's comment.
MediumRESOLVEDenhancementDemosCreate a demo that shows a Yocto built Zephyr image running on Arduino 101 
11405*
11405 Does not apply to RMC2.
MediumRESOLVEDnormalBSPsRMC: records in an existing RMC database cannot be updated 
11446*
11446 This requirement is not valid now.
MediumRESOLVEDenhancementBSPsFlexibility and configurability to boot from any partition 
11456*
11456

I'm fine with following the sensible Debian policy. Thanks for the explanation.

The problem we encountered was due to an upper case LINUX_VERSION_EXTENSION as Joe explained.
MediumRESOLVEDnormalOE-CoreLINUX_VERSION_EXTENSION cannot contain capital letters for ipk packaging 
11462*
11462 The PR #200 got merged.
MediumRESOLVEDenhancementIoT Reference OS KitROS-Core support 
11465*
11465 Got merged to intel-iot-refkit
MediumRESOLVEDenhancementIoT Reference OS KitReference Kit Industrial Robotics Profile Detailed Documentation 
11476*
11476 Replace iptables with nftables. Add new features provided by nftables, like modular file-based firewall configuration. Support multiple network interfaces classified to different logical networks (LAN, WAN, VPN, ...). Make performance comparisons between the firewalls.
MediumRESOLVEDenhancementIoT Reference OS KitNftables firewall support 
11477*MediumRESOLVEDenhancementIoT Reference OS KitDetailed computer vision profile documentation 
11478*
11478 The DNN module is now enabled and a test is added to Refkit. The test downloads an ImageNet Caffe model (the same used in the meta-refkit-extra Caffe demos) and uses it to classify an image without enabling meta-refkit-extra layer. In the future the caffe recipe could be changed to use the caffe-reference-bvlc recipe for downloading the test data.
MediumRESOLVEDenhancementIoT Reference OS KitMove caffe from meta-refkit-extra to meta-refkit 
11481*MediumRESOLVEDenhancementIoT Reference OS KitRefkit image configuration guidelines 
11485*
11485 Now nodejs version updated to 6.11 in refkit .
MediumRESOLVEDenhancementIoT Reference OS KitRefkit: Upgrade nodejs version(v5.11+) 
11490*
11490

Here is the update on OpenWRT's uci/LuCI evaluation:

- UCI: is the configuration solution for OpenWRT's systems. - LuCI/LuCI2/JuCI : is the web interface for configuring devices running OpenWRT system, built on top of UCI. License: Apache-2.0 - LuCI is Lua based, and uses Lua extensions to access subsystem info and is appeared to be quite resource consuming and didn't work well on devices with slow CPU and little amount of RAM. - LuCI2 is a new(experimental) web interface with a different architecture written using JavaScript. It uses XHR(XmlHTTPRequest) method., that means building the HTML pages is done at client side. LuCI2 uses ubus(inter-process communication bus system) to communicate with the subsystem. License: Apache v2.0 - JuCI is modern web interface build using HTML5 and angular.js, and uses websockets for communicating with a compact and fast lua backend running o the device. License: GPLv3 - LuCI2 is preferred web interface over Luci and Juci due to it's simple architecture, less external dependencies and flexible licensing. - LuCI2 web interface provides configuration ui for:

   - System information such as host name, device model, Firmware version, Kernel version, Device memory information, Storage details.
   - Routes –     IPv4/v6 routes active on the system
   - Kernel logs
   - System logs     (/var/log/messages)
   - Sending signals to running processes     
   - Add/remove ssh keys(dropbear)
   - Adding/removing network interfaces
   - enable/disable a network device

- Luci2 provides base widgets(JS objects) which can be extended to customize the ui. New UI tabs/views can be added by extending Luci's L.ui.view JavaScript object.

- External dependencies we bring-in:

   libubox – C utility functions for OpenWrt
   uci  - A small utility written in C, intended to centralize the configuration
   ubus – OpenWrt micro bus for inter process communication
   rpcd – ubus RPC backend server
   luci2 - OpenWrt web user interface
   uhttp2     – light weight web server
   ustream-ssl - Ustream SSL wrapper library

The Yocto meta data for these components are grouped under meta-configuration layer:

  https://github.com/avalluri/meta-configuration

There needs to be work done at system adaptation., i.e, Make refkit core components such as openssh, connman etc., aware of UCI configuration, by writing adapters. Similar proof of concept work is done here: https://github.com/avalluri/rpcd-system-plugin

https://github.com/avalluri/connman-uci
MediumRESOLVEDenhancementIoT Reference OS KitConfiguration Management Solution Study 
11492*
11492 Rejected.
MediumRESOLVEDenhancementIoT Reference OS KitReference Kit Gateway Profile Detailed Documentation 
11523*
11523

You've fixed it:

commit b2b422c190af482a0b4b7291545aa3239c15a1e8 Author: brian avery <brian.avery@intel.com> Date: Wed Apr 19 12:49:04 2017 -0700

   qemuboot.bbclass: save relative paths in conf file
   
   This saves relative paths in the qemuboot.conf file instead of absolute
   paths. This is to allow the images and kernels to be relocated and still
   have the testimage and runqemu work.
   
   [YOCTO #11375]
   
   (From OE-Core rev: 235243d7be5df57df4767e4710b846e83f0aa9fd)
   
   Signed-off-by: brian avery <brian.avery@intel.com>
   Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MediumRESOLVEDnormalOE-Coreqemuboot.conf files in the downloads.../machines/qemu/qemu<machine> should be scrubbed of ab paths 
11530*
11530 Closing this, we decided that RMC will not support secure boot out of the box.
MediumRESOLVEDenhancementBSPsRMC:[EFI] modify shim to launch an EFI binary when not running in secure boot mode 
11541*
11541

This bug covers the implementation of the MD5 fingerprint generator, which is now complete. The implementation of the different methods for reading smbios data is in progress and is covered by this bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=11537
MediumRESOLVEDnormalBSPsRMC: print the fingerprint and MD5 hash of the current board 
11542*MediumRESOLVEDnormalOE-Corerunqemu does not display the error text from qemu-system-XXX when qemu-system-XXX fails to run 
11588*
11588 PR #167 is merged.
MediumRESOLVEDnormalIoT Reference OS KitCan't resolve own hostname when running under QEMU 
11589*
11589

Please add below configuration in conf/local.conf and the build will successful. MKUBIFS_ARGS = " -m 512 -e 15360 -c 3600 " UBINIZE_ARGS = " -p 16KiB -m 512 -s 512 "


https://lists.yoctoproject.org/pipermail/yocto/2013-June/014757.html

Enhancement on image_type.bbclass in order to pre-early bring out the error and example configuration for any ubi and ubifs image build.
MediumRESOLVEDnormalOE-Coreubi and ubifs image compression failed on do_image_ubi and do_image_ubifs[2]
11590*MediumRESOLVEDnormalOE-Corecreating root file systems using elf failed applying patch fix-makefile-to-find-libz.patch[3]
11616*
11616 Closing. I am not seeing this in the current builds.
MediumRESOLVEDnormalOE-CoreMesa build failed with gcc 7 (ARM) 
11675*
11675

This has been merged into bitbake. Marking as RESOLVED and set doc flag to "Done".

Thanks!
MediumRESOLVEDnormalBitBake User Manualbitbake.conf URL link example should be updated 
11684*
11684 commit d74bcbeaf241a67871d62b7e2c17900ae900642e
MediumRESOLVEDnormalToasteraddress RemovedInDjango110Warning's for Django >= 1.9 
11708*
11708

(In reply to comment #11) > whats the known method to get python3 xmlrunner on Ubuntu 16.04.2 ?

Install the python3-pip package, then run (as root) "pip3 install unitest-xml-reporting".
MediumRESOLVEDnormalIoT Reference OS KitCI: capture and display results of oe-selftest as JUnit XML 
11718*
11718 Merged in OE-Core 1bd3ed18379c330c1c733dc9f043dbbe8aa0d254.
MediumRESOLVEDnormalOE-CoreRPM injects /usr/lib/.build-id/ into packages 
11719*
11719 The fix has been merged to poky master. Commit id 1b11a653d0be6128b26ea9421c783c6e78f7549b
MediumRESOLVEDnormalOE-CoreUnneeded stack trace is printed when ruunqemu fails 
11727*
11727 Commit a25ece2d77f28e71a71913ea25391bcbc8fa37e0
MediumRESOLVEDnormalToastertrim build target input 
11730*MediumRESOLVEDnormalOE-Corekernel-devsrc: various references to the host build system 
11744*
11744 Commit a25ece2d77f28e71a71913ea25391bcbc8fa37e0
MediumRESOLVEDnormalToasterset clone progress default to off 
11765*
11765 A DAFT test fixture has been created. I have a attached a picture of it.
MediumRESOLVEDenhancementAutomated Runtime TestingCreate DAFT test fixture for BSP QA cycles 
11767*
11767 The fix has been merged to poky master. Commit id d66314a18c0c1aeeef50185635dbbe76e48b72d1
MediumRESOLVEDnormalOE-Coreelf image compression failed due missing cpio.gz file 
11768*MediumRESOLVEDnormalAutoBuilderRun core-image-sato-sdk instead of core-image-sato for musl target 
11790*
11790 The fix has been merged into poky master. Commit id 8fb8a21b7d4f1fb69f0407f03fd5907d861f7d42
MediumRESOLVEDnormalOE-CoreWIC creates wrong partition number 
11794*
11794 commit 3bc3d26b465b5af3cebc1d4c0d1fa382965c32cf
MediumRESOLVEDenhancementToasterAdd remote HTTP API to enable status aggregation of multiple Toaster instances 
11819*
11819

1. More additions to local.conf are required to produce multiubi image

Here is an example:

IMAGE_FSTYPES += "multiubi" MULTIUBI_BUILD ?= "normal large" export MKUBIFS_ARGS_normal = "-F -m 2048 -e 124KiB -c 1912 -x zlib" export UBINIZE_ARGS_normal = "-m 2048 -p 128KiB -s 2048" export MKUBIFS_ARGS_large = "-F -m 4096 -e 248KiB -c 8124 -x zlib" export UBINIZE_ARGS_large = "-m 4096 -p 256KiB -s 4096"

with above 6 lines in local.conf 'bitbake core-image-minimal' produces set of expected images just fine:

$ ls -la tmp/deploy/images/qemux86-64/ |grep ubi -rw-r--r-- 2 ed users 8126464 Jul 28 13:12 core-image-minimal-qemux86-64-20170728093839_large.rootfs.ubi -rw-r--r-- 2 ed users 7364608 Jul 28 13:12 core-image-minimal-qemux86-64-20170728093839_large.rootfs.ubifs -rw-r--r-- 2 ed users 6422528 Jul 28 13:12 core-image-minimal-qemux86-64-20170728093839_normal.rootfs.ubi -rw-r--r-- 2 ed users 5967872 Jul 28 13:12 core-image-minimal-qemux86-64-20170728093839_normal.rootfs.ubifs lrwxrwxrwx 2 ed users 61 Jul 28 13:12 core-image-minimal-qemux86-64_large.ubi -> core-image-minimal-qemux86-64-20170728093839_large.rootfs.ubi lrwxrwxrwx 2 ed users 63 Jul 28 13:12 core-image-minimal-qemux86-64_large.ubifs -> core-image-minimal-qemux86-64-20170728093839_large.rootfs.ubifs lrwxrwxrwx 2 ed users 62 Jul 28 13:12 core-image-minimal-qemux86-64_normal.ubi -> core-image-minimal-qemux86-64-20170728093839_normal.rootfs.ubi lrwxrwxrwx 2 ed users 64 Jul 28 13:12 core-image-minimal-qemux86-64_normal.ubifs -> core-image-minimal-qemux86-64-20170728093839_normal.rootfs.ubifs -rw-r--r-- 2 ed users 289 Jul 28 13:12 ubinize_large-core-image-minimal-qemux86-64-20170728093839.cfg -rw-r--r-- 2 ed users 290 Jul 28 13:12 ubinize_normal-core-image-minimal-qemux86-64-20170728093839.cfg


2. My guess is that building container images doesn't produce rootfs.container. This is covered by containerimage test which passes on current master:

$ oe-selftest -r containerimage 2017-07-28 13:22:40,790 - oe-selftest - INFO - Adding layer libraries: 2017-07-28 13:22:40,790 - oe-selftest - INFO - /home/ed/git/yocto/poky/meta/lib 2017-07-28 13:22:40,791 - oe-selftest - INFO - /home/ed/git/yocto/poky/meta-yocto-bsp/lib 2017-07-28 13:22:40,791 - oe-selftest - INFO - /home/ed/git/yocto/poky/meta-selftest/lib 2017-07-28 13:22:40,792 - oe-selftest - INFO - Running bitbake -p 2017-07-28 13:23:32,153 - oe-selftest - INFO - test_expected_files (containerimage.ContainerImageTests) ... ok 2017-07-28 13:23:32,154 - oe-selftest - INFO - 2017-07-28 13:23:32,154 - oe-selftest - INFO - ---------------------------------------------------------------------- 2017-07-28 13:23:32,154 - oe-selftest - INFO - Ran 1 test in 38.096s 2017-07-28 13:23:32,154 - oe-selftest - INFO - 2017-07-28 13:23:32,154 - oe-selftest - INFO - OK 2017-07-28 13:23:32,154 - oe-selftest - INFO - RESULTS: 2017-07-28 13:23:32,154 - oe-selftest - INFO - RESULTS - containerimage.ContainerImageTests.test_expected_files - Testcase 1619: PASSED 2017-07-28 13:23:32,155 - oe-selftest - INFO - SUMMARY: 2017-07-28 13:23:32,155 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 38.096s 2017-07-28 13:23:32,155 - oe-selftest - INFO - oe-selftest - OK - All required tests passed

Please, look at the test case to get more details.

NOTE: This looks like 2 absolutely unrelated issues to me and shouldn't be put in one bug. Please, consider to create one bug per issue next time.
MediumRESOLVEDnormalOE-Coremultiubi and container rootfs is not being created 
11840*
11840 Works now and a more recent checkuri worked, so it was a transient failure.
MediumRESOLVEDnormalOE-Core[master] nightly-checkuri libtimedate-perl_2.30 
11842*
11842 The fix has been merged into poky master. Commit id: b8cb2bb17508020899a5ffaa29aee941922d68e0
MediumRESOLVEDnormalOE-CoreSetting NOHDD=1 and NOISO=1 no longer allows you to build a >4GB image 
11681*
11681

Poky tiny images were successfully created (core2-32 and corei7-64).(In reply to comment #9) > Poky tiny images were successfully created (core2-32 and corei7-64).

tested in commit:98099349e358a9caaec8ec81f0d4abe588909cfe
MediumVERIFIEDmajorBSPspoky-tiny fails to build because of resource unavailability 
11699*
11699 Verified
MediumVERIFIEDnormalDevelopment Manual[megamanual] dnf using rpm: 5.18.4.3.1. Using RPM section changes required 
11870*
11870 duplicated
MediumVERIFIEDenhancementOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1 Ubuntu1604 
10543*
10543 adding scott
Medium+ACCEPTEDenhancementCROPSuse CDT "new build system" to enable building for Make project 
10545*
10545 adding scott and giving to chin huat.
Medium+ACCEPTEDenhancementCROPSuse CDT "new build system" to enable building for Automake project 
11394*
11394 Bugs 11390 and 11391 demonstrate that there's a bit of a gap in our testing of devtool and git URLs. We should have some tests that verify the conditions that trigger those bugs once they are fixed, as well as tests that exercise the behaviour implemented in reformat_git_uri() in scripts/lib/recipetool/create.py.
Medium+ACCEPTEDenhancementAutomated Runtime TestingAdd tests to cover devtool handling of various git URL styles 
11424*
11424

Add Link Time Optimization (LTO) to poky-tiny's kernel.

Some work has already been submitted and its been merged on yocto-kernel-cache and linux-yocto MLs, although this work was for kernel 4.4.

A rebase to this previous work needs to be done to make it work with newer production kernels, the reason why this is not merged for newer kernels is that there are some compilation/linking issues with kernels > 4.4.
Medium+ACCEPTEDenhancementMeta-yoctopoky-tiny + Link Time Optimization 
11497*
11497 Moving milestone as dependent bug #11623 isn't going to make M2
Medium+ACCEPTEDnormaleSDKeSDK: create test case for populate_sdk_ext using shared states 
11567*
11567

Leonardo,

Tell me the impact to the user. Is the script named the same? Does it just live somewhere else now? If you can describe the feature from the point of view of the user that would be using it then I can work something up.

Thanks,

Scott
Medium+ACCEPTEDnormalBitBakeTrying to create an new layer with the yocto-layer script fails. 
11737*
11737 Moved to 2.5 as this feature is not yet integrated
Medium+ACCEPTEDnormalAutomated Build Testinginclude selftest tests for devtool import/export plugins 
11176*
11176

Add optional post-process command to use strip-nondeterminism to remove sources of non-derterminism from the rootfs.

This will provide an optional "hammer" to improve the determinism of the system's output whilst we continue to work on the wider problem of reproducible builds with the Yocto Project.

Post-processing a rootfs with strip-nondeterminism will provide immediate benefits to users of the system performing file-based updates (i.e. we'll be better able to produce a new rootfs for processing by OSTree which only includes real changes, not just changes introduced by non-determinism).
Medium+IN PROGRESS DESIGNenhancementOE-CoreAdd optional command to rootfs-postprocess to remove non-determinism from rootfs 
11177*
11177 will be part of the "reproducible binaries" patch set.
Medium+IN PROGRESS DESIGNenhancementOE-CoreGenerate archives with deterministic metadata 
11178*
11178

Probably worth mentioning: in local.conf:

PACKAGE_CLASSES = "package_rpm package_deb package_ipk"

BUILD_REPRODUCIBLE_BINARIES="1"
Medium+IN PROGRESS DESIGNenhancementOE-CoreUse SOURCE_DATE_EPOCH 
11209*
11209

(In reply to comment #20) > > Are the steps in Comment 15 basically the procedure to get this done? If > so, we can add a section that documents those steps. > > We do have this section > (http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#signing-rpm- > packages) in the dev-manual. > > Can we just update that section?

No, it's related to the next section: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing-package-feeds

You could just remove RPM from the note saying that signed package feeds are not supported.
Medium+IN PROGRESS DESIGNnormalOE-CoreRPM package feed signing is currently not supported 
11483*
11483

Automate first 7 testcases from testplan

https://bugzilla.yoctoproject.org/tr_show_plan.cgi?plan_id=207
Medium+IN PROGRESS DESIGNenhancementAutomated Runtime TestingAutomate testcases for package management 
11702*
11702

(In reply to comment #0) > If local.conf doesn't have a newline at the end, we get this error: > > $ oe-selftest -r > archiver.Archiver.test_archiver_allows_to_filter_on_recipe_name > 2017-06-22 11:40:18,363 - oe-selftest - INFO - Adding layer libraries: > 2017-06-22 11:40:18,363 - oe-selftest - INFO - /media/build1/poky/meta/lib > 2017-06-22 11:40:18,364 - oe-selftest - INFO - > /media/build1/poky/meta-yocto-bsp/lib > 2017-06-22 11:40:18,364 - oe-selftest - INFO - > /media/build1/poky/meta-selftest/lib > 2017-06-22 11:40:18,364 - oe-selftest - INFO - Running bitbake -p > 2017-06-22 11:40:23,385 - oe-selftest - INFO - > 2017-06-22 11:40:23,386 - oe-selftest - INFO - Running tests... > 2017-06-22 11:40:23,498 - oe-selftest - INFO - > ---------------------------------------------------------------------- > 2017-06-22 11:40:46,005 - oe-selftest - INFO - > test_archiver_allows_to_filter_on_recipe_name (archiver.Archiver) ... ERROR > (22.506s) > 2017-06-22 11:40:46,006 - oe-selftest - INFO - > 2017-06-22 11:40:46,006 - oe-selftest - INFO - > ====================================================================== > 2017-06-22 11:40:46,006 - oe-selftest - INFO - ERROR [22.506s]: > test_archiver_allows_to_filter_on_recipe_name (archiver.Archiver) > 2017-06-22 11:40:46,006 - oe-selftest - INFO - > ---------------------------------------------------------------------- > 2017-06-22 11:40:46,006 - oe-selftest - INFO - Traceback (most recent call > last): > File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line > 32, in wrapped_f > return func(*args, **kwargs) > File "/media/build1/poky/meta/lib/oeqa/selftest/cases/archiver.py", line > 33, in test_archiver_allows_to_filter_on_recipe_name > src_path = os.path.join(bb_vars['DEPLOY_DIR_SRC'], bb_vars['TARGET_SYS']) > File "/usr/lib/python3.5/posixpath.py", line 89, in join > genericpath._check_arg_types('join', a, *p) > File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types > (funcname, s.__class__.__name__)) from None > TypeError: join() argument must be str or bytes, not 'NoneType' > 2017-06-22 11:40:46,007 - oe-selftest - INFO - > ---------------------------------------------------------------------- > 2017-06-22 11:40:46,007 - oe-selftest - INFO - Ran 1 test in 22.507s > 2017-06-22 11:40:46,007 - oe-selftest - INFO - > 2017-06-22 11:40:46,007 - oe-selftest - INFO - FAILED (errors=1) > 2017-06-22 11:40:46,007 - oe-selftest - INFO - > 2017-06-22 11:40:46,007 - oe-selftest - INFO - Generating XML reports... > 2017-06-22 11:40:46,011 - oe-selftest - INFO - RESULTS: > 2017-06-22 11:40:46,011 - oe-selftest - INFO - RESULTS - > archiver.Archiver.test_archiver_allows_to_filter_on_recipe_name - Testcase > 1345: ERROR > 2017-06-22 11:40:46,011 - oe-selftest - INFO - SUMMARY: > 2017-06-22 11:40:46,011 - oe-selftest - INFO - oe-selftest () - Ran 1 test > in 22.626s > 2017-06-22 11:40:46,011 - oe-selftest - INFO - oe-selftest - FAIL - Required > tests failed > > We can likely do better than this.

I can't reproduce this error, i deleted the 0x0a character with vim (:set noendofline binary) and then verified with hexdump -C.

And for me this test passes.

Anibal
Medium+IN PROGRESS DESIGNnormalAutomated Build Testingoe-selftest fails if local.conf doesn't end with a newline 
11705*
11705

Alex Kanavin confirmed the wrappers are only needed when cross-compiling.

So the fix is not to include the wrappers from the final image.
Medium+IN PROGRESS DESIGNnormalOE-Coregobject-introspection_1.50.0 contains various references to the host build system 
11791*
11791

Images QA test are:

   - beaglebone/
        - core-image-sato-sdk-beaglebone.*
        - u-boot*
        - zImage*
   - edgerouter/
        - core-image-sato-sdk-edgerouter.*
        - miodules*
        - vmlinux*
   - mpc8315e-rdb/
        -   core-image-minimal-mpc8315e-rdb.*
   -  genericx86-64-lsb/
        -  core-image-lsb-sdk-genericx86-64.*
   -  genericx86-64/
        -  core-image-sato-sdk-genericx86-64.*
        -  core-image-sato-sdk-ptest-genericx86-64.hddimg
        -  core-image-sato-sdk-ptest-genericx86-64.wic
   -  genericx86-lsb/
        -  core-image-lsb-sdk-genericx86.*
   -  genericx86-64/
        -  core-image-sato-sdk-genericx86.*
    - qemu/
          - qemux86/
              -  bzImage-qemux86.bin
              -  core-image-sato-sdk-qemux86.*
          - qemux86-64/
              -  bzImage-qemux86-64.bin
              -  core-image-sato-sdk-qemux86-64.*
          - qemuarm/ && qemuarm64/ && qemumips/ && qemumips64/ && qemuppc/
              - *.bin
- core-image-sato-sdk*
Medium+IN PROGRESS DESIGNenhancementAutoBuilderReduce the amount and storage space required of image artefacts published from builds 
11818*
11818

(In reply to comment #1) > Created attachment 3922 [details] > oe-selftest run bb_server_timeout=100 failure log > > First run the tests that fails, see full log, > > 2017-08-07 20:21:14,503 - oe-selftest - INFO - RESULTS - > archiver.Archiver.test_archiver_allows_to_filter_on_recipe_name - Testcase > 1345: FAILED > 2017-08-07 20:21:14,503 - oe-selftest - INFO - RESULTS - > archiver.Archiver.test_archiver_filters_by_type - Testcase -1: FAILED > 2017-08-07 20:21:14,503 - oe-selftest - INFO - RESULTS - > archiver.Archiver.test_archiver_filters_by_type_and_name - Testcase -1: > FAILED > 2017-08-07 20:21:14,506 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_bbappend_order - Testcase 1425: FAILED > 2017-08-07 20:21:14,508 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_event_handler - Testcase 806: FAILED > 2017-08-07 20:21:14,509 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_image_manifest - Testcase 899: FAILED > 2017-08-07 20:21:14,509 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_invalid_patch - Testcase 108: FAILED > 2017-08-07 20:21:14,511 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_prefile - Testcase 1032: FAILED > 2017-08-07 20:21:14,512 - oe-selftest - INFO - RESULTS - > bbtests.BitbakeTests.test_setscene_only - Testcase 1422: FAILED > 2017-08-07 20:21:14,513 - oe-selftest - INFO - RESULTS - > buildoptions.BuildhistoryTests.test_buildhistory_basic - Testcase 293: FAILED > 2017-08-07 20:21:14,514 - oe-selftest - INFO - RESULTS - > buildoptions.ImageOptionsTests.test_ccache_tool - Testcase 286: FAILED > 2017-08-07 20:21:14,514 - oe-selftest - INFO - RESULTS - > buildoptions.ImageOptionsTests.test_incremental_image_generation - Testcase > 761: FAILED > 2017-08-07 20:21:14,516 - oe-selftest - INFO - RESULTS - > containerimage.ContainerImageTests.test_expected_files - Testcase 1619: > FAILED > 2017-08-07 20:21:14,528 - oe-selftest - INFO - RESULTS - > distrodata.Distrodata.test_checkpkg - Testcase -1: FAILED > 2017-08-07 20:21:14,531 - oe-selftest - INFO - RESULTS - > imagefeatures.ImageFeatures.test_long_chain_conversion - Testcase -1: FAILED > 2017-08-07 20:21:14,531 - oe-selftest - INFO - RESULTS - > imagefeatures.ImageFeatures. > test_non_root_user_can_connect_via_ssh_without_password - Testcase 1107: > FAILED > 2017-08-07 20:21:14,545 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_import_export_override_db - Testcase 931: > FAILED > 2017-08-07 20:21:14,545 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_import_export_replace_db - Testcase 930: FAILED > 2017-08-07 20:21:14,546 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_deb_arch_dep - Testcase 934: FAILED > 2017-08-07 20:21:14,546 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_deb_arch_indep - Testcase 937: > FAILED > 2017-08-07 20:21:14,546 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_ipk_arch_dep - Testcase 933: FAILED > 2017-08-07 20:21:14,546 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_ipk_arch_indep - Testcase 936: > FAILED > 2017-08-07 20:21:14,546 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_rpm_arch_dep - Testcase 932: FAILED > 2017-08-07 20:21:14,547 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_pr_service_rpm_arch_indep - Testcase 935: > FAILED > 2017-08-07 20:21:14,558 - oe-selftest - INFO - RESULTS - > recipetool.RecipetoolTests.test_recipetool_create_github - Testcase 1638: > FAILED > 2017-08-07 20:21:14,570 - oe-selftest - INFO - RESULTS - > runtime_test.TestImage.test_testimage_dnf - Testcase 1883: FAILED > 2017-08-07 20:21:14,572 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_cleansstate_task_distro_nonspecific - Testcase > 1376: FAILED > 2017-08-07 20:21:14,573 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests. > test_rebuild_distro_specific_sstate_cross_native_targets - Testcase 175: > FAILED > 2017-08-07 20:21:14,573 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_rebuild_distro_specific_sstate_native_target - > Testcase 1373: FAILED > 2017-08-07 20:21:14,575 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_cache_management_script_using_machine - > Testcase 974: FAILED > 2017-08-07 20:21:14,575 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_cache_management_script_using_pr_1 - > Testcase 973: FAILED > 2017-08-07 20:21:14,575 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_cache_management_script_using_pr_2 - > Testcase 978: FAILED > 2017-08-07 20:21:14,576 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_creation_distro_nonspecific_pass - > Testcase 976: FAILED > 2017-08-07 20:21:14,576 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_creation_distro_specific_fail - Testcase > 1374: FAILED > 2017-08-07 20:21:14,577 - oe-selftest - INFO - RESULTS - > sstatetests.SStateTests.test_sstate_creation_distro_specific_pass - Testcase > 975: FAILED

The errors are two different ones,

1st - One related to not deterministic meta-data

2nd - Related to fetcher failures and it doesn't matter
Medium+IN PROGRESS DESIGNnormalAutomated Build TestingAllow oe-selftest to work with BB_SERVER_TIMEOUT 
11179*
11179

Locale and Timezone settings of a shell in which builds are performed can affect the build output in various ways[1][2], adding non-determinism to the system when building on machines with different TZ settings.

We should export a consistent TZ and locale to the environment in which builds are performed in order to improve the determinism of our build output.

1. https://reproducible-builds.org/docs/timezones/

2. https://reproducible-builds.org/docs/locales/
Medium+IN PROGRESS DESIGN COMPLETEenhancementOE-CoreEnsure TZ is also set to a consistent value 
11308*Medium+IN PROGRESS IMPLEMENTATIONenhancementOE-CoreConsider replacing pkg-config with pkgconf 
11429*
11429 What if I want to run selftest for all of the qemu machines? Will MACHINE be whitelisted to?
Medium+IN PROGRESS IMPLEMENTATIONenhancementOE-Coreoe-selftest should use its own build directory and write the desired configuration 
11466*
11466

https://github.com/pohly/intel-iot-refkit/commits/tpm2 contains my work-in-progress changes. Currently it only allows building tpm2.0-tools from meta-measured.

Clearly I am not going to finish this for M2, so I propose moving it to M3.
Medium+IN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS KitTPM 2.0 support (under qemu) 
11468*
11468

(In reply to comment #4) > Upstream discussion around fwupd integration into system update is now here: > https://github.com/hughsie/fwupd/issues/162

And upstream has developed a solution, see https://github.com/hughsie/fwupd/pull/163#issuecomment-318340508

Regarding testing, upstream is using Logitech unifying dongles. This looks like something that we should be able to replicate. However, each dongle can only be used for a while before the EEPROM wears out. So we should integrate this into our master build testing, but not PRs.

See https://github.com/hughsie/appstream-glib/pull/182#issuecomment-318042615
Medium+IN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS Kitintegrate firmware update into system update 
11521*
11521

seriously... the lsb builds use a 4.1 kernel and non-lsb use 4.8... sigh..

The fix for this issue caused the standard multilib mip64 core-image-minimal to fail. This issue has something to do with the console.
Medium+IN PROGRESS IMPLEMENTATIONnormalOE-Corerunqemu defaults to 512M memory if QB_MEM is not set, breaking mips64 
11522*
11522

having env variables to control aspects of qemu settings should accept the value and the runqemu script should handle the necessary command line syntactic sugar. This would seem to be more intuitive if all you do is read the variable and try to set it.


This should be done with all the env variables that runqemu uses that currently expect to have full qemu command lines set.
Medium+IN PROGRESS IMPLEMENTATIONenhancementOE-Corerunqemu env var QB_MEM expects to be set to "-m 256" not "256" or "256M" 
11547*
11547

Comments from RP:

About ptest, we don't have good tools to show "what regressed" at the moment and we don't trigger ptest as part of any of our autobuilder builds. There therefore could be some work in this area. Enabling it as part of our image testing, collecting up the results and showing where things regress in some way.
Medium+IN PROGRESS IMPLEMENTATIONenhancementOE-CoreAdd ptest to testimage 
11833*
11833

I have filed this bug against bitbake since the issue appears to not be in the Toaster code:

  Bug 11898 - bitbake server timeout on first 'server.runCommand' call after build starts

I am writing a simpler test case which I will base on knotty.

I will try out David Lopez Barriba observation (thank you!) to see if that helps. In my tests I tried to remove all background python and bitbake tasks, and I also replicated with the "noweb" option to remove that variable. My results were all over the place.

I will keep this bug open to track the issue and the bitbake progress.
Medium+IN PROGRESS IMPLEMENTATIONnormalToasterToaster timeout for bitbake server 
11158*Medium+IN PROGRESS REVIEWnormalAutomated Build Testingbitbake: Create test for multiconfig globing support 
11451*
11451

Submitted to oe-devel mailing list for meta-openwrt to review merging.

http://lists.openembedded.org/pipermail/openembedded-devel/2017-July/113681.html
Medium+IN PROGRESS REVIEWenhancementOE-CoreBring in Juci from openWRT as an on target network configurator 
11488*Medium+IN PROGRESS REVIEWenhancementAutomated Runtime TestingTestimage: Add tests for ipk/opkg like dnf/rpm ones 
11587*
11587

Implemented as a new warning flag in GCC "Wnot-cross-compiler".

In cross-compiler it does absolutely nothing, the warning will be triggered if used not in cross-compiler. It can be used to force an error when used as host compiler:

-Wnot-cross-compiler -Werror=not-cross-compiler 

If the host uses (unpatched) GCC, it will also generate an error:

gcc -Wnot-cross-compiler hello_world.c gcc: error: unrecognized command line option ‘-Wnot-cross-compiler’


So far the feedback from the mailing list is not very positive, the concern seems to be that if the host compiler is not GCC, it MAY silently ignore

any unknown command line options.
Medium+IN PROGRESS REVIEWenhancementOE-Coreadd "fence flag" to cross toolchain 
11680*Medium+IN PROGRESS REVIEWenhancementAutoBuilderEnable AB to build WIC images for qemux86 and qemux86-64 machines and publish them 
11781*
11781

Steps: $ . ../poky/oe-init-build-env-memres . $ bitbake world In another terminal: $ . ../poky/oe-init-build-env-memres . Run the following command and Ctrl-C several times: $ bitbake --observe-only Traceback (most recent call last):

 File "/buildarea/lyang1/poky/bitbake/lib/bb/ui/knotty.py", line 441, in main
   helper.eventHandler(event)
 File "/buildarea/lyang1/poky/bitbake/lib/bb/ui/uihelper.py", line 42, in eventHandler
   del self.running_tasks[event.pid]
KeyError: 43646
Medium+IN PROGRESS REVIEWnormalBitBakebitbake --observe-only may get KeyError 
11879Medium+IN PROGRESS REVIEWnormalBSPsTestimage: multiple "uvesafb" errors present in log in minnowmax on genericx86/genericx86-64 
10880*
10880 See Bruce's question
Medium+NEEDINFOnormalOE-Coreperf recipe contaminates linux shared workdir in do_configure_prepend() 
11821*
11821

(In reply to comment #0) > builddir : /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest > buildername : nightly-oe-selftest > buildnumber : 404 > commit-description : 2.4_M1-574-g2ec756257e >

Armin, Can you post the URL from where you took the log? Due to the nature of the AB, where old builds are removed, the URL may not exist anymore, so if you have the whole log locally, attach it.

> > error message. > > 017-07-23 15:25:53,161 - oe-selftest - INFO - oe-selftest - FAIL - Required > tests failed > Traceback (most recent call last): > File "/usr/lib/python3.5/weakref.py", line 624, in _exitfunc > f() > File "/usr/lib/python3.5/weakref.py", line 548, in __call__ > return info.func(*info.args, **(info.kwargs or {})) > File "/usr/lib/python3.5/tempfile.py", line 936, in _cleanup > _rmtree(name) > File "/usr/lib/python3.5/shutil.py", line 480, in rmtree > _rmtree_safe_fd(fd, path, onerror) > File "/usr/lib/python3.5/shutil.py", line 438, in _rmtree_safe_fd > onerror(os.unlink, fullname, sys.exc_info()) > File "/usr/lib/python3.5/shutil.py", line 436, in _rmtree_safe_fd > os.unlink(name, dir_fd=topfd)

> FileNotFoundError: [Errno 2] No such file or directory: 'S.gpg-agent.browser'
Medium+NEEDINFOnormalOE-Corenightly-oe-selftest 2.4_M1-574-g2ec756257e failed 
10541Medium+NEWenhancementCROPSUse "new project template" framework to create sample Devtool project 
10544*
10544 Moving to M3
Medium+NEWenhancementCROPSuse CDT "new build system" to enable building for CMake project 
10546*
10546 probably future... but we'll see.
Medium+NEWenhancementCROPSuse CDT "new build system" to enable building for Devtool project 
10548*
10548 Moving to M3
Medium+NEWenhancementCROPSEclipse CROPS plugin support for debugging via gdb to QEMU 
10549*
10549 Moving to M3
Medium+NEWenhancementCROPSEclipse CROPS plugin support for debugging via gdb to hardware target 
10556*
10556 Moving to M3
Medium+NEWenhancementCROPSDocker tooling support to manipulate CROPS containers from the Eclipse CROPS plugin 
11131*
11131

There are some tests that needs to be made based on YP Compatible registration form [1]:

- Test case to review if the README file specifies the maintainer. - Test case to review if the README file specifies where to send patches. - Test case to review if the README file contains the dependencies listed, this needs some format definition to be auditable?.

- Test case to build what the layer provides, at this time only parsing is made.

[1] https://www.yoctoproject.org/webform/yocto-project-compatible-registration
Medium+NEWenhancementMeta-yoctoAdd more tests to Yocto Project Compatible Layers script 
11183*
11183

(In reply to comment #1) > Is this maybe a duplicated of bug 10722 ?

Sorry, I mean bug 10772
Medium+NEWenhancementOE-CoreEvaluate "native" CVE scanning solution 
11360*
11360

Currently, the report always draws one line per chart in the html report (representing one tester/branch/machine). It would be nice to be able to draw multiple lines per chart, i.e. for example represent test results from multiple testers in the same chart, for example.

This will probably require a new report template. For example, the statistics currently shown are not necessarily meaningful when multiple data sets are represented in one chart.
Medium+NEWenhancementOE-Coreoe-build-perf-report: show multiple data sets per chart 
11361*
11361 Moving to 2.4M3
Medium+NEWenhancementAutomated Build Testingoe-build-perf-test: monitor system resource utilization 
11381*
11381

Make it possible to display a summary of bitbake tasks. This information is extracted from buildstats and is only available for tests/measurements where buildstats are collected.

We could display e.g. the following information: - total number of tasks - top 5 resource-hungry tasks (cputime)

- top 5 change in resource usage (cputime)
Medium+NEWenhancementOE-Coreoe-build-perf-report: show task summary 
11382*
11382

We could display the changes in build content for measurements for which buildstats are saved: - new recipes - removed recipes

- recipe version changes
Medium+NEWenhancementOE-Coreoe-build-perf-report: display changes in build content 
11517*
11517 For this particular enhacement, there is no need to wait for the tinfoil changes so there is no blocker.
Medium+NEWenhancementPatchwork/Patchtestcheck for real sign-off-by names 
11518*
11518 Moving to M4 waiting for an execution issue to be solved (bitbake/tinfoil related).
Medium+NEWenhancementPatchwork/PatchtestUpstream-Status Submitted and Inappropriate check for where/reason info 
11519*
11519

(In reply to comment #1) > (In reply to comment #0) > > According to [1] "Python functions must be four space indented - no tabs." > > > > [1] http://www.openembedded.org/wiki/Styleguide#Format_Guidelines > > There's a Pylint option that catches tab indentation. We are already using > Pylint to test Python code and I think changing a couple parameters will do > the work. Do you think a new check is needed?

understood, then the pylint implementation should be the path to take.
Medium+NEWenhancementPatchwork/Patchtestcheck for four-space indented in python metadata 
11700*
11700

Robert, can you take this. tcl makes me so crazy. :)

The paths in the files are now pointing into the recipe sysroot so all the paths are breaking. Note that there's a patch on the list against this recipe to clean up some of the low hanging fruit I found before deciding I didn't want to learn enough to fix this confidently.
Medium+NEWnormalOE-Coretcl_8.6.6: tclConfig.sh: non-deterministic generation 
11748*
11748

Trying to make a testcase giving a wrong machine to runqemu as follows:

   def test_wrong_machine(self):
       """Test runqemu with wrong machine"""
       cmd = "%s %s" % (self.cmd_common, 'qemuarm')
       with runqemu(self.recipe, ssh=False, launch_cmd=cmd) as qemu:
           self.assertTrue(qemu.runner.logged, "Failed: %s" % cmd)

The build done was a qemux86-64, from selftest, so it was expected that giving qemuarm to runqemu would cause the test to fail. It didn't happen that way, the runqemu util seems to get the qemuarm value but at some point it overwrites it with qemux86-64 and the test passes. Here is the output:

Output from runqemu: runqemu - INFO - Assuming MACHINE = qemuarm runqemu - INFO - Running MACHINE=qemuarm bitbake -e... runqemu - INFO - MACHINE: qemuarm runqemu - INFO - DEPLOY_DIR_IMAGE: /home/humberto/poky/build/tmp/deploy/images/qemux86-64 runqemu - INFO - Running ls -t /home/humberto/poky/build/tmp/deploy/images/qemux86-64/*.qemuboot.conf... runqemu - INFO - CONFFILE: /home/humberto/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.qemuboot.conf runqemu - INFO - Continuing with the following parameters:

runqemu - INFO - Running /usr/sbin/ip link... runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running ldd tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64... runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170703160717.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci -nographic -serial tcp:127.0.0.1:56917 -cpu core2duo -m 256 -serial tcp:127.0.0.1:48241 -kernel tmp/deploy/images/qemux86-64/bzImage--4.10.17+git0+4b89f331d4_6648a34e00-r0-qemux86-64-20170629102456.bin -append 'root=/dev/vda rw highres=off console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 console=tty1 console=ttyS0,115200n8 printk.time=1'


As seen, the qemuarm value is received, but it is soon changed to qemux86-64 when looking for a conf file.
Medium+NEWnormalAutomated Build TestingMachine given to runqemu util is overwritten 
11757*
11757

Partly fixed by https://github.com/intel/intel-iot-refkit/pull/238/commits/01641909eaafc51941cec27ef2d830582a0f886c (for system update).

Let's re-evaluate the impact on the current testing.
Medium+NEWnormalIoT Reference OS Kitselftests: do not touch existing build artifacts 
11783*
11783 Long term I still believe that David Woodhouse's proposal for Fedora makes sense universally, but with s/networkmanager/connman/ for us. That is luckily an implementation detail and already implemented in connman, the non-trivial bit is making the world use libproxy.
Medium+NEWenhancementOE-CoreShould be able to define Target Proxy settings and have them appear in images 
11809*
11809

Looks very much like: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11631

so not necessarily a race, but multiple providers?
Medium+NEWmajorOE-CorePossible race in xcb recipes 
11829*
11829
  • clone poky and prepare environment
  • touch and include the following text into conf/auto.conf

IMAGE_INSTALL_append = "lib64-python3-dev" require conf/multilib.conf MULTILIBS = "multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib64 = "x86-64"

  • create a core-image-minimal image with bitbake
  • boot it with runqemu
  • expected: login prompt should be reached
  • actual:

[ 6.732574] Write protecting the kernel read-only data: 2524k INIT: version 2.88 booting INIT: cannot execute "/bin/sh" INIT: Entering runlevel: 5 INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: cannot execute "/bin/sh" INIT: Id "S1" respawning too fast: disabled for 5 minutes INIT: cannot execute "/bin/sh"

INIT: Id "S0" respawning too fast: disabled for 5 minutes
Medium+NEWnormalOE-Coreimage including multilib:lib64 python3-dev package does not reach login 
11899*
11899 Perhaps we could add a bitbake-selftest for this, too?
Medium+NEWnormalBitBakebroken 'bitbake --status-only' and 'bitbake -m' 
11904*
11904 With the recent rework in master if you change bblayers.conf to have a bad line continuation (e.g. a comment that ends in \ with a blank line after it) then you get back a rather ugly error message with lines that should be separated out crunched together.
Medium+NEWnormalBitBakeBad line continuation in bblayers.conf causes ugly server message 
11906*
11906 Fair enough, but then you should be not be starting with a Fedora srpm. Take a srpm produced from an oe-core recipe via archiver.bbclass and make that work first.
Medium+NEWenhancementOE-Corerpmbuild: Can not build packages on qemu target 
11911*
11911 We've seen this a couple of times on the tumbleweed builder on the new cluster, Michael is going to take a look.
Medium+NEWnormalAutomated Runtime Testingconnection lost between host-target on a nightly-arm-lsb AB build 
11917*
11917

Mostly for the reporter: The commit referenced is relatively old so it may have been fixed already:

commit 9ed748a542b520c1cb763d981969233c0f5efd4e Author: Richard Purdie <richard.purdie@linuxfoundation.org> AuthorDate: Wed Aug 2 06:37:01 2017 +0100 Commit: Richard Purdie <richard.purdie@linuxfoundation.org> CommitDate: Thu Aug 3 11:14:13 2017 +0100

bitbake: daemonize: Always print any remaning UI events at exit
Medium+NEWnormalOE-Core(buildoptions) Failure on test_arch_work_dir and layer_with_out_git_dir 
11923*
11923

(In reply to comment #2) > In the QA report [1], it says that the Eclipse testing was being performed > on Fedora 22 [2], yet your comment above says Debian 8. First of all, it is > important that we are consistent in our information and testing platforms. > Second of all, Fedora-22 has been EOL for a while now and should NOT be used > for QA. > > [1] > https://wiki.yoctoproject.org/wiki/WW32_-_2017-08-09_-_Full_Test_Cycle_2. > 4_M2_rc3 > [2] https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=7844

What happens is when the testrun was created, automatically was selected fedora 22 by default, and must be changed to debian 8 and I forgot to do it, but has been tested on Debian 8
Medium+NEWnormalEclipse Plugin[Eclipse] Failed to debug a Project in Eclipse and displays error: java.lang.NullPointerException 
11943*
11943 Minor correction - instead of "RPROVIDEd by the provider package" I should have said "is in another package's RPROVIDES" so that we repeat the actual variable name verbatim.
Medium+NEWenhancementOE-Coreoe-pkgdata-util should support RPROVIDES 
10368*Medium+RESOLVEDenhancementBitBakeQA Bitbake: create setup and basic unit tests for event module 
10942*Medium+RESOLVEDnormalOE-Corelinux-firmware-ath9k fw ver 1.4.0 in main package 
10999*
10999

Merged the libva change to oe-core:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=73d1c2713725602549fff99434be24fe593d80bb

and into meta-intel here for libva-intel-driver:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=0c2da994195b4db36db80258d09d0e5faed22136

Both now use the github repo directly and when updates occur we will need to update the SRCREV SHAs
Medium+RESOLVEDmajorBSPsmeta-intel: Recipes multimedia:libva need to be updated to point to github upstream projects 
11002*
11002 Merged in oe-core e9471f8da3946439141ccdd8284200aa614df46c.
Medium+RESOLVEDnormalOE-Coredbus: user-session dbus.socket contains path from native sysroot 
11164*Medium+RESOLVEDnormalMeta-yoctoyocto-compat-layer: Add support to isolate the environment 
11180*
11180

We landed DNF within the Yocto 2.3 timeframe as part of our effort to move the userspace to Python3 by default. Unfortunately there wasn't time to complete this effort and the RPM4 & DNF we currently build are using Python2.

We should move all of these components to Python3 in the 2.4 cycle.
Medium+RESOLVEDenhancementOE-CoreSwitch RPM4, dnf and co to Python3 
11181*
11181

Patchset posted for review: http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136138.html

From the cover letter, this is the sitation now:

There are still a few py2 holdouts: - python-numpy (needed by a few recipes in meta-oe, shares code with python3-numpy) - python-nose (dependency of python-numpy) - python-scons (work to port it to py3 is ongoing now) - python-setuptools (dependency of python-scons) - bmap-tools - ltp - perf - asciidoc

And a couple of packagegroups list python 2 as well: - packagegroup-self-hosted - packagegroup-core-lsb

Let's revisit the situation with the above in a year or so.
Medium+RESOLVEDenhancementOE-CoreRemove Python 2 as a host tool or needing to be built for our core images 
11182*
11182

(2) is solved by oe-core 54a2549802a911cad2475a6aa379315a834419d8.

I now think that (1) isn't required, as people won't be accidentally including python3-core in images anymore.
Medium+RESOLVEDenhancementOE-CoreMake it easier to add Python to an image 
11202*
11202

Hi Jair,

I had verified that flatpak bugzilla had been resolved and it included basic tests. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11086

I will close this bugzilla and we will open new bugzilla in the future when QA team develop more tests for flatpak.
Medium+RESOLVEDenhancementIoT Reference OS Kit TestingQA: Validate Flatpak-based 3rd party application support 
11295*
11295 All 3 patches have been merged into master.
Medium+RESOLVEDnormalOE-Coredo_image_wic: fails when rm_work is active 
11305*
11305

This fix is deployed in production:

9b3b3b49188ee7954b653f295a66498d4b8ac88a
Medium+RESOLVEDenhancementPatchwork/Patchtestpatchwork: Improve Series naming when no cover letter is provided 
11313*
11313 Fixed in oe-core 767335c92b7cc657a008722a908380a3c89c3c66.
Medium+RESOLVEDnormalOE-CoreAs a developer, I want to avoid churn of cross,crosssdk,nativesdk,cross-canadian do_populate_sysroot 
11316*
11316

Patchset posted for review (only patches 2 to 5 are relevant):

http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136269.html
Medium+RESOLVEDenhancementOE-CoreTrim down LSB support 
11323*
11323 Does not apply to RMC2. Fingerprints will be directory names and name collisions will not be allowed.
Medium+RESOLVEDmajorBSPsRMC: Handle fingerprints and file blob name collisions in rmc.bbclass 
11327*Medium+RESOLVEDnormalBSPsInstall opption is not not displayed when booting core-image-sato-sdk-intel-core2-32.hddimg 
11355*
11355

Merged in oe-core master in: http://git.openembedded.org/openembedded-core/commit/?id=e06266798d975bd6bebdb6bfdbd3d21be1c44ffd http://git.openembedded.org/openembedded-core/commit/?id=496a9dc179fe9dc370c940f4a2f7bcab869a804f

It is now possible to dump buildstats from the build perf results Git repository and analyze them with the buildstats-diff script.
Medium+RESOLVEDenhancementOE-Coreoe-build-perf-report: support viewing buildstats 
11383*
11383

This was implemented here (and some of the surrounding commits):

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7eb654cb4d82b54e3e4df0a57face61063b72c45
Medium+RESOLVEDenhancementBitBaketinfoil: enable running tasks with dependencies 
11414*Medium+RESOLVEDnormalOE-Coredevtool breaks if an invalid image name is passed to build-image 
11428*
11428

A new buildset, nightly-refkit, has been added (as well as supporting new code and buildsteps). nightly-refkit has two main builds:

1) clones the intel-iot-refkit repository and all submodules then sets up a bblayers.conf which refers to the OE-Core and Bitbake repositories in the main poky checkout with layers from the refkit repository. The buildset then builds whatever the value of REFKIT_CI_BUILD_TARGETS is in meta-refkit/conf/distro/include/refkit-ci.inc as well as running oe-selftests.

2) builds the same REFKIT_CI_BUILD_TARGETS from meta-refkit/conf/distro/include/refkit-ci.inc with the poky distro

http://git.yoctoproject.org/clean/cgit.cgi/yocto-autobuilder/commit/?id=1c4e352100d457d99f7096401e8834bc75d29141
Medium+RESOLVEDenhancementAutoBuilderSupport building intel-iot-refkit with yocto-autobuilder 
11434*Medium+RESOLVEDenhancementOE-Coredevtool edit-recipe/find-recipe enhancements 
11447*Medium+RESOLVEDenhancementBSPsConfigurability to boot from UEFI boot partition or direct boot without bootloader 
11454*Medium+RESOLVEDenhancementAutoBuilderRationalise autobuilder configuration 
11457*Medium+RESOLVEDminorBitBakebb.plain() isn't plain anymore 
11574*
11574 Fixed in oe-core ad915e9baa04c73981c4795a97da95cea40b50c2.
Medium+RESOLVEDnormalOE-CoreERROR: kconfig-frontends-4.10.0.1-r0 do_compile: Function failed: 
11575*
11575

Patch merged into OE-Core and backports for older releases:-

OE-Core rev: dc8b21ae0ed3bceb9f3df4f6cd8f8f55b9c306fb

Poky master rev: cd1addaaf4f4681465de6b0ca705e01a5058e3ba

Poky pyro rev: 31389f8b0088a8a83aa5e50f11359b39934e4640

Poky morty rev: e92165f5cea1c345672dd866df6a44d1cd8b97ce

Poky krogoth rev: 80b35ed1a282a4f3f5d723febfd70481a48182c2
Medium+RESOLVEDnormalOE-CoreERROR: cryptodev-tests-1.8-r0 do_checkuri: Fetcher failure for URL: 'http://download.gna.org/cryptodev-linux/cryptodev-linux-1.8.tar.gz' 
11608*
11608 Ubuntu17.04 has been added on GDC/AB as supported distro
Medium+RESOLVEDnormalAutomated Build Testingdistro-testing: Add ubuntu 17.04 to supported distros 
11610*
11610

(In reply to comment #4) > I'm fairly confident this will fix the original issue as well. > > > commit 01266607aa4d3d4905d2c07b4bdf46ea9f5372f0 > Author: Jussi Kukkonen <jussi.kukkonen@intel.com> > Date: Thu Jun 22 12:52:06 2017 +0300 > > gdk-pixbuf: Make loader.cache reproducible > > Make the loader order in the file reliable to enable more reproducible > builds. > > [YOCTO #11610] > > (From OE-Core rev: 6c97a3291988cec0ac018338cd96aa2e734ca5c4)


Thanks Jussi,

I built two separate images with the patch and they ended up being binary identical.
Medium+RESOLVEDenhancementOE-Coregdk-pixbuf: improve reproducibility 
11627*
11627 I am closing this as RESOLVED/FIXED as the main objective (booting 4.10 kernel on MAX10m50C board) has been accomplished.
Medium+RESOLVEDenhancementOE-Coreupdate max10 reference board to boot with 4.10 kernel 
11628*Medium+RESOLVEDenhancementOE-Coreimplement uboot for nios2 softcore on max10 reference board 
11635*
11635 So is this due to build machine lacking swap as discussed in 11608? I guess I can close this as NOTABUG.
Medium+RESOLVEDnormalOE-Core32bit x86 webkitgtk builds fail on Ubuntu 17.04 
11636*
11636 Closing as not a bug: the test machine had less swap than the current autobuilder instances and run out of memory. Both piglit and especially webkit have very high peak memory usage: 32 GB may not be enough for a world build if large values of PARALLEL_MAKE are used.
Medium+RESOLVEDnormalOE-Core32bit x86 piglit builds fail on Ubuntu 17.04 host 
11679*
11679 This is fixed by oe-core/5490efb7446196dce6a4be678263e8a73648446a
Medium+RESOLVEDmajorOE-Core"cannot make copy relocation for protected symbol" build errors with musl and ld-is-gold 
11682*
11682 This case is covered by other bug.
Medium+RESOLVEDnormalAutomated Build Testingoe-selftest does not clean-up properly the build/conf metadata 
11709*
11709 both patchsets have been merged to poky master.
Medium+RESOLVEDmajorOE-CoreSupport EFI System partition with 4K FAT clusters 
11710*
11710

Fix merged to master (requires a number of the patches around it, too many to list here):

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e4346e8be5f451d5cfe0b68a272abd15b0951831
Medium+RESOLVEDnormalOE-CoreFetching from recipetool no longer works with memres 
11713*Medium+RESOLVEDnormalAutomated Runtime Testingtestimage for core-image-sato-sdk fails on musl due to iptables compile failures 
11714*
11714

Please re-test this with latest meta-intel (will be part of M2 meta-intel BSP)

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=1811a41d6f891784b2a5b65d60626add51f3d13e

Along with additional patches enable the out of Tree iwlwifi driver, which should resolve this.

It it does not, please re-open this issue
Medium+RESOLVEDnormalBSPsIntel AC 7260 Bluetooth interface stops responding after disabling Bluetooth 
11717*
11717 commit eea5cb317137d71ad0cab954d2c9ad2069580b6f
Medium+RESOLVEDnormalToasterlarge package set causes 'too many SQL variables' error 
11741*
11741 Merged in oe-core b10ecbab3acd46e48d36910e30544e9f5f08d6d7.
Medium+RESOLVEDnormalOE-Coresdk: generates empty manifests when doing do_populate_sdk 
11760*
11760 the fix has been merged to poky master. commit id: b15df41d7d6074e76fea8d1c4f1d12273b46f1a3
Medium+RESOLVEDnormalOE-Coresquashfs_xz and squashfs_lzo image compression failed[4]
11788*Medium+RESOLVEDenhancementAutoBuilderDrop package publishing 
11823*
11823 Closing as a duplicate of 11745.
Medium+RESOLVEDnormalIoT Reference OS KitAB: test intel-iot-refkit with the right submodules 
11836*
11836 The logs are gone for this build and the code area has also been reworked with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5f835043f24cef29d229918a9e9cdef62407e558 and preceding patches. We can reopen this if we have any reasonable way to debug this further (or open a new bug for the new issue).
Medium+RESOLVEDnormalOE-Core[master] nightly-no-x11 barfed 
11846*
11846 nightly-checkuri is no longer triggered by nightly and has its own weekly trigger on the yocto.io AB cluster.
Medium+RESOLVEDnormalAutoBuilderMove nightly-checkuri out of nightly and automatically trigger for master and maintained branches on a weekly basis 
11847*
11847

merged at master:

e40eeaa790: Leonardo Sandoval: Fri Aug 11 00:08:31 2017 +0100: context: Include a command line argument to run all except certain tests
Medium+RESOLVEDenhancementAutomated Build TestingAdd an option to oe-selftest to run all tests except for [...] 
11850*
11850 Plugins now published for M2 rc3
Medium+RESOLVEDnormalAutoBuilder[Autobuilder] Eclipse-plugin files are not found in autobuilder 
11851*
11851

The basic root cause is resolved with 11851. The previous comment about deleting clones turns out to solve the problem by the simple time delay, not any mismatched content.

I did get this issue intermittently with non-Toaster usage, which makes it a bb problem. I believe that has or is being addresses with other bitbake-devel patches.
Medium+RESOLVEDnormalToasterToaster broken with bitbake move to default XMLRPC 
11869*
11869

(In reply to comment #15) > Autobuilder was reconfigured and the tests were redeemed again and the fault > disappeared, it was a poor autobuilder configuration. > ========================================================================= > RESULTS - runqemu.RunqemuTests.test_boot_deploy - Testcase 2007: PASSED > 2017-08-03 19:03:42,634 - oe-selftest - INFO - RESULTS - > runqemu.RunqemuTests.test_boot_deploy_hddimg - Testcase 2008: PASSED > 2017-08-03 19:03:42,634 - oe-selftest - INFO - RESULTS - > runqemu.RunqemuTests.test_boot_machine - Testcase 2001: PASSED > 2017-08-03 19:03:42,634 - oe-selftest - INFO - RESULTS - > runqemu.RunqemuTests.test_boot_machine_ext4 - Testcase 2002: PASSED > 2017-08-03 19:03:42,635 - oe-selftest - INFO - RESULTS - > runqemu.RunqemuTests.test_boot_machine_iso - Testcase 2003: PASSED > 2017-08-03 19:03:42,635 - oe-selftest - INFO - RESULTS - > runqemu.RunqemuTests.test_boot_machine_slirp - Testcase 2009: PASSED > ====================================================================== > .log in attachments

OK, thanks. Setting bug status to Resolved/Invalid then.
Medium+RESOLVEDnormalOE-CoreFAILED runqemu.RunqemuTests.test_boot_deploy - Testcase 2007: Ubuntu1604 
11896*
11896 That seems reasonable, yes.
Medium+RESOLVEDnormalOE-Corecheckpkg needs to have exemption in metadata 
11935*
11935 Yep.
Medium+RESOLVEDnormalBSPsConnman fails to scan wifi ap on automatic refresh due to firmware loading errors 
11939*Medium+RESOLVEDnormalOE-Coreopenssl-1.1.0f-r0 QA Errors 
11940*Medium+RESOLVEDnormalOE-Corebind-9.10.5 QA errors 
11941*Medium+RESOLVEDnormalOE-Coreltp-20170516-r0 QA errors 
11609*
11609 All seems to be working
Medium+VERIFIEDenhancementAutoBuilderAdd an Ubuntu 17.04 builder to the YP AB cluster 
11687*
11687

Verified with 2.4 M2 rc2.

Git rev: master/8e15e9b6e478f6368034519b2a8fd3c7ea71d23b
Medium+VERIFIEDnormalGeneral RuntimeCan not run QEMU machines under UNFS 
11947*
11947 if user.email & user.name are not set, some of the git commands that devtool upgrade runs result in erroneous behaviour. we should probably check these settings when running an upgrade. I'm not sure if any of the other devtool features need this to be set as well.
UndecidedNEWnormalOE-Coredevtool upgrade needs to have some git configs set to get correct results 
11948*
11948

In a complex upgrade like qemu 2.8.1.1 -> 2.10.o-rc2, this can take ~ 10 minutes. Right now, there is no user feedback that progress is being made unless devtool is run with -d. Instead, it looks like devtool upgrade has hung.

We should probably do a progress bar regardless since even if we speed it up a huge (webkit?) upgrade may still be slow. We may also want to look at other ways to do this like using the python git library instead of system calls, or doing some batching of our own, ... The "culprit" is in scripts/lib/devtool/upgrade.py:

       (stdout,_) = __run('git ls-files --modified --others --exclude-standard')   
       for f in stdout.splitlines():                                                                                                
__run('git add "%s"' % f)
UndecidedNEWnormalOE-Coredevtool upgrade walks the file tree and execs a git add for each file 
11949*
11949 BTW, observed with refkit
UndecidedNEWmajorOE-Coreqemu-2.10-rc2 build error (patch failed) 
11950*
11950

As seen in Autobuilder: https://autobuilder.yocto.io/builders/nightly-refkit/builds/122/steps/BuildImages/logs/stdio

relevant errors:

| x86_64-linux-libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -isystem/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX -isystem/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include -O2 -pipe -Wall -Werror -Wreturn-type -Wsign-compare -c tpm12/tpm_delegate.c -fPIC -DPIC -o tpm12/.libs/libtpms_tpm12_la-tpm_delegate.o | tpm12/tpm_crypto.c: In function ‘TPM_RSAGenerateKeyPair’: | tpm12/tpm_crypto.c:362:9: error: ‘RSA_generate_key’ is deprecated [-Werror=deprecated-declarations] | rsa = RSA_generate_key(num_bits, e, NULL, NULL); /* freed @1 */ | ^~~ | In file included from /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include/openssl/asn1.h:15:0, | from /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include/openssl/rsa.h:16, | from /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include/openssl/engine.h:24, | from tpm12/tpm_crypto.c:50: | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/libtpm-native/1.0+gitAUTOINC+ad44846dda-r0/recipe-sysroot-native/usr/include/openssl/rsa.h:193:1: note: declared here | DEPRECATEDIN_0_9_8(RSA *RSA_generate_key(int bits, unsigned long e, void | ^ | tpm12/tpm_crypto.c:370:58: error: dereferencing pointer to incomplete type ‘RSA {aka struct rsa_st}’ | rc = TPM_bn2binMalloc(n, &nbytes, (TPM_BIGNUM)rsa->n, num_bits/8); /* freed by caller */

|
UndecidedNEWnormalOE-Core(refkit) Error compiling libtpm-native-1.0 
11951*
11951

A seen in Autobuilder: https://autobuilder.yocto.io/builders/nightly-refkit/builds/122/steps/BuildImages/logs/stdio

Relevant part:

ERROR: tpm-tools-native-1.3.9.1+gitAUTOINC+5c5126bedf-r0 do_compile: oe_runmake failed ERROR: tpm-tools-native-1.3.9.1+gitAUTOINC+5c5126bedf-r0 do_compile: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/tpm-tools-native/1.3.9.1+gitAUTOINC+5c5126bedf-r0/temp/log.do_compile.946) ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/build/tmp-glibc/work/x86_64-linux/tpm-tools-native/1.3.9.1+gitAUTOINC+5c5126bedf-r0/temp/log.do_compile.946 Log data follows: ...

tpm_extendpcr.c: In function ‘main’: | tpm_extendpcr.c:139:14: error: storage size of ‘ctx’ isn’t known | EVP_MD_CTX ctx; | ^~~ | tpm_extendpcr.c:139:14: warning: unused variable ‘ctx’ [-Wunused-variable]

| make[3]: *** [Makefile:472: tpm_extendpcr.o] Error 1
UndecidedNEWnormalOE-Core(refkit) tpm-tools-native-1.3.9.1 compile error 
11952*
11952

As seen in Autobuilder: https://autobuilder.yocto.io/builders/nightly-ppc-lsb/builds/421/steps/Running%20Sanity%20Tests/logs/stdio

ERROR: core-image-lsb-1.0-r0 do_testimage: Didn't receive a console connection from qemu. Here is the qemu command line used: tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-ppc-devicevirtio-net-pci,netdev=net0,mac=52:54:00:12:34:04-netdevtap,id=net0,ifname=tap1,script=no,downscript=no-drivefile=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/deploy/images/qemuppc/core-image-lsb-qemuppc.ext4,if=virtio,format=raw-show-cursor-usb-usbdevicetablet-devicevirtio-rng-pci-serialtcp:127.0.0.1:46580-machinemac99-cpuG4-m256-serialtcp:127.0.0.1:47257-snapshot-kerneltmp/deploy/images/qemuppc/vmlinux--4.1.42+git0+9f9c9a66ef_1e29490acc-r0.2-qemuppc-20170817003236.bin-appendroot=/dev/vda rw highres=off mem=256M ip=192.168.7.4::192.168.7.3:255.255.255.0 console=tty console=ttyS0 console=tty1 console=ttyS0,115200n8 printk.time=1 and output from runqemu: runqemu - INFO - Continuing with the following parameters:

runqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable


I believe "[Errno 11] Resource temporarily unavailable" should be handled by re-trying, instead of erroring out immediately
UndecidedNEWnormalOE-Corerunqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable 
11953*
11953

As seen in Autobuilder:

https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/458/steps/Running%20oe-selftest/logs/stdio

Relevant part: 2017-08-18 16:32:03,936 - oe-selftest - INFO - FAIL: test_stoptask_behavior (buildoptions.DiskMonTest) 2017-08-18 16:32:03,936 - oe-selftest - INFO - ---------------------------------------------------------------------- 2017-08-18 16:32:03,936 - oe-selftest - INFO - Traceback (most recent call last):

 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/cases/buildoptions.py", line 69, in test_stoptask_behavior
   self.assertTrue('WARNING: The free space' in res.output, msg = "A warning should have been displayed for disk monitor is set to WARN: %s" %res.output)

AssertionError: False is not true : A warning should have been displayed for disk monitor is set to WARN: NOTE: Starting bitbake server...

Parsing recipes...done.
UndecidedNEWnormalOE-Corenightly-oe-selftest failed: FAIL: test_stoptask_behavior (buildoptions.DiskMonTest) 
11010*
11010

Great - setting to RESOLVED and marking the doc flag to "done."

Thanks!
UndecidedRESOLVEDnormalReferencedocumentation for NO_RECOMMENDATIONS is incorrect 
11489*
11489 duplicate of Bug 11460
UndecidedRESOLVEDnormalOE-Corepostinst-useradd uses the abs path of pseudo which is encoded in sstate 
11514*
11514

I couldn't reproduce the issue in same system, same configuration the very next day.

I'm closing this bug as invalid now.
UndecidedRESOLVEDnormalOE-Corem4_native: do_configure failure on Centos-7 
11573*
11573

Bug in a patch, now dropped from mut.

Marking as OBSOLETE so that QA don't want to verify.
UndecidedRESOLVEDnormalOE-CoreERROR: lzop-1.03-r0 do_package_write_ipk 
11576*
11576 The elfutils patch was merged to meta-gpl2 master today.
UndecidedRESOLVEDnormalOE-CoreERROR: elfutils-0.148-r11 do_compile: oe_runmake failed 
11577*
11577 Oops, filed the same bug twice.
UndecidedRESOLVEDnormalOE-CoreERROR: elfutils-0.148-r11 do_compile: oe_runmake failed 
11617*
11617 The patches have been removed from MUT.
UndecidedRESOLVEDnormalOE-Core[wic] test_wic_rm failed 
11619*
11619

$ git clone git://anonscm.debian.org/collab-maint/ca-certificates.git Cloning into 'ca-certificates'... remote: Counting objects: 1678, done. remote: Compressing objects: 100% (994/994), done. remote: Total 1678 (delta 1178), reused 925 (delta 664) Receiving objects: 100% (1678/1678), 915.56 KiB | 465.00 KiB/s, done. Resolving deltas: 100% (1178/1178), done.

Transient failure on the cluster.
UndecidedRESOLVEDnormalOther YP Layersca-certificates build fails due to invalud URL 
11624*
11624 MUT-only, patch has been dropped and the submitter told.
UndecidedRESOLVEDnormalOE-Corecore-image-sato fails dnf testimage run 
11625*
11625 Transient failure.
UndecidedRESOLVEDnormalOther YP Layersdropbear fails checkuri 
11626*
11626 This was user error and the subsquent build was ok, sorry for the noise.
UndecidedRESOLVEDnormalBitBakeFailed to get distroversion. DISTRO_VERSION="2.1.3" is not the same as specified Yocto Project release number 
11641*
11641 Already yanked from MUT.
UndecidedRESOLVEDnormalOE-Coretest_integrity_compressed_images oe-selftest failed 
11678*
11678 This seems to be a duplicate. Please, have a look at the bug 11525 and add your requirements there. Thanks.
UndecidedRESOLVEDnormalOE-CoreFeature Request: /etc/fstab to use PARTUUID for EFI wic images 
11751*
11751 Thanks Leo, this is really good analysis. Looks like build times went up due to the change however we did see much better package and eSDK sizes as a result. We can therefore call this a reasonable compromise and decide to accept the small performance hit.
UndecidedRESOLVEDnormalAutomated Build TestingPerformance regressions detected on core-image-sato and virtual/kernel at 2.4M1 rc1 
11761*
11761 If less quits, bitbake loses its stdout. Its reasonable it prints a pipe error at this point which is what a standard commandline utility would do. The alternative is to silently swallow an error when stdout has disappeared and we still have output which seems worse to me so I don't think we can improve this as described.
UndecidedRESOLVEDminorBitBakeBroken pipe when paginating bitbake -e 
11774*
11774 Thanks! Marking RESOLVED + doc change "Done"
UndecidedRESOLVEDnormalDevelopment Manualbmaptool instructions for copies that require sudo rights is incorrect in the RSS world 
11803*UndecidedRESOLVEDnormalOE-Corerunqemu: use absolute path for nfs 
11835*
11835 Likely a transient network issue, clicking on the url works here.
UndecidedRESOLVEDnormalOE-Corenightly-checkuri debianutils failed 
11852*
11852 expat 2.2.2 has been withdrawn.
UndecidedRESOLVEDnormalOE-Core[mater-next] expat_2.2.2 causing multiple builds to fails[5]
11853*
11853 gperf 3.1 breakage again, backed out of next.
UndecidedRESOLVEDnormalOE-Core[master-next] libid3tag in nightly-no-x11[: https://autobuilder.yocto.io/builders/nightly-no-x11/builds/374/steps/Running Sanity Tests/logs/stdio]
11854*
11854 I'll reopen 11785 as the issue is not fully fixed. It's fixed in the patchelf code, but uninative tarball still has to be published.
UndecidedRESOLVEDnormalOE-CoreFailed to build autoconf-native on Debian 9 i686 
11855*
11855 Fixed with the new uninative as of oe-core a2ab288bd002ebb6e64d46e941fb122e1157ff49.
UndecidedRESOLVEDnormalOE-CoreFailed to build libgcc-initial on Fedora26 i686 
11857*UndecidedRESOLVEDnormalOE-CoreFAIL [23.106s]: test_mkfs_extraopts (wic.Wic) centos7 
11858*
11858

Looks like an autobuilder configuration error to me:

| runqemu - ERROR - Error: There are no available tap devices to use for networking, | runqemu - ERROR - and I see /etc/runqemu-nosudo exists, so I am not going to try creating | runqemu - ERROR - a new one with sudo.

Also, the reported bug (test_checkpkg) passes in these logs?
UndecidedRESOLVEDnormalOE-CoreDistrodata.test_checkpkg - Testcase -1: FAILED centos7 
11859*
11859

This is another autobuilder setup issue. To quote from the logs:

| runqemu - ERROR - Error: There are no available tap devices to use for networking, | runqemu - ERROR - and I see /etc/runqemu-nosudo exists, so I am not going to try creating

| runqemu - ERROR - a new one with sudo.
UndecidedRESOLVEDnormalOE-Core[Test Case 1883] TestImage.test_testimage_dnf Centos7 
11860*
11860 Patch dropped, v2 sent.
UndecidedRESOLVEDnormalOE-Core[Master-next] nightly-musl 2.4_M1[6]
11861UndecidedRESOLVEDnormalOE-Corefail [Test Case 1644] test_testimage_install centos7 
11910*
11910 This was due to the max number of processes being set to 1200 on the opensuse423 autobuilder worker. We've increased that number (as seen in ulimit) which should resolve this and stop the fork() call failing.
UndecidedRESOLVEDnormalAutomated Build Testingbuild-appliance failing due to lack of resources 
11863*
11863 duplicated
UndecidedVERIFIEDnormalOE-Coredistrodata.Distrodata.test_checkpkg - Testcase -1: Debian8 
11864*
11864 duplicated
UndecidedVERIFIEDnormalOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1 Debian8 
11865*
11865 duplicated
UndecidedVERIFIEDnormalOE-Coredistrodata.Distrodata.test_checkpkg - Testcase -1: fedora24 
11866*
11866 duplicated
UndecidedVERIFIEDnormalOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1: fedora24 
11867*
11867 duplicated
UndecidedVERIFIEDnormalOE-Coredistrodata.Distrodata.test_checkpkg - Testcase -1:opensuse422 
Personal tools