poky.conf: Bumping SKD_VERSION

SDK_VERSION needs a bump for 1.1.1 release

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>

.gitignore

@@ -9,11 +9,9 @@ build*/pyshtables.py
 pstage/
 scripts/oe-git-proxy-socks
 sources/
-meta-darwin
-meta-maemo
-meta-extras
-meta-m2
-meta-prvt*
+meta-*
+!meta-skeleton
+!meta-demoapps
 *.swp
 *.orig
 *.rej

README.hardware

@@ -68,12 +68,12 @@ Intel Atom based PCs and devices (atom-pc)
 
 The atom-pc MACHINE is tested on the following platforms:
 
-  o Asus eee901
+  o Asus EeePC 901
   o Acer Aspire One
   o Toshiba NB305
   o Intel Embedded Development Board 1-N450 (Black Sand)
 
-and is likely to work on many unlisted atom based devices. The MACHINE type
+and is likely to work on many unlisted Atom based devices. The MACHINE type
 supports ethernet, wifi, sound, and i915 graphics by default in addition to
 common PC input devices, busses, and so on.
 
@@ -83,26 +83,18 @@ straightforward with a caveat for USB devices. The following examples assume the
 target boot device is /dev/sdb, be sure to verify this and use the correct
 device as the following commands are run as root and are not reversable.
 
-Hard Disk:
-  1. Build a directdisk image format. This will generate proper partition tables
-     that will in turn be written to the physical media. For example:
-
-     $ bitbake core-image-minimal-directdisk
-  
-  2. Use the "dd" utility to write the image to the raw block device. For example:
-
-     # dd if=core-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb
-
 USB Device:
-  1. Build an hddimg image format. This is a simple filesystem without partition
-     tables and is suitable for USB keys. For example:
+  1. Build a live image. This image type consists of a simple filesystem
+     without a partition table, which is suitable for USB keys, and with the
+     default setup for the atom-pc machine, this image type is built
+     automatically for any image you build. For example:
 
-     $ bitbake core-image-minimal-live
+     $ bitbake core-image-minimal
 
   2. Use the "dd" utility to write the image to the raw block device. For
      example:
 
-     # dd if=core-image-minimal-live-atom-pc.hddimg of=/dev/sdb
+     # dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb
 
   If the device fails to boot with "Boot error" displayed, it is likely the BIOS
   cannot understand the physical layout of the disk (or rather it expects a
@@ -126,7 +118,7 @@ USB Device:
 
      b. Copy the contents of the poky image to the USB-ZIP mode device:
 
-     # mount -o loop core-image-minimal-live-atom-pc.hddimg  /tmp/image
+     # mount -o loop core-image-minimal-atom-pc.hddimg  /tmp/image
      # mount /dev/sdb4 /tmp/usbkey
      # cp -rf /tmp/image/* /tmp/usbkey
 
@@ -150,7 +142,7 @@ faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
 the NAND flash. The beagleboard MACHINE is tested on the following platforms:
 
   o Beagleboard C4
-  o Beagleboard xM Rev A
+  o Beagleboard xM rev A & B
 
 The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
 these instructions assume you have erased the NAND on the C4 so its boot

bitbake/bin/bitbake-runtask

@@ -4,6 +4,10 @@ import os
 import sys
 import warnings
 sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
+from bb import fetch2
+import logging
+
+logger = logging.getLogger("BitBake")
 
 try:
     import cPickle as pickle
@@ -16,13 +20,20 @@ class BBConfiguration(object):
     Manages build options and configurations for one run
     """
 
-    def __init__(self, debug, debug_domains):
-        setattr(self, "data", {})
-        setattr(self, "file", [])
-        setattr(self, "cmd", None)
-        setattr(self, "dump_signatures", True)
-        setattr(self, "debug", debug)
-        setattr(self, "debug_domains", debug_domains)
+    def __init__(self, **options):
+        self.data = {}
+        self.file = []
+        self.cmd = None
+        self.dump_signatures = True
+        self.prefile = []
+        self.postfile = []
+        self.parse_only = True
+
+    def __getattr__(self, attribute):
+        try:
+            return super(BBConfiguration, self).__getattribute__(attribute)
+        except AttributeError:
+            return None
 
 _warnings_showwarning = warnings.showwarning
 def _showwarning(message, category, filename, lineno, file=None, line=None):
@@ -39,82 +50,70 @@ warnings.showwarning = _showwarning
 warnings.simplefilter("ignore", DeprecationWarning)
 
 import bb.event
-
-# Need to map our I/O correctly. stdout is a pipe to the server expecting 
-# events. We save this and then map stdout to stderr.
-
-eventfd = os.dup(sys.stdout.fileno())
-bb.event.worker_pipe = os.fdopen(eventfd, 'w', 0)
-
-# map stdout to stderr
-os.dup2(sys.stderr.fileno(), sys.stdout.fileno())
-
-# Replace those fds with our own
-#logout = data.expand("${TMPDIR}/log/stdout.%s" % os.getpid(), self.cfgData, True)
-#mkdirhier(os.path.dirname(logout))
-#newso = open("/tmp/stdout.%s" % os.getpid(), 'w')
-#os.dup2(newso.fileno(), sys.stdout.fileno())
-#os.dup2(newso.fileno(), sys.stderr.fileno())
-
-# Don't read from stdin from the parent
-si = file("/dev/null", 'r')
-os.dup2(si.fileno( ), sys.stdin.fileno( ))
-
-# We don't want to see signals to our parent, e.g. Ctrl+C
-os.setpgrp()
-
-# Save out the PID so that the event can include it the
-# events
-bb.event.worker_pid = os.getpid()
-bb.event.useStdout = False
-
-hashfile = sys.argv[1]
-buildfile = sys.argv[2]
-taskname = sys.argv[3]
-
 import bb.cooker
 
-p = pickle.Unpickler(file(hashfile, "rb"))
-hashdata = p.load()
+buildfile = sys.argv[1]
+taskname = sys.argv[2]
+if len(sys.argv) >= 4:
+    dryrun = sys.argv[3]    
+else:
+    dryrun = False
+if len(sys.argv) >= 5:
+    hashfile = sys.argv[4]
+    p = pickle.Unpickler(file(hashfile, "rb"))
+    hashdata = p.load()
+else:
+    hashdata = None
 
-debug = hashdata["msg-debug"]
-debug_domains = hashdata["msg-debug-domains"]
-verbose = hashdata["verbose"]
+handler = bb.event.LogHandler()
+logger.addHandler(handler)
 
-bb.utils.init_logger(bb.msg, verbose, debug, debug_domains)
+#An example to make debug log messages show up
+#bb.msg.init_msgconfig(True, 3, [])
 
-cooker = bb.cooker.BBCooker(BBConfiguration(debug, debug_domains), None)
-cooker.parseConfiguration()
+console = logging.StreamHandler(sys.stdout)
+format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+bb.msg.addDefaultlogFilter(console)
+console.setFormatter(format)
 
-cooker.bb_cache = bb.cache.init(cooker)
-cooker.status = bb.cache.CacheData()
+def worker_fire(event, d):
+    if isinstance(event, logging.LogRecord):
+        console.handle(event)
+bb.event.worker_fire = worker_fire
+bb.event.worker_pid = os.getpid()
 
-(fn, cls) = cooker.bb_cache.virtualfn2realfn(buildfile)
+initialenv = os.environ.copy()
+config = BBConfiguration()
+
+def register_idle_function(self, function, data):
+    pass
+
+cooker = bb.cooker.BBCooker(config, register_idle_function, initialenv)
+config_data = cooker.configuration.data
+cooker.status = config_data
+cooker.handleCollections(bb.data.getVar("BBFILE_COLLECTIONS", config_data, 1))
+
+fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
 buildfile = cooker.matchFile(fn)
-fn = cooker.bb_cache.realfn2virtual(buildfile, cls)
+fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
 
 cooker.buildSetVars()
 
 # Load data into the cache for fn and parse the loaded cache data
-the_data = cooker.bb_cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
-cooker.bb_cache.setData(fn, buildfile, the_data)
-cooker.bb_cache.handle_data(fn, cooker.status)
-
-#exportlist = bb.utils.preserved_envvars_export_list()
-#bb.utils.filter_environment(exportlist)
+the_data = bb.cache.Cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
 
 if taskname.endswith("_setscene"):
     the_data.setVarFlag(taskname, "quieterrors", "1")
 
-bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
-
-for h in hashdata["hashes"]:
-    bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
-for h in hashdata["deps"]:
-    bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
+if hashdata:
+    bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
+    for h in hashdata["hashes"]:
+        bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
+    for h in hashdata["deps"]:
+        bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
 
 ret = 0
-if sys.argv[4] != "True":
+if dryrun != "True":
     ret = bb.build.exec_task(fn, taskname, the_data)
 sys.exit(ret)
 

bitbake/lib/bb/build.py

@@ -149,8 +149,7 @@ def exec_func(func, d, dirs = None):
         adir = dirs[-1]
     else:
         adir = data.getVar('B', d, 1)
-        if not os.path.exists(adir):
-            adir = None
+        bb.utils.mkdirhier(adir)
 
     ispython = flags.get('python')
     if flags.get('fakeroot') and not flags.get('task'):

bitbake/lib/bb/codeparser.py

@@ -150,117 +150,79 @@ def parser_cache_savemerge(d):
     bb.utils.unlockfile(glf)
 
 
+Logger = logging.getLoggerClass()
+class BufferedLogger(Logger):
+    def __init__(self, name, level=0, target=None):
+        Logger.__init__(self, name)
+        self.setLevel(level)
+        self.buffer = []
+        self.target = target
+
+    def handle(self, record):
+        self.buffer.append(record)
+
+    def flush(self):
+        for record in self.buffer:
+            self.target.handle(record)
+        self.buffer = []
+
 class PythonParser():
-    class ValueVisitor():
-        """Visitor to traverse a python abstract syntax tree and obtain
-        the variables referenced via bitbake metadata APIs, and the external
-        functions called.
+    getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
+    execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
+
+    def warn(self, func, arg):
+        """Warn about calls of bitbake APIs which pass a non-literal
+        argument for the variable name, as we're not able to track such
+        a reference.
         """
 
-        getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
-        expands = ("d.expand", "bb.data.expand", "data.expand")
-        execs = ("bb.build.exec_func", "bb.build.exec_task")
+        try:
+            funcstr = codegen.to_source(func)
+            argstr = codegen.to_source(arg)
+        except TypeError:
+            self.log.debug(2, 'Failed to convert function and argument to source form')
+        else:
+            self.log.debug(1, self.unhandled_message % (funcstr, argstr))
 
-        @classmethod
-        def _compare_name(cls, strparts, node):
-            """Given a sequence of strings representing a python name,
-            where the last component is the actual Name and the prior
-            elements are Attribute nodes, determine if the supplied node
-            matches.
-            """
+    def visit_Call(self, node):
+        name = self.called_node_name(node.func)
+        if name in self.getvars:
+            if isinstance(node.args[0], ast.Str):
+                self.var_references.add(node.args[0].s)
+            else:
+                self.warn(node.func, node.args[0])
+        elif name in self.execfuncs:
+            if isinstance(node.args[0], ast.Str):
+                self.var_execs.add(node.args[0].s)
+            else:
+                self.warn(node.func, node.args[0])
+        elif name and isinstance(node.func, (ast.Name, ast.Attribute)):
+            self.execs.add(name)
 
-            if not strparts:
-                return True
-
-            current, rest = strparts[0], strparts[1:]
+    def called_node_name(self, node):
+        """Given a called node, return its original string form"""
+        components = []
+        while node:
             if isinstance(node, ast.Attribute):
-                if current == node.attr:
-                    return cls._compare_name(rest, node.value)
+                components.append(node.attr)
+                node = node.value
             elif isinstance(node, ast.Name):
-                if current == node.id:
-                    return True
-            return False
-
-        @classmethod
-        def compare_name(cls, value, node):
-            """Convenience function for the _compare_node method, which
-            can accept a string (which is split by '.' for you), or an
-            iterable of strings, in which case it checks to see if any of
-            them match, similar to isinstance.
-            """
-
-            if isinstance(value, basestring):
-                return cls._compare_name(tuple(reversed(value.split("."))),
-                                         node)
+                components.append(node.id)
+                return '.'.join(reversed(components))
             else:
-                return any(cls.compare_name(item, node) for item in value)
+                break
 
-        def __init__(self, value):
-            self.var_references = set()
-            self.var_execs = set()
-            self.direct_func_calls = set()
-            self.var_expands = set()
-            self.value = value
-
-        @classmethod
-        def warn(cls, func, arg):
-            """Warn about calls of bitbake APIs which pass a non-literal
-            argument for the variable name, as we're not able to track such
-            a reference.
-            """
-
-            try:
-                funcstr = codegen.to_source(func)
-                argstr = codegen.to_source(arg)
-            except TypeError:
-                logger.debug(2, 'Failed to convert function and argument to source form')
-            else:
-                logger.debug(1, "Warning: in call to '%s', argument '%s' is "
-                                "not a literal", funcstr, argstr)
-
-        def visit_Call(self, node):
-            if self.compare_name(self.getvars, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.var_references.add(node.args[0].s)
-                else:
-                    self.warn(node.func, node.args[0])
-            elif self.compare_name(self.expands, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.warn(node.func, node.args[0])
-                    self.var_expands.update(node.args[0].s)
-                elif isinstance(node.args[0], ast.Call) and \
-                     self.compare_name(self.getvars, node.args[0].func):
-                    pass
-                else:
-                    self.warn(node.func, node.args[0])
-            elif self.compare_name(self.execs, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.var_execs.add(node.args[0].s)
-                else:
-                    self.warn(node.func, node.args[0])
-            elif isinstance(node.func, ast.Name):
-                self.direct_func_calls.add(node.func.id)
-            elif isinstance(node.func, ast.Attribute):
-                # We must have a qualified name.  Therefore we need
-                # to walk the chain of 'Attribute' nodes to determine
-                # the qualification.
-                attr_node = node.func.value
-                identifier = node.func.attr
-                while isinstance(attr_node, ast.Attribute):
-                    identifier = attr_node.attr + "." + identifier
-                    attr_node = attr_node.value
-                if isinstance(attr_node, ast.Name):
-                    identifier = attr_node.id + "." + identifier
-                self.direct_func_calls.add(identifier)
-
-    def __init__(self):
-        #self.funcdefs = set()
+    def __init__(self, name, log):
+        self.var_references = set()
+        self.var_execs = set()
         self.execs = set()
-        #self.external_cmds = set()
         self.references = set()
+        self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
+
+        self.unhandled_message = "in call of %s, argument '%s' is not a string literal"
+        self.unhandled_message = "while parsing %s, %s" % (name, self.unhandled_message)
 
     def parse_python(self, node):
-
         h = hash(str(node))
 
         if h in pythonparsecache:
@@ -271,24 +233,25 @@ class PythonParser():
         code = compile(check_indent(str(node)), "<string>", "exec",
                        ast.PyCF_ONLY_AST)
 
-        visitor = self.ValueVisitor(code)
         for n in ast.walk(code):
             if n.__class__.__name__ == "Call":
-                visitor.visit_Call(n)
+                self.visit_Call(n)
 
-        self.references.update(visitor.var_references)
-        self.references.update(visitor.var_execs)
-        self.execs = visitor.direct_func_calls
+        self.references.update(self.var_references)
+        self.references.update(self.var_execs)
 
         pythonparsecache[h] = {}
         pythonparsecache[h]["refs"] = self.references
         pythonparsecache[h]["execs"] = self.execs
 
 class ShellParser():
-    def __init__(self):
+    def __init__(self, name, log):
         self.funcdefs = set()
         self.allexecs = set()
         self.execs = set()
+        self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
+        self.unhandled_template = "unable to handle non-literal command '%s'"
+        self.unhandled_template = "while parsing %s, %s" % (name, self.unhandled_template)
 
     def parse_shell(self, value):
         """Parse the supplied shell code in a string, returning the external
@@ -403,8 +366,7 @@ class ShellParser():
 
                 cmd = word[1]
                 if cmd.startswith("$"):
-                    logger.debug(1, "Warning: execution of non-literal "
-                                    "command '%s'", cmd)
+                    self.log.debug(1, self.unhandled_template % cmd)
                 elif cmd == "eval":
                     command = " ".join(word for _, word in words[1:])
                     self.parse_shell(command)

bitbake/lib/bb/cooker.py

@@ -288,7 +288,9 @@ class BBCooker:
             self.status = bb.cache.CacheData(self.caches_array)
             self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
 
-            fn = self.matchFile(buildfile)
+            fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
+            fn = self.matchFile(fn)
+            fn = bb.cache.Cache.realfn2virtual(fn, cls)
         elif len(pkgs_to_build) == 1:
             self.updateCache()
 

bitbake/lib/bb/data.py

@@ -49,6 +49,7 @@ from bb import data_smart
 from bb import codeparser
 import bb
 
+logger = data_smart.logger
 _dict_type = data_smart.DataSmart
 
 def init():
@@ -258,7 +259,7 @@ def emit_func(func, o=sys.__stdout__, d = init()):
         emit_var(key, o, d, False) and o.write('\n')
 
     emit_var(func, o, d, False) and o.write('\n')
-    newdeps = bb.codeparser.ShellParser().parse_shell(d.getVar(func, True))
+    newdeps = bb.codeparser.ShellParser(func, logger).parse_shell(d.getVar(func, True))
     seen = set()
     while newdeps:
         deps = newdeps
@@ -267,39 +268,45 @@ def emit_func(func, o=sys.__stdout__, d = init()):
         for dep in deps:
             if bb.data.getVarFlag(dep, "func", d):
                emit_var(dep, o, d, False) and o.write('\n')
-               newdeps |=  bb.codeparser.ShellParser().parse_shell(d.getVar(dep, True))
+               newdeps |=  bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
         newdeps -= seen
 
 def update_data(d):
     """Performs final steps upon the datastore, including application of overrides"""
     d.finalize()
 
-def build_dependencies(key, keys, shelldeps, d):
+def build_dependencies(key, keys, shelldeps, vardepvals, d):
     deps = set()
+    vardeps = d.getVarFlag(key, "vardeps", True)
     try:
-        if d.getVarFlag(key, "func"):
+        value = d.getVar(key, False)
+        if key in vardepvals:
+           value =  d.getVarFlag(key, "vardepvalue", True)
+        elif d.getVarFlag(key, "func"):
             if d.getVarFlag(key, "python"):
-                parsedvar = d.expandWithRefs(d.getVar(key, False), key)
-                parser = bb.codeparser.PythonParser()
+                parsedvar = d.expandWithRefs(value, key)
+                parser = bb.codeparser.PythonParser(key, logger)
                 parser.parse_python(parsedvar.value)
                 deps = deps | parser.references
             else:
-                parsedvar = d.expandWithRefs(d.getVar(key, False), key)
-                parser = bb.codeparser.ShellParser()
+                parsedvar = d.expandWithRefs(value, key)
+                parser = bb.codeparser.ShellParser(key, logger)
                 parser.parse_shell(parsedvar.value)
                 deps = deps | shelldeps
+            if vardeps is None:
+                parser.log.flush()
             deps = deps | parsedvar.references
             deps = deps | (keys & parser.execs) | (keys & parsedvar.execs)
         else:
-            parser = d.expandWithRefs(d.getVar(key, False), key)
+            parser = d.expandWithRefs(value, key)
             deps |= parser.references
             deps = deps | (keys & parser.execs)
-        deps |= set((d.getVarFlag(key, "vardeps", True) or "").split())
+        deps |= set((vardeps or "").split())
         deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
     except:
         bb.note("Error expanding variable %s" % key)
         raise
-    return deps
+    return deps, value
     #bb.note("Variable %s references %s and calls %s" % (key, str(deps), str(execs)))
     #d.setVarFlag(key, "vardeps", deps)
 
@@ -307,12 +314,14 @@ def generate_dependencies(d):
 
     keys = set(key for key in d.keys() if not key.startswith("__"))
     shelldeps = set(key for key in keys if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
+    vardepvals = set(key for key in keys if d.getVarFlag(key, "vardepvalue"))
 
     deps = {}
+    values = {}
 
     tasklist = bb.data.getVar('__BBTASKS', d) or []
     for task in tasklist:
-        deps[task] = build_dependencies(task, keys, shelldeps, d)
+        deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
         newdeps = deps[task]
         seen = set()
         while newdeps:
@@ -321,11 +330,11 @@ def generate_dependencies(d):
             newdeps = set()
             for dep in nextdeps:
                 if dep not in deps:
-                    deps[dep] = build_dependencies(dep, keys, shelldeps, d)
+                    deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, vardepvals, d)
                 newdeps |=  deps[dep]
             newdeps -= seen
         #print "For %s: %s" % (task, str(taskdeps[task]))
-    return tasklist, deps
+    return tasklist, deps, values
 
 def inherits_class(klass, d):
     val = getVar('__inherit_cache', d) or []

bitbake/lib/bb/data_smart.py

@@ -68,8 +68,14 @@ class VariableParse:
             code = match.group()[3:-1]
             codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
 
-            parser = bb.codeparser.PythonParser()
+            parser = bb.codeparser.PythonParser(self.varname, logger)
             parser.parse_python(code)
+            if self.varname:
+                vardeps = self.d.getVarFlag(self.varname, "vardeps", True)
+                if vardeps is None:
+                    parser.log.flush()
+            else:
+                parser.log.flush()
             self.references |= parser.references
             self.execs |= parser.execs
 

bitbake/lib/bb/fetch2/__init__.py

@@ -197,6 +197,7 @@ def uri_replace(ud, uri_find, uri_replace, d):
     uri_decoded = list(decodeurl(ud.url))
     uri_find_decoded = list(decodeurl(uri_find))
     uri_replace_decoded = list(decodeurl(uri_replace))
+    logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, uri_find_decoded, uri_replace_decoded))
     result_decoded = ['', '', '', '', '', {}]
     for i in uri_find_decoded:
         loc = uri_find_decoded.index(i)
@@ -209,12 +210,18 @@ def uri_replace(ud, uri_find, uri_replace, d):
                     result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
                 if uri_find_decoded.index(i) == 2:
                     if ud.mirrortarball:
-                        result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.mirrortarball))
+                        if result_decoded[loc].endswith("/"):
+                            result_decoded[loc] = os.path.dirname(result_decoded[loc])
+                        result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.mirrortarball))
                     elif ud.localpath:
-                        result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.localpath))
+                        if result_decoded[loc].endswith("/"):
+                            result_decoded[loc] = os.path.dirname(result_decoded[loc])
+                        result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.localpath))
             else:
                 return ud.url
-    return encodeurl(result_decoded)
+    result = encodeurl(result_decoded)
+    logger.debug(2, "For url %s returning %s" % (ud.url, result))
+    return result
 
 methods = []
 urldata_cache = {}
@@ -385,7 +392,8 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
     exportvars = ['PATH', 'GIT_PROXY_COMMAND', 'GIT_PROXY_HOST',
                   'GIT_PROXY_PORT', 'GIT_CONFIG', 'http_proxy', 'ftp_proxy',
                   'https_proxy', 'no_proxy', 'ALL_PROXY', 'all_proxy',
-                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME']
+                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME',
+                  'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
 
     for var in exportvars:
         val = bb.data.getVar(var, d, True)

bitbake/lib/bb/fetch2/git.py

@@ -190,7 +190,7 @@ class Git(FetchMethod):
                 logger.debug(1, "No Origin")
 
             runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d)
-            fetch_cmd = "%s fetch --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
+            fetch_cmd = "%s fetch -f --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
             bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             runfetchcmd(fetch_cmd, d)
             runfetchcmd("%s prune-packed" % ud.basecmd, d)
@@ -220,7 +220,7 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        runfetchcmd("git clone -s -n %s %s" % (ud.clonedir, destdir), d)
+        runfetchcmd("git clone -s -n %s/ %s" % (ud.clonedir, destdir), d)
         if not ud.nocheckout:
             os.chdir(destdir)
             if subdir != "":

bitbake/lib/bb/fetch2/local.py

@@ -50,9 +50,6 @@ class Local(FetchMethod):
         path = url.split("://")[1]
         path = path.split(";")[0]
         newpath = path
-        dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
-        if os.path.exists(dldirfile):
-            return dldirfile
         if path[0] != "/":
             filespath = data.getVar('FILESPATH', d, True)
             if filespath:
@@ -62,6 +59,7 @@ class Local(FetchMethod):
                 if filesdir:
                     newpath = os.path.join(filesdir, path)
         if not os.path.exists(newpath) and path.find("*") == -1:
+            dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
             return dldirfile
         return newpath
 

bitbake/lib/bb/parse/parse_py/BBHandler.py

@@ -148,7 +148,7 @@ def handle(fn, d, include):
 
     # DONE WITH PARSING... time to evaluate
     if ext != ".bbclass":
-        data.setVar('FILE', fn, d)
+        data.setVar('FILE', abs_fn, d)
 
     statements.eval(d)
 

bitbake/lib/bb/parse/parse_py/ConfHandler.py

@@ -102,7 +102,7 @@ def handle(fn, data, include):
         feeder(lineno, s, fn, statements)
 
     # DONE WITH PARSING... time to evaluate
-    bb.data.setVar('FILE', fn, data)
+    bb.data.setVar('FILE', abs_fn, data)
     statements.eval(data)
     if oldfile:
         bb.data.setVar('FILE', oldfile, data)

bitbake/lib/bb/runqueue.py

@@ -1203,8 +1203,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 if task in self.rq.scenequeue_covered:
                     continue
                 if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
-                    self.rq.scenequeue_covered.add(task)
-                    found = True
+                    ok = True
+                    for revdep in self.rqdata.runq_revdeps[task]:
+                        if self.rqdata.runq_fnid[task] != self.rqdata.runq_fnid[revdep]:
+                            ok = False
+                            break
+                    if ok:
+                        found = True
+                        self.rq.scenequeue_covered.add(task)
 
         # Detect when the real task needs to be run anyway by looking to see
         # if any of its dependencies within the same package are scheduled
@@ -1227,9 +1233,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
-        for task in self.rq.scenequeue_covered:
-            self.task_skip(task)
-
         event.fire(bb.event.StampUpdate(self.rqdata.target_pairs, self.rqdata.dataCache.stamp), self.cfgData)
 
         schedulers = self.get_schedulers()
@@ -1323,8 +1326,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
         task = self.sched.next()
         if task is not None:
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
-
             taskname = self.rqdata.runq_task[task]
+
+            if task in self.rq.scenequeue_covered:
+                logger.debug(2, "Setscene covered task %s (%s)", task,
+                                self.rqdata.get_user_idstring(task))
+                self.task_skip(task)
+                return True
+
             if self.rq.check_stamp_task(task, taskname):
                 logger.debug(2, "Stamp current task %s (%s)", task,
                                 self.rqdata.get_user_idstring(task))
@@ -1506,8 +1515,9 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
 
             for task in xrange(len(self.sq_revdeps)):
                 if task not in valid_new and task not in noexec:
+                    realtask = self.rqdata.runq_setscene[task]
                     logger.debug(2, 'No package found, so skipping setscene task %s',
-                                 self.rqdata.get_user_idstring(task))
+                                 self.rqdata.get_user_idstring(realtask))
                     self.task_failoutright(task)
 
         logger.info('Executing SetScene Tasks')
@@ -1580,7 +1590,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             taskname = self.rqdata.runq_task[realtask] + "_setscene"
             if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask]):
                 logger.debug(2, 'Stamp for underlying task %s(%s) is current, so skipping setscene variant',
-                             task, self.rqdata.get_user_idstring(task))
+                             task, self.rqdata.get_user_idstring(realtask))
                 self.task_failoutright(task)
                 return True
 
@@ -1622,7 +1632,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         for task in oldcovered:
             self.rq.scenequeue_covered.add(self.rqdata.runq_setscene[task])
 
-        logger.debug(1, 'We can skip tasks %s', self.rq.scenequeue_covered)
+        logger.debug(1, 'We can skip tasks %s', sorted(self.rq.scenequeue_covered))
 
         self.rq.state = runQueueRunInit
         return True

bitbake/lib/bb/siggen.py

@@ -72,11 +72,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
     def _build_data(self, fn, d):
 
-        tasklist, gendeps = bb.data.generate_dependencies(d)
+        tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
 
         taskdeps = {}
         basehash = {}
-        lookupcache = {}
 
         for task in tasklist:
             data = d.getVar(task, False)
@@ -101,6 +100,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
             alldeps = seen - self.basewhitelist
 
             for dep in sorted(alldeps):
+                data = data + dep
                 if dep in lookupcache:
                     var = lookupcache[dep]
                 else:
@@ -135,7 +135,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         k = fn + "." + task
         data = dataCache.basetaskhash[k]
         self.runtaskdeps[k] = []
-        for dep in sorted(deps):
+        for dep in sorted(deps, key=clean_basepath):
             # We only manipulate the dependencies for packages not in the whitelist
             if self.twl and not self.twl.search(dataCache.pkg_fn[fn]):
                 # then process the actual dependencies
@@ -159,7 +159,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         k = fn + "." + task
         if runtime == "customfile":
             sigfile = stampbase
-        elif runtime:
+        elif runtime and k in self.taskhash:
             sigfile = stampbase + "." + task + ".sigdata" + "." + self.taskhash[k]
         else:
             sigfile = stampbase + "." + task + ".sigbasedata" + "." + self.basehash[k]
@@ -180,7 +180,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
             data['gendeps'][dep] = self.gendeps[fn][dep]
             data['varvals'][dep] = self.lookupcache[fn][dep]
 
-        if runtime:
+        if runtime and k in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[k]
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
@@ -217,19 +217,32 @@ def dump_this_task(outfile, d):
     task = "do_" + d.getVar("BB_CURRENTTASK", True)
     bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile")
 
+def clean_basepath(a):
+    if a.startswith("virtual:"):
+        b = a.rsplit(":", 1)[0] + a.rsplit("/", 1)[1]
+    else:
+        b = a.rsplit("/", 1)[1]
+    return b
+
+def clean_basepaths(a):
+    b = {}
+    for x in a:
+        b[clean_basepath(x)] = a[x]
+    return b
+
 def compare_sigfiles(a, b):
     p1 = pickle.Unpickler(file(a, "rb"))
     a_data = p1.load()
     p2 = pickle.Unpickler(file(b, "rb"))
     b_data = p2.load()
 
-    def dict_diff(a, b):
+    def dict_diff(a, b, whitelist=set()):
         sa = set(a.keys())
         sb = set(b.keys())
         common = sa & sb
         changed = set()
         for i in common:
-            if a[i] != b[i]:
+            if a[i] != b[i] and i not in whitelist:
                 changed.add(i)
         added = sa - sb
         removed = sb - sa
@@ -237,20 +250,23 @@ def compare_sigfiles(a, b):
 
     if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
         print "basewhitelist changed from %s to %s" % (a_data['basewhitelist'], b_data['basewhitelist'])
+        print "changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist'])
 
     if 'taskwhitelist' in a_data and a_data['taskwhitelist'] != b_data['taskwhitelist']:
         print "taskwhitelist changed from %s to %s" % (a_data['taskwhitelist'], b_data['taskwhitelist'])
+        print "changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist'])
 
     if a_data['taskdeps'] != b_data['taskdeps']:
-        print "Task dependencies changed from %s to %s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
+        print "Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
 
     if a_data['basehash'] != b_data['basehash']:
         print "basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash'])
 
-    changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'])
+    changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'], a_data['basewhitelist'] & b_data['basewhitelist'])
     if changed:
         for dep in changed:
             print "List of dependencies for variable %s changed from %s to %s" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep])
+            print "changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep])
     if added:
         for dep in added:
             print "Dependency on variable %s was added" % (dep)
@@ -265,7 +281,9 @@ def compare_sigfiles(a, b):
             print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
 
     if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
-        changed, added, removed = dict_diff(a_data['runtaskhashes'], b_data['runtaskhashes'])
+        a = clean_basepaths(a_data['runtaskhashes'])
+        b = clean_basepaths(b_data['runtaskhashes'])
+        changed, added, removed = dict_diff(a, b)
         if added:
             for dep in added:
                 print "Dependency on task %s was added" % (dep)
@@ -274,9 +292,10 @@ def compare_sigfiles(a, b):
                 print "Dependency on task %s was removed" % (dep)
         if changed:
             for dep in changed:
-                print "Hash for dependent task %s changed from %s to %s" % (dep, a_data['runtaskhashes'][dep], b_data['runtaskhashes'][dep])
+                print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
     elif 'runtaskdeps' in a_data and 'runtaskdeps' in b_data and sorted(a_data['runtaskdeps']) != sorted(b_data['runtaskdeps']):
         print "Tasks this task depends on changed from %s to %s" % (sorted(a_data['runtaskdeps']), sorted(b_data['runtaskdeps']))
+        print "changed items: %s" % a_data['runtaskdeps'].symmetric_difference(b_data['runtaskdeps'])
 
 def dump_sigfile(a):
     p1 = pickle.Unpickler(file(a, "rb"))

bitbake/lib/bb/ui/crumbs/hobprefs.py

@@ -39,6 +39,7 @@ class HobPrefs(gtk.Dialog):
             self.selected_image_types = handler.remove_image_output_type(ot)
 
         self.configurator.setConfVar('IMAGE_FSTYPES', "%s" % " ".join(self.selected_image_types).lstrip(" "))
+        self.reload_required = True
 
     def sdk_machine_combo_changed_cb(self, combo, handler):
         sdk_mach = combo.get_active_text()

bitbake/lib/bb/ui/crumbs/runningbuild.py

@@ -179,6 +179,10 @@ class RunningBuild (gobject.GObject):
             # that we need to attach to a task.
             self.tasks_to_iter[(package, task)] = i
 
+        # If we don't handle these the GUI does not proceed
+        elif isinstance(event, bb.build.TaskInvalid):
+            return
+
         elif isinstance(event, bb.build.TaskBase):
             current = self.tasks_to_iter[(package, task)]
             parent = self.tasks_to_iter[(package, None)]

bitbake/lib/bb/ui/hob.py

@@ -400,9 +400,9 @@ class MainWindow (gtk.Window):
         if response == gtk.RESPONSE_OK:
             rep.loadRecipe(recipe)
             self.save_path = recipe
+            self.model.load_image_rep(rep)
+            self.dirty = False
         chooser.destroy()
-        self.model.load_image_rep(rep)
-        self.dirty = False
 
     def bake_clicked_cb(self, button):
         build_image = True

bitbake/lib/bb/utils.py

@@ -443,7 +443,7 @@ def lockfile(name, shared=False, retry=True):
                     return lf
             lf.close()
         except Exception:
-            continue
+            pass
         if not retry:
             return None
 
@@ -505,7 +505,6 @@ def preserved_envvars_exported():
         'SHELL',
         'TERM',
         'USER',
-        'USERNAME',
     ]
 
 def preserved_envvars_exported_interactive():

documentation/Makefile

@@ -1,48 +1,61 @@
 # This is a single Makefile to handle all generated Yocto Project documents.
 # The Makefile needs to live in the documents directory and all figures used
-# in any manuals must be PNG files and live in the individual book's figures
-# directory.
+# in any manuals must be .PNG files and live in the individual book's figures
+# directory.  Note that the figures for the Yocto Project Development Manual
+# differ between the 'master' and 'edison' branches.
 #
 # The Makefile has these targets:
 #
-#    pdf: generates a PDF version of a manual.  Not valid for the Quick Start
-#    html: generates an HTML version of a manual.
-#    tarball: creates a tarball for the doc files.
+#    pdf:      generates a PDF version of a manual.  Not valid for the Quick Start
+#    html:     generates an HTML version of a manual.
+#    tarball:  creates a tarball for the doc files.
 #    validate: validates 
-#    publish: pushes generated files to the Yocto Project website
-#    clean: removes files
+#    publish:  pushes generated files to the Yocto Project website
+#    clean:    removes files
 #
 # The Makefile generates an HTML and PDF version of every document except the
 # Yocto Project Quick Start.  The Quick Start is in HTML form only.  The variable
-# The command-line argument DOC represents the folder name in which a particular 
-# document is stored.  The command-line argument VER represents the distro 
-# version of the Yocto Release for which the manuals are being generated.
+# DOC is used to indicate the folder name for a given manual. The variable
+# VER represents the distro version of the Yocto Release for which the manuals 
+# are being generated.  The variable BRANCH is used to indicate the 'edison'
+# branch and is used only when DOC=dev-manual (making the YP Development
+# Manual).  
+#
 # To build the HTML and PDF versions of the manual you must invoke the Makefile
 # with the DOC argument.  If you are going to publish the manual then you 
 # you must invoke the Makefile with both the DOC and the VER argument.
+# If you are building the 'edison' version of the YP DEvelopment Manual then
+# you must use the DOC and BRANCH arguments.  
 #
 # Examples:
 #
 #     make DOC=bsp-guide
 #     make DOC=yocto-project-qs
 #     make pdf DOC=poky-ref-manual
+#     make DOC=dev-manual BRANCH=edison
 #
 # The first example generates the HTML and PDF versions of the BSP Guide.
 # The second example generates the HTML version only of the Quick Start.  Note that 
 # the Quick Start only has an HTML version available.  The third example generates 
-# both the PDF and HTML versions of the Yocto Project Reference Manual.
+# both the PDF and HTML versions of the Yocto Project Reference Manual. The 
+# last example generates both the PDF and HTML 'edison' versions of the YP 
+# Development Manual.
 #
 # Use the publish target to push the generated manuals to the Yocto Project 
 # website.  All files needed for the manual's HTML form are pushed as well as the 
 # PDF version (if applicable).  
 # Examples:
 #
-#    make publish DOC=bsp-guide VER=1.1
-#    make publish DOC=adt-manual VER=1.1
+#    make publish DOC=bsp-guide VER=1.2
+#    make publish DOC=adt-manual VER=1.2
+#    make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
+#    make publish DOC=dev-manual VER=1.2 
 #
-# The first example publishes the 1.1 version of both the PDF and HTML versions of 
-# the BSP Guide.  The second example publishes the 1.1 version of both the PDF and 
-# HTML versions of the ADT Manual.
+# The first example publishes the 1.2 version of both the PDF and HTML versions of 
+# the BSP Guide.  The second example publishes the 1.2 version of both the PDF and 
+# HTML versions of the ADT Manual. The third example publishes the PDF and HTML
+# 'edison' versions of the YP Development Manual.  Finally, the last example publishes
+# the PDF and HTML 'master' versions of the YP Development Manual. 
 #
 
 ifeq ($(DOC),bsp-guide)
@@ -66,11 +79,32 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
            --stringparam  section.label.includes.component.label 1 \
            --xinclude
 ALLPREQ = html pdf tarball
-TARFILES = style.css dev-manual.html dev-manual.pdf figures/bsp-dev-flow.png figures/dev-title.png \
+#
+# Note that the tarfile might produce the "Cannot stat: No such file or directory" error
+# message for .PNG files that are not present when building a particular branch.  The 
+# list of files is all-inclusive for all branches.
+#
+
+	ifeq ($(BRANCH),edison)
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos.png figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png \
+           figures/kernel-example-repos-edison.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-edison.png \
+           figures/source-repos.png figures/yp-download.png \
            figures/wip.png
+	else
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3.png \
+           figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
+	endif
+
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css

documentation/adt-manual/adt-command.xml

@@ -12,9 +12,9 @@
         Toolchain Tarball)</link>".  
         And, that sourcing your architecture-specific environment setup script 
         initializes a suitable cross-toolchain development environment.  
-        This setup occurs by adding the compiler, QEMU scripts, QEMU binary, 
+        During the setup, locations for the compiler, QEMU scripts, QEMU binary, 
         a special version of <filename>pkgconfig</filename> and other useful 
-        utilities to the <filename>PATH</filename> variable.
+        utilities are added to the <filename>PATH</filename> variable.
         Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename> 
         are also defined so that, 
         for example, <filename>configure.sh</filename> can find pre-generated 

documentation/adt-manual/adt-eclipse.xml

@@ -53,10 +53,12 @@
         <para>
             Once you have downloaded the tarball, extract it into a clean 
             directory.
-            For example, the following command unpacks and installs the Eclipse IDE
+            For example, the following commands unpack and install the Eclipse IDE
+            tarball found in the <filename>Downloads</filename> area 
             into a clean directory using the default name <filename>eclipse</filename>:
             <literallayout class='monospaced'>
-     $ tar -xzvf ~/Downloads/Eclipse-SDK-3.7-linux-gtk-x86_64.tar.gz
+     $ cd ~
+     $ tar -xzvf ~/Downloads/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
             </literallayout>
         </para>
 
@@ -138,30 +140,36 @@
     </section>
 
     <section id='installing-the-eclipse-yocto-plug-in'>
-    <title>Installing the Eclipse Yocto Plug-in</title>
+    <title>Installing or Accessing the Eclipse Yocto Plug-in</title>
 
         <para>
-            You can install the Eclipse Yocto Plug-in one of three methods: as new software
-            from within the Eclipse IDE, from the Yocto Project source repositories, or as a built zip file.
+            You can install the Eclipse Yocto Plug-in into the Eclipse application
+            one of two ways:  using the Eclipse IDE and installing the plug-in as new software, or
+            using a built zip file.
+            If you don't want to permanently install the plug-in but just want to try it out
+            within the Eclipse environment, you can import the plug-in project from the 
+            Yocto Project source repositories.
         </para>
 
         <section id='new-software'>
-        <title>New Software</title>
+        <title>Installing the Plug-in as New Software</title>
 
             <para>
-                To install the Eclipse Yocto Plug-in directly into the Eclipse IDE, 
+                To install the Eclipse Yocto Plug-in as new software directly into the Eclipse IDE, 
                 follow these steps:
                 <orderedlist>
                     <listitem><para>Start up the Eclipse IDE.</para></listitem>
                     <listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem>
                     <listitem><para>Click "Add..." in the "Work with:" area.</para></listitem>
                     <listitem><para>Enter 
-                        <filename>http://www.yoctoproject.org/downloads/eclipse-plugin/1.1</filename> 
+                        <filename>http://downloads.yoctoproject.org/releases/eclipse-plugin/1.1.1</filename> 
                         in the URL field and provide a meaningful name in the "Name" field.</para></listitem>
                     <listitem><para>Click "OK" to have the entry added to the "Work with:" 
                         drop-down list.</para></listitem>
                     <listitem><para>Select the entry for the plug-in from the "Work with:" drop-down 
                         list.</para></listitem>
+                    <listitem><para>Check the box next to <filename>Development tools and SDKs for Yocto Linux</filename>.
+                        </para></listitem>
                     <listitem><para>Complete the remaining software installation steps and 
                         then restart the Eclipse IDE to finish the installation of the plug-in.
                         </para></listitem>
@@ -169,46 +177,8 @@
             </para>
         </section>
 
-
-        <section id='yocto-project-source'>
-        <title>Yocto Project Source</title>
-
-            <para>
-                To install the Eclipse Yocto Plug-in from the Yocto Project source repositories, 
-                follow these steps:
-                <orderedlist>
-                    <listitem><para>Open a shell and create a Git repository with:
-                        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
-                        </literallayout>
-                        For this example, the repository is named 
-                        <filename>~/yocto-eclipse</filename>.</para></listitem>
-                    <listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
-                    <listitem><para>Expand the "General" box and pick "existing projects into workspace".
-                        </para></listitem>
-                    <listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
-                        </para></listitem>
-                    <listitem><para>There will be three things there.
-                        Select each one and install one at a time.
-                        Do all three.</para></listitem>
-                    <listitem><para>Restart everything.</para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                At this point you should be able to invoke Eclipse from the shell using the following:
-                <literallayout class='monospaced'>
-     $ cd ~/eclipse
-     $ ./eclipse -vmargs -XX:PermSize=256M
-                </literallayout>
-                The left navigation pane shows the default projects. 
-                Right-click on one of these projects and run it as an Eclipse application.
-                This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
-           </para>
-       </section>
-
        <section id='zip-file-method'>
-       <title>Zip File Method</title>
+       <title>Installing the Plug-in from a Zip File</title>
             <para>
                 To install the Eclipse Yocto Plug-in by building and installing a plug-in 
                 zip file, follow these steps:
@@ -234,9 +204,9 @@
                         name of the Git branch along with the Yocto Project release you are 
                         using.
                         Here is an example that uses the <filename>master</filename> Git repository
-                        and the <filename>1.1M4</filename> release:
+                        and the <filename>1.1.1</filename> release:
                         <literallayout class='monospaced'>
-     $ scripts/build.sh master 1.1M4 
+     $ scripts/build.sh master 1.1.1 
                         </literallayout>
                         After running the script, the file
                         <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
@@ -247,22 +217,57 @@
                         </para></listitem>
                     <listitem><para>Click "Add".</para></listitem>
                     <listitem><para>Provide anything you want in the "Name" field.</para></listitem>
-                    <listitem><para>For the "Archive" field, select the ZIP file you built in step 
-                        4.
+                    <listitem><para>Click "Archive" and browse to the ZIP file you built 
+                        in step four.  
                         This ZIP file should not be "unzipped", and must be the 
                         <filename>*archive.zip</filename> file created by running the 
                         <filename>build.sh</filename> script.</para></listitem>
-                    <listitem><para>Select the new entry in the installation window and complete
+                    <listitem><para>Check the box next to the new entry in the installation window and complete
                         the installation.</para></listitem>
                     <listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
                 </orderedlist>
             </para>
 
             <para>
-                At this point you should be able to configure the Eclipse Yocto Plug-in as described in
-                the next section.
+                At this point you should be able to configure the Eclipse Yocto Plug-in as described in the
+                "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
+                section.</para>
+        </section>            
+
+        <section id='yocto-project-source'>
+        <title>Importing the Plug-in Project into the Eclipse Environment</title>
+            <para>
+                Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories
+                is useful when you want to try out the latest plug-in from the tip of plug-in's 
+                development tree.
+                It is important to understand when you import the plug-in you are not installing 
+                it into the Eclipse application.
+                Rather, you are importing the project and just using it.
+                To import the plug-in project, follow these steps:
+                <orderedlist>
+                    <listitem><para>Open a shell and create a Git repository with:
+                        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
+                        </literallayout>
+                        For this example, the repository is named 
+                        <filename>~/yocto-eclipse</filename>.</para></listitem>
+                    <listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
+                    <listitem><para>Expand the "General" box and select "existing projects into workspace"
+                        and then click "Next".</para></listitem>
+                    <listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
+                        </para></listitem>
+                    <listitem><para>There will be three things there.
+                        Select each one and install one at a time.
+                        Do all three.</para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                The left navigation pane in the Eclipse application shows the default projects. 
+                Right-click on one of these projects and run it as an Eclipse application.
+                This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
            </para>
-       </section>            
+       </section>
     </section>
 
     <section id='configuring-the-eclipse-yocto-plug-in'>
@@ -317,7 +322,7 @@
                         </para></listitem>
                     <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                         If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                        <filename>/opt/poky/1.1</filename> directory.
+                        <filename>/opt/poky/1.1.1</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
                         Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
                         and Running the ADT Installer Script</link>" and 
@@ -349,9 +354,8 @@
                         The pull-down menu should have the supported architectures.  
                         If the architecture you need is not listed in the menu, you 
                         will need to build the image.
-                        See the "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the  
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
-                        The Yocto Project Quick Start</ulink> for more information.</para></listitem>
+                        See the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section 
+                        of The Yocto Project Quick Start for more information.</para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -467,7 +471,9 @@
                 The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
                 <filename>autoconf</filename>, <filename>autoheader</filename>, 
                 <filename>automake --a</filename>, and 
-                <filename>./configure</filename>.</para></listitem>
+                <filename>./configure</filename>.
+                Click on the <filename>Console</filename> tab beneath your source code to 
+                see the results of reconfiguring your project.</para></listitem>
         </orderedlist>
     </para>
 </section>
@@ -490,7 +496,7 @@
             <listitem><para>Expose the <filename>Run -&gt; External Tools</filename> menu.
                 Your image should appear as a selectable menu item.
                 </para></listitem>
-            <listitem><para>Select your image in the navigation pane to launch the 
+            <listitem><para>Select your image from the menu to launch the 
                 emulator in a new window.</para></listitem>
             <listitem><para>If needed, enter your host root password in the shell window at the prompt.  
                 This sets up a <filename>Tap 0</filename> connection needed for running in user-space 
@@ -509,8 +515,8 @@
 <title>Deploying and Debugging the Application</title>
 
     <para>
-        Once the QEMU emulator is running the image, you can deploy your application and use the emulator 
-        to perform debugging.  
+        Once the QEMU emulator is running the image, using the Eclipse IDE 
+        you can deploy your application and use the emulator to perform debugging.  
         Follow these steps to deploy the application.
         <orderedlist>
             <listitem><para>Select <filename>Run -&gt; Debug Configurations...</filename></para></listitem>
@@ -550,7 +556,7 @@
         your development experience.  
         These tools are aids in developing and debugging applications and images.  
         You can run these user-space tools from within the Eclipse IDE through the 
-        <filename>Window -&gt; YoctoTools</filename> menu.
+        <filename>YoctoTools</filename> menu.
     </para>
 
     <para>

documentation/adt-manual/adt-intro.xml

@@ -114,7 +114,7 @@
                 <listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used 
                     to keep track of certain types of hardware and software events.  
                     For more information on these types of counters see 
-                    <ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click 
+                    <ulink url='https://perf.wiki.kernel.org/'></ulink> and click 
                     on “Perf tools.”</para></listitem>
                 <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure 
                     that simplifies information gathering about a running Linux system.  

documentation/adt-manual/adt-manual.xml

@@ -43,10 +43,15 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>2010-2012</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -58,7 +63,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
           Application Developer's Toolkit (ADT) User's Guide</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/adt-manual/adt-package.xml

@@ -54,9 +54,7 @@
 
     <note>
         For build performance information related to the PMS, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> 
-        in <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-        The Yocto Project Reference Manual</ulink>.
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
     </note>
 
     <para>

documentation/adt-manual/adt-prepare.xml

@@ -55,8 +55,10 @@
 
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
-                You can download the tarball into any directory from  
-                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/adt-installer/'></ulink>.
+                You can download the tarball into any directory from the 
+                <ulink url='http://downloads.yoctoproject.org/releases'>Index of Releases</ulink>, specifically
+                at  
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/adt_installer'></ulink>.
                 Or, you can use BitBake to generate the tarball inside the existing Yocto Project 
                 build tree.
             </para>
@@ -79,9 +81,9 @@
      $ cd ~
      $ mkdir yocto-project
      $ cd yocto-project
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
-     $ tar xjf poky-edison-6.0.tar.bz2
-     $ source poky-edison-6.0/oe-init-build-env
+     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
+     $ tar xjf poky-edison-6.0.1.tar.bz2
+     $ source poky-edison-6.0.1/oe-init-build-env
      $ bitbake adt-installer
                 </literallayout>
             </para>
@@ -93,6 +95,14 @@
             <para>
                 Before running the ADT Installer script, you need to unpack the tarball.
                 You can unpack the tarball in any directory you wish.
+                For example, this command copies the ADT Installer tarball from where 
+                it was built into the home directory and then unpacks the tarball into 
+                a top-level directory named <filename>adt-installer</filename>:
+                <literallayout class='monospaced'>
+     $ cd ~
+     $ cp ~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ tar -xjf adt_installer.tar.bz2
+                </literallayout>
                 Unpacking it creates the directory <filename>adt-installer</filename>, 
                 which contains the ADT Installer script (<filename>adt_installer</filename>)
                 and its configuration file (<filename>adt_installer.conf</filename>).
@@ -155,18 +165,19 @@
 
             <para>
                 After you have configured the <filename>adt_installer.conf</filename> file, 
-                run the installer using the following command:
+                run the installer for this example using the following commands:
                 <literallayout class='monospaced'>
-     $ adt_installer
+     $ cd ~/adt-installer
+     $ ./adt_installer
                 </literallayout>
             </para>
 
             <note>
                 The ADT Installer requires the <filename>libtool</filename> package to complete.  
                 If you install the recommended packages as described in the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
                 section of 
-                <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
                 The Yocto Project Quick Start</ulink>, then you will have libtool installed.
             </note>
 
@@ -181,7 +192,7 @@
             <para>
                 Once the installation completes, the ADT, which includes the cross-toolchain, is installed.
                 You will notice environment setup files for the cross-toolchain in 
-                <filename>/opt/poky/1.1</filename>,
+                <filename>/opt/poky/1.1.1</filename>,
                 and image tarballs in the <filename>adt-installer</filename>
                 directory according to your installer configurations, and the target sysroot located
                 according to the <filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> variable
@@ -204,9 +215,9 @@
             Follow these steps:
             <orderedlist>
                 <listitem><para>Go to  
-                    <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/toolchain'></ulink> 
+                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain'></ulink> 
                     and find the folder that matches your host development system 
-                    (i.e. <filename>i586</filename> for 32-bit machines or 
+                    (i.e. <filename>i686</filename> for 32-bit machines or 
                     <filename>x86_64</filename> for 64-bit machines).</para></listitem>
                 <listitem><para>Go into that folder and download the toolchain tarball whose name 
                     includes the appropriate target architecture.
@@ -214,7 +225,7 @@
                     you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the 
                     <filename>x86_64</filename> folder and download the following tarball:
                     <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-i586-toolchain-1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-1.1.1.tar.bz2
                     </literallayout>
                     <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
                         if you have a Yocto Project build tree.
@@ -231,9 +242,15 @@
                         </para></note></para></listitem>
                 <listitem><para>Make sure you are in the root directory with root privileges and then expand 
                     the tarball.  
-                    The tarball expands into <filename>/opt/poky/1.1</filename>.
+                    The tarball expands into <filename>/opt/poky/1.1.1</filename>.
                     Once the tarball is expanded, the cross-toolchain is installed.
                     You will notice environment setup files for the cross-toolchain in the directory.
+                    Here is an example where the tarball exists in the user's <filename>Downloads</filename>
+                    directory:
+                    <literallayout class='monospaced'>
+     # cd /
+     # tar -xjf /home/scottrif/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+                    </literallayout>     
                     </para></listitem>
             </orderedlist>
         </para>
@@ -270,7 +287,7 @@
                         command.</note></para></listitem>
                 <listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the 
                     cross-toolchain installation.
-                    <note>If change out of your working directory after you 
+                    <note>If you change out of your working directory after you 
                         <filename>source</filename> the environment setup script and before you run
                         the <filename>bitbake</filename> command, the command might not work. 
                         Be sure to run the <filename>bitbake</filename> command immediately 
@@ -294,21 +311,21 @@
         Before you can develop using the cross-toolchain, you need to set up the 
         cross-development environment by sourcing the toolchain's environment setup script.  
         If you used the ADT Installer or used an existing ADT tarball to install the ADT,
-        then you can find this script in the <filename>/opt/poky/1.1</filename>
+        then you can find this script in the <filename>/opt/poky/1.1.1</filename>
         directory.  
         If you installed the toolchain in the build tree, you can find the environment setup 
         script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
     </para>
 
     <para> 
-        Be sure to run the environment setup script that matches the architecture for 
+        Be sure to source the environment setup script that matches the architecture for 
         which you are developing.  
         Environment setup scripts begin with the string “<filename>environment-setup</filename>”
         and include as part of their name the architecture.  
-        For example, the toolchain environment setup script for a 64-bit IA-based architecture would 
-        be the following: 
+        For example, the command to source the toolchain environment setup script 
+        for a 64-bit IA-based machine would be the following: 
         <literallayout class='monospaced'>
-     /opt/poky/1.1/environment-setup-x86_64-poky-linux
+     $ source /opt/poky/1.1.1/environment-setup-x86_64-poky-linux
         </literallayout>
     </para>
 </section>
@@ -330,10 +347,8 @@
             To get the kernel and filesystem images, you either have to build them or download
             pre-built versions.
             You can find examples for both these situations in the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#test-run'>A
-            Quick Test Run</ulink>" section of   
-            <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
-            The Yocto Project Quick Start</ulink>.
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#test-run'>A
+            Quick Test Run</ulink>" section of The Yocto Project Quick Start.
         </para>
 
         <para> 
@@ -342,12 +357,10 @@
             <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>) 
             that you can use unaltered in the QEMU emulator.  
             These kernel images reside in the Yocto Project release 
-            area - <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'></ulink>
+            area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'></ulink>
             and are ideal for experimentation within Yocto Project.
             For information on the image types you can build using the Yocto Project, see the
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-            The Yocto Project Reference Manual</ulink>.
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in The Yocto Project Reference Manual.
         </para>
 
         <para>
@@ -363,7 +376,7 @@
             If you want to use a different image type that contains the <filename>tcf-agent</filename>, 
             you can do so one of two ways:
             <itemizedlist>
-                <listitem><para>Modify the <filename>conf/local.conf</filename> configuration in 
+                <listitem><para>Modify the <filename>conf/local.conf</filename> configuration file in 
                     the Yocto Project build directory and then rebuild the image.
                     With this method, you need to modify the <filename>EXTRA_IMAGE_FEATURES</filename>
                     variable to have the value of "tools-debug" before rebuilding the image. 
@@ -419,16 +432,17 @@
             To extract the root filesystem, first <filename>source</filename>
             the cross-development environment setup script and then 
             use the <filename>runqemu-extract-sdk</filename> command on the 
-            filesystem image. 
-            For example, the following commands set up the environment and then extract
+            filesystem image tarball. 
+            For example, the following commands set up the environment by sourcing 
+            the setup script from within the build directory and then extracting
             the root filesystem from a previously built filesystem image tarball named  
-            <filename>core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2</filename>.
+            <filename>core-image-sato-sdk-qemux86.tar.bz2</filename>.
             The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
             directory:
             <literallayout class='monospaced'>
      $ source $HOME/poky/build/tmp/environment-setup-i586-poky-linux
      $ runqemu-extract-sdk \
-        tmp/deploy/images/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        tmp/deploy/images/core-image-sato-sdk-qemux86.tar.bz2 \
         $HOME/qemux86-sato
             </literallayout>
             In this case, you could now point to the target sysroot at 

documentation/bsp-guide/bsp-guide.xml

@@ -55,10 +55,15 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>2010-2012</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -70,7 +75,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
+          <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
           Board Support Package (BSP) Developer's Guide</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/bsp-guide/bsp.xml

@@ -30,9 +30,9 @@
         <note>
             The information here does not provide an example of how to create a BSP.
             For examples on how to create a BSP, see the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
             The Yocto Project Development Manual</ulink>.
             You can also see the 
             <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
@@ -100,9 +100,9 @@
         "
                 </literallayout>
                 For more detailed information on layers, see the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>BitBake Layers</ulink>" section of the Yocto Project Reference Manual.
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>BitBake Layers</ulink>" section of the Yocto Project Reference Manual.
                 You can also see the detailed examples in the appendices of  
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
                 The Yocto Project Development Manual</ulink>.
             </para>
 
@@ -149,10 +149,7 @@
      meta-crownbay/recipes-core/tasks/task-core-tools.bbappend
      meta-crownbay/recipes-graphics/
      meta-crownbay/recipes-graphics/xorg-xserver/
-     meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
-     meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/
-     meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
@@ -407,7 +404,6 @@
                 For example, the Crown Bay BSP contains the following files that support 
                 building a BSP that supports and does not support the Intel EMGD:
                 <literallayout class='monospaced'>
-     meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
@@ -465,11 +461,11 @@
      KMACHINE_crownbay-noemgd  = "yocto/standard/crownbay"
      KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
+     SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
+     SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
 
-     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
-     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
+     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
+     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
                 This append file contains statements used to support the Crown Bay BSP for both
                 Intel EMGD and non-EMGD.
@@ -484,8 +480,8 @@
      KMACHINE_crownbay  = "yocto/standard/crownbay"
      KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
+     SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
+     SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
                 The append file defines <filename>crownbay</filename> as the compatible machine,
                 defines the <filename>KMACHINE</filename>, points to some configuration fragments
@@ -542,7 +538,7 @@
                 The configuration options will likely end up in that location anyway if the BSP gets 
                 added to the Yocto Project. 
                 For information on how to add these configurations directly, see  
-                <ulink url='http://yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+                <ulink url='http://yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.</para>
                 <para>
                 In general, however, the Yocto Project maintainers take care of moving the 

documentation/dev-manual/dev-manual-bsp-appendix.xml

@@ -10,8 +10,11 @@
     The example assumes the following:
     <itemizedlist>
         <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
-        <listitem><para>Use of the Crown Bay Board Support Package (BSP) as a base BSP from 
-            which to work from.</para></listitem>  
+        <listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from 
+            which to work.  
+            The example begins with the Crown Bay BSP as the starting point
+            but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
+            </para></listitem>  
         <listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
         <listitem><para>Example was developed on an Intel-based Core i7 platform running 
             Ubuntu 10.04 LTS released in April of 2010.</para></listitem>        
@@ -24,10 +27,30 @@
     <para>
         You need to have the Yocto Project files available on your host system.  
         You can get files through tarball extraction or by cloning the <filename>poky</filename>
-        Git repository.  
-        See the bulleted item
-        "<link linkend='local-yp-release'>Yocto Project Release</link>" 
-        for information on how to get these files.
+        Git repository.
+        The following paragraphs describe both methods.
+        For additional information, see the bulleted item
+        "<link linkend='local-yp-release'>Yocto Project Release</link>".
+    </para>
+
+    <para>
+        As mentioned, one way to get the Yocto Project files is to use Git to clone the 
+        <filename>poky</filename> repository:
+        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+        </literallayout> 
+        Alternatively, you can start with the downloaded Poky "edison" tarball:
+        <literallayout class='monospaced'>
+     $ tar xfj poky-edison-6.0.1.tar.bz2
+     $ cd poky
+        </literallayout> 
+        <note>If you're using the tarball method, you can ignore all the following steps that
+        ask you to carry out Git operations.  
+        You already have the results of those operations
+        in the form of the edison release tarballs.
+        Consequently, there is nothing left to do other than extract those tarballs into the 
+        proper locations.</note>
     </para>
 
     <para>
@@ -39,12 +62,11 @@
      $ git branch -a
      $ git tag -l
         </literallayout> 
-        For this example we are going to use the Yocto Project 1.1 Release, which is code
+        For this example we are going to use the Yocto Project 1.1.1 Release, which is code
         named "edison". 
         These commands create a local branch named <filename>edison</filename>
         that tracks the remote branch of the same name.
         <literallayout class='monospaced'>
-     $ cd poky
      $ git checkout -b edison origin/edison
      Switched to a new branch 'edison'
         </literallayout>
@@ -58,7 +80,12 @@
         For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
         <trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform 
         Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
-        The BSP layer is <filename>meta-crownbay</filename>.
+        The BSP layer is <filename>meta-crownbay</filename>.  
+        The base BSP is simply the BSP
+        we will be using as a starting point, so don't worry if you don't actually have Crown Bay
+        hardware.
+        The remainder of the example transforms the base BSP into a BSP that should be
+        able to boot on generic atom-pc (netbook) hardware.
     </para>
 
     <para>
@@ -73,27 +100,52 @@
     <para>
         You need to have the base BSP layer on your development system.  
         Similar to the local Yocto Project files, you can get the BSP 
-        layer one of two ways:  
+        layer a couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
         has the Yocto Project BSP layers.  
         You should use the same method that you used to get the local Yocto Project files earlier.
         See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get 
         the BSP files.
     </para>
-        
+
     <para>
-        This example assumes the local <filename>meta-intel</filename> Git repository is
-        inside the local <filename>poky</filename> Git repository.
-        The <filename>meta-intel</filename> Git repository contains all the metadata 
-        that supports BSP creation.
+        This example assumes the BSP layer will be located within a directory named
+        <filename>meta-intel</filename> contained within the <filename>poky</filename>
+        parent directory.  
+        The following steps will automatically create the
+        <filename>meta-intel</filename> directory and the contained meta-crownbay
+        starting point in both the Git and the tarball cases.
     </para>
 
     <para>
+        If you're using the Git method, you could do the following to create
+        the starting layout after you have made sure you are in the <filename>poky</filename>
+        directory created in the previous steps:
+        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/meta-intel.git
+     $ cd meta-intel
+        </literallayout> 
+        Alternatively, you can start with the downloaded <filename>meta-intel</filename>
+        edison tarball.
+        Again, be sure that you are already in the <filename>poky</filename> directory
+        as described previously:
+        <literallayout class='monospaced'>
+     $ tar xfj crownbay-noemgd-edison-6.0.1.tar.bz2
+     $ cd meta-intel
+        </literallayout> 
+    </para>
+        
+    <para>
+        The <filename>meta-intel</filename> directory contains all the metadata 
+        that supports BSP creation.  
+        If you're using the Git method, the following
+        step will switch to the edison metadata.
+        If you're using the tarball method, you already have the correct metadata and can 
+        skip to the next step.
         Because <filename>meta-intel</filename> is its own Git repository, you will want
         to be sure you are in the appropriate branch for your work.
         For this example we are going to use the <filename>edison</filename> branch. 
         <literallayout class='monospaced'>
-     $ cd meta-intel
      $ git checkout -b edison origin/edison
      Switched to a new branch 'edison'
         </literallayout>
@@ -112,15 +164,12 @@
 
     <para>  
         For this example, the new layer will be named <filename>meta-mymachine</filename>.  
-        The name must follow the BSP layer naming convention, which is 
+        The name should follow the BSP layer naming convention, which is 
         <filename>meta-&lt;name&gt;</filename>.  
-        The following example assumes your working directory is <filename>meta-intel</filename> 
+        The following assumes your working directory is <filename>meta-intel</filename> 
         inside the local Yocto Project files.  
-        If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting 
-        <filename>meta-crownbay</filename> directory structure to a location of your choice.
-        Good practice for a Git repository, however, is to just copy the new layer alongside 
-        the existing
-        BSP layers in the <filename>meta-intel</filename> Git repository:
+        To start your new layer, just copy the new layer alongside the existing
+        BSP layers in the <filename>meta-intel</filename> directory:
         <literallayout class='monospaced'>
      $ cp -a meta-crownbay/ meta-mymachine 
         </literallayout>
@@ -162,9 +211,14 @@
         </para>
 
         <para>
-            The next step makes changes to <filename>mymachine.conf</filename> itself.  
-            The only changes needed for this example are changes to the comment lines.
-            Here we simply substitute the Crown Bay name with an appropriate name.
+            Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
+            The only changes we want to make for this example are to the comment lines.  
+            Changing comments, of course, is never strictly necessary, but it's alway good form to make
+            them reflect reality as much as possible.
+
+            Here, simply substitute the Crown Bay name with an appropriate name for the BSP 
+            (<filename>mymachine</filename> in this case) and change the description to 
+            something that describes your hardware.
         </para>
 
         <para>
@@ -176,11 +230,12 @@
         </para>
 
         <para>
-            The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
+            The next configuration file in the new BSP layer we need to edit is
+            <filename>meta-mymachine/conf/layer.conf</filename>.
             This file identifies build information needed for the new layer.  
             You can see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>The Board 
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in  
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board 
             Support Packages (BSP) Development Guide</ulink>
             for more information on this configuration file.  
             Basically, we are changing the existing statements to work with our BSP. 
@@ -232,7 +287,7 @@
                 the remaining one that doesn't support EMGD.  
                 These commands take care of the <filename>recipes-bsp</filename> recipes:
                 <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd*
+     $ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
      $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
      meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
                 </literallayout>
@@ -248,7 +303,6 @@
                 be sure to rename remaining directories appropriately.  
                 The following commands clean up the <filename>recipes-graphics</filename> directory:
                 <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
      $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
      $ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
         meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine   
@@ -304,6 +358,10 @@
                 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
                 statements point to the exact commits used by the Yocto Project development team
                 in their source repositories that identify the right kernel for our hardware.
+                In other words, the <filename>SRCREV</filename> values are simply Git commit 
+                IDs that identify which commit on each
+                of the kernel branches (machine and meta) will be checked out and used to build
+                the kernel.
             </para>
  
             <para>
@@ -323,12 +381,12 @@
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
         "2247da9131ea7e46ed4766a69bb1353dba22f873"
      SRCREV_meta_pn-linux-yocto_crownbay ?= \
-        "67a46a608f47c19f16995be7de7b272025864b1b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
 
      SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
         "2247da9131ea7e46ed4766a69bb1353dba22f873"
      SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
-        "67a46a608f47c19f16995be7de7b272025864b1b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
 
@@ -343,24 +401,49 @@
             </para>
 
             <para>  
-                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>
+                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
                 we delete the two <filename>SRCREV</filename> statements that support 
                 EMGD (the top pair).
                 We also change the remaining pair to specify <filename>mymachine</filename>
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
+                In this case, because we're working with the edison branch of everything, we
+                need to use the <filename>SRCREV</filename> values for the atom-pc branch
+                that are associated with the edison release.  
+                To find those values, we need to find the <filename>SRCREV</filename>
+                values that edison uses for the atom-pc branch, which we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                file.
+            </para>
+
+            <para>  
+                The machine <filename>SRCREV</filename> we want is in the 
+                <filename>SRCREV_machine_atom-pc</filename> variable.  
+                The meta <filename>SRCREV</filename> isn't specified in this file, so it must be 
+                specified in the base kernel recipe in the
+                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
+                file, in the <filename>SRCREV_meta variable</filename> found there.  
+                It happens to be the same as the value we already inherited from the 
+                <filename>meta-crownbay</filename> BSP.
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
-        "06c798f25a19281d7fa944b14366dd75820ba009"
+        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \ 
-        "67a46a608f47c19f16995be7de7b272025864b1b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
 
             <para>
-                If you are familiar with Git repositories you probably won’t have trouble locating the 
+                In this example, we're using the <filename>SRCREV</filename> values we 
+                found already captured in the edison release because we're creating a BSP based on 
+                edison.  
+                If, instead, we had based our BSP on the master branches, we would want to use 
+                the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
+                We will not be doing that for this example.
+                However, if you do base a future BSP on master and
+                if you are familiar with Git repositories, you probably won’t have trouble locating the 
                 exact commit strings in the Yocto Project source repositories you need to change 
                 the <filename>SRCREV</filename> statements.  
                 You can find all the <filename>machine</filename> and <filename>meta</filename> 
@@ -394,19 +477,25 @@
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
+                Because we are using the atom-pc branch for this new BSP, we can also find
+                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                file we looked at in a previous step.  
+                In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
                 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_mymachine = "mymachine"
-     KMACHINE_mymachine  = "yocto/standard/mymachine"
+     KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
      KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
 
      SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "06c798f25a19281d7fa944b14366dd75820ba009"
+        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "67a46a608f47c19f16995be7de7b272025864b1b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
         </section>
@@ -485,14 +574,14 @@
 
     <para>
         The appendix 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
         Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information 
          on configuration variables.
     </para>
 </section>
 
 <section id='building-the-image-app'>
-    <title>Building the Image</title>
+    <title>Building and Booting the Image</title>
 
     <para>
         To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 
@@ -513,6 +602,65 @@
         If the build results in any type of error you should check for misspellings in the 
         files you changed or problems with your host development environment such as missing packages.
     </para>
+
+    <para>
+        Finally, once you have an image, you can try booting it from a device
+        (e.g. a USB device).
+        To prepare a bootable USB device, insert a USB flash drive into your build system and
+        copy the <filename>.hddimage</filename>, located in the 
+        <filename>poky/build/tmp/deploy/images</filename>
+        directory after a successful build to the flash drive.  
+        Assuming the USB flash drive takes device <filename>/dev/sdc</filename>, 
+        use <filename>dd</filename> to copy the live image to it.  
+        For example:
+        <literallayout class='monospaced'>
+     # dd if=core-image-sato-mymachine-20120111232235.hddimg of=/dev/sdc
+     # sync
+     # eject /dev/sdc
+        </literallayout>
+        You should now have a bootable USB flash device.  
+    </para>
+
+    <para>
+        Insert the device
+        into a bootable USB socket on the target, and power it on.  
+        The system should boot to the Sato graphical desktop.
+    </para>
+
+    <para>
+        For reference, the sato image produced by the previous steps for edison 
+        should look like the following in terms of size.
+        If your sato image is much different from this,
+        you probably made a mistake in one of the above steps:
+        <literallayout class='monospaced'>
+     358709248 2012-01-11 20:43 core-image-sato-mymachine-20120111232235.hddimg
+        </literallayout>
+        <note>The previous instructions are also present in the README that was copied
+        from meta-crownbay, which should also be updated to reflect the specifics of your
+        new BSP.  
+        That file and the <filename>README.hardware</filename> file in the top-level 
+        <filename>poky</filename> directory
+        also provides some suggestions for things to try if booting fails and produces
+        strange error messages.</note>
+    </para>
+
+    <para>
+        Because this new image is not in any way tailored to the system you're
+        booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
+        example, it might not be completely functional though it should at least boot to a text
+        prompt.  
+        Specifically, it might fail to boot into graphics without some tweaking.  
+        If this ends up being the case, a possible next step would be to replace the 
+        <filename>mymachine.conf</filename>
+        contents with the contents of <filename>atom-pc.conf</filename> and replace 
+        <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
+        in <filename>meta-yocto</filename> and see if it fares any better.  
+        In any case, following the previous steps should
+        probably give you a buildable and bootable image.  
+        Getting things working like you want
+        them to for your hardware will normally require some amount of experimentation with
+        configuration settings.
+    </para>
 </section>
 </appendix>
 

documentation/dev-manual/dev-manual-intro.xml

@@ -69,7 +69,7 @@
                 <listitem><para>Reference material.  
                     This type of material resides in an appropriate reference manual.  
                     For example, system variables are documented in the 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
                     Yocto Project Reference Manual</ulink>.</para></listitem>
                 <listitem><para>Detailed public information that is not specific to the Yocto Project.  
                     For example, exhaustive information on how to use Git is covered better through the 
@@ -90,27 +90,27 @@
                     </emphasis> The home page for the Yocto Project provides lots of information on the project 
                     as well as links to software and documentation.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
                     The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started 
                     with the Yocto Project quickly and start building an image.</para></listitem>
                 <listitem><para><emphasis> 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
                     The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
                     guide to the Yocto Project build component known as "Poky."  
                     The manual also contains a reference chapter on Board Support Package (BSP) 
                     layout.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
                     The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
                     This guide provides information that lets you get going with the ADT to 
                     develop projects using the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
                     The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
                     This guide defines the structure for BSP components.  
                     Having a commonly understood structure encourages standardization.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
                     The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
                     This manual describes the architecture of the Yocto Project kernel and provides 
                     some work flow examples.</para></listitem>

documentation/dev-manual/dev-manual-kernel-appendix.xml

@@ -65,7 +65,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-edison.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
@@ -75,9 +75,10 @@
                     <listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis> 
                         This area contains all the metadata that supports building images in the 
                         Yocto Project build environment - the local Yocto Project files.
-                        The local Yocto Project files Git repository also contains the build directory
-                        and a configuration directory that let you control the build.
-                        Note also that in this example, the repository also contains the 
+                        In this example, the local Yocto Project files Git repository also 
+                        contains the build directory, which contains the configuration directory 
+                        that lets you control the build.
+                        In this example, the repository also contains the 
                         <filename>poky-extras</filename> Git repository.</para>
                         <para>See the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>"
@@ -148,7 +149,7 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1 Release code named "edison", 
+                This example uses the Yocto Project 1.1.1 Release code named "edison", 
                 which maps to the <filename>edison</filename> branch in the repository. 
                 The following commands create and checkout the local <filename>edison</filename>
                 branch:
@@ -171,13 +172,34 @@
                 <filename>poky-extras</filename> Git Repository</link>" 
                 for information on how to get the <filename>poky-extras</filename> repository.
             </para>
+
+            <para>
+                Once you have the repository set up, 
+                you have many development branches from which you can work. 
+                From inside the repository you can see the branch names and the tag names used 
+                in the Git repository using either of the following two commands:
+                <literallayout class='monospaced'>
+     $ cd poky
+     $ git branch -a
+     $ git tag -l
+                </literallayout> 
+                This example uses the Yocto Project 1.1.1 Release code named "edison", 
+                which maps to the <filename>edison</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>edison</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b edison origin/edison
+     Branch edison set up to track remote branch edison from origin.
+     Switched to a new branch 'edison'
+                </literallayout>
+            </para>
         </section>
 
         <section id='setting-up-the-bare-clone-and-its-copy'>
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.0</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
@@ -189,13 +211,14 @@
                 The bare clone exists for the kernel build tools and simply as the receiving end 
                 of <filename>git push</filename>
                 commands after you make edits and commits inside the copy of the clone.
-                The copy (<filename>linux-yocto-3.0</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have 
                 a local branch created and checked out for your work.
                 This example uses <filename>common-pc-base</filename> as the local branch.
                 The following commands create and checkout the branch:
                 <literallayout class='monospaced'>
-     $ cd ~/linux-yocto-3.0
+     $ cd ~/my-linux-yocto-3.0-1.1.x-work
      $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
+     Checking out files: 100% (7289/7289), done.
      Branch common-pc-base set up to track remote branch 
         yocto/standard/common-pc/base from origin.
      Switched to a new branch 'common-pc-base'
@@ -225,8 +248,8 @@
                     of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and 
                     a half times the number of cores your machine supports.
                 </note>
-                The following two commands build the default <filename>qemux86</filename> image and 
-                <filename>source</filename> build environment setup script.
+                The following two commands <filename>source</filename> the build environment setup script
+                and build the default <filename>qemux86</filename> image.
                 If necessary, the script creates the build directory:
                 <literallayout class='monospaced'>
      $ cd ~/poky
@@ -289,7 +312,7 @@
 
             <para>
                 The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>linux-yocto-3.0</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
                 (the copy of the bare clone) in <filename>init</filename>.
                 This example simply inserts several <filename>printk</filename> statements
                 at the beginning of the <filename>calibrate_delay</filename> function.
@@ -414,13 +437,13 @@
                        <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
                        directory, you need to identify the location of the 
                        local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.0.git</filename>.
+                       <filename>linux-yocto-3.0-1.1.x.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.0.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the 
                        following statement.
                        Be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0.git
+     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
                        <filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
@@ -437,7 +460,8 @@
                Because all the kernel <filename>.bbappend</filename> files are parsed during the 
                build process regardless of whether you are using them or not, you should either 
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
-               <filename>.bbappend</filename> files, or you should simply remove all the files 
+               unused <filename>.bbappend</filename> files.
+               Alternatively, you can simply remove all the files 
                except the one your are using for the build 
                (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
            </note>            
@@ -508,46 +532,94 @@
                 in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
                 Code</link>" you should already have the Yocto Project files set up on your 
                 host machine.
+                If this is the case, go to then next section titled
+                "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
+                <filename>CONFIG_SMP</filename> Behavior</link>" and continue with the 
+                example.
             </para>
 
             <para>
                 If you don't have the Yocto Project files established on your system, 
-                See "<link linkend='setting-up-the-local-yocto-project-files-git-repository'>Setting 
-                Up the Local Yocto Project Files Git Repository</link>" for 
-                information.
-                To reconfigure the kernel, this is the only Git repository you need to have set up. 
+                you can get them through tarball extraction or by 
+                cloning the <filename>poky</filename> Git repository.  
+                This example uses <filename>poky</filename> as the root directory of the 
+                local Yocto Project files Git repository.
+                See the bulleted item
+                "<link linkend='local-yp-release'>Yocto Project Release</link>"
+                for information on how to get these files.
             </para>
 
-<!--
+            <para>
+                Once you have the repository set up, 
+                you have many development branches from which you can work. 
+                From inside the repository you can see the branch names and the tag names used 
+                in the Git repository using either of the following two commands:
+                <literallayout class='monospaced'>
+     $ cd poky
+     $ git branch -a
+     $ git tag -l
+                </literallayout> 
+                This example uses the Yocto Project 1.1.1 Release code named "edison", 
+                which maps to the <filename>edison</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>edison</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b edison origin/edison
+     Branch edison set up to track remote branch edison from origin.
+     Switched to a new branch 'edison'
+                </literallayout>
+            </para>
 
             <para>
-                If you took the time to work through the example that modifies the kernel source code 
-                in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
-                Code</link>" you are already set up to quickly work through this example.
-                If not, then work through the following list to prepare:
-                <itemizedlist>
-                    <listitem><para><emphasis>Understand the development environment:</emphasis>
-                        See "<link linkend='understanding-the-files-you-need'>Understanding 
-                        the Files You Need</link>" for information.</para></listitem>
-                    <listitem><para><emphasis>Set up the local Yocto Project files Git 
-                        repository:</emphasis>
-                        See "<link linkend='setting-up-the-local-yocto-project-files-git-repository'>Setting 
-                        Up the Local Yocto Project Files Git Repository</link>" for 
-                        information.</para></listitem>
-                    <listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git 
-                        repository:</emphasis>
-                        See "<link linkend='setting-up-the-poky-extras-git-repository'>Setting 
-                        Up <filename>poky-extras</filename> Git repository</link>" for
-                        information.</para></listitem>
-                    <listitem><para><emphasis>Set up the the bare clone and its copy:</emphasis>
-                        See "<link linkend='setting-up-the-bare-clone-and-its-copy'>Setting Up the 
-                        Bare Clone and its Copy</link>" for information.</para></listitem>
-                    <listitem><para><emphasis>Build the default QEMU kernel image:</emphasis>
-                        See "<link linkend='building-and-booting-the-default-qemu-kernel-image'>Building 
-                        and Booting the Default QEMU Kernel image</link>" for information.
-                        Do not boot the image in the QEMU emulator at this point.</para></listitem>
-                </itemizedlist>
-            </para> -->
+                Next, you need to build the default <filename>qemux86</filename> image that you 
+                can boot using QEMU.
+                <note>
+                    Because a full build can take hours, you should check two variables in the 
+                    <filename>build</filename> directory that is created after you source the 
+                    <filename>oe-init-build-env</filename> script.
+                    You can find these variables
+                    <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
+                    in the <filename>build/conf</filename> directory in the 
+                    <filename>local.conf</filename> configuration file.
+                    By default, these variables are commented out.
+                    If your host development system supports multi-core and multi-thread capabilities,
+                    you can uncomment these statements and set the variables to significantly shorten
+                    the full build time.
+                    As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number 
+                    of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and 
+                    a half times the number of cores your machine supports.
+                </note>
+                The following two commands <filename>source</filename> the build environment setup script
+                and build the default <filename>qemux86</filename> image.
+                If necessary, the script creates the build directory:
+                <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ source oe-init-build-env
+
+          ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         meta-toolchain-sdk
+         adt-installer
+         meta-ide-support
+
+     You can also run generated qemu images with a command like 'runqemu qemux86'
+                </literallayout>
+            </para>
+
+            <para>
+                The following <filename>bitbake</filename> command starts the build:
+                <literallayout class='monospaced'>
+     $ bitbake -k core-image-minimal
+                </literallayout>
+                <note>Be sure to check the settings in the <filename>local.conf</filename>
+                before starting the build.</note>
+            </para>
         </section>
 
         <section id='examining-the-default-config-smp-behavior'>
@@ -596,7 +668,7 @@
             <para>
                 After setting up the environment to run <filename>menuconfig</filename>, you are ready 
                 to use the tool to interactively change the kernel configuration.
-                In this example, we are basing our changes on the <filename>linux-yocto-3.0</filename>
+                In this example, we are basing our changes on the <filename>linux-yocto-3.0-1.1.x</filename>
                 kernel.
                 The Yocto Project build environment recognizes this kernel as 
                 <filename>linux-yocto</filename>.
@@ -629,8 +701,8 @@
                 in the actually filename are omitted in order to make it more
                 readable:
                 <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...
-        ...r20/linux-qemux86-standard-build
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.10+git1+d38...
+        ...3a9ac596f7a-r3/linux-qemux86-standard-build
                 </literallayout>
             </para>
 

documentation/dev-manual/dev-manual-model.xml

@@ -24,7 +24,7 @@
     For a user-space application development example that uses the 
     <trademark class='trade'>Eclipse</trademark> IDE,
     see the 
-    <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
     The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
 </para>
 
@@ -79,8 +79,8 @@
             <orderedlist>
                 <listitem><para><emphasis>Set up your host development system to support 
                     development using the Yocto Project</emphasis>:  See the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the 
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                     system</emphasis>:  You need to have the Yocto Project files available on your host system. 
@@ -137,7 +137,7 @@
                     N450, and Sugar Bay are isolated.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.  
                     This layout is described in the section
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>Example Filesystem Layout</ulink>" section of the Board Support Package (BSP) Development Guide.  
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>Example Filesystem Layout</ulink>" section of the Board Support Package (BSP) Development Guide.  
                     In the standard layout, you will notice a suggested structure for recipes and  
                     configuration information.  
                     You can see the standard layout for the Crown Bay BSP in this example by examining the 
@@ -160,7 +160,7 @@
                     You need to get the build environment ready by sourcing an environment setup script 
                     and you need to be sure two key configuration files are configured appropriately.</para>
                     <para>The entire process for building an image is overviewed in the section
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
                     You might want to reference this information.</para></listitem>
                 <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
                     tool to build images based on the type of image you want to create.  
@@ -168,9 +168,9 @@
                     <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
                     See the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in the 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-                    Yocto Project Reference Manual</ulink>for information on supported images.</para></listitem>
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" 
+                    appendix in The Yocto Project Reference Manual for information on 
+                    supported images.</para></listitem>
             </orderedlist>
         </para>
 
@@ -178,7 +178,7 @@
             You can view a video presentation on "Building Custom Embedded Images with Yocto"
             at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.  
             You can also find supplemental information in  
-            <ulink url='http://yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
+            <ulink url='http://yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
             The Board Support Package (BSP) Development Guide</ulink>.
             Finally, there is wiki page write up of the example also located 
             <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
@@ -201,7 +201,7 @@
             The remainder of this section presents a high-level overview of the Linux Yocto 
             kernel architecture and the steps to modify the Linux Yocto kernel.
             For a complete discussion of the kernel, see  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
             The Yocto Project Kernel Architecture and Use Manual</ulink>.
             You can reference the appendix 
             "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
@@ -231,8 +231,12 @@
                     stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
                     stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The current
-                    Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project current (master) development.
+                    This kernel is based on the Linux 3.0 release.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x.
+                    This kernel is based on the Linux 3.0 release.</para></listitem> 
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -311,7 +315,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-3.png" 
+                <imagedata fileref="figures/kernel-overview-3-edison.png" 
                     width="6in" depth="4in" align="center" scale="100" />
             </para> 
 
@@ -349,7 +353,7 @@
             <para>
                 Again, for a complete discussion of the Yocto Project kernel's architcture and its 
                 branching strategy,
-                see the <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+                see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
                 Also, you can reference 
                 <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
@@ -373,8 +377,8 @@
                 <orderedlist>
                     <listitem><para><emphasis>Set up your host development system to support 
                         development using the Yocto Project</emphasis>:  See  
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
+                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                         system</emphasis>:  Having the Yocto Project files on your system gives you access to 
@@ -443,7 +447,7 @@
                         (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
                         are configured appropriately.</para>
                         <para>The entire process for building an image is overviewed in the 
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
+                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
                         You might want to reference this information.
                         Also, you should look at the detailed examples found in the appendices at 
                         at the end of this manual.</para></listitem>
@@ -454,10 +458,8 @@
                         <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                         <para>The build process supports several types of images to satisfy different needs.  
                         See the appendix
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" in the 
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-                        Yocto Project Reference Manual</ulink> for information on supported 
-                        images.</para></listitem>
+                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
+                        in The Yocto Project Reference Manual for information on supported images.</para></listitem>
                     <listitem><para><emphasis>Make your configuration changes available
                         in the kernel layer</emphasis>:  Up to this point, all the configuration changes to the 
                         kernel have been done and tested iteratively.  
@@ -507,7 +509,7 @@
             provides an overview of the general development process.
             If you want to see a detailed example of the process as it is used from within the Eclipse 
             IDE, see 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
             The Application Development Toolkit (ADT) User's Manual</ulink>.
         </para>
 
@@ -524,8 +526,8 @@
             <orderedlist>
                 <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:  
                     See  
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
 
 <!--
@@ -553,12 +555,12 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     (QEMU or real hardware), the area you get the image from differs.
                         <itemizedlist>
                             <listitem><para>Download the image from  
-                                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'>  
+                                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>  
                                 <filename>machines</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application on actual hardware. 
                                 </para></listitem>
                             <listitem><para>Download the image from the 
-                                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/qemu/'>  
+                                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>  
                                 <filename>machines/qemu</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application using the QEMU 
                                 emulator.</para></listitem>
@@ -573,9 +575,9 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                         </itemizedlist></para>
                     <para>For information on pre-built kernel image naming schemes for images 
                     that can run on the QEMU emulator, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
                     section in  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
                     The Yocto Project Quick Start</ulink>.</para></listitem>
                 <listitem><para><emphasis>Install the ADT</emphasis>:  
                     The ADT provides a target-specific cross-development toolchain, the root filesystem,
@@ -584,8 +586,8 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     easy method.
                     You can get these pieces by running an ADT installer script, which is configurable.
                     For information on how to install the ADT, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>The Yocto Project
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
                     Application Development (ADT) User's Manual</ulink>.</para></listitem>
                 <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</emphasis>:  
                     If you choose not to install the ADT using the ADT Installer,
@@ -630,14 +632,14 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
             <orderedlist>
                 <listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis> 
                     For information on how to install the toolchain, see the
-                    "<ulink url='http://www.yoctoproject/docs/1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
-                    <ulink url='http://www.yoctoproject/docs/1.1/adt-manual/adt-manual.html'>The Yocto Project
+                    "<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
+                    <ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
                     Application Development (ADT) User's Manual</ulink>.</para></listitem>
                 <listitem><para><emphasis>Download the Target Image:</emphasis>  The Yocto Project supports
                     several target architectures and has many pre-built kernel images and root filesystem 
                     images.</para>
                     <para>If you are going to develop your application on hardware, go to the 
-                    <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'>  
+                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>  
                     <filename>machines</filename></ulink> download area and choose a target machine area
                     from which to download the kernel image and root filesystem.
                     This download area could have several files in it that support development using   
@@ -647,7 +649,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     Be sure to get the files you need for your particular development process.</para>
                     <para>If you are going to develop your application and then run and test it using the QEMU
                     emulator, go to the 
-                    <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/qemu/'>  
+                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>  
                     <filename>machines/qemu</filename></ulink> download area.
                     From this area, go down into the directory for your target architecture
                     (e.g. <filename>qemux86_64</filename> for an 
@@ -655,7 +657,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     Download kernel, root filesystem, and any other files you need for your process.
                     <note>In order to use the root filesystem in QEMU, you need to extract it.
                     See the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the 
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the 
                     root filesystem.</note></para></listitem>
                 <listitem><para><emphasis>Develop and Test your Application:</emphasis>  At this point, 
                     you have the tools to develop your application.  

documentation/dev-manual/dev-manual-newbie.xml

@@ -101,8 +101,8 @@
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://www.yoctoproject.org/downloads/'>Index of /downloads:</ulink></emphasis>
-                This area contains an index of downloads such as 
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
+                This area contains an index releases such as 
                 the <trademark class='trade'>Eclipse</trademark>
                 Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
                 and all released versions of Yocto Project in the form of images or tarballs.
@@ -115,7 +115,7 @@
                 This page on the Yocto Project website allows you to download any Yocto Project
                 release or Board Support Package (BSP) in tarball form.
                 The tarballs are similar to those found in the 
-                <ulink url='http://www.yoctoproject.org/downloads/'>Index of /downloads:</ulink> area.</para>
+                <ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
                 <para>
                 <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
             </para></listitem>
@@ -170,9 +170,9 @@
             Images are the binary output that runs on specific hardware and for specific
             use cases.
             For a list of the supported image types that the Yocto Project provides, see the
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
             appendix in
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
             The Yocto Project Reference Manual</ulink>.</para></listitem>
         <listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core, 
             a BSP, or an application stack.</para></listitem>
@@ -216,14 +216,14 @@
             system in order to do any development using the Yocto Project.</para>
             <para>The name of the top-level directory of the Yocto Project file structure  
             is derived from the Yocto Project release tarball.
-            For example, downloading and unpacking <filename>poky-edison-6.0.tar.bz2</filename>
+            For example, downloading and unpacking <filename>poky-edison-6.0.1.tar.bz2</filename>
             results in a Yocto Project file structure whose Yocto Project source directory is named 
-            <filename>poky-edison-6.0</filename>.
+            <filename>poky-edison-6.0.1</filename>.
             If you create a Git repository, then you can name the repository anything you like.</para>
             <para>You can find instruction on how to set up the Yocto Project files on your 
             host development system by reading 
             the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>Getting
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>Getting
             Setup</ulink>" section.</para></listitem>
         <listitem><para><emphasis>Yocto Project Build Directory:</emphasis>
             This term refers to the area used by the Yocto Project for builds.  
@@ -233,9 +233,9 @@
             You can create the Yocto Project build directory anywhere you want on your 
             development system.
             Here is an example that creates the directory in <filename>mybuilds</filename> 
-            and names the Yocto Project build directory <filename>YP-6.0</filename>:
+            and names the Yocto Project build directory <filename>YP-6.0.1</filename>:
             <literallayout class='monospaced'> 
-     $ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
+     $ source poky-edison-6.0.1/oe-init-build-env $HOME/mybuilds/YP-6.0.1
             </literallayout>
             If you don't specifically name the directory, BitBake creates it 
             in the current directory and uses the name <filename>build</filename>.
@@ -486,8 +486,8 @@
         While each development environment is unique, there are some best practices or methods 
         that help development run smoothly.  
         The following list describes some of these practices.  
-        For more detailed information about these strategies see 
-        <ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>. 
+        For more information about Git workflows, see the workflow topics in the 
+        <ulink url='http://book.git-scm.com'>Git Community Book</ulink>. 
         <itemizedlist>
             <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep your changes you commit 
                 small as compared to bundling many disparate changes into a single commit.  
@@ -542,44 +542,59 @@
     <title>Tracking Bugs</title>
 
     <para>
-        The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
-        This bug-tracking application works well for group development because it tracks bugs and code 
+        The Yocto Project uses its own implementation of 
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
+        Implementations of Bugzilla work well for group development because they track bugs and code 
         changes, can be used to communicate changes and problems with developers, can be used to 
-        submit and review patches, and can be used to manage quality assurance.  
-        You can find a good overview of Bugzilla <ulink url='http://www.bugzilla.org/about/'>here</ulink>.     
+        submit and review patches, and can be used to manage quality assurance. 
+        The home page for the Yocto Project implementation of Bugzilla is   
+        <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
     </para>
 
     <para>
         Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
         such as when discovering an issue with some component of the build system that acts contrary 
         to the documentation or your expectations.  
-        You can find information 
-        for Bugzilla configuration and bug tracking procedures specific to the Yocto Project 
+        Following is the general procedure for submitting a new bug using the Yocto Project
+        Bugzilla.
+        You can find more information on defect management, bug tracking, and feature request
+        processes all accomplished through the Yocto Project Bugzilla on the wiki page
         <ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.     
+        <orderedlist>
+            <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
+                a bug.</para></listitem>
+            <listitem><para>When submitting a new bug, be sure to choose the appropriate
+                Classification, Product, and Component for which the issue was found.
+                Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
+                Infrastructure, Poky, and Yocto Metadata Layers.
+                Each of these Classifications break down into multiple Products and, in some 
+                cases, multiple Components.</para></listitem>
+            <listitem><para>Use the bug form to choose the correct Hardware and Architecture
+                for which the bug applies.</para></listitem>
+            <listitem><para>Indicate the Yocto Project version you were using when the issue
+                occurred.</para></listitem>
+            <listitem><para>Be sure to indicate the Severity of the bug.  
+                Severity communicates how the bug impacted your work.</para></listitem>
+            <listitem><para>Provide a brief summary of the issue. 
+                Try to limit your summary to just a line or two and be sure to capture the 
+                essence of the issue.</para></listitem>
+            <listitem><para>Provide a detailed description of the issue.  
+                You should provide as much detail as you can about the context, behavior, output, 
+                and so forth that surround the issue.  
+                You can even attach supporting files for output or log by using the "Add an attachment"
+                button.</para></listitem>
+            <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
+        </orderedlist>
     </para>
-
-    <para>
-        The Yocto Project uses its own version of the Bugzilla application.  
-        You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.  
-        You need to use this implementation of Bugzilla when logging a defect against anything released 
-        by the Yocto Project team.     
-    </para>
-
-    <para>
-        Here are some things to remember when dealing with bugs against the Yocto Project:   
-        <itemizedlist>
-            <listitem><para>The Yocto Project follows a bug-naming convention: 
-                <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
-                assigned defect ID used in Bugzilla.  
-                So, for example, a valid way to refer to a defect when creating a commit comment 
-                would be <filename>[YOCTO #1011]</filename>.   
-                This convention becomes important if you are submitting patches against the Yocto Project 
-                code itself.
-                See the following section for more information.</para></listitem>
-            <listitem><para>Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
-                Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
-        </itemizedlist>
-    </para>
+ 
+    <note>
+        Bugs in the Yocto Project Bugzilla follow naming convention: 
+        <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
+        assigned defect ID used in Bugzilla.  
+        So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.   
+        This convention becomes important if you are submitting patches against the Yocto Project 
+        code itself.
+    </note>
 </section>
 
 <section id='how-to-submit-a-change'>
@@ -590,8 +605,8 @@
         You should send patches to the appropriate Yocto Project mailing list to get them 
         in front of the Yocto Project Maintainer.
         For a list of the Yocto Project mailing lists, see the
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'> The 
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in 
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'> The 
         Yocto Project Reference Manual</ulink>.
     </para>
 
@@ -733,9 +748,8 @@
         </para>
 
         <para>            
-            You can find general Git information on how to push a change upstream 
-            <ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#Developing-With-git'>
-            here</ulink>.
+            You can find general Git information on how to push a change upstream in the 
+            <ulink url='http://book.git-scm.com/3_distributed_workflows.html'>Git Community Book</ulink>.
         </para>
     </section>
 

documentation/dev-manual/dev-manual-start.xml

@@ -9,7 +9,7 @@
     This chapter introduces the Yocto Project and gives you an idea of what you need to get started.  
     You can find enough information to set up your development host and build or use images for 
     hardware supported by the Yocto Project by reading  
-    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
     The Yocto Project Quick Start</ulink>.
 </para>
 
@@ -57,7 +57,7 @@
                 </para></listitem>
             <listitem><para><emphasis>Packages:</emphasis>  The Yocto Project requires certain packages
                 exist on your development system (e.g. Python 2.6 or 2.7).  
-                See "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" 
+                See "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" 
                 section in the Yocto Project Quick start for the exact package 
                 requirements and the installation commands to install them 
                 for the supported distributions.</para></listitem>
@@ -75,11 +75,11 @@
                         back into the Yocto Project, you can simply download the Yocto Project release you want 
                         from the website’s <ulink url='http://yoctoproject.org/download'>download page</ulink>.
                         Once you have the tarball, just extract it into a directory of your choice.</para>
-                        <para>For example, the following command extracts the Yocto Project 1.1 release tarball 
+                        <para>For example, the following command extracts the Yocto Project 1.1.1 release tarball 
                         into the current working directory and sets up the Yocto Project file structure
-                        with a top-level directory named <filename>poky-1.1</filename>:
+                        with a top-level directory named <filename>poky-edison-6.0.1</filename>:
                         <literallayout class='monospaced'>
-     $ tar xfj poky-edison-6.0.tar.bz2
+     $ tar xfj poky-edison-6.0.1.tar.bz2
                         </literallayout></para>
                         <para>This method does not produce a Git repository. 
                         Instead, you simply end up with a local snapshot of the 
@@ -117,28 +117,30 @@
                 For simplicity, it is recommended that you create these structures outside of the 
                 Yocto Project files' Git repository.</para>
                 <para>As an example, the following transcript shows how to create the bare clone
-                of the <filename>linux-yocto-3.0</filename> kernel and then create a copy of 
+                of the <filename>linux-yocto-3.0-1.1.x</filename> kernel and then create a copy of 
                 that clone.
                 <note>When you have a local Linux Yocto kernel Git repository, you can 
                 reference that repository rather than the upstream Git repository as 
                 part of the <filename>clone</filename> command.
                 Doing so can speed up the process.</note>
                 In the following example, the bare clone is named 
-                <filename>linux-yocto-3.0.git</filename>, while the 
-                copy is named <filename>linux-yocto-3.0</filename>: 
+                <filename>linux-yocto-3.0-1.1.x.git</filename>, while the 
+                copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>: 
                 <literallayout class='monospaced'>
-     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0 linux-yocto-3.0.git
-     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0.git/
-     remote: Counting objects: 2123870, done.
-     remote: Compressing objects: 100% (341338/341338), done.
-     remote: Total 2123870 (delta 1778780), reused 2107534 (delta 1762583)
-     Receiving objects: 100% (2123870/2123870), 445.72 MiB | 2.06 MiB/s, done.
-     Resolving deltas: 100% (1778780/1778780), done.                </literallayout></para>
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
+     remote: Counting objects: 2259181, done.
+     remote: Compressing objects: 100% (373259/373259), done.
+     remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
+     Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
+     Resolving deltas: 100% (1892638/1892638), done.
+                </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ git clone linux-yocto-3.0.git linux-yocto-3.0
-     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0/.git/
-     Checking out files: 100% (36898/36898), done.                </literallayout></para></listitem>
+     $ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
+     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
+     Checking out files: 100% (36898/36898), done.
+                </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
                 The <filename>poky-extras</filename> Git repository contains metadata needed to 
@@ -157,11 +159,12 @@
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
      Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
-     remote: Counting objects: 543, done.
-     remote: Compressing objects: 100% (483/483), done.
-     remote: Total 543 (delta 144), reused 307 (delta 39)
-     Receiving objects: 100% (543/543), 520.55 KiB, done.
-     Resolving deltas: 100% (144/144), done.                </literallayout></para></listitem>
+     remote: Counting objects: 561, done.
+     remote: Compressing objects: 100% (501/501), done.
+     remote: Total 561 (delta 159), reused 306 (delta 39)
+     Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
+     Resolving deltas: 100% (159/159), done.
+                </literallayout></para></listitem>
            <listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis>  
                 Similar considerations exist for BSPs.  
                 You can get set up for BSP development one of two ways: tarball extraction or
@@ -198,11 +201,11 @@
      $cd poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
-     remote: Counting objects: 1325, done.
-     remote: Compressing objects: 100% (1078/1078), done.
-     remote: Total 1325 (delta 546), reused 85 (delta 27)
-     Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
-     Resolving deltas: 100% (546/546), done.
+     remote: Counting objects: 3279, done.
+     remote: Compressing objects: 100% (2708/2708), done.
+     remote: Total 3279 (delta 1761), reused 194 (delta 105)
+     Receiving objects: 100% (3279/3279), 1.75 MiB | 377 KiB/s, done.
+     Resolving deltas: 100% (1761/1761), done.
                         </literallayout></para>
                         <para>The same  
                         <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -213,7 +216,7 @@
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.  
                 See the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
                 section in the Yocto Application Development Toolkit (ADT) 
                 User’s Guide for more information.</para></listitem>
         </itemizedlist>
@@ -226,7 +229,7 @@
     <para>
         The build process creates an entire Linux distribution, including the toolchain, from source.  
         For more information on this topic, see the 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
         section in the Yocto Project Quick Start.
     </para>
 
@@ -264,7 +267,7 @@
 
     <para>
         You can find details on all these steps in the 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section of the Yocto Project Quick Start. 
     </para>
 </section>

documentation/dev-manual/dev-manual.xml

@@ -33,10 +33,15 @@
                 <date>6 October 2011</date>
                 <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-     <year>2010-2011</year>
+     <year>2010-2012</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -51,7 +56,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and  
-          <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
           The Yocto Project Development Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/kernel-manual/kernel-concepts.xml

@@ -159,8 +159,8 @@
                 The features are tagged and organized by way of a branching strategy implemented by the 
                 source code manager (SCM) Git.
                 For information on Git as applied to the Yocto Project, see the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
-                section in <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
+                section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                 Yocto Project Development Manual</ulink>.
             </para>
             <para>
@@ -288,8 +288,8 @@
             <para>
                 You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
                 You can also get an introduction to Git as it applies to the Yocto Project in the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
-                section in <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
+                section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                 Yocto Project Development Manual</ulink>. 
                 This section overviews Git and describes a minimal set of commands that allow you to be 
                 functional using Git.

documentation/kernel-manual/kernel-doc-intro.xml

@@ -45,10 +45,10 @@
 
     <para>
         For more discussion on the Yocto Project kernel, you can also see the
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>",
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>", and 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>" sections all in
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>",
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>", and 
+        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>" sections all in
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
     </para>
 
     <para> 

documentation/kernel-manual/kernel-how-to.xml

@@ -50,8 +50,8 @@
             </literallayout>
             For another example of how to set up a local Git repository of the Linux Yocto 
             kernel files, see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in  
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
         </para>
         <para>  
             Once the Git repository is set up on your local machine, you can switch to the 
@@ -226,9 +226,9 @@
             You can find Git documentation at 
             <ulink url='http://git-scm.com/documentation'></ulink>.
             You can find a simple overview of using Git with the Yocto Project in the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
             section of  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto 
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto 
             Project Development Manual</ulink>.
         </para>
 
@@ -354,9 +354,9 @@
                 The Yocto Project provides scripts that help you work in a collaborative development 
                 environment.  
                 For information on these scripts, see the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#pushing-a-change-upstream'>Pushing a Change Upstream and Requesting a Pull</ulink>" and   
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#submitting-a-patch'>Submitting a Patch Through Email</ulink>" sections in    
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#pushing-a-change-upstream'>Pushing a Change Upstream and Requesting a Pull</ulink>" and   
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#submitting-a-patch'>Submitting a Patch Through Email</ulink>" sections in    
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                 Yocto Project Development Manual</ulink>".
             </para>
 
@@ -637,8 +637,8 @@
                     The messages used to commit changes are a large part of these standards.
                     Consequently, be sure that the headers for each commit have the required information.
                     For information on how to follow the Yocto Project commit message standards, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>How to Submit a Change</ulink>" section in  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>How to Submit a Change</ulink>" section in  
+                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                     Yocto Project Development Manual</ulink>".
                 </para>
 
@@ -772,8 +772,8 @@
                 existing similar BSP.
                 The information is introductory in nature and does not provide step-by-step examples. 
                 For detailed information on how to create a BSP given an existing similar BSP, see
-                the "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>BSP Development Example</ulink>" appendix in  
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>BSP Development Example</ulink>" appendix in  
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                 Yocto Project Development Manual</ulink>, or see the 
                 <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
                 wiki page.

documentation/kernel-manual/kernel-manual.xml

@@ -48,10 +48,15 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>2010-2012</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -63,7 +68,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
           The Yocto Project Kernel Architecture and Use Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/poky-ref-manual/development.xml

@@ -91,9 +91,9 @@
             with other plug-ins installed into the Eclipse IDE.
             Once you have your environment setup you need to configure the Eclipse plug-in.
             For information on how to install and configure the Eclipse plug-in, see the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#adt-eclipse'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#adt-eclipse'>
             "Working Within Eclipse"</ulink> chapter in the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
             "Application Development Toolkit (ADT) User's Guide."</ulink>
          </para>
          </section>
@@ -102,7 +102,7 @@
         <title>External Development Using the QEMU Emulator</title>
         <para>
             Running Poky QEMU images is covered in the 
-            <ulink url="http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html">
+            <ulink url="http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html">
             Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
         </para>
         <para>

documentation/poky-ref-manual/extendpoky.xml

@@ -3,13 +3,14 @@
 
 <chapter id='extendpoky'>
 
-<title>Extending the Yocto Project</title>
+<title>Common Tasks</title>
     <para>
-        This chapter provides information about how to extend the functionality
-        already present in the Yocto Project.
-        The chapter also documents standard tasks such as adding new
+        This chapter describes standard tasks such as adding new
         software packages, extending or customizing images or porting the Yocto Project to
         new hardware (adding a new machine). 
+        The chapter also describes ways to modify package source code, combine multiple 
+        versions of library files into a single image, track license changes, and handle
+        a package name alias.
         Finally, the chapter contains advice about how to make changes to the 
         Yocto Project to achieve the best results.
     </para>
@@ -531,9 +532,9 @@
         <para>
             For a complete example that shows how to add a new machine to the Yocto Project, 
             see the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in Appendix A of  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
             The Yocto Project Development Manual</ulink>.
         </para>
 
@@ -658,6 +659,412 @@
         </section>
     </section>
 
+    <section id="usingpoky-modifing-packages">
+        <title>Modifying Package Source Code</title>
+        <para>
+            Although the Yocto Project is usually used to build software, you can use it to modify software. 
+        </para>
+
+        <para>
+            During a build, source is available in the 
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
+            The actual location depends on the type of package and the architecture of the target device. 
+            For a standard recipe not related to 
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
+            <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
+            For target device-dependent packages, you should use the <filename>MACHINE</filename>
+            variable instead of 
+            <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename> 
+            in the directory name.
+        </para>
+
+        <tip>
+            Be sure the package recipe sets the 
+            <filename><link linkend='var-S'>S</link></filename> variable to something
+            other than the standard <filename>WORKDIR/PN-PV/</filename> value.
+        </tip>
+
+        <para>
+            After building a package, you can modify the package source code without problems. 
+            The easiest way to test your changes is by calling the 
+            <filename>compile</filename> task as shown in the following example:
+            <literallayout class='monospaced'>
+     $ bitbake -c compile -f NAME_OF_PACKAGE
+            </literallayout>
+        </para>
+
+        <para>
+            The <filename>-f</filename> or <filename>--force</filename>
+            option forces re-execution of the specified task.
+            You can call other tasks this way as well. 
+            But note that all the modifications in 
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
+            are gone once you execute <filename>-c clean</filename> for a package.
+        </para>
+    </section>
+
+    <section id="usingpoky-modifying-packages-quilt">
+        <title>Modifying Package Source Code with Quilt</title>
+            
+        <para>
+            By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
+            to manage patches in the <filename>do_patch</filename> task. 
+            This is a powerful tool that you can use to track all modifications to package sources.
+        </para>
+
+        <para>
+            Before modifying source code, it is important to notify Quilt so it can track the changes 
+            into the new patch file:
+            <literallayout class='monospaced'>
+     $ quilt new NAME-OF-PATCH.patch
+            </literallayout>
+        </para>
+
+        <para>
+            After notifying Quilt, add all modified files into that patch:
+            <literallayout class='monospaced'>
+     $ quilt add file1 file2 file3
+            </literallayout>
+        </para>
+
+        <para>
+            You can now start editing. 
+            Once you are done editing, you need to use Quilt to generate the final patch that 
+            will contain all your modifications.
+            <literallayout class='monospaced'>
+     $ quilt refresh
+            </literallayout>
+        </para>
+
+        <para>
+            You can find the resulting patch file in the
+            <filename>patches/</filename> subdirectory of the source 
+            (<filename><link linkend='var-S'>S</link></filename>) directory. 
+            For future builds, you should copy the patch into the Yocto Project metadata and add it into the 
+            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.  
+            Here is an example:
+            <literallayout class='monospaced'>
+     SRC_URI += "file://NAME-OF-PATCH.patch"
+            </literallayout>
+        </para>
+
+        <para>
+            Finally, don't forget to 'bump' the 
+            <filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since 
+            the resulting packages have changed.
+        </para>
+    </section>
+
+    <section id="building-multiple-architecture-libraries-into-one-image">
+        <title>Combining Multiple Versions of Library Files into One Image</title>
+
+        <para>
+            The build system offers the ability to build libraries with different
+            target optimizations or architecture formats and combine these together
+            into one system image. 
+            You can link different binaries in the image 
+            against the different libraries as needed for specific use cases.
+            This feature is called "Multilib."
+        </para>
+
+        <para>
+            An example would be where you have most of a system compiled in 32-bit
+            mode using 32-bit libraries, but you have something large, like a database
+            engine, that needs to be a 64-bit application and use 64-bit libraries.
+            Multilib allows you to get the best of both 32-bit and 64-bit libraries.
+        </para>
+
+        <para>
+            While the Multilib feature is most commonly used for 32 and 64-bit differences,
+            the approach the build system uses facilitates different target optimizations. 
+            You could compile some binaries to use one set of libraries and other binaries
+            to use other different sets of libraries.
+            The libraries could differ in architecture, compiler options, or other 
+            optimizations.
+        </para>
+
+        <para>
+            This section overviews the Multilib process only. 
+            For more details on how to implement Multilib, see the 
+            <ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki 
+            page.
+        </para>
+
+        <section id='preparing-to-use-multilib'>
+            <title>Preparing to use Multilib</title>
+
+            <para>
+                User-specific requirements drive the Multilib feature,
+                Consequently, there is no one "out-of-the-box" configuration that likely
+                exists to meet your needs.
+            </para>
+
+            <para>
+                In order to enable Multilib, you first need to ensure your recipe is
+                extended to support multiple libraries. 
+                Many standard recipes are already extended and support multiple libraries.
+                You can check in the <filename>meta/conf/multilib.conf</filename>
+                configuration file in the Yocto Project files directory to see how this is 
+                done using the <filename>BBCLASSEXTEND</filename> variable.
+                Eventually, all recipes will be covered and this list will be unneeded.
+            </para>
+  
+            <para>
+                For the most part, the Multilib class extension works automatically to
+                extend the package name from <filename>${PN}</filename> to
+                <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
+                is the particular multilib (e.g. "lib32-" or "lib64-"). 
+                Standard variables such as <filename>DEPENDS</filename>, 
+                <filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>, 
+                <filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and 
+                <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
+                If you are extending any manual code in the recipe, you can use the 
+                <filename>${MLPREFIX}</filename> variable to ensure those names are extended 
+                correctly. 
+                This automatic extension code resides in <filename>multilib.bbclass</filename>.
+            </para>
+        </section>
+
+        <section id='using-multilib'>
+            <title>Using Multilib</title>
+
+            <para>
+                After you have set up the recipes, you need to define the actual
+                combination of multiple libraries you want to build. 
+                You accomplish this through your <filename>local.conf</filename>
+                configuration file in the Yocto Project build directory. 
+                An example configuration would be as follows:
+                <literallayout class='monospaced'>
+     MACHINE = "qemux86-64"
+     require conf/multilib.conf
+     MULTILIBS = "multilib:lib32"
+     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+     MULTILIB_IMAGE_INSTALL = "lib32-connman"
+                </literallayout>
+                This example enables an
+                additional library named <filename>lib32</filename> alongside the 
+                normal target packages.
+                When combining these "lib32" alternatives, the example uses "x86" for tuning.
+                For information on this particular tuning, see
+                <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
+            </para>
+
+            <para>
+                The example then includes <filename>lib32-connman</filename>
+                in all the images, which illustrates one method of including a 
+                multiple library dependency. 
+                You can use a normal image build to include this dependency,
+                for example:
+                <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                </literallayout>
+                You can also build Multilib packages specifically with a command like this:
+                <literallayout class='monospaced'>
+     $  bitbake lib32-connman
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='additional-implementation-details'>
+            <title>Additional Implementation Details</title>
+
+            <para>
+                Different packaging systems have different levels of native Multilib
+                support. 
+                For the RPM Package Management System, the following implementation details 
+                exist:
+                <itemizedlist>
+                    <listitem><para>A unique architecture is defined for the Multilib packages,
+                        along with creating a unique deploy folder under 
+                        <filename>tmp/deploy/rpm</filename> in the Yocto
+                        Project build directory. 
+                        For example, consider <filename>lib32</filename> in a 
+                        <filename>qemux86-64</filename> image. 
+                        The possible architectures in the system are "all", "qemux86_64",
+                        "lib32_qemux86_64", and "lib32_x86".</para></listitem>
+                    <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from 
+                        <filename>${PN}</filename> during RPM packaging.
+                        The naming for a normal RPM package and a Multilib RPM package in a
+                        <filename>qemux86-64</filename> system resolves to something similar to
+                        <filename>bash-4.1-r2.x86_64.rpm</filename> and 
+                        <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
+                        </para></listitem>
+                    <listitem><para>When installing a Multilib image, the RPM backend first 
+                        installs the base image and then installs the Multilib libraries.
+                        </para></listitem>
+                    <listitem><para>The build system relies on RPM to resolve the identical files in the 
+                        two (or more) Multilib packages.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                For the IPK Package Management System, the following implementation details exist:
+                <itemizedlist>
+                    <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from 
+                        <filename>${PN}</filename> during IPK packaging.
+                        The naming for a normal RPM package and a Multilib IPK package in a
+                        <filename>qemux86-64</filename> system resolves to something like 
+                        <filename>bash_4.1-r2.x86_64.ipk</filename> and
+                        <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
+                        </para></listitem>
+                    <listitem><para>The IPK deploy folder is not modified with 
+                        <filename>${MLPREFIX}</filename> because packages with and without 
+                        the Multilib feature can exist in the same folder due to the 
+                        <filename>${PN}</filename> differences.</para></listitem>
+                    <listitem><para>IPK defines a sanity check for Multilib installation 
+                        using certain rules for file comparison, overridden, etc.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section> 
+    </section>
+
+    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
+        <title>Tracking License Changes</title>
+
+        <para>
+            The license of an upstream project might change in the future. In order to prevent these changes
+            going unnoticed, the Yocto Project provides a 
+            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
+            variable to track changes to the license text. The checksums are validated at the end of the
+            configure step, and if the checksums do not match, the build will fail.
+        </para>
+
+        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
+            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
+
+            <para>
+                The <filename>LIC_FILES_CHKSUM</filename>
+                variable contains checksums of the license text in the source code for the recipe.
+                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
+                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
+                         file://licfile2.txt;endline=50;md5=zzzz \
+                         ..."
+                </literallayout>
+            </para>
+
+            <para>
+                The Yocto Project uses the 
+                <filename><link linkend='var-S'>S</link></filename> variable as the 
+                default directory used when searching files listed in 
+                <filename>LIC_FILES_CHKSUM</filename>.
+                The previous example employs the default directory.
+            </para>
+
+            <para>
+                You can also use relative paths as shown in the following example: 
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
+                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
+     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+                </literallayout>
+            </para>
+
+            <para>
+                In this example, the first line locates a file in 
+                <filename><link linkend='var-S'>S</link>/src/ls.c</filename>. 
+                The second line refers to a file in 
+                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
+                of <filename>S</filename>.
+            </para>
+            <para>
+                Note that this variable is mandatory for all recipes, unless the 
+                <filename>LICENSE</filename> variable is set to "CLOSED".
+            </para>
+        </section>
+
+        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
+            <title>Explanation of Syntax</title>
+            <para>
+                As mentioned in the previous section, the 
+                <filename>LIC_FILES_CHKSUM</filename> variable lists all the 
+                important files that contain the license text for the source code. 
+                It is possible to specify a checksum for an entire file, or a specific section of a
+                file (specified by beginning and ending line numbers with the "beginline" and "endline"
+                parameters, respectively). 
+                The latter is useful for source files with a license notice header,
+                README documents, and so forth.
+                If you do not use the "beginline" parameter, then it is assumed that the text begins on the 
+                first line of the file. 
+                Similarly, if you do not use the "endline" parameter, it is assumed that the license text 
+                ends with the last line of the file. 
+            </para>
+
+            <para>
+                The "md5" parameter stores the md5 checksum of the license text. 
+                If the license text changes in any way as compared to this parameter
+                then a mismatch occurs.
+                This mismatch triggers a build failure and notifies the developer.
+                Notification allows the developer to review and address the license text changes.
+                Also note that if a mismatch occurs during the build, the correct md5 
+                checksum is placed in the build log and can be easily copied to the recipe.
+            </para>
+
+            <para>
+                There is no limit to how many files you can specify using the 
+                <filename>LIC_FILES_CHKSUM</filename> variable.
+                Generally, however, every project requires a few specifications for license tracking. 
+                Many projects have a "COPYING" file that stores the license information for all the source 
+                code files.
+                This practice allows you to just track the "COPYING" file as long as it is kept up to date. 
+            </para>
+
+            <tip>
+                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
+                error and displays the correct "md5" parameter value during the build. 
+                The correct parameter is also captured in the build log. 
+            </tip>
+
+            <tip>
+                If the whole file contains only license text, you do not need to use the "beginline" and 
+                "endline" parameters. 
+            </tip>
+        </section>
+    </section>
+
+    <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
+        <title>Handling a Package Name Alias</title>
+        <para>
+            Sometimes a package name you are using might exist under an alias or as a similarly named
+            package in a different distribution.
+            The Yocto Project implements a <filename>distro_check</filename>
+            task that automatically connects to major distributions
+            and checks for these situations. 
+            If the package exists under a different name in a different distribution, you get a 
+            <filename>distro_check</filename> mismatch.  
+            You can resolve this problem by defining a per-distro recipe name alias using the 
+            <filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
+        </para>
+
+        <para>
+            Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
+            variable:
+            <literallayout class='monospaced'>
+     DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
+                                       distro2=package_name_alias2 \
+                                       distro3=package_name_alias3 \
+                                       ..."
+            </literallayout>
+        </para>
+        
+        <para>
+            If you have more than one distribution alias, separate them with a space.
+            Note that the Yocto Project currently automatically checks the 
+            Fedora, OpenSuSE, Debian, Ubuntu, 
+            and Mandriva distributions for source package recipes without having to specify them 
+            using the <filename>DISTRO_PN_ALIAS</filename> variable.
+            For example, the following command generates a report that lists the Linux distributions
+            that include the sources for each of the Yocto Project recipes.
+            <literallayout class='monospaced'>
+     $ bitbake world -f -c distro_check
+            </literallayout>
+            The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> 
+            file found in the Yocto Project files area.
+        </para>
+    </section>
+
     <section id="usingpoky-changes">
         <title>Making and Maintaining Changes</title>
         <para>
@@ -976,411 +1383,6 @@
         </section>
     </section>
 
-    <section id="usingpoky-modifing-packages">
-        <title>Modifying Package Source Code</title>
-        <para>
-            Although the Yocto Project is usually used to build software, you can use it to modify software. 
-        </para>
-
-        <para>
-            During a build, source is available in the 
-            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
-            The actual location depends on the type of package and the architecture of the target device. 
-            For a standard recipe not related to 
-            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
-            <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
-            For target device-dependent packages, you should use the <filename>MACHINE</filename>
-            variable instead of 
-            <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename> 
-            in the directory name.
-        </para>
-
-        <tip>
-            Be sure the package recipe sets the 
-            <filename><link linkend='var-S'>S</link></filename> variable to something
-            other than the standard <filename>WORKDIR/PN-PV/</filename> value.
-        </tip>
-
-        <para>
-            After building a package, you can modify the package source code without problems. 
-            The easiest way to test your changes is by calling the 
-            <filename>compile</filename> task as shown in the following example:
-            <literallayout class='monospaced'>
-     $ bitbake -c compile -f NAME_OF_PACKAGE
-            </literallayout>
-        </para>
-
-        <para>
-            The <filename>-f</filename> or <filename>--force</filename>
-            option forces re-execution of the specified task.
-            You can call other tasks this way as well. 
-            But note that all the modifications in 
-            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
-            are gone once you execute <filename>-c clean</filename> for a package.
-        </para>
-    </section>
-
-    <section id="usingpoky-modifying-packages-quilt">
-        <title>Modifying Package Source Code with Quilt</title>
-            
-        <para>
-            By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
-            to manage patches in the <filename>do_patch</filename> task. 
-            This is a powerful tool that you can use to track all modifications to package sources.
-        </para>
-
-        <para>
-            Before modifying source code, it is important to notify Quilt so it can track the changes 
-            into the new patch file:
-            <literallayout class='monospaced'>
-     $ quilt new NAME-OF-PATCH.patch
-            </literallayout>
-        </para>
-
-        <para>
-            After notifying Quilt, add all modified files into that patch:
-            <literallayout class='monospaced'>
-     $ quilt add file1 file2 file3
-            </literallayout>
-        </para>
-
-        <para>
-            You can now start editing. 
-            Once you are done editing, you need to use Quilt to generate the final patch that 
-            will contain all your modifications.
-            <literallayout class='monospaced'>
-     $ quilt refresh
-            </literallayout>
-        </para>
-
-        <para>
-            You can find the resulting patch file in the
-            <filename>patches/</filename> subdirectory of the source 
-            (<filename><link linkend='var-S'>S</link></filename>) directory. 
-            For future builds, you should copy the patch into the Yocto Project metadata and add it into the 
-            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.  
-            Here is an example:
-            <literallayout class='monospaced'>
-     SRC_URI += "file://NAME-OF-PATCH.patch"
-            </literallayout>
-        </para>
-
-        <para>
-            Finally, don't forget to 'bump' the 
-            <filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since 
-            the resulting packages have changed.
-        </para>
-    </section>
-
-    <section id="building-multiple-architecture-libraries-into-one-image">
-        <title>Combining Multiple versions of Library Files into One Image</title>
-
-        <para>
-            The build system offers the ability to build libraries with different
-            target optimizations or architecture formats and combine these together
-            into one system image. 
-            You can link different binaries in the image 
-            against the different libraries as needed for specific use cases.
-            This feature is called "Multilib."
-        </para>
-
-        <para>
-            An example would be where you have most of a system compiled in 32-bit
-            mode using 32-bit libraries, but you have something large, like a database
-            engine, that needs to be a 64-bit application and use 64-bit libraries.
-            Multilib allows you to get the best of both 32-bit and 64-bit libraries.
-        </para>
-
-        <para>
-            While the Multilib feature is most commonly used for 32 and 64-bit differences,
-            the approach the build system uses facilitates different target optimizations. 
-            You could compile some binaries to use one set of libraries and other binaries
-            to use other different sets of libraries.
-            The libraries could differ in architecture, compiler options, or other 
-            optimizations.
-        </para>
-
-        <para>
-            This section overviews the Multilib process only. 
-            For more details on how to implement Multilib, see the 
-            <ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki 
-            page.
-        </para>
-
-        <section id='preparing-to-use-multilib'>
-            <title>Preparing to use Multilib</title>
-
-            <para>
-                User-specific requirements drive the Multilib feature,
-                Consequently, there is no one "out-of-the-box" configuration that likely
-                exists to meet your needs.
-            </para>
-
-            <para>
-                In order to enable Multilib, you first need to ensure your recipe is
-                extended to support multiple libraries. 
-                Many standard recipes are already extended and support multiple libraries.
-                You can check in the <filename>meta/conf/multilib.conf</filename>
-                configuration file in the Yocto Project files directory to see how this is 
-                done using the <filename>BBCLASSEXTEND</filename> variable.
-                Eventually, all recipes will be covered and this list will be unneeded.
-            </para>
-  
-            <para>
-                For the most part, the Multilib class extension works automatically to
-                extend the package name from <filename>${PN}</filename> to
-                <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
-                is the particular multilib (e.g. "lib32-" or "lib64-"). 
-                Standard variables such as <filename>DEPENDS</filename>, 
-                <filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>, 
-                <filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and 
-                <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
-                If you are extending any manual code in the recipe, you can use the 
-                <filename>${MLPREFIX}</filename> variable to ensure those names are extended 
-                correctly. 
-                This automatic extension code resides in <filename>multilib.bbclass</filename>.
-            </para>
-        </section>
-
-        <section id='using-multilib'>
-            <title>Using Multilib</title>
-
-            <para>
-                After you have set up the recipes, you need to define the actual
-                combination of multiple libraries you want to build. 
-                You accomplish this through your <filename>local.conf</filename>
-                configuration file in the Yocto Project build directory. 
-                An example configuration would be as follows:
-                <literallayout class='monospaced'>
-     MACHINE = "qemux86-64"
-     require conf/multilib.conf
-     MULTILIBS = "multilib:lib32"
-     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
-     MULTILIB_IMAGE_INSTALL = "lib32-connman"
-                </literallayout>
-                This example enables an
-                additional library named <filename>lib32</filename> alongside the 
-                normal target packages.
-                When combining these "lib32" alternatives, the example uses "x86" for tuning.
-                For information on this particular tuning, see
-                <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
-            </para>
-
-            <para>
-                The example then includes <filename>lib32-connman</filename>
-                in all the images, which illustrates one method of including a 
-                multiple library dependency. 
-                You can use a normal image build to include this dependency,
-                for example:
-                <literallayout class='monospaced'>
-     $ bitbake core-image-sato
-                </literallayout>
-                You can also build Multilib packages specifically with a command like this:
-                <literallayout class='monospaced'>
-     $  bitbake lib32-connman
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='additional-implementation-details'>
-            <title>Additional Implementation Details</title>
-
-            <para>
-                Different packaging systems have different levels of native Multilib
-                support. 
-                For the RPM Package Management System, the following implementation details 
-                exist:
-                <itemizedlist>
-                    <listitem><para>A unique architecture is defined for the Multilib packages,
-                        along with creating a unique deploy folder under 
-                        <filename>tmp/deploy/rpm</filename> in the Yocto
-                        Project build directory. 
-                        For example, consider <filename>lib32</filename> in a 
-                        <filename>qemux86-64</filename> image. 
-                        The possible architectures in the system are "all", "qemux86_64",
-                        "lib32_qemux86_64", and "lib32_x86".</para></listitem>
-                    <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from 
-                        <filename>${PN}</filename> during RPM packaging.
-                        The naming for a normal RPM package and a Multilib RPM package in a
-                        <filename>qemux86-64</filename> system resolves to something similar to
-                        <filename>bash-4.1-r2.x86_64.rpm</filename> and 
-                        <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
-                        </para></listitem>
-                    <listitem><para>When installing a Multilib image, the RPM backend first 
-                        installs the base image and then installs the Multilib libraries.
-                        </para></listitem>
-                    <listitem><para>The build system relies on RPM to resolve the identical files in the 
-                        two (or more) Multilib packages.</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                For the IPK Package Management System, the following implementation details exist:
-                <itemizedlist>
-                    <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from 
-                        <filename>${PN}</filename> during IPK packaging.
-                        The naming for a normal RPM package and a Multilib IPK package in a
-                        <filename>qemux86-64</filename> system resolves to something like 
-                        <filename>bash_4.1-r2.x86_64.ipk</filename> and
-                        <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
-                        </para></listitem>
-                    <listitem><para>The IPK deploy folder is not modified with 
-                        <filename>${MLPREFIX}</filename> because packages with and without 
-                        the Multilib feature can exist in the same folder due to the 
-                        <filename>${PN}</filename> differences.</para></listitem>
-                    <listitem><para>IPK defines a sanity check for Multilib installation 
-                        using certain rules for file comparison, overridden, etc.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section> 
-    </section>
-
-    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
-        <title>Tracking License Changes</title>
-
-        <para>
-            The license of an upstream project might change in the future. In order to prevent these changes
-            going unnoticed, the Yocto Project provides a 
-            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
-            variable to track changes to the license text. The checksums are validated at the end of the
-            configure step, and if the checksums do not match, the build will fail.
-        </para>
-
-        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
-            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
-
-            <para>
-                The <filename>LIC_FILES_CHKSUM</filename>
-                variable contains checksums of the license text in the source code for the recipe.
-                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
-                <literallayout class='monospaced'>
-     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
-                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
-                         file://licfile2.txt;endline=50;md5=zzzz \
-                         ..."
-                </literallayout>
-            </para>
-
-            <para>
-                The Yocto Project uses the 
-                <filename><link linkend='var-S'>S</link></filename> variable as the 
-                default directory used when searching files listed in 
-                <filename>LIC_FILES_CHKSUM</filename>.
-                The previous example employs the default directory.
-            </para>
-
-            <para>
-                You can also use relative paths as shown in the following example: 
-                <literallayout class='monospaced'>
-     LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
-                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
-                </literallayout>
-            </para>
-
-            <para>
-                In this example, the first line locates a file in 
-                <filename><link linkend='var-S'>S</link>/src/ls.c</filename>. 
-                The second line refers to a file in 
-                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
-                of <filename>S</filename>.
-            </para>
-            <para>
-                Note that this variable is mandatory for all recipes, unless the 
-                <filename>LICENSE</filename> variable is set to "CLOSED".
-            </para>
-        </section>
-
-        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
-            <title>Explanation of Syntax</title>
-            <para>
-                As mentioned in the previous section, the 
-                <filename>LIC_FILES_CHKSUM</filename> variable lists all the 
-                important files that contain the license text for the source code. 
-                It is possible to specify a checksum for an entire file, or a specific section of a
-                file (specified by beginning and ending line numbers with the "beginline" and "endline"
-                parameters respectively). 
-                The latter is useful for source files with a license notice header,
-                README documents, and so forth.
-                If you do not use the "beginline" parameter, then it is assumed that the text begins on the 
-                first line of the file. 
-                Similarly, if you do not use the "endline" parameter, it is assumed that the license text 
-                ends with the last line of the file. 
-            </para>
-
-            <para>
-                The "md5" parameter stores the md5 checksum of the license text. 
-                If the license text changes in any way as compared to this parameter
-                then a mismatch occurs.
-                This mismatch triggers a build failure and notifies the developer.
-                Notification allows the developer to review and address the license text changes.
-                Also note that if a mismatch occurs during the build, the correct md5 
-                checksum is placed in the build log and can be easily copied to the recipe.
-            </para>
-
-            <para>
-                There is no limit to how many files you can specify using the 
-                <filename>LIC_FILES_CHKSUM</filename> variable.
-                Generally, however, every project requires a few specifications for license tracking. 
-                Many projects have a "COPYING" file that stores the license information for all the source 
-                code files.
-                This practice allows you to just track the "COPYING" file as long as it is kept up to date. 
-            </para>
-
-            <tip>
-                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
-                error and displays the correct "md5" parameter value during the build. 
-                The correct parameter is also captured in the build log. 
-            </tip>
-
-            <tip>
-                If the whole file contains only license text, you do not need to use the "beginline" and 
-                "endline" parameters. 
-            </tip>
-        </section>
-    </section>
-
-    <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
-        <title>Handling a Package Name Alias</title>
-        <para>
-            Sometimes a package name you are using might exist under an alias or as a similarly named
-            package in a different distribution.
-            The Yocto Project implements a <filename>distro_check</filename>
-            task that automatically connects to major distributions
-            and checks for these situations. 
-            If the package exists under a different name in a different distribution, you get a 
-            <filename>distro_check</filename> mismatch.  
-            You can resolve this problem by defining a per-distro recipe name alias using the 
-            <filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
-        </para>
-
-        <para>
-            Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
-            variable:
-            <literallayout class='monospaced'>
-     DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
-                                       distro2=package_name_alias2 \
-                                       distro3=package_name_alias3 \
-                                       ..."
-            </literallayout>
-        </para>
-        
-        <para>
-            If you have more than one distribution alias, separate them with a space.
-            Note that the Yocto Project currently automatically checks the 
-            Fedora, OpenSuSE, Debian, Ubuntu, 
-            and Mandriva distributions for source package recipes without having to specify them 
-            using the <filename>DISTRO_PN_ALIAS</filename> variable.
-            For example, the following command generates a report that lists the Linux distributions
-            that include the sources for each of the Yocto Project recipes.
-            <literallayout class='monospaced'>
-     $ bitbake world -f -c distro_check
-            </literallayout>
-            The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> 
-            file found in the Yocto Project files area.
-        </para>
-    </section>
 </chapter>
 
 <!-- 

documentation/poky-ref-manual/faq.xml

@@ -33,8 +33,8 @@
                 You can use a stand-alone tarball to provide Python 2.6.
                 You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
                 <itemizedlist>
-                    <listitem><para><ulink url='http://www.yoctoproject.org/downloads/miscsupport/yocto-1.1-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
-                    <listitem><para><ulink url='http://www.yoctoproject.org/downloads/miscsupport/yocto-1.1-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
                 </itemizedlist>
             </para>
             <para>

documentation/poky-ref-manual/introduction.xml

@@ -15,8 +15,11 @@
         construct complete Linux images.
         You can find complete introductory and getting started information on the Yocto Project
         by reading the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>   
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>   
         Yocto Project Quick Start</ulink>.
+        For task-based information using the Yocto Project, see 
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
+        The Yocto Project Development Manual</ulink>.
         You can also find lots of information on the Yocto Project on the 
         <ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>.
     </para>
@@ -36,6 +39,11 @@
                 <link linkend='extendpoky'>Extending the Yocto Project</link>:</emphasis> This chapter
                 provides information about how to extend and customize the Yocto Project 
                 along with advice on how to manage these changes.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='technical-details'>Technical Details</link>:</emphasis> 
+                This chapter describes fundamental Yocto Project components as well as an explanation
+                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
+                </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='bsp'>Board Support Packages (BSP) - Developer's Guide</link>:</emphasis> 
                 This chapter describes the example filesystem layout for BSP development and 
@@ -90,9 +98,9 @@
 <title>System Requirements</title>
     <para>
         For system Yocto Project system requirements, see the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#resources'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#resources'>
         What You Need and How You Get It</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
     </para>
 </section>
@@ -104,7 +112,7 @@
         of methods:
         <itemizedlist>
             <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through 
-                <ulink url='http://yoctoproject.org/downloads/poky/'/>.</para></listitem>
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
             <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
                 <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.  
                 These builds include Yocto Project releases, meta-toolchain tarballs, and 
@@ -125,9 +133,9 @@
         You can get these files by downloading a Yocto Project release tarball and unpacking it,  
         or by establishing a Git repository of the files.
         For information on both these methods, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>
         Getting Setup</ulink> section in  
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
         The Yocto Project Development Manual</ulink>.
     </para>
 </section>

documentation/poky-ref-manual/poky-ref-manual.xml

@@ -62,10 +62,15 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2007-2011</year>
+      <year>2007-2012</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -77,7 +82,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
           The Yocto Project Reference Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
@@ -92,6 +97,8 @@
 
     <xi:include href="extendpoky.xml"/>
 
+    <xi:include href="technical-details.xml"/>
+
     <xi:include href="../bsp-guide/bsp.xml"/>
 
     <xi:include href="development.xml"/>

documentation/poky-ref-manual/ref-bitbake.xml

@@ -207,9 +207,9 @@
             It is worth noting that you can greatly speed up the build time by properly setting 
             the <filename>BB_NUMBER_THREADS</filename> variable.  
             See the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
             Building an Image</ulink> section in the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
             Yocto Project Quick Start</ulink> for more information.
         </para>
 
@@ -260,8 +260,50 @@
         <para>
             Once all the tasks have been completed BitBake exits.
         </para> 
-    </section>
 
+        <para>
+            When running a task, BitBake tightly controls the execution environment 
+            of the build tasks to make sure unwanted contamination from the build machine
+            cannot influence the build. 
+            Consequently, if you do want something to get passed into the build 
+            task's environment, you must take a few steps:
+            <orderedlist>
+                <listitem><para>Tell BitBake to load what you want from the environment
+                    into the data store. 
+                    You can do so through the <filename>BB_ENV_WHITELIST</filename>
+                    variable.
+                    For example, assume you want to prevent the build system from 
+                    accessing your <filename>$HOME/.ccache</filename> directory.
+                    The following command tells BitBake to load 
+                    <filename>CCACHE_DIR</filename> from the environment into the data
+                    store:
+                    <literallayout class='monospaced'>
+     export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" 
+                    </literallayout></para></listitem>
+                <listitem><para>Tell BitBake to export what you have loaded into the 
+                    environment store to the task environment of every running task.
+                    Loading something from the environment into the data store
+                    (previous step) only makes it available in the datastore. 
+                    To export it to the task environment of every running task,
+                    use a command similar to the following in your 
+                    <filename>local.conf</filename> or distro configuration file:
+                    <literallayout class='monospaced'>
+     export CCACHE_DIR
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+
+        <note>
+            A side effect of the previous steps is that BitBake records the variable
+            as a dependency of the build process in things like the shared state
+            checksums. 
+            If doing so results in unnecessary rebuilds of tasks, you can whitelist the 
+            variable so that the shared state code ignores the dependency when it creates
+            checksums.
+            For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
+            example in <xref linkend='checksums'>Checksums (Signatures)</xref>.
+        </note>
+    </section>
 
     <section id='ref-bitbake-commandline'>
         <title>BitBake Command Line</title>

documentation/poky-ref-manual/ref-classes.xml

@@ -391,6 +391,87 @@
         for common problems that show up during runtime.
         Distribution policy usually dictates whether to include this class as the Yocto Project does.
     </para>
+
+    <para>
+        You can configure the sanity checks so that specific test failures either raise a warning or 
+        an error message.  
+        Typically, failures for new tests generate a warning.
+        Subsequent failures for the same test would then generate an error message 
+        once the metadata is in a known and good condition.
+        You use the <filename>WARN_QA</filename> variable to specify tests for which you 
+        want to generate a warning message on failure.
+        You use the <filename>ERROR_QA</filename> variable to specify tests for which you 
+        want to generate an error message on failure.
+    </para>
+
+    <para>
+        The following list shows the tests you can list with the <filename>WARN_QA</filename>
+        and <filename>ERROR_QA</filename> variables:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
+                Ensures that the binaries were linked with the 
+                <filename>LDFLAGS</filename> options provided by the build system. 
+                If this test fails, check that the <filename>LDFLAGS</filename> variable
+                is being passed to the linker command.</para></listitem>
+            <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
+                Checks for dynamic library load paths (rpaths) in the binaries that 
+                by default on a standard system are searched by the linker (e.g.
+                <filename>/lib</filename> and <filename>/usr/lib</filename>). 
+                While these paths will not cause any breakage, they do waste space and 
+                are unnecessary.</para></listitem>
+            <listitem><para><emphasis><filename>rpaths:</filename></emphasis>
+                Checks for rpaths in the binaries that contain build system paths such
+                as <filename>TMPDIR</filename>.
+                If this test fails, bad <filename>-rpath</filename> options are being 
+                passed to the linker commands and your binaries have potential security 
+                issues.</para></listitem>
+            <listitem><para><emphasis><filename>dev-so:</filename></emphasis>
+                Checks that the <filename>.so</filename> symbolic links are in the 
+                <filename>-dev</filename> package and not in any of the other packages. 
+                In general, these symlinks are only useful for development purposes.
+                Thus, the <filename>-dev</filename> package is the correct location for
+                them. 
+                Some very rare cases do exist for dynamically loaded modules where 
+                these symlinks are needed instead in the main package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-files:</filename></emphasis>
+                Checks for <filename>.debug</filename> directories in anything but the 
+                <filename>-dbg</filename> package. 
+                The debug files should all be in the <filename>-dbg</filename> package.
+                Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
+            <listitem><para><emphasis><filename>arch:</filename></emphasis>
+                Checks the Executable and Linkable Format (ELF) type, bit size and endianness 
+                of any binaries to ensure it matches the target architecture. 
+                This test fails if any binaries don't match the type since there would be an 
+                incompatibility. 
+                Sometimes software, like bootloaders, might need to bypass this check.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
+                Checks that <filename>-dbg</filename> packages only depend on other
+                <filename>-dbg</filename> packages and not on any other types of packages,
+                which would cause a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
+                Checks that <filename>-dev</filename> packages only depend on other 
+                <filename>-dev</filename> packages and not on any other types of packages,
+                which would be a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
+                Checks <filename>.pc</filename> files for any 
+                <filename>TMPDIR/WORKDIR</filename> paths. 
+                Any <filename>.pc</filename> file containing these paths is incorrect 
+                since <filename>pkg-config</filename> itself adds the correct sysroot prefix 
+                when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>la:</filename></emphasis>
+                Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
+                paths. 
+                Any <filename>.la</filename> file continaing these paths is incorrect since 
+                <filename>libtool</filename> adds the correct sysroot prefix when using the 
+                files automatically itself.</para></listitem>
+            <listitem><para><emphasis><filename>desktop:</filename></emphasis>
+                Runs the <filename>desktop-file-validate</filename> program against any 
+                <filename>.desktop</filename> files to validate their contents against 
+                the specification for <filename>.desktop</filename> files.</para></listitem>
+        </itemizedlist>
+    </para>
 </section>
 
 <section id='ref-classes-siteinfo'>

documentation/poky-ref-manual/ref-structure.xml

@@ -14,9 +14,9 @@
 
 <para>
     For information on how to establish the Yocto Project files on your local development system, see the
-    <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-started'> 
+    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-started'> 
     Getting Setup</ulink> section in the 
-    <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
     The Yocto Project Development Manual</ulink>.
 </para>
 

documentation/poky-ref-manual/ref-variables.xml

@@ -285,6 +285,7 @@
 
         <glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>The list of packages which extend usability of the image. 
                     Those packages will automatically be installed but can be removed by user.</para>
             </glossdef>
@@ -328,6 +329,7 @@
 
         <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
             <glossdef>
+                <para></para>
                 <para>Variable that controls which locales for <filename>eglibc</filename> are
                     to be generated during the build (useful if the target device has 64Mbytes
                     of RAM or less).</para>
@@ -693,6 +695,7 @@
 
          <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of required packages to install as part of the package being
                     built.
@@ -722,6 +725,7 @@
 
          <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of recommended packages to install as part of the package being 
                     built. 
@@ -805,6 +809,7 @@
 
          <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of optional but non-machine essential packages to install as 
                     part of the package being built.
@@ -1230,6 +1235,7 @@
 
         <glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     By default, the Yocto Project automatically detects whether 
                     <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>  

documentation/poky-ref-manual/resources.xml

@@ -10,9 +10,9 @@
         The Yocto Project team is happy for people to experiment with the Yocto Project.
         A number of places exist to find help if you run into difficulties or find bugs. 
         To find out how to download source code,
-        see the <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-yp-release'>
+        see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>
         Yocto Project Release</ulink> list item in
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto 
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto 
         Project Development Manual</ulink>.
     </para>
 </section>
@@ -97,9 +97,9 @@
         You can submit changes to the project either by creating and sending pull requests, 
         or by submitting patches through email.
         For information on how to do both, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>
         How to Submit a Change</ulink> in
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
         The Yocto Project Development Manual</ulink>.
     </para>
 </section>

documentation/poky-ref-manual/technical-details.xml

@@ -0,0 +1,574 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<chapter id='technical-details'>
+<title>Technical Details</title>
+
+    <para>
+        This chapter provides technical details for various parts of the Yocto Project. 
+        Currently, topics include Yocto Project components and shared state (sstate) cache.
+    </para>
+
+<section id='usingpoky-components'>
+    <title>Yocto Project Components</title>
+
+    <para>
+        The BitBake task executor together with various types of configuration files form the 
+        Yocto Project core.
+        This section overviews the BitBake task executor and the
+        configuration files by describing what they are used for and how they interact.
+    </para>
+    
+    <para>  
+        BitBake handles the parsing and execution of the data files. 
+        The data itself is of various types:
+    <itemizedlist>
+        <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular 
+            pieces of software</para></listitem>
+        <listitem><para><emphasis>Class Data:</emphasis>  An abstraction of common build 
+            information (e.g. how to build a Linux kernel).</para></listitem>
+        <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings, 
+            policy decisions, etc.
+            Configuration data acts as the glue to bind everything together.</para></listitem>
+    </itemizedlist>
+        For more information on data, see the
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html#yocto-project-terms'>
+        Yocto Project Terms</ulink> section in 
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
+        The Yocto Project Development Manual</ulink>.
+    </para>
+
+    <para> 
+        BitBake knows how to combine multiple data sources together and refers to each data source
+        as a "<link linkend='usingpoky-changes-layers'>layer</link>".
+    </para>
+
+    <para>
+        Following are some brief details on these core components.
+        For more detailed information on these components see the 
+        <link linkend='ref-structure'>'Reference: Directory Structure'</link>
+        appendix.
+    </para>
+
+    <section id='usingpoky-components-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            BitBake is the tool at the heart of the Yocto Project and is responsible
+            for parsing the metadata, generating a list of tasks from it,
+            and then executing those tasks. 
+            To see a list of the options BitBake supports, use the following help command:
+            <literallayout class='monospaced'>
+     $ bitbake --help
+            </literallayout>
+        </para>
+
+        <para>
+            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            <filename>packagename</filename> is the name of the package you want to build 
+            (referred to as the "target" in this manual). 
+            The target often equates to the first part of a <filename>.bb</filename> filename.
+            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
+            might type the following:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+            </literallayout>
+            Several different versions of <filename>matchbox-desktop</filename> might exist.
+            BitBake chooses the one selected by the distribution configuration.
+            You can get more details about how BitBake chooses between different 
+            target versions and providers in the 
+            <link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
+        </para>
+
+        <para>
+            BitBake also tries to execute any dependent tasks first.
+            So for example, before building <filename>matchbox-desktop</filename>, BitBake
+            would build a cross compiler and <filename>eglibc</filename> if they had not already 
+            been built.
+            <note>This release of the Yocto Project does not support the <filename>glibc</filename>
+                GNU version of the Unix standard C library.  By default, the Yocto Project builds with
+                <filename>eglibc</filename>.</note>
+        </para>
+
+        <para>
+            A useful BitBake option to consider is the <filename>-k</filename> or 
+            <filename>--continue</filename> option.  
+            This option instructs BitBake to try and continue processing the job as much 
+            as possible even after encountering an error.  
+            When an error occurs, the target that
+            failed and those that depend on it cannot be remade.  
+            However, when you use this option other dependencies can still be processed.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-metadata'>
+        <title>Metadata (Recipes)</title>
+
+        <para>
+            The <filename>.bb</filename> files are usually referred to as "recipes." 
+            In general, a recipe contains information about a single piece of software.
+            The information includes the location from which to download the source patches 
+            (if any are needed), which special configuration options to apply, 
+            how to compile the source files, and how to package the compiled output. 
+        </para>
+
+        <para>
+            The term "package" can also be used to describe recipes.
+            However, since the same word is used for the packaged output from the Yocto 
+            Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files), 
+            this document avoids using the term "package" when refering to recipes.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-classes'>
+        <title>Classes</title>
+
+        <para>
+            Class files (<filename>.bbclass</filename>) contain information that is useful to share
+            between metadata files. 
+            An example is the Autotools class, which contains
+            common settings for any application that Autotools uses.
+            The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
+            about common classes and how to use them.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The configuration files (<filename>.conf</filename>) define various configuration variables
+            that govern the Yocto Project build process. 
+            These files fall into several areas that define machine configuration options, 
+            distribution configuration options, compiler tuning options, general common configuration
+            options and user configuration options (<filename>local.conf</filename>, which is found
+            in the Yocto Project files build directory).
+        </para>
+    </section>
+</section>
+
+<section id="shared-state-cache">
+    <title>Shared State Cache</title>
+
+    <para>
+        By design, the Yocto Project build system builds everything from scratch unless 
+        BitBake can determine that parts don't need to be rebuilt.
+        Fundamentally, building from scratch is attractive as it means all parts are 
+        built fresh and there is no possibility of stale data causing problems. 
+        When developers hit problems, they typically default back to building from scratch
+        so they know the state of things from the start.
+    </para>
+
+    <para>  
+        Building an image from scratch is both an advantage and a disadvantage to the process. 
+        As mentioned in the previous paragraph, building from scratch ensures that 
+        everything is current and starts from a known state.
+        However, building from scratch also takes much longer as it generally means 
+        rebuiding things that don't necessarily need rebuilt.
+    </para>
+
+    <para>
+        The Yocto Project implements shared state code that supports incremental builds.
+        The implementation of the shared state code answers the following questions that
+        were fundamental roadblocks within the Yocto Project incremental build support system:
+        <itemizedlist>
+            <listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
+            <listitem>How are changed pieces of software removed and replaced?</listitem>
+            <listitem>How are pre-built components that don't need to be rebuilt from scratch
+                used when they are available?</listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For the first question, the build system detects changes in the "inputs" to a given task by 
+        creating a checksum (or signature) of the task's inputs. 
+        If the checksum changes, the system assumes the inputs have changed and the task needs to be 
+        rerun.
+        For the second question, the shared state (sstate) code tracks which tasks add which output
+        to the build process. 
+        This means the output from a given task can be removed, upgraded or otherwise manipulated.
+        The third question is partly addressed by the solution for the second question
+        assuming the build system can fetch the sstate objects from remote locations and 
+        install them if they are deemed to be valid.
+    </para>
+
+    <para>
+        The rest of this section goes into detail about the overall incremental build
+        architecture, the checksums (signatures), shared state, and some tips and tricks.
+    </para>
+
+    <section id='overall-architecture'>
+        <title>Overall Architecture</title>
+
+        <para>
+            When determining what parts of the system need to be built, BitBake 
+            uses a per-task basis and does not use a per-recipe basis.
+            You might wonder why using a per-task basis is preferred over a per-recipe basis.
+            To help explain, consider having the IPK packaging backend enabled and then switching to DEB. 
+            In this case, <filename>do_install</filename> and <filename>do_package</filename>
+            output are still valid.
+            However, with a per-recipe approach, the build would not include the 
+            <filename>.deb</filename> files.        
+            Consequently, you would have to invalidate the whole build and rerun it. 
+            Rerunning everything is not the best situation.
+            Also in this case, the core must be "taught" much about specific tasks. 
+            This methodology does not scale well and does not allow users to easily add new tasks 
+            in layers or as external recipes without touching the packaged-staging core.
+        </para>
+    </section>
+
+    <section id='checksums'>
+        <title>Checksums (Signatures)</title>
+
+        <para>
+            The shared state code uses a checksum, which is a unique signature of a task's 
+            inputs, to determine if a task needs to be run again. 
+            Because it is a change in a task's inputs that triggers a rerun, the process
+            needs to detect all the inputs to a given task. 
+            For shell tasks, this turns out to be fairly easy because
+            the build process generates a "run" shell script for each task and 
+            it is possible to create a checksum that gives you a good idea of when 
+            the task's data changes.
+        </para>
+
+        <para>
+            To complicate the problem, there are things that should not be included in 
+            the checksum. 
+            First, there is the actual specific build path of a given task - 
+            the <filename>WORKDIR</filename>. 
+            It does not matter if the working directory changes because it should not 
+            affect the output for target packages.
+            Also, the build process has the objective of making native/cross packages relocatable. 
+            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            The simplistic approach for excluding the worknig directory is to set 
+            <filename>WORKDIR</filename> to some fixed value and create the checksum
+            for the "run" script. 
+        </para>
+
+        <para>
+            Another problem results from the "run" scripts containing functions that 
+            might or might not get called.  
+            The incremental build solution contains code that figures out dependencies 
+            between shell functions.
+            This code is used to prune the "run" scripts down to the minimum set, 
+            thereby alleviating this problem and making the "run" scripts much more 
+            readable as a bonus.
+        </para>
+
+        <para>
+            So far we have solutions for shell scripts.
+            What about python tasks?
+            The same approach applies even though these tasks are more difficult.
+            The process needs to figure out what variables a python function accesses 
+            and what functions it calls.
+            Again, the incremental build solution contains code that first figures out 
+            the variable and function dependencies, and then creates a checksum for the data 
+            used as the input to the task.
+        </para>
+
+        <para>
+            Like the <filename>WORKDIR</filename> case, situations exist where dependencies 
+            should be ignored.
+            For these cases, you can instruct the build process to ignore a dependency
+            by using a line like the following:
+            <literallayout class='monospaced'>
+     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
+            </literallayout>
+            This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not 
+            depend on the value of <filename>MACHINE</filename>, even if it does reference it.
+        </para>
+           
+        <para>
+            Equally, there are cases where we need to add dependencies BitBake is not able to find.
+            You can accomplish this by using a line like the following:
+            <literallayout class='monospaced'>
+      PACKAGE_ARCHS[vardeps] = "MACHINE"
+            </literallayout>
+            This example explicitly adds the <filename>MACHINE</filename> variable as a 
+            dependency for <filename>PACKAGE_ARCHS</filename>.
+        </para>
+
+        <para> 
+            Consider a case with inline python, for example, where BitBake is not
+            able to figure out dependencies. 
+            When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake 
+            produces output when it discovers something for which it cannot figure out
+            dependencies. 
+            The Yocto Project team has currently not managed to cover those dependencies 
+            in detail and is aware of the need to fix this situation.
+        </para>
+
+        <para>
+            Thus far, this section has limited discussion to the direct inputs into a task.
+            Information based on direct inputs is referred to as the "basehash" in the code.
+            However, there is still the question of a task's indirect inputs, the things that 
+            were already built and present in the build directory. 
+            The checksum (or signature) for a particular task needs to add the hashes of all the
+            tasks on which the particular task depends. 
+            Choosing which dependencies to add is a policy decision.
+            However, the effect is to generate a master checksum that combines the 
+            basehash and the hashes of the task's dependencies.
+        </para>
+
+        <para>
+            While figuring out the dependencies and creating these checksums is good,
+            what does the Yocto Project build system do with the checksum information? 
+            The build system uses a signature handler that is responsible for 
+            processing the checksum information.
+            By default, there is a dummy "noop" signature handler enabled in BitBake.
+            This means that behaviour is unchanged from previous versions. 
+            OECore uses the "basic" signature handler through this setting in the
+            <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+     BB_SIGNATURE_HANDLER ?= "basic"
+            </literallayout>
+            Also within the BitBake configuration file, we can give BitBake
+            some extra information to help it handle this information.
+            The following statements effectively result in a list of global
+            variable dependency excludes - variables never included in 
+            any checksum:
+            <literallayout class='monospaced'>
+     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
+     BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
+     BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
+     BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
+     BB_HASHTASK_WHITELIST += "(.*-cross$|.*-native$|.*-cross-initial$| \
+         .*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
+            </literallayout>
+            This example is actually where <filename>WORKDIR</filename>
+            is excluded since <filename>WORKDIR</filename> is constructed as a
+            path within <filename>TMPDIR</filename>, which is on the whitelist.
+        </para>
+
+        <para>
+            The <filename>BB_HASHTASK_WHITELIST</filename> covers dependent tasks and 
+            excludes certain kinds of tasks from the dependency chains. 
+            The effect of the previous example is to isolate the native, target,
+            and cross-components.
+            So, for example, toolchain changes do not force a rebuild of the whole system.
+        </para>
+
+        <para>
+            The end result of the "basic" handler is to make some dependency and
+            hash information available to the build. 
+            This includes:
+            <literallayout class='monospaced'>
+     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+     BB_TASKHASH - the hash of the currently running task
+            </literallayout>
+            There is also a "basichash" <filename>BB_SIGNATURE_HANDLER</filename>,
+            which is the same as the basic version but adds the task hash to the stamp files. 
+            This results in any metadata change that changes the task hash,
+            automatically causing the task to be run again. 
+            This removes the need to bump <filename>PR</filename>
+            values and changes to metadata automatically ripple across the build.
+            Currently, this behavior is not the default behavior.
+            However, it is likely that the Yocto Project team will go forward with this 
+            behavior in the future since all the functionality exists. 
+            The reason for the delay is the potential impact to the distribution feed 
+            creation as they need increasing <filename>PR</filename> fields
+            and the Yocto Project currently lacks a mechanism to automate incrementing 
+            this field.
+        </para>
+    </section>
+
+    <section id='shared-state'>
+        <title>Shared State</title>
+
+        <para>
+            Checksums and dependencies, as discussed in the previous section, solve half the 
+            problem.
+            The other part of the problem is being able to use checksum information during the build
+            and being able to reuse or rebuild specific components.
+        </para>
+
+        <para>
+            The shared state class (<filename>sstate.bbclass</filename>) 
+            is a relatively generic implementation of how to "capture" a snapshot of a given task. 
+            The idea is that the build process does not care about the source of a task's output.
+            Output could be freshly built or it could be downloaded and unpacked from
+            somewhere - the build process doesn't need to worry about its source.
+        </para>
+
+        <para>
+            There are two types of output, one is just about creating a directory
+            in <filename>WORKDIR</filename>.
+            A good example is the output of either <filename>do_install</filename> or 
+            <filename>do_package</filename>. 
+            The other type of output occurs when a set of data is merged into a shared directory 
+            tree such as the sysroot.
+        </para>
+
+        <para>
+            The Yocto Project team has tried to keep the details of the implementation hidden in 
+            <filename>sstate.bbclass</filename>. 
+            From a user's perspective, adding shared state wrapping to a task
+            is as simple as this <filename>do_deploy</filename> example taken from 
+            <filename>do_deploy.bbclass</filename>:
+            <literallayout class='monospaced'>
+     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+     SSTATETASKS += "do_deploy"
+     do_deploy[sstate-name] = "deploy"
+     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
+     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+
+     python do_deploy_setscene () {
+         sstate_setscene(d)
+     }
+     addtask do_deploy_setscene
+            </literallayout>
+            In the example, we add some extra flags to the task, a name field ("deploy"), an
+            input directory where the task sends data, and the output
+            directory where the data from the task should eventually be copied. 
+            We also add a <filename>_setscene</filename> variant of the task and add the task
+            name to the <filename>SSTATETASKS</filename> list.
+        </para>
+
+        <para>
+            If you have a directory whose contents you need to preserve, you can do this with 
+            a line like the following:
+            <literallayout class='monospaced'>
+     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
+            </literallayout>
+            This method, as well as the following example, also works for mutliple directories.
+            <literallayout class='monospaced'>
+     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
+     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
+     do_package[sstate-lockfile] = "${PACKAGELOCK}"
+            </literallayout>
+            These methods also include the ability to take a lockfile when manipulating
+            shared state directory structures since some cases are sensitive to file
+            additions or removals.
+        </para>
+
+        <para>
+            Behind the scenes, the shared state code works by looking in 
+            <filename>SSTATE_DIR</filename> and  
+            <filename>SSTATE_MIRRORS</filename> for shared state files. 
+            Here is an example:
+            <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://someserver.tld/share/sstate/ \n \
+     file://.* file:///some/local/dir/sstate/"
+            </literallayout>
+        </para>
+
+        <para>
+            The shared state package validity can be detected just by looking at the
+            filename since the filename contains the task checksum (or signature) as
+            described earlier in this section. 
+            If a valid shared state package is found, the build process downloads it 
+            and uses it to accelerate the task.
+        </para>
+
+        <para>
+            The build processes uses the <filename>*_setscene</filename> tasks
+            for the task acceleration phase.
+            BitBake goes through this phase before the main execution code and tries
+            to accelerate any tasks for which it can find shared state packages. 
+            If a shared state package for a task is available, the shared state
+            package is used.
+            This means the task and any tasks on which it is dependent are not 
+            executed.
+        </para>
+
+        <para>
+            As a real world example, the aim is when building an IPK-based image,
+            only the <filename>do_package_write_ipk</filename> tasks would have their 
+            shared state packages fetched and extracted. 
+            Since the sysroot is not used, it would never get extracted. 
+            This is another reason why a task-based approach is preferred over a 
+            recipe-based approach, which would have to install the output from every task.
+        </para>
+    </section>
+
+    <section id='tips-and-tricks'>
+        <title>Tips and Tricks</title>
+
+        <para>
+            The code in the Yocto Project that supports incremental builds is not 
+            simple code.
+            This section presents some tips and tricks that help you work around 
+            issues related to shared state code.
+        </para>
+
+        <section id='debugging'>
+            <title>Debugging</title>
+
+            <para>
+                When things go wrong, debugging needs to be straightforward. 
+                Because of this, the Yocto Project team included strong debugging
+                tools:
+                <itemizedlist>
+                    <listitem><para>Whenever a shared state package is written out, so is a
+                        corresponding <filename>.siginfo</filename> file. 
+                        This practice results in a pickled python database of all
+                        the metadata that went into creating the hash for a given shared state
+                        package.</para></listitem>
+                    <listitem><para>If BitBake is run with the <filename>--dump-signatures</filename>
+                        (or <filename>-S</filename>) option, BitBake dumps out 
+                        <filename>.siginfo</filename> files in
+                        the stamp directory for every task it would have executed instead of
+                        building the specified target package.</para></listitem>
+                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
+                        can process these <filename>.siginfo</filename> files. 
+                        If one file is specified, it will dump out the dependency
+                        information in the file. 
+                        If two files are specified, it will compare the two files and dump out 
+                        the differences between the two.
+                        This allows the question of "What changed between X and Y?" to be
+                        answered easily.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='invalidating-shared-state'>
+            <title>Invalidating Shared State</title>
+
+            <para>
+                The shared state code uses checksums and shared state memory 
+                cache to avoid unnecessarily rebuilding tasks.
+                As with all schemes, this one has some drawbacks.
+                It is possible that you could make implicit changes that are not factored 
+                into the checksum calculation, but do affect a task's output. 
+                A good example is perhaps when a tool changes its output.
+                Let's say that the output of <filename>rpmdeps</filename> needed to change.
+                The result of the change should be that all the "package", "package_write_rpm",
+                and "package_deploy-rpm" shared state cache items would become invalid.
+                But, because this is a change that is external to the code and therefore implicit,
+                the associated shared state cache items do not become invalidated.
+                In this case, the build process would use the cached items rather than running the 
+                task again. 
+                Obviously, these types of implicit changes can cause problems.
+            </para>
+
+            <para>
+                To avoid these problems during the build, you need to understand the effects of any
+                change you make.
+                Note that any changes you make directly to a function automatically are factored into 
+                the checksum calculation and thus, will invalidate the associated area of sstate cache.
+                You need to be aware of any implicit changes that are not obvious changes to the 
+                code and could affect the output of a given task. 
+                Once you are aware of such a change, you can take steps to invalidate the cache 
+                and force the task to run. 
+                The step to take is as simple as changing a function's comments in the source code. 
+                For example, to invalidate package shared state files, change the comment statments
+                of <filename>do_package</filename> or the comments of one of the functions it calls.
+                The change is purely cosmetic, but it causes the checksum to be recalculated and  
+                forces the task to be run again.
+            </para>
+
+            <note>
+                For an example of a commit that makes a cosmetic change to invalidate 
+                a shared state, see this
+                <ulink url='http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
+            </note>
+        </section>                
+    </section>
+</section>
+
+</chapter>
+<!-- 
+vim: expandtab tw=80 ts=4 
+-->

documentation/poky-ref-manual/usingpoky.xml

@@ -4,213 +4,84 @@
 <title>Using the Yocto Project</title>
 
     <para>
-        This section gives an overview of the components that make up the Yocto Project 
-        followed by information about Yocto Project builds and dealing with any
-        problems that might arise.
+        This chapter describes common usage for the Yocto Project.
+        The information is introductory in nature as other manuals in the Yocto Project
+        provide more details on how to use the Yocto Project.
     </para>
 
-<section id='usingpoky-components'>
-    <title>Yocto Project Components</title>
-
-    <para>
-        The BitBake task executor together with various types of configuration files form the 
-        Yocto Project core.
-        This section overviews the BitBake task executor and the
-        configuration files by describing what they are used for and they they interact.
-    </para>
-    
-    <para>  
-        BitBake handles the parsing and execution of the data files. 
-        The data itself is of various types:
-    <itemizedlist>
-        <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular 
-            pieces of software</para></listitem>
-        <listitem><para><emphasis>Class Data:</emphasis>  An abstraction of common build 
-            information (e.g. how to build a Linux kernel).</para></listitem>
-        <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings, 
-            policy decisions, etc.
-            Configuration data acts a the glue to bind everything together.</para></listitem>
-    </itemizedlist>
-        For more information on data, see the
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#yocto-project-terms'>
-        Yocto Project Terms</ulink> section in 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
-    </para>
-
-    <para> 
-        BitBake knows how to combine multiple data sources together and refers to each data source
-        as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
-    </para>
-
-    <para>
-        Following are some brief details on these core components.
-        For more detailed information on these components see the 
-        <link linkend='ref-structure'>'Reference: Directory Structure'</link>
-        appendix.
-    </para>
-
-    <section id='usingpoky-components-bitbake'>
-        <title>BitBake</title>
-
-        <para>
-            BitBake is the tool at the heart of the Yocto Project and is responsible
-            for parsing the metadata, generating a list of tasks from it,
-            and then executing those tasks. 
-            To see a list of the options BitBake supports, use the following help command:
-            <literallayout class='monospaced'>
-     $ bitbake --help
-            </literallayout>
-        </para>
-
-        <para>
-            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
-            <filename>packagename</filename> is the name of the package you want to build 
-            (referred to as the "target" in this manual). 
-            The target often equates to the first part of a <filename>.bb</filename> filename.
-            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
-            might type the following:
-            <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop
-            </literallayout>
-            Several different versions of <filename>matchbox-desktop</filename> might exist.
-            BitBake chooses the one selected by the distribution configuration.
-            You can get more details about how BitBake chooses between different 
-            target versions and providers in the 
-            <link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
-        </para>
-
-        <para>
-            BitBake also tries to execute any dependent tasks first.
-            So for example, before building <filename>matchbox-desktop</filename>, BitBake
-            would build a cross compiler and <filename>eglibc</filename> if they had not already 
-            been built.
-            <note>This release of the Yocto Project does not support the <filename>glibc</filename>
-                GNU version of the Unix standard C library.  By default, the Yocto Project builds with
-                <filename>eglibc</filename>.</note>
-        </para>
-
-        <para>
-            A useful BitBake option to consider is the <filename>-k</filename> or 
-            <filename>--continue</filename> option.  
-            This option instructs BitBake to try and continue processing the job as much 
-            as possible even after encountering an error.  
-            When an error occurs, the target that
-            failed and those that depend on it cannot be remade.  
-            However, when you use this option other dependencies can still be processed.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-metadata'>
-        <title>Metadata (Recipes)</title>
-
-        <para>
-            The <filename>.bb</filename> files are usually referred to as "recipes." 
-            In general, a recipe contains information about a single piece of software.
-            The information includes the location from which to download the source patches 
-            (if any are needed), which special configuration options to apply, 
-            how to compile the source files, and how to package the compiled output. 
-        </para>
-
-        <para>
-            The term "package" can also be used to describe recipes.
-            However, since the same word is used for the packaged output from the Yocto 
-            Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files), 
-            this document avoids using the term "package" to refer to recipes.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-classes'>
-        <title>Classes</title>
-
-        <para>
-            Class files (<filename>.bbclass</filename>) contain information that is useful to share
-            between metadata files. 
-            An example is the Autotools class, which contains
-            common settings for any application that Autotools uses.
-            The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
-            about common classes and how to use them.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-configuration'>
-        <title>Configuration</title>
-
-        <para>
-            The configuration files (<filename>.conf</filename>) define various configuration variables
-            that govern the Yocto Project build process. 
-            These files fall into several areas that define machine configuration options, 
-            distribution configuration options, compiler tuning options, general common configuration
-            options and user configuration options (<filename>local.conf</filename>, which is found
-            in the Yocto Project files build directory).
-        </para>
-    </section>
-</section>
-
-
 <section id='usingpoky-build'>
     <title>Running a Build</title>
 
     <para>
-        You can find information on how to build an image using the Yocto Project in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
+        You can find general information on how to build an image using the 
+        Yocto Project in the 
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
         Building an Image</ulink> section of the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
-        This section provides a quick overview.
+        This section provides a summary of the build process and provides information
+        for less obvious aspects of the build process.
     </para>
 
-    <para>
-        The first thing you need to do is set up the Yocto Project build environment by sourcing
-        the environment setup script as follows:
-        <literallayout class='monospaced'>
-     $ source oe-init-build-env [build_dir];
-        </literallayout>
-    </para>
+    <section id='build-overview'>
+        <title>Build Overview</title>
 
-    <para>
-        The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
-        uses for the build.
-        If you do not specify a build directory it defaults to <filename>build</filename>
-        in the Yocto Project files directory structure.
-        A common practice is to use a different build directory for different targets. 
-        For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
-        target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
-        See <link linkend="structure-core-script">oe-init-build-env</link>
-        for more information on this script.
-    </para>
+        <para>
+            The first thing you need to do is set up the Yocto Project build environment by sourcing
+            the environment setup script as follows:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env [build_dir]
+            </literallayout>
+        </para>
 
-    <para>
-        Once the Yocto Project build environment is set up, you can build a target using:
-        <literallayout class='monospaced'>
+        <para>
+            The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
+            uses for the build.
+            If you do not specify a build directory it defaults to <filename>build</filename>
+            in your current working directory.
+            A common practice is to use a different build directory for different targets. 
+            For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
+            target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
+            See <link linkend="structure-core-script">oe-init-build-env</link>
+            for more information on this script.
+        </para>
+
+        <para>
+            Once the Yocto Project build environment is set up, you can build a target using:
+            <literallayout class='monospaced'>
      $ bitbake &lt;target&gt;
-        </literallayout>
-    </para>
+            </literallayout>
+        </para>
 
-    <para>
-        The <filename>target</filename> is the name of the recipe you want to build. 
-        Common targets are the images in <filename>meta/recipes-core/images</filename>,
-        <filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
-        files.
-        Or, the target can be the name of a recipe for a specific piece of software such as 
-        <application>busybox</application>. 
-        For more details about the images Yocto Project supports, see the 
-        <link linkend="ref-images">'Reference: Images'</link> appendix.
-    </para>
+        <para>
+            The <filename>target</filename> is the name of the recipe you want to build. 
+            Common targets are the images in <filename>meta/recipes-core/images</filename>,
+            <filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
+            files.
+            Or, the target can be the name of a recipe for a specific piece of software such as 
+            <application>busybox</application>. 
+            For more details about the images Yocto Project supports, see the 
+            <link linkend="ref-images">'Reference: Images'</link> appendix.
+        </para>
 
-    <note>
-        Building an image without GNU Public License Version 3 (GPLv3) components is 
-        only supported for minimal and base images.
-        See <link linkend='ref-images'>'Reference: Images'</link> for more information.
-    </note>
+        <note>
+            Building an image without GNU Public License Version 3 (GPLv3) components is 
+            only supported for minimal and base images.
+            See <link linkend='ref-images'>'Reference: Images'</link> for more information.
+        </note>
+    </section>
 
-    <note>
-        When building an image using GPL components, you need to maintain your original 
-        settings and not switch back and forth applying different versions of the GNU
-        Public License.  
-        If you rebuild using different versions of GPL, dependency errors might occur
-        due to some components not being rebuilt.
-    </note>
+    <section id='building-an-image-using-gpl-components'>
+        <title>Building an Image Using GPL Components</title>
+
+        <para>
+            When building an image using GPL components, you need to maintain your original 
+            settings and not switch back and forth applying different versions of the GNU
+            Public License.  
+            If you rebuild using different versions of GPL, dependency errors might occur
+            due to some components not being rebuilt.
+        </para>
+    </section>
 </section>
 
 <section id='usingpoky-install'>
@@ -222,9 +93,9 @@
         <filename class="directory">tmp/deploy/images</filename>. 
         For information on how to run pre-built images such as <filename>qemux86</filename> 
         and <filename>qemuarm</filename>, see the
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
         Using Pre-Built Binaries and QEMU</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
         For information about how to install these images, see the documentation for your
         particular board/machine.

documentation/yocto-project-qs/yocto-project-qs.xml

@@ -6,7 +6,7 @@
 
 <section id='fake-title'>
     <title>Yocto Project Quick Start</title>
-    <para>Copyright &copy; 2010-2011 Linux Foundation</para>
+    <para>Copyright &copy; 2010-2012 Linux Foundation</para>
 </section>
 
 <section id='welcome'>
@@ -37,13 +37,13 @@
         Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
         at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and 
         the FAQ appendix located in  
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
         The Yocto Project Reference Manual</ulink> helpful.
     </para>
     <note>
         Due to production processes, there could be differences between the Yocto Project
         documentation bundled in the release tarball and the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink> on
         the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
         For the latest version of this manual, see the manual on the website.
@@ -130,7 +130,7 @@
             <para>A host system running a supported Linux distribution (i.e. recent releases of
                 Fedora, openSUSE, Debian, and Ubuntu).
                 If the host system supports multiple cores and threads, you can configure the 
-                Yocto Project build system to increase the time needed to build images
+                Yocto Project build system to decrease the time needed to build images
                 significantly.
             </para>
         </listitem>
@@ -149,7 +149,7 @@
             The Yocto Project team is continually verifying more and more Linux 
             distributions with each release.
             In general, if you have the current release minus one of the following 
-            distributions you should no problems.
+            distributions you should have no problems.
             <itemizedlist>
                 <listitem><para>Ubuntu</para></listitem>
                 <listitem><para>Fedora</para></listitem>
@@ -191,33 +191,44 @@
         <para>
             Packages and package installation vary depending on your development system.  
             In general, you need to have root access and then install the required packages.
+            The next few sections show you how to get set up with the right packages for
+            Ubuntu, Fedora, and openSUSE.
         </para>
+  
+        <section id='ubuntu'>
+            <title>Ubuntu</title>
 
-        <note><para>
-            If you are using a Fedora version prior to version 15, you will need to take some 
-            extra steps to enable <filename>sudo</filename>.
-            See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink> 
-            wiki page for details.
-        </para></note>
+            <para>
+                If your distribution is Ubuntu, you need to be running the bash shell.  
+                You can be sure you are running this shell by entering the following command and 
+                selecting "No" at the prompt:
+                <literallayout class='monospaced'>
+     $ sudo dpkg-reconfigure dash
+                </literallayout>
+            </para>
 
-        <para>
-            The packages you need for a Debian-based host are shown in the following command:
-        </para>
+            <para>
+                The packages you need for a supported Ubuntu distribution are shown in the following command:
+            </para>
 
-            <literallayout class='monospaced'>
+                <literallayout class='monospaced'>
      $ sudo apt-get install sed wget cvs subversion git-core coreutils \
      unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
      python-pysqlite2 diffstat help2man make gcc build-essential \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
      mercurial autoconf automake groff libtool xterm
-            </literallayout>
+                </literallayout>
+        </section>
 
-        <para>
-            The packages you need for an RPM-based host like Fedora and openSUSE, 
-            respectively, are as follows:
-        </para>
+        <section id='fedora'>
+            <title>Fedora</title>
 
-            <literallayout class='monospaced'>
+            <para>
+                The packages you need for a supported Fedora distribution are shown in the following
+                commands:
+            </para>
+
+                <literallayout class='monospaced'>
      $ sudo yum groupinstall "development tools"
      $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
      unzip python-psyco perl texinfo texi2html diffstat openjade \
@@ -227,14 +238,31 @@
      perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
      SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
      autoconf automake libtool xterm
-            </literallayout>
+                </literallayout>
 
-            <literallayout class='monospaced'>
+            <note><para>
+                If you are using a Fedora version prior to version 15, you will need to take some 
+                extra steps to enable <filename>sudo</filename>, or you will need to run
+                the commands as root user.
+                See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink> 
+                wiki page for details.
+            </para></note>
+        </section>
+
+        <section id='opensuse'>
+            <title>openSUSE</title>
+
+            <para>
+                The packages you need for a supported openSUSE distribution are shown in the following 
+                command:
+            </para>
+
+                <literallayout class='monospaced'>
      $ sudo zypper install python gcc gcc-c++ libtool \
-     subversion git chrpath automake \
-     help2man diffstat texinfo mercurial wget
-            </literallayout>
- 
+     subversion git chrpath automake make wget help2man \
+     diffstat texinfo mercurial freeglut-devel libSDL-devel
+                </literallayout>
+        </section>
     </section>
 
     <section id='releases'>
@@ -257,9 +285,9 @@
             development system. 
             Doing so allows you to contribute back to the project.
             For information on how to get set up using this method, see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-yp-release'>Yocto 
+            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>Yocto 
             Project Release</ulink>" item in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto Project
+            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project
             Development Manual</ulink>.
         </para>
     </section>
@@ -278,7 +306,7 @@
             <para>Build an image and run it in the QEMU emulator</para>
         </listitem>
         <listitem>
-            <para>Or, use a pre-built image and run it in the QEMU emulator</para>
+            <para>Use a pre-built image and run it in the QEMU emulator</para>
         </listitem>
     </itemizedlist>
 
@@ -317,23 +345,22 @@
              If you encounter problems with the Yocto Project finding and downloading source code, see
              the FAQ entry "How does Poky obtain source code and will it work behind my
              firewall or proxy server?" in  
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
              The Yocto Project Reference Manual</ulink>.
          </para></note>
 
          <para>
              <literallayout class='monospaced'>
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
-     $ tar xjf poky-edison-6.0.tar.bz2
-     $ source poky-edison-6.0/oe-init-build-env edison-6.0-build
+     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
+     $ tar xjf poky-edison-6.0.1.tar.bz2
+     $ source poky-edison-6.0.1/oe-init-build-env edison-6.0.1-build
              </literallayout>
          </para>
 
          <tip><para>
              To help conserve disk space during builds, you can add the following statement
-             to your <filename>local.conf</filename> file in the Yocto Project build
-             directory, which for this example 
-             is <filename>edison-6.0-build</filename>.
+             to your project's configuration file, which for this example
+             is <filename>edison-6.0.1-build/conf/local.conf</filename>.
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
@@ -342,21 +369,20 @@
          </para></tip>
 
          <itemizedlist>
-             <listitem><para>The first command retrieves the Yocto Project release tarball from the 
-                 source repositories. 
-                 Notice, the example uses the <filename>wget</filename> shell command.
+             <listitem><para>In the previous example, the first command retrieves the Yocto Project
+                 release tarball from the source repositories using the
+                 <filename>wget</filename> command.
                  Alternatively, you can go to the 
-                 <ulink url='http://www.yoctoproject.org'>Yocto Project website</ulink> downloads
-                 area to retrieve the tarball.</para></listitem>
+                 <ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink>
+                 Downloads page to retrieve the tarball.</para></listitem>
              <listitem><para>The second command extracts the files from the tarball and places 
-                 them into a directory named <filename>poky-edison-6.0</filename> in the current 
-                 directory. 
-               </para></listitem>
+                 them into a directory named <filename>poky-edison-6.0.1</filename> in the current 
+                 directory.</para></listitem>
              <listitem><para>The third command runs the Yocto Project environment setup script.
                  Running this script defines Yocto Project build environment settings needed to 
                  complete the build.
                  The script also creates the Yocto Project
-                 build directory, which is <filename>edison-6.0-build</filename> in this case.
+                 build directory, which is <filename>edison-6.0.1-build</filename> in this case.
                  After the script runs, your current working directory is set 
                  to the build directory.
                  Later, when the build completes, the build directory contains all the files 
@@ -364,32 +390,31 @@
                  </para></listitem>
          </itemizedlist>
          <para>
-             Take some time to examine your <filename>conf/local.conf</filename> file found in the
-             Yocto Project build directory.
-             The defaults in the <filename>local.conf</filename> should work fine.
+             Take some time to examine your <filename>local.conf</filename> file 
+             in your project's configuration directory.
+             The defaults in that file should work fine.
              However, there are some variables of interest at which you might look.
          </para>
 
          <para>  
              By default, the target architecture for the build is <filename>qemux86</filename>, 
-             which is an image that can be used in the QEMU emulator and is targeted for an
+             which produces an image that can be used in the QEMU emulator and is targeted at an
              <trademark class='registered'>Intel</trademark> 32-bit based architecture.
-             To change this default, edit the value of the <filename>MACHINE</filename> variable in the 
-             <filename>conf/local.conf</filename> file in the build directory before 
-             launching the build.
+             To change this default, edit the value of the <filename>MACHINE</filename> variable 
+             in the configuration file before launching the build.
          </para>
 
          <para>
              Another couple of variables of interest are the 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
+             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
+             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
              By default, these variables are commented out. 
-             However, if you have a multi-core CPU you might want to remove the comment
-             and set the variable
+             However, if you have a multi-core CPU you might want to uncomment
+             the lines and set the variable
              <filename>BB_NUMBER_THREADS</filename> equal to twice the number of your 
              host's processor cores.
-             Also, you could set the variable <filename>PARALLEL_MAKE</filename> equal to the number 
-             of processor cores.
+             Also, you could set the variable <filename>PARALLEL_MAKE</filename> equal to 
+             1.5 times the number of processor cores.
              Setting these variables can significantly shorten your build time.
          </para>
 
@@ -398,10 +423,10 @@
             the image. 
             By default, the Yocto Project build system uses the RPM package manager.
             You can control this configuration by using the 
-            <filename><ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
+            <filename><ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
              For additional package manager selection information, see 
-             "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+             "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in 
+             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
              The Yocto Project Reference Manual</ulink>.
         </para>
 
@@ -410,15 +435,15 @@
              <filename>core-image-sato</filename> in this example.
              For information on the <filename>-k</filename> option use the 
              <filename>bitbake --help</filename> command or see the
-             "<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
+             "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in 
+             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
              <literallayout class='monospaced'>
      $ bitbake -k core-image-sato
              </literallayout>
              <note><para>
                  BitBake requires Python 2.6 or 2.7.  For more information on this requirement, 
                  see the FAQ appendix in  
-                 <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+                 <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
                  The Yocto Project Reference Manual</ulink>.
              </para></note>
              The final command runs the image:
@@ -471,10 +496,10 @@
             <title>Installing the Toolchain</title>
             <para>
                 You can download the pre-built toolchain, which includes the <filename>runqemu</filename> 
-                script and support files, from 
-                <ulink url='http://yoctoproject.org/downloads/yocto-1.1/toolchain/'></ulink>.  
+                script and support files, from the appropriate directory under
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/'></ulink>.  
                 Toolchains are available for 32-bit and 64-bit development systems from the 
-                <filename>i686</filename> and <filename>x86_64</filename> folders, respectively. 
+                <filename>i686</filename> and <filename>x86_64</filename> directories, respectively. 
                 Each type of development system supports five target architectures.
                 The tarball files are named such that a string representing the host system appears 
                 first in the filename and then is immediately followed by a string representing
@@ -482,7 +507,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     yocto-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+     poky-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
@@ -500,7 +525,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
             </literallayout>
 
             <para>
@@ -513,16 +538,16 @@
             <para>
                 <literallayout class='monospaced'>
      $ cd /
-     $ sudo tar -xvjf ~/toolchains/yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
                 </literallayout>
             </para>
 
             <para>
                 For more information on how to install tarballs, see the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in  
-                <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>The Yocto Project 
-                Application Development Toolkit (ADT) Development Manual</ulink>.
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in  
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project 
+                Application Development Toolkit (ADT) User's Guide</ulink>.
             </para>
         </section>
 
@@ -531,7 +556,7 @@
       
             <para>
                 You can download the pre-built Linux kernel suitable for running in the QEMU emulator from 
-                <ulink url='http://yoctoproject.org/downloads/yocto-1.1/machines/qemu'></ulink>.
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
                 Be sure to use the kernel that matches the architecture you want to simulate.
                 Download areas exist for the five supported machine architectures:
                 <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
@@ -541,24 +566,19 @@
             <para>  
                 Most kernel files have one of the following forms:
                 <literallayout class='monospaced'>
-     *zImage-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
-     vmlinux-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
+     *zImage-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
+     vmlinux-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
 
      Where:
-         &lt;<emphasis>kernel-rev</emphasis>&gt; is the base Linux kernel revision 
-                (e.g. 2.6.37).
-
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
                 x86, x86-64, ppc, mips, or arm.
-
-         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project. 
                 </literallayout>
             </para>
 
             <para>
                 You can learn more about downloading a Yocto Project kernel in the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The 
+                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
+                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
                 Yocto Project Development Manual</ulink>.
             </para>
         </section>
@@ -568,7 +588,7 @@
 
             <para>
                 You can also download the filesystem image suitable for your target architecture from
-                <ulink url='http://yoctoproject.org/downloads/yocto-1.1/machines/qemu'></ulink>.
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
                 Again, be sure to use the filesystem that matches the architecture you want 
                 to simulate.
             </para>
@@ -581,19 +601,17 @@
                 The <filename>tar</filename> form can be flattened out in your host development system
                 and used for Yocto Project build purposes.
                 <literallayout class='monospaced'>
-     yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.ext3.bz2
-     yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.tar.bz2
+     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
+     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
 
      Where:
          &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
-                   lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
+                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
                    For information on these types of image profiles, see
-                   <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
+                   <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
 
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
                 x86, x86-64, ppc, mips, or arm.
-
-         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project. 
                 </literallayout>
             </para>
         </section>
@@ -605,7 +623,7 @@
                 Before you start the QEMU emulator, you need to set up the emulation environment.
                 The following command form sets up the emulation environment.
                 <literallayout class='monospaced'>
-     $ source /opt/poky/1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
+     $ source /opt/poky/1.1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
 
      Where:
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
@@ -635,12 +653,13 @@
             <para>
                 Continuing with the example, the following two commands setup the emulation 
                 environment and launch QEMU.
-                This example assumes the root filesystem tarball has been downloaded and expanded, and 
+                This example assumes the toolchain tarball has been downloaded and expanded
+                into <filename>/opt/poky</filename> and  
                 that the kernel and filesystem are for a 32-bit target architecture.
                 <literallayout class='monospaced'>
-     $ source /opt/poky/1.1/environment-setup-i686-poky-linux 
-     $ runqemu qemux86 bzImage-3.0-qemux86-1.1.bin \
-     yocto-image-sato-qemux86-1.1.rootfs.ext3
+     $ source /opt/poky/1.1.1/environment-setup-i586-poky-linux 
+     $ runqemu qemux86 bzImage-3.0-qemux86-1.1.1.bin \
+     core-image-sato-qemux86.ext3
                 </literallayout>
             </para>
 

meta-skeleton/recipes-skeleton/useradd/useradd-example.bb

@@ -17,13 +17,12 @@ PACKAGES =+ "${PN}-user3"
 
 inherit useradd
 
-# Specify which package(s) should include the user/group code.
-# Make sure that any packages which install files owned by custom
-# users/groups are included here. The code which adds users and
-# groups is idempotent.
+# You must set USERADD_PACKAGES when you inherit useradd. This
+# lists which output packages will include the user/group
+# creation code.
 USERADD_PACKAGES = "${PN} ${PN}-user3"
 
-# You *must* set USERADD_PARAM and/or GROUPADD_PARAM when
+# You must also set USERADD_PARAM and/or GROUPADD_PARAM when
 # you inherit useradd.
 
 # USERADD_PARAM specifies command line options to pass to the

meta-yocto/conf/distro/poky.conf

@@ -1,8 +1,8 @@
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 6.0)"
-DISTRO_VERSION = "1.1"
+DISTRO_NAME = "Yocto (Built by Poky 6.0.1)"
+DISTRO_VERSION = "1.1.1"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${DISTRO_VERSION}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -18,6 +18,11 @@ PREFERRED_VERSION_linux-yocto_qemux86-64 ?= "3.0%"
 PREFERRED_VERSION_linux-yocto_qemuarm ?= "3.0%"
 PREFERRED_VERSION_linux-yocto_qemumips ?= "3.0%"
 PREFERRED_VERSION_linux-yocto_qemuppc ?= "3.0%"
+PREFERRED_VERSION_linux-yocto-rt_qemux86 ?= "3.0%"
+PREFERRED_VERSION_linux-yocto-rt_qemux86-64 ?= "3.0%"
+PREFERRED_VERSION_linux-yocto-rt_qemuarm ?= "3.0%"
+PREFERRED_VERSION_linux-yocto-rt_qemumips ?= "3.0%"
+PREFERRED_VERSION_linux-yocto-rt_qemuppc ?= "3.0%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"

meta-yocto/conf/local.conf.sample.extended

@@ -15,6 +15,9 @@
 
 #DISTRO_FEATURES = "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci ${DISTRO_FEATURES_LIBC}"
 
+# If you want to get an image based on gtk+directfb without x11, Please copy this variable to build/conf/local.conf
+#DISTRO_FEATURES = "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g directfb ${DISTRO_FEATURES_LIBC}"
+
 # ENABLE_BINARY_LOCALE_GENERATION controls the generation of binary locale
 # packages at build time using qemu-native. Disabling it (by setting it to 0)
 # will save some build time at the expense of breaking i18n on devices with

meta-yocto/conf/machine/atom-pc.conf

@@ -6,7 +6,7 @@
 include conf/machine/include/tune-atom.inc
 
 MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 wifi \
-                    acpi"
+                    acpi alsa"
 
 KERNEL_IMAGETYPE = "bzImage"
 

meta/classes/autotools.bbclass

@@ -31,6 +31,8 @@ export CONFIG_SITE = "${@siteinfo_get_files(d)}"
 acpaths = "default"
 EXTRA_AUTORECONF = "--exclude=autopoint"
 
+export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir}"
+
 def autotools_set_crosscompiling(d):
 	if not bb.data.inherits_class('native', d):
 		return " cross_compiling=yes"
@@ -66,10 +68,8 @@ CONFIGUREOPTS = " --build=${BUILD_SYS} \
 
 oe_runconf () {
 	if [ -x ${S}/configure ] ; then
-		cfgcmd="${S}/configure \
-		${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
-		bbnote "Running $cfgcmd..."
-		$cfgcmd || bbfatal "oe_runconf failed" 
+		bbnote "Running ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
+		${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@" || bbfatal "oe_runconf failed"
 	else
 		bbfatal "no configure script found"
 	fi

meta/classes/base.bbclass

@@ -283,7 +283,7 @@ python base_eventhandler() {
 		logfile.close()
 }
 
-addtask configure after do_unpack do_patch
+addtask configure after do_patch
 do_configure[dirs] = "${CCACHE_DIR} ${S} ${B}"
 do_configure[deptask] = "do_populate_sysroot"
 base_do_configure() {
@@ -327,7 +327,7 @@ python () {
 
     # If PRINC is set, try and increase the PR value by the amount specified
     princ = bb.data.getVar('PRINC', d, True)
-    if princ:
+    if princ and princ != "0":
         pr = bb.data.getVar('PR', d, True)
         pr_prefix = re.search("\D+",pr)
         prval = re.search("\d+",pr)

meta/classes/buildstats.bbclass

@@ -48,14 +48,27 @@ def set_device(e):
     # something like stick DL_DIR on a different partition and this would
     # throw stats gathering off. The same goes with SSTATE_DIR. However, let's
     # get the basics in here and work on the cornercases later. 
+    # A note. /proc/diskstats does not contain info on encryptfs, tmpfs, etc.
+    # If we end up hitting one of these fs, we'll just skip diskstats collection.
     ############################################################################
     device=os.stat(tmpdir)
     majordev=os.major(device.st_dev)
     minordev=os.minor(device.st_dev)
-    for line in open("/proc/diskstats", "r"):
-        if majordev == int(line.split()[0]) and minordev == int(line.split()[1]):
-           rdev=line.split()[2]
-    file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
+    ############################################################################
+    # Bug 1700: 
+    # Because tmpfs/encryptfs/ramfs etc inserts no entry in /proc/diskstats
+    # we set rdev to NoLogicalDevice and search for it later. If we find NLD
+    # we do not collect diskstats as the method to collect meaningful statistics
+    # for these fs types requires a bit more research. 
+    ############################################################################
+    rdev="NoLogicalDevice"
+    try:
+        for line in open("/proc/diskstats", "r"):
+            if majordev == int(line.split()[0]) and minordev == int(line.split()[1]):
+               rdev=line.split()[2]
+    except:
+        pass
+    file = open(e.data.getVar('DEVFILE', True), "w")
     file.write(rdev)
     file.close()
     
@@ -71,12 +84,15 @@ def get_diskstats(dev):
     # For info on what these are, see kernel doc file iostats.txt
     ############################################################################
     DSTAT_KEYS = ['ReadsComp', 'ReadsMerged', 'SectRead', 'TimeReads', 'WritesComp', 'SectWrite', 'TimeWrite', 'IOinProgress', 'TimeIO', 'WTimeIO']  
-    for x in open("/proc/diskstats", "r"):
-        if dev in x:
-            diskstats_val = x.rstrip().split()[4:]
-    diskstats = dict(itertools.izip(DSTAT_KEYS, diskstats_val))        
+    try:
+        for x in open("/proc/diskstats", "r"):
+            if dev in x:
+                diskstats_val = x.rstrip().split()[4:]
+    except IOError as e:
+        return
+    diskstats = dict(itertools.izip(DSTAT_KEYS, diskstats_val))
     return diskstats
-    
+
 def set_diskdata(var, dev, data):
     data.setVar(var, get_diskstats(dev))
 
@@ -133,10 +149,11 @@ def write_task_data(status, logfile, dev, e):
     # For the best information, running things with BB_TOTAL_THREADS = "1"
     # would return accurate per task results.
     ############################################################################
-    diskdata = get_diskdata("__diskdata_task", dev, e.data)
-    if diskdata:
-        for key in sorted(diskdata.iterkeys()):
-            file.write(key + ": " + diskdata[key] + "\n")
+    if dev != "NoLogicalDevice":
+        diskdata = get_diskdata("__diskdata_task", dev, e.data)
+        if diskdata:
+            for key in sorted(diskdata.iterkeys()):
+                file.write(key + ": " + diskdata[key] + "\n")
     if status is "passed":
 	    file.write("Status: PASSED \n")
     else:
@@ -169,7 +186,8 @@ python run_buildstats () {
             bb.mkdirhier(bsdir)
         except:
             pass
-        set_diskdata("__diskdata_build", device, e.data)
+        if device != "NoLogicalDevice":
+            set_diskdata("__diskdata_build", device, e.data)
         set_timedata("__timedata_build", e.data)
         build_time = os.path.join(bsdir, "build_stats")
         # write start of build into build_time
@@ -185,7 +203,7 @@ python run_buildstats () {
                 
     elif isinstance(e, bb.event.BuildCompleted):
         bn = get_bn(e)
-        dev = get_device(e)
+        device = get_device(e)
         bsdir = os.path.join(bb.data.getVar('BUILDSTATS_BASE', e.data, True), bn)
         taskdir = os.path.join(bsdir, bb.data.expand("${PF}", e.data))
         build_time = os.path.join(bsdir, "build_stats")
@@ -201,10 +219,11 @@ python run_buildstats () {
             file.write("Elapsed time: %0.2f seconds \n" % (time))
             if cpu:
                 file.write("CPU usage: %0.1f%% \n" % cpu)
-        diskio = get_diskdata("__diskdata_build", dev, e.data)
-        if diskio:
-            for key in sorted(diskio.iterkeys()):
-                file.write(key + ": " + diskio[key] + "\n")
+        if device != "NoLogicalDevice":
+            diskio = get_diskdata("__diskdata_build", device, e.data)
+            if diskio:
+                for key in sorted(diskio.iterkeys()):
+                    file.write(key + ": " + diskio[key] + "\n")
         file.close()
 
     if isinstance(e, bb.build.TaskStarted):
@@ -212,7 +231,8 @@ python run_buildstats () {
         device = get_device(e)
         bsdir = os.path.join(bb.data.getVar('BUILDSTATS_BASE', e.data, True), bn)
         taskdir = os.path.join(bsdir, bb.data.expand("${PF}", e.data))
-        set_diskdata("__diskdata_task", device, e.data)
+        if device != "NoLogicalDevice":
+            set_diskdata("__diskdata_task", device, e.data)
         set_timedata("__timedata_task", e.data)
         try:
             bb.mkdirhier(taskdir)

meta/classes/distutils.bbclass

@@ -72,3 +72,5 @@ distutils_do_install() {
 }
 
 EXPORT_FUNCTIONS do_compile do_install
+
+export LDSHARED="${CCLD} -shared"

meta/classes/image.bbclass

@@ -5,8 +5,7 @@ inherit imagetest-${IMAGETEST}
 
 LICENSE = "MIT"
 PACKAGES = ""
-MULTILIB_IMAGE_INSTALL ?= ""
-RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${MULTILIB_IMAGE_INSTALL} ${NORMAL_FEATURE_INSTALL}"
+RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}"
 RRECOMMENDS += "${NORMAL_FEATURE_INSTALL_OPTIONAL}"
 
 INHIBIT_DEFAULT_DEPS = "1"
@@ -54,7 +53,6 @@ IMAGE_INSTALL ?= ""
 IMAGE_INSTALL[type] = "list"
 IMAGE_BASENAME[export] = "1"
 export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${FEATURE_INSTALL}"
-export MULTILIB_PACKAGE_INSTALL ?= "${MULTILIB_IMAGE_INSTALL}"
 PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
 
 # Images are generally built explicitly, do not need to be part of world.

meta/classes/image_types.bbclass

@@ -38,22 +38,22 @@ IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime --output=${DEPLO
 
 IMAGE_CMD_cramfs = "mkcramfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}"
 
-IMAGE_CMD_ext2 = "genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2"
+IMAGE_CMD_ext2 = "genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2"
 IMAGE_CMD_ext2.gz () {
 	rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN} && mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
-	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
+	genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
 	gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
 	mv ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.gz
 	rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
 }
 
 IMAGE_CMD_ext3 () {
-	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
+	genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
 	tune2fs -j ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
 }
 IMAGE_CMD_ext3.gz () {
 	rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN} && mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
-	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
+	genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
 	tune2fs -j ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
 	gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
 	mv ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3.gz
@@ -61,7 +61,7 @@ IMAGE_CMD_ext3.gz () {
 }
 
 oe_mkext4fs () {
-	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} $1
+	genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} $1
 	tune2fs -O extents,uninit_bg,dir_index,has_journal $1
 	e2fsck -yfDC0 $1 || chk=$?
 	case $chk in
@@ -111,7 +111,7 @@ IMAGE_CMD_ubi () {
 	echo vol_flags=autoresize >> ubinize.cfg
 	mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
 }
-IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
+IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}"
 
 EXTRA_IMAGECMD = ""
 EXTRA_IMAGECMD_jffs2 ?= "--pad --little-endian --eraseblock=0x40000"

meta/classes/imagetest-qemu.bbclass

@@ -70,7 +70,7 @@ def qemuimagetest_main(d):
         os.environ["DISPLAY"] = bb.data.getVar("DISPLAY", d, True)
         os.environ["COREBASE"] = bb.data.getVar("COREBASE", d, True)
         os.environ["TOPDIR"] = bb.data.getVar("TOPDIR", d, True)
-        os.environ["TMPDIR"] = bb.data.getVar("TMPDIR", d, True)
+        os.environ["OE_TMPDIR"] = bb.data.getVar("TMPDIR", d, True)
         os.environ["TEST_STATUS"] = bb.data.getVar("TEST_STATUS", d, True)
         os.environ["TARGET_IPSAVE"] = bb.data.getVar("TARGET_IPSAVE", d, True)
         os.environ["TEST_SERIALIZE"] = bb.data.getVar("TEST_SERIALIZE", d, True)
@@ -80,9 +80,31 @@ def qemuimagetest_main(d):
         bb.note("Run %s test in scenario %s" % (case, scen))
         os.system("%s" % fulltestpath)
     
+    """function to check testcase list and remove inappropriate cases"""
+    def check_list(list):
+	final_list = []
+	for test in list:
+	    (scen, case, fullpath) = test
+
+	    """Skip rpm/zypper if package_rpm not set for PACKAGE_CLASSES"""
+	    if case.find("zypper") != -1 or case.find("rpm") != -1:
+	        if d.getVar("PACKAGE_CLASSES", True).find("rpm", 0, 11) == -1:
+            	    bb.note("skip rpm/zypper cases since package_rpm not set in PACKAGE_CLASSES")
+	 	    continue
+	        else:
+		    final_list.append((scen, case, fullpath))
+	    else:
+                    final_list.append((scen, case, fullpath))
+
+	if not final_list:
+	    raise bb.build.FuncFailed("There is no suitable testcase for this target")
+
+	return final_list
+
     """Generate testcase list in runtime"""
     def generate_list(testlist):
         list = []
+	final_list = []
         if len(testlist) == 0:
             raise bb.build.FuncFailed("No testcase defined in TEST_SCEN")
 
@@ -114,7 +136,8 @@ def qemuimagetest_main(d):
                        if not os.path.isfile(fulltestcase):
                             raise bb.build.FuncFailed("Testcase %s not found" % fulltestcase)
                        list.append((item, casefile, fulltestcase))
-        return list
+	final_list = check_list(list)
+        return final_list
 
     """Clean tmp folder for testing"""
     def clean_tmp():

meta/classes/license.bbclass

@@ -44,7 +44,7 @@ SPDXLICENSEMAP[MPLv1.1] = "MPL-1"
 SPDXLICENSEMAP[MIT-X] = "MIT"
 
 #Openssl variations
-SPDXLICENSEMAP[openssl] = "Openssl"
+SPDXLICENSEMAP[openssl] = "OpenSSL"
 
 #Other variations
 SPDXLICENSEMAP[AFL2.1] = "AFL-2"

meta/classes/module.bbclass

@@ -14,8 +14,11 @@ do_make_scripts() {
 	           -C ${STAGING_KERNEL_DIR} scripts
 }
 
+addtask make_scripts before do_compile
+do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
+do_make_scripts[deptask] = "do_populate_sysroot"
+
 module_do_compile() {
-	do_make_scripts
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
 		   KERNEL_SRC=${STAGING_KERNEL_DIR}    \

meta/classes/multilib.bbclass

@@ -56,9 +56,8 @@ python __anonymous () {
         map_dependencies("PACKAGE_INSTALL", d)
         map_dependencies("LINGUAS_INSTALL", d)
         map_dependencies("RDEPENDS", d)
-        pinstall = d.getVar("LINGUAS_INSTALL", True) + " " + d.getVar("PACKAGE_INSTALL", True) + " " + d.getVar("MULTILIB_PACKAGE_INSTALL", False)
-        d.setVar("MULTILIB_PACKAGE_INSTALL", pinstall)
-        d.setVar("PACKAGE_INSTALL", "")
+        pinstall = d.getVar("LINGUAS_INSTALL", True) + " " + d.getVar("PACKAGE_INSTALL", True)
+        d.setVar("PACKAGE_INSTALL", pinstall)
         d.setVar("LINGUAS_INSTALL", "")
         # FIXME, we need to map this to something, not delete it!
         d.setVar("PACKAGE_INSTALL_ATTEMPTONLY", "")

meta/classes/native.bbclass

@@ -69,6 +69,11 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 libdir = "${STAGING_DIR_NATIVE}${libdir_native}"
 
+baselib = "lib"
+
+# Libtool's default paths are correct for the native machine
+lt_cv_sys_lib_dlsearch_path_spec[unexport] = "1"
+
 NATIVE_PACKAGE_PATH_SUFFIX = ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"

meta/classes/package.bbclass

@@ -916,16 +916,37 @@ python populate_packages () {
 			if file in seen:
 				continue
 			seen.append(file)
+
+			def mkdir(src, dest, p):
+				src = os.path.join(src, p)
+				dest = os.path.join(dest, p)
+				bb.mkdirhier(dest)
+				fstat = os.stat(src)
+				os.chmod(dest, fstat.st_mode)
+				os.chown(dest, fstat.st_uid, fstat.st_gid)
+				if p not in seen:
+					seen.append(p)
+
+			def mkdir_recurse(src, dest, paths):
+				while paths.startswith("./"):
+					paths = paths[2:]
+				p = "."
+				for c in paths.split("/"):
+					p = os.path.join(p, c)
+					if not os.path.exists(os.path.join(dest, p)):
+						mkdir(src, dest, p)
+
 			if os.path.isdir(file) and not os.path.islink(file):
-				bb.mkdirhier(os.path.join(root,file))
-				os.chmod(os.path.join(root,file), os.stat(file).st_mode)
+				mkdir_recurse(dvar, root, file)
 				continue
 
+			mkdir_recurse(dvar, root, os.path.dirname(file))
 			fpath = os.path.join(root,file)
-			dpath = os.path.dirname(fpath)
-			bb.mkdirhier(dpath)
 			if not os.path.islink(file):
 				os.link(file, fpath)
+				fstat = os.stat(file)
+				os.chmod(fpath, fstat.st_mode)
+				os.chown(fpath, fstat.st_uid, fstat.st_gid)
 				continue
 			ret = bb.copyfile(file, fpath)
 			if ret is False or ret == 0:
@@ -939,13 +960,13 @@ python populate_packages () {
 		dir = root[len(dvar):]
 		if not dir:
 			dir = os.sep
-		for f in files:
+		for f in (files + dirs):
 			path = os.path.join(dir, f)
 			if ('.' + path) not in seen:
 				unshipped.append(path)
 
 	if unshipped != []:
-		bb.warn("For recipe %s, the following files were installed but not shipped in any package:" % pn)
+		bb.warn("For recipe %s, the following files/directories were installed but not shipped in any package:" % pn)
 		for f in unshipped:
 			bb.warn("  " + f)
 
@@ -1089,7 +1110,7 @@ if [ x"$D" = "x" ]; then
 fi
 }
 
-RPMDEPS = "${STAGING_LIBDIR_NATIVE}/rpm/bin/rpmdeps"
+RPMDEPS = "${STAGING_LIBDIR_NATIVE}/rpm/bin/rpmdeps --macros ${STAGING_LIBDIR_NATIVE}/rpm/macros --define '_rpmfc_magic_path ${STAGING_DIR_NATIVE}/usr/share/misc/magic.mgc' --rpmpopt ${STAGING_LIBDIR_NATIVE}/rpm/rpmpopt"
 
 # Collect perfile run-time dependency metadata
 # Output:

meta/classes/package_ipk.bbclass

@@ -83,12 +83,34 @@ package_tryout_install_multilib_ipk() {
 		fi
 	done
 }
+
+split_multilib_packages() {
+	INSTALL_PACKAGES_NORMAL_IPK=""
+	INSTALL_PACKAGES_MULTILIB_IPK=""
+	for pkg in ${INSTALL_PACKAGES_IPK}; do
+		is_multilib=0
+		for item in ${MULTILIB_VARIANTS}; do
+			local pkgname_prefix="${item}-"
+			if [ ${pkg:0:${#pkgname_prefix}} == ${pkgname_prefix} ]; then
+				is_multilib=1
+				break
+			fi
+		done
+
+		if [ ${is_multilib} = 0 ]; then
+			INSTALL_PACKAGES_NORMAL_IPK="${INSTALL_PACKAGES_NORMAL_IPK} ${pkg}"
+		else
+			INSTALL_PACKAGES_MULTILIB_IPK="${INSTALL_PACKAGES_MULTILIB_IPK} ${pkg}"
+		fi
+	done
+}
+
 #
 # install a bunch of packages using opkg
 # the following shell variables needs to be set before calling this func:
 # INSTALL_ROOTFS_IPK - install root dir
 # INSTALL_CONF_IPK - configuration file
-# INSTALL_PACKAGES_NORMAL_IPK - packages to be installed
+# INSTALL_PACKAGES_IPK - packages to be installed
 # INSTALL_PACKAGES_ATTEMPTONLY_IPK - packages attemped to be installed only
 # INSTALL_PACKAGES_LINGUAS_IPK - additional packages for uclibc
 # INSTALL_TASK_IPK - task name
@@ -97,15 +119,18 @@ package_install_internal_ipk() {
 
 	local target_rootfs="${INSTALL_ROOTFS_IPK}"
 	local conffile="${INSTALL_CONF_IPK}"
-	local package_to_install="${INSTALL_PACKAGES_NORMAL_IPK}"
 	local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_IPK}"
 	local package_linguas="${INSTALL_PACKAGES_LINGUAS_IPK}"
-	local package_multilib="${INSTALL_PACKAGES_MULTILIB_IPK}"
 	local task="${INSTALL_TASK_IPK}"
 
+	split_multilib_packages
+
+	local package_to_install="${INSTALL_PACKAGES_NORMAL_IPK}"
+	local package_multilib="${INSTALL_PACKAGES_MULTILIB_IPK}"
+
 	mkdir -p ${target_rootfs}${localstatedir}/lib/opkg/
 
-	local ipkg_args="-f ${conffile} -o ${target_rootfs} --force-overwrite"
+	local ipkg_args="-f ${conffile} -o ${target_rootfs} --force-overwrite --force_postinstall"
 
 	opkg-cl ${ipkg_args} update
 

meta/classes/package_rpm.bbclass

@@ -154,7 +154,7 @@ resolve_package_rpm () {
 # INSTALL_PLATFORM_RPM - main platform
 # INSTALL_PLATFORM_EXTRA_RPM - extra platform
 # INSTALL_CONFBASE_RPM - configuration file base name
-# INSTALL_PACKAGES_NORMAL_RPM - packages to be installed
+# INSTALL_PACKAGES_RPM - packages to be installed
 # INSTALL_PACKAGES_ATTEMPTONLY_RPM - packages attemped to be installed only
 # INSTALL_PACKAGES_LINGUAS_RPM - additional packages for uclibc
 # INSTALL_PROVIDENAME_RPM - content for provide name
@@ -166,8 +166,7 @@ package_install_internal_rpm () {
 	local platform="${INSTALL_PLATFORM_RPM}"
 	local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
 	local confbase="${INSTALL_CONFBASE_RPM}"
-	local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}"
-	local multilib_to_install="${INSTALL_PACKAGES_MULTILIB_RPM}"
+	local package_to_install="${INSTALL_PACKAGES_RPM}"
 	local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"
 	local package_linguas="${INSTALL_PACKAGES_LINGUAS_RPM}"
 	local providename="${INSTALL_PROVIDENAME_RPM}"
@@ -211,12 +210,14 @@ package_install_internal_rpm () {
 				echo "Processing $pkg..."
 
 				archvar=base_archs
+				manifest=install.manifest
 				ml_prefix=`echo ${pkg} | cut -d'-' -f1`
 				ml_pkg=$pkg
 				for i in ${MULTILIB_PREFIX_LIST} ; do
 					if [ ${ml_prefix} == ${i} ]; then
 						ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
 						archvar=ml_archs
+						manifest=install_multilib.manifest
 						break
 					fi
 				done
@@ -226,7 +227,7 @@ package_install_internal_rpm () {
 					echo "Unable to find package $pkg ($ml_pkg)!"
 					exit 1
 				fi
-				echo $pkg_name >> ${target_rootfs}/install/install.manifest
+				echo $pkg_name >> ${target_rootfs}/install/${manifest}
 			done
 		fi
 	fi
@@ -235,12 +236,14 @@ package_install_internal_rpm () {
 			echo "Processing $pkg..."
 
 			archvar=base_archs
+			manifest=install.manifest
 			ml_prefix=`echo ${pkg} | cut -d'-' -f1`
 			ml_pkg=$pkg
 			for i in ${MULTILIB_PREFIX_LIST} ; do
 				if [ ${ml_prefix} == ${i} ]; then
 					ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
 					archvar=ml_archs
+					manifest=install_multilib.manifest
 					break
 				fi
 			done
@@ -250,7 +253,7 @@ package_install_internal_rpm () {
 				echo "Unable to find package $pkg ($ml_pkg)!"
 				exit 1
 			fi
-			echo $pkg_name >> ${target_rootfs}/install/install.manifest
+			echo $pkg_name >> ${target_rootfs}/install/${manifest}
 		done
 	fi
 
@@ -356,29 +359,7 @@ package_install_internal_rpm () {
 
 	touch ${target_rootfs}/install/install_multilib_solution.manifest
 
-	if [ ! -z "${multilib_to_install}" ]; then
-		for pkg in ${multilib_to_install} ; do
-			echo "Processing $pkg..."
-
-			archvar=base_archs
-			ml_prefix=`echo ${pkg} | cut -d'-' -f1`
-			ml_pkg=$pkg
-			for i in ${MULTILIB_PREFIX_LIST} ; do
-				if [ ${ml_prefix} == ${i} ]; then
-					ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
-					archvar=ml_archs
-					break
-				fi
-			done
-
-			pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
-			if [ -z "$pkg_name" ]; then
-				echo "Unable to find package $pkg ($ml_pkg)!"
-				exit 1
-			fi
-			echo $pkg_name >> ${target_rootfs}/install/install_multilib.manifest
-		done
-
+	if [ -e "${target_rootfs}/install/install_multilib.manifest" ]; then
 		# multilib package installation
 
 		# Generate an install solution by doing a --justdb install, then recreate it with
@@ -401,13 +382,39 @@ package_install_internal_rpm () {
 	cat ${target_rootfs}/install/install_solution.manifest > ${target_rootfs}/install/total_solution.manifest
 	cat ${target_rootfs}/install/install_multilib_solution.manifest >> ${target_rootfs}/install/total_solution.manifest
 
+	# Construct install scriptlet wrapper
+	cat << EOF > ${WORKDIR}/scriptlet_wrapper
+#!/bin/bash
+
+export PATH="${PATH}"
+export D="${target_rootfs}"
+export OFFLINE_ROOT="\$D"
+export IPKG_OFFLINE_ROOT="\$D"
+export OPKG_OFFLINE_ROOT="\$D"
+
+\$2 \$1/\$3 \$4
+if [ \$? -ne 0 ]; then
+  mkdir -p \$1/etc/rpm-postinsts
+  num=100
+  while [ -e \$1/etc/rpm-postinsts/\${num} ]; do num=\$((num + 1)); done
+  echo "#!\$2" > \$1/etc/rpm-postinsts/\${num}
+  echo "# Arg: \$4" >> \$1/etc/rpm-postinsts/\${num}
+  cat \$1/\$3 >> \$1/etc/rpm-postinsts/\${num}
+  chmod +x \$1/etc/rpm-postinsts/\${num}
+fi
+EOF
+
+	chmod 0755 ${WORKDIR}/scriptlet_wrapper
+
 	# Attempt install
 	${RPM} --root ${target_rootfs} \
 		--predefine "_rpmds_sysinfo_path ${target_rootfs}/etc/rpm/sysinfo" \
 		--predefine "_rpmrc_platform_path ${target_rootfs}/etc/rpm/platform" \
+		-D "_var ${localstatedir}" \
 		-D "_dbpath ${rpmlibdir}" \
-		--noscripts --notriggers --noparentdirs --nolinktos --replacepkgs \
+		--noparentdirs --nolinktos --replacepkgs \
 		-D "__dbi_txn create nofsync private" \
+		-D "_cross_scriptlet_wrapper ${WORKDIR}/scriptlet_wrapper" \
 		-Uhv ${target_rootfs}/install/total_solution.manifest
 }
 
@@ -490,6 +497,16 @@ python write_specfile () {
 				else:
 					target.append(path + "/" + file)
 
+	# Prevent the prerm/postrm scripts from being run during an upgrade
+	def wrap_uninstall(scriptvar):
+		scr = scriptvar.strip()
+		if scr.startswith("#!"):
+			pos = scr.find("\n") + 1
+		else:
+			pos = 0
+		scr = scr[:pos] + 'if [ "$1" = "0" ] ; then\n' + scr[pos:] + '\nfi'
+		return scr
+
 	packages = bb.data.getVar('PACKAGES', d, True)
 	if not packages or packages == '':
 		bb.debug(1, "No packages; nothing to do")
@@ -690,8 +707,11 @@ python write_specfile () {
 				spec_scriptlets_bottom.append('%%post -n %s' % splitname)
 			elif script == 'prerm':
 				spec_scriptlets_bottom.append('%%preun -n %s' % splitname)
+				scriptvar = wrap_uninstall(scriptvar)
 			elif script == 'postrm':
 				spec_scriptlets_bottom.append('%%postun -n %s' % splitname)
+				scriptvar = wrap_uninstall(scriptvar)
+			spec_scriptlets_bottom.append('# %s - %s' % (splitname, script))
 			spec_scriptlets_bottom.append(scriptvar)
 			spec_scriptlets_bottom.append('')
 
@@ -769,19 +789,25 @@ python write_specfile () {
 
 	if srcpreinst:
 		spec_scriptlets_top.append('%pre')
+		spec_scriptlets_top.append('# %s - preinst' % srcname)
 		spec_scriptlets_top.append(srcpreinst)
 		spec_scriptlets_top.append('')
 	if srcpostinst:
 		spec_scriptlets_top.append('%post')
+		spec_scriptlets_top.append('# %s - postinst' % srcname)
 		spec_scriptlets_top.append(srcpostinst)
 		spec_scriptlets_top.append('')
 	if srcprerm:
 		spec_scriptlets_top.append('%preun')
-		spec_scriptlets_top.append(srcprerm)
+		spec_scriptlets_top.append('# %s - prerm' % srcname)
+		scriptvar = wrap_uninstall(srcprerm)
+		spec_scriptlets_top.append(scriptvar)
 		spec_scriptlets_top.append('')
 	if srcpostrm:
 		spec_scriptlets_top.append('%postun')
-		spec_scriptlets_top.append(srcpostrm)
+		spec_scriptlets_top.append('# %s - postrm' % srcname)
+		scriptvar = wrap_uninstall(srcpostrm)
+		spec_scriptlets_top.append(scriptvar)
 		spec_scriptlets_top.append('')
 
 	# Write the SPEC file
@@ -929,6 +955,7 @@ python do_package_rpm () {
 	cmd = cmd + " --define '_unpackaged_files_terminate_build 0'"
 	cmd = cmd + " --define 'debug_package %{nil}'"
 	cmd = cmd + " --define '_rpmfc_magic_path " + magicfile + "'"
+	cmd = cmd + " --define '_tmppath " + workdir + "'"
 	cmd = cmd + " -bb " + outspecfile
 
 	# Build the rpm package!

meta/classes/patch.bbclass

@@ -138,7 +138,7 @@ python patch_do_patch() {
 			raise bb.build.FuncFailed(str(sys.exc_value))
 		resolver.Resolve()
 }
-patch_do_patch[vardepsexclude] = "DATE SRCDATE"
+patch_do_patch[vardepsexclude] = "DATE SRCDATE PATCHRESOLVE"
 
 addtask patch after do_unpack
 do_patch[dirs] = "${WORKDIR}"

meta/classes/populate_sdk.bbclass

@@ -18,6 +18,13 @@ PID = "${@os.getpid()}"
 
 EXCLUDE_FROM_WORLD = "1"
 
+python () {
+    # If we don't do this we try and run the mapping hooks while parsing which is slow
+    # bitbake should really provide something to let us know this...
+    if bb.data.getVar('BB_WORKERCONTEXT', d, True) is not None:
+        runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", d)
+}
+
 fakeroot do_populate_sdk() {
 	rm -rf ${SDK_OUTPUT}
 	mkdir -p ${SDK_OUTPUT}

meta/classes/populate_sdk_deb.bbclass

@@ -13,7 +13,7 @@ populate_sdk_post_deb () {
 	tar -cf - -C ${STAGING_ETCDIR_NATIVE} -ps apt | tar -xf - -C ${target_rootfs}/etc
 }
 
-fakeroot populate_sdk_deb () {
+populate_sdk_deb () {
 
 	# update index
 	package_update_index_deb
@@ -27,7 +27,7 @@ fakeroot populate_sdk_deb () {
 	export INSTALL_ROOTFS_DEB="${SDK_OUTPUT}/${SDKTARGETSYSROOT}"
 	export INSTALL_BASEARCH_DEB="${DPKG_ARCH}"
 	export INSTALL_ARCHS_DEB="${PACKAGE_ARCHS}"
-	export INSTALL_PACKAGES_NORMAL_DEB="${TOOLCHAIN_TARGET_TASK}"
+	export INSTALL_PACKAGES_DEB="${TOOLCHAIN_TARGET_TASK}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_DEB=""
 	export PACKAGES_LINGUAS_DEB=""
 	export INSTALL_TASK_DEB="populate_sdk-target"
@@ -43,7 +43,7 @@ fakeroot populate_sdk_deb () {
 	export INSTALL_ROOTFS_DEB="${SDK_OUTPUT}"
 	export INSTALL_BASEARCH_DEB="${DEB_SDK_ARCH}"
 	export INSTALL_ARCHS_DEB="${SDK_PACKAGE_ARCHS}"
-	export INSTALL_PACKAGES_NORMAL_DEB="${TOOLCHAIN_HOST_TASK}"
+	export INSTALL_PACKAGES_DEB="${TOOLCHAIN_HOST_TASK}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_DEB=""
 	export PACKAGES_LINGUAS_DEB=""
 	export INSTALL_TASK_DEB="populate_sdk-nativesdk"

meta/classes/populate_sdk_ipk.bbclass

@@ -1,7 +1,7 @@
 do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
 do_populate_sdk[recrdeptask] += "do_package_write_ipk"
 
-fakeroot populate_sdk_ipk() {
+populate_sdk_ipk() {
 
 	rm -f ${IPKGCONF_TARGET}
 	touch ${IPKGCONF_TARGET}
@@ -18,14 +18,14 @@ fakeroot populate_sdk_ipk() {
 	#install target
 	export INSTALL_ROOTFS_IPK="${SDK_OUTPUT}/${SDKTARGETSYSROOT}"
 	export INSTALL_CONF_IPK="${IPKGCONF_TARGET}"
-	export INSTALL_PACKAGES_NORMAL_IPK="${TOOLCHAIN_TARGET_TASK}"
+	export INSTALL_PACKAGES_IPK="${TOOLCHAIN_TARGET_TASK}"
 
 	package_install_internal_ipk
 
 	#install host
 	export INSTALL_ROOTFS_IPK="${SDK_OUTPUT}"
 	export INSTALL_CONF_IPK="${IPKGCONF_SDK}"
-	export INSTALL_PACKAGES_NORMAL_IPK="${TOOLCHAIN_HOST_TASK}"
+	export INSTALL_PACKAGES_IPK="${TOOLCHAIN_HOST_TASK}"
 
 	package_install_internal_ipk
 

meta/classes/populate_sdk_rpm.bbclass

@@ -21,7 +21,7 @@ populate_sdk_post_rpm () {
 	rm -rf ${target_rootfs}/install
 }
 
-fakeroot populate_sdk_rpm () {
+populate_sdk_rpm () {
 
 	package_update_index_rpm
 	package_generate_rpm_conf
@@ -32,7 +32,7 @@ fakeroot populate_sdk_rpm () {
 	export INSTALL_ROOTFS_RPM="${SDK_OUTPUT}/${SDKTARGETSYSROOT}"
 	export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_TARGET_BASE}"
-	export INSTALL_PACKAGES_NORMAL_RPM="${TOOLCHAIN_TARGET_TASK}"
+	export INSTALL_PACKAGES_RPM="${TOOLCHAIN_TARGET_TASK}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_RPM=""
 	export INSTALL_PACKAGES_LINGUAS_RPM=""
 	export INSTALL_PROVIDENAME_RPM="/bin/sh /bin/bash /usr/bin/env /usr/bin/perl pkgconfig pkgconfig(pkg-config)"
@@ -81,7 +81,7 @@ EOF
 	export INSTALL_ROOTFS_RPM="${SDK_OUTPUT}"
 	export INSTALL_PLATFORM_RPM="${SDK_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_HOST_BASE}"
-	export INSTALL_PACKAGES_NORMAL_RPM="${TOOLCHAIN_HOST_TASK}"
+	export INSTALL_PACKAGES_RPM="${TOOLCHAIN_HOST_TASK}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_RPM=""
 	export INSTALL_PACKAGES_LINGUAS_RPM=""
 	export INSTALL_PROVIDENAME_RPM="/bin/sh /bin/bash /usr/bin/env /usr/bin/perl pkgconfig libGL.so()(64bit) libGL.so"

meta/classes/rootfs_ipk.bbclass

@@ -44,7 +44,7 @@ fakeroot rootfs_ipk_do_rootfs () {
 		pkginfo="`opkg-cl ${IPKG_ARGS} info $i`"
 		if [ ! -z "$pkginfo" ]; then
 			echo "$pkginfo" | grep -e '^Package:' -e '^Architecture:' -e '^Version:' >> $STATUS
-			echo "Status: deinstall ok not-installed" >> $STATUS
+			echo "Status: deinstall hold not-installed" >> $STATUS
 			echo >> $STATUS
 		else
 			echo "Requested ignored recommendation $i is not a package"
@@ -58,10 +58,7 @@ fakeroot rootfs_ipk_do_rootfs () {
 
 	export INSTALL_ROOTFS_IPK="${IMAGE_ROOTFS}"
 	export INSTALL_CONF_IPK="${IPKGCONF_TARGET}"
-	export INSTALL_PACKAGES_NORMAL_IPK="${PACKAGE_INSTALL}"
-	export INSTALL_PACKAGES_MULTILIB_IPK="${MULTILIB_PACKAGE_INSTALL}"
-
-	package_install_internal_ipk
+	export INSTALL_PACKAGES_IPK="${PACKAGE_INSTALL}"
 
 	#post install
 	export D=${IMAGE_ROOTFS}
@@ -69,6 +66,8 @@ fakeroot rootfs_ipk_do_rootfs () {
 	export IPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export OPKG_OFFLINE_ROOT=${IPKG_OFFLINE_ROOT}
 
+	package_install_internal_ipk
+
 	# Distro specific packages should create this
 	#mkdir -p ${IMAGE_ROOTFS}/etc/opkg/
 	#grep "^arch" ${IPKGCONF_TARGET} >${IMAGE_ROOTFS}/etc/opkg/arch.conf
@@ -76,22 +75,8 @@ fakeroot rootfs_ipk_do_rootfs () {
 	${OPKG_POSTPROCESS_COMMANDS}
 	${ROOTFS_POSTINSTALL_COMMAND}
 	
-	runtime_script_required=0
-	for i in ${IMAGE_ROOTFS}${opkglibdir}/info/*.preinst; do
-		if [ -f $i ] && ! sh $i; then
-		     	runtime_script_required=1
-			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .preinst`
-		fi
-	done
-	for i in ${IMAGE_ROOTFS}${opkglibdir}/info/*.postinst; do
-		if [ -f $i ] && ! sh $i configure; then
-		     	runtime_script_required=1
-			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .postinst`
-		fi
-	done
-
 	if ${@base_contains("IMAGE_FEATURES", "read-only-rootfs", "true", "false" ,d)}; then
-		if [ $runtime_script_required -eq 1 ]; then
+		if grep Status:.install.ok.unpacked ${IMAGE_ROOTFS}${opkglibdir}status; then
 			echo "Some packages could not be configured offline and rootfs is read-only."
 			exit 1
 		fi

meta/classes/rootfs_rpm.bbclass

@@ -20,8 +20,6 @@ do_rootfs[depends] += "opkg-native:do_populate_sysroot"
 
 do_rootfs[recrdeptask] += "do_package_write_rpm"
 
-AWKPOSTINSTSCRIPT = "${COREBASE}/scripts/rootfs_rpm-extract-postinst.awk"
-
 RPM_PREPROCESS_COMMANDS = "package_update_index_rpm; package_generate_rpm_conf; "
 RPM_POSTPROCESS_COMMANDS = ""
 
@@ -46,7 +44,7 @@ RPM="rpm ${RPMOPTS}"
 do_rootfs[lockfiles] += "${DEPLOY_DIR_RPM}/rpm.lock"
 
 fakeroot rootfs_rpm_do_rootfs () {
-	#set +x
+	set +x
 
 	${RPM_PREPROCESS_COMMANDS}
 
@@ -57,8 +55,7 @@ fakeroot rootfs_rpm_do_rootfs () {
 	export INSTALL_ROOTFS_RPM="${IMAGE_ROOTFS}"
 	export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_TARGET_BASE}"
-	export INSTALL_PACKAGES_NORMAL_RPM="${PACKAGE_INSTALL}"
-	export INSTALL_PACKAGES_MULTILIB_RPM="${MULTILIB_PACKAGE_INSTALL}"
+	export INSTALL_PACKAGES_RPM="${PACKAGE_INSTALL}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_RPM="${PACKAGE_INSTALL_ATTEMPTONLY}"
 	export INSTALL_PACKAGES_LINGUAS_RPM="${LINGUAS_INSTALL}"
 	export INSTALL_PROVIDENAME_RPM=""
@@ -109,19 +106,9 @@ EOF
 
 	${ROOTFS_POSTINSTALL_COMMAND}
 
-	mkdir -p ${IMAGE_ROOTFS}/etc/rpm-postinsts/
-	${RPM} --root ${IMAGE_ROOTFS} -D '_dbpath ${rpmlibdir}' -qa \
-		-D "__dbi_txn create nofsync private" \
-		--qf 'Name: %{NAME}\n%|POSTIN?{postinstall scriptlet%|POSTINPROG?{ (using %{POSTINPROG})}|:\n%{POSTIN}\n}:{%|POSTINPROG?{postinstall program: %{POSTINPROG}\n}|}|' \
-		> ${IMAGE_ROOTFS}/etc/rpm-postinsts/combined
-	awk -f ${AWKPOSTINSTSCRIPT} < ${IMAGE_ROOTFS}/etc/rpm-postinsts/combined
-	rm ${IMAGE_ROOTFS}/etc/rpm-postinsts/combined	
-
-	for i in ${IMAGE_ROOTFS}/etc/rpm-postinsts/*.sh; do
-		if [ -f $i ] && sh $i; then
-			# rm $i
-			mv $i $i.done
-		fi
+	# Report delayed package scriptlets
+	for i in ${IMAGE_ROOTFS}/etc/rpm-postinsts/*; do
+		echo "Delayed package scriptlet: `head -n 3 $i | tail -n 1`"
 	done
 
 	install -d ${IMAGE_ROOTFS}/${sysconfdir}/rcS.d
@@ -129,11 +116,10 @@ EOF
 	i=\$i
 	cat > ${IMAGE_ROOTFS}${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}configure << EOF
 #!/bin/sh
-for i in /etc/rpm-postinsts/*.sh; do
+for i in /etc/rpm-postinsts/*; do
 	echo "Running postinst $i..."
-	if [ -f $i ] && sh $i; then
-		# rm $i
-		mv $i $i.done
+	if [ -f $i ] && $i; then
+		rm $i
 	else
 		echo "ERROR: postinst $i failed."
 	fi

meta/classes/sstate.bbclass

@@ -114,15 +114,16 @@ def sstate_install(ss, d):
     for state in ss['dirs']:
         oe.path.copytree(state[1], state[2])
         for walkroot, dirs, files in os.walk(state[1]):
+            bb.debug(2, "Staging files from %s to %s" % (state[1], state[2]))
             for file in files:
                 srcpath = os.path.join(walkroot, file)
                 dstpath = srcpath.replace(state[1], state[2])
-                bb.debug(2, "Staging %s to %s" % (srcpath, dstpath))
+                #bb.debug(2, "Staging %s to %s" % (srcpath, dstpath))
                 sharedfiles.append(dstpath)
             for dir in dirs:
                 srcdir = os.path.join(walkroot, dir)
                 dstdir = srcdir.replace(state[1], state[2])
-                bb.debug(2, "Staging %s to %s" % (srcdir, dstdir))
+                #bb.debug(2, "Staging %s to %s" % (srcdir, dstdir))
                 if not dstdir.endswith("/"):
                     dstdir = dstdir + "/"
                 shareddirs.append(dstdir)
@@ -258,10 +259,15 @@ def sstate_clean(ss, d):
             bb.utils.unlockfile(lock)
 
     stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
+    extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info', True)
     oe.path.remove(stfile)
     oe.path.remove(stfile + "_setscene")
-    oe.path.remove(stfile + ".*")
-    oe.path.remove(stfile + "_setscene" + ".*")
+    if extrainf:
+        oe.path.remove(stfile + ".*" + extrainf)
+        oe.path.remove(stfile + "_setscene" + ".*" + extrainf)
+    else:
+        oe.path.remove(stfile + ".*")
+        oe.path.remove(stfile + "_setscene" + ".*")
 
 CLEANFUNCS += "sstate_cleanall"
 
@@ -355,12 +361,12 @@ def sstate_package(ss, d):
             for file in files:
                 srcpath = os.path.join(walkroot, file)
                 dstpath = srcpath.replace(state[1], sstatebuild + state[0])
-                bb.debug(2, "Preparing %s for packaging at %s" % (srcpath, dstpath))
                 make_relative_symlink(srcpath, dstpath, d)
             for dir in dirs:
                 srcpath = os.path.join(walkroot, dir)
                 dstpath = srcpath.replace(state[1], sstatebuild + state[0])
                 make_relative_symlink(srcpath, dstpath, d)
+        bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], sstatebuild + state[0]))
         oe.path.copytree(state[1], sstatebuild + state[0])
 
     workdir = bb.data.getVar('WORKDIR', d, True)

meta/classes/useradd.bbclass

@@ -1,10 +1,9 @@
-USERADDPN ?= "${PN}"
-
 # base-passwd-cross provides the default passwd and group files in the
 # target sysroot, and shadow -native and -sysroot provide the utilities
 # and support files needed to add and modify user and group accounts
-DEPENDS_append = " base-passwd shadow-native shadow-sysroot"
-RDEPENDS_${USERADDPN}_append = " base-passwd shadow"
+DEPENDS_append = "${USERADDDEPENDS}"
+USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow"
+USERADDDEPENDS_virtclass-nativesdk = ""
 
 # This preinstall function will be run in two contexts: once for the
 # native sysroot (as invoked by the useradd_sysroot() wrapper), and
@@ -37,7 +36,13 @@ if test "x$GROUPADD_PARAM" != "x"; then
 	opts=`echo "$GROUPADD_PARAM" | cut -d ';' -f 1`
 	remaining=`echo "$GROUPADD_PARAM" | cut -d ';' -f 2-`
 	while test "x$opts" != "x"; do
-		eval $PSEUDO groupadd -f $OPT $opts
+		groupname=`echo "$opts" | awk '{ print $NF }'`
+		group_exists=`grep "^$groupname:" $SYSROOT/etc/group || true`
+		if test "x$group_exists" = "x"; then
+			eval $PSEUDO groupadd  $OPT $opts
+		else
+			echo "Note: group $groupname already exists, not re-creating it"
+		fi
 
 		if test "x$opts" = "x$remaining"; then
 			break
@@ -90,35 +95,38 @@ useradd_sysroot_sstate () {
 	fi
 }
 
-do_install[prefuncs] += "useradd_sysroot"
-SSTATEPOSTINSTFUNCS += "useradd_sysroot_sstate"
+do_install[prefuncs] += "${SYSROOTFUNC}"
+SYSROOTFUNC = "useradd_sysroot"
+SYSROOTFUNC_virtclass-nativesdk = ""
+SSTATEPOSTINSTFUNCS += "${SYSROOTPOSTFUNC}"
+SYSROOTPOSTFUNC = "useradd_sysroot_sstate"
+SYSROOTPOSTFUNC_virtclass-nativesdk = ""
 
 # Recipe parse-time sanity checks
 def update_useradd_after_parse(d):
-	if not d.getVar('USERADD_PACKAGES', False):
-		if not d.getVar('USERADD_PARAM', False) and not d.getVar('GROUPADD_PARAM', False):
-			raise bb.build.FuncFailed, "%s inherits useradd but doesn't set USERADD_PARAM or GROUPADD_PARAM" % bb.data.getVar('FILE', d)
+	useradd_packages = d.getVar('USERADD_PACKAGES', True)
+
+	if not useradd_packages:
+		raise bb.build.FuncFailed, "%s inherits useradd but doesn't set USERADD_PACKAGES" % bb.data.getVar('FILE', d)
+
+	for pkg in useradd_packages.split():
+		if not d.getVar('USERADD_PARAM_%s' % pkg, True) and not d.getVar('GROUPADD_PARAM_%s' % pkg, True):
+			raise bb.build.FuncFailed, "%s inherits useradd but doesn't set USERADD_PARAM or GROUPADD_PARAM for package %s" % (bb.data.getVar('FILE', d), pkg)
 
 python __anonymous() {
 	update_useradd_after_parse(d)
 }
 
 # Return a single [GROUP|USER]ADD_PARAM formatted string which includes the
-# [group|user]add parameters for all packages in this recipe
+# [group|user]add parameters for all USERADD_PACKAGES in this recipe
 def get_all_cmd_params(d, cmd_type):
 	import string
 	
 	param_type = cmd_type.upper() + "ADD_PARAM_%s"
 	params = []
 
-	pkgs = d.getVar('USERADD_PACKAGES', True)
-	if not pkgs:
-		pkgs = d.getVar('USERADDPN', True)
-		packages = (d.getVar('PACKAGES', True) or "").split()
-		if packages and pkgs not in packages:
-			pkgs = packages[0]
-
-	for pkg in pkgs.split():
+	useradd_packages = d.getVar('USERADD_PACKAGES', True) or ""
+	for pkg in useradd_packages.split():
 		param = d.getVar(param_type % pkg, True)
 		if param:
 			params.append(param)
@@ -141,16 +149,15 @@ fakeroot python populate_packages_prepend () {
 		preinst += d.getVar('useradd_preinst', True)
 		bb.data.setVar('pkg_preinst_%s' % pkg, preinst, d)
 
-	# We add the user/group calls to all packages to allow any package
-	# to contain files owned by the users/groups defined in the recipe.
-	# The user/group addition code is careful not to create duplicate
-	# entries, so this is safe.
-	pkgs = d.getVar('USERADD_PACKAGES', True)
-	if not pkgs:
-		pkgs = d.getVar('USERADDPN', True)
-		packages = (d.getVar('PACKAGES', True) or "").split()
-		if packages and pkgs not in packages:
-			pkgs = packages[0]
-	for pkg in pkgs.split():
-		update_useradd_package(pkg)
+		# RDEPENDS setup
+		rdepends = d.getVar("RDEPENDS_%s" % pkg, True) or ""
+		rdepends += " base-passwd shadow"
+		bb.data.setVar("RDEPENDS_%s" % pkg, rdepends, d)
+
+	# Add the user/group preinstall scripts and RDEPENDS requirements
+	# to packages specified by USERADD_PACKAGES
+	if not bb.data.inherits_class('nativesdk', d):
+		useradd_packages = d.getVar('USERADD_PACKAGES', True) or ""
+		for pkg in useradd_packages.split():
+			update_useradd_package(pkg)
 }

meta/conf/bitbake.conf

@@ -8,6 +8,7 @@
 
 # Used by multilib code to change the library paths
 baselib = "${BASELIB}"
+baselib[vardepvalue] = "${baselib}"
 BASELIB = "lib"
 BASELIB_powerpc64 = "lib64"
 
@@ -159,7 +160,6 @@ ASSUME_PROVIDED = "\
     python-native-runtime \
     svn-native \
     tar-native \
-    texinfo-native \
     virtual/libintl-native \
     "
 
@@ -170,6 +170,7 @@ ASSUME_PROVIDED = "\
 PN = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0] or 'defaultpkgname'}"
 PV = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[1] or '1.0'}"
 PR = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[2] or 'r0'}"
+PRINC ?= "0"
 PF = "${PN}-${EXTENDPE}${PV}-${PR}"
 EXTENDPE = "${@['','${PE\x7d_'][bb.data.getVar('PE',d,1) > 0]}"
 P = "${PN}-${PV}"
@@ -242,7 +243,7 @@ PROVIDES = ""
 PROVIDES_prepend = "${P} ${PF} ${PN} "
 RPROVIDES = ""
 
-MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native virtual/libintl-nativesdk virtual/xserver"
+MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native virtual/libintl-nativesdk virtual/xserver virtual/update-alternatives-native virtual/update-alternatives"
 
 SOLIBS = ".so.*"
 SOLIBS_darwin = ".*.dylib"
@@ -407,7 +408,7 @@ export PATH
 CCACHE = "${@bb.which(bb.data.getVar('PATH', d, 1), 'ccache') and 'ccache '}"
 TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
 
-export CCACHE_DIR = "${TMPDIR}/ccache/${HOST_SYS}/${PN}"
+export CCACHE_DIR = "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
 export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export F77 = "${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
@@ -659,6 +660,7 @@ AUTO_LIBNAME_PKGS = "${PACKAGES}"
 OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
 DISTROOVERRIDES ?= "${DISTRO}"
 MACHINEOVERRIDES ?= "${MACHINE}"
+MACHINEOVERRIDES[vardepsexclude] = "MACHINE"
 
 CPU_FEATURES ?= ""
 CPU_FEATURES_arm ?= "vfp"
@@ -751,7 +753,7 @@ TRANSLATED_TARGET_ARCH ??= "${@d.getVar('TARGET_ARCH', True).replace("_", "-")}"
 # Setup our default hash policy
 BB_SIGNATURE_HANDLER ?= "basic"
 BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
-BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE"
+BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE"
 
 MLPREFIX ??= ""
 MULTILIB_VARIANTS ??= ""

meta/conf/multilib.conf

@@ -348,6 +348,7 @@ BBCLASSEXTEND_append_pn-setserial = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-settings-daemon = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-sgml-common = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-shadow = " ${MULTILIBS}"
+BBCLASSEXTEND_append_pn-shadow-sysroot = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-shared-mime-info = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-slang = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-speex = " ${MULTILIBS}"

meta/files/device_table-minimal.txt

@@ -15,6 +15,7 @@
 /dev/hda	b	660	0	6	3	0	-	-	-
 /dev/hda	b	660	0	6	3	1	1	1	20
 /dev/kmem	c	640	0	15	1	2	-	-	-
+/dev/kmsg	c	600	0	0	1	11	-	-	-
 /dev/mem	c	640	0	15	1	1	-	-	-
 /dev/null	c	666	0	0	1	3	-	-	-
 /dev/ram	b	640	0	0	1	0	0	1	4

meta/lib/oe/data.py

@@ -15,4 +15,4 @@ def typed_value(key, d):
     try:
         return oe.maketype.create(d.getVar(key, True) or '', var_type, **flags)
     except (TypeError, ValueError), exc:
-        bb.msg.fatal(bb.msg.domain.Data, "%s: %s" % (key, str(exc)))
+        bb.msg.fatal("Data", "%s: %s" % (key, str(exc)))

meta/lib/oe/patch.py

@@ -358,7 +358,7 @@ class UserResolver(Resolver):
 
             t = bb.data.getVar('T', self.patchset.d, 1)
             if not t:
-                bb.msg.fatal(bb.msg.domain.Build, "T not set")
+                bb.msg.fatal("Build", "T not set")
             bb.utils.mkdirhier(t)
             import random
             rcfile = "%s/bashrc.%s.%s" % (t, str(os.getpid()), random.random())
@@ -376,7 +376,7 @@ class UserResolver(Resolver):
             os.environ['SHELLCMDS'] = "bash --rcfile " + rcfile
             rc = os.system(bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
             if os.WIFEXITED(rc) and os.WEXITSTATUS(rc) != 0:
-                bb.msg.fatal(bb.msg.domain.Build, ("Cannot proceed with manual patch resolution - '%s' not found. " \
+                bb.msg.fatal("Build", ("Cannot proceed with manual patch resolution - '%s' not found. " \
                     + "Check TERMCMDRUN variable.") % bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
 
             # Construct a new PatchSet after the user's changes, compare the

meta/lib/oe/terminal.py

@@ -57,6 +57,20 @@ class Gnome(XTerminal):
     command = 'gnome-terminal --disable-factory -t "{title}" -x {command}'
     priority = 2
 
+class Xfce(XTerminal):
+    command = 'Terminal -T "{title}" -e "{command}"'
+    priority = 2
+
+    def __init__(self, command, title=None, env=None):
+        # Upstream binary name is Terminal but Debian/Ubuntu use
+        # xfce4-terminal to avoid possible(?) conflicts
+        distro = distro_name()
+        if distro == 'ubuntu' or distro == 'debian':
+            cmd = 'xfce4-terminal -T "{title}" -e "{command}"'
+        else:
+            cmd = command
+        XTerminal.__init__(self, cmd, title, env)
+
 class Konsole(XTerminal):
     command = 'konsole -T "{title}" -e {command}'
     priority = 2
@@ -131,3 +145,12 @@ def check_konsole_version(konsole):
         if ver.startswith('Konsole'):
             vernum = ver.split(' ')[-1]
     return vernum
+
+def distro_name():
+    try:
+        p = Popen(['lsb_release', '-i'])
+        out, err = p.communicate()
+        distro = out.split(':')[1].strip().lower()
+    except:
+        distro = "unknown"
+    return distro

meta/recipes-bsp/apmd/apmd_3.2.2-14.bb

@@ -34,7 +34,7 @@ INITSCRIPT_PARAMS = "defaults"
 
 do_compile() {
 	# apmd doesn't use whole autotools. Just libtool for installation
-	oe_runmake "LIBTOOL=${STAGING_BINDIR_CROSS}/${TARGET_PREFIX}libtool" apm apmd
+	oe_runmake "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool" apm apmd
 }
 
 do_install() {

meta/recipes-bsp/grub/grub_1.99.bb

@@ -41,4 +41,4 @@ do_install_append () {
 
 FILES_${PN}-doc = "${datadir}"
 FILES_${PN} = "/usr /etc"
-
+INSANE_SKIP_${PN} = "arch"

meta/recipes-connectivity/avahi/avahi.inc

@@ -14,8 +14,7 @@ SECTION = "network"
 # python scripts are under GPLv2+
 LICENSE = "GPLv2+ & LGPLv2.1+"
 
-INC_PR = "r7"
-
+INC_PR = "r9"
 DEPENDS = "expat libcap libdaemon dbus glib-2.0"
 
 SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
@@ -23,7 +22,12 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
           file://99avahi-autoipd \
           file://initscript.patch"
 
-inherit autotools pkgconfig update-rc.d gettext
+USERADD_PACKAGES = "avahi-daemon"
+USERADD_PARAM_avahi-daemon = "--system --home /var/run/avahi-daemon \
+                              --no-create-home --shell /bin/false \
+                              --user-group avahi"
+
+inherit autotools pkgconfig update-rc.d gettext useradd
 
 EXTRA_OECONF = "--with-distro=debian \
              --disable-introspection \
@@ -114,15 +118,12 @@ do_install_avahi-autoipd() {
 	install ${WORKDIR}/99avahi-autoipd ${D}${sysconfdir}/udhcpc.d
 }
 
-# At the time the postinst runs, dbus might not be setup so only restart if running
+# At the time the postinst runs, dbus might not be setup so only restart if running 
 
 pkg_postinst_avahi-daemon () {
-	# can't do this offline
 	if [ "x$D" != "x" ]; then
-		exit 1
+		exit 0
 	fi
-	grep "^avahi:" /etc/group > /dev/null || addgroup avahi
-	grep "^avahi:" /etc/passwd > /dev/null || adduser --disabled-password --system --home /var/run/avahi-daemon --no-create-home avahi --ingroup avahi -g Avahi
 
 	DBUSPID=`pidof dbus-daemon`
 

meta/recipes-connectivity/connman/connman.inc

@@ -18,7 +18,12 @@ DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
 INITSCRIPT_NAME = "connman"
 INITSCRIPT_PARAMS = "start 05 5 2 3 . stop 22 0 1 6 ."
 
-inherit autotools pkgconfig update-rc.d
+USERADD_PACKAGES = "${PN}"
+USERADD_PARAM_${PN} = "--system --no-create-home \
+                       --shell /bin/false --groups video,tty,audio \
+                       --user-group xuser"
+
+inherit autotools pkgconfig update-rc.d useradd
 
 do_install_append() {
     install -d ${D}${sysconfdir}/init.d/

meta/recipes-connectivity/connman/connman_0.75.bb

@@ -1,5 +1,5 @@
 require connman.inc
-PR = "r1"
+PR = "r2"
 
 EXTRA_OECONF += "\
   ac_cv_path_WPASUPPLICANT=/usr/sbin/wpa_supplicant \

meta/recipes-connectivity/gypsy/gypsy_0.8.bb

@@ -16,11 +16,11 @@ DEPENDS = "glib-2.0 dbus bluez4 dbus-glib libxslt"
 SRC_URI = "http://gypsy.freedesktop.org/releases/gypsy-${PV}.tar.gz \
            file://fix-unused-but-set-variable-warning.patch \
           "
-PR = "r1"
+PR = "r2"
 
 inherit autotools pkgconfig
 
-FILES_${PN} += "/usr/share/dbus-1/services/"
+FILES_${PN} += "/usr/share/dbus-1/system-services/"
 
 SRC_URI[md5sum] = "32b8db24db86d2dac87b391dd255f4bf"
 SRC_URI[sha256sum] = "1986a58189614a950725c3bc7d05faa3b84695f35cb696326f340ef87fc3acaa"

meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb

@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1"
 
 DEPENDS = "avahi"
 RDEPENDS_${PN} = "avahi-daemon"
-PR = "r3"
+PR = "r4"
 
 SRC_URI = "http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz"
 
@@ -26,14 +26,12 @@ EXTRA_OECONF = "--libdir=${base_libdir} --disable-lynx --enable-avahi"
 # TODO: pattern based configuration update
 pkg_postinst_${PN} () {
 	cat $D/etc/nsswitch.conf | grep "hosts:\s*files dns$" > /dev/null && {
-		cat $D/etc/nsswitch.conf | sed 's/hosts:\s*files dns/& mdns4/' > /tmp/nsswitch.conf
-		mv /tmp/nsswitch.conf $D/etc/nsswitch.conf
+		sed -i 's/hosts:\s*files dns/& mdns4/' $D/etc/nsswitch.conf
 	}
 }
 
 pkg_prerm_${PN} () {
 	cat /etc/nsswitch.conf | grep "hosts:\s*files dns mdns4$" > /dev/null && {
-		cat /etc/nsswitch.conf | sed 's/\(hosts:\s*files dns\) mdns4*/\1/' > /tmp/nsswitch.conf
-		mv /tmp/nsswitch.conf /etc/nsswitch.conf
+		sed -i 's/\(hosts:\s*files dns\) mdns4*/\1/' /etc/nsswitch.conf
 	}
 }

meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bb

@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3"
 
 # util-linux for libblkid
 DEPENDS = "libcap libnfsidmap libevent util-linux tcp-wrappers"
-RDEPENDS_${PN} = "portmap"
+RDEPENDS_${PN} = "portmap python"
 RRECOMMENDS_${PN} = "kernel-module-nfsd"
 
 PR = "r2"

meta/recipes-connectivity/openssh/openssh_5.8p2.bb

@@ -29,6 +29,14 @@ PAM_SRC_URI = "file://sshd"
 SRC_URI[md5sum] = "0541579adf9d55abb15ef927048d372e"
 SRC_URI[sha256sum] = "5c35ec7c966ce05cc4497ac59c0b54a556e55ae7368165cc8c4129694654f314"
 
+inherit useradd update-rc.d
+
+USERADD_PACKAGES = "${PN}-sshd"
+USERADD_PARAM_${PN}-sshd = "--system --no-create-home --home-dir /var/run/sshd --shell /bin/false --user-group sshd"
+INITSCRIPT_PACKAGES = "${PN}-sshd"
+INITSCRIPT_NAME_${PN}-sshd = "sshd"
+INITSCRIPT_PARAMS_${PN}-sshd = "defaults 9"
+
 inherit autotools
 
 # LFS support:
@@ -91,16 +99,6 @@ RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
 DEPENDS_${PN}-sshd += "update-rc.d"
 RDEPENDS_${PN}-sshd += "update-rc.d ${PN}-keygen"
 
-pkg_postinst_${PN}-sshd () {
-	if [ "x$D" != "x" ]; then
-		exit 1
-	else
-		addgroup sshd
-		adduser --system --home /var/run/sshd --no-create-home --disabled-password --ingroup sshd -s /bin/false sshd
-		update-rc.d sshd defaults 9
-	fi
-}
-
 pkg_postinst_${PN}-scp () {
 	update-alternatives --install ${bindir}/scp scp scp.${PN} 90
 }
@@ -117,16 +115,5 @@ pkg_postrm_${PN}-scp () {
 	update-alternatives --remove ${bindir}/scp scp.${PN}
 }
 
-pkg_postrm_${PN}-sshd () {
-	if [ "x$D" != "x" ]; then
-		exit 1
-	else
-		${sysconfdir}/init.d/sshd stop
-		deluser sshd
-		delgroup sshd
-		update-rc.d -f sshd remove
-	fi
-}
-
 CONFFILES_${PN}-sshd = "${sysconfdir}/ssh/sshd_config"
 CONFFILES_${PN}-ssh = "${sysconfdir}/ssh/ssh_config"