Yocto Project - User contributions [en]

Obsolete - Warning Fixing

2012-03-31T02:44:45Z

Lianhao.lu:

Obsolete - Warning Fixing

2012-03-19T01:57:35Z

Lianhao.lu:

This is a list of known warning messages currently appearing in a world build of poky. They're ordered by warning type. If you plan to work on any of these warnings and there is an owner listed, please check with that person first so we don't duplicate work.

License Warnings: Owner: Beth
WARNING: icu: No generic license file exists for: ICU in any provider
WARNING: setserial: No generic license file exists for: GPL in any provider
WARNING: socat: No generic license file exists for: GPL-2.0-with-OpenSSL-exception in any provider

Owner: Lianhao, fixed in llu/warningfix branch on contrib
WARNING: /media/build1/poky/build/tmp/work/qemux86-poky-linux/sysvinit-inittab-2.88dsf-r6/sysvinit-2.88dsf/COPYING could not be copied for some reason. It may not exist. WARN for now.

Stripped files warnings:
WARNING: File '/sbin/hdparm.hdparm' from hdparm was already stripped, this will prevent future debugging!
WARNING: File '/usr/bin/test-libacpi' from libacpi was already stripped, this will prevent future debugging!
WARNING: File '/usr/bin/memdiskfind' from syslinux was already stripped, this will prevent future debugging!
WARNING: File '/usr/bin/syslinux' from syslinux was already stripped, this will prevent future debugging!
WARNING: File '/usr/bin/gethostip' from syslinux was already stripped, this will prevent future debugging!
WARNING: File '/usr/bin/isohybrid' from syslinux was already stripped, this will prevent future debugging!

Unpackaged files warnings:
FIXED in MUT
WARNING: For recipe mktemp, the following files/directories were installed but not shipped in any package:
WARNING: /usr/bin
FIXED in MUT
WARNING: For recipe gawk, the following files/directories were installed but not shipped in any package:
WARNING: /usr/bin/awk
WARNING: /usr/bin/dgawk
FIXED in MUT
WARNING: For recipe gst-plugin-bluetooth, the following files/directories were installed but not shipped in any package:
WARNING: /var
WARNING: /var/lib
WARNING: /var/lib/bluetooth
WARNING: /usr/share/alsa
WARNING: /usr/share/alsa/bluetooth.conf
WARNING: /usr/lib/bluetooth
WARNING: /usr/lib/alsa-lib/libasound_module_pcm_bluetooth.la
WARNING: /usr/lib/alsa-lib/libasound_module_ctl_bluetooth.la
WARNING: /usr/lib/alsa-lib/libasound_module_ctl_bluetooth.so
WARNING: /usr/lib/alsa-lib/libasound_module_pcm_bluetooth.so
WARNING: /usr/lib/bluetooth/plugins
FIXED in MUT
WARNING: For recipe telepathy-mission-control, the following files/directories were installed but not shipped in any package:
WARNING: /usr/share/glib-2.0
WARNING: /usr/share/glib-2.0/schemas
WARNING: /usr/share/glib-2.0/schemas/im.telepathy.MissionControl.FromEmpathy.gschema.xml
FIXED in MUT
WARNING: For recipe gnome-desktop, the following files/directories were installed but not shipped in any package:
WARNING: /usr/share/libgnome-desktop
WARNING: /usr/share/libgnome-desktop/pnp.ids
Owner Paul Eggleton:
WARNING: For recipe iproute2, the following files/directories were installed but not shipped in any package:
WARNING: /lib
WARNING: /lib/tc

Unpackaged files warnings: Python & perl recipes: Owner Nitin, fixed in nitin/misc branch on contrib
FIXS ARE in MUT
WARNING: For recipe python-pyrex, the following files/directories were installed but not shipped in any package:
WARNING: /usr/share
WARNING: /usr/share/lib
WARNING: /usr/share/lib/python2.7
WARNING: /usr/share/lib/python2.7/site-packages
WARNING: /usr/share/lib/python2.7/site-packages/Pyrex
WARNING: /usr/share/lib/python2.7/site-packages/Pyrex/Compiler
WARNING: /usr/share/lib/python2.7/site-packages/Pyrex/Compiler/Lexicon.pickle
WARNING: For recipe python-pycurl, the following files/directories were installed but not shipped in any package:
WARNING: /usr/share/share
WARNING: For recipe git, the following files/directories were installed but not shipped in any package:
WARNING: /usr/lib/perl-native
WARNING: /usr/lib/perl-native/perl
WARNING: /usr/lib/perl-native/perl/5.14.2
WARNING: /usr/lib/perl-native/perl/5.14.2/Git.pm
WARNING: /usr/lib/perl-native/perl/5.14.2/perllocal.pod
WARNING: /usr/lib/perl-native/perl/5.14.2/auto
WARNING: /usr/lib/perl-native/perl/5.14.2/auto/Git
WARNING: /usr/lib/perl-native/perl/5.14.2/auto/Git/.packlist

meta-toolchain/nativesdk warnings:
WARNING: For recipe eglibc-nativesdk, the following files/directories were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libthread_db.so.1
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_hesiod-2.13.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libSegFault.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libthread_db-1.0.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libmemusage.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_hesiod.so.2
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_nisplus.so.2
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_nis-2.13.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_nisplus-2.13.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libnss_nis.so.2
WARNING: QA Issue: non -staticdev package contains static .a library: libgcc-nativesdk-dev path '/work/x86_64-nativesdk-pokysdk-linux/libgcc-nativesdk-4.6.3+svnr184847-r23/packages-split/libgcc-nativesdk-dev/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/x86_64-pokysdk-linux/4.6.4/libgcc.a'
WARNING: QA Issue: non -staticdev package contains static .a library: libgcc-nativesdk-dev path '/work/x86_64-nativesdk-pokysdk-linux/libgcc-nativesdk-4.6.3+svnr184847-r23/packages-split/libgcc-nativesdk-dev/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/x86_64-pokysdk-linux/4.6.4/libgcc_eh.a'
WARNING: For recipe alsa-lib-nativesdk, the following files/directories were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/smixer.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/sndo-mixer.alisp
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/alsa.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/alsa.conf.d
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/surround40.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/center_lfe.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/surround50.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/rear.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/side.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/default.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/iec958.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/dmix.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/surround51.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/surround71.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/front.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/dpl.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/surround41.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/hdmi.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/modem.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/pcm/dsnoop.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/alsa.conf.d/README
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/AU8810.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/RME9652.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CMI8738-MC8.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VX222.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/Maestro3.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CMI8338-SWIEC.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/HDA-Intel.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/USB-Audio.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VIA8233A.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ENS1370.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/FireWave.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VIA8237.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CMI8788.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CA0106.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ICE1724.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/GUS.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/AU8830.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/Audigy.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ENS1371.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/YMF744.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ES1968.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ICH4.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VIA8233.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/FM801.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/EMU10K1X.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/TRID4DWAVENX.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/RME9636.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ICH-MODEM.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/AU8820.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/EMU10K1.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ATIIXP.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/FWSpeakers.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/PMacToonie.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/Audigy2.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/PS3.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/SB-XFi.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ICH.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/aliases.alisp
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CMI8338.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/AACI.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/Aureon71.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/Aureon51.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ATIIXP-MODEM.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ICE1712.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/ATIIXP-SPDMA.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VXPocket.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CS46xx.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/PC-Speaker.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/CMI8738-MC6.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/PMac.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VIA686A.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/VXPocket440.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/NFORCE.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/aliases.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/SI7018.conf
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/SI7018
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/SI7018/sndop-mixer.alisp
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/alsa/cards/SI7018/sndoc-mixer.alisp
WARNING: For recipe ncurses-nativesdk, the following files/directories were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/reset
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/clear
WARNING: For recipe sqlite3-nativesdk, the following files/directories were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/include
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/man
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/man/man1
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/man/man1/sqlite3.1
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/include/sqlite3.h
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/include/sqlite3ext.h
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libsqlite3.so
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libsqlite3.so.0.8.6
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libsqlite3.la
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libsqlite3.so.0
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libsqlite3.a
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/pkgconfig
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/pkgconfig/sqlite3.pc
WARNING: For recipe pseudo-nativesdk, the following files/directories were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/var
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/var/pseudo
WARNING: QA Issue: non -staticdev package contains static .a library: gdb-cross-canadian-i586 path '/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-i586-7.4-r6.3/packages-split/gdb-cross-canadian-i586/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/lib/libiberty.a'

exec_prefix cross linkage: (lowest priority to fix)
WARNING: QA Issue: pcmciautils: /media/build1/poky/build/tmp/work/i586-poky-linux/pcmciautils-018-r0/packages-split/pcmciautils/sbin/pccardctl links to something under exec_prefix
WARNING: QA Issue: ldd reports: libc.so.6 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libc.so.6 (0xdead1000)
WARNING: QA Issue: gzip: Found a reference to /usr/ in /media/build1/poky/build/tmp/work/i586-poky-linux/gzip-1.4-r0/packages-split/gzip/bin/zcat.gzip
WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix
WARNING: QA Issue: gzip: Found a reference to /usr/ in /media/build1/poky/build/tmp/work/i586-poky-linux/gzip-1.4-r0/packages-split/gzip/bin/gunzip.gzip
WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix
WARNING: QA Issue: iputils: /media/build1/poky/build/tmp/work/i586-poky-linux/iputils-s20101006-r3/packages-split/iputils-arping/bin/arping links to something under exec_prefix
WARNING: QA Issue: ldd reports: libsysfs.so.2 => /media/build1/poky/build/tmp/sysroots/qemux86/usr/lib/libsysfs.so.2 (0xdead1000)
WARNING: QA Issue: chkconfig: /media/build1/poky/build/tmp/work/i586-poky-linux/chkconfig-1.3.58-r0/packages-split/chkconfig/sbin/chkconfig links to something under exec_prefix
WARNING: QA Issue: ldd reports: libpopt.so.0 => /media/build1/poky/build/tmp/sysroots/qemux86/usr/lib/libpopt.so.0 (0xdead1000)
WARNING: QA Issue: bash: Found a reference to /usr/ in /media/build1/poky/build/tmp/work/i586-poky-linux/bash-4.2-r2/packages-split/bash/bin/bashbug
WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix
WARNING: QA Issue: libpam: /media/build1/poky/build/tmp/work/i586-poky-linux/libpam-1.1.5-r3/packages-split/pam-plugin-access/lib/security/pam_access.so links to something under exec_prefix
WARNING: QA Issue: ldd reports: libpam.so.0 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libpam.so.0 (0xdead1000)
WARNING: QA Issue: libpam: /media/build1/poky/build/tmp/work/i586-poky-linux/libpam-1.1.5-r3/packages-split/pam-plugin-cracklib/lib/security/pam_cracklib.so links to something under exec_prefix
WARNING: QA Issue: ldd reports: libpam.so.0 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libpam.so.0 (0xdead1000)
WARNING: QA Issue: libpam: /media/build1/poky/build/tmp/work/i586-poky-linux/libpam-1.1.5-r3/packages-split/pam-plugin-unix/lib/security/pam_unix.so links to something under exec_prefix
WARNING: QA Issue: ldd reports: libpam.so.0 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libpam.so.0 (0xdead1000)
WARNING: QA Issue: udev: /media/build1/poky/build/tmp/work/i586-poky-linux/udev-164-r13/packages-split/libgudev/lib/libgudev-1.0.so.0.0.1 links to something under exec_prefix
WARNING: QA Issue: ldd reports: libudev.so.0 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libudev.so.0 (0xdead1000)
WARNING: QA Issue: udev: /media/build1/poky/build/tmp/work/i586-poky-linux/udev-164-r13/packages-split/udev-acl/lib/udev/udev-acl links to something under exec_prefix
WARNING: QA Issue: ldd reports: libacl.so.1 => /media/build1/poky/build/tmp/sysroots/qemux86/lib/libacl.so.1 (0xdead1000)

Network based PR service

2012-01-12T01:35:50Z

Lianhao.lu:

The network based PR service is a missing building block in the current poky build system to enable the "basichash" ''BB_SIGNATURE_HANDLER'' for shared state. By having the network based PR service and the "basichash" signature handler, the poky users can modify the recipes without worrying about bumping the PR value manually in the recipes. The build system will automatically detect the change, rebuild only the necessary pieces of work, and have the changes reflected in the 'package revision' field value of the final package feed. (See [https://lists.yoctoproject.org/pipermail/yocto/2011-March/001157.html] for the details about shared state and BB_SIGNATURE_HANDLER).

The basic scenario of using the network based PR service is that the client asks the server for a value (i.e. ''PRAUTO'') by including the task checksum as part of the search index. The server returns the stored value if the search index is found in its backend database. If the search index is notfound, the server bumps the value, stores the new index into the database, and returns the incremented value to the client. The client then includes the PRAUTO as part of the 'package revision' field value in the created package feed. The service is network based so a central database can be used to provide multiple build clients with the same value for the same index.

The base patches enabling the above scenario is in poky master branch now(disabled by default though). To use the PR service, the users should first start the service daemon by running the following commands:

''source ./oe-init-build-env''
''bitbake-prserv --start''

Then the users should make sure the ''PRHOST_ADDR'' and ''PRHOST_PORT'' are set correctly in ''conf/local.conf'' to match the configurations of the machine on which the service daemon is running, and then "bitbake" whatever they want to. (Please also make sure the ''BB_SIGNATURE_HANDLER'' is set to "basichash" instead of "basic").

By leaving the ''PRHOST_ADDR'' and ''PRHOST_PORT'' unset, the PR service mechanism is disabled and the poky runs exactly the same as it is now: the user needs to bump the PR manually in the recipe when changes are made .

There are still some pending tasks, however, to make the PR service mechanism adapted to various usage model and scenarios:

----'''1. Automatically launching service daemon''' (Source: Richard Purdie)

For many users, they may want to run the service daemon and the poky build system on the same machine most of the time. So they may not want to bother typing "bitbake-prserv --start". In this localhost case, it is desired to have poky launch the service daemon automatically at the start and stop it when the build finishes. Also it might need to run multiple daemons on the same machine at the same time.

Status: Done. To start launching local service automatically, set PRSERV_HOST to "localhost" and PRSERV_PORT to "0". See Bug #1126[http://bugzilla.pokylinux.org/show_bug.cgi?id=1126] for details.

----'''2. Use different PR service for different recipes''' (Source: Frans Meulenbroeks)

Some users want to use different PR service or disable the PR service per recipe basis. We need to support something like:

''PRSERV_HOST_pn-myprivaterecipe = "someotherhost"''

''PRSERV_HOST_pn-myprivaterecipe = ""''

Status: Done. See Bug #1126[http://bugzilla.pokylinux.org/show_bug.cgi?id=1126] for details.

----'''3. Support proxy''' (Source: Koen Kooi)

Since the PR service is a network based XMLRPC service, it would be nice to support the http proxy for the intranet build clients to contact the outside PR service.

----'''4. Write permission control''' (Source: Koen Kooi)

Some usage scenario might only allow certain authorized clients to have the write permission to bump the value in the PR service database, and other unauthorized clients can only "read" the value back from the database. The question is what if an unauthorized client who doesn't have the write permission asks for a value which is not stored in the database. Several ways are brought up to handle this kind of situation. One is to generate a warning on the client side and an error in the server log. Another way is to return a specific string as the ''PRAUTO''(i.e. "custom") to indicate this situation.

----'''5. database sync-up''' (Source: Richard Purdie)

If the user uses local PR services, we need to way to dump the local databases to the central server, so other users may use the central server to generate the same package feeds as those using the local servers.

Status: Done. See Bug #1556[http://bugzilla.pokylinux.org/show_bug.cgi?id=1556] for details.

Hob2 (Hob v2)

2011-11-14T16:27:04Z

Lianhao.lu: /* Discussion 2 (Lianhao, Josh and Jessica) */

This page holds the history for Hob v2 design and implementation.

== Requirements ==

See slides attached.
[[File:HOBV2-plan-0.2.pdf]]

== Related Bugs ==

* http://bugzilla.pokylinux.org/show_bug.cgi?id=1588
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1688
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1573
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1691
* http://bugzilla.pokylinux.org/show_bug.cgi?id=991
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1241
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1272
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1303
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1450
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1572
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1581
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1221
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1277
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1742
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1743
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1744
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1745
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1746
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1747
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1748
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1749
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1750
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1751
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1752
* http://bugzilla.pokylinux.org/show_bug.cgi?id=1753

== Discussion 1 (Lianhao, Ke, Dongxiao and Shane) ==

In order to get the accurate dependencies of the packages to be installed into a rootfs image, the hob v2 works in a 2-stages way: In stage 1, the users select the recipes which would be built to generate packages; In stage 2, the users select the packages which would be installed into the final rootfs image. The hob v2 will present the UI to the users in the form of a step-by-step wizard. Here is the main workflow:

Step 1: Users are asked to specify which layers(directories) should be included.

- TP1: Hob would check for the validity of the file conf/layer.conf to make sure the user input is a valid layer.

'''[P1][D5]http://bugzilla.pokylinux.org/show_bug.cgi?id=1742'''

Step 2: Users are asked to select various configurations, i.e. machine, distro, package format, image output type, etc.

- TP2: bitbake backend will then parse the configuration files and all the available recipes based on user's configuration.

'''[P1][D5]http://bugzilla.pokylinux.org/show_bug.cgi?id=1743'''

Step 3: Users are asked to select the recipes which will be built later to generate the packages. In this step, the users may select the recipes from scratch or select the recipes from the pre-defined base image templates, e.g. core-image-sato, core-image-minimal, etc.

- TP3: Hob frontend needs the information of all the available recipes, e.g. PN, license, description, section, etc.

'''[P1][D5]http://bugzilla.pokylinux.org/show_bug.cgi?id=1745'''

- TP4: Hob frontend needs to know the build dependencies between the recipes. Say recipe A has a build dependency on recipe B, if the users select recipe A, recipe B should also be automatically selected. Without deselecting recipe A, the users can NOT deselect recipe B only. If the users deselect recipe A, the recipe B will still remain selected.

'''[P1][D10]http://bugzilla.pokylinux.org/show_bug.cgi?id=1747'''

- TP5: bitbake backend needs to be able to generate the recipe dependencies quick enough so the Hob frontend UI won't wait too long.

'''[P1][TBD]http://bugzilla.pokylinux.org/show_bug.cgi?id=1749'''

Step 4: After the users select all the recipes they want to build and click "Next", bitbake will build them. This may take quite a long time if those recipes have never been built or if there is no sstate. During that time, the building log will be displayed in the hob UI along with the progress bar. The users may choose to cancel the build if they want.

- TP6: A progress bar should tell the users how much left for the building.

'''[P1][D3]http://bugzilla.pokylinux.org/show_bug.cgi?id=1751'''

Step 5: After all recipes are built successfully, the users will be asked to choose which packages they want to install into the final rootfs images. The available packages can be sorted by Name/Section/Size/Selected or not. The users may also be given the opportunity to configure other image options if appropriate, i.e. how much free space will be added into the final images, do we need prelink or mklibs on the final images, etc. Some packages are by default selected to be installed based on the base image template the users have chosen in step3.

- TP7: New items, i.e. package installed size, will be added into the current pkgdata.

'''[P1][D3]http://bugzilla.pokylinux.org/show_bug.cgi?id=1748'''

- TP8: Need to develop a new bitbake task to collect all the pkgdata information and send these information back to Hob UI frontend

'''[P1][D5]http://bugzilla.pokylinux.org/show_bug.cgi?id=1750'''

- TP9: Hob UI frontend will use the information generated in TP8 to build a reference count based tree model about the packages dependencies. This tree model helps the users to figure out what actually will be installed into the final rootfs images.

'''[P1][D15]http://bugzilla.pokylinux.org/show_bug.cgi?id=1752'''

- TP10: Hob UI needs to write a temporary recipe and reparse that recipes to build the final images.

'''[P1][D3]http://bugzilla.pokylinux.org/show_bug.cgi?id=1746'''

Other TPs:
- TP11: users should be able to load/save their configurations, choices of recipes and/or packages.

'''[P1][D3]http://bugzilla.pokylinux.org/show_bug.cgi?id=1744'''

Open Issues(OI):
- OI1: For TP5, we need to investigate whether the bitbake backend can generate the accurate recipe build dependencies using only cache data and taskData, without calling prepare_run_queue() which would take quite a long time because it will generate all the task dependencies. If not, we need to figure out a way to accelerate that process. One way is to write another special prepare_run_queue so it only process the information the hob concerns. But RP is concerned that if we have 2 kind of prepare_run_queue, we need to make sure the dependencies generated by each of them are exactly the same.

- OI2: How to handle the build dependencies of virtual targets. E.g. many recipes have build dependencies on virtual/libc, and we have both eglibc and uclibc to provide virtual/libc. Eglibc will be the default options but what if the user wants uclibc instead of eglibc. One possible way may be to treat this as part of the configuration PREPERRED_PROVIDER, and have the bitbake backend reparse the recipes based on the new configurations, but this way may take some time due to the reparsing.

'''[P1][TBD]http://bugzilla.pokylinux.org/show_bug.cgi?id=1753'''

== Discussion 2 (Lianhao, Josh and Jessica) ==

1. It's feasible to save the UI configurations in the client side, not in the server side's conf/local.conf (Bug #1441), but there is one thing need needs special attention: the cache validity. Currently, the cache validity is decided by comparing the file modification time(See code in Cache:__init__() in cache.py). If we change the configuration in the data store but not in the server side's configuration file, that means we have to design a new way to decide the cache validity.

2. Currently, the server commands getVariable and setVariable only apply to the base configuration data store. It doesn't apply to the data store of a specific recipe. It's feasible to extend those commands, in which case we don't need to create new recipe for stage 2 building, but again need to pay attention to cache validity. Josh prefers the way to create new recipe for stage 2 building because it is simpler.

3. About OI1, Josh thinks taskData itself is not enough to generate accurate build dependencies. Josh is ok with NOT providing build dependencies in stage 1, but RP thinks we need to show that build dependencies .

AR: confirm whether we could generate correct build dependencies based on taskData only. If the answer is no, then we need to see how the lengthy operation of prepare_runqueue will influence the user experience. Is it ok with users if they're given a progress bar indicating what is going on during that period of time(more than 20 seconds I guess including the taskData, prepare_runqueue and pre-process the returned data)? If it's not acceptable, we may need to persuade RP not showing the build dependencies in stage1, at least for 1.2 version, unless we have other ways to get the dependencies in a short time.

4. About OI2, Josh thinks it's the right way to use PREPERRED_PROVIDERS as part of the configurations for multiple provider situation.

5. Josh thinks the current metadata information in the recipe may not be sufficient for hob use. He prefers to add more metadata into the recipe. I raised the question of whether the community is willing to accept it, Josh thinks we should do that work for the recipes we own, just like the distro tracking data we added.

6. Jessica/Josh mentioned that we should keep extensibility in our minds during HobV2 design, since we already got comment from community saying that they want to add more configurations in stage 2 building. I mentioned about the idea of having a configuration file for the configurable items in HobV2. Josh mentioned there is already some kind of mechanism in bitbake which would be a good start point for us(See commit 4921fda5b3a18c797acd267f2b1179ac032cd42).

7. Jessica thinks we kind of need to demo the Hobv2 skeleton UI at the end of M1(Bug #1764). There will be a person in UK helping us with the UX design, Dave suggest this "artist" thought might change our engineer mindset.

8. Jessica suggests that we need to do the split between client/server in 1.2, in an evolutionary way that Hobv2 uses the modal of client/server split, while other UI may continue to use the modal of client/server on the same machine.

== UI Skelecton ==

<That is based on our previous discussions (esp. discussion 1) and just for review, the UI design could be changed and polished, some details could be determined later>

'''1.
Here is the main window with menus.

[[File:main window.png]]

“New Build” is to reset the process to the initial state to start a new build process.
“Open Template” is to load a hob-specific file saved last time, which includes setting, recipes, and packages.
“Close Template” is just to close the current process, discard any change to the template file.
“Save Template” is to save the changes of the template file.
“Save Template As” is to save the changes to another template file. A file save dialog is shown.
“Exit” is to exit the program.

The items under “Window” are to switch to any step from any step.

The “view” items under “Tools” are to view different files and logs.
The “Open” items are to open different directories. It is worth noting that “Open target directory” is useful after the target image is made.
"One click to build and make" is that the user doesn't want to click "Next >" one by one, but load his/her template, use all settings in the template file and click this to make the target image.
“Deploy live image to USB drive” is to make a live image based on the image made.
"kernel config" is to "menu config" in the kernel for kernel customization. (TBD)

The menus under “Help” are to show help hints, files and copyright information.

Yocto 1.2 Features

2011-09-21T07:58:34Z

Lianhao.lu: /* Project-wide Features */

== Potential Yocto Project 1.2 Features ==
Yocto Project 1.2 - Target release = April 2012

== Yocto Project 1.2 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.

=== Yocto Project 1.2 Objectives ===
The objectives of the Yocto 1.2 release are to ... [TBD]

=== Yocto Project 1.2 Theme List ===
The Yocto Project 1.2 Themes towards the Objectives listed above are:

* Theme 1
* Theme 2
* Theme 3

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Usability ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]
|-
| Web Hob||Add a web interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network. Would require us to have a web server package installed of course for local builds.||1||Review||davest/tracey/RP||TBD||xx
|-
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx
|-
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx
|-
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||1||Review||davest/tracey/RP||TBD||xx
|-
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.
|}

== Core/Bitbake ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing
|-
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)
|-
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2
|-
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2
|-
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2
|-
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2
|-
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2
|-
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list
|}

== QA Items ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||
|-
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2
|-
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||
|-
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task.
|}

== Meta Data ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2
|-
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2
|-
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2
|-
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2
|-
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1
|-
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example
|-
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2
|-
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list
|-
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2
|-
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2
|-
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1
|-
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1
|-
| Add Directfb（license LGPL） function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1
|}

== Autobuilder ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks
|-
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week
|-
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half
|-
| license manifest||||2||||Beth||Beth||1.2||1 week
|-
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks
|}

== BSPs ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel
|-
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua
|-
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1
|}

== ADT ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||
|-
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2
|-
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2
|-
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2
|-
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?
|}

== Documentation ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest
|}

== Performance & usability ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list
|}

== Kernel ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1
|-
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2
|-
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1
|-
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1
|-
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?
|-
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?
|}

== Project-wide Features ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Due'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||
|-
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||
|-
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||
|-
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||
|-
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||
|-
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||
|-
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||
|-
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2
|-
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2
|-
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1
|-
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1
|-
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1
|-
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1
|-
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414
|-
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1
|-
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1
|-
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1
|-
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||
|-
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1
|-
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1
|-
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1
|-
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||
|-
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||
|-
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||
|-
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||
|-
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923
|-
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||
|-
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||
|-
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316
|-
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852
|-
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||
|-
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already
|-
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||
|-
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.
|}

Yocto 1.2 Features

2011-09-21T03:07:59Z

Lianhao.lu: /* ADT */

Network based PR service

2011-05-30T08:18:36Z

Lianhao.lu: "Italic" the poky variables and corrected the grammar.

The network based PR service is a missing building block in the current poky build system to enable the "basichash" ''BB_SIGNATURE_HANDLER'' for shared state. By having the network based PR service and the "basichash" signature handler, the poky users can modify the recipes without worrying about bumping the PR value manually in the recipes. The build system will automatically detect the change, rebuild only the necessary pieces of work, and have the changes reflected in the 'package revision' field value of the final package feed. (See [https://lists.yoctoproject.org/pipermail/yocto/2011-March/001157.html] for the details about shared state and BB_SIGNATURE_HANDLER).

The basic scenario of using the network based PR service is that the client asks the server for a value (i.e. ''PRAUTO'') by including the task checksum as part of the search index. The server returns the stored value if the search index is found in its backend database. If the search index is notfound, the server bumps the value, stores the new index into the database, and returns the incremented value to the client. The client then includes the PRAUTO as part of the 'package revision' field value in the created package feed. The service is network based so a central database can be used to provide multiple build clients with the same value for the same index.

The base patches enabling the above scenario is in poky master branch now(disabled by default though). To use the PR service, the users should first start the service daemon by running the following commands:

''source ./oe-init-build-env''
''bitbake-prserv --start''

Then the users should make sure the ''PRHOST_ADDR'' and ''PRHOST_PORT'' are set correctly in ''conf/local.conf'' to match the configurations of the machine on which the service daemon is running, and then "bitbake" whatever they want to. (Please also make sure the ''BB_SIGNATURE_HANDLER'' is set to "basichash" instead of "basic").

By leaving the ''PRHOST_ADDR'' and ''PRHOST_PORT'' unset, the PR service mechanism is disabled and the poky runs exactly the same as it is now: the user needs to bump the PR manually in the recipe when changes are made .

There are still some pending tasks, however, to make the PR service mechanism adapted to various usage model and scenarios:

----'''1. Automatically launching service daemon''' (Source: Richard Purdie)

For many users, they may want to run the service daemon and the poky build system on the same machine most of the time. So they may not want to bother typing "bitbake-prserv --start". In this localhost case, it is desired to have poky launch the service daemon automatically at the start and stop it when the build finishes. Also it might need to run multiple daemons on the same machine at the same time.

----'''2. Use different PR service for different recipes''' (Source: Frans Meulenbroeks)

Some users want to use different PR service or disable the PR service per recipe basis. We need to support something like:

''PRSERV_HOST_pn-myprivaterecipe = "someotherhost"''

''PRSERV_HOST_pn-myprivaterecipe = ""''

----'''3. Support proxy''' (Source: Koen Kooi)

Since the PR service is a network based XMLRPC service, it would be nice to support the http proxy for the intranet build clients to contact the outside PR service.

----'''4. Write permission control''' (Source: Koen Kooi)

Some usage scenario might only allow certain authorized clients to have the write permission to bump the value in the PR service database, and other unauthorized clients can only "read" the value back from the database. The question is what if an unauthorized client who doesn't have the write permission asks for a value which is not stored in the database. Several ways are brought up to handle this kind of situation. One is to generate a warning on the client side and an error in the server log. Another way is to return a specific string as the ''PRAUTO''(i.e. "custom") to indicate this situation.

----'''5. database sync-up''' (Source: Richard Purdie)

If the user uses local PR services, we need to way to dump the local databases to the central server, so other users may use the central server to generate the same package feeds as those using the local servers.

Network based PR service

2011-05-30T08:03:07Z

Lianhao.lu: discussion and pending tasks of network based PR service

The network based PR service is a missing building block in current poky build system to enable the "basichash" BB_SIGNATURE_HANDLER for shared state. By having the network based PR service and the "basichash" signature handler, the poky users can modify the recipes without worrying about bumping the PR value manually in the recipes. The poky build system will automatically detect the change and rebuild only necessary pieces of work, and have the change reflected in the related field's value(i.e. Revision) of the final package feed. (See [https://lists.yoctoproject.org/pipermail/yocto/2011-March/001157.html] for the details about shared state and BB_SIGNATURE_HANDLER).

The basic scenario of using the network based PR service is that the client asks the server for a value (i.e. PRAUTO) by including the task checksum as part of the search index. The server returns the stored value if the search index is found in its backend database. If the search index is NOT found, the server bumps the value, stores the new index into the database, and returns the incremented value to the client. The client then includes PRAUTO as part of the revision field value in the final created package feed. The service is network based so a central database can be used by providing multiple build client with the same value for the same index.

The base patches enabling the above scenario is in poky master branch now(disabled by default though). To use the PR service, the users should first start the service daemon by running the following commands:

''source ./oe-init-build-env''
''bitbake-prserv --start''

Then the users should make sure the PRHOST_ADDR and PRHOST_PORT are set correctly in conf/local.conf to match the configurations of the machine on which the service daemon is running, and then "bitbake" whatever they want to. (Please also make sure the BB_SIGNATURE_HANDLER is set to "basichash" instead of "basic").

By leaving the PRHOST_ADDR and PRHOST_PORT unset, the PR service mechanism is disabled and the poky runs exactly as same as it is now: the user needs to bump the PR manually in the recipe when changes are made to the recipe.

There are still pending tasks there, however, to make the PR service mechanism adapted to various usage model and scenarios:

----'''1. Automatically launching service daemon''' (Source: Richard Purdie)

For many users, they may want to run the service daemon and poky build system on the same machine for most of the time. So they may not want to bother typing "bitbake-prserv --start". In this localhost case, it is desired to have poky launch the service daemon automatically at start and stop it at finish. Also it might need to run multiple daemons on the same machine.

----'''2. Use different PR service for different recipes''' (Source: Frans Meulenbroeks)

Some users want to use different PRHOST or disable the PR service per recipe basis. We need to support something like:

''PRSERV_HOST_pn-myprivaterecipe = "someotherhost"''

''PRSERV_HOST_pn-myprivaterecipe = ""''

----'''3. Support proxy''' (Source: Koen Kooi)

Since it is a network based XMLRPC service, it would be nice to support the http proxy for the intranet build clients to contact internet PR service.

----'''4. Write permission control''' (Source: Koen Kooi)

Some use scenario might only allow certain authorized clients to have the write permission to bump the value in the PR service database, and other unauthorized client can only "read" the value back from the database. The question is what if an unauthorized client who doesn't have the write permission asks for value which is not stored in the database. Several ideas are brought up to handle this kind of situations. One is to generate a warning on the client side and an error in the server log. Another way is to use a specific string in the PRAUTO(i.e. custom) to indicate this situation.

----'''5. database sync-up''' (Source: Richard Purdie)

If the user uses local PR services, we need to way to dump the local databases to the central server, so other users may use the central server to generate the same package feeds as those using the local servers.

Yocto 1.1 Features

2011-04-01T02:30:43Z

Lianhao.lu: /* ADT */

== Potential Yocto Project 2011.10 Features ==
Yocto Project 2011.10 (a.k.a. Yocto Project 1.1) - Target release = October 2011

== Yocto Project 2011.10 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto Project 2011.10. These will grow and change with community input.

=== Yocto Project 2011.10 Objectives ===
The objectives of the Yocto 2011.10 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto Project 2011.10 Theme List ===
The Yocto Project 2011.10 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto Project 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes ||
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 ||
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 ||
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 ||
|-
|| Clean up warning messages || A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. || 2 || Review || davest and RP ||
|-
|| Monitor disk availability || Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem || 2 || Review || RP and Robert ||
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||QA Framework Enhancements ||
* Add test for unfs_qemu bootup in the sanity test framework and give Liping his patch (Jiajun)
* Help to define long-term flexible framework for SDK/meta-toolchain testing.. Under the test folder, we have different groups of test, such as sanity, SDK(tools), meta-toolchain. User could freely select which test cases they want to test. (Control granularity/level group? Or even a single case has a switch) (Jiajun)
* More test-projects into existing manual test part for meta-toolchain. We should help to find the two typical projects, one c and o C++. (Jiajun)
* Transform the meta-toolchain manual testing into the unified test-framework. (Liping)
* Prepare a workable environment for testing all those newly added features. (Liping)
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)
|bgcolor="yellow"| ?? || Review|| QA ||
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA ||
|-
|| Automated test infrastructure || Automate the test infrastructure
|| 2 || Review|| QA ||
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes ||
|-
|| Be prepared for Distro upgrades || Our release is right around the time of the 6monthly distro release dates, we should accommodate for this in our testing plan || 2 || Review || Joshua ||
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data||
|-
|| btrfs || || 2 || Review|| Meta-data||
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data||
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data||
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data||
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data||
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data||
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data||
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data||
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data||
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan, Jingdong Lu, Kai kang,Xudong Hao
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team ||
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team ||
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team ||
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes ||
|-
|| Incompatible License || || 2 || Review || Paul ||
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes ||
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes ||
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes ||
|-
|| remove gnome-vfs || || 3 || Review || RP Notes ||
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes ||
|-
|| sato refresh || || 3 || Review || RP Notes ||
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes ||
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes ||
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea
|-
|| Ability to build SRPM || || 3 || Review || RP Notes ||
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes ||
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M3;Owner = Xiaofeng Yan if possible
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Saul
|-
|| Optimize support for Intel hardware features || We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc. || 1|| Review|| Tom ||
|-
|| Fish River Island/Fish River Island II BSP(s) || The base Fish River Island BSP exists already, we now need to add support for the extra devices, and add support for changes introduced by Fish River Island II || 2|| Review|| Tom ||
|-
|| Support ECG (ongoing) || ECG is ramping up with Yocto BSPs and likely will require significant amounts of time and help. Also, since we're trading their BSP work for our help in upstreaming patches, we're also likely to have to spend a significant amount of time with upstream-related tasks too. || 1|| Review|| Tom ||

|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || not using oprofile-UI. More integrated with upstream
|| 2 || Review|| ADT Team ||
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure logging || || 2 || Review|| ADT Team ||
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Review || Adrian ||
|-
|| Systemtap integration || Make it easy and convenient for the user to write and execute Systemtap scripts from the IDE. http://www.eclipse.org/linuxtools/projectPages/systemtap/ might provide a good starting point and may be something we can contribute to. We may also need to contribute further up the chain to provide e.g. remote target capabilities. || 2 || Review || Tom ||
|-
|| 'perf scripting' integration || Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. We should be able to leverage and build on the Systemtap integration for this. || 2 || Review || Tom ||
|-
|| Enhance the deploy part in remote debug || ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target. || 2 || Review || Lianhao ||
|-
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 1|| Not Started || from scratch || Owner = ScottR
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Not Started || From ADT module and scratch || Owner = ScottR
|-
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.
|| 2|| Not Started || From scratch || Owner = ScottR
|-
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.
|| 3|| Not Started || From scratch || Owner = ScottR
|-
|| OOB documentation || Create an out of box guide for giveaway systems built using Yocto. || 1|| Review || Julie || Owner = ScottR
|-
|| Tracing/profiling HOWTOs || Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools. || 2|| Review || Tom ||
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License tracking || Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts that can be used for both a weekly release and for OCT 2011 release to be run by autobuilder
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added.
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team ||
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || Audit kernel configs for the various BSPS. Should not be limited to just kernel config options -- it should also include discussion of overall strategies for defining and managing base branches, feature topic branches, config features, etc, and should result in not only the current kernels being changed to match, but also BKMs being published somewhere, probably in the kernel manual.
|| 1|| Review|| Team ||
|-
|| Ongoing kernel maintenance || There should be a task spread out over the whole release, say 10% of one person's time (just a guess), for monitoring LKML and Linus' master branch, and/or relevant lists for patches relevant to the BSPs we maintain. We also need to figure out if Bruce needs help with the management of the base branches e.g. re-enabling features after kernel uprevs, moving feature tags forward, etc.
|| 1|| Review|| Tom ||
|-
|| Tracing: perf trace scripting support || Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time. || 2 || Review || from 1.0 ||
|-
|| Tracing: Add Systemtap support for userspace tracing || Add utrace, etc || 2 || Review || Tom ||
|-
|| Tracing: Systemtap usability in Yocto || Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable 'out of the box' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar || 2 || Review || Tom ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}