From Yocto Project
Jump to: navigation, search

Testing watchlists again and again and again and again and again

IDPStatusSeverityProductSummary (547 tasks)  
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 
11452*HighRESOLVEDenhancementLayer IndexAdd a YP Compatible (V2) flag/column for layers on 
11467*HighRESOLVEDenhancementIoT Reference OS Kitintegrate a system update solution 
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 

This is a workaround to avoid filesystem corruption

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 
11898*HighRESOLVEDmajorBitBakebitbake server timeout on first 'server.runCommand' call after build starts 
11903*HighRESOLVEDnormalBitBakeServer log needs separation between instances 
11913*HighRESOLVEDnormalAutomated Runtime Testingmusl image launch with runqemu did not reach the login banner 

There was a need to include file chunks, so the second patch fixing this issue
HighRESOLVEDnormalAutomated Runtime Testinggpg: signing failed due to lack of memory on nightly-oe-selftest 
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 

Fixed by:

commit 0db0e1851c8c23cbfbccb9553391fb8da08bf645 Author: Peter Kjellerstedt <> Date: Tue Aug 15 16:41:54 2017 -0500

   texinfo: Avoid a problem with a dependency on perl(Locale::gettext_xs)
   We do not build the Locale::gettext_xs Perl module and the code will
   test for it and happily use Locale::gettext_pp instead if it is not
   found. However, this still causes a file dependency on
   perl(Locale::gettext_xs) to be generated, which must be satisfied by
   adding an explicit provide for it.
(From OE-Core rev: c1e16ac6aea0ec15b35d227814bbf137ac8de6c2)
HighRESOLVEDnormalBitBakehosttools" dpkg-deb -b fails 
12036 commit bdb1f7571ed539b89ce42268a81ab76d27133dd9
HighRESOLVEDnormalToaster'ToasterSetting' import missing from lsupdates 
12037 commit 2e8256d0c75aaf66f88ccc18084187ab16aec17e
HighRESOLVEDnormalToasterNeed to update Toaster to new YP-2.4 release name and bb version 


Thanks for tagging it. I could have done that but was unsure of whether or not to do it. Thanks for the instruction on Git as well to keep both branches in sync for the time being.

HighRESOLVEDnormalGeneral Docsadd rocko branch to yocto-docs 
12113*HighRESOLVEDnormalAutomated Runtime TestingLast 25 lines of log isn't displayed 

One more comment.

I changed the threshold in the attached script to capture all events longer than 3 seconds as opposed to 5 seconds. If you do that you see the follow entries.

Server high latency events: Event# Loop Latency Event 155 2 4 <bb.event.RecipeParsed object at 0x7f5ea2265d68> 155 3 5 <bb.event.RecipeParsed object at 0x7f5ea2265d68>

The delays occur early in the Recipe Parsing phase, and is quite visible in the knotty's shell progress bar. This is consistent with the failures being observed early in the build (before the patch was applied).

Each server call is done 5 times in a fast loop, and the above "Loop" value is the iteration. The loop number appear random in my several runs (as opposed to always being the first call), telling me that it is one of the background parsing tasks that the server call happens to overlap with.
HighRESOLVEDnormalBitBakebitbake server timeout - race condition on fast machines 
12143HighRESOLVEDnormalAutomated Build TestingPtest-runner does not run python, in 2.4rc1 
12144 Closing this as RESOLVED/FIXED, but individual test that fail need to be filed as separate bugs.
HighRESOLVEDnormalAutomated Build Testingptest-busybox cases failed in 2.4rc1 

This fixes one test:

The patch above will improve statistics, but there are several additional tests that fail, individual bugs need to be filed for each one.
HighRESOLVEDmajorAutomated Build Testingptest-bash cases failed in 2.4rc1 
12146*HighRESOLVEDnormalAutomated Build Testingptest-e2fsprog cases failed in 2.4rc1 

commit 3eb62b0d700a05c923c5cd96f0c3377202c1e0da

(Bitbake rev: fa767d85f19a7af92a44fe11fdfb38633009ad71)
HighRESOLVEDnormalToasterToaster server lost "toaster.conf" environment, user settings lost 
12346*HighRESOLVEDmajorBSPsmeta-intel: ISO installer silently fails to install if booted in legacy mode 
12373*HighRESOLVEDnormalOE-CoreFeature Backfilling doesn't work for multilib 
11424 The requirement for tinification/ smaller kernel size has waned, if we need to bring this back alive later we can.
LowACCEPTEDenhancementMeta-yoctopoky-tiny + Link Time Optimization 

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.
LowACCEPTEDnormalOE-Corelibcrypto: improve binary reproducibility 
12142 I found the same in the search box from Recipes
LowACCEPTEDnormalToasterThe color from the table from the project build changed when you use an special character. 
11142 Moving to 2.5 and reassign this bug to Jair as he will be working on oeqa enhancements
LowNEWenhancementAutomated Build TestingUse artificial recipes for oe-selftest where possible to reduce work 
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 

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 

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-mingw-w64-runtime/3.1.0-r0/build' | i686-pokysdk-mingw32-gcc -E --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-mingw-w64-runtime/3.1.0-r0/recipe-sysroot -x c ../mingw-w64-v3.1.0/mingw-w64-crt/lib32/ -Wp,-w -I../mingw-w64-v3.1.0/mingw-w64-crt/def-include | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/build/tmp/hosttools/sed 's/^#/;/' >lib32/msvcrt.def

| /bin/bash: lib32/msvcrt.def: No such file or directory
LowNEWnormalOther YP Layers[mingw32] nativesdk-mingw-w64-runtime fails to compile 
12154 I'm aware of this issue, the tricky thing is that some recipes apply patches only for the native case or only for the target case, so it's hard to share a single source tree for those. We could of course only block (or show a warning for) recipes that do such things, but fixing this is not high on our current priority list.
LowNEWnormaleSDKesdk/devtool cannot build both native and target components 
12169 IoTG is excited about this. They currently scp files off their booted image, but this would be a great help to them sometime in the future. No rush though.
LowNEWenhancementOE-Corewic cp allows me to cp a file into a wic partition, it should let me cp one out as well. 

I managed to completely take down my entire linux system (not just a terminal) while doing some combination of the wic (cp,ls,rm) actions.

Tried and failed to replicate it, even when running the above in a script loop.

after the crash, it said: bash: /big/src/myBugs/poky/scripts/wic: /usr/bin/env: bad interpreter: Input/output error

Mostly here in case i, or others, experience this in the future.
LowNEWnormalOE-Coreunreproduceable total system crash while doing wic cp,wic rm, wic ls 


When importing layers the confirmation label always says that it imported 2 layers, the layer you really want and the openembedded-core which is already by default in the project.

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: Debian 4.3.0-0.bpo.1-amd64 STEPS TO REPRODUCE:

1. Start Toaster 2. Create a project for roko 3. Go to the Import Layer tab 4. Fill in the information for a layer with a git repository source. 5. Check that in the layer dependencies by default it shows openembedded-core

EXPECTED OUTCOME: the confirmation label should read layer-name added 1 layer but instead it reads 2 layers added to the project and it lists the openembedded-core
LowNEWnormalToaster[Toaster] Importing layers, confirmation label is misleading 

I needed a solution for OSTree, so I wrote one. See

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 The PR got merged to master.
LowRESOLVEDenhancementIoT Reference OS KitRefKit: Python version alignment 
11475*LowRESOLVEDenhancementIoT Reference OS KitRock-paper-scissors demo based on RefKit computer vision profile 
11480*LowRESOLVEDenhancementIoT Reference OS KitIntegrate YOLO to Refkit 
11916*LowRESOLVEDenhancementOE-Coree2fsprogs-doc: improve reproducible build 
11918*LowRESOLVEDnormalOE-Corebash: improve reproducibility 
11922*LowRESOLVEDnormalOE-Corelibgmp: improve binary reproducibility 
10050 Much of the oeqa code has been rewritten since this issue was filed, need to test whether the issue is still present.
MediumACCEPTEDenhancementAutomated Runtime Testingoeqa runner generate wrong test results in log file when running dynamic test cases 
11346 This will not be Open Sourced until SDL and IP Plan have been completed. Currently working with OTC SDL team for higher level YP which will feed into this.
MediumACCEPTEDenhancementDemosCreate demo that shows Amazon Alexa voice activated personal assistant in action 
11663 Inherited from Anibal.
MediumACCEPTEDnormalOE-CoreBuild QA RPATH warning in perl-native build ( 

The change is not trivial, as the current OEQA framework extends the upstream unittest library which uses recursion to discover the test cases, and sorts them on alphabetical order by default. It is possible to change the default unittest behavior and re-order the test cases afterwards on the way specified on the command line, but some other aspects need to be considered. For example, the framework and the oe-selftest tool allow to specify modules, classes or test cases, or any combination of them. Also, with the inclusion of dependency decorators, the order of test cases is re-arranged according to their dependencies. Finally, the framework also allows the possibility to specify a module manifest file to list the tests to execute, so it may be necessary to re-order the tests in a similar way as specified in the file if that option is used, to have a consistent behavior. Considering we will be changing the default unittest behavior, it also may be convenient to have a new option in the tool to allow to specify the required order.

According to this, and this item's priority, I'll modify its target milestone to 2.5 M1.
MediumACCEPTEDnormalAutomated Build Testingoe-selftest: --run-tests ignores test order 

Preliminary notes: Managed to reproduce all listed problems.

For qemux86/x264 upgrading the recipe for the latest stable version did not fix the problem.;a=shortlog;h=refs/heads/stable
MediumACCEPTEDnormalOE-Coretexrels found for x264/libproxy/python3-pycairo for poky-lsb 

This module is also getting some other error with NUC and LSB image (2.4 M4 rc1 meta-intel) by using the configuration below.

core-image-lsb-sdk intel-corei7-64

Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO = "poky-lsb" DISTRO_VERSION = "2.4" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "HEAD:65d23bd7986615fdfb0f1717b615534a2a14ab80" meta-intel = "master:863590f9bc7104fef698ce6b89ec24dfce542df1"

167 NOTE: test_parselogs (parselogs.ParseLogsTest) 168 NOTE: ... FAIL


195 NOTE: ====================================================================== 196 NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) 197 NOTE: ---------------------------------------------------------------------- 198 NOTE: Traceback (most recent call last): 199 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/core/decorator/", ine 32, in wrapped_f 200 return func(*args, **kwargs) 201 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/core/decorator/", ine 32, in wrapped_f 202 return func(*args, or fails should be present in logs**kwargs) 203 File "/home/jzepeda/2.4rc3/poky/meta/lib/oeqa/runtime/cases/", ine 363, in test_parselogs 204 self.assertEqual(errcount, 0, msg=self.msg) 205 AssertionError: 262 != 0 : Log: /home/jzepeda/2.4rc3/poky/automated/tmp/work/intel_corei7_64-poky-linux/core-image-lsb-sdk/1.0-r0/access.log

ERROR: core-image-lsb-sdk-1.0-r0 do_testimage: core-image-lsb-sdk - FAILED - check the task log and the ssh log ERROR: core-image-lsb-sdk-1.0-r0 do_testimage: Function failed: do_testimage ERROR: Logfile of failure stored in: /home/jzepeda/2.4rc3/poky/automated/tmp/work/intel_corei7_64-poky-linux/core-image-lsb-sdk/1.0-r0/temp/log.do_testimage.29482 ERROR: Task (/home/jzepeda/2.4rc3/poky/meta/recipes-extended/images/ failed with exit code '1'

6954 *********************** 6955 262 errors found in logs.

(The access log contains some public IPs from intel that Im not allowed to attach)

EXPECTED OUTCOME: Errors must not be gotten.

Actual status: FAILED
MediumACCEPTEDnormalBSPs[Testcase 1059] Parselogs is failing corei7-64-lsb on Cherry Hill giving error: *ERROR* timed out waiting for Punit DDR DVFS request 

I cannot yet replicate the error, even with the broken layer received from Libby.

Possible Workaround: I will mention that I have observed in the past that if you build a target (like a file system) that produces certain artifacts, and then re-build with a differed target (like for eSDKs), the last build does not present a cumulative list of valid artifacts, and that you usually have to go back to the previous build to get those respective target links. That may be related here, where even though the last target failed you can still go back to previous build to get those working artifact links.

I am moving this to YP-2.5 since we are at the end of M4, but I will see about pulling this into 2.4.1.
MediumACCEPTEDnormalToasterCant download other artifacts when modifying built recipe 

My first guess was that the search values were hidden in one of the un-displayed columns, but with my testing that does not appear to be the case.

I will need to see what the filter is actually finding as matches, and it may be either errors in the filter process or fields that are there but never displayed.
MediumACCEPTEDnormalToasterThe search results for numbers are incorrect. 
12138 changed importance to undecided so it can be retriaged.
MediumACCEPTEDnormalOE-Core[master] the icon on the connection manager appears without connection in Eclipse Plugin 

STATUS: FAILED BUILD: 2.4 M4: rc1-592c3449697ce39bf07864fafd7f0a61ca230561 ENVIRONMENT: Fedora 26 STEPS TO REPRODUCE: 1. Access a project page, either by creating a new project or accessing an existing project from the "All builds" table. 2. Navigate to the "Image Recipes" page. 3. Search something that you know that is not on the list. 4. click on the x or the lynk show all and youll get a msg: toaster has no recipe information. To generate recipe information you need to run a build.

EXPECTED OUTCOME: You have to see the list complete again.
MediumACCEPTEDnormalToasterThe link and the x button from the search's result did not work as expected 

Turns out that wic ls has an optional argument to pass in the native sysroot containing mtools-native

wic ls -n (pwd)/tmp/sysroots-components/x86_64/mtools-native /tmp/core-image-base-qemux86-64.wic:1


The above works fine without the ~/.mtoolsrc file.
MediumACCEPTEDnormalOE-Corewic ls myimage.wic:1 fails on ubuntu 16.04 using host mtools 
12207 After you hit "new project" if you no longer want to create one, we have no cancel button. Forcing users to use the browser back button feels quite awkward.
MediumACCEPTEDenhancementToasterNew Project needs a cancel button in case you change your mind. 
12208 The "add layer" button for Layer dependencies (optional) is active immediately after going to the Import Layer page, even though nothing has been typed in. Hitting the "add layer" button for Layer dependencies (optional) button results in multiple copies of openembedded-core being added...
MediumACCEPTEDnormalToasteron the import layer page, the "add layer" button for dependent layers is active, when empty 

So because there is now locale fr_FR present, the locale gets tested and the test fails. The locale was not present before, so this is a new test.

It is not quite clear why the test fails, the testing is done by the program "pcretest". Looking at the source code (pcretest.c) I see this will not be a walk in the park, as the this is basically just one giant spaghetti code. (the "test routine" is 2783 lines long!)
MediumACCEPTEDnormalAutomated Build Testingptest-runner libpcre one failed 

Just some notes: the failing test is part of bash-ptest suite. This is not a new bug/regression. There are (and have been) several tests failing, but instead of a bulk

"bash-ptest fails" we now file individual individual bug reports for tests that fail.
MediumACCEPTEDnormalAutomated Build Testingptest-runner FAIL: run-lastpipe, 2.4_M4_rc2 

Ptest-runner tests were executed and observing this run-new-exp failures on the results.

POKY : 2.4_M4_r2 COMMIT:da05a01423a60a23cd1073eb0ad3776e5bf4f2a8 HW: NUC 6i5SYH IMAGES:

Results Chart table:

EXPECTED OUTCOME: The pass rate goes up the percentage

ACTUAL OUTCOME: The pass rate goes up the percentage
run-new-exp 627c627 < argv[1] = <host(2)[4.4]# > --- > argv[1] = <host(2)[4.4]$ > FAIL: run-new-exp

full-log in attachment
MediumACCEPTEDnormalAutomated Build Testingptest-runner FAIL: run-new-exp, 2.4_M4_rc2 

Ptest-runner tests were executed and observing this run-vredir failures on the results.

POKY : 2.4_M4_r2 COMMIT:da05a01423a60a23cd1073eb0ad3776e5bf4f2a8 HW: NUC 6i5SYH IMAGES:

Results Chart table:

EXPECTED OUTCOME: The pass rate goes up the percentage

ACTUAL OUTCOME: The pass rate goes up the percentage

run-vredir 90,91c90,91 < ./vredir6.sub: line 10: /dev/null: Too many open files < ./vredir6.sub: line 13: /dev/null: Too many open files --- > ./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument > ./vredir6.sub: line 13: /dev/null: Invalid argument FAIL: run-vredir

full=log in attachent
MediumACCEPTEDnormalAutomated Build Testingptest-bash cases failed in 2.4_M4_rc2, [FAIL: run-vredir] 

I ran this as root from rpm's upstream source checkout, you need to tweak as appropriate (and copy rpmrc where rpm asks you beforehand):

root@kanavin-desktop:/home/ak/development/rpm# RPM_CONFIGDIR=. ./rpm -v -r /home/ak/development/rpm/testdir/ -ivh ../poky/build/tmp/deploy/rpm/noarch/os-release-1.0-r0.noarch.rpm
MediumACCEPTEDmajorOE-Coredo_rootfs fails with disc space (dnf) although there's enough space left 

Back in 2.3 wic create would tell you where the rootfs location was:

wic create mkefidisk -e core-image-minimal ROOTFS_DIR: /home.../core-image-minimal/1.0-r0/rootfs

As of 2.4 it outputs the tmp rootfs location instead. This was probably introduced when this feature was turned into a plugin.

wic create mkefidisk -e core-image-minimal ROOTFS_DIR: /home/scottrif/poky/build/tmp.wic.r4hkds0b/rootfs_copy

See plugins/imager/ print_info()
MediumACCEPTEDnormalOE-Corewic create displays incorrect rootfs location 

Moving to Stephano.


for some wiki docs on rpm feeds.
MediumIN PROGRESS DESIGNnormalOE-Coreoe-setup-rpmrepo no longer works with RSS 
11466 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.
MediumIN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS KitTPM 2.0 support (under qemu) 
11494 All component in refkit gateway profile is compliance with secure boot requirement. Except gnupg dependency in flatpak. script in oe-selftest also complete but cannot upstream until the gnupg dependency is fix.
MediumIN PROGRESS IMPLEMENTATIONenhancementIoT Reference OS KitGPLv3 free gateway profile 
11674*MediumIN PROGRESS REVIEWnormalOE-Corecore-image-sato-sdk-ptest build error for cpio image 

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: 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= 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:
MediumIN PROGRESS REVIEWnormalOE-Corerunqemu: value given to qemuparams is automatically overwritten 

(In reply to comment #0) > The objective of this bug is to examine the viability to add ext2 support to > poky tiny images.

Just to clarify, this bug is to add support for creating/modifying ext partitions on poky-tiny, this will be added via busybox.

While doing this I will also check what other functionality should or may be added to poky-tiny.
MediumIN PROGRESS REVIEWenhancementBSPsAdd mkfs.ext support to busybox on poky-tiny 

Ok Amber. I will wait until this is merged so I can play with it and then document it in that section where I tell about the wic command.


MediumIN PROGRESS REVIEWnormalOE-Core'wic help' / 'wic --help' output is not user friendly. Needs to be redone 

I have a final version of the runtime package management stuff and a bit of a re-write for the PACKAGE_FEEDS_ARCHS variable. Maybe you could review these sections for sanity.

Thanks, Scott - Here, I added wording to show this is an optional variable. I also put in a "Tip" box to describe the ability to "whitelist" architectures. - I updated the example list of bash packages created by a build. I previously had a static list that was not complete. Wording now lists a bunch of bash packages as an example. - I added "tar" as a supported package. It was not in the previous list but is mentioned in the description of the PACKAGE_CLASSES variable. I added better wording about generating the package index. I understand the dependency issues here now so I think was able to better explain to the user the need for building the package index separately after any packages are built. - I pretty much rewrote this entire section for clarity and better understanding.
MediumIN PROGRESS REVIEWnormalDevelopment ManualSection results in 404 error and failure to synchronize cache 
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 

(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 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 

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 
10552 adding to future wish list.
MediumNEWenhancementCROPSDevtool add from existing Eclipse project within the Eclipse CROPS plugin 
10553 adding to future wish list.
MediumNEWenhancementCROPSContext sensitive recipe syntax support within the Eclipse CROPS plugin 
10555 adding to future wish list.
MediumNEWenhancementCROPSDevtool upgrade from existing recipe into an Eclipse project within the Eclipse CROPS plugin 

(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 
10934 GNU ed in the RRS has an unknown version upgrade ( but the http index should be trivially indexable ( I suspect the problem is that all of the tarballs as .tar.lz, and we don't handle that extension in bitbake.
MediumNEWnormalRecipe Reporting System (RRS)RRS doesn't notice .lz upgrades 

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 

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 

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/", 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/", 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/", 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/", 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/", line 149, in loadConfig
   exec f in localDict
 File "/media/data/yocto-autobuilder/yocto-controller/controller.cfg", line 94, in <module>
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/", line 65, in createBuildsets
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/", line 102, in parseBuildSet
 File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/", 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. 2.

MediumNEWenhancementAutoBuilderImprove configuration parser - better error reporting and more lenient 

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 

I just had to manually rotate the page as edits were failing with the following error:

Error: The text you have submitted is 2,052 kilobytes long, which is longer than the maximum of 2,048 kilobytes. It cannot be saved.
MediumNEWenhancementAutoBuilderImplement log rotation for Wikilog 
11348*MediumNEWenhancementDemosCreate demo showing Yocto built FPGA image in action 

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 /home/ed/git/yocto/poky/scripts/lib/wic/ 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 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 
11388 Push to future release.
MediumNEWenhancementDemosCreate a demo using build performance visualization tool to show build speed improvements 
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 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 

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 

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

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 Is this a superset of bug 11421?
MediumNEWnormalCROPSeSDK automated testcases don't run on Crops-eSDK 

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 

First video analysis component to be integrated is Motion ( Initial version of the recipe is here:
MediumNEWenhancementIoT Reference OS KitComputer vision video analysis support 

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 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) 
11533 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
MediumNEWenhancementBSPsRMC: [EFI] Add debug option 

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:



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

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

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) 

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


./rmc --fp

will return b2c1a220edd348efb0108e8c98e9a28d .
MediumNEWnormalBSPsRMC: Get board fingerprint 

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

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

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


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

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


./rmc -p -f FILE.fp
MediumNEWenhancementBSPsRMC: Print fingerprint file contents 
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 
11544 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
MediumNEWenhancementBSPsRMC: Add debug option 

Parse CONFIG file and store RMC log to file if

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

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 
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 
11704 adding markus and randy
MediumNEWenhancementBitBakeAdd other resource monitoring options to conf/local.conf STOPTASKS/ABORT 

(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 

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


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


include =


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 

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 
11801MediumNEWnormalOE-Corerpmbuild fails randomly when try to build a spec file 
11808 Moving this to medium pending the resolution of bug 11183.
MediumNEWminorOE-Corecve-check does not match previous SW versions 
11881 Couldn't we just add what we have now, and if it's deemed "not perfect" in the future, provide patches then for improvements?
MediumNEWenhancementBSPsadd infrastructure to allow BSPs to switch between *set* of configurations 

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 

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]

MediumNEWenhancementOE-Coreinclude more info when signatures do not match on the SstateTest unit tests 

We have observed issues on the Yocto Project Autobuilder clusters which seem like one or more of the tap devices have become corrupted.

It would be useful to have a script which can validate that the device is correctly configured and usable.

Note: filed against OE-Core because other, non Autobuilder, users have observed long-lived tap devices becoming unusable.
MediumNEWenhancementOE-CoreScript to validate tap devices 
11998 When building core-image-sato-sdk-ptest, I would expect sed-ptest to be present in the image. (it is not). The sed recipe contains code for ptest, the wiki pages mention sed-ptest , so I would expect the test to exist. Looking at some old test logs, I see sed-ptest has not been ran at all ever ( ). Am I missing something here?
MediumNEWnormalOE-Coresed-ptest missing 
12018 The output of bitbake --help should be grouped to make it easier to read. For example showing first the options that a normal user would use (-C --runall etc), then debugging options, then internal flags (or even hide those behind --help-internal?)
MediumNEWenhancementBitBakeHelp output should be grouped 

In a couple of different failures recently, the failure to start or connect to the server for various reasons needs better messaging.

In one case I had started a bitbake in another window and then tried to start another task in a different window.

NOTE: Reconnecting to bitbake server... NOTE: Retrying server connection... NOTE: Reconnecting to bitbake server... NOTE: Retrying server connection... ERROR: Unable to connect to bitbake server, or start one

In another case I forgot to be in the BUILDDIR and got the following message:

NOTE: Retrying server connection... (Traceback (most recent call last):

 File "/srv/sdc/builds/x32/bitbake/lib/bb/", line 427, in setup_bitbake
   topdir, lock = lockBitbake()
 File "/srv/sdc/builds/x32/bitbake/lib/bb/", line 494, in lockBitbake
   lockfile = topdir + "/bitbake.lock"

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' )

ERROR: Unable to connect to bitbake server, or start one
MediumNEWminorBitBakebitbake server failing to start or connect need better messaging 

Added tests for wic in eSDK. Patch is still pending on mailing list.

However, this is just some basic tests to ensure wic is working within eSDK.

We need more tests to increase the coverage.
MediumNEWnormalTest Plans/Suitebug for QA to create Testcases for this new test on testopia AUTO_eSDK_sdkext 

more warnings:
MediumNEWnormalBitBakeResourceWarning (sometimes) 

STATUS: FAILED BUILD: 2.4 M4: rc1-592c3449697ce39bf07864fafd7f0a61ca230561 ENVIRONMENT: Debian 4.3.0-0.bpo.1-amd64 STEPS TO REPRODUCE: 1. Start up toaster. 2. Create 2 builds, such as "bitbake core-image-minimal" and "bitbake core-image-sato". Wait for successful builds and then run: xdg-open http://localhost:8000/. 3. Enter "All build" table in web browser. 4. click on the time's link next to Build time: 5. You will see the task table and see the time's column is empty.

EXPECTED OUTCOME: Has to be the time from the tasks
MediumNEWnormalToasterThe field from time's task is empty 
12165 Due to time constraints and importance, moving this issue to Future as of now, it is not causing any problem with the patchtest execution.
MediumNEWenhancementPatchwork/PatchtestCorrect temporal workaround for "too many open files" error 

The patchtest initscript and the core-image-patchtest recipe were refactor, thus this workaround is now inside Due to time constraints and as it is not an urgent matter, I'm moving it to Future.
MediumNEWenhancementPatchwork/PatchtestProvide adequate solution for setting correct LOCALE in guest machine 

The problem may be resolved with "12194" (specifically buildhistory missing). I see the problem in builds before the patch for #12194 but not after.

I will test some more, and then close as a duplicate if nothing else comes up.
MediumNEWenhancementToasterAfter building an image, checking the packages there's nothing. 

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: genericx86-64_NUC NUC Model: NUC6i5SYH IMAGES: core-image-sato-sdk.wic, core-image-sato-sdk.hddimg

The "snd_hda_codec_hdmi" parselog errors continue appearing in 2.4 RC3 on automatic BSP testing for genericx86-64 images in NUC (in both, wic and hddimg formats). For more reference, I have attached the log file with more details about the execution using the hddimg version.

This is an example of the errors that appear:

Central error: [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16

[ 1.448566] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.449571] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.449609] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.452014] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452015] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452015] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452016] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452017] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452017] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.453193] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.453793] snd_hda_codec_generic hdaudioC0D2: ignore pin 0x7, too many assigned pins [ 1.453795] snd_hda_codec_generic hdaudioC0D2: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [ 1.453796] snd_hda_codec_generic hdaudioC0D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453796] snd_hda_codec_generic hdaudioC0D2: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453797] snd_hda_codec_generic hdaudioC0D2: mono: mono_out=0x0 [ 1.453798] snd_hda_codec_generic hdaudioC0D2: dig-out=0x5/0x6 [ 1.453799] snd_hda_codec_generic hdaudioC0D2: inputs: [ 1.455463] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input4 [ 1.455526] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input5

[ 1.455598] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
MediumNEWnormalBSPsnot audio- play (wav) with HDMI, 2.4 

STATUS: FAILED BUILD: 2.4 M4: rc1-592c3449697ce39bf07864fafd7f0a61ca230561 ENVIRONMENT: Fedora 26 STEPS TO REPRODUCE:

      1. Access a project page, either by creating a new project or accessing an existing project from the "All projects" table.
   2. On the project page click on the "New custom image" link situated on the left-hand side  
 3. Click on button create custom image without name and it will change to creating custom image
EXPECTED OUTCOME: It has to wait for a name
MediumNEWnormalToasterThe button from New custom image is not working as expected 

STATUS: FAILED BUILD: 2.4 M4: rc1-592c3449697ce39bf07864fafd7f0a61ca230561 ENVIRONMENT: Fedora 26 STEPS TO REPRODUCE:

      1. Access a project page, either by creating a new project or accessing an existing project from the "All projects" table.
   2. On the project page click on the "New custom image" link situated on the left-hand side  
 3. Click on button create custom image without name and it will change to creating custom image

4. write an image recipe example core-image-sato 5. It says "an image with this name already exists. Image name must be unique. 6. Press the button create custom image

EXPECTED OUTCOME: You couldn't press the button because the name is not unique, it has to be disabled.
MediumNEWnormalToasterThe button from New custom image is letting you press it and its supposed to be disabled. 

For more reference, I found the following old thread on the Ubuntu forums, mentioning CONFIG_USB_SUSPEND as a probable cause for this error.
MediumNEWnormalBSPs[TC 1059] test_parselogs failed om MMAX64 (Turbot, WIC image) : usb 1-3: device descriptor read/64, error -71 
12224 Right, does not occur if you use an hddimg instead of wic. Examining the contents the only difference bootloader wise is the syslinux config, so I believe that's where the problem lies.
MediumNEWnormalOE-Corewic image created for qemux86-64 stalls on undefined video mode number: 318 


BTW, I would have never thought to mix distros this way. I expect that the three images built against the current distro setting. I would like to try this and see that Toaster kept them all organized (outside of this display rendering defect).
MediumNEWnormalToaster[toaster] when building 3 or more images left hand summary is not shown correctly 

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: Debian 4.3.0-0.bpo.1-amd64 STEPS TO REPRODUCE:

1. Start Toaster 2. Build a core-image-minimal 3. Click on the Layers button

EXPECTED OUTCOME: Before I could see these layers in the table meta-qt3 and meta-qt4. now I dont...

NOTE: I just want to know if this is expected so that I may make changes to the testcase that uses them.
MediumNEWnormalToaster[toaster]why arent the meta-qt3 and meta-qt4 present in the compatible layers for poky 


When adding layers through the compatible layer table can lead to duplicated layers being added to the project.

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: Debian 4.3.0-0.bpo.1-amd64 STEPS TO REPRODUCE:

1. Start toaster 2. meta-oe had been added as a dependency of some other layer, 3. adding more layers that had meta-oe as a dependency I saw it duplicated it.


This is not reproducible anymore but I attach the screen shot as evidence that some how this happened. Condition must be checked again.
MediumNEWnormalToaster[Toaster] project layers can be duplicated 

The unit test ensuring a change on LIC_FILES_CHKSUM is mentioned in the commit message, is failing erroneously on production, thus reporting false-positives to the community. The behaviour I've seen so far is that the variable (LIC_FILES_CHKSUM) is empty on the pre-test and not empty on the test, which will result in a failure due to the test-case logic: if pre-test and test variables are different, the test-case will report a failure. This shouldn't happen as the series doesn't modify such variable at all.

This has happened twice:
MediumNEWnormalPatchwork/PatchtestLIC_FILES_CHKSUM test-case throws false-positives on production machine only 

Since the refactoring I did in 2.4 for devtool/recipetool fetching new source, we actually need to create a "dummy" recipe in order to be able to run do_fetch/do_unpack/do_patch with the desired SRC_URI, then run the tasks, then delete the recipe. To do this we look through BBFILES and pick a place to put the recipe, favouring the workspace layer if it's present - but it may not be if the user is running recipetool and devtool has never been run.

This current method is a kludge. We could really use a place to put these dummy recipes temporarily without potentially writing things into a random layer in the user's configuration. Of course we could add a layer on the fly, but that would trigger a full reparse of the metadata which I think would be worse.
MediumNEWenhancementOE-Corerecipetool needs a place to put dummy recipes / bbappends 
12378 here for documentation since no reproducer
MediumNEWnormalBitBakeparsing error while using persistent bitbake server 
12388 punting this to 2.6
MediumNEWenhancementOE-Corerunqemu: support setting the -cpu <NAME> from the command line 
12389 In general, the whole suite must be exercised (oe-selftest -a) based on release tarball and see if other areas are affected.
MediumNEWnormalAutomated Runtime Testingoe-selftest devtool tests fails when repository comes from a tarball 
12390 The % wildcard (as used in PREFERRED_VERSION and in bbappend filenames) can only match at the end. Whilst this is almost certainly by design, we don't actually state that anywhere in the documentation that I can find - not anywhere we refer to the wildcard usage in the bitbake manual or ref manual, at any rate. We should either change the code to allow the wildcard to be anywhere (easiest I can think of would be to substitute the % with * and use fnmatch); or alternatively we update the documentation so it is clear that there is this limitation.
MediumNEWenhancementBitBake% wildcard does not work anywhere except at the end 

Hi David! We talked about these in Prague.

As I said, main case is to e.g. dump your site.conf into the toaster bitbake vars.

-> I don't want to do this var by var and value by value.  ;)
MediumNEWenhancementToasterMake Bitbake Variables settings a textbox so you can inject larger sets of variables 

Hi !

Use-case: A toaster instance to be paired with e.g. a sstate-cache or download mirror. Currently we'd need to inject the variables one-by-one for each project/build.

Enhancement: Instead we could have a global settings button and define 'bitbake vars" there. They'd be applied to all projects then. applies here, too.
MediumNEWenhancementToasterAllow toaster to store bitbake variables global to the toaster instance (not per build) 
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/ decode stdout data fail 
10535 Given CDT upstreaming approach, this is no longer relevant. Can reopen if things change.
MediumRESOLVEDenhancementCROPSBuild container for Maven/Tycho build for Eclipse CROPS Plugin 
10537 Current plan is to stick with eclipse-poky.
MediumRESOLVEDenhancementCROPSUse "new project template" framework to create sample Make project 
10538 Current plan is to stick with eclipse-poky.
MediumRESOLVEDenhancementCROPSUse "new project template" framework to create sample Automake project 
10540 will use Managed Builder solution for now.
MediumRESOLVEDenhancementCROPSUse "new project template" framework to create sample CMake project 
10632 commit 4f2baebf362d71351db044c0646f9bc6e8a39c49
MediumRESOLVEDenhancementToasterAdd distro selection support 
10947 this is not a priority for now
MediumRESOLVEDnormalToasterReintegrate fully functional and corrected toaster automation testcases from 

Change pushed to production in commit:

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

Change pushed to production in commit:

MediumRESOLVEDnormalPatchwork/Patchtestpatchwork: Bundle paging links drop "archive" query parameter 

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.
MediumRESOLVEDnormalBSPsDifferent major versions of QEMU produce different RMC fingerprints 
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
MediumRESOLVEDenhancementIoT Reference OS Kit TestingQA: Validate Reference kit has BT audio support on gateway profile 

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

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 

Hi Jair,

According to, 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. 

The requested functionality is provided in commit:

MediumRESOLVEDenhancementOE-Corecreate-pull-request: add in-reply-to option to ensure patch/series threads don't break 
11320 Won't apply to RMC2.
MediumRESOLVEDenhancementBSPsRMC: Extend grub-efi to process RMC database file from ESP 
11321 Does not apply to RMC2.
MediumRESOLVEDenhancementBSPsRMC: grub-efi - append KBOOTPARAM to linux boot entry's cmdline 
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 Bruce's comment.
MediumRESOLVEDenhancementDemosCreate a demo that shows a Yocto built Zephyr image running on Arduino 101 

The custom layer index aspect has been resolved by 11957.

The file-based layer index feature will be incorporated with the updated layer index class, which will be completed in YP-2.5.

Based on this, I am closing this enhancement.
MediumRESOLVEDenhancementToastersupport custom layer index servers, file-based layer index 
11405 Does not apply to RMC2.
MediumRESOLVEDnormalBSPsRMC: records in an existing RMC database cannot be updated 
11445 The requester has withdrawn the enhancement request, therefore closing this bug.
MediumRESOLVEDenhancementOE-Corewic: allow wic to support additional partition (e.g. 4th partition) 
11446 This requirement is not valid now.
MediumRESOLVEDenhancementBSPsFlexibility and configurability to boot from any partition 
11455 We're going to handle this a different way, by separating out the embedded shell commands into a repo of callable scripts. We can then branch that repo per-release.
MediumRESOLVEDenhancementAutoBuilderImplement script to support running two versions of AB on YP infrastructure 

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 The PR #200 got merged.
MediumRESOLVEDenhancementIoT Reference OS KitROS-Core support 
11465 Got merged to intel-iot-refkit
MediumRESOLVEDenhancementIoT Reference OS KitReference Kit Industrial Robotics Profile Detailed Documentation 
11468 was merged into refkit.

Automated testing is missing, but as it was excluded from the scope of the issue anyway, I closing this one here as "resolved".
MediumRESOLVEDenhancementIoT Reference OS Kitintegrate firmware update into system update 
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 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 Now nodejs version updated to 6.11 in refkit .
MediumRESOLVEDenhancementIoT Reference OS KitRefkit: Upgrade nodejs version(v5.11+) 

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:

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:
MediumRESOLVEDenhancementIoT Reference OS KitConfiguration Management Solution Study 
11492 Rejected.
MediumRESOLVEDenhancementIoT Reference OS KitReference Kit Gateway Profile Detailed Documentation 
11510 Fixed in oe-core 3328211afdef8ffb00dd4dff1143959d5412b075.
MediumRESOLVEDenhancementOE-CoreImprove the way we handle python's packaging (autopackaging) 

The test already checks for indentation errors/inconsistencies, but this issue is now obsolete as the pylint test case has to be refactored.

I'm filing a new issue for tracking the refactoring process.
MediumRESOLVEDenhancementPatchwork/Patchtestcheck for four-space indented in python metadata 

You've fixed it:

commit b2b422c190af482a0b4b7291545aa3239c15a1e8 Author: brian avery <> 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 <>
   Signed-off-by: Ross Burton <>
Signed-off-by: Richard Purdie <>
MediumRESOLVEDnormalOE-Coreqemuboot.conf files in the downloads.../machines/qemu/qemu<machine> should be scrubbed of ab paths 
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 

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:
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 PR #167 is merged.
MediumRESOLVEDnormalIoT Reference OS KitCan't resolve own hostname when running under QEMU 

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 "

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[1]
11590*MediumRESOLVEDnormalOE-Corecreating root file systems using elf failed applying patch fix-makefile-to-find-libz.patch[2]

Merged into oe-core on 21st Sept 2017

From OE-Core rev: 752a8a02d52cf868d1c182672d6ceb3d455dfa1e
MediumRESOLVEDenhancementOE-Corebzip2-ptest: improve reproducible build 
11601 bug 11432 requires the same feature as the one reported.
MediumRESOLVEDenhancementPatchwork/Patchtestcheck new patches are indicated in the SRC_URI 
11602*MediumRESOLVEDnormalOE-Coreacl-ptest references host build path 
11616 Closing. I am not seeing this in the current builds.
MediumRESOLVEDnormalOE-CoreMesa build failed with gcc 7 (ARM) 
11642 In accordance with the strategy to use more standard tools for our CI infrastructure, the team decision was not to continue integrating DAFT to our process. According to this, development on this item won't be continued anymore.
MediumRESOLVEDenhancementAutomated Runtime TestingUse DAFT to execute BSP's automated test on QA cycles. 
11656 Merged in oe-core 04db02138e363898e040e33557f1296e8a43c3fd
MediumRESOLVEDnormalOE-Corelibtool contains build host references 
11666*MediumRESOLVEDnormalOE-Coreattr-ptest references host build path 
11667*MediumRESOLVEDnormalOE-Coreflex-ptest references host build path 
11668*MediumRESOLVEDnormalOE-Corelibz-ptest contains build host references 

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

MediumRESOLVEDnormalBitBake User Manualbitbake.conf URL link example should be updated 
11684 commit d74bcbeaf241a67871d62b7e2c17900ae900642e
MediumRESOLVEDnormalToasteraddress RemovedInDjango110Warning's for Django >= 1.9 
11694 Fixed in oe-core 3328211afdef8ffb00dd4dff1143959d5412b075.
MediumRESOLVEDenhancementOE-CorePython JSON manifest should be parsed directly by bitbake 
11695 Fixed in oe-core 3328211afdef8ffb00dd4dff1143959d5412b075.
MediumRESOLVEDenhancementOE-CoreAdd task to create python manifest(s) automatically 

(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 
11711 There is no definite way to provide the branch name so patchtest cannot force a certain format. Setting this bug as invalid.
MediumRESOLVEDnormalPatchwork/Patchtestcheck proper prefix on subject 
11718 Merged in OE-Core 1bd3ed18379c330c1c733dc9f043dbbe8aa0d254.
MediumRESOLVEDnormalOE-CoreRPM injects /usr/lib/.build-id/ into packages 
11719 The fix has been merged to poky master. Commit id 1b11a653d0be6128b26ea9421c783c6e78f7549b
MediumRESOLVEDnormalOE-CoreUnneeded stack trace is printed when ruunqemu fails 
11727 Commit a25ece2d77f28e71a71913ea25391bcbc8fa37e0
MediumRESOLVEDnormalToastertrim build target input 
11730*MediumRESOLVEDnormalOE-Corekernel-devsrc: various references to the host build system 

After some discussion on the ML, we agreed that the core-image-tiny-initramfs image should not provide an actual hardware (WIC) image, this has been fixed on oe-core here:

A new image core-image-tiny that works using core-image-tiny-initramfs does provide a hwardware image, and it was added to meta-intel here:
MediumRESOLVEDnormalBSPsdo_image_wic fails on core-image-tiny-initramfs 
11740*MediumRESOLVEDenhancementBSPsDAFT: Enable BeagleBone OTG Ethernet interface on genericx86 images. 
11744 Commit a25ece2d77f28e71a71913ea25391bcbc8fa37e0
MediumRESOLVEDnormalToasterset clone progress default to off 

I did some performance benchmarks with branch [1] which avoids bitbake process launch but gains are minimal (I do have the numbers) so will close this bug as wontfix. So, it was a good idea but turned in practice that it is not worth it.

MediumRESOLVEDenhancementAutomated Runtime Testingselftest test cases should use the test data and/or tinfoil instead of bitbake 
11753 Patchtest should always test series on head and no other commit in production as we are interested in ensuring new patches fully apply.
MediumRESOLVEDenhancementPatchwork/Patchtestpatchwork should track the HEAD commit id in stored patches 
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 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 

I have just tested this patch on my ARM platform and it doesn't work as intended:

The `len(partitions) > 4` also counts those with the --no-table flag so my u-boot "partition" is counted as well. Although there are only 4 real partitions in my wks, the fstab still ends up with mmcblk1p5 for the fourth partition.
MediumRESOLVEDnormalOE-CoreWIC creates wrong partition number 
11793 This resulted in being not that important, if in the future there is a need to implement, open a bug
MediumRESOLVEDnormalAutomated Runtime Testingcreate opkg and dpkg index 
11794 commit 3bc3d26b465b5af3cebc1d4c0d1fa382965c32cf
MediumRESOLVEDenhancementToasterAdd remote HTTP API to enable status aggregation of multiple Toaster instances 
11805 Tools have been removed.
MediumRESOLVEDenhancementAutomated Build TestingCreate yocto-bsp/yocto-kernel tools tests 
11806 Tool has been removed.
MediumRESOLVEDenhancementAutomated Build TestingCreate test for yocto-kernel tool 

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 Works now and a more recent checkuri worked, so it was a transient failure.
MediumRESOLVEDnormalOE-Core[master] nightly-checkuri libtimedate-perl_2.30 
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 
11868*MediumRESOLVEDenhancementOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1 opensuse422 
11871*MediumRESOLVEDenhancementOE-Coredistrodata.Distrodata.test_checkpkg - Testcase -1: ubuntu1604 
11872*MediumRESOLVEDnormalAutomated Build TestingUpdate and add the ID to the TCs in testopia:ubuntu1604 
11873*MediumRESOLVEDnormalAutomated Build TestingThese TCs need to be added to testopia Distrodata.test_checkpkg and Wic.test_mkfs_extraopts 
11880*MediumRESOLVEDnormalOE-Corekernel-devsrc: multiple files present in kernel-build-artifacts 
11891 The patchset has been merged to poky master. commit id cef80d0dfedd5a692267fa5ffa2146af4856304a
MediumRESOLVEDenhancementOE-CorePort bmaptools to Python 3 
11894 Interestingly I can't replicate this now, maybe the other fixes solved it or something in oe-core changed. I'll close and will reopen if I hit it again.
MediumRESOLVEDnormalBSPsiwlwifi fails to build 
11915 commit 52a67cc958185266f1b982555cf019a8b4f10817
MediumRESOLVEDnormalToasterToaster: custom image updates and original creation 

yes. this bug then becomes user lack of knowledge, as I did not know the connman ui did that. :)

MediumRESOLVEDenhancementSatosato display should show ip address if available 
11938 commit 9bfe460934dd9bafcfab7bdf8cbbf7ad968e9026
MediumRESOLVEDenhancementToasterAdd ability to do custom actions when Toaster is started and stopped 
11948*MediumRESOLVEDenhancementOE-Coredevtool upgrade walks the file tree and execs a git add for each file 
11950 Oe-core went back to openssl 1.0 and no plans to move to 1.1 just yet. Closing as obsolete for now.
MediumRESOLVEDnormalIoT Reference OS Kit(refkit) Error compiling libtpm-native-1.0 
11951 Oe-core went back to openssl 1.0 and no plans to move to 1.1 just yet. Closing as obsolete for now.
MediumRESOLVEDnormalIoT Reference OS Kit(refkit) tpm-tools-native- compile error 
11956 This defect is covered by the fix in 12006.
MediumRESOLVEDnormalToasterproblems with layer links 

commit 254e2debe5705f4fe34307378a8c1457e4327d1c

Note that the commit header accidentally marked this as #11938.
MediumRESOLVEDenhancementToastersupport custom Layer Index URL and fixture override 

The problem was caused by mismatched include files. They were mismatched because the "master" git repo did not contain the "snapshot" version, so nativesdk-gnutls build looked into incorrect /opt/poky/xxx folder. (should have been /opt/poky/xxx+snapshot). This problem was fixed/should not be observed after:
MediumRESOLVEDmajorOE-Corenativesdk-gnutls fails on system with toolchain installed in default location (using headers from toolchain) 
11997*MediumRESOLVEDnormalOE-Corelibxml2-ptest : build host references 
12014 commit 8b289ea6c32277a2f474dda925aa261296a4cde4
MediumRESOLVEDnormalToasterdebug message during build lists layers missing separators 
12015 commit 3752641986058806c464c4eb155732baf4dbaff7
MediumRESOLVEDnormalToasterset default pokydirname if no external layers 
12050 We can not seem to reproduce this, there may be related to a race in resetting the uedev system over the switchroot. See Bug #9520 for further details. If this fails again in a reproducible way then we can reopen.
MediumRESOLVEDnormalBSPsfailed on udevd[342] inotify_add_watch /dev/loop when running test image 
12051*MediumRESOLVEDnormalOE-Corehostap-utils download site is down 
12083*MediumRESOLVEDcriticalOE-Corebuild failure with gcc-6.3.0: ./md-unwind-support.h:55:21: error: field 'uc' has incomplete type 
12087 Mars plugin is dropped from the AB. Oxygen has been added. Marking as fixed.
MediumRESOLVEDnormalEclipse PluginEclipse Oxygen needs to be added. Eclipse Mars needs to be dropped 
12089 Setting Doc flag to "done".
MediumRESOLVEDnormalBitBake User ManualNeed to document BBFILES_DYNAMIC 
12095 Given current resources, we won't be able to address this. Suggested workaround is to build both the 32 and 64 bit sdks.
MediumRESOLVEDnormalADTToolchain.Host.Mismatch problem 
12118*MediumRESOLVEDenhancementOE-Coremuslx32: webkitgtk compilation error 
12119*MediumRESOLVEDenhancementOE-Coremuslx32: boost compilation error 
12121*MediumRESOLVEDenhancementOE-Coremuslx32: qat16 compilation error 
12122*MediumRESOLVEDenhancementOE-Coremuslx32: systemd-boot compilation error 


Make sure architecture dependent defines are correct for x32 by checking for both ILP32 and x86_64.
MediumRESOLVEDenhancementOE-Coremuslx32: acpica compilation error 
12125 Replaced by Bug 12517.
MediumRESOLVEDnormalOE-Corerunqemu-gen-tapdevs not working when using directly from build-dir 
12152*MediumRESOLVEDnormalOE-CoreAdd automated test for Go toolchain support 
12240*MediumRESOLVEDnormalGeneral RuntimeLSB-test: package list should be updated to use latest binary available 
12258 Merged in oe-core c04ae17f439ffd5fd70d8564430a94582e2cf688.
MediumRESOLVEDenhancementOE-CoreLICENSE in packagegroup? 
12264 Thanks.
MediumRESOLVEDnormalOE-CoreIMAGE_FSTYPES += "... wic.bmap ..." bmaptool freaking out 

OK, great, I think we can consider this resolved unless you have further issues.

I have however filed bug 12390 to cover the issue that % only works at the end of an expression - either we need to make it work anywhere, or properly document it as only working at the end since it appears we aren't currently mentioning that.
MediumRESOLVEDnormalBitBakeusing DEFAULT_PREFERENCE with SRCREV = "${AUTOREV}" can't work 
12384 It seems to be problem with wic. I am investigeting.The ticket can closed.
MediumRESOLVEDmajorOther YP Layers[meta][util-linux] mount: /proc: operation permitted for root only. 

Thanks Cornel,

We looked back and fixed all development branches for any yocto release that did not support 6.x. The "current" quick start and ref-manual should now reflect this as well. Because you have reviewed the change already, I am setting this as RESOLVED.

Fixed on the tip of the morty development branch on yocto docs (2.2.3).

Fixed on the tip of the pyro development branch on yocto docs (2.3.3).

Fixed on the tip of the rocko development branch on yocto docs (2.4.1).
MediumRESOLVEDnormalQuick Startinstructions for centos are wrong 

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 Verified
MediumVERIFIEDnormalDevelopment Manual[megamanual] dnf using rpm: Using RPM section changes required 
11769 Verified, issue is fixed.
MediumVERIFIEDnormalOE-CoreSDK environment-setup CXXFLAGS wrong 
11870 duplicated
MediumVERIFIEDenhancementOE-Corewic.Wic.test_mkfs_extraopts - Testcase -1 Ubuntu1604 
11889*MediumVERIFIEDnormalToaster[toaster] Toaster did not build on 2.4 m2 rc2 release 
12213 Verified as not reproducible on 2.4 M4 rc3.
MediumVERIFIEDnormalBSPs[TC 1059] test_parselogs failed on MMAX64 (Turbot) with direct firmware load for rtl_nic/rtl8168g-2.fw error 
10880 See Bruce's question
Medium+ACCEPTEDnormalOE-Coreperf recipe contaminates linux shared workdir in do_configure_prepend() 
11308 Ah, ok. I see now that there are a several bugs/enhancements being moved so I'll leave them alone rather than assume they are victims of the browser/Bugzilla bug that has been plaguing me! :)
Medium+ACCEPTEDenhancementOE-CoreConsider replacing pkg-config with pkgconf 
11497 This is blocked on the locked-sigs bug, which has moved target milestone again. I'm assigning this issue to Paul so that he can track the dependency and disposition this issue to an appropriate implementer once the dependency bug is resolved.
Medium+ACCEPTEDnormaleSDKeSDK: create test case for populate_sdk_ext using shared states 

(In reply to comment #2) > With reference to link below: > > ubuntu1604/builds/58/steps/Running%20oe-selftest/logs/stdio > > devtool-import-export-selftest&id=4b0e8df2ecb7f6a90add6bf4d2839bf5d8478a4d > > > 2018-03-13 07:18:38,192 - oe-selftest - INFO - test_devtool_deploy_target > (devtool.DevtoolTests) ... OK (149.287s) > 2018-03-13 07:19:17,697 - oe-selftest - INFO - test_devtool_export > (devtool.DevtoolTests) ... OK (39.503s) > 2018-03-13 07:19:56,857 - oe-selftest - WARNING - tearDown commands have > failed: rm workspace-export*.tar.gz > 2018-03-13 07:19:56,929 - oe-selftest - INFO - > test_devtool_export_exclude_all (devtool.DevtoolTests) ... OK (39.231s) > 2018-03-13 07:20:34,443 - oe-selftest - INFO - > test_devtool_export_exclude_specific_file (devtool.DevtoolTests) ... OK > (37.513s) > 2018-03-13 07:21:11,969 - oe-selftest - INFO - test_devtool_export_include > (devtool.DevtoolTests) ... OK (37.523s) > 2018-03-13 07:21:51,570 - oe-selftest - INFO - > test_devtool_export_overwrite_file (devtool.DevtoolTests) ... OK (39.598s) > 2018-03-13 07:22:09,454 - oe-selftest - INFO - test_devtool_extract > (devtool.DevtoolTests) ... OK (17.881s) > 2018-03-13 07:22:25,818 - oe-selftest - INFO - > test_devtool_extract_virtual (devtool.DevtoolTests) ... OK (16.364s) > 2018-03-13 07:23:06,201 - oe-selftest - INFO - > test_devtool_finish_modify_origlayer (devtool.DevtoolTests) ... OK (40.382s) > 2018-03-13 07:23:45,617 - oe-selftest - INFO - > test_devtool_finish_modify_otherlayer (devtool.DevtoolTests) ... OK (39.415s) > 2018-03-13 07:24:22,425 - oe-selftest - INFO - > test_devtool_finish_upgrade_origlayer (devtool.DevtoolTests) ... OK (36.807s) > 2018-03-13 07:25:02,547 - oe-selftest - INFO - > test_devtool_finish_upgrade_otherlayer (devtool.DevtoolTests) ... OK > (40.121s) > 2018-03-13 07:25:55,764 - oe-selftest - WARNING - tearDown commands have > failed: bitbake-layers remove-layer *//tmp/import7syded0e Here is a tearDown command fialing, I think this should be corrected.

> 2018-03-13 07:25:55,898 - oe-selftest - INFO - test_devtool_import > (devtool.DevtoolTests) ... OK (53.350s) > > Here are list of testcases below run for devtool.DevtoolTests are NOT > included with Testcase ID and yet to be merged into the HEAD on master > branch. > All the testcase mentioned below are tested in local PG autobuilder and > found to be passing. All other testcases are failing using this branch > lsandov1/devtool-import-export-selftest. Did you rebase this branch on top master? Because this branch is kind of old.

> > a) test_devtool_export > b) test_devtool_export_include > c) test_devtool_export_exclude_all > d) test_devtool_export_exclude_specific_file > e) test_devtool_export_overwrite_file > f) test_devtool_import > > 2018-03-13 07:27:13,844 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_create_workspace - Testcase 1158: PASSED > 2018-03-13 07:27:13,844 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add - Testcase 1159: PASSED > 2018-03-13 07:27:13,845 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add_fetch - Testcase 1160: PASSED > 2018-03-13 07:27:13,846 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add_fetch_git - Testcase 1161: PASSED > 2018-03-13 07:27:13,847 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add_fetch_simple - Testcase 1391: PASSED > 2018-03-13 07:27:13,848 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add_git_local - Testcase 1423: PASSED > 2018-03-13 07:27:13,849 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_add_library - Testcase 1162: PASSED > 2018-03-13 07:27:13,850 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_build_image - Testcase 1366: PASSED > 2018-03-13 07:27:13,851 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_buildclean - Testcase 1620: PASSED > 2018-03-13 07:27:13,852 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_deploy_target - Testcase 1272: PASSED > 2018-03-13 07:27:13,853 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_export - Testcase -1: PASSED > 2018-03-13 07:27:13,853 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_export_exclude_all - Testcase -1: PASSED > 2018-03-13 07:27:13,854 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_export_exclude_specific_file - Testcase > -1: PASSED > 2018-03-13 07:27:13,855 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_export_include - Testcase -1: PASSED > 2018-03-13 07:27:13,856 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_export_overwrite_file - Testcase -1: PASSED > 2018-03-13 07:27:13,857 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_extract - Testcase 1163: PASSED > 2018-03-13 07:27:13,858 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_extract_virtual - Testcase 1379: PASSED > 2018-03-13 07:27:13,859 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_finish_modify_origlayer - Testcase 1621: > PASSED > 2018-03-13 07:27:13,860 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_finish_modify_otherlayer - Testcase 1622: > PASSED > 2018-03-13 07:27:13,861 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_finish_upgrade_origlayer - Testcase 1623: > PASSED > 2018-03-13 07:27:13,861 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_finish_upgrade_otherlayer - Testcase 1624: > PASSED > 2018-03-13 07:27:13,862 - oe-selftest - INFO - RESULTS - > devtool.DevtoolTests.test_devtool_import - Testcase -1: PASSED > > Since these additional testcases are passing in > lsandov1/devtool-import-export-selftest, it should be merged into master > branch to be included into 2.5 M3 and beyond.

I think the test cases that are failing should be reviewed as they may be failing due the new test test cases added.
Medium+ACCEPTEDnormalAutomated Build Testinginclude selftest tests for devtool import/export plugins 
11791 Is this part of the autobuilder rework? If not, will it be ready for YP 2.5 M3?
Medium+ACCEPTEDenhancementAutoBuilderReduce the amount and storage space required of image artefacts published from builds 

I have drilled down to the point where devtool unable to find due to the wrongly configured variable BBAKE_EDK_TOOLS_PATH in <ovmf-source>/OvmfPkg/ and it came from a environment variable, STAGING_BINDIR_NATIVE.

Within a native build environment, EDK_TOOLS_PATH was set by do_patch post task functions, "fix_basetools_location". And its STAGING_BINDIR_NATIVE is pointed to RSS by looking at the output from “bitbake -e”.

However, in eSDK environment, patching was done by oe.patch module in within devtool. And it appears that the STAGING_BINDIR_NATIVE is wrongly set, hence causing BBAKE_EDK_TOOLS_PATH having the wrong BBAKE_EDK_TOOLS_PATH path and hence causing ovmf unable to be compiled within eSDK.

Problematic STAGING_BINDIR_NATIVE: /poky_sdk/tmp/work/i586-poky-linux/ovmf/git-r0/devtooltmp-sui06mnf/workdir/recipe-sysroot-native/usr/bin/edk2_basetools/BaseTools

A correct STAGING_BINDIR_NATIVE: /poky_sdk/tmp/work/i586-poky-linux/ovmf/git-r0/recipe-sysroot-native/usr/bin/edk2_basetools/BaseTools

I'm now looking at devtool <def _extract_source()> where devtooltmp-* was created and how does it impact the STAGING_BINDIR_NATIVE.
Medium+ACCEPTEDnormaleSDKin an esdk, devtool fails to build ovmf 

It appears that this defect is a side effect of:

 #12194 - Toaster server lost "toaster.conf" environment, user settings lost

Specifically, I think it is a result of this missing from the build environment: INHERIT+="toaster buildhistory"

Once I added the patch to #12194 the layer list as appears as expected. I will do more confirmation testing and then close this as a duplicate.
Medium+ACCEPTEDnormalToaster[Test Case 946] View detailed configuration information for a build 
12461*Medium+ACCEPTEDmajorOE-CoreIMAGE_TYPES cpio.lz4 isbroken 
11177 There have been some incremental progress. Generally, archive commands (tar, gzip) are scattered all over. Several patches were accepted that fix some of the issues, but there are a few more left. Some patches are still pending/being reviewed in ML. So moving to 2.5 M1 for completion, as more patches are to follow before this can be closed as RESOLVED.
Medium+IN PROGRESS DESIGNenhancementOE-CoreGenerate archives with deterministic metadata 
11877*Medium+IN PROGRESS DESIGNenhancementOE-CoreAdd aarch64 ilp32 framework[3]
11522 This is an enhancement, will do it in YP 2.5
Medium+IN PROGRESS IMPLEMENTATIONenhancementOE-Corerunqemu env var QB_MEM expects to be set to "-m 256" not "256" or "256M" 
11158 Moving the ticket to 2.5 M2 to match the new bug 11429's target milestone.
Medium+IN PROGRESS REVIEWnormalAutomated Build Testingbitbake: Create test for multiconfig globing support 
11176 Still in review...
Medium+IN PROGRESS REVIEWenhancementOE-CoreAdd optional command to rootfs-postprocess to remove non-determinism from rootfs 

Sent patch to the ML:

Moving to 2.5 M1, a slightly better version is being tested.

Patch sent to the ML:

This being an enhancement, it is unlikely to be merged in 2.4M4, so moving to 2.5M1
Medium+IN PROGRESS REVIEWenhancementOE-CoreEnsure TZ is also set to a consistent value 
11429*Medium+IN PROGRESS REVIEWenhancementOE-Coreoe-selftest should use its own build directory and write the desired configuration 

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 REVIEWnormalOE-Corerunqemu defaults to 512M memory if QB_MEM is not set, breaking mips64 

Taking ownership of this bug. This one has been in REVIEW status for over two months. I am leaving it open, but could someone to look over the material?


Medium+IN PROGRESS REVIEWnormalBitBakeTrying to create an new layer with the yocto-layer script fails. 
11612 Moving the ticket to 2.5 M2 to match the new bug 11429's target milestone.
Medium+IN PROGRESS REVIEWnormalAutomated Build TestingQA Bitbake: Create tests for multiconfig support 
11781 The bitbake --observer doesn't work atm, we need go on working on it in 2.5
Medium+IN PROGRESS REVIEWnormalBitBakebitbake --observe-only may get KeyError 

If you run a tinfoil-using script without running oe-init-build-env (or similar) then it hangs for 30s and then gives a traceback:

snip -----------------

$ scripts/oe-pkgdata-util list-pkgs ERROR: Unable to connect to bitbake server, or start one Traceback (most recent call last):

 File "scripts/oe-pkgdata-util", line 598, in <module>
 File "scripts/oe-pkgdata-util", line 578, in main
   tinfoil = tinfoil_init()
 File "scripts/oe-pkgdata-util", line 44, in tinfoil_init
 File "/home/paul/poky/poky/bitbake/lib/bb/", line 397, in prepare
 File "/home/paul/poky/poky/bitbake/lib/bb/", line 473, in setup_bitbake
   bb.fatal("Unable to connect to bitbake server, or start one")
 File "/home/paul/poky/poky/bitbake/lib/bb/", line 104, in fatal
   raise BBHandledException()

bb.BBHandledException ERROR: Unable to connect to bitbake server, or start one ERROR: Unable to connect to bitbake server, or start one

snip ----------------- Scripts such as devtool have their own checks for this that error out immediately, but it seems to me that tinfoil ought to handle this properly itself rather than every script having to have boilerplate checking code.
Medium+IN PROGRESS REVIEWenhancementBitBakeTinfoil doesn't behave well if environment not initialised 
12131 The patch has been merged into mainline three months ago, but the process to propagate to stable kernel is much slow than I expect. So I will submit this patch to the linux-yocto directly.
Medium+IN PROGRESS REVIEWnormalBSPsKernel traceback when reboot beaglebone black 

As I understand this in this bug the idea is to better describe the Basic architecture information of the oeqa test. On this wiki Describe how a new person can contribute to creating testcases for their new modules.

Make documentation proposal on this framework that later we can decide to add it to the mega manual or some other place. We will decide upon the content.

The core development of this framework under

Start by reading the README then the
Medium+NEWenhancementAutomated Runtime TestingDocument best practises/style guide for selftest tests and update tests 

As described in the comments on this bug

It seems that the CDT project lead is not going to mature the core build API sufficiently until at least CDT photon (June 2018).

So I'm moving this to 2.6
Medium+NEWenhancementCROPSuse CDT core build to enable building for CMake project 
11183 No, punted to 2.6 already.
Medium+NEWenhancementOE-CoreEvaluate "native" CVE scanning solution 

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 Moving to 2.4M3
Medium+NEWenhancementAutomated Build Testingoe-build-perf-test: monitor system resource utilization 
11394 QA Penang needs to start fresh
Medium+NEWenhancementAutomated Runtime TestingAdd tests to cover devtool handling of various git URL styles 
11517 Due to time constraints and the importance of this enhancement (this check is not as important as other ones, no need to rush into a solution for now), moving it to Future.
Medium+NEWenhancementPatchwork/Patchtestcheck for real sign-off-by names 

(In reply to comment #2) > This worked fine in 2.4 M2. Fails with latest

Sorry - I commented and modified the wrong Bug here
Medium+NEWenhancementOE-CoreEnable simple toolchain switching 
11783 Please provide an update for this. Will it make it into 2.5 M3?
Medium+NEWenhancementOE-CoreShould be able to define Target Proxy settings and have them appear in images 
11899 Perhaps we could add a bitbake-selftest for this, too?
Medium+NEWnormalBitBakebroken 'bitbake --status-only' and 'bitbake -m' 
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 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 

Definition of a manual test case to test this functionality has been pulled out into a separate issue; #12411

Automation of the test case is now the scope of this issue. It's somewhat more complicated because as Brian stated in comment #3 we should perform this testing outside of the AB environment.

Improving coverage of the eSDK by adding further automated test cases for use by testsdk should probably also be a separate bugzilla entry.
Medium+NEWnormalManual TestingQA: Create automated testing to cover ESDK artifacts downloaded from the autobuilder 
11994 So we blame the new qemu.
Medium+NEWnormalGeneral RuntimeGraphical qemu doesn't work over remote X on Fedora 26 

If you enable locked signatures and a signature differs, you always get a taskhash mismatch error even if it's set to warn (or ignore) on mismatch.

A quick example (I picked lighttpd for no particular reason other than it doesn't have too many dependencies):

snip ---------


   lighttpd:do_fetch:deadbeefdeadbeefdeadbeefdeadbeef \

SIGGEN_LOCKEDSIGS_TYPES_qemux86-64 = "t-core2-64"

snip ---------

If you run bitbake lighttpd, this generates the expected warning:

WARNING: The lighttpd:do_fetch sig is computed to be 06afc9089e48717a68a2f911c49fa035, but the sig is locked to deadbeefdeadbeefdeadbeefdeadbeef in SIGGEN_LOCKEDSIGS_t-core2-64

However you also get:

ERROR: lighttpd-1.4.45-r0 do_fetch: Taskhash mismatch 06afc9089e48717a68a2f911c49fa035 versus deadbeefdeadbeefdeadbeefdeadbeef for /home/paul/poky/poky/meta/recipes-extended/lighttpd/ ERROR: Taskhash mismatch 06afc9089e48717a68a2f911c49fa035 versus deadbeefdeadbeefdeadbeefdeadbeef for /home/paul/poky/poky/meta/recipes-extended/lighttpd/

We don't need to see the latter error - in fact it looks as if we're getting it twice - perhaps once from cooker and then again from the worker, I'm not sure.

(This is the underlying cause of bug 11883, but we want the signatures to be unlocked in that case so that can be fixed independently of this).
Medium+NEWnormalBitBakeLocked signature change triggers taskhash mismatch error 
12084 Did a few minutes of digging as I was curious: python-paho-mqtt is using setuptools and the setup_requires argument, where setuptools will use pip to fetch the module if it isn't present. Not sure if setuptools has a way to disable this, we may need to patch it into setuptools-native and then pass a special argument to disable fetching.
Medium+NEWnormalOE-Coredistutils/setuptools recipes may try to fetch code during do_compile 

The following set of actions can be an issue:

1) from a laptop, ssh into a build server and run: $ cd ~/cow $ . ./poky/oe-init-build-env $ bitbake core-image-sato

Wait until the server is into something that takes a long time like building glibc

Then close laptop, or disconnect it from the network.

2) From a terminal on the server itself $ cd ~/cow $ . ./poky/oe-init-build-env $ bitbake core-image-sato

This results in 20 seconds of *no output* !!! Followed by: Reconnecting to bitbake server .... Retrying server connection .... a number of times followed by: ERROR: Unable to connect to bitbake server or start one

This is because the original bitbake server (whose pid is in bitbake.lock) is still merrily building the image. unfortunately, there isn't afaik, a way to reconnect to the running server, nor is it terribly obvious that the reason you can't run another bitbake command is that there is a running server already using that build directory.


Furthermore, Paul pointed out that if you did enable a reconnection, you might need to add a new event (welcome back?) that would fire on reconnection so that the connection didn't look dead in case the server was busy working but had no events to hand out.
Medium+NEWnormalBitBakebitbake resident server reconnect needed ? 

We have seen several issues over the 2.4 cycle where environment variables exported and used by the yocto-autobuilder have polluted the build environment[1][2].

Our build environment should be as pristine as possible to prevent adverse effects on the build system, therefore we should make a concerted effort to further reduce the amount of environment variables we export on the workers.


Medium+NEWenhancementAutoBuilderReduce the number of exported environment variables 

If you type something into devpyshell that should trigger an exception, that exception isn't printed out, e.g:

snip ---------

OE PyShell (PN = lsof)

pydevshell> powjdaowj pydevshell>

snip --------- There's a second or two delay before the prompt returns so I can see an exception is being generated, but it isn't shown.
Medium+NEWnormalOE-CoreExceptions not displayed within devpyshell 
12168 Moving gstreamer bugs to Anuj.
Medium+NEWnormalOE-Coremedia player - must be warned that it is not possible to play MPEG-1 and MP3 formats 

but bitbake linux-yocto does deploy bzImage and the kernel modules into the tmp/deploy/images/<arch>/ directory. bitbake doing this is quite helpful.

But, what if you want to use devtool (likely in the esdk setting) to do a kernel or module build and then do something *other* than build-image.

For instance maybe you want to do a wic cp of the kernel into the boot partition or maybe you want to just copy the new modules to a target and test them quickly.
Medium+NEWnormalOE-Coredevtool build linux-yocto fails to deploy bzImage into tmp/deploy/images/<arch>/bzImage 
12181 I've created bug 12372 to track the progress in the implementation of automated execution of pTest.
Medium+NEWenhancementAutomated Build TestingQA: Archive ptest results in git 

If we insist that a oe/yocto build has always to be for one very specific board than /bin/start_getty enforces this behaviour and I will need to add this bbappend to my meta layer (which is how I have it right now and how it works for me).

do_install_append() {

       sed -i 's/bin\/start_getty/sbin\/getty/' ${D}${sysconfdir}/inittab


The sad thing is, that it worked before the script and the script broke it and it's not very clear to me what this magic script tries to solve.

I found this:

and this: ${base_bindir}/start_getty? 

One of the things you would commonly want to cp into a wic image using wic cp is lib/modules/kernel-version. This would require a recursive copy. e.g.

wic cp modules--4.x.x/ wicimage:/lib/modules/
Medium+NEWenhancementOE-Corewic cp should support recursive copies 
12262 Optional layers are new, and Toaster does not yet how to deal with them.
Medium+NEWnormalToaster[Toaster] Layer details page: optional layers cant be blank when importing a layer 
12337 Moving to Chin Huat.
Medium+NEWnormalEclipse PluginPKG_CONFIG_PATH not read correctly from SDK environment 
12344Medium+NEWnormaleSDKUnable to create derivative SDK within eSDK environment 

Problem: A number of errors and warnings get spewed if you get rid of tmp after the persistent bitbake server is started, and further bitbake commands don't do anything.

Steps to reproduce: export BB_SERVER_TIMEOUT=10000 bitbake core-image-minimal mv tmp tmp-old bitbake core-image-minimal

Result: Errors seen in error.log.

Further 'bitbake core-image-minimal' commands result in the following: [clsulliv@clsulliv build]$ bitbake core-image-minimal NOTE: Reconnecting to bitbake server...

[clsulliv@clsulliv build]$
Medium+NEWnormalBitBakemoving or removing tmp breaks persistent bitbake server 

Steps to reproduce: export BB_SERVER_TIMEOUT=10000 bitbake core-image-minimal ctrl+C before it finishes change something in local.conf (for fun, try changing MACHINE) bitbake core-image-minimal


Parsing is skipped, and lots of task mismatch errors. In the case of changing MACHINE, you will likely get multiple task mismatches for every package built.
Medium+NEWnormalBitBakepersistent bitbake server does not re-parse if previous build was ctrl+C'd 
12383 Indeed. Thanks for catching that Ross.
Medium+NEWnormalOE-Coreqemu inclusion of kernel modules is inconsistent. 

If you run devtool modify on the kernel, run bitbake -c clean, then try to build the kernel again the configuration will be different:

devtool modify virtual/kernel bitbake virtual/kernel cp tmp/work-shared/qemux86-64/kernel-build-artifacts/.config kconfig-good bitbake -c clean virtual/kernel bitbake virtual/kernel diff -udN kconfig-good tmp/work/qemux86_64-poky-linux/linux-yocto/4.12.14+git999-r0/linux-yocto-4.12.14+git999/.config

(The second build of the kernel will almost certainly fail because it will try to generate X.509 certificates and openssl-native isn't in DEPENDS, so the openssl command won't be available to run.)

There is some logic set up in the workspace bbappend for the kernel that sets up the configuration, and I suspect this is where the problem lies - it moves the configuration into place from ${S} to ${B} the first time but the second time around it's not there to move, and you get the default kernel configuration instead.
Medium+NEWnormalOE-Corekernel set up with devtool modify builds with wrong config after cleaning 
12404 wic rm does not currently remove directories, nor does it support the -r flag
Medium+NEWnormalOE-Corewic rm should remove directories and support the -r flag 

I am working with multiple machines, including raspberrypi3 and raspberrypi-cm3. While executing

$ bitbake mc:raspberrypi-cm3:rpi-basic-image mc:raspberrypi3:rpi-basic-image

I encounter issues (FileExists or compilation ones). They appear when bitbake work on the same package for the 2 machines. Since the architecture is the same and the build directory is also the same, there are concurrency errors which don't appear if the 2 tasks are done separately.

I am not aware of the complexity of solving the issue, by detecting when recipes have the same names and when buildirs are also the same, but this would add a lot of value and speed to the multiconfig setup.

I am using OS: Ubuntu 16.04 poky: rocko meta-openembedded: rocko meta-raspberrypi: master


David Bensoussan

Synapticon GmbH
Medium+NEWnormalBitBakeMulticonfig for machines with same architectures 

It seems to be issue of DNF tool. From Yocto 2.3( pyro), the smart tool (rpm manager for YOCTO) is replaced by DNF tool. Earlier, the smart tool was taking it as warning message and removing installation of lib32 rpm in case of conflict in files (from package corei7_32 & corei7_64) happens. But the dnf tool is not handling this issue properly and Yocto build for multilib image is breaking.

Here is error message in details:


Traceback (most recent call last):

 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/cli/", line 64, in main
   return _main(base, args, cli_class, option_parser_class)
 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/cli/", line 99, in _main
   return cli_run(cli, base)
 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/cli/", line 123, in cli_run
   ret = resolving(cli, base)
 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/cli/", line 154, in resolving
 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/cli/", line 238, in do_transaction
   super(BaseCli, self).do_transaction(display)
 File "/home/ilab/Preeti-Work/ApolloLake/rocko-test/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/", line 716, in do_transaction

dnf.exceptions.Error: Transaction check error:

 file /usr/bin/python3.5m-config from install of lib32-python3-core-3.5.3-r1.0.corei7_32 conflicts with file from package python3-core-3.5.3-r1.0.corei7_64
 file /usr/include/gmp.h from install of lib32-libgmp-dev-6.1.2-r0.corei7_32 conflicts with file from package libgmp-dev-6.1.2-r0.corei7_64
 file /usr/share/pkgconfig/xtrans.pc from install of lib32-xtrans-dev-1:1.3.5-r0.corei7_32 conflicts with file from package xtrans-dev-1:1.3.5-r0.corei7_64

Error Summary

2018-01-25T03:51:32Z CRITICAL Error: Transaction check error:

 file /usr/bin/python3.5m-config from install of lib32-python3-core-3.5.3-r1.0.corei7_32 conflicts with file from package python3-core-3.5.3-r1.0.corei7_64
 file /usr/include/gmp.h from install of lib32-libgmp-dev-6.1.2-r0.corei7_32 conflicts with file from package libgmp-dev-6.1.2-r0.corei7_64
file /usr/share/pkgconfig/xtrans.pc from install of lib32-xtrans-dev-1:1.3.5-r0.corei7_32 conflicts with file from package xtrans-dev-1:1.3.5-r0.corei7_64
Medium+NEWcriticalMeta-yoctomultilib/rpm: core-image-sato-sdk do_rootfs: Function failed when installed lib32-glib-2.0 

I'm getting java null pointer exception issue in Windows while configuring sdk for windows using eclipse plugin.

BUILD: 2.4 Eclipse version: oxygen OS: Windows7

Please find crash log in attachment.
Medium+NEWnormalEclipse PluginYocto eclipse plugin java null pointer exception issue in Windows. 
10541 Rather than continuing to push this ahead in time. I'll close this for now. If the upstream centric Eclipse plugin approach reaches a level of maturity where it makes sense to visit this topic again, we can do that.
Medium+RESOLVEDenhancementCROPSUse "new project template" framework to create sample Devtool project 
10543 Not relevant for eclipse-poky.
Medium+RESOLVEDenhancementCROPSuse CDT "new build system" to enable building for Make project 
10545 Not relevant for eclipse-poky.
Medium+RESOLVEDenhancementCROPSuse CDT "new build system" to enable building for Automake project 
10546 Rather than continuing to push this ahead in time. I'll close this for now. If the upstream centric Eclipse plugin approach reaches a level of maturity where it makes sense to visit this topic again, we can do that.
Medium+RESOLVEDenhancementCROPSuse CDT "new build system" to enable building for Devtool project 
10548 Current plan is to stick with eclipse-poky.
Medium+RESOLVEDenhancementCROPSEclipse CROPS plugin support for debugging via gdb to QEMU 
10549 Current plan is to stick with eclipse-poky.
Medium+RESOLVEDenhancementCROPSEclipse CROPS plugin support for debugging via gdb to hardware target 
10556 handled by upstream docker tooling.
Medium+RESOLVEDenhancementCROPSDocker tooling support to manipulate CROPS containers from the Eclipse CROPS plugin 
10942*Medium+RESOLVEDnormalOE-Corelinux-firmware-ath9k fw ver 1.4.0 in main package 

Merged the libva change to oe-core:

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

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

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 

Patchset posted for review:

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 

(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 

Hi Jair,

I had verified that flatpak bugzilla had been resolved and it included basic tests.

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 
11209 Thanks - setting to RESOLVED and putting the doc flag to 'done'.
Medium+RESOLVEDnormalOE-CoreRPM package feed signing is currently not supported 
11295 All 3 patches have been merged into master.
Medium+RESOLVEDnormalOE-Coredo_image_wic: fails when rm_work is active 

This fix is deployed in production:

Medium+RESOLVEDenhancementPatchwork/Patchtestpatchwork: Improve Series naming when no cover letter is provided 
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 

Patchset posted for review (only patches 2 to 5 are relevant):
Medium+RESOLVEDenhancementOE-CoreTrim down LSB support 
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 

Merged in oe-core master in:

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 
11381*Medium+RESOLVEDenhancementOE-Coreoe-build-perf-report: show task summary 
11382*Medium+RESOLVEDenhancementOE-Coreoe-build-perf-report: display changes in build content 

This was implemented here (and some of the surrounding commits):
Medium+RESOLVEDenhancementBitBaketinfoil: enable running tasks with dependencies 
11414*Medium+RESOLVEDnormalOE-Coredevtool breaks if an invalid image name is passed to build-image 

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/ as well as running oe-selftests.

2) builds the same REFKIT_CI_BUILD_TARGETS from meta-refkit/conf/distro/include/ with the poky distro
Medium+RESOLVEDenhancementAutoBuilderSupport building intel-iot-refkit with yocto-autobuilder 
11447*Medium+RESOLVEDenhancementBSPsConfigurability to boot from UEFI boot partition or direct boot without bootloader 

Closed as this has already been merged together with meta-configuration as discussed.
Medium+RESOLVEDenhancementOE-CoreBring in Juci from openWRT as an on target network configurator 
11454*Medium+RESOLVEDenhancementAutoBuilderRationalise autobuilder configuration 
11457*Medium+RESOLVEDminorBitBakebb.plain() isn't plain anymore 
11483*Medium+RESOLVEDenhancementAutomated Runtime TestingAutomate testcases for package management 
11488*Medium+RESOLVEDenhancementAutomated Runtime TestingTestimage: Add tests for ipk/opkg like dnf/rpm ones 
11518*Medium+RESOLVEDenhancementPatchwork/PatchtestUpstream-Status Submitted and Inappropriate check for where/reason info 

Merged into master:

All: 5f6945f buildhistory.bbclass: add ptest 8a5d3bf testimage.bbclass: update comments 0cdabb7 buildhistory.bbclass: print message when no commit 9fd9fae core/target/ replace decode errors f4d4bfd utils/ fix section check 2070496 runtime/cases/ rename it to 86e062d runtime/cases/ add skip status f1c8488 oeqa/utils/ add skip status

dccf0efb runtime/cases/ revive it
Medium+RESOLVEDenhancementOE-CoreAdd regression check for ptest 
11548 This is too vague and ongoing to be a bugzilla entry, so I'm closing this.
Medium+RESOLVEDenhancementOE-CoreReduce local Pending patches 
11574 Fixed in oe-core ad915e9baa04c73981c4795a97da95cea40b50c2.
Medium+RESOLVEDnormalOE-CoreERROR: kconfig-frontends- do_compile: Function failed: 

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: '' 

The patch was sent to the mailing list. It does what it is supposed to do.

The final verdict regarding inclusion has not been done yet. For now, I am closing this as RESOLVED/WORKSFORME. The ticket can be re-opened if needed.
Medium+RESOLVEDenhancementOE-Coreadd "fence flag" to cross toolchain 
11608 Ubuntu17.04 has been added on GDC/AB as supported distro
Medium+RESOLVEDnormalAutomated Build Testingdistro-testing: Add ubuntu 17.04 to supported distros 

(In reply to comment #4) > I'm fairly confident this will fix the original issue as well. > > > commit 01266607aa4d3d4905d2c07b4bdf46ea9f5372f0 > Author: Jussi Kukkonen <> > 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 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 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 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 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 This case is covered by other bug.
Medium+RESOLVEDnormalAutomated Build Testingoe-selftest does not clean-up properly the build/conf metadata 
11700 After the patch was merged, the problem was not observed anymore for several weeks. I am closing this as RESOLVED/FIXED. Should I run into the problem again, I will re-open the bug.
Medium+RESOLVEDnormalOE-Coretcl_8.6.6: non-deterministic generation 
11702 The problem seems to be gone, even though I can't find the commit with fixed. Closing as obsolete.
Medium+RESOLVEDnormalAutomated Build Testingoe-selftest fails if local.conf doesn't end with a newline 
11705*Medium+RESOLVEDnormalOE-Coregobject-introspection_1.50.0 contains various references to the host build system 
11709 both patchsets have been merged to poky master.
Medium+RESOLVEDmajorOE-CoreSupport EFI System partition with 4K FAT clusters 

Fix merged to master (requires a number of the patches around it, too many to list here):
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 Still no joy on reproducing it, I will close this for now, if the issue re-appears, then this or a new bug can be opened.
Medium+RESOLVEDnormalBSPsIntel AC 7260 Bluetooth interface stops responding after disabling Bluetooth 
11717 commit eea5cb317137d71ad0cab954d2c9ad2069580b6f
Medium+RESOLVEDnormalToasterlarge package set causes 'too many SQL variables' error 
11741 Merged in oe-core b10ecbab3acd46e48d36910e30544e9f5f08d6d7.
Medium+RESOLVEDnormalOE-Coresdk: generates empty manifests when doing do_populate_sdk 
11748 The real problem is DEPLOY_DIR_IMAGE is exported somewhere, runqemu doesn't know whether qemuarm is a MACHINE or not, it needs guess. And then it will look DEPLOY_DIR_IMAGE, so you need unset DEPLOY_DIR_IMAGE to test it.
Medium+RESOLVEDnormalAutomated Build TestingMachine given to runqemu util is overwritten 
11757 I believe this has been addressed sufficiently well.
Medium+RESOLVEDnormalIoT Reference OS Kitselftests: do not touch existing build artifacts 
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 
11809 Fixed in oe-core 6f6a2b5ff7ec23bd3782f0c3521f3576101cbc9d.
Medium+RESOLVEDmajorOE-CorePossible race in xcb recipes 
11818*Medium+RESOLVEDnormalAutomated Build TestingAllow oe-selftest to work with BB_SERVER_TIMEOUT 

There was a need for a second patch, the same idea as the first but targeted for another code area. Patch now in master:
Medium+RESOLVEDnormalOE-Corenightly-oe-selftest 2.4_M1-574-g2ec756257e failed 
11823 Closing as a duplicate of 11745.
Medium+RESOLVEDnormalIoT Reference OS KitAB: test intel-iot-refkit with the right submodules 

(In reply to comment #2) > I believe this might be a config error, since for what I can see, you are > trying to run 64 bit libraries on a 32 bit machine (qemux86), the other way > around would be ok though.

My bad (sorry for wasting your time), I though I was testing with a 64bit machine, but it was not the case, it was a 32bit, so init cannot be executed due to this reason.
Medium+RESOLVEDnormalOE-Coreimage including multilib:lib64 python3-dev package does not reach login 

The bug 11898 has been accepted and is being worked on by bitbake-devel.

I am formally marking this as a duplicate.
Medium+RESOLVEDnormalToasterToaster timeout for bitbake server 
11836 The logs are gone for this build and the code area has also been reworked with 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 nightly-checkuri is no longer triggered by nightly and has its own weekly trigger on the AB cluster.
Medium+RESOLVEDnormalAutoBuilderMove nightly-checkuri out of nightly and automatically trigger for master and maintained branches on a weekly basis 

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 Plugins now published for M2 rc3
Medium+RESOLVEDnormalAutoBuilder[Autobuilder] Eclipse-plugin files are not found in autobuilder 

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 

(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 
11879*Medium+RESOLVEDnormalBSPsTestimage: multiple "uvesafb" errors present in log in minnowmax on genericx86/genericx86-64 
11896 That seems reasonable, yes.
Medium+RESOLVEDnormalOE-Corecheckpkg needs to have exemption in metadata 
11911 Thank you Josh! I've updated the Note here: and marking this to RESOLVED/Done
Medium+RESOLVEDnormalAutomated Runtime Testingconnection lost between host-target on a nightly-arm-lsb AB build 
11917Medium+RESOLVEDnormalOE-Core(buildoptions) Failure on test_arch_work_dir and layer_with_out_git_dir 
11923 did add the browse button as a network connection test to the documentation in a separate doc bug
Medium+RESOLVEDnormalEclipse Plugin[Eclipse] Failed to debug a Project in Eclipse and displays error: java.lang.NullPointerException 
11929 I think we'll call this done for the moment, and if there are other behavioural improvements we can make we'll deal with them separately.
Medium+RESOLVEDnormalBitBakepreparing tinfoil twice with config_only=False is failing 
11935Medium+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 
11943 Merged in oe-core f78478f0d0379ea02727c81ad2455207c70d140b.
Medium+RESOLVEDenhancementOE-Coreoe-pkgdata-util should support RPROVIDES 

The autobuilder configurations were fixed to have these values set, and thus the patch got merged to master:
Medium+RESOLVEDenhancementOE-Coredevtool upgrade needs to have some git configs set to get correct results 
11949 I have the fix available in
Medium+RESOLVEDmajorIoT Reference OS Kitqemu-2.10-rc2 build error (patch failed) 
11952 fixes the "error" messages and makes them warnings. Bug 12001 tracks the process not appearing in 60s issue.
Medium+RESOLVEDnormalOE-Corerunqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable 

I believe this failure was caused by a large change in disk usage from another build process on the worker whilst this test was running. In general this doesn't happen and it was a case of unfortunate timing.

The infrstrusture setup with multiple workers running in parallel on machines means this kind of thing would be very hard to fix without for example separate partitions for the different workers. Closing as WONTFIX as a one off issue. Will reconsider if we started seeing this regularly.
Medium+RESOLVEDnormalOE-Corenightly-oe-selftest failed: FAIL: test_stoptask_behavior (buildoptions.DiskMonTest) 
11967*Medium+RESOLVEDnormalOE-Corecreating root file systems using 'elf' failed with error convert_magic 00000000 != a5a5a5a5 

Thanks for the quick reviews! I am setting to RESOLVED and marking the docs flag as done.

Medium+RESOLVEDnormalGeneral Docsremove oe-init-build-env-memres from documentation 

Setting to RESOLVED and marking Doc flag "done."


Medium+RESOLVEDnormalDevelopment ManualEclipse section has some issues 
11972*Medium+RESOLVEDnormalOE-Coredevtool upgrade+finish failed to drop patch it should have 
11974*Medium+RESOLVEDnormalAutoBuilderMake wiki logging more resilient to network issues 

(In reply to comment #1) > Please visit > > and tell me if this display format suits your needs.

Yes, is the display format that we need.
Medium+RESOLVEDnormalAutoBuilderShow the full name of artifacts published on Yocto AB ( 
11978*Medium+RESOLVEDnormalOE-Corepython-native is being built without IPV6 enabled 
12001 looks like the closed box didn't stick.... see previous comment for commit and reason.
Medium+RESOLVEDnormalAutomated Build TestingQEMU hangs and tests are aborted 
12017 After Richard comments on triage I double checked and there is problem with gcc-5 dependencies on my host, so it was still using 4.9 by default and hence the error appeared, I just correct the dependencies the installation goes well and the artifact can be used correctly even if SDK_GCC_VER=, So setting this as invalid.
Medium+RESOLVEDnormalAutoBuildersome published toolchain artifacts for eSDK have SDK_GCC_VER empty 
12022*Medium+RESOLVEDnormalAutomated Build Testingsigning.Signing.test_signing_packages hangs on 

We're going to assume this is fixed as:

  • master doesn't have 4.9
  • rocko updated to a new 4.9 stable version which may have fixed it.
We can reopen this if we see it again with rocko.
Medium+RESOLVEDnormalAutomated Runtime Testingbacktrace in dmesg on qemuppc with 4.9 
12038 Since the material has been written, sent, and accepted by Scott, I am going to close this case.
Medium+RESOLVEDnormalToasterUpdate Toaster manual for YP-2.4 
12047*Medium+RESOLVEDnormalAutoBuilderRun yocto-compat-layer scripts as part of AB runs 
12056 commit 7dce5875eae80425d1528a914c6b1f165fbb524b
Medium+RESOLVEDnormalToastertoaster: catch early build and server exceptions 
12057 Fixed in oe-core 42e0de37d18f072dc5dcf5dc45cb441e4c2110d8.
Medium+RESOLVEDnormalOE-CorePackage license wrong in RPM for ${PN} when ${LICENSE_${PN}} != ${LICENSE} 
12088 Per Todor, mark as resolved. --dependency works for him.
Medium+RESOLVEDnormalOE-Coreyocto-compat-layer does not resolve layer dependencies 
12108 Fixed in oe-core bdd20c296048937737da0f10bd1a3b63843c5bf4.
Medium+RESOLVEDnormalOE-Corego-runtime does not build for mips32r2 
12111*Medium+RESOLVEDmajorMeta-yoctoGRUB2 menuconfig is not getting generated for genericx86 ISO image 
12127 and the preceding 8 commits address this issue. Appears that a python bug was fixed in 3.6 which started exposing these messages. in particular.
Medium+RESOLVEDnormalAutomated Build TestingDuplicate log observed on oe-selftest runs 
12132Medium+RESOLVEDnormalKernelRunning diffconfig task from BitBake returns error 
12161 OK thanks. I see the changes form 2 min ago;)
Medium+RESOLVEDnormalMeta-yoctobitbake linux-yocto-custom -c diffconfig ERROR, but creates fragment;) 
12162*Medium+RESOLVEDnormalMeta-yoctoERROR: do_kernel_metadata: Could not locate BSP definition 
12163*Medium+RESOLVEDnormalBitBakeObtuse error if build dir != cwd 
12167*Medium+RESOLVEDenhancementOE-CoreRemove yocto-layer now that bitbake-layers has been merged 
12173*Medium+RESOLVEDnormalOE-Corewic cp,rm,ls of a partition e.g. ic ls myimage.wic:1/ fails if host mtools are not installed 
12177*Medium+RESOLVEDenhancementeSDKSupport wic in the esdk 
12191 looks good to me
Medium+RESOLVEDnormalDevelopment Manualneed to document new wic features wic cp, wic rm, and wic ls. 

The openbios issue tracker is not accessible:

So I report it in github:

And send Email to the openbios mailing list:
Medium+RESOLVEDnormalOE-Coreqemuppc: Cannot manage 'undefined' PCI device type '<NULL>' 
12210*Medium+RESOLVEDnormalOE-Corepopulate_sdk_ext failed when multilib 
12218 This issue already being tracked in 12185
Medium+RESOLVEDnormalOE-Coredevtool modify failing in fedora 26 
12219*Medium+RESOLVEDmajorOE-Corenothing provides linux-firmware-imx-sdma-license 

I have not seen this in last 6-8 weeks, so I am going to close this as RESOLVED/OBSOLETE. It may have something to do with gawk being upgraded to 4.2.

Will re-open if encountered again.
Medium+RESOLVEDnormalOE-Coreinconsistent .gnu_debuglink 
12238 Patches for both already submitted to oe-core list.

commit b656fd9267b1f36d46ca20a1c0bcfaedbf7df438 Author: Chen Qi <> Date: Fri Oct 27 17:43:51 2017 +0800

   gcc: fix miscompilation on mips64
   We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
   The output of the command is like `systemctl show <xxx>', which is incorrect.
   This patch is from gcc bugzilla's attachment.
   The patch hasn't been merged into gcc. But it does solve the above problem.
   (From OE-Core rev: 3717c76eb24217c14a22f72fdd8732923729dee8)
   Signed-off-by: Chen Qi <>
   Signed-off-by: Ross Burton <>
   Signed-off-by: Richard Purdie <>

commit cd803651751fec224c78509743e10aea79a941de Author: Chen Qi <> Date: Fri Oct 27 17:43:50 2017 +0800

   systemd: remove useless options for mips4
   Looking back the history, we had problem with systemd on qemumips64
   which is also related to compilation flags. We solved that by using
   tweaking FULL_OPTIMIZATION for mips64 to have "-fno-tree-switch-conversion
   Now systemd has been upgraded to 234, and we don't have the above problem
   any more, thus removing these flags.
   (From OE-Core rev: 713761d23df24ad1b52e08bd2d2dc688393bef5b)
   Signed-off-by: Chen Qi <>
   Signed-off-by: Ross Burton <>
Signed-off-by: Richard Purdie <>
Medium+RESOLVEDnormalGeneral Runtime`systemctl status' command doesn't behave correctly on qemumips64 
12270 Thanks, I will close it.
Medium+RESOLVEDnormalOE-Core[rocko] [Test Case 1534] runqemu fails using esdk in nfs mode 
12285*Medium+RESOLVEDnormaleSDKdevtool: upgrade: fails with a TypeError 
12318*Medium+RESOLVEDnormalOE-Coredevtool upgrade+finish not deleting old files 

I have now fixed this in master (for 2.5) - not only do we avoid the traceback, but we also now search the recipe cache as well in case the item being searched for has not been built:
Medium+RESOLVEDnormaleSDKdevtool search produces tracebacks and not returning the search results 

I've implemented a fix for this in CreateAutoConf and tested it on the cluster with a synthetic 2.4.2 release.

Having downloaded the generated eSDK I can confirm that I'm no longer able to reproduce the issue.
Medium+RESOLVEDnormalAutoBuilderdevtool sdk-install unable to add component 

(In reply to comment #2) > Jackie, as you stated, mips32r2 is the default tune so unless we can fix > this build, we'll just close the bug as 'no fix planned'. > It would be good to do an oe-core world build -k to record how many > packakges do not compile. If it's only one, then we could exclude it from > the world builds for _mips.

mozjs is the only one that failed, so close it as "won't fix"
Medium+RESOLVEDnormalOther YP failed with DEFAULTTUNE "mips" 

Please consider to backport this fix for pyro.

Pyro is having the same issue:

--- snip for neon --- ERROR: neon-0.30.2-r0 do_checkuri: Fetcher failure for URL: ''. URL doesn't work ERROR: neon-0.30.2-r0 do_checkuri: Function failed: do_checkuri ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-checkuri/build/build/tmp/work/i586-poky-linux/neon/0.30.2-r0/temp/log.do_checkuri.20693 NOTE: recipe neon-0.30.2-r0: task do_checkuri: Failed ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-checkuri/build/meta/recipes-support/neon/ failed with exit code '1' ---

--- snip for neon-native --- ERROR: neon-native-0.30.2-r0 do_checkuri: Fetcher failure for URL: ''. URL doesn't work ERROR: neon-native-0.30.2-r0 do_checkuri: Function failed: do_checkuri ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-checkuri/build/build/tmp/work/x86_64-linux/neon-native/0.30.2-r0/temp/log.do_checkuri.19684 NOTE: recipe neon-native-0.30.2-r0: task do_checkuri: Failed ERROR: Task (virtual:native:/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-checkuri/build/meta/recipes-support/neon/ failed with exit code '1'

Medium+RESOLVEDnormalOE-CoreFetcher failure for URL: "" 
12365*Medium+RESOLVEDnormalOE-Coreglibc-initial do_fetch failed if rm_work is enabled 
12464 Fixed in bitbake ceaca281cafa662aa2385b95641bce309dce843d.
Medium+RESOLVEDminorBitBakeFailure when get_srcrev runs from fakeroot tasks 
12477*Medium+RESOLVEDnormalOE-CorePossible bad interaction between shared-state uninative and gobject-introspection[6]
10368Medium+VERIFIEDenhancementBitBakeQA Bitbake: create setup and basic unit tests for event module 
11434 Bug have been resolved and verified
Medium+VERIFIEDenhancementOE-Coredevtool edit-recipe/find-recipe enhancements 
11609 All seems to be working
Medium+VERIFIEDenhancementAutoBuilderAdd an Ubuntu 17.04 builder to the YP AB cluster 
11680*Medium+VERIFIEDenhancementAutoBuilderEnable AB to build WIC images for qemux86 and qemux86-64 machines and publish them 

Verified with 2.4 M2 rc2.

Git rev: master/8e15e9b6e478f6368034519b2a8fd3c7ea71d23b
Medium+VERIFIEDnormalGeneral RuntimeCan not run QEMU machines under UNFS 

Verified with 2.4 RC1 build.

Git rev: master/592c3449697ce39bf07864fafd7f0a61ca230561
Medium+VERIFIEDnormalMeta-yoctocrosstap doesn't work on 2.4 M3 RC1 

Verified with 2.4 RC1 build.

Git rev: master/592c3449697ce39bf07864fafd7f0a61ca230561
Medium+VERIFIEDnormalMeta-yoctoUpdate yocto-bsp script for kernel 4.12 
12013 Verified.
Medium+VERIFIEDnormalBSPsPoky tiny image ask for password 

the images able to boot with of Meta-Intel 2.4 rc2

BUILD: 2.4_rc2_meta-intel-f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284 ENVIRONMENTS: corei7-64_Joule, corei7-64_NUC, intel-core2-32Minnowmax32, corei7-64_Minnowmax64, intel-quark_Galileo

STEPS TO REPRODUCE: 1. Download corresponding images for devices: minowmax32/64, NUC, joule and galileo from:

2. Burn each image on to a USB 3. Try to boot each of the images from their corresponding platform devices (minowmax 32/64, NUC, joule, galileo).

EXPECTED OUTCOME: Images can boot without problem.

ACTUAL OUTCOME: Images can boot without problem.
Medium+VERIFIEDnormalBSPsUnable to boot with some of Meta-Intel 2.4 M3 rc1 images 

thas correct eclipse oxygen is updated (4.7.0)
Medium+VERIFIEDnormalEclipse PluginUpdate to Eclipse Oxygen (4.7.0) release 
12287 Duplicate of 9525.
Medium+VERIFIEDnormalBSPscan not install the image to a USB, SD or hard drive(core-image-sato-sdk-intel-core2-32.hddimg) 
11985 OK, thanks! I'll add that to RefKit through a bbappend...
UndecidedNEWnormalIoT Reference OS KitRefkit wayland image: failed to return into virtual terminal after terminate wayland (ctrl+alt+backspace) 

(In reply to comment #2) > As this defect happen intermediately (happen more often on MinnowMax). When > this defect was detected (click on weston-terminal icon does not fire up new > terminal), try to find out which virtual terminal was used at the bootup to > launch weston (eg. virtual terminal #2).

Just to make sure, do you really only have a single weston running at this point (the one started by the init manager), and the terminal just doesn't appear? Or do you already have another weston started somehow?

> Switch to different virtual terminal by the key sequence CTL-ALT-F<n> where > n is 1-6. For example CTL-ALT-F1 to virtual terminal and then execute > weston-launch to fire up a weston-compositor. Try to execute weston-launch > on every virtual terminal.

So you just call "weston-launch"? I'm a little surprised if it works and XDG_RUNTIME_DIR is set... Can you check what the values of that env var is in the various vt's or mention if you set it yourself? Are you running as root or multiple accounts?

> When you use weston-launch to fire up a weston-compositor, by default it is > without any weston terminal. But you will notice one of the > weston-compositor that you fire up contains 1 or more weston terminal. In > fact if you go back to the virtual terminal used at the bootup (eg. virtual > terminal #2), click on the weston-terminal icon, it will fire up new weston > terminal at another virtual terminal (eg. virtual terminal #1). > > To debug, execute "export" at each weston terminal and observe the > "WAYLAND_DISPLAY". I notice 2 of the virtual terminal shared the same > "WAYLAND_DISPLAY" value. > > Please let me know if you can reproduce this.

No, I couldn't (I'm not on your hardware and am running poky so not really the same thing). In any case the new westons get a new WAYLAND_DISPLAY.
UndecidedNEWnormalIoT Reference OS KitRefkit wayland image: click on weston-terminal icon does not fire up new terminal 

Ahh, yes twm is from meta-oe:

It is of course not intended for any final product, but it is there only so that X11 is functional to some extent.

This is only thing RefKit has regarding X11:

Intention is to keep X11 to as bare minimum as possible. Since final products based on RefKit would likely either use meta-qt5 (embedded) or some proprietary graphics framework in a way that there is only single application active/possible, we want to minimize amount/size of things that wouldn't be used anyway.
UndecidedNEWnormalIoT Reference OS KitRefkit X11 image: select the "Exit" in twm does not terminate X11 fully 
12002 I wonder what is trying to use 4.1 kernel, it is ancient. We support linux-intel-4.9 from meta-intel BSP and I have also successfully tested linux-yocto-4.10... (and also -rt variants of both)
UndecidedNEWnormalIoT Reference OS Kitlinux-yocto-* recipes are missing 

Below find steps to run test case, 1)Start Toaster.

2)Click on new project button.

3)Enter a project name, select a release and click on create project or select an existing project.

4)Build a image task (ex: core-image-minimal:clean) and wait until build finish.

5)Click on rebuild button from all build page.

6)Click on the build and verify if the number of tasks executed = 1.

7)From project builds page click on run again button.

8)Click on the build and verify if the number of tasks executed = 1.

when running step 5, it is compiled again, and tasks executed =1 is not getting as per step 6.

getting same issue in step 8 as well.
UndecidedNEWnormalToaster[2.4.2 rc2] Run again button from all builds page must run the specified task 

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

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

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 

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 The elfutils patch was merged to meta-gpl2 master today.
UndecidedRESOLVEDnormalOE-CoreERROR: elfutils-0.148-r11 do_compile: oe_runmake failed 
11577 Oops, filed the same bug twice.
UndecidedRESOLVEDnormalOE-CoreERROR: elfutils-0.148-r11 do_compile: oe_runmake failed 
11617 The patches have been removed from MUT.
UndecidedRESOLVEDnormalOE-Core[wic] test_wic_rm failed 

$ git clone 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 MUT-only, patch has been dropped and the submitter told.
UndecidedRESOLVEDnormalOE-Corecore-image-sato fails dnf testimage run 
11625 Transient failure.
UndecidedRESOLVEDnormalOther YP Layersdropbear fails checkuri 
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 Already yanked from MUT.
UndecidedRESOLVEDnormalOE-Coretest_integrity_compressed_images oe-selftest failed 
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 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 
Warnings were generated during the execution of function
  1. Report truncated - count greater than max allowed 501 > 500
Personal tools