nyuuzyou/wikis huggingface dataset:
How to Build Target Application in the Host Machine

=== Build target app in host machine ===
If you want to build your target application in host machine just by command line, you can refer to the following example:
==== 1. Create a file, named setup-cross-environment ====
This file can be got by "bitbake meta-ide-support", or you can refer to the following as an example.
You should modify "/sda1/poky-20100903/build-qemuppc-gcc" to your own poky build path, besides you should modify the sysroot path to fit your own cross architecture. The example is for powerpc.
 export PATH=/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/i686-linux/usr/bin/ppc603e-poky-linux:/sda1/poky-20100903/build-
 qemuppc-gcc/tmp/sysroots/ppc603e-poky-linux/usr/bin/crossscripts:/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/i686-
 linux/usr/sbin:/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/i686-linux/usr/bin:/sda1/poky-20100903/build-qemuppc-
 gcc/tmp/sysroots/i686-linux/sbin:/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/i686-
 linux//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 
 export PKG_CONFIG_SYSROOT_DIR=/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/ppc603e-poky-linux
 export PKG_CONFIG_PATH=/sda1/poky-20100903/build-qemuppc-gcc/tmp/sysroots/ppc603e-poky-linux/usr/lib/pkgconfig
 export CONFIG_SITE="/sda1/poky-20100903/meta/site/endian-little /sda1/poky-20100903/meta/site/common-glibc /sda1/poky-
 20100903/meta/site/ix86-common /sda1/poky-20100903/meta/site/common"
 export CC=powerpc-poky-linux-gcc
 export CXX=powerpc-poky-linux-g++
 export CONFIGURE_FLAGS="--target=powerpc-poky-linux --host=powerpc-poky-linux --build=i686-linux"
==== 2. Source the file ====
 # source setup-cross-environment
==== 3. Configure the target application ====
If your target application is autotool based, you should run configure like:
 # ./configure --target=powerpc-poky-linux --host=powerpc-poky-linux --build=i686-linux
==== 4. Build the target application ====
 # make
==== 5. Copy the application binary into target system ====
How to delete information from the Toaster database

Category:Toaster
By default, Toaster stores all build data in a toaster.sqlite database file located in the Build Directory.
You can delete builds from the Toaster database using two bespoke commands (buildslist and builddelete) added to /poky/bitbake/lib/toaster/manage.py
== Follow these steps to delete a build ==
1. Identify the build: Run the following command from your Build Directory to display a user-readable, tabbed list of build IDs and identification information:
 $ python ../bitbake/lib/toaster/manage.py buildslist
2. Delete a specific build: Using the build ID displayed in the previous step, run the following command to delete a specific build:
 $ python ../bitbake/lib/toaster/manage.py builddelete <build_id>
The build and all related information is deleted from the Toaster database. The deletion operation traverses the ForeignKey relationships recursively.
When using the buildslist and builddelete commands, you need to consider the following:
* For default configurations, your working directory must be the Build Directory. Using these command from the Build Directory allows Toaster to find the toaster.sqlite file, which is located in the Build Directory.
* For other database configurations, it is possible that you can use these commands from a directory other than the Build directory. To do so, the toastermain/settings.py file must be configured to point to the correct database backend.
It is recommended to always call manage.py from the Build Directory.
How to support permission management in Build Mode for Toaster

Category:Toaster
On the mailing list Bian Naimeng asked how to support user authentication so that there is some control of who can start builds.
Based on her mailing list comments, she successfully set up Toaster to run under Apache and used the apache-basic-authentication to control access. The instructions for running toaster under apache are located in the Toaster Manual and the instructions for connecting the apache-basic-authentication are located at this site: .
Thanks/credit to Bian!
How to turn on Poky Audio on Netbook

On HP Mini netbook, we found the sound was always muted, and the hot key [F11] could not enable it. 
Here are some command lines to enable the audio and adjust the volumn.
# amixer set Master on // Turn on the audio device
# amixer set Master NUM // To adjust the main volumn, between 0 and 64
# amixer set Speaker on // Turn on the speaker
# amixer set Speaker NUM // To adjust the speaker volumn, betwee 0 and 64
# amixer set Headphone on // Turn on the headphone
# amixer set Headphone NUM // To adjust the headphone volumn, betwee 0 and 64
IRC Bug Day logs

= Yocto Project IRC Bug Scrub = 
== Introduction ==
IRC Bug Sessions are meant as a way to assign new defects, get status updates on existing ones and close fixed defects. Our process for this is in flux but here is where you can get the logs and dates for all of our defect meetings. Please join the team in fixing defects and getting our bug count lower. sgw or pidge will be the "bug caller" during these sessions.
===Master Stabilization Cycle Bug Days===
Thursday February 17th @ 07:00 GMT / Thurs 23:00 PST / Fri 18th 15:00 China Feb17th IRC LOG 
Tuesday February 22nd @ 17:30 GMT / Tue 09:30 PST / Wed 23rd 01:30 China Feb22th IRC LOG 
Thursday February 24th @ 07:00 GMT / Thurs 24th 23:00 PST / Fri 25th 15:00 China Feb24th IRC LOG
===Release Candidate Validation/Verification Bug Days===
Tuesday March 1st 22nd @ 17:30 GMT / Tue 09:30 PST / Wed 2nd 01:30 China 
Thursday March 3rd 17th @ 07:00 GMT / Thurs 23:00 PST / Fri 4th 15:00 China 
Tuesday March 8th 22nd @ 17:30 GMT / Tue 09:30 PST / Wed 9th 01:30 China 
Thursday March 10th 17th @ 07:00 GMT / Thurs 23:00 PST / Fri 11th 15:00 China 
Tuesday March 15th 22nd @ 17:30 GMT / Tue 09:30 PST / Wed 16th 01:30 China 
Thursday March 17th 17th @ 07:00 GMT / Thurs 23:00 PST / Fri 18th 15:00 China
Image Recipes

This page describes the stock image recipes that come with the Yocto Project. Also see the Yocto documentation.
== core-image-minimal ==
The minimal recipe provides an image with the least number of packages to be a bootable image for a given platform (MACHINE) from a stock Yocto Project distribution. It is not necessarily the smallest image that can be created, as many size reductions can be made with kernel changes, etc. When first starting a project, this is the fastest complete build, and it is also a good place to start to create a custom image.
The minimal image includes these features:
== core-image-base ==
== core-image-base ==
== core-image-sato ==
== core-image-sato-dev ==
== core-image-lsb ==
Installer Scope

A simple installer for GRUB and SYSLINUX boot loaders currently exists in the oe-core layer. The installer has a number of limitations and specific requirements that developers often encounter. This page helps define the scope of the installer such that the Yocto Project Team can better triage bugs filed against the installer.
== Requirements == 
Following are requirements that this simple boot loader must have:
* Must work with boot loaders other than GRUB and SYSLINUX.
* Must have the ability to use UUID from the initial RAM disk.
* The root filesystem contains installer scripts for both basic installs and EFI installs.
* Must contain either an msdos or gpt basic partition. The Extensible Firmware Interface (EFI) creates two parts for the basic partition: system and root. The root filesystem is loop mounted and copied from to the root partition. The partition has magic for both the boot loader and the Master Boot Record (MBR).
* The installer must have minimal user interaction required to install it to disk. A possible scenario is to have the installer selectable from a list.
* Must be able to be installed on target hardware to facilitate automated QA testing.
* The root filesystem contains plugin architecture to facilitate installation of other packages such as ptest.
* The root filesystem partitioning exists for system, rootfs, and swap.
* Sata vs. USB: initramdisk enables UUID and udev rules apply. (We should check to see what Wind River does.)
* Live Image -> cpio root / kernel/ initramfs.
== Restrictions ==
The installer does not support multiple kernels.
== Known Issues ==
Currently, the installer has a race condition with Sata versus USB drives (sda vs sdb when booting from USB).
IoT Ref Kit 2.3 Planning

== RefKit 17.04 / YP 2.3 M3 Enhancements==
== RefKit 17.04 / YP 2.3 M3 Bugs==
== RefKit 17.05 / YP 2.3 M4 Enhancements==
== RefKit 17.05 / YP 2.3 M4 Bugs==
IoT Ref Kit 2.4 Planning

== YP 2.4 Enhancements==
== YP 2.4 Bugs==
== RefKit 17.07 / YP 2.4 M1 Enhancements==
== RefKit 17.07 / YP 2.4 M1 Bugs==
== RefKit 17.08 / YP 2.4 M2 Enhancements==
== RefKit 17.08 / YP 2.4 M2 Bugs==
== YP 2.4 M3 Enhancements==
== YP 2.4 M3 Bugs==
== YP 2.4 M4 Enhancements==
== YP 2.4 M4 Bugs==
IoT Ref Kit Bug Triage

Editing Bug Triage
Bold textItalic textInternal linkExternal link (remember http:// prefix)Level 2 headlineEmbedded fileFile linkIgnore wiki formattingYour signature with timestampHorizontal line (use sparingly)
= Goal =
The output of the bug IoT Ref Kit Bug triage meeting should be that all bugs have an owner, a target milestone, and a priority.
Prior to the meeting, each Product Owner should review their Weekly New and High Bugs and be ready with any opens. An example open would be a bug that may need to change Products.
= Roles =
* Call facilitator: Stephen K. Jolley (stephen.k.jolley@intel.com)
** Ensure we keep to the agenda, don't rathole on bug resolution, and stay within our time block.
* Team Leads should pre-triage bugs for their areas of responsibility. Some guidelines on what they should/shouldn't do are:
** a) Pre-triage should happen in the presence of the appropriate team lead,
** b) The bugs being pre-triaged should be the responsibility of the team in question.
** c) The pre-triage team should be confident when dis-positioning the bugs, taking into account the individual's workload.
** d) If the bug raises any doubt or needs information prior, defer it to the main bug triage team.
** e) To insure a bug is triaged by the main bug triage team; set its priority to Undecided.
= Agenda =
* Review Queries
** State number, title, and owner
** Owner makes any modifications
** Assign owner, target milestone, and priority.
* Opens
** Collect opens
** Discuss opens
= Bug Criteria =
* Priority-Severity
** High: Two Week
** Medium+: Milestone
** Medium: Nice to have for milestone, should have for release
** Low: Nice to have, but no urgency
= Bug Product Searches =
* Bug Product Triage
= Yocto Bug Triage Searches =
== Non-Prioritized Bugs ==
== Non-Targeted Bugs ==
== Unassigned Bugs ==
== New This Week ==
== Medium+ Enhancements/Bugs ==
== High Enhancements/Bugs ==
== Bugs and Enhancements by Owner !(Future, 2.4) ==
== NEEDINFO ==
== Re-Opened ==
== Old Milestone ==
== Future Dot Releases==
JefroBus

JefroBus Schedule: Collab & ELC 2011
This is the schedule for the JefroBus. I have a car with room for 4 friendly passengers plus reasonable luggage, or 3 reasonably acquainted passengers plus a lot of luggage, or 2 hostile passengers plus any amount of luggage.. you get the idea. The schedule is posted below. 
If you are arriving at San Jose, Oakland, or San Francisco, and there is room left in the car, feel free to place yourself on the schedule. If you need a trip that is not posted here, send email to Jefro and I'll see what I can arrange.
For planning purposes, travel times to/from the Kabuki Hotel:
* SJC: approx 1hr
* SFO: approx 25m
* BART/CalTrain: approx 10m
Tuesday, April 5, 2011
 6:00pm - SJC to Kabuki [davest]
Friday, April 8, 2011
 11:00am - Kabuki to SFO [dawn]
 4:00pm - Kabuki to SJC [julie, jzhang, tracey]
Sunday, April 10, 2011
 10:30am - SFO to Kabuki [tomr, sgw]
Monday, April 11, 2011
 10:30am - BART or CalTrain to Kabuki [pidge is ok. she's going to hoof it early in the morning so she doesn't miss the keynote]
Wednesday, April 13, 2011
 7:00pm - Kabuki to SFO [tracey, sgw]
Thursday, April 14, 2011
 6:30am - Kabuki to SFO [RP]
Juci Integration

JUCI Integration is work planned to support OpenWRT in Yocto Project. Current status: Low priority.
Contributor(s):
1. Valluri, Amarnath <amarnath.valluri@intel.com>
2. Phoong, Stanley Cheong Kwan <stanley.cheong.kwan.cheong@intel.com>
3. Chang, Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
= Step-by-step build guide=
﻿1. Clone 'poky' git repository and checkout to the tested commit hash.
 $ git clone git://git.yoctoproject.org/poky
 $ git reset --hard fcdfe09d9cc4e2977bd602dfd18f729cd9f6d73d
﻿
2. Clone 'meta-openembedded' and checkout to the tested commit hash.
 $ git clone git://git.openembedded.org/meta-openembedded
 $ git reset --hard f841648657069051dffa1012a42eb1524b894d50
3. Clone 'meta-nodejs' and checkout to the tested commit hash.
 $ git clone https://github.com/imyller/meta-nodejs.git
 $ git reset --hard eec531e97a17bfd406f3bf76dee4057dcf5286a4
4. Clone 'meta-nodejs-contrib' and checkout to the tested commit hash.
 $ git clone https://github.com/imyller/meta-nodejs-contrib.git
 $ git reset --hard e7949bea628db5b7c5ac71841569f3f69953411a
5. Clone 'meta-configuration' and checkout to the tested branch.
 $ git clone https://github.com/avalluri/meta-configuration.git
 $ git checkout juci/devel
6. Source poky build environmental script.
7. Add the respective bblayers into build/conf/bblayers.conf.
 BBLAYERS ?= " \
 /media/rebeccas/yocto/juci/poky/meta \
 /media/rebeccas/yocto/juci/poky/meta-poky \
 /media/rebeccas/yocto/juci/poky/meta-yocto-bsp \
 /media/rebeccas/yocto/juci/meta-openembedded/meta-oe \
 /media/rebeccas/yocto/juci/meta-openembedded/meta-python \
 /media/rebeccas/yocto/juci/meta-openembedded/meta-networking \
 /media/rebeccas/yocto/juci/meta-nodejs \
 /media/rebeccas/yocto/juci/meta-nodejs-contrib \
 /media/rebeccas/yocto/juci/meta-configuration \
 "
8. Add the following configurations into build/conf/local.conf.
 # JUCI integration
 CORE_IMAGE_EXTRA_INSTALL += "packagegroup-conffw juci rpcd ubus orangerpcd lighttpd coreutils procps libwebsockets wget bash openssh openssh-sftp openssh-sftp-server networkmanager"
 CONFFW_UI = ""
 # systemd configuration
 DISTRO_FEATURES_append = " systemd"
 DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
 VIRTUAL-RUNTIME_init_manager = "systemd"
 VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
 EXTRA_IMAGE_FEATURES_append = " ssh-server-openssh"
9. Build an image for qemu MACHINE.
= Step-by-step runtime guide =
1. Fire up qemu.
2. To run on the device requires a few steps:
 $ mv /www/* /www/pages
 $ mv /www/pages/logs /www
 $ mv /etc/lighttpd.confe /etc/lighttpd.conf 
 $ ubusd &
 $ rpcd &
 $ orangerpcd &
 $ systemctl stop lighttpd.service 
 $ systemctl start lighttpd.service 
3. Then hit 192.168.7.xx with your browser. User=admin, Password=admin
= Runtime Screenshots =
Kernel

=Overview=
The Yocto Project Kernel Team is primarily responsible for the following components:
* BSPs and tooling
* linux-yocto meta data
* Linux kernel recipes
* Linux tracing, debug, and analysis tooling
* installation
* system startup
The following queries represent tasks associated with these components. These queries provide current status as well as input into release and milestone planning.
See http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports for bugzilla integration usage.
==Kernel Team Release Planning==
* Kernel/1.2_Planning
* Kernel/1.3_Planning
* Kernel/1.4_Planning
* Kernel/1.5_Planning
* Kernel/1.6_Planning
* Kernel/1.7_Planning
* Kernel/1.8_Planning
* Kernel/1.9_Planning
==Weekly Activity==
=== BSPs and Kernel ===
=== OE-Core/Kernel ===
=Non-Release-Specific Queries=
==New Kernel Team Bugs==
==Other Bugs==
The following bugs are assigned to the Kernel Team members, but are not categorized into the product and components we usually work with.
===Non BSPs,Kernel,Kernel Development,OE-Core===
Note: This doesn't list any OE-Core bugs. The query doesn't work when specifying only the "kernel" component from the "OE-Core" product.
==Untargeted Kernel Team Bugs==
===BSPs,Kernel,Kernel Development===
===OE-Core/Kernel===
Kernel/1.2 Planning

=1.2 Kernel Team Bugs=
==1.2 Bug Status==
===BSPs,Kernel,Kernel Development===
===OE-Core/Kernel===
==1.2 Open Bug Priority==
===BSPs,Kernel,Kernel Development===
===OE-Core/Kernel===
===1.2 Backlog===
===BSPs,Kernel,Kernel Development===
===OE-Core/Kernel===
Kernel/1.3 Planning

=1.3 Kernel Team Bugs=
==1.3 Bug Status by Milestone==
==1.3 Open Bug Priority by Milestone==
==1.3 Weekly Activity==
==1.3 Resolved Bugs==
==1.3 Targeted Bugs==
===1.3 M1===
====Completed Bugs====
====Scheduled Bugs====
===1.3 M2===
====Completed Bugs====
====Scheduled Bugs====
===1.3 M3===
====Completed Bugs====
====Scheduled Bugs====
===1.3 M4===
====Completed Bugs====
====Scheduled Bugs====
===1.3 M5===
====Completed Bugs====
====Scheduled Bugs====
===1.3 Backlog===
Kernel/1.4 Planning

=1.4 Kernel Team Bugs=
==1.4 Bug Status by Milestone==
==1.4 Open Bug Priority by Milestone==
==1.4 Weekly Activity==
==1.4 Resolved Bugs==
==1.4 Targeted Bugs==
===1.4 M1===
====Completed Bugs====
====Scheduled Bugs====
===1.4 M2===
====Completed Bugs====
====Scheduled Bugs====
===1.4 M3===
====Completed Bugs====
====Scheduled Bugs====
===1.4 M4===
====Completed Bugs====
====Scheduled Bugs====
===1.4 M5===
====Completed Bugs====
====Scheduled Bugs====
===1.4 Backlog===
===Previous Backlog===
Kernel/1.5 Planning

=1.5 Kernel Team Bugs=
==1.5 Bug Status by Milestone==
==1.5 Open Bug Priority by Milestone==
==1.5 Weekly Activity==
==1.5 Resolved Bugs==
==1.5 Targeted Bugs==
===1.5 M1===
====Completed Bugs====
====Scheduled Bugs====
===1.5 M2===
====Completed Bugs====
====Scheduled Bugs====
===1.5 M3===
====Completed Bugs====
====Scheduled Bugs====
===1.5 M4===
====Completed Bugs====
====Scheduled Bugs====
===1.5 M5===
====Completed Bugs====
====Scheduled Bugs====
===1.5 Backlog===
===Previous Backlog===
===Meta-Intel Backlog===
Kernel/1.7 Planning

=1.7 Planning=
==1.7 Priorities==
* Developer Workflow
** Slient failure, CONFIG_ missing/overridden/irrelevant
** Maybe as QA Warnings? --nakamble
* Automation and QA Testing
** Kernel manual guides
** Yocto BSP tooling
** wic
* Meta-Data cleanup
** intel-common - factor our platforms, don't just include the entire BSP scc
* BSP Updates
* linux-yocto-dev by M1
* Deployment Mark Hatle owns this now
* BSP Consolidation
** purge remaining MACHINE_ARCH packages for meta-intel
** runtime BSP customization (aka HDMI audio on the NUC, etc.)
* Continue Poky Tiny
==1.7 Commitments==
* The MUT branch will be built using linux-yocto-dev on a regular basis on the Autobuilder starting at M1.
* The versioned kernel recipe will be submitted at RC1 and before feature-freeze.
* The core-image-kernel-dev recipe will be moved from poky-extras into oe-core and used for kernel sanity and stress testing.
* Two weeks prior to the feature freeze date, the kernel team will send a Kernel Status Report detailing the current state of linux-yocto-dev, including the most likely kernel version (98% confidence) based on the known inputs and enumerate any unknowns. The report will include a list of known issues from the MUT builds which will reduce the surprise and scramble following the merge. The issue list is expected to be minimal given the prior runs in MUT. Factors influencing the final linux-yocto kernel version include the base kernel version for PREEMPT_RT, LTSI, stable, etc. which are beyond our control. Depending on the priorities for the release, any of these may impact the final kernel version decision. Should new or late arriving information necessitate a change to the kernel version, it will be raised with the CCB and re will need to weigh the risk (which will be much less with the MUT builds) and possible schedule slippage with the benefits (such as aligning with LTSI or PREEMPT_RT). Note that we cannot always meet all requirements of schedule and external tree support and at each release we must choose between them.
=1.7 Kernel Team Bugs=
==1.7 Bug Status by Milestone==
==1.7 Open Bug Priority by Milestone==
==1.7 Weekly Activity==
==1.7 Resolved Bugs==
==1.7 Targeted Bugs==
===1.7 M1===
====Completed Bugs====
====Scheduled Bugs====
===1.7 M2===
====Completed Bugs====
====Scheduled Bugs====
===1.7 M3===
====Completed Bugs====
====Scheduled Bugs====
===1.7 M4===
====Completed Bugs====
====Scheduled Bugs====
===1.7 M5===
====Completed Bugs====
====Scheduled Bugs====
===1.7 Backlog===
===Previous Backlog (!1.7,!Future)===
===Meta-Intel Backlog (!Future)===
===Previous Backlog===
===Future===
Kernel/1.8 Planning

=1.8 Planning=
==1.8 Priorities==
* Developer Workflow
** Silent failure, CONFIG_ missing/overridden/irrelevant - Fixed
* Automation and QA Testing
** Kernel manual guides 
*** Testing the process within the Manual
*** Tooling would change and process would break
*** This will need to be pushed to 1.9
** Yocto BSP tooling
** wic
* Meta-Data cleanup
** intel-common - factor our platforms, don't just include the entire BSP scc
* BSP Updates
* linux-yocto-dev by M1
* Deployment Mark Hatle owns this now
* BSP Refactor
** Not including whole BSPs
** purge remaining MACHINE_ARCH packages for meta-intel
** runtime BSP customization (aka HDMI audio on the NUC, etc.)
* Continue Poky Tiny
** Still needs to work
** Need to add tiny variant for Intel Core BSP
* Future
** Autobuilder detection of config changes
==1.8 Commitments==
* The MUT branch will be built using linux-yocto-dev on a regular basis on the Autobuilder starting at M1.
* The versioned kernel recipe will be submitted at RC1 and before feature-freeze.
* The core-image-kernel-dev recipe will be moved from poky-extras into oe-core and used for kernel sanity and stress testing.
* Two weeks prior to the feature freeze date, the kernel team will send a Kernel Status Report detailing the current state of linux-yocto-dev, including the most likely kernel version (98% confidence) based on the known inputs and enumerate any unknowns. The report will include a list of known issues from the MUT builds which will reduce the surprise and scramble following the merge. The issue list is expected to be minimal given the prior runs in MUT. Factors influencing the final linux-yocto kernel version include the base kernel version for PREEMPT_RT, LTSI, stable, etc. which are beyond our control. Depending on the priorities for the release, any of these may impact the final kernel version decision. Should new or late arriving information necessitate a change to the kernel version, it will be raised with the CCB and re will need to weigh the risk (which will be much less with the MUT builds) and possible schedule slippage with the benefits (such as aligning with LTSI or PREEMPT_RT). Note that we cannot always meet all requirements of schedule and external tree support and at each release we must choose between them.
=1.8 Kernel Team Bugs=
==1.8 Bug Status by Milestone==
==1.8 Open Bug Priority by Milestone==
==1.8 Weekly Activity==
==1.8 Resolved Bugs==
==1.8 Targeted Bugs==
===1.8 M1===
====Completed Bugs====
====Scheduled Bugs====
===1.8 M2===
====Completed Bugs====
====Scheduled Bugs====
===1.8 M3===
====Completed Bugs====
====Scheduled Bugs====
===1.8 M4===
====Completed Bugs====
====Scheduled Bugs====
===1.8 Backlog===
===Previous Backlog (!1.8,!Future)===
===Meta-Intel Backlog (!Future)===
===Previous Backlog===
===Future===